Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Good morning a third time Chris, Now unrelated to the funding order, but one of the reasons why timeliness is desirable for CoinSwap is that if possible, we want to ensure that sends from a user wallet are not correlatable with receives into that wallet. Thus, there is the strong suggestion that before sending to a payee, the user wallet should swap, then use the swapped funds to pay the payee, i.e. swap-on-pay. JoinMarket does this in `sendpayment.py`, for example, and this is the recommended way to perform payments out of the JoinMarket wallet. Let me propose an alternative: swap-on-receive+swap-on-change. ZeroLink already suggests that wallets maintain two internal wallets: a pre-mix wallet and a post-mix wallet. With swap-on-receive, when the user wants a receive address, the wallet gets it from the pre-mix wallet address. Then, when wallet notices any unspent funds on any pre-mix wallet address, the wallet automatically swaps it into the post-mix wallet. This is swap-on-receive. Long-term HODLing goes into post-mix wallet addresses. Then, when sending, the wallet selects from the post-mix wallet coins, and spends those coins directly into the payee address. If there is no exact amount, it has to have change. The change output does *not* go to the pre-mix or post-mix wallet address. Instead, it goes to a 2-of-2 funding outpoint for a new swap immediately. This lets the payee receive its funds quickly, as soon as the transaction confirms, without waiting for the CoinSwap to complete. Of course, the user now has to be online to *fully* receive funds (the user cannot spend the funds until it is in the post-mix wallet). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Good morning again Chris, I am uncertain if you are aware, but some years ago somebody claimed that 2p-ECDSA could use Scriptless Script as well over on lightning-dev. * https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf * https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html I cannot claim to follow the math enough to say it is actually secure, but the idea does exist. If this is sufficiently secure, we can fold the Spilman backout into the scriptless script swap as well. * Alice creates secret keypairs A[0] = a[0] * G, A[1] = a[1] * G * Bob creates secret keypairs B[0] = b[0] * G, B[1] = b[1] * G * Alice creates (but does not sign) funding from Alice -> A[0] && B[0] * Bob provides partial signature for A[0] && B[0] -(nLockTime=locktime1)-> Alice to Alice and Alice completes this signature and stashes it. * Bob creates (but does not sign) funding from Bob -> A[1] && B[1] * Alice provides partial signature for A[1] && B[1] -(nLockTime=lockTime2)-> Bob to Bob and Bob completes this signature and stashes it. * Alice and Bob sign and broadcast their funding transactions. * This can safely be done in any order; Bob will refuse to continue with the protocol until it sees Alice funding is confirmed, and will abort if locktime2 is too near. * Alice waits for Bob funding tx to confirm. * Alice provides a 2p-ECDSA adaptor signature for A[1] && B[1] --> Alice; the adaptor signature, when completed, reveals the secret a[0] to Bob. * Bob waits for Alice funding tx to confirm. * Bob provides the partial signature for the given adaptor signature for A[1] && B[1] --> Alice and Alice completes this signature and stashes it. * Alice gives a[0] outright to Bob. * Bob gives b[1] outright to Alice. * Alice spends the A[1] && B[1] output before locktime2. * Bob spends the A[0] && B[0] output before locktime1. I also pointed out the griefing problem in Lightning also applies to SwapMarket. Bob can limit the griefing problem by requiring that locktime2 <= now + 12, and requiring that locktime1 >= now + 60. This means that Alice has to lock its funds for 10 hours if it forces Bob to lock its funds for 2 hours, making it undesirable as an attack on competing makers. This does prevent chaining (no maker is going to accept the outgoing), but if Alice wants chaining it can always use the private key handed over to immediately start a funding tx with another Bob. (This is not a good solution for griefing in the Lightning Network since channels are intended to be reused there, whereas the Spilman channels in CoinSwap exist only to allow funding transactions to confirm in any order onchain, and are used only for the specific swap; in Lightning the forwarding node has an incentive to release the incoming HTLC immediately instead of imposing the incoming wait time since the funding can be reused for a different payment, but in CoinSwap it cannot be reused anyway, so it could just let the incoming timelock lapse instead of releasing that encumbrance as would be done in Lightning.) Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Good morning Chris, > I think I'm having trouble understanding this, does it work like this: > > Say we're in the 2-party coinswap case (Alice and Bob) > > We have Alice's funding transaction: > Alice UTXO ---> 2of2 multisig (Alice+Bob) > > And we have the regular contract transaction > 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock > > And you propose a second pre-signed transaction? > 2of2 multisig (Alice+Bob) ---> Bob+timelock2 No, it is: 2of2 multisig (Alice+Bob) --(nLockTime=locktime1)-> Alice The timelock is imposed as a `nLockTime`, not as an `OP_CLTV` (so not in the output of the tx, but part of the tx), and the backout returns the funds to Alice, not sends it to Bob. This transaction is created *before* the contract transaction. The order is: * Create (but not sign) Alice funding tx (Alice --> Alice+Bob). * Create and sign Alice backout transaction (Alice+Bob -(nLockTime=locktime1)-> Alice). * Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret). * Create and sign Bob backout transaction (Alice+Bob+sharedSecret -(nLocktime=locktime2)-> Bob) where timelock2 < timelock1. * Sign and broadcast funding txes. * At this point, even if Bob funding tx is confirmed but Alice funding tx is not, Bob can recover funds with the backout, but Alice cannot steal the funds (since there is no hashlock branch at this point). * When Alice funding tx is confirmed, create and sign contract transaction (Alice+Bob --> Alice+timelock1 OR Bob+hashlock). * When Bob funding tx is confirmed and Bob has received the Alice contract transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecret --> Bob+timelock2 OR Alice+hashlock). * Continue as normal. In effect, the backout transaction creates a temporary Spilman unidirectional time-bound channel. We just reuse the same timelock on the HTLC we expect to instantiate, as the time bound of the Spilman channel; the timelock exists anyway, we might as well reuse it for the Spilman. Creation of the contract tx invalidates the backout tx (the backout tx is `nLockTime`d, the contract tx has no such encumbrance), but the backout allows Alice and Bob to fund their txes simultaneously without risk of race loss. However, they do still have to wait for (deep) confirmation before signing contract transactions, and Bob has to wait for the incoming contract transaction as well before it signs its outgoing contract transaction. The protocol is trivially extendable with more than one Bob. The insight basically is that we can split CoinSwap into a "channel establishment" phase and "HTLC forwarding" phase followed by "HTLC resolution" and "private key handover". HTLC forwarding and HTLC resolution are "done offchain" in the channels, and channel establishment can be done in any order, including reverse. Indeed, the Spilman channel need not have the same timelock as the HTLC it will eventually host: it could have a shorter timelock, since the contract transaction has no `nLockTime` it can be instantiated (with loss of privacy due to the nonstandard script) before the Spilman timeout. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Good day ZmnSCPxj, >>> But S6 has the mild advantage that all the funding transactions paying to >>> 2-of-2s can appear on the same block, whereas chaining swaps will have a >>> particular order of when the transactions appear onchain, which might be >>> used to derive the order of swaps. >> >> On the other hand, funds claiming in S6 is also ordered in time, so >> someone paying attention to the mempool could guess as well the order of >> swaps. >> >> I think this is wrong, and that it's possible for the funding >> transactions of chained/routed swaps to all be in the same block as well. >> >> In CoinSwap it's possible to get DOS'd without the other side spending >> money if you broadcast your funding transaction first and the other side >> simply disappears. You'd get your money back but you have to waste time >> and spend miner fees. The other side didn't spend money to do this, not >> even miner fees. >> >> From the point of view of us as a maker in the route, we know we won't >> get DOS'd like this for free if we only broadcast our funding >> transaction once we've seen the other side's funding transaction being >> broadcast first. This should work as long as the two transactions have a >> similar fee rate. There might be an attack involving hash power: If the >> other side has a small amount of hash power and mines only their funding >> transaction in a manner similar to a finney attack, then our funding >> transaction should get mined very soon afterwards by another miner and >> the protocol will continue as normal. If the other side has knowledge of >> the preimage and uses it to do CPFP and take the money, then we can >> learn that preimage and do our own CPFP to get our money back too. > > How about RBF? > > A taker Alice can broadcast the funding tx spending its own funds. > The funding tx spends funds controlled unilaterally by Alice. > Alice can sign a replacement transaction for those funds, spending them to an > address with unilateral control, and making the funding tx output with all > the obligations attached never get confirmed in the first place. > > The chances may be small --- Bob can certainly monitor for Alice broadcasting > a replacement and counter-broadcast its own replacement --- but the risk > still exists. > TANSTAAGM (There Aint No Such Thing As A Global Mempool) also means Alice > could arrange the replacement by other means, such as not using the > RBF-enabled flag, broadcasting the self-paying replacement near miner nodes, > and broadcasting the CoinSwap-expected funding tx near the Bob fullnode; Bob > fullnode will then reject attempts to replace it, but miners will also reject > the CoinSwap-expected funding tx and it will not confirm anyway. > > > With the pre-SAS 4-tx setup, this potentially allows Alice to steal the funds > of Bob; after Alice gets its funding-tx-replacement confirmed together with > the Bob honest-funding-tx, Alice can use the contract transaction and publish > the preimage to take the Bob funds. > Since the Alice-side funding tx has been replaced, knowledge of the hash > preimage will not help Bob any: the Alice funding tx has been replaced and > Bob cannot use the preimage to claim it (it does not exist). > > > With SAS Alice cannot outright steal the Bob funds, but the Bob funds will > now be locked in a 2-of-2 and Alice can take it hostage (either Bob gives up > on the funds, i.e. donates its value to all HODLers, or Bob gives most of the > value to Alice). > > > For the avoidance of theft, it is probably better for Bob to wait for > Alice-side funding tx to confirm, probably deeply because reorgs suck. > > This at least makes it costly to perform this attack; you have to lock more > of your funds longer in order to induce a competitor to lock its funds. > > > Come to think of it, the same issue probably holds for S6 as well, the > funding tx with the longest timelock has to confirm first before the next is > even broadcast, bleah. Your RBF observation actually blows my idea out of the water. Not just because of RBF but because of an attack by a miner. Supposing that Alice starts with knowledge of the hash preimage, if she uses RBF to make her funding transaction never confirm but allows Bob's funding transaction to confirm, then Alice can use her preimage to take the money from Bob's funding transaction. Bob will learn the value of the preimage but it won't be much good to him because Alice's funding transaction isn't valid anymore. Alice will get money from her funding transaction and also money from Bob's funding transaction. Because of this attack, it's pretty clear that a CoinSwap peer who starts _without_ knowledge of the preimage must wait for the other side's funding transaction to actually confirm, perhaps even with multiple confirmations if they fear that the other side has access to hashpower. For example, a miner could play the role of Alice and use this attack to almost-risklessly steal Bob's co
Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Hi, As far as I understand your answer is "let's try to use what exists", this is not what I am proposing and not the Tor network, no "standard" exit nodes, different hidden services, decentralized anonymizer network unlike the Tor network, nodes are anonymizing themselves Comments below, please let me know what is unclear in the description of the project so I can modify it because all the time I get the impression that it is mixed with the Tor network while it just has a very little to do with it, and I don't get that the simple principle of communicating between nodes using the Tor protocol without RDV points is never considered Regards, Le 05/06/2020 à 13:44, ZmnSCPxj a écrit : > Good morning Aymeric, > >> The issue each time there are discussions/research linking to Tor is that it >> is biased since the beginning because based on a wrong postulate: using the >> Tor network >> > Well, in the interest of using the wrong tool for a highly important job, let > me present this thought: Then for an important job people should use the right tool... > > * The Tor network is weakened due to its dependence on a limited set of exit > nodes. And centralized structure, limited set of nodes to make it short, for some (or a lot) misbehaving, not designed for bitcoin, nothing prevents bitcoin from operating its own anonymizer system, which I am proposing > * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services. Good to a certain extent... if you want to hide that you are operating a bitcoin node you can use RDV points (ie hidden services) but if you don't care you just connect anonymized circuits between bitcoin nodes, this is more "direct" and does not exist in the Tor network, this includes light clients that can act as relays also > * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet > connections, the issue is with Tor-to-clearnet connections. There are plenty of Tor-to-Tor issues, not theoretical but in the real world, "Tor-to-clearnet" can be done outside of the Tor network, ie the bitcoin network > * Of course, no miner is going to run over Tor because latency, so all the > miners will be on clearnet. Probably, again I am not proposing a remake of the Tor network, I don't see the use for a miner to hide (neither for a bitcoin node to use RDV points), but they can be part of the global anonymized system, please see below > * So make your own bridge between Tor and clearnet. > * Run two fullnodes on your computer (with sufficient ingenuity, you can > probably share their block storages, or make one pruning). > * One fullnode is on the public network but runs in `blocksonly` so it does > not propagate any transactions (which might be attached to your public IP). > * The other fullnode is on the Tor network and has an `-addnode` to the > public-network node via `localhost`, which I assume is very hard for an > eclipse attacker to get at. > * Use the Tor-fullnode to propagate your transactions. Yes but one full node should be able to do this alone, ie implement both interfaces, like miners and everybody in fact (or Peersm bridges with bittorrent if you look at the history of the project) > > Of course, the eclipse attacker can still attack all Tor exit nodes and block > outgoing transaction traffic to perform eclipse attacks. > And if you decide to propagate transactions to the public-network node then > you pretty much lose your privacy there. Please see the convergence link, it's not based on the assumption that "the more you are the better you can hide and the lesser you can get attacked", this does not work at all, it's based on the assumption that even with a reduced set of peers it becomes very difficult to know who is doing what and whom is talking to whom, the concept of exiting/bridging to clearnet(s) is not clearly detailed in this version but appears on the drawings ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Good morning Aymeric, > The issue each time there are discussions/research linking to Tor is that it > is biased since the beginning because based on a wrong postulate: using the > Tor network > Well, in the interest of using the wrong tool for a highly important job, let me present this thought: * The Tor network is weakened due to its dependence on a limited set of exit nodes. * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services. * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections. * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet. * So make your own bridge between Tor and clearnet. * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning). * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP). * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at. * Use the Tor-fullnode to propagate your transactions. Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks. And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit : >> [Tor is tricky](https://arxiv.org/abs/1410.6079) too > Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes > me that a mitigation would be to run your Bitcoin fullnode on clearnet while > running your Lightning node over Tor. > Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) > "only" loses you the ability to pay, receive, or route (and thereby earn > forwarding fees), but as long as your blockchain view is clear, it should be > fine. > > Of course, the Lightning node could still be correlated with the Bitcoin node > when transactions are broadcast with the attached Bitcoin node (as noted in > the paper). > Instead the Lightning node should probably connect, over Tor, to some random > Bitcoin fullnodes / Electrum servers and broadcast txes to them. > > And this seems to tie with what you propose: that the LN node should use a > different view-fullnode from the broadcast-fullnode. > The issue each time there are discussions/research linking to Tor is that it is biased since the beginning because based on a wrong postulate: using the Tor network I will not elaborate on this again, it's an obvious very bad idea to use the Tor network for bitcoin It's not a bad idea to use the Tor protocol with no story of exit nodes and hidden services, linking again to: https://github.com/Ayms/node-Tor#phase-4-and-phase-5 And new link: http://www.peersm.com/Convergence-2020.pdf "A universal and generic architecture to anonymize any application or protocol and turn it into an independent decentralized p2p network inside browsers and servers, with browsers acting as servers" LN and bitcoin nodes would be relays and/or RDV points and/or clients and serving parties, some Tor network nodes could be used in the middle also (relays only) but in any case sybils/eclipse attacks become much more difficult to perform (or unlikely depending on how the peer discovery system is designed) bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor) Then question for possible future tests: is there a simple way to pipe the bitcoin protocol via stdin/stdout? (the socks interface could be used but we already saw that it did raise issues) -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
