{"type":"rich","version":"1.0","author_name":"npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","author_url":"https://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-07-05\n📝 Original message:I had the idea recently for proof of reserves\n\u003chttps://niccarter.info/proof-of-reserves/\u003e done in a way that can be used\nto verify reserves are sufficient on an ongoing basis. I'm curious if there\nare any current approaches out there to proof of reserves that are similar.\n\nThe idea is to have users create actual private keys using a seed in pretty\nmuch the normal way. Users would generate a public key from this seed to\nrepresent their account, and would give the public key to the custodian to\nrepresent their account in a public record of account balances.\n\nWhen a user's account is credited, the custodian would update a map of\naddresses (created from the public key of each account) to balances - this\nmap could be structured into a merkle tree in the usual \"merkle approach\".\nThe custodian would also store funds on one or more HD wallets (each with\nmany addresses) and create a proof that they own each HD wallet. The proof\ncould be as simple as a single signature created with the xpub for the\nwallet, which would be sufficient for proving ownership over the whole\nlist/tree of addresses.\n\nThese two structures (the map and the HD wallet) would be combined and\nhashed, and the hash published in an on chain transaction (possibly along\nwith a URI where the full data can be found), on something like a daily\nbasis. Software for each user could continuously validate that their\naccount has a balance that matches what it's supposed to have, and could\nalso verify that owned addresses have funds that have at least as many\ncoins as promised to accounts. If these things aren't verifiable (either\nbecause the balances total to more than the HD wallet contains, or because\nof data unavailability), people can raise hell about it.\n\nTo give user's additional proving ability, a receipt system could be added.\nUsers could request a receipt for any balance update. Eg the user would\ncreate a message with a timestamp, their custodial \"address\", and the new\nbalance. The user would sign this receipt and send it to the custodian, who\nwould also sign it and send it back. This way, if something goes wrong, a\nuser can use this signed receipt to show that the custodian did in fact\npromise a new updated balance at a particular time (which would cover the\ncase that the custodian records the wrong value in their map). Conversely,\nthe receipt would be useful to honest custodians as well, since they could\nshow the user's signed receipt request in the case a user is trying to lie\nabout what balance they should have. There is still the case that the\ncustodian simply refuses to return a signed receipt, in which case the\nuser's only recourse is to yell about it immediately and demand a receipt\nor a refund.\n\nWhy record it on chain? Doing that gives a clear record of proof of\nreserves that can be verified later by anyone in the future. It prevents a\ncustodian from being able to change history when it suits them (by creating\na new records with false timestamps in the past). Many of these records\ncould be aggregated together and recorded in the same transaction (with a\nsingle hash), so a single transaction per day could record the records of\nall participating custodians. If all custodians are using a standard\nsystem, one can cross verify that addresses claimed by one custodian aren't\nalso claimed by another custodian.\n\nEven tho the user is responsible for their keys in order to properly\nverify, losing the keys isn't that big of a deal, since they could simply\ncreate a new seed and give a new public key to the custodian - who would\nhave other identifying information they could use to validate that they own\nthe account. So it places less responsibility on the user, while still\nintroducing people, in a light-weight way, to self custody of keys.\n\nHaving a record like this every day would reduce the possibility of\nshenanigans like taking a short term loan of a large amount of\ncryptocurrency. Sure, they could take a 10 minute loan once per day, but it\nwould also be possible to trace on-chain transactions so you could tell if\nsuch a thing was going on. I wonder if there would be some way to include\nthe ability to prove balances held on the lightning network, but I suspect\nthat isn't generally possible.\n\nIn any case, I'm curious what people think of this kind of thing, and if\nsystems with similar properties are already out there.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210705/fc1967cb/attachment.html\u003e"}