From: Michael Gronager <gronager@ceptacle•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net,
Michael Gronager <gronager@ceptacle•com>
Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions
Date: Wed, 13 Mar 2013 21:14:24 +0100 [thread overview]
Message-ID: <BEB68029-123A-4497-A59B-6487FE99742B@ceptacle.com> (raw)
In-Reply-To: <20130313182805.GA7921@vps7135.xlshosting.net>
I hear consensus that at some point we need a hardfork (== creating blocks that will not be accepted by <0.7 clients).
Miners generate block, hence they are the ones who should filter themselves though some consensus.
> But we cannot just drop support for old nodes. It is completely unreasonable to put the
> _majority_ of the network on a fork, without even as much as a discussion about it.
> "Oh, you didn't get the memo? The rules implemented in your client are outdated." - that
> is not how Bitcoin works: the network defines the rules.
Consensus was rapidly reached a day ago: To ensure the majority (all of?) the network could accept the blocks mined, and not just 0.8. This was the right decision! Too many was dependent on <=0.7
So, the question is not if, but when to do a hardfork. We need to define and monitor the % of nodes running different versions (preferably a weighted average - some nodes, like e.g. blockchain.info & mtgox serve many...). Once there was the rowit bitcoinstatus page - do we have another resource for this ?
Then the second question is how to ensure we don't create a fork again? Pieter (and others?) are of the opinion that we should mimic a 0.7 lock-object-starvation-reject-rule. I don't like this for three reasons:
1. I find it hard to ensure we have actually coined the bug precisely
2. I expect that similar issues will happen again
3. The current issue was between two versions, but in the future it could be between two implementations - then trying implement or even to coordinate strange rules becomes very unlikely.
Hence the scheme for "considerate mining" - it is the only scheme that guarantees 100% that no block are released that will not be accepted by a supermajority of the install base.
Another nice thing about it - it requires no development :)
So simply run in serial in front of all considerate miners nodes of different versions until a certain threshold of the install base is reached.
/M
prev parent reply other threads:[~2013-03-13 20:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 17:01 Gavin Andresen
2013-03-13 17:48 ` Peter Todd
2013-03-13 18:01 ` Michael Gronager
2013-03-13 18:08 ` Luke-Jr
2013-03-13 18:28 ` Pieter Wuille
2013-03-13 19:29 ` Roy Badami
2013-03-13 19:43 ` Stephen Pair
2013-03-13 20:14 ` Michael Gronager [this message]
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=BEB68029-123A-4497-A59B-6487FE99742B@ceptacle.com \
--to=gronager@ceptacle$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@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