path: root/f2/30b48030055728abdcb05abd62dec46aab557f

Return-Path: <stevenroose@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B3F38341F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Jan 2019 22:00:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com
	[209.85.222.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1882485A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Jan 2019 22:00:23 +0000 (UTC)
Received: by mail-qk1-f173.google.com with SMTP id w204so12538603qka.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Jan 2019 14:00:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=YWGWGgwRqiqsvgvA879uEaH2vi7jmw3msTAySJvFZvA=;
	b=VxlmJbnVkxIl6osiX30gyosOpYdbiJEkhKqwsiHM8P7/pUBJqT0I0+zJQ79PfE+G8t
	O2m1QP4eUy0ZkV7dgVh8bhtHBszAyZrWW/g/xVdFQDLoDP+L/KyCTSNXinNAveN4QFC/
	zSJEjg4irOc6swIPAHD6pHh5O70EgMFAlRYoXOvuY9MwGn0gHeqwwbYN6+LzLlPPqajl
	oz15zMIAQgyEmJyPXUrcQcWC05LcWwx953/zTRS58ohCzFf4CbvYDmjddGRB+i8YsHwA
	Rtf+5YjJxpbxGxUzZhbfy7k4wY1vRI1I9hDnY6vDTlh9Y8v1iotyDud3K+xj3ZQUJtLF
	N8Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=YWGWGgwRqiqsvgvA879uEaH2vi7jmw3msTAySJvFZvA=;
	b=Ysc47oqgzLd+2LXfluiklQb+ZuOf6+30Q3w/TDuvyZ0/7tmvqCVBg3rbicy0qghm2b
	tdtPxtIzH+b2pkTa+2lcEESiJHUy55/3ekfn7R86GbIfD3mTMNfKYNjbsUTcLbRX2vMN
	Sr9wev4vShHkmkyizQWql75kHZNXOZ67qVhPCnWU/Twp11UkhD76KSvBdicgF0kOd60o
	nFN4KJtw7aL7szBk+tHiEFI6JKOoQQ1dho7XEgWpG7ILVT5BY0YCFIYAisQ+cPGSiP3k
	ThD+QaEOYwLZbTGtjYkb1hoM7y+7OUFS1ySh4Ndk9/HWN7D/jvAUyvGm3iMcaKV/GEY3
	aQJg==
X-Gm-Message-State: AJcUukdhx20tEzkatnAuKTolzyyOVo6mZnaG4T7qzCTGGYY8Ag4caDWQ
	9hQq0vKsCSoEcPtbIG/0oSOOmjH1OUxzQWxKb1g8gcRU
X-Google-Smtp-Source: ALg8bN7Wc9P/9h7Av1Aw2QdAcC3pETWjs7wDEhle/z4D3PBDdmDM2rUwf7XJ5l6ExqEXcgVLJewkPBc+nsksX4eMPSs=
X-Received: by 2002:a37:b9c2:: with SMTP id
	j185mr26054247qkf.333.1548799221819; 
	Tue, 29 Jan 2019 14:00:21 -0800 (PST)
MIME-Version: 1.0
From: Steven Roose <stevenroose@gmail.com>
Date: Tue, 29 Jan 2019 22:03:04 +0000
Message-ID: <CAChG=YV2em+6c9P4DEUB1=+ZSEA6S0j9HDuWoKBeRVMmtzaMNg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000071f07405809febcd"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 29 Jan 2019 22:51:32 +0000
Subject: [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves Transactions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2019 22:00:24 -0000

--00000000000071f07405809febcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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


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


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

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.

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

This BIP is licensed under the Creative Commons CC0 1.0 Universal license.

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

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.


=3D=3D=3DWhat this BIP is not doing=3D=3D=3D

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=C3=BCnz, Joseph Bonneau,
Jeremy
Clark, and Dan Boneh. "Provisions: Privacy-preserving proofs of solvency fo=
r
Bitcoin exchanges." (2015).</ref>, this BIP intentionally only formalizes
the de-facto existing method.


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

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 commiting 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

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

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.


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

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
constsruction (making validation even more efficient).

The proposed proof-file format provides a standard way of combining multipl=
e
proofs and associated metadata.  The specification of the format is in the
Protocol Buffers<ref>https://github.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;

// 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;
}
</pre>

The last field, <tt>pending_proofs</tt>, leaves open some space in the same
file that can be used by proof-construction tools.  This allows them to
construct different proofs incrementally without having to switch between
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 (empty <tt>scriptSig</tt> and
witness).  This can cause some problems when signing this type of
transactions.
For example, hardware wallets often require the signer to provide
information
about all inputs of transactions they are signing, such as the previous
output
or previous transaction; this data obviously doesn't exist for the
commitment
inputs.

For most existing devices, it's possible to circumvent these requirements b=
y
providing dummy data or by instructing the device to ignore this specific
input.  However, there is still a UX problem.  Because the hardware wallet
device doesn't recognize the transaction as a proof-of-reserves transaction
it
will think it is signing a regular transaction that is spending all the
money
in the UTXOs.  Most devices will ask for confirmation with a message along
the
lines of "Are you sure you want to send XXX BTC to address [...]?".  This i=
s
not the best user experience.

An addition to the BIP 174 PSBT format could help signing devices to
recognize 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_COMMITMENT =3D 0x09</t=
t>
** 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-reserves.
*** <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
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 inputs;
* SHOULD only provide signatures with a signature hash that commits to this
input;
* SHOULD accept an empty <tt>scriptSig</tt> for this input (as if the
<tt>scriptPubKey</tt> was <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

A work-in-progress implementation of a tool that produces and verifies
proofs
in the described format can be found here:
https://github.com/stevenroose/reserves


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

<references />

PR: https://github.com/bitcoin/bips/pull/756

--00000000000071f07405809febcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>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.<br></div>=
<div><br></div><div><br></div><div>&lt;pre&gt;<br></div><div>=C2=A0 BIP: ?<=
br></div><div>=C2=A0 Layer: Applications<br></div><div>=C2=A0 Title: Simple=
 Proof-of-Reserves Transactions<br></div><div>=C2=A0 Author: Steven Roose &=
lt;<a href=3D"mailto:steven@stevenroose.org" rel=3D"noreferrer nofollow noo=
pener">steven@stevenroose.org</a>&gt;<br></div><div>=C2=A0 Comments-Summary=
: No comments yet.<br></div><div>=C2=A0 Comments-URI: tbd<br></div><div>=C2=
=A0 Status: Draft<br></div><div>=C2=A0 Type: Standards Track<br></div><div>=
=C2=A0 Created: 2019-01-28<br></div><div>=C2=A0 License: CC0-1.0<br></div><=
div>&lt;/pre&gt;<br></div><div><br></div><div><br></div><div>=3D=3DAbstract=
=3D=3D<br></div><div><br></div><div>This BIP describes a simple way to cons=
truct proof-of-reserves transactions.<br></div><div>This proposal formalize=
s a standard format for constructing such proofs, easing<br></div><div>thei=
r construction with existing wallet infrastructure and enabling general<br>=
</div><div>proof-verification software.=C2=A0 It relies on existing standar=
ds such as regular<br></div><div>Bitcoin transaction serialization/validati=
on and the BIP 174 PSBT format.<br></div><div>The proposal also includes th=
e description of a PSBT extension for a better<br></div><div>user experienc=
e.<br></div><div><br></div><div>=3D=3DCopyright=3D=3D<br></div><div><br></d=
iv><div>This BIP is licensed under the Creative Commons CC0 1.0 Universal l=
icense.<br></div><div><br></div><div>=3D=3DMotivation=3D=3D<br></div><div><=
br></div><div>From the very early days in the history of Bitcoin, there hav=
e been companies<br></div><div>managing bitcoins for their users.=C2=A0 The=
se users give up control over their coins<br></div><div>in return for a cer=
tain service.=C2=A0 Inevitably, there have been many cases of<br></div><div=
>companies losing their users&#39; bitcoins without timely disclosing such =
events to<br></div><div>the public.=C2=A0 Proofs of Reserves are a way for =
companies managing large amounts<br></div><div>of bitcoins to prove ownersh=
ip over a given amount of funds.=C2=A0 The regular proof<br></div><div>of c=
ontrol helps to ensure that no significant loss has occurred.<br></div><div=
><br></div><div>While the term proof-of-reserves is not new by any means, t=
he procedure is not<br></div><div>very common among high-value custodian co=
mpanies.=C2=A0 One of the reasons for this<br></div><div>is that every comp=
any that wants to perform a proof-of-reserves has to construct<br></div><di=
v>its own way to do so.=C2=A0 Accordingly, their users have to understand t=
he<br></div><div>construction of the proof in order to be able to verify it=
.=C2=A0 This raises the bar<br></div><div>of entry both for custodians and =
for users.<br></div><div><br></div><div><br></div><div>=3D=3D=3DWhat this B=
IP is not doing=3D=3D=3D<br></div><div><br></div><div>The proof-of-reserve =
construction described in this document has some known<br></div><div>shortc=
omings, mostly with regards to its privacy properties.=C2=A0 While there ex=
ists<br></div><div>research about improved proof-of-reserves mechanisms tha=
t have much better<br></div><div>privacy properties&lt;ref&gt;Dagher, Gaby =
G., Benedikt B=C3=BCnz, Joseph Bonneau, Jeremy<br></div><div>Clark, and Dan=
 Boneh. &quot;Provisions: Privacy-preserving proofs of solvency for<br></di=
v><div>Bitcoin exchanges.&quot; (2015).&lt;/ref&gt;, this BIP intentionally=
 only formalizes<br></div><div>the de-facto existing method.<br></div><div>=
<br></div><div><br></div><div>=3D=3DSpecification=3D=3D<br></div><div><br><=
/div><div>Our specification consists of two parts:<br></div><div># the form=
at for the actual proofs<br></div><div># a file format used to package a se=
t of proofs and relevant metadata<br></div><div><br></div><div>The final co=
nstruction should have the following properties:<br></div><div>* flexible p=
roof construction to support complex wallet infrastructures<br></div><div>*=
 easy integration with existing wallet solutions (both hardware and softwar=
e wallets)<br></div><div>* support for verification via a standard procedur=
e, regardless of publisher of the proof<br></div><div>* proof prevents reus=
e of proofs by other parties by commiting to a message<br></div><div>*
 allow validating that the issuer had the funds under his control at a=20
certain block, regardless of what happened after that block<br></div><div><=
br></div><div>=3D=3D=3DProof Format=3D=3D=3D<br></div><div><br></div><div>T=
o allow for maximal compatibility with existing systems, proofs are formatt=
ed as regular Bitcoin<br></div><div>transactions.=C2=A0 However, one small =
adaptation to the transaction is made that has two functions:<br></div><div=
># make the transaction unspendable to avoid putting funds at risk<br></div=
><div># link the proof to the issuer of the proof to prevent copying proofs=
 from other custodians<br></div><div><br></div><div>The resulting construct=
ion is a Bitcoin transaction with the following<br></div><div>characteristi=
cs:<br></div><div><br></div><div>* The first input (the &quot;commitment in=
put&quot;)<br></div><div>**
 MUST have the txid part of the previous outpoint set to the SHA-256=20
hash of the commitment message prefixed with &quot;Proof-of-Reserves:=20
&quot;&lt;ref&gt;If the message is &quot;Some Message&quot;, the txid part =
should be=20
&lt;tt&gt;SHA-256(&quot;Proof-of-Reserves: Some Message&quot;)&lt;/tt&gt; w=
ith the
 string encoded as UTF-8.&lt;/ref&gt; and index 0.<br></div><div>* The rema=
ining inputs<br></div><div>** MUST have signatures that commit to the commi=
tment input (e.g. using &lt;tt&gt;SIGHASH_ALL&lt;/tt&gt;).<br></div><div>*
 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.<br></div><div><br></div><div>The existenc=
e of the first input (which is just a commitment hash) ensures<br></div><di=
v>that this transaction is invalid and can never be confirmed.<br></div><di=
v><br></div><div><br></div><div>=3D=3D=3DProof File Format=3D=3D=3D<br></di=
v><div><br></div><div>In theory, the first part of the specification would =
be sufficient as a minimum<br></div><div>viable standard.=C2=A0 However, th=
ere are a number of motivations to extend the<br></div><div>standard with a=
n extra layer of metadata:<br></div><div><br></div><div># constructing and =
combining multiple proofs<br></div><div>#: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.<br></div><div># metadata for verification<br></div><div>#: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.<br></div>=
<div># potential future improvements<br></div><div>#: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).<br></div><div><br></div><div>The proposed proof-file format pro=
vides a standard way of combining multiple<br></div><div>proofs and associa=
ted metadata.=C2=A0 The specification of the format is in the<br></div><div=
>Protocol Buffers&lt;ref&gt;<a href=3D"https://github.com/protocolbuffers/p=
rotobuf/" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://gi=
thub.com/protocolbuffers/protobuf/</a>&lt;/ref&gt; format.<br></div><div><b=
r></div><div>&lt;pre&gt;<br></div><div>syntax =3D &quot;proto3&quot;;<br></=
div><div>import &quot;google/protobuf/any.proto&quot;;<br></div><div><br></=
div><div>message OutputMeta {<br></div><div>// Identify the outpoint.<br></=
div><div>bytes txid =3D 1;<br></div><div>uint32 vout =3D 2;<br></div><div><=
br></div><div>// The block hash of the block where this output was created.=
<br></div><div>bytes block_hash =3D 3;<br></div><div>}<br></div><div><br></=
div><div>message FinalProof {<br></div><div>// The proof transaction.=C2=A0=
 Should be able to be parsed like a regular<br></div><div>// Bitcoin transa=
ction.<br></div><div>bytes proof_tx =3D 1;<br></div><div><br></div><div>// =
The metadata of the ouputs used in the proof transaction.<br></div><div>rep=
eated OutputMeta output_metadata =3D 2;<br></div><div>}<br></div><div><br><=
/div><div>message ProofOfReserves {<br></div><div>// A version number for t=
his format to enable extending it with<br></div><div>// additional fields.<=
br></div><div>uint32 version =3D 1;<br></div><div><br></div><div>// The net=
work magic for the network in which the proofs are valid.<br></div><div>// =
0xD9B4BEF9 for mainnet, 0x0709110B for testnet<br></div><div>//TODO conside=
r BIP44 coin type ids instead:<br></div><div>// <a href=3D"https://github.c=
om/satoshilabs/slips/blob/master/slip-0044.md" target=3D"_blank" rel=3D"nor=
eferrer nofollow noopener">https://github.com/satoshilabs/slips/blob/master=
/slip-0044.md</a><br></div><div>uint32 network_magic =3D 2;<br></div><div><=
br></div><div>// The commitment message for this proof-of-reserves.=C2=A0<b=
r></div><div>// This message is global for all the proofs.<br></div><div>st=
ring message =3D 3;<br></div><div><br></div><div>// The block at which this=
 proof is supposed to be validated.<br></div><div>// Verification should ta=
ke into account unspentness of outputs at this<br></div><div>// block heigh=
t.<br></div><div>bytes block_hash =3D 4;<br></div><div><br></div><div>// Th=
e set of final proof transactions with their output metadata.<br></div><div=
>repeated FinalProof final_proofs =3D 5;<br></div><div><br></div><div>// Re=
served field that can potentially be used by proof-construction tools.<br><=
/div><div>// It can be ignored for verification.<br></div><div>repeated goo=
gle.protobuf.Any pending_proofs =3D 6;<br></div><div>}<br></div><div>&lt;/p=
re&gt;<br></div><div><br></div><div>The last field, &lt;tt&gt;pending_proof=
s&lt;/tt&gt;, leaves open some space in the same<br></div><div>file that ca=
n be used by proof-construction tools.=C2=A0 This allows them to<br></div><=
div>construct different proofs incrementally without having to switch betwe=
en file<br></div><div>formats.<br></div><div><br></div><div><br></div><div>=
=3D=3D=3DPSBT (BIP 174) extension=3D=3D=3D<br></div><div><br></div><div>The=
 &quot;commitment input&quot; detailed in the proof format section does not=
 spend an<br></div><div>existing UTXO and thus shouldn&#39;t be signed (emp=
ty &lt;tt&gt;scriptSig&lt;/tt&gt; and<br></div><div>witness).=C2=A0 This ca=
n cause some problems when signing this type of transactions.<br></div><div=
>For example, hardware wallets often require the signer to provide informat=
ion<br></div><div>about all inputs of transactions they are signing, such a=
s the previous output<br></div><div>or previous transaction; this data obvi=
ously doesn&#39;t exist for the commitment<br></div><div>inputs.<br></div><=
div><br></div><div>For most existing devices, it&#39;s possible to circumve=
nt these requirements by<br></div><div>providing dummy data or by instructi=
ng the device to ignore this specific<br></div><div>input.=C2=A0 However, t=
here is still a UX problem.=C2=A0 Because the hardware wallet<br></div><div=
>device doesn&#39;t recognize the transaction as a proof-of-reserves transa=
ction it<br></div><div>will think it is signing a regular transaction that =
is spending all the money<br></div><div>in the UTXOs.=C2=A0 Most devices wi=
ll ask for confirmation with a message along the<br></div><div>lines of &qu=
ot;Are you sure you want to send XXX BTC to address [...]?&quot;.=C2=A0 Thi=
s is<br></div><div>not the best user experience.<br></div><div><br></div><d=
iv>An addition to the BIP 174 PSBT format could help signing devices to rec=
ognize proof-of-reserve transactions.<br></div><div>The following field is =
added to the BIP 174 &lt;tt&gt;INPUT&lt;/tt&gt; map:<br></div><div><br></di=
v><div>* Type: Proof-of-reserves commitment &lt;tt&gt;PSBT_IN_POR_COMMITMEN=
T =3D 0x09&lt;/tt&gt;<br></div><div>** Key: None. The key must only contain=
 the 1 byte type.<br></div><div>*** &lt;tt&gt;{0x09}&lt;/tt&gt;<br></div><d=
iv>** Value: The UTF-8 encoded commitment message string for the proof-of-r=
eserves.<br></div><div>*** &lt;tt&gt;{porCommitment}&lt;/tt&gt;<br></div><d=
iv><br></div><div>Wallets processing an input that has this field set<br></=
div><div>*
 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;<br></div=
><div>* MUST assume the input value to be 0 (without requiring the previous=
 output or transaction to be provided);<br></div><div>* SHOULD display the =
commitment message to ask the user for confirmation before signing any inpu=
ts;<br></div><div>* SHOULD only provide signatures with a signature hash th=
at commits to this input;<br></div><div>*
 SHOULD accept an empty &lt;tt&gt;scriptSig&lt;/tt&gt; for this input=20
(as if the &lt;tt&gt;scriptPubKey&lt;/tt&gt; was=20
&lt;tt&gt;OP_TRUE&lt;/tt&gt;).<br></div><div><br></div><div><br></div><div>=
=3D=3DImplementations=3D=3D<br></div><div><br></div><div>A proof-of-concept=
 implementation of the PSBT extension in the<br></div><div>[<a href=3D"http=
s://github.com/rust-bitcoin/rust-bitcoin" target=3D"_blank" rel=3D"noreferr=
er nofollow noopener">https://github.com/rust-bitcoin/rust-bitcoin</a> rust=
-bitcoin] project can be<br></div><div>found in the &lt;tt&gt;psbt-por&lt;/=
tt&gt; branch here:<br></div><div><a href=3D"https://github.com/stevenroose=
/rust-bitcoin/tree/psbt-por" target=3D"_blank" rel=3D"noreferrer nofollow n=
oopener">https://github.com/stevenroose/rust-bitcoin/tree/psbt-por</a><br><=
/div><div><br></div><div>A work-in-progress implementation of a tool that p=
roduces and verifies proofs<br></div><div>in the described format can be fo=
und here:<br></div><div><a href=3D"https://github.com/stevenroose/reserves"=
 target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://github.com/=
stevenroose/reserves</a><br></div><div><br></div><div><br></div><div>=3D=3D=
 Footnotes =3D=3D<br></div><div><br></div><div>&lt;references /&gt;<br></di=
v><div><br></div><div>PR: <a href=3D"https://github.com/bitcoin/bips/pull/7=
56" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://github.c=
om/bitcoin/bips/pull/756</a></div></div>

--00000000000071f07405809febcd--