Author: Ruben Somsen 2023-08-19 14:35:10+00:00
Published on: 2023-08-19T14:35:10+00:00
In the email, Ruben responds to Ryan's proposal and discusses the concept of "fraud proofs" in the context of Bitcoin. He explains that fraud proofs involve committing to every computational step and allowing anyone to reveal erroneous steps, thus proving that a state transition or block is invalid. However, Ruben points out that fraud proofs do not address the issue of data availability.Ruben explains that if someone claims data is unavailable, the only way to verify this claim is by downloading the data. This poses a problem because malicious peers can cause others to download all the data, resulting in no bandwidth savings. He mentions that fraud proofs could still reduce the need for computation by verifying only the parts for which fraud notifications are received, but it does not completely solve the scaling issue.Ruben provides some historical context, mentioning that fraud proofs were considered for inclusion in segwit (Segregated Witness), but were abandoned due to the data availability problem. He also shares a link to an update on the topic: https://bitcoincore.org/en/2016/01/26/segwit-benefits/update-2016-10-19Finally, Ruben mentions that there is a potential solution to the data availability issue called PoW fraud proofs/softchains. He provides a link to a description of this solution: https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1. He notes that he currently believes this solution is better suited for low-bandwidth mainchain nodes rather than sidechains. Ruben concludes by saying that sampling data availability through erasure codes is also possible, but it is complex and fragile.Overall, Ruben's response provides insight into the concept of fraud proofs, highlights the limitation of data availability, and suggests potential solutions to address this issue in the context of Bitcoin.
Updated on: 2023-08-20T01:53:50.294016+00:00