Published on: 2016-01-12T03:58:13+00:00
In a Bitcoin-dev mailing list, Joe2015 responded to Nick ODell's query about fee collection from transactions in the block. Joe suggested mapping the new-rules coinbase transaction into an old-rules legacy coinbase transaction, but emphasized the need for careful consideration to ensure the mapping is irreversible. Joe has redesigned the implementation and provided GitHub links for reference. The new version maps the Merkle root onto a 'legacy' coinbase transaction, effectively solving the problem with fees.The conversation on the Bitcoin-dev mailing list revolves around Joe's proposal for a "generalized soft fork." Marco Falke expresses doubts about the proposal, arguing that it contradicts the definition of a soft fork as it requires nodes to upgrade. Joe clarifies that while it may not technically be a soft fork, it possesses similar properties except for meaningful backwards compatibility for non-upgraded clients. Marco raises concerns about how non-updated nodes would verify collected fees without actual transactions at hand and suggests a hard fork as a cleaner solution. Joe acknowledges that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients. He argues that a "firm soft fork" could be a better option. However, Joe realizes an oversight in his proof-of-concept implementation where all transactions would have to be zero-fee due to missing fees from non-updated nodes. He suggests implicitly adding the fees or finding other solutions.Marco Falke and Joe discuss the concept of a "generalized" soft fork. Falke questions the property of a true soft fork as it requires nodes to upgrade, leaving non-upgraded nodes vulnerable to double spends. Joe suggests allowing the new rules to add fees implicitly as a solution. When Falke questions the benefits of a "generalized" soft fork over a hard fork, Joe emphasizes the risk of a network split between upgraded and non-upgraded clients and argues that a "firm" soft fork is a better option in such cases.The Bitcoin developer community is discussing a proposal called the "forced soft-fork," which would require all nodes on the network to upgrade to the latest software version. The proposal has received mixed reactions, with some considering it "crufty and hackish" while others argue that the fear of recursion is misplaced. The forced soft-fork involves a multi-levels-deep block-within-a-block approach, but proponents claim that careful planning can simplify it. While the forced soft-fork could make it easier for developers to implement new features and upgrades, concerns about its impact on the security and stability of the Bitcoin network remain.In a discussion on the bitcoin-dev mailing list, Martijn Meijering expresses concerns about blocking old clients from seeing transactions. Peter Todd warns against sending multiple transactions without knowing if the longest blockchain is being seen and suggests designing software with fee-bumping to avoid mistakes. Increasing the tx version number could potentially disrupt pre-signed transactions.Jonathan Toomim voices his opinion against a proposed approach involving multi-levels-deep block structures for generalized softforks, deeming it interesting but hackish and not deployable. Another participant suggests incorporating the forced fork concept into Bitcoin by committing to H(version + digest) in block headers. This approach would provide safety advantages over hard forks and relatively simple implementation, though it may institutionalize 51% attacks and give miners more political control.A proposal for a softfork implementation of BIP102, normally a hardfork, has been shared on the bitcoin-dev mailing list. The implementation uses a strategy pattern to address concerns with deploying a block-size increase through a hardfork. Post-fork blocks are constructed to be mapped to valid blocks under pre-fork rules, allowing post-fork miners to create a valid chain indirectly. For non-upgraded clients, the block-size limit is circumvented by moving transaction validation data "outside" of the block, while upgraded clients see an unchanged block layout with a larger block-size limit and a new interpretation of the header Merkle root encoded in the coinbase. This implementation reduces fraud risk and requires miner majority to force miner consensus.A concern has been raised about the safety of old clients not being able to see transactions due to a new transaction blocking feature. It is suggested that increasing the tx version number could prevent transactions sent from old clients from confirming. The inclusion of this idea in the code remains uncertain.Marco questions whether a proposed approach is actually a soft fork, as it requires nodes to upgrade. He argues that true soft forks don't require any node upgrades and expresses concerns about missing transactions and vulnerability to double spends for non-upgraded nodes. Marco asks if there is something he is missing about the proposal.A proof-of-concept implementation of BIP102 as a softfork has been developed under the unofficial codename BIP102s. It constructs post-fork blocks that can be mapped to valid blocks under pre-fork rules, enabling post-fork miners to create a valid chain indirectly.
Updated on: 2023-08-01T17:19:26.356499+00:00