Lloyd Fournier <lloyd.fo...@gmail.com> writes: > 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.
Agreed. Let's PoDLE! > 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. Note: we can avoid leaking claimer_node_id (Hey, look at me, someone's opening a channel with me now!). The purpose of claimer_node_id is to restrict spam (you need to have broadcasted a valid open channel to be recognized by the network as a valid node_id), but we can make this direct: require a utxo + the script needed to spend it, and any key in that script will serve in place of claimer_node_id (for v1 segwit, the output itself may serve as key). Since we're headed to an anchor (or Eltoo) world where nodes have to keep a few UTXOs around for emergencies anyway, this may have better privacy. At worst, they use a key from an existing, public channel UTXO, which is no worse than using their node_id. > 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]. Less true after taproot though? > 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. I also agree; it's fairly easy to add later with a feature bit, and I think we now have a roadmap on how it should be done. Let's not boil the ocean. > [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). I'll add to my reading list (or wait for one of my colleagues to provide the TL;DR!). Cheers! Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
