Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Jared Lee Richardson via bitcoin-dev]

> and allows for resource requirements
> that are too high for many users to validate. The block size settings
> there are effectively placebo controls.

Right, but that's my point.  Any level of control the fullnodes believe
they have is effectively a placebo, unless the opposition to the miners is
essentially unanimous (and maybe not even then, if the chainsplit doesn't
have any miners to get to the next difficulty change or gets attacked
repeatedly).

> I'm advocating that resource requirements be low
> enough that full validation remains possible for a large percentage of
> the economy.

We're derailed from the main thread at this point, but just wanted to state
that I agree in part.  The part I don't agree with is when a single
transaction begins to cost more than a month's worth of full validation,
which has already happened at least once last week, the full validation is
on its way to becoming worthless.  The two costs have to be balanced for
the coin to have utility for its users.

I agree with the rest.

Jared

On Tue, Jun 13, 2017 at 5:23 PM, James Hilliard 
wrote:

> On Tue, Jun 13, 2017 at 2:35 PM, Jared Lee Richardson
>  wrote:
> >> Wallet nodes being able to fully validate and choose whether or not to
> > accept a particular chain is an important part of bitcoins security
> > model.
> >
> > What you're describing is effectively the same as BU.
>
> BU by default uses an "Accept Depth" parameter which effectively lets
> miners decide block size rules and allows for resource requirements
> that are too high for many users to validate. The block size settings
> there are effectively placebo controls.
>
> >
> > Nodes follow chains, they do not decide the victor.  The average user
> > follows the default of the software, which is to follow the longest valid
> > chain.  Forcing the average user to decide which software to run is far
> more
> > valuable than allowing "the software" to decide things, when in fact all
> it
> > will do is decide the previous default.
>
> That's largely true that they typically don't decide the victor in
> soft forks unless they are the ones to activate the rules
> changes(satoshi did this a few times in the early days), however they
> make it very difficult for a hard fork to be activated without
> consent. Yes, I'm not advocating for having runtime consensus settings
> for nodes either, I'm advocating that resource requirements be low
> enough that full validation remains possible for a large percentage of
> the economy.
>
> >
> >> 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
> >
> > This is true and a good point.  A false signal from miners could trick
> the
> > honest miners into forking off prematurely with a minority.
>
> More likely the false signal would be used during the orphaning period
> to prevent blocks from being orphaned for miners that don't want to
> follow the fork.
>
> >
> >>  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.
> >
> > This is the job of the stratum server and the pool operator.  These are
> > distinct responsibilities; Miners should choose a pool operator in line
> with
> > their desires.  Solo mining is basically dead, as it will never again be
> > practical(and has not been for at least 2 years) for the same hardware
> that
> > does the mining to also do full node operation.
> >
> > If the pool operator/stratum server also does not do validation, then any
> > number of problems could occur.
>
> Yes, there is a good amount of risk with validationless mining right
> now here since it's well known that over half of mining pools use
> validationless mining to some degree. This may not be too bad though
> due to fallbacks but the risk is probably fairly implementation
> specific.
>
> >
> >
> >
> >
> > On Mon, Jun 12, 2017 at 10:44 PM, James Hilliard via bitcoin-dev
> >  wrote:
> >>
> >> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
> >>  wrote:
> >> > The BIP is described using Chinese and English. If any part is missing
> >> > or need more specific, please reply. Forgive for my poor English.
> >> >
> >> > This method will incorporate any upgrade that affects non-mining
> nodes.
> >> > They should beware that the rule has been changed.
> >> >
> >> > TLDR: Major miners activate and orphan the minor. That ensures all
> >> > miners upgrades. Then invalid the tx from not upgrading nodes. Nodes
> must
> >> > upgrade (with other protocol upgrade codes) in order to work. Then
> the final
> >> > miner vote over protocol upgrade, with all nodes has the same upgraded
> >> > codes.
> >> >
> >> > 
> >> > BIP: ???
> >> > Title: Demonstration of Phase in

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 2:35 PM, Jared Lee Richardson
 wrote:
>> Wallet nodes being able to fully validate and choose whether or not to
> accept a particular chain is an important part of bitcoins security
> model.
>
> What you're describing is effectively the same as BU.

BU by default uses an "Accept Depth" parameter which effectively lets
miners decide block size rules and allows for resource requirements
that are too high for many users to validate. The block size settings
there are effectively placebo controls.

>
> Nodes follow chains, they do not decide the victor.  The average user
> follows the default of the software, which is to follow the longest valid
> chain.  Forcing the average user to decide which software to run is far more
> valuable than allowing "the software" to decide things, when in fact all it
> will do is decide the previous default.

That's largely true that they typically don't decide the victor in
soft forks unless they are the ones to activate the rules
changes(satoshi did this a few times in the early days), however they
make it very difficult for a hard fork to be activated without
consent. Yes, I'm not advocating for having runtime consensus settings
for nodes either, I'm advocating that resource requirements be low
enough that full validation remains possible for a large percentage of
the economy.

>
>> 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
>
> This is true and a good point.  A false signal from miners could trick the
> honest miners into forking off prematurely with a minority.

More likely the false signal would be used during the orphaning period
to prevent blocks from being orphaned for miners that don't want to
follow the fork.

>
>>  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.
>
> This is the job of the stratum server and the pool operator.  These are
> distinct responsibilities; Miners should choose a pool operator in line with
> their desires.  Solo mining is basically dead, as it will never again be
> practical(and has not been for at least 2 years) for the same hardware that
> does the mining to also do full node operation.
>
> If the pool operator/stratum server also does not do validation, then any
> number of problems could occur.

Yes, there is a good amount of risk with validationless mining right
now here since it's well known that over half of mining pools use
validationless mining to some degree. This may not be too bad though
due to fallbacks but the risk is probably fairly implementation
specific.

>
>
>
>
> On Mon, Jun 12, 2017 at 10:44 PM, James Hilliard via bitcoin-dev
>  wrote:
>>
>> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>>  wrote:
>> > The BIP is described using Chinese and English. If any part is missing
>> > or need more specific, please reply. Forgive for my poor English.
>> >
>> > This method will incorporate any upgrade that affects non-mining nodes.
>> > They should beware that the rule has been changed.
>> >
>> > TLDR: Major miners activate and orphan the minor. That ensures all
>> > miners upgrades. Then invalid the tx from not upgrading nodes. Nodes must
>> > upgrade (with other protocol upgrade codes) in order to work. Then the 
>> > final
>> > miner vote over protocol upgrade, with all nodes has the same upgraded
>> > codes.
>> >
>> > 
>> > BIP: ???
>> > Title: Demonstration of Phase in Full Network Upgrade Activated by
>> > Miners
>> > Author: LIN Zheming
>> > Status: Draft
>> > Type: Standards Track
>> > Created: 2017-06-12
>> > 
>> >
>> > ==Summary==
>> >
>> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
>> > This idea was not created by an individual but is a product of
>> > collaboration in the Chinese bitcoin community between different interest
>> > groups.
>> >
>> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
>> > This method is put forth to incentivize and to protect mining nodes and
>> > non-mining nodes during protocol upgrading. With this incentive mechanism,
>> > the non-mining nodes will not suffer monetary loss from chain
>> > splitting.
>> >
>> >
>> > 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。
>> >
>> > After the activation condition is met, majority miners will set a new
>> > block versionbits after the first grace period(a difficulty change of 2016
>> > blocks). The blocks with lower versionbits will be orphaned. In terms of 
>> > the
>> > Nakamoto Consensus, the end of the first grace period will force all mining
>> >

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Jared Lee Richardson via bitcoin-dev]

> Wallet nodes being able to fully validate and choose whether or not to
accept a particular chain is an important part of bitcoins security
model.

What you're describing is effectively the same as BU.

Nodes follow chains, they do not decide the victor.  The average user
follows the default of the software, which is to follow the longest valid
chain.  Forcing the average user to decide which software to run is far
more valuable than allowing "the software" to decide things, when in fact
all it will do is decide the previous default.

> 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

This is true and a good point.  A false signal from miners could trick the
honest miners into forking off prematurely with a minority.

>  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.

This is the job of the stratum server and the pool operator.  These are
distinct responsibilities; Miners should choose a pool operator in line
with their desires.  Solo mining is basically dead, as it will never again
be practical(and has not been for at least 2 years) for the same hardware
that does the mining to also do full node operation.

If the pool operator/stratum server also does not do validation, then any
number of problems could occur.




On Mon, Jun 12, 2017 at 10:44 PM, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>  wrote:
> > The BIP is described using Chinese and English. If any part is missing
> or need more specific, please reply. Forgive for my poor English.
> >
> > This method will incorporate any upgrade that affects non-mining nodes.
> They should beware that the rule has been changed.
> >
> > TLDR: Major miners activate and orphan the minor. That ensures all
> miners upgrades. Then invalid the tx from not upgrading nodes. Nodes must
> upgrade (with other protocol upgrade codes) in order to work. Then the
> final miner vote over protocol upgrade, with all nodes has the same
> upgraded codes.
> >
> > 
> > BIP: ???
> > Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> > Author: LIN Zheming
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-06-12
> > 
> >
> > ==Summary==
> >
> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
> > This idea was not created by an individual but is a product of
> collaboration in the Chinese bitcoin community between different interest
> groups.
> >
> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
> > This method is put forth to incentivize and to protect mining nodes and
> non-mining nodes during protocol upgrading. With this incentive mechanism,
> the non-mining nodes will not suffer monetary loss from chain
> splitting.
> >
> > 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。
> 通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，
> 未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。
> 并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。
> >
> > After the activation condition is met, majority miners will set a new
> block versionbits after the first grace period(a difficulty change of 2016
> blocks). The blocks with lower versionbits will be orphaned. In terms of
> the Nakamoto Consensus, the end of the first grace period will force all
> mining nodes upgraded to signal a new version of consensus. After the
> second grace period ( a difficulty change of 2016 blocks), mining nodes
> will only accept transactions with new versionbits. Transactions from nodes
> not upgrading will not be relayed nor included in blocks with new
> versionbits. This will protect funds of non-mining nodes from utilizing
> replay attack and will function as a notification for them to upgrade.
> Codes dealing with protocol upgrade could be included in the upgrade. After
> the non-mining node upgrades, mining nodes will vote to activate the
> protocol upgrade and this will achieve the broad/widespread deployment of
> the protocol upgrade.
> >
> > 在该项改动广泛部署至客户端之后，依然由其激活条件控制。
> > The protocol upgrade depends on its activate condition independently
> even after the change deployed among nodes.
> >
> > ==Motivation==
> >
> > 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。
> > In view of the fact that the original Bitcoin consensus did not consider
> the non-mining wallet nodes(as mentioned above), the result is that
> upgrading the consensus of these wallet nodes is passive and lazy. When
> there is disagreement in the direction of the upgrade, the miners have no
> mechanism to ensure that the chain being extend

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Gregory Maxwell via bitcoin-dev]

On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
 wrote:
> The BIP is described using Chinese and English. If any part is missing or 
> need more specific, please reply. Forgive for my poor English.

Your English is much better than my Chinese.  Thank you for taking the
time to write this.

I am still reading and trying to completely understand your proposal
but I wanted to make one observation:

> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
> In view of the fact that the original Bitcoin consensus did not consider the 
> non-mining wallet nodes(as mentioned above), the result is that upgrading the 
> consensus of these wallet nodes is passive and lazy.

This is not true. Non-mining wallet nodes were considered, and their
upgrade practices are not usually slower than miners.

Even in the very first version of the software it did not mine unless
the user went into the settings and explicitly turned it on or used a
command-line option.  By default, every installation of Bitcoin was a
non-mining wallet node.

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.

Frequently it is the miners that are "passive and lazy" in upgrading.
In some cases when new versions have had major improvements specific
to mining (such as for 0.8) miners upgraded much faster than other
nodes. But often, it is the other way around and miners adopt new
versions much slower than other nodes. If you look at block
construction today you will see that many miners are running highly
outdated node software which is more than one or even two years old.
(and as a result, they lose out on a considerable amount of
transaction fees.)

In fact, many miners have the most severe form of passive behavior:
they do not run a node at all but simply sell their hash power to
pools (which themselves are often slow to upgrade).  By comparison,
http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html 95%
of reachable nodes are running software now from the last year and a
half.

I do not, however, believe that it is a problem that anyone is slow to upgrade.

Reliability cannot be maintained in infrastructure if it is rapidly
changing.  A normal deployment process for major systems
infrastructure outside of Bitcoin usually takes months because time
must be given to test and find bugs.

Miners depend on their income from mining and interruptions can be
very costly.  Many pools are also involved with altcoins which are
constantly breaking and they have their attention directed elsewhere
and cannot quickly spare the time required to upgrade their software.
These delays are the natural consequence of a decentralized system
where no one has the power to force other people to adopt their
priorities.

If you look at the deployment processes of major internet protocols,
HTTP2, new versions of SSH, BGP,  or IP itself you will find that
upgrades often happen slower than the entire life of Bitcoin so far--
and none of these protocols have the difficult consistency challenges
of Bitcoin or as much risk of irreparable financial loss if things go
wrong.

Because many people in the Bitcoin community appears to expect
upgrades much faster than even centralized ISP backbones upgrade their
router software I think they have unrealistic expectations with how
fast upgrading can occur while preserving stability, security, and
decentralization and unrealistic expectations of how fast upgrading
will occur so long as no one has the ability to force other people to
run their upgrades.

I look forward to competing my understanding of your proposal.

Cheers,
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 3:24 AM, Zheming Lin via bitcoin-dev
 wrote:
> Hi all the developers:
>
> I must clarify that despite the general ideas comes from discussions with 
> others. The opinion in replies are only limited to my self.
>
> The old TXs can be re-enable after the fourth stage and just like **nothing 
> happened** with the grace periods. The code can be provided with the protocol 
> upgrade voting. At the end of the vote, either success or failed, we can have 
> old TXs work again. It’s like after a long time that the block jammed. I 
> think nobody get harmed (Is there? I’m not so sure about that), that’s the 
> purpose.

I think that would cause problems with systems like lightning network
that rely on reliable confirmations of transactions as part of their
security models.

>
> Thank you for your time and kindly replies. Your opinions are more than 
> welcome.
>
> LIN Zheming
>
>> 在 2017年6月13日，10:23，Zheming Lin  写道：
>>
>> The BIP is described using Chinese and English. If any part is missing or 
>> need more specific, please reply. Forgive for my poor English.
>>
>> This method will incorporate any upgrade that affects non-mining nodes. They 
>> should beware that the rule has been changed.
>>
>> TLDR: Major miners activate and orphan the minor. That ensures all miners 
>> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade 
>> (with other protocol upgrade codes) in order to work. Then the final miner 
>> vote over protocol upgrade, with all nodes has the same upgraded codes.
>>
>> 
>> BIP: ???
>> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
>> Author: LIN Zheming
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-06-12
>> 
>>
>> ==Summary==
>>
>> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
>> This idea was not created by an individual but is a product of collaboration 
>> in the Chinese bitcoin community between different interest groups.
>>
>> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
>> This method is put forth to incentivize and to protect mining nodes and 
>> non-mining nodes during protocol upgrading. With this incentive mechanism, 
>> the non-mining nodes will not suffer monetary loss from chain splitting.
>>
>> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。
>>
>> After the activation condition is met, majority miners will set a new block 
>> versionbits after the first grace period(a difficulty change of 2016 
>> blocks). The blocks with lower versionbits will be orphaned. In terms of the 
>> Nakamoto Consensus, the end of the first grace period will force all mining 
>> nodes upgraded to signal a new version of consensus. After the second grace 
>> period ( a difficulty change of 2016 blocks), mining nodes will only accept 
>> transactions with new versionbits. Transactions from nodes not upgrading 
>> will not be relayed nor included in blocks with new versionbits. This will 
>> protect funds of non-mining nodes from utilizing replay attack and will 
>> function as a notification for them to upgrade. Codes dealing with protocol 
>> upgrade could be included in the upgrade. After the non-mining node 
>> upgrades, mining nodes will vote to activate the protocol upgrade and this 
>> will achieve the broad/widespread deployment of the protocol upgrade.
>>
>> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。
>> The protocol upgrade depends on its activate condition independently even 
>> after the change deployed among nodes.
>>
>> ==Motivation==
>>
>> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
>> In view of the fact that the original Bitcoin consensus did not consider the 
>> non-mining wallet nodes(as mentioned above), the result is that upgrading 
>> the consensus of these wallet nodes is passive and lazy. When there is 
>> disagreement in the direction of the upgrade, the miners have no mechanism 
>> to ensure that the chain being extended is the chain widely accepted by the 
>> wallet nodes. This also adversely affects the security of the wallet 
>> nodes.
>>
>> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
>>
>> Apart from ensuring the asset security of wallet nodes, this method can be 
>> used to provide additional incentives to upgrade the protocol for the wallet 
>> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can 
>> be guaranteed to work - not only on the longest chain, but also on the 
>> longest chain used by other wallet nodes in the broader bitcoin sphere. 
>> Under the Nakamoto Consensus, there will be no persistent forks as protocol 
>> upgrades can be phased in.
>>
>> ==Specification==
>>
>> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Zheming Lin via bitcoin-dev]

Hi all the developers:

I must clarify that despite the general ideas comes from discussions with 
others. The opinion in replies are only limited to my self.

The old TXs can be re-enable after the fourth stage and just like **nothing 
happened** with the grace periods. The code can be provided with the protocol 
upgrade voting. At the end of the vote, either success or failed, we can have 
old TXs work again. It’s like after a long time that the block jammed. I think 
nobody get harmed (Is there? I’m not so sure about that), that’s the purpose.

Thank you for your time and kindly replies. Your opinions are more than welcome.

LIN Zheming

> 在 2017年6月13日，10:23，Zheming Lin  写道：
> 
> The BIP is described using Chinese and English. If any part is missing or 
> need more specific, please reply. Forgive for my poor English.
> 
> This method will incorporate any upgrade that affects non-mining nodes. They 
> should beware that the rule has been changed.
> 
> TLDR: Major miners activate and orphan the minor. That ensures all miners 
> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade 
> (with other protocol upgrade codes) in order to work. Then the final miner 
> vote over protocol upgrade, with all nodes has the same upgraded codes.
> 
> 
> BIP: ???
> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> Author: LIN Zheming
> Status: Draft
> Type: Standards Track
> Created: 2017-06-12
> 
> 
> ==Summary==
> 
> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
> This idea was not created by an individual but is a product of collaboration 
> in the Chinese bitcoin community between different interest groups.
> 
> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
> This method is put forth to incentivize and to protect mining nodes and 
> non-mining nodes during protocol upgrading. With this incentive mechanism, 
> the non-mining nodes will not suffer monetary loss from chain splitting.
> 
> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。
> 
> After the activation condition is met, majority miners will set a new block 
> versionbits after the first grace period(a difficulty change of 2016 blocks). 
> The blocks with lower versionbits will be orphaned. In terms of the Nakamoto 
> Consensus, the end of the first grace period will force all mining nodes 
> upgraded to signal a new version of consensus. After the second grace period 
> ( a difficulty change of 2016 blocks), mining nodes will only accept 
> transactions with new versionbits. Transactions from nodes not upgrading will 
> not be relayed nor included in blocks with new versionbits. This will protect 
> funds of non-mining nodes from utilizing replay attack and will function as a 
> notification for them to upgrade. Codes dealing with protocol upgrade could 
> be included in the upgrade. After the non-mining node upgrades, mining nodes 
> will vote to activate the protocol upgrade and this will achieve the 
> broad/widespread deployment of the protocol upgrade.
> 
> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。
> The protocol upgrade depends on its activate condition independently even 
> after the change deployed among nodes.
> 
> ==Motivation==
> 
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
> In view of the fact that the original Bitcoin consensus did not consider the 
> non-mining wallet nodes(as mentioned above), the result is that upgrading the 
> consensus of these wallet nodes is passive and lazy. When there is 
> disagreement in the direction of the upgrade, the miners have no mechanism to 
> ensure that the chain being extended is the chain widely accepted by the 
> wallet nodes. This also adversely affects the security of the wallet 
> nodes.
> 
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
> 
> Apart from ensuring the asset security of wallet nodes, this method can be 
> used to provide additional incentives to upgrade the protocol for the wallet 
> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can be 
> guaranteed to work - not only on the longest chain, but also on the longest 
> chain used by other wallet nodes in the broader bitcoin sphere. Under the 
> Nakamoto Consensus, there will be no persistent forks as protocol upgrades 
> can be phased in.
> 
> ==Specification==
> 
> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。
> 
> 1. Mining nodes signal by setting a version bit. While this BIP is active, 
> all blocks must set the chosen nVersion.
> 2. Mining nodes will use tx version to define current version transactions. 

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Zheming Lin via bitcoin-dev]

Hi James:

> 在 2017年6月13日，15:19，James Hilliard  写道：
> 
> On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin  > wrote:
>> Hi James:
>> 
>> Thank you very much for detailed feedback. Sorry for my understanding of
>> English being poor. I’ll try to answer that.
>> 
>> 
>> 在 2017年6月13日，13:44，James Hilliard  写道：
>> 
>> 
>> 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. 
>> 
>> 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.
>> 
>> 
>> 假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
>> False signal can’t be solved in my opinion. If the majority part just don’t
>> agree with the change, why they cheat? If the majority part is honest as
>> described in nakamoto consensus, I think that won’t 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.
> 

节点需要自主决定是否跟随协议升级。但是他们不能被动的什么都不做。他们总是存在有多种的选择。
The node should decide to follow the protocol upgrade or not. But they can’t 
just be passive and do nothing. The choice is always provided.

如果他们并不相信大多数的矿工，他们可以选择一些没有矿工角色的替代币。
If they don’t trust the choice of majority miners, they can use some alt coin 
that don’t including miners’ part.

>> 
>> 
>> 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.
>> 
>> 
>> 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.
>> 
>> 
>> 也许我是错的我并不肯定。请对如何让这个方法兼容 SPY 挖矿提出建设性意见。
>> Maybe I’m 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.
> 

我们应当引入区块校验，但如何为不验证进行 SPY 挖矿的矿工提供激励是另外一个问题了。
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. 
>> 
>> 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.
>> 
>> 
>> 这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
>> It would not force our nodes to do anything that changes the consensus. But
>> they should be prepared for the **maybe** upcoming changes.
>> 协议的改变将通过矿工投票产生，但是这个过程应该被所有节点所知晓并承认。
>> Protocol 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”.

我并不把这个方法看作是完全的向后兼容。在大家都认可“区块高度xxx后，执行xxx”的时候，我并不认为这很重要。
I don’t see them as completely backwards compatible. since I don’t see that is 
important if we all agree with “after block height xxx, then xxx”.
我们依然可以从创世区块开始一直验证到今天。
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 t

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Zheming Lin via bitcoin-dev]

Hi James:

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


> 在 2017年6月13日，13:44，James Hilliard  写道：
> 
> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>  > wrote:
>> The BIP is described using Chinese and English. If any part is missing or 
>> need more specific, please reply. Forgive for my poor English.
>> 
>> This method will incorporate any upgrade that affects non-mining nodes. They 
>> should beware that the rule has been changed.
>> 
>> TLDR: Major miners activate and orphan the minor. That ensures all miners 
>> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade 
>> (with other protocol upgrade codes) in order to work. Then the final miner 
>> vote over protocol upgrade, with all nodes has the same upgraded codes.
>> 
>> ==Motivation==
>> 
>> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
>> In view of the fact that the original Bitcoin consensus did not consider the 
>> non-mining wallet nodes(as mentioned above), the result is that upgrading 
>> the consensus of these wallet nodes is passive and lazy. When there is 
>> disagreement in the direction of the upgrade, the miners have no mechanism 
>> to ensure that the chain being extended is the chain widely accepted by the 
>> wallet nodes. This also adversely affects the security of the wallet 
>> nodes.
> Wallet nodes being able to fully validate and choose whether or not to
> accept a particular chain is an important part of bitcoins security
> model.

是的我认为这些节点非常重要，因此不愿意看到这些节点因为无法预见到网络上可能发生的改变而蒙受损失。这些节点依然拥有选择的权利，比如通过类似于 BIP148 
的方法。

I admitted that these nodes a very important. so we don’t want these nodes 
suffer financial loss by undetectable network change. These nodes always have 
choice like BIP148.

>> 
>> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
>> 
>> Apart from ensuring the asset security of wallet nodes, this method can be 
>> used to provide additional incentives to upgrade the protocol for the wallet 
>> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can 
>> be guaranteed to work - not only on the longest chain, but also on the 
>> longest chain used by other wallet nodes in the broader bitcoin sphere. 
>> Under the Nakamoto Consensus, there will be no persistent forks as protocol 
>> upgrades can be phased in.
> There is no way to guarantee a wallet node will accept a particular
> block since that is always up to the user.

我们无法对此进行保证。但是我们能够提供一种让这些节点了解并参与部署改变的激励。
We can not have any guarantee. but we can have incentives that they participate 
and be aware about the change happening.
用户总是可以进行选择。
Users always have choice.

>> 
>> ==Specification==
>> 
>> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号
>> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 
>> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。
>> 
>> 1. Mining nodes signal by setting a version bit. While this BIP is active, 
>> all blocks must set the chosen nVersion.
>> 2. Mining nodes will use tx version to define current version transactions. 
>> Current tx version is 1, and tx version 2 will be allowed. After the second 
>> grace period, tx version 1 will be regarded as invalid.
> Sounds like this would cause issues with pre-signed time locked transactions.

我们可以在第四阶段中重新允许这些交易。无论升级是否成功激活，他们都需要为此做好准备。他们并不能被丢下甚至被欺骗为什么都没有发生。
They can be re-enable in the successful or unsuccessful activation of the 
fourth stage. Whether or not, what they need is to be prepared for the future 
coming. But they can’t be left behind or be cheated like nothing happened.

>> 
>> 
>> ==Deployment==
>> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。
>> 
>> Protocol upgrading will phase in over three stages. We can have an optional 
>> fourth stage to integrate codes of protocol upgrade.
>> 
>> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016 
>> 个区块均发送了相同的支持信号，进入下一阶段。
>> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 
>> 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。
>> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 
>> 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。
>> 4. 
>> （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>> 
>> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be 
>> activated after 55% (1109) of 2016 blocks has the signal.
>> 
>> 2. Mining nodes upgrade stage: After a first grace period of 2016 blocks and 
>> total signalling blocks passed 2218 of 4032 blocks, miners broadcasting 
>> blocks with new versionbits in block headers will orphan blocks with old 
>> versionbits. At this stage all nodes can send transactions with new 
>> versionbits, and transactions with old versionbits will be compatible.
>> 
>> 3. Non-mining nodes upgrade 

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 3:13 AM, Zheming Lin  wrote:
> Hi James:
>
> 在 2017年6月13日，15:19，James Hilliard  写道：
>
> On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin  wrote:
>
> Hi James:
>
> Thank you very much for detailed feedback. Sorry for my understanding of
> English being poor. I’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard  写道：
>
>
> 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. 
>
> 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.
>
>
> 假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
> False signal can’t be solved in my opinion. If the majority part just don’t
> agree with the change, why they cheat? If the majority part is honest as
> described in nakamoto consensus, I think that won’t 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.
>
>
> 节点需要自主决定是否跟随协议升级。但是他们不能被动的什么都不做。他们总是存在有多种的选择。
> The node should decide to follow the protocol upgrade or not. But they can’t
> just be passive and do nothing. The choice is always provided.
>
> 如果他们并不相信大多数的矿工，他们可以选择一些没有矿工角色的替代币。
> If they don’t trust the choice of majority miners, they can use some alt
> coin that don’t including miners’ part.

They generally don't have to switch to an altcoin when they get to
choose which blocks they accept ultimately. This is a key component of
Bitcoin's incentive model since it makes it so miners are unlikely to
do a hard fork if their blocks would not be accepted by nodes/users.
For example if 55% of miners wanted to hard fork and change the block
reward back to 50 BTC the minority side would not need to switch to an
altcoin, they would just need to ignore those 50 BTC block reward
blocks.

>
>
>
> 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.
> 
>
> 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.
>
>
> 也许我是错的我并不肯定。请对如何让这个方法兼容 SPY 挖矿提出建设性意见。
> Maybe I’m 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.
>
>
> 我们应当引入区块校验，但如何为不验证进行 SPY 挖矿的矿工提供激励是另外一个问题了。
> 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. 
>
> 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.
>
>
> 这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
> It would not force our nodes to do anything that changes the consensus. But
> they should be prepared for the **maybe** upcoming changes.
> 协议的改变将通过矿工投票产生，但是这个过程应该被所有节点所知晓并承认。
> Protocol 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”.
>
>
> 我并不把这个方法看作是完全的向后兼容。在大家都认可“区块高度xxx后

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin  wrote:
> Hi James:
>
> Thank you very much for detailed feedback. Sorry for my understanding of
> English being poor. I’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard  写道：
>
> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>  wrote:
>
> The BIP is described using Chinese and English. If any part is missing or
> need more specific, please reply. Forgive for my poor English.
>
> This method will incorporate any upgrade that affects non-mining nodes. They
> should beware that the rule has been changed.
>
> TLDR: Major miners activate and orphan the minor. That ensures all miners
> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade
> (with other protocol upgrade codes) in order to work. Then the final miner
> vote over protocol upgrade, with all nodes has the same upgraded codes.
>
> ==Motivation==
>
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
> In view of the fact that the original Bitcoin consensus did not consider the
> non-mining wallet nodes(as mentioned above), the result is that upgrading
> the consensus of these wallet nodes is passive and lazy. When there is
> disagreement in the direction of the upgrade, the miners have no mechanism
> to ensure that the chain being extended is the chain widely accepted by the
> wallet nodes. This also adversely affects the security of the wallet
> nodes.
>
> Wallet nodes being able to fully validate and choose whether or not to
> accept a particular chain is an important part of bitcoins security
> model.
>
>
> 是的我认为这些节点非常重要，因此不愿意看到这些节点因为无法预见到网络上可能发生的改变而蒙受损失。这些节点依然拥有选择的权利，比如通过类似于 BIP148
> 的方法。
>
> I admitted that these nodes a very important. so we don’t want these nodes
> suffer financial loss by undetectable network change. These nodes always
> have choice like BIP148.
>
>
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
>
> Apart from ensuring the asset security of wallet nodes, this method can be
> used to provide additional incentives to upgrade the protocol for the wallet
> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can
> be guaranteed to work - not only on the longest chain, but also on the
> longest chain used by other wallet nodes in the broader bitcoin sphere.
> Under the Nakamoto Consensus, there will be no persistent forks as protocol
> upgrades can be phased in.
>
> There is no way to guarantee a wallet node will accept a particular
> block since that is always up to the user.
>
>
> 我们无法对此进行保证。但是我们能够提供一种让这些节点了解并参与部署改变的激励。
> We can not have any guarantee. but we can have incentives that they
> participate and be aware about the change happening.
> 用户总是可以进行选择。
> Users always have choice.
>
>
> ==Specification==
>
> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。
>
> 1. Mining nodes signal by setting a version bit. While this BIP is active,
> all blocks must set the chosen nVersion.
> 2. Mining nodes will use tx version to define current version transactions.
> Current tx version is 1, and tx version 2 will be allowed. After the second
> grace period, tx version 1 will be regarded as invalid.
>
> Sounds like this would cause issues with pre-signed time locked
> transactions.
>
>
> 我们可以在第四阶段中重新允许这些交易。无论升级是否成功激活，他们都需要为此做好准备。他们并不能被丢下甚至被欺骗为什么都没有发生。
> They can be re-enable in the successful or unsuccessful activation of the
> fourth stage. Whether or not, what they need is to be prepared for the
> future coming. But they can’t be left behind or be cheated like nothing
> happened.
>
>
>
> ==Deployment==
> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。
>
> Protocol upgrading will phase in over three stages. We can have an optional
> fourth stage to integrate codes of protocol upgrade.
>
> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
> 个区块均发送了相同的支持信号，进入下一阶段。
> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了
> 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。
> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032
> 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。
> 4.
> （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>
> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be
> activated after 55% (1109) of 2016 blocks has the signal.
>
> 2. Mining nodes upgrade stage: After a first grace period of 2016 blocks and
> total signalling blocks passed 2218 of 4032 blocks, miners broadcasting
> blocks with new versionbits in block headers will orphan blocks with old
> versionbits. At this stage all nodes can send transactions with new
> versionbits, and transactions with old versionbits will be compatible.
>
> 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new
> versionbits