From: "Jorge Timón" <jtimon@jtimon•cc>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Date: Fri, 5 Feb 2016 10:58:36 +0100 [thread overview]
Message-ID: <CABm2gDpPZ6gcUncM3opPYft6+g=MH35xvboRfLaitju9DDyCxg@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]
Concept ACK. I've been talking about adding this to BIP99 since before
scaling bitcoin Hong Kong, so it will be nice to have a BIP to just point
to. Also I hadn't thought about concurrent deployment of 2 hardforks, nice.
On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> If the worry is full nodes that are not upgraded, then a block with a
negative version number will, indeed, fork them off the the chain, in
exactly the same way a block with new hard-forking consensus rules would.
And with the same consequences (if there is any hashpower not paying
attention, then a worthless minority chain might continue on with the old
rules).
Additionally, a warning or special error could be thrown when a block is
rejected due to the hardfork bit being activated.
> I think a much better idea than this proposed BIP would be a BIP that
recommends that SPV clients to pay attention to block version numbers in
the headers that they download, and warn if there is a soft OR hard fork
that they don't know about.
Although I agree this PR should include such warning/error recommendations,
SPV nodes can't tell whether a change is a hardfork or a softfork just by
looking at the version bits, even in the case of uncontroversial hardforks
deployed with bip9 as recommended by bip99. For controversial hardforks
where bip9 should NOT be used for deployment, setting the hardfork bit is
even more important.
> It is also a very good idea for SPV clients to pay attention to
timestamps in the block headers that the receive, and to warn if blocks
were generated either much slower or faster than statistically likely.
Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in
general.
This seems out of the scope of this PR.
[-- Attachment #2: Type: text/html, Size: 2036 bytes --]
next prev parent reply other threads:[~2016-02-05 9:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 17:14 jl2012
2016-02-04 17:36 ` Gavin Andresen
2016-02-04 17:56 ` jl2012
2016-02-04 18:00 ` Bryan Bishop
2016-02-04 18:24 ` Tier Nolan
2016-02-04 18:19 ` Peter Todd
2016-02-04 18:29 ` Luke Dashjr
2016-02-05 10:20 ` Jorge Timón
2016-02-04 19:36 ` Gregory Maxwell
2016-02-04 22:15 ` Gavin Andresen
2016-02-05 9:58 ` Jorge Timón [this message]
2016-02-07 19:27 ` jl2012
2016-02-07 20:20 ` Gavin
2016-02-08 2:44 ` Anthony Towns
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='CABm2gDpPZ6gcUncM3opPYft6+g=MH35xvboRfLaitju9DDyCxg@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@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