{"type":"rich","version":"1.0","title":"Bastien TEINTURIER [ARCHIVE] wrote","author_name":"Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)","author_url":"https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-12-08\n📝 Original message:\nHi Z,\n\n`SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four\n\u003e years?) or a similar \"covenant\" opcode,\n\nsuch as `OP_CHECKTEMPLATEVERIFY` without any commitments or an\n\u003e `OP_CHECKSIGFROMSTACK` on an empty message.\n\u003e All you really need is a signature for an empty message, really...\n\u003e\n\nThat fails my requirement of \"deployable in 2022\" :)\n\nSame thing applies to fast-forwards: I do see their value, but I'd like to\nfocus on a first version with minimal changes to the transaction structure\nand the update protocol, to ensure we can actually get agreement on it\nsomewhat quickly and ship it in 2022. Then we can start working on a\nmore ambitious rework of the protocol that adds a lot of cool features,\nsuch as what AJ proposed recently.\n\nCheers,\nBastien\n\nLe mer. 8 déc. 2021 à 00:52, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning t-bast,\n\u003e\n\u003e\n\u003e \u003e I believe these new transactions may require an additional round-trip.\n\u003e \u003e Let's take a very simple example, where we have one pending PTLC in each\n\u003e \u003e direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to\n\u003e A.\n\u003e \u003e\n\u003e \u003e Now A makes some unrelated updates and wants to sign a new commitment.\n\u003e \u003e A cannot immediately send her `commitment_signed` to B.\n\u003e \u003e If she did, B would be able to broadcast this new commitment, and A would\n\u003e \u003e not be able to claim PTLC_BA from B's new commitment (even if she knew\n\u003e \u003e the payment secret) because she wouldn't have B's signature for the new\n\u003e \u003e PTLC-remote-success transaction.\n\u003e \u003e\n\u003e \u003e So we first need B to send a new message `remote_ptlcs_signed` to A that\n\u003e \u003e contains B's adaptor signatures for the PTLC-remote-success transactions\n\u003e \u003e that would spend B's future commitment. After that A can safely send her\n\u003e \u003e `commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B\n\u003e \u003e before B can send its `commitment_signed`.\n\u003e \u003e\n\u003e \u003e It's actually not that bad, we're only adding one message in each\n\u003e direction,\n\u003e \u003e and we're not adding more data (apart from nonces) to existing messages.\n\u003e \u003e\n\u003e \u003e If you have ideas on how to avoid this new message, I'd be glad to hear\n\u003e \u003e them, hopefully I missed something again and we can make it better!\n\u003e\n\u003e `SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four\n\u003e years?) or a similar \"covenant\" opcode, such as `OP_CHECKTEMPLATEVERIFY`\n\u003e without any commitments or an `OP_CHECKSIGFROMSTACK` on an empty message.\n\u003e All you really need is a signature for an empty message, really...\n\u003e\n\u003e Alternately, fast-forwards, which avoid this because it does not change\n\u003e commitment transactions on the payment-forwarding path.\n\u003e You only change commitment transactions once you have enough changes to\n\u003e justify collapsing them.\n\u003e Even in the aj formulation, when A adds a PTLC it only changes the\n\u003e transaction that hosts **only** A-\u003eB PTLCs as well as the A main output,\n\u003e all of which can be sent outright by A without changing any B-\u003eA PTLCs.\n\u003e\n\u003e Basically... instead of a commitment tx like this:\n\u003e\n\u003e                         +-------+\n\u003e     funding outpoint --\u003e|       |--\u003e A main\n\u003e                         |       |--\u003e B main\n\u003e                         |       |--\u003e A-\u003eB PTLC\n\u003e                         |       |--\u003e B-\u003eA PTLC\n\u003e                         +-------+\n\u003e\n\u003e We could do this instead:\n\u003e\n\u003e                         +-------+2of2  +-----+\n\u003e     funding outpoint --\u003e|       |-----\u003e|     |--\u003e A main\n\u003e                         |       |      |     |--\u003e A-\u003eB PTLC\n\u003e                         |       |      +-----+\n\u003e                         |       |2or2  +-----+\n\u003e                         |       |-----\u003e|     |--\u003e B main\n\u003e                         |       |      |     |--\u003e B-\u003eA PTLC\n\u003e                         +-------+      +-----+\n\u003e\n\u003e Then whenever A wants to add a new A-\u003eB PTLC it only changes the tx inputs\n\u003e of the *other* A-\u003eB PTLCs without affecting the B-\u003eA PTLCs.\n\u003e Payment forwarding is fast, and you only change the \"big\" commitment tx\n\u003e rarely to clean up claimed and failed PTLCs, moving the extra messages out\n\u003e of the forwarding hot path.\n\u003e\n\u003e But this is basically highly similar to what aj designed anyway, so...\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/531e3f1e/attachment-0001.html\u003e"}