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

[Jameson Lopp <jameson.lopp@gmail.com>]

[-- 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 --]