{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:On Wed, Dec 09, 2015 at 01:31:51AM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e \u003e Create a 1-megabyte transaction, with all of it's inputs spending\n\u003e \u003e segwitness-spending SIGHASH_ALL inputs.\n\u003e \u003e Because the segwitness inputs are smaller in the block, you can fit more of\n\u003e \u003e them into 1 megabyte. Each will hash very close to one megabyte of data.\n\u003e Witness size comes out of the 1MB at a factor of 0.25. It is not\n\u003e possible to make a block which has signatures with the full 1MB of\n\u003e data under the sighash while also having signatures externally.  So\n\u003e every byte moved into the witness and thus only counted as 25% comes\n\u003e out of the data being hashed and is hashed nInputs (*checksigs) less\n\u003e times.\n\nSo the worst case script I can come up with is:\n\n      \u003cpubkey\u003e 1 0 {2OVER CHECKSIG ADD CODESEP} OP_EQUAL\n\nwhich (if I didn't mess it up) would give you a redeem script of about\n36B plus 4B per sigop, redeemable via a single signature that's valid\nfor precisely one of the checksigs.\n\nMaxing out 20k sigops gives 80kB of redeemscript in that case; so you\ncould have to hash 19.9GB of data to fully verify the script with\ncurrent bitcoin rules.\n\nSegwit with the 75% factor and the same sigop limit would make that very\nslightly worse -- it'd up the hashed data by maybe 1MB in total. Without\na sigop limit at all it'd be severely worse of course -- you could fit\nalmost 500k sigops in 2MB of witness data, leaving 500kB of base data,\nfor a total of 250GB of data to hash to verify your 3MB block...\n\nSegwit without the 75% factor, but with a 3MB of witness data limit,\nmakes that up to three times worse (750k sigops in 3MB of witness data,\nwith 1MB of base data for 750GB of data to hash), but with any reasonable\nsigop limit, afaics it's pretty much the same.\n\nHowever I think you could add some fairly straightforward (maybe\nsoft-forking) optimisations to just rule out that sort of (deliberate)\nabuse; eg disallowing more than a dozen sigops per input, or just failing\nchecksigs with the same key in a single input, maybe. So maybe that's\nnot sufficiently realistic?\n\nI think the only realistic transactions that would cause lots of sigs and\nhashing are ones that have lots of inputs that each require a signature\nor two, so might happen if a miner is cleaning up dust. In that case,\nyour 1MB transaction is a single output with a bunch of 41B inputs. If you\nhave 10k such inputs, that's only 410kB. If each input is a legitimate\n2 of 2 multisig, that's about 210 bytes of witness data per input, or\n2.1MB, leaving 475kB of base data free, which matches up. 20k sigops by\n475kB of data is 9.5GB of hashing.\n\nSwitching from 2-of-2 multisig to just a single public key would prevent\nyou from hitting the sigop limit; I think you could hit 14900 signatures\nwith about 626kB of base data and 1488kB of witness data, for about\n9.3GB of hashed data.\n\nThat's a factor of 2x improvement over the deliberately malicious exploit\ncase above, but it's /only/ a factor of 2x.\n\nI think Rusty's calculation http://rusty.ozlabs.org/?p=522 was that\nthe worst case for now is hashing about 406kB, 3300 times for 1.34GB of\nhashed data [0].\n\nSo that's still almost a factor of 4 or 5 worse than what's possible now?\nUnless I messed up the maths somewhere?\n\nCheers,\naj\n\n[0] Though I'm not sure that's correct? Seems like with a 1MB\n    transaction with i inputs, each with s bytes of scriptsig, that you're\n    hashing (1MB-s*i), and the scriptsig for a p2pkh should only be about\n    105B, not 180B.  So maximising i*(1MB-s*i) = 1e6*i - 105*i^2 gives i =\n    1e6/210, so 4762 inputs, and hashing 500kB of data each time,\n    for about 2.4GB of hashed data total."}