Feature or Enhancement?
- (x) New feature
- ( ) Enhancement of existing feature
Description
The compiler currently understands values with type prefixes of x for hexadecimal, d for decimal, and s for string. Many ops use an allowable sigflag ("sighash flag" in Bitcoin terminology) to allow/disallow blanking of sigfields during signature checking. This is a single byte, where every bit represents the index of the field it is allowing (1) or disallowing (0) to be blanked. Signatures that did not commit to every sigfield include an appended sigflag to indicate which fields were blanked. The VM code for checking this looks like the following:
sig_flag1 = sig_flag & 0b00000001
sig_flag2 = sig_flag & 0b00000010
sig_flag3 = sig_flag & 0b00000100
sig_flag4 = sig_flag & 0b00001000
sig_flag5 = sig_flag & 0b00010000
sig_flag6 = sig_flag & 0b00100000
sig_flag7 = sig_flag & 0b01000000
sig_flag8 = sig_flag & 0b10000000
if sig_flag1:
sert(allowable_flags & 0b00000001, 'disallowed sigflag')
...This means that setting the bit at index 3 enables blanking of sigfield4. This would be represented in tapescript source code as d8 or x08, which is not at all intuitive. Even worse, allowing multiple fields to be blanked would result in something even less intuitive, e.g. sigfield3 and sigfield5 together would be d20 or x14.
An intuitive way to indicate which sigfields are allowed to be blanked would be to use a bit string, e.g. check_sig b00010100. This requires only a change to the compiler, but decompiling allowable sigfields for relevant ops to this format would be a nice feature as well.
Additional context
Feature or Enhancement?
Description
The compiler currently understands values with type prefixes of
xfor hexadecimal,dfor decimal, andsfor string. Many ops use an allowable sigflag ("sighash flag" in Bitcoin terminology) to allow/disallow blanking of sigfields during signature checking. This is a single byte, where every bit represents the index of the field it is allowing (1) or disallowing (0) to be blanked. Signatures that did not commit to every sigfield include an appended sigflag to indicate which fields were blanked. The VM code for checking this looks like the following:This means that setting the bit at index 3 enables blanking of sigfield4. This would be represented in tapescript source code as
d8orx08, which is not at all intuitive. Even worse, allowing multiple fields to be blanked would result in something even less intuitive, e.g. sigfield3 and sigfield5 together would bed20orx14.An intuitive way to indicate which sigfields are allowed to be blanked would be to use a bit string, e.g.
check_sig b00010100. This requires only a change to the compiler, but decompiling allowable sigfields for relevant ops to this format would be a nice feature as well.Additional context