<oembed><type>rich</type><version>1.0</version><author_name>npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r</author_name><author_url>https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-12-16&#xA;📝 Original message:On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev&#xA;&lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt; 2) If block size stays at 1M, the Bitcoin Core developer team should sign a&#xA;&gt; collective note stating their desire to transition to a new economic policy,&#xA;&gt; that of &#34;healthy fee market&#34; and strongly urge users to examine their fee&#xA;&gt; policies, wallet software, transaction volumes and other possible User&#xA;&gt; impacting outcomes.&#xA;&#xA;You present this as if the Bitcoin Core development team is in charge&#xA;of deciding the network consensus rules, and is responsible for making&#xA;changes to it in order to satisfy economic demand. If that is the&#xA;case, Bitcoin has failed, in my opinion.&#xA;&#xA;What the Bitcoin Core team should do, in my opinion, is merge any&#xA;consensus change that is uncontroversial. We can certainly -&#xA;individually or not - propose solutions, and express opinions, but as&#xA;far as maintainers of the software goes our responsibility is keeping&#xA;the system running, and risking either a fork or establishing&#xA;ourselves as the de-facto central bank that can make any change to the&#xA;system would greatly undermine the system&#39;s value.&#xA;&#xA;Hard forking changes require that ultimately every participant in the&#xA;system adopts the new rules. I find it immoral and dangerous to merge&#xA;such a change without extremely widespread agreement. I am personally&#xA;fine with a short-term small block size bump to kick the can down the&#xA;road if that is what the ecosystem desires, but I can only agree with&#xA;merging it in Core if I&#39;m convinced that there is no strong opposition&#xA;to it from others.&#xA;&#xA;Soft forks on the other hand only require a majority of miners to&#xA;accept them, and everyone else can upgrade at their leisure or not at&#xA;all. Yes, old full nodes after a soft fork are not able to fully&#xA;validate the rules new miners enforce anymore, but they do still&#xA;verify the rules that their operators opted to enforce. Furthermore,&#xA;they can&#39;t be prevented. For that reason, I&#39;ve proposed, and am&#xA;working hard, on an approach that includes Segregated Witness as a&#xA;first step. It shows the ecosystem that something is being done, it&#xA;kicks the can down the road, it solves/issues half a dozen other&#xA;issues at the same time, and it does not require the degree of&#xA;certainty needed for a hardfork.&#xA;&#xA;-- &#xA;Pieter</html></oembed>