BIP 127: Simple Proof-of-Reserves Transactions

stevenroose commented at 1:00 pm on January 29, 2019: contributor

(submitted to bitcoin-dev, awaiting approval)

lismarys approved

MrLouzao approved

luke-jr added the label New BIP on Feb 15, 2019

luke-jr added the label Proposed BIP modification on Feb 15, 2019

luke-jr commented at 3:18 pm on February 15, 2019: member

This needs a backward compatibility section (probably simply saying it’s n/a).

Also, @achow101 needs to ACK the modifications to BIP 174.

achow101 commented at 5:47 am on February 16, 2019: member

You should add the new type to BIP 174’s Appendix A. That should also include a link to the location in the new BIP descriibing it.

stevenroose force-pushed on Feb 16, 2019

stevenroose commented at 6:18 pm on February 16, 2019: contributor

@achow101 I added the field to that table. I also mention the BIP in the explanation, but it’s currently set to TBD until this BIP gets a number assigned, then I can update both mentions of TBD to become a hyperlink. @luke-jr added compatibility section.

luke-jr renamed this:
~~[proposal] Simple Proof-of-Reserves Transactions~~
BIP 127: Simple Proof-of-Reserves Transactions
on Feb 16, 2019

luke-jr commented at 10:08 pm on February 16, 2019: member

Assigned BIP 127

stevenroose commented at 9:57 pm on February 17, 2019: contributor

I just realized it might be useful to have a way to deal with funds that are locked in a CLTV in the future. Are their opinions about this?

I’m thinking of two approaches:

have a global “locktime” variable for the entire proof, which proves that “the prover would be able to spend C coins at time L”
allow specifying a locktime for some UTXOs which allows for more fine-grained locktime limitation specification, but might make the “proof statement” more complex. Something like “the prover has ownership of C1 coins now and C2 coins a time L1, …”. For UX purposes the prover can decide to use the same locktime for all it’s CLTV UTXOs even though the locktime is further away for some of the UTXOs. Just to simplify the statement.

Both techniques would be quite straightforward to implement for verification.

stevenroose force-pushed on Feb 17, 2019

stevenroose commented at 10:04 pm on February 17, 2019: contributor

@luke-jr I updated the files to use the assigned number. Up to you if you merge it like this and allow me to update once I figured out a good way to deal with CLTV or if you want to wait for that in order to merge this.

stevenroose force-pushed on Feb 17, 2019

luke-jr commented at 3:24 am on February 18, 2019: member

“the prover would be able to spend C coins at time L”

This can’t be proven. The TXOs might get spent before time L.

luke-jr commented at 3:25 am on February 18, 2019: member

0First Comments-URI must be exactly "https://github.com/bitcoin/bips/wiki/Comments:BIP-0127" in bip-0127.mediawiki

achow101 commented at 8:14 pm on February 18, 2019: member

ACK BIP174 changes

luke-jr cross-referenced this on Feb 18, 2019 from issue BIP 137: Signatures of Messages using Bitcoin Private Keys by cgilliard

stevenroose force-pushed on Feb 21, 2019

stevenroose commented at 4:45 pm on February 21, 2019: contributor

@luke-jr There is an error in the Travis that I don’t understand. Seems to be related to the git history. I tried rebasing from latest master but that didn’t work..

stevenroose commented at 11:41 am on March 18, 2019: contributor

@luke-jr ping :)

luke-jr commented at 5:06 pm on March 18, 2019: member

It’s saying you need to update the README

in bip-0127.mediawiki:69 in c1ef9e48d1 outdated

64+
65+The final construction should have the following properties:
66+* flexible proof construction to support complex wallet infrastructures
67+* easy integration with existing wallet solutions (both hardware and software wallets)
68+* support for verification via a standard procedure, regardless of publisher of the proof
69+* proof prevents reuse of proofs by other parties by commiting to a message

rex4539 commented at 3:07 pm on April 3, 2019:

Typo: “commiting”

stevenroose commented at 7:55 pm on April 3, 2019:

done, thanks

in bip-0127.mediawiki:103 in c1ef9e48d1 outdated

 98+# constructing and combining multiple proofs
 99+#: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.
100+# metadata for verification
101+#: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.
102+# potential future improvements
103+#: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).

rex4539 commented at 3:08 pm on April 3, 2019:

Typo: “constsruction”

stevenroose commented at 7:55 pm on April 3, 2019:

done, thanks

rex4539 changes_requested

stevenroose force-pushed on Apr 3, 2019

BIP 127: Simple proofs-of-reserves 7276e9ae7b

stevenroose commented at 8:00 pm on April 3, 2019: contributor

@luke-jr fixed the README

I don’t currently have much time to work on this, but I think it’s quite final apart from the CLTV issue. So can go in like this and I can amend with a fix for that if needed.

rex4539 approved

luke-jr merged this on Apr 4, 2019

luke-jr closed this on Apr 4, 2019

Overtorment cross-referenced this on Feb 27, 2020 from issue BIP127 proof-of-reserve by Overtorment

BIP 127: Simple Proof-of-Reserves Transactions #756