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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gacrux@gmail.com>) id 1We1Vz-0003pO-K2
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 12:15:31 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.182 as permitted sender)
client-ip=209.85.223.182; envelope-from=gacrux@gmail.com;
helo=mail-ie0-f182.google.com;
Received: from mail-ie0-f182.google.com ([209.85.223.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We1Vy-0006ow-Nl
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 12:15:31 +0000
Received: by mail-ie0-f182.google.com with SMTP id tp5so1494044ieb.41
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 05:15:25 -0700 (PDT)
X-Received: by 10.42.23.82 with SMTP id r18mr12618367icb.43.1398514525188;
Sat, 26 Apr 2014 05:15:25 -0700 (PDT)
Received: from [192.168.1.150] (60-240-212-53.tpgi.com.au. [60.240.212.53])
by mx.google.com with ESMTPSA id kr5sm5598943igb.9.2014.04.26.05.15.23
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 26 Apr 2014 05:15:24 -0700 (PDT)
Message-ID: <535BA357.6050607@gmail.com>
Date: Sat, 26 Apr 2014 22:15:19 +1000
From: Gareth Williams <gacrux@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com> <CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com> <CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com> <CAC1+kJNE+k4kcTj3Ap0-A=PdD1=+-k5hN4431Z99A+S7M3=BoQ@mail.gmail.com> <CANEZrP3obO9rXKcX+G7bs2dd3AqEFOsO8pCUF6orrkGeZyr9Ew@mail.gmail.com> <CAC1+kJPxwTm6qvh2GYT2XMJAPD5O4WHLOGBTRmchRmZ2wS4MSg@mail.gmail.com> <CANEZrP2PZFVvH3oJyLW80e9W_Fa4bvqQ25E7T-ZFFuG9u-q1hQ@mail.gmail.com> <5359E509.4080907@gmail.com> <CANEZrP0bKe-=T5ps0myLZjo60tv2mkm3Bw0o4e-9y7zb1h5eDg@mail.gmail.com> <535A60FE.10209@gmail.com>
<CANEZrP0y45eSVgbzXYmvYy1WEQNyd=tmC2EpZgGSB28poXSzDw@mail.gmail.com>
In-Reply-To: <CANEZrP0y45eSVgbzXYmvYy1WEQNyd=tmC2EpZgGSB28poXSzDw@mail.gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=378E4544
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC"
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gacrux[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1We1Vy-0006ow-Nl
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: Sat, 26 Apr 2014 12:15:31 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 26/04/14 01:28, Mike Hearn wrote:
> When you have a *bitcoin* TXn buried under 100 blocks you can be da=
mn
>=20
> sure that money is yours - but only because the rules for interpret=
ing
> data in the blockchain are publicly documented and (hopefully)
> immutable. If they're mutable then the PoW alone gives me no confid=
ence
> that the money is really mine, and we're left with a much less usef=
ul
> system. This should be more sacred than the 21m limit.
>=20
>=20
> Well, I think we should avoid the term "sacred" - nothing is sacred
> because we're not building a religion here, we're engineering a tool.
Are you sure there isn't room for just a touch of "religion"? :) As you
state below, all that protects my money from confiscation is strong
group consensus that it's mine - "a social rule, not a mathematical one."=
Everything ultimately balances on that. People being a little bit
"religious" about following the protocol faithfully are the linchpin of
Bitcoin security, not PoW.
> Consider a world in which 1 satoshi is too valuable to represent some
> kinds of transactions, so those transactions stop happening even though=
> we all agree they're useful. The obvious solution is to change the rule=
s
> so there can be 210 million coins and 10x everyones UTXOs at some
> pre-agreed flag day. We probably wouldn't phrase it like that, it's
> easier for people to imagine what's happening if it's phrased as "addin=
g
> more places after the decimal point" or something, but at the protocol
> level coins are represented using integers, so it'd have to be
> implemented as a multiply.
Agree.
> Would this be a violation of the social contract? A violation of all
> that is sacred? I don't think so, it'd just be sensible engineering and=
> there'd be strong consensus for that exactly because 21 million /is/ so=
> arbitrary. If all balances and prices multiply 100-fold overnight, no
> wealth is reallocated which would be the /actual/ violation of the
> social contract: we just get more resolution for setting prices.
Wholeheartedly agree. "21 million" is just shorthand for the
preservation of artificial scarcity. No rational person could argue that
what you described violates the social contract.
I do see what you're driving at - that there exists a situation where it
would be justified to change the interpretation of data in existing block=
s.
But, please consider: if I controlled a single UTXO worth 1% of the
total money supply before your change, the network would still recognise
that I control a single UTXO worth 1% of the total money supply after
your change. So you haven't really changed the interpretation of
existing blocks at all there. It's just semantics :)
Contrast this with invalidating a coinbase before maturity, which
clearly has a very real impact. At the point the vote passes, you're ***
sidestepping the PoW mechanism and rewriting the meaning of an existing,
validated block ***.
> So. The thing that protects your money from confiscation is not proof o=
f
> work. PoW is just a database synchronisation mechanism. The thing that
> protects your money from confiscation is a strong group consensus that
> theft is bad. But that's a social rule, not a mathematical rule.
Agree. That's my whole point :)
I recognise my security is in the hands of the users (the economic
majority.) Tomorrow they could all decide to patch their nodes to
reallocate my UTXOs, and there's not a damn thing I could do about it,
PoW and private keys notwithstanding. I must simply trust that they will
not do this.
So we can have:
1. "Neutral Bitcoin", where everyone is committed to prevention of theft
by following a simple set of mathematical rules which treat all
validated blocks as equal.
Or:
2. "Political Bitcoin", where everyone is committed to prevention of
theft based on human judgements, and the contents of some validated
blocks are more equal than others.
I recognise that the latter allows for a lot of flexibility in combating
fraud, but with (substantial) due respect, it isn't Bitcoin.
-Gareth
--O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTW6NXAAoJEEY5w2E3jkVEok0IAI8HHIGvA9UIzeDaCZtdGDAn
8xO0rwkI/d2CFDn/imSk1daLC5/EwcG1+4cba270VTJyKVq8r4tbQpvZg4/IwQLb
qa5Mu1W8tVwIRkQ/xbfvyskbq48+eUJ7EqE1Glr9cAdsydFaOWZWomQJjTyK1xPM
c+fP8dIbMb0AiOoZmTJp5cN54CA9b4mVL85TAcz7E6Vf8/Y4wM3GTLA4U42J9mh1
9Sfvfe9cylhlbFhBXJlg/7JLi3W43T0T9nQYF0qjd3petcBDoE925xLQFYPcpo9a
kJDIk8oMYX1rOGuoCHDqALu6KFdEovQG64iQLhLoOcmJ1+/vcCa9N3ZjpTOe8MM=
=9xfv
-----END PGP SIGNATURE-----
--O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC--
|
