path: root/af/8c422d507f02138b638ee7413161aae3b20835

Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7F98BC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 16:39:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 7812440339
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 16:39:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZXet1hYjc3n2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 16:39:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com
 [IPv6:2607:f8b0:4864:20::636])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 3ABD34032D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 16:39:48 +0000 (UTC)
Received: by mail-pl1-x636.google.com with SMTP id x3so3858089pll.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 06 Jul 2021 09:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=UikOjF3n93wIUH5Yc7lqBzYhVwjE0thE/tAXUPQuYqA=;
 b=sVb0d5TWQfpNxHjaBD6vjX+wkaQkENr/VtSwhfICdeT6cSdb4ezQX0EHYdnXF83owK
 6KQDMBAghiL9sm8MbvKDpff0U1E0eutj2fNz5QzMjP/cnRUkeMupEy2Ofs117izUm7+0
 iNoB/fc9JLHI+YxaHyTPH/iBaeJIFTrLEMr9Oq5xdEXf2H8swZ+0sSPe9yIZ+CATBPaa
 UBmCR0eeYxz+KgtY54GfCCpjRNa/wPlRmRgRxoEP1kPkDSosNzMPXWKVF0zXTRR3JHFm
 rVYQIQwxak7TOXpZZKzEWEzEy3lTlEEOFjNBUx6OvFgIjaL7fZCE5dXp/miCVFXCQYpF
 8xyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:content-transfer-encoding;
 bh=UikOjF3n93wIUH5Yc7lqBzYhVwjE0thE/tAXUPQuYqA=;
 b=S7KSEC/DFb0liu+0GgjdqNsgOJ0FI2CzBd2jVRmUBIuGZcCKFheO+ec+DIRsL4wa75
 sbMLi4WzIP/CVx6FwikBFhJcsQXX//5xs4FIIxfoLW52sdqpCqwGbeojfH8n0Ay9i1vm
 OFTpQ7dQ0D+xgZIsOo7u3g+CAdM2Zs7VHQCRMw/EzQcDNgg4zLpIGKRs/0BnDir1oCJZ
 eK7yV0Ogj5sVO2uM3D4hU6M8fL9uAHUh8oony6W9svlbyz0u4+Fqvnd46O5jFjuzBtoT
 DQ311wtUIlRRJH1irPZMEMOBC17CQkqua927ncRbnpVwXdLLKZW9Dv5pPN6qWAwwxYC6
 /pKw==
X-Gm-Message-State: AOAM530bsoakz+RKaZhTFcSTNGaIwEKnztBld5g4JddYgn6gPJRgvCci
 wg6j4fmp84cEHqhFAFnL5IcFsbelLjjINCvqAJlWPFU=
X-Google-Smtp-Source: ABdhPJzyPtlDk/ZhylsUmCCeo96LfD0EJdMM7jseVUHD1y0PZdsrohzNbFw0SkMvf5mijEhbA4pqUvpgTi3yisML4XI=
X-Received: by 2002:a17:90b:93:: with SMTP id
 bb19mr1340212pjb.139.1625589587559; 
 Tue, 06 Jul 2021 09:39:47 -0700 (PDT)
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
X-Mailman-Approved-At: Tue, 06 Jul 2021 18:23:47 +0000
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 16:39:49 -0000

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