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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z4Ryh-00040S-Sn
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 10:50:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.54 as permitted sender)
client-ip=74.125.82.54; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f54.google.com;
Received: from mail-wg0-f54.google.com ([74.125.82.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4Ryg-0006PO-3p
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 10:50:55 +0000
Received: by wgzl5 with SMTP id l5so40540379wgz.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 03:50:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.19.100 with SMTP id d4mr29382427wie.95.1434365448079;
Mon, 15 Jun 2015 03:50:48 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Mon, 15 Jun 2015 03:50:47 -0700 (PDT)
In-Reply-To: <CAPg+sBiPhhrBh8f3QxJLtoysfywtVFSo2RH0WXVR+vpX9z6+HQ@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
<CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com>
<CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
<CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com>
<CAPg+sBiPhhrBh8f3QxJLtoysfywtVFSo2RH0WXVR+vpX9z6+HQ@mail.gmail.com>
Date: Mon, 15 Jun 2015 12:50:47 +0200
X-Google-Sender-Auth: P1-Spqnbdbb3xJroZGCwwzi92fQ
Message-ID: <CANEZrP10gn+969d-oe-8Em9ipe4DOP9q0WkNtL6u-6V5aphkPQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec53d5c6302d00005188c3ba8
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: 1Z4Ryg-0006PO-3p
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
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: Mon, 15 Jun 2015 10:50:55 -0000
--bcaec53d5c6302d00005188c3ba8
Content-Type: text/plain; charset=UTF-8
>
> The fact that using a centralized service is easier isn't a good reason
> IMHO. It disregards the long-term, and introduces systemic risk.
>
Well sure, that's easy for you to say, but you have a salary :) Other
developers may find the incremental benefits of decentralisation low vs
adding additional features, for instance, and who is to say they are wrong?
> But in cases where using a decentralized approach doesn't *add* anything,
> I cannot reasonably promote it, and that's why I was against getutxos in
> the P2P protocol.
>
It does add something though! It means, amongst other things, I can switch
of all my servers, walk away for good, discard this Mike Hearn pseudonym I
invented for Bitcoin and the app will still work :) Surely that is an
important part of being decentralised?
It also means that as the underlying protocol evolves over time, getutxos
can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
one more additional bit of security. If one day miners commit to UTXO sets,
great, one more additional bit of security. When we start including input
values in the signature hash, great ... one more step up in security.
Anyway, I didn't really want to reopen this debate. I just point out that
third party services are quite happy to provide whatever developers need to
build great apps, even if doing so fails to meet some kind of perfect
cryptographic ideal. And that's why they're winning devs.
Now back to your regularly scheduled block size debates ...
--bcaec53d5c6302d00005188c3ba8
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div>The fact that using a centralized service is ea=
sier isn't a good reason IMHO. It disregards the long-term, and introdu=
ces systemic risk.<br></div></div></div></div></blockquote><div><br></div><=
div>Well sure, that's easy for you to say, but you have a salary :) Oth=
er developers may find the incremental benefits of decentralisation low vs =
adding additional features, for instance, and who is to say they are wrong?=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>But in cases where u=
sing a decentralized approach doesn't *add* anything, I cannot reasonab=
ly promote it, and that's why I was against getutxos in the P2P protoco=
l.<br></div></div></div></div></blockquote><div><br></div><div>It does add =
something though! It means, amongst other things, I can switch of all my se=
rvers, walk away for good, discard this Mike Hearn pseudonym I invented for=
Bitcoin and the app will still work :) Surely that is an important part of=
being decentralised?</div><div><br></div><div>It also means that as the un=
derlying protocol evolves over time, getutxos can evolve along side it. P2P=
protocol gets encrypted/authenticated? Great, one more additional bit of s=
ecurity. If one day miners commit to UTXO sets, great, one more additional =
bit of security. When we start including input values in the signature hash=
, great ... one more step up in security.</div><div><br></div><div>Anyway, =
I didn't really want to reopen this debate. I just point out that third=
party services are quite happy to provide whatever developers need to buil=
d great apps, even if doing so fails to meet some kind of perfect cryptogra=
phic ideal. And that's why they're winning devs.</div><div><br></di=
v><div>Now back to your regularly scheduled block size debates ...=C2=A0</d=
iv></div></div></div>
--bcaec53d5c6302d00005188c3ba8--
|
