rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2021-12-07 📝 Original message: Good morning t-bast, > I believe these new transactions may require an additional round-trip. > Let's take a very simple example, where we have one pending PTLC in each > direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A. > > Now A makes some unrelated updates and wants to sign a new commitment. > A cannot immediately send her `commitment_signed` to B. > If she did, B would be able to broadcast this new commitment, and A would > not be able to claim PTLC_BA from B's new commitment (even if she knew > the payment secret) because she wouldn't have B's signature for the new > PTLC-remote-success transaction. > > So we first need B to send a new message `remote_ptlcs_signed` to A that > contains B's adaptor signatures for the PTLC-remote-success transactions > that would spend B's future commitment. After that A can safely send her > `commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B > before B can send its `commitment_signed`. > > It's actually not that bad, we're only adding one message in each direction, > and we're not adding more data (apart from nonces) to existing messages. > > If you have ideas on how to avoid this new message, I'd be glad to hear > them, hopefully I missed something again and we can make it better! `SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four years?) or a similar "covenant" opcode, such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an `OP_CHECKSIGFROMSTACK` on an empty message. All you really need is a signature for an empty message, really... Alternately, fast-forwards, which avoid this because it does not change commitment transactions on the payment-forwarding path. You only change commitment transactions once you have enough changes to justify collapsing them. Even in the aj formulation, when A adds a PTLC it only changes the transaction that hosts **only** A->B PTLCs as well as the A main output, all of which can be sent outright by A without changing any B->A PTLCs. Basically... instead of a commitment tx like this: +-------+ funding outpoint -->| |--> A main | |--> B main | |--> A->B PTLC | |--> B->A PTLC +-------+ We could do this instead: +-------+2of2 +-----+ funding outpoint -->| |----->| |--> A main | | | |--> A->B PTLC | | +-----+ | |2or2 +-----+ | |----->| |--> B main | | | |--> B->A PTLC +-------+ +-----+ Then whenever A wants to add a new A->B PTLC it only changes the tx inputs of the *other* A->B PTLCs without affecting the B->A PTLCs. Payment forwarding is fast, and you only change the "big" commitment tx rarely to clean up claimed and failed PTLCs, moving the extra messages out of the forwarding hot path. But this is basically highly similar to what aj designed anyway, so... Regards, ZmnSCPxj