<oembed><type>rich</type><version>1.0</version><author_name>npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu</author_name><author_url>https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-05-07&#xA;📝 Original message:OK, so lets do that. I&#39;ve seen a lot of &#34;I&#39;m not entirely comfortable&#xA;with committing to this right now, but think we should eventually&#34;, but&#xA;not much &#34;I&#39;d be comfortable with committing to this when I see X&#34;. In&#xA;the interest of ignoring debate and pushing people towards a consensus&#xA;at all costs, ( ;) ) I&#39;m gonna go ahead and suggest we talk about the&#xA;second.&#xA;&#xA;Personally, there are several things that worry me significantly about&#xA;committing to a blocksize increase, which I&#39;d like to see resolved&#xA;before I&#39;d consider supporting a blocksize increase commitment.&#xA;&#xA; * Though there are many proposals floating around which could&#xA;significantly decrease block propagation latency, none of them are&#xA;implemented today. I&#39;d expect to see these not only implemented but&#xA;being used in production (though I dont particularly care about them&#xA;being all that stable). I&#39;d want to see measurements of how they perform&#xA;both in production and in the face of high packet loss (eg across the&#xA;GFW or in the case of small/moderate DoS). In addition, I&#39;d expect to&#xA;see analysis of how these systems perform in the worst-case, not just&#xA;packet-loss-wise, but in the face of miners attempting to break the system.&#xA;&#xA; * I&#39;d very much like to see someone working on better scaling&#xA;technology, both in terms of development and in terms of getting&#xA;traction in the marketplace. I know StrawPay is working on development,&#xA;though its not obvious to me how far they are from their website, but I&#xA;dont know of any commitments by large players (either SPV wallets,&#xA;centralized wallet services, payment processors, or any others) to&#xA;support such a system (to be fair, its probably too early for such&#xA;players to commit to anything, since anything doesnt exist in public).&#xA;&#xA; * I&#39;d like to see some better conclusions to the discussion around&#xA;long-term incentives within the system. If we&#39;re just building Bitcoin&#xA;to work in five years, great, but if we want it all to keep working as&#xA;subsidy drops significantly, I&#39;d like a better answer than &#34;we&#39;ll deal&#xA;with it when we get there&#34; or &#34;it will happen, all the predictions based&#xA;on people&#39;s behavior today say so&#34; (which are hopefully invalid thanks&#xA;to the previous point). Ideally, I&#39;d love to see some real free pressure&#xA;already on the network starting to develop when we commit to hardforking&#xA;in a year. Not just full blocks with some fees because wallets are&#xA;including far greater fees than they really need to, but software which&#xA;properly handles fees across the ecosystem, smart fee increases when&#xA;transactions arent confirming (eg replace-by-fee, which could be limited&#xA;to increase-in-fees-only for those worried about double-spends).&#xA;&#xA;I probably forgot one or two and certainly dont want to back myself into&#xA;a corner on committing to something here, but those are a few things I&#xA;see today as big blockers on larger blocks.&#xA;&#xA;Luckily, people have been making progress on building the software&#xA;needed in all of the above for a while now, but I think they&#39;re all&#xA;very, very immature today.&#xA;&#xA;On 05/07/15 19:13, Jeff Garzik wrote:&gt; On Thu, May 7, 2015 at 3:03 PM,&#xA;Matt Corallo &lt;bitcoin-list at bluematt.me&#xA;&gt; &lt;mailto:bitcoin-list at bluematt.me&gt;&gt; wrote:&#xA;-snip-&#xA;&gt;&gt; If, instead, there had been an intro on the list as &#34;I think we should&#xA;&gt;&gt; do the blocksize increase soon, what do people think?&#34;, the response&#xA;&gt;&gt; could likely have focused much more around creating a specific list of&#xA;&gt;&gt; things we should do before we (the technical community) think we are&#xA;&gt;&gt; prepared for a blocksize increase.&#xA;&gt;&#xA;&gt; Agreed, but that is water under the bridge at this point.  You - rightly&#xA;&gt; - opened the topic here and now we&#39;re discussing it.&#xA;&gt;&#xA;&gt; Mike and Gavin are due the benefit of doubt because making a change to a&#xA;&gt; leaderless automaton powered by leaderless open source software is&#xA;&gt; breaking new ground.  I don&#39;t focus so much on how we got to this point,&#xA;&gt; but rather, where we go from here.</html></oembed>