Author: Nick ODell 2016-01-04 18:04:29
Published on: 2016-01-04T18:04:29+00:00
The conversation in this email thread on the Bitcoin-dev mailing list revolves around the idea of a "generalized soft fork" proposed by Joe. Marco Falke expresses his doubts about the proposal and argues that it requires nodes to upgrade, which contradicts the definition of a soft fork. Joe clarifies that while it is not technically a soft fork, it has all the properties of one except for meaningful backwards compatibility for non-upgraded clients. Marco also raises concerns about how non-updated nodes would verify the collected fees without actual transactions at hand, and points out that a hard fork would be cleaner in terms of code changes. Joe agrees that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients in case of a contentious issue like block size limit. He argues that a "firm soft fork" could be a better option than a hard fork or keeping the blocksize limit unchanged forever. However, Joe also 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. Overall, the email thread discusses the advantages and disadvantages of different approaches towards resolving issues related to the block size limit in Bitcoin and the risks associated with them.
Updated on: 2023-06-11T02:48:48.222788+00:00