path: root/6a/8cd9d488799de31ce631236f4e82043f7c65a5

Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A98DFC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 18:40:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 980F240111
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 18:40:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, TVD_PH_BODY_ACCOUNTS_PRE=0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JFw8wYXcPmhH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 18:40:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com
 [IPv6:2607:f8b0:4864:20::435])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 48E894010D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 18:40:36 +0000 (UTC)
Received: by mail-pf1-x435.google.com with SMTP id x16so20263442pfa.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 06 Jul 2021 11:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=from:to:references:in-reply-to:subject:date:message-id:mime-version
 :content-transfer-encoding:thread-index:content-language;
 bh=HtUr3cpxegSnlddzVV2zNaXPf28Hof/JGOQfVqRI2ck=;
 b=Nl2k11YgvCqolbJA4LLXm4Ar1KDCy1kmq+gvTbSmFpJnt2wvKiahwnP2WXAJZjoSsV
 tzkdx7q1K8s1/p6d8Y1jTkuX3OGDU/NJQZWNuIU9DsBLfHDfjMM/yDlftEspFx4tO+G5
 CyE+9VezDqm4arWTYdv/uVpx0NX+lo/ST0tk4Rbu+pmXTmUjve0hQIeQl/tSWD1DVZ23
 KXbYCea55wAA5OgYyfYqMQPgeqAs8gmjm20DqU7ZkMrCrpLotM3YCL0ALiE/BrKjO6Fk
 Zwg1ZFy9fkYNifFWX906kINnqW7tSpw4/W7naCuxq4T7OyyX99Z6NFve1B4+7k0HreU7
 1NhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:references:in-reply-to:subject:date
 :message-id:mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=HtUr3cpxegSnlddzVV2zNaXPf28Hof/JGOQfVqRI2ck=;
 b=ub0XYkfn/I3rpiNr8IIgy1hWPPGDrSzT2zNkAnRBB5tfXQtoCd7BTWKH+lM9nYxOH2
 h2guHJm+VuaYl+G42lRUcI4ZWFEYQ3jjQZIpe4DvfqwyUZ+PMv27N0jciGN4kcRnfKnq
 +4Y2hy7pFOaLnRa0y443miuu1aM1KGRSlCtrV2/au7gIjWj2ayRbe/TIuG92nDNHaA+P
 VB+sh6vKTFD0zL07KtaZpgwhdlS2UcGMtvry6/NnM4MAbUCF35t7TGGS2vBgc9+EXmfK
 OmdEssfj1vZnvyOTDI4pe1L4Nb/DQXl6zIVKDQY67XdKoox+iMkT1nepEDfrBT/azrba
 U6/w==
X-Gm-Message-State: AOAM530k859r9Bfvnq5cfJlY0YOwGnxgvVn9QY2lVWqcQ+wm6VEH+ci9
 NtJtSKeXtcl0g1/HwerRwK/tzg==
X-Google-Smtp-Source: ABdhPJwZfrLoK96oTUDg50g9vUIsEQATbnJcNDYwXQJ44BAFudukNmlevLwvv/h0ewXbf/mkND+Fkg==
X-Received: by 2002:a62:8288:0:b029:31a:52f3:27e5 with SMTP id
 w130-20020a6282880000b029031a52f327e5mr19032872pfd.61.1625596835511; 
 Tue, 06 Jul 2021 11:40:35 -0700 (PDT)
Received: from ERICDESKTOP ([2601:600:9c00:1d0::cccf])
 by smtp.gmail.com with ESMTPSA id y8sm3180284pff.29.2021.07.06.11.40.34
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 06 Jul 2021 11:40:35 -0700 (PDT)
From: <eric@voskuil.org>
To: "'Erik Aronesty'" <erik@q32.com>,
 "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>,
 "'Billy Tetrud'" <billy.tetrud@gmail.com>
References: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
 <CAJowKgJEJr=LhYhuQs4zOyskdAwjZT6aEFd-3=rsShLUf7yWJw@mail.gmail.com>
In-Reply-To: <CAJowKgJEJr=LhYhuQs4zOyskdAwjZT6aEFd-3=rsShLUf7yWJw@mail.gmail.com>
Date: Tue, 6 Jul 2021 11:40:35 -0700
Message-ID: <006b01d77296$6898e370$39caaa50$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJUkbj9xZo4yQDfQ0KB6PzJ1Ja4gQGjCHbdqi7txbA=
Content-Language: en-us
Subject: Re: [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: Tue, 06 Jul 2021 18:40:37 -0000

> you should check out some of the earlier work done here:
> 
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this 

Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.

> more than enough.

Arbitrary and subjective.

A business raises money (investment) so that it can spend more than it
previously had. This is net "insolvency" until (and assuming) it produces
and earns over time an amount sufficient to cover its capitalization and
time value.

These sort of schemes are relevant only to what Rothbard calls a money
"warehouse" (a literal vault), which is explicitly not a "bank" (banks
lend). Warehousing Bitcoin is a strange idea to start with. And given that
they are so larded with trust and race conditions it's hardly an improvement
over holding your own keys.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud <billy.tetrud@gmail.com>; Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proof of reserves - recording
> 
> 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
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.
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev