bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-05-11 16:51:51 +00:00
Code Issues Releases Wiki Activity

BIP-0322: encode finalized PSBT for Proof of Funds

Browse Source 
This commit proposes a fix for the problem that an offline verifier
previously was not able to even verify the witness stack of additional
inputs. By providing the full finalized PSBT, a verifier has all the
input data necessary to run the script through the validation engine.

We require the PSBT to be finalized to make sure it contains the final
script witness or final script sig but no extra potentially
privacy-sensitive fields. The Non-Witness and Witness UTXO fields are
explicitly allowed for finalized PSBTs, which makes the format perfect
for the use case.
This commit is contained in:
Oli
2026-04-14 15:54:44 +02:00
parent 8a46a5bfa5
commit 833a1a8a89
1 changed files with 29 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
bip-0322.mediawiki
View File

@@ -79,9 +79,9 @@ UTXOs.
| <code>all</code>
| full <code>to_sign</code> transaction, consensus and base64-encoded
|-
| Full (PoF)
| Full (Proof of Funds)
| <code>all</code>
| full <code>to_sign</code> transaction, consensus and base64-encoded
| full finalized PSBT of the <code>to_sign</code> transaction, consensus and base64-encoded
|}
<sup>1</sup>: Possible on a technical level but should NOT be used anymore in the context of this
@@ -161,12 +161,29 @@ full signature as above, with the following modifications.
<ul>
<li>
All outputs that the signer wishes to demonstrate control of are included as additional inputs
of <code>to_sign</code>, and their witness and scriptSig data should be set as though these
outputs were actually being spent.
The <code>to_spend</code> transaction is represented as a finalized PSBT instead of a raw
transaction (see [[bip-0174.mediawiki#input-finalizer|BIP-0174]] for details on the finalization
process).
</li>
<li>
All outputs that the signer wishes to demonstrate control of are included as additional inputs of
<code>to_sign</code>, and their witness and scriptSig data should be set as though these outputs
were actually being spent.
</li>
<li>
The Non-Witness or Witness UTXO fields (as appropriate for the type) of each additional input must
be set to the corresponding UTXO.
</li>
<li>
As an optimization for large sets of Non-Witness UTXOs that spend outputs from the same
transaction, the Non-Witness UTXO field may be omitted for any input that spends an output from
the same transaction as an input earlier in the list.
</li>
</ul>
A ''full Proof of Funds'' signature consists of the base64-encoding of the finalized PSBT once it
has been signed.
Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to
learn that the claimed inputs exist on the blockchain and remain unspent.
An offline validator therefore can only attest to the cryptographic validity of the additional
@@ -205,8 +222,10 @@ Validation consists of the following steps:
# Basic validation
## Compute the transaction <code>to_spend</code> from ''m'' and ''A''
## Decode ''s'' as the transaction <code>to_sign</code>
## If ''s'' was a full transaction, confirm all fields are set as specified above; in particular that
## If ''s'' was a full transaction or PSBT, confirm all fields are set as specified above; in particular that
##* <code>to_sign</code> has at least one input and its first input spends the output of </code>to_spend</code>
##* <code>to_sign</code> with more than one input has an appropriate Witness UTXO or Non-Witness UTXO for each input
##** If (based on the input type) a Non-Witness UTXO is required but not provided, check if the first input with the same transaction ID has a Non-Witness UTXO set and use that; fail validation if no such Non-Witness UTXO can be found
##* <code>to_sign</code> has exactly one output, as specified above
## Confirm that the two transactions together satisfy all consensus rules, except for <code>to_spend</code>'s missing input, and except that ''nSequence'' of <code>to_sign</code>'s first input and ''nLockTime'' of <code>to_sign</code> are not checked.
# (Optional) If the validator does not have a full script interpreter, it should check that it understands all scripts being satisfied. If not, it should stop here and output ''inconclusive''.
@@ -257,7 +276,10 @@ They then encode their signature, choosing either ''simple'' or ''full'' as foll
<code>message_signature</code>
</li>
<li>
Otherwise they must base64-encode <code>to_sign</code>.
If they added no inputs to <code>to_sign</code>, they may base64-encode <code>to_sign</code>
</li>
<li>
Otherwise, they must base64-encode the finalized PSBT of <code>to_sign</code>
</li>
</ul>