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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Wcz69-0006DV-5m
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 15:28:33 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.96 as permitted sender)
client-ip=62.13.148.96; envelope-from=pete@petertodd.org;
helo=outmail148096.authsmtp.net;
Received: from outmail148096.authsmtp.net ([62.13.148.96])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Wcz67-0005Hn-7H for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 15:28:33 +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 s3NFSOSP090302;
Wed, 23 Apr 2014 16:28:24 +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 s3NFSKcB051705
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 23 Apr 2014 16:28:22 +0100 (BST)
Date: Wed, 23 Apr 2014 11:28:18 -0400
From: Peter Todd <pete@petertodd.org>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Message-ID: <20140423152818.GF19430@savin>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="KJY2Ze80yH5MUxol"
Content-Disposition: inline
In-Reply-To: <CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e80bd6c7-cafb-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAEUGUUGAgsB AmIbWlJeUlV7W2E7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAmJ3 ZWVNIBl3dgJGfTBx YERnVj4OVEQoIUAu
RVMHRDtUeGZhPWMC 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: 1Wcz67-0005Hn-7H
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: Wed, 23 Apr 2014 15:28:33 -0000
--KJY2Ze80yH5MUxol
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 23, 2014 at 06:04:00PM +0300, Alex Mizrahi wrote:
> This is outright ridiculous.
>=20
> Zero-confirmation double-spending is a small problem, and possible
> solutions are known. (E.g. trusted third party + multi-sig addresses for
> small-value transactions.)
Also replace-by-fee scorched earth.
> On the other hand, protocol changes like described above might have
> game-theoretical implications which are non-trivial and hard to understan=
d.
To put it mildly. :) Beyond the obvious issues with adding mechanisms
for miners to vote on what blacklists they wish to apply, it's
interesting to consider how trying to make zeroconf transactions secure
directly is quite close to changing the block interval. Like the
blocksize that's a fundemental economic parameter of the system - how
low-latency and well connected you must be to be allowed to mine. Even
in a scheme where the punishment for allowing a double-spend was somehow
applied perfectly fairly, you'd still be favoring large well-connected
miners in a very similar way to reducing the block interval.
> The above approach works as long as the majority of hashpower is honest,
> > defined to mean, working to stop double spending. This is the same secu=
rity
> > property as described in the white paper, thus this introduces no new
> > security assumptions.
> >
>=20
> No. Bitcoin should work if miners are merely individually rational, i.e.
> they try to maximize their pay-offs without colluding with others.
It's worth noting that the academic efforts studying Bitcoin are
spending quite a bit of effort focused on the incentive compatibility of
various mechanisms in the protocol: https://github.com/citp/bitcoin-sok/iss=
ues/5
There's solid consensus in the academic community that Bitcoin can't
just depend on notions of "honesty" to work.
> I guess word "honest" might have different meanings, that can be a source
> of confusing.
> 1. Honest -- not trying to destroy bitcoin
> 2. Honest -- following rules which are not required by the protocol
What exactly those rules are is up for debate too. Right now if, say,
just 5% of Bitcoin miners were willing to accept Colored Coin
transactions you could still use Colored Coins. The other 95% may want
to block said transactions, but there's huge practical difficulties in
organizing a reorg and ensuring that everyone co-operates; miners have
strong incentives to defect if the consensus isn't assured as any miners
attempting to reorg are wasting their hashing power if it doesn't
succeed.
OTOH with a voting scheme the cost to propose that a specific block or a
transaction be blacklisted is much lower. In Mike's proposed scheme to
not just blacklist, but actually take coinbases it's downright
profitable. Rather than being a last resort option, it'll be easy for
miners to propose various things be blacklisted, if the vote goes
through, great, if it doesn't, no harm done. Obviously that makes
blacklists into a much more useful tool and greatly changes the
political landscape around them.
Remember, if you're operating a publicly known pool, and there's a
voting mechanism available to you to blacklist specific blocks, how are
you going to resist pressure from your local authorities to do just when
there's no cost to you to do so?
--=20
'peter'[:-1]@petertodd.org
0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7
--KJY2Ze80yH5MUxol
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTV9wOXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAyNzgwMzFmODZjNzEyNjVmNmVhZjFmZTljZTZjYzgzMWRj
NGY5NTY2NzZhN2E3ZjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftR8Af/cVCaxQQdLV7LB5bHOQ2H5NkD
tO1TXcu84lRxYjJx0CChOtcoI5oONcVtkNyM+pn+mrVNI/CbIqyBVQZmUW7CGc0m
zaSgZII/0dYPUQCi0kXoBrNTRADgvrOKB+/ef9MUVInkuH7iqJuwqSeqA6x4BSXB
kTL6VHFLT97Gkrtnw2c+0QmguZXSdw3DwvlL1E6eiwvxlyJwsXfjXsyFJwQ+cjpJ
o4WkPZ9EC1gNFpWrccCns0TCxCrG7cAAJ4dq1LPxUkfIjwe7Rk0/Ckye7ae3t3h8
Y8djr1OHoUsAQXhjjOQEeldwnzdTQInQQsuf6LG88mcm6S7AQjcln7Wc5BKw7Q==
=ZBka
-----END PGP SIGNATURE-----
--KJY2Ze80yH5MUxol--
|
