Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C7A3EC000E for ; Wed, 30 Jun 2021 08:55:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B5F9040137 for ; Wed, 30 Jun 2021 08:55:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcBlQ2bzu8o2 for ; Wed, 30 Jun 2021 08:55:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by smtp2.osuosl.org (Postfix) with ESMTPS id 3E1A6402E3 for ; Wed, 30 Jun 2021 08:55:48 +0000 (UTC) Received: by mail-pl1-x62c.google.com with SMTP id z4so1071859plg.8 for ; Wed, 30 Jun 2021 01:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=2Xtfy5GqrUdbqxW0mbGyXnKsULjlR7fDR43OVxiEI4U=; b=UBCp7d9wSr/Osgi1ArA3g0RmQW+B3GsTPkQtZigBoxNaie+wnsK3ZbsKyLgL4E9+BY KQ6TBDyL2p/ECskt7VEq0V7xgfE9vZaSQL0pFdTJdTPWavVUHZp2bioUhYg6FW9dghc1 JdRdPnBNeZ8+gnxQ9b/JQ+Fb8yEAlUamG/ONiwI3+H+P+FN38ByO9fyYeC52xF5bFGbX zmQHSwBeJ8PqtsM+NLR84VaZ27DOKc+eZK7Hv1rbIC6JzDLZlDbkvAtXupv8drwsevT9 R5WCP12te7wV3oQPePCsHGeWtQIpUtsDz36pGtKycdEaxuQgvD5i2Yd+7i89WlU6ImXS Aa8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=2Xtfy5GqrUdbqxW0mbGyXnKsULjlR7fDR43OVxiEI4U=; b=RV6WH/0+xA0nXLSnTik/5sphmkAPivAnDofTqa2cyOIpqd01oRpaBcFa6JTf+pXpvr +ZVyIredoBy34Fndwto9T8AyBLgBJFup1q3Y4QQvnTFfSTVnnMDJLuszLBibhELCFwfv zqbn2RLh9z5EE8TQ2O9AcLDao0ZFcXTp2pHMS0OWZR9bT1YoWYAVxFu9sQsjAlZ5TleR zNniIuvA3boeDxcCdDIGRkaaRphaZTBZjoMQyQVsXp+AlBL9ofj1QM5StFQejB5/VS/J DtHjWWuVxDDsyxvJOaubucaskJ9EJriRZQFLXyWY3Dr+fo0tzrPITaLRKn9WaYmKg29w +hTA== X-Gm-Message-State: AOAM531JRsZWgbS2inIUSj++ZZgI+16D+8qwUwdeZqfGCPb16jekRRMW DZ6SC0ZR6Q/B1uyzfmL3+rTm/Q== X-Google-Smtp-Source: ABdhPJzLMJZs4Whij513I3restW3i/S3b51HX+3QdQBW0Ork8m9IlVByLH0nyC4FfZ1yXw2hTKQk6Q== X-Received: by 2002:a17:90a:df10:: with SMTP id gp16mr3433056pjb.164.1625043347614; Wed, 30 Jun 2021 01:55:47 -0700 (PDT) Received: from ERICDESKTOP ([2601:600:9c00:1d0::9d25]) by smtp.gmail.com with ESMTPSA id z26sm17131623pfk.112.2021.06.30.01.55.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jun 2021 01:55:47 -0700 (PDT) From: To: "'Billy Tetrud'" References: <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org> In-Reply-To: Date: Wed, 30 Jun 2021 01:55:47 -0700 Message-ID: <020101d76d8d$b86397f0$292ac7d0$@voskuil.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0202_01D76D53.0C05F870" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGzRHqRlNUnlmfFxKP28gVDQPjFFgHW7TzYAa1DJcarWGSOAA== Content-Language: en-us Cc: 'Bitcoin Protocol Discussion' Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades 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: Wed, 30 Jun 2021 08:55:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0202_01D76D53.0C05F870 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All good questions. =20 > Is the goal here to do what the economic majority wants, or some other = group? If so, do you think we have an accurate way of measuring what the = economic majority wants? =20 It=E2=80=99s important that people understand that = =E2=80=9Ceconomic=E2=80=9D does not refer to people interested in, = HODLing, coding, or selling Bitcoin. It is only those who are *presently = accepting* it. We refer to these as =E2=80=9Ceconomic nodes=E2=80=9D. = Those are the people with the economic power to reject coin that they = consider invalid. Only their validation is of any economic consequence = in the event of a split. I see no reason to assume that the economy is = any less centralized than mining is pooled. Today the support of the = economy would be best measured by meeting with exchange operators. If = they did not go along, any unenforced soft fork (split) would isolate = everyone who thought they could continue to trade their coin on = exchanges. =20 I=E2=80=99d also question the use of the term = =E2=80=9Cmajority=E2=80=9D. It applies to hash power, by design, but not = to the economy. A split of any size is possible, requiring no majority. = All it requires is other people to trade with. =20 Exchanges are highly regulated and compliant institutions. Mining = operations are heavily pooled. Neither of these is inherently better = than the other. Everyone can have a say by being a miner or being a = merchant. Subeconomies can split, majority hash power can censor (which = is the exact mechanism of soft fork enforcement). These ideas are = straightforward and hardly worthy of debate. The interesting question is = how one gets others to go along with his new coin. Make no mistake, any = rule change (soft or hard) is a new coin. If hash power doesn=E2=80=99t = enforce the new rules of a soft fork, the chain is split just as if it = was a hard fork. =20 I=E2=80=99m sure people will continue to try and devise ways to figure = out who wants to come along, to try and convince people (including = exchanges and miners) to do so, to reassure them that everyone else will = =E2=80=9Chave to=E2=80=9D, and to mislead them about the actual behavior = and risks. We=E2=80=99ve seen permanent splits, and we=E2=80=99ve seen = hash power enforced soft forks. We=E2=80=99re likely to see more of = both. But as core devs we have a responsibility to inform people, = honestly, and let them decide. My only beef with this whole process has = been that a widespread belief had formed, supported by far too many core = devs (and even embedded in the text of deployed BIPs), that soft forks = are inherently =E2=80=9Cbackward compatible=E2=80=9D. This is = unequivocally not true. The only such compatibility is majority hash = power enforcement of a soft fork. This is not a matter of opinion, = it=E2=80=99s the core innovation of Bitcoin. Proof of Work settles the = question of who has authority to order transactions. Majority hash power = has that authority. Merchants can split again and again, but their = miners will still have that authority. If one wants a say, one can mine. =20 e =20 From: Billy Tetrud =20 Sent: Tuesday, June 29, 2021 7:03 PM To: Eric Voskuil Cc: Jorge Tim=C3=B3n ; Luke Dashjr ; = Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork = upgrades =20 @Jorge =20 >I don't think we should avoid splits at all costs. =20 I absolutely agree that we shouldn't avoid splits at all costs. There = are some costs too high to pay to avoid a split. If an economic majority = started wanting to increase bitcoin's blocksize to 1 GB next year, we = should absolutely hard fork away from that mess with a minority chain.=20 =20 > I don't think we should avoid splits when possible,=20 =20 I want to see why exactly we disagree about avoiding chain splits "when = possible". Are you really saying that we should just hard fork every = time instead of soft fork? Should we even bother to get widespread buy = in at all, or should we just release the software, hardfork away, and = let anyone that wants to follow us follow us later? Are you not at all = worried about the costs associated with an increased orphan rate and = reorg rate? Are you not worried that an update might happen too fast and = that a significant fraction of people that could have come along with us = to the new update might be left behind because they didn't have time to = evaluate the changed rules? =20 Do you agree that, in a conversation about rule changes, some people = want it their way no matter what and will hardfork to get the rules they = want, and some people want it their way, but only if enough other people = agree to follow those rules too? Some people might want a rule change, = but aren't willing to follow, say, a 20% minority fork. Perhaps their = personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people = exist?=20 =20 If you do, then I don't understand why you disagree that we should avoid = chain splits even "when possible". Maybe you could elaborate as to what = you mean there.=20 =20 @Luke =20 Are you in agreement with Jorge here that we should not even attempt to = avoid chain splits?=20 =20 > The only alternative to a split in the problematic scenarios are 1) = concede centralised miner control over the network, and 2) have = inconsistent enforcement of rules by users who don't agree on what the = correct rules are, again leading to centralised miner control over the = network. =20 There is not simply a binary "do or do not". There is also timing. = Non-contentious changes can happen fast. Contentious changes need more = time for discussion, preparation, or coordination, even if the eventual = outcome is the same. Do you disagree that timing issues can be = important, that delays can be useful and help to avoid chain splits? Do = you agree that miners have a (large) incentive to follow the economic = majority? Is the goal here to do what the economic majority wants, or = some other group? If so, do you think we have an accurate way of = measuring what the economic majority wants? Will that mechanism continue = to be accurate into the future?=20 =20 I'm asking these questions to try and figure out why we disagree here. ------=_NextPart_000_0202_01D76D53.0C05F870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All good = questions.

 

> Is the goal here to do what the economic = majority wants, or some other group? If so, do you think we have an = accurate way of measuring what the economic majority = wants?

 

It=E2=80=99s important that people understand that = =E2=80=9Ceconomic=E2=80=9D does not refer to people interested in, = HODLing, coding, or selling Bitcoin. It is only those who are = *presently accepting* it. We refer to these as =E2=80=9Ceconomic = nodes=E2=80=9D. Those are the people with the economic power to reject = coin that they consider invalid. Only their validation is of any = economic consequence in the event of a split. I see no reason to assume = that the economy is any less centralized than mining is pooled. Today = the support of the economy would be best measured by meeting with = exchange operators. If they did not go along, any unenforced soft fork = (split) would isolate everyone who thought they could continue to trade = their coin on exchanges.

 

I=E2=80=99d = also question the use of the term =E2=80=9Cmajority=E2=80=9D. It applies = to hash power, by design, but not to the economy. A split of any size is = possible, requiring no majority. All it requires is other people to = trade with.

 

Exchanges are highly regulated and compliant = institutions. Mining operations are heavily pooled. Neither of these is = inherently better than the other. Everyone can have a say by being a = miner or being a merchant. Subeconomies can split, majority hash power = can censor (which is the exact mechanism of soft fork enforcement). = These ideas are straightforward and hardly worthy of debate. The = interesting question is how one gets others to go along with his new = coin. Make no mistake, any rule change (soft or hard) is a new coin. If = hash power doesn=E2=80=99t enforce the new rules of a soft fork, the = chain is split just as if it was a hard fork.

 

I=E2=80=99m = sure people will continue to try and devise ways to figure out who wants = to come along, to try and convince people (including exchanges and = miners) to do so, to reassure them that everyone else will =E2=80=9Chave = to=E2=80=9D, and to mislead them about the actual behavior and risks. = We=E2=80=99ve seen permanent splits, and we=E2=80=99ve seen hash power = enforced soft forks. We=E2=80=99re likely to see more of both. But as = core devs we have a responsibility to inform people, honestly, and let = them decide. My only beef with this whole process has been that a = widespread belief had formed, supported by far too many core devs (and = even embedded in the text of deployed BIPs), that soft forks are = inherently =E2=80=9Cbackward compatible=E2=80=9D. This is unequivocally = not true. The only such compatibility is majority hash power enforcement = of a soft fork. This is not a matter of opinion, it=E2=80=99s the core = innovation of Bitcoin. Proof of Work settles the question of who has = authority to order transactions. Majority hash power has that authority. = Merchants can split again and again, but their miners will still have = that authority. If one wants a say, one can mine.

 

e

 

From: Billy Tetrud = <billy.tetrud@gmail.com>
Sent: Tuesday, June 29, 2021 = 7:03 PM
To: Eric Voskuil = <eric@voskuil.org>
Cc: Jorge Tim=C3=B3n = <jtimon@jtimon.cc>; Luke Dashjr <luke@dashjr.org>; Bitcoin = Protocol Discussion = <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: = [bitcoin-dev] Trinary Version Signaling for softfork = upgrades

 

@Jorge

 

>I don't think we should avoid splits at all = costs.

 

I = absolutely agree that we shouldn't avoid splits at all costs. There are = some costs too high to pay to avoid a split. If an economic majority = started wanting to increase bitcoin's blocksize to 1 GB next year, = we should absolutely hard fork away from that mess with a minority = chain. 

 

>  I don't think we should avoid splits when = possible, 

 

I = want to see why exactly we disagree about avoiding chain splits = "when possible". Are you really saying that we should just = hard fork every time instead of soft fork? Should we even bother to get = widespread buy in at all, or should we just release the software, = hardfork away, and let anyone that wants to follow us follow us later? = Are you not at all worried about the costs associated with an increased = orphan rate and reorg rate? Are you not worried that an update might = happen too fast and that a significant fraction of people that could = have come along with us to the new update might be left behind because = they didn't have time to evaluate the = changed rules?

 

Do you agree that, in a conversation about rule = changes, some people want it their way no matter what and will hardfork = to get the rules they want, and some people want it their way, but only = if enough other people agree to follow those rules too? Some people = might want a rule change, but aren't willing to follow, say, a 20% = minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or = 90%. Do you agree those people exist? 

 

If you do, then I don't understand why you disagree = that we should avoid chain splits even "when possible". Maybe = you could elaborate as to what you mean = there. 

 

@Luke

 

Are you in agreement with Jorge here that we should = not even attempt to avoid chain = splits? 

 

> The only alternative to a split in the = problematic scenarios are 1) concede centralised miner control over the = network, and 2) have inconsistent enforcement of rules by users who = don't agree on what the correct rules are, again leading to centralised = miner control over the network.

 

There is not simply a binary "do or do not". = There is also timing. Non-contentious changes can happen fast. = Contentious changes need more time for discussion, preparation, or = coordination, even if the eventual outcome is the same. Do you = disagree that timing issues can be important, that delays = can be useful and help to avoid chain splits? Do you agree that = miners have a (large) incentive to follow the economic majority? Is the = goal here to do what the economic majority wants, or some = other group? If so, do you think we have an accurate way of measuring = what the economic majority wants? Will that mechanism continue to be = accurate into the future? 

 

I'm asking these questions to try and figure out why = we disagree here.

------=_NextPart_000_0202_01D76D53.0C05F870--