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
|
Return-Path: <corey3@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 100A13EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 01:56:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49D33FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 01:56:01 +0000 (UTC)
Received: by igbjg10 with SMTP id jg10so34188154igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 18:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=wjJli8DMXaKA+mkxekWwAj4oS0yXjRR63dgMPkNyTu0=;
b=TE2sLSRD+5mvWuum8v6F2rxJr2LekusWgBKxsvqSJ1eLDwJBnCSDdK2ropD3UAwiix
9ZAUv9HSowYbiLxL79FswzThjqbxIa8NNS7UUL05sZXO6/NvMNK8oWSeyatgc51SC6mP
t6xjIbaUuuIwXDkHskKQsWdTTmjZWqah9Cgq5W7ssd+1OviRlqdsdnmjF62tDoJcBfiH
VE2AdSeRD7ytPtbl819eP5tetL2j2LeFYFD2Mn4TagX850haXsI8k0EVrliAJGn/6iMN
4A0HORcvAqx1yFxLLiPDDKkeykJEG00TWNKVvpSb8QUTlwCD/jrj62g3AFmUAZcrojlc
k4jw==
MIME-Version: 1.0
X-Received: by 10.50.143.37 with SMTP id sb5mr21520687igb.13.1439344560726;
Tue, 11 Aug 2015 18:56:00 -0700 (PDT)
Received: by 10.64.127.103 with HTTP; Tue, 11 Aug 2015 18:56:00 -0700 (PDT)
Date: Tue, 11 Aug 2015 18:56:00 -0700
Message-ID: <CAK_HAC9T391=uDHr+37R3NOrJEy=SSBzna1qXF2bO9+8nbcTQA@mail.gmail.com>
From: Corey Haddad <corey3@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135fe4e4067d2051d1385c5
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 12 Aug 2015 01:56:02 -0000
--001a1135fe4e4067d2051d1385c5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
wrote:
>Neither one of those assertions is clear. Keep in mind the goal is to have
>Bitcoin survive active censorship. Presumably that means being able to run
>a node even in the face of a hostile ISP or government. Furthermore, it
>means being location independent and being able to move around. In many
>places the higher the bandwidth requirements the fewer the number of ISPs
>that are available to service you, and the more visible you are.
>It may also be necessary to be able to run over Tor. And not just today's
>Tor which is developed, serviced, and supported by the US government, but =
a
>Tor or I2P that future governments have turned hostile towards and activel=
y
>censor or repress. Or existing authoritative governments, for that matter.
>How much bandwidth would be available through those connections?
>It may hopefully never be necessary to operate under such constraints,
>except by freedom seeking individuals within existing totalitarian regimes=
.
>However the credible threat of doing so may be what keeps Bitcoin from
>being repressed in the first place. Lose the capability to go underground,
>and it will be pressured into regulation, eventually.
I agree on the importance of having the credible threat of being able to
operate in the underground, and for the reasons you outlined. However, I
see that threat as being inherent in the now-public-knowledge that a system
like Bitcoin can exist. The smart governments already know that
Bitcoin-like systems are unstoppable phenomena, that they can operate over
Tor and I2P, that they can and do run without central servers, and that
they can be run on commodity hardware without detection. Bitcoin itself
does not need to constantly operate in survival-mode, hunkered down, and
always ready for big brother=E2=80=99s onslaught, to benefit from the prote=
ction of
the =E2=80=98credible threat=E2=80=99.
It=E2=80=99s important to accurately asses the level of threat the Bitcoin =
system
faces from regulation, legislation, and government =E2=80=98operations=E2=
=80=99. If we are
too paranoid, we are going to waste resources or forgo opportunities in the
name of, essentially, baseless fear. When I got involved with this project
in 2012, no one really knew how governments were going to react. Had an
all out war-on-Bitcoin been declared, I think it=E2=80=99s pretty safe to s=
ay the
structure of the network would look different than it does today. We would
probably be discussing ways to disguise Bitcoin traffic to look like VoIP
calls, not talking about how to best scale the network. In light of the
current regulatory climate surrounding Bitcoin, I believe the best security
against a state-sponsored / political crackdown to be gained at this time
comes from growing the user base and use cases, as opposed to hardening and
fortifying the protocol. Uber is a great example of this form of
security-though-adoption, as was mentioned earlier today on this mailing
list.
If there are security or network-hardening measures that don=E2=80=99t come=
at the
expense of growing the user base and use cases, then there is no reason not
to adopt them. The recent improvements in Tor routing are a great example
of a security improvement that in no meaningful way slows Bitcoin=E2=80=99s
potential growth. How does this relate to the Blocksize debate? Let=E2=80=
=99s
accept that 8 MB blocks might cause a little bit, and perhaps even a
=E2=80=98medium bit=E2=80=99 (however that is measured), of centralization.=
Although the
network might be slightly more vulnerable to government attack, if millions
more people are able to join the system as a result, I=E2=80=99d wager the =
overall
security situation would be stronger, owning to greatly decreased risk of
attack.
-Corey (CubicEarth)
--001a1135fe4e4067d2051d1385c5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-size:13px">On Tur, Aug 11, 2015 at 07:0=
8 AM,=C2=A0<b>Mark Friedenbach</b>=C2=A0via bitcoin-dev <<br></div><div =
style=3D"font-size:13px"><pre style=3D"white-space:pre-wrap"><a href=3D"htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_bla=
nk">bitcoin-dev at lists.linuxfoundation.org</a>> wrote:</pre></div><div=
style=3D"font-size:13px"><br></div><div style=3D"font-size:13px">>Neith=
er one of those assertions is clear. Keep in mind the goal is to have</div>=
<div style=3D"font-size:13px">>Bitcoin survive active censorship. Presum=
ably that means being able to run</div><div style=3D"font-size:13px">>a =
node even in the face of a hostile ISP or government. Furthermore, it</div>=
<div style=3D"font-size:13px">>means being location independent and bein=
g able to move around. In many</div><div style=3D"font-size:13px">>place=
s the higher the bandwidth requirements the fewer the number of ISPs</div><=
div style=3D"font-size:13px">>that are available to service you, and the=
more visible you are.</div><div style=3D"font-size:13px"><br></div><div st=
yle=3D"font-size:13px">>It may also be necessary to be able to run over =
Tor. And not just today's</div><div style=3D"font-size:13px">>Tor wh=
ich is developed, serviced, and supported by the US government, but a</div>=
<div style=3D"font-size:13px">>Tor or I2P that future governments have t=
urned hostile towards and actively</div><div style=3D"font-size:13px">>c=
ensor or repress. Or existing authoritative governments, for that matter.</=
div><div style=3D"font-size:13px">>How much bandwidth would be available=
through those connections?</div><div style=3D"font-size:13px"><br></div><d=
iv style=3D"font-size:13px">>It may hopefully never be necessary to oper=
ate under such constraints,</div><div style=3D"font-size:13px">>except b=
y freedom seeking individuals within existing totalitarian regimes.</div><d=
iv style=3D"font-size:13px">>However the credible threat of doing so may=
be what keeps Bitcoin from</div><div style=3D"font-size:13px">>being re=
pressed in the first place. Lose the capability to go underground,</div><di=
v style=3D"font-size:13px">>and it will be pressured into regulation, ev=
entually.</div><div style=3D"font-size:13px"><br></div><div style=3D"font-s=
ize:13px">I agree on the importance of having the credible threat of being =
able to operate in the underground, and for the reasons you outlined.=C2=A0=
However, I see that threat as being inherent in the now-public-knowledge t=
hat a system like Bitcoin can exist.=C2=A0 The smart governments already kn=
ow that Bitcoin-like systems are unstoppable phenomena, that they can opera=
te over Tor and I2P, that they can and do run without central servers, and =
that they can be run on commodity hardware without detection.=C2=A0 Bitcoin=
itself does not need to constantly operate in survival-mode, hunkered down=
, and always ready for big brother=E2=80=99s onslaught, to benefit from the=
protection of the =E2=80=98credible threat=E2=80=99.</div><div style=3D"fo=
nt-size:13px"><br></div><div style=3D"font-size:13px">It=E2=80=99s importan=
t to accurately asses the level of threat the Bitcoin system faces from reg=
ulation, legislation, and government =E2=80=98operations=E2=80=99.=C2=A0 If=
we are too paranoid, we are going to waste resources or forgo opportunitie=
s in the name of, essentially, baseless fear.=C2=A0 When I got involved wit=
h this project in 2012, no one really knew how governments were going to re=
act.=C2=A0 Had an all out war-on-Bitcoin been declared, I think it=E2=80=99=
s pretty safe to say the structure of the network would look different than=
it does today.=C2=A0 We would probably be discussing ways to disguise Bitc=
oin traffic to look like VoIP calls, not talking about how to best scale th=
e network.=C2=A0 In light of the current regulatory climate surrounding Bit=
coin, I believe the best security against a state-sponsored / political cra=
ckdown to be gained at this time comes from growing the user base and use c=
ases, as opposed to hardening and fortifying the protocol.=C2=A0 Uber is a =
great example of this form of security-though-adoption, as was mentioned ea=
rlier today on this mailing list.</div><div style=3D"font-size:13px"><br></=
div><div style=3D"font-size:13px">If there are security or network-hardenin=
g measures that don=E2=80=99t come at the expense of growing the user base =
and use cases, then there is no reason not to adopt them.=C2=A0 The recent =
improvements in Tor routing are a great example of a security improvement t=
hat in no meaningful way slows Bitcoin=E2=80=99s potential growth.=C2=A0 Ho=
w does this relate to the Blocksize debate?=C2=A0 Let=E2=80=99s accept that=
8 MB blocks might cause a little bit, and perhaps even a =E2=80=98medium b=
it=E2=80=99 (however that is measured), of centralization.=C2=A0 Although t=
he network might be slightly more vulnerable to government attack, if milli=
ons more people are able to join the system as a result, I=E2=80=99d wager =
the overall security situation would be stronger, owning to greatly decreas=
ed risk of attack.</div><div style=3D"font-size:13px"><br></div><div style=
=3D"font-size:13px">-Corey (CubicEarth)</div></div>
--001a1135fe4e4067d2051d1385c5--
|
