summaryrefslogtreecommitdiff
path: root/ab/fac6974711a849f46f5e71db96721bf9a9a240
blob: eb5260cad4da526bedeec8d7651b58bb0775ee56 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1UDYqV-0008F9-5G
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 Mar 2013 11:18:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.80 as permitted sender)
	client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
	helo=outmail149080.authsmtp.com; 
Received: from outmail149080.authsmtp.com ([62.13.149.80])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UDYqS-0001fs-IL for bitcoin-development@lists.sourceforge.net;
	Thu, 07 Mar 2013 11:18:47 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r27B0QLO002235 for <bitcoin-development@lists.sourceforge.net>;
	Thu, 7 Mar 2013 11:00:26 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 r27B0JJX026271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 7 Mar 2013 11:00:21 GMT
Date: Thu, 7 Mar 2013 06:00:18 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20130307110018.GA7491@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 34e5d989-8716-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
	P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXwJ1
	LRkLXVBSFQZ4AB0L Bh4UUBs8cANYeX5u ZEFqQHFbVVt/fUFi
	QwAWF2p0ZR0aAGAd VkJfdk1VcQdNflFG bgV6AHoFaHgPYXtm
	WlZqMmp0N2wHImEN GltQfApJGhlWE2Qq YxkYEjhqF0kCTCYo
	ZxUgJhYXEUAKNV8p MVo5MQAA
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: 1UDYqS-0001fs-IL
Subject: [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: Thu, 07 Mar 2013 11:18:47 -0000


--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

So with UTXO merkle-sum-fee-trees and fraud notices(1) we can
effectively audit the blocks produced by miners and provide a way for
SPV nodes to reject invalid blocks without requiring the whole
blockchain data.

Next step: How do we prevent censorship? Can we at all?

Basically while UTXO-style proofs allow anyone to determine if a block
is valid, it's fundementally still miners that choose what transactions
to accept into blocks in the first place. Unfortunately the very nature
of a blockchain is that it is meant to prove that transactions are
public and that a consensus exists about what transactions are
spendable, thus any attempt to hide the bare technical details, txins
and txouts, is futile.  Even using encryption doesn't work, because
assuming you convinced a miner to accept your encrypted transaction,
that just shifts the part that makes the transaction public to the act
of revealing the key, which again must be done publicly in the
blockchain to prove consensus.

As transaction volume makes running a validating node more expensive, we
can expect the number of independent pools to decrease, or at the very
least make monitoring those pools easier as volumes grow beyond what
technologies such as Tor can effectively accomodate. This provides the
opportunity to pressure the remaining, identifiable, independent miners
into accepting restrictions on what transactions can be mined.

It's also notably that auditable off-chain transaction systems are
vulnerable. All of the trustworthy ones that don't rely on trusted
hardware require at least some of their on-chain transactions to be
publicly known, specifically so that the total amount of reserves held
by off-chain transaction providers can be audited. At best you can use
Gregory Maxwell's suggestion of maintaining a "reserve" account backed
by funds that rarely move, where new deposits go to non-public addresses
and result in the depositor receiving funds from the reserve account,
but again, if the spendability of those funds is in question, the value
of the reserve itself is also in question. Additionally miners can block
fidelity bond sacrifice transactions easily; again a critical
technologies required to implement some types of off-chain transaction
systems, as well as for many other purposes.

Of course we can just assume that the current pseudo-anonymity of
transactions is "good enough", but consider the case of stolen coins:
even if the bulk of transactions are effectively anonymous, transactions
can always be made public delibrately and miners pressured into
preventing the movement of coins declared tainted.

Finally it's possible that some kind of chaum token system could be
implemented directly in the blockchain, but this has the problem that A:
no efficient ones are yet known, let alone demonstrated, and B: unless
non-chaum token systems are prohibited by a hard-fork with wide
adoption, the censorship risk is miners deciding to not mine any chaum
token transactions. It's easy to imagine a government deciding that
while they will accept transactions that occure on the public block
chain, and are thus at best pseudo-anonymous, are acceptable any attempt
to conduct truely anonymous transactions will be forbidden.


On the other hand, with small blocks the barriers to entry to becoming a
miner remain low, and mining anonymously behind low-bandwidth
anti-censorship technologies such as Tor remains feasible. Any attempt
by a major pool to censor, IE choose not to mine, a transaction will
naturally lead to an opportunity for an anonymous miner to get a profit
mining that transaction, thus we can expect transactions to be treated
fairly equally on a fee per KB basis. In addition, the ever present
possibility of this happening, further discourages large miners from
doing so in the first place, and in turn gives those miners additional
incentive to resist attempts to restrict what transactions they are
allowed to mine.

Of course off-chain transaction systems can still practice censorship of
transactions on their own, but because the decentralized blockchain
still exists communities subject to such censorship can always create
their own auditable and secure off-chain transaction systems for their
own use. Again, the existence of such systems creates economic
incentives to find ways to move value between all off-chain transaction
systems regardless of imposed restrictions, and again the overall
ability to transfer value freely is maintained.

1) https://bitcointalk.org/index.php?topic=3D137933.0

--=20
'peter'[:-1]@petertodd.org

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJROHNBAAoJEH+rEUJn5PoEhekH/1gLeE0TOw8TZ6HRvOOLiUzw
0PGAMvVkWY2BgtL9ERnzrq+7Qq5Vx0cUJPGQbB0WpEualSIYaVO3J8K0weI+CNlU
AJQKMM7X6avvZbrIamsdb8ET7/KhOnNBgMqgQFbUiCi1WVLJi+RWvF6xecBxVnyN
LdPym4TBkFheW8G7jyZ+pkMG2jI/vqGh+X/KVmlvAwYJZ7BhesNiDlF5eXCqxkdg
pMaNsYQdGYMBDqPHo5GSP3xTwG9UM8QdpjP//EnDG4IonYWEAgdHEzjpbODugYGV
hvjurRH5fYmvCTePaH9qZ1RAk6qJ6GtYgW0SV790O0h5oeyhhoMQORvPgwKK2C0=
=l0c8
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--