summaryrefslogtreecommitdiff
path: root/7d/9ddd0d0f03dd48e346bbe8d5d29f6862e49b3d
blob: bd65ac11f36390cf5cb78fd701eec40d751a3c87 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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>
	<A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com>
	<545BF0C2.3030201@bluematt.me>
	<CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com>
	<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: <CANEZrP2mnbr7zjQ5kOWCVLH79wgHgHDSLMpqkKhpD84QMcwuLA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
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 <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><span class=3D"">&gt; Who benefits from not fixing bugs in Bit=
coin?<br>
<br>
</span>We can bring up politics if you want.</blockquote><div><br></div><di=
v class=3D"gmail_extra">No, please don&#39;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&#39;s obnoxious and you need to stop it.</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Hard forks=
 vs soft forks are=C2=A0<i>purely</i>=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 &quot;which side of the fork do I accept in my economic activity&=
quot;. It&#39;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.</div></div></div></div>

--089e0160b5f4e8ef6b050747a2a7--