Lloyd Fournier <lloyd.fo...@gmail.com> writes: > 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.
Yes, sorry. I assumed immediate broadcast + 60 second wait for conflicts. It's this scheme I was trying to shoehorn into the mempool (broadcast signalling tx, wait, try to RBF it with a real open). But there are three problems with doing that: 1. Everyone knows what you're doing, as they see the signalling tx (and it needs to commit to a challenge, such as using OP_RETURN, so you can't simply reuse the same tx). 2. Bitcoind doesn't tell you if it encounters a conflicting tx from a peer, so we'd probably need to gossip this via lightning instead. 3. If tx fees are low, the signalling tx might get mined. > 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. Yes, every initiator needs to provide an h2, and it has to be their own. But you don't care (and can't know) that there's an h2 for another input, too. If Alice wants to initialte an open with Carol while Bob is initiating an opening with her, she's got to provide her own UTXO & PoDLE. Another point: the idea was that the accepting node would sign the gossip msg, and only known nodes (i.e. ones with a public channel) would be allowed to do so. This gives easy anti-spam: if Alice starts spamming a giant pile of h2s, we start randomly dropping them. That doesn't degrade the protection much: a single UTXO reuse might slip through, but a larger number would still be detected with P approaching 1. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
