rich1.0Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypnjumphttps://yabu.me📅 Original date posted:2021-01-14 📝 Original message: On Wed, Jan 13, 2021 at 11:54 AM Rusty Russell <rusty at rustcorp.com.au> wrote: > Lloyd Fournier <lloyd.fourn at gmail.com> writes: > > Rusty, Zman, > > > > A concern I have with only doing one signaling transaction out of the > whole > > group of inputs is that it means you don't prove ownership of the other > > inputs. > > But that's by design. You can contact two peers and middleman between > them to produce a single tx. > Ah. I missed this motivation. So you actually want to have sessions where you use the same signaling transaction in all of them. That's a cool idea. > > The practical problem with a signalling tx is that it's hard to tell if > it's conflicting. Mallory uses a single UTXO to probe for everyone's > UTXO at once. Poor Bob wants to both wait 60 seconds to see if a > conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal > to others. He wants to do both of these *before* revealing his own > UTXOs. > > I think this is a problem with all three schemes I mentioned. You will always have to wait for things to be gossiped in some way to catch attempts at parallel sessions. Of course there could be faster mediums than the mempool but it does seem a convenient one to use. Note that you should not wait a predictable amount of time but rather a randomly sampled amount from e.g. 0-60 seconds (or longer). If everyone is waiting the same predictable amount of time it does nothing to protect you. But the "middleman" idea you mentioned above makes this all the more complicated: If you are meant to have parallel sessions then this is a problem for an honest Alice who initiates a funding with Bob and Carol. Bob decides to wait 24s and Carol decides to wait 55s to check the mempool for the signaling before revealing their utxos. After Bob wakes up from his 24s he will add his own utxos and demand that Alice complete the transaction by signing it. But since Alice is trying to also add Carol's UTXOs to the transaction she will have to wait until Carol becomes responsive again. To Bob this will look like Alice has become unresponsive through no fault of her own and Bob will broadcast the signaling tx. In other words, if parallel sessions are legal then you shouldn't try and catch parallel sessions. But if parallel sessions are legal there will always be an effective dual funding UTXO discovery attack by using one UTXO to hit many targets. I think this is true for all three schemes I mentioned. It seems the really difficult question is: is it even worth trying to stop sequential attacks if parallel attacks are unstoppable? Not sure how to square this, but I do prefer this approach over PoDLE. > I think PoDLE might actually have an advantage in parallel attacks if the scheme was changed a bit. A weakness of the lightning proposal as compared to the joinmarket idea is that the `h2` point is not broadcast immediately -- rather you wait for failure and then broadcast it. Instead, a peer should broadcast h2 as soon as they have agreed to create a transaction with the initiator. Then if at any time during the tx creation protocol they receive the same h2 from someone else, they cancel and don't reveal their UTXOs (let's say they wait ~10s after broadcasting before revealing any utxos). Note that here you don't have to randomly select the time you wait. There are several (perhaps addressable) downsides to this scheme but it at least has better protection against parallel attacks than the others. Since it is effective it would also break the "middleman" idea unless Alice funds with two utxos (a different h2 for each party) or there is some way for all parties involved in the funding to distinguish gossiped h2s from their funding session from others. Cheers, LL -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210115/db7150a5/attachment.html>