From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xmmlw-0003jm-Em for bitcoin-development@lists.sourceforge.net; Fri, 07 Nov 2014 16:52:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.45 as permitted sender) client-ip=209.85.215.45; envelope-from=mh.in.england@gmail.com; helo=mail-la0-f45.google.com; Received: from mail-la0-f45.google.com ([209.85.215.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xmmlv-00082Q-9L for bitcoin-development@lists.sourceforge.net; Fri, 07 Nov 2014 16:52:28 +0000 Received: by mail-la0-f45.google.com with SMTP id pn19so4706514lab.4 for ; Fri, 07 Nov 2014 08:52:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.37.104 with SMTP id x8mr12473509laj.74.1415379140798; Fri, 07 Nov 2014 08:52:20 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.25.91.147 with HTTP; Fri, 7 Nov 2014 08:52:20 -0800 (PST) In-Reply-To: <20141107000310.GA6532@savin.petertodd.org> References: <20141106213215.GA12918@savin.petertodd.org> <545BF0C2.3030201@bluematt.me> <545BFAD6.1000504@riseup.net> <20141106232649.GD26859@savin.petertodd.org> <545C0617.7020300@riseup.net> <20141107000310.GA6532@savin.petertodd.org> Date: Fri, 7 Nov 2014 17:52:20 +0100 X-Google-Sender-Auth: C6HOYHRWWtit7Rjvgt8uYX8SUz0 Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=089e0160b5f4e8ef6b050747a2a7 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Xmmlv-00082Q-9L Cc: Bitcoin Dev , Justus Ranvier Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:52:28 -0000 --089e0160b5f4e8ef6b050747a2a7 Content-Type: text/plain; charset=UTF-8 > > > Who benefits from not fixing bugs in Bitcoin? > > We can bring up politics if you want. No, please don't. That question was rhetorical, not an invitation for you to try and convince bystanders that anyone who disagrees with you is a shadowy Agent Of Centralisation or an idiot. You use that tactic way too much: it's obnoxious and you need to stop it. Hard forks vs soft forks are *purely* about whether you drag along old nodes in a quasi-broken state. They do not reduce total work needed by the community one iota. Non-miners who wish to reject a soft fork can easily run a node that does so, if they wanted to - the voting mechanism still boils down to "which side of the fork do I accept in my economic activity". It's certainly garbage to claim that the reason to want to avoid soft forks is being an Evil Centralised Foundation: this is about a set of engineering tradeoffs only. --089e0160b5f4e8ef6b050747a2a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Who benefits from not fixing bugs in Bit= coin?

We can bring up politics if you want.

No, please don't. That question was rhetorical,= not an invitation for you to try and convince bystanders that anyone who d= isagrees with you is a shadowy Agent Of Centralisation or an idiot. You use= that tactic way too much: it's obnoxious and you need to stop it.

Hard forks= vs soft forks are=C2=A0purely=C2=A0about whether you drag along old= nodes in a quasi-broken state. They do not reduce total work needed by the= community one iota. Non-miners who wish to reject a soft fork can easily r= un a node that does so, if they wanted to - the voting mechanism still boil= s down to "which side of the fork do I accept in my economic activity&= quot;. It's certainly garbage to claim that the reason to want to avoid= soft forks is being an Evil Centralised Foundation: =C2=A0this is about a = set of engineering tradeoffs only.
--089e0160b5f4e8ef6b050747a2a7--