<oembed><type>rich</type><version>1.0</version><author_name>npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0</author_name><author_url>https://nostr.ae/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-07-21&#xA;📝 Original message:I think it&#39;s not a horrible idea to just add a field into the transaction&#xA;metadata for N_SIG_OPS in the script_sig&#xA;&#xA;It is much simpler in implementation if the concern is complexity (once a&#xA;transaction goes above N_SIG_OPS it could be considered invalid, number&#xA;computed must be equal). It wouldn&#39;t even need to be stored permanently as&#xA;it can be pruned easily and recomputed later (hashes would protect against&#xA;buggy complicated sig counting code).&#xA;&#xA;Furthermore, it would differentiate a branch with different counts well.&#xA;&#xA;&#xA;&#xA;On Wed, Jul 22, 2015 at 2:09 AM, Gavin Andresen via bitcoin-dev &lt;&#xA;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell &lt;gmaxwell at gmail.com&gt;&#xA;&gt; wrote:&#xA;&gt;&#xA;&gt;&gt; On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev&#xA;&gt;&gt; &lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt;&gt; &gt; Mitigate a potential CPU exhaustion denial-of-service attack by limiting&#xA;&gt;&gt; &gt; the maximum size of a transaction included in a block.&#xA;&gt;&gt;&#xA;&gt;&gt; This seems like a fairly indirect approach. The resource being watched&#xA;&gt;&gt; for is not the size (otherwise two transactions for 200k would be&#xA;&gt;&gt; strictly worse than one 200k transactions) but the potential of N^2&#xA;&gt;&gt; costs related to repeated hashing in checksig; which this ignores.&#xA;&gt;&gt;&#xA;&gt;&#xA;&gt; Yes.  The tradeoff is implementation complexity: it is trivial to check&#xA;&gt; transaction size,&#xA;&gt; not as trivial to count signature operations, because&#xA;&gt; number-of-bytes-in-transaction&#xA;&gt; doesn&#39;t require any context.&#xA;&gt;&#xA;&gt; But I would REALLY hate myself if in ten years a future version of me was&#xA;&gt; struggling to&#xA;&gt; get consensus to move away from some stupid 100,000 byte transaction size&#xA;&gt; limit&#xA;&gt; I imposed to mitigate a potential DoS attack.&#xA;&gt;&#xA;&gt; So I agree, a limit on sigops is the right way to go. And if that is being&#xA;&gt; changed,&#xA;&gt; might as well accurately count exactly how many sigops a transaction&#xA;&gt; actually&#xA;&gt; requires to be validated...&#xA;&gt;&#xA;&gt; --&#xA;&gt; --&#xA;&gt; Gavin Andresen&#xA;&gt;&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/6ff84cc8/attachment-0001.html&gt;</html></oembed>