Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-01-14 📝 Original message: On Wed, Jan 13, 2021 at ...

📅 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>;