user120191: 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.

user47827: 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.

120191: <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>
 47827: <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>
