<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 6:59 PM, Gregory Maxwell <span dir="ltr"><<a href="mailto:greg@xiph.org" target="_blank">greg@xiph.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im">> We also need to fix the O(n^2) sighash problem as an additional BIP for ANY<br>
> blocksize increase.<br>
<br>
</span><span class="im">The witness data is never an input to sighash, so no, I don't agree<br>
that this holds for "any" increase.<br></span></blockquote></div><br>Here's the attack:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Create a 1-megabyte transaction, with all of it's inputs spending segwitness-spending SIGHASH_ALL inputs.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That will be O(n^2) worse than the worst case of a 1-megabyte transaction with signatures in the scriptSigs.<br><br>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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">RE: fraud proof data being deterministic: yes, I see, the data can be computed instead of broadcast with the block.</div><div class="gmail_extra"><br></div><div class="gmail_extra">RE: emerging consensus of Core:</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think it is a huge mistake not to "design for success" (see <a href="http://gavinandresen.ninja/designing-for-success">http://gavinandresen.ninja/designing-for-success</a> ).</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>