<oembed><type>rich</type><version>1.0</version><author_name>npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw</author_name><author_url>https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-12-08&#xA;📝 Original message:Thanks for laying out a road-map, Greg.&#xA;&#xA;I&#39;ll need to think about it some more, but just a couple of initial&#xA;reactions:&#xA;&#xA;Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the&#xA;coinbase is messy and will just complicate consensus-critical code (as&#xA;opposed to making the right side of the merkle tree in block.version=5&#xA;blocks the segwitness data).&#xA;&#xA;It will also make any segwitness fraud proofs significantly larger (merkle&#xA;path versus  merkle path to coinbase transactions, plus ENTIRE coinbase&#xA;transaction, which might be quite large, plus merkle path up to root).&#xA;&#xA;&#xA;We also need to fix the O(n^2) sighash problem as an additional BIP for ANY&#xA;blocksize increase. That also argues for a hard fork-- it is much easier to&#xA;fix it correctly and simplify the consensus code than to continue to apply&#xA;band-aid fixes on top of something fundamentally broken.&#xA;&#xA;&#xA;Segwitness will require a hard or soft-fork rollout, then a significant&#xA;fraction of the transaction-producing wallets to upgrade and start&#xA;supporting segwitness-style transactions.  I think it will be much quicker&#xA;than the P2SH rollout, because the biggest transaction producers have a&#xA;strong motivation to lower their fees, and it won&#39;t require a new type of&#xA;bitcoin address to fund wallets.  But it still feels like it&#39;ll be six&#xA;months to a year at the earliest before any relief from the current&#xA;problems we&#39;re seeing from blocks filling up.&#xA;&#xA;Segwitness will make the current bottleneck (block propagation) a little&#xA;worse in the short term, because of the extra fraud-proof data.  Benefits&#xA;well worth the costs.&#xA;&#xA;------------------&#xA;&#xA;I think a barrier to quickly getting consensus might be a fundamental&#xA;difference of opinion on this:&#xA;   &#34;Even without them I believe we’ll be in an acceptable position with&#xA;respect to capacity in the near term&#34;&#xA;&#xA;The heaviest users of the Bitcoin network (businesses who generate tens of&#xA;thousands of transactions per day on behalf of their customers) would&#xA;strongly disgree; the current state of affairs is NOT acceptable to them.&#xA;&#xA;&#xA;&#xA;-- &#xA;--&#xA;Gavin Andresen&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/386ffdbc/attachment.html&gt;</html></oembed>