rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2021-01-07 📝 Original message: Lloyd Fournier <lloyd.fourn at gmail.com> writes: > This achieves all properties except for (4 - distinguishable on-chain) > which is why it was dismissed. It also seems to require 2 txs per channel open? (Interestingly I missed that post previously, thanks for the pointer!) > I think it is possible to extend the idea to achieve (4) and therefore > obtain all desired properties. > Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups > in case of abort. Here's how it could work in my mind: > > 1. Initiator requests dual-funding and provides a TX_temp spending their > input set to a main output and a change output (does not sign it yet). They > also provide a sighash SIGNLE|ANYONECANPAY signature on the main output > spending into TX_backup-fund and a signature on the first commitment > transaction spending from TX_backup-fund (exactly as in [6]). > 2. Peer responds with commitment TX signature for TX_backup-fund. > 3. Initiator responds with the signatures for TX_temp. > *Peer now has a fully functional transaction chain with which to open the > channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*. > 4. Peer (if possible) checks there are no existing transactions in the > chain or mempool spending from the taker's inputs. If not it responds with > its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund. > 5. Initiator responds with commitment TX signature and TX_fund input > signatures. > 6. Peer broadcasts TX_fund. > *If at any point after step 3 Initiator does not respond for ~2 seconds > they broadcast TX_temp and TX_backup-funding* 2 seconds is not sufficient; as an Australian (or Tor user) you should know this :) But otherwise, it's kinda nice (bar breaking the interactive construction). > We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain > in case of abort (i.e. TX_backup-funding makes it on-chain). > It appears to be pretty close to the ideal solution in terms of privacy and > security. > If the malicious initiator learns an output they will always have to spend > one of their inputs otherwise they will quickly get hit by the TX_temp + > TX_backup-funding. > Note that it is possible the node is just slow in which case even if step > TX_backup-funding makes it in both parties should just carry on with the > channel. > > The downsides are that it involves six rounds of communication and cannot > use the "interactive tx building" protocol developed for the original > proposal > > # Signaling Transactions > > Finally I present a simple but unintuitive protocol that achieves roughly > the same properties as the PoDLE protocol but without lightning gossip > messages. > > Whenever the initiator adds an input in the interactive tx building they > provide signatures on a "signaling" transaction spending that input (and > any inputs they have added so far). > The signaling transactions will typically spend the funds back to the > initiator's wallet. > Before revealing any of their inputs, the peer checks that none of the > inputs added by the initiator are in their mempool/chain. > If the initiator aborts the protocol after learning one of the peer's > inputs the peer broadcasts one of the signaling transactions. > > Like the PoDLE proposal this doesn't achieve (3) since a malicious peer > could broadcast the signaling transaction making the honest initiator pay a > transaction fee before using the input in another session. > To mitigate this a bit, the transactions could be RBF and have a 1 > sat-per-byte feerate to give the initiator a decent amount of time to use > their input productively before the tx confirms (and paying a low fee if it > ever does confirm). > > The advantages of signaling transactions over PoDLE is that it doesn't > involve any wonky crypto or new gossip messages. > The advantage of the PoDLE proposal over this is that a malicious peer can > only blacklist the UTXO (not necessarily force you to spend it). We only need a single UTXO for this, which is even better. So the initiator sends a "good faith" signed tx, which spends one of its UTXOs, to the accepter. 1sat-per-byte is probably a too low, but the accepter can provide a feerate for it[1]. Opener aborts if that "good-faith" feerate is too high. It's implied that this is the first added input, too. If the accepter screws the opener by broadcasting it, the opener can still open a channel with someone else before it's confirmed: they just can't use *that* utxo if they want another node to DF. Or simply take the loss, since the feerate is presumably minimal, and use CPFP. Cheers, Rusty. [1] The latest c-lightning implementation of the spec[2] already has the accepter indicating min, max and preferred feerates (and then the opener selects within that range). This would simply add another feerate field, suggest implementing as ceiling(min / 2, 1). [2] Which Lisa promises she'll publish RSN, so we can add your derived points proposal to it.