I'm glad the original name (or similar) has been conserved for op_expiry, unlike op_maturity, which ended up being called op_checkLockTimeVerify.
Somehow I had hope that this could be eventually accepted, even though I understood that this changed the "once valid, always valid unless replaced" assumption. Not relevant to bitcoin except perhaps for some colored coin implementations, but for multi-asset chains like those created with elements project (or some chain following freimarkets' design), this also allows other interesting use cases, like making p2p trades easier. For example, signing incomplete transactions as "offers" that others can complete and publish if they like the offer. Anyway, it seems the use cases springing more interest is a lightning one. On Tue, Nov 7, 2023 at 1:13 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Antoine, > > > > Once the HTLC is committed on the Bob-Caroll link, Caroll releases the > preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob > does _not_ send back his signature for the updated channel state. > > > > Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC > output with the preimage. Her commitment transaction propagation in network > mempools is systematically "replaced cycled out" by Bob. > > I think this is impossible? > > In this scenario, there is an HTLC offered by Bob to Carol. > > Prior to block 100, only Carol can actually create an HTLC-success > transaction. > Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock > says "wait till block 100". > > Neither can Bob replace-recycle out the commitment transaction itself, > because the commitment transaction is a single-input transaction, whose > sole input requires a signature from Bob and a signature from Carol --- > obviously Carol will not cooperate on an attack on herself. > > So as long as Carol is able to get the HTLC-success transaction confirmed > before block 100, Bob cannot attack. > Of course, once block 100 is reached, `OP_EXPIRE` will then mean that > Carol cannot claim the fund anymore. > > Regards, > ZmnSCPxj > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev