public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Zheming Lin <heater@gmail.com>
To: Jameson Lopp <jameson.lopp@gmail.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: Thu, 15 Jun 2017 02:29:35 +0800	[thread overview]
Message-ID: <31040BE1-64ED-4D05-BCBE-E80BC7B9A182@gmail.com> (raw)
In-Reply-To: <CADL_X_fdZG50HHb3iOePrzuOwU55tAqP80u3--xXEDWBKL7=jg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]

Hi Jameson:

> 在 2017年6月15日,01:20,Jameson Lopp <jameson.lopp@gmail.com <mailto:jameson.lopp@gmail.com>> 写道:
> 
> 
> 
> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> 
> > 在 2017年6月14日,02:11,Gregory Maxwell <greg@xiph.org <mailto:greg@xiph.org>> 写道:
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org <mailto: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?

>  
> 
> 对钱包用户的选择,是他们是否相信多数矿工。如果他们不相信,可以通过分叉来消除掉矿工。
> 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.


Regards

LIN Zheming


[-- Attachment #2: Type: text/html, Size: 8004 bytes --]

  reply	other threads:[~2017-06-14 18:30 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 [this message]
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
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=31040BE1-64ED-4D05-BCBE-E80BC7B9A182@gmail.com \
    --to=heater@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jameson.lopp@gmail.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