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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
|
Return-Path: <luvb@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AF23B2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 07:11:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-SG2-obe.outbound.protection.outlook.com
(mail-oln040092253080.outbound.protection.outlook.com [40.92.253.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B9D8FAF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 07:11:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
bh=1SoTi5R7xv/tobWQEAOHVBxDb540RImq8U5eGFBIvII=;
b=nh0hFJVslxdHF8DJLdNTFAxvKLLXTb653qECEK402RE5Ezqb8Xa9UoY2I1siqyMfCDyQsXmOqQfSxwJFZ717UGr+jKmvmSN/D4W6pWV+iAvk0ctlz1+vi+YAzofW+onqCUVwbNTruV/4DWXsp61W+WAhov6tm22vt4UEwxtEl5YdNJ1S/+H+ompqIUwCF+DpT90hdA8YVz+tTI//wVbn7SjuRK82LzNP+Z1vjKOHyzQmTzdOiIvHxDxNbVPJ+JuByWaJjMTiwqnRTTKuO2h0HjXQjciJn7f0BbTRgJzJotsnx+KJw2S0TN7z1VjMVSe9dqCGN5s/1NSOK4TonpYIyg==
Received: from PU1APC01FT039.eop-APC01.prod.protection.outlook.com
(10.152.252.58) by PU1APC01HT185.eop-APC01.prod.protection.outlook.com
(10.152.252.189) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7;
Thu, 30 Mar 2017 07:11:21 +0000
Received: from SINPR04MB1949.apcprd04.prod.outlook.com (10.152.252.60) by
PU1APC01FT039.mail.protection.outlook.com (10.152.253.127) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5 via
Frontend Transport; Thu, 30 Mar 2017 07:11:21 +0000
Received: from SINPR04MB1949.apcprd04.prod.outlook.com ([10.141.116.153]) by
SINPR04MB1949.apcprd04.prod.outlook.com ([10.141.116.153]) with mapi id
15.01.0991.022; Thu, 30 Mar 2017 07:11:21 +0000
From: Luv Khemani <luvb@hotmail.com>
To: David Vorick <david.vorick@gmail.com>, Jared Lee Richardson
<jaredr26@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Hard fork proposal from last week's meeting
Thread-Index: AQHSqMNonQ4DjsxFiU+7a8C6k6bCq6GsRI2AgAAb7oCAAGkzLQ==
Date: Thu, 30 Mar 2017 07:11:21 +0000
Message-ID: <SINPR04MB1949AB581C6870184445E0C4C2340@SINPR04MB1949.apcprd04.prod.outlook.com>
References: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
<CAFVRnyq9Qgw88RZqenjQTDZHEWeuNCdh12Dq7wCGZdu9ZuEN9w@mail.gmail.com>,
<CAD1TkXvd4yLHZDAdMi78WwJ_siO1Vt7=DgYiBmP45ffVveuHBg@mail.gmail.com>
In-Reply-To: <CAD1TkXvd4yLHZDAdMi78WwJ_siO1Vt7=DgYiBmP45ffVveuHBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed)
header.d=none; gmail.com; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:8ED8A085A3E967CC7496685A4320639FBD811C323B1D3B081ABA379CA44F8700;
UpperCasedChecksum:5D5E927E1F3AC40C2F57F9C39D8B4D17D7345C8AC841F3645FBEF82476A51936;
SizeAsReceived:8404; Count:42
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [it9R7jlWksJ44+trxL+8n5EVA8f8IFwO]
x-microsoft-exchange-diagnostics: 1; PU1APC01HT185;
5:Ro00q3UWAp7XDON/KAnt3lNwHEocoRWPHacMhLQil6ikdTrTjE0SB90ucBbSUK76hnLS6nNfE/WCvxkfeajNm5fd1I2S5UTwdrBftllEdPWbMmJPomU8ZGqPHyCWhJeAWxGnPKntX7o9rUWWct/Uzg==;
24:ojehugImnFQWaJdhshY8fiAVDWUWPFI/i3fkWSpbC9X7urn1XR3iJdwB5z4ay9oCivZ/AsO8K6tHhPLmdQRtF+4KUC+Xb2orqIqFgSHGYn4=;
7:3pKg5UAh1iCsQAHKwEPCEysIT9qB5CkjKU64OvWdScvbn0RJp0ybVoeKop7pctIfIscLvkB849IB87aFccEK4Fsmj04fGfF/r3aQwqGc5aiimC57qP7R8llSfHibcnRchHoWX8RFMHpKb3xC29u70bb+BEpgskdU0tgiJUKQY2M/cIi+/VidpRCYrBWpVt+PafH9iXTbO1nTfZDRhyYwRnyk8ccJZBiMcFKTcQB/Rp8GD+UYkXqepeme+EXARE8EeaO5CloG3RpaC68adOqSqD7yTvgGX0TAsOXU3sd5jHuoEQushnc+2uE9uMn/6p4u
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004);
DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT185;
H:SINPR04MB1949.apcprd04.prod.outlook.com; FPR:; SPF:None;
LANG:en;
x-ms-office365-filtering-correlation-id: e894460f-91a0-4ae9-2749-08d4773bf826
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045);
SRVR:PU1APC01HT185;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
SRVR:PU1APC01HT185; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT185;
x-forefront-prvs: 02622CEF0A
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
boundary="_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 07:11:21.4727 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT185
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 30 Mar 2017 10:58:27 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 07:11:26 -0000
--_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
>> If home users are not running their own full nodes, then home users have=
to trust and rely on other, more powerful nodes to represent them. Of cour=
se, the more powerful nodes, simply by nature of having more power, are goi=
ng to have different opinions and objectives from the users.
>I think you're conflating mining with node operation here. Node users onl=
y power is to block the propagation of certain things. Since miners also h=
ave a node endpoint, they can cut the node users out of the equation by lin=
king with eachother directly - something they already do out of practicalit=
y for propagation. Node users do not have the power to arbitrate consensus=
, that is why we have blocks and PoW.
You are only looking at technical aspects and missing the political aspect.
Node users decide what a Bitcoin is. It matters not how much hash power is =
behind a inflationary supply chain fork, full nodes protect the user from t=
he change of any properties of Bitcoin which they do not agree with. The ab=
ility to retain this power for users is of prime importance and is arguably=
what gives Bitcoin most of it's value. Any increase in the cost to run a f=
ull node is an increase in cost to maintain monetary sovereignty. The abili=
ty for a user to run a node is what keeps the miners honest and prevents th=
em from rewriting any of Bitcoin's rules.
If it's still difficult to grasp the above paragraph, ask yourself the foll=
owing questions,
- What makes Bitcoin uncensorable
- What gives confidence that the 21 million limit will be upheld
- What makes transactions irreversible
- If hashpower was king as you make it to be, why havn't miners making up m=
ajority hashrate who want bigger blocks been able to change the blocksize?
The market is not storing 10s of billions of dollars in Bitcoin despite all=
it's risks because it is useful for everyday transactions, that is a solve=
d problem in every part of the world (Cash/Visa/etc..).
Having said that, i fully empathise with your view that increasing transact=
ion fees might allow competitors to gain marketshare for low value use case=
s. By all means, we should look into ways of solving the problem. But all t=
hese debates around blocksize is a total waste of time. Even if we fork to =
2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction capacit=
y will still be too low for global usage in the medium-long term. The addit=
ional capacity from blocksize increases are linear improvements with very l=
arge systemic costs compared with the userbase and usage which is growing e=
xponentially. Lightning potentially offers a couple or orders of magnitude =
of scaling and will make blocksize a non-issue for years to come. Even if i=
t fails to live up to the hype, you should not discount the market innovati=
ng solutions when there is money to be made.
--_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p><br>
</p>
<div>
<div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-size:12=
.8px">>> </span><span style=3D"font-size:12.8px">If home users a=
re not running their own full nodes, then home users have to trust and rely=
on other, more powerful nodes to represent them. Of
course, the more powerful nodes, simply by nature of having more power, ar=
e going to have different opinions and objectives from the users.<br>
<br>
>I think you're conflating mining with node operation here. Node u=
sers only power is to block the propagation of certain things. Since =
miners also have a node endpoint, they can cut the node users out of the eq=
uation by linking with eachother directly - something
they already do out of practicality for propagation. Node users do n=
ot have the power to arbitrate consensus, that is why we have blocks and Po=
W.</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-size:12=
.8px"><br>
</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;">You are onl=
y looking at technical aspects and missing the political aspect.</span></di=
v>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;"><br>
</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;">Node users =
decide what a Bitcoin is. It matters not how much hash power is behind=
a inflationary supply chain fork, full nodes protect
the user from the change of any properties of Bitcoin which they do not ag=
ree with. The ability to retain this power for users is of prime importance=
and is arguably what gives Bitcoin most of it's value. Any increase in the=
cost to run a full node is an increase
in cost to maintain monetary sovereignty. The ability for a user to run a =
node is what keeps the miners honest and prevents them from rewriting any o=
f Bitcoin's rules.</span><br>
</div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;"><br>
</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;">If it's sti=
ll difficult to grasp the above paragraph, ask yourself the following quest=
ions,</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;">- What make=
s Bitcoin uncensorable</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;">- What give=
s confidence that the 21 million limit will be upheld</span></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family:=
"Comic Sans MS", fantasy, cursive; font-size: 10pt;">- What make=
s transactions irreversible</span></div>
<div dir=3D"ltr"><font face=3D"Comic Sans MS, fantasy, cursive"><span style=
=3D"font-size: 10pt;">- If hashpower was king as you make it to be, why
</span><span style=3D"font-size: 13.3333px;">havn't</span><span style=3D"fo=
nt-size: 10pt;"> miners making up majority hashrate who want bigger bl=
ocks been able to change the blocksize?</span></font></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><br>
</div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><font face=3D"Comic Sans MS=
, fantasy, cursive"><span style=3D"font-size: 13.3333px;">The market is not=
storing 10s of billions of dollars in Bitcoin despite all it's risks =
because it is useful for everyday transactions,
that is a solved problem in every part of the world (Cash/Visa/etc..).&nbs=
p;</span></font></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><font face=3D"Comic Sans MS=
, fantasy, cursive"><span style=3D"font-size: 13.3333px;"><br>
</span></font></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);"><font face=3D"Comic Sans MS=
, fantasy, cursive"><span style=3D"font-size: 13.3333px;">Having said that,=
i fully empathise with your view that increasing transaction fees might al=
low competitors to gain marketshare for
low value use cases. By all means, we should look into ways of solvin=
g the problem. But all these debates around blocksize is a total waste=
of time. Even if we fork to 2MB, 5MB, 10MB. It is irrelevant in the larger=
picture, transaction capacity will still
be too low for global usage in the medium-long term. The additional capaci=
ty from blocksize increases are linear improvements with very large systemi=
c costs compared with the userbase and usage which is growing exponent=
ially. Lightning potentially offers a
couple or orders of magnitude of scaling and will make blocksize a non-iss=
ue for years to come. Even if it fails to live up to the hype, you should n=
ot discount the market innovating solutions when there is money to be made.=
</span></font></div>
<div dir=3D"ltr" style=3D"color: rgb(0, 0, 0);">
<div><br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
--_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_--
|