Hardfork bit BIP

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

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

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

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.

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>

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

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.

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.

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.

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

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.

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

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