public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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





      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 [Bitcoin-development] Blocksize and off-chain transactions 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.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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