On Wed, Jan 20, 2021 at 12:34 PM Rusty Russell <ru...@rustcorp.com.au>
wrote:
>
>
> 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.
>
I think immediate broadcast of signaling TX is a bad idea even if it's done
over lightning since it leaks that the UTXO associated with the signaling
TX is creating a channel (even if the channel was meant to be private).
You could argue that the signaling TX need not be associated with a UTXO
but I find this awkward.
Lazily broadcast, signaling txs are a good way to protect against
sequential attacks but are weak against parallel attacks. Unfortunately I
think protection of the former means very little without the latter.
>
> > 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.
>
>
Ok since it appears eagerly broadcasted PoDLEs are the only proposal that
can protect against parallel attacks let's try and put the best version of
it forward.
Here's my shot.
Let H0 and H1 be 32-byte output hash functions.
1. In any of the `tx_add_input` messages the initiator may attach a PoDLE
which contains the public key for an input as well as a P2 (the public key
projected onto a different generator).
2. Upon receiving the PoDLE, the peer checks its validity and creates a
"claim" message claiming the UTXO which contains.
i) H0(P2)
ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and
claimer_node_id as the message -- required so conflicting claim messages
can only be produced by someone who actually knows P2.
iii) The claimer_node_id and a BIP340 signature under it over the rest
of the message data -- required to stop spam: only accept and re-broadcast
these messages from nodes who have real channels.
The peer broadcasts this claim message if they haven't before received a
valid claim message with H0(P2) and a valid MAC.
3. Any node receiving the claim message checks whether it has seen it
already (same H0(P2) and MAC). If not, checks the signature against
claimer_node_id and checks whether that node is valid (or perhaps
blacklisted because it has spammed too many claim messages recently),
stores (H0(P2), MAC, claimer_node_id) it and re-broadcasts the message to
its peers.
4. The claiming node waits ~60 seconds to see if it receives a conflicting
claim message where the H0(P2) is the same and the MAC is different and
valid. If they don't receive that then they carry on to add their own utxos.
I believe this does guarantee what we wanted: an attacker will only be able
to do the attack once per UTXO. This is better than I expected to find at
the beginning of entering into this subject!
This certainly seems to be the strongest in the class of solutions.
Now I'd like to make the strongest possible argument against it in favor of
just doing nothing (for now) at the protocol level about this problem.
Consider the following propositions:
1. The public nodes that will offer dual funding and are susceptible to
this attack will be the kind that have a lot of churn i.e. they dual fund a
channel, when that closes they use the remaining funds to fund another
channel.
2. Chainalysis already works very well at identifying the UTXOs these kinds
of nodes. If the change output of a funding or the closing output are
reused in another public channel it is easy to identify which node was
funding what with the techniques in [1,2].
3. It is therefore rather redundant to do this type of active UTXO probing
since all you need to do is wait and be patient. Churning public nodes will
eventually use their UTXO to do a dual or single funding. Then by
cross-layer de-anonymization techniques you will be able to determine that
they owned that UTXO without ever interacting with the node.
4. These techniques can even be applied to private channels at least while
they are identifiable on the blockchain (in [2] using chainalysis they can
identify one node involved in a private channel 79% of the time).
5. There is of course some extra advantage in doing this attack but looking
at the effectiveness of techniques in [1,2] and my intuition about how
churning nodes are most susceptible to these techniques I *guess* it
wouldn't be much. If this is the case then chainalysis companies may not be
able to justify doing active attacks when passive attacks work almost as
well.
6. It may be more effective to deal with UTXO probing outside of the
protocol. For example, a group of dual-funders could maintain a shared UTXO
blacklist and use chainalysis on it to not only ban single UTXOs but entire
clusters of outputs. i.e. do chainalysis on the chainalyzers! There are
some efforts to create open tools to do Chainalysis [3] that could be
leveraged against this attack. This might be much more effective than
PoDLEs as just spending the output somewhere else would not be enough to
use it again in the attack.
7. The above PoDLE proposal actually creates a new extra bit of data that
can be used for chainalysis -- when you broadcast the claim message you are
saying you're going to make a dual funded channel sometime soon. So
Chainalysis can look in the next block for something that looks like a dual
funding and know you participated. This could be quite valuable for them
and I would hesitate to give it to them in the anticipation of them doing
an attack they may never actually do.
8. If all of the above points are not enough to prevent this attack from
being widespread and the above PoDLE proposal is still the best idea I
guess it wouldn't be too hard to shoehorn it into the protocol later.
At the moment my bias is towards doing nothing and keeping things simple.
It seems chainalysis techniques are effective at associating funding UTXOs
to nodes for the most common usage patterns. Taproot will change the game
for private channels but won't do much for public channels.
Having said that -- it was a thing in JoinMarket so I might be wrong. I can
offer some conjecture as to why JoinMarket had this issue: if you can find
all the maker UTXOs before and after a join then you have removed a lot of
the anonymity set. Since CoinJoin is a UTXO privacy technology this makes
sense.
[1] https://arxiv.org/abs/2007.00764
[2] https://arxiv.org/pdf/2003.12470.pdf
[3] https://graphsense.info/
I am told there is a new revision of [1] coming out any day now that will
present a few more tricks and have contributions directly from a scientist
at Chainalsysis (the company).
Cheers,
LL
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
