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