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, suppos
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 balan
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
