public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners
Date: Fri, 16 Jun 2017 06:09:33 +0300	[thread overview]
Message-ID: <8999832B-BD81-415A-9CA5-0DE397A1A904@voskuil.org> (raw)
In-Reply-To: <CAJowKgJE6+1nKFYngTRhS_X2z_tmLoxY__J_Aph6UHmAnR8tcQ@mail.gmail.com>

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

  reply	other threads:[~2017-06-16  3:09 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
2017-06-16  3:09               ` Eric Voskuil [this message]
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=8999832B-BD81-415A-9CA5-0DE397A1A904@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=erik@q32.com \
    /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