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: update motivation, clarify Proof of Funds purpose

Browse Source 
This addresses two discussion items:
 - The list of UTXOs should not be interpreted as a "proof that no other
   UTXOs for an address exist".
 - The BIP only addresses "signer receives funds with the address" and
   not "signer sent a previous transaction" use case.
This commit is contained in:
Oli
2026-04-14 15:31:58 +02:00
parent 665d96065f
commit 0a20483c65
1 changed files with 19 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
bip-0322.mediawiki
View File

@@ -26,15 +26,26 @@ interoperability with existing signing hardware, we also define a signature mess
resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on
any real network).
The Proof of Funds variant allows demonstrating control of a set of UTXOs.
The list of UTXOs may or may not be related to the address being signed with (the
<code>message_challenge</code>).
But in any case, the UTXO list does not aim to prove completeness (e.g. it does NOT mean:
"these are all UTXOs that exist for an address") nor that they are unspent (e.g. a
validator must consult the blockchain to verify that).
Additionally, the current message signature format uses ECDSA signatures which do not commit to the
public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid
signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
Ultimately no message signing protocol can actually prove control of funds, both because a signature
is obsolete as soon as it is created, and because the possessor of a secret key may be willing to
sign messages on others' behalf even if it would not sign actual transactions. No signmessage
sign messages on others' behalf even if it would not sign actual transactions. No message signing
protocol can fix these limitations.
Finally, this BIP only addresses the use case where a signer shows they will be able to control
funds sent to the invoice address. Proving that a signer sent a prior transaction is not possible
using this BIP.
== Types of Signatures ==
This BIP specifies three formats for signing messages: ''legacy'', ''simple'' and ''full''.
@@ -148,7 +159,11 @@ full signature as above, with the following modifications.
</ul>
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 to learn their scriptPubKeys.
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
inputs' witness stack, but not its blockchain state.
An attested list of UTXOs can also never prove that there don't exist more UTXOs for a certain
address.
== Detailed Specification ==
@@ -256,8 +271,8 @@ through the special case as described above.
== Acknowledgements ==
Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others
for their feedback on the specification.
Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, Luke Dashjr,
and many others for their feedback on the specification.
== References ==