{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-20\n📝 Original message:Draft BIP to prevent a potential CPU exhaustion attack if a significantly\nlarger maximum blocksize is adopted:\n\n  Title: Limit maximum transaction size\n  Author: Gavin Andresen \u003cgavinandresen at gmail.com\u003e\n  Status: Draft\n  Type: Standards Track\n  Created: 2015-07-17\n\n==Abstract==\n\nMitigate a potential CPU exhaustion denial-of-service attack by limiting\nthe maximum size of a transaction included in a block.\n\n==Motivation==\n\nSergio Demian Lerner reported that a maliciously constructed block could\ntake several minutes to validate, due to the way signature hashes are\ncomputed for OP_CHECKSIG/OP_CHECKMULTISIG ([[\nhttps://bitcointalk.org/?topic=140078|CVE-2013-2292]]).\nEach signature validation can require hashing most of the transaction's\nbytes, resulting in O(s*b) scaling (where n is the number of signature\noperations and m is the number of bytes in the transaction, excluding\nsignatures). If there are no limits on n or m the result is O(n^2) scaling.\n\nThis potential attack was mitigated by changing the default relay and\nmining policies so transactions larger than 100,000 bytes were not\nrelayed across the network or included in blocks. However, a miner\nnot following the default policy could choose to include a\ntransaction that filled the entire one-megaybte block and took\na long time to validate.\n\n==Specification==\n\nAfter deployment, the maximum serialized size of a transaction allowed\nin a block shall be 100,000 bytes.\n\n==Compatibility==\n\nThis change should be compatible with existing transaction-creation\nsoftware,\nbecause transactions larger than 100,000 bytes have been considered\n\"non-standard\"\n(they are not relayed or mined by default) for years.\n\nSoftware that assembles transactions into blocks and that validates blocks\nmust be\nupdated to reject oversize transactions.\n\n==Deployment==\n\nThis change will be deployed with BIP 100 or BIP 101.\n\n==Discussion==\n\nAlternatives to this BIP:\n\n1. A new consensus rule that limits the number of signature operations in a\nsingle transaction instead of limiting size. This might be more compatible\nwith\nfuture opcodes that require larger-than-100,000-byte transactions, although\nany such future opcodes would likely require changes to the Script\nvalidation\nrules anyway (e.g. the 520-byte limit on data items).\n\n2. Fix the SIG opcodes so they don't re-hash variations of the\ntransaction's data.\nThis is the \"most correct\" solution, but would require updating every\npiece of transaction-creating and transaction-validating software to change\nhow\nthey compute the signature hash.\n\n==References==\n\n[[https://bitcointalk.org/?topic=140078|CVE-2013-2292]]: Sergio Demian\nLerner's original report\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/04cdfad9/attachment-0001.html\u003e"}