From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org, "Jorge Timón" <jtimon@jtimon•cc>
Subject: Re: [bitcoin-dev] New BIP: Hardfork warning system
Date: Fri, 2 Dec 2016 04:18:21 +0000 [thread overview]
Message-ID: <201612020418.23011.luke@dashjr.org> (raw)
In-Reply-To: <CABm2gDoQ8_Wpc+zCwf-sbUhLYYy-cjdO2dgvzADQX9PAq+yYnw@mail.gmail.com>
On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote:
> We can already warn users of a hardfork when a block is invalid (at
> least) because of the highest bit in nVersion (as you say, because it
> is forbidden since bip34 was deployed).
The difference is that right now, full nodes will happily follow a shorter
best-valid chain. This BIP would require them to hold back at the best-common
block between the best-valid chain and the invalid chain, forcing the user to
make a decision whether to reject the invalid chain permanently, or upgrade to
a version which can understand that chain as valid.
> It seems the softfork serves only to warn about soft-hardforks, assuming it
> chooses to use this mechanism (which a malicious soft hardfork may not do).
Note: a malicious "SHF" is not a SHF at all, but an "evil fork".
> In fact, you could reuse another of the prohibited bits to signal a soft-
> hardfork while distinguishing it from a regular hardfork. And this will also
> serve for old nodes that have not upgraded to the softfork. But, wait,
> if you signal a soft-hardfork with an invalid bit, it's not a
> soft-hardfork anymore, is it? It's simply a hardfork.
Nodes implementing this BIP will see it as a simple hardfork, but will
intentionally provide equivalent behaviour as older nodes which see it as a
soft-hardfork. In other words, all [compatible] hardforks will now behave like
a soft-hardfork without any special DMMS design.
If Bitcoin's eventual hardfork is far enough down the road (such that no nodes
remain from before this BIP are adopted), the SHF design could be safely done
away with entirely. And either way, it makes it easier to resist an un-
consented-to hardfork.
Luke
next prev parent reply other threads:[~2016-12-02 4:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 17:20 Johnson Lau
2016-12-01 18:51 ` Tom Zander
2016-12-01 20:44 ` Luke Dashjr
2016-12-02 1:42 ` Jorge Timón
2016-12-02 4:18 ` Luke Dashjr [this message]
2016-12-02 6:35 ` Jorge Timón
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=201612020418.23011.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/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