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 --]
next prev parent reply other threads:[~2017-06-15 18:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2017-06-16 3:09 ` Eric Voskuil
2017-07-22 3:58 ` Zheming Lin
2017-06-14 18:30 ` Zheming Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJowKgJE6+1nKFYngTRhS_X2z_tmLoxY__J_Aph6UHmAnR8tcQ@mail.gmail.com \
--to=erik@q32.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=eric@voskuil.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox