Enforcing inflation rules for SPV clients [combined summary]



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

Published on: 2012-06-25T23:21:14+00:00


Summary:

The conversation between Mike and Daniel focuses on various aspects of the Bitcoin system, including potential conspiracies involving bad or hacked client developers and miners. They discuss how the official Bitcoin client addresses this issue through its gitian system, which involves multiple developers compiling the same source to the same binary and signing the results. This helps prevent the release of hacked clients. The conversation also highlights the importance of lightweight clients being able to audit the coinbase transaction and the difficulty of calculating fees without all input transactions being available.To address these challenges, the conversation suggests compartmentalizing errors to make them individually cheaper to verify. This could involve requiring error messages to be received by a quorum of peers before checking and dropping unreliable peers. Hashcash could also be used to balance costs to send and verify a given type of error message. Additionally, SPV clients could subscribe to announcements of invalid blocks and their specific failure mode to keep rule enforcement decentralized while scaling Bitcoin.The conversation acknowledges that mobile clients may struggle with verifying coinbase transaction invalidity, especially if the block size limit is lifted. To overcome this, they propose splitting up the summing of spendable fees into verifiable pieces and including them in a new Merkle tree. Verifying a claim of invalidity of one of these leaves would require downloading about 1MB of transaction data and verifying inclusion, which could still be manageable for a smartphone at large transaction volumes.The conversation also touches on the topics of block size and centralization. One person expresses uncertainty about whether larger blocks would lead to centralization, as it would take significant changes in transaction usage to reach gigabyte-sized blocks. They speculate that technology will have improved enough by that time to mitigate any concerns. The conversation notes that this topic has been debated before and may be further discussed at a future meetup.In another part of the conversation, a proposal made by Daniel is discussed. The proposal involves good nodes broadcasting announcements when they detect a rule violation, along with a proof of the violation. Mike Hearn mentions that he had also proposed a similar idea on the same mailing list and elaborated on it in an IRC chat. The use of proofs would ensure that nodes doing validation without personally witnessing the complete history of Bitcoin still have strong security. This proposal aligns with Satoshi's comment about information being easy to spread but hard to stifle.The conversation also addresses the possibility of miners conspiring to raise inflation, which could be problematic if most economic actors use SPV clients. It is noted that checking the coinbase of a transaction is not possible without knowing the fees in the block, which requires all input transactions. To resolve this issue, Daniel proposes having good nodes broadcast announcements when they detect a rule-breaker, along with a proof. The SPV client would then verify the split, download the necessary transactions and merkle branches, and check the fee, apply the inflation formula, and validate the coinbase value. Mechanisms are discussed to recover from accidentally accepting invalid blocks, such as creating a system where miners who have contributed to the pool's proof-of-work are allocated verification work. Proofs of invalidity are also suggested to circulate.Overall, the conversation emphasizes the importance of trust models, decentralization, and auditing in ensuring the integrity of the Bitcoin system. Various proposals and solutions are discussed to address potential vulnerabilities and challenges in the system.


Updated on: 2023-08-01T03:43:30.612754+00:00