📅 Original date posted:2021-07-06
📝 Original message:> 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 at lists.linuxfoundation.org> On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud <billy.tetrud at gmail.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
eric at voskuil.org [ARCHIVE] /
npub1r3…6s8vu
2023-06-07 22:56:42
in reply to nevent1q…haj8
Author Public Key
npub1r34khxrz9w39zpzezymqz04dcel95adfxf6qpjul9wdv2qn5vtps06s8vuPublished at
2023-06-07 22:56:42Event JSON
{
"id": "4a102188894c32ea91680d3d23dcbd46657e11eda82355f6eae0a51c7621e96f",
"pubkey": "1c6b6b98622ba25104591136013eadc67e5a75a9327400cb9f2b9ac5027462c3",
"created_at": 1686178602,
"kind": 1,
"tags": [
[
"e",
"8d7c8e46a21aeccd372e51b6693b44408b64b038bd6112c7f0d1530660522551",
"",
"root"
],
[
"e",
"cf7ae593542267a162f2f617d7687eed15f0ce2f9983bf2c09ebec8be21a73e7",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2021-07-06\n📝 Original message:\u003e you should check out some of the earlier work done here:\n\u003e \n\u003e https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this \n\nNothing here refutes what I have said. Furthermore it relies on the\nassumption that all assets and liabilities are provable. This is clearly\nprohibitive.\n\n\u003e more than enough.\n\nArbitrary and subjective.\n\nA business raises money (investment) so that it can spend more than it\npreviously had. This is net \"insolvency\" until (and assuming) it produces\nand earns over time an amount sufficient to cover its capitalization and\ntime value.\n\nThese sort of schemes are relevant only to what Rothbard calls a money\n\"warehouse\" (a literal vault), which is explicitly not a \"bank\" (banks\nlend). Warehousing Bitcoin is a strange idea to start with. And given that\nthey are so larded with trust and race conditions it's hardly an improvement\nover holding your own keys.\n\ne\n\n\u003e -----Original Message-----\n\u003e From: bitcoin-dev \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e On\n\u003e Behalf Of Erik Aronesty via bitcoin-dev\n\u003e Sent: Tuesday, July 6, 2021 9:40 AM\n\u003e To: Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e; Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] Proof of reserves - recording\n\u003e \n\u003e you should check out some of the earlier work done here:\n\u003e \n\u003e https://github.com/olalonde/proof-of-solvency#assets-proof\n\u003e \n\u003e to be honest, if any exchange supported that proof, it would be more than\n\u003e enough.\n\u003e \n\u003e there's really no way to prevent a smash-and-grab, but this does prevent a\n\u003e slow-leak\n\u003e \n\u003e \n\u003e On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev \u003cbitcoin-\n\u003e dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e I had the idea recently for proof of reserves done in a way that can be\nused\n\u003e to verify reserves are sufficient on an ongoing basis. I'm curious if\nthere are\n\u003e any current approaches out there to proof of reserves that are similar.\n\u003e \u003e\n\u003e \u003e The idea is to have users create actual private keys using a seed in\npretty\n\u003e much the normal way. Users would generate a public key from this seed to\n\u003e represent their account, and would give the public key to the custodian to\n\u003e represent their account in a public record of account balances.\n\u003e \u003e\n\u003e \u003e When a user's account is credited, the custodian would update a map of\n\u003e addresses (created from the public key of each account) to balances - this\n\u003e map could be structured into a merkle tree in the usual \"merkle approach\".\n\u003e The custodian would also store funds on one or more HD wallets (each with\n\u003e many addresses) and create a proof that they own each HD wallet. The proof\n\u003e could be as simple as a single signature created with the xpub for the\nwallet,\n\u003e which would be sufficient for proving ownership over the whole list/tree\nof\n\u003e addresses.\n\u003e \u003e\n\u003e \u003e These two structures (the map and the HD wallet) would be combined and\n\u003e hashed, and the hash published in an on chain transaction (possibly along\n\u003e with a URI where the full data can be found), on something like a daily\nbasis.\n\u003e Software for each user could continuously validate that their account has\na\n\u003e balance that matches what it's supposed to have, and could also verify\nthat\n\u003e owned addresses have funds that have at least as many coins as promised to\n\u003e accounts. If these things aren't verifiable (either because the balances\ntotal\n\u003e to more than the HD wallet contains, or because of data unavailability),\n\u003e people can raise hell about it.\n\u003e \u003e\n\u003e \u003e To give user's additional proving ability, a receipt system could be\nadded.\n\u003e Users could request a receipt for any balance update. Eg the user would\n\u003e create a message with a timestamp, their custodial \"address\", and the new\n\u003e balance. The user would sign this receipt and send it to the custodian,\nwho\n\u003e would also sign it and send it back. This way, if something goes wrong, a\nuser\n\u003e can use this signed receipt to show that the custodian did in fact promise\na\n\u003e new updated balance at a particular time (which would cover the case that\n\u003e the custodian records the wrong value in their map). Conversely, the\nreceipt\n\u003e would be useful to honest custodians as well, since they could show the\n\u003e user's signed receipt request in the case a user is trying to lie about\nwhat\n\u003e balance they should have. There is still the case that the custodian\nsimply\n\u003e refuses to return a signed receipt, in which case the user's only recourse\nis to\n\u003e yell about it immediately and demand a receipt or a refund.\n\u003e \u003e\n\u003e \u003e Why record it on chain? Doing that gives a clear record of proof of\nreserves\n\u003e that can be verified later by anyone in the future. It prevents a\ncustodian\n\u003e from being able to change history when it suits them (by creating a new\n\u003e records with false timestamps in the past). Many of these records could be\n\u003e aggregated together and recorded in the same transaction (with a single\n\u003e hash), so a single transaction per day could record the records of all\n\u003e participating custodians. If all custodians are using a standard system,\none can\n\u003e cross verify that addresses claimed by one custodian aren't also claimed\nby\n\u003e another custodian.\n\u003e \u003e\n\u003e \u003e Even tho the user is responsible for their keys in order to properly\nverify,\n\u003e losing the keys isn't that big of a deal, since they could simply create a\nnew\n\u003e seed and give a new public key to the custodian - who would have other\n\u003e identifying information they could use to validate that they own the\naccount.\n\u003e So it places less responsibility on the user, while still introducing\npeople, in a\n\u003e light-weight way, to self custody of keys.\n\u003e \u003e\n\u003e \u003e Having a record like this every day would reduce the possibility of\n\u003e shenanigans like taking a short term loan of a large amount of\n\u003e cryptocurrency. Sure, they could take a 10 minute loan once per day, but\nit\n\u003e would also be possible to trace on-chain transactions so you could tell if\nsuch\n\u003e a thing was going on. I wonder if there would be some way to include the\n\u003e ability to prove balances held on the lightning network, but I suspect\nthat\n\u003e isn't generally possible.\n\u003e \u003e\n\u003e \u003e In any case, I'm curious what people think of this kind of thing, and if\n\u003e systems with similar properties are already out there.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "850b0a1b4e7a5beb61804c15d52e81bd799b69174701bc9c083b5a6ee471ebadc36696de6121617c923ffab4b8f111692b3fad1d8950d9160f4a12d94f3be586"
}