<p>I am entered the world of bitcoin recently and currently I am studying the broad area of covenants (that are gaining more attention from the community, see <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html" rel="nofollow noreferrer">1</a>). In this context, certainly the <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki" rel="nofollow noreferrer">BIP-0118</a> is relevant.</p>
<p>Assume hypothetically that BIP-118 is active, suppose that a payee wants to precompile a transaction <code>tx</code> with ANYPREVOUT. The transaction <code>tx</code> makes no explicit reference to any input to be spent and will be presented later to the payer to be signed. Assume that <code>tx</code> is built to consume an unspent output of the payer and the amount is completely transferred to the payee, without change. So, <code>tx</code> will have one input and one output. I would like to understand how this transaction <code>tx</code> should look like and how this should be used in practice. I discuss below my idea about, hope to find someone that corrects me or improve my understanding. In the following, we assume that the fees are zero.</p>
<p>As I understood, <code>tx</code> produces a P2TR output that is spendable only via the script-path (see taproot BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="nofollow noreferrer">3</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">4</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="nofollow noreferrer">5</a> or <a href="https://arxiv.org/pdf/2102.12796.pdf" rel="nofollow noreferrer">6</a> for a brief anatomy of P2TR outputs or inputs). The receiver address is a new type of address, that has this two possible forms:</p>
<ol>
<li><code>0x01</code> or</li>
<li><code>0x01A</code>
where A is a 32-bytes string. I think that A is a Schnorr tweaked public key, namely the x-axis component of the point <code>Q=P+hash(P||h)⋅P</code>, where P is a Schnorr public key (see <a href="https://bitcoin.stackexchange.com/questions/111098/what-is-the-script-assembly-and-execution-in-p2tr-spend-spend-from-taproot">7</a> for a description on tweaked key) and <code>h</code> is the hash of some script <code>s</code> (in general, <code>h</code> is the Merkle root of some Merkle tree, but I guess that in our case the Merkle tree consists in just one point/leaf, is this correct?). Call <code>x</code> the private key, so <code>xG=P</code>, where <code>G</code> is a generator of the elliptic curve.</li>
</ol>
<p>Suppose for now that we deal with addresses of the form as in 2. So the payee address is version 1 segwit, and the witness program (the output of <code>tx</code>) has more or less the following form:</p>
<pre><code>&lt;h1&gt; &lt;h2&gt; 0x01 &lt;h3&gt;
</code></pre>
<p>where <code>h1</code> (int 64) is the amount in sat, <code>h2</code> (var int) is the length of the following item and <code>h3</code> is a 32-bytes string that represents the x-axis of the tweaked pubkey <code>Q</code>.</p>
<p>For spending the <code>tx</code> output is necessary to present a witness, that, by construction, has (strictly) more than 2 elements, see <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#specification" rel="nofollow noreferrer">8</a>. In particular, the witness has the form:</p>
<pre><code>&lt;n&gt; &lt;d&gt; &lt;s&gt; &lt;c&gt;
</code></pre>
<p>where <code>n</code> is the number of witness elements, <code>d</code> is the data for the following item <code>s</code>, that is the script (such hashed gives the h used to tweak the the pubkey) and <code>c</code> is the control block. The control block is of the form</p>
<pre><code>0xc0 &lt;p&gt; &lt;b&gt;
</code></pre>
<p>where <code>0xc0</code> is the leaf version (didn't really understand it, has something to do with the idea &quot;leave possibility to future upgrades&quot;, like the version byte of segwit?), <code>p</code> is the internal pub key, namely the x-axis of <code>P</code> and <code>b</code> should be a sequence of hashes that are used to reconstruct the merkel tree. So, in our case, <code>b</code>=<code>h</code>?</p>
<p>So far, hasn't appeared yet anything that tells us that the part of the transaction that is signed (by <code>x</code>, the internal private key of the payee?) does not include any reference to a previous input (even though it should include the  input amount, the function that calculates this part of the message signed should be <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message" rel="nofollow noreferrer">SigMsg118(hash_type,ext_flag) </a>). So, I suppose that the script <code>s</code> does the ANYPREVOUT-job in the following way.</p>
<ol>
<li>A signature <code>(R,s)</code> (made by internal private key <code>x</code> that corresponds to <code>p</code>) appears in the part <code>d</code> above. This signature commits to all outputs, to all inputs' amounts but not to any reference to the previous inputs; the <code>hash_type</code> of the signature should be <code>0xc0</code>, that corresponds to <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> (actually, <code>SIGHASH_ANYPREVOUT</code> commits to the inputs' references, as I understood; see <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message" rel="nofollow noreferrer">9</a>).</li>
<li>Now, in the script <code>s</code> should appear a sort of <code>OP_CHECKSIG</code>, that checks the signature <code>(R,s)</code> against the internal pubkey <code>p</code>.</li>
</ol>
<p>Nevertheless, <code>p</code> appears in the control block <code>c</code>, that is after <code>s</code>, and actually the pubkey <code>p</code> is a data for the script and should appear also in <code>d</code>. There is something that I am missing in the logic.</p>
<p>So far, I discussed how to spend the output of the transaction <code>tx</code> that uses <code>ANYPREVOUT</code>. But before this, <code>tx</code> has to be validated and for doing so, it must consume some input. As mentioned in the beginning of the question, once <code>tx</code> is created as above, it is sent to the the payer, that puts the inputs's missing data. So, he adds to <code>tx</code> the following:</p>
<ul>
<li>the inputs' reference, namely a previous transaction hash and the index of the unspent output that it is going to be consumed;</li>
<li>the signature of the input with sighash-type <code>SIGHASH_NONE|ANYONECANPAY</code>. For instance, the unlocking script with a signature <code>SIGHASH_NONE|ANYONECANPAY</code> in the case that the input is P2PKH, or the witness, if the input is segwit, that should contain again some <code>SIGHASH_NONE|ANYONECANPAY</code>-part (actually it can be any king of input, not just P2PKH or P2WPKH)</li>
</ul>
<p>Now, there is one more problem, namely that the payer is supposed to have an unspent output of the exact value of the funds he wants to send to the payee. Suppose that this is not the case and the payer has only unspent outputs of larger amounts. So, a change is needed and the transaction tx will have two outputs as before. The change is an output as before, that requires the machinery of BIP-118 to be spent. So, it is correct to say that the payer signs the transaction only if his wallet is BIP-118-aware?</p>
<p>One last question. In <a href="https://bitcoin.stackexchange.com/questions/114647/public-keys-for-bip-118-sighash-anyprevout">10</a>, Michael Folkson kindly explained me how BIP-118 deals with public keys of the form <code>0x01</code>. But how they are supposed to work in this context? How all the machinery I discussed above works with BIP-118 1-byte public keys?</p>

CC BY-SA 4.0
2022-07-29T10:15:51.330Z
I'll make some edits later but where you say "address" you should be saying "public key". BIP118 defines a new public key type but doesn't make any changes to the address format (bech32m).
Michael Folkson
CC BY-SA 4.0
2022-08-01T11:21:49.697Z
I think you misunderstand sighash flags too. "The transaction tx makes no explicit reference to any input to be spent and will be presented later to the payer to be signed." The signer will choose to use a sighash flag like ANYPREVOUT (or SIGHASH_SINGLE, SIGHASH_ANYONECANPAY etc) at signing time and that will determine what the signer needs to sign. The transaction isn't constructed to be an ANYPREVOUT transaction and then presented to the signer. A transaction always needs inputs to spend but whether the signer signs those specific inputs is the question here.
Michael Folkson
CC BY-SA 4.0
2022-08-01T11:27:12.777Z
The functionality we want for protocols like eltoo is for that signature to be reused in a new transaction with different inputs without requiring a new signature.
Michael Folkson
CC BY-SA 4.0
2022-08-01T16:26:44.697Z
Well actually I misunderstood the logic. The signature is done by the payee. But I still don't understand where in the witness appears this signature. ANYPREVOUT only supports spending a P2TR via the script path, so a P2TR output with an invalid script can't be spent using ANYPREVOUT. This is strange!
Lorban
CC BY-SA 4.0
2022-08-01T16:39:14.187Z
There can only be an ANYPREVOUT signature spending via the script path not the key path, yes. But there can be a non-ANYPREVOUT signature spending via the key path still. So in the unlikely scenario that the script path implementation was botched you could still spend from the key path with a non-ANYPREVOUT signature (assuming that a spendable key path had been encoded into the address)
Michael Folkson
CC BY-SA 4.0
2022-08-01T17:31:49.213Z
ok but, still, suppose that someone, say Alice, is making a transaction tx1 that spends the output of a transaction tx0 made by Bob, that hasn't appeared yet. So, Alice precompiles the transaction tx1 with anyprevout, that can spend the tx0 output only using the script of tx0. But Alice may not be aware of this script, that is made by Bob and so may not be able to precompile tx1... Is this a problem? I mean, this seems to require communication between Alice and Bob...
Lorban
CC BY-SA 4.0
2022-08-01T17:51:11.473Z
Right in protocols like Lightning and eltoo'd Lightning they require communication between Alice and Bob. In your example Alice needs to know the script that Bob encoded into the outputs of tx0 to be able to construct a transaction that spends those outputs.
Michael Folkson
CC BY-SA 4.0
2022-08-01T17:54:38.573Z
ok thank you! this is very helpful!
Lorban
<transactions><bip118-sighash-anyprevout>
Qualitative anatonomy of a transaction that uses ANYPREVOUT
Lorban
# Qualitative anatonomy of a transaction that uses ANYPREVOUT

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

I am entered the world of bitcoin recently and currently I am studying the broad area of covenants (that are gaining more attention from the community, see [1](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html)). In this context, certainly the [BIP-0118](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki) is relevant.

Assume hypothetically that BIP-118 is active, suppose that a payee wants to precompile a transaction `tx` with ANYPREVOUT. The transaction `tx` makes no explicit reference to any input to be spent and will be presented later to the payer to be signed. Assume that `tx` is built to consume an unspent output of the payer and the amount is completely transferred to the payee, without change. So, `tx` will have one input and one output. I would like to understand how this transaction `tx` should look like and how this should be used in practice. I discuss below my idea about, hope to find someone that corrects me or improve my understanding. In the following, we assume that the fees are zero.

As I understood, `tx` produces a P2TR output that is spendable only via the script-path (see taproot BIPs [3](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), [4](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and [5](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) or [6](https://arxiv.org/pdf/2102.12796.pdf) for a brief anatomy of P2TR outputs or inputs). The receiver address is a new type of address, that has this two possible forms:

1. `0x01` or
2. `0x01A`
   where A is a 32-bytes string. I think that A is a Schnorr tweaked public key, namely the x-axis component of the point `Q=P+hash(P||h)⋅P`, where P is a Schnorr public key (see [7](https://bitcoin.stackexchange.com/questions/111098/what-is-the-script-assembly-and-execution-in-p2tr-spend-spend-from-taproot) for a description on tweaked key) and `h` is the hash of some script `s` (in general, `h` is the Merkle root of some Merkle tree, but I guess that in our case the Merkle tree consists in just one point/leaf, is this correct?). Call `x` the private key, so `xG=P`, where `G` is a generator of the elliptic curve.

Suppose for now that we deal with addresses of the form as in 2. So the payee address is version 1 segwit, and the witness program (the output of `tx`) has more or less the following form:

```
<h1> <h2> 0x01 <h3>

```

where `h1` (int 64) is the amount in sat, `h2` (var int) is the length of the following item and `h3` is a 32-bytes string that represents the x-axis of the tweaked pubkey `Q`.

For spending the `tx` output is necessary to present a witness, that, by construction, has (strictly) more than 2 elements, see [8](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#specification). In particular, the witness has the form:

```
<n> <d> <s> <c>

```

where `n` is the number of witness elements, `d` is the data for the following item `s`, that is the script (such hashed gives the h used to tweak the the pubkey) and `c` is the control block. The control block is of the form

```
0xc0 <p> <b>

```

where `0xc0` is the leaf version (didn't really understand it, has something to do with the idea "leave possibility to future upgrades", like the version byte of segwit?), `p` is the internal pub key, namely the x-axis of `P` and `b` should be a sequence of hashes that are used to reconstruct the merkel tree. So, in our case, `b`=`h`?

So far, hasn't appeared yet anything that tells us that the part of the transaction that is signed (by `x`, the internal private key of the payee?) does not include any reference to a previous input (even though it should include the input amount, the function that calculates this part of the message signed should be [SigMsg118(hash\_type,ext\_flag)](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message) ). So, I suppose that the script `s` does the ANYPREVOUT-job in the following way.

1. A signature `(R,s)` (made by internal private key `x` that corresponds to `p`) appears in the part `d` above. This signature commits to all outputs, to all inputs' amounts but not to any reference to the previous inputs; the `hash_type` of the signature should be `0xc0`, that corresponds to `SIGHASH_ANYPREVOUTANYSCRIPT` (actually, `SIGHASH_ANYPREVOUT` commits to the inputs' references, as I understood; see [9](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message)).
2. Now, in the script `s` should appear a sort of `OP_CHECKSIG`, that checks the signature `(R,s)` against the internal pubkey `p`.

Nevertheless, `p` appears in the control block `c`, that is after `s`, and actually the pubkey `p` is a data for the script and should appear also in `d`. There is something that I am missing in the logic.

So far, I discussed how to spend the output of the transaction `tx` that uses `ANYPREVOUT`. But before this, `tx` has to be validated and for doing so, it must consume some input. As mentioned in the beginning of the question, once `tx` is created as above, it is sent to the the payer, that puts the inputs's missing data. So, he adds to `tx` the following:

* the inputs' reference, namely a previous transaction hash and the index of the unspent output that it is going to be consumed;
* the signature of the input with sighash-type `SIGHASH_NONE|ANYONECANPAY`. For instance, the unlocking script with a signature `SIGHASH_NONE|ANYONECANPAY` in the case that the input is P2PKH, or the witness, if the input is segwit, that should contain again some `SIGHASH_NONE|ANYONECANPAY`-part (actually it can be any king of input, not just P2PKH or P2WPKH)

Now, there is one more problem, namely that the payer is supposed to have an unspent output of the exact value of the funds he wants to send to the payee. Suppose that this is not the case and the payer has only unspent outputs of larger amounts. So, a change is needed and the transaction tx will have two outputs as before. The change is an output as before, that requires the machinery of BIP-118 to be spent. So, it is correct to say that the payer signs the transaction only if his wallet is BIP-118-aware?

One last question. In [10](https://bitcoin.stackexchange.com/questions/114647/public-keys-for-bip-118-sighash-anyprevout), username_1 username_1 kindly explained me how BIP-118 deals with public keys of the form `0x01`. But how they are supposed to work in this context? How all the machinery I discussed above works with BIP-118 1-byte public keys?

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

> **Comments:**
> **username_1**: I'll make some edits later but where you say "address" you should be saying "public key". BIP118 defines a new public key type but doesn't make any changes to the address format (bech32m).  
> **username_1**: I think you misunderstand sighash flags too. "The transaction tx makes no explicit reference to any input to be spent and will be presented later to the payer to be signed." The signer will choose to use a sighash flag like ANYPREVOUT (or SIGHASH_SINGLE, SIGHASH_ANYONECANPAY etc) at signing time and that will determine what the signer needs to sign. The transaction isn't constructed to be an ANYPREVOUT transaction and then presented to the signer. A transaction always needs inputs to spend but whether the signer signs those specific inputs is the question here.  
> **username_1**: The functionality we want for protocols like eltoo is for that signature to be reused in a new transaction with different inputs without requiring a new signature.  
> **username_0**: Well actually I misunderstood the logic. The signature is done by the payee. But I still don't understand where in the witness appears this signature. ANYPREVOUT only supports spending a P2TR via the script path, so a P2TR output with an invalid script can't be spent using ANYPREVOUT. This is strange!  
> **username_1**: There can only be an ANYPREVOUT signature spending via the script path not the key path, yes. But there can be a non-ANYPREVOUT signature spending via the key path still. So in the unlikely scenario that the script path implementation was botched you could still spend from the key path with a non-ANYPREVOUT signature (assuming that a spendable key path had been encoded into the address)  
> **username_0**: ok but, still, suppose that someone, say Alice, is making a transaction tx1 that spends the output of a transaction tx0 made by Bob, that hasn't appeared yet. So, Alice precompiles the transaction tx1 with anyprevout, that can spend the tx0 output only using the script of tx0. But Alice may not be aware of this script, that is made by Bob and so may not be able to precompile tx1... Is this a problem? I mean, this seems to require communication between Alice and Bob...  
> **username_1**: Right in protocols like Lightning and eltoo'd Lightning they require communication between Alice and Bob. In your example Alice needs to know the script that Bob encoded into the outputs of tx0 to be able to construct a transaction that spends those outputs.  
> **username_0**: ok thank you! this is very helpful!  

---

## 0 answers

