* [bitcoin-dev] Proof of reserves - recording
@ 2021-07-05 18:24 Billy Tetrud
2021-07-05 23:26 ` ZmnSCPxj
2021-07-06 16:39 ` Erik Aronesty
0 siblings, 2 replies; 21+ messages in thread
From: Billy Tetrud @ 2021-07-05 18:24 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4351 bytes --]
I had the idea recently for proof of reserves
<https://niccarter.info/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.
[-- Attachment #2: Type: text/html, Size: 4728 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-05 18:24 [bitcoin-dev] Proof of reserves - recording Billy Tetrud
@ 2021-07-05 23:26 ` ZmnSCPxj
2021-07-05 23:32 ` Eric Voskuil
2021-07-06 16:39 ` Erik Aronesty
1 sibling, 1 reply; 21+ messages in thread
From: ZmnSCPxj @ 2021-07-05 23:26 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
Good morning Billy,
> 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.
Thinking about this in terms of economic logic:
Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
One of the participants should provably be the custodian.
* If the counterparty is a true third party, it has no incentive to lie about its money.
* Especially if the counterparty is *another* custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
* If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-05 23:26 ` ZmnSCPxj
@ 2021-07-05 23:32 ` Eric Voskuil
2021-07-06 0:09 ` ZmnSCPxj
0 siblings, 1 reply; 21+ messages in thread
From: Eric Voskuil @ 2021-07-05 23:32 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
If only one could prove that he won’t get into a boating accident.
e
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Good morning Billy,
>
>> 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.
>
> Thinking about this in terms of economic logic:
>
> Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
>
> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
> One of the participants should provably be the custodian.
>
> * If the counterparty is a true third party, it has no incentive to lie about its money.
> * Especially if the counterparty is *another* custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
> It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
> The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
> * If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
>
> Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-05 23:32 ` Eric Voskuil
@ 2021-07-06 0:09 ` ZmnSCPxj
2021-07-06 1:34 ` Billy Tetrud
0 siblings, 1 reply; 21+ messages in thread
From: ZmnSCPxj @ 2021-07-06 0:09 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
Good morning e,
> If only one could prove that he won’t get into a boating accident.
At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive to unilaterally close the channel, which reveals the exact amounts (though not necessarily who owns which).
If the other party then uses its funds in a new proof-of-reserves, then obviously the other output of the unilateral close was the one lost in the boating accident.
On the other hand, yes, custodians losing custodied funds in boating accidents is much too common.
I believe it is one reason why custodian proof-of-reserves is not that popular --- it only proves that the funds were owned under a particular key at some snapshot of the past, it does not prove that the key will not get lost (or "lost and then salvaged by a scuba diver") later.
Regards,
ZmnSCPxj
>
> e
>
> > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > Good morning Billy,
> >
> > > 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.
> >
> > Thinking about this in terms of economic logic:
> > Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
> > The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
> > One of the participants should provably be the custodian.
> >
> > - If the counterparty is a true third party, it has no incentive to lie about its money.
> > - Especially if the counterparty is another custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
> > It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
> > The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
> >
> > - If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
> >
> > Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of all channels.
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 0:09 ` ZmnSCPxj
@ 2021-07-06 1:34 ` Billy Tetrud
2021-07-06 4:54 ` ZmnSCPxj
0 siblings, 1 reply; 21+ messages in thread
From: Billy Tetrud @ 2021-07-06 1:34 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4468 bytes --]
@ ZmnSCPxj, Good Evening
> The two participants in the channel can sign a plaintext containing
their node pubkeys and how much each owns
Sure, but even if both participants in the channel sign a correct statement
of truth, one of the participants can send funds out in the next second,
invalidating that truth. While proof of ownership of on-chain UTXOs can be
seen publicly in real time if they are spent, LN transactions aren't public
like that. So any balance attestation is at best only valid the instant its
taken, and can't be used as verification the money is still owned by the
same channel partner in the next second.
> a custodian Lightning node is unable to "freeze" a snapshot of its
current state and make an atomic proof-of-reserves of *all* channels
That would be a neat trick. But yeah, I don't know how that would be
possible.
> I believe it is one reason why custodian proof-of-reserves is not that
popular ... it does not prove that the key will not get lost
True, but at least if funds do get lost, it would be come clear far
quicker. Today, an insolvent company could go many months without the
public finding out.
On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning e,
>
>
> > If only one could prove that he won’t get into a boating accident.
>
> At least in the context of Lightning channels, if one party in the channel
> loses its key in a boating accident, the other party (assuming it is a true
> separate person and not a sockpuppet) has every incentive to unilaterally
> close the channel, which reveals the exact amounts (though not necessarily
> who owns which).
> If the other party then uses its funds in a new proof-of-reserves, then
> obviously the other output of the unilateral close was the one lost in the
> boating accident.
>
> On the other hand, yes, custodians losing custodied funds in boating
> accidents is much too common.
> I believe it is one reason why custodian proof-of-reserves is not that
> popular --- it only proves that the funds were owned under a particular key
> at some snapshot of the past, it does not prove that the key will not get
> lost (or "lost and then salvaged by a scuba diver") later.
>
>
> Regards,
> ZmnSCPxj
>
> >
> > e
> >
> > > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
> > > Good morning Billy,
> > >
> > > > 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.
> > >
> > > Thinking about this in terms of economic logic:
> > > Every channel is anchored onchain, and that anchor (the funding txout)
> is proof of the existence, and size, of the channel.
> > > The two participants in the channel can sign a plaintext containing
> their node pubkeys and how much each owns.
> > > One of the participants should provably be the custodian.
> > >
> > > - If the counterparty is a true third party, it has no incentive to
> lie about its money.
> > > - Especially if the counterparty is another custodian who wants
> proof-of-reserves, it has every incentive to overreport, but then the first
> party will refuse to sign.
> > > It has a disincentive to underreport, and would itself refuse to
> sign a dishonest report that assigns more funds to the first party.
> > > The only case that would be acceptable to both custodians would be
> to honestly report their holdings in the Lightning channel.
> > >
> > > - If the counterparty is a sockpuppet of the custodian, then the
> entire channel is owned by the custodian and it would be fairly dumb of he
> custodian to claim to have less funds than the entire channel.
> > >
> > > Perhaps a more practical problem is that Lightning channel states
> change fairly quickly, and there are possible race conditions, due to
> network latency (remember, both nodes need to sign, meaning both of them
> need to communicate with each other, thus hit by network latency and other
> race conditions) where a custodian Lightning node is unable to "freeze" a
> snapshot of its current state and make an atomic proof-of-reserves of all
> channels.
> > > Regards,
> > > ZmnSCPxj
> > >
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 5388 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 1:34 ` Billy Tetrud
@ 2021-07-06 4:54 ` ZmnSCPxj
2021-07-06 5:09 ` Eric Voskuil
0 siblings, 1 reply; 21+ messages in thread
From: ZmnSCPxj @ 2021-07-06 4:54 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
Good morning Billy,
>
> > The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns
>
> Sure, but even if both participants in the channel sign a correct statement of truth, one of the participants can send funds out in the next second, invalidating that truth. While proof of ownership of on-chain UTXOs can be seen publicly in real time if they are spent, LN transactions aren't public like that. So any balance attestation is at best only valid the instant its taken, and can't be used as verification the money is still owned by the same channel partner in the next second.
The same problem really also exists onchain --- a thief (or "thief") who has gotten a copy of the key can sign a transaction that spends it, one second after the proof-of-reserves is made.
Really, though, the issue is that ownership of funds is conditional on *knowledge* of keys.
And *knowledge* is easily copyable.
Thus, it is possible that the funds that are "proven" to be the reserve of a custodian is actually *also* owned by someone else who has gotten to the privkeys (e.g. somebody threw a copy of it from a boating accident and a fearless scuba diver rescued it), and thus can also move the funds outside of the control of the custodian.
This condition can remain for many months or years, as well, without knowledge of the custodian clients, *or* of the custodian itself.
There is no way to prove that there is no alternate copy of the privkeys, hence "if only one could prove that he won't get into a boating accident".
On the other hand, one could argue that at least the onchain proof requires more conditions to occur, so we might plausibly live with "we cannot prove we will never get into a boating accident but we can show evidence that we live in a landlocked city far from any lakes, seas, or rivers".
Regards,
ZmnSCPxj
>
> > a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels
>
> That would be a neat trick. But yeah, I don't know how that would be possible.
>
> > I believe it is one reason why custodian proof-of-reserves is not that popular ... it does not prove that the key will not get lost
>
> True, but at least if funds do get lost, it would be come clear far quicker. Today, an insolvent company could go many months without the public finding out.
>
> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > Good morning e,
> >
> > > If only one could prove that he won’t get into a boating accident.
> >
> > At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive to unilaterally close the channel, which reveals the exact amounts (though not necessarily who owns which).
> > If the other party then uses its funds in a new proof-of-reserves, then obviously the other output of the unilateral close was the one lost in the boating accident.
> >
> > On the other hand, yes, custodians losing custodied funds in boating accidents is much too common.
> > I believe it is one reason why custodian proof-of-reserves is not that popular --- it only proves that the funds were owned under a particular key at some snapshot of the past, it does not prove that the key will not get lost (or "lost and then salvaged by a scuba diver") later.
> >
> > Regards,
> > ZmnSCPxj
> >
> > >
> > > e
> > >
> > > > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > Good morning Billy,
> > > >
> > > > > 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.
> > > >
> > > > Thinking about this in terms of economic logic:
> > > > Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
> > > > The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
> > > > One of the participants should provably be the custodian.
> > > >
> > > > - If the counterparty is a true third party, it has no incentive to lie about its money.
> > > > - Especially if the counterparty is another custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
> > > > It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
> > > > The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
> > > >
> > > > - If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
> > > >
> > > > Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of all channels.
> > > > Regards,
> > > > ZmnSCPxj
> > > >
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 4:54 ` ZmnSCPxj
@ 2021-07-06 5:09 ` Eric Voskuil
2021-07-06 6:02 ` Billy Tetrud
0 siblings, 1 reply; 21+ messages in thread
From: Eric Voskuil @ 2021-07-06 5:09 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
[-- Attachment #1: Type: text/plain, Size: 5910 bytes --]
https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Billy,
>
>
>>
>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns
>>
>> Sure, but even if both participants in the channel sign a correct statement of truth, one of the participants can send funds out in the next second, invalidating that truth. While proof of ownership of on-chain UTXOs can be seen publicly in real time if they are spent, LN transactions aren't public like that. So any balance attestation is at best only valid the instant its taken, and can't be used as verification the money is still owned by the same channel partner in the next second.
>
> The same problem really also exists onchain --- a thief (or "thief") who has gotten a copy of the key can sign a transaction that spends it, one second after the proof-of-reserves is made.
>
> Really, though, the issue is that ownership of funds is conditional on *knowledge* of keys.
> And *knowledge* is easily copyable.
>
> Thus, it is possible that the funds that are "proven" to be the reserve of a custodian is actually *also* owned by someone else who has gotten to the privkeys (e.g. somebody threw a copy of it from a boating accident and a fearless scuba diver rescued it), and thus can also move the funds outside of the control of the custodian.
> This condition can remain for many months or years, as well, without knowledge of the custodian clients, *or* of the custodian itself.
>
> There is no way to prove that there is no alternate copy of the privkeys, hence "if only one could prove that he won't get into a boating accident".
>
> On the other hand, one could argue that at least the onchain proof requires more conditions to occur, so we might plausibly live with "we cannot prove we will never get into a boating accident but we can show evidence that we live in a landlocked city far from any lakes, seas, or rivers".
>
> Regards,
> ZmnSCPxj
>
>>
>>> a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels
>>
>> That would be a neat trick. But yeah, I don't know how that would be possible.
>>
>>> I believe it is one reason why custodian proof-of-reserves is not that popular ... it does not prove that the key will not get lost
>>
>> True, but at least if funds do get lost, it would be come clear far quicker. Today, an insolvent company could go many months without the public finding out.
>>
>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>
>>> Good morning e,
>>>
>>>> If only one could prove that he won’t get into a boating accident.
>>>
>>> At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive to unilaterally close the channel, which reveals the exact amounts (though not necessarily who owns which).
>>> If the other party then uses its funds in a new proof-of-reserves, then obviously the other output of the unilateral close was the one lost in the boating accident.
>>>
>>> On the other hand, yes, custodians losing custodied funds in boating accidents is much too common.
>>> I believe it is one reason why custodian proof-of-reserves is not that popular --- it only proves that the funds were owned under a particular key at some snapshot of the past, it does not prove that the key will not get lost (or "lost and then salvaged by a scuba diver") later.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>>>
>>>> e
>>>>
>>>>> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>>>>> Good morning Billy,
>>>>>
>>>>>> 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.
>>>>>
>>>>> Thinking about this in terms of economic logic:
>>>>> Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
>>>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
>>>>> One of the participants should provably be the custodian.
>>>>>
>>>>> - If the counterparty is a true third party, it has no incentive to lie about its money.
>>>>> - Especially if the counterparty is another custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
>>>>> It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
>>>>> The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
>>>>>
>>>>> - If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
>>>>>
>>>>> Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of all channels.
>>>>> Regards,
>>>>> ZmnSCPxj
>>>>>
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 12778 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 5:09 ` Eric Voskuil
@ 2021-07-06 6:02 ` Billy Tetrud
2021-07-06 7:37 ` Eric Voskuil
0 siblings, 1 reply; 21+ messages in thread
From: Billy Tetrud @ 2021-07-06 6:02 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 10351 bytes --]
@ZmnSCPxj
> a thief (or "thief") who has gotten a copy of the key can sign a
transaction that spends it, one second after the proof-of-reserves is made.
Sure, but anyone can easily see that transaction happen and can discount
that part of the attestation. The same isn't true on lightning.
> *knowledge* is easily copyable.
Knowledge isn't even really needed. Custodians could collude to sign each
other's balance attestations. However, if the network of proof of reserves
is cohesive, people could validate that addresses (and their balances)
aren't shared by anyone that's part of that PoR network.
> There is no way to prove that there is no alternate copy of the privkeys
Well there are only really 2 cases:
1. Only one entity has the keys
2. Two entities have the keys and trust each other
In case 1, the attestation is accurate. In case 2, its really another way
of saying case 1: you can view the two trusting entities as a single
entity. In the case there are 2 non-trusting entities, its very likely that
one would steal from the other, or that they would be very uncomfortable
with the situation such that it wouldn't last long.
But you can't prove that someone won't steal the reserves. You can't prove
cryptographically that the reserves aren't promised to someone else in a
legal contract (unless of course you make the proof of reserves system
legally binding). But this is why anyone that recommends PoR also
recommends independent audits to attest that the PoR actually matches
reality.
So yes, there are limitations, but I don't think that means that PoR isn't
worth doing. Is that what you're implying?
> we can show evidence that we live in a landlocked city far from any
lakes, seas, or rivers
I think that's the idea, if I understand you correctly.
@Eric
Auditability Fallacy
<https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy>
> A solvency audit requires simultaneous (atomic) proof of both the full
amount of the asset held by a custodian and the securities issued against
it.
> in the case where the security is issued on a distinct public chain the
atomicity requirement is not satisfied.
I think what its saying is that you can't get atomicity of both the
security and the reserve. While this is true, what you can get is a system
where the order of events can be established to a degree of precision. Ie,
you can know that between reserve-snapshot A and B, the balances add up to
X. Each user can validate that their balance was indeed that value between
A and B. With reserve snapshots and balance snapshots frequent enough, this
can allow reasonably high accuracy of estimated solvency. However, it does
seem clear that perfect accuracy is not possible.
> Historically it has not been difficult to detect such deviations. The
difficulty arises in stopping them.
I disagree here that it has not been difficult to detect deviations
(insolvency). I mean, "difficulty" isn't the right word. These things
always become clear eventually. But I think its important to detect
insolvency quickly. Historically insolvency has certainly not been detected
quickly. Insolvency is instead practically perpetual, and the question is
only how insolvent and when will it explode?
I'm of the opinion that you can't prevent insolvency. Places will have
money troubles and will try to cover it up, since usually there is no
downside (admitting insolvency can lead to bankrupcy, and failure to
conceal insolvency has the same result - so why not try to conceal it and
hope you can shore it up). However, its important that people know the
institutions they have their money in are insolvent, or to what degree they
are. If that information were well tracked, it could become clear over time
that a 10% insolvent company rarely goes out of business, but a 20%
insolvent company usually does. Then people can have parameters where
they're ok with a certain measurable degree of insolvency, but react
swiftly and strongly when a company is too reckless. Currently the amount
of recklessness any given company engages in is basically a company secret
that their clients don't have insight into. PoR would greatly help this I
think. You don't think so?
On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil <eric@voskuil.org> wrote:
> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>
> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Billy,
>
>
>
> The two participants in the channel can sign a plaintext containing
> their node pubkeys and how much each owns
>
>
> Sure, but even if both participants in the channel sign a correct
> statement of truth, one of the participants can send funds out in the next
> second, invalidating that truth. While proof of ownership of on-chain UTXOs
> can be seen publicly in real time if they are spent, LN transactions aren't
> public like that. So any balance attestation is at best only valid the
> instant its taken, and can't be used as verification the money is still
> owned by the same channel partner in the next second.
>
>
> The same problem really also exists onchain --- a thief (or "thief") who
> has gotten a copy of the key can sign a transaction that spends it, one
> second after the proof-of-reserves is made.
>
> Really, though, the issue is that ownership of funds is conditional on
> *knowledge* of keys.
> And *knowledge* is easily copyable.
>
> Thus, it is possible that the funds that are "proven" to be the reserve of
> a custodian is actually *also* owned by someone else who has gotten to the
> privkeys (e.g. somebody threw a copy of it from a boating accident and a
> fearless scuba diver rescued it), and thus can also move the funds outside
> of the control of the custodian.
> This condition can remain for many months or years, as well, without
> knowledge of the custodian clients, *or* of the custodian itself.
>
> There is no way to prove that there is no alternate copy of the privkeys,
> hence "if only one could prove that he won't get into a boating accident".
>
> On the other hand, one could argue that at least the onchain proof
> requires more conditions to occur, so we might plausibly live with "we
> cannot prove we will never get into a boating accident but we can show
> evidence that we live in a landlocked city far from any lakes, seas, or
> rivers".
>
> Regards,
> ZmnSCPxj
>
>
> a custodian Lightning node is unable to "freeze" a snapshot of its
> current state and make an atomic proof-of-reserves of *all* channels
>
>
> That would be a neat trick. But yeah, I don't know how that would be
> possible.
>
>
> I believe it is one reason why custodian proof-of-reserves is not that
> popular ... it does not prove that the key will not get lost
>
>
> True, but at least if funds do get lost, it would be come clear far
> quicker. Today, an insolvent company could go many months without the
> public finding out.
>
>
> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>
> Good morning e,
>
>
> If only one could prove that he won’t get into a boating accident.
>
>
> At least in the context of Lightning channels, if one party in the channel
> loses its key in a boating accident, the other party (assuming it is a true
> separate person and not a sockpuppet) has every incentive to unilaterally
> close the channel, which reveals the exact amounts (though not necessarily
> who owns which).
>
> If the other party then uses its funds in a new proof-of-reserves, then
> obviously the other output of the unilateral close was the one lost in the
> boating accident.
>
>
> On the other hand, yes, custodians losing custodied funds in boating
> accidents is much too common.
>
> I believe it is one reason why custodian proof-of-reserves is not that
> popular --- it only proves that the funds were owned under a particular key
> at some snapshot of the past, it does not prove that the key will not get
> lost (or "lost and then salvaged by a scuba diver") later.
>
>
> Regards,
>
> ZmnSCPxj
>
>
>
> e
>
>
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> Good morning Billy,
>
>
> 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.
>
>
> Thinking about this in terms of economic logic:
>
> Every channel is anchored onchain, and that anchor (the funding txout) is
> proof of the existence, and size, of the channel.
>
> The two participants in the channel can sign a plaintext containing their
> node pubkeys and how much each owns.
>
> One of the participants should provably be the custodian.
>
>
> - If the counterparty is a true third party, it has no incentive to lie
> about its money.
>
> - Especially if the counterparty is another custodian who wants
> proof-of-reserves, it has every incentive to overreport, but then the first
> party will refuse to sign.
>
> It has a disincentive to underreport, and would itself refuse to sign
> a dishonest report that assigns more funds to the first party.
>
> The only case that would be acceptable to both custodians would be to
> honestly report their holdings in the Lightning channel.
>
>
> - If the counterparty is a sockpuppet of the custodian, then the entire
> channel is owned by the custodian and it would be fairly dumb of he
> custodian to claim to have less funds than the entire channel.
>
>
> Perhaps a more practical problem is that Lightning channel states change
> fairly quickly, and there are possible race conditions, due to network
> latency (remember, both nodes need to sign, meaning both of them need to
> communicate with each other, thus hit by network latency and other race
> conditions) where a custodian Lightning node is unable to "freeze" a
> snapshot of its current state and make an atomic proof-of-reserves of all
> channels.
>
> Regards,
>
> ZmnSCPxj
>
>
> bitcoin-dev mailing list
>
> bitcoin-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 18254 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 6:02 ` Billy Tetrud
@ 2021-07-06 7:37 ` Eric Voskuil
0 siblings, 0 replies; 21+ messages in thread
From: Eric Voskuil @ 2021-07-06 7:37 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9324 bytes --]
> @Eric
> Auditability Fallacy
>
> > A solvency audit requires simultaneous (atomic) proof of both the full amount of the asset held by a custodian and the securities issued against it.
>
> > in the case where the security is issued on a distinct public chain the atomicity requirement is not satisfied.
>
> I think what its saying is that you can't get atomicity of both the security and the reserve. While this is true, what you can get is a system where the order of events can be established to a degree of precision. Ie, you can know that between reserve-snapshot A and B, the balances add up to X. Each user can validate that their balance was indeed that value between A and B. With reserve snapshots and balance snapshots frequent enough, this can allow reasonably high accuracy of estimated solvency. However, it does seem clear that perfect accuracy is not possible.
If perfect is not possible, it’s not possible. It reduces to trust, which is the status quo.
All “users” need to simultaneously share their individual and temporary audits with each other (ie publicly).
> > Historically it has not been difficult to detect such deviations. The difficulty arises in stopping them.
>
> I disagree here that it has not been difficult to detect deviations (insolvency).
It is not hard to spot price inflation. Stopping or avoiding it is the actual issue. No “proof” of reserve can do this. The federal reserve was clearly insolvent from its early days, as that was its purpose.
> I mean, "difficulty" isn't the right word. These things always become clear eventually. But I think its important to detect insolvency quickly. Historically insolvency has certainly not been detected quickly. Insolvency is instead practically perpetual, and the question is only how insolvent and when will it explode?
There is no “proof” that answers this question.
> I'm of the opinion that you can't prevent insolvency.
It’s not a matter of opinion. Lending implies risk. When you invest you are in fact the owner of the insolvency, not someone else.
> Places will have money troubles and will try to cover it up, since usually there is no downside (admitting insolvency can lead to bankrupcy, and failure to conceal insolvency has the same result - so why not try to conceal it and hope you can shore it up). However, its important that people know the institutions they have their money in are insolvent, or to what degree they are. If that information were well tracked, it could become clear over time that a 10% insolvent company rarely goes out of business, but a 20% insolvent company usually does.
Nonsense, any business can fail, regardless of temporal cash reserves.
> Then people can have parameters where they're ok with a certain measurable degree of insolvency, but react swiftly and strongly when a company is too reckless. Currently the amount of recklessness any given company engages in is basically a company secret that their clients don't have insight into. PoR would greatly help this I think. You don't think so?
Reckless is a subjective term. Proofs will not insure any investment.
e
>> On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil <eric@voskuil.org> wrote:
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>>
>>>> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>>>
>>> Good morning Billy,
>>>
>>>
>>>>
>>>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns
>>>>
>>>> Sure, but even if both participants in the channel sign a correct statement of truth, one of the participants can send funds out in the next second, invalidating that truth. While proof of ownership of on-chain UTXOs can be seen publicly in real time if they are spent, LN transactions aren't public like that. So any balance attestation is at best only valid the instant its taken, and can't be used as verification the money is still owned by the same channel partner in the next second.
>>>
>>> The same problem really also exists onchain --- a thief (or "thief") who has gotten a copy of the key can sign a transaction that spends it, one second after the proof-of-reserves is made.
>>>
>>> Really, though, the issue is that ownership of funds is conditional on *knowledge* of keys.
>>> And *knowledge* is easily copyable.
>>>
>>> Thus, it is possible that the funds that are "proven" to be the reserve of a custodian is actually *also* owned by someone else who has gotten to the privkeys (e.g. somebody threw a copy of it from a boating accident and a fearless scuba diver rescued it), and thus can also move the funds outside of the control of the custodian.
>>> This condition can remain for many months or years, as well, without knowledge of the custodian clients, *or* of the custodian itself.
>>>
>>> There is no way to prove that there is no alternate copy of the privkeys, hence "if only one could prove that he won't get into a boating accident".
>>>
>>> On the other hand, one could argue that at least the onchain proof requires more conditions to occur, so we might plausibly live with "we cannot prove we will never get into a boating accident but we can show evidence that we live in a landlocked city far from any lakes, seas, or rivers".
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>>>
>>>>> a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels
>>>>
>>>> That would be a neat trick. But yeah, I don't know how that would be possible.
>>>>
>>>>> I believe it is one reason why custodian proof-of-reserves is not that popular ... it does not prove that the key will not get lost
>>>>
>>>> True, but at least if funds do get lost, it would be come clear far quicker. Today, an insolvent company could go many months without the public finding out.
>>>>
>>>>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>>>>
>>>>> Good morning e,
>>>>>
>>>>>> If only one could prove that he won’t get into a boating accident.
>>>>>
>>>>> At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive to unilaterally close the channel, which reveals the exact amounts (though not necessarily who owns which).
>>>>> If the other party then uses its funds in a new proof-of-reserves, then obviously the other output of the unilateral close was the one lost in the boating accident.
>>>>>
>>>>> On the other hand, yes, custodians losing custodied funds in boating accidents is much too common.
>>>>> I believe it is one reason why custodian proof-of-reserves is not that popular --- it only proves that the funds were owned under a particular key at some snapshot of the past, it does not prove that the key will not get lost (or "lost and then salvaged by a scuba diver") later.
>>>>>
>>>>> Regards,
>>>>> ZmnSCPxj
>>>>>
>>>>>>
>>>>>> e
>>>>>>
>>>>>>> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>>>>>>> Good morning Billy,
>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> Thinking about this in terms of economic logic:
>>>>>>> Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
>>>>>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
>>>>>>> One of the participants should provably be the custodian.
>>>>>>>
>>>>>>> - If the counterparty is a true third party, it has no incentive to lie about its money.
>>>>>>> - Especially if the counterparty is another custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
>>>>>>> It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
>>>>>>> The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
>>>>>>>
>>>>>>> - If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
>>>>>>>
>>>>>>> Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of all channels.
>>>>>>> Regards,
>>>>>>> ZmnSCPxj
>>>>>>>
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
[-- Attachment #2: Type: text/html, Size: 17702 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-05 18:24 [bitcoin-dev] Proof of reserves - recording Billy Tetrud
2021-07-05 23:26 ` ZmnSCPxj
@ 2021-07-06 16:39 ` Erik Aronesty
2021-07-06 18:40 ` eric
2021-07-07 6:18 ` Billy Tetrud
1 sibling, 2 replies; 21+ messages in thread
From: Erik Aronesty @ 2021-07-06 16:39 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
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 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 16:39 ` Erik Aronesty
@ 2021-07-06 18:40 ` eric
2021-07-07 6:18 ` Billy Tetrud
1 sibling, 0 replies; 21+ messages in thread
From: eric @ 2021-07-06 18:40 UTC (permalink / raw)
To: 'Erik Aronesty', 'Bitcoin Protocol Discussion',
'Billy Tetrud'
> 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@lists.linuxfoundation.org> On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud <billy.tetrud@gmail.com>; Bitcoin Protocol Discussion
> <bitcoin-dev@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@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-06 16:39 ` Erik Aronesty
2021-07-06 18:40 ` eric
@ 2021-07-07 6:18 ` Billy Tetrud
2021-07-09 14:55 ` Eric Voskuil
1 sibling, 1 reply; 21+ messages in thread
From: Billy Tetrud @ 2021-07-07 6:18 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9630 bytes --]
I wanted to relay an interesting related link that Melvin PMed me:
https://petertodd.org/2016/commitments-and-single-use-seals
@Aronesty
Thanks, that system looks interesting, I'll have a closer look!
@Voskuil
I think we must disagree on at least one fundamental point. I'm finding
myself disagreeing with most of what you're saying.
> If perfect is not possible, it’s not possible. It reduces to trust, which
is the status quo.
Let not perfect be the enemy of good. Trust cannot be eliminated.
Perfection cannot be achieved. However trust can be reduced further than it
exists today, and we can clearly make things better than they are now. Are
you really saying that if its not perfect, its worthless?
> All “users” need to simultaneously share their individual and temporary
audits with each other (ie publicly).
This is not the case. In both the mechanism I briefly described and Peter
Todd's mechanism from Melvin's link (top of this message), users need not
share any information with other users unless that information is "my
balance doesn't match the record". It doesn't even need to be in a timely
manner if these records are committed to the blockchain - one could
theoretically look back years and compare their personal records to the
records published by the custodian, and then tell the community about it if
they don't match. All that is required is that a critical mass of users
verify their balance (ideally using software that regularly checks
automatically).
> It is not hard to spot price inflation
I don't know why you think that's the case. Inflation is today vehemently
argued about. Are high real estate prices indications of inflation? What
about recovering stock prices? Is inflation temporary or will we expect it
to last more long term? If one company is inflating perceived supply, this
would almost certainly not show up as significant economy-wide inflation.
And if the majority of companies are doing it, how can you stop it if you
don't have any idea which ones are doing it? I do think spotting the
inflation in any kind of timely manner is indeed hard.
> Stopping or avoiding it is the actual issue. No “proof” of reserve can do
this.
I of course agree that proof of reserves cannot stop inflation/insolvency.
I disagree with the idea that this is the "actual" issue - which seems to
imply to me that its the only issue that matters. Even if we can't stop a
company from promising more coins than they have in reserves, we can limit
how long these events happen for - and how big these bubbles can get. Don't
you agree that would be very helpful, if it were it possible (which it
seems you think it isn't)?
> The federal reserve was clearly insolvent from its early days, as that
was its purpose.
Do you have a source as evidence that it was widely understood that the Fed
was insolvent from its early days? I really don't think it was seen as the
purpose by the vast majority of people in the US. People were lead to
believe every dollar was backed by a unique chunk of gold. Had it been
possible to do a kind of proof of reserves (or estimate of reserves) as
we're talking about, it would have been clear much earlier that the Fed was
doing a lot of shinanigans. I think that would have been very useful
information for the public back then. Perhaps they wouldn't have been able
to do anything about the Fed (or maybe they would have). But people can
certainly pull their money out of companies that can't show solvency.
> Nonsense, any business can fail, regardless of temporal cash reserves.
I agree that any business can fail. But a bank that pretends it can serve
cash on demand is not a normal business, and cash reserves absolutely
relate to their ability to survive as a bank. Its honestly confusing to me
how you could think otherwise. Also, calling my thoughts "nonsense" is
rude, please check yourself, Eric.
> it's hardly an improvement over holding your own keys.
No one is claiming that proof of reserves is "an improvement" over holding
your own keys. Clearly holding your own keys is ideal. However, not
everyone is comfortable with that. The fact of the matter is that many will
choose a custodial wallet, for better or worse. PoR attempts to make thing
on the "better" side than the "worse" side.
On Tue, Jul 6, 2021 at 9:39 AM Erik Aronesty <erik@q32.com> wrote:
> 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
> 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
>
[-- Attachment #2: Type: text/html, Size: 11268 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-07 6:18 ` Billy Tetrud
@ 2021-07-09 14:55 ` Eric Voskuil
2021-07-09 17:43 ` Billy Tetrud
0 siblings, 1 reply; 21+ messages in thread
From: Eric Voskuil @ 2021-07-09 14:55 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
> On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> But people can certainly pull their money out of companies that can't show solvency.
As I pointed out previously there is an unsupportable leap being made here between a vault (money warehouse) and any company (including a bank).
A company cannot possibly show that it has all of the money that every person has invested into it. At times a solvent company may even have zero cash. It is also not possible for a company provide cryptographic proof of its many necessarily non-crypto assets and liabilities. What is presumed here is a community-verified sort of crypto balance sheet, with no considerations of risk - a central aspect of business.
As I said, if you want a vault, you can just use your own wallet. Solvency does not in any way imply 100% cash balance of the amounts invested. Raising money under such terms is pointless for both company and investors (the owners of the company).
> > Nonsense, any business can fail, regardless of temporal cash reserves.
>
> I agree that any business can fail. But a bank that pretends it can serve cash on demand is not a normal business,
Banks (lending institutions) do not operate under any such pretense. US banks require 7 day time deposits for all interest bearing accounts (read your depositor agreement), and it should be clear that your uninsured balance is at risk. Banks are investment funds, not money warehouses (in Rothbard’s terminology).
With a 100% of investment cash hoard, there is zero lending and zero return. This is true for all business.
> and cash reserves absolutely relate to their ability to survive as a bank.
“relate to” is a far cry from 100% “reserve”. At 100% reserve an investment fund would most certainly fail. At 20% it would fail. Money markets (banks without a reserve requirement) don’t break the buck, compete effectively with banks with reserve requirements (required by the taxpayer who is insuring deposits and providing discount credit), and maintain around 10% reserve. This is consistent with a world of people with time preference that creates around a 10% interest rate (return on investment).
> Its honestly confusing to me how you could think otherwise.
It’s confusing to me how anyone would put money into a business and expect (even want) it to sit there.
> Also, calling my thoughts "nonsense" is rude, please check yourself, Eric.
Check myself? Nonsense is English for “doesn’t make sense”. It’s not an insult.
e
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-09 14:55 ` Eric Voskuil
@ 2021-07-09 17:43 ` Billy Tetrud
2021-07-09 18:32 ` Eric Voskuil
0 siblings, 1 reply; 21+ messages in thread
From: Billy Tetrud @ 2021-07-09 17:43 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]
> there is an unsupportable leap being made here
You think that because you're misinterpreting me. I'm in no way claiming
that any solvent company can prove it, I'm simply claiming that any company
can prove that they have bitcoin reserves to cover bitcoins promised as
account balances.
> Banks (lending institutions) do not operate under any such pretense
You seem to be saying that banks are under no legal obligation to serve
cash on demand to customers. While you might be right, again you're
misinterpreting me. Banks do in fact make claims to their customers that
they'll be able to get cash out of their account on demand. They're called
demand deposit accounts for a reason. And certainly customers expect to be
able to withdraw their cash on demand.
> With a 100% of investment cash hoard, there is zero lending and zero
return
I did say "pretend" did I not?
> “relate to” is a far cry from 100% “reserve”
Indeed. Again, you seem to be misunderstanding me. You're putting the words
"100% reserve" in my mouth, when I never said any such thing. Proof of
80%/50%/20% reserves is still useful if that's the clear expectation for
the customer/client.
> Nonsense is English for “doesn’t make sense”
Literally, sure. But in actual use it carries a dismissive and rude
connotation.
On Fri, Jul 9, 2021 at 7:55 AM Eric Voskuil <eric@voskuil.org> wrote:
>
> > On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > But people can certainly pull their money out of companies that can't
> show solvency.
>
> As I pointed out previously there is an unsupportable leap being made here
> between a vault (money warehouse) and any company (including a bank).
>
> A company cannot possibly show that it has all of the money that every
> person has invested into it. At times a solvent company may even have zero
> cash. It is also not possible for a company provide cryptographic proof of
> its many necessarily non-crypto assets and liabilities. What is presumed
> here is a community-verified sort of crypto balance sheet, with no
> considerations of risk - a central aspect of business.
>
> As I said, if you want a vault, you can just use your own wallet. Solvency
> does not in any way imply 100% cash balance of the amounts invested.
> Raising money under such terms is pointless for both company and investors
> (the owners of the company).
>
> > > Nonsense, any business can fail, regardless of temporal cash reserves.
> >
> > I agree that any business can fail. But a bank that pretends it can
> serve cash on demand is not a normal business,
>
> Banks (lending institutions) do not operate under any such pretense. US
> banks require 7 day time deposits for all interest bearing accounts (read
> your depositor agreement), and it should be clear that your uninsured
> balance is at risk. Banks are investment funds, not money warehouses (in
> Rothbard’s terminology).
>
> With a 100% of investment cash hoard, there is zero lending and zero
> return. This is true for all business.
>
> > and cash reserves absolutely relate to their ability to survive as a
> bank.
>
> “relate to” is a far cry from 100% “reserve”. At 100% reserve an
> investment fund would most certainly fail. At 20% it would fail. Money
> markets (banks without a reserve requirement) don’t break the buck, compete
> effectively with banks with reserve requirements (required by the taxpayer
> who is insuring deposits and providing discount credit), and maintain
> around 10% reserve. This is consistent with a world of people with time
> preference that creates around a 10% interest rate (return on investment).
>
> > Its honestly confusing to me how you could think otherwise.
>
> It’s confusing to me how anyone would put money into a business and expect
> (even want) it to sit there.
>
> > Also, calling my thoughts "nonsense" is rude, please check yourself,
> Eric.
>
> Check myself? Nonsense is English for “doesn’t make sense”. It’s not an
> insult.
>
> e
[-- Attachment #2: Type: text/html, Size: 4805 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-09 17:43 ` Billy Tetrud
@ 2021-07-09 18:32 ` Eric Voskuil
2021-07-09 22:02 ` Billy Tetrud
0 siblings, 1 reply; 21+ messages in thread
From: Eric Voskuil @ 2021-07-09 18:32 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
> On Jul 9, 2021, at 10:44, Billy Tetrud <billy.tetrud@gmail.com> wrote:
>
> > there is an unsupportable leap being made here
>
> You think that because you're misinterpreting me. I'm in no way claiming that any solvent company can prove it, I'm simply claiming that any company can prove that they have bitcoin reserves to cover bitcoins promised as account balances.
You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
> > Banks (lending institutions) do not operate under any such pretense
>
> You seem to be saying that banks are under no legal obligation to serve cash on demand to customers. While you might be right,
I am, as banks are lending institutions.
> again you're misinterpreting me. Banks do in fact make claims to their customers that they'll be able to get cash out of their account on demand.
Up to the insured limit, in 7 days. This is of course true because the taxpayer has insured the bank to that level.
> They're called demand deposit accounts for a reason.
They are time deposits, read your bank agreement. Not that it makes any difference. How the contract is satisfied is not a term of the contract, just that it is. And as I pointed out, money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
> And certainly customers expect to be able to withdraw their cash on demand.
Irrelevant.
> > With a 100% of investment cash hoard, there is zero lending and zero return
>
> I did say "pretend" did I not?
See above.
> > “relate to” is a far cry from 100% “reserve”
>
> Indeed. Again, you seem to be misunderstanding me. You're putting the words "100% reserve" in my mouth, when I never said any such thing. Proof of 80%/50%/20% reserves is still useful if that's the clear expectation for the customer/client.
Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”. And even with that, investors would have to accept the promise that there are no other liabilities.
The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve.
It’s information, sure, but it’s not what people seem to think. If one wants full reserve banking, use a wallet. If one wants to invest, the money will be spent - that’s why it was raised. There can be no covenant placed on it that will ensure it’s return.
e
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-09 18:32 ` Eric Voskuil
@ 2021-07-09 22:02 ` Billy Tetrud
2021-07-09 23:18 ` Eric Voskuil
0 siblings, 1 reply; 21+ messages in thread
From: Billy Tetrud @ 2021-07-09 22:02 UTC (permalink / raw)
To: Eric Voskuil, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5902 bytes --]
@Voskuil
> You can prove that in your own wallet. All other scenarios imply lending
(which is what is implied by “reserve”) and lending cannot be 100% reserve.
You're using terms in non-standard ways. Putting money into a bank is not
considered "lending" to the bank. You may make a case that you're lending
to a bank, and that they legally owe you repayment of that money on demand
limited by the terms you mentioned. But regardless of a case that can be
made there, pretty much no one considers that "lending". Since you you like
defining things legally, depositing money in a bank is legally not defined
as lending to the bank.
So no, all other scenarios do not imply lending. You can have your coins in
custody with someone else, and that someone else can keep 100% reserves if
they choose (or agreed to) and can prove it to you via the method I
described or the methods others have linked to.
> They are time deposits, read your bank agreement.
You are not correct
<https://www.investopedia.com/terms/t/timedeposit.asp#:~:text=A%20time%20deposit%20is%20an,pre%2Dset%20date%20of%20maturity.&text=Time%20deposits%20generally%20pay%20a,of%20investment%20is%20term%20deposit.>.
Another source
<https://www.slsp.sk/en/personal/faq/what-is-the-difference-between-a-term-deposit-and-savings-account>
if you don't believe me. The only way you would be correct is if banks were
committing fraud and calling something a "savings account" when it isn't in
fact a savings account.
> money markets have had no reserve requirement and have a nearly spotless
record of satisfying their obligations.
Lol, money markets are so new that they've had no opportunity to show their
true risk. In the finance world, things work fine for a long time until
they fail spectacularly, losing more than the gain they made in the first
place. This is a regular occurence. Its the reason bitcoin was created.
> Irrelevant.
It is certainly not irrelevant. People have been lead to believe that they
can withdraw their money from their accounts. People expect this. Banks are
doing nothing to educate people on the limitations of that fact. PoR would
give people the ability to see quite accurately how much reserves there are
and can use this knowledge to put pressure on institutions to keep the
reserves those people think they should keep.
> Without 100% “reserve” there is no way to cryptographically demonstrate
“solvency”.
You can show proof that you're 80% solvent, and then claim the other 20% is
in other assets. This is, again, still useful.
>The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or
state seizure, no matter what the reserve
You're right, but that's irrelevant.
But it seems like you're not interested in understanding what I'm saying or
discussing these things honestly. So I'm going to end my conversation with
you here.
On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Jul 9, 2021, at 10:44, Billy Tetrud <billy.tetrud@gmail.com> wrote:
> >
> > > there is an unsupportable leap being made here
> >
> > You think that because you're misinterpreting me. I'm in no way claiming
> that any solvent company can prove it, I'm simply claiming that any company
> can prove that they have bitcoin reserves to cover bitcoins promised as
> account balances.
>
> You can prove that in your own wallet. All other scenarios imply lending
> (which is what is implied by “reserve”) and lending cannot be 100% reserve.
>
> > > Banks (lending institutions) do not operate under any such pretense
> >
> > You seem to be saying that banks are under no legal obligation to serve
> cash on demand to customers. While you might be right,
>
> I am, as banks are lending institutions.
>
> > again you're misinterpreting me. Banks do in fact make claims to their
> customers that they'll be able to get cash out of their account on demand.
>
> Up to the insured limit, in 7 days. This is of course true because the
> taxpayer has insured the bank to that level.
>
> > They're called demand deposit accounts for a reason.
>
> They are time deposits, read your bank agreement. Not that it makes any
> difference. How the contract is satisfied is not a term of the contract,
> just that it is. And as I pointed out, money markets have had no reserve
> requirement and have a nearly spotless record of satisfying their
> obligations.
>
> > And certainly customers expect to be able to withdraw their cash on
> demand.
>
> Irrelevant.
>
> > > With a 100% of investment cash hoard, there is zero lending and zero
> return
> >
> > I did say "pretend" did I not?
>
> See above.
>
> > > “relate to” is a far cry from 100% “reserve”
> >
> > Indeed. Again, you seem to be misunderstanding me. You're putting the
> words "100% reserve" in my mouth, when I never said any such thing. Proof
> of 80%/50%/20% reserves is still useful if that's the clear expectation for
> the customer/client.
>
> Without 100% “reserve” there is no way to cryptographically demonstrate
> “solvency”. And even with that, investors would have to accept the promise
> that there are no other liabilities.
>
> The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or
> state seizure, no matter what the reserve.
>
> It’s information, sure, but it’s not what people seem to think. If one
> wants full reserve banking, use a wallet. If one wants to invest, the money
> will be spent - that’s why it was raised. There can be no covenant placed
> on it that will ensure it’s return.
>
> e
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7027 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-09 22:02 ` Billy Tetrud
@ 2021-07-09 23:18 ` Eric Voskuil
2021-07-09 23:50 ` ZmnSCPxj
0 siblings, 1 reply; 21+ messages in thread
From: Eric Voskuil @ 2021-07-09 23:18 UTC (permalink / raw)
To: 'Billy Tetrud'; +Cc: 'Bitcoin Protocol Discussion'
>> You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
>You're using terms in non-standard ways. Putting money into a bank is not considered "lending" to the bank.
What people consider is irrelevant, all that matters is what is correct. A bank account as you are referring to it is indistinguishable from a money market (investment) fund in all aspects but federal reserve membership and regulatory controls. Interest (and offset expenses) derives directly from their earnings on this *investment*. Describing it otherwise is either an error (leading to false conclusions) or a lie.
> You may make a case that you're lending to a bank, and that they legally owe you repayment of that money on demand limited by the terms you mentioned. But regardless of a case that can be made there, pretty much no one considers that "lending". Since you you like defining things legally, depositing money in a bank is legally not defined as lending to the bank.
Please don’t bother to try and use statue as if it was at all relevant regarding economic concepts.
> So no, all other scenarios do not imply lending. You can have your coins in custody with someone else, and that someone else can keep 100% reserves if they choose (or agreed to) and can prove it to you via the method I described or the methods others have linked to.
That’s what Rothbard calls a “warehouse” - in order to distinguish it from investment. I’ve already made this distinction. Easier to prove with your own wallet, as I said. You are conflating this with banking, which should be obvious.
>> They are time deposits, read your bank agreement.
> You are https://www.investopedia.com/terms/t/timedeposit.asp#:~:text=A%20time%20deposit%20is%20an,pre%2Dset%20date%20of%20maturity.&text=Time%20deposits%20generally%20pay%20a,of%20investment%20is%20term%20deposit.. https://www.slsp.sk/en/personal/faq/what-is-the-difference-between-a-term-deposit-and-savings-account if you don't believe me. The only way you would be correct is if banks were committing fraud and calling something a "savings account" when it isn't in fact a savings account.
No, I am not wrong. It's not a question of believing you, it's a question of understanding the concepts. You will find this language in your deposit agreement (as required by statute):
"9. Our right to require advance notice of withdrawals
For all savings accounts and all personal interest-bearing checking accounts, we reserve the right to require seven days’ prior written notice of withdrawal."
https://www.chase.com/content/dam/chasecom/en/checking/documents/deposit_account_agreement.pdf
"When a man deposits goods at a warehouse, he is given a receipt and pays the owner of the warehouse a certain sum for the service of storage. He still retains ownership of the property; the owner of the warehouse is simply guarding it for him. When the warehouse receipt is presented, the owner is obligated to restore the good deposited. A warehouse specializing in money is known as a "bank.""
- Rothbard
As you can see, he is not talking about what you are talking about when it comes to colloquial use of the term "bank", he is clear to define what he means by "bank".
"Someone else's property is taken by the warehouse and used for its own money-making purposes. It is not borrowed, since no interest is paid for the use of the money."
- Rothbard
Any expectation of interest implies *borrowing*, in other words, a *loan* to the bank.
"Whether saved capital is channeled into investments via stocks or via loans is unimportant. The only difference is in the legal technicalities. Indeed, even the legal difference between the creditor and the owner is a negligible one."
- Rothbard
> You're using terms in non-standard ways. Putting money into a bank is not considered "lending" to the bank.
I think it's quite clear that Rothbard considers it lending. I'm not big on appeal to authority, but sometimes it helps open minds. Links here:
https://github.com/libbitcoin/libbitcoin-system/wiki/Full-Reserve-Fallacy
>> money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
> Lol, money markets are so new that they've had no opportunity to show their true risk.
1971, 50 years.
https://en.wikipedia.org/wiki/Money_market_fund
> In the finance world, things work fine for a long time until they fail spectacularly, losing more than the gain they made in the first place. This is a regular occurence. Its the reason bitcoin was created.
regular occurrence...
"Buck breaking has rarely happened. Up to the 2008 financial crisis, only three money funds had broken the buck in the 37-year history of money funds... The first money market mutual fund to break the buck was First Multifund for Daily Income (FMDI) in 1978, liquidating and restating NAV at 94 cents per share"
An investment loss of 6%.
"The Community Bankers US Government Fund broke the buck in 1994, paying investors 96 cents per share."
An investment loss of 4%.
"This was only the second failure in the then 23-year history of money funds and there were no further failures for 14 years... No further failures occurred until September 2008, a month that saw tumultuous events for money funds."
It was a "tumultuous" month for nearly all investments. The feds of course doled out the pork, and the funds had to take it (as if their competition did and they didn't they would fail due to higher relative capital costs and thereby lower rates). In the past, absent pork, they had raised money where necessary to maintain their NAV (just as banks do, but they go to the taxpayer, and just as all business do from time to time).
These are remarkably stable in terms of NAV. And people seem to be satisfied with them:
"At the end of 2011, there were 632 money market funds in operation,[19] with total assets of nearly US$2.7 trillion.[19] Of this $2.7 trillion, retail money market funds had $940 billion in Assets Under Management (AUM). Institutional funds had $1.75 trillion under management.[19]"
The point being, that this is as close to free market bank-based investing as exists in the white market. In a money market fund, the NAV is reflected in the share price, so any losses are evenly distributed - no different than when all those HODLers take a hit when Elon farts, and the reserve they maintain has been very effective in maintaining their $1/share *target* despite paying *interest* on *investments*. They are merely shifting market returns into interest, just like banks. Market returns over short periods aren't always positive. No surprise. The larger point being, BANKS ARE INVESTMENT FUNDS.
>> Irrelevant.
> It is certainly not irrelevant. People have been lead to believe that they can withdraw their money from their accounts. People expect this.
Irrelevant, people have minds and free will and can read the contracts they are actually signing. Contracts are the *actual* Law associated with non-aggression.
> Banks are doing nothing to educate people on the limitations of that fact.
Again, irrelevant. And wholly unnecessary given compulsory taxpayer deposit insurance.
> PoR would give people the ability to see quite accurately how much reserves there are and can use this knowledge to put pressure on institutions to keep the reserves those people think they should keep.
For all of the reasons I've stated, it's a fairly pointless exercise, but people can do what they want. But if they are doing this with a deeply flawed understanding of banking to start with, they will be disappointed in the outcome.
>> Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”.
> You can show proof that you're 80% solvent, and then claim the other 20% is in other assets. This is, again, still useful.
80% solvent ... 50% pregnant.
>>The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve
> You're right, but that's irrelevant.
I'll leave that to the reader. The alternative is to use your own wallet.
> But it seems like you're not interested in understanding what I'm saying or discussing these things honestly.
I'm not interested in allowing flawed concepts to be perpetuated without question. This is just a drain on capital that could be put to much better use. How many times have I heard the oxymoron "full reserve banking", and how much capital has been burned on this futile exercise, simply due to a failure to understand these concepts.
> So I'm going to end my conversation with you here.
While seemingly off-topic, these are things that need to be aired in this community. Thanks for the discourse.
e
On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Jul 9, 2021, at 10:44, Billy Tetrud <mailto:billy.tetrud@gmail.com> wrote:
>
> > there is an unsupportable leap being made here
>
> You think that because you're misinterpreting me. I'm in no way claiming that any solvent company can prove it, I'm simply claiming that any company can prove that they have bitcoin reserves to cover bitcoins promised as account balances.
You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
> > Banks (lending institutions) do not operate under any such pretense
>
> You seem to be saying that banks are under no legal obligation to serve cash on demand to customers. While you might be right,
I am, as banks are lending institutions.
> again you're misinterpreting me. Banks do in fact make claims to their customers that they'll be able to get cash out of their account on demand.
Up to the insured limit, in 7 days. This is of course true because the taxpayer has insured the bank to that level.
> They're called demand deposit accounts for a reason.
They are time deposits, read your bank agreement. Not that it makes any difference. How the contract is satisfied is not a term of the contract, just that it is. And as I pointed out, money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
> And certainly customers expect to be able to withdraw their cash on demand.
Irrelevant.
> > With a 100% of investment cash hoard, there is zero lending and zero return
>
> I did say "pretend" did I not?
See above.
> > “relate to” is a far cry from 100% “reserve”
>
> Indeed. Again, you seem to be misunderstanding me. You're putting the words "100% reserve" in my mouth, when I never said any such thing. Proof of 80%/50%/20% reserves is still useful if that's the clear expectation for the customer/client.
Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”. And even with that, investors would have to accept the promise that there are no other liabilities.
The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve.
It’s information, sure, but it’s not what people seem to think. If one wants full reserve banking, use a wallet. If one wants to invest, the money will be spent - that’s why it was raised. There can be no covenant placed on it that will ensure it’s return.
e
_______________________________________________
bitcoin-dev mailing list
mailto:bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-09 23:18 ` Eric Voskuil
@ 2021-07-09 23:50 ` ZmnSCPxj
2021-07-10 0:49 ` eric
0 siblings, 1 reply; 21+ messages in thread
From: ZmnSCPxj @ 2021-07-09 23:50 UTC (permalink / raw)
To: Eric Voskuil, Bitcoin Protocol Discussion; +Cc: 'Billy Tetrud'
Good morning e,
> Any expectation of interest implies borrowing, in other words, a loan to the bank.
Perhaps this is the key point of contention?
In cases where Bitcoin is given over to an exchange, there is no expectation of interest, at least in the sense that there is no expectation that the number of Bitcoins deposited in the exchange *increase* over time.
(There may be an expectation of an increase in the number of green-ink historical commemoration papers it can buy, but the point is that the number of Bitcoins held in behalf of the user is not expected to change)
The expectation is that exchanges earn money from the difference between buy-price and sell-price, and the money-warehousing service they provide is simply provided for free to facilitate their *main* business (i.e. brokers for *exchange*).
Thus, the expectation is that the exchange provides a warehouse service, not a bank service, and this service is provided for free since it enables their *real* business of earning from bid-ask spreads.
On the other hand, not your keys not your coins, so anyone who uses such a warehouse has whatever happens to the funds coming for them...
And of course exchanges need not earn money *just* from bid-ask spreads *in practice*, so they are unlikely to provide proof-of-reserves either.
Indeed, money warehousing may very well be provided by means other than proof-of-reserves, such as by using multisig the way Green wallet does, with better security.
Perhaps "pure exchanges" would be more amenable to such a scheme rather than proof-of-reserves.
Regards,
ZmnSCPxj
>
> "Whether saved capital is channeled into investments via stocks or via loans is unimportant. The only difference is in the legal technicalities. Indeed, even the legal difference between the creditor and the owner is a negligible one."
>
> - Rothbard
>
> > You're using terms in non-standard ways. Putting money into a bank is not considered "lending" to the bank.
>
> I think it's quite clear that Rothbard considers it lending. I'm not big on appeal to authority, but sometimes it helps open minds. Links here:
>
> https://github.com/libbitcoin/libbitcoin-system/wiki/Full-Reserve-Fallacy
>
> > > money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
>
> > Lol, money markets are so new that they've had no opportunity to show their true risk.
>
> 1971, 50 years.
> https://en.wikipedia.org/wiki/Money_market_fund
>
> > In the finance world, things work fine for a long time until they fail spectacularly, losing more than the gain they made in the first place. This is a regular occurence. Its the reason bitcoin was created.
>
> regular occurrence...
>
> "Buck breaking has rarely happened. Up to the 2008 financial crisis, only three money funds had broken the buck in the 37-year history of money funds... The first money market mutual fund to break the buck was First Multifund for Daily Income (FMDI) in 1978, liquidating and restating NAV at 94 cents per share"
>
> An investment loss of 6%.
>
> "The Community Bankers US Government Fund broke the buck in 1994, paying investors 96 cents per share."
>
> An investment loss of 4%.
>
> "This was only the second failure in the then 23-year history of money funds and there were no further failures for 14 years... No further failures occurred until September 2008, a month that saw tumultuous events for money funds."
>
> It was a "tumultuous" month for nearly all investments. The feds of course doled out the pork, and the funds had to take it (as if their competition did and they didn't they would fail due to higher relative capital costs and thereby lower rates). In the past, absent pork, they had raised money where necessary to maintain their NAV (just as banks do, but they go to the taxpayer, and just as all business do from time to time).
>
> These are remarkably stable in terms of NAV. And people seem to be satisfied with them:
>
> "At the end of 2011, there were 632 money market funds in operation,[19] with total assets of nearly US$2.7 trillion.[19] Of this $2.7 trillion, retail money market funds had $940 billion in Assets Under Management (AUM). Institutional funds had $1.75 trillion under management.[19]"
>
> The point being, that this is as close to free market bank-based investing as exists in the white market. In a money market fund, the NAV is reflected in the share price, so any losses are evenly distributed - no different than when all those HODLers take a hit when Elon farts, and the reserve they maintain has been very effective in maintaining their $1/share target despite paying interest on investments. They are merely shifting market returns into interest, just like banks. Market returns over short periods aren't always positive. No surprise. The larger point being, BANKS ARE INVESTMENT FUNDS.
>
> > > Irrelevant.
>
> > It is certainly not irrelevant. People have been lead to believe that they can withdraw their money from their accounts. People expect this.
>
> Irrelevant, people have minds and free will and can read the contracts they are actually signing. Contracts are theactual Law associated with non-aggression.
>
> > Banks are doing nothing to educate people on the limitations of that fact.
>
> Again, irrelevant. And wholly unnecessary given compulsory taxpayer deposit insurance.
>
> > PoR would give people the ability to see quite accurately how much reserves there are and can use this knowledge to put pressure on institutions to keep the reserves those people think they should keep.
>
> For all of the reasons I've stated, it's a fairly pointless exercise, but people can do what they want. But if they are doing this with a deeply flawed understanding of banking to start with, they will be disappointed in the outcome.
>
> > > Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”.
>
> > You can show proof that you're 80% solvent, and then claim the other 20% is in other assets. This is, again, still useful.
>
> 80% solvent ... 50% pregnant.
>
> > > The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve
>
> > You're right, but that's irrelevant.
>
> I'll leave that to the reader. The alternative is to use your own wallet.
>
> > But it seems like you're not interested in understanding what I'm saying or discussing these things honestly.
>
> I'm not interested in allowing flawed concepts to be perpetuated without question. This is just a drain on capital that could be put to much better use. How many times have I heard the oxymoron "full reserve banking", and how much capital has been burned on this futile exercise, simply due to a failure to understand these concepts.
>
> > So I'm going to end my conversation with you here.
>
> While seemingly off-topic, these are things that need to be aired in this community. Thanks for the discourse.
>
> e
>
> On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > On Jul 9, 2021, at 10:44, Billy Tetrud mailto:billy.tetrud@gmail.com wrote:
> >
> > > there is an unsupportable leap being made here
> >
> > You think that because you're misinterpreting me. I'm in no way claiming that any solvent company can prove it, I'm simply claiming that any company can prove that they have bitcoin reserves to cover bitcoins promised as account balances.
>
> You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
>
> > > Banks (lending institutions) do not operate under any such pretense
> >
> > You seem to be saying that banks are under no legal obligation to serve cash on demand to customers. While you might be right,
>
> I am, as banks are lending institutions.
>
> > again you're misinterpreting me. Banks do in fact make claims to their customers that they'll be able to get cash out of their account on demand.
>
> Up to the insured limit, in 7 days. This is of course true because the taxpayer has insured the bank to that level.
>
> > They're called demand deposit accounts for a reason.
>
> They are time deposits, read your bank agreement. Not that it makes any difference. How the contract is satisfied is not a term of the contract, just that it is. And as I pointed out, money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
>
> > And certainly customers expect to be able to withdraw their cash on demand.
>
> Irrelevant.
>
> > > With a 100% of investment cash hoard, there is zero lending and zero return
> >
> > I did say "pretend" did I not?
>
> See above.
>
> > > “relate to” is a far cry from 100% “reserve”
> >
> > Indeed. Again, you seem to be misunderstanding me. You're putting the words "100% reserve" in my mouth, when I never said any such thing. Proof of 80%/50%/20% reserves is still useful if that's the clear expectation for the customer/client.
>
> Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”. And even with that, investors would have to accept the promise that there are no other liabilities.
>
> The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve.
>
> It’s information, sure, but it’s not what people seem to think. If one wants full reserve banking, use a wallet. If one wants to invest, the money will be spent - that’s why it was raised. There can be no covenant placed on it that will ensure it’s return.
>
> e
>
> bitcoin-dev mailing list
> mailto: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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-09 23:50 ` ZmnSCPxj
@ 2021-07-10 0:49 ` eric
2021-07-10 1:26 ` ZmnSCPxj
0 siblings, 1 reply; 21+ messages in thread
From: eric @ 2021-07-10 0:49 UTC (permalink / raw)
To: 'ZmnSCPxj', 'Bitcoin Protocol Discussion'
Cc: 'Billy Tetrud'
> Good morning e,
Good afternoon Z.
> > Any expectation of interest implies borrowing, in other words, a loan to
> the bank.
>
> Perhaps this is the key point of contention?
I'm not sure, but from my observations it's long been a point of confusion in Bitcoiner understanding of banking.
To put a finer point on it, Rothbard's criteria is a vague in a couple ways. Earnings that offset fees are also "interest" in the economic context - in which he writes. So even a zero-interest account (or negative up to the full cost of maintaining the account) qualifies under this criterion. Yet he is careful to say "implies". The arrangement may of course be explicit, in which case one no longer relies on implied contract, one relies on explicit contract. Finally, one may "expect" no interest, and even pay fees, but it may nonetheless be a loan. This is what contracts are for.
If one contracts for warehousing service, such Safe Deposit, as opposed to a time deposit, such as Certificate of Deposit, Savings Account, or Checking Account, then one gets a warehousing service - full fees and a contractual obligation to maintain 100% of the deposit. There are also money transmission services that move money around for a fee. The inability to distinguish money from credit (including money substitutes) and warehousing from investment (including "banking") leads directly to false conclusions regarding money and banking. Unfortunately a good number of self-described "Austrians" perpetuate these errors.
> In cases where Bitcoin is given over to an exchange, there is no expectation
> of interest, at least in the sense that there is no expectation that the number
> of Bitcoins deposited in the exchange *increase* over time.
> (There may be an expectation of an increase in the number of green-ink
> historical commemoration papers it can buy, but the point is that the number
> of Bitcoins held in behalf of the user is not expected to change)
>
> The expectation is that exchanges earn money from the difference between
> buy-price and sell-price, and the money-warehousing service they provide is
> simply provided for free to facilitate their *main* business (i.e. brokers for
> *exchange*).
> Thus, the expectation is that the exchange provides a warehouse service,
> not a bank service, and this service is provided for free since it enables their
> *real* business of earning from bid-ask spreads.
I'm not aware of what are people's expectations, nor would I judge what qualifies as someone's "real" business, but a warehouse that facilitates trades for a fee is of course a possible business model. PayPal's intended (real?) business model was to earn from the float. That didn't pan out, because people didn't retain money in their transmitter service.
Exchanges that deal in monopoly money must move this through traditional finance. This incurs all manner of risk. When someone sends them monopoly money, there is no crypto-surety possible. This is part of their "reserve" just as is the other side of trades.
What matters is what people contract for - agree to, voluntarily.
> On the other hand, not your keys not your coins, so anyone who uses such a
> warehouse has whatever happens to the funds coming for them...
One of the essential benefits of Bitcoin being that you can be your own warehouse, and be your own money transmitter.
But all production requires investment, which inherently entails letting go of your money, producing something with it, and selling it to people for other money. All investment is from someone's "reserve". Full reserve investment (including banking) is an oxymoron. So whether through exchanges or otherwise, there will be production, risk, loss and earnings. Otherwise there will be nothing at all to buy, and all money will be worthless. This idea of assuring that money is fully reserved applies only to that which one does not invest (one's hoard); it does not apply to banks, or the capital of any other companies. If it can help people feel better about their Safe Deposit (warehousing), I'm all for it. But if one wants a 20% bitcoin reserve, one can certainly place 20% into cold storage.
> And of course exchanges need not earn money *just* from bid-ask spreads
> *in practice*, so they are unlikely to provide proof-of-reserves either.
If they did not earn money as a bank, the explicit cost of their services would be that much higher. Which people prefer is of course entirely up to them. I don't know which is more likely.
> Indeed, money warehousing may very well be provided by means other than
> proof-of-reserves, such as by using multisig the way Green wallet does, with
> better security.
Right, this is an aspect of using your own wallet.
> Perhaps "pure exchanges" would be more amenable to such a scheme
> rather than proof-of-reserves.
Or simply pairing traders, which is of course an existing model.
Best,
e
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-10 0:49 ` eric
@ 2021-07-10 1:26 ` ZmnSCPxj
2021-07-10 1:49 ` eric
0 siblings, 1 reply; 21+ messages in thread
From: ZmnSCPxj @ 2021-07-10 1:26 UTC (permalink / raw)
To: eric; +Cc: 'Bitcoin Protocol Discussion', 'Billy Tetrud'
Good morning e,
Okay, it seems to me that what you are saying is something like this:
> Proof-of-reserves would (partially) work for a "pure" warehousing service (i.e. user pays some fee, service keeps money and provides proofs that money is kept).
> However, "pure" warehousing is not what a typical exchange does (else the explicit fees in their exchanges would be higher), as it takes on risk due to having to deal with non-Bitcoin monopoly money (by definition, since they are *exchanges*).
> Further, with Bitcoin you can be your own warehouse (including Green-like multisig schemes where you own your own keys that are part of the scheme), which is an alternative choice to hiring a "pure warehouse" (i.e. Safe Deposit).
Would that be a fair (if somewhat rough and undetailed) restatement?
Regards,
ZmnSCPxj
> > Good morning e,
>
> Good afternoon Z.
>
> > > Any expectation of interest implies borrowing, in other words, a loan to
> > >
> >
> > the bank.
> > Perhaps this is the key point of contention?
>
> I'm not sure, but from my observations it's long been a point of confusion in Bitcoiner understanding of banking.
>
> To put a finer point on it, Rothbard's criteria is a vague in a couple ways. Earnings that offset fees are also "interest" in the economic context - in which he writes. So even a zero-interest account (or negative up to the full cost of maintaining the account) qualifies under this criterion. Yet he is careful to say "implies". The arrangement may of course be explicit, in which case one no longer relies on implied contract, one relies on explicit contract. Finally, one may "expect" no interest, and even pay fees, but it may nonetheless be a loan. This is what contracts are for.
>
> If one contracts for warehousing service, such Safe Deposit, as opposed to a time deposit, such as Certificate of Deposit, Savings Account, or Checking Account, then one gets a warehousing service - full fees and a contractual obligation to maintain 100% of the deposit. There are also money transmission services that move money around for a fee. The inability to distinguish money from credit (including money substitutes) and warehousing from investment (including "banking") leads directly to false conclusions regarding money and banking. Unfortunately a good number of self-described "Austrians" perpetuate these errors.
>
> > In cases where Bitcoin is given over to an exchange, there is no expectation
> > of interest, at least in the sense that there is no expectation that the number
> > of Bitcoins deposited in the exchange increase over time.
> > (There may be an expectation of an increase in the number of green-ink
> > historical commemoration papers it can buy, but the point is that the number
> > of Bitcoins held in behalf of the user is not expected to change)
> > The expectation is that exchanges earn money from the difference between
> > buy-price and sell-price, and the money-warehousing service they provide is
> > simply provided for free to facilitate their main business (i.e. brokers for
> > exchange).
> > Thus, the expectation is that the exchange provides a warehouse service,
> > not a bank service, and this service is provided for free since it enables their
> > real business of earning from bid-ask spreads.
>
> I'm not aware of what are people's expectations, nor would I judge what qualifies as someone's "real" business, but a warehouse that facilitates trades for a fee is of course a possible business model. PayPal's intended (real?) business model was to earn from the float. That didn't pan out, because people didn't retain money in their transmitter service.
>
> Exchanges that deal in monopoly money must move this through traditional finance. This incurs all manner of risk. When someone sends them monopoly money, there is no crypto-surety possible. This is part of their "reserve" just as is the other side of trades.
>
> What matters is what people contract for - agree to, voluntarily.
>
> > On the other hand, not your keys not your coins, so anyone who uses such a
> > warehouse has whatever happens to the funds coming for them...
>
> One of the essential benefits of Bitcoin being that you can be your own warehouse, and be your own money transmitter.
>
> But all production requires investment, which inherently entails letting go of your money, producing something with it, and selling it to people for other money. All investment is from someone's "reserve". Full reserve investment (including banking) is an oxymoron. So whether through exchanges or otherwise, there will be production, risk, loss and earnings. Otherwise there will be nothing at all to buy, and all money will be worthless. This idea of assuring that money is fully reserved applies only to that which one does not invest (one's hoard); it does not apply to banks, or the capital of any other companies. If it can help people feel better about their Safe Deposit (warehousing), I'm all for it. But if one wants a 20% bitcoin reserve, one can certainly place 20% into cold storage.
>
> > And of course exchanges need not earn money just from bid-ask spreads
> > in practice, so they are unlikely to provide proof-of-reserves either.
>
> If they did not earn money as a bank, the explicit cost of their services would be that much higher. Which people prefer is of course entirely up to them. I don't know which is more likely.
>
> > Indeed, money warehousing may very well be provided by means other than
> > proof-of-reserves, such as by using multisig the way Green wallet does, with
> > better security.
>
> Right, this is an aspect of using your own wallet.
>
> > Perhaps "pure exchanges" would be more amenable to such a scheme
> > rather than proof-of-reserves.
>
> Or simply pairing traders, which is of course an existing model.
>
> Best,
> e
>
> > Regards,
> > ZmnSCPxj
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proof of reserves - recording
2021-07-10 1:26 ` ZmnSCPxj
@ 2021-07-10 1:49 ` eric
0 siblings, 0 replies; 21+ messages in thread
From: eric @ 2021-07-10 1:49 UTC (permalink / raw)
To: 'ZmnSCPxj'
Cc: 'Bitcoin Protocol Discussion', 'Billy Tetrud'
All reasonable.
e
> Okay, it seems to me that what you are saying is something like this:
>
> > Proof-of-reserves would (partially) work for a "pure" warehousing service
> (i.e. user pays some fee, service keeps money and provides proofs that
> money is kept).
> > However, "pure" warehousing is not what a typical exchange does (else
> the explicit fees in their exchanges would be higher), as it takes on risk due
> to having to deal with non-Bitcoin monopoly money (by definition, since they
> are *exchanges*).
> > Further, with Bitcoin you can be your own warehouse (including Green-like
> multisig schemes where you own your own keys that are part of the
> scheme), which is an alternative choice to hiring a "pure warehouse" (i.e.
> Safe Deposit).
>
> Would that be a fair (if somewhat rough and undetailed) restatement?
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-07-10 1:49 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-05 18:24 [bitcoin-dev] Proof of reserves - recording Billy Tetrud
2021-07-05 23:26 ` ZmnSCPxj
2021-07-05 23:32 ` Eric Voskuil
2021-07-06 0:09 ` ZmnSCPxj
2021-07-06 1:34 ` Billy Tetrud
2021-07-06 4:54 ` ZmnSCPxj
2021-07-06 5:09 ` Eric Voskuil
2021-07-06 6:02 ` Billy Tetrud
2021-07-06 7:37 ` Eric Voskuil
2021-07-06 16:39 ` Erik Aronesty
2021-07-06 18:40 ` eric
2021-07-07 6:18 ` Billy Tetrud
2021-07-09 14:55 ` Eric Voskuil
2021-07-09 17:43 ` Billy Tetrud
2021-07-09 18:32 ` Eric Voskuil
2021-07-09 22:02 ` Billy Tetrud
2021-07-09 23:18 ` Eric Voskuil
2021-07-09 23:50 ` ZmnSCPxj
2021-07-10 0:49 ` eric
2021-07-10 1:26 ` ZmnSCPxj
2021-07-10 1:49 ` eric
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox