From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7F98BC000E for ; 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 ; 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 ; 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 ; Tue, 6 Jul 2021 16:39:48 +0000 (UTC) Received: by mail-pl1-x636.google.com with SMTP id x3so3858089pll.5 for ; 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: In-Reply-To: From: Erik Aronesty Date: Tue, 6 Jul 2021 12:39:36 -0400 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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