<oembed><type>rich</type><version>1.0</version><author_name>npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58</author_name><author_url>https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-18&#xA;📝 Original message:Is that a forward-looking position?  It does not seem so.&#xA;&#xA;The whole point is getting out in front of the need, to prevent significant&#xA;negative impact to users when blocks are consistently full.&#xA;&#xA;To do that, you need to (a) plan forward, in order to (b) set a hard fork&#xA;date in the future.&#xA;&#xA;&#34;We don&#39;t see a need today&#34; is therefore useless, because when you do reach&#xA;X day when need is apparent, the best solution then becomes an immediate&#xA;fork for which the network and markets are not prepared.&#xA;&#xA;Failing to resolve the block size issue soon will simply result in most&#xA;businesses assuming relevant Bitcoin Core standards process is failing, and&#xA;proceed with the Bitcoin-XT fork.&#xA;&#xA;As I&#39;ve said on IRC, the &#34;do nothing, for now&#34; position is untenable.&#xA;&#xA;-- &#xA;Jeff Garzik&#xA;Bitcoin core developer and open source evangelist&#xA;BitPay, Inc.      https://bitpay.com/&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/9e4db165/attachment.html&gt;</html></oembed>