rich1.0npub1kkr20dcfa7a27uqrlkryqwxangtngc9nmx9cdlpyp3yvq37s8wsqz7fx4ehttps://nostr.ae/npub1kkr20dcfa7a27uqrlkryqwxangtngc9nmx9cdlpyp3yvq37s8wsqz7fx4enjumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:For soft forks, consensus is required. In fact, we (today) have miners who individually choose to mine blocks that are completely empty, with no known input from (or communication with) the outside world. This is a consensus process. Users can switch back and forth all they like, and this only happens when there is unanimous miner-developer consensus. Most of the time they don't even know, that they are under consensus. It is only "controversial hard forks" which DON'T require wide agreement and developer endorsements. Hear me out. This is because, with zero dev-agreement, we have two benefits: first, there are tremendous security issues which can be fixed by trying more than one hard fork at once (these fixes can prevent loss of funds), and, second, because each fork is equally Acked and Nacked (a Schrodinger's Ack, if you will), they will have equal standing, and therefore users will be equally indifferent to both forks and they will both live for a long time (and users will be able to pick the fork that best fits them, empowering the user). People have overlooked how simple this issue is because of the political climate. We need a climate change, pardon the pun. On Mon, Oct 5, 2015 at 2:33 PM, Tom Zander via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote: > > > Unsuccessfully. > > > > I think rather successfully. > > Arguing that BIP66 rollout was a full success is in the same park of > "successful" ? > Where for weeks people were told not to trust the longest chain until it > was > 30 blocks. > Lets put that in perspective. The main functionality of Bitcoin > Frankly, if that fiasco happened in a company, people would get fired for > gross misconduct. > > Bottom line is that there is a horrible track record of doing soft forks in > the past, there are some really good technical reasons why this should not > happen again. > > And the defence against this argument is to do character assassination > because > you think he has ulterior motives? Like you say in this part; > > > That Mike himself continues to misexplain > > things is not surprising since he has all but outright said that his > > motivation here is to disrupt Bitcoin in order to try to force his > > blocksize hardfork on people. > > "all but outright said" is still not said. Is still just a suspicion you > have. > And you are accusing a man of something he didn't do. > That’s just not right. > > > > The point is that Bitcoin Core claims to have a consensus mechanism and > > > sticks to "no change" on not reaching a consensus. And that rule is the > > > reason why bigger blocks were blocked for years. > > > > You're repeating Mike's claims there-- not anyone elses. Take your > > complaint up with him-- not the list. > > There is no complaint. Why do you think there is? > Are you claiming that not reaching consensus is NOT the reason that bigger > blocks are not in Bitcoin Core? > > > Reaching consensus is an admirable goal. But its exactly that, a goal. > And anyone that is a perfectionist will know that in the real world goals > are > often not reached. That doesn't make them less useful. That makes them > goals. > This specific goal is in conflict of building a good product and a well > functioning community. > > A good product and a well functioning community needs rules and needs > timely > decisions and conflict resolution. > It does not need muting of valuable voices, it does not need character > assassinations and it really doesn't need egos. > > I suggest reading this book; > http://www.artofcommunityonline.org/ > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/ff7bea8c/attachment-0001.html>