From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11274C0012 for ; Sat, 26 Mar 2022 01:46:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DC5C060B6B for ; Sat, 26 Mar 2022 01:45:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MONEY_NOHTML=1.533, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chy6fx_rFyCF for ; Sat, 26 Mar 2022 01:45:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp3.osuosl.org (Postfix) with ESMTPS id 98EC7607E3 for ; Sat, 26 Mar 2022 01:45:57 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1nXvV0-0003kc-E1; Sat, 26 Mar 2022 11:45:52 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sat, 26 Mar 2022 11:45:46 +1000 Date: Sat, 26 Mar 2022 11:45:46 +1000 From: Anthony Towns To: Jorge =?iso-8859-1?Q?Tim=F3n?= , Bitcoin Protocol Discussion Message-ID: <20220326014546.GA12225@erisian.com.au> References: <20220315154549.GA7580@erisian.com.au> <20220322234951.GB11179@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Speedy Trial X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2022 01:46:00 -0000 On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev wrote: > Sorry, I won't answer to everything, because it's clear you're not listening. I'm not agreeing with you; that's different to not listening to you. > In the HYPOTHETICAL CASE that there's an evil for, the fork being evil > is a PREMISE of that hypothetical case, a GIVEN. Do you really find people more inclined to start agreeing with you when you begin yelling at them? When other people start shouting at you, do you feel like it's a discussion that you're engaged in? > Your claim that "if it's evil, good people would oppose it" is a NON > SEQUITUR, "good people" aren't necessarily perfect and all knowing. > good people can make mistakes, they can be fooled too. > In the hypothetical case that THERE'S AN EVIL FORK, if "good people" > don't complain, it is because they didn't realize that the given fork > was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY > DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the > hypothetical case where there's a fork some people think it's evil but > it's not really evil. The problem with that approach is that any solution we come up with doesn't only have to deal with the hypotheticals you want to discuss. In particular, any approach that allows you to block an evil fork, even when everyone else doesn't agree that it's evil, would also allow an enemy of bitcoin to block a good fork, that everyone else correctly recognises is good. A solution that works for an implausible hypothetical and breaks when a single attacker decides to take advantage of it is not a good design. And I did already address what to do in exactly that scenario: > > But hey what about the worst case: what if everyone else in bitcoin > > is evil and supports doing evil things. And maybe that's not even > > implausible: maybe it's not an "evil" thing per se, perhaps [...] > > > > In that scenario, I think a hard fork is the best choice: split out a new > > coin that will survive the upcoming crash, adjust the mining/difficulty > > algorithm so it works from day one, and set it up so that you can > > maintain it along with the people who support your vision, rather than > > having to constantly deal with well-meaning attacks from "bitcoiners" > > who don't see the risks and have lost the plot. > > > > Basically: do what Satoshi did and create a better system, and let > > everyone else join you as the problems with the old one eventually become > > unavoidably obvious. > Once you understand what hypothetical case I'm talking about, maybe > you can understand the rest of my reasoning. As I understand it, your hypothetical is: 0) someone has come up with a bad idea 1) most of bitcoin is enthusiastically behind the idea 2) you are essentially alone in discovering that it's a bad idea 3) almost everyone remains enthusiastic, despite your explanations that it's a bad idea 4) nevertheless, you and your colleagues who are aware the idea is bad should have the power to stop the bad idea 5) bip8 gives you the power to stop the bad idea but speedy trial does not Again given (0), I think (1) and (2) are already not very likely, and (3) is simply not plausible. But in the event that it does somehow occur, I disagree with (4) for the reasons I describe above; namely, that any mechanism that did allow that would be unable to distinguish between the "bad idea" case and something along the lines of: 0') someone has come up with a good idea (yay!) 1') most of bitcoin is enthusiastically behind the idea 2') an enemy of bitcoin is essentially alone in trying to stop it 3') almost everyone remains enthusiastic, despite that guy's incoherent raving 4') nevertheless, the enemies of bitcoin should have the power to stop the good idea And, as I said in the previous mail, I think (5) is false, independently of any of the other conditions. > But if you don't understand the PREMISES of my example, You can come up with hypothetical premises that invalidate bitcoin, let alone some activation method. For example, imagine if the Federal Reserve Board are full of geniuses and know exactly when to keep issuance predictable and when to juice the economy? Having flexibility gives more options than hardcoding "21M" somewhere, so clearly the USD's approach is the way to go, and everything is just a matter of appointing the right people to the board, not all this decentralised stuff. The right answer is to reject bad premises, not to argue hypotheticals that have zero relationship to reality. Cheers, aj