From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A98DFC000E for ; 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 ; 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 ; 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 ; Tue, 6 Jul 2021 18:40:36 +0000 (UTC) Received: by mail-pf1-x435.google.com with SMTP id x16so20263442pfa.13 for ; 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: To: "'Erik Aronesty'" , "'Bitcoin Protocol Discussion'" , "'Billy Tetrud'" References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 On > Behalf Of Erik Aronesty via bitcoin-dev > Sent: Tuesday, July 6, 2021 9:40 AM > To: Billy Tetrud ; Bitcoin Protocol Discussion > > 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 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