rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 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>