📅 Original date posted:2015-07-20
📝 Original message:On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mitigate a potential CPU exhaustion denial-of-service attack by limiting
> the maximum size of a transaction included in a block.
This seems like a fairly indirect approach. The resource being watched
for is not the size (otherwise two transactions for 200k would be
strictly worse than one 200k transactions) but the potential of N^2
costs related to repeated hashing in checksig; which this ignores.
The cost of the indirection is forclosing future applications which
involve larger signatures but have no quadratic component and are thus
fast to verify-- or requring yet another hard fork to remove the
limit, or a kludgy soft fork that splits the same data across two
"transactions" which get processed as a unit... all would be
unfortunate.
Alternative 1 sounds more attractive to be for this reason as it's more direct.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:42:40
in reply to nevent1q…dhqh
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:42:40Event JSON
{
"id": "7f3ad04463a7a48c843d9adea5c2843103d7c25fce0758a2a4f78083138234e3",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686152560,
"kind": 1,
"tags": [
[
"e",
"4db225e616a06087530c4b30cfa43f47ac26331621975d63e97abbdb75e7e0fa",
"",
"root"
],
[
"e",
"ea7bb0fe2262f08a4bf3c3ddda14ea441874a6853169c978982c4b66434a0f78",
"",
"reply"
],
[
"p",
"787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129"
]
],
"content": "📅 Original date posted:2015-07-20\n📝 Original message:On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Mitigate a potential CPU exhaustion denial-of-service attack by limiting\n\u003e the maximum size of a transaction included in a block.\n\nThis seems like a fairly indirect approach. The resource being watched\nfor is not the size (otherwise two transactions for 200k would be\nstrictly worse than one 200k transactions) but the potential of N^2\ncosts related to repeated hashing in checksig; which this ignores.\n\nThe cost of the indirection is forclosing future applications which\ninvolve larger signatures but have no quadratic component and are thus\nfast to verify-- or requring yet another hard fork to remove the\nlimit, or a kludgy soft fork that splits the same data across two\n\"transactions\" which get processed as a unit... all would be\nunfortunate.\n\nAlternative 1 sounds more attractive to be for this reason as it's more direct.",
"sig": "81d1fa77f7c6868079f2c1fb59fef0350b6b0dcefa089fcfcf5114259279dfceea9c49dbe9bf138ce2b89a540e00d69f616775d86afbf426bf7fcb28f45bae2b"
}