2

I am reading specifications of BIP-118 that introduces the new signing mode SIGHASH_ANYPREVOUT. In the bip specifications, it is written that the addresses have length 33-bytes or 1-bytes length. In both cases, the public key starts with 0x01. If it has 33-bytes length, then we remove the 0x01 prefix and use the remaining 32 bytes, presumably as a taproot public key.

What I can't understand is actually how we use the 1-byte public key. In the BIP's specifications, it is said that, in this case, "use the 32-byte taproot internal key, p, as defined in BIP 341". What does it mean? Is this byte transformed to a public key with some key tweak as in taproot? I think that I am missing some logic around. I am a bit new to bitcoin and, usually, BIP proposals are written to be read by people that are already very familiar.

Improve this question

1 Answer 1

Reset to default
1

The use of a 0x01 byte public key is discussed later in BIP118:

Because OP_0 leaves an empty vector on the stack it would not satisfy BIP 342's rules for unknown public key types. As such, it is convenient to use one of OP_1..OP_16 or OP_1NEGATE as a way to reference the taproot internal key. To keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.

BIP342 defined unknown public key types here. The public key needs to not be zero to be treated as an undefined public key.

If the public key size is not zero and not 32 bytes, the public key is of an unknown public key type and no actual signature verification is applied. During script execution of signature opcodes they behave exactly as known public key types except that signature validation is considered to be successful.

Unknown public key types allow adding new signature validation rules through softforks. A softfork could add actual signature validation which either passes or makes the script fail and terminate immediately. This way, new SIGHASH modes can be added, as well as NOINPUT-tagged public keys and a public key constant which is replaced by the taproot internal key for signature validation.

The Taproot internal key is the untweaked public key (pre Taproot tweaking).

Is this byte transformed to a public key with some key tweak as in taproot?

No as the citation says it is used to reference the Taproot internal key. The byte isn't transformed into a public key.

Improve this answer
8
  • I recap a little. So, only to a BIP-118 addresses are allowed to "receive" BTC with anyprevout, through the script path (i.e. number of witness elements >2). The witness script is the second-last element in the witness, and the last is the control block, of which the bytes 1to33 is the untweaked public key. I suppose that this is the public key used to sign some transaction parts (possibly without the script-pubkey of the input, that is presumably the key-step of bip 118) and the signature appears in the witness script.
    – Lorban
    Commented Jul 28, 2022 at 15:18
  • So, the witness script actually check the signature against the internal pubkey contained in the control block?
    – Lorban
    Commented Jul 28, 2022 at 15:18
  • Anyway, thank you for your answer, you helped me a lot!
    – Lorban
    Commented Jul 28, 2022 at 15:20
  • But this is a different issue, should I open another question on stack exchange?
    – Lorban
    Commented Jul 28, 2022 at 15:37
  • 1
    The new signature validation rules would only be checked on a BIP118 public key assuming a soft fork activated BIP118 on the Bitcoin network. Without activating them the new signature validation rules aren't applied and the signature validation is assumed successful. Feel free to open another question, sure.
    – Michael Folkson
    Commented Jul 28, 2022 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.