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

From: Erik Aronesty <erik@q32•com>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
Date: Thu, 15 Jun 2017 14:38:57 -0400	[thread overview]
Message-ID: <CAJowKgJE6+1nKFYngTRhS_X2z_tmLoxY__J_Aph6UHmAnR8tcQ@mail.gmail.com> (raw)
In-Reply-To: <95BB8EA8-31F6-4131-B557-A35342FA17A1@voskuil.org>

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