> Majority hash power does have the ability to determine what gets confirmed. Miners don’t have the ability to decide whether a block is valid. Hash power is only recognized as such if it is used for creating a valid block, i.e., a block that strictly follows all the rules as set by the node software that transacting users choose to run. If suddenly 70% of all hash power decided to start mining blocks that are invalid according to the rules set in the users’ software, then these invalid blocks will be disregarded. From a user perspective, 70% of all hash power will seem to have disappeared. In short, users define what is Bitcoin, not miners. This is fundamental to being decentralized. On Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Jun 29, 2021, at 12:28, Jorge Timón wrote: > >  > "Confirmation" isn't needed for softforks. > > > All transactions require confirmation. Splitting does not change this. > > Softforks are not compatible without miner enforcement. So soft forking > without it has essentially the same effect as hard forking, the chain > splits. > > Miners controlling confirmation doesn't mean miners control the rules, > they never did. > > > Please define “control” because these statements hinge on that word. > Nobody “controls” the rules of others, nor did anyone claim that to be the > case. Majority hash power does have the ability to determine what gets > confirmed. That is the central design principle of proof of work. It takes > that decision out of the hands of politicians and places it at the feet of > the market. > > Read section 11 of the bitcoin paper "even with a majority of hashrate one > cannot arbitrarily change rules or forge signatures. > > > Never claimed that was the case. One can run any rules that one desires. > > You may say users chosing the rules is "politicial". Isn't miners deciding > them for users more political? > > > No, it’s economic. The largest investment in mining (including highest > fees paid to incentivize it) determines censorship resistance. > > Whatever you call it, it is still how free software works: users decide > what to run. > > > A *person* can run whatever software they want. Money requires that others > agree (same rules), and to be money bitcoin requires confirmation. > > It is extremely disappointing to see how few developers seem to ubderstand > this, or even care about users deciding or miners not deciding the rules. > > > It’s poorly understood because there are so many who should know better > making very misleading statements. > > How can we expect users to understand bitcoin when most developers don't > seem to understand it? > > > Clearly we cannot. > > It is really sad. > > On Tue, Jun 29, 2021, 19:17 Eric Voskuil wrote: > >> >> > On Jun 29, 2021, at 10:55, Luke Dashjr wrote: >> > >> > The only alternative to a split in the problematic scenarios are 1) >> concede >> > centralised miner control over the network, >> >> Miners control confirmation, entirely. >> >> This is the nature of bitcoin. And merchants control validation, >> entirely. Anyone can be a miner or a merchant. Neither is inherently >> “better” than the other. The largest merchants are likely a handful of >> exchanges, likely at least as centralized as miners are pooled. >> >> Splitting does not change this. >> >> > and 2) have inconsistent >> > enforcement of rules by users who don't agree on what the correct rules >> are, >> >> There are no “correct” rules. Whatever rules one enforces determine what >> network he chooses to participate in. >> >> > again leading to centralised miner control over the network. >> >> Leading to? Miners control confirmation, always. Whether that is >> centralized, just as with merchanting, is up to individuals. >> >> > In other words, in this context, accepting a split between disagreeing >> users >> > is the ONLY way Bitcoin can possibly continue as a decentralised >> currency. >> >> No, it is not. You are proposing splitting as the method of censorship >> resistance inherent to Bitcoin. Coordinating this split requires >> coordinated action. The whole point of bitcoin is coordinate that action >> based on mining (proof of work). Replacing that with a political process is >> just a reversion to political money. >> >> > Making that split as clean and well-defined as possible not only >> ensures the >> > best opportunity for both sides of the disagreement, >> >> Trivially accomplished, just change a rule. This isn’t about that. It’s >> about how one gets others to go along with the new coin, or stay with the >> old. An entirely political process, which is clearly evident from the >> campaigns around such attempts. >> >> > but also minimises the >> > risk that the split occurs at all (since the "losing" side needs to >> concede, >> > rather than passively continue the disagreement ongoing after the >> attempted >> > protocol change). >> >> Nobody “needs to” concede once a split has occurred, which is evident in >> existing splits. >> >> e >> >> > Luke >> > >> > >> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: >> >> At least we are now acknowledging that splitting is what it’s about. >> That’s >> >> progress. >> >> >> >> e >> >> >> >>>> On Jun 29, 2021, at 01:32, Jorge Timón wrote: >> >>> >> >>>  >> >>> I think the option of "permanent failure because miners veto" should >> >>> actually be abandoned. No, I don't think we should avoid splits when >> >>> possible, I don't think we should avoid splits at all costs. >> >>> >> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud >> wrote: >> >>>> @Luke >> >>>> >> >>>>> They can still slow it down. >> >>>> >> >>>> Absolutely. However I think that the option of permanent failure is >> >>>> important. It certainly would be ideal to ensure that enough bitcoin >> >>>> users support the upgrade *before* releasing it, however >> realistically >> >>>> this can never be more than an estimate, and estimates can sometimes >> be >> >>>> wildly wrong. It would be unfortunate if miners had a substantially >> >>>> different estimate of user support than the people putting in the >> work >> >>>> to release bitcoin upgrades. Even if upgrades are never released >> before >> >>>> it becomes clear that a large supermajority of users want the >> upgrade, >> >>>> if miners don't agree with the estimate a harmful chain split could >> >>>> occur. And I agree with Eric that the goal here is to prevent a chain >> >>>> split during an upgrade when possible. This includes permanent >> failure >> >>>> of an upgrade when there is unexpectedly large miner opposition. >> >>>> >> >>>> This of course does not prevent a UASF-style deployment to be done >> after >> >>>> an initial failure to deploy occurs. My proposal is essentially a >> >>>> mechanism to improve upon the speedy-trial idea, allowing for even >> >>>> speedier releases (than speedy trial) without adding additional risk >> of >> >>>> undesired chain splits. >> >>>> >> >>>>> [BIP8] already has the trinary state you seem to be describing >> >>>> >> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow >> the >> >>>> longest chain, B. Follow the upgrade chain, or C. follow the >> >>>> non-upgraded chain. I agree. However the trinary state in my >> proposal is >> >>>> materially different - it is the signaling itself that is trinary, >> not >> >>>> just which chain is being followed. This allows others to know and >> make >> >>>> programmatic decisions (in software) based on that signaling. I'm >> sure >> >>>> you can agree that does not exist in BIP8. >> >>>> >> >>>>> No additional bit is needed, as softforks are coordinated between >> >>>>> users, NOT miners >> >>>> >> >>>> And yet there is miner involvement, as you rightly pointed out. >> Miners >> >>>> are needed to set the nVersion in the header. So when you say "no >> >>>> additional bit is needed", could you please be clearer as to what you >> >>>> mean? Do you mean that signaling of opposition in a block can be done >> >>>> without any "additional bit"? Or are you just saying that it is >> >>>> redundant to consider what miners might be opposing an upgrade? >> >>>> >> >>>> @Jorge >> >>>> >> >>>>> If different users want different incompatible things... there's no >> >>>>> way to avoid the split >> >>>> >> >>>> I agree. This happened with bcash, and that's fine. It was painful, >> but >> >>>> there were a significant amount of users that disagreed, and they >> have >> >>>> the chain they want now. >> >>>> >> >>>> But we generally all want to avoid a chain split when possible. >> Because >> >>>> chain splits have a cost, and that cost can be high, its likely that >> >>>> many users would rather choose the chain with the most support rather >> >>>> than choosing the chain with their preferred rules. >> >>>> >> >>>> However, the question here is: how do we estimate what fraction of >> users >> >>>> wants which rules? We don't have a divining rod to determine with >> >>>> certainty what users want. We can only make polls of various levels >> of >> >>>> inaccuracy. The methods bitcoin has been using is community >> discussion >> >>>> and social consensus estimation as well as miner signaling during the >> >>>> actual deployment period. Neither of these are perfect, but they are >> >>>> both reasonable enough mechanisms. However, because both of these >> >>>> mechanisms are very rough estimates of user sentiment, we need to >> >>>> consider the possibility that sometimes the estimate may be >> >>>> substantially inaccurate when we design deployment procedures. This >> >>>> inaccuracy is why we need multiple barriers in place for an upgrade, >> and >> >>>> why we need to have higher thresholds of success (require larger >> >>>> supermajorities in both consensus and miner signaling). >> >>>> >> >>>> Developers obviously care about bitcoin and have an incentive >> (personal >> >>>> and probably financial) to do it right. And miners have both an >> >>>> incentive to keep the system healthy, as well as an incentive to >> mine on >> >>>> the chain that the economic majority of users is using. But measuring >> >>>> the consensus of the bitcoin community can be extraordinarily >> difficult >> >>>> to do with consistent accuracy, and so I think miner signaling as it >> has >> >>>> been used as a second barrier to entry for an upgrade is quite >> >>>> appropriate. >> >>>> >> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil >> wrote: >> >>>>> I have not objected to anyone splitting. As I said, a split is >> always >> >>>>> possible, and of course has been done on a large scale. It is only >> the >> >>>>> misleading statements about inherent soft fork “compatibility” and >> the >> >>>>> implication that activation without hash power enforcement does not >> >>>>> create a split that I object to. People who know better should be >> >>>>> honest about it. >> >>>>> >> >>>>> Far too many people have been led to believe there is some sort of >> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed >> down”). >> >>>>> There is only a choice between creating a split and hash power >> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible - >> >>>>> unless enforced by majority hash power. >> >>>>> >> >>>>> The statements below are grossly misleading and need to be called >> out >> >>>>> as such so that people can actually make this decision you speak of. >> >>>>> This idea that “users” decide the rules is not the question. The >> >>>>> question is only how to avoid a split. If one does not care he can >> >>>>> split at any time, no discussion required. >> >>>>> >> >>>>> e >> >>>>> >> >>>>>> On Jun 27, 2021, at 01:47, Jorge Timón wrote: >> >>>>>> >> >>>>>> If different users want different incompatible things (enough on >> >>>>>> each side), there's no way to avoid the split. We shouldn't try to >> >>>>>> avoid such a split. >> >>>>>> Users decide the rules, not miners nor developers. >> >>>>>> >> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>> Ultimately there is only one answer to this question. Get majority >> >>>>>>> hash power support. >> >>>>>>> >> >>>>>>> Soft fork enforcement is the same act as any other censorship >> >>>>>>> enforcement, the difference is only a question of what people >> want. >> >>>>>>> Given that there is no collective “we”, those wants differ. >> Bitcoin >> >>>>>>> resolves this question of conflicting wants, but it is not a >> >>>>>>> democracy, it’s a market. One votes by trading. >> >>>>>>> >> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is >> >>>>>>> accomplished by mining (or paying others to do so). Anyone can >> mine, >> >>>>>>> so everyone gets a say. Mining is trading capital now for more >> >>>>>>> later. If enough people want to do that, they can enforce a soft >> >>>>>>> fork. It’s time Bitcoiners stop thinking of miners as other >> people. >> >>>>>>> Anyone can mine, and that’s your vote. >> >>>>>>> >> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But >> it’s >> >>>>>>> dishonest to imply that one can do this and all others will surely >> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one >> >>>>>>> that has been shown to not always pay off. >> >>>>>>> >> >>>>>>> e >> >>>>>>> >> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil >> wrote: >> >>>>>>>> >> >>>>>>>> For some definitions of “block”. >> >>>>>>>> >> >>>>>>>> Without majority hash power support, activation simply means you >> >>>>>>>> are off on a chain split. Anyone can of course split off from a >> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this >> >>>>>>>> is a bit of an empty claim. >> >>>>>>>> >> >>>>>>>> Nobody can stop a person from splitting. The relevant question is >> >>>>>>>> how to *prevent* a split. And activation without majority hash >> >>>>>>>> power certainly does not “ensure” this. >> >>>>>>>> >> >>>>>>>> e >> >>>>>>>> >> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade >> >>>>>>>>> entirely. They can still slow it down. >> >>>>>>>>> >> >>>>>>>>> It also already has the trinary state you seem to be describing >> >>>>>>>>> (although perhaps this could be better documented in the BIP): >> >>>>>>>>> users who oppose the softfork can and should treat the >> successful >> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they >> do >> >>>>>>>>> not follow a chain with the rules in force. >> >>>>>>>>> >> >>>>>>>>> No additional bit is needed, as softforks are coordinated >> between >> >>>>>>>>> users, NOT miners (who have no particular say in them, aside >> from >> >>>>>>>>> their role as also being users). The miner involvement is only >> out >> >>>>>>>>> of necessity (to set the bit in the header, which users >> coordinate >> >>>>>>>>> with) and potentially to accelerate activation by protecting >> >>>>>>>>> upgrade-lagging users. >> >>>>>>>>> >> >>>>>>>>> Luke >> >>>>>>>>> >> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev >> >>>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the >> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about >> >>>>>>>>>> ways to solve the problems that both sides brought up. In >> short, >> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners >> failing >> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin >> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point >> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a >> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and >> >>>>>>>>>> have created a proposal >> >>>>>>>>>> < >> https://github.com/fresheneesz/bip-trinary-version-signaling/blo >> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades >> that >> >>>>>>>>>> solve both problems. >> >>>>>>>>>> >> >>>>>>>>>> The proposal uses trinary version signaling rather than binary >> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade, >> this >> >>>>>>>>>> allows for three signaling states: >> >>>>>>>>>> >> >>>>>>>>>> * Actively support the change. >> >>>>>>>>>> * Actively oppose the change. >> >>>>>>>>>> * Not signaling (neither support or oppose). This is the >> default >> >>>>>>>>>> state. >> >>>>>>>>>> >> >>>>>>>>>> Using this additional information, we can release >> non-contentious >> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners >> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppose >> >>>>>>>>>> the change are incentivized to update their software to a >> version >> >>>>>>>>>> that can actively signal opposition to the change. The more >> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock >> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in >> >>>>>>>>>> the proposal, this chart shows how much support signaling would >> >>>>>>>>>> be necessary given a particular amount of active opposition >> >>>>>>>>>> signaling: >> >>>>>>>>>> >> >>>>>>>>>> [image: thresholdChart.png] >> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should >> be >> >>>>>>>>>> relatively safe because it is a supermajority amount that is >> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of >> >>>>>>>>>> miners support the change today, its unlikely that less than a >> >>>>>>>>>> majority of miners would support the change a year or two from >> >>>>>>>>>> now), and if no one is signaling opposition, chances are that >> the >> >>>>>>>>>> vast majority of the other 40% would also eventually signal >> >>>>>>>>>> support. >> >>>>>>>>>> >> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if >> they >> >>>>>>>>>> actually oppose the change while at the same time allowing >> these >> >>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork >> >>>>>>>>>> activation much. >> >>>>>>>>>> >> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrade >> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready >> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to >> discuss >> >>>>>>>>>> this will only delay things and cause contention again like it >> >>>>>>>>>> did with taproot. >> >>>>>>>>>> >> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I >> >>>>>>>>>> would appreciate any comments here, or written as github issues >> >>>>>>>>>> on the proposal repo itself. >> >>>>>>>>>> >> >>>>>>>>>> Thanks, >> >>>>>>>>>> BT >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> bitcoin-dev mailing list >> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org >> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> bitcoin-dev mailing list >> >>>>>>> bitcoin-dev@lists.linuxfoundation.org >> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >