📅 Original date posted:2016-02-07
📝 Original message:From: Gavin Andresen [mailto:gavinandresen at gmail.com]
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell <greg at xiph.org>
Cc: jl2012 <jl2012 at xbt.hk>; Bitcoin Dev <bitcoin-dev at 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
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 19:48:32
in reply to nevent1q…gj0g
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 19:48:32Event JSON
{
"id": "838b41d8a82145fa9e446d946a87822978b4183440a9e716ad2275736532f938",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686160112,
"kind": 1,
"tags": [
[
"e",
"225bd65196e0b92a41e9e14e274e0ca016fd5fd1fb7ff068f7d16d873098abfe",
"",
"root"
],
[
"e",
"d5bff6ab5444c1642015f4e51d59b60fd2bbd04d68a51d619820d61836117dc8",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2016-02-07\n📝 Original message:From: Gavin Andresen [mailto:gavinandresen at gmail.com] \nSent: Friday, 5 February, 2016 06:16\nTo: Gregory Maxwell \u003cgreg at xiph.org\u003e\nCc: jl2012 \u003cjl2012 at xbt.hk\u003e; Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSubject: Re: [bitcoin-dev] Hardfork bit BIP\n\n\u003eIt is always possible I'm being dense, but I still don't understand how this proposal makes a chain-forking situation better for anybody.\n\n\u003eIf 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.\n\nIt 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.\n\n\u003eIf 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).\n\nIt 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.\n\n\u003eIf the worry is not-upgraded SPV clients connecting to the old, not-upgraded full nodes, I don't see how this proposed BIP helps.\n\nSame for not-upgraded full nodes following not-upgraded full nodes. Anyway, the header with enough PoW should still be propagated.\n\n\u003eI 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.\n\nNormal 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.\n\n\u003eIt 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.\n\nYes, they should.\n\n-- \n--\nGavin Andresen",
"sig": "0ddf166088a8cbf317d6c0261da1a67884bcdb645619263b5516f6799a89e51ca67f69c5518bb48c73b2381d48afb6423384d6792109c469e9c1816a79a94660"
}