{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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."}