From: Roy Badami <roy@gnomon•org.uk>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Mechanics of a hard fork
Date: Thu, 7 May 2015 21:00:23 +0100 [thread overview]
Message-ID: <20150507200023.GI63100@giles.gnomon.org.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard fork proposal has consensus if we haven't even decided
what level of supermajority is needed to establish consensus?
For instance, back in 2012 Gavin was proposing, effectively, that a
hard fork should require a supermajority of 99% of miners in order to
succeed:
https://gist.github.com/gavinandresen/2355445
More recently, Gavin has proposed that a supermoajority of only 80% of
miners should be needed in order to trigger the hard fork.
http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html
Just now, on this list (see attached message) Gavin seems to be
aluding to some mechanism for a hard fork which involves consensus of
full nodes, and then a soft fork preceeding the hard fork, which I'd
love to see a full explanation of.
FWIW, I think 80% is far too low to establish consensus for a hard
fork. I think the supermajority of miners should be sufficiently
large that the rump doesn't constitute a viable coin. If you don't
have that very strong level of consensus then you risk forking Bitcoin
into two competing coins (and I believe we already have one exchange
promissing to trade both forks as long as the blockchains are alive).
As a starting point, I think 35/36th of miners (approximately 97.2%)
is the minimum I would be comfortable with. It means that the rump
coin will initially have an average confirmation time of 6 hours
(until difficulty, very slowly, adjusts) which is probably far enough
from viable that the majority of holdouts will quickly desert it too.
Thoughs?
roy
[-- Attachment #2: hardfork.eml --]
[-- Type: message/rfc822, Size: 9872 bytes --]
[-- Attachment #2.1.1.1: Type: text/plain, Size: 1971 bytes --]
For reference: the blog post that (re)-started this debate, and which links
to individual issues, is here:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
In it, I asked people to email me objections I might have missed. I would
still appreciate it if people do that; it is impossible to keep up with
this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
also have time to respond thoughtfully to the objections raised.
I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
how much transaction volume the main Bitcoin blockchain will be able to
support over the next eleven years."
I've been pretty clear on what I think is a reasonable compromise (a
one-time increase scheduled for early next year), and I have tried to
explain why I think it it is the right set of tradeoffs.
There ARE tradeoffs here, and the hard question is what process do we use
to decide those tradeoffs? How do we come to consensus? Is it worth my
time to spend hours responding thoughtfully to every new objection raised
here, or will the same thing happen that happened last year and the year
before-- everybody eventually gets tired of arguing
angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
I AM considering contributing some version of the bigger blocksize-limit
hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
fast Internet connection, and assume Nelson's law to increase over time),
and then encouraging merchants and exchanges and web wallets and
individuals who think it strikes a reasonable balance to run it.
And then, assuming it became a super-majority of nodes on the network,
encourage miners to roll out a soft-fork to start producing bigger blocks
and eventually trigger the hard fork.
Because ultimately consensus comes down to what software people choose to
run.
--
--
Gavin Andresen
[-- Attachment #2.1.1.2: Type: text/html, Size: 2677 bytes --]
[-- Attachment #2.1.2: Type: text/plain, Size: 409 bytes --]
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
[-- Attachment #2.1.3: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next reply other threads:[~2015-05-07 20:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 20:00 Roy Badami [this message]
2015-05-07 21:24 ` Tier Nolan
2015-05-07 21:42 ` Roy Badami
2015-05-07 21:49 ` Pieter Wuille
2015-05-07 22:08 ` Roy Badami
2015-05-08 2:16 ` Adam Back
2015-05-08 2:35 ` Pieter Wuille
2015-05-08 3:12 ` Cameron Garnham
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=20150507200023.GI63100@giles.gnomon.org.uk \
--to=roy@gnomon$(echo .)org.uk \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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