Zheming Lin [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-13 📝 Original message:Hi James: > 在 ...

📅 Original date posted:2017-06-13
📝 Original message:Hi James:

> 在 2017年6月13日，15:19，James Hilliard <james.hilliard1 at gmail.com> 写道：
>
> On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin <heater at gmail.com <mailto:heater at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170613/5b7117d4/attachment-0001.html>;