Good morning aj, It seems okay to me.
-- Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction could, in theory, have only a single internal taproot pubkey, `P = MuSig(A, B)` for a channel between A and B. So the funding outpoint would be spent with a taprooted P + a single tapscript `<1> OP_CHECKSIG`. Update transactions would be signed with the internal taproot pubkey using `SIGHASH_ANYPREVOUTANYSCRIPT`. The update transaction output would be spendable with a taprooted P + a single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1> OP_CHECKSIG`. Each update transaction would have a monotonically-increasing `nLockTime`, i.e. the above `index`. Then a state transaction would be signed with the internal taproot pubkey using `SIGHASH_ANYPREVOUT`, which commits to the exact script including `<index + 1>`, which is unique for each update transaction. Thus a state transaction can only spend the specific update transaction, but the update transaction can spend the funding outpoint or any update transaction outpoint. State transaction input would have an `nSequence` requiring a relative locktime of the agreed-upon unilateral close delay. The above assumes MuSig signing, which requires 1.5 round trips for a channel, or three broadcast rounds for a multiparticipant (n >= 3) construction. Regards, ZmnSCPxj > Hello world, > > After talking with Christina ages ago, we came to the conclusion that > it made more sense to update BIP 118 to the latest thinking than have > a new BIP number, so I've (finally) opened a (draft) PR to update BIP > 118 with the ANYPREVOUT bip I've passed around to a few people, > > https://github.com/bitcoin/bips/pull/943 > > Probably easiest to just read the new BIP text on github: > > https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki > > It doesn't come with tested code at this point, but I figure better to > have the text available for discussion than nothing. > > Some significant changes since previous discussion include complete lack > of chaperone signatures or anything like it (if you want them, you can > always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no > longer commits to the value (details/rationale in the text). > > Cheers, > aj > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
