MIME-Version: 1.0
References: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
In-Reply-To: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 6 Jul 2021 12:39:36 -0400
Message-ID: <CAJowKgJEJr=LhYhuQs4zOyskdAwjZT6aEFd-3=rsShLUf7yWJw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Proof of reserves - recording
Precedence: list

you should check out some of the earlier work done here:

https://github.com/olalonde/proof-of-solvency#assets-proof

to be honest, if any exchange supported that proof, it would be more
than enough.

there's really no way to prevent a smash-and-grab, but this does
prevent a slow-leak


On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I had the idea recently for proof of reserves done in a way that can be u=
sed to verify reserves are sufficient on an ongoing basis. I'm curious if t=
here are any current approaches out there to proof of reserves that are sim=
ilar.
>
> The idea is to have users create actual private keys using a seed in pret=
ty much the normal way. Users would generate a public key from this seed to=
 represent their account, and would give the public key to the custodian to=
 represent their account in a public record of account balances.
>
> When a user's account is credited, the custodian would update a map of ad=
dresses (created from the public key of each account) to balances - this ma=
p could be structured into a merkle tree in the usual "merkle approach". Th=
e custodian would also store funds on one or more HD wallets (each with man=
y addresses) and create a proof that they own each HD wallet. The proof cou=
ld be as simple as a single signature created with the xpub for the wallet,=
 which would be sufficient for proving ownership over the whole list/tree o=
f addresses.
>
> These two structures (the map and the HD wallet) would be combined and ha=
shed, and the hash published in an on chain transaction (possibly along wit=
h a URI where the full data can be found), on something like a daily basis.=
 Software for each user could continuously validate that their account has =
a balance that matches what it's supposed to have, and could also verify th=
at owned addresses have funds that have at least as many coins as promised =
to accounts. If these things aren't verifiable (either because the balances=
 total to more than the HD wallet contains, or because of data unavailabili=
ty), people can raise hell about it.
>
> To give user's additional proving ability, a receipt system could be adde=
d. Users could request a receipt for any balance update. Eg the user would =
create a message with a timestamp, their custodial "address", and the new b=
alance. The user would sign this receipt and send it to the custodian, who =
would also sign it and send it back. This way, if something goes wrong, a u=
ser can use this signed receipt to show that the custodian did in fact prom=
ise a new updated balance at a particular time (which would cover the case =
that the custodian records the wrong value in their map). Conversely, the r=
eceipt would be useful to honest custodians as well, since they could show =
the user's signed receipt request in the case a user is trying to lie about=
 what balance they should have. There is still the case that the custodian =
simply refuses to return a signed receipt, in which case the user's only re=
course is to yell about it immediately and demand a receipt or a refund.
>
> Why record it on chain? Doing that gives a clear record of proof of reser=
ves that can be verified later by anyone in the future. It prevents a custo=
dian from being able to change history when it suits them (by creating a ne=
w records with false timestamps in the past). Many of these records could b=
e aggregated together and recorded in the same transaction (with a single h=
ash), so a single transaction per day could record the records of all parti=
cipating custodians. If all custodians are using a standard system, one can=
 cross verify that addresses claimed by one custodian aren't also claimed b=
y another custodian.
>
> Even tho the user is responsible for their keys in order to properly veri=
fy, losing the keys isn't that big of a deal, since they could simply creat=
e a new seed and give a new public key to the custodian - who would have ot=
her identifying information they could use to validate that they own the ac=
count. So it places less responsibility on the user, while still introducin=
g people, in a light-weight way, to self custody of keys.
>
> Having a record like this every day would reduce the possibility of shena=
nigans like taking a short term loan of a large amount of cryptocurrency. S=
ure, they could take a 10 minute loan once per day, but it would also be po=
ssible to trace on-chain transactions so you could tell if such a thing was=
 going on. I wonder if there would be some way to include the ability to pr=
ove balances held on the lightning network, but I suspect that isn't genera=
lly possible.
>
> In any case, I'm curious what people think of this kind of thing, and if =
systems with similar properties are already out there.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev