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
|
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 <pete@petertodd.org>) id 1UEbTr-0002oB-IS
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Mar 2013 08:19:43 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UEbTp-0003PF-BS for bitcoin-development@lists.sourceforge.net;
Sun, 10 Mar 2013 08:19:43 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r2A8JXKT020019; Sun, 10 Mar 2013 08:19:33 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r2A8JSb7013044
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 10 Mar 2013 08:19:30 GMT
Date: Sun, 10 Mar 2013 04:18:57 -0400
From: Peter Todd <pete@petertodd.org>
To: Daniel Lidstrom <lidstrom83@gmail.com>
Message-ID: <20130310081857.GA2609@savin>
References: <20130307110018.GA7491@savin>
<CANEZrP0MHA_Mv37DSv=CLBWLHo_-ajRgNRd1-4EGJ2GZvTxiJQ@mail.gmail.com>
<20130307183035.GA9083@savin>
<CANEZrP3oHropYJ1zEXCw1QdtRimK_JxeohOh1yNkPxzZohcXnA@mail.gmail.com>
<CADjHg8EQbmdpFE6yxq5tvkn49WUGz2Yv3WEeWzG+LMPAMAHCww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <CADjHg8EQbmdpFE6yxq5tvkn49WUGz2Yv3WEeWzG+LMPAMAHCww@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3bd4a88f-895b-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwIUFVQGAgsB AmUbW1xeUVR7WmI7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqA20J fH1MVRlzdAVCfDBx Zk9kWz5YDhB+JE51
FFNcHGhUeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4vFyQz SlUIGTIkHlZNTiM/
ZxcrLEUbBl0RM11a
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UEbTp-0003PF-BS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Large-blocks and censorship
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: Sun, 10 Mar 2013 08:19:43 -0000
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 07, 2013 at 02:31:10PM -0700, Daniel Lidstrom wrote:
> My views on censorship resistance in the face of scaling:
>=20
> 1) I expect if I'm not careful about preserving my privacy with the way I
> use Bitcoin, then I will always run the risk of being censored by miners.
> This means connecting to the network anonymously, not reusing addresses,
> and perhaps even mixing my coins. The onus is on me here to avoid
> censorship, but I'm optimistic that this privacy preservation can be made
> pretty automatic.
Yes, but keep in mind the meta risk, which is that as Bitcoin becomes
centralized one of the types of transactions that will be censored are
ones that preserve your privacy. For instance, as it costs thousands of
dollars to setup a mining pool, and hence mining pools also become quite
visible, it would be very easy for local governments to start doing
things like specifying that transactions must be accompanied with a
proof of identification. With that proof of course Bitcoin can remain
totally legal, and the pool in business.
> 2) I expect anonymity systems to scale to accommodate Bitcoin full nodes,
> not Bitcoin to stay small to avoid putting pressure on anonymity systems =
to
> scale.
Why do you expect that? It's always harder to hide a large amount of
bandwidth than a small one, and stenography is limited by the bandwidth
of the data it's hiding it. HD video streams aren't going to require
more bandwidth in the future.
> 3) If 2 is too tall an order, then mining in a pool is always an option.
> There should always be some countries in the world free enough to allow
> mining pools to operate, and miners in countries that ban Bitcoin can
> simply connect to these anonymously. If not, then Bitcoin is toast anywa=
y,
> is it not? If these miners are really interested in avoiding censoring
> transactions, then they will do their due diligence and choose a pool that
> doesn't do this. But even if they don't, censorship can be personally
> avoided by following 1.
Right now the thing that keeps pools honest is that setting up another
pool is pretty easy; note how most pools are run as hobbyist projects.
Similarly you can always use P2Pool, which is totally decentralized.
But if running the validating node required to run a pool costs
thousands of dollars that competition just isn't there anymore and
starting a new pool isn't an option. Remember there will be a chicken
and egg problem in that the new pool has thousands of dollars in costs,
yet no hashing power yet.
As for constantly moving countries, The Pirate Bay is in the same
position, and as well as they've done, they still wind up getting shut
down periodically. Do you really want access to your funds contingent on
some highly visible mining pools, constantly wondering if their local
government will change their mind?
Anyway, seems that my question was answered: There aren't any clever
technical ways to avoid censorship if validating nodes and mining pools
are centralized.
--=20
'peter'[:-1]@petertodd.org
--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRPEHxAAoJEH+rEUJn5PoEOa4H/jUM7308oLofqZqhMjREMcmx
iUyd4d0+cqVcm6yTU27TvF5KAJR2R+SLK5ZvzdbD6UijyPLiNY0xnEY9GrQa7vUA
+GntLmZ4rOmF0sXFIGj2YyzUaq33MJr27NkNoZcAVOBcFx60/VIf7t3oDkMVJvN/
zU+4fEcBfoehy9mNRfprpJd2AbnAbjEnlUIcNnxqKLl8niAgMP+t7CKSk4eOqvn3
JiRERtZgSTMSkd1WOwbWvZP21jMeFdUHlq50sTFr9ICLceXiq1eQV3r60pR3ncdy
fpw6XA2aHiNZVMlb60gBcWh2e+xmqFC4LyhMLK2N+k4NET1AyBf6/j8DUJCMzqE=
=ErBP
-----END PGP SIGNATURE-----
--VS++wcV0S1rZb1Fb--
|
