On Tue, Dec 8, 2015 at 6:59 PM, Gregory Maxwell <greg@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.
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.