{"type":"rich","version":"1.0","author_name":"npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","author_url":"https://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-07-06\n📝 Original message:@ZmnSCPxj\n\u003e  a thief (or \"thief\") who has gotten a copy of the key can sign a\ntransaction that spends it, one second after the proof-of-reserves is made.\n\nSure, but anyone can easily see that transaction happen and can discount\nthat part of the attestation. The same isn't true on lightning.\n\n\u003e *knowledge* is easily copyable.\n\nKnowledge isn't even really needed. Custodians could collude to sign each\nother's balance attestations. However, if the network of proof of reserves\nis cohesive, people could validate that addresses (and their balances)\naren't shared by anyone that's part of that PoR network.\n\n\u003e There is no way to prove that there is no alternate copy of the privkeys\n\nWell there are only really 2 cases:\n\n1. Only one entity has the keys\n2. Two entities have the keys and trust each other\n\nIn case 1, the attestation is accurate. In case 2, its really another way\nof saying case 1: you can view the two trusting entities as a single\nentity. In the case there are 2 non-trusting entities, its very likely that\none would steal from the other, or that they would be very uncomfortable\nwith the situation such that it wouldn't last long.\n\nBut you can't prove that someone won't steal the reserves. You can't prove\ncryptographically that the reserves aren't promised to someone else in a\nlegal contract (unless of course you make the proof of reserves system\nlegally binding). But this is why anyone that recommends PoR also\nrecommends independent audits to attest that the PoR actually matches\nreality.\n\nSo yes, there are limitations, but I don't think that means that PoR isn't\nworth doing. Is that what you're implying?\n\n\u003e we can show evidence that we live in a landlocked city far from any\nlakes, seas, or rivers\n\nI think that's the idea, if I understand you correctly.\n\n@Eric\nAuditability Fallacy\n\u003chttps://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy\u003e\n\n\u003e A solvency audit requires simultaneous (atomic) proof of both the full\namount of the asset held by a custodian and the securities issued against\nit.\n\n\u003e in the case where the security is issued on a distinct public chain the\natomicity requirement is not satisfied.\n\nI think what its saying is that you can't get atomicity of both the\nsecurity and the reserve. While this is true, what you can get is a system\nwhere the order of events can be established to a degree of precision. Ie,\nyou can know that between reserve-snapshot A and B, the balances add up to\nX. Each user can validate that their balance was indeed that value between\nA and B. With reserve snapshots and balance snapshots frequent enough, this\ncan allow reasonably high accuracy of estimated solvency. However, it does\nseem clear that perfect accuracy is not possible.\n\n\u003e Historically it has not been difficult to detect such deviations. The\ndifficulty arises in stopping them.\n\nI disagree here that it has not been difficult to detect deviations\n(insolvency). I mean, \"difficulty\" isn't the right word. These things\nalways become clear eventually. But I think its important to detect\ninsolvency quickly. Historically insolvency has certainly not been detected\nquickly. Insolvency is instead practically perpetual, and the question is\nonly how insolvent and when will it explode?\n\nI'm of the opinion that you can't prevent insolvency. Places will have\nmoney troubles and will try to cover it up, since usually there is no\ndownside (admitting insolvency can lead to bankrupcy, and failure to\nconceal insolvency has the same result - so why not try to conceal it and\nhope you can shore it up). However, its important that people know the\ninstitutions they have their money in are insolvent, or to what degree they\nare. If that information were well tracked, it could become clear over time\nthat a 10% insolvent company rarely goes out of business, but a 20%\ninsolvent company usually does. Then people can have parameters where\nthey're ok with a certain measurable degree of insolvency, but react\nswiftly and strongly when a company is too reckless. Currently the amount\nof recklessness any given company engages in is basically a company secret\nthat their clients don't have insight into. PoR would greatly help this I\nthink. You don't think so?\n\nOn Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\n\u003e https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy\n\u003e\n\u003e On Jul 5, 2021, at 21:54, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\n\u003e Good morning Billy,\n\u003e\n\u003e\n\u003e\n\u003e   The two participants in the channel can sign a plaintext containing\n\u003e their node pubkeys and how much each owns\n\u003e\n\u003e\n\u003e Sure, but even if both participants in the channel sign a correct\n\u003e statement of truth, one of the participants can send funds out in the next\n\u003e second, invalidating that truth. While proof of ownership of on-chain UTXOs\n\u003e can be seen publicly in real time if they are spent, LN transactions aren't\n\u003e public like that. So any balance attestation is at best only valid the\n\u003e instant its taken, and can't be used as verification the money is still\n\u003e owned by the same channel partner in the next second.\n\u003e\n\u003e\n\u003e The same problem really also exists onchain --- a thief (or \"thief\") who\n\u003e has gotten a copy of the key can sign a transaction that spends it, one\n\u003e second after the proof-of-reserves is made.\n\u003e\n\u003e Really, though, the issue is that ownership of funds is conditional on\n\u003e *knowledge* of keys.\n\u003e And *knowledge* is easily copyable.\n\u003e\n\u003e Thus, it is possible that the funds that are \"proven\" to be the reserve of\n\u003e a custodian is actually *also* owned by someone else who has gotten to the\n\u003e privkeys (e.g. somebody threw a copy of it from a boating accident and a\n\u003e fearless scuba diver rescued it), and thus can also move the funds outside\n\u003e of the control of the custodian.\n\u003e This condition can remain for many months or years, as well, without\n\u003e knowledge of the custodian clients, *or* of the custodian itself.\n\u003e\n\u003e There is no way to prove that there is no alternate copy of the privkeys,\n\u003e hence \"if only one could prove that he won't get into a boating accident\".\n\u003e\n\u003e On the other hand, one could argue that at least the onchain proof\n\u003e requires more conditions to occur, so we might plausibly live with \"we\n\u003e cannot prove we will never get into a boating accident but we can show\n\u003e evidence that we live in a landlocked city far from any lakes, seas, or\n\u003e rivers\".\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e   a custodian Lightning node is unable to \"freeze\" a snapshot of its\n\u003e current state and make an atomic proof-of-reserves of *all* channels\n\u003e\n\u003e\n\u003e That would be a neat trick. But yeah, I don't know how that would be\n\u003e possible.\n\u003e\n\u003e\n\u003e   I believe it is one reason why custodian proof-of-reserves is not that\n\u003e popular ... it does not prove that the key will not get lost\n\u003e\n\u003e\n\u003e True, but at least if funds do get lost, it would be come clear far\n\u003e quicker. Today, an insolvent company could go many months without the\n\u003e public finding out.\n\u003e\n\u003e\n\u003e On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\n\u003e\n\u003e Good morning e,\n\u003e\n\u003e\n\u003e If only one could prove that he won’t get into a boating accident.\n\u003e\n\u003e\n\u003e At least in the context of Lightning channels, if one party in the channel\n\u003e loses its key in a boating accident, the other party (assuming it is a true\n\u003e separate person and not a sockpuppet) has every incentive to unilaterally\n\u003e close the channel, which reveals the exact amounts (though not necessarily\n\u003e who owns which).\n\u003e\n\u003e If the other party then uses its funds in a new proof-of-reserves, then\n\u003e obviously the other output of the unilateral close was the one lost in the\n\u003e boating accident.\n\u003e\n\u003e\n\u003e On the other hand, yes, custodians losing custodied funds in boating\n\u003e accidents is much too common.\n\u003e\n\u003e I believe it is one reason why custodian proof-of-reserves is not that\n\u003e popular --- it only proves that the funds were owned under a particular key\n\u003e at some snapshot of the past, it does not prove that the key will not get\n\u003e lost (or \"lost and then salvaged by a scuba diver\") later.\n\u003e\n\u003e\n\u003e Regards,\n\u003e\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e\n\u003e e\n\u003e\n\u003e\n\u003e On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev\n\u003e bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e\n\u003e Good morning Billy,\n\u003e\n\u003e\n\u003e I wonder if there would be some way to include the ability to prove\n\u003e balances held on the lightning network, but I suspect that isn't generally\n\u003e possible.\n\u003e\n\u003e\n\u003e Thinking about this in terms of economic logic:\n\u003e\n\u003e Every channel is anchored onchain, and that anchor (the funding txout) is\n\u003e proof of the existence, and size, of the channel.\n\u003e\n\u003e The two participants in the channel can sign a plaintext containing their\n\u003e node pubkeys and how much each owns.\n\u003e\n\u003e One of the participants should provably be the custodian.\n\u003e\n\u003e\n\u003e -   If the counterparty is a true third party, it has no incentive to lie\n\u003e about its money.\n\u003e\n\u003e -   Especially if the counterparty is another custodian who wants\n\u003e proof-of-reserves, it has every incentive to overreport, but then the first\n\u003e party will refuse to sign.\n\u003e\n\u003e      It has a disincentive to underreport, and would itself refuse to sign\n\u003e a dishonest report that assigns more funds to the first party.\n\u003e\n\u003e      The only case that would be acceptable to both custodians would be to\n\u003e honestly report their holdings in the Lightning channel.\n\u003e\n\u003e\n\u003e -   If the counterparty is a sockpuppet of the custodian, then the entire\n\u003e channel is owned by the custodian and it would be fairly dumb of he\n\u003e custodian to claim to have less funds than the entire channel.\n\u003e\n\u003e\n\u003e Perhaps a more practical problem is that Lightning channel states change\n\u003e fairly quickly, and there are possible race conditions, due to network\n\u003e latency (remember, both nodes need to sign, meaning both of them need to\n\u003e communicate with each other, thus hit by network latency and other race\n\u003e conditions) where a custodian Lightning node is unable to \"freeze\" a\n\u003e snapshot of its current state and make an atomic proof-of-reserves of all\n\u003e channels.\n\u003e\n\u003e Regards,\n\u003e\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e bitcoin-dev mailing list\n\u003e\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210705/b2c7cab2/attachment-0001.html\u003e"}