{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-21\n📝 Original message:On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Mitigate a potential CPU exhaustion denial-of-service attack by limiting\n\u003e \u003e the maximum size of a transaction included in a block.\n\u003e\n\u003e This seems like a fairly indirect approach. The resource being watched\n\u003e for is not the size (otherwise two transactions for 200k would be\n\u003e strictly worse than one 200k transactions) but the potential of N^2\n\u003e costs related to repeated hashing in checksig; which this ignores.\n\u003e\n\nYes.  The tradeoff is implementation complexity: it is trivial to check\ntransaction size,\nnot as trivial to count signature operations, because\nnumber-of-bytes-in-transaction\ndoesn't require any context.\n\nBut I would REALLY hate myself if in ten years a future version of me was\nstruggling to\nget consensus to move away from some stupid 100,000 byte transaction size\nlimit\nI imposed to mitigate a potential DoS attack.\n\nSo I agree, a limit on sigops is the right way to go. And if that is being\nchanged,\nmight as well accurately count exactly how many sigops a transaction\nactually\nrequires to be validated...\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/258a0bc6/attachment.html\u003e"}