Jameson Lopp [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-14 📝 Original message:On Wed, Jun 14, 2017 at ...

📅 Original date posted:2017-06-14
📝 Original message:On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
>
> > 在 2017年6月14日，02:11，Gregory Maxwell <greg at xiph.org> 写道：
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> The BIP is described using Chinese and English. If any part is missing
> or need more specific, please reply. Forgive for my poor English.
> >
> > Your English is much better than my Chinese. Thank you for taking the
> > time to write this.
> >
> > I am still reading and trying to completely understand your proposal
> > but I wanted to make one observation:
> >
> >> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。<br/>
> >> In view of the fact that the original Bitcoin consensus did not
> consider the non-mining wallet nodes(as mentioned above), the result is
> that upgrading the consensus of these wallet nodes is passive and lazy.
> >
> > This is not true. Non-mining wallet nodes were considered, and their
> > upgrade practices are not usually slower than miners.
> >
>
> 我针对的是懒惰和被动的节点，而非活跃做出选择的节点。用户愿意的话总是可以做出自己的选择。并没有办法来强迫并不认同的人形成共识。
> I mean lazy and passive ones I addressed. Not the one actively chose
> whichever solution they like. Users always have their solution. There’s no
> way to force a union if they are not together.
>
> > Even in the very first version of the software it did not mine unless
> > the user went into the settings and explicitly turned it on or used a
> > command-line option. By default, every installation of Bitcoin was a
> > non-mining wallet node.
> >
>
> 在中本聪白皮书中第五章的定义下，每个节点都需要挖矿。如果咱俩对此存在分歧，我并无法说服你。
> From the definition of Satishi Nakamoto, Section 5, each node mines. If
> that’s the disagreement between us, there’s no more I can convince you.
>
> > 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.


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


> > Frequently it is the miners that are "passive and lazy" in upgrading.
> > In some cases when new versions have had major improvements specific
> > to mining (such as for 0.8) miners upgraded much faster than other
> > nodes. But often, it is the other way around and miners adopt new
> > versions much slower than other nodes. If you look at block
> > construction today you will see that many miners are running highly
> > outdated node software which is more than one or even two years old.
> > (and as a result, they lose out on a considerable amount of
> > transaction fees.)
> >
>
> 我个人将这种行为视作对当前版本的反对票。这个BIP也考虑了这种情况，您是否注意到矿工应该先升级（避免被孤立），这是否解决了你提出的问题呢？
> I personally take that as VETO to current version. This BIP also address
> this situation. Did you notice that miners should be upgraded first? Did
> that solve the problem you mentioned above?
>
> 如果我们可以通过这个方法让所有矿工至少都要升级到相同的共识版本并开始对将来的升级投票，那应该不会有任何问题。
> 除非矿工希望进行的投票，不是某些人希望看到的投票。
> If we can use this method to at least make miners upgraded to the same
> consensus version and start to vote for the upcoming changes, that would
> solve the problem for the passive behavior. Unless the vote miners wish to
> hold, is not in the wishlist of someone.
>
> > In fact, many miners have the most severe form of passive behavior:
> > they do not run a node at all but simply sell their hash power to
> > pools (which themselves are often slow to upgrade). By comparison,
> > http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html 95%
> > of reachable nodes are running software now from the last year and a
> > half.
> >
> > I do not, however, believe that it is a problem that anyone is slow to
> upgrade.
> >
> > Reliability cannot be maintained in infrastructure if it is rapidly
> > changing. A normal deployment process for major systems
> > infrastructure outside of Bitcoin usually takes months because time
> > must be given to test and find bugs.
> >
> > Miners depend on their income from mining and interruptions can be
> > very costly. Many pools are also involved with altcoins which are
> > constantly breaking and they have their attention directed elsewhere
> > and cannot quickly spare the time required to upgrade their software.
> > These delays are the natural consequence of a decentralized system
> > where no one has the power to force other people to adopt their
> > priorities.
> >
> > If you look at the deployment processes of major internet protocols,
> > HTTP2, new versions of SSH, BGP, or IP itself you will find that
> > upgrades often happen slower than the entire life of Bitcoin so far--
> > and none of these protocols have the difficult consistency challenges
> > of Bitcoin or as much risk of irreparable financial loss if things go
> > wrong.
> >
> > Because many people in the Bitcoin community appears to expect
> > upgrades much faster than even centralized ISP backbones upgrade their
> > router software I think they have unrealistic expectations with how
> > fast upgrading can occur while preserving stability, security, and
> > decentralization and unrealistic expectations of how fast upgrading
> > will occur so long as no one has the ability to force other people to
> > run their upgrades.
> >
> > I look forward to competing my understanding of your proposal.
> >
> > Cheers,
>
> I think the divergency is from the different definition of bitcoin. If no
> common understanding, let’s get one from the white paper, together.
>
> Regards
>
> LIN Zheming
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170614/d3d09d0c/attachment-0001.html>;