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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Wdi33-0001BM-N9
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 15:28:21 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.51 as permitted sender)
client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f51.google.com;
Received: from mail-oa0-f51.google.com ([209.85.219.51])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wdi32-0004FD-QN
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 15:28:21 +0000
Received: by mail-oa0-f51.google.com with SMTP id i4so4329583oah.24
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 Apr 2014 08:28:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.55.65 with SMTP id q1mr1898693obp.70.1398439695492; Fri,
25 Apr 2014 08:28:15 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Fri, 25 Apr 2014 08:28:15 -0700 (PDT)
In-Reply-To: <535A60FE.10209@gmail.com>
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>
Date: Fri, 25 Apr 2014 17:28:15 +0200
X-Google-Sender-Auth: dn7JludfizTWUR74NugPmtmR7Uc
Message-ID: <CANEZrP0y45eSVgbzXYmvYy1WEQNyd=tmC2EpZgGSB28poXSzDw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gareth Williams <gacrux@gmail.com>
Content-Type: multipart/alternative; boundary=089e015388484a2c3604f7df9d3b
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Wdi32-0004FD-QN
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: Fri, 25 Apr 2014 15:28:21 -0000
--089e015388484a2c3604f7df9d3b
Content-Type: text/plain; charset=UTF-8
>
> When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>
sure that money is yours - but only because the rules for interpreting
> data in the blockchain are publicly documented and (hopefully)
> immutable. If they're mutable then the PoW alone gives me no confidence
> that the money is really mine, and we're left with a much less useful
> system. This should be more sacred than the 21m limit.
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.
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 rules 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 "adding 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.
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.
So. The thing that protects your money from confiscation is not proof of
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.
--089e015388484a2c3604f7df9d3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">When you have a *bitcoin* TXn buried under 100 b=
locks you can be damn<br>
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
sure that money is yours - but only because the rules for interpreting<br>
data in the blockchain are publicly documented and (hopefully)<br>
immutable. If they're mutable then the PoW alone gives me no confidence=
<br>
that the money is really mine, and we're left with a much less useful<b=
r>
system. This should be more sacred than the 21m limit.</blockquote><div><br=
></div><div>Well, I think we should avoid the term "sacred" - not=
hing is sacred because we're not building a religion here, we're en=
gineering a tool.</div>
<div><br></div><div>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 cha=
nge the rules 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&=
#39;s easier for people to imagine what's happening if it's phrased=
as "adding more places after the decimal point" or something, bu=
t at the protocol level coins are represented using integers, so it'd h=
ave to be implemented as a multiply.</div>
<div><br></div><div>Would this be a violation of the social contract? A vio=
lation of all that is sacred? I don't think so, it'd just be sensib=
le engineering and there'd be strong consensus for that exactly because=
21 million <i>is</i>=C2=A0so arbitrary. If all balances and prices multipl=
y 100-fold overnight, no wealth is reallocated which would be the <i>actual=
</i>=C2=A0violation of the social contract:=C2=A0we just get more resolutio=
n for setting prices.</div>
<div><br></div><div>So. The thing that protects your money from confiscatio=
n is not=C2=A0proof of work. PoW is just a database synchronisation mechani=
sm. 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 mathematic=
al rule.</div>
</div></div></div>
--089e015388484a2c3604f7df9d3b--
|
