{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-01-14\n📝 Original message:\nOn Wed, Jan 13, 2021 at 11:54 AM Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e writes:\n\u003e \u003e Rusty, Zman,\n\u003e \u003e\n\u003e \u003e A concern I have with only doing one signaling transaction out of the\n\u003e whole\n\u003e \u003e group of inputs is that it means you don't prove ownership of the other\n\u003e \u003e inputs.\n\u003e\n\u003e But that's by design.  You can contact two peers and middleman between\n\u003e them to produce a single tx.\n\u003e\n\nAh. I missed this motivation. So you actually want to have sessions where\nyou use the same signaling transaction in all of them. That's a cool idea.\n\n\u003e\n\u003e The practical problem with a signalling tx is that it's hard to tell if\n\u003e it's conflicting.  Mallory uses a single UTXO to probe for everyone's\n\u003e UTXO at once.  Poor Bob wants to both wait 60 seconds to see if a\n\u003e conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal\n\u003e to others.  He wants to do both of these *before* revealing his own\n\u003e UTXOs.\n\u003e\n\u003e\nI think this is a problem with all three schemes I mentioned. You will\nalways have to wait for things to be gossiped in some way to catch attempts\nat parallel sessions.\nOf course there could be faster mediums than the mempool but it does seem a\nconvenient one to use.\nNote that you should not wait a predictable amount of time but rather a\nrandomly sampled amount from e.g. 0-60 seconds (or longer). If everyone is\nwaiting the same predictable amount of time it does nothing to protect you.\n\nBut the \"middleman\" idea you mentioned above makes this all the more\ncomplicated: If you are meant to have parallel sessions then this is a\nproblem for an honest Alice who initiates a funding with Bob and Carol.\nBob decides to wait 24s and Carol decides to wait 55s to check the mempool\nfor the signaling before revealing their utxos. After Bob wakes up from his\n24s he will add his own utxos and demand that Alice complete the\ntransaction by signing it. But since Alice is trying to also add Carol's\nUTXOs to the transaction she will have to wait until Carol becomes\nresponsive again. To Bob this will look like Alice has become unresponsive\nthrough no fault of her own and Bob will broadcast the signaling tx.\n\nIn other words, if parallel sessions are legal then you shouldn't try and\ncatch parallel sessions. But if parallel sessions are legal there will\nalways be an effective dual funding UTXO discovery attack by using one UTXO\nto hit many targets. I think this is true for all three schemes I mentioned.\n\nIt seems the really difficult question is: is it even worth trying to stop\nsequential attacks if parallel attacks are unstoppable?\n\nNot sure how to square this, but I do prefer this approach over PoDLE.\n\u003e\n\nI think PoDLE might actually have an advantage in parallel attacks if the\nscheme was changed a bit. A weakness of the lightning proposal as compared\nto the joinmarket idea is that the `h2` point is not broadcast immediately\n-- rather you wait for failure and then broadcast it.  Instead, a peer\nshould broadcast h2 as soon as they have agreed to create a transaction\nwith the initiator. Then if at any time during the tx creation protocol\nthey receive the same h2 from someone else, they cancel and don't reveal\ntheir UTXOs (let's say they wait ~10s after broadcasting before revealing\nany utxos). Note that here you don't have to randomly select the time you\nwait.\n\nThere are several (perhaps addressable) downsides to this scheme but it at\nleast has better protection against parallel attacks than the others.\nSince it is effective it would also break the \"middleman\" idea unless Alice\nfunds with two utxos (a different h2 for each party) or there is some way\nfor all parties involved in the funding to distinguish gossiped h2s from\ntheir funding session from others.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210115/db7150a5/attachment.html\u003e"}