<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <span dir="ltr">&lt;<a href="mailto:gmaxwell@gmail.com" target="_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev<br>
&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Mitigate a potential CPU exhaustion denial-of-service attack by limiting<br>
&gt; the maximum size of a transaction included in a block.<br>
<br>
</span>This seems like a fairly indirect approach. The resource being watched<br>
for is not the size (otherwise two transactions for 200k would be<br>
strictly worse than one 200k transactions) but the potential of N^2<br>
costs related to repeated hashing in checksig; which this ignores.<br></blockquote><div><br></div><div>To get a feeling for the implementation complexity / correctness tradeoff,</div><div>I implemented changes to Core to count exactly how many signature operations</div><div>are performed and how many bytes are hashed to compute sighashes:</div><div>  <a href="https://github.com/gavinandresen/bitcoin-git/commit/08ecd6f67d977271faa92bc1890b8f94b15c2792">https://github.com/gavinandresen/bitcoin-git/commit/08ecd6f67d977271faa92bc1890b8f94b15c2792</a></div><div><br></div><div>I haven&#39;t benchmarked how much keeping track of the counts affects performance (but I expect</div><div>it to be minimal compared to ECDSA signature validation, accessing inputs from the UTXO, etc).</div><div><br></div><div>I like the idea of a consensus rule that directly addresses the attack-- e.g. &quot;validating</div><div>a transaction must not require more than X megabytes hashed to compute signature hashes.&quot;</div><div>(or: &quot;validating a block must not require more than X megabytes hashed...&quot; which is</div><div>more symmetric with the current &quot;maximum number of sigops allowed per block&quot;)</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thinking about this and looking at block 364,292, I think I see a simple optimization that would</div><div class="gmail_extra">speed up validation for transactions with lots of inputs:  use SIGHASH_ANYONECANPAY</div><div class="gmail_extra">for all of the inputs instead of SIGHASH_ALL.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(which would make the transaction malleable-- if that&#39;s a concern, then make one of the inputs</div><div class="gmail_extra">SIGHASH_ALL and the rest SIGHASH_ANYONECANPAY-- I think this is a change that</div><div class="gmail_extra">should be made to Core and other wallets should make).</div><div class="gmail_extra"><br></div><div class="gmail_extra">---</div><div class="gmail_extra"><br></div><div class="gmail_extra">I&#39;d like to hear from maintainers of other full implementations: how hard would it be for you</div><div class="gmail_extra">to keep track of the number of bytes hashed to validate a transaction or block, and use</div><div class="gmail_extra">it as a consensus rule?</div><div><br></div>-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div><div class="gmail_signature"><br></div>
</div></div>