{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-01-07\n📝 Original message:\nLloyd Fournier \u003clloyd.fourn at gmail.com\u003e writes:\n\u003e This achieves all properties except for (4 - distinguishable on-chain)\n\u003e which is why it was dismissed.\n\nIt also seems to require 2 txs per channel open?  (Interestingly I\nmissed that post previously, thanks for the pointer!)\n\n\u003e I think it is possible to extend the idea to achieve (4) and therefore\n\u003e obtain all desired properties.\n\u003e Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups\n\u003e in case of abort. Here's how it could work in my mind:\n\u003e\n\u003e 1. Initiator requests dual-funding and provides a TX_temp spending their\n\u003e input set to a main output and a change output (does not sign it yet). They\n\u003e also provide a sighash SIGNLE|ANYONECANPAY signature on the main output\n\u003e spending into TX_backup-fund and a signature on the first commitment\n\u003e transaction spending from TX_backup-fund (exactly as in [6]).\n\u003e 2. Peer responds with commitment TX signature for TX_backup-fund.\n\u003e 3. Initiator responds with the signatures for TX_temp.\n\u003e *Peer now has a fully functional transaction chain with which to open the\n\u003e channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.\n\u003e 4. Peer (if possible) checks there are no existing transactions in the\n\u003e chain or mempool spending from the taker's inputs. If not it responds with\n\u003e its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.\n\u003e 5. Initiator responds with commitment TX signature and TX_fund input\n\u003e signatures.\n\u003e 6. Peer broadcasts TX_fund.\n\u003e *If at any point after step 3 Initiator does not respond for ~2 seconds\n\u003e they broadcast TX_temp and TX_backup-funding*\n\n2 seconds is not sufficient; as an Australian (or Tor user) you should\nknow this :)\n\nBut otherwise, it's kinda nice (bar breaking the interactive construction).\n\n\u003e We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain\n\u003e in case of abort (i.e. TX_backup-funding makes it on-chain).\n\u003e It appears to be pretty close to the ideal solution in terms of privacy and\n\u003e security.\n\u003e If the malicious initiator learns an output they will always have to spend\n\u003e one of their inputs otherwise they will quickly get hit by the TX_temp +\n\u003e TX_backup-funding.\n\u003e Note that it is possible the node is just slow in which case even if step\n\u003e TX_backup-funding makes it in both parties should just carry on with the\n\u003e channel.\n\u003e\n\u003e The downsides are that it involves six rounds of communication and cannot\n\u003e use the \"interactive tx building\" protocol developed for the original\n\u003e proposal\n\u003e\n\u003e # Signaling Transactions\n\u003e\n\u003e Finally I present a simple but unintuitive protocol that achieves roughly\n\u003e the same properties as the PoDLE protocol but without lightning gossip\n\u003e messages.\n\u003e\n\u003e Whenever the initiator adds an input in the interactive tx building they\n\u003e provide signatures on a \"signaling\" transaction spending that input (and\n\u003e any inputs they have added so far).\n\u003e The signaling transactions will typically spend the funds back to the\n\u003e initiator's wallet.\n\u003e Before revealing any of their inputs, the peer checks that none of the\n\u003e inputs added by the initiator are in their mempool/chain.\n\u003e If the initiator aborts the protocol after learning one of the peer's\n\u003e inputs the peer broadcasts one of the signaling transactions.\n\u003e\n\u003e Like the PoDLE proposal this doesn't achieve (3) since a malicious peer\n\u003e could broadcast the signaling transaction making the honest initiator pay a\n\u003e transaction fee before using the input in another session.\n\u003e To mitigate this a bit, the transactions could be RBF and have a 1\n\u003e sat-per-byte feerate to give the initiator a decent amount of time to use\n\u003e their input productively before the tx confirms (and paying a low fee if it\n\u003e ever does confirm).\n\u003e\n\u003e The advantages of signaling transactions over PoDLE is that it doesn't\n\u003e involve any wonky crypto or new gossip messages.\n\u003e The advantage of the PoDLE proposal over this is that a malicious peer can\n\u003e only blacklist the UTXO (not necessarily force you to spend it).\n\nWe only need a single UTXO for this, which is even better.\n\nSo the initiator sends a \"good faith\" signed tx, which spends one of its\nUTXOs, to the accepter.  1sat-per-byte is probably a too low, but the\naccepter can provide a feerate for it[1].  Opener aborts if that\n\"good-faith\" feerate is too high.  It's implied that this is the first\nadded input, too.\n\nIf the accepter screws the opener by broadcasting it, the opener can\nstill open a channel with someone else before it's confirmed: they just\ncan't use *that* utxo if they want another node to DF.  Or simply take\nthe loss, since the feerate is presumably minimal, and use CPFP.\n\nCheers,\nRusty.\n\n[1] The latest c-lightning implementation of the spec[2] already has the\n    accepter indicating min, max and preferred feerates (and then the\n    opener selects within that range).  This would simply add another\n    feerate field, suggest implementing as ceiling(min / 2, 1).\n[2] Which Lisa promises she'll publish RSN, so we can add your derived\n    points proposal to it."}