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.



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 

!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 

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.
Lightning-dev mailing list

Reply via email to