[bitcoin-dev] Hardfork bit BIP

[bitcoin-dev] Hardfork bit BIP

[jl2012]

[-- Attachment #1: Type: text/plain, Size: 7228 bytes --]

 

https://github.com/bitcoin/bips/pull/317

ABSTRACT

This document specifies a proposed change to the semantics of the sign
bit of the "version" field in Bitcoin block headers, as a mechanism to
indicate a hardfork is deployed. It alleviates certain risks related to
a hardfork by introducing an explicit "point of no return" in the
blockchain. This is a general mechanism which should be employed by any
planned hardfork in the future. 

 [1]MOTIVATION

Hardforks in Bitcoin are usually considered as difficult and risky,
because: 

 	* Hardforks require not only support of miners, but also, most
importantly, supermajority support of the Bitcoin economy. As a result,
softfork deployment mechanisms described in BIP 34 [2] or BIP 9 [3] are
not enough for introducing hardforks safely.
 	* Full nodes and SPV nodes following original consensus rules may not
be aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued legacy tokens.
 	* In the case which the original consensus rules are also valid under
the new consensus rules, users following the new chain may unexpectedly
reorg back to the original chain if it grows faster than the new one.
People may find their confirmed transactions becoming unconfirmed and
lose money.

The first issue involves soliciting support for a hardfork proposal,
which is more a political topic than a technical one. This proposal aims
at alleviating the risks related to the second and third issues. It
should be employed by any planned hardfork in the future.

 [4]DEFINITIONS

See BIP99 [5] 

 [6]SPECIFICATION

HARDFORK BIT The sign bit in nVersion is defined as the hardfork bit.
Currently, blocks with this header bit setting to 1 are invalid, since
BIP65 [7] interprets nVersion as a signed number and requires it to be ≥
4. Among the 640 bits in the block header, this is the only one which is
fixed and serves no purpose, and therefore the best way to indicate the
deployment of a hardfork. 

FLAG BLOCK Any planned hardfork must have one and only one flag block
which is the "point of no return". To ensure monotonicity, flag block
should be determined by block height, or as the first block with
GetMedianTimePast() greater than a threshold. Other mechanisms could be
difficult for SPV nodes to follow. The height/time threshold could be a
predetermined value or relative to other events (e.g. 10000 blocks / 100
days after 95% of miner support). The exact mechanism is out of the
scope of this BIP. No matter what mechanism is used, the threshold is
consensus critical. It must be publicly verifiable with only blockchain
data, and preferably SPV-friendly (i.e. verifiable with block headers
only, without downloading any transaction). 

Flag block is constructed in a way that nodes with the original
consensus rules must reject. On the other hand, nodes with the new
consensus rules must reject a block if it is not a flag block while it
is supposed to be. To achieve these goals, the flag block must 

 	* have the hardfork bit setting to 1, and
 	* follow any other rules required by the hardfork

If these conditions are not fully satisfied, upgraded nodes shall reject
the block.

The hardfork bit must be turned off in the successors of the flag block,
until the deployment of the next hardfork. 

Although a hardfork is officially deployed when flag block is generated,
the exact behavioural change is out of the scope of this BIP. For
example, a hardfork may not be fully active until certain time after the
flag block. 

CONCURRENT HARDFORK PROPOSALS To avoid confusion and unexpected
behaviour, a flag block should normally signify the deployment of only
one hardfork. Therefore, a hardfork proposal has to make sure that its
flag block threshold is not clashing with other ongoing hardfork
proposals. 

In the case that the version bits mechanism is used in deploying a
hardfork, height of the flag block should take a value of32N + B, where
N is a positive integer and B is the position of bit B defined in BIP9
[8]. This guarantees that no clash may happen with another hardfork
proposal using BIP9. 

UNCONTROVERSIAL SUBTLE HARDFORKS Hardforks may sometimes be totally
uncontroversial and make barely noticeable change (BIP50 [9], for
example). In such cases, the use of hardfork bit may not be needed as it
may cause unnecessary disruption. The risk and benefit should be
evaluated case-by-case. 

AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
found on the network, full nodes and SPV nodes should alert their users
and/or stop accepting/sending transactions. It should be noted that the
warning system could become a denial-of-service vector if the attacker
is willing to give up the block reward. Therefore, the warning may be
issued only if a few blocks are built on top of the flag block in a
reasonable time frame. This will in turn increase the risk in case of a
real planned hardfork so it is up to the wallet programmers to decide
the optimal strategy. Human warning system (e.g. the emergency alert
system in Bitcoin Core) could fill the gap. 

 [10]COMPATIBILITY

As a mechanism to indicate hardfork deployment, this BIP breaks backward
compatibility intentionally. However, without further changes in the
block header format, full nodes and SPV nodes could still verify the
Proof-of-Work of a flag block and its successors. 

HARDFORK INVOLVING CHANGE IN BLOCK HEADER FORMAT If a hardfork involves
a new block header format, the original format should still be used for
the flag block and a reasonable period afterwards, to make sure existing
nodes realize that an unknown hardfork has been deployed. 

VERSION BITS This proposal is also compatible with the BIP9. The version
bits mechanism could be employed to measure miner support towards a
hardfork proposal, and to determine the height or time threshold of the
flag block. Also, miners of the flag block may still cast votes for
other concurrent softfork or hardfork proposals as normal. 

POINT OF NO RETURN After the flag block is generated, a miner may
support either the original rules or the new rules, but not both. It is
not possible for miners in one fork to attack or overtake the other fork
without giving up the mining reward of their preferred fork. 

 [11]COPYRIGHT

This document is placed in the public domain. 

Links:
------
[1]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#motivation
[2] https://github.com/jl2012/bips/blob/hardforkbit/bip-0034.mediawiki
[3] https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki
[4]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#definitions
[5] https://github.com/jl2012/bips/blob/hardforkbit/bip-0099.mediawiki
[6]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#specification
[7] https://github.com/jl2012/bips/blob/hardforkbit/bip-0065.mediawiki
[8]
https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki#Mechanism
[9] https://github.com/jl2012/bips/blob/hardforkbit/bip-0050.mediawiki
[10]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#compatibility
[11]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#copyright

[-- Attachment #2: Type: text/html, Size: 8506 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

This BIP is unnecessary, in my opinion.

I'm going to take issue with items (2) and (3) that are the motivation for
this BIP:

" 2. Full nodes and SPV nodes following original consensus rules may not be
aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued legacy tokens."

If a hardfork is deployed by increasing the version number in blocks (as is
done for soft forks), then there is no risk-- Full and SPV nodes should
notice that they are seeing up-version blocks and warn the user that they
are using obsolete software.

It doesn't matter if the software is obsolete because of hard or soft fork,
the difference in risks between those two cases will not be understood by
the typical full node or SPV node user.

" 3. In the case which the original consensus rules are also valid under
the new consensus rules, users following the new chain may unexpectedly
reorg back to the original chain if it grows faster than the new one.
People may find their confirmed transactions becoming unconfirmed and lose
money."

If a hard or soft fork uses a 'grace period' (as described in BIP 9 or BIP
101) then there is essentially no risk that a reorg will happen past the
triggering block. A block-chain re-org of two thousand or more blocks on
the main Bitcoin chain is unthinkable-- the economic chaos would be
massive, and the reaction to such a drastic (and extremely unlikely) event
would certainly be a hastily imposed checkpoint to get everybody back onto
the chain that everybody was using for economic transactions.


Since I don't agree with the motivations for this BIP, I don't think the
proposed mechanism (a negative-version-number-block) is necessary. And
since it would simply add more consensus-level code, I believe the
keep-it-simple principle applies.


-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2941 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[jl2012]

Gavin Andresen 於 2016-02-04 12:36 寫到:
> This BIP is unnecessary, in my opinion.
> 
> I'm going to take issue with items (2) and (3) that are the motivation
> for this BIP:
> 
> " 2. Full nodes and SPV nodes following original consensus rules may
> not be aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens."
> 
> If a hardfork is deployed by increasing the version number in blocks
> (as is done for soft forks), then there is no risk-- Full and SPV
> nodes should notice that they are seeing up-version blocks and warn
> the user that they are using obsolete software.
> 
> It doesn't matter if the software is obsolete because of hard or soft
> fork, the difference in risks between those two cases will not be
> understood by the typical full node or SPV node user.

Thanks for your comments.

In the case of a softfork, as long as an user waits for a few 
confirmations, the risk of money loss is very low. In the worst case 
they run a full node with SPV security. In the case of a hardfork, the 
consequence of failing to upgrade to the economic majority fork *is* 
fatal, even if an user waits for 1000 confirmations. Not to mention the 
risk of having 2 economically active forks. That's why wallets should 
STOP accepting and sending tx after a hardfork bit is detected and wait 
for users' instructions.

> " 3. In the case which the original consensus rules are also valid
> under the new consensus rules, users following the new chain may
> unexpectedly reorg back to the original chain if it grows faster than
> the new one. People may find their confirmed transactions becoming
> unconfirmed and lose money."
> 
> If a hard or soft fork uses a 'grace period' (as described in BIP 9 or
> BIP 101) then there is essentially no risk that a reorg will happen
> past the triggering block. A block-chain re-org of two thousand or
> more blocks on the main Bitcoin chain is unthinkable-- the economic
> chaos would be massive, and the reaction to such a drastic (and
> extremely unlikely) event would certainly be a hastily imposed
> checkpoint to get everybody back onto the chain that everybody was
> using for economic transactions.

No, the "triggering block" you mentioned is NOT where the hardfork 
starts. Using BIP101 as an example, the hardfork starts when the first 
 >1MB is mined. For people who failed to upgrade, the "grace period" is always zero, which is the moment they realize a hardfork.


> Since I don't agree with the motivations for this BIP, I don't think
> the proposed mechanism (a negative-version-number-block) is necessary.
> And since it would simply add more consensus-level code, I believe the
> keep-it-simple principle applies.
> 
> --
> 
> --
> Gavin Andresen

Re: [bitcoin-dev] Hardfork bit BIP

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Thu, Feb 4, 2016 at 11:56 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> past the triggering block. A block-chain re-org of two thousand or
>> more blocks on the main Bitcoin chain is unthinkable-- the economic
>> chaos would be massive, and the reaction to such a drastic (and
>> extremely unlikely) event would certainly be a hastily imposed
>> checkpoint to get everybody back onto the chain that everybody was
>> using for economic transactions.
>>
>
> No, the "triggering block" you mentioned is NOT where the hardfork starts.
> Using BIP101 as an example, the hardfork starts when the first >1MB is
> mined. For people who failed to upgrade, the "grace period" is always zero,
> which is the moment they realize a hardfork.
>

Are there any plans written down anywhere about the "hastily imposed
checkpoint" scenario? As far as I know, we would have to check-point on
both blockchains because of the way that hard-forks work (creating two
separate chains and/or networks). Nothing about this should be an
"emergency", we have all the time in the world to prepare a safe and
responsible way to upgrade the network without unilaterally
declaring obsolescence.

- Bryan
http://heybryan.org/
1 512 203 0507

[-- Attachment #2: Type: text/html, Size: 1995 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Thu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> No, the "triggering block" you mentioned is NOT where the hardfork starts.
> Using BIP101 as an example, the hardfork starts when the first >1MB is
> mined. For people who failed to upgrade, the "grace period" is always zero,
> which is the moment they realize a hardfork.


Clients have to update in some way to get the benefit of this right?

An SPV client which fully validated the header chain would simply reject
the hard forking header.  Last time I checked, the Bitcoinj SPV wallet
ignored the version bits, and just followed the longest chain.  Is that
still the case?

In fact, does Core enforce the 95% rule for the soft-forks before checking
for long forks?  I am assuming that it happens when checking headers rather
than when checking full blocks.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[-- Attachment #2: Type: text/html, Size: 2025 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Thu, Feb 04, 2016 at 12:36:06PM -0500, Gavin Andresen via bitcoin-dev wrote:
> This BIP is unnecessary, in my opinion.
> 
> I'm going to take issue with items (2) and (3) that are the motivation for
> this BIP:
> 
> " 2. Full nodes and SPV nodes following original consensus rules may not be
> aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens."
> 
> If a hardfork is deployed by increasing the version number in blocks (as is
> done for soft forks), then there is no risk-- Full and SPV nodes should
> notice that they are seeing up-version blocks and warn the user that they
> are using obsolete software.

1) There is no way to guarantee that nodes will see those blocks, and
the current network behavior works against such guarantees even in the
non-adversarial case.

2) I know of no currently deployed SPV wallet software that warns users
about unknown block versions anyway.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[Luke Dashjr]

On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> ABSTRACT
> 
> This document specifies a proposed change to the semantics of the sign
> bit of the "version" field in Bitcoin block headers, as a mechanism to
> indicate a hardfork is deployed.

Disagree with treating the "version" field as a number, in BIP 9 or this BIP 
which reinterpret it as a bit vector.

> Among the 640 bits in the block header, this is the only one which is
> fixed and serves no purpose, ...

Minor nit (not relevant to actual proposal): This is not true. There are over 
32 other bits (part of the "previous-block" field) which also serve no 
purpose.

> FLAG BLOCK Any planned hardfork must have one and only one flag block
> which is the "point of no return". To ensure monotonicity, flag block
> should be determined by block height, or as the first block with
> GetMedianTimePast() greater than a threshold. Other mechanisms could be
> difficult for SPV nodes to follow. The height/time threshold could be a
> predetermined value or relative to other events (e.g. 10000 blocks / 100
> days after 95% of miner support). The exact mechanism is out of the
> scope of this BIP. No matter what mechanism is used, the threshold is
> consensus critical. It must be publicly verifiable with only blockchain
> data, and preferably SPV-friendly (i.e. verifiable with block headers
> only, without downloading any transaction).

With the current codebase, it is significantly easier to trigger on the block 
timestamp rather than its height or median-time-past. Using either of the 
latter would require refactoring of CBlockIndex. As a hard-fork, even if the 
rules are ineffective for a few blocks following the forking point, using the 
hardfork version bit in this BIP would still ensure a clean break. While I 
agree that median-time-past and height are superior methods that ought to be 
used for hardforks, an emergency hardfork may need to avoid them for 
simplicity, and I don't think they need to be mandated as such in this BIP.

> Although a hardfork is officially deployed when flag block is generated, ...

I would avoid implying the hardfork can be "officially deployed" without 
actual adoption.

> AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
> found on the network, full nodes and SPV nodes should alert their users
> and/or stop accepting/sending transactions. It should be noted that the
> warning system could become a denial-of-service vector if the attacker
> is willing to give up the block reward. Therefore, the warning may be
> issued only if a few blocks are built on top of the flag block in a
> reasonable time frame. This will in turn increase the risk in case of a
> real planned hardfork so it is up to the wallet programmers to decide
> the optimal strategy. Human warning system (e.g. the emergency alert
> system in Bitcoin Core) could fill the gap.

This seems vulnerable to DoS attacks by rejected hardforks.

> VERSION BITS This proposal is also compatible with the BIP9. The version
> bits mechanism could be employed to measure miner support towards a
> hardfork proposal, and to determine the height or time threshold of the
> flag block. Also, miners of the flag block may still cast votes for
> other concurrent softfork or hardfork proposals as normal.

Rather not imply BIP 9 should be used for hardforks, or that miners have any 
voice in the decision. This is already a serious misconception.

> POINT OF NO RETURN After the flag block is generated, a miner may
> support either the original rules or the new rules, but not both. It is
> not possible for miners in one fork to attack or overtake the other fork
> without giving up the mining reward of their preferred fork.

This is not actually desirable, and would suggest a possible reason *not* to 
comply with this BIP. A legitimate hardfork would never have two continued 
sets of rules for miners to choose from.

Luke

Re: [bitcoin-dev] Hardfork bit BIP

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 4526 bytes --]

On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> > ABSTRACT
> >
> > This document specifies a proposed change to the semantics of the sign
> > bit of the "version" field in Bitcoin block headers, as a mechanism to
> > indicate a hardfork is deployed.
>
> Disagree with treating the "version" field as a number, in BIP 9 or this
BIP
> which reinterpret it as a bit vector.

I don't interpret this as "treating version bits as a number" it is just
being explained which bit we're talking about. Could you propose some
concrete rephrasing instead of leaving the task of somehow solving this
vague and subtle concern to the author?

> > FLAG BLOCK Any planned hardfork must have one and only one flag block
> > which is the "point of no return". To ensure monotonicity, flag block
> > should be determined by block height, or as the first block with
> > GetMedianTimePast() greater than a threshold. Other mechanisms could be
> > difficult for SPV nodes to follow. The height/time threshold could be a
> > predetermined value or relative to other events (e.g. 10000 blocks / 100
> > days after 95% of miner support). The exact mechanism is out of the
> > scope of this BIP. No matter what mechanism is used, the threshold is
> > consensus critical. It must be publicly verifiable with only blockchain
> > data, and preferably SPV-friendly (i.e. verifiable with block headers
> > only, without downloading any transaction).
>
> With the current codebase, it is significantly easier to trigger on the
block
> timestamp rather than its height or median-time-past. Using either of the
> latter would require refactoring of CBlockIndex. As a hard-fork, even if
the
> rules are ineffective for a few blocks following the forking point, using
the
> hardfork version bit in this BIP would still ensure a clean break. While I
> agree that median-time-past and height are superior methods that ought to
be
> used for hardforks, an emergency hardfork may need to avoid them for
> simplicity, and I don't think they need to be mandated as such in this
BIP.

I very much disagree with "significant" and in any case it depends on the
hardfork: the changes required can still be quite minimal in all cases and
it should never be a problem, even for emergency hardforks. In emergency,
we could for example just a new global (we have many already anyway),
although activeChain.tip () is already there and one can simply get the
last height or median time from there.

> > VERSION BITS This proposal is also compatible with the BIP9. The version
> > bits mechanism could be employed to measure miner support towards a
> > hardfork proposal, and to determine the height or time threshold of the
> > flag block. Also, miners of the flag block may still cast votes for
> > other concurrent softfork or hardfork proposals as normal.
>
> Rather not imply BIP 9 should be used for hardforks, or that miners have
any
> voice in the decision. This is already a serious misconception.

This is consistent with bip99, which recommends bip9 for deploying
uncontroversial hardforks.

> > POINT OF NO RETURN After the flag block is generated, a miner may
> > support either the original rules or the new rules, but not both. It is
> > not possible for miners in one fork to attack or overtake the other fork
> > without giving up the mining reward of their preferred fork.
>
> This is not actually desirable, and would suggest a possible reason *not*
to
> comply with this BIP. A legitimate hardfork would never have two continued
> sets of rules for miners to choose from.

Controversial hardforks (as defined bip9) always have the potential to
create two chains that survive for unbounded amounts of time (maybe
forever) as discussed in one of the few threads of the bitcoin discuss
mailing list.
Of course, BIP99 cannot say anything general about the "legitimacy" of all
controversial hardforks since ASIC-reset hardforks, for example, are
controversial hardforks by definition in the context of bip99 (and the
definitions in bip99 seem to apply to this bip). BIP99 can only warn about
the dangers and risks of controversial hardforks but at some point (let's
hope never) a controversial hardfork may be required to save the system
from some evil (say, evil miners blacklisting via softforking out the
miners that don't  blacklist or something) and that controversial hardfork
would be legitimate (at least to the eyes of some).

[-- Attachment #2: Type: text/html, Size: 5258 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[Gregory Maxwell]

On Thu, Feb 4, 2016 at 5:14 PM, jl2012 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> https://github.com/bitcoin/bips/pull/317

I think this is a good idea, and I've independently proposed it in the past.

I agree with most of luke's language nitpicks.

It could, however, be pointed out that the version number flag is not
sufficient in the deployed network, because many clients also do not
validate the version field, due to a disinterest in security great
enough to not implement anything around height-in-coinbase.

So to fully achieve the intended effect using the highest bit of prev
would currently be much more effective.

Re: [bitcoin-dev] Hardfork bit BIP

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

It is always possible I'm being dense, but I still don't understand how
this proposal makes a chain-forking situation better for anybody.

If there are SPV clients that don't pay attention to versions in block
headers, then setting the block version negative doesn't directly help
them, they will ignore it in any case.

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).

If the worry is not-upgraded SPV clients connecting to the old,
not-upgraded full nodes, I don't see how this proposed BIP helps.

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.

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.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1711 bytes --]

Re: [bitcoin-dev] Hardfork bit BIP

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Hardfork bit BIP

[jl2012]

From: Gavin Andresen [mailto:gavinandresen@gmail.com] 
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell <greg@xiph.org>
Cc: jl2012 <jl2012@xbt.hk>; Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP

>It is always possible I'm being dense, but I still don't understand how this proposal makes a chain-forking situation better for anybody.

>If there are SPV clients that don't pay attention to versions in block headers, then setting the block version negative doesn't directly help them, they will ignore it in any case.

It is unfortunate SPV clients are not following that. However, they SHOULD follow that. It becomes a self fulfilling prophecy if we decide not to do that if SPV are not following that.

>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).

It will distinguish between a planned hardfork and an accidental hardfork, and full nodes may react differently. Particularly, a planned unknown hardfork is a strong indication that the original chain has become economic minority and the non-upgraded full node should stop accepting incoming tx immediately.

>If the worry is not-upgraded SPV clients connecting to the old, not-upgraded full nodes, I don't see how this proposed BIP helps.

Same for not-upgraded full nodes following not-upgraded full nodes. Anyway, the header with enough PoW should still be propagated.

>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.

Normal version number only suggests softforks, which is usually not a concern for SPV clients. An unknown hardfork is a completely different story as the values of the forks are completely unknown.

>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.

Yes, they should.

-- 
--
Gavin Andresen

Re: [bitcoin-dev] Hardfork bit BIP

[Gavin]

> On Feb 7, 2016, at 2:27 PM, <jl2012@xbt.hk> <jl2012@xbt.hk> wrote:
> 
> Normal version number only suggests softforks, which is usually not a concern for SPV clients.

Soft forks affect the security of low-confirmation (zero or one) transactions sent to SPV wallets even more than hard forks, and because many users and businesses choose convenience over airtight security I would argue transaction validation rule changes are a VERY big concern for lightweight clients.

Re: [bitcoin-dev] Hardfork bit BIP

[Anthony Towns]

On Sun, Feb 07, 2016 at 03:20:27PM -0500, Gavin via bitcoin-dev wrote:
> > On Feb 7, 2016, at 2:27 PM, <jl2012@xbt.hk> <jl2012@xbt.hk> wrote:
> > Normal version number only suggests softforks, which is usually not a concern for SPV clients.
> Soft forks affect the security of low-confirmation (zero or one) transactions sent to SPV wallets even more than hard forks,

This isn't true for soft-forks that only forbid transactions that would
already be rejected for forwarding and mining due to being non-standard.

> and because many users and businesses choose convenience over airtight security I would argue transaction validation rule changes are a VERY big concern for lightweight clients.

I agree on that point; but ensuring soft-forks only affect non-standard
transactions already addresses that concern in every way I've been able
to discover.

Cheers,
aj