Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-23 📝 Original message:Anthony Towns <aj at ...
📅 Original date posted:2018-11-23
📝 Original message:Anthony Towns <aj at erisian.com.au> writes:
> Commiting to just the sequence numbers seems really weird to me; it
> only really prevents you from adding inputs, since you could still
> replace any input that was meant to be there by almost any arbitrary
> other transaction...
It's a really roundabout way of committing to the inputs, I
agree. I'm actually wondering if it makes sense to correct that
additional blanked field in BIP118 at all since it seems there is no
real use-case for NOINPUT that doesn't involve blanking the
`hashSequence` as well.
> I could see this *maybe* making sense if you at least committed to the
> values of each input's outpoint; since that would be an actual constraint?
BIP118 still commits to the value of the input being spent, i.e.,
6. value is not being blanked in the current proposal. This is on
purpose since we commit to the outputs, not committing to the input
values could end up with unexpected fees.
>> As for your proposal, I really like the `sighash_scriptmask` proposal,
>> and committing to the fees (with the `nofee` escape hatch) also works
>> seems also a nice fix. My one concern is that introducing a new opcode
>> to mask things in the sighash looks like a similar layering violation as
>> `codeseparator` was, but that's just a minor issue imho.
>
> I think OP_MASK is okay as far as layering goes, if you just think of it
> as a (set of) multibyte "OP_MASKED_PUSH" opcode(s). So when you
> pseudocode a script like:
>
> <n> OP_CSV OP_DROP <p> OP_CHECKSIG
>
> and then decide <n> needs to be masked, you rewrite it as:
>
> [n] OP_CSV OP_DROP <p> OP_CHECKSIG
>
> indicating n is masked, and don't worry about the exact bytes that will
> encode the push, anymore than you currently worry about whether it's
> OP_0, OP_1..16, <1..75>+1..75-bytes, PUSHDATA[1,2,3]+n+n-bytes.
>
> As long as OP_MASK only applies to a PUSH and it's an error for OP_MASK
> not to be immediately followed by that PUSH, I think that all works
> out fine.
Agreed, that makes more sense :-)
📝 Original message:Anthony Towns <aj at erisian.com.au> writes:
> Commiting to just the sequence numbers seems really weird to me; it
> only really prevents you from adding inputs, since you could still
> replace any input that was meant to be there by almost any arbitrary
> other transaction...
It's a really roundabout way of committing to the inputs, I
agree. I'm actually wondering if it makes sense to correct that
additional blanked field in BIP118 at all since it seems there is no
real use-case for NOINPUT that doesn't involve blanking the
`hashSequence` as well.
> I could see this *maybe* making sense if you at least committed to the
> values of each input's outpoint; since that would be an actual constraint?
BIP118 still commits to the value of the input being spent, i.e.,
6. value is not being blanked in the current proposal. This is on
purpose since we commit to the outputs, not committing to the input
values could end up with unexpected fees.
>> As for your proposal, I really like the `sighash_scriptmask` proposal,
>> and committing to the fees (with the `nofee` escape hatch) also works
>> seems also a nice fix. My one concern is that introducing a new opcode
>> to mask things in the sighash looks like a similar layering violation as
>> `codeseparator` was, but that's just a minor issue imho.
>
> I think OP_MASK is okay as far as layering goes, if you just think of it
> as a (set of) multibyte "OP_MASKED_PUSH" opcode(s). So when you
> pseudocode a script like:
>
> <n> OP_CSV OP_DROP <p> OP_CHECKSIG
>
> and then decide <n> needs to be masked, you rewrite it as:
>
> [n] OP_CSV OP_DROP <p> OP_CHECKSIG
>
> indicating n is masked, and don't worry about the exact bytes that will
> encode the push, anymore than you currently worry about whether it's
> OP_0, OP_1..16, <1..75>+1..75-bytes, PUSHDATA[1,2,3]+n+n-bytes.
>
> As long as OP_MASK only applies to a PUSH and it's an error for OP_MASK
> not to be immediately followed by that PUSH, I think that all works
> out fine.
Agreed, that makes more sense :-)