@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
> 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?