{"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-04\n📝 Original message:\nHappy New Year Lightning Developers,\n\nI've recently been closely looking at the dual funding proposal [1] because\nit uses a DLEQ proof (PoDLE) which we are also working on specifying as\npart of DLC ECDSA adaptor signatures [2].\nWhile reading it I had some queries and ideas that I thought were worth\nsharing (even though they are very very late).\n\n# Background\n\nLisa posted a draft proposal [1] which includes the PoDLE and explained it\nin [3] along with a good list of its weaknesses.\nThe original discussion thread where the idea was conceived is [4] and\nthere is an excellent summary in the following optech [5] which I post\nbelow:\n\n\u003e Another proposal was to use PoDLE, which was originally developed for\nJoinMarket based on a suggestion by Gregory Maxwell. This protocol allows\nan initiating user such as Mallory to commit to a UTXO in a way that\nprevents anyone from identifying that UTXO. The participating user, such as\nBob, publishes the commitment across the network (e.g. the JoinMarket\nnetwork) so that nobody else will start a session with Mallory while she’s\nusing that particular UTXO. Then Bob asks Mallory to identify her UTXO and,\nif it’s a valid UTXO that matches her commitment, Bob discloses his UTXO to\nMallory so that they can proceed with the protocol (e.g. a coinjoin). If\nMallory aborts the protocol before completion, the commitment previously\npublished across the network prevents her from being able to start a new\nsession with any other user and so learn their UTXO. Mallory’s only option\nis to spend her coins from herself to herself in order to generate a new\nUTXO—a process that costs her money and so limits her ability to spy on\nusers. (Note, though, that PoDLE as implemented in JoinMarket allows\nMallory up to three retries by default so honest users aren’t penalized for\noccasional accidental failures, such as a loss of network connectivity.)\nThe idea is to adapt this protocol for LN in order to prevent attackers\nfrom learning which available UTXOs are controlled by LN users.\n\nEspecially relevant to this post is the idea posted by Darosior here [6]\nwhich was summarized as follows:\n\n\u003e One proposal to fix this would require the person proposing to open the\nchannel (e.g. Mallory) to provide their UTXO(s) in a ready-to-spend state\nso that probing would cost money (e.g. transaction fees). A downside of\nthis approach is that the construction proposed would be easily\nidentifiable by block chain analysis, making it easy to determine when a\ndual-funded channel was opened\n\nThe goals of this post is to (i) see if I understand the PoDLE idea\ncorrectly, to (ii) refine Darosior's idea and to (iii) propose a minimal\nalternative idea.\n\n#  Requirements\n\nInformally, here are the desirable properties I came up with for a dual\nfunding protocol:\n\n1. If a malicious initiator learns a peer UTXO, then the initiator should\nhave to spend their UTXOs before reusing them against the next peer (should\nbe forced to spend them to repeat attack -- *if attacking sequentially*).\n2. A malicious initiator should not be able to use the same UTXOs in\nparallel with multiple peers (to learn the UTXOs of multiple makers with a\nsingle UTXO).\n3. An honest initiator should not have to spend their UTXOs if they execute\nwith a malicious peer.\n4. dual-funded opening transactions should not have any distinguishing\nfeatures (i.e. sighash flags).\n5. An honest but intermittently failing initiator should not have their\nUTXO details sent by an honest peer to other parties.\n\nNote I am going to ignore property (2) because of proposals below can turn\ntheir protection against sequential attacks (1) into protection against\nparallel attacks (2) by having the peer choose a random time delay and see\nif anything is gossiped to them that would indicate malicious behavior by\nthe initiator in some other channel.\n\n# PoDLEs\n\nTo solve this problem in JoinMarket, Waxwing had the idea [8] of turning\nknowledge of a secret key for a particular UTXO into a kind of unlinkable\ncredential.\nGiven a UTXO public key P1, the initiator projects their private key onto a\ndifferent generator J to produce P2.\nP2 is unlinkable to P1 (without a proof) but is fully determined by P1.\nThis allows participants to maintain a blacklist of P2s without learning\nthe P1s.\nHaving the P1s in the blacklist would make the blacklist itself useful for\nchain analysis because it contains a list of UTXOs that tried to open\nchannels (but perhaps accidentally failed).\n\nThe idea is like this:\n1. Taker asks some maker's if they want to do a coinjoin and sends them all\nSHA256(P2)\n2. When they find the maker they want to proceed with they reveal P2 and\nprove DLEQ((P1, G), (P2, J)) i.e. P1 and P2 have the same private key just\ndifferent base points.\n3. If they haven't received SHA256(P2)from the gossip network (i.e. it's\nnot in the blacklist), the maker then sends their own UTXO data AND gossips\nSHA256(P2)\n4. They carry on the protocol.\n\nThe current lightning proposal [1] follows the same logic except that it\nonly gossips SHA256(P2) in case of malicious behavior (this seems sensible).\nIf I understood it correctly, then it achieves properties (1,4,5).\n\nThe main downside is that it introduces a new gossip message. The\ndifficulties associated with this are listed in [3].\nNotably it is missing property (3) - protection against malicious peers who\ngossip SHA256(P2) even when there was no wrongdoing.\n\nA question I have is why is SHA256(P2) sent up front? I think that P2 can\njust be sent along with the proof later on in the case of dual funding.\nWaxwing gave an explanation of it in the case of joinmarket in [7] but I\ndidn't grasp it.\n\n# Darosior's SIGHASH_SINGLE|SIGHASH_ANYONECANPAY\n\nThe proposal from Darosior [6] is to have the taker provide their inputs in\na ready to broadcast state using SIGHASH_SIGNLE|SIGHASH_ANYONECANPAY.\nThis way the peer never needs to send their inputs directly to the\ninitiator (the initiator will only find out about them when the transaction\nis broadcast).\nI encourage the reader to look at [6] which has nice diagrams and is very\nshort and to the point.\nThis achieves all properties except for (4 - distinguishable on-chain)\nwhich is why it was dismissed.\n\nI think it is possible to extend the idea to achieve (4) and therefore\nobtain all desired properties.\nSimply put peers can just use the SINGLE|ANYONECANPAY signature as back ups\nin case of abort. Here's how it could work in my mind:\n\n1. Initiator requests dual-funding and provides a TX_temp spending their\ninput set to a main output and a change output (does not sign it yet). They\nalso provide a sighash SIGNLE|ANYONECANPAY signature on the main output\nspending into TX_backup-fund and a signature on the first commitment\ntransaction spending from TX_backup-fund (exactly as in [6]).\n2. Peer responds with commitment TX signature for TX_backup-fund.\n3. Initiator responds with the signatures for TX_temp.\n*Peer now has a fully functional transaction chain with which to open the\nchannel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.\n4. Peer (if possible) checks there are no existing transactions in the\nchain or mempool spending from the taker's inputs. If not it responds with\nits inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.\n5. Initiator responds with commitment TX signature and TX_fund input\nsignatures.\n6. Peer broadcasts TX_fund.\n*If at any point after step 3 Initiator does not respond for ~2 seconds\nthey broadcast TX_temp and TX_backup-funding*\n\nWe have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain\nin case of abort (i.e. TX_backup-funding makes it on-chain).\nIt appears to be pretty close to the ideal solution in terms of privacy and\nsecurity.\nIf the malicious initiator learns an output they will always have to spend\none of their inputs otherwise they will quickly get hit by the TX_temp +\nTX_backup-funding.\nNote that it is possible the node is just slow in which case even if step\nTX_backup-funding makes it in both parties should just carry on with the\nchannel.\n\nThe downsides are that it involves six rounds of communication and cannot\nuse the \"interactive tx building\" protocol developed for the original\nproposal\n\n# Signaling Transactions\n\nFinally I present a simple but unintuitive protocol that achieves roughly\nthe same properties as the PoDLE protocol but without lightning gossip\nmessages.\n\nWhenever the initiator adds an input in the interactive tx building they\nprovide signatures on a \"signaling\" transaction spending that input (and\nany inputs they have added so far).\nThe signaling transactions will typically spend the funds back to the\ninitiator's wallet.\nBefore revealing any of their inputs, the peer checks that none of the\ninputs added by the initiator are in their mempool/chain.\nIf the initiator aborts the protocol after learning one of the peer's\ninputs the peer broadcasts one of the signaling transactions.\n\nLike the PoDLE proposal this doesn't achieve (3) since a malicious peer\ncould broadcast the signaling transaction making the honest initiator pay a\ntransaction fee before using the input in another session.\nTo mitigate this a bit, the transactions could be RBF and have a 1\nsat-per-byte feerate to give the initiator a decent amount of time to use\ntheir input productively before the tx confirms (and paying a low fee if it\never does confirm).\n\nThe advantages of signaling transactions over PoDLE is that it doesn't\ninvolve any wonky crypto or new gossip messages.\nThe advantage of the PoDLE proposal over this is that a malicious peer can\nonly blacklist the UTXO (not necessarily force you to spend it).\n\n# Summary\n\nThe preference of protocol depends on how you weigh the importance of a\nmalicious non-initiating peer griefing the initiator.\nTo protect fully, the extended version of Darosior's protocol does not\nallow griefing.\nThere is always a lot to be said for ruling out a class of attack even if\nit costs you a few rounds of communication.\n\nIs griefing a real concern though? Layer-2 is full of opportunities to\ngrief your counterparty and the ones presented here are hardly the worst.\nIf you're opening channels with someone who wants to grief you, you are\nalready in trouble.\nPoDLEs have very weak griefing in the form of unfairly adding your UTXO to\nthe blacklist but comes at the cost of complexity and a few difficult to\nanswer questions.\nI think the simplicity of signaling transactions may be worth the extra\ngriefing capabilities it offers a malicious peer given they are hardly as\nbad as the griefing capabilities they will have if you open a channel to\nthem!\n\nCheers,\n\nLL\n\n[1] https://github.com/niftynei/lightning-rfc/pull/1\n\u003chttps://github.com/lightningnetwork/lightning-rfc/pull/524\u003e\n[2] https://github.com/discreetlogcontracts/dlcspecs/pull/114\n[3]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002516.html\n[4]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002466.html\n[5]\nhttps://bitcoinops.org/en/newsletters/2020/02/05/#interactive-construction-of-ln-funding-transactions\n[6]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002475.html\n[7]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002522.html\n[8] https://joinmarket.me/blog/blog/poodle/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210104/08adc787/attachment.html\u003e"}