<oembed><type>rich</type><version>1.0</version><title>Rusty Russell [ARCHIVE] wrote</title><author_name>Rusty Russell [ARCHIVE] (npub1zw…hkhpx)</author_name><author_url>https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2021-01-19&#xA;📝 Original message:&#xA;Lloyd Fournier &lt;lloyd.fourn at gmail.com&gt; writes:&#xA;&gt; I think PoDLE might actually have an advantage in parallel attacks if the&#xA;&gt; scheme was changed a bit. A weakness of the lightning proposal as compared&#xA;&gt; to the joinmarket idea is that the `h2` point is not broadcast immediately&#xA;&gt; -- rather you wait for failure and then broadcast it.  Instead, a peer&#xA;&gt; should broadcast h2 as soon as they have agreed to create a transaction&#xA;&gt; with the initiator. Then if at any time during the tx creation protocol&#xA;&gt; they receive the same h2 from someone else, they cancel and don&#39;t reveal&#xA;&gt; their UTXOs (let&#39;s say they wait ~10s after broadcasting before revealing&#xA;&gt; any utxos). Note that here you don&#39;t have to randomly select the time you&#xA;&gt; wait.&#xA;&#xA;Yes, sorry.  I assumed immediate broadcast + 60 second wait for&#xA;conflicts.  It&#39;s this scheme I was trying to shoehorn into the mempool&#xA;(broadcast signalling tx, wait, try to RBF it with a real open).  But&#xA;there are three problems with doing that:&#xA;&#xA;1. Everyone knows what you&#39;re doing, as they see the signalling tx (and&#xA;   it needs to commit to a challenge, such as using OP_RETURN, so you&#xA;   can&#39;t simply reuse the same tx).&#xA;2. Bitcoind doesn&#39;t tell you if it encounters a conflicting tx from a&#xA;   peer, so we&#39;d probably need to gossip this via lightning instead.&#xA;3. If tx fees are low, the signalling tx might get mined.&#xA;&#xA;&gt; There are several (perhaps addressable) downsides to this scheme but it at&#xA;&gt; least has better protection against parallel attacks than the others.&#xA;&gt; Since it is effective it would also break the &#34;middleman&#34; idea unless Alice&#xA;&gt; funds with two utxos (a different h2 for each party) or there is some way&#xA;&gt; for all parties involved in the funding to distinguish gossiped h2s from&#xA;&gt; their funding session from others.&#xA;&#xA;Yes, every initiator needs to provide an h2, and it has to be their own.&#xA;But you don&#39;t care (and can&#39;t know) that there&#39;s an h2 for another&#xA;input, too.  If Alice wants to initialte an open with Carol while Bob is&#xA;initiating an opening with her, she&#39;s got to provide her own UTXO &amp;&#xA;PoDLE.&#xA;&#xA;Another point: the idea was that the accepting node would sign the&#xA;gossip msg, and only known nodes (i.e. ones with a public channel) would&#xA;be allowed to do so.  This gives easy anti-spam: if Alice starts&#xA;spamming a giant pile of h2s, we start randomly dropping them.  That&#xA;doesn&#39;t degrade the protection much: a single UTXO reuse might slip&#xA;through, but a larger number would still be detected with P approaching&#xA;1.&#xA;&#xA;Cheers,&#xA;Rusty.</html></oembed>