š
Original date posted:2015-12-08
š Original message:On Tue, Dec 8, 2015 at 6:59 PM, Gregory Maxwell <greg at xiph.org> wrote:
> > We also need to fix the O(n^2) sighash problem as an additional BIP for
> ANY
> > blocksize increase.
>
> The witness data is never an input to sighash, so no, I don't agree
> that this holds for "any" increase.
>
Here's the attack:
Create a 1-megabyte transaction, with all of it's inputs spending
segwitness-spending SIGHASH_ALL inputs.
Because the segwitness inputs are smaller in the block, you can fit more of
them into 1 megabyte. Each will hash very close to one megabyte of data.
That will be O(n^2) worse than the worst case of a 1-megabyte transaction
with signatures in the scriptSigs.
Did I misunderstand something or miss something about the 1-mb transaction
data and 3-mb segwitness data proposal that would make this attack not
possible?
RE: fraud proof data being deterministic: yes, I see, the data can be
computed instead of broadcast with the block.
RE: emerging consensus of Core:
I think it is a huge mistake not to "design for success" (see
http://gavinandresen.ninja/designing-for-success ).
I think it is a huge mistake to pile on technical debt in
consensus-critical code. I think we should be working harder to make things
simpler, not more complex, whenever possible.
And I think there are pretty big self-inflicted current problems because
worries about theoretical future problems have prevented us from coming to
consensus on simple solutions.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/58a8269d/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4ā¦d44kw
2023-06-07 17:45:41
in reply to nevent1qā¦n7v6
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 17:45:41Event JSON
{
"id": "974d8d5b6de4d621004f5bda4780de18bed0241da23df3efdf49baf4bc794f3f",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686159941,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"fa872fb3f24f82114cac2fab950a53de9c479224cdb9b8dc25fb0ec98d11ece6",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "š
Original date posted:2015-12-08\nš Original message:On Tue, Dec 8, 2015 at 6:59 PM, Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e \u003e We also need to fix the O(n^2) sighash problem as an additional BIP for\n\u003e ANY\n\u003e \u003e blocksize increase.\n\u003e\n\u003e The witness data is never an input to sighash, so no, I don't agree\n\u003e that this holds for \"any\" increase.\n\u003e\n\nHere's the attack:\n\nCreate a 1-megabyte transaction, with all of it's inputs spending\nsegwitness-spending SIGHASH_ALL inputs.\n\nBecause the segwitness inputs are smaller in the block, you can fit more of\nthem into 1 megabyte. Each will hash very close to one megabyte of data.\n\nThat will be O(n^2) worse than the worst case of a 1-megabyte transaction\nwith signatures in the scriptSigs.\n\nDid I misunderstand something or miss something about the 1-mb transaction\ndata and 3-mb segwitness data proposal that would make this attack not\npossible?\n\nRE: fraud proof data being deterministic: yes, I see, the data can be\ncomputed instead of broadcast with the block.\n\nRE: emerging consensus of Core:\n\nI think it is a huge mistake not to \"design for success\" (see\nhttp://gavinandresen.ninja/designing-for-success ).\n\nI think it is a huge mistake to pile on technical debt in\nconsensus-critical code. I think we should be working harder to make things\nsimpler, not more complex, whenever possible.\n\nAnd I think there are pretty big self-inflicted current problems because\nworries about theoretical future problems have prevented us from coming to\nconsensus on simple solutions.\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/58a8269d/attachment.html\u003e",
"sig": "b99e81f73206ef0aac0c9b7b4a87904e1ccec52d78e474253c3a93a4754eae82a7058875edb843ccd60073fad8e654931692d924ffa489ff016c7d4414226286"
}