rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-07-20 📝 Original message: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> Status: Draft Type: Standards Track Created: 2015-07-17 ==Abstract== Mitigate a potential CPU exhaustion denial-of-service attack by limiting the maximum size of a transaction included in a block. ==Motivation== 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 ([[ https://bitcointalk.org/?topic=140078|CVE-2013-2292]]). 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. ==Specification== After deployment, the maximum serialized size of a transaction allowed in a block shall be 100,000 bytes. ==Compatibility== This change should be compatible with existing transaction-creation software, because transactions larger than 100,000 bytes have been considered "non-standard" (they are not relayed or mined by default) for years. Software that assembles transactions into blocks and that validates blocks must be updated to reject oversize transactions. ==Deployment== This change will be deployed with BIP 100 or BIP 101. ==Discussion== 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 with future opcodes that require larger-than-100,000-byte transactions, although any such future opcodes would likely require changes to the Script validation 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 transaction's data. This is the "most correct" solution, but would require updating every piece of transaction-creating and transaction-validating software to change how they compute the signature hash. ==References== [[https://bitcointalk.org/?topic=140078|CVE-2013-2292]]: Sergio Demian Lerner's original report -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/04cdfad9/attachment-0001.html>