From: Michael Gronager <gronager@ceptacle•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk
Date: Tue, 12 Mar 2013 14:00:13 +0100 [thread overview]
Message-ID: <5F4490C7-8846-4AA7-AF9B-9A02DDEC6245@ceptacle.com> (raw)
In-Reply-To: <CAAS2fgSOxon1m79gA_afgG7ypHRJfurb4ydZuCBgb_sSy1HG+w@mail.gmail.com>
>> Forks are caused by rejection criteria, hence:
>> 1. If you introduce new rejection criteria in an upgrade miners should upgrade _first_.
>> 2. If you loosen some rejection criteria miners should upgrade _last_.
>> 3. If you keep the same criteria assume 2.
>
> And ... if you aren't aware that you're making a change ???
then only half should upgrade :-P
Well I thought I covered that by 3... But, question is of course if we could have been in a situation where 0.8 had been the one rejecting blocks?
So miners could go with a filtering approach: only connect to the network through a node of a version one less than the current. That would still have caused block 225430 to be created, but it would never have been relayed and hence no harm. (and if the issue had been in 0.8 the block would not even have been accepted there in the first place). Downside is some lost seconds.
/M
prev parent reply other threads:[~2013-03-12 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 0:18 Pieter Wuille
2013-03-12 1:01 ` Pieter Wuille
2013-03-12 9:10 ` Mike Hearn
2013-03-12 9:53 ` Jorge Timón
2013-03-12 9:57 ` Peter Todd
2013-03-12 10:10 ` Mike Hearn
2013-03-12 10:17 ` Peter Todd
2013-03-12 10:13 ` Michael Gronager
2013-03-12 10:26 ` Peter Todd
2013-03-12 10:43 ` Mike Hearn
2013-03-12 10:40 ` Roy Badami
2013-03-12 11:44 ` Pieter Wuille
2013-03-12 12:11 ` Mike Hearn
2013-03-12 12:27 ` Michael Gronager
2013-03-12 12:18 ` Jorge Timón
2013-03-12 12:40 ` Jay F
2013-03-12 12:38 ` Gregory Maxwell
2013-03-12 13:00 ` 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=5F4490C7-8846-4AA7-AF9B-9A02DDEC6245@ceptacle.com \
--to=gronager@ceptacle$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@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