{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-01-28\n📝 Original message:\nOn Wed, Jan 20, 2021 at 12:34 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e\n\u003e\n\u003e Yes, sorry.  I assumed immediate broadcast + 60 second wait for\n\u003e conflicts.  It's this scheme I was trying to shoehorn into the mempool\n\u003e (broadcast signalling tx, wait, try to RBF it with a real open).  But\n\u003e there are three problems with doing that:\n\u003e\n\u003e 1. Everyone knows what you're doing, as they see the signalling tx (and\n\u003e    it needs to commit to a challenge, such as using OP_RETURN, so you\n\u003e    can't simply reuse the same tx).\n\u003e 2. Bitcoind doesn't tell you if it encounters a conflicting tx from a\n\u003e    peer, so we'd probably need to gossip this via lightning instead.\n\u003e 3. If tx fees are low, the signalling tx might get mined.\n\u003e\n\nI think immediate broadcast of signaling TX is a bad idea even if it's done\nover lightning since it leaks that the UTXO associated with the signaling\nTX is creating a channel (even if the channel was meant to be private).\nYou could argue that the signaling TX need not be associated with a UTXO\nbut I find this awkward.\nLazily broadcast, signaling txs are a good way to protect against\nsequential attacks but are weak against parallel attacks. Unfortunately I\nthink protection of the former means very little without the latter.\n\n\n\u003e\n\u003e \u003e There are several (perhaps addressable) downsides to this scheme but it\n\u003e at\n\u003e \u003e least has better protection against parallel attacks than the others.\n\u003e \u003e Since it is effective it would also break the \"middleman\" idea unless\n\u003e Alice\n\u003e \u003e funds with two utxos (a different h2 for each party) or there is some way\n\u003e \u003e for all parties involved in the funding to distinguish gossiped h2s from\n\u003e \u003e their funding session from others.\n\u003e\n\u003e Yes, every initiator needs to provide an h2, and it has to be their own.\n\u003e But you don't care (and can't know) that there's an h2 for another\n\u003e input, too.  If Alice wants to initialte an open with Carol while Bob is\n\u003e initiating an opening with her, she's got to provide her own UTXO \u0026\n\u003e PoDLE.\n\u003e\n\u003e Another point: the idea was that the accepting node would sign the\n\u003e gossip msg, and only known nodes (i.e. ones with a public channel) would\n\u003e be allowed to do so.  This gives easy anti-spam: if Alice starts\n\u003e spamming a giant pile of h2s, we start randomly dropping them.  That\n\u003e doesn't degrade the protection much: a single UTXO reuse might slip\n\u003e through, but a larger number would still be detected with P approaching\n\u003e 1.\n\u003e\n\u003e\nOk since it appears eagerly broadcasted PoDLEs are the only proposal that\ncan protect against parallel attacks let's try and put the best version of\nit forward.\nHere's my shot.\n\nLet H0 and H1 be 32-byte output hash functions.\n\n1. In any of the `tx_add_input` messages the initiator may attach a PoDLE\nwhich contains the public key for an input as well as a P2 (the public key\nprojected onto a different generator).\n2. Upon receiving the PoDLE, the peer checks its validity and creates a\n\"claim\" message claiming the UTXO which contains.\n    i) H0(P2)\n    ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and\nclaimer_node_id as the message -- required so conflicting claim messages\ncan only be produced by someone who actually knows P2.\n    iii) The claimer_node_id and a BIP340 signature under it over the rest\nof the message data -- required to stop spam: only accept and re-broadcast\nthese messages from nodes who have real channels.\n   The peer broadcasts this claim message if they haven't before received a\nvalid claim message with H0(P2) and a valid MAC.\n3. Any node receiving the claim message checks whether it has seen it\nalready (same H0(P2) and MAC). If not, checks the signature against\nclaimer_node_id and checks whether that node is valid (or perhaps\nblacklisted because it has spammed too many claim messages recently),\nstores (H0(P2), MAC, claimer_node_id) it and re-broadcasts the message to\nits peers.\n4. The claiming node waits ~60 seconds to see if it receives a conflicting\nclaim message where the H0(P2) is the same and the MAC is different and\nvalid. If they don't receive that then they carry on to add their own utxos.\n\nI believe this does guarantee what we wanted: an attacker will only be able\nto do the attack once per UTXO. This is better than I expected to find at\nthe beginning of entering into this subject!\nThis certainly seems to be the strongest in the class of solutions.\n\nNow I'd like to make the strongest possible argument against it in favor of\njust doing nothing (for now) at the protocol level about this problem.\n\nConsider the following propositions:\n1. The public nodes that will offer dual funding and are susceptible to\nthis attack will be the kind that have a lot of churn i.e. they dual fund a\nchannel, when that closes they use the remaining funds to fund another\nchannel.\n2. Chainalysis already works very well at identifying the UTXOs these kinds\nof nodes. If the change output of a funding or the closing output are\nreused in another public channel it is easy to identify which node was\nfunding what with the techniques in [1,2].\n3. It is therefore rather redundant to do this type of active UTXO probing\nsince all you need to do is wait and be patient. Churning public nodes will\neventually use their UTXO to do a dual or single funding. Then by\ncross-layer de-anonymization techniques you will be able to determine that\nthey owned that UTXO without ever interacting with the node.\n4. These techniques can even be applied to private channels at least while\nthey are identifiable on the blockchain (in [2] using chainalysis they can\nidentify one node involved in a private channel 79% of the time).\n5. There is of course some extra advantage in doing this attack but looking\nat the effectiveness of techniques in [1,2] and my intuition about how\nchurning nodes are most susceptible to these techniques I *guess* it\nwouldn't be much. If this is the case then chainalysis companies may not be\nable to justify  doing active attacks when passive attacks work almost as\nwell.\n6. It may be more effective to deal with UTXO probing outside of the\nprotocol. For example, a group of dual-funders could maintain a shared UTXO\nblacklist and use chainalysis on it to not only ban single UTXOs but entire\nclusters of outputs. i.e. do chainalysis on the chainalyzers! There are\nsome efforts to create open tools to do Chainalysis [3] that could be\nleveraged against this attack. This might be much more effective than\nPoDLEs as just spending the output somewhere else would not be enough to\nuse it again in the attack.\n7. The above PoDLE proposal actually creates a new extra bit of data that\ncan be used for chainalysis -- when you broadcast the claim message you are\nsaying you're going to make a dual funded channel sometime soon. So\nChainalysis can look in the next block for something that looks like a dual\nfunding and know you participated. This could be quite valuable for them\nand I would hesitate to give it to them in the anticipation of them doing\nan attack they may never actually do.\n8. If all of the above points are not enough to prevent this attack from\nbeing widespread and the above PoDLE proposal is still the best idea I\nguess it wouldn't be too hard to shoehorn it into the protocol later.\n\nAt the moment my bias is towards doing nothing and keeping things simple.\nIt seems chainalysis techniques are effective at associating funding UTXOs\nto nodes for the most common usage patterns. Taproot will change the game\nfor private channels but won't do much for public channels.\nHaving said that -- it was a thing in JoinMarket so I might be wrong. I can\noffer some conjecture as to why JoinMarket had this issue: if you can find\nall the maker UTXOs before and after a join then you have removed a lot of\nthe anonymity set. Since CoinJoin is a UTXO privacy technology this makes\nsense.\n\n[1] https://arxiv.org/abs/2007.00764\n[2] https://arxiv.org/pdf/2003.12470.pdf\n[3] https://graphsense.info/\n\nI am told there is a new revision of [1] coming out any day now that will\npresent a few more tricks and have contributions directly from a scientist\nat Chainalsysis (the company).\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210128/1f7d828d/attachment.html\u003e"}