Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BBD2D982 for ; Tue, 13 Jun 2017 08:14:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f196.google.com (mail-pf0-f196.google.com [209.85.192.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 715C41A0 for ; Tue, 13 Jun 2017 08:14:03 +0000 (UTC) Received: by mail-pf0-f196.google.com with SMTP id d5so7121406pfe.1 for ; Tue, 13 Jun 2017 01:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VOE/kj4/6tKLPmqlW9xfBr3flNtn5ruklDk9euCrIG0=; b=Ack0C0UprxGPTpNnGZ1xcBjMOrXwc6zZV6oK/2ntEmwUmkCNDphc8CI9m6VOrBCoM4 VoU5l3NDWDrP8/Yy73q9Ho0pCkeTEhBMRryMEpG6AFYBoI+NU8nGL8pg6qapE8XcDqPc 7YDgZWxa8BtwV3Qx3egpBZbEhrpBAR9fxQJDCdG+sm8KDp703/hUuPEY5PTrBXNZ7pon YGe4LQPwGwNzmQfBmOTsniL057S3lNTTRq2EE3UjAonnCWVATpDy4uugaCz/Ml7z338G zy9axdtDcPCntUmDa/85unHpik2YAXEJT5UxemwtUl707w8ugCN65sGXBvQOaJUMdMGh 2Srw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VOE/kj4/6tKLPmqlW9xfBr3flNtn5ruklDk9euCrIG0=; b=NtQ/KBW2y+JYlNsLG+yiQw4qZb3v5W8zsv8kgTsBgP3nbfTvTsS0eT/0BCDvs4Dzbo qFi822EpSb/AEJM6/OfJbKjSbCGsgPmfgPMa1GBJtnVZsQ1J1QOUV2e5PB9Sji0npeQM bkm07uwdoHljKlFuhrtqkiAJZEJaokOPPR0gSLRuEjTSaz4jp69qsSna1PocCKixPN1U g6IBt7JPF5d51K3Fa38OqJ7gdjRbrrKTHsse+Gfw7XigN9cNj7qcafqTxxwP7VKmF0BJ GLby6mjp3rzukt31InhKTf3qd3S5mtIjCoNdMVUMW8eP0yiSgJRAoudvidqMewSoKZV5 pvQA== X-Gm-Message-State: AODbwcBqbQ+Fndg3jUXCXb7fxXmXJ4822ghiiRjj52dQ8/u0N6dkkxSX DVTzNZwgMQezXw== X-Received: by 10.84.225.2 with SMTP id t2mr61045757plj.108.1497341642936; Tue, 13 Jun 2017 01:14:02 -0700 (PDT) Received: from [192.168.1.102] ([59.56.44.119]) by smtp.gmail.com with ESMTPSA id 67sm22921225pfn.84.2017.06.13.01.14.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 01:14:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5AF2E759-FAF2-4AC7-947E-7BEC5068F490" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3431\)) From: Zheming Lin In-Reply-To: Date: Tue, 13 Jun 2017 16:13:58 +0800 Message-Id: <65B4ED60-0351-4A8D-942A-56BC8C230E4A@gmail.com> References: <2002E56E-45F8-4B4B-A7A5-CBEF739D5D8B@gmail.com> To: James Hilliard X-Mailer: Apple Mail (2.3431) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, 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: Tue, 13 Jun 2017 10:13:06 +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: Tue, 13 Jun 2017 08:14:04 -0000 --Apple-Mail=_5AF2E759-FAF2-4AC7-947E-7BEC5068F490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb2312 Hi James: > =D4=DA 2017=C4=EA6=D4=C213=C8=D5=A3=AC15:19=A3=ACJames Hilliard = =D0=B4=B5=C0=A3=BA >=20 > On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin > wrote: >> Hi James: >>=20 >> Thank you very much for detailed feedback. Sorry for my understanding = of >> English being poor. I=A1=AFll try to answer that. >>=20 >>=20 >> =D4=DA 2017=C4=EA6=D4=C213=C8=D5=A3=AC13:44=A3=ACJames Hilliard = =D0=B4=B5=C0=A3=BA >>=20 >>=20 >> 1. The activation only requires majority miners signal. As described = in the >> paper by Satoshi Nakamoto, 55% miners will be in the longest chain = after 340 >> blocks, with 99.9% certainty. This will minimize the possibility of = delaying >> network upgrades by controlling a small number of hashing power. We = can >> foresee that after 51% signalling, all miners will upgrade within the = first >> grace period.
>>=20 >> Technically soft forks can be implemented at 55% hashpower already >> without an orphaning period(like BIP16). Those that don't upgrade >> would just be at risk of mining invalid blocks. One would not want to >> use this method to try and activate a controversial hard fork since >> it's trivial for miners to false signal. The orphaning period >> effectively forces miners to make a decision but does not necessarily >> force them to make a particular decision since they can simply choose >> to reject the fork and false signal. >>=20 >>=20 >> = =BC=D9=D0=C5=BA=C5=B5=C4=CE=CA=CC=E2=D4=DA=CE=D2=BF=B4=C0=B4=CE=DE=B7=A8=BD= =E2=BE=F6=A1=A3=B5=AB=C8=E7=B9=FB=B6=E0=CA=FD=B2=BB=CD=AC=D2=E2=D5=E2=B8=F6= =B8=C4=B1=E4=A3=AC=CE=AA=CA=B2=C3=B4=CB=FB=C3=C7=BB=B9=D2=AA=C6=DB=C6=AD=A3= =BF=C8=E7=B9=FB=B6=E0=CA=FD=C8=E7=D6=D0=B1=BE=B4=CF=B9=B2=CA=B6=D6=D0=C3=E8= =CA=F6=B5=C4=C4=C7=D1=F9=CA=C7=B3=CF=CA=B5=BF=C9=D0=C5=B5=C4=A3=AC=C4=C7=BE= =CD=B2=BB=BB=E1=D3=D0=C8=CE=BA=CE=CE=CA=CC=E2=A1=A3=CD=A8=B9=FD=CB=E3=C1=A6= =D7=DC=C4=DC=B7=D6=B3=F6=CA=A4=B8=BA=A1=A3 >> False signal can=A1=AFt be solved in my opinion. If the majority part = just don=A1=AFt >> agree with the change, why they cheat? If the majority part is honest = as >> described in nakamoto consensus, I think that won=A1=AFt be a = problem. CPU power >> always decides. >=20 > Nakamoto consensus is used to determine the longest chain among > multiple valid chains, it's not enough to determine validity by > itself. For example in a hard fork if a minority of hashpower decided > not to fork then they would simply consider the forked chain invalid > and ignore it, even if that majority chain had significantly more > work. >=20 = =BD=DA=B5=E3=D0=E8=D2=AA=D7=D4=D6=F7=BE=F6=B6=A8=CA=C7=B7=F1=B8=FA=CB=E6=D0= =AD=D2=E9=C9=FD=BC=B6=A1=A3=B5=AB=CA=C7=CB=FB=C3=C7=B2=BB=C4=DC=B1=BB=B6=AF= =B5=C4=CA=B2=C3=B4=B6=BC=B2=BB=D7=F6=A1=A3=CB=FB=C3=C7=D7=DC=CA=C7=B4=E6=D4= =DA=D3=D0=B6=E0=D6=D6=B5=C4=D1=A1=D4=F1=A1=A3 The node should decide to follow the protocol upgrade or not. But they = can=A1=AFt just be passive and do nothing. The choice is always = provided. =C8=E7=B9=FB=CB=FB=C3=C7=B2=A2=B2=BB=CF=E0=D0=C5=B4=F3=B6=E0=CA=FD=B5=C4=BF= =F3=B9=A4=A3=AC=CB=FB=C3=C7=BF=C9=D2=D4=D1=A1=D4=F1=D2=BB=D0=A9=C3=BB=D3=D0= =BF=F3=B9=A4=BD=C7=C9=AB=B5=C4=CC=E6=B4=FA=B1=D2=A1=A3 If they don=A1=AFt trust the choice of majority miners, they can use = some alt coin that don=A1=AFt including miners=A1=AF part. >>=20 >>=20 >> 2. During the first two grace periods, non-mining nodes will not be >> affected. They have enough time to upgrade their software.
>> 3. Versionbits included in block header, not influencing the SPY = mining. >>
>>=20 >> The widely deployed stratum based SPV mining does not really provide = a >> proper way to validate nversion of the previous block, it only lets >> you see the nversion of the current stratum job since you don't get a >> full bock header. There's always a risk here that miners build on top >> of invalid blocks when SPV mining. >>=20 >>=20 >> =D2=B2=D0=ED=CE=D2=CA=C7=B4=ED=B5=C4=CE=D2=B2=A2=B2=BB=BF=CF=B6=A8=A1=A3= =C7=EB=B6=D4=C8=E7=BA=CE=C8=C3=D5=E2=B8=F6=B7=BD=B7=A8=BC=E6=C8=DD SPY = =CD=DA=BF=F3=CC=E1=B3=F6=BD=A8=C9=E8=D0=D4=D2=E2=BC=FB=A1=A3 >> Maybe I=A1=AFm wrong. Please give some advice that how to make it = compatible with >> SPY mining. >=20 > It's just problematic in general and I'm not sure there's a good way > around it other than putting as many safety nets as possible in place > to limit the amount of time miners mine on invalid work. For example > when an invalid BU blocks was mined on the network more than 50% of > hashpower mined on top of it for a short period of time. >=20 =CE=D2=C3=C7=D3=A6=B5=B1=D2=FD=C8=EB=C7=F8=BF=E9=D0=A3=D1=E9=A3=AC=B5=AB=C8= =E7=BA=CE=CE=AA=B2=BB=D1=E9=D6=A4=BD=F8=D0=D0 SPY = =CD=DA=BF=F3=B5=C4=BF=F3=B9=A4=CC=E1=B9=A9=BC=A4=C0=F8=CA=C7=C1=ED=CD=E2=D2= =BB=B8=F6=CE=CA=CC=E2=C1=CB=A1=A3 We should introduce block validation in the code, but how to provide = incentive to no-validating SPY miner is another problem. >>=20 >> 4. After two grace periods, all nodes must be upgraded. Otherwise = they >> cannot send transactions or get any confirmations. Compared with = forming new >> consensus among nodes, the situation is not worse than before.
>>=20 >> Previous consensus changes have largely been done in backwards >> compatible ways which lets users opt-in to new features. In general >> backwards compatibility is considered a good thing, this seems to = make >> that worse. >>=20 >>=20 >> = =D5=E2=B2=A2=C3=BB=D3=D0=C7=BF=D6=C6=CE=D2=C3=C7=B5=C4=BD=DA=B5=E3=D7=F7=B3= =F6=C8=CE=BA=CE=B8=C4=B1=E4=B9=B2=CA=B6=B5=C4=B1=ED=CA=BE=A1=A3=BD=F6=BD=F6= =C8=C3=D5=E2=D0=A9=BD=DA=B5=E3=CE=AA=BD=D3=CF=C2=C0=B4=BF=C9=C4=DC=B5=C4=B8= =C4=B1=E4=D7=F6=BA=C3=D7=BC=B1=B8=A1=A3 >> It would not force our nodes to do anything that changes the = consensus. But >> they should be prepared for the **maybe** upcoming changes. >> = =D0=AD=D2=E9=B5=C4=B8=C4=B1=E4=BD=AB=CD=A8=B9=FD=BF=F3=B9=A4=CD=B6=C6=B1=B2= =FA=C9=FA=A3=AC=B5=AB=CA=C7=D5=E2=B8=F6=B9=FD=B3=CC=D3=A6=B8=C3=B1=BB=CB=F9= =D3=D0=BD=DA=B5=E3=CB=F9=D6=AA=CF=FE=B2=A2=B3=D0=C8=CF=A1=A3 >> Protocol upgrades could be done using miners vote. but the progress = of >> voting should be acknowledged by all nodes. >=20 > I'm not seeing how it could be considered backwards compatible if > "they cannot send transactions or get any confirmations=A1=B1. = =CE=D2=B2=A2=B2=BB=B0=D1=D5=E2=B8=F6=B7=BD=B7=A8=BF=B4=D7=F7=CA=C7=CD=EA=C8= =AB=B5=C4=CF=F2=BA=F3=BC=E6=C8=DD=A1=A3=D4=DA=B4=F3=BC=D2=B6=BC=C8=CF=BF=C9= =A1=B0=C7=F8=BF=E9=B8=DF=B6=C8xxx=BA=F3=A3=AC=D6=B4=D0=D0xxx=A1=B1=B5=C4=CA= =B1=BA=F2=A3=AC=CE=D2=B2=A2=B2=BB=C8=CF=CE=AA=D5=E2=BA=DC=D6=D8=D2=AA=A1=A3= I don=A1=AFt see them as completely backwards compatible. since I don=A1=AF= t see that is important if we all agree with =A1=B0after block height = xxx, then xxx=A1=B1. =CE=D2=C3=C7=D2=C0=C8=BB=BF=C9=D2=D4=B4=D3=B4=B4=CA=C0=C7=F8=BF=E9=BF=AA=CA= =BC=D2=BB=D6=B1=D1=E9=D6=A4=B5=BD=BD=F1=CC=EC=A1=A3 And we can validate from the genesis block till today. >>=20 >>=20 >> 5. The ledger in non-mining wallet nodes is honored and reserved. = Users of >> off-chain wallet services can decide whether or not to follow the = service >> providers after they got the public notification from the service = providers. >>
>> 6. Protocol upgrades in the future can be bonded with the upgrades of = nodes, >> and the upgrades activate through miners vote independently. There = would be >> enough time for nodes to be upgraded in order to support new = protocols. Even >> in case of failing in miner activation, the situation will not worsen = and >> the status quo will remain.
>>=20 >>=20 >> =3D=3DRisks=3D=3D >>=20 >> 1. = =CB=E3=C1=A6=B5=C4=B2=A8=B6=AF=BB=E1=D3=B0=CF=EC=D7=EE=B3=A4=C1=B4=B5=C4=BD= =E1=B9=FB=A1=A3=D2=F2=B4=CB=D4=BD=B8=DF=B5=C4=BC=A4=BB=EE=B1=C8=C0=FD=D2=AA= =C7=F3=BD=AB=BC=F5=C9=D9=B6=CC=CA=B1=BC=E4=B7=D6=B2=E6=B5=C4=CE=A3=CF=D5=A1= =A3
>> 2. = =BF=F3=B9=A4=BF=C9=C4=DC=B7=A2=BC=D9=D0=C5=BA=C5=C0=B4=B1=DC=C3=E2=B1=BB=B9= =C2=C1=A2=A3=AC=B5=AB=D4=DA=C7=AE=B0=FC=BD=DA=B5=E3=BF=B4=C0=B4=CE=DE=B7=A8= =C7=F8=B7=D6=CA=C7=B7=F1=CA=C7=BC=D9=D0=C5=BA=C5=A3=AC=D6=BB=C4=DC=C9=FD=BC= =B6=A1=A3=B6=F8=C7=AE=B0=FC=BD=DA=B5=E3=C9=FD=BC=B6=D6=AE=BA=F3=A3=AC=BF=F3= =B9=A4=D2=B2=BD=AB=B8=FA=CB=E6=A1=A3
>> 3. = =C7=AE=B0=FC=BD=DA=B5=E3=BF=C9=C4=DC=B7=A2=BC=D9=D0=C5=BA=C5=C0=B4=BD=F6=C9= =FD=BC=B6=B0=E6=B1=BE=BA=C5=B6=F8=B2=BB=D6=A7=B3=D6=B0=F3=B6=A8=B5=C4=D0=AD= =D2=E9=C9=FD=BC=B6=B4=FA=C2=EB=A3=AC=B5=AB=C7=AE=B0=FC=BD=DA=B5=E3=CA=FD=C1= =BF=CE=DE=B7=A8=C5=D0=B1=F0=A3=AC=D1=CF=CB=E0=B5=C4=D5=E6=CA=B5=BD=DA=B5=E3= =D3=A6=B5=B1=B8=FA=CB=E6=BF=C9=D6=A4=CA=B5=B5=C4=BF=F3=B9=A4=CD=B6=C6=B1=BD= =E1=B9=FB=A1=A3
>> 4. >> = =B4=E6=D4=DA=C9=D9=B2=BF=B7=D6=BF=F3=B9=A4=BA=CD=C7=AE=B0=FC=BD=DA=B5=E3=B9= =B2=C4=B1=A3=AC=D4=DA=D0=C2=D0=AD=D2=E9=C9=FD=BC=B6=BC=A4=BB=EE=BA=F3=D2=C0= =C8=BB=CA=B9=D3=C3=C0=CF=D0=AD=D2=E9=CD=DA=BF=F3=B5=C4=BF=C9=C4=DC=A1=A3=D5= =E2=D6=D6=BF=C9=C4=DC=CB=E6=CA=B1=B7=A2=C9=FA=CE=DE=B7=A8=B6=C5=BE=F8=A3=AC= =B5=AB=CD=A8=B9=FD=C8=C3=B3=C1=C4=AC=B5=C4=B4=F3=B6=E0=CA=FD=C7=AE=B0=FC=BD= =DA=B5=E3=C9=FD=BC=B6=B5=C4=B7=BD=CA=BD=BF=C9=D2=D4=BD=B5=B5=CD=D5=E2=D6=D6= =D0=D0=CE=AA=B4=F8=C0=B4=B5=C4=C0=FB=D2=E6=A1=A3
>>=20 >> 1. The fluctuation of the hashing power will affect the result of the >> longest chain. Higher activating requirement means a lower risk of = temporary >> fork.
>> 2. Miners could simply signal to avoid being orphaned, but from the >> perspective of non-mining wallet nodes, they can't distinguish the = false >> signal from the true signal. They must upgrade with the assumption = that the >> signals are all true. After all the non-mining nodes have upgraded, = the >> miners signalling false signal should follow.
>>=20 >> Miners can simply announce they are false signalling with coinbase >> tags and other methods. This activation method would likely not be >> viable for controversial changes. >>=20 >>=20 >> =C8=E7=B9=FB=B4=F3=B6=E0=CA=FD=BF=F3=B9=A4=CA=C7=B3=CF=CA=B5=B5=C4=A3=AC= =BC=D9=D0=C5=BA=C5=B2=BB=BB=E1=D3=D0=CE=CA=CC=E2=A1=A3 >> False signal won=A1=AFt be a problem if majority miners are honest. >=20 > I'm referring to a potential situation where 55% of miners want a > change and 45% don't, the 45% could false signal. >=20 =B5=B1=C8=BB=A3=AC45% = =BF=C9=D2=D4=B7=A2=CB=CD=BC=D9=D0=C5=BA=C5=A3=AC=BF=C9=D2=D4=BA=CD=B2=BF=B7= =D6=BD=DA=B5=E3=B9=B2=C4=B1=A1=A3=B5=AB=D5=E2=CA=C7=B5=B1=C7=B0=D2=D1=BE=AD= =B4=E6=D4=DA=B5=C4=CE=CA=CC=E2=A3=AC=B2=A2=C3=BB=D3=D0=D2=F2=B4=CB=B8=FC=D4= =E3=B8=E2=A1=A3 Of cause, there could be false signal from 45% and have conspiracy with = some nodes. But that=A1=AFs the problem we have today, and it don=A1=AFt = get any worse (nor any better). >>=20 >> 3. Non-mining wallet nodes could false signal without supporting the = new >> protocol but since the total number of nodes cannot be distinguished, >> genuine nodes should follow the proven result provided by miners = vote.
>>=20 >> Users would likely take into account markets and other factors when >> deciding what to do, the total number of nodes doesn't really matter >> much. Miner signalling is not necessarily indicative of economic and >> user support. >>=20 >>=20 >> =BF=F3=B9=A4=D0=E8=D2=AA=D4=DA=BF=C9=D2=D4=C8=B7=B1=A3=B4=F3=B6=E0=CA=FD= =D3=C3=BB=A7=B2=BB=B1=BB=C9=FD=BC=B6=D3=B0=CF=EC=B5=C4=C7=E9=BF=F6=CF=C2=B2= =C5=C4=DC=B9=AB=D5=FD=CD=B6=C6=B1=A1=A3 >> Miners should vote unbiasedly under the condition that most users are = not >> affected by protocol upgrading. >>=20 >>=20 >> 4. Miners and non-mining nodes could conspire to fork using old = protocol >> consensus. It can't be eliminated, just like in the past but through = most >> passive non-mining nodes being upgraded, their benefit is reduced. =
>>=20 >>=20 >> =3D=3DImplementation=3D=3D >> ___TBD___ >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_5AF2E759-FAF2-4AC7-947E-7BEC5068F490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb2312 Hi = James:

=D4=DA 2017=C4=EA6=D4=C213=C8=D5=A3=AC15:19=A3=AC= James Hilliard <james.hilliard1@gmail.com> =D0=B4=B5=C0=A3=BA

On Tue, Jun 13, 2017 at 1:50 AM, = Zheming Lin <heater@gmail.com> wrote:
Hi James:

Thank you very much for detailed feedback. Sorry for my = understanding of
English being poor. I=A1=AFll try to = answer that.


=D4=DA = 2017=C4=EA6=D4=C213=C8=D5=A3=AC13:44=A3=ACJames Hilliard <james.hilliard1@gmail.com> =D0=B4=B5=C0=A3=BA


1. The activation only requires = majority miners signal. As described in the
paper by = Satoshi Nakamoto, 55% miners will be in the longest chain after 340
blocks, with 99.9% certainty. This will minimize the = possibility of delaying
network upgrades by controlling a = small number of hashing power. We can
foresee that after = 51% signalling, all miners will upgrade within the first
grace period. <br/>

Technically soft forks can be implemented at 55% hashpower = already
without an orphaning period(like BIP16). Those = that don't upgrade
would just be at risk of mining invalid = blocks. One would not want to
use this method to try and = activate a controversial hard fork since
it's trivial for = miners to false signal. The orphaning period
effectively = forces miners to make a decision but does not necessarily
force them to make a particular decision since they can = simply choose
to reject the fork and false signal.


=BC=D9=D0=C5=BA=C5=B5=C4=CE=CA=CC=E2=D4=DA=CE=D2=BF=B4=C0=B4=CE= =DE=B7=A8=BD=E2=BE=F6=A1=A3=B5=AB=C8=E7=B9=FB=B6=E0=CA=FD=B2=BB=CD=AC=D2=E2= =D5=E2=B8=F6=B8=C4=B1=E4=A3=AC=CE=AA=CA=B2=C3=B4=CB=FB=C3=C7=BB=B9=D2=AA=C6= =DB=C6=AD=A3=BF=C8=E7=B9=FB=B6=E0=CA=FD=C8=E7=D6=D0=B1=BE=B4=CF=B9=B2=CA=B6= =D6=D0=C3=E8=CA=F6=B5=C4=C4=C7=D1=F9=CA=C7=B3=CF=CA=B5=BF=C9=D0=C5=B5=C4=A3= =AC=C4=C7=BE=CD=B2=BB=BB=E1=D3=D0=C8=CE=BA=CE=CE=CA=CC=E2=A1=A3=CD=A8=B9=FD= =CB=E3=C1=A6=D7=DC=C4=DC=B7=D6=B3=F6=CA=A4=B8=BA=A1=A3
False= signal can=A1=AFt be solved in my opinion. If the majority part just = don=A1=AFt
agree with the change, why they cheat? If the = majority part is honest as
described in nakamoto = consensus, I think that won=A1=AFt be a problem. CPU power
always decides.

Nakamoto consensus is used to determine the = longest chain among
multiple valid chains, it's not = enough to determine validity by
itself. For example in a hard = fork if a minority of hashpower decided
not to fork then they would = simply consider the forked chain invalid
and ignore it, even if that = majority chain had significantly more
work.

=BD=DA=B5=E3=D0=E8=D2=AA=D7=D4=D6=F7=BE=F6=B6=A8=CA=C7= =B7=F1=B8=FA=CB=E6=D0=AD=D2=E9=C9=FD=BC=B6=A1=A3=B5=AB=CA=C7=CB=FB=C3=C7=B2= =BB=C4=DC=B1=BB=B6=AF=B5=C4=CA=B2=C3=B4=B6=BC=B2=BB=D7=F6=A1=A3=CB=FB=C3=C7= =D7=DC=CA=C7=B4=E6=D4=DA=D3=D0=B6=E0=D6=D6=B5=C4=D1=A1=D4=F1=A1=A3
The node should decide to follow the protocol upgrade or not. But = they can=A1=AFt just be passive and do nothing. The choice is always = provided.

=C8=E7=B9=FB=CB=FB=C3=C7=B2=A2=B2=BB=CF=E0=D0=C5=B4=F3= =B6=E0=CA=FD=B5=C4=BF=F3=B9=A4=A3=AC=CB=FB=C3=C7=BF=C9=D2=D4=D1=A1=D4=F1=D2= =BB=D0=A9=C3=BB=D3=D0=BF=F3=B9=A4=BD=C7=C9=AB=B5=C4=CC=E6=B4=FA=B1=D2=A1=A3=
If they don=A1=AFt trust the choice of majority miners, they = can use some alt coin that don=A1=AFt including miners=A1=AF = part.



2. During the first two grace periods, non-mining nodes will = not be
affected. They have enough time to upgrade their = software. <br/>
3. Versionbits included in block = header, not influencing the SPY mining.
<br/>

The widely deployed stratum based SPV mining = does not really provide a
proper way to validate nversion = of the previous block, it only lets
you see the nversion = of the current stratum job since you don't get a
full bock = header. There's always a risk here that miners build on top
of invalid blocks when SPV mining.


=D2=B2=D0=ED=CE=D2=CA=C7=B4=ED=B5=C4=CE=D2=B2=A2= =B2=BB=BF=CF=B6=A8=A1=A3=C7=EB=B6=D4=C8=E7=BA=CE=C8=C3=D5=E2=B8=F6=B7=BD=B7= =A8=BC=E6=C8=DD SPY =CD=DA=BF=F3=CC=E1=B3=F6=BD=A8=C9=E8=D0=D4=D2=E2=BC=FB= =A1=A3
Maybe I=A1=AFm wrong. Please give some advice that = how to make it compatible with
SPY mining.

It's just problematic in general and I'm = not sure there's a good way
around it other than putting as = many safety nets as possible in place
to limit the amount of time = miners mine on invalid work. For example
when an invalid BU blocks was = mined on the network more than 50% of
hashpower mined on top of it for = a short period of time.


=CE=D2=C3=C7=D3=A6=B5=B1=D2=FD=C8=EB=C7=F8=BF=E9=D0=A3= =D1=E9=A3=AC=B5=AB=C8=E7=BA=CE=CE=AA=B2=BB=D1=E9=D6=A4=BD=F8=D0=D0 SPY = =CD=DA=BF=F3=B5=C4=BF=F3=B9=A4=CC=E1=B9=A9=BC=A4=C0=F8=CA=C7=C1=ED=CD=E2=D2= =BB=B8=F6=CE=CA=CC=E2=C1=CB=A1=A3
We should introduce block = validation in the code, but how to provide incentive to no-validating = SPY miner is another problem.



4. After two = grace periods, all nodes must be upgraded. Otherwise they
cannot send transactions or get any confirmations. Compared = with forming new
consensus among nodes, the situation is = not worse than before. <br/>

Previous = consensus changes have largely been done in backwards
compatible ways which lets users opt-in to new features. In = general
backwards compatibility is considered a good = thing, this seems to make
that worse.


=D5=E2=B2=A2=C3=BB=D3=D0=C7=BF=D6=C6=CE=D2=C3=C7=B5=C4=BD=DA=B5= =E3=D7=F7=B3=F6=C8=CE=BA=CE=B8=C4=B1=E4=B9=B2=CA=B6=B5=C4=B1=ED=CA=BE=A1=A3= =BD=F6=BD=F6=C8=C3=D5=E2=D0=A9=BD=DA=B5=E3=CE=AA=BD=D3=CF=C2=C0=B4=BF=C9=C4= =DC=B5=C4=B8=C4=B1=E4=D7=F6=BA=C3=D7=BC=B1=B8=A1=A3
It = would not force our nodes to do anything that changes the consensus. = But
they should be prepared for the **maybe** upcoming = changes.
=D0=AD=D2=E9=B5=C4=B8=C4=B1=E4=BD=AB=CD=A8=B9=FD=BF=F3=B9=A4=CD= =B6=C6=B1=B2=FA=C9=FA=A3=AC=B5=AB=CA=C7=D5=E2=B8=F6=B9=FD=B3=CC=D3=A6=B8=C3= =B1=BB=CB=F9=D3=D0=BD=DA=B5=E3=CB=F9=D6=AA=CF=FE=B2=A2=B3=D0=C8=CF=A1=A3Protocol upgrades could be done using miners vote. but the = progress of
voting should be acknowledged by all nodes.

I'm not seeing how it could be considered = backwards compatible if
"they cannot send transactions = or get any confirmations=A1=B1.

=CE=D2=B2=A2=B2=BB=B0=D1=D5=E2=B8=F6=B7=BD=B7=A8=BF=B4= =D7=F7=CA=C7=CD=EA=C8=AB=B5=C4=CF=F2=BA=F3=BC=E6=C8=DD=A1=A3=D4=DA=B4=F3=BC= =D2=B6=BC=C8=CF=BF=C9=A1=B0=C7=F8=BF=E9=B8=DF=B6=C8xxx=BA=F3=A3=AC=D6=B4=D0= =D0xxx=A1=B1=B5=C4=CA=B1=BA=F2=A3=AC=CE=D2=B2=A2=B2=BB=C8=CF=CE=AA=D5=E2=BA= =DC=D6=D8=D2=AA=A1=A3
I don=A1=AFt see them as completely = backwards compatible. since I don=A1=AFt see that is important if we all = agree with =A1=B0after block height xxx, then = xxx=A1=B1.
=CE=D2=C3=C7=D2=C0=C8=BB=BF=C9=D2=D4=B4=D3=B4=B4=CA=C0= =C7=F8=BF=E9=BF=AA=CA=BC=D2=BB=D6=B1=D1=E9=D6=A4=B5=BD=BD=F1=CC=EC=A1=A3
And we can validate from the genesis block till = today.




5. The ledger in non-mining = wallet nodes is honored and reserved. Users of
off-chain = wallet services can decide whether or not to follow the service
providers after they got the public notification from the = service providers.
<br/>
6. Protocol = upgrades in the future can be bonded with the upgrades of nodes,
and the upgrades activate through miners vote independently. = There would be
enough time for nodes to be upgraded in = order to support new protocols. Even
in case of failing in = miner activation, the situation will not worsen and
the = status quo will remain. <br/>


=3D=3DRisks=3D=3D

1. = =CB=E3=C1=A6=B5=C4=B2=A8=B6=AF=BB=E1=D3=B0=CF=EC=D7=EE=B3=A4=C1=B4=B5=C4=BD= =E1=B9=FB=A1=A3=D2=F2=B4=CB=D4=BD=B8=DF=B5=C4=BC=A4=BB=EE=B1=C8=C0=FD=D2=AA= =C7=F3=BD=AB=BC=F5=C9=D9=B6=CC=CA=B1=BC=E4=B7=D6=B2=E6=B5=C4=CE=A3=CF=D5=A1= =A3<br/>
2. = =BF=F3=B9=A4=BF=C9=C4=DC=B7=A2=BC=D9=D0=C5=BA=C5=C0=B4=B1=DC=C3=E2=B1=BB=B9= =C2=C1=A2=A3=AC=B5=AB=D4=DA=C7=AE=B0=FC=BD=DA=B5=E3=BF=B4=C0=B4=CE=DE=B7=A8= =C7=F8=B7=D6=CA=C7=B7=F1=CA=C7=BC=D9=D0=C5=BA=C5=A3=AC=D6=BB=C4=DC=C9=FD=BC= =B6=A1=A3=B6=F8=C7=AE=B0=FC=BD=DA=B5=E3=C9=FD=BC=B6=D6=AE=BA=F3=A3=AC=BF=F3= =B9=A4=D2=B2=BD=AB=B8=FA=CB=E6=A1=A3<br/>
3. = =C7=AE=B0=FC=BD=DA=B5=E3=BF=C9=C4=DC=B7=A2=BC=D9=D0=C5=BA=C5=C0=B4=BD=F6=C9= =FD=BC=B6=B0=E6=B1=BE=BA=C5=B6=F8=B2=BB=D6=A7=B3=D6=B0=F3=B6=A8=B5=C4=D0=AD= =D2=E9=C9=FD=BC=B6=B4=FA=C2=EB=A3=AC=B5=AB=C7=AE=B0=FC=BD=DA=B5=E3=CA=FD=C1= =BF=CE=DE=B7=A8=C5=D0=B1=F0=A3=AC=D1=CF=CB=E0=B5=C4=D5=E6=CA=B5=BD=DA=B5=E3= =D3=A6=B5=B1=B8=FA=CB=E6=BF=C9=D6=A4=CA=B5=B5=C4=BF=F3=B9=A4=CD=B6=C6=B1=BD= =E1=B9=FB=A1=A3<br/>
4.
=B4=E6=D4=DA=C9=D9=B2=BF=B7=D6=BF=F3=B9=A4=BA=CD=C7=AE=B0=FC=BD= =DA=B5=E3=B9=B2=C4=B1=A3=AC=D4=DA=D0=C2=D0=AD=D2=E9=C9=FD=BC=B6=BC=A4=BB=EE= =BA=F3=D2=C0=C8=BB=CA=B9=D3=C3=C0=CF=D0=AD=D2=E9=CD=DA=BF=F3=B5=C4=BF=C9=C4= =DC=A1=A3=D5=E2=D6=D6=BF=C9=C4=DC=CB=E6=CA=B1=B7=A2=C9=FA=CE=DE=B7=A8=B6=C5= =BE=F8=A3=AC=B5=AB=CD=A8=B9=FD=C8=C3=B3=C1=C4=AC=B5=C4=B4=F3=B6=E0=CA=FD=C7= =AE=B0=FC=BD=DA=B5=E3=C9=FD=BC=B6=B5=C4=B7=BD=CA=BD=BF=C9=D2=D4=BD=B5=B5=CD= =D5=E2=D6=D6=D0=D0=CE=AA=B4=F8=C0=B4=B5=C4=C0=FB=D2=E6=A1=A3<br/>
1. The fluctuation of the hashing power will = affect the result of the
longest chain. Higher activating = requirement means a lower risk of temporary
fork. = <br/>
2. Miners could simply signal to avoid being = orphaned, but from the
perspective of non-mining wallet = nodes, they can't distinguish the false
signal from the = true signal. They must upgrade with the assumption that the
signals are all true. After all the non-mining nodes have = upgraded, the
miners signalling false signal should = follow. <br/>

Miners can simply = announce they are false signalling with coinbase
tags and = other methods. This activation method would likely not be
viable for controversial changes.


=C8=E7=B9=FB=B4=F3=B6=E0=CA=FD=BF=F3=B9=A4=CA=C7= =B3=CF=CA=B5=B5=C4=A3=AC=BC=D9=D0=C5=BA=C5=B2=BB=BB=E1=D3=D0=CE=CA=CC=E2=A1= =A3
False signal won=A1=AFt be a problem if majority = miners are honest.

I'm referring to a potential = situation where 55% of miners want a
change and 45% don't, the 45% = could false signal.


=B5=B1=C8=BB=A3= =AC45% = =BF=C9=D2=D4=B7=A2=CB=CD=BC=D9=D0=C5=BA=C5=A3=AC=BF=C9=D2=D4=BA=CD=B2=BF=B7= =D6=BD=DA=B5=E3=B9=B2=C4=B1=A1=A3=B5=AB=D5=E2=CA=C7=B5=B1=C7=B0=D2=D1=BE=AD= =B4=E6=D4=DA=B5=C4=CE=CA=CC=E2=A3=AC=B2=A2=C3=BB=D3=D0=D2=F2=B4=CB=B8=FC=D4= =E3=B8=E2=A1=A3
Of cause, there could be false signal from 45% = and have conspiracy with some nodes. But that=A1=AFs the problem we have = today, and it don=A1=AFt get any worse (nor any better).



3. Non-mining = wallet nodes could false signal without supporting the new
protocol but since the total number of nodes cannot be = distinguished,
genuine nodes should follow the proven = result provided by miners vote. <br/>

Users would likely take into account markets and other = factors when
deciding what to do, the total number of = nodes doesn't really matter
much. Miner signalling is not = necessarily indicative of economic and
user support.


=BF=F3=B9=A4=D0=E8=D2=AA=D4=DA=BF=C9=D2=D4=C8=B7=B1=A3=B4=F3=B6= =E0=CA=FD=D3=C3=BB=A7=B2=BB=B1=BB=C9=FD=BC=B6=D3=B0=CF=EC=B5=C4=C7=E9=BF=F6= =CF=C2=B2=C5=C4=DC=B9=AB=D5=FD=CD=B6=C6=B1=A1=A3
Miners = should vote unbiasedly under the condition that most users are not
affected by protocol upgrading.


4. Miners and non-mining nodes could conspire = to fork using old protocol
consensus. It can't be = eliminated, just like in the past but through most
passive = non-mining nodes being upgraded, their benefit is reduced. = <br/>


=3D=3DImplementation=3D=3D
___TBD___

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /blockquote>

= --Apple-Mail=_5AF2E759-FAF2-4AC7-947E-7BEC5068F490--