From: Pieter Wuille <pieter.wuille@gmail•com>
To: digitsu <jerry.d.chan@bittoku•co.jp>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Sat, 26 Dec 2015 17:44:41 +0100 [thread overview]
Message-ID: <CAPg+sBiT5=ss9e=iac6J-A=85okF0zxMeV7H4z9-Qfx3CAWHXA@mail.gmail.com> (raw)
In-Reply-To: <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
That's exactly the point: a hard fork does not just affect miners, and
cannot just get decided by miners. All full nodes must have accepted the
new rules, or they will be forked off when the hashrate percentage triggers.
Furthermore, 75% is pretty terrible as a switchover point, as it guarantees
that old nodes will still see a 25% forked off chain temporarily.
My opinion is that the role of Bitcoin Core maintainers is judging whether
consensus for a hard fork exists, and is technically necessary and safe. We
don't need a hashpower vote to decide whether a hardfork is accepted or
not, we need to be sure that full noded will accept it, and adopt it in
time. A hashpower vote can still be used to be sure that miners _also_
agree.
Currently, a large amount of developers and others believe that the
treshhold for a hardfork is not reached, especially given the fact that we
scale in the short term, as well as make many changes that long-term
benefit scalability, with just a softfork (which does not require forking
off nodes that don't adopt the new rules, for whatever reason).
--
Pieter
On Dec 26, 2015 17:25, "digitsu" <jerry.d.chan@bittoku•co.jp> wrote:
> So it seems that everyone is in agreement then, since a hard fork to 2M is
> orthogonal to SW, and also that core should not be involved in dictating
> what the consensus rules should be, then why not put BIP102 into play with
> a 75% mining majority activation and let the market decide.
>
> As it’s activation only involves the miners, and its implementation
> doesn’t affect users or exchanges, then it poses no complication to SW
> which can do done in parallel.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2004 bytes --]
next prev parent reply other threads:[~2015-12-26 16:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 14:53 Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08 ` Jeff Garzik
2015-12-16 21:11 ` Pieter Wuille
2015-12-17 2:06 ` Jameson Lopp
2015-12-17 16:58 ` Tier Nolan
2015-12-17 19:44 ` Peter Todd
2015-12-18 5:23 ` Jorge Timón
2015-12-18 9:44 ` Tier Nolan
2015-12-16 21:24 ` Jorge Timón
2015-12-16 21:36 ` Jeff Garzik
2015-12-18 5:11 ` Jeff Garzik
2015-12-18 7:56 ` Pieter Wuille
2015-12-18 10:13 ` sickpig
2015-12-18 15:48 ` Pieter Wuille
2015-12-19 19:04 ` Dave Scotese
[not found] ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44 ` Pieter Wuille [this message]
2015-12-26 17:20 ` Jorge Timón
2015-12-26 22:55 ` Jonathan Toomim
2015-12-26 23:01 ` Pieter Wuille
2015-12-26 23:07 ` Jonathan Toomim
2015-12-26 23:16 ` Pieter Wuille
2015-12-27 0:03 ` Jonathan Toomim
2015-12-26 23:15 ` Justus Ranvier
2015-12-27 0:13 ` Bryan Bishop
2015-12-27 0:33 ` Justus Ranvier
2015-12-18 13:56 ` Jeff Garzik
2015-12-23 6:26 ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27 ` Jeff Garzik
2015-12-17 6:12 ` Dave Scotese
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='CAPg+sBiT5=ss9e=iac6J-A=85okF0zxMeV7H4z9-Qfx3CAWHXA@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jerry.d.chan@bittoku$(echo .)co.jp \
/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