<p>The use of a 0x01 byte public key is discussed later in <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#cite_note-5" rel="nofollow noreferrer">BIP118</a>:</p>
<blockquote>
<p>Because <code>OP_0</code> 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 <code>OP_1..OP_16</code> or <code>OP_1NEGATE</code> 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.</p>
</blockquote>
<p>BIP342 defined unknown public key types <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#rules-for-signature-opcodes" rel="nofollow noreferrer">here</a>. The public key needs to not be zero to be treated as an undefined public key.</p>
<blockquote>
<p>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.</p>
</blockquote>
<blockquote>
<p>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.</p>
</blockquote>
<p>The Taproot internal key is the untweaked public key (pre Taproot tweaking).</p>
<blockquote>
<p>Is this byte transformed to a public key with some key tweak as in taproot?</p>
</blockquote>
<p>No as the citation says it is used to reference the Taproot internal key. The byte isn't transformed into a public key.</p>

CC BY-SA 4.0
2022-07-28T15:18:52.690Z
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
CC BY-SA 4.0
2022-07-28T15:18:57.830Z
So, the witness script actually check the signature against the internal pubkey contained in the control block?
Lorban
CC BY-SA 4.0
2022-07-28T15:20:30.807Z
Anyway, thank you for your answer, you helped me a lot!
Lorban
CC BY-SA 4.0
2022-07-28T15:37:33.150Z
But this is a different issue, should I open another question on stack exchange?
Lorban
CC BY-SA 4.0
2022-07-28T16:32:20.270Z
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
CC BY-SA 4.0
2022-07-28T16:55:25.463Z
well you are completely right, BIP-118 is still not active. I was trying to understand how is supposed to work and how a transaction with only output signed would look like.
Lorban
CC BY-SA 4.0
2022-07-28T16:56:18.000Z
Sure, post another question
Michael Folkson
CC BY-SA 4.0
2022-07-29T10:04:51.127Z
Hi Michael, posted the question.
https://bitcoin.stackexchange.com/questions/114673/qualitative-anatonomy-of-a-transaction-that-uses-anyprevout
Lorban
CC BY-SA 4.0
2022-07-27T19:29:20.800Z
2022-07-27T19:51:35.030Z
2022-07-27T19:51:35.030Z
Michael Folkson
<p>I am reading specifications of BIP-118 that introduces the new signing mode SIGHASH_ANYPREVOUT.
In <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#public-key" rel="nofollow noreferrer">the bip specifications</a>, 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.</p>
<p>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, &quot;use the 32-byte taproot internal key, p, as defined in BIP 341&quot;. 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.</p>

<taproot><bip118-sighash-anyprevout>
Public keys for BIP-118 SIGHASH_ANYPREVOUT
Lorban
# Public keys for BIP-118 SIGHASH_ANYPREVOUT

(Asked by: username_0 on 2022-07-27)

I am reading specifications of BIP-118 that introduces the new signing mode SIGHASH\_ANYPREVOUT.
In [the bip specifications](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#public-key), 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.

**Tags:** taproot, bip118-sighash-anyprevout


---

## 1 answers

### Answer by username_1 on 2022-07-27. Score: 1 | Accepted answer

The use of a 0x01 byte public key is discussed later in [BIP118](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#cite_note-5):

> 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](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#rules-for-signature-opcodes). 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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: So, the witness script actually check the signature against the internal pubkey contained in the control block?  
> **username_0**: Anyway, thank you for your answer, you helped me a lot!  
> **username_0**: But this is a different issue, should I open another question on stack exchange?  
> **username_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.  
> **username_0**: well you are completely right, BIP-118 is still not active. I was trying to understand how is supposed to work and how a transaction with only output signed would look like.  
> **username_1**: Sure, post another question  
> **username_0**: Hi username_1, posted the question. https://bitcoin.stackexchange.com/questions/114673/qualitative-anatonomy-of-a-transaction-that-uses-anyprevout  

---

