From: Gregory Maxwell <gmaxwell@gmail•com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] 0.8.1 ideas
Date: Wed, 13 Mar 2013 06:14:00 -0700 [thread overview]
Message-ID: <CAAS2fgRJxx3VwBoQm2Tkwr-DbAg6wQityzegZXxddXbqBSh8dQ@mail.gmail.com> (raw)
In-Reply-To: <201303131256.30144.luke@dashjr.org>
On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr <luke@dashjr•org> wrote:
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391 transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe unless a reorg is more than
> 6 blocks deep)
I'm not a fan of the two stages, your before block 262144 part sounds
fine to me, though I thought the safe number was closer to 5000.
Perhaps 4911?
The goal here is to pick something which is _absolutely sure_ to be
less than what pre-0.8 accepts (so that its is just a soft fork), but
it need not be needlessly smaller than that.
I think we can accept some small risk of "backport" clients getting
stuck after large reorgs after there has been sufficient upgrade time.
Performance reasons mean that its very likely no one will be mining
on those nodes by then, and so if they get stuck they'll just need to
manually unstick them. Difficulty is high enough that its unlikely
anything important will remain stuck long enough for a malicious party
to exploit them by mining blocks on the stuck fork.
By allowing that risk you halve the complexity of your change by not
requiring two hard forks. The 'never make' half of it would probably
be fine.
As far as the size change, that should be a separate process after
we've proven the ability to make a hardforking change with something
low risk/low controversy like this, and only after someone has
actually shown that the software is stable under those conditions lest
we get another issue like we have now where the increase in block
target from 500k/250k to 1MB by a miner exposed inadequate testing.
next prev parent reply other threads:[~2013-03-13 13:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 12:56 Luke-Jr
2013-03-13 13:14 ` Gregory Maxwell [this message]
2013-03-13 15:05 ` Peter Todd
2013-03-13 15:18 ` Gregory Maxwell
2013-03-13 15:26 ` Luke-Jr
2013-03-13 16:04 ` Peter Todd
2013-03-13 17:41 ` Mark Friedenbach
2013-03-13 17:58 ` Pieter Wuille
2013-03-13 18:27 ` Mark Friedenbach
2013-03-13 18:35 ` slush
2013-03-13 18:38 ` Pieter Wuille
2013-03-13 19:30 ` Gregory Maxwell
[not found] ` <16B6728E-4220-4DA6-B740-FA38A7C19CCB@thelibertyportal.com>
2013-03-13 20:24 ` Gregory Maxwell
2013-03-13 20:18 ` Luke-Jr
2013-03-13 18:04 ` Luke-Jr
2013-03-13 21:06 ` Andy Parkins
2013-03-13 21:14 ` Luke-Jr
2013-03-13 21:22 ` Roy Badami
2013-03-13 21:27 ` Gregory Maxwell
2013-03-13 21:36 ` Roy Badami
2013-03-14 0:18 ` Cameron Garnham
2013-03-15 17:06 ` Benjamin Lindner
2013-03-15 19:23 ` Luke-Jr
2013-03-15 19:52 ` Gregory Maxwell
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=CAAS2fgRJxx3VwBoQm2Tkwr-DbAg6wQityzegZXxddXbqBSh8dQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/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