From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>,
Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] On soft-forks and hard-forks
Date: Tue, 29 Oct 2013 12:35:05 -0400 [thread overview]
Message-ID: <20131029163505.GA28320@petertodd.org> (raw)
In-Reply-To: <CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4311 bytes --]
> On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <pete@petertodd•org> wrote:
> > Peter Todd <pete@petertodd•org> wrote:
> > >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
> > >> For block 0x11 again shall there be a separate code for "block is
> > >from the
> > >> future"? We don't want to lose the nVersion field to people just
> > >using it
> > >> for nonsense, so does it make sense to reject blocks that claim to be
> > >v2 or
> > >> v3?
> > >
> > >That would prevent us from using nVersion as a soft-forking mechanism.
> >
> > Actually, that statement didn't go far enough: rejecting blocks with
> > nVersions that you don't expect is a hard fork.
>
> Yes, exactly. That's the point. As you well know I think the whole
> soft-fork mechanism is wrong and should not be used. If the rules change,
> your node is *supposed* to end up on a chain fork and trigger an alert to
> you, that's pretty much the whole purpose of Bitcoin's design. Undermining
> that security model is problematic.
That's a nice sentiment, but there's a lot more nuance to it than
"soft-forks are bad"
We're talking about rejection here: you don't want to end up on an
isolated chain fork wondering if maybe miners have been unlucky. You
want to know that a longer chain exists so as to have solid evidence
that you're local configuration isn't what miners are mining. Thus not
only should you "accept" blocks with versions you don't know about, you
should relay those blocks as well so that other out-of-date nodes have
the highest possible chance of finding out about them. Creating a block
is expensive, so with some minor safeguards - a high minimum difficulty,
and maximum size - relaying blocks you consider invalid is perfectly
safe and doesn't enable DoS attacks. Relaying block headers has similar
logic, and even less DoS attack worry. (don't apply bloom filters to
invalid blocks though!)
I had this discussion with Warren the other day actually: Litecoin is
considering banning old node versions and rejecting their attempts to
connect. I pointed out how you wanted to be damn sure there was no-one
mining with them, least you wind up creating a slowly growing fork mined
by nodes unaware of the main chain.
Soft-forks and SPV nodes is another topic. SPV nodes don't do any
meaningful validation - they usually don't even have the transaction
inputs spent by a transaction to determine if a scriptSig is valid.
Their security is already dependent on miners, so allowing those miners
to upgrade does no harm. In addition there are even cases where what
would be a hard-fork for a full node, is a soft-fork for a SPV node. On
the other hand if your "SPV" node is more sophisticated, then by all
means use a nVersion change to trigger an alert to the user. If you're
implementation relays blockchain data, continue doing so to ensure other
nodes find out about the new version as soon as possible. (all SPV nodes
should relay block headers if possible)
Note how the nVersion field is useful for voting: the "chain height in
coinbase" soft-fork was accomplished this way, changing nVersion from 1
to 2 with full enforcement of the rule triggered by a 95% supermajority.
Bitcoin is a decentralized system, so any changes need to be done by
voting to show that a clear consensus of hashing power will enforce and
validate the new rules. (time and height deadlines can be disasters if
the upgrade is ever ignored or delayed)
Interestingly this suggests that what we actually want is two nVersions
per upgrade: the first to signal that nodes wish to upgrade, and are
showing their intent to use the new rules. The second to signal that the
upgrade has actually happened and the old rules are now ignored. Client
software can use this two stage approach to know when rules may have
changed, and the user probably should consider upgrading. As applied to
the chain height upgrade we would have gone from version 2 during the
voting, to version 3 for any block produced while the rules were in
effect. Put another way, the last in nVersion is simply to signify that
the new blockchain rules are now active, as opposed to being proposed.
--
'peter'[:-1]@petertodd.org
000000000000000180dabf823b09a30b4f2032b5cab7ba1d0351cab350bee91f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-10-29 16:35 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-26 0:34 [Bitcoin-development] Feedback requested: "reject" p2p message Gavin Andresen
2013-10-26 1:01 ` Jean-Paul Kogelman
2013-10-26 2:00 ` Gavin
2013-10-26 4:32 ` kjj
2013-10-27 14:32 ` Mike Hearn
2013-10-27 14:39 ` Luke-Jr
2013-10-27 14:50 ` Mike Hearn
2013-10-30 17:13 ` Gregory Maxwell
2013-10-31 12:01 ` Mike Hearn
2013-10-27 22:52 ` Gavin Andresen
2013-10-28 2:52 ` kjj
2013-10-28 9:26 ` Andreas Schildbach
2013-10-28 9:32 ` Gregory Maxwell
2013-10-29 5:37 ` Gavin Andresen
2013-10-29 8:55 ` Warren Togami Jr.
2013-10-29 9:12 ` Peter Todd
2013-10-29 9:52 ` Mike Hearn
2013-10-29 10:14 ` Peter Todd
2013-10-29 11:38 ` Peter Todd
2013-10-29 12:32 ` Mike Hearn
2013-10-29 16:35 ` Peter Todd [this message]
2013-10-30 2:01 ` Gavin Andresen
2013-10-30 8:24 ` Mike Hearn
2013-10-30 9:05 ` Mark Friedenbach
2013-10-30 10:26 ` Mike Hearn
2013-10-28 2:59 ` Luke-Jr
2013-10-28 3:02 ` Pieter Wuille
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=20131029163505.GA28320@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)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