* [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
@ 2017-06-13 2:23 Zheming Lin
2017-06-13 5:44 ` James Hilliard
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Zheming Lin @ 2017-06-13 2:23 UTC (permalink / raw)
To: bitcoin-dev
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.
<pre>
BIP: ???
Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
Author: LIN Zheming
Status: Draft
Type: Standards Track
Created: 2017-06-12
</pre>
==Summary==
本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
This idea was not created by an individual but is a product of collaboration in the Chinese bitcoin community between different interest groups.<br/>
这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
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.<br/>
发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
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.<br/>
在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
The protocol upgrade depends on its activate condition independently even after the change deployed among nodes.<br/>
==Motivation==
鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
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.<br/>
使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
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.<br/>
==Specification==
1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号<br/>
2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
1. Mining nodes signal by setting a version bit. While this BIP is active, all blocks must set the chosen nVersion.<br/>
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.<br/>
==Deployment==
协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
Protocol upgrading will phase in over three stages. We can have an optional fourth stage to integrate codes of protocol upgrade.<br/>
1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016 个区块均发送了相同的支持信号，进入下一阶段。<br/>
2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
1. Signal stage: Mining nodes signal using BIP9. The next stage will be activated after 55% (1109) of 2016 blocks has the signal.<br/>
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.<br/>
3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new versionbits, mining nodes will start to refuse transactions with old versionbits. Only transactions with new versionbits can be relayed and included in blocks. Transactions with old versionbits can be safely purged from memory pools.<br/>
4. (Optional)Protocol Upgrade stage: The codes dealing with protocol upgrade can be integrated in the third stage. After the non-mining nodes upgrades to support newer version of transactions, the codes with protocol upgrade must be included and now we can use miner vote to activate and finish this upgrade.<br/>
至此，协议升级完成。<br/>
At this point, the protocol upgrade have phased in.<br/>
==Benefits==
1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51% 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
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/>
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/>
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/>
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/>
==Risks==
1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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/>
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/>
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/>
==Implementation==
___TBD___
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 2:23 [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners Zheming Lin
@ 2017-06-13 5:44 ` James Hilliard
2017-06-13 6:50 ` Zheming Lin
2017-06-13 19:35 ` Jared Lee Richardson
2017-06-13 8:24 ` Zheming Lin
2017-06-13 18:11 ` Gregory Maxwell
2 siblings, 2 replies; 24+ messages in thread
From: James Hilliard @ 2017-06-13 5:44 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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.
>
> <pre>
> BIP: ???
> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> Author: LIN Zheming
> Status: Draft
> Type: Standards Track
> Created: 2017-06-12
> </pre>
>
> ==Summary==
>
> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
> This idea was not created by an individual but is a product of collaboration in the Chinese bitcoin community between different interest groups.<br/>
>
> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
> 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.<br/>
>
> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
>
> 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.<br/>
>
> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
> The protocol upgrade depends on its activate condition independently even after the change deployed among nodes.<br/>
>
> ==Motivation==
>
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
> 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.<br/>
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.
>
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
>
> 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.<br/>
There is no way to guarantee a wallet node will accept a particular
block since that is always up to the user.
>
> ==Specification==
>
> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号<br/>
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
>
> 1. Mining nodes signal by setting a version bit. While this BIP is active, all blocks must set the chosen nVersion.<br/>
> 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.<br/>
Sounds like this would cause issues with pre-signed time locked transactions.
>
>
> ==Deployment==
> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
>
> Protocol upgrading will phase in over three stages. We can have an optional fourth stage to integrate codes of protocol upgrade.<br/>
>
> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016 个区块均发送了相同的支持信号，进入下一阶段。<br/>
> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
> 4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>
> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be activated after 55% (1109) of 2016 blocks has the signal.<br/>
>
> 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.<br/>
>
> 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new versionbits, mining nodes will start to refuse transactions with old versionbits. Only transactions with new versionbits can be relayed and included in blocks. Transactions with old versionbits can be safely purged from memory pools.<br/>
>
> 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol upgrade can be integrated in the third stage. After the non-mining nodes upgrades to support newer version of transactions, the codes with protocol upgrade must be included and now we can use miner vote to activate and finish this upgrade.<br/>
>
> 至此，协议升级完成。<br/>
>
> At this point, the protocol upgrade have phased in.<br/>
>
> ==Benefits==
>
> 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51% 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
> 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
> 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
> 4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
> 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
> 6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
>
> 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.
> 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.
> 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.
> 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/>
>
>
> ==Risks==
>
> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
> 4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
> 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.
> 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/>
>
>
> ==Implementation==
> ___TBD___
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 5:44 ` James Hilliard
@ 2017-06-13 6:50 ` Zheming Lin
2017-06-13 7:19 ` James Hilliard
2017-06-13 19:35 ` Jared Lee Richardson
1 sibling, 1 reply; 24+ messages in thread
From: Zheming Lin @ 2017-06-13 6:50 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 13662 bytes --]
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 <james.hilliard1@gmail•com> 写道：
>
> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> 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==
>>
>> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
>> 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.<br/>
> 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.
>>
>> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
>>
>> 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.<br/>
> 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 来发送信号<br/>
>> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
>>
>> 1. Mining nodes signal by setting a version bit. While this BIP is active, all blocks must set the chosen nVersion.<br/>
>> 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.<br/>
> 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==
>> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
>>
>> Protocol upgrading will phase in over three stages. We can have an optional fourth stage to integrate codes of protocol upgrade.<br/>
>>
>> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016 个区块均发送了相同的支持信号，进入下一阶段。<br/>
>> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
>> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
>> 4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>>
>> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be activated after 55% (1109) of 2016 blocks has the signal.<br/>
>>
>> 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.<br/>
>>
>> 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new versionbits, mining nodes will start to refuse transactions with old versionbits. Only transactions with new versionbits can be relayed and included in blocks. Transactions with old versionbits can be safely purged from memory pools.<br/>
>>
>> 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol upgrade can be integrated in the third stage. After the non-mining nodes upgrades to support newer version of transactions, the codes with protocol upgrade must be included and now we can use miner vote to activate and finish this upgrade.<br/>
>>
>> 至此，协议升级完成。<br/>
>>
>> At this point, the protocol upgrade have phased in.<br/>
>>
>> ==Benefits==
>>
>> 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51% 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
>> 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
>> 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
>> 4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
>> 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
>> 6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
>>
>> 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.
假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
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.
>> 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.
也许我是错的我并不肯定。请对如何让这个方法兼容 SPY 挖矿提出建设性意见。
Maybe I’m wrong. Please give some advice that how to make it compatible with SPY mining.
>> 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.
这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
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.
>> 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/>
>>
>>
>> ==Risks==
>>
>> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
>> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
>> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
>> 4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
如果大多数矿工是诚实的，假信号不会有问题。
False signal won’t be a problem if majority miners are honest.
>> 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.
矿工需要在可以确保大多数用户不被升级影响的情况下才能公正投票。
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/>
>>
>>
>> ==Implementation==
>> ___TBD___
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
[-- Attachment #2: Type: text/html, Size: 39992 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 6:50 ` Zheming Lin
@ 2017-06-13 7:19 ` James Hilliard
2017-06-13 8:13 ` Zheming Lin
0 siblings, 1 reply; 24+ messages in thread
From: James Hilliard @ 2017-06-13 7:19 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
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’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard <james.hilliard1@gmail•com> 写道：
>
> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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==
>
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
> 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.<br/>
>
> 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.
>
>
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
>
> 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.<br/>
>
> 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 来发送信号<br/>
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
>
> 1. Mining nodes signal by setting a version bit. While this BIP is active,
> all blocks must set the chosen nVersion.<br/>
> 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.<br/>
>
> 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==
> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
>
> Protocol upgrading will phase in over three stages. We can have an optional
> fourth stage to integrate codes of protocol upgrade.<br/>
>
> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
> 个区块均发送了相同的支持信号，进入下一阶段。<br/>
> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了
> 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032
> 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
> 4.
> （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>
> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be
> activated after 55% (1109) of 2016 blocks has the signal.<br/>
>
> 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.<br/>
>
> 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new
> versionbits, mining nodes will start to refuse transactions with old
> versionbits. Only transactions with new versionbits can be relayed and
> included in blocks. Transactions with old versionbits can be safely purged
> from memory pools.<br/>
>
> 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol upgrade
> can be integrated in the third stage. After the non-mining nodes upgrades to
> support newer version of transactions, the codes with protocol upgrade must
> be included and now we can use miner vote to activate and finish this
> upgrade.<br/>
>
> 至此，协议升级完成。<br/>
>
> At this point, the protocol upgrade have phased in.<br/>
>
> ==Benefits==
>
> 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340
> 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51%
> 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
> 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
> 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
> 4.
> 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
> 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
> 6.
> 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
>
> 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.
>
>
> 假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
> 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.
>
>
> 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.
>
>
> 也许我是错的我并不肯定。请对如何让这个方法兼容 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.
>
> 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.
>
>
> 这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
> 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".
>
>
> 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/>
>
>
> ==Risks==
>
> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
> 4.
> 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
>
>
> 如果大多数矿工是诚实的，假信号不会有问题。
> False signal won’t 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.
>
> 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.
>
>
> 矿工需要在可以确保大多数用户不被升级影响的情况下才能公正投票。
> 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/>
>
>
> ==Implementation==
> ___TBD___
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 7:19 ` James Hilliard
@ 2017-06-13 8:13 ` Zheming Lin
2017-06-13 8:37 ` James Hilliard
0 siblings, 1 reply; 24+ messages in thread
From: Zheming Lin @ 2017-06-13 8:13 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 8970 bytes --]
Hi James:
> 在 2017年6月13日，15:19，James Hilliard <james.hilliard1@gmail•com> 写道：
>
> On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin <heater@gmail•com <mailto:heater@gmail•com>> 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 <james.hilliard1@gmail•com> 写道：
>>
>>
>> 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.
>>
>>
>> 假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
>> 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. <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.
>>
>>
>> 也许我是错的我并不肯定。请对如何让这个方法兼容 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. <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.
>>
>>
>> 这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
>> 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 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/>
>>
>>
>> ==Risks==
>>
>> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
>> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
>> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
>> 4.
>> 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
>>
>>
>> 如果大多数矿工是诚实的，假信号不会有问题。
>> False signal won’t 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.
>
当然，45% 可以发送假信号，可以和部分节点共谋。但这是当前已经存在的问题，并没有因此更糟糕。
Of cause, there could be false signal from 45% and have conspiracy with some nodes. But that’s the problem we have today, and it don’t 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.
>>
>>
>> 矿工需要在可以确保大多数用户不被升级影响的情况下才能公正投票。
>> 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/>
>>
>>
>> ==Implementation==
>> ___TBD___
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 25641 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 2:23 [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners Zheming Lin
2017-06-13 5:44 ` James Hilliard
@ 2017-06-13 8:24 ` Zheming Lin
2017-06-13 10:20 ` James Hilliard
2017-06-13 18:11 ` Gregory Maxwell
2 siblings, 1 reply; 24+ messages in thread
From: Zheming Lin @ 2017-06-13 8:24 UTC (permalink / raw)
To: 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 <heater@gmail•com> 写道：
>
> 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.
>
> <pre>
> BIP: ???
> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> Author: LIN Zheming
> Status: Draft
> Type: Standards Track
> Created: 2017-06-12
> </pre>
>
> ==Summary==
>
> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
> This idea was not created by an individual but is a product of collaboration in the Chinese bitcoin community between different interest groups.<br/>
>
> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
> 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.<br/>
>
> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
>
> 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.<br/>
>
> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
> The protocol upgrade depends on its activate condition independently even after the change deployed among nodes.<br/>
>
> ==Motivation==
>
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
> 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.<br/>
>
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
>
> 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.<br/>
>
> ==Specification==
>
> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号<br/>
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
>
> 1. Mining nodes signal by setting a version bit. While this BIP is active, all blocks must set the chosen nVersion.<br/>
> 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.<br/>
>
>
> ==Deployment==
> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
>
> Protocol upgrading will phase in over three stages. We can have an optional fourth stage to integrate codes of protocol upgrade.<br/>
>
> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016 个区块均发送了相同的支持信号，进入下一阶段。<br/>
> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
> 4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>
> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be activated after 55% (1109) of 2016 blocks has the signal.<br/>
>
> 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.<br/>
>
> 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new versionbits, mining nodes will start to refuse transactions with old versionbits. Only transactions with new versionbits can be relayed and included in blocks. Transactions with old versionbits can be safely purged from memory pools.<br/>
>
> 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol upgrade can be integrated in the third stage. After the non-mining nodes upgrades to support newer version of transactions, the codes with protocol upgrade must be included and now we can use miner vote to activate and finish this upgrade.<br/>
>
> 至此，协议升级完成。<br/>
>
> At this point, the protocol upgrade have phased in.<br/>
>
> ==Benefits==
>
> 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51% 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
> 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
> 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
> 4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
> 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
> 6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
>
> 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/>
> 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/>
> 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/>
> 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/>
>
>
> ==Risks==
>
> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
> 4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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/>
> 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/>
> 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/>
>
>
> ==Implementation==
> ___TBD___
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 8:13 ` Zheming Lin
@ 2017-06-13 8:37 ` James Hilliard
0 siblings, 0 replies; 24+ messages in thread
From: James Hilliard @ 2017-06-13 8:37 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
On Tue, Jun 13, 2017 at 3:13 AM, Zheming Lin <heater@gmail•com> wrote:
> Hi James:
>
> 在 2017年6月13日，15:19，James Hilliard <james.hilliard1@gmail•com> 写道：
>
> 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’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard <james.hilliard1@gmail•com> 写道：
>
>
> 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.
>
>
> 假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
> 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. <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.
>
>
> 也许我是错的我并不肯定。请对如何让这个方法兼容 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. <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.
>
>
> 这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
> 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.
By backwards compatible I mean being able to continue functioning
without updating the node, soft forks are generally backwards
compatible because you can still transact even if you don't upgrade
your node to support the soft fork, you just won't be able to use the
new soft fork features.
>
>
>
>
> 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/>
>
>
> ==Risks==
>
> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
> 4.
> 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
>
>
> 如果大多数矿工是诚实的，假信号不会有问题。
> False signal won’t 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.
>
>
> 当然，45% 可以发送假信号，可以和部分节点共谋。但这是当前已经存在的问题，并没有因此更糟糕。
> Of cause, there could be false signal from 45% and have conspiracy with some
> nodes. But that’s the problem we have today, and it don’t 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.
>
>
> 矿工需要在可以确保大多数用户不被升级影响的情况下才能公正投票。
> 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/>
>
>
> ==Implementation==
> ___TBD___
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 8:24 ` Zheming Lin
@ 2017-06-13 10:20 ` James Hilliard
0 siblings, 0 replies; 24+ messages in thread
From: James Hilliard @ 2017-06-13 10:20 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
On Tue, Jun 13, 2017 at 3:24 AM, Zheming Lin via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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 <heater@gmail•com> 写道：
>>
>> 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.
>>
>> <pre>
>> BIP: ???
>> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
>> Author: LIN Zheming
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-06-12
>> </pre>
>>
>> ==Summary==
>>
>> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
>> This idea was not created by an individual but is a product of collaboration in the Chinese bitcoin community between different interest groups.<br/>
>>
>> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
>> 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.<br/>
>>
>> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
>>
>> 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.<br/>
>>
>> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
>> The protocol upgrade depends on its activate condition independently even after the change deployed among nodes.<br/>
>>
>> ==Motivation==
>>
>> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
>> 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.<br/>
>>
>> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
>>
>> 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.<br/>
>>
>> ==Specification==
>>
>> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号<br/>
>> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
>>
>> 1. Mining nodes signal by setting a version bit. While this BIP is active, all blocks must set the chosen nVersion.<br/>
>> 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.<br/>
>>
>>
>> ==Deployment==
>> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
>>
>> Protocol upgrading will phase in over three stages. We can have an optional fourth stage to integrate codes of protocol upgrade.<br/>
>>
>> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016 个区块均发送了相同的支持信号，进入下一阶段。<br/>
>> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
>> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
>> 4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>>
>> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be activated after 55% (1109) of 2016 blocks has the signal.<br/>
>>
>> 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.<br/>
>>
>> 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new versionbits, mining nodes will start to refuse transactions with old versionbits. Only transactions with new versionbits can be relayed and included in blocks. Transactions with old versionbits can be safely purged from memory pools.<br/>
>>
>> 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol upgrade can be integrated in the third stage. After the non-mining nodes upgrades to support newer version of transactions, the codes with protocol upgrade must be included and now we can use miner vote to activate and finish this upgrade.<br/>
>>
>> 至此，协议升级完成。<br/>
>>
>> At this point, the protocol upgrade have phased in.<br/>
>>
>> ==Benefits==
>>
>> 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51% 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
>> 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
>> 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
>> 4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
>> 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
>> 6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
>>
>> 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/>
>> 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/>
>> 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/>
>> 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/>
>>
>>
>> ==Risks==
>>
>> 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
>> 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
>> 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
>> 4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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/>
>> 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/>
>> 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/>
>>
>>
>> ==Implementation==
>> ___TBD___
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 2:23 [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners Zheming Lin
2017-06-13 5:44 ` James Hilliard
2017-06-13 8:24 ` Zheming Lin
@ 2017-06-13 18:11 ` Gregory Maxwell
2017-06-14 16:39 ` Zheming Lin
2 siblings, 1 reply; 24+ messages in thread
From: Gregory Maxwell @ 2017-06-13 18:11 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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:
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
> 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,
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 5:44 ` James Hilliard
2017-06-13 6:50 ` Zheming Lin
@ 2017-06-13 19:35 ` Jared Lee Richardson
2017-06-14 0:23 ` James Hilliard
1 sibling, 1 reply; 24+ messages in thread
From: Jared Lee Richardson @ 2017-06-13 19:35 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 17509 bytes --]
> 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
> <bitcoin-dev@lists•linuxfoundation.org> 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.
> >
> > <pre>
> > BIP: ???
> > Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> > Author: LIN Zheming
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-06-12
> > </pre>
> >
> > ==Summary==
> >
> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
> > This idea was not created by an individual but is a product of
> collaboration in the Chinese bitcoin community between different interest
> groups.<br/>
> >
> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
> > 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.<br/>
> >
> > 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。
> 通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，
> 未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。
> 并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
> >
> > 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.<br/>
> >
> > 在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
> > The protocol upgrade depends on its activate condition independently
> even after the change deployed among nodes.<br/>
> >
> > ==Motivation==
> >
> > 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。<br/>
> > 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.<br/>
> 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.
> >
> > 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，
> 还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
> >
> > 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.<br/>
> There is no way to guarantee a wallet node will accept a particular
> block since that is always up to the user.
> >
> > ==Specification==
> >
> > 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号<br/>
> > 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
> >
> > 1. Mining nodes signal by setting a version bit. While this BIP is
> active, all blocks must set the chosen nVersion.<br/>
> > 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.<br/>
> Sounds like this would cause issues with pre-signed time locked
> transactions.
> >
> >
> > ==Deployment==
> > 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
> >
> > Protocol upgrading will phase in over three stages. We can have an
> optional fourth stage to integrate codes of protocol upgrade.<br/>
> >
> > 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
> 个区块均发送了相同的支持信号，进入下一阶段。<br/>
> > 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，
> 并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
> > 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／
> 转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
> > 4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。
> 则此时可以通过矿工节点投票的方式完成全网络的协议升级。
> >
> > 1. Signal stage: Mining nodes signal using BIP9. The next stage will be
> activated after 55% (1109) of 2016 blocks has the signal.<br/>
> >
> > 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.<br/>
> >
> > 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new
> versionbits, mining nodes will start to refuse transactions with old
> versionbits. Only transactions with new versionbits can be relayed and
> included in blocks. Transactions with old versionbits can be safely purged
> from memory pools.<br/>
> >
> > 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol
> upgrade can be integrated in the third stage. After the non-mining nodes
> upgrades to support newer version of transactions, the codes with protocol
> upgrade must be included and now we can use miner vote to activate and
> finish this upgrade.<br/>
> >
> > 至此，协议升级完成。<br/>
> >
> > At this point, the protocol upgrade have phased in.<br/>
> >
> > ==Benefits==
> >
> > 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。
> 这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51%
> 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
> > 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
> > 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
> > 4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。
> 相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
> > 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
> > 6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。
> 即使矿工投票激活失败也不影响现状。<br/>
> >
> > 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.
> > 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.
> > 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.
> > 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/>
> >
> >
> > ==Risks==
> >
> > 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
> > 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
> > 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，
> 严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
> > 4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，
> 但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
> > 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.
> > 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/>
> >
> >
> > ==Implementation==
> > ___TBD___
> >
> > _______________________________________________
> > 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
>
[-- Attachment #2: Type: text/html, Size: 20609 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 19:35 ` Jared Lee Richardson
@ 2017-06-14 0:23 ` James Hilliard
2017-06-14 1:08 ` Jared Lee Richardson
0 siblings, 1 reply; 24+ messages in thread
From: James Hilliard @ 2017-06-14 0:23 UTC (permalink / raw)
To: Jared Lee Richardson; +Cc: Bitcoin Dev
On Tue, Jun 13, 2017 at 2:35 PM, Jared Lee Richardson
<jaredr26@gmail•com> 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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> 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.
>> >
>> > <pre>
>> > BIP: ???
>> > Title: Demonstration of Phase in Full Network Upgrade Activated by
>> > Miners
>> > Author: LIN Zheming
>> > Status: Draft
>> > Type: Standards Track
>> > Created: 2017-06-12
>> > </pre>
>> >
>> > ==Summary==
>> >
>> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
>> > This idea was not created by an individual but is a product of
>> > collaboration in the Chinese bitcoin community between different interest
>> > groups.<br/>
>> >
>> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
>> > 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.<br/>
>> >
>> >
>> > 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
>> >
>> > 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.<br/>
>> >
>> > 在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
>> > The protocol upgrade depends on its activate condition independently
>> > even after the change deployed among nodes.<br/>
>> >
>> > ==Motivation==
>> >
>> >
>> > 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
>> > 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.<br/>
>> 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.
>> >
>> >
>> > 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
>> >
>> > 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.<br/>
>> There is no way to guarantee a wallet node will accept a particular
>> block since that is always up to the user.
>> >
>> > ==Specification==
>> >
>> > 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion
>> > 来发送信号<br/>
>> > 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
>> > 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
>> >
>> > 1. Mining nodes signal by setting a version bit. While this BIP is
>> > active, all blocks must set the chosen nVersion.<br/>
>> > 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.<br/>
>> Sounds like this would cause issues with pre-signed time locked
>> transactions.
>> >
>> >
>> > ==Deployment==
>> > 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
>> >
>> > Protocol upgrading will phase in over three stages. We can have an
>> > optional fourth stage to integrate codes of protocol upgrade.<br/>
>> >
>> > 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
>> > 个区块均发送了相同的支持信号，进入下一阶段。<br/>
>> > 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了
>> > 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
>> > 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032
>> > 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
>> > 4.
>> > （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>> >
>> > 1. Signal stage: Mining nodes signal using BIP9. The next stage will be
>> > activated after 55% (1109) of 2016 blocks has the signal.<br/>
>> >
>> > 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.<br/>
>> >
>> > 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new
>> > versionbits, mining nodes will start to refuse transactions with old
>> > versionbits. Only transactions with new versionbits can be relayed and
>> > included in blocks. Transactions with old versionbits can be safely purged
>> > from memory pools.<br/>
>> >
>> > 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol
>> > upgrade can be integrated in the third stage. After the non-mining nodes
>> > upgrades to support newer version of transactions, the codes with protocol
>> > upgrade must be included and now we can use miner vote to activate and
>> > finish this upgrade.<br/>
>> >
>> > 至此，协议升级完成。<br/>
>> >
>> > At this point, the protocol upgrade have phased in.<br/>
>> >
>> > ==Benefits==
>> >
>> > 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340
>> > 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51%
>> > 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
>> > 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
>> > 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
>> > 4.
>> > 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
>> > 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
>> > 6.
>> > 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。即使矿工投票激活失败也不影响现状。<br/>
>> >
>> > 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.
>> > 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.
>> > 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.
>> > 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/>
>> >
>> >
>> > ==Risks==
>> >
>> > 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
>> > 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
>> > 3.
>> > 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
>> > 4.
>> > 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
>> > 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.
>> > 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/>
>> >
>> >
>> > ==Implementation==
>> > ___TBD___
>> >
>> > _______________________________________________
>> > 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
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 0:23 ` James Hilliard
@ 2017-06-14 1:08 ` Jared Lee Richardson
0 siblings, 0 replies; 24+ messages in thread
From: Jared Lee Richardson @ 2017-06-14 1:08 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 21272 bytes --]
> 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 <james.hilliard1@gmail•com>
wrote:
> On Tue, Jun 13, 2017 at 2:35 PM, Jared Lee Richardson
> <jaredr26@gmail•com> 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
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>
> >> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
> >> <bitcoin-dev@lists•linuxfoundation.org> 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.
> >> >
> >> > <pre>
> >> > BIP: ???
> >> > Title: Demonstration of Phase in Full Network Upgrade Activated by
> >> > Miners
> >> > Author: LIN Zheming
> >> > Status: Draft
> >> > Type: Standards Track
> >> > Created: 2017-06-12
> >> > </pre>
> >> >
> >> > ==Summary==
> >> >
> >> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。<br/>
> >> > This idea was not created by an individual but is a product of
> >> > collaboration in the Chinese bitcoin community between different
> interest
> >> > groups.<br/>
> >> >
> >> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。<br/>
> >> > 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.<br/>
> >> >
> >> >
> >> > 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。
> 通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，
> 未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。
> 并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。<br/>
> >> >
> >> > 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.<br/>
> >> >
> >> > 在该项改动广泛部署至客户端之后，依然由其激活条件控制。<br/>
> >> > The protocol upgrade depends on its activate condition independently
> >> > even after the change deployed among nodes.<br/>
> >> >
> >> > ==Motivation==
> >> >
> >> >
> >> > 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。<br/>
> >> > 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.<br/>
> >> 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.
> >> >
> >> >
> >> > 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，
> 还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。<br/>
> >> >
> >> > 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.<br/>
> >> There is no way to guarantee a wallet node will accept a particular
> >> block since that is always up to the user.
> >> >
> >> > ==Specification==
> >> >
> >> > 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion
> >> > 来发送信号<br/>
> >> > 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
> >> > 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。<br/>
> >> >
> >> > 1. Mining nodes signal by setting a version bit. While this BIP is
> >> > active, all blocks must set the chosen nVersion.<br/>
> >> > 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.<br/>
> >> Sounds like this would cause issues with pre-signed time locked
> >> transactions.
> >> >
> >> >
> >> > ==Deployment==
> >> > 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。<br/>
> >> >
> >> > Protocol upgrading will phase in over three stages. We can have an
> >> > optional fourth stage to integrate codes of protocol upgrade.<br/>
> >> >
> >> > 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
> >> > 个区块均发送了相同的支持信号，进入下一阶段。<br/>
> >> > 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了
> >> > 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，
> 将可以使用新版本号发送交易，同时兼容旧版本号交易。<br/>
> >> > 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032
> >> > 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。<br/>
> >> > 4.
> >> > （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。
> 则此时可以通过矿工节点投票的方式完成全网络的协议升级。
> >> >
> >> > 1. Signal stage: Mining nodes signal using BIP9. The next stage will
> be
> >> > activated after 55% (1109) of 2016 blocks has the signal.<br/>
> >> >
> >> > 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.<br/>
> >> >
> >> > 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with
> new
> >> > versionbits, mining nodes will start to refuse transactions with old
> >> > versionbits. Only transactions with new versionbits can be relayed and
> >> > included in blocks. Transactions with old versionbits can be safely
> purged
> >> > from memory pools.<br/>
> >> >
> >> > 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol
> >> > upgrade can be integrated in the third stage. After the non-mining
> nodes
> >> > upgrades to support newer version of transactions, the codes with
> protocol
> >> > upgrade must be included and now we can use miner vote to activate and
> >> > finish this upgrade.<br/>
> >> >
> >> > 至此，协议升级完成。<br/>
> >> >
> >> > At this point, the protocol upgrade have phased in.<br/>
> >> >
> >> > ==Benefits==
> >> >
> >> > 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340
> >> > 个区块后确保成为最长链。这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51%
> >> > 后，挖矿节点将迅速的在第一个宽限期内进行升级。<br/>
> >> > 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。<br/>
> >> > 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？）<br/>
> >> > 4.
> >> > 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。
> 相对于在节点间重新达成新的共识，这种状况并没有更糟糕。<br/>
> >> > 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。<br/>
> >> > 6.
> >> > 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。
> 即使矿工投票激活失败也不影响现状。<br/>
> >> >
> >> > 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.
> >> > 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.
> >> > 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.
> >> > 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/>
> >> >
> >> >
> >> > ==Risks==
> >> >
> >> > 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。<br/>
> >> > 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。<br/>
> >> > 3.
> >> > 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，
> 严肃的真实节点应当跟随可证实的矿工投票结果。<br/>
> >> > 4.
> >> > 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，
> 但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。<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.
> >> > 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.
> >> > 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/>
> >> >
> >> >
> >> > ==Implementation==
> >> > ___TBD___
> >> >
> >> > _______________________________________________
> >> > 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
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 26032 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-13 18:11 ` Gregory Maxwell
@ 2017-06-14 16:39 ` Zheming Lin
2017-06-14 17:20 ` Jameson Lopp
0 siblings, 1 reply; 24+ messages in thread
From: Zheming Lin @ 2017-06-14 16:39 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
> 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
>
> On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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:
>
>> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。<br/>
>> 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.
>
我针对的是懒惰和被动的节点，而非活跃做出选择的节点。用户愿意的话总是可以做出自己的选择。并没有办法来强迫并不认同的人形成共识。
I mean lazy and passive ones I addressed. Not the one actively chose whichever solution they like. Users always have their solution. There’s no way to force a union if they are not together.
> 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.
>
在中本聪白皮书中第五章的定义下，每个节点都需要挖矿。如果咱俩对此存在分歧，我并无法说服你。
From the definition of Satishi Nakamoto, Section 5, each node mines. If that’s the disagreement between us, there’s no more I can convince you.
> 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.
>
是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
到底我们的用户是否真的拥有选择？
Did the users have any real choice?
我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
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?
> 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.)
>
我个人将这种行为视作对当前版本的反对票。这个BIP也考虑了这种情况，您是否注意到矿工应该先升级（避免被孤立），这是否解决了你提出的问题呢？
I personally take that as VETO to current version. This BIP also address this situation. Did you notice that miners should be upgraded first? Did that solve the problem you mentioned above?
如果我们可以通过这个方法让所有矿工至少都要升级到相同的共识版本并开始对将来的升级投票，那应该不会有任何问题。除非矿工希望进行的投票，不是某些人希望看到的投票。
If we can use this method to at least make miners upgraded to the same consensus version and start to vote for the upcoming changes, that would solve the problem for the passive behavior. Unless the vote miners wish to hold, is not in the wishlist of someone.
> 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,
I think the divergency is from the different definition of bitcoin. If no common understanding, let’s get one from the white paper, together.
Regards
LIN Zheming
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 16:39 ` Zheming Lin
@ 2017-06-14 17:20 ` Jameson Lopp
2017-06-14 18:29 ` Zheming Lin
2017-06-14 18:30 ` Zheming Lin
0 siblings, 2 replies; 24+ messages in thread
From: Jameson Lopp @ 2017-06-14 17:20 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 9901 bytes --]
On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> 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:
> >
> >> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。<br/>
> >> 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.
> >
>
> 我针对的是懒惰和被动的节点，而非活跃做出选择的节点。用户愿意的话总是可以做出自己的选择。并没有办法来强迫并不认同的人形成共识。
> I mean lazy and passive ones I addressed. Not the one actively chose
> whichever solution they like. Users always have their solution. There’s no
> way to force a union if they are not together.
>
> > 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.
> >
>
> 在中本聪白皮书中第五章的定义下，每个节点都需要挖矿。如果咱俩对此存在分歧，我并无法说服你。
> From the definition of Satishi Nakamoto, Section 5, each node mines. If
> that’s the disagreement between us, there’s no more I can convince you.
>
> > 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.
> >
>
> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，
> 他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
> Yes, users always have choice that they can abandon the nodes. This BIP
> does’t go against them. I mean only the one(especially wallets) that’s
> passive, they need to know there’s a choice and pick one.
>
> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x,
> 2m, ec, 8m… but the upgrade is not the key point.
>
> 到底我们的用户是否真的拥有选择？
> Did the users have any real choice?
>
> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
> I don’t see the reason they trust the majority miners(as they do today)
> but refuse the vote for upcoming protocol upgrade.
>
To be clear, Bitcoin is not a democracy - if you find yourself using the
term "voting" then you may be misunderstanding how consensus forms. Once a
feature has been vetted and the code is deployed, miners may signal that
they are ready to enforce new rules. If for some reason miners are too
"passive or lazy" or wish to "veto" the activation of the new rules, users
may choose to circumvent said veto by refusing to accept blocks that do not
show readiness for enforcing the new rules.
>
> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
> This choice for wallet users right now, is wether to follow the 51%
> majority miners. If they don’t, they can have their fork that get rid of
> miners.
>
> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
> If they do trust the majority miners, they stay and follow the vote for
> upcoming protocol upgrade.
>
> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
> So the questions is: Do the bitcoin developers, users, holders, service
> provides, even miners, (still) have faith in the majority of miners as
> designed in the white paper?
>
>
There is a fundamental misconception regarding this point - the white paper
refers to majority hashpower needing to be honest with regard to
determining the correct chain within the context of many possible /valid/
chain forks. It is not referring to using hashpower to determine the
correct chain amongst an infinitely variable number of currently invalid
chain forks. Bitcoin ecosystem participants should not have faith in miners
(or any other entity) when it comes to choosing the consensus rules they
wish to enforce.
> > 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.)
> >
>
> 我个人将这种行为视作对当前版本的反对票。这个BIP也考虑了这种情况，您是否注意到矿工应该先升级（避免被孤立），这是否解决了你提出的问题呢？
> I personally take that as VETO to current version. This BIP also address
> this situation. Did you notice that miners should be upgraded first? Did
> that solve the problem you mentioned above?
>
> 如果我们可以通过这个方法让所有矿工至少都要升级到相同的共识版本并开始对将来的升级投票，那应该不会有任何问题。
> 除非矿工希望进行的投票，不是某些人希望看到的投票。
> If we can use this method to at least make miners upgraded to the same
> consensus version and start to vote for the upcoming changes, that would
> solve the problem for the passive behavior. Unless the vote miners wish to
> hold, is not in the wishlist of someone.
>
> > 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,
>
> I think the divergency is from the different definition of bitcoin. If no
> common understanding, let’s get one from the white paper, together.
>
> Regards
>
> LIN Zheming
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 11757 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 17:20 ` Jameson Lopp
@ 2017-06-14 18:29 ` Zheming Lin
2017-06-14 18:55 ` Jameson Lopp
2017-06-14 18:30 ` Zheming Lin
1 sibling, 1 reply; 24+ messages in thread
From: Zheming Lin @ 2017-06-14 18:29 UTC (permalink / raw)
To: Jameson Lopp; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]
Hi Jameson:
> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com <mailto:jameson.lopp@gmail•com>> 写道：
>
>
>
> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
>
> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org <mailto:greg@xiph•org>> 写道：
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> > The enforcement of the system's rules by users broadly, and not just
> > miners, is specifically described in the white paper (section 8,
> > paragraph 2, it especially clear in the last sentence). This is
> > critical for the security of Bitcoin especially with the current
> > degree of centralization in pools. Without it, Bitcoin's security
> > would look a lot more like the Ripple system.
> >
>
> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
> Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
>
> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>
> 到底我们的用户是否真的拥有选择？
> Did the users have any real choice?
>
> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
> I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
>
> To be clear, Bitcoin is not a democracy - if you find yourself using the term "voting" then you may be misunderstanding how consensus forms. Once a feature has been vetted and the code is deployed, miners may signal that they are ready to enforce new rules. If for some reason miners are too "passive or lazy" or wish to "veto" the activation of the new rules, users may choose to circumvent said veto by refusing to accept blocks that do not show readiness for enforcing the new rules.
How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork?
I agree with you that the “vote” 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?
>
>
> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
> This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
>
> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
> If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
>
> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
> So the questions is: Do the bitcoin developers, users, holders, service provides, even miners, (still) have faith in the majority of miners as designed in the white paper?
>
>
> There is a fundamental misconception regarding this point - the white paper refers to majority hashpower needing to be honest with regard to determining the correct chain within the context of many possible /valid/ chain forks. It is not referring to using hashpower to determine the correct chain amongst an infinitely variable number of currently invalid chain forks. Bitcoin ecosystem participants should not have faith in miners (or any other entity) when it comes to choosing the consensus rules they wish to enforce.
>
Arrrgh. I think in the BIP, the miners just invalids tx version 1 temporarily. That’s a “soft fork” right? If they dislike the idea, they can leave as always.
Regards
LIN Zheming
[-- Attachment #2: Type: text/html, Size: 8004 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 17:20 ` Jameson Lopp
2017-06-14 18:29 ` Zheming Lin
@ 2017-06-14 18:30 ` Zheming Lin
1 sibling, 0 replies; 24+ messages in thread
From: Zheming Lin @ 2017-06-14 18:30 UTC (permalink / raw)
To: Jameson Lopp; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]
Hi Jameson:
> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com <mailto:jameson.lopp@gmail•com>> 写道：
>
>
>
> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
>
> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org <mailto:greg@xiph•org>> 写道：
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> > The enforcement of the system's rules by users broadly, and not just
> > miners, is specifically described in the white paper (section 8,
> > paragraph 2, it especially clear in the last sentence). This is
> > critical for the security of Bitcoin especially with the current
> > degree of centralization in pools. Without it, Bitcoin's security
> > would look a lot more like the Ripple system.
> >
>
> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
> Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
>
> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>
> 到底我们的用户是否真的拥有选择？
> Did the users have any real choice?
>
> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
> I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
>
> To be clear, Bitcoin is not a democracy - if you find yourself using the term "voting" then you may be misunderstanding how consensus forms. Once a feature has been vetted and the code is deployed, miners may signal that they are ready to enforce new rules. If for some reason miners are too "passive or lazy" or wish to "veto" the activation of the new rules, users may choose to circumvent said veto by refusing to accept blocks that do not show readiness for enforcing the new rules.
How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork?
I agree with you that the “vote” 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?
>
>
> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
> This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
>
> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
> If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
>
> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
> So the questions is: Do the bitcoin developers, users, holders, service provides, even miners, (still) have faith in the majority of miners as designed in the white paper?
>
>
> There is a fundamental misconception regarding this point - the white paper refers to majority hashpower needing to be honest with regard to determining the correct chain within the context of many possible /valid/ chain forks. It is not referring to using hashpower to determine the correct chain amongst an infinitely variable number of currently invalid chain forks. Bitcoin ecosystem participants should not have faith in miners (or any other entity) when it comes to choosing the consensus rules they wish to enforce.
>
Arrrgh. I think in the BIP, the miners just invalids tx version 1 temporarily. That’s a “soft fork” right? If they dislike the idea, they can leave as always.
Regards
LIN Zheming
[-- Attachment #2: Type: text/html, Size: 8188 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 18:29 ` Zheming Lin
@ 2017-06-14 18:55 ` Jameson Lopp
2017-06-14 19:04 ` Zheming Lin
2017-06-15 5:04 ` Eric Voskuil
0 siblings, 2 replies; 24+ messages in thread
From: Jameson Lopp @ 2017-06-14 18:55 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5636 bytes --]
On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin <heater@gmail•com> wrote:
> Hi Jameson:
>
> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>
>
>
> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@
> lists.linuxfoundation.org> wrote:
>
>>
>>
>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
>> >
>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> > The enforcement of the system's rules by users broadly, and not just
>> > miners, is specifically described in the white paper (section 8,
>> > paragraph 2, it especially clear in the last sentence). This is
>> > critical for the security of Bitcoin especially with the current
>> > degree of centralization in pools. Without it, Bitcoin's security
>> > would look a lot more like the Ripple system.
>> >
>>
>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知
>> 道必须做出一个选择。（而不是被动的跟随默认的策略）
>> Yes, users always have choice that they can abandon the nodes. This BIP
>> does’t go against them. I mean only the one(especially wallets) that’s
>> passive, they need to know there’s a choice and pick one.
>>
>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>> This BIP can be applied to almost any upgrade, including Segwit,
>> Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>
>> 到底我们的用户是否真的拥有选择？
>> Did the users have any real choice?
>>
>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>> I don’t see the reason they trust the majority miners(as they do today)
>> but refuse the vote for upcoming protocol upgrade.
>>
>
> To be clear, Bitcoin is not a democracy - if you find yourself using the
> term "voting" then you may be misunderstanding how consensus forms. Once a
> feature has been vetted and the code is deployed, miners may signal that
> they are ready to enforce new rules. If for some reason miners are too
> "passive or lazy" or wish to "veto" the activation of the new rules, users
> may choose to circumvent said veto by refusing to accept blocks that do not
> show readiness for enforcing the new rules.
>
>
> How does the users show their opinion? They can fork away and leave. But
> what remains will be united. Are you afraid of the united users or the fork?
>
> I agree with you that the “vote” is not accurate. Could you kindly suggest
> an other word for that?
>
> I think users should have choice to follow the miners or not. Do you agree
> with this or not?
>
> Regarding consensus changes, users can voice their opinion on any number
of communication platforms. Though if you're looking for a way for users to
signal their intentions at the protocol level, every proposal for doing
that to date has been arguably flawed. Measuring meatspace consensus is
pretty tricky if not completely impossible, especially given the fact that
the vast majority of Bitcoin users do not voice any opinions on the matter
of consensus rules.
Most attempts at measuring user consensus would probably be best described
as signaling rather than voting given that the act of doing so has no
actual power to affect consensus. Every user who runs a fully validating
node is free to enforce the rules with which the agree regardless of what
rules other entities are enforcing.
>
>
>>
>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>> This choice for wallet users right now, is wether to follow the 51%
>> majority miners. If they don’t, they can have their fork that get rid of
>> miners.
>>
>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>> If they do trust the majority miners, they stay and follow the vote for
>> upcoming protocol upgrade.
>>
>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>> So the questions is: Do the bitcoin developers, users, holders, service
>> provides, even miners, (still) have faith in the majority of miners as
>> designed in the white paper?
>>
>>
> There is a fundamental misconception regarding this point - the white
> paper refers to majority hashpower needing to be honest with regard to
> determining the correct chain within the context of many possible /valid/
> chain forks. It is not referring to using hashpower to determine the
> correct chain amongst an infinitely variable number of currently invalid
> chain forks. Bitcoin ecosystem participants should not have faith in miners
> (or any other entity) when it comes to choosing the consensus rules they
> wish to enforce.
>
>
> Arrrgh. I think in the BIP, the miners just invalids tx version 1
> temporarily. That’s a “soft fork” 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 9343 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 18:55 ` Jameson Lopp
@ 2017-06-14 19:04 ` Zheming Lin
2017-06-14 20:11 ` Jameson Lopp
2017-06-15 5:04 ` Eric Voskuil
1 sibling, 1 reply; 24+ messages in thread
From: Zheming Lin @ 2017-06-14 19:04 UTC (permalink / raw)
To: Jameson Lopp; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5910 bytes --]
Hi Jameson:
> 在 2017年6月15日，02:55，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>
>
>
> On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin <heater@gmail•com <mailto:heater@gmail•com>> wrote:
> Hi Jameson:
>
>> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com <mailto:jameson.lopp@gmail•com>> 写道：
>>
>>
>>
>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>
>>
>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org <mailto:greg@xiph•org>> 写道：
>> >
>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>> > <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>
>> > The enforcement of the system's rules by users broadly, and not just
>> > miners, is specifically described in the white paper (section 8,
>> > paragraph 2, it especially clear in the last sentence). This is
>> > critical for the security of Bitcoin especially with the current
>> > degree of centralization in pools. Without it, Bitcoin's security
>> > would look a lot more like the Ripple system.
>> >
>>
>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
>> Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
>>
>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>
>> 到底我们的用户是否真的拥有选择？
>> Did the users have any real choice?
>>
>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>> I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
>>
>> To be clear, Bitcoin is not a democracy - if you find yourself using the term "voting" then you may be misunderstanding how consensus forms. Once a feature has been vetted and the code is deployed, miners may signal that they are ready to enforce new rules. If for some reason miners are too "passive or lazy" or wish to "veto" the activation of the new rules, users may choose to circumvent said veto by refusing to accept blocks that do not show readiness for enforcing the new rules.
>
> How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork?
>
> I agree with you that the “vote” is not accurate. Could you kindly suggest an other word for that?
>
> I think users should have choice to follow the miners or not. Do you agree with this or not?
>
> Regarding consensus changes, users can voice their opinion on any number of communication platforms. Though if you're looking for a way for users to signal their intentions at the protocol level, every proposal for doing that to date has been arguably flawed. Measuring meatspace consensus is pretty tricky if not completely impossible, especially given the fact that the vast majority of Bitcoin users do not voice any opinions on the matter of consensus rules.
>
“Sybil attack”. The genuine node will leave the chain if it doesn’t like the change. That’s what restrain the majority miners acting foolishly.
If the users like the idea, they follow. If they don’t the fork away(and not afraid of replay attack). I think it’s a way to move forward together.
Would you support the idea that we put the choice to the users to decide?
> Most attempts at measuring user consensus would probably be best described as signaling rather than voting given that the act of doing so has no actual power to affect consensus. Every user who runs a fully validating node is free to enforce the rules with which the agree regardless of what rules other entities are enforcing.
>>
>>
>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>> This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
>>
>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>> If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
>>
>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>> So the questions is: Do the bitcoin developers, users, holders, service provides, even miners, (still) have faith in the majority of miners as designed in the white paper?
>>
>>
>> There is a fundamental misconception regarding this point - the white paper refers to majority hashpower needing to be honest with regard to determining the correct chain within the context of many possible /valid/ chain forks. It is not referring to using hashpower to determine the correct chain amongst an infinitely variable number of currently invalid chain forks. Bitcoin ecosystem participants should not have faith in miners (or any other entity) when it comes to choosing the consensus rules they wish to enforce.
>>
>
> Arrrgh. I think in the BIP, the miners just invalids tx version 1 temporarily. That’s a “soft fork” 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.
And if we add a version 2 valid, does that still be a “soft fork”?
Regards,
LIN Zheming
[-- Attachment #2: Type: text/html, Size: 11380 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 19:04 ` Zheming Lin
@ 2017-06-14 20:11 ` Jameson Lopp
2017-06-16 14:39 ` Zheming Lin
0 siblings, 1 reply; 24+ messages in thread
From: Jameson Lopp @ 2017-06-14 20:11 UTC (permalink / raw)
To: Zheming Lin; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7057 bytes --]
On Wed, Jun 14, 2017 at 12:04 PM, Zheming Lin <heater@gmail•com> wrote:
> Hi Jameson:
>
> 在 2017年6月15日，02:55，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>
>
>
> On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin <heater@gmail•com> wrote:
>
>> Hi Jameson:
>>
>> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>>
>>
>>
>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>>
>>>
>>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
>>> >
>>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> > The enforcement of the system's rules by users broadly, and not just
>>> > miners, is specifically described in the white paper (section 8,
>>> > paragraph 2, it especially clear in the last sentence). This is
>>> > critical for the security of Bitcoin especially with the current
>>> > degree of centralization in pools. Without it, Bitcoin's security
>>> > would look a lot more like the Ripple system.
>>> >
>>>
>>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知
>>> 道必须做出一个选择。（而不是被动的跟随默认的策略）
>>> Yes, users always have choice that they can abandon the nodes. This BIP
>>> does’t go against them. I mean only the one(especially wallets) that’s
>>> passive, they need to know there’s a choice and pick one.
>>>
>>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>>> This BIP can be applied to almost any upgrade, including Segwit,
>>> Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>>
>>> 到底我们的用户是否真的拥有选择？
>>> Did the users have any real choice?
>>>
>>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>>> I don’t see the reason they trust the majority miners(as they do today)
>>> but refuse the vote for upcoming protocol upgrade.
>>>
>>
>> To be clear, Bitcoin is not a democracy - if you find yourself using the
>> term "voting" then you may be misunderstanding how consensus forms. Once a
>> feature has been vetted and the code is deployed, miners may signal that
>> they are ready to enforce new rules. If for some reason miners are too
>> "passive or lazy" or wish to "veto" the activation of the new rules, users
>> may choose to circumvent said veto by refusing to accept blocks that do not
>> show readiness for enforcing the new rules.
>>
>>
>> How does the users show their opinion? They can fork away and leave. But
>> what remains will be united. Are you afraid of the united users or the fork?
>>
>> I agree with you that the “vote” is not accurate. Could you kindly
>> suggest an other word for that?
>>
>> I think users should have choice to follow the miners or not. Do you
>> agree with this or not?
>>
>> Regarding consensus changes, users can voice their opinion on any number
> of communication platforms. Though if you're looking for a way for users to
> signal their intentions at the protocol level, every proposal for doing
> that to date has been arguably flawed. Measuring meatspace consensus is
> pretty tricky if not completely impossible, especially given the fact that
> the vast majority of Bitcoin users do not voice any opinions on the matter
> of consensus rules.
>
>
> “Sybil attack”. The genuine node will leave the chain if it doesn’t like
> the change. That’s what restrain the majority miners acting foolishly.
>
> If the users like the idea, they follow. If they don’t the fork away(and
> not afraid of replay attack). I think it’s a way to move forward together.
>
> Would you support the idea that we put the choice to the users to decide?
>
> The concept of "sybil attacks" doesn't really apply to enforcing
network-wide consensus changes. Even if someone spooled up 100 times more
nodes than currently exist and they all "signal" for some consensus rule
change, that doesn't compel the rest of the "genuine" nodes to change the
rules they enforce.
The users always have a choice with regard to what consensus rules to
enforce and what software to run. Everyone is welcome to propose changes
and write software that they make available to users.
> Most attempts at measuring user consensus would probably be best described
> as signaling rather than voting given that the act of doing so has no
> actual power to affect consensus. Every user who runs a fully validating
> node is free to enforce the rules with which the agree regardless of what
> rules other entities are enforcing.
>
>>
>>
>>>
>>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>>> This choice for wallet users right now, is wether to follow the 51%
>>> majority miners. If they don’t, they can have their fork that get rid of
>>> miners.
>>>
>>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>>> If they do trust the majority miners, they stay and follow the vote for
>>> upcoming protocol upgrade.
>>>
>>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>>> So the questions is: Do the bitcoin developers, users, holders, service
>>> provides, even miners, (still) have faith in the majority of miners as
>>> designed in the white paper?
>>>
>>>
>> There is a fundamental misconception regarding this point - the white
>> paper refers to majority hashpower needing to be honest with regard to
>> determining the correct chain within the context of many possible /valid/
>> chain forks. It is not referring to using hashpower to determine the
>> correct chain amongst an infinitely variable number of currently invalid
>> chain forks. Bitcoin ecosystem participants should not have faith in miners
>> (or any other entity) when it comes to choosing the consensus rules they
>> wish to enforce.
>>
>>
>> Arrrgh. I think in the BIP, the miners just invalids tx version 1
>> temporarily. That’s a “soft fork” 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.
>
>
> And if we add a version 2 valid, does that still be a “soft fork”?
>
> As far as I know - if you're only restricting the validation rules then it
should be a non-breaking change.
>
> Regards,
>
> LIN Zheming
>
[-- Attachment #2: Type: text/html, Size: 11891 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 18:55 ` Jameson Lopp
2017-06-14 19:04 ` Zheming Lin
@ 2017-06-15 5:04 ` Eric Voskuil
2017-06-15 18:38 ` Erik Aronesty
1 sibling, 1 reply; 24+ messages in thread
From: Eric Voskuil @ 2017-06-15 5:04 UTC (permalink / raw)
To: Jameson Lopp; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7574 bytes --]
> 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 <heater@gmail•com> wrote:
>> Hi Jameson:
>>
>>> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>>>
>>>
>>>
>>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>>
>>>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
>>>> >
>>>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>>>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>> > The enforcement of the system's rules by users broadly, and not just
>>>> > miners, is specifically described in the white paper (section 8,
>>>> > paragraph 2, it especially clear in the last sentence). This is
>>>> > critical for the security of Bitcoin especially with the current
>>>> > degree of centralization in pools. Without it, Bitcoin's security
>>>> > would look a lot more like the Ripple system.
>>>> >
>>>>
>>>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
>>>> Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
>>>>
>>>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>>>> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>>>
>>>> 到底我们的用户是否真的拥有选择？
>>>> Did the users have any real choice?
>>>>
>>>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>>>> I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
>>>
>>> To be clear, Bitcoin is not a democracy - if you find yourself using the term "voting" then you may be misunderstanding how consensus forms. Once a feature has been vetted and the code is deployed, miners may signal that they are ready to enforce new rules. If for some reason miners are too "passive or lazy" or wish to "veto" the activation of the new rules, users may choose to circumvent said veto by refusing to accept blocks that do not show readiness for enforcing the new rules.
>>
>> How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork?
>>
>> I agree with you that the “vote” 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 systems in which they vote using their existence as power, not their participation, and they expect some subset of existing human bodies to control all others. This is the concept of some ruling over others, which gives the rulers a more powerful voice than either their proportional existence or individual 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 forks cannot control miners' selection of transactions and miners cannot control the economy's determination of what is valid. If one wants a say in either 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 described as signaling rather than voting given that the act of doing so has no actual power to affect consensus. Every user who runs a fully validating node is free to enforce the rules with which the agree regardless of what rules other entities are enforcing.
>>>
>>>>
>>>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>>>> This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
>>>>
>>>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>>>> If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
>>>>
>>>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>>>> So the questions is: Do the bitcoin developers, users, holders, service provides, even miners, (still) have faith in the majority of miners as designed in the white paper?
>>>>
>>>
>>> There is a fundamental misconception regarding this point - the white paper refers to majority hashpower needing to be honest with regard to determining the correct chain within the context of many possible /valid/ chain forks. It is not referring to using hashpower to determine the correct chain amongst an infinitely variable number of currently invalid chain forks. Bitcoin ecosystem participants should not have faith in miners (or any other entity) when it comes to choosing the consensus rules they wish to enforce.
>>>
>>
>> Arrrgh. I think in the BIP, the miners just invalids tx version 1 temporarily. That’s a “soft fork” 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
[-- Attachment #2: Type: text/html, Size: 12021 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-15 5:04 ` Eric Voskuil
@ 2017-06-15 18:38 ` Erik Aronesty
2017-06-16 3:09 ` Eric Voskuil
0 siblings, 1 reply; 24+ messages in thread
From: Erik Aronesty @ 2017-06-15 18:38 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 8823 bytes --]
> 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.html
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 <heater@gmail•com> wrote:
>
>> Hi Jameson:
>>
>> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>>
>>
>>
>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>>
>>>
>>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
>>> >
>>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> > The enforcement of the system's rules by users broadly, and not just
>>> > miners, is specifically described in the white paper (section 8,
>>> > paragraph 2, it especially clear in the last sentence). This is
>>> > critical for the security of Bitcoin especially with the current
>>> > degree of centralization in pools. Without it, Bitcoin's security
>>> > would look a lot more like the Ripple system.
>>> >
>>>
>>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知
>>> 道必须做出一个选择。（而不是被动的跟随默认的策略）
>>> Yes, users always have choice that they can abandon the nodes. This BIP
>>> does’t go against them. I mean only the one(especially wallets) that’s
>>> passive, they need to know there’s a choice and pick one.
>>>
>>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>>> This BIP can be applied to almost any upgrade, including Segwit,
>>> Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>>
>>> 到底我们的用户是否真的拥有选择？
>>> Did the users have any real choice?
>>>
>>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>>> I don’t see the reason they trust the majority miners(as they do today)
>>> but refuse the vote for upcoming protocol upgrade.
>>>
>>
>> To be clear, Bitcoin is not a democracy - if you find yourself using the
>> term "voting" then you may be misunderstanding how consensus forms. Once a
>> feature has been vetted and the code is deployed, miners may signal that
>> they are ready to enforce new rules. If for some reason miners are too
>> "passive or lazy" or wish to "veto" the activation of the new rules, users
>> may choose to circumvent said veto by refusing to accept blocks that do not
>> show readiness for enforcing the new rules.
>>
>>
>> How does the users show their opinion? They can fork away and leave. But
>> what remains will be united. Are you afraid of the united users or the fork?
>>
>> I agree with you that the “vote” 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 systems
> in which they vote using their existence as power, not their participation,
> and they expect some subset of existing human bodies to control all others.
> This is the concept of some ruling over others, which gives the rulers a
> more powerful voice than either their proportional existence or individual
> 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 forks
> cannot control miners' selection of transactions and miners cannot control
> the economy's determination of what is valid. If one wants a say in either
> 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 described
> as signaling rather than voting given that the act of doing so has no
> actual power to affect consensus. Every user who runs a fully validating
> node is free to enforce the rules with which the agree regardless of what
> rules other entities are enforcing.
>
>>
>>
>>>
>>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>>> This choice for wallet users right now, is wether to follow the 51%
>>> majority miners. If they don’t, they can have their fork that get rid of
>>> miners.
>>>
>>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>>> If they do trust the majority miners, they stay and follow the vote for
>>> upcoming protocol upgrade.
>>>
>>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>>> So the questions is: Do the bitcoin developers, users, holders, service
>>> provides, even miners, (still) have faith in the majority of miners as
>>> designed in the white paper?
>>>
>>>
>> There is a fundamental misconception regarding this point - the white
>> paper refers to majority hashpower needing to be honest with regard to
>> determining the correct chain within the context of many possible /valid/
>> chain forks. It is not referring to using hashpower to determine the
>> correct chain amongst an infinitely variable number of currently invalid
>> chain forks. Bitcoin ecosystem participants should not have faith in miners
>> (or any other entity) when it comes to choosing the consensus rules they
>> wish to enforce.
>>
>>
>> Arrrgh. I think in the BIP, the miners just invalids tx version 1
>> temporarily. That’s a “soft fork” 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
>
>
[-- Attachment #2: Type: text/html, Size: 13890 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-15 18:38 ` Erik Aronesty
@ 2017-06-16 3:09 ` Eric Voskuil
2017-07-22 3:58 ` Zheming Lin
0 siblings, 1 reply; 24+ messages in thread
From: Eric Voskuil @ 2017-06-16 3:09 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 9926 bytes --]
Seems functional as a way for the economy to signal, but signaling is only an expression of intent to participate, not actual participation. One can signal and then not participate, as we see with hash rate signaling.
Today we see people complaining about miner control, because hash rate is centralized. Tomorrow we are likely to see people complaining about economic control, as its centralization continues.
So imagine a few web wallets/APIs signaling based on their ownership of the major fraction of value. Can potential splitters safely rely on these signals? The wallets have a voice because they participate.
Consider also that user activated soft forks are not followed by unmodified nodes (on the presumption of minority hash rate support that necessitated the economic activation). In other words, they exhibit the categorical behavior of hard forks (incompatibility). So to the extent that the economy has control, it is only over the ability to hard fork (split the chain).
e
> On Jun 15, 2017, at 9:38 PM, Erik Aronesty <erik@q32•com> wrote:
>
> > 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.html
>
> 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 <heater@gmail•com> wrote:
>>>> Hi Jameson:
>>>>
>>>>> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>>>
>>>>>>
>>>>>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org> 写道：
>>>>>> >
>>>>>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>>>>>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>>>
>>>>>> > The enforcement of the system's rules by users broadly, and not just
>>>>>> > miners, is specifically described in the white paper (section 8,
>>>>>> > paragraph 2, it especially clear in the last sentence). This is
>>>>>> > critical for the security of Bitcoin especially with the current
>>>>>> > degree of centralization in pools. Without it, Bitcoin's security
>>>>>> > would look a lot more like the Ripple system.
>>>>>> >
>>>>>>
>>>>>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
>>>>>> Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
>>>>>>
>>>>>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>>>>>> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>>>>>
>>>>>> 到底我们的用户是否真的拥有选择？
>>>>>> Did the users have any real choice?
>>>>>>
>>>>>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>>>>>> I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
>>>>>
>>>>> To be clear, Bitcoin is not a democracy - if you find yourself using the term "voting" then you may be misunderstanding how consensus forms. Once a feature has been vetted and the code is deployed, miners may signal that they are ready to enforce new rules. If for some reason miners are too "passive or lazy" or wish to "veto" the activation of the new rules, users may choose to circumvent said veto by refusing to accept blocks that do not show readiness for enforcing the new rules.
>>>>
>>>> How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork?
>>>>
>>>> I agree with you that the “vote” 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 systems in which they vote using their existence as power, not their participation, and they expect some subset of existing human bodies to control all others. This is the concept of some ruling over others, which gives the rulers a more powerful voice than either their proportional existence or individual 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 forks cannot control miners' selection of transactions and miners cannot control the economy's determination of what is valid. If one wants a say in either 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 described as signaling rather than voting given that the act of doing so has no actual power to affect consensus. Every user who runs a fully validating node is free to enforce the rules with which the agree regardless of what rules other entities are enforcing.
>>>>>
>>>>>>
>>>>>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>>>>>> This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
>>>>>>
>>>>>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>>>>>> If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
>>>>>>
>>>>>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>>>>>> So the questions is: Do the bitcoin developers, users, holders, service provides, even miners, (still) have faith in the majority of miners as designed in the white paper?
>>>>>>
>>>>>
>>>>> There is a fundamental misconception regarding this point - the white paper refers to majority hashpower needing to be honest with regard to determining the correct chain within the context of many possible /valid/ chain forks. It is not referring to using hashpower to determine the correct chain amongst an infinitely variable number of currently invalid chain forks. Bitcoin ecosystem participants should not have faith in miners (or any other entity) when it comes to choosing the consensus rules they wish to enforce.
>>>>>
>>>>
>>>> Arrrgh. I think in the BIP, the miners just invalids tx version 1 temporarily. That’s a “soft fork” 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
>>
>
[-- Attachment #2: Type: text/html, Size: 15254 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-14 20:11 ` Jameson Lopp
@ 2017-06-16 14:39 ` Zheming Lin
0 siblings, 0 replies; 24+ messages in thread
From: Zheming Lin @ 2017-06-16 14:39 UTC (permalink / raw)
To: Jameson Lopp; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7117 bytes --]
Will there be a “Do nothing” soft fork, showing that the community can still moving forward?
So all the nodes get to upgrade to use tx version 2, and that avoid a chain split.
Are you support that or against that, why?
Regards,
LIN Zheming
> 在 2017年6月15日，上午4:11，Jameson Lopp <jameson.lopp@gmail•com> 写道：
>
>
>
> On Wed, Jun 14, 2017 at 12:04 PM, Zheming Lin <heater@gmail•com <mailto:heater@gmail•com>> wrote:
> Hi Jameson:
>
>> 在 2017年6月15日，02:55，Jameson Lopp <jameson.lopp@gmail•com <mailto:jameson.lopp@gmail•com>> 写道：
>>
>>
>>
>> On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin <heater@gmail•com <mailto:heater@gmail•com>> wrote:
>> Hi Jameson:
>>
>>> 在 2017年6月15日，01:20，Jameson Lopp <jameson.lopp@gmail•com <mailto:jameson.lopp@gmail•com>> 写道：
>>>
>>>
>>>
>>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>>
>>>
>>> > 在 2017年6月14日，02:11，Gregory Maxwell <greg@xiph•org <mailto:greg@xiph•org>> 写道：
>>> >
>>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>>> > <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>>
>>> > The enforcement of the system's rules by users broadly, and not just
>>> > miners, is specifically described in the white paper (section 8,
>>> > paragraph 2, it especially clear in the last sentence). This is
>>> > critical for the security of Bitcoin especially with the current
>>> > degree of centralization in pools. Without it, Bitcoin's security
>>> > would look a lot more like the Ripple system.
>>> >
>>>
>>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
>>> Yes, users always have choice that they can abandon the nodes. This BIP does’t go against them. I mean only the one(especially wallets) that’s passive, they need to know there’s a choice and pick one.
>>>
>>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>>> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>>
>>> 到底我们的用户是否真的拥有选择？
>>> Did the users have any real choice?
>>>
>>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>>> I don’t see the reason they trust the majority miners(as they do today) but refuse the vote for upcoming protocol upgrade.
>>>
>>> To be clear, Bitcoin is not a democracy - if you find yourself using the term "voting" then you may be misunderstanding how consensus forms. Once a feature has been vetted and the code is deployed, miners may signal that they are ready to enforce new rules. If for some reason miners are too "passive or lazy" or wish to "veto" the activation of the new rules, users may choose to circumvent said veto by refusing to accept blocks that do not show readiness for enforcing the new rules.
>>
>> How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork?
>>
>> I agree with you that the “vote” is not accurate. Could you kindly suggest an other word for that?
>>
>> I think users should have choice to follow the miners or not. Do you agree with this or not?
>>
>> Regarding consensus changes, users can voice their opinion on any number of communication platforms. Though if you're looking for a way for users to signal their intentions at the protocol level, every proposal for doing that to date has been arguably flawed. Measuring meatspace consensus is pretty tricky if not completely impossible, especially given the fact that the vast majority of Bitcoin users do not voice any opinions on the matter of consensus rules.
>>
>
> “Sybil attack”. The genuine node will leave the chain if it doesn’t like the change. That’s what restrain the majority miners acting foolishly.
>
> If the users like the idea, they follow. If they don’t the fork away(and not afraid of replay attack). I think it’s a way to move forward together.
>
> Would you support the idea that we put the choice to the users to decide?
>
> The concept of "sybil attacks" doesn't really apply to enforcing network-wide consensus changes. Even if someone spooled up 100 times more nodes than currently exist and they all "signal" for some consensus rule change, that doesn't compel the rest of the "genuine" nodes to change the rules they enforce.
>
> The users always have a choice with regard to what consensus rules to enforce and what software to run. Everyone is welcome to propose changes and write software that they make available to users.
>> Most attempts at measuring user consensus would probably be best described as signaling rather than voting given that the act of doing so has no actual power to affect consensus. Every user who runs a fully validating node is free to enforce the rules with which the agree regardless of what rules other entities are enforcing.
>>>
>>>
>>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>>> This choice for wallet users right now, is wether to follow the 51% majority miners. If they don’t, they can have their fork that get rid of miners.
>>>
>>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>>> If they do trust the majority miners, they stay and follow the vote for upcoming protocol upgrade.
>>>
>>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>>> So the questions is: Do the bitcoin developers, users, holders, service provides, even miners, (still) have faith in the majority of miners as designed in the white paper?
>>>
>>>
>>> There is a fundamental misconception regarding this point - the white paper refers to majority hashpower needing to be honest with regard to determining the correct chain within the context of many possible /valid/ chain forks. It is not referring to using hashpower to determine the correct chain amongst an infinitely variable number of currently invalid chain forks. Bitcoin ecosystem participants should not have faith in miners (or any other entity) when it comes to choosing the consensus rules they wish to enforce.
>>>
>>
>> Arrrgh. I think in the BIP, the miners just invalids tx version 1 temporarily. That’s a “soft fork” 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.
>
> And if we add a version 2 valid, does that still be a “soft fork”?
>
> As far as I know - if you're only restricting the validation rules then it should be a non-breaking change.
>
> Regards,
>
> LIN Zheming
[-- Attachment #2: Type: text/html, Size: 14609 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
2017-06-16 3:09 ` Eric Voskuil
@ 2017-07-22 3:58 ` Zheming Lin
0 siblings, 0 replies; 24+ messages in thread
From: Zheming Lin @ 2017-07-22 3:58 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
I think we should not switch to Proof of Stake system.
in Proof of Stake system, the one with more voting power tend to protect
their investment and that will stop others from competing with them. they
will use the voting power to make entering barrier, limiting the
competition is bad for bitcoin economy (I believe).
Miners are not centralized, they just grow bigger and be industrialized,
but there's still a lot of competition. The competition is the main
security model of bitcoin system.
When we are talking about "security" in bitcoin system, we are talking
about the probability that a transaction revert or change. We can not be
100% sure under 3 confirmations, but in 6 or more confirmations, we think
the cash received is safe and can't be taken away. That's the security
provided by bitcoin system.
Hard fork is not dangerous, when hard fork happens, people can wait for a
short time (like maintenance of a POS/CreditCard system). When the chain
with most hashrate wins (with high enough probability), we can then safely
assume that the longest chain can't be reverted.
Regards,
LIN Zheming
[-- Attachment #2: Type: text/html, Size: 1607 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-07-22 3:58 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-13 2:23 [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners Zheming Lin
2017-06-13 5:44 ` James Hilliard
2017-06-13 6:50 ` Zheming Lin
2017-06-13 7:19 ` James Hilliard
2017-06-13 8:13 ` Zheming Lin
2017-06-13 8:37 ` James Hilliard
2017-06-13 19:35 ` Jared Lee Richardson
2017-06-14 0:23 ` James Hilliard
2017-06-14 1:08 ` Jared Lee Richardson
2017-06-13 8:24 ` Zheming Lin
2017-06-13 10:20 ` James Hilliard
2017-06-13 18:11 ` Gregory Maxwell
2017-06-14 16:39 ` Zheming Lin
2017-06-14 17:20 ` Jameson Lopp
2017-06-14 18:29 ` Zheming Lin
2017-06-14 18:55 ` Jameson Lopp
2017-06-14 19:04 ` Zheming Lin
2017-06-14 20:11 ` Jameson Lopp
2017-06-16 14:39 ` Zheming Lin
2017-06-15 5:04 ` Eric Voskuil
2017-06-15 18:38 ` Erik Aronesty
2017-06-16 3:09 ` Eric Voskuil
2017-07-22 3:58 ` Zheming Lin
2017-06-14 18:30 ` Zheming Lin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox