-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:
Peter, > Yes, it is different. It’s different because the future network > upgrade to larger blocks includes a loosening of the consensus > ruleset whereas previous upgrades have included a tightening of the > rule set. (BTW—this is not my proposal, I am describing what I > have recently learned through my work with Bitcoin Unlimited and > discussions with miners and businesses). The repeated use of the term "network upgrade" in place of the accepted technical term (hard fork) is misleading. This and the presupposition that the hard fork is coming, and the claims that it's not your proposal, make me feel like I'm shopping for a used car... It's not used it's pre-owned, everyone's getting the warranty, let me see what my manager has to say about the price - it's not my decision. This is a development list. Avoidance of standardized terminology and use of the presumptive close diminishes your message. > With a tightening of the rule set, a hash power minority that has > not upgraded will not produce a minority branch; instead they will > simply have any invalid blocks they produce orphaned, serving as a > wake-up call to upgrade. "tightening of the rule set" == soft fork This implies that the minority hash power is producing blocks that are valid according to rules in existence prior to the soft fork. You are referring to these as invalid, but because this has already confused one commentator, let's be clear. The blocks you are referring to are valid blocks being orphaned because the majority hash power is rejecting them because of soft fork activation. This of course produces a minority chain, so this statement is incorrect. > With a loosening of the consensus rule set, the situation is > different: a hash power minority that has not upgraded will produce > a minority branch, that will also drag along non-upgraded node > operators, leading to potential confusion. "loosening of the consensus rule set" == hard fork This is also incorrect. In the case of a hard fork old nodes reject the new blocks that are invalid according to old rules and continue to accept other old blocks. This produces a second distinct chain. It is neither a majority nor a minority chain with respect to the original. It is simply a new coin that happens to share history with the old coin. This doesn't imply confusion, since both chains continue to operate under the rules of their nodes. The only confusion arises from people wanting to transaction across *both* chains. It is only in this context that replay becomes an issue. > The idea behind orphaning the blocks of non-upgraded miners was to > serve as a wake-up call to upgrade, to reduce the chances of a > minority chain emerging in the first place, similar to what happens > automatically with a soft-forking change. If one's worry is a > chain split, then this seems like a reasonable way to reduce the > chances of that worry materializing. The Level 3 anti-split > protection takes this idea one step further to ensure that if a > minority branch does emerge, that transactions cannot be confirmed > on that branch. Stopping people from transacting on the old chain due to an ongoing 51% attack (again, using proper terminology) is one way to make it hard for people to transact on both chains. But if you don't care that people are able to transact on both chains, there's no reason to spend the money on the attack. So let me point to the elephant in the room. The proposed 51% attack is more obviously an attempt to transfer economic activity from BTC to BTU, not a benevolent measure to prevent confusion. It can clearly be viewed as elimination of competition through an electronic attack on BTC operations. Given that they are all regulated entities, I'm not sure how the envisioned large miner collaborators (or others who might fund it) will feel about participation in the scheme. > This is not a fight about “Core vs. BU”; Bitcoin’s future is one > of “genetic diversity” with multiple implementations, so that a bug > in one doesn’t threaten the network as a whole You are right that this is not about Core and BU. These are implementations, not protocols. However, please do not presume that other implementations are enlisted in your scheme, or that this is about making the network more bug-resistant. > To me it seems this is largely a fight about whether node operators > should be easily able to adjust the size of blocks their nodes > accept. BU makes it easy for node operators to accept larger > blocks; Core doesn’t believe users should have this power (outside > of recompiling from source, which few users can do). I feel like making the block size a configuration option in Libbitcoin just to emphasize the gross error of this idea. It has never been about the inability of users to compile the code. It's about the purposeful difficulty in changing the rules when everyone has a say. > Once again, this is not my proposal. I am writing about what I > have come to learn over the past several weeks. When I first heard > about these ideas, I was initially against them too. They seemed > harsh and merciless. It wasn’t until I got out their and started > talking... The idea was so powerful you were converted (another sales tactic). Who's proposal is this? Can they not speak for themselves? > So I guess the “ethics” here depend on the lens through which one > is looking... These are not ethical questions. These are development questions, built on economic concepts, backed by individual financial decisions. There is no equivalence of ideas based on one's arbitrary perspective. > But if one's intention is to split and not follow the majority > hash power when blocks become larger, The "split" is always by the one that hard forks. The splitter is the one who changes what exists and therefore creates something new. Please fix your terminology. > then why not change the proof-of-work? This would certainly result > in a peaceful splitting, as you said you desire. A hard fork, including changing the PoW algorithm, requires the purposely improbable coordination of the economy in the creation of a new coin and the abandonment of the old. This should be apparent from the ongoing block size hard fork attempts. e -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJY2D2SAAoJEDzYwH8LXOFO3r0H/R0PTi2x15Zj1oceOqcNpP4k /TrTohFl/BRE4PaOqJ9n9DbJ6W8rnAjRnguOIgOB1CSIRCuy73AQ4aqRSTCBlHbe VVrlKKFS8zh50Cjg8tlnomWeKe1YDO31R2Avises+Dr3kyqQ9+QYtOoqxvuvYrXo B03fjPIL0eTQypA4KP/W7CxrlHN7oyN+PtehpI51JOGMxx6Xc0RDelGz1NTlQQ1f 90Axeey51tgAzJ8wsC+Vf22hZdU06VDdtG8PSHVcrELoicDnEjR4T+1XqA1hcAY2 hWBX5qpQYJqJv1ypfTH0ouh6QtLhJZGCWzKZnpH+T7d3FUG+AXn0UjTP3Nkh7NY= =Cc8r -----END PGP SIGNATURE----- _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
