<div dir="ltr"><div>Draft BIP to prevent a potential CPU exhaustion attack if a significantly larger maximum blocksize is adopted:</div><div><br></div><div> Title: Limit maximum transaction size<br></div><div> Author: Gavin Andresen <<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>></div><div> Status: Draft</div><div> Type: Standards Track</div><div> Created: 2015-07-17</div><div><br></div><div>==Abstract==</div><div><br></div><div>Mitigate a potential CPU exhaustion denial-of-service attack by limiting</div><div>the maximum size of a transaction included in a block.</div><div><br></div><div>==Motivation==</div><div><br></div><div>Sergio Demian Lerner reported that a maliciously constructed block could</div><div>take several minutes to validate, due to the way signature hashes are</div><div>computed for OP_CHECKSIG/OP_CHECKMULTISIG ([[<a href="https://bitcointalk.org/?topic=140078|CVE-2013-2292]]">https://bitcointalk.org/?topic=140078|CVE-2013-2292]]</a>).</div><div>Each signature validation can require hashing most of the transaction's</div><div>bytes, resulting in O(s*b) scaling (where n is the number of signature</div><div>operations and m is the number of bytes in the transaction, excluding</div><div>signatures). If there are no limits on n or m the result is O(n^2) scaling.</div><div><br></div><div>This potential attack was mitigated by changing the default relay and</div><div>mining policies so transactions larger than 100,000 bytes were not</div><div>relayed across the network or included in blocks. However, a miner</div><div>not following the default policy could choose to include a</div><div>transaction that filled the entire one-megaybte block and took</div><div>a long time to validate.</div><div><br></div><div>==Specification==</div><div><br></div><div>After deployment, the maximum serialized size of a transaction allowed</div><div>in a block shall be 100,000 bytes.</div><div><br></div><div>==Compatibility==</div><div><br></div><div>This change should be compatible with existing transaction-creation software,</div><div>because transactions larger than 100,000 bytes have been considered "non-standard"</div><div>(they are not relayed or mined by default) for years.</div><div><br></div><div>Software that assembles transactions into blocks and that validates blocks must be</div><div>updated to reject oversize transactions.</div><div><br></div><div>==Deployment==</div><div><br></div><div>This change will be deployed with BIP 100 or BIP 101.</div><div><br></div><div>==Discussion==</div><div><br></div><div>Alternatives to this BIP:</div><div><br></div><div>1. A new consensus rule that limits the number of signature operations in a</div><div>single transaction instead of limiting size. This might be more compatible with</div><div>future opcodes that require larger-than-100,000-byte transactions, although</div><div>any such future opcodes would likely require changes to the Script validation</div><div>rules anyway (e.g. the 520-byte limit on data items).</div><div><br></div><div>2. Fix the SIG opcodes so they don't re-hash variations of the transaction's data.</div><div>This is the "most correct" solution, but would require updating every</div><div>piece of transaction-creating and transaction-validating software to change how</div><div>they compute the signature hash.</div><div><br></div><div>==References==</div><div><br></div><div>[[<a href="https://bitcointalk.org/?topic=140078|CVE-2013-2292]">https://bitcointalk.org/?topic=140078|CVE-2013-2292]</a>]: Sergio Demian Lerner's original report</div><div><br></div><div><br></div><div class="gmail_signature"><br></div>
</div>