Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 38F0AB4A for ; Fri, 16 Jun 2017 14:39:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f195.google.com (mail-pf0-f195.google.com [209.85.192.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B7EC23D for ; Fri, 16 Jun 2017 14:39:33 +0000 (UTC) Received: by mail-pf0-f195.google.com with SMTP id w12so6835273pfk.0 for ; Fri, 16 Jun 2017 07:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JU+WiMuec7KTQ6B/EtkYXWNXwfh8rVFUpb4KAFfMdgY=; b=Li5PdCwA6WgWSTQKZoVSWaTVznU7FTmCM415tyknSKho7+FlDKZ/Pm62dMsB1K1cZY kFKGUvpfSFUYmcZCYEWc/IBHBeqbfTUcVkGF+ANnz76QCXWCSymxY4Guw3T/npBc876k TZ3bMEo0SY3fCaYfOE/t789f36yOD7Vb4jPQnnCukpAnp8pD8NbE5n32du0dp6uNpX7q Tf1wxgkW+Iny4rpl+rzuSFt4SUu89w6qbscmuZQvg5I4drbYgv7LXd41qSH+aUJYnjm1 3o8tcVorSiLQFxYqDlkUmNVTe29YF/3T4cKtjEm+U3hDkIVjaCgcAHImQleYrsexNITJ tXtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JU+WiMuec7KTQ6B/EtkYXWNXwfh8rVFUpb4KAFfMdgY=; b=Us0NQe2+R4v8yT45JabCZyPx2/mG8kJi+Vz77iKTLls33p0+v0vO263v5EWozauxv2 0L6FMKK43dgVYSYHQ7YBEv3xEMq0SLFPoJvgI9aCBSYlU7AL30AHYZ+MX/1NAr/e5eh3 WYIN2C1YouIZiHvP2kKDTwkao11aNQQ02/XZgYjSBcMGnh1viUArRkWKjhAhyGdvzKhi qqyiwvE1iImkdC3ROmA/6Zei9xQQFqgak7e6cmeIb2k8GY8c85+O5jWh84PsXjCpUlqA 6IrJiSQtb/yc6V6mBMz5dH23ODdf2Q9ALCdMBqKyc/23UXdnVW3dwkQ1TJ8z4vwcWuPs +MXQ== X-Gm-Message-State: AKS2vOwO0PXk4gEnJf92CgxF7K7V7i7kZLF2RBFH2lBfrEpMlIKbjPIv EqdVml4IzFKRIg== X-Received: by 10.98.24.69 with SMTP id 66mr11406368pfy.132.1497623972967; Fri, 16 Jun 2017 07:39:32 -0700 (PDT) Received: from [192.168.1.26] ([110.84.170.198]) by smtp.gmail.com with ESMTPSA id v62sm4697959pfb.124.2017.06.16.07.39.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 07:39:31 -0700 (PDT) From: Zheming Lin Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_78FE48AE-7442-4E15-B951-7AF7D27EB8A6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 16 Jun 2017 22:39:26 +0800 In-Reply-To: To: Jameson Lopp References: <31040BE1-64ED-4D05-BCBE-E80BC7B9A182@gmail.com> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 16 Jun 2017 15:21:04 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 14:39:37 -0000 --Apple-Mail=_78FE48AE-7442-4E15-B951-7AF7D27EB8A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb2312 Will there be a =A1=B0Do nothing=A1=B1 soft fork, showing that the = community can still moving forward? So all the nodes get to upgrade to use tx version 2, and that avoid a = chain split. Are you support that or against that, why? Regards, LIN Zheming > =D4=DA 2017=C4=EA6=D4=C215=C8=D5=A3=AC=C9=CF=CE=E74:11=A3=ACJameson = Lopp =D0=B4=B5=C0=A3=BA >=20 >=20 >=20 > On Wed, Jun 14, 2017 at 12:04 PM, Zheming Lin > wrote: > Hi Jameson: >=20 >> =D4=DA 2017=C4=EA6=D4=C215=C8=D5=A3=AC02:55=A3=ACJameson Lopp = > =D0=B4=B5=C0=A3=BA= >>=20 >>=20 >>=20 >> On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin > wrote: >> Hi Jameson: >>=20 >>> =D4=DA 2017=C4=EA6=D4=C215=C8=D5=A3=AC01:20=A3=ACJameson Lopp = > =D0=B4=B5=C0=A3=BA= >>>=20 >>>=20 >>>=20 >>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev = > wrote: >>>=20 >>>=20 >>> > =D4=DA 2017=C4=EA6=D4=C214=C8=D5=A3=AC02:11=A3=ACGregory Maxwell = > =D0=B4=B5=C0=A3=BA >>> > >>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev >>> > > wrote: >>>=20 >>> > The enforcement of the system's rules by users broadly, and not = just >>> > miners, is specifically described in the white paper (section 8, >>> > paragraph 2, it especially clear in the last sentence). This is >>> > critical for the security of Bitcoin especially with the current >>> > degree of centralization in pools. Without it, Bitcoin's security >>> > would look a lot more like the Ripple system. >>> > >>>=20 >>> =CA=C7=B5=C4=A3=AC=D3=C3=BB=A7=D3=C0=D4=B6=B6=BC=D3=D0=D1=A1=D4=F1=A3=AC= =B2=A2=BF=C9=D2=D4=C5=D7=C6=FA=C4=C7=D0=A9=BD=DA=B5=E3=A1=A3=D5=E2=B8=F6 = BIP = =B2=A2=C3=BB=D3=D0=B7=B4=B6=D4=D5=E2=D0=A9=D3=C3=BB=A7=D5=E2=C3=B4=D7=F6=A1= =A3=D6=BB=D3=D0=C4=C7=D0=A9=B1=BB=B6=AF=B5=C4=C7=AE=B0=FC=D3=C3=BB=A7=A3=AC= =CB=FB=C3=C7=D0=E8=D2=AA=D6=AA=B5=C0=B1=D8=D0=EB=D7=F6=B3=F6=D2=BB=B8=F6=D1= =A1=D4=F1=A1=A3=A3=A8=B6=F8=B2=BB=CA=C7=B1=BB=B6=AF=B5=C4=B8=FA=CB=E6=C4=AC= =C8=CF=B5=C4=B2=DF=C2=D4=A3=A9 >>> Yes, users always have choice that they can abandon the nodes. This = BIP does=A1=AFt go against them. I mean only the one(especially wallets) = that=A1=AFs passive, they need to know there=A1=AFs a choice and pick = one. >>>=20 >>> =D5=E2=B8=F6 BIP = =BF=C9=D2=D4=B1=BB=D3=A6=D3=C3=D3=DA=BC=B8=BA=F5=C8=CE=BA=CE=B5=C4=C9=FD=BC= =B6=C9=CF=A3=AC=B0=FC=C0=A8=B8=F4=C0=EB=BC=FB=D6=A4=A3=AC=C1=BD=D5=D7=B5=C4= =B8=F4=C0=EB=BC=FB=D6=A4=A3=AC=C1=BD=D5=D7=C0=A9=C8=DD=A3=AC=D3=BF=CF=D6=B9= =B2=CA=B6=A3=AC=B0=CB=D5=D7=C0=A9=C8=DD=B5=C8=A1=A3=B5=AB=D5=E2=D0=A9=C9=FD= =BC=B6=B2=A2=B2=BB=CA=C7=D6=D8=B5=E3=A1=A3 >>> This BIP can be applied to almost any upgrade, including Segwit, = Segwit2x, 2m, ec, 8m=A1=AD but the upgrade is not the key point. >>>=20 >>> =B5=BD=B5=D7=CE=D2=C3=C7=B5=C4=D3=C3=BB=A7=CA=C7=B7=F1=D5=E6=B5=C4=D3=B5= =D3=D0=D1=A1=D4=F1=A3=BF >>> Did the users have any real choice? >>>=20 >>> = =CE=D2=B2=A2=B2=BB=C4=DC=C0=ED=BD=E2=CB=FB=C3=C7=CF=E0=D0=C5=B4=F3=B2=BF=B7= =D6=BF=F3=B9=A4=A3=A8=BE=CD=CF=F1=B5=B1=C7=B0=D2=BB=D1=F9=A3=A9=A3=AC=B5=AB= =BE=DC=BE=F8=D5=E2=D0=A9=B6=E0=CA=FD=BF=F3=B9=A4=B6=D4=D0=AD=D2=E9=B8=C4=B1= =E4=B5=C4=CD=B6=C6=B1=BD=E1=B9=FB=A1=A3 >>> I don=A1=AFt see the reason they trust the majority miners(as they = do today) but refuse the vote for upcoming protocol upgrade. >>>=20 >>> To be clear, Bitcoin is not a democracy - if you find yourself using = the term "voting" then you may be misunderstanding how consensus forms. = Once a feature has been vetted and the code is deployed, miners may = signal that they are ready to enforce new rules. If for some reason = miners are too "passive or lazy" or wish to "veto" the activation of the = new rules, users may choose to circumvent said veto by refusing to = accept blocks that do not show readiness for enforcing the new rules. >>=20 >> How does the users show their opinion? They can fork away and leave. = But what remains will be united. Are you afraid of the united users or = the fork? >>=20 >> I agree with you that the =A1=B0vote=A1=B1 is not accurate. Could you = kindly suggest an other word for that? >>=20 >> I think users should have choice to follow the miners or not. Do you = agree with this or not? >>=20 >> Regarding consensus changes, users can voice their opinion on any = number of communication platforms. Though if you're looking for a way = for users to signal their intentions at the protocol level, every = proposal for doing that to date has been arguably flawed. Measuring = meatspace consensus is pretty tricky if not completely impossible, = especially given the fact that the vast majority of Bitcoin users do not = voice any opinions on the matter of consensus rules. >>=20 >=20 > =A1=B0Sybil attack=A1=B1. The genuine node will leave the chain if it = doesn=A1=AFt like the change. That=A1=AFs what restrain the majority = miners acting foolishly. >=20 > If the users like the idea, they follow. If they don=A1=AFt the fork = away(and not afraid of replay attack). I think it=A1=AFs a way to move = forward together.=20 >=20 > Would you support the idea that we put the choice to the users to = decide? >=20 > The concept of "sybil attacks" doesn't really apply to enforcing = network-wide consensus changes. Even if someone spooled up 100 times = more nodes than currently exist and they all "signal" for some consensus = rule change, that doesn't compel the rest of the "genuine" nodes to = change the rules they enforce.=20 >=20 > The users always have a choice with regard to what consensus rules to = enforce and what software to run. Everyone is welcome to propose changes = and write software that they make available to users. >> Most attempts at measuring user consensus would probably be best = described as signaling rather than voting given that the act of doing so = has no actual power to affect consensus. Every user who runs a fully = validating node is free to enforce the rules with which the agree = regardless of what rules other entities are enforcing.=20 >>> =20 >>>=20 >>> = =B6=D4=C7=AE=B0=FC=D3=C3=BB=A7=B5=C4=D1=A1=D4=F1=A3=AC=CA=C7=CB=FB=C3=C7=CA= =C7=B7=F1=CF=E0=D0=C5=B6=E0=CA=FD=BF=F3=B9=A4=A1=A3=C8=E7=B9=FB=CB=FB=C3=C7= =B2=BB=CF=E0=D0=C5=A3=AC=BF=C9=D2=D4=CD=A8=B9=FD=B7=D6=B2=E6=C0=B4=CF=FB=B3= =FD=B5=F4=BF=F3=B9=A4=A1=A3 >>> This choice for wallet users right now, is wether to follow the 51% = majority miners. If they don=A1=AFt, they can have their fork that get = rid of miners. >>>=20 >>> =C8=E7=B9=FB=CB=FB=C3=C7=C8=D4=BE=C9=CF=E0=D0=C5=BF=F3=B9=A4=A3=AC=C4=C7= =C3=B4=BF=C9=D2=D4=C1=F4=CF=C2=C0=B4=B2=A2=B8=FA=CB=E6=BF=F3=B9=A4=BD=AB=C0= =B4=B5=C4=D0=AD=D2=E9=B8=C4=B1=E4=A1=A3 >>> If they do trust the majority miners, they stay and follow the vote = for upcoming protocol upgrade. >>>=20 >>> = =CB=F9=D2=D4=CE=CA=CC=E2=D4=DA=D3=DA=A3=BA=B1=C8=CC=D8=B1=D2=B5=C4=BF=AA=B7= =A2=D5=DF=A1=A2=D3=C3=BB=A7=A1=A2=D3=B5=D3=D0=D5=DF=A1=A2=B7=FE=CE=F1=CC=E1= =B9=A9=D5=DF=A1=A2=C9=F5=D6=C1=BF=F3=B9=A4=A3=AC=CA=C7=B7=F1=A3=A8=C8=D4=C8= =BB=A3=A9=C8=E7=B0=D7=C6=A4=CA=E9=D6=D0=C3=E8=CA=F6=B5=C4=B6=D4=B4=F3=B6=E0= =CA=FD=BF=F3=B9=A4=D3=B5=D3=D0=D0=C5=C8=CE=A1=A3 >>> So the questions is: Do the bitcoin developers, users, holders, = service provides, even miners, (still) have faith in the majority of = miners as designed in the white paper? >>>=20 >>> =20 >>> There is a fundamental misconception regarding this point - the = white paper refers to majority hashpower needing to be honest with = regard to determining the correct chain within the context of many = possible /valid/ chain forks. It is not referring to using hashpower to = determine the correct chain amongst an infinitely variable number of = currently invalid chain forks. Bitcoin ecosystem participants should not = have faith in miners (or any other entity) when it comes to choosing the = consensus rules they wish to enforce. >>>=20 >>=20 >> Arrrgh. I think in the BIP, the miners just invalids tx version 1 = temporarily. That=A1=AFs a =A1=B0soft fork=A1=B1 right? If they dislike = the idea, they can leave as always. >>=20 >> =46rom my understanding, if the only change miners make is to stop = confirming transactions that have a version less than X then it should = be a soft fork, yes.=20 >=20 > And if we add a version 2 valid, does that still be a =A1=B0soft = fork=A1=B1? >=20 > As far as I know - if you're only restricting the validation rules = then it should be a non-breaking change.=20 >=20 > Regards, >=20 > LIN Zheming --Apple-Mail=_78FE48AE-7442-4E15-B951-7AF7D27EB8A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb2312 Will there be a  =A1=B0Do nothing=A1=B1 soft fork, = showing that the community can still moving forward?

So all the nodes get to upgrade to use = tx version 2, and that avoid a chain split.

Are you support that or = against that, why?

Regards,
LIN Zheming

=D4=DA 2017=C4=EA6=D4=C215=C8=D5=A3=AC=C9=CF=CE=E74:11=A3=ACJam= eson Lopp <jameson.lopp@gmail.com> =D0=B4=B5=C0=A3=BA



On Wed, Jun 14, 2017 at 12:04 PM, = Zheming Lin <heater@gmail.com> wrote:
Hi Jameson:

=D4=DA = 2017=C4=EA6=D4=C215=C8=D5=A3=AC02:55=A3=ACJameson Lopp <jameson.lopp@gmail.com> =D0=B4=B5=C0=A3=BA



On Wed, Jun 14, 2017 at 11:29 AM, Zheming = Lin <heater@gmail.com> wrote:
Hi Jameson:

=D4=DA 2017=C4=EA6=D4=C215=C8=D5=A3=AC01:20=A3=ACJameson Lopp = <jameson.lopp@gmail.com> =D0=B4=B5=C0=A3=BA



On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via = bitcoin-dev=  <bitcoin-dev@lists.linuxfoundation.org>=  wrote:


> =D4=DA 2017=C4=EA6=D4=C214=C8=D5=A3=AC02:11=A3=ACGregory = Maxwell <greg@xiph.org> =D0=B4=B5=C0=A3=BA
>
> On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via = bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> = wrote:

> The enforcement of the system's rules by users broadly, = and not just
> miners, is specifically described in the = white paper (section 8,
> paragraph 2, it especially = clear in the last sentence).  This is
> critical = for the security of Bitcoin especially with the current
>= degree of centralization in pools.  Without it, Bitcoin's = security
> would look a lot more like the Ripple = system.
>

=CA=C7=B5=C4=A3=AC=D3=C3=BB=A7=D3=C0=D4=B6=B6=BC=D3=D0=D1= =A1=D4=F1=A3=AC=B2=A2=BF=C9=D2=D4=C5=D7=C6=FA=C4=C7=D0=A9=BD=DA=B5=E3=A1=A3= =D5=E2=B8=F6 BIP = =B2=A2=C3=BB=D3=D0=B7=B4=B6=D4=D5=E2=D0=A9=D3=C3=BB=A7=D5=E2=C3=B4=D7=F6=A1= =A3=D6=BB=D3=D0=C4=C7=D0=A9=B1=BB=B6=AF=B5=C4=C7=AE=B0=FC=D3=C3=BB=A7=A3=AC= =CB=FB=C3=C7=D0=E8=D2=AA=D6=AA=B5=C0=B1=D8=D0=EB=D7=F6=B3=F6=D2=BB=B8=F6=D1=A1=D4=F1=A1=A3=A3= =A8=B6=F8=B2=BB=CA=C7=B1=BB=B6=AF=B5=C4=B8=FA=CB=E6=C4=AC=C8=CF=B5=C4=B2=DF= =C2=D4=A3=A9
Yes, users always have choice that they can = abandon the nodes. This BIP does=A1=AFt go against them. I mean only the = one(especially wallets) that=A1=AFs passive, they need to know there=A1=AF= s a choice and pick one.

=D5=E2=B8=F6 BIP = =BF=C9=D2=D4=B1=BB=D3=A6=D3=C3=D3=DA=BC=B8=BA=F5=C8=CE=BA=CE=B5=C4=C9=FD=BC= =B6=C9=CF=A3=AC=B0=FC=C0=A8=B8=F4=C0=EB=BC=FB=D6=A4=A3=AC=C1=BD=D5=D7=B5=C4= =B8=F4=C0=EB=BC=FB=D6=A4=A3=AC=C1=BD=D5=D7=C0=A9=C8=DD=A3=AC=D3=BF=CF=D6=B9=B2=CA=B6=A3=AC=B0= =CB=D5=D7=C0=A9=C8=DD=B5=C8=A1=A3=B5=AB=D5=E2=D0=A9=C9=FD=BC=B6=B2=A2=B2=BB= =CA=C7=D6=D8=B5=E3=A1=A3
This BIP can be applied to almost = any upgrade, including Segwit, Segwit2x, 2m, ec, 8m=A1=AD but the = upgrade is not the key point.

=B5=BD=B5=D7=CE=D2=C3=C7=B5=C4=D3=C3=BB=A7=CA=C7=B7=F1=D5=E6=B5= =C4=D3=B5=D3=D0=D1=A1=D4=F1=A3=BF
Did the users have any = real choice?

=CE=D2=B2=A2=B2=BB=C4=DC=C0=ED=BD=E2=CB=FB=C3=C7=CF=E0=D0=C5=B4= =F3=B2=BF=B7=D6=BF=F3=B9=A4=A3=A8=BE=CD=CF=F1=B5=B1=C7=B0=D2=BB=D1=F9=A3=A9= =A3=AC=B5=AB=BE=DC=BE=F8=D5=E2=D0=A9=B6=E0=CA=FD=BF=F3=B9=A4=B6=D4=D0=AD=D2=E9=B8=C4=B1=E4=B5=C4=CD=B6=C6= =B1=BD=E1=B9=FB=A1=A3
I don=A1=AFt see the reason they = trust the majority miners(as they do today) but refuse the vote for = upcoming protocol upgrade.

To be = clear, Bitcoin is not a democracy - if you find yourself using the term = "voting" then you may be misunderstanding how consensus forms. Once a = feature has been vetted and the code is deployed, miners may signal that = they are ready to enforce new rules. If for some reason miners are too = "passive or lazy" or wish to "veto" the activation of the new rules, = users may choose to circumvent said veto by refusing to accept blocks = that do not show readiness for enforcing the new = rules.

How does the users show their opinion? = They can fork away and leave. But what remains will be united. Are you = afraid of the united users or the fork?

I agree with you that the =A1=B0vote=A1=B1= is not accurate. Could you kindly suggest an other word for = that?

I think = users should have choice to follow the miners or not. Do you agree with = this or not?

Regarding= consensus changes, users can voice their opinion on any number of = communication platforms. Though if you're looking for a way for users to = signal their intentions at the protocol level, every proposal for doing = that to date has been arguably flawed. Measuring meatspace consensus is = pretty tricky if not completely impossible, especially given the fact = that the vast majority of Bitcoin users do not voice any opinions on the = matter of consensus rules.


=A1=B0Sybil attack=A1=B1. = The genuine node will leave the chain if it doesn=A1=AFt like the = change. That=A1=AFs what restrain the majority miners acting = foolishly.

If = the users like the idea, they follow. If they don=A1=AFt the fork = away(and not afraid of replay attack). I think it=A1=AFs a way to move = forward together. 

Would you support the idea that we put the choice to the = users to decide?

The concept = of "sybil attacks" doesn't really apply to enforcing network-wide = consensus changes. Even if someone spooled up 100 times more nodes than = currently exist and they all "signal" for some consensus rule change, = that doesn't compel the rest of the "genuine" nodes to change the rules = they enforce. 

The users always have a choice with regard to what consensus = rules to enforce and what software to run. Everyone is welcome to = propose changes and write software that they make available to = users.
Most attempts at measuring user consensus would probably be = best described as signaling rather than voting given that the act of = doing so has no actual power to affect consensus. Every user who runs a = fully validating node is free to enforce the rules with which the agree = regardless of what rules other entities are = enforcing. 
 

=B6=D4=C7=AE=B0=FC=D3=C3=BB=A7=B5=C4=D1=A1=D4=F1=A3=AC=CA=C7=CB= =FB=C3=C7=CA=C7=B7=F1=CF=E0=D0=C5=B6=E0=CA=FD=BF=F3=B9=A4=A1=A3=C8=E7=B9=FB= =CB=FB=C3=C7=B2=BB=CF=E0=D0=C5=A3=AC=BF=C9=D2=D4=CD=A8=B9=FD=B7=D6=B2=E6=C0=B4=CF=FB=B3=FD=B5=F4=BF=F3=B9= =A4=A1=A3
This choice for wallet users right now, is = wether to follow the 51% majority miners. If they don=A1=AFt, they can = have their fork that get rid of miners.

=C8=E7=B9=FB=CB=FB=C3=C7=C8=D4=BE=C9=CF=E0=D0=C5=BF=F3=B9=A4=A3= =AC=C4=C7=C3=B4=BF=C9=D2=D4=C1=F4=CF=C2=C0=B4=B2=A2=B8=FA=CB=E6=BF=F3=B9=A4= =BD=AB=C0=B4=B5=C4=D0=AD=D2=E9=B8=C4=B1=E4=A1=A3
If they do trust the majority miners, they stay and follow = the vote for upcoming protocol upgrade.

=CB=F9=D2=D4=CE=CA=CC=E2=D4=DA=D3=DA=A3=BA=B1=C8=CC=D8=B1=D2=B5= =C4=BF=AA=B7=A2=D5=DF=A1=A2=D3=C3=BB=A7=A1=A2=D3=B5=D3=D0=D5=DF=A1=A2=B7=FE= =CE=F1=CC=E1=B9=A9=D5=DF=A1=A2=C9=F5=D6=C1=BF=F3=B9=A4=A3=AC=CA=C7=B7=F1=A3=A8=C8=D4=C8=BB=A3=A9=C8=E7=B0= =D7=C6=A4=CA=E9=D6=D0=C3=E8=CA=F6=B5=C4=B6=D4=B4=F3=B6=E0=CA=FD=BF=F3=B9=A4= =D3=B5=D3=D0=D0=C5=C8=CE=A1=A3
So the questions is: Do the = bitcoin developers, users, holders, service provides, even miners, = (still) have faith in the majority of miners as designed in the white = paper?

 
There is a fundamental misconception regarding this point - = the white paper refers to majority hashpower needing to be honest with = regard to determining the correct chain within the context of many = possible /valid/ chain forks. It is not referring to using hashpower to = determine the correct chain amongst an infinitely variable number of = currently invalid chain forks. Bitcoin ecosystem participants should not = have faith in miners (or any other entity) when it comes to choosing the = consensus rules they wish to enforce.


Arrrgh. I think in the BIP, the = miners just invalids tx version 1 temporarily. That=A1=AFs a =A1=B0soft = fork=A1=B1 right? If they dislike the idea, they can leave as = always.

=46rom = my understanding, if the only change miners make is to stop confirming = transactions that have a version less than X then it should be a soft = fork, yes. 

And if we add a version 2 valid, = does that still be a =A1=B0soft fork=A1=B1?

As far as I know - if = you're only restricting the validation rules then it should be a = non-breaking change. 

Regards,

LIN = Zheming

= --Apple-Mail=_78FE48AE-7442-4E15-B951-7AF7D27EB8A6--