path: root/33/805d538cc34c34282e715d51a2fa73155ac31d

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 30C78C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 18:24:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 1FE5683AA5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 18:24:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.603
X-Spam-Level: 
X-Spam-Status: No, score=0.603 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CMlKfTgLBKYU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 18:24:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [IPv6:2a00:1450:4864:20::62c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id CCE3D835CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 18:24:55 +0000 (UTC)
Received: by mail-ej1-x62c.google.com with SMTP id c17so30109551ejk.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Jul 2021 11:24:55 -0700 (PDT)
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=xc/CdhDS9Zq88f/GZZFCIz4+T6WFBSOZ/OEZDP28MP8=;
 b=rkgV8LuAjqRjLsww/I83OsMzBIyqAu4JmHqx5fQgJ79W384zxKque78+1UmXo2EY1y
 Iel8VNkKTKuFc3dyXtkDSuhwRM1C8kEEKWS1JmyeM02KPsyhuria5/+nIsK8Z6/UsXVI
 eGwUinPhxwUgzakTUbfMElImpwWCcDwmf9TvRuV4CAILJKom9siQrp1wLldFtjzMXsQ/
 j3XT6rvIbljk3cViVGB3jKdBAuR4N80OCkZJxq53Y2c9kwpQo4pyUMeXB2S3Khp93t2c
 XThjKEBXuEjBjmQurtX5OHc0TtNl+n3oXkduTpiIC6lIDC7BZouxxcouIL/wz5Dv4kUf
 4LBg==
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=xc/CdhDS9Zq88f/GZZFCIz4+T6WFBSOZ/OEZDP28MP8=;
 b=qk+iEsTEvBOIGEBaxr0h412yFvlA3lcfUFGQaC4ZfdDBq4MiHswknzXvDdyMyjrxqE
 412pCWAxFnzqKIdwIKvY9vPbAgr8++ySd8jZFLqVneq8pO2H7qUdAtpZpjNtXT0ESWuC
 2DSnpeabeilcLaLpxZ+Bj2cM1RWj4r2MUhXJ9Gb3Y5Ct1BPGLXwUABz3+XnO6e4bWZB9
 jfdWkdFNP+u1fFYA8rfbQQgeZc8SJWLo+dSv2xUI7zt71fpt3HFSI9U2Se+pohLNTmOu
 K/zowNDhLyh7jAIvrnxSQykY60vR4snfr9x7joZGac9FL6AjVAYAQR7B48PsSN53zShs
 XSlw==
X-Gm-Message-State: AOAM531W1mSGY4ZaC0vr7kxRDIAJcXu+K5VNyfEHYEjRhTvqx11N62th
 Pxam5kYGFndY0AB+EWTxTHOpIAMiqCTqXqpS9ZwmB/U4zAh7SQ==
X-Google-Smtp-Source: ABdhPJz/gpE8eLia9O/fb3LEU0px6YUh1e4k2SkwLHKUNKAUgLZPDKMNVg8uko99TI1PPQwRUUwMHDOhoPf1lo1X/Vg=
X-Received: by 2002:a17:906:478b:: with SMTP id
 cw11mr14062310ejc.241.1625509493523; 
 Mon, 05 Jul 2021 11:24:53 -0700 (PDT)
MIME-Version: 1.0
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 5 Jul 2021 11:24:36 -0700
Message-ID: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f0ca5005c6646b17"
X-Mailman-Approved-At: Mon, 05 Jul 2021 21:10:26 +0000
Subject: [bitcoin-dev] Proof of reserves - recording
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Mon, 05 Jul 2021 18:24:57 -0000

--000000000000f0ca5005c6646b17
Content-Type: text/plain; charset="UTF-8"

I had the idea recently for proof of reserves
<https://niccarter.info/proof-of-reserves/> done in a way that can be used
to verify reserves are sufficient on an ongoing basis. I'm curious if there
are any current approaches out there to proof of reserves that are similar.

The idea is to have users create actual private keys using a seed in pretty
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
addresses (created from the public key of each account) to balances - this
map could be structured into a merkle tree in the usual "merkle approach".
The custodian would also store funds on one or more HD wallets (each with
many addresses) and create a proof that they own each HD wallet. The proof
could 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 of addresses.

These two structures (the map and the HD wallet) would be combined and
hashed, and the hash published in an on chain transaction (possibly along
with 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 that 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 unavailability), people can raise hell about it.

To give user's additional proving ability, a receipt system could be added.
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
balance. 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
user can use this signed receipt to show that the custodian did in fact
promise 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 receipt 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 recourse 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
reserves that can be verified later by anyone in the future. It prevents a
custodian from being able to change history when it suits them (by creating
a new records with false timestamps in the past). Many of these records
could be aggregated together and recorded in the same transaction (with a
single hash), so a single transaction per day could record the records of
all participating custodians. If all custodians are using a standard
system, one can cross verify that addresses claimed by one custodian aren't
also claimed by another custodian.

Even tho the user is responsible for their keys in order to properly
verify, losing the keys isn't that big of a deal, since they could simply
create a new seed and give a new public key to the custodian - who would
have other identifying information they could use to validate that they own
the account. So it places less responsibility on the user, while still
introducing people, in a light-weight way, to self custody of keys.

Having a record like this every day would reduce the possibility of
shenanigans like taking a short term loan of a large amount of
cryptocurrency. Sure, they could take a 10 minute loan once per day, but it
would also be possible 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 prove balances held on the lightning network, but I suspect
that isn't generally 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.

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

<div dir=3D"ltr">I had the idea recently for <a href=3D"https://niccarter.i=
nfo/proof-of-reserves/">proof of reserves</a> done in a way that can be use=
d to verify reserves are sufficient on an ongoing basis. I&#39;m curious if=
 there are any current approaches out there to proof of reserves that are s=
imilar.=C2=A0<div><br></div><div>The idea is to have users create actual pr=
ivate keys using a seed in pretty 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=C2=A0in a public re=
cord of account balances.=C2=A0</div><div><br></div><div>When a user&#39;s =
account is credited, the custodian would update a map of addresses (created=
 from the public key of each account) to balances - this map could be struc=
tured into a merkle tree in the usual &quot;merkle approach&quot;. The cust=
odian would also store funds on one or more HD wallets (each with many addr=
esses) and create a proof that they own each HD wallet. The proof could be =
as simple as a single signature created with the xpub for the wallet,=C2=A0=
which would be sufficient for proving ownership over the whole list/tree of=
 addresses.=C2=A0</div><div><br></div><div>These two structures (the map an=
d the HD wallet) would be combined and hashed, and the hash published in an=
 on chain transaction (possibly along with a URI where the full data can be=
 found), on something like a daily basis. Software for each user could cont=
inuously validate that their account has a balance that matches what it&#39=
;s supposed to have, and could also verify that owned addresses have funds =
that have at least as many coins as promised to accounts. If these things a=
ren&#39;t verifiable (either because the balances total to more than the HD=
 wallet contains, or because of data unavailability), people can raise hell=
 about it.</div><div><br></div><div>To give user&#39;s additional proving a=
bility, a receipt system could be added. Users could request a receipt for =
any balance update. Eg the user would create a message with a timestamp, th=
eir custodial=C2=A0&quot;address&quot;, and the new balance. 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 user can use this signe=
d receipt to show that the custodian did in fact promise a new updated bala=
nce at a particular=C2=A0time (which would cover the case that the custodia=
n records the wrong value in their map). Conversely, the receipt would be u=
seful to honest custodians as well, since they could show the user&#39;s si=
gned 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 refuse=
s to return a signed receipt, in which case the user&#39;s only recourse is=
 to yell about it immediately and demand a receipt or a refund.=C2=A0</div>=
<div><br></div><div>Why record it on chain? Doing that gives a clear record=
 of proof of reserves that can be verified later by anyone in the future. I=
t prevents a custodian from being able to change history when it suits them=
 (by creating a new records with false timestamps in the past). Many of the=
se records could be aggregated together and recorded in the same transactio=
n (with a single hash), so a single transaction per day could record the re=
cords of all participating custodians. If all custodians are using a standa=
rd system, one can cross verify that addresses claimed by one custodian are=
n&#39;t also claimed by another custodian.</div><div><br></div><div>Even th=
o the user is responsible for their keys in order to properly verify, losin=
g the keys isn&#39;t that big of a deal, since they could simply create a n=
ew seed and give a new public key to the custodian - who would have other i=
dentifying information they could use to validate that they own the account=
. So it places less responsibility on the user, while still introducing peo=
ple, in a light-weight way, to self custody of keys.</div><div><br></div><d=
iv>Having a record like this every day would reduce the possibility of shen=
anigans like taking a short term loan of a large amount of cryptocurrency. =
Sure, they could take a 10 minute loan once per day, but it would also be p=
ossible to trace on-chain transactions so you could tell if such a thing wa=
s going on. I wonder if there would be some way to include the ability to p=
rove balances held on the lightning network, but I suspect that isn&#39;t g=
enerally possible.=C2=A0</div><div><br></div><div>In any case, I&#39;m curi=
ous what people think of this kind of thing, and if systems with similar pr=
operties are already out there.=C2=A0</div><div><br></div><div><br></div><d=
iv><div><br></div><div><br></div></div></div>

--000000000000f0ca5005c6646b17--