BIP: ? Layer: Applications Title: Simple Proof-of-Reserves Transactions Author: Steven Roose Comments-Summary: No comments yet. Comments-URI: tbd Status: Draft Type: Standards Track Created: 2019-01-28 License: CC0-1.0

syntax =3D "proto3"; import "google/protobuf/any.proto"; message OutputMeta { // Identify the outpoint. bytes txid =3D 1; uint32 vout =3D 2; // The block hash of the block where this output was created. bytes block_hash =3D 3; } message FinalProof { // The proof transaction. Should be able to be parsed like a regular // Bitcoin transaction. bytes proof_tx =3D 1; // The metadata of the ouputs used in the proof transaction. repeated OutputMeta output_metadata =3D 2; } message ProofOfReserves { // A version number for this format to enable extending it with // additional fields. uint32 version =3D 1; // The network magic for the network in which the proofs are valid. // 0xD9B4BEF9 for mainnet, 0x0709110B for testnet //TODO consider BIP44 coin type ids instead: // https://github.com/satoshilabs/slips/blob/master/slip-0044.md uint32 network_magic =3D 2; // The commitment message for this proof-of-reserves. // This message is global for all the proofs. string message =3D 3; // The block at which this proof is supposed to be validated. // Verification should take into account unspentness of outputs at this // block height. bytes block_hash =3D 4; // The set of final proof transactions with their output metadata. repeated FinalProof final_proofs =3D 5; // Reserved field that can potentially be used by proof-construction tools. // It can be ignored for verification. repeated google.protobuf.Any pending_proofs =3D 6; }

PR: https://github.com/bitcoin/bips/pull/756 --00000000000071f07405809febcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Been working on a proof-of-reserves tool POC for a wh= ile, trying to formalize the formats so that wallets can integrate more easily.

<pre>

=C2=A0 BIP: ?<= br>

=C2=A0 Layer: Applications

=C2=A0 Title: Simple= Proof-of-Reserves Transactions

=C2=A0 Author: Steven Roose &= lt;steven@stevenroose.org>

=C2=A0 Comments-Summary= : No comments yet.

=C2=A0 Comments-URI: tbd

=C2= =A0 Status: Draft

=C2=A0 Type: Standards Track

= =C2=A0 Created: 2019-01-28

=C2=A0 License: CC0-1.0

<= div></pre>

=3D=3DAbstract= =3D=3D

This BIP describes a simple way to cons= truct proof-of-reserves transactions.

This proposal formalize= s a standard format for constructing such proofs, easing

thei= r construction with existing wallet infrastructure and enabling general
=

proof-verification software.=C2=A0 It relies on existing standar= ds such as regular

Bitcoin transaction serialization/validati= on and the BIP 174 PSBT format.

The proposal also includes th= e description of a PSBT extension for a better

user experienc= e.

=3D=3DCopyright=3D=3D

This BIP is licensed under the Creative Commons CC0 1.0 Universal l= icense.

=3D=3DMotivation=3D=3D

<= br>

From the very early days in the history of Bitcoin, there hav= e been companies

managing bitcoins for their users.=C2=A0 The= se users give up control over their coins

in return for a cer= tain service.=C2=A0 Inevitably, there have been many cases of

companies losing their users' bitcoins without timely disclosing such = events to

the public.=C2=A0 Proofs of Reserves are a way for = companies managing large amounts

of bitcoins to prove ownersh= ip over a given amount of funds.=C2=A0 The regular proof

of c= ontrol helps to ensure that no significant loss has occurred.

While the term proof-of-reserves is not new by any means, t= he procedure is not

very common among high-value custodian co= mpanies.=C2=A0 One of the reasons for this

is that every comp= any that wants to perform a proof-of-reserves has to construct

its own way to do so.=C2=A0 Accordingly, their users have to understand t= he

construction of the proof in order to be able to verify it= .=C2=A0 This raises the bar

of entry both for custodians and = for users.

=3D=3D=3DWhat this B= IP is not doing=3D=3D=3D

The proof-of-reserve = construction described in this document has some known

shortc= omings, mostly with regards to its privacy properties.=C2=A0 While there ex= ists

research about improved proof-of-reserves mechanisms tha= t have much better

privacy properties<ref>Dagher, Gaby = G., Benedikt B=C3=BCnz, 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.

=3D=3DSpecification=3D=3D

<= /div>

Our specification consists of two parts:

# the form= at for the actual proofs

# a file format used to package a se= t of proofs and relevant metadata

The final co= nstruction should have the following properties:

* flexible p= roof construction to support complex wallet infrastructures

*= easy integration with existing wallet solutions (both hardware and softwar= e wallets)

* support for verification via a standard procedur= e, regardless of publisher of the proof

* proof prevents reus= e of proofs by other parties by commiting to a message

* allow validating that the issuer had the funds under his control at a=20 certain block, regardless of what happened after that block

<= br>

=3D=3D=3DProof Format=3D=3D=3D

T= o allow for maximal compatibility with existing systems, proofs are formatt= ed as regular Bitcoin

transactions.=C2=A0 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 construct= ion is a Bitcoin transaction with the following

characteristi= cs:

* The first input (the "commitment in= put")

** MUST have the txid part of the previous outpoint set to the SHA-256=20 hash of the commitment message prefixed with "Proof-of-Reserves:=20 "<ref>If the message is "Some Message", the txid part = should be=20 <tt>SHA-256("Proof-of-Reserves: Some Message")</tt> w= ith the string encoded as UTF-8.</ref> and index 0.

* The rema= ining inputs

** MUST have signatures that commit to the commi= tment input (e.g. using <tt>SIGHASH_ALL</tt>).

* The transaction MUST have a single output that is the exact sum of all=20 the inputs, assuming the commitment input to have 0 value; this means=20 the transaction has no miner fee.

The existenc= e of the first input (which is just a commitment hash) ensures

that this transaction is invalid and can never be confirmed.

=3D=3D=3DProof File Format=3D=3D=3D

In theory, the first part of the specification would = be sufficient as a minimum

viable standard.=C2=A0 However, th= ere are a number of motivations to extend the

standard with a= n extra layer of metadata:

# constructing and = combining multiple proofs

#:Having thousands of UTXOs spread across different offline and online wallets=20 could make it difficult to construct a single proof transaction with all UTXOs.=C2=A0 Allowing multiple proof transactions with the same commitment= =20 message and block number gives extra flexibility to custodians with=20 complex wallet infrastructure without making the combined proof less=20 secure.

# metadata for verification

#:Not=20 all systems that will be used for verification have access to a full=20 index of all transactions.=C2=A0 However, proofs should be easily verifiabl= e=20 even after some of the UTXOs used in the proof are no longer unspent.=C2=A0= =20 Metadata present in the proof allows for relatively efficient=20 verification of proofs even if no transaction index is available.

# potential future improvements

#:The extensible metadata format allows for amending the standard in the=20 future.=C2=A0 One potential improvement would be having UTXO set=20 commitments.=C2=A0 These would allow the proofs-of-reserves to come with=20 accompanying proofs-of-inclusion of all used UTXOs in the UTXO set at=20 the block of proof constsruction (making validation even more=20 efficient).

The proposed proof-file format pro= vides a standard way of combining multiple

proofs and associa= ted metadata.=C2=A0 The specification of the format is in the

Protocol Buffers<ref>https://gi= thub.com/protocolbuffers/protobuf/</ref> format.

<pre>

syntax =3D "proto3";

import "google/protobuf/any.proto";

message OutputMeta {

// Identify the outpoint.

bytes txid =3D 1;

uint32 vout =3D 2;

<= br>

// The block hash of the block where this output was created.=

bytes block_hash =3D 3;

}

message FinalProof {

// The proof transaction.=C2=A0= Should be able to be parsed like a regular

// Bitcoin transa= ction.

bytes proof_tx =3D 1;

// = The metadata of the ouputs used in the proof transaction.

rep= eated OutputMeta output_metadata =3D 2;

}

<= /div>

message ProofOfReserves {

// A version number for t= his format to enable extending it with

// additional fields.<= br>

uint32 version =3D 1;

// The net= work magic for the network in which the proofs are valid.

// = 0xD9B4BEF9 for mainnet, 0x0709110B for testnet

//TODO conside= r BIP44 coin type ids instead:

// https://github.com/satoshilabs/slips/blob/master= /slip-0044.md

uint32 network_magic =3D 2;

<= br>

// The commitment message for this proof-of-reserves.=C2=A0

// This message is global for all the proofs.

st= ring message =3D 3;

// The block at which this= proof is supposed to be validated.

// Verification should ta= ke into account unspentness of outputs at this

// block heigh= t.

bytes block_hash =3D 4;

// Th= e set of final proof transactions with their output metadata.

repeated FinalProof final_proofs =3D 5;

// Re= served field that can potentially be used by proof-construction tools.
<= /div>

// It can be ignored for verification.

repeated goo= gle.protobuf.Any pending_proofs =3D 6;

}

</p= re>

The last field, <tt>pending_proof= s</tt>, leaves open some space in the same

file that ca= n be used by proof-construction tools.=C2=A0 This allows them to

<= div>construct different proofs incrementally without having to switch betwe= en file

formats.

= =3D=3D=3DPSBT (BIP 174) extension=3D=3D=3D

The= "commitment input" detailed in the proof format section does not= spend an

existing UTXO and thus shouldn't be signed (emp= ty <tt>scriptSig</tt> and

witness).=C2=A0 This ca= n cause some problems when signing this type of transactions.

For example, hardware wallets often require the signer to provide informat= ion

about all inputs of transactions they are signing, such a= s the previous output

or previous transaction; this data obvi= ously doesn't exist for the commitment

inputs.

<= div>

For most existing devices, it's possible to circumve= nt these requirements by

providing dummy data or by instructi= ng the device to ignore this specific

input.=C2=A0 However, t= here is still a UX problem.=C2=A0 Because the hardware wallet

device doesn't recognize the transaction as a proof-of-reserves transa= ction it

will think it is signing a regular transaction that = is spending all the money

in the UTXOs.=C2=A0 Most devices wi= ll ask for confirmation with a message along the

lines of &qu= ot;Are you sure you want to send XXX BTC to address [...]?".=C2=A0 Thi= s is

not the best user experience.

An addition to the BIP 174 PSBT format could help signing devices to rec= ognize proof-of-reserve transactions.

The following field is = added to the BIP 174 <tt>INPUT</tt> map:

* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMEN= T =3D 0x09</tt>

** Key: None. The key must only contain= the 1 byte type.

*** <tt>{0x09}</tt>

** Value: The UTF-8 encoded commitment message string for the proof-of-r= eserves.

*** <tt>{porCommitment}</tt>

Wallets processing an input that has this field set

* MUST make sure the txid of the previous outpoint is set to the SHA-256=20 hash of the prefixed commitment message string, as detailed above;

* MUST assume the input value to be 0 (without requiring the previous= output or transaction to be provided);

* SHOULD display the = commitment message to ask the user for confirmation before signing any inpu= ts;

* SHOULD only provide signatures with a signature hash th= at commits to this input;

* SHOULD accept an empty <tt>scriptSig</tt> for this input=20 (as if the <tt>scriptPubKey</tt> was=20 <tt>OP_TRUE</tt>).

= =3D=3DImplementations=3D=3D

A proof-of-concept= implementation of the PSBT extension in the

[https://github.com/rust-bitcoin/rust-bitcoin rust= -bitcoin] project can be

found in the <tt>psbt-por</= tt> branch here:

https://github.com/stevenroose/rust-bitcoin/tree/psbt-por
<= /div>

A work-in-progress implementation of a tool that p= roduces and verifies proofs

in the described format can be fo= und here:

https://github.com/= stevenroose/reserves

=3D=3D= Footnotes =3D=3D

PR: https://github.c= om/bitcoin/bips/pull/756

--00000000000071f07405809febcd--