Proof of reserves [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2021-07-10T01:49:37+00:00


Summary:

A new approach to proof of reserves has been proposed in the bitcoin-dev mailing list. The idea is for users to create private keys using a seed, generate a public key to represent their account, and give it to the custodian to record in a public record of account balances. The custodian would update a map of addresses to balances and store funds on HD wallets, creating a proof that they own each wallet. These structures would be combined and hashed, with the hash published on-chain daily. Software for each user could continuously validate their balance and verify that owned addresses have sufficient funds. A receipt system could also be added for balance updates.The proposal aims to provide a clear record of reserves that can be verified by anyone, preventing custodians from changing history. However, it does not prevent smash-and-grab attacks. The proposal also introduces people to self-custody of keys in a lightweight way, reducing the responsibility on the user. The community has been invited to provide feedback on similar systems.The discussion highlights the fallacy of auditability and the challenges in solvency audits. Trust becomes a factor as perfect accuracy is not possible. Users can publicly share their individual and temporary audits to estimate solvency. Insolvency is difficult to prevent, but proof of reserves (PoR) can help detect it. However, PoR does not insure investments against reckless behavior. Ownership of funds is conditional on knowledge of keys, which can be easily copied. Custodian proof-of-reserves only proves ownership at a specific snapshot, without guaranteeing future control. Lightning channel states change quickly, making it challenging for custodian lightning nodes to freeze a snapshot.The conversation on the GitHub page for libbitcoin-system addresses the issue of custodian proof-of-reserves. It is explained that attestation of balances in Lightning channels is valid only at the time it is taken and cannot verify ownership in the next second. Knowledge of keys is easily copyable, potentially allowing others to move funds outside the custodian's control. There is no way to prove the absence of alternate copies of private keys. Lightning channel states change quickly, creating race conditions for custodian Lightning nodes to freeze a snapshot. Despite these limitations, PoR is still worth considering.Further discussions on the bitcoin-dev mailing list explore the possibility of proving balances held on the Lightning Network. Anchoring channels on-chain serves as proof of their existence and size. Participants can sign plaintext with node pubkeys and ownership amounts. Custodian proof-of-reserves is not popular due to its limited scope and inability to prevent key loss. Lightning channel states change rapidly, posing challenges for atomic proof-of-reserves. Possible race conditions and network latency make freezing snapshots difficult.In conclusion, while there are proposals for proof of reserves in both Bitcoin and Lightning Network contexts, there are limitations and challenges to overcome. The discussions highlight the difficulties in achieving perfect accuracy and preventing insolvency. The issue of ownership based on knowledge of keys and the rapid changes in Lightning channel states add further complexity. However, the community continues to explore and discuss solutions to improve transparency and trust in the cryptocurrency ecosystem.In a recent article, the author discusses the challenge of providing proof-of-reserves for custodians in the Lightning network. The author highlights that there is a disincentive to underreport, but the dynamic nature of Lightning channel states and network latency can create race conditions that make it difficult for custodians to provide an atomic proof-of-reserves.To address this issue, the author proposes a solution involving the creation of private keys by users using a seed, which generates a public key. This public key is then provided to the custodian, representing the user's account in a public record of account balances. The custodian would update a map of addresses to balances and store funds on HD wallets. They would create a proof of ownership using the xpub for the wallet.To ensure ongoing verification of sufficient reserves, the author suggests combining and hashing these structures, with the resulting hash published in an on-chain transaction daily. This approach allows users to continuously validate their account balance and verify that owned addresses have sufficient funds. Additionally, users can request receipts for any balance updates.Recording this information on-chain serves multiple purposes. It prevents custodians from changing their history and enables cross-verification among custodians. Even if users lose their keys, they can easily create a new seed and provide a new public key to the custodian.Furthermore, having a daily record reduces the possibility of short-term loans of large cryptocurrency amounts, adding another layer of security to the system.Overall, this proposal provides a potential solution to the challenge of proving reserves in the Lightning network. By combining private and public keys, hashing structures, and recording information on-chain, custodians can offer ongoing verification of sufficient reserves while minimizing the risks associated with network dynamics and latency.


Updated on: 2023-08-02T04:22:07.715686+00:00