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
|
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 1WdLBy-0004zU-4h
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 15:04:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.43 as permitted sender)
client-ip=62.13.149.43; envelope-from=pete@petertodd.org;
helo=outmail149043.authsmtp.co.uk;
Received: from outmail149043.authsmtp.co.uk ([62.13.149.43])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WdLBs-0003gd-8o for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 15:04:02 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3OF3nNc015997;
Thu, 24 Apr 2014 16:03:49 +0100 (BST)
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 s3OF3gP5010863
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 24 Apr 2014 16:03:44 +0100 (BST)
Date: Thu, 24 Apr 2014 11:03:37 -0400
From: Peter Todd <pete@petertodd.org>
To: Christophe Biocca <christophe.biocca@gmail.com>
Message-ID: <20140424150337.GA24314@savin>
References: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
<CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
<CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com>
<CAAS2fgQV0=QfCWhwVh6-mw=eg9MDd1E21P_7rFAnGp0P43c1Fw@mail.gmail.com>
<CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com>
<CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com>
<CANEZrP18=Y5EBcfR-sHumVvU3-yqYr1tuhr_J4ieG817HOpE=g@mail.gmail.com>
<20140424134441.GE16884@savin>
<CANEZrP0Qmmrs5dzQ8N6FGL1K3W0A0XWBqtkPTFOgU_rXDvc+sQ@mail.gmail.com>
<CANOOu=8XLdS-v-xULrv8Y5XukapCafTLDGa0M0q_W1speb2Ykg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G"
Content-Disposition: inline
In-Reply-To: <CANOOu=8XLdS-v-xULrv8Y5XukapCafTLDGa0M0q_W1speb2Ykg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: a1aea8fe-cbc1-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAYUGUUGAgsB AmIbWlJeUF57XWY7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAmN3 BUl+Vxlzdw1AezBx ZkJqWz4KXRUvJE4r
F1MHRz4HeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4gGT86 TRkZEH01EEQBQyI4
JgAnLVhUAEFZPkQp Olw8Q1sXPlc8CwtY ElAvSCZFO1AKRDFD
X-Authentic-SMTP: 61633532353630.1023: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: 1WdLBs-0003gd-8o
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
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, 24 Apr 2014 15:04:02 -0000
--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
> Actually Peter, coinbase confiscations are a much worse mechanism for
> enforcement of widespread censorship rules than simple orphaning. They
> lose their power when the transaction miners are punished for can
> build up over time without losing their usefulness:
<snip>
> Of course, in such a dystopian future, orphaning would be the
> enforcement mechanism. It would be stupid to rely on coinbase
> reallocation/burning to do this task when the existing tools work so
> much better.
I don't disagree with you at an end stage, but the thing with coinbase
blacklists/confiscation is because it's a voting mechanism the initial
stages of enforcing widespread censorship rules with it are much easier.
For instance, if a 10% pool that has been forced/wants to blacklist
certain transactions can do so, and then vote to blacklist blocks that
do not abide by that blacklist. Casting that vote does them no harm.
Every time another pool joins the blacklist, there's no harm to them to
doing so. At some point they will reach a majority, which causes the
blacklist to actually apply. The whole process happens smoothly, letting
the blacklist be applied safely and easily. With orphaning/reorging on
the other hand you just can't be sure that the other miners will
actually adopt it, making adoption risky.
Of course, that's above and beyond the fact that you can't prove a
Finney attack happened to a third-party, making it easy to attack
smaller miners with Sybil attacks, get them creating blocks with
double-spends in them, and using that as an excuse to punish them.
> What's interesting is that this mechanism is especially tailored to
> blocking time sensitive transactions (that need to be confirmed
> now/soon, or are worthless), such that their total out-of-band fees
> can't build up over time. Double spending is one such category. I'm at
> a loss to come up with something else, but maybe someone has a good
> example?
Decentralized markets are a great example: the bids and orders they
depend on are time-senstive and become much less valuable if they get
delayed greatly.
--=20
'peter'[:-1]@petertodd.org
0000000000000000091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b
--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTWSfFXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwOTFhZTU4OWMwMzRiYzA0NjZlMmZlY2E1MWRjMDE4YmIy
YzMzMDNlOGFiODY0OGIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvNYAf/SzKD2sONRQsZX74ZimhXMZJa
GsCYJKIH6ZYU6ToL93jotCSKYR+iuRhxRIvYYI1JmCdVEwXbLtuMJfRmM4ufuy6A
RtSGrhwWFJ4h1rSOC8aBReJ9dg5/4Y+YlQjdlkejZKTz2QqVcr/h+smaJpHV5O+6
mdj15H6Ziyv5gE62slsz2AvW9vzfJqLSX9/Mr/EPAsLlZQe8PCdzfJtdvHswtPS9
ZuWR6mFtmcTjh4Pxd2YVjXMMmtvr3ndrxRE9Q2TafT1BR0yClKMbLz/bbeOVB7iM
OwppTqiBTbYIKCqxnl0Iu9r4hoGBY53ZiHrswfXuoiD20ZUKwEm6tHAkuzD4BA==
=crLw
-----END PGP SIGNATURE-----
--k1lZvvs/B4yU6o8G--
|
