📅 Original date posted:2011-09-26
🗒️ Summary of this message: Gavin Andresen discusses the potential for DoS attacks on Bitcoin nodes and the importance of updating to avoid obsolete clients and non-majority block chains.
📝 Original message:On Mon, Sep 26, 2011 at 3:17 PM, Luke-Jr <luke at dashjr.org> wrote:
> + return DoS(10, error("AcceptToMemoryPool() : transaction with out-of-
> bounds SigOpCount"));
> + return DoS(10, error("ConnectInputs() : tried to
> spend coinbase at depth %d", pindexBlock->nHeight - pindex->nHeight));
> These shouldn't be "DoS"'d, or else you open a new DoS when nodes legitimately
> relay such transactions/blocks.
Huh?
So in the future lets suppose we schedule a change to the acceptable
block rules that allows more SigOps in a block, or allows generation
transaction to be spent before 100 confirmations. At that same time,
the DoS rules will be changed.
You cannot "legitimately" relay those blocks without a scheduled
block-chain-split. If a block-chain-split IS scheduled and the rules
change, then denying service to nodes running old, obsolete versions
of bitcoin is the right thing to do-- it is better to "fail hard" and
find it difficult or impossible to connect to the network rather than
continue with an obsolete client and a non-majority block chain.
(and the third DoS in AcceptBlock(): prev block not found is a
"should be impossible" case, because AcceptBlock is only called when
extending the best-block chain).
--
--
Gavin Andresen
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 02:29:12
in reply to nevent1q…hhdx
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 02:29:12Event JSON
{
"id": "8462c555b6ba2412d25cd90ffda835a4453a3f4f37370a0793edf85f7bf614cb",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686104952,
"kind": 1,
"tags": [
[
"e",
"d6d0027f983f7cf39b7bceeaefc2da4fd33248e5b23365297769f7aaa959dad8",
"",
"root"
],
[
"e",
"ca53b085c62e86759ae20b295761d14f5861b6f18993aed296e97d68c941aacf",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2011-09-26\n🗒️ Summary of this message: Gavin Andresen discusses the potential for DoS attacks on Bitcoin nodes and the importance of updating to avoid obsolete clients and non-majority block chains.\n📝 Original message:On Mon, Sep 26, 2011 at 3:17 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e + return DoS(10, error(\"AcceptToMemoryPool() : transaction with out-of-\n\u003e bounds SigOpCount\"));\n\u003e + return DoS(10, error(\"ConnectInputs() : tried to\n\u003e spend coinbase at depth %d\", pindexBlock-\u003enHeight - pindex-\u003enHeight));\n\u003e These shouldn't be \"DoS\"'d, or else you open a new DoS when nodes legitimately\n\u003e relay such transactions/blocks.\n\nHuh?\n\nSo in the future lets suppose we schedule a change to the acceptable\nblock rules that allows more SigOps in a block, or allows generation\ntransaction to be spent before 100 confirmations. At that same time,\nthe DoS rules will be changed.\n\nYou cannot \"legitimately\" relay those blocks without a scheduled\nblock-chain-split. If a block-chain-split IS scheduled and the rules\nchange, then denying service to nodes running old, obsolete versions\nof bitcoin is the right thing to do-- it is better to \"fail hard\" and\nfind it difficult or impossible to connect to the network rather than\ncontinue with an obsolete client and a non-majority block chain.\n\n(and the third DoS in AcceptBlock(): prev block not found is a\n\"should be impossible\" case, because AcceptBlock is only called when\nextending the best-block chain).\n\n-- \n--\nGavin Andresen",
"sig": "6a457bcced63633c98634385eb3d7c8c9a28e8e4e292ec347acdb83107918d21bf98f06d1dfb81373417e2f9a08526abadde9bfdca79dd7baff1914af83e1733"
}