Published on: 2017-05-20T05:05:43+00:00
The email thread discusses different approaches to ensuring that the timeout for versionbits is specified. One approach suggested is to bundle a pair of similar transactions, one with transaction version bits set and another with locktime set. Another approach is to use input height, which invalidates a transaction in a block if the soft-fork has not timed out or activated, the block does not signal bit N, the transaction version does signal bit N and at least one input to the transaction has a height >= S. This approach also allows for bit reuse and is compatible with using bitcoin days destroyed as a weighting measure.The discussion on versionbits and its behavior after deployment timeout was the subject of communication between Russell O'Connor and Luke Dashjr. It was suggested that a user can add a timeout by bundling a pair of similar transactions, one with the transaction version bits set and another with a locktime set. Later, a proposal by Dashjr suggested adding a subset of nVersion to simplify the process while using fewer precious nVersion bits. The proposal allows specifying a single bit and only supports BIP8/9-style signalling.The proposal presented is deemed imperfect by the writer, as it rewards signalling whereas the end goal is activation. The writer suggests a different approach that would reward activation and proposes an opcode to create an assurance contract for activation of a softfork. They acknowledge their limited knowledge about Bitcoin's codebase but believe the suggested spec is workable. Additionally, the writer highlights the possibility of inverse logic wherein a vote against a softfork can be cast.On May 13, 2017, Luke Dashjr emailed about the need to specify a timeout for versionbits to avoid losing their meaning after deployment. Users can bundle a pair of similar transactions, one with transaction version bits set and another with a locktime set to add a timeout. Dashjr's formal condition includes a check for block version, but it does not prevent upgrading versionbits. Any txVersion that does not begin with 0b001 is unconditionally acceptable and available for further soft-forking.In a discussion on Bitcoin development, Peter Todd and another user debated the idea of users paying for signalling of softforks. The other user argued that as long as the deployment of the softfork is widespread, the risk of users not paying is minimal. Peter Todd countered by saying that this assumption relies on the notion that the users who pay for soft-fork signalling will represent an economic majority, which may not always be the case. He suggests that if the economic majority hasn't consented to the softfork, many users will make their transactions conditional on non-signalling.The discussion involves potential issues with nVersion signaling, which is difficult to enforce. Users are responsible for adoption of rules and paying miners for signaling certain bits can further complicate the situation. The risk of false signaling is minimal if deployment of the softfork is widespread, but it could lead to a breakdown in honesty of the nVersion system if users pay prematurely. There is concern that users paying for soft-fork signaling may not represent an economic majority and miners could take extra fees provided by a small percentage of users while violating the nVersion protocol. Additionally, the discussion highlights concerns with the inadequacy and unreadability of English language specifications; it is suggested to use the "reference implementation" as the specification instead.The discussion between Luke Dashjr and Eric Voskuil revolves around the issue of mining centralization in Bitcoin. Dashjr contends that most people cannot mine except at a huge expense, so the profits from every miner you buy will go to pay for Bitmain growing their arsenal more than enough to offset your influence. Voskuil disagrees that nobody should mine because it's a zero-sum game that one miner will always win and therefore we should not push up the hash rate by trying to compete because the same miner just makes more money on the hardware. He argues that there is nothing inherently wrong with paying people to run nodes or signal "readiness," but there is no reason whatsoever to consider these ideas beneficial from a personal/economic or security/decentralization standpoint.In an email thread, Eric Voskuil argues that mining is broken and it is difficult for people to influence miners without incurring a huge expense. He also suggests that paying people to run nodes or signal readiness is not beneficial from either personal/economic or security/decentralization standpoint. Eric's argument assumes that miners are a government or control Bitcoin in some way, which is incorrect. Miners are entrusted with enforcement of softforks, and their refusal to do so is considered an attack on the network.In this message, ZmnSCPxj argues that it is economically logical for some people to pay fees to others with better Bitcoin to hash rate conversion rates rather than suffering a lower conversion rate due to differences in electricity rates depending on country. However, the author of the message disagrees, stating that this is simply an argument for all people to pay one person.
Updated on: 2023-08-01T20:37:33.597196+00:00