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.

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