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