š
Original date posted:2016-02-04
š Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/58242583/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4ā¦d44kw
2023-06-07 17:48:32
in reply to nevent1qā¦7wt0
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 17:48:32Event JSON
{
"id": "365d4f412ebe18594b4a68907950b6d20716227106c92f43483374ec1c571e18",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686160112,
"kind": 1,
"tags": [
[
"e",
"225bd65196e0b92a41e9e14e274e0ca016fd5fd1fb7ff068f7d16d873098abfe",
"",
"root"
],
[
"e",
"09bea480dca75822ffc643540ac6920308ee43f4f931c54f95c3cf8db3345cee",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "š
Original date posted:2016-02-04\nš Original message:It is always possible I'm being dense, but I still don't understand how\nthis proposal makes a chain-forking situation better for anybody.\n\nIf there are SPV clients that don't pay attention to versions in block\nheaders, then setting the block version negative doesn't directly help\nthem, they will ignore it in any case.\n\nIf the worry is full nodes that are not upgraded, then a block with a\nnegative version number will, indeed, fork them off the the chain, in\nexactly the same way a block with new hard-forking consensus rules would.\nAnd with the same consequences (if there is any hashpower not paying\nattention, then a worthless minority chain might continue on with the old\nrules).\n\nIf the worry is not-upgraded SPV clients connecting to the old,\nnot-upgraded full nodes, I don't see how this proposed BIP helps.\n\nI think a much better idea than this proposed BIP would be a BIP that\nrecommends that SPV clients to pay attention to block version numbers in\nthe headers that they download, and warn if there is a soft OR hard fork\nthat they don't know about.\n\nIt is also a very good idea for SPV clients to pay attention to timestamps\nin the block headers that the receive, and to warn if blocks were generated\neither much slower or faster than statistically likely. Doing that (as\nBitcoin Core already does) will mitigate Sybil attacks in general.\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/58242583/attachment.html\u003e",
"sig": "970457241281a1b575a05a5d3c789267fc40b4789acd2e5a3c17136cf26287016b97d69f848f570908e69da38e68601573612e80ef83e60c422c3c28f1792ed2"
}