This BIP describes a simple way to construct proof-of-reserves transactions.
This proposal formalizes a standard format for constructing such proofs, easing
their construction with existing wallet infrastructure and enabling general
proof-verification software. It relies on existing standards such as regular
Bitcoin transaction serialization/validation and the BIP 174 PSBT format.
The proposal also includes the description of a PSBT extension for a better
user experience.
==Copyright==
This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
==Motivation==
From the very early days in the history of Bitcoin, there have been companies
managing bitcoins for their users. These users give up control over their coins
in return for a certain service. Inevitably, there have been many cases of
companies losing their users' bitcoins without timely disclosing such events to
the public. Proofs of Reserves are a way for companies managing large amounts
of bitcoins to prove ownership over a given amount of funds. The regular proof
of control helps to ensure that no significant loss has occurred.
While the term proof-of-reserves is not new by any means, the procedure is not
very common among high-value custodian companies. One of the reasons for this
is that every company that wants to perform a proof-of-reserves has to construct
its own way to do so. Accordingly, their users have to understand the
construction of the proof in order to be able to verify it. This raises the bar
of entry both for custodians and for users.
===What this BIP is not doing===
The proof-of-reserve construction described in this document has some known
shortcomings, mostly with regards to its privacy properties. While there exists
research about improved proof-of-reserves mechanisms that have much better
privacy properties<ref>Dagher, Gaby G., Benedikt Bünz, Joseph Bonneau, Jeremy
Clark, and Dan Boneh. "Provisions: Privacy-preserving proofs of solvency for
Bitcoin exchanges." (2015).</ref>, this BIP intentionally only formalizes
the de-facto existing method.
==Specification==
Our specification consists of two parts:
# the format for the actual proofs
# a file format used to package a set of proofs and relevant metadata
The final construction should have the following properties:
* flexible proof construction to support complex wallet infrastructures
* easy integration with existing wallet solutions (both hardware and software wallets)
* support for verification via a standard procedure, regardless of publisher of the proof
* proof prevents reuse of proofs by other parties by committing to a message
* allow validating that the issuer had the funds under his control at a certain block, regardless of what happened after that block
===Proof Format===
To allow for maximal compatibility with existing systems, proofs are formatted as regular Bitcoin
transactions. However, one small adaptation to the transaction is made that has two functions:
# make the transaction unspendable to avoid putting funds at risk
# link the proof to the issuer of the proof to prevent copying proofs from other custodians
The resulting construction is a Bitcoin transaction with the following
characteristics:
* The first input (the "commitment input")
** MUST have the txid part of the previous outpoint set to the SHA-256 hash of the commitment message prefixed with "Proof-of-Reserves: "<ref>If the message is "Some Message", the txid part should be <tt>SHA-256("Proof-of-Reserves: Some Message")</tt> with the string encoded as UTF-8.</ref> and index 0.
* The remaining inputs
** MUST have signatures that commit to the commitment input (e.g. using <tt>SIGHASH_ALL</tt>).
* The transaction MUST have a single output that is the exact sum of all the inputs, assuming the commitment input to have 0 value; this means the transaction has no miner fee.
The existence of the first input (which is just a commitment hash) ensures
that this transaction is invalid and can never be confirmed.
===Proof File Format===
In theory, the first part of the specification would be sufficient as a minimum
viable standard. However, there are a number of motivations to extend the
standard with an extra layer of metadata:
# constructing and combining multiple proofs
#:Having thousands of UTXOs spread across different offline and online wallets could make it difficult to construct a single proof transaction with all UTXOs. Allowing multiple proof transactions with the same commitment message and block number gives extra flexibility to custodians with complex wallet infrastructure without making the combined proof less secure.
# metadata for verification
#:Not all systems that will be used for verification have access to a full index of all transactions. However, proofs should be easily verifiable even after some of the UTXOs used in the proof are no longer unspent. Metadata present in the proof allows for relatively efficient verification of proofs even if no transaction index is available.
# potential future improvements
#:The extensible metadata format allows for amending the standard in the future. One potential improvement would be having UTXO set commitments. These would allow the proofs-of-reserves to come with accompanying proofs-of-inclusion of all used UTXOs in the UTXO set at the block of proof construction (making validation even more efficient).
The proposed proof-file format provides a standard way of combining multiple
proofs and associated metadata. The specification of the format is in the
An implementation of the custom proof PSBTs is part of the [https://bitcoindevkit.org/ BDK], and can be found here: https://crates.io/crates/bdk-reserves
