[Lightning-dev] DRAFT: interactive tx construction protocol

[ZmnSCPxj]

Hi darosior, niftynei, and list,

waxwing replied the below text, and asked to propagate as well to lightning-dev.
He has just recently re-subscribed to lightning-dev, but may be waiting for the necessary subscription notices or whatnot.

Regards,
ZmnSCPxj

-----------

Re: Venus Flytrap attack and JoinMarket

This issue didn't crop up in our use case because takers always send out to 5-12 (typically) makers at once, and the HP2 only needs to get broadcast by one to stop any reuse.
But whichever way you look at it, it's a very good point! And in LN case, seems like a very substantial attack (at least from what little I've read so far).

In case a brief summary of JM mechanism is helpful, here's the taker-maker conversation:

!fill amount, oid, commitment (HP2)
-- this is where a taker sends to each maker an hp2 value. This is the step intended to enforce scarcity, and the assumption in JM was always that this would basically inevitably get shared. Because there are typically 5-12 makers involved, this seemed a reasonably safe assumption.
If the commitment value is already used and thus not valid, it gets broadcast immediately. If it's not, it only gets shared as part of the !ioauth step below.

!pubkey key

-- this is just the maker giving an ephemeral key for the encryption

!auth (s, e, u, P, P2)
-- (encrypted) this is the taker opening the above commitment. It's rather weird at first sight, because he is opening immediately after committing, with apparently no step inbetween; but in fact the implicit intermediate step is the broadcast (exactly what is being questioned with 'venus flytrap').

!ioauth maker-utxo-data
-- notice the maker is only sending this utxo data (encrypted of course) after proof of ownership of the utxo above.
It's only at this step that the hp2 commitment value is (a) added to the maker's local "used up" list, and (b)privmsged to 1  randomly chosen other bots in the trading pit, who then pubmsgs it to everyone (and that happens multiple times because multiple makers in tx), and they in turn record it as "used".

The mechanism is both not very strong - we use 3 allowed attempts per utxo - and imperfect in its "justice"; such commitments can be "used up" by failures of one's counterparties. But it does serve to stop trivial global snooping, and doesn't cost anything in terms of identity or locked funds, so it has served a purpose (we did actually see such attacks before it, and not after it).

I'd also note that in terms of the venus flytrap attack mentioned, there could be a small time window between one maker receiving !auth and at least one other honest maker getting to broadcast step at !ioauth; while I don't think that's very practical in our use case, it is for sure a theoretical concern and removing it could be either slightly, or extremely, important in another use case.

I'll have a look at this new idea related to node-id and get back to you on that. Thanks for this analysis and investigation, it's a very interesting area.