Eric Voskuil [ARCHIVE] on Nostr: đź“… Original date posted:2021-07-06 đź“ť Original message:> @Eric > Auditability ...
đź“… Original date posted:2021-07-06
đź“ť Original message:> @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 at voskuil.org> wrote:
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>>
>>>> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj at 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 at 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 at 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 at lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/fdd3ae32/attachment-0001.html>;
đź“ť Original message:> @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 at voskuil.org> wrote:
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>>
>>>> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj at 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 at 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 at 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 at lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/fdd3ae32/attachment-0001.html>;