From: Gavin Andresen [mailto:gavinandre...@gmail.com] Sent: Friday, 5 February, 2016 06:16 To: Gregory Maxwell <g...@xiph.org> Cc: jl2012 <jl2...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
