{"type":"rich","version":"1.0","author_name":"npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef","author_url":"https://nostr.ae/npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-20\n📝 Original message:I take it there's no feasibility in suggesting the script execution code \nhas run time maximums? I'm aware these would be much harder to have \nconsensus on, but would seem like the better solution if at all possible.\n\nRoss\n\nOn 20/07/2015 20:10, Gavin Andresen via bitcoin-dev wrote:\n\u003e Draft BIP to prevent a potential CPU exhaustion attack if a \n\u003e significantly larger maximum blocksize is adopted:\n\u003e\n\u003e   Title: Limit maximum transaction size\n\u003e   Author: Gavin Andresen \u003cgavinandresen at gmail.com \n\u003e \u003cmailto:gavinandresen at gmail.com\u003e\u003e\n\u003e   Status: Draft\n\u003e   Type: Standards Track\n\u003e   Created: 2015-07-17\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e Mitigate a potential CPU exhaustion denial-of-service attack by limiting\n\u003e the maximum size of a transaction included in a block.\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e Sergio Demian Lerner reported that a maliciously constructed block could\n\u003e take several minutes to validate, due to the way signature hashes are\n\u003e computed for OP_CHECKSIG/OP_CHECKMULTISIG \n\u003e ([[https://bitcointalk.org/?topic=140078|CVE-2013-2292]] \n\u003e \u003chttps://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]\u003e).\n\u003e Each signature validation can require hashing most of the transaction's\n\u003e bytes, resulting in O(s*b) scaling (where n is the number of signature\n\u003e operations and m is the number of bytes in the transaction, excluding\n\u003e signatures). If there are no limits on n or m the result is O(n^2) \n\u003e scaling.\n\u003e\n\u003e This potential attack was mitigated by changing the default relay and\n\u003e mining policies so transactions larger than 100,000 bytes were not\n\u003e relayed across the network or included in blocks. However, a miner\n\u003e not following the default policy could choose to include a\n\u003e transaction that filled the entire one-megaybte block and took\n\u003e a long time to validate.\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e After deployment, the maximum serialized size of a transaction allowed\n\u003e in a block shall be 100,000 bytes.\n\u003e\n\u003e ==Compatibility==\n\u003e\n\u003e This change should be compatible with existing transaction-creation \n\u003e software,\n\u003e because transactions larger than 100,000 bytes have been considered \n\u003e \"non-standard\"\n\u003e (they are not relayed or mined by default) for years.\n\u003e\n\u003e Software that assembles transactions into blocks and that validates \n\u003e blocks must be\n\u003e updated to reject oversize transactions.\n\u003e\n\u003e ==Deployment==\n\u003e\n\u003e This change will be deployed with BIP 100 or BIP 101.\n\u003e\n\u003e ==Discussion==\n\u003e\n\u003e Alternatives to this BIP:\n\u003e\n\u003e 1. A new consensus rule that limits the number of signature operations \n\u003e in a\n\u003e single transaction instead of limiting size. This might be more \n\u003e compatible with\n\u003e future opcodes that require larger-than-100,000-byte transactions, \n\u003e although\n\u003e any such future opcodes would likely require changes to the Script \n\u003e validation\n\u003e rules anyway (e.g. the 520-byte limit on data items).\n\u003e\n\u003e 2. Fix the SIG opcodes so they don't re-hash variations of the \n\u003e transaction's data.\n\u003e This is the \"most correct\" solution, but would require updating every\n\u003e piece of transaction-creating and transaction-validating software to \n\u003e change how\n\u003e they compute the signature hash.\n\u003e\n\u003e ==References==\n\u003e\n\u003e [[https://bitcointalk.org/?topic=140078|CVE-2013-2292] \n\u003e \u003chttps://bitcointalk.org/?topic=140078%7CCVE-2013-2292]\u003e]: Sergio \n\u003e Demian Lerner's original report\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/b969dd16/attachment.html\u003e"}