From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82C3E727 for ; Thu, 15 Jun 2017 18:39:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50AEC227 for ; Thu, 15 Jun 2017 18:38:59 +0000 (UTC) Received: by mail-qt0-f171.google.com with SMTP id w1so31833293qtg.2 for ; Thu, 15 Jun 2017 11:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8NHWw7Ls/UuGLQYbupNIEj3zUYFaBMOT5pxa0OdT03A=; b=pSK6b4e1tJQD6gfaYq5Itb8R0dnDWvs1QilVPVSWboEH+ZZlf+wTQg8dPMaXCrxlhB o+jD8VZcKcNx4MYF0zD28U410c+Cl1/37xn61Om+/6cM4sfqH08s41vrOypLC/nXoyda PQ9qwc4FkCA7zFvtN5zZfEeEZE4OB8cb9qVKmXNrnwW+JotaOMHFAPCils3LiKie1nqk T/69sK8xSNJztE4rRjKcodlXJULN6zeYxjmTuP+sYqChUt89WyZsFDMNSPgaLaaNMCz5 pZuzfBLM6IlEoNnj6FEqJLxXU+zGhR6eZHcYSXk0Vr565y4H2p3zi8k34E2wSogbqLKU nhLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8NHWw7Ls/UuGLQYbupNIEj3zUYFaBMOT5pxa0OdT03A=; b=loCLES3ah/8TWctgTwdg00qqfWgsgUUv5fJAyuZ5vmIFweJlj0qYx+ls4Jkhy952Wr XKsvOo2a2DK7Yc4xppgOVBZDHoei6kOsaH8xjA/NHvaIL/tHWk4E8AB53fivebHAUrhX /e3BcvlHdIoiNmZlKHhZckaaufDwzKDflFjeEva/kh2vMxuN0B8jKmt9nvzhyaE1re9U sCp+SHwz7HCfLFa5Zso/rtbKNX5aqvnQIUsPZCQ/w1+UxZPUeHbpZfwNwZ0cdubZm0g0 UljXaNKFABSUHsOwONcGBe7l2rzFkp1HFINdoXgDrPQzMpuVBy3Wix/vAQxYWK++cy6v OGXA== X-Gm-Message-State: AKS2vOxy5ITlI4iC9MN/1oZgJWvEeYXRxiRDZ27JCIF4mAVv66LnSXKy ghy0qdFXvkfuOQAet5p9f+mdyMOkow== X-Received: by 10.200.12.78 with SMTP id l14mr8132814qti.227.1497551938249; Thu, 15 Jun 2017 11:38:58 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.237.54.100 with HTTP; Thu, 15 Jun 2017 11:38:57 -0700 (PDT) In-Reply-To: <95BB8EA8-31F6-4131-B557-A35342FA17A1@voskuil.org> References: <31040BE1-64ED-4D05-BCBE-E80BC7B9A182@gmail.com> <95BB8EA8-31F6-4131-B557-A35342FA17A1@voskuil.org> From: Erik Aronesty Date: Thu, 15 Jun 2017 14:38:57 -0400 X-Google-Sender-Auth: fQ5ZGVgxZHbrB3dIlE1aYbBfi2I Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="089e0822908c4feb18055203fbec" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 15 Jun 2017 18:41:59 +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: Thu, 15 Jun 2017 18:39:03 -0000 --089e0822908c4feb18055203fbec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 had proposed earlier and maintain that "UTXO bits" can be used to allow coordinated user participation activation thresholds akin to other hashpower thresholds. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.htm= l While I'm not certain that my implementation was correct (or was just too complicated and concerned with compression at the expense of readability), I am fairly certain that this mechanism - or a similar one - would be a reasonable way for users to coordinate changes independently of miners and with very high consensus levels. On Thu, Jun 15, 2017 at 1:04 AM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Jun 14, 2017, at 9:55 PM, Jameson Lopp via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin wrote: > >> Hi Jameson: >> >> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8815=E6=97=A5=EF=BC=8C01:20=EF=BC=8CJames= on Lopp =E5=86=99=E9=81=93=EF=BC=9A >> >> >> >> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> >>> >>> > =E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=EF=BC=8C02:11=EF=BC=8CGr= egory Maxwell =E5=86=99=E9=81=93=EF=BC=9A >>> > >>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev >>> > 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. >>> > >>> >>> =E6=98=AF=E7=9A=84=EF=BC=8C=E7=94=A8=E6=88=B7=E6=B0=B8=E8=BF=9C=E9=83= =BD=E6=9C=89=E9=80=89=E6=8B=A9=EF=BC=8C=E5=B9=B6=E5=8F=AF=E4=BB=A5=E6=8A=9B= =E5=BC=83=E9=82=A3=E4=BA=9B=E8=8A=82=E7=82=B9=E3=80=82=E8=BF=99=E4=B8=AA BI= P =E5=B9=B6=E6=B2=A1=E6=9C=89=E5=8F=8D=E5=AF=B9=E8=BF=99=E4=BA=9B=E7=94=A8= =E6=88=B7=E8=BF=99=E4=B9=88=E5=81=9A=E3=80=82=E5=8F=AA=E6=9C=89=E9=82=A3=E4= =BA=9B=E8=A2=AB=E5=8A=A8=E7=9A=84=E9=92=B1=E5=8C=85=E7=94=A8=E6=88=B7=EF=BC= =8C=E4=BB=96=E4=BB=AC=E9=9C=80=E8=A6=81=E7=9F=A5 >>> =E9=81=93=E5=BF=85=E9=A1=BB=E5=81=9A=E5=87=BA=E4=B8=80=E4=B8=AA=E9=80= =89=E6=8B=A9=E3=80=82=EF=BC=88=E8=80=8C=E4=B8=8D=E6=98=AF=E8=A2=AB=E5=8A=A8= =E7=9A=84=E8=B7=9F=E9=9A=8F=E9=BB=98=E8=AE=A4=E7=9A=84=E7=AD=96=E7=95=A5=EF= =BC=89 >>> Yes, users always have choice that they can abandon the nodes. This BIP >>> does=E2=80=99t go against them. I mean only the one(especially wallets)= that=E2=80=99s >>> passive, they need to know there=E2=80=99s a choice and pick one. >>> >>> =E8=BF=99=E4=B8=AA BIP =E5=8F=AF=E4=BB=A5=E8=A2=AB=E5=BA=94=E7=94=A8=E4= =BA=8E=E5=87=A0=E4=B9=8E=E4=BB=BB=E4=BD=95=E7=9A=84=E5=8D=87=E7=BA=A7=E4=B8= =8A=EF=BC=8C=E5=8C=85=E6=8B=AC=E9=9A=94=E7=A6=BB=E8=A7=81=E8=AF=81=EF=BC=8C= =E4=B8=A4=E5=85=86=E7=9A=84=E9=9A=94=E7=A6=BB=E8=A7=81=E8=AF=81=EF=BC=8C=E4= =B8=A4=E5=85=86=E6=89=A9=E5=AE=B9=EF=BC=8C=E6=B6=8C=E7=8E=B0=E5=85=B1=E8=AF= =86=EF=BC=8C=E5=85=AB=E5=85=86=E6=89=A9=E5=AE=B9=E7=AD=89=E3=80=82=E4=BD=86= =E8=BF=99=E4=BA=9B=E5=8D=87=E7=BA=A7=E5=B9=B6=E4=B8=8D=E6=98=AF=E9=87=8D=E7= =82=B9=E3=80=82 >>> This BIP can be applied to almost any upgrade, including Segwit, >>> Segwit2x, 2m, ec, 8m=E2=80=A6 but the upgrade is not the key point. >>> >>> =E5=88=B0=E5=BA=95=E6=88=91=E4=BB=AC=E7=9A=84=E7=94=A8=E6=88=B7=E6=98= =AF=E5=90=A6=E7=9C=9F=E7=9A=84=E6=8B=A5=E6=9C=89=E9=80=89=E6=8B=A9=EF=BC=9F >>> Did the users have any real choice? >>> >>> =E6=88=91=E5=B9=B6=E4=B8=8D=E8=83=BD=E7=90=86=E8=A7=A3=E4=BB=96=E4=BB= =AC=E7=9B=B8=E4=BF=A1=E5=A4=A7=E9=83=A8=E5=88=86=E7=9F=BF=E5=B7=A5=EF=BC=88= =E5=B0=B1=E5=83=8F=E5=BD=93=E5=89=8D=E4=B8=80=E6=A0=B7=EF=BC=89=EF=BC=8C=E4= =BD=86=E6=8B=92=E7=BB=9D=E8=BF=99=E4=BA=9B=E5=A4=9A=E6=95=B0=E7=9F=BF=E5=B7= =A5=E5=AF=B9=E5=8D=8F=E8=AE=AE=E6=94=B9=E5=8F=98=E7=9A=84=E6=8A=95=E7=A5=A8= =E7=BB=93=E6=9E=9C=E3=80=82 >>> I don=E2=80=99t see the reason they trust the majority miners(as they d= o 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, use= rs >> 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 f= ork? >> >> I agree with you that the =E2=80=9Cvote=E2=80=9D 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. > > > There is exactly one way to express one's opinion on consensus at the > protocol level - participation. The method is neither flawed nor > inequitable in the context of Bitcoin. > > The only "problem" with it is that people are not satisfied with having a > voice limited to their participation. People are used to political system= s > in which they vote using their existence as power, not their participatio= n, > and they expect some subset of existing human bodies to control all other= s. > This is the concept of some ruling over others, which gives the rulers a > more powerful voice than either their proportional existence or individua= l > participation would allow. > > Bitcoin exists in defiance of political models. It is a market, not a > state. The only choice you have is to participate or leave. If you are > satisfied with others participating in your stead, you have left the > consensus - you have no say. > > Most people who think they are participating in Bitcoin have either never > participated or long ago left the consensus. Having surrendered it, these > people now grope for a way to have their say. You can always reclaim your > say on consensus, but you cannot take it away from others. > > To have your say regarding hard forks, you must validate Bitcoin received > in exchange for something else of economic value. To have your say > regarding soft forks you must mine. Everyone has these options. Hard fork= s > cannot control miners' selection of transactions and miners cannot contro= l > the economy's determination of what is valid. If one wants a say in eithe= r > one must participate in the respective operation. > > e > > 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. > > Most attempts at measuring user consensus would probably be best describe= d > 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. > >> >> >>> >>> =E5=AF=B9=E9=92=B1=E5=8C=85=E7=94=A8=E6=88=B7=E7=9A=84=E9=80=89=E6=8B= =A9=EF=BC=8C=E6=98=AF=E4=BB=96=E4=BB=AC=E6=98=AF=E5=90=A6=E7=9B=B8=E4=BF=A1= =E5=A4=9A=E6=95=B0=E7=9F=BF=E5=B7=A5=E3=80=82=E5=A6=82=E6=9E=9C=E4=BB=96=E4= =BB=AC=E4=B8=8D=E7=9B=B8=E4=BF=A1=EF=BC=8C=E5=8F=AF=E4=BB=A5=E9=80=9A=E8=BF= =87=E5=88=86=E5=8F=89=E6=9D=A5=E6=B6=88=E9=99=A4=E6=8E=89=E7=9F=BF=E5=B7=A5= =E3=80=82 >>> This choice for wallet users right now, is wether to follow the 51% >>> majority miners. If they don=E2=80=99t, they can have their fork that g= et rid of >>> miners. >>> >>> =E5=A6=82=E6=9E=9C=E4=BB=96=E4=BB=AC=E4=BB=8D=E6=97=A7=E7=9B=B8=E4=BF= =A1=E7=9F=BF=E5=B7=A5=EF=BC=8C=E9=82=A3=E4=B9=88=E5=8F=AF=E4=BB=A5=E7=95=99= =E4=B8=8B=E6=9D=A5=E5=B9=B6=E8=B7=9F=E9=9A=8F=E7=9F=BF=E5=B7=A5=E5=B0=86=E6= =9D=A5=E7=9A=84=E5=8D=8F=E8=AE=AE=E6=94=B9=E5=8F=98=E3=80=82 >>> If they do trust the majority miners, they stay and follow the vote for >>> upcoming protocol upgrade. >>> >>> =E6=89=80=E4=BB=A5=E9=97=AE=E9=A2=98=E5=9C=A8=E4=BA=8E=EF=BC=9A=E6=AF= =94=E7=89=B9=E5=B8=81=E7=9A=84=E5=BC=80=E5=8F=91=E8=80=85=E3=80=81=E7=94=A8= =E6=88=B7=E3=80=81=E6=8B=A5=E6=9C=89=E8=80=85=E3=80=81=E6=9C=8D=E5=8A=A1=E6= =8F=90=E4=BE=9B=E8=80=85=E3=80=81=E7=94=9A=E8=87=B3=E7=9F=BF=E5=B7=A5=EF=BC= =8C=E6=98=AF=E5=90=A6=EF=BC=88=E4=BB=8D=E7=84=B6=EF=BC=89=E5=A6=82=E7=99=BD= =E7=9A=AE=E4=B9=A6=E4=B8=AD=E6=8F=8F=E8=BF=B0=E7=9A=84=E5=AF=B9=E5=A4=A7=E5= =A4=9A=E6=95=B0=E7=9F=BF=E5=B7=A5=E6=8B=A5=E6=9C=89=E4=BF=A1=E4=BB=BB=E3=80= =82 >>> 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 min= ers >> (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=E2=80=99s a =E2=80=9Csoft fork=E2=80=9D right? If they= dislike the idea, they can >> leave as always. >> >> From 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. > >> >> Regards >> >> LIN Zheming >> >> >> > _______________________________________________ > 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 > > --089e0822908c4feb18055203fbec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> How does the users show their opinion? They can = fork away and=20 leave. But what remains will be united. Are you afraid of the united=20 users or the fork?

I had proposed earlier and maintain th= at "UTXO bits" can be used to allow coordinated user participatio= n activation thresholds akin to other hashpower thresholds.=C2=A0=C2=A0
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/= 2017-May/014251.html

While I'm not certain that my implement= ation was correct (or was just too complicated and concerned with compressi= on at the expense of readability), I am fairly certain that this mechanism = - or a similar one - would be a reasonable way for users to coordinate chan= ges independently of miners and with very high consensus levels.


On Thu, = Jun 15, 2017 at 1:04 AM, Eric Voskuil via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:


On Jun 14, 2017, at 9:55 PM, Jameson Lopp via bitcoin-= dev <bitcoin-dev@lists.linuxfoundation.org> wrote:



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

=E5=9C=A8 2017=E5=B9=B46= =E6=9C=8815=E6=97=A5=EF=BC=8C01:20=EF=BC=8CJameson Lopp <jameson.lopp@gmail.com>= =E5=86=99=E9=81=93=EF=BC=9A



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


> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=EF=BC=8C0= 2:11=EF=BC=8CGregory Maxwell <greg@xiph.org> =E5=86=99=E9=81=93=EF=BC=9A
>
> = On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> <bi= tcoin-dev@lists.linuxfoundation.org> wrote:

> The enforcement of the system's rules by users broad= ly, and not just
> miners, is specifically described in the white pap= er (section 8,
> paragraph 2, it especially clear in the last sentenc= e).=C2=A0 This is
> critical for the security of Bitcoin especially w= ith the current
> degree of centralization in pools.=C2=A0 Without it= , Bitcoin's security
> would look a lot more like the Ripple syst= em.
>

=E6=98=AF=E7=9A=84=EF=BC=8C=E7=94=A8=E6=88=B7=E6= =B0=B8=E8=BF=9C=E9=83=BD=E6=9C=89=E9=80=89=E6=8B=A9=EF=BC=8C=E5=B9=B6=E5=8F= =AF=E4=BB=A5=E6=8A=9B=E5=BC=83=E9=82=A3=E4=BA=9B=E8=8A=82=E7=82=B9=E3=80=82= =E8=BF=99=E4=B8=AA BIP =E5=B9=B6=E6=B2=A1=E6=9C=89=E5=8F=8D=E5=AF=B9=E8=BF= =99=E4=BA=9B=E7=94=A8=E6=88=B7=E8=BF=99=E4=B9=88=E5=81=9A=E3=80=82=E5=8F=AA= =E6=9C=89=E9=82=A3=E4=BA=9B=E8=A2=AB=E5=8A=A8=E7=9A=84=E9=92=B1=E5=8C=85=E7= =94=A8=E6=88=B7=EF=BC=8C=E4=BB=96=E4=BB=AC=E9=9C=80=E8=A6=81=E7=9F=A5= =E9=81=93=E5=BF=85=E9=A1=BB=E5=81=9A=E5=87=BA=E4=B8=80=E4=B8=AA=E9=80=89=E6= =8B=A9=E3=80=82=EF=BC=88=E8=80=8C=E4=B8=8D=E6=98=AF=E8=A2=AB=E5=8A=A8=E7=9A= =84=E8=B7=9F=E9=9A=8F=E9=BB=98=E8=AE=A4=E7=9A=84=E7=AD=96=E7=95=A5=EF=BC=89=
Yes, users always have choice that they can abandon the nodes. This BIP= does=E2=80=99t go against them. I mean only the one(especially wallets) th= at=E2=80=99s passive, they need to know there=E2=80=99s a choice and pick o= ne.

=E8=BF=99=E4=B8=AA BIP =E5=8F=AF=E4=BB=A5=E8=A2=AB=E5=BA=94=E7= =94=A8=E4=BA=8E=E5=87=A0=E4=B9=8E=E4=BB=BB=E4=BD=95=E7=9A=84=E5=8D=87=E7=BA= =A7=E4=B8=8A=EF=BC=8C=E5=8C=85=E6=8B=AC=E9=9A=94=E7=A6=BB=E8=A7=81=E8=AF=81= =EF=BC=8C=E4=B8=A4=E5=85=86=E7=9A=84=E9=9A=94=E7=A6=BB=E8=A7=81=E8=AF=81=EF= =BC=8C=E4=B8=A4=E5=85=86=E6=89=A9=E5=AE=B9=EF=BC=8C=E6=B6=8C=E7=8E=B0= =E5=85=B1=E8=AF=86=EF=BC=8C=E5=85=AB=E5=85=86=E6=89=A9=E5=AE=B9=E7=AD=89=E3= =80=82=E4=BD=86=E8=BF=99=E4=BA=9B=E5=8D=87=E7=BA=A7=E5=B9=B6=E4=B8=8D=E6=98= =AF=E9=87=8D=E7=82=B9=E3=80=82
This BIP can be applied to almost any upg= rade, including Segwit, Segwit2x, 2m, ec, 8m=E2=80=A6 but the upgrade is no= t the key point.

=E5=88=B0=E5=BA=95=E6=88=91=E4=BB=AC=E7=9A=84=E7=94= =A8=E6=88=B7=E6=98=AF=E5=90=A6=E7=9C=9F=E7=9A=84=E6=8B=A5=E6=9C=89=E9=80=89= =E6=8B=A9=EF=BC=9F
Did the users have any real choice?

=E6=88=91= =E5=B9=B6=E4=B8=8D=E8=83=BD=E7=90=86=E8=A7=A3=E4=BB=96=E4=BB=AC=E7=9B=B8=E4= =BF=A1=E5=A4=A7=E9=83=A8=E5=88=86=E7=9F=BF=E5=B7=A5=EF=BC=88=E5=B0=B1=E5=83= =8F=E5=BD=93=E5=89=8D=E4=B8=80=E6=A0=B7=EF=BC=89=EF=BC=8C=E4=BD=86=E6=8B=92= =E7=BB=9D=E8=BF=99=E4=BA=9B=E5=A4=9A=E6=95=B0=E7=9F=BF=E5=B7=A5=E5=AF= =B9=E5=8D=8F=E8=AE=AE=E6=94=B9=E5=8F=98=E7=9A=84=E6=8A=95=E7=A5=A8=E7=BB=93= =E6=9E=9C=E3=80=82
I don=E2=80=99t see the reason they trust the majorit= y miners(as they do today) but refuse the vote for upcoming protocol upgrad= e.

To be clear, Bitcoin is= not a democracy - if you find yourself using the term "voting" t= hen you may be misunderstanding how consensus forms. Once a feature has bee= n 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 m= ay 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 f= ork away and leave. But what remains will be united. Are you afraid of the = united users or the fork?

I agree with you that th= e =E2=80=9Cvote=E2=80=9D is not accurate. Could you kindly suggest an other= word for that?

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

<= /span>
Regarding consensus changes, user= s 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 fl= awed.

=
There is exactly one way to express one's opinion on consensus at = the protocol level - participation. The method is neither flawed nor inequi= table in the context of Bitcoin.

The only "pr= oblem" with it is that people are not satisfied with having a voice li= mited to their participation. People are used to political systems in which= they vote using their existence as power, not their participation, and the= y expect some subset of existing human bodies to control all others. This i= s the concept of some ruling over others, which gives the rulers a more pow= erful voice than either their proportional existence or individual particip= ation would allow.

Bitcoin exists in defiance of p= olitical models. It is a market, not a state. The only choice you have is t= o participate or leave. If you are satisfied with others participating in y= our stead, you have left the consensus - you have no say.

Most people who think they are participating in Bitcoin have either= never participated or long ago left the consensus. Having surrendered it, = these people now grope for a way to have their say. You can always reclaim = your say on consensus, but you cannot take it away from others.
<= br>
To have your say regarding hard forks, you must validate Bitc= oin received in exchange for something else of economic value. To have your= say regarding soft forks you must mine. Everyone has these options. Hard f= orks cannot control miners' selection of transactions and miners cannot= control the economy's determination of what is valid. If one wants a s= ay in either one must participate in the respective operation.
e

Me= asuring meatspace consensus is pretty tricky if not completely impossible, = especially given the fact that the vast majority of Bitcoin users do not vo= ice any opinions on the matter of consensus rules.

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 actu= al power to affect consensus. Every user who runs a fully validating node i= s free to enforce the rules with which the agree regardless of what rules o= ther entities are enforcing.=C2=A0
=C2=A0
=
=E5=AF=B9=E9=92=B1=E5=8C=85=E7=94=A8=E6=88=B7=E7=9A=84=E9=80=89=E6=8B= =A9=EF=BC=8C=E6=98=AF=E4=BB=96=E4=BB=AC=E6=98=AF=E5=90=A6=E7=9B=B8=E4=BF=A1= =E5=A4=9A=E6=95=B0=E7=9F=BF=E5=B7=A5=E3=80=82=E5=A6=82=E6=9E=9C=E4=BB=96=E4= =BB=AC=E4=B8=8D=E7=9B=B8=E4=BF=A1=EF=BC=8C=E5=8F=AF=E4=BB=A5=E9=80=9A= =E8=BF=87=E5=88=86=E5=8F=89=E6=9D=A5=E6=B6=88=E9=99=A4=E6=8E=89=E7=9F=BF=E5= =B7=A5=E3=80=82
This choice for wallet users right now, is wether to fol= low the 51% majority miners. If they don=E2=80=99t, they can have their for= k that get rid of miners.

=E5=A6=82=E6=9E=9C=E4=BB=96=E4=BB=AC=E4=BB= =8D=E6=97=A7=E7=9B=B8=E4=BF=A1=E7=9F=BF=E5=B7=A5=EF=BC=8C=E9=82=A3=E4=B9=88= =E5=8F=AF=E4=BB=A5=E7=95=99=E4=B8=8B=E6=9D=A5=E5=B9=B6=E8=B7=9F=E9=9A=8F=E7= =9F=BF=E5=B7=A5=E5=B0=86=E6=9D=A5=E7=9A=84=E5=8D=8F=E8=AE=AE=E6=94=B9=E5=8F= =98=E3=80=82
If they do trust the majority miners, they stay and fo= llow the vote for upcoming protocol upgrade.

=E6=89=80=E4=BB=A5=E9= =97=AE=E9=A2=98=E5=9C=A8=E4=BA=8E=EF=BC=9A=E6=AF=94=E7=89=B9=E5=B8=81=E7=9A= =84=E5=BC=80=E5=8F=91=E8=80=85=E3=80=81=E7=94=A8=E6=88=B7=E3=80=81=E6=8B=A5= =E6=9C=89=E8=80=85=E3=80=81=E6=9C=8D=E5=8A=A1=E6=8F=90=E4=BE=9B=E8=80=85=E3= =80=81=E7=94=9A=E8=87=B3=E7=9F=BF=E5=B7=A5=EF=BC=8C=E6=98=AF=E5=90=A6= =EF=BC=88=E4=BB=8D=E7=84=B6=EF=BC=89=E5=A6=82=E7=99=BD=E7=9A=AE=E4=B9=A6=E4= =B8=AD=E6=8F=8F=E8=BF=B0=E7=9A=84=E5=AF=B9=E5=A4=A7=E5=A4=9A=E6=95=B0=E7=9F= =BF=E5=B7=A5=E6=8B=A5=E6=9C=89=E4=BF=A1=E4=BB=BB=E3=80=82
So the questio= ns is: Do the bitcoin developers, users, holders, service provides, even mi= ners, (still) have faith in the majority of miners as designed in the white= paper?

=C2=A0
There is a f= undamental misconception regarding this point - the white paper refers to m= ajority hashpower needing to be honest with regard to determining the corre= ct chain within the context of many possible /valid/ chain forks. It is not= referring to using hashpower to determine the correct chain amongst an inf= initely 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 i= n the BIP, the miners just invalids tx version 1 temporarily. That=E2=80=99= s a =E2=80=9Csoft fork=E2=80=9D right? If they dislike the idea, they can l= eave as always.

Fro= m my understanding, if the only change miners make is to stop confirming tr= ansactions that have a version less than X then it should be a soft fork, y= es.=C2=A0

Regards
=
LIN Zheming
<= /div>


<= span>_______________________________________________
b= itcoin-dev mailing list
bitcoin-dev@lists.linuxfoundat= ion.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


--089e0822908c4feb18055203fbec--