{"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-10-11\n📝 Original message:\nHey aj,\n\nThis is awesome work. My line of research on \"witness asymmetric channels\"\nessentially ended up in a dead end because I couldn't see how they were\nmuch better than naive PTLC lightning. The idea I really liked from it was\n\"revocable signatures\". I hoped someone would eventually figure out what to\ndo with them. Looks like you've done that!\n\nI also didn't make the connection to how revocable signatures actually\nsolves the constant size storage problem. I knew it could make the protocol\nin \"generalized payment channels\" [1] only require constant size which was\nthe target of the idea but I hadn't considered that lightning already\nsuffers from this problem so it can be applied more generally.\n\nThe other big breakthrough you made is showing how you can do concurrent\nnon-interactive payment forwarding by using a refined version of Z's fast\nforward idea. In my mind the most practical way to make FF work on\nPoon-Dryja channels was to do it asymmetrically [3] but this meant that if\na payment was sent the other way you'd have to do a 3 phase commit first.\nWith your idea as long as you have balance to spare in your balance output\nyou can always forward a payment in one message. A nice speed boost for\nbusy routing nodes.\n\n### Scorched earth punishment\n\nAnother thing that I'd like to mention is that using revocable signatures\nenables scorched earth punishments [2]. The key you reveal when you post a\nrevoked state does not have to be limited to your channel -- it could be\nused in multiple channels allowing the wronged party to take coins from all\ntheir channels with the perpetrator. Furthermore, a lightning service\nprovider that offers channels with the same channel key to all their\ncustomers is putting up all their coins in all their existing channels as\ntheir good behaviour bond rather than just the coins they have in the\nchannels they have with you.\n\nFor many users this will be sufficient to go without a \"watchtower\" to do\npunishments for them. They know if the LSP takes their coins with a revoked\nstate whenever they come back online they can punish the LSP by revealing\ntheir static channel key to everyone. They can even do this weeks or months\nafter the theft assuming the LSP is still operating with the same key.\n\nSome people feel this idea is too spicy but I prefer it to introducing a\ntrusted third party for people that cannot be online all the time.\n\n[1] https://eprint.iacr.org/2020/476.pdf\n[2]\nhttps://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments\n[3]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003045.html\n\nSome queries below:\n\nOn Sat, 9 Oct 2021 at 12:12, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e\n\u003e We will use \"i\" to represent the number of times a given inflight\n\u003e transaction has been updated for the nth update to the balance\n\u003e transaction.\n\u003e\n\u003e At any time Alice can update the inflight transaction spending her balance\n\u003e to transfer funds towards Bob, either by updating the balances directly,\n\u003e or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And\n\u003e conversely for Bob)\n\u003e\n\u003e We will define RP=musig(A/2/n/i, RB2(n,i)).\n\u003e\n\u003e The inflight transaction spending Alice's balance can have multiple\n\u003e types of outputs:\n\u003e\n\u003e  * Alice's remaining balance: pays directly to A/2/n/i\n\u003e\n\u003e  * Bob's remaining balances: pays to RP/2 with script path\n\u003e    \"\u003cB/2/n/i\u003e CHECKSIGVERIFY \u003cD\u003e CSV\"\n\u003e\n\u003e  * An htlc paying to Bob: pays to RP/2/k with script paths:\n\u003e    + \"LENGTH 32 EQUALVERIFY HASH160 \u003cX\u003e EQUALVERIFY \u003cB/2/n/i/k\u003e\n\u003e CHECKSIGVERIFY \u003cA/2/n/i/k\u003e CHECKSIG\"\n\u003e    + \"\u003cA/2/n/i/k/1\u003e CHECKSIGVERIFY \u003cT\u003e CLTV\"\n\u003e\n\u003e  * A ptlc paying to Bob: pays to RP/2/k with script paths:\n\u003e    + \"\u003cB/2/n/i/k\u003e CHECKSIG NOTIF \u003cT\u003e CLTV DROP ENDIF \u003cA/2/n/i/k\u003e CHECKSIG\"\n\u003e\n\u003e Any outputs that would be zero or dust are not included.\n\u003e\n\u003e Note that we number each currently inflight transaction by \"k\",\n\u003e starting at 0. The same htlc/ptlc may have a different value for k\n\u003e between different inflight transactions.\n\u003e\n\nCan you expand on why \"k\" is needed in addition to \"n\" and \"i\". k sounds\nlike the same thing as i to me.\n\nAlso what does RP/2/k notation imply given the definition of RP you gave\nabove?\n\n\n\u003e  * if the inflight transaction contains a ptlc output, then if Alice\n\u003e    has not retained the old ptlc details (the point and the timeout)\n\u003e    she will not trivially be able to reconstruct the script path,\n\u003e    which includes the timeout. However, presuming the timeout was\n\u003e    within 5000 blocks, then the only possible timeouts are the inflight\n\u003e    tx's nlocktime+i with 0\u003ci\u003c=5000, and she will only need to calculate\n\u003e    5000*k cases and match the corresponding scriptPubKeys to exhaustively\n\u003e    enumerate every possible ptlc output, which should take under a minute,\n\u003e    and be easily achievable. In addition, if Bob attempts to claim the\n\u003e    funds, he will reveal the script path, and Alice will be either able\n\u003e    to claim the inflight output directly or the layered output.\n\u003e\n\nWhat about just doing a scriptless PTLC to avoid this (just CSV input of\npresigned tx)? The cost is pre-sharing more nonces per PTLC message.\n\nThis does not support option_static_remotekey, but compensates for that\n\u003e by allowing balances to be recovered with only the channel setup data\n\u003e even if all revocation data is lost.\n\u003e\n\nThis is rather big drawback but is this really the case? Can't \"in-flight\"\ntransactions send the balance of the remote party to their unencumbered\nstatic remote key? Since there is no \"in-flight\" transaction just after you\ncreate a new balance tx you can just sign a \"good will\" in-flight tx\nwhenever you create a new balance tx that sends all the coins to your\nstatic key. Of course, your counterparty has no incentive to broadcast this\nwhen they close the channel but we can just specify that as part of the\nprotocol you broadcast this anyway (even if it gives you nothing). It's no\nskin off their back.\nOk so what about the fee for the \"good will\" tx? Well let's say it is a\nspecial case and just pays for itself with a reasonable fee. The \"good\nwill\" tx is low time preference and can be CPFP easily if you haven't lost\nyour state. If you have lost your state then this is much better than\nnothing.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/a619e4b8/attachment-0001.html\u003e"}