rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-07-21 📝 Original message:On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote: > 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. > Yes. The tradeoff is implementation complexity: it is trivial to check transaction size, not as trivial to count signature operations, because number-of-bytes-in-transaction doesn't require any context. But I would REALLY hate myself if in ten years a future version of me was struggling to get consensus to move away from some stupid 100,000 byte transaction size limit I imposed to mitigate a potential DoS attack. So I agree, a limit on sigops is the right way to go. And if that is being changed, might as well accurately count exactly how many sigops a transaction actually requires to be validated... -- -- Gavin Andresen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/258a0bc6/attachment.html>