Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium
Good morning Chris, > > Looking at these equations, I realize that the incentives against > post-coinswap-theft-attempt still work even if we set K = 0, because the > extra miner fee paid by Bob could be enough disincentive. This made me pause for a moment, but on reflection, is correct. The important difference here relative to v1 is that the mining fee for the collateralized contract transaction is deducted from the `Jb` input provided by Bob. > Unlike the v1 protocol, each CoinSwap party knows a different version of > the contract transactions, so the taker Alice always knows which maker > broadcast a certain set of contract transactions, and so can always ban > the correct fidelity bond. Great observation, and an excellent property to have. Will go think about this more. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium
Hello list, This email is an appendium or modification of the earlier CoinSwap protocol published on this list. It is intended to fix the problems found in review. (Original email quoted here too) On 11/08/2020 13:05, Chris Belcher via bitcoin-dev wrote: > I'm currently working on implementing CoinSwap (see my other email > "Design for a CoinSwap implementation for massively improving Bitcoin > privacy and fungibility"). > > CoinSwaps are special because they look just like regular bitcoin > transactions, so they improve the privacy even for people who do not use > them. Once CoinSwap is deployed, anyone attempting surveillance of > bitcoin transactions will be forced to ask themselves the question: how > do we know this transaction wasn't a CoinSwap? > > This email contains a detailed design of the first protocol version. It > makes use of the building blocks of multi-transaction CoinSwaps, routed > CoinSwaps, liquidity market, private key handover, and fidelity bonds. > It does not include PayJoin-with-CoinSwap, but that's in the plan to be > added later. > > == Routed CoinSwap == > > Diagram of CoinSwaps in the route: > > Alice > Bob > Charlie > Alice > > Where (>) means one CoinSwap. Alice gives coins to Bob, who gives > coins to Charlie, who gives coins to Alice. Alice is the market taker > and she starts with the hash preimage. She chooses the CoinSwap amount > and chooses who the makers will be. > > This design has one market taker and two market makers in its route, but > it can easily be extended to any number of makers. > > == Multiple transactions == > > Each single CoinSwap is made up of multiple transactions to avoid amount > correlation > > (a0 BTC) ---> (b0 BTC) ---> (c0 BTC) ---> > Alice (a1 BTC) ---> Bob (b1 BTC) ---> Charlie (c1 BTC) ---> Alice > (a2 BTC) ---> (b2 BTC) ---> (c2 BTC) ---> > > The arrow (--->) represent funding transactions. The money gets paid to > a 2-of-2 multisig but after the CoinSwap protocol and private key > handover is done they will be controlled by the next party in the route. > > This example has 6 regular-sized transactions which use approximately > the same amount of block space as a single JoinMarket coinjoin with 6 > parties (1 taker, 5 makers). Yet the privacy provided by this one > CoinSwap would be far far greater. It would not have to be repeated in > the way that Equal-Output CoinJoins must be. > > == Direct connections to Alice === > > Only Alice, the taker, knows the entire route, Bob and Charlie just know > their previous and next transactions. Bob and Charlie do not have direct > connections with each other, only with Alice. > > Diagram of Tor connections: > > Bob Charlie > | / > | / > | / > Alice > > When Bob and Charlie communicate, they are actually sending and > receiving messages via Alice who relays them to Charlie or Bob. This > helps hide whether the previous or next counterparty in a CoinSwap route > is a maker or taker. > > This doesn't have security issues even in the final steps where private > keys are handed over, because those private keys are always for 2-of-2 > multisig and so on their own are never enough to steal money. > > > === Miner fees === > > Makers have no incentive to pay any miner fees. They only do > transactions which earn them an income and are willing to wait a very > long time for that to happen. By contrast takers want to create > transactions far more urgently. In JoinMarket we coded a protocol where > the maker could contribute to miner fees, but the market price offered > of that trended towards zero. So the reality is that takers will pay all > the miner fees. Also because makers don't know the taker's time > preference they don't know how much they should pay in miner fees. > > The taker will have to set limits on how large the maker's transactions > are, otherwise makers could abuse this by having the taker consolidate > maker's UTXOs for free. > > == Funding transaction definitions == > > Funding transactions are those which pay into the 2-of-2 multisig addresses. > > Definitions: > I = initial coinswap amount sent by Alice = a0 + a1 + a2 > (WA, WB, WC) = Total value of UTXOs being spent by Alice, Bob, Charlie >respectively. Could be called "wallet Alice", "wallet >Bob", etc > (B, C) = Coinswap fees paid by Alice and earned by Bob and Charlie. > (M1, M2, M3) = Miner fees of the first, second, third, etc sets of >funding transactions. Alice will choose what these are >since she's paying. > multisig(A+B) = A 2of2 multisig output with private keys held by A and B > > The value in square parentheses refers to the bitcoin amount. > > Alice funding txes > [WA btc] ---> multisig (Alice+Bob) [I btc] > change [WA-M1-I btc] > Bob funding txes > [WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc] >
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
subscribe pls https://www.youtube.com/channel/UCcRPSO-n2HgolBFKzW3re4Q On Saturday, September 5, 2020, Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Chris, > > I forgot to underscore that contract transaction output must be grieved by > at least a CSV of 1. Otherwise, a malicious counterparty can occupy with > garbage both the timelock-or-preimage output and its own anchor output thus > blocking you to use the bumping capability of your own anchor ouput. > > A part of this, I think it works. > > > Another possible fix for both vulnerabilities is to separate the > > timelock and hashlock cases into two separate transactions as described > > by ZmnSCPxj in a recent email to this list. This comes at the cost of > > breaking private key handover allowing coins to remain unspent > indefinitely. > > This works too assuming these second-stage transactions aren't malleable > at all (e.g SIGASH_SINGLE). Other ways you can increase their > feerate/absolute fee and you're back to the initial situation. > > Beyond note also that anchors-on-second-stage are more risky here, as > otherwise your counterparty can again attach a low-feerate child. In case > of concurrent broadcast (assuming you haven't achieved to claim the output > before timelock expiration due to network outage/mempool-congestion) you > might not see your counterparty version. I.e, your local mempool has the > timelock tx and the rest of the network the hashlock and your CPFP bump > won't propagate as being an orphan. > > So you're left with a RBF-range, which is mostly okay minus a theoretical > concern : a party guessing the odds to lose the balance are high can > broadcast/send out-of-band the highest-fee bound to miners thus > incentivizing them to censor a honest, low-fee preimage tx. A > "nothing-at-stake-for-genuinely-evil-counterparty" issue. > > > Another possible fix for the second attack, is to encumber the output > > with a `1 OP_CSV` which stops that output being spent while unconfirmed. > > This seems to be the simplest way if your aim is to only fix the second > > attack. > > Yes you don't package fee malleability so an honest party can always > unilaterally bump the feerate and override concurrent bids. > > > That said, I would lean towards anchors and thus unileratel fee bumping. > Feerate interactivity among a multi-party protocol should be seen as an > oracle to leak the full-node of a participant. By sending a range of > conflicting transactions with different feerates to a set of network > mempools I could theoretically observe variations in the protocol feerate > announced. > > I would recommend you to have a look on this paper, if it's not done yet : > https://arxiv.org/pdf/2007.00764.pdf, the first one analyzing privacy > holistically across Bitcoin layers. > > Cheers, > > Antoine > > Le sam. 29 août 2020 à 18:03, Chris Belcher a écrit : > >> Hello Antoine, >> >> Thanks for the very useful insights. >> >> It seems having just one contract transaction which includes anchor >> outputs in the style already used by Lightning is one way to fix both >> these vulnerabilities. >> >> For the first attack, the other side cannot burn the entire balance >> because they only have access to the small amount of satoshi of the >> anchor output, and to add miner fees they must add their own inputs. So >> they'd burn their own coins to miner fees, not the coins in the contract. >> >> For the second attack, the other side cannot do transaction pinning >> because there is only one contract transaction, and all the protections >> already developed for use with Lightning apply here as well, such as >> CPFP carve out. >> >> >> Another possible fix for both vulnerabilities is to separate the >> timelock and hashlock cases into two separate transactions as described >> by ZmnSCPxj in a recent email to this list. This comes at the cost of >> breaking private key handover allowing coins to remain unspent >> indefinitely. >> >> Another possible fix for the second attack, is to encumber the output >> with a `1 OP_CSV` which stops that output being spent while unconfirmed. >> This seems to be the simplest way if your aim is to only fix the second >> attack. >> >> >> These are all the possible fixes I can think of. >> >> Regards >> Chris >> >> On 24/08/2020 20:30, Antoine Riard wrote: >> > Hello Chris, >> > >> > I think you might have vulnerability issues with the current design. >> > >> > With regards to the fee model for contract transactions, AFAICT timely >> > confirmation is a fund safety matter for an intermediate hop. Between >> the >> > offchain preimage reveal phase and the offchain private key handover >> phase, >> > the next hop can broadcast your outgoing contract transactions, thus >> > forcing you to claim quickly backward as you can't assume previous hop >> will >> > honestly cooperate to achieve the private key handover. This means that >> > your range of pre-signed RBF-transactions must theoretically
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hi Zeeman, I think one of the general problems for any participant in an interdependent chain of contracts like Lightning or CoinSwap is to avoid a disequilibrium in its local HTLC ledger. Concretely sending forward more than you receive backward. W.r.t, timelocks delta aim to enforce order of events, namely that a forward contract must be terminated before any backward contract to avoid a discrepancy in settlement. Order of events can be enforced by a) absolute timelocks and thus linearized on the same scale by blockchain ticks or b) by a counterparty to two relative-time locked contracts which observe the broadcast of the backward transaction and thus manually trigger the kickoff of forward timelock by broadcasting the corresponding transaction. With this rough model in mind, pinning an absolute or relative timelocked transaction produce the same effect, i.e breaking contracts settlement order. > This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition. > There is no transaction that both participants hold in completely-signed form I don't think that's different from the current model where you have either a valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never full witness material to build both ? I see a theoretical issue with RBF-range, if you're likely to lose the balance, you can broadcast your highest-RBF version thus incentivizing miners to censor counterparty claim tx. Kind of a "nothing at stake" issue. As of today, you have to take this fee out of your pocket if you want to incentivize miners to act so, not promising a fee from an ongoing disputed balance. > Private key turnover is still useful even in an absolute-timelock world. The way I understand the either-HTLC-or-private-key-turnover construction in CoinSwap is for the HTLC to serve as a security backup in case the cooperative key turnover fails. Lightning don't have this model as you don't switch funding transaction ownership. > To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A. This limits its funding lockup to 1 week. Okay I think I understand your point. So by intermediating the chain with the taker you ensure that in case of previous hop failure, taker funds are only timelocked for the delta of this faulting hop not the whole route. But still not anchoring onchain the next route segment means that any moment the next maker can exit from the proposed position ? That's interesting, so a) you require all takers to lock their funds onchain before initiating the whole routing and you will pay more in service fees or b) you only lock them step by step but you increase risk of next hop default and thus latency. Roughly. It might be an interesting construction to explore on its own, minus the downside of producing weird spend patterns due to next hop maker bidding with another party. Cheers, Antoine Le lun. 24 août 2020 à 23:16, ZmnSCPxj a écrit : > > Good morning Antoine, > > > > Note, I think this is independent of picking up either relative or > absolute timelocks as what matters is the block delta between two links. > > I believe it is quite dependent on relative locktimes. > Relative locktimes *require* a contract transaction to kick off the > relative locktime period. > On the other hand, with Scriptless Script (which we know how to do with > 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a > contract transaction. > > With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one > participant holds a completely-signed timelock transaction while the other > participant holds a completely-signed pointlock transaction. > This can be arranged by having one side offer partial signatures for the > transaction of the other, and once completing the signature, not sharing it > with the other until we are ready to actually broadcast the transaction of > our own volition. > There is no transaction that both participants hold in completely-signed > form. > > This should remove most of the shenanigans possible, and makes the 30xRBF > safe for any range of fees. > I think. > > Since for each PTLC a participant holds only its "own" transaction, it is > possible for a participant to define its range of fees for the RBF versions > of the transaction it owns, without negotiation with the other participant. > Since the fee involved is deducted from its own transaction, each > participant can define this range of RBFed fees and impose it on the > partial signatures it gets from the other participant. > > -- > > Private key turnover is still useful even in an absolute-timelock world. > > If we need to bump up the block delta between links, it might be > impractical to have the total delta of a multi-hop swap be too long at the > taker. > > As a concrete example,
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hi Chris, I forgot to underscore that contract transaction output must be grieved by at least a CSV of 1. Otherwise, a malicious counterparty can occupy with garbage both the timelock-or-preimage output and its own anchor output thus blocking you to use the bumping capability of your own anchor ouput. A part of this, I think it works. > Another possible fix for both vulnerabilities is to separate the > timelock and hashlock cases into two separate transactions as described > by ZmnSCPxj in a recent email to this list. This comes at the cost of > breaking private key handover allowing coins to remain unspent indefinitely. This works too assuming these second-stage transactions aren't malleable at all (e.g SIGASH_SINGLE). Other ways you can increase their feerate/absolute fee and you're back to the initial situation. Beyond note also that anchors-on-second-stage are more risky here, as otherwise your counterparty can again attach a low-feerate child. In case of concurrent broadcast (assuming you haven't achieved to claim the output before timelock expiration due to network outage/mempool-congestion) you might not see your counterparty version. I.e, your local mempool has the timelock tx and the rest of the network the hashlock and your CPFP bump won't propagate as being an orphan. So you're left with a RBF-range, which is mostly okay minus a theoretical concern : a party guessing the odds to lose the balance are high can broadcast/send out-of-band the highest-fee bound to miners thus incentivizing them to censor a honest, low-fee preimage tx. A "nothing-at-stake-for-genuinely-evil-counterparty" issue. > Another possible fix for the second attack, is to encumber the output > with a `1 OP_CSV` which stops that output being spent while unconfirmed. > This seems to be the simplest way if your aim is to only fix the second > attack. Yes you don't package fee malleability so an honest party can always unilaterally bump the feerate and override concurrent bids. That said, I would lean towards anchors and thus unileratel fee bumping. Feerate interactivity among a multi-party protocol should be seen as an oracle to leak the full-node of a participant. By sending a range of conflicting transactions with different feerates to a set of network mempools I could theoretically observe variations in the protocol feerate announced. I would recommend you to have a look on this paper, if it's not done yet : https://arxiv.org/pdf/2007.00764.pdf, the first one analyzing privacy holistically across Bitcoin layers. Cheers, Antoine Le sam. 29 août 2020 à 18:03, Chris Belcher a écrit : > Hello Antoine, > > Thanks for the very useful insights. > > It seems having just one contract transaction which includes anchor > outputs in the style already used by Lightning is one way to fix both > these vulnerabilities. > > For the first attack, the other side cannot burn the entire balance > because they only have access to the small amount of satoshi of the > anchor output, and to add miner fees they must add their own inputs. So > they'd burn their own coins to miner fees, not the coins in the contract. > > For the second attack, the other side cannot do transaction pinning > because there is only one contract transaction, and all the protections > already developed for use with Lightning apply here as well, such as > CPFP carve out. > > > Another possible fix for both vulnerabilities is to separate the > timelock and hashlock cases into two separate transactions as described > by ZmnSCPxj in a recent email to this list. This comes at the cost of > breaking private key handover allowing coins to remain unspent > indefinitely. > > Another possible fix for the second attack, is to encumber the output > with a `1 OP_CSV` which stops that output being spent while unconfirmed. > This seems to be the simplest way if your aim is to only fix the second > attack. > > > These are all the possible fixes I can think of. > > Regards > Chris > > On 24/08/2020 20:30, Antoine Riard wrote: > > Hello Chris, > > > > I think you might have vulnerability issues with the current design. > > > > With regards to the fee model for contract transactions, AFAICT timely > > confirmation is a fund safety matter for an intermediate hop. Between the > > offchain preimage reveal phase and the offchain private key handover > phase, > > the next hop can broadcast your outgoing contract transactions, thus > > forcing you to claim quickly backward as you can't assume previous hop > will > > honestly cooperate to achieve the private key handover. This means that > > your range of pre-signed RBF-transactions must theoretically have for fee > > upper bound the maximum of the contested balance, as game-theory side, > it's > > rational to you to burn your balance instead of letting your counterparty > > claim it after timelock expiration, in face of mempool congestion. Where > > the issue dwells is that this fee is pre-committed and not cancelled when > > the
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Chris, and probably also Lightningers, > However, it might be possible to prevent the maker from learning the > collateral input at all. > > If my understanding of BIP-143 is correct, inputs are hashed separately > (`hashPrevouts`) from outputs (`hashOutputs`). > Bob can provide the `hashPrevouts` as an opaque hash, while providing a > decommitment of `hashOutputs` to show that the outputs of the collateralized > contract transaction are correct, which is all that Charlie really needs to > know. > > Bob is incentivized to provide the correct `hashPrevouts`, because if it > provides an incorrect `hashPrevouts` it cannot get a signature for a > transaction it can use in case of a protocol abort, thus potentially losing > its money in case of a protocol abort. > Conversely, Charlie does not care where Bob gets the funds that goes into its > contract output come from, it only cares that the Bob collateralized contract > output is I+K. > It loses nothing to sign that transaction, and it would prefer that > transaction since its own contract output is only I. > > This solution is mildly "unclean" as it depends on the details of the sighash > algorithm, though, and is not proposed seriously. > Hopefully nobody will change the sighash algorithm anytime soon. > > In addition, it complicates reusing Lightning watchtowers. > Lightning watchtowers currently trigger on txid (i.e. it would have triggered > on the txid of the B collateralized contract tx), but watching this needs to > trigger on the spend of a txo, since it is not possible to prove that a > specific `hashPrevouts` etc. goes with a specific txid without revealing the > whole tx (which is precisely what we are trying to avoid), as both are hashes. > Watchtowers may need to be entrusted with privkeys, or need to wait for > `SIGHASH_ANYPREVOUT` so that the exact txid of the B collateralized contract > tx does not need to be fixed at signing time, thus this solution is > undesirable as well. On the other hand, when considering Decker-Russell-Osuntokun, the `(halftxid, encrypted_blob)` approach to watchtowers simply does not work. Watchtowers are simpler in Decker-Russell-Osuntoku if and only if the watchtower knows the funding outpoint, therefore knows which channel it is watching *before* an attack on the channel occurs, and is less private. I have argued before that we should instead use `(sighash[0:15], encrypted_blob)` rather than `(txid[0:15], encrypted_blob)`. This makes Decker-Russell-Osuntokun blobs indistinguishable from Poon-Dryja blobs, and the watchtower is not even made aware what the commitment type of the channel is until an actual attack occurs. If watchtowers use `(sighash[0:15], encrypted_blob)` instead, the proposal to hide the collateral input behind `hashPrevouts` would be workable, as Charlie knows the entire sighash of the B collateralized contract transaction even if it does not know the txid. This also does not reveal the funding outpoint, or whether it is watching a Poon-Dryja channel, a Decker-Russell-Osuntokun channel, or a CoinSwap. -- Even if we propose that CoinSwap makers should run their own watchtowers rather than hire a public watchtower, it's safer for a CoinSwap maker to have watchtowers that are unaware of exactly *what* they are watching. If the watchtowers are aware of the funding outputs they are watching, then every additional watchtower a maker creates increases the attack surface on the privacy of the maker, as the funding outputs becoming known allows the maker hodlings to be derived. If watchtowers only get a partial sighash, then the information that they contain are not sufficient by themselves to determine what coins are owned by the maker, thus every additional watchtower is no longer a potential attack vector on the privacy of the maker. So this is off-topic, but anyway, we should probably move to using `sighash[0:15]` instead of `txid[0:15]` for watchtowers. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Antoine, > > This can be arranged by having one side offer partial signatures for the > > transaction of the other, and once completing the signature, not sharing it > > with the other until we are ready to actually broadcast the transaction of > > our own volition. > > There is no transaction that both participants hold in completely-signed > > form > > I don't think that's different from the current model where you have either a > valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never full > witness material to build both ? It is different in that the current (actually, now *previous*) model looks like this: funding out -> contract tx --> HTLC-timeout OR HTLC-success Whereas what I am describing looks like this: funding out -> HTLC-timeout OR HTLC-success The attack being described has to do with the fact that, after private key turnover (i.e. after hash-lock resolution), the contract tx can be used to at least annoy the supposed new owner of the funding out, since the contract tx deducts fees from its input to pay for itself. And at the end of the swap (after private key turnover) the one who funded the funding outpoint (and swapped its control for this outpoint already, for a different outpoint) can at least try to broadcast the contract tx for a *chance* that the HTLC-timeout becomes valid and it can steal the coin even after taking the swapped coin on the other side of the swap. Chris recently described a different technique, which has different contract txes, with the contract tx held by the offerrer of the HTLC (who can otherwise later annoy the acceptor of the HTLC once the HTLC has been hash-resolved) costing the offerrer of the HTLC some coins if it is published after swap completion. > > To reduce this risk, A can instead first swap A->B->A, then when that > > completes, A->C->A. > This limits its funding lockup to 1 week. > > Okay I think I understand your point. So by intermediating the chain with the > taker you ensure that in case of previous hop failure, taker funds are only > timelocked for the delta of this faulting hop not the whole route. But still > not anchoring onchain the next route segment means that any moment the next > maker can exit from the proposed position ? > > That's interesting, so a) you require all takers to lock their funds onchain > before initiating the whole routing and you will pay more in service fees or > b) you only lock them step by step but you increase risk of next hop default > and thus latency. Roughly. > > It might be an interesting construction to explore on its own, minus the > downside of producing weird spend patterns due to next hop maker bidding with > another party. > Correct, a taker can pay higher fees for lots of smaller swaps that reduce its lockup risk, or pay less (with similar privacy bought) but with greater total lockup risk. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Chris,
> > This seems a great solution!
> > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be
> > B as well.
> > This means, the taker has to have some collateral input, of at least value
> > K, that it cannot swap (because if it tried to swap that amount, it would
> > be unable to provide a collateral as well).
> > How much does C need to know about the B collateralized contract
> > transaction?
> > At the minimum, it has to know the output pays out to the correct contract,
> > so it seems to me it has to know the entire B collateralized contract
> > transaction, meaning it learns another input of B ("collateral(B)") that is
> > not otherwise involved in the CoinSwap.
> > This is important, again, if B is a taker, as it means an unrelated input
> > of B is now learned by C as having the same ownership as B.
>
> Yes, in fact that's why in my example I talk about a CoinSwap between
> two makers Bob and Charlie. Makers can be reasonably expected to own
> multiple UTXOs, but takers cannot. As you say because collateral
> payments breaks the ability of takers to sweep their entire wallet
> through CoinSwap.
>
> Happily, I think takers themselves don't need to use collateral
> payments. Here's an argument to why:
>
> Riskless theft attempts by the taker who no longer controls the coins
> actually isnt riskless or costless: Because it reduces the privacy of
> the previously-owned coins. If a taker genuinely wanted good privacy
> (Which, after all, they're paying for via miner fees and CoinSwap fees)
> then they would benefit if the coins they no longer own remain unspent
> for a long time, because it increases their anonymity set by making them
> hide among a greater crowd of coins which also don't get spent for a
> long time.
Hmmm.
The attack can only be mounted after protocol completion.
Thus, at that point, makers have made money, and takers have paid.
And taker is now in possession of a coin unlinked with its original coin, which
is what it paid for.
However, if the taker considers the maker fee it has already paid as a sunk
cost, then it would still be rational of them to mount this attack (sunk costs
should be ignored).
>From this point-of-view, it is possible to do so with only a *subsequent*
>potential gain, and still no downside.
For example, suppose the taker has already performed an "honest" CoinSwap.
Then, it is now in possession of a UTXO that is not linked with its income
stream.
It can then perform another CoinSwap, and *then* perform the attack.
This reveals that the UTXO it provided is involved in a CoinSwap due to
publication of the contract transaction, which is not a loss in this case since
the UTXO it put in was not linked to its income stream already, via a previous
non-attacked CoinSwap.
A taker might rationally consider doing riskless costless theft with its
already-delinked coins if it assesses that some maker is not sufficiently
online and with insufficient watchtowers (both operating expenditures!) that it
has some probability of success times amount it has to seed the theft, versus
the fee of that maker plus miner fees.
In response, a maker that is forced to accept a sweeping taker will raise its
fee, so as to disincentivize this attack using already-delinked coins.
Hmmm.
In addition, post-Scriptless-Script, assuming relative-locktime-use is
"normalized" as proposed in
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html
, then the "contract transaction" and its timelock-path-transaction look
exactly the same as ordinary (P2SH-)P2WPKH single-input-single-output
transactions, thus in that case the taker does ***not*** lose any privacy.
This removes whatever protection you can get from contract transaction
blackmail.
--
The above suggests to me that you still want the collateralized contract
transaction from the taker as well.
A sweeping taker can split its funds in half, swapping one half (and using the
remainder for collateral input), then after that swap, using the
already-swapped coins for the collateral input of the remaining unswapped coins.
This leaks information: you are now linking a post-mix coin with a pre-mix
coin, not onchain (if you do not mount an attack, which you probably will not)
but you *do* reveal this information to the maker (one input is from the
funding tx that is pre-mix, the collateral input is from the post-mix coin).
The only protection here is that the maker is unaware of the fact that your
input coin is pre-mix and your collateral input is post-mix, so it can be hard
for a maker to *use* this information.
However, it might be possible to prevent the maker from learning the collateral
input at all.
If my understanding of BIP-143 is correct, inputs are hashed separately
(`hashPrevouts`) from outputs (`hashOutputs`).
Bob can provide the `hashPrevouts` as an opaque hash, while providing a
decommitment of `hashOutputs` to show that the
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello ZmnSCPxj,
On 03/09/2020 10:45, ZmnSCPxj wrote:
> Good morning Chris,
>
>> A big downside is that it really ruins the property of allowing coins to
>> remain unspent indefinitely. That has privacy implications: if a coin
>> remains unspent for longer than 2 weeks (or another short locktime) then
>> for sure the transaction was not a CoinSwap, and so the anonymity set of
>> the CoinSwap system would be far smaller For this reason I'm pretty
>> desperate to solve the vulnerability without losing the coins remaining
>> unspent indefinitely feature.
>
> Ah, right accept no small privacy leaks!
I'd argue its not even a small leak. A huge amount of coins remain
unspent for weeks, months and years, and it would be great to add them
to our CoinSwap anonymity set. And also have them benefit from
CoinSwap's anonymity set even if they didn't use CoinSwap.
> This seems a great solution!
>
> Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be B
> as well.
> This means, the taker has to have *some* collateral input, of at least value
> K, that it cannot swap (because if it tried to swap that amount, it would be
> unable to provide a collateral as well).
>
> How much does C need to know about the B collateralized contract transaction?
> At the minimum, it has to know the output pays out to the correct contract,
> so it seems to me it has to know the entire B collateralized contract
> transaction, meaning it learns another input of B ("collateral(B)") that is
> not otherwise involved in the CoinSwap.
> This is important, again, if B is a taker, as it means an unrelated input of
> B is now learned by C as having the same ownership as B.
Yes, in fact that's why in my example I talk about a CoinSwap between
two makers Bob and Charlie. Makers can be reasonably expected to own
multiple UTXOs, but takers cannot. As you say because collateral
payments breaks the ability of takers to sweep their entire wallet
through CoinSwap.
Happily, I think takers themselves don't need to use collateral
payments. Here's an argument to why:
Riskless theft attempts by the taker who no longer controls the coins
actually isnt riskless or costless: Because it reduces the privacy of
the previously-owned coins. If a taker genuinely wanted good privacy
(Which, after all, they're paying for via miner fees and CoinSwap fees)
then they would benefit if the coins they no longer own remain unspent
for a long time, because it increases their anonymity set by making them
hide among a greater crowd of coins which also don't get spent for a
long time.
Assuming that all peers, especially makers, deploy multiple redundant
watchtowers then we can assume the success rate of such a theft attempt
is very low. Because of the very low payoff, and privacy benefit of
leaving coins unspent, then it can be argued that taker software which
attempts such theft will never get popular.
Of course this privacy argument only applies to takers, and if the
CoinSwap contract is between two makers as part of a multi-transaction
CoinSwap then it doesn't apply. So a maker-to-maker CoinSwap must use
collateral payments.
== Leak of first hop ==
Collateral inputs only applying to maker-maker CoinSwaps adds an
additional information leak, which is that makers can now tell whether
their previous peer was a taker or maker, based on whether they used a
collateral input or not.
This should be okay because the first maker doesn't know the final
destination of the coins. This is similar to Tor, where this information
is already leaked, for example when the user connects to a Tor bridge.
The operator of the Tor bridge knows that everyone connecting to it is
not a Tor relay node but an actual user. The operator of the tor bridge
still has no idea where the user's internet traffic goes. Our situation
is actually better than Tor, because in Tor the final relay always knows
that they are an exit node, while the final maker in a CoinSwap might
not know that.
Also, if the taker does happen to own an extra UTXO, they may choose to
use a collateral input anyway, just to pretend that they're a maker.
Regards
CB
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Chris,
> A big downside is that it really ruins the property of allowing coins to
> remain unspent indefinitely. That has privacy implications: if a coin
> remains unspent for longer than 2 weeks (or another short locktime) then
> for sure the transaction was not a CoinSwap, and so the anonymity set of
> the CoinSwap system would be far smaller For this reason I'm pretty
> desperate to solve the vulnerability without losing the coins remaining
> unspent indefinitely feature.
Ah, right accept no small privacy leaks!
>
> We need to solve the vulnerability you found, which I'll call the
> riskless theft attempt problem. So what do you think of this solution:
>
> == Building block 1: A, B and C having different contract txes ==
>
> In the original proposal each CoinSwap peer has the same contract
> transaction, and either side can broadcast it whenever they like. This
> actually isn't necessary. We can have a contract transaction
> fully-signed but only known to one peer, with a possibly-different
> transaction transaction fully-signed and only known to the other peer.
>
> Obviously for the CoinSwap to work both contract transactions must have
> the same hash-time-locked contract, but they can differ in other ways.
>
> == Building block 2: collateral payments ==
>
> The riskless theft attempt problem happens because the previous owner of
> the coins knows the fully-signed contract transaction and can broadcast
> it at no cost to themselves. So to solve the problem we add a cost.
>
> There is a 2of2 multisig made up of Bob's and Charlie's keys. The
> associated contract transaction known to Bob must now also have one of
> Bob's single-sig inputs. The outputs are such that some of the money
> from Bob's input now ends up in the HTLC output. The result is that
> after the CoinSwap if Bob broadcasts his contract transaction but fails
> to take the money from the HTLC output, then Bob will have lost money.
Just to be clear:
* B is the one who originally funded the HTLC, and owns the timelock.
* C is the one who will accept the HTLC, and owns the hashlock.
> I'm calling this idea collateral payments, by analogy with collateral
> used for loans. A collateral is someone valuable a debtor puts on the
> table, and if they don't repay the loan then they lose the collateral
> (presumably the creditor sells it to repay the loan).
>
> Here is a diagram of the contract transaction known to Bob:
>
> multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
>
> collateral(B) [J btc] (Bob)[J-K btc]
>
>
> where:
> I = CoinSwap amount
> J = Value of Bob's collateral input
> K = Value that Bob loses if he broadcasts his contract tx but doesnt
> get the money
> M~ = miner fee (random variable)
>
> The value K is something that can be set by the protocol, and made high
> enough so that doing a riskless theft attempt is not worth it. Probably
> the value of K will be quite small because the odds of a riskless
> payment attempt succeeding is very small (assuming the makers all use
> multiple redundant watchtowers). Mostly likely K will be smaller than
> M~, so if the collateral is lost to Bob then the miners will the ones to
> gain, rather than Charlie.
This seems a great solution!
Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be B as
well.
This means, the taker has to have *some* collateral input, of at least value K,
that it cannot swap (because if it tried to swap that amount, it would be
unable to provide a collateral as well).
How much does C need to know about the B collateralized contract transaction?
At the minimum, it has to know the output pays out to the correct contract, so
it seems to me it has to know the entire B collateralized contract transaction,
meaning it learns another input of B ("collateral(B)") that is not otherwise
involved in the CoinSwap.
This is important, again, if B is a taker, as it means an unrelated input of B
is now learned by C as having the same ownership as B.
A fresh maker that is given its starting funds in a single UTXO needs to split
up its funds to make at least one collateral input it can use.
Of note is that the B output also serves as a point for CPFPing this
transaction, thus only one version of the B collateralized contract transaction
needs to be made, and the B collateralized contract transaction can be at or
close to the minimum relay feerate and later CPFPed.
In terms of onchain analysis heuristics, it looks like the B output is change,
while the B+C contract output is the send-out, I think, for most cases.
In case of a protocol abort, this heuristic is misled, since both outputs
become owned by B due to the protocol abort.
In case of a protocol completion, this heuristic is accurate, since the B+C
contract output will be claimed by C, but we do not expect this transaction to
be confirmed onchain after protocol completion anyway (it effectively donates K
to C or miners), so this
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello ZmnSCPxj, On 25/08/2020 04:16, ZmnSCPxj wrote: > > Good morning Antoine, > > >> Note, I think this is independent of picking up either relative or absolute >> timelocks as what matters is the block delta between two links. > > I believe it is quite dependent on relative locktimes. > Relative locktimes *require* a contract transaction to kick off the relative > locktime period. > On the other hand, with Scriptless Script (which we know how to do with > 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a > contract transaction. > > With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one > participant holds a completely-signed timelock transaction while the other > participant holds a completely-signed pointlock transaction. > This can be arranged by having one side offer partial signatures for the > transaction of the other, and once completing the signature, not sharing it > with the other until we are ready to actually broadcast the transaction of > our own volition. > There is no transaction that both participants hold in completely-signed form. > > This should remove most of the shenanigans possible, and makes the 30xRBF > safe for any range of fees. > I think. > > Since for each PTLC a participant holds only its "own" transaction, it is > possible for a participant to define its range of fees for the RBF versions > of the transaction it owns, without negotiation with the other participant. > Since the fee involved is deducted from its own transaction, each participant > can define this range of RBFed fees and impose it on the partial signatures > it gets from the other participant. > > -- > > Private key turnover is still useful even in an absolute-timelock world. > > If we need to bump up the block delta between links, it might be impractical > to have the total delta of a multi-hop swap be too long at the taker. > > As a concrete example, suppose A is a taker who wants to route over makers B > and C. > However, B and C require a CLTV delta of 1 week. > > If A wants to route "directly" A->B->C->A, then if something bad happens, it > could be looking at having its funds locked for two weeks. > > To reduce this risk, A can instead first swap A->B->A, then when that > completes, A->C->A. > This limits its funding lockup to 1 week. > > Private key turnover is useful since as soon as the A->B->A swap completes, > it can directly fund the A->C->A swap from the B-side funding transaction of > the A->B->A swap. > > | A->B->A |A->C->A | > : : : > A -:->funding A> B : : > : : : > B -:->funding A -:--> funding A --> C : > : : : > : :C-> funding A --:-> to-cold A --> > : : : > > This increases the number of transactions by 1 per swap beyond the first, > compared to a direct routing A->B->C->A, but this may be worth it for A if > the timelocks involved are too big for A. > > With 2p-ECDSA, a funding A looks exactly the same as a to-cold A, so B is > unable to reliably determine if it is the last hop in the route. > > Without private key turnover, A would have: > > **NO** private key turnover! > > | A->B->A |A->C->A | > : : : > A -:->funding A> B : : > : : : > B -:->funding A -:--> claim A -> funding A --> C : > : : : > : : C-> funding A --:-> to-cold A > --> > : : : > > So if timelock-deltas are possibly-high (to reduce the probability of the > MAD-HTLC argument, and other attacks, succeeding), takers might prefer to > route by completing one swap first before starting the next one, and private > key turnover is useful by reducing blockspace required by each hop. > > For reference, this is how it looks like with a single A->B->C->A swap with > private key turnover: > > | A->B->C->A | > : : > A -:->funding A> B : > : : > B -:->funding B -> C : > : : > C -:->funding A -:-> to-cold A --> > : : > > This is still smaller than in the A->B->A, A->C->A with private key turnover, > by one funding tx per hop. > However, A risks a much higher timelock (twice the timelock). > Thus, A might prefer a lower timelock in exchange for paying for an > additional transaction. > > Regards, > ZmnSCPxj > Separating
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Chris, > It seems having just one contract transaction which includes anchor > outputs in the style already used by Lightning is one way to fix both > these vulnerabilities. > > For the first attack, the other side cannot burn the entire balance > because they only have access to the small amount of satoshi of the > anchor output, and to add miner fees they must add their own inputs. So > they'd burn their own coins to miner fees, not the coins in the contract. Minimum output size is 547 sats, so anchor outputs are that amount at minimum. A P2SH-P2WPKH output costs something like ~130 vbytes to spend, at 1.000 sat/vbyte that is only ~130 sats to spend a 547 sat anchor output, an opportunistic camper could collect from a few swaps it would have done anyway (e.g. as a passive popular maker?) and broadcast the contract txes of those swaps and then spend the anchor outputs together to get a few sats in a not-so-dusty UTXO, getting (547 - 130) sat per input minus the cost of creating a new tiny output. Assuming the camper has already claimed its side of the swap in order to put it in cold, this is basically a tiny but free amount of extra money, and if small CoinJoins in JoinMarket are any indication, the 547 sats minus fee to spend it minus fee to create (amortized among the multiple contract txes) new UTXO might be comparable to the actual maker fee. Since this camping attack is done after the CoinSwap, the maker fidelity bond is a weak protection against this. The maker can keep around contract transactions indefinitely, and if standard wallets assume they can leave the coins in the same UTXO indefinitely, the contract transactions remain valid indefinitely, including up to fidelity bond timeout. When the fidelity bond times out, the maker has to destroy its identity anyway, so it could opportunistically wait for a low-fee period after fidelity-bond timeout (we currently get low fee periods once a week, for example, so the camper can wait for at most a week to do this) to publish all still-valid contract transactions, and spend all the anchor outputs including the fidelity bond at the minimum feerate, getting a slightly larger fidelity bond fund, then CoinSwap it to honest makers to clean it, then make a new fidelity bond. And if one of the takers happens to not be watching for contract tx timeout, it can potentially get free money, again, from the inattention. (I call it a "camper attack" since the attacking CoinSwap participant waits around in a single place (maker fidelity bond) and snipes passing contract transactions to extract value from them when opportunity (low fee rate) is good, like a camper.) To protect against this, we should force contract txes to signal RBF, make contract txes min-relay=feerate (requires CPFP package relay at base layer tho), and during low-fee periods we should collect outputs whose private key have been turned over to us, paying at a feerate slightly higher than 547 sat / 130 vbyte fee rate (at which point it becomes uneconomical for campers to mount their sniping attack as they would lose the anchor output amount to fees anyway). In fact the wallet can do that all the time, and if prevailing fees are above the 547 / 130 rate it will not confirm and the wallet that wants to spend its funds *now* can sign a new RBF tx at higher feerate to replace it. Low fees, who would have thought that would enable an attack vector Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello Antoine, Thanks for the very useful insights. It seems having just one contract transaction which includes anchor outputs in the style already used by Lightning is one way to fix both these vulnerabilities. For the first attack, the other side cannot burn the entire balance because they only have access to the small amount of satoshi of the anchor output, and to add miner fees they must add their own inputs. So they'd burn their own coins to miner fees, not the coins in the contract. For the second attack, the other side cannot do transaction pinning because there is only one contract transaction, and all the protections already developed for use with Lightning apply here as well, such as CPFP carve out. Another possible fix for both vulnerabilities is to separate the timelock and hashlock cases into two separate transactions as described by ZmnSCPxj in a recent email to this list. This comes at the cost of breaking private key handover allowing coins to remain unspent indefinitely. Another possible fix for the second attack, is to encumber the output with a `1 OP_CSV` which stops that output being spent while unconfirmed. This seems to be the simplest way if your aim is to only fix the second attack. These are all the possible fixes I can think of. Regards Chris On 24/08/2020 20:30, Antoine Riard wrote: > Hello Chris, > > I think you might have vulnerability issues with the current design. > > With regards to the fee model for contract transactions, AFAICT timely > confirmation is a fund safety matter for an intermediate hop. Between the > offchain preimage reveal phase and the offchain private key handover phase, > the next hop can broadcast your outgoing contract transactions, thus > forcing you to claim quickly backward as you can't assume previous hop will > honestly cooperate to achieve the private key handover. This means that > your range of pre-signed RBF-transactions must theoretically have for fee > upper bound the maximum of the contested balance, as game-theory side, it's > rational to you to burn your balance instead of letting your counterparty > claim it after timelock expiration, in face of mempool congestion. Where > the issue dwells is that this fee is pre-committed and not cancelled when > the balance change of ownership by the outgoing hop learning the preimage > of the haslock output. Thus the previous hop is free to broadcast the > highest-fee RBF-transactions and burn your balance, as for him, his balance > is now encoded in the output of the contract transactions on the previous > link, for which he knows the preimage. > > Note, I think this is independent of picking up either relative or absolute > timelocks as what matters is the block delta between two links. Of course > you can increase this delta to be week-lengthy and thus decrease the need > for a compelling fee but a) you may force quickly close with contract > transactions if the private key handover doesn't happen soon, you don't > want to be caught by surprise by congestion so you would close far behind > delta period expiration like half of it, and b) you increase the time-value > of makers funds in case of faulty hop, thus logically increasing the maker > fee and making the cost of the system higher in average. I guess a better > solution would be to use dual-anchor outputs has spec'ed out by Lightning, > it lets the party who has a balance at stake unilaterally increase feerate > with a CPFP. The CPFP is obviously a higher blockchain cost but a) it's a > safety mechanism for a worst-case scenario, 99% of the time they won't be > committed, b) you might use this CPFP to aggregate change outputs or other > opportunistically side-usage. > > With regards to the preimage release phase, I think you might have a > pinning scenario. The victim would be an intermediate hop, targeted by a > malicious taker. The preimage isn't revealed offchain to this victim hop. A > low-feerate version of the outgoing contract transaction is broadcast and > not going to confirm, assuming a bit of congestion. As preimage is known, > the malicious taker can directly attach a high-fee, low-feerate child > transaction and thus prevent any replacement of the pinned parent by a > honest broadcast of a high-fee RBF-transaction under BIP 125 rules. At the > same time, the malicious taker broadcasts the contract tx on the previous > link and gets it confirmed. At relative timelock expiration, malicious > taker claims back the funds. When the pinned transaction spending the > outgoing link gets evicted (either by replacing child by a higher feerate > or waiting for mempool expiration after 2 weeks), taker gets it confirmed > this time and claims output through hashlock. Given the relative timelock > blocking the victim, there is not even a race. > > I guess restraining the contract transaction to one and only one version > would overcome this attack. A honest intermediate hop, as soon as seeing a > relative timelock triggered
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Antoine, > Note, I think this is independent of picking up either relative or absolute > timelocks as what matters is the block delta between two links. I believe it is quite dependent on relative locktimes. Relative locktimes *require* a contract transaction to kick off the relative locktime period. On the other hand, with Scriptless Script (which we know how to do with 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a contract transaction. With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one participant holds a completely-signed timelock transaction while the other participant holds a completely-signed pointlock transaction. This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition. There is no transaction that both participants hold in completely-signed form. This should remove most of the shenanigans possible, and makes the 30xRBF safe for any range of fees. I think. Since for each PTLC a participant holds only its "own" transaction, it is possible for a participant to define its range of fees for the RBF versions of the transaction it owns, without negotiation with the other participant. Since the fee involved is deducted from its own transaction, each participant can define this range of RBFed fees and impose it on the partial signatures it gets from the other participant. -- Private key turnover is still useful even in an absolute-timelock world. If we need to bump up the block delta between links, it might be impractical to have the total delta of a multi-hop swap be too long at the taker. As a concrete example, suppose A is a taker who wants to route over makers B and C. However, B and C require a CLTV delta of 1 week. If A wants to route "directly" A->B->C->A, then if something bad happens, it could be looking at having its funds locked for two weeks. To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A. This limits its funding lockup to 1 week. Private key turnover is useful since as soon as the A->B->A swap completes, it can directly fund the A->C->A swap from the B-side funding transaction of the A->B->A swap. | A->B->A |A->C->A | : : : A -:->funding A> B : : : : : B -:->funding A -:--> funding A --> C : : : : : :C-> funding A --:-> to-cold A --> : : : This increases the number of transactions by 1 per swap beyond the first, compared to a direct routing A->B->C->A, but this may be worth it for A if the timelocks involved are too big for A. With 2p-ECDSA, a funding A looks exactly the same as a to-cold A, so B is unable to reliably determine if it is the last hop in the route. Without private key turnover, A would have: **NO** private key turnover! | A->B->A |A->C->A | : : : A -:->funding A> B : : : : : B -:->funding A -:--> claim A -> funding A --> C : : : : : : C-> funding A --:-> to-cold A --> : : : So if timelock-deltas are possibly-high (to reduce the probability of the MAD-HTLC argument, and other attacks, succeeding), takers might prefer to route by completing one swap first before starting the next one, and private key turnover is useful by reducing blockspace required by each hop. For reference, this is how it looks like with a single A->B->C->A swap with private key turnover: | A->B->C->A | : : A -:->funding A> B : : : B -:->funding B -> C : : : C -:->funding A -:-> to-cold A --> : : This is still smaller than in the A->B->A, A->C->A with private key turnover, by one funding tx per hop. However, A risks a much higher timelock (twice the timelock). Thus, A might prefer a lower timelock in exchange for paying for an additional transaction. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello Chris, I think you might have vulnerability issues with the current design. With regards to the fee model for contract transactions, AFAICT timely confirmation is a fund safety matter for an intermediate hop. Between the offchain preimage reveal phase and the offchain private key handover phase, the next hop can broadcast your outgoing contract transactions, thus forcing you to claim quickly backward as you can't assume previous hop will honestly cooperate to achieve the private key handover. This means that your range of pre-signed RBF-transactions must theoretically have for fee upper bound the maximum of the contested balance, as game-theory side, it's rational to you to burn your balance instead of letting your counterparty claim it after timelock expiration, in face of mempool congestion. Where the issue dwells is that this fee is pre-committed and not cancelled when the balance change of ownership by the outgoing hop learning the preimage of the haslock output. Thus the previous hop is free to broadcast the highest-fee RBF-transactions and burn your balance, as for him, his balance is now encoded in the output of the contract transactions on the previous link, for which he knows the preimage. Note, I think this is independent of picking up either relative or absolute timelocks as what matters is the block delta between two links. Of course you can increase this delta to be week-lengthy and thus decrease the need for a compelling fee but a) you may force quickly close with contract transactions if the private key handover doesn't happen soon, you don't want to be caught by surprise by congestion so you would close far behind delta period expiration like half of it, and b) you increase the time-value of makers funds in case of faulty hop, thus logically increasing the maker fee and making the cost of the system higher in average. I guess a better solution would be to use dual-anchor outputs has spec'ed out by Lightning, it lets the party who has a balance at stake unilaterally increase feerate with a CPFP. The CPFP is obviously a higher blockchain cost but a) it's a safety mechanism for a worst-case scenario, 99% of the time they won't be committed, b) you might use this CPFP to aggregate change outputs or other opportunistically side-usage. With regards to the preimage release phase, I think you might have a pinning scenario. The victim would be an intermediate hop, targeted by a malicious taker. The preimage isn't revealed offchain to this victim hop. A low-feerate version of the outgoing contract transaction is broadcast and not going to confirm, assuming a bit of congestion. As preimage is known, the malicious taker can directly attach a high-fee, low-feerate child transaction and thus prevent any replacement of the pinned parent by a honest broadcast of a high-fee RBF-transaction under BIP 125 rules. At the same time, the malicious taker broadcasts the contract tx on the previous link and gets it confirmed. At relative timelock expiration, malicious taker claims back the funds. When the pinned transaction spending the outgoing link gets evicted (either by replacing child by a higher feerate or waiting for mempool expiration after 2 weeks), taker gets it confirmed this time and claims output through hashlock. Given the relative timelock blocking the victim, there is not even a race. I guess restraining the contract transaction to one and only one version would overcome this attack. A honest intermediate hop, as soon as seeing a relative timelock triggered backward would immediately broadcast the outgoing link contract tx or if it's already in network mempools broadcast a higher-feerate child. As you don't have valid multiple contract transactions, an attacker can't obstruct you to propagate the correct child, as you are not blind about the parent txid. Lastly, one downside of using relative timelocks, in case of one downstream link failure, it forces every other upstream hops to go onchain to protect against this kind of pinning scenario. And this would be a privacy breakdown, as a maker would be able to provoke one, thus constraining every upstream hops to go onchain with the same hash and revealing the CoinSwap route. Let me know if I reviewed the correct transactions circuit model or misunderstood associated semantic. I might be completely wrong, coming from a LN perspective. Cheers, Antoine Le mar. 11 août 2020 à 13:06, Chris Belcher via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > I'm currently working on implementing CoinSwap (see my other email > "Design for a CoinSwap implementation for massively improving Bitcoin > privacy and fungibility"). > > CoinSwaps are special because they look just like regular bitcoin > transactions, so they improve the privacy even for people who do not use > them. Once CoinSwap is deployed, anyone attempting surveillance of > bitcoin transactions will be forced to ask themselves the question: how > do we know this transaction
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Chris, > > Absolute timelocks mean that you can set a timer where you put your node to > > sleep without risk of loss of funds (basically, once the absolute timelocks > > have resolved, you can forget about CoinSwaps). > > But I think the ability to spend at any time would be better, and getting > > 100% online 144 blocks a day, 2016 blocks a retargeting period is becoming > > more and more feasible. > > You can always put your node to sleep as a maker, and your watchtowers > will protect you. Assuming you have multiple watchtowers, yes. It would be best if watchtowers for CoinSwap and watchtowers for Lightning could be the same thing, and ideally, a watchtower would not even know if what it was watching were a Lightning channel or a CoinSwap until an attack happens. > > What do you mean by the point about 100% online nodes getting more > feasible? Many bitcoin nodes have been always-on for years, I think I > missed something. Not all locations on Earth make it easy to be 100% online. However, as the technology of you puny humans advance, it becomes more and more possible for a random point on Earth to be 100% online. > > > You're right that attempting such an move by the taker is riskless, but > > > its not costless. The taker sets up the entire CoinSwap protocol because > > > they wanted more privacy; but if the taker broadcasts the Alice contract > > > transaction and waits for the timeout, then all they've achieved is > > > spent miner fees, got their own coin back and draw attention to it with > > > the unusual HTLC script. They've achieved no benefit from what I see, so > > > they won't do this. Any taker or maker who attempts anything like this > > > will be spending miner fees. > > > > They would be spending miner fees from the funds being stolen, thus still > > costless. > > In particular, let us imagine a simple 1-maker swap. > > > > - The taker and the maker complete the swap. > > - The taker now has possession of: > > - The private key for its incoming HTLC. > > - The pre-signed contract transaction for its outgoing HTLC. > > - The taker spends from its incoming HTLC using the private key. > > - The maker ignores this, because this is just normal operation. > > - Fees paid for this is not an additional cost, because a taker that > > wants to put its freshly-private funds into cold storage will do this > > anyway. > > - The taker gets a fresh, private coin from this incoming HTLC, so it > > gets the privacy it paid for. > > - The taker waits for the incoming-HTLC-spend to confirm. > > - The taker broadcasts the pre-signed contract transaction, in the hope > > that the maker is offline. > > - The fees paid for this are from the contract transaction that the > > taker is trying to steal. > > Even if the theft attempt fails, the taker has already gotten its > > private money out, and is thus not risking anything. > > > > - Semantically, the outgoing HTLC is already "owned" by the maker > > (the maker has private key to it). > > - Thus, the taker commits an action that the maker pays fees for! > > - The maker cannot react except to spend via the hashlock branch. > > In particular, because the taker-incoming (maker-outgoing) UTXO is > > already spent, it cannot retaliate by also broadcasting the contract > > transaction of the taker-incoming (maker-outgoing) HTLC. > > > > - The theft succeeds (the timelock passes) because the maker happens to > > be offline for that long. > > - This is "free money" to the taker, who has already gotten what it > > paid for --- private money in cold storage --- from the CoinSwap. > > - Even if the stolen fund reveals the contract, the taker can > > re-acquire privacy for the funds it stole for free, by paying for --- wait > > for it --- another CoinSwap for its swag. > > Yep you're right, I get it. > > The biggest defense against theft will have to be multiple redundant > watchtowers. But as you say the attack is riskless and costless for the > taker to attempt, so they might try anyway even if the probability of > success is very low. > > If this attack becomes widespread then it effectively breaks the > property that maker's coins remain unspent indefinitely. It seems like > that would lead to makers increasing their CoinSwap fees because they > know they'll always have to spend a bit of miner fees afterwards. > > Hopefully the success rate for this attack can be low enough that > taker's human niceness will stop them trying. But for sure this is a > concerning problem. Indeed. We also cannot use succinct atomic swaps because their asymmetry makes them unroutable --- you can only use it for single-maker swaps. This makes it obvious to the maker that you have only a single maker. > > Using an absolute timelock (implemented by a `nLockTime` tx directly off > > the 2-of-2, not `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello, On 21/08/2020 05:20, ZmnSCPxj wrote: > Good morning, > > > >> Right, so if the taker uses only a single maker then they must have more >> than one UTXO. > > Spending one UTXO is fine, it is generating a transaction that has one output > that is problematic. > > What needs to happen is that this single UTXO is spent to two outputs: the > CoinSwap 2-of-2 and the change output. > This is because intermediate makers will have very high likelihood of > generating such a pattern (it is unlikely they have an exact amount that a > taker would require of them), and the occassional maker might have a very > large UTXO that it can use for similar purposes. > > One thing a taker can do would be to multipath its CoinSwap, i.e. it spends > any number of UTXOs and creates two outputs, which are actually two separate > CoinSwap 2-of-2s to different makers. > As each maker is unaware of the other, this should be similar to the case > where the maker is an intermediate hop and is getting its incoming HTLC from > another maker, which is unlikely to have a precise amount and will thus have > a transaction that has two outputs, the 2-of-2 CoinSwap and the change. Agreed. I write about multipath CoinSwap routes in the original design document, under "Combining multi-transaction with routing" === Miner fees === Makers have no incentive to pay any miner fees. They only do transactions which earn them an income and are willing to wait a very long time for that to happen. By contrast takers want to create transactions far more urgently. In JoinMarket we coded a protocol where the maker could contribute to miner fees, but the market price offered of that trended towards zero. So the reality is that takers will pay all the miner fees. Also because makers don't know the taker's time preference they don't know how much they should pay in miner fees. The taker will have to set limits on how large the maker's transactions are, otherwise makers could abuse this by having the taker consolidate maker's UTXOs for free. >>> >>> Why not have the taker pay for the first maker-spent UTXO and have >>> additional maker-spent UTXOs paid for by the maker? >>> i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 >>> BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). >>> Disagreements on feerate can be resolved by having the taker set the >>> feerate, i.e. "the customer is always right". >>> Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it >>> pays for the mining fees for that extra UTXO. >>> The maker can always reject the swap attempt if it has to spend multiple >>> UTXOs and would lose money doing so if the taker demands a too-high feerate. >> >> Having the taker pay for just one UTXO will have an unfortunate side >> effect of resulting in the maker's money being split up into a large >> number of UTXOs, because every CoinSwap they take part in has an >> incentive to increase their UTXO count by one. At the start of >> JoinMarket this was an issue where then a taker wanting to CoinJoin a >> large would come along and the result would be a huge CoinJoin >> transaction with many many small inputs. Perhaps the taker could pay for >> 2-3 UTXOs to counteract this. (Of course the exact number would be >> configurable by the taker user, but defaults usually don't get changed). >> >> I'm still not convinced with having makers contribute to miner fees. In >> JoinMarket we tried to get makers to contribute a little to miner fees >> and simply they never did in any meaningful way. The market has spoken. >> In terms of incentives makers are happy to wait a very long time, if we >> assume they're just HODLers then even if they earn a few thousand >> satoshis that's good. >> == Contract transaction definitions == Contract transactions are those which may spend from the 2-of-2 multisig outputs, they transfer the coins into a contract where the coins can be spent either by waiting for a timeout or providing a hash preimage value. Ideally contract transactions will never be broadcast but their existence keeps all parties honest. M~ is miner fees, which we treat as a random variable, and ultimately set by whichever pre-signed RBF tx get mined. When we talk about the contract tx, we actually mean perhaps 20-30 transactions which only differ by the miner fee and have RBF enabled, so they can be broadcasted in sequence to get the contract transaction mined regardless of the demand for block space. >>> >>> The highest-fee version could have, in addition, CPFP-anchor outputs, like >>> those being proposed in Lightning, so even if onchain fees rise above the >>> largest fee reservation, it is possible to add even more fees. >>> Or not. >>> Hmm. >> >> I think RBF transactions are better because they ultimately use less >> block space than CPFP. >> >> There
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning, > Right, so if the taker uses only a single maker then they must have more > than one UTXO. Spending one UTXO is fine, it is generating a transaction that has one output that is problematic. What needs to happen is that this single UTXO is spent to two outputs: the CoinSwap 2-of-2 and the change output. This is because intermediate makers will have very high likelihood of generating such a pattern (it is unlikely they have an exact amount that a taker would require of them), and the occassional maker might have a very large UTXO that it can use for similar purposes. One thing a taker can do would be to multipath its CoinSwap, i.e. it spends any number of UTXOs and creates two outputs, which are actually two separate CoinSwap 2-of-2s to different makers. As each maker is unaware of the other, this should be similar to the case where the maker is an intermediate hop and is getting its incoming HTLC from another maker, which is unlikely to have a precise amount and will thus have a transaction that has two outputs, the 2-of-2 CoinSwap and the change. > > This leak in the case of a taker spending a single UTXO also happens > when the taker needs to create a branching route. I described this in my > original email "Design for a CoinSwap implementation for massively > improving Bitcoin privacy and fungibility" under the section "Combining > multi-transaction with routing" (the second diagram). > > I think this might be unavoidable. If the taker has just one UTXO they'd > be much better off using multiple makers for this reason. > > > - The makers can try timing the communications lag with the taker. > > The general assumption would be that more makers == more delay in taker > > responses. > > > > Sounds like adding random delays would fix this. The protocol already > involves waiting for a confirmation (average waiting time 10 minutes, at > best) and might involve more confirmations for extra security and > privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause > too many issues. > Also the Tor network can be pretty laggy so that might add enough noise > anyway. Indeed, this seems a bit of a long shot for the surveilling maker. > > > === Miner fees === > > > Makers have no incentive to pay any miner fees. They only do > > > transactions which earn them an income and are willing to wait a very > > > long time for that to happen. By contrast takers want to create > > > transactions far more urgently. In JoinMarket we coded a protocol where > > > the maker could contribute to miner fees, but the market price offered > > > of that trended towards zero. So the reality is that takers will pay all > > > the miner fees. Also because makers don't know the taker's time > > > preference they don't know how much they should pay in miner fees. > > > The taker will have to set limits on how large the maker's transactions > > > are, otherwise makers could abuse this by having the taker consolidate > > > maker's UTXOs for free. > > > > Why not have the taker pay for the first maker-spent UTXO and have > > additional maker-spent UTXOs paid for by the maker? > > i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 > > BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). > > Disagreements on feerate can be resolved by having the taker set the > > feerate, i.e. "the customer is always right". > > Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it > > pays for the mining fees for that extra UTXO. > > The maker can always reject the swap attempt if it has to spend multiple > > UTXOs and would lose money doing so if the taker demands a too-high feerate. > > Having the taker pay for just one UTXO will have an unfortunate side > effect of resulting in the maker's money being split up into a large > number of UTXOs, because every CoinSwap they take part in has an > incentive to increase their UTXO count by one. At the start of > JoinMarket this was an issue where then a taker wanting to CoinJoin a > large would come along and the result would be a huge CoinJoin > transaction with many many small inputs. Perhaps the taker could pay for > 2-3 UTXOs to counteract this. (Of course the exact number would be > configurable by the taker user, but defaults usually don't get changed). > > I'm still not convinced with having makers contribute to miner fees. In > JoinMarket we tried to get makers to contribute a little to miner fees > and simply they never did in any meaningful way. The market has spoken. > In terms of incentives makers are happy to wait a very long time, if we > assume they're just HODLers then even if they earn a few thousand > satoshis that's good. > > > > == Contract transaction definitions == > > > Contract transactions are those which may spend from the 2-of-2 multisig > > > outputs, they transfer the coins into a contract where the coins can be > > > spent either by waiting for a timeout or providing a
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello Nadav and ZmnSCPxj, On 20/08/2020 22:38, ZmnSCPxj wrote: > Good morning Nadav, > >> Hey Chris and all, >> >> Looking good :) I have one major concern though >> >>> q = EC privkey generated by maker >>> Q = q.G = EC pubkey published by maker >>> >>> p = nonce generated by taker >>> P = p.G = nonce point calculated by taker >>> >>> R = Q + P = pubkey used in bitcoin transaction >>> = (q + p).G >> >> If I'm understanding this correctly (which I'm not sure I ame), it seems >> like the plan is to put R on-chain as the key to an output? As stated this >> is completely insecure as Q is known in advance so the taker can always >> choose a nonce p but then claim that their nonce point is p.G - Q so that >> the key that goes on-chain is (p.G - Q + Q) = p.G allowing them to steal the >> funds. > > My reading from this is that nonce `p` has to be given by the taker to the > maker outright. > In original post: > >> Taker sends unsigned transaction which pays to multisig using pubkey Q, >> and also sends nonce p. > > Thus, taker provides a proof-of-knowledge, i.e. the actual `p` scalar itself > (not zero-knowledge, but what the maker needs is proof-of-knowledge, and > could not care less if the proof is zero-knowledge or not). Yes this looks right. In hindsight my text could be clarified by changing the relevant lines to: p = nonce generated by taker, sent to maker P = p.G = nonce point calculated by taker R = Q + P = pubkey used in bitcoin transaction, calculated by taker = (q + p).G = same pubkey, calculated by maker I don't think the key subtraction attack described by Nadav will work here...? > On the other hand, I do not see the point of this tweak if you are going to > use 2p-ECDSA, since my knowledge is that 2p-ECDSA uses the pubkey that is > homomorphic to the product of the private keys. > And that pubkey is already tweaked, by the fresh privkey of the maker (and > the maker is buying privacy and wants security of the swap, so is > incentivized to generate high-entropy temporary privkeys for the actual swap > operation). > > Not using 2p-ECDSA of some kind would remove most of the privacy advantages > of CoinSwap. > You cannot hide among `2 2 OP_CHECKMULTISIG` scripts of Lightning, > because: > > * Lightning channel closes tend to be weeks at least after the funding > outpoint creation, whereas CoinSwap envisions hours or days. > * Lightning mutual channel closes have a very high probability of spending to > two P2WPKH addresses. > > You need to hide among the much larger singlesig anonymity set, which means > using a single signature (created multiparty by both participants), not two > signatures (one from each participant). > > Or is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH160 > OP_EQUAL OP_ELSE OP_CHECKSEQUENCEVERIFY OP_DROP > OP_ENDIF OP_CHECKSIG`? > This provides a slight privacy boost in a case (contract transaction > publication) where most of the privacy is lost anyway. I completely agree that 2of2 multisigs made with OP_CHECKMULTISIG are lacking in terms of privacy, and that 2p-ECDSA is much better. However this whole protocol is quite complicated and I thought it would be a good move to first implement it with OP_CHECKMULTISIG, to get all the other details right (miner fees, coinswap fees, private key handover, contract transactions, tor hidden services, watchtowers, etc etc) and then add 2p-ECDSA later. Of course in that case all this tweaking of public keys would be superseded by the 2p-ECDSA protocol. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hello ZmnSCPxj, Thanks for the review. My comments are inline. On 20/08/2020 12:17, ZmnSCPxj wrote: > Good morning Chris, > > Great to see this! > > Mostly minor comments. > > > >> >> == Direct connections to Alice === >> >> Only Alice, the taker, knows the entire route, Bob and Charlie just know >> their previous and next transactions. Bob and Charlie do not have direct >> connections with each other, only with Alice. >> >> Diagram of Tor connections: >> >> Bob Charlie >> | / >> | / >> | / >> Alice >> >> When Bob and Charlie communicate, they are actually sending and >> receiving messages via Alice who relays them to Charlie or Bob. This >> helps hide whether the previous or next counterparty in a CoinSwap route >> is a maker or taker. >> >> This doesn't have security issues even in the final steps where private >> keys are handed over, because those private keys are always for 2-of-2 >> multisig and so on their own are never enough to steal money. > > This has a massive advantage over CoinJoin. > > In CoinJoin, since all participants sign a single transaction, every > participant knows the total number of participants. > Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, > the maker knows exactly which output belongs to the taker. > Even if all communications were done via the single paying taker, the > maker(s) are shown the final transaction and thus can easily know how many > participants there are (by counting the number of equal-valued outputs). > > With CoinSwap, in principle no maker has to know how many other makers are in > the swap. > > Thus it would still be useful to make a single-maker CoinSwap, as that would > be difficult, for the maker, to diferentiate from a multi-maker CoinSwap. Yes great point. > There are still a few potential leaks though: > > * If paying through a CoinSwap, the cheapest option for the taker would be to > send out a single large UTXO (single-output txes) to the first maker, and > then demand the final payment and any change as two separate swaps from the > final maker. > * Intermediate makers are likely to not have exact amounts, thus is > unlikely to create a single-output tx when forwarding. > * Thus, the first maker could identify the taker. Right, so if the taker uses only a single maker then they must have more than one UTXO. This leak in the case of a taker spending a single UTXO also happens when the taker needs to create a branching route. I described this in my original email "Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility" under the section "Combining multi-transaction with routing" (the second diagram). I think this might be unavoidable. If the taker has just one UTXO they'd be much better off using multiple makers for this reason. > * The makers can try timing the communications lag with the taker. > The general assumption would be that more makers == more delay in taker > responses. Sounds like adding random delays would fix this. The protocol already involves waiting for a confirmation (average waiting time 10 minutes, at best) and might involve more confirmations for extra security and privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause too many issues. Also the Tor network can be pretty laggy so that might add enough noise anyway. >> >> === Miner fees === >> >> Makers have no incentive to pay any miner fees. They only do >> transactions which earn them an income and are willing to wait a very >> long time for that to happen. By contrast takers want to create >> transactions far more urgently. In JoinMarket we coded a protocol where >> the maker could contribute to miner fees, but the market price offered >> of that trended towards zero. So the reality is that takers will pay all >> the miner fees. Also because makers don't know the taker's time >> preference they don't know how much they should pay in miner fees. >> >> The taker will have to set limits on how large the maker's transactions >> are, otherwise makers could abuse this by having the taker consolidate >> maker's UTXOs for free. > > Why not have the taker pay for the *first* maker-spent UTXO and have > additional maker-spent UTXOs paid for by the maker? > i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC", > and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). > > Disagreements on feerate can be resolved by having the taker set the feerate, > i.e. "the customer is always right". > Thus if the maker *has to* spend two UTXOs to make up the 0.4 BTC bag, it > pays for the mining fees for that extra UTXO. > The maker can always reject the swap attempt if it *has to* spend multiple > UTXOs and would lose money doing so if the taker demands a too-high feerate. Having the taker pay for just one UTXO will have an unfortunate side effect of resulting in the maker's money being split up into a large number of UTXOs, because
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Nadav, > Hey Chris and all, > > Looking good :) I have one major concern though > > > q = EC privkey generated by maker > > Q = q.G = EC pubkey published by maker > > > > p = nonce generated by taker > > P = p.G = nonce point calculated by taker > > > > R = Q + P = pubkey used in bitcoin transaction > > = (q + p).G > > If I'm understanding this correctly (which I'm not sure I ame), it seems like > the plan is to put R on-chain as the key to an output? As stated this is > completely insecure as Q is known in advance so the taker can always choose a > nonce p but then claim that their nonce point is p.G - Q so that the key that > goes on-chain is (p.G - Q + Q) = p.G allowing them to steal the funds. My reading from this is that nonce `p` has to be given by the taker to the maker outright. In original post: > Taker sends unsigned transaction which pays to multisig using pubkey Q, > and also sends nonce p. Thus, taker provides a proof-of-knowledge, i.e. the actual `p` scalar itself (not zero-knowledge, but what the maker needs is proof-of-knowledge, and could not care less if the proof is zero-knowledge or not). On the other hand, I do not see the point of this tweak if you are going to use 2p-ECDSA, since my knowledge is that 2p-ECDSA uses the pubkey that is homomorphic to the product of the private keys. And that pubkey is already tweaked, by the fresh privkey of the maker (and the maker is buying privacy and wants security of the swap, so is incentivized to generate high-entropy temporary privkeys for the actual swap operation). Not using 2p-ECDSA of some kind would remove most of the privacy advantages of CoinSwap. You cannot hide among `2 2 OP_CHECKMULTISIG` scripts of Lightning, because: * Lightning channel closes tend to be weeks at least after the funding outpoint creation, whereas CoinSwap envisions hours or days. * Lightning mutual channel closes have a very high probability of spending to two P2WPKH addresses. You need to hide among the much larger singlesig anonymity set, which means using a single signature (created multiparty by both participants), not two signatures (one from each participant). Or is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH160 OP_EQUAL OP_ELSE OP_CHECKSEQUENCEVERIFY OP_DROP OP_ENDIF OP_CHECKSIG`? This provides a slight privacy boost in a case (contract transaction publication) where most of the privacy is lost anyway. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Hey Chris and all, Looking good :) I have one major concern though >q = EC privkey generated by maker >Q = q.G = EC pubkey published by maker > >p = nonce generated by taker >P = p.G = nonce point calculated by taker > >R = Q + P = pubkey used in bitcoin transaction > = (q + p).G If I'm understanding this correctly (which I'm not sure I ame), it seems like the plan is to put R on-chain as the key to an output? As stated this is completely insecure as Q is known in advance so the taker can always choose a nonce p but then claim that their nonce point is p.G - Q so that the key that goes on-chain is (p.G - Q + Q) = p.G allowing them to steal the funds. If the plan is not to use full-fledged 2-ECDSA (which I think is actually necessary as I still don't understand how the HTLC signatures are generated) you have to, at the very least, force the taker to provide a Zero Knowledge Proof of Knowledge (ZKPoK) of the discrete log to the point they advertise as their nonce point to avoid this. Alternatively, I think you can use the following key as is done in MuSig: R = H(Q || P || Q)*Q + H(Q || P || P)*P But I still don't see how signatures can be generated for HTLCs from this key. Of course all of this complexity more or less goes away once we have Schnorr signatures and can use MuSig with adaptor signatures. Best, Nadav On Thu, Aug 20, 2020 at 6:17 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Chris, > > Great to see this! > > Mostly minor comments. > > > > > > > == Direct connections to Alice === > > > > Only Alice, the taker, knows the entire route, Bob and Charlie just know > > their previous and next transactions. Bob and Charlie do not have direct > > connections with each other, only with Alice. > > > > Diagram of Tor connections: > > > > Bob Charlie > > | / > > | / > > | / > > Alice > > > > When Bob and Charlie communicate, they are actually sending and > > receiving messages via Alice who relays them to Charlie or Bob. This > > helps hide whether the previous or next counterparty in a CoinSwap route > > is a maker or taker. > > > > This doesn't have security issues even in the final steps where private > > keys are handed over, because those private keys are always for 2-of-2 > > multisig and so on their own are never enough to steal money. > > This has a massive advantage over CoinJoin. > > In CoinJoin, since all participants sign a single transaction, every > participant knows the total number of participants. > Thus, in CoinJoin, it is fairly useless to have just one taker and one > maker, the maker knows exactly which output belongs to the taker. > Even if all communications were done via the single paying taker, the > maker(s) are shown the final transaction and thus can easily know how many > participants there are (by counting the number of equal-valued outputs). > > With CoinSwap, in principle no maker has to know how many other makers are > in the swap. > > Thus it would still be useful to make a single-maker CoinSwap, as that > would be difficult, for the maker, to diferentiate from a multi-maker > CoinSwap. > > There are still a few potential leaks though: > > * If paying through a CoinSwap, the cheapest option for the taker would be > to send out a single large UTXO (single-output txes) to the first maker, > and then demand the final payment and any change as two separate swaps from > the final maker. > * Intermediate makers are likely to not have exact amounts, thus is > unlikely to create a single-output tx when forwarding. > * Thus, the first maker could identify the taker. > * The makers can try timing the communications lag with the taker. > The general assumption would be that more makers == more delay in taker > responses. > > > > > > > === Miner fees === > > > > Makers have no incentive to pay any miner fees. They only do > > transactions which earn them an income and are willing to wait a very > > long time for that to happen. By contrast takers want to create > > transactions far more urgently. In JoinMarket we coded a protocol where > > the maker could contribute to miner fees, but the market price offered > > of that trended towards zero. So the reality is that takers will pay all > > the miner fees. Also because makers don't know the taker's time > > preference they don't know how much they should pay in miner fees. > > > > The taker will have to set limits on how large the maker's transactions > > are, otherwise makers could abuse this by having the taker consolidate > > maker's UTXOs for free. > > Why not have the taker pay for the *first* maker-spent UTXO and have > additional maker-spent UTXOs paid for by the maker? > i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 > BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). > > Disagreements on feerate can be resolved by having the taker set the > feerate, i.e. "the customer is always right". > Thus if the
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Good morning Chris, Great to see this! Mostly minor comments. > > == Direct connections to Alice === > > Only Alice, the taker, knows the entire route, Bob and Charlie just know > their previous and next transactions. Bob and Charlie do not have direct > connections with each other, only with Alice. > > Diagram of Tor connections: > > Bob Charlie > | / > | / > | / > Alice > > When Bob and Charlie communicate, they are actually sending and > receiving messages via Alice who relays them to Charlie or Bob. This > helps hide whether the previous or next counterparty in a CoinSwap route > is a maker or taker. > > This doesn't have security issues even in the final steps where private > keys are handed over, because those private keys are always for 2-of-2 > multisig and so on their own are never enough to steal money. This has a massive advantage over CoinJoin. In CoinJoin, since all participants sign a single transaction, every participant knows the total number of participants. Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, the maker knows exactly which output belongs to the taker. Even if all communications were done via the single paying taker, the maker(s) are shown the final transaction and thus can easily know how many participants there are (by counting the number of equal-valued outputs). With CoinSwap, in principle no maker has to know how many other makers are in the swap. Thus it would still be useful to make a single-maker CoinSwap, as that would be difficult, for the maker, to diferentiate from a multi-maker CoinSwap. There are still a few potential leaks though: * If paying through a CoinSwap, the cheapest option for the taker would be to send out a single large UTXO (single-output txes) to the first maker, and then demand the final payment and any change as two separate swaps from the final maker. * Intermediate makers are likely to not have exact amounts, thus is unlikely to create a single-output tx when forwarding. * Thus, the first maker could identify the taker. * The makers can try timing the communications lag with the taker. The general assumption would be that more makers == more delay in taker responses. > > === Miner fees === > > Makers have no incentive to pay any miner fees. They only do > transactions which earn them an income and are willing to wait a very > long time for that to happen. By contrast takers want to create > transactions far more urgently. In JoinMarket we coded a protocol where > the maker could contribute to miner fees, but the market price offered > of that trended towards zero. So the reality is that takers will pay all > the miner fees. Also because makers don't know the taker's time > preference they don't know how much they should pay in miner fees. > > The taker will have to set limits on how large the maker's transactions > are, otherwise makers could abuse this by having the taker consolidate > maker's UTXOs for free. Why not have the taker pay for the *first* maker-spent UTXO and have additional maker-spent UTXOs paid for by the maker? i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). Disagreements on feerate can be resolved by having the taker set the feerate, i.e. "the customer is always right". Thus if the maker *has to* spend two UTXOs to make up the 0.4 BTC bag, it pays for the mining fees for that extra UTXO. The maker can always reject the swap attempt if it *has to* spend multiple UTXOs and would lose money doing so if the taker demands a too-high feerate. > == Contract transaction definitions == > > Contract transactions are those which may spend from the 2-of-2 multisig > outputs, they transfer the coins into a contract where the coins can be > spent either by waiting for a timeout or providing a hash preimage > value. Ideally contract transactions will never be broadcast but their > existence keeps all parties honest. > > M~ is miner fees, which we treat as a random variable, and ultimately > set by whichever pre-signed RBF tx get mined. When we talk about the > contract tx, we actually mean perhaps 20-30 transactions which only > differ by the miner fee and have RBF enabled, so they can be broadcasted > in sequence to get the contract transaction mined regardless of the > demand for block space. The highest-fee version could have, in addition, CPFP-anchor outputs, like those being proposed in Lightning, so even if onchain fees rise above the largest fee reservation, it is possible to add even more fees. Or not. Hmm. Another thought: later you describe that miner fees are paid by Alice by forwarding those fees as well, how does that work when there are multiple versions of the contract transaction? > > (Alice+timelock_A OR Bob+hash) = Is an output which can be spent > either with Alice's private key > after waiting for a relative > timelock_A, or by Bob's private key by >
