Johnson Lau [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-21 📝 Original message:> On 21 Dec 2018, at 7:15 ...
📅 Original date posted:2018-12-21
📝 Original message:> On 21 Dec 2018, at 7:15 PM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Johnson Lau <jl2012 at xbt.hk> writes:
>
>> I think the use of OP_CSV (BIP112) is not needed here (although it
>> doesn’t really harm except taking a few more bytes). All you need is
>> to sign the settlement tx with a BIP68 relative locktime. Since this
>> is a 2-of-2 branch, both parties need to agree with the relative
>> locktime, so it is not necessary to restrict it through OP_CSV
>
> I keep forgetting about BIP68, but you're right, that should be
> sufficient for our use-case and would safe us a few bytes.
>
With taproot, this actually saves a lot more than a few bytes. For each update, you will make 3 signatures. One is a SIGHASH_ALL spending the setup TXO with no locktime. One is a NOINPUT spending a previous update TXO with absolute locktime. One is a NOINPUT spending the latest update TXO with relative locktime. For the first and third signatures, you will just sign directly with the scriptPubKey, without revealing the hidden taproot script. The second signature will reveal the taproot script, but it is needed only when someone published an outdated update tx.
📝 Original message:> On 21 Dec 2018, at 7:15 PM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Johnson Lau <jl2012 at xbt.hk> writes:
>
>> I think the use of OP_CSV (BIP112) is not needed here (although it
>> doesn’t really harm except taking a few more bytes). All you need is
>> to sign the settlement tx with a BIP68 relative locktime. Since this
>> is a 2-of-2 branch, both parties need to agree with the relative
>> locktime, so it is not necessary to restrict it through OP_CSV
>
> I keep forgetting about BIP68, but you're right, that should be
> sufficient for our use-case and would safe us a few bytes.
>
With taproot, this actually saves a lot more than a few bytes. For each update, you will make 3 signatures. One is a SIGHASH_ALL spending the setup TXO with no locktime. One is a NOINPUT spending a previous update TXO with absolute locktime. One is a NOINPUT spending the latest update TXO with relative locktime. For the first and third signatures, you will just sign directly with the scriptPubKey, without revealing the hidden taproot script. The second signature will reveal the taproot script, but it is needed only when someone published an outdated update tx.