From: Gregory Maxwell <greg@xiph•org>
To: Zheming Lin <heater@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: Tue, 13 Jun 2017 18:11:39 +0000 [thread overview]
Message-ID: <CAAS2fgT=0k0NJWsO_TtBRTi2VqZtzuT1d1Sk+KZ2+2PUcA71tg@mail.gmail.com> (raw)
In-Reply-To: <A6AE8145-8C8A-44C2-88D3-8574D895AF6B@gmail.com>
On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
<bitcoin-dev@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.
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.
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.
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.)
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,
next prev parent reply other threads:[~2017-06-13 18:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-13 2:23 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 [this message]
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
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='CAAS2fgT=0k0NJWsO_TtBRTi2VqZtzuT1d1Sk+KZ2+2PUcA71tg@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=heater@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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