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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DC9EE7A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Apr 2017 13:26:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com
[209.85.161.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79813A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Apr 2017 13:26:37 +0000 (UTC)
Received: by mail-yw0-f171.google.com with SMTP id i203so48651365ywc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Apr 2017 06:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=FUc6PEYUrgKSnEMjBJxK16wGrcOxvgm+s5dlP2s+YOI=;
b=JhGvFo5Fr/UThrDyX/y7dowFZ8GykU5E8D+lFSLWkc252FqdLb6dsyzq89MvFhQW1n
oWaqrHiRupTv4BYujOOsEa9J/8t9DdKjsr/JZXiJfS+u5BRMRpsWQFAV5KFUnkU39Bb1
sTDq7w38T5HfdpGrgpCMg6IWsdRWyvNOB7w67hnxjyE+ACfmf1qchk9ltpSjaymX5HyT
xi2jRADzdkFFSwoPwj3JnAfTQ3CwQPcQ3IHRFRBpy0i2DV3p88t3wSw/ZCb4G/PW/S3s
5LFMf6hL2c3poERaQdGCQzP6u1OlPDUxMmZQzJcdSJwaJZ29+bvEa99Dv996bqJSFIXj
cmhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=FUc6PEYUrgKSnEMjBJxK16wGrcOxvgm+s5dlP2s+YOI=;
b=EHhiCbongk5oGOdTL/ESrdiC3U+2kXcVxlHi9pNTGiRrXamWpgpzuL4XZSvxBSG95Q
WkaYniVifoveH+lKAqi6L2mZAAPw78Pv15yoggwGqy5HnQWCiLHgHhHhJw2Tv9wwuKxR
VRmiF8YFScbKJDQbAwmQozkZhb5YrjC+Bg04D6WR+Hsjmh/mdthJy4y3M+IhwaIc5Zjs
XNo3yBUZ6OTszuiXhGs4oa2/rSi4fJ0O3J1OAUqgKcGflSNtpNj7uGipaKKgMdbUsEg8
QJlAo1xHFwv/J2WrUZXj3tbpI3Nu5MsnY1UDD7rJ16nqNWAWcDJ/4kdDeU0OOel6HjT8
byrg==
X-Gm-Message-State: AFeK/H0B50kM+PF2pgJS4FiiCqjblqP+yRljBsp9A+qeiZtcYbQwRy4LmbBTLUz7zya1ZFhzdAvgBiXeg2ssbg==
X-Received: by 10.129.55.129 with SMTP id e123mr5904024ywa.251.1491053196601;
Sat, 01 Apr 2017 06:26:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.123.135 with HTTP; Sat, 1 Apr 2017 06:26:35 -0700 (PDT)
Received: by 10.37.123.135 with HTTP; Sat, 1 Apr 2017 06:26:35 -0700 (PDT)
In-Reply-To: <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
References: <CABerxhFY8NoA6sSiz1oZ=01Di8n9+QR1xE6NNtxvm=Ov1bGhWQ@mail.gmail.com>
<9eb001f8-7623-3c79-41bb-7ed6e45b43ae@voskuil.org>
<CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
<CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Sat, 1 Apr 2017 15:26:35 +0200
Message-ID: <CAAt2M18sPfFpEo2YySgouhBZWv8KvDgg2HcNpoGuD4fcU2Z_iA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=001a1149d3d81fefd3054c1ae055
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Rodney Morris <rodney.morris@gmail.com>
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: Sat, 01 Apr 2017 13:26:38 -0000
--001a1149d3d81fefd3054c1ae055
Content-Type: text/plain; charset=UTF-8
Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote:
> If the obsession with every personal computer being able to run a
> fill node continues then bitcoin will be consigned to the dustbin
> of history,
The cause of the block size debate is the failure to understand the
Bitcoin security model. This failure is perfectly exemplified by the
above statement. If a typical personal computer cannot run a node
there is no security.
If you're capable of running and trusting your own node chances are you
already have something better than a typical personal computer!
And those who don't have it themselves likely know where they can run or
access a node they can trust.
If you're expecting average joe to trust the likely not updated node on his
old unpatched computer full of viruses, you're going to have a bad time.
The real solution is to find ways to reduce the required trust in a
practical manner.
Using lightweight clients with multiple servers have already been
mentioned, Zero-knowledge proofs (if the can be made practical and stay
secure...) is another obvious future tool, and hardware wallets helps
against malware.
If you truly want everybody to run their own full nodes, the only plausible
solution is managed hardware in the style of Chromebooks, except that you
could pick your own distribution and software repository. Meaning you're
still trusting the exact same people whose nodes you would otherwise rely
on, except now you're mirroring their nodes on your own hardware instead.
Which at most improves auditability.
--001a1149d3d81fefd3054c1ae055
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev&qu=
ot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>>:<br type=3D"attribution"><blockquote cl=
ass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<div class=3D"quoted-text"><br>
On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote:<br>
> If the obsession with every personal computer being able to run a<br>
> fill node continues then bitcoin will be consigned to the dustbin<br>
> of history,<br>
<br>
</div>The cause of the block size debate is the failure to understand the<b=
r>
Bitcoin security model. This failure is perfectly exemplified by the<br>
above statement. If a typical personal computer cannot run a node<br>
there is no security.=C2=A0</blockquote></div></div></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">If you're capable of running and trusting =
your own node chances are you already have something better than a typical =
personal computer!=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>And those who don't have it themselves likely know where they can run =
or access a node they can trust.=C2=A0</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">If you're expecting average joe to trust the likely not =
updated node on his old unpatched computer full of viruses, you're goin=
g to have a bad time.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">The real solution is to find ways to reduce the required trust in a pra=
ctical manner.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Usi=
ng lightweight clients with multiple servers have already been mentioned, Z=
ero-knowledge proofs (if the can be made practical and stay secure...) is a=
nother obvious future tool, and hardware wallets helps against malware.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">If you truly want ev=
erybody to run their own full nodes, the only plausible solution is managed=
hardware in the style of Chromebooks, except that you could pick your own =
distribution and software repository. Meaning you're still trusting the=
exact same people whose nodes you would otherwise rely on, except now you&=
#39;re mirroring their nodes on your own hardware instead. Which at most im=
proves auditability.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"></blockquote></div></div></div></div>
--001a1149d3d81fefd3054c1ae055--
|
