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
|
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 1WCXw5-0000HK-MF
for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 17:12:53 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.77 as permitted sender)
client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
helo=outmail149077.authsmtp.com;
Received: from outmail149077.authsmtp.com ([62.13.149.77])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WCXw4-0004I2-3U for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 17:12:53 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s19HCjD7067843
for <bitcoin-development@lists.sourceforge.net>;
Sun, 9 Feb 2014 17:12:45 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 s19HCfJq090824
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Sun, 9 Feb 2014 17:12:43 GMT
Date: Sun, 9 Feb 2014 12:12:14 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20140209171214.GA20126@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 63f7ddbb-91ad-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXwx1
Jh0bXVBSFQF4ABsL BxwUVh08cANYeX5u ZEFqQHFbVVt/fUFi
QwAXFGR+FjEaKWAW UEhac01VcQNCeFFD aQZ4ACdfM3gOZys0
WlZqMmt0bGlRIWEN GltQfAobGB1WEmUq ahUIEDkjEEFNTCI1
NBEgMUMHVF0AKVk/ NBM8QV0COhMfQhVE GEpADDJDKkJp
X-Authentic-SMTP: 61633532353630.1024: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: 1WCXw4-0004I2-3U
Subject: [Bitcoin-development] Embedded consensus system upgrade procedures
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: Sun, 09 Feb 2014 17:12:53 -0000
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
The Problem
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We have an embedded consensus system and we want to be able to upgrade
it with new rules. There inevitably will be a transition period where
some users use clients that interpret the new rules, while others only
interpret the old rules. Since we only rely on the host consensus system
for timestamped proof-of-publication the the miner-vote soft-fork
upgrade mechanism;(1) there are no validating miners in the system to
whome trust can be outsourced.
We have a problem: messages encoding actions, such as moving as asset
=66rom one owner to another, can be published on the the blockchain
according to new and old rules simultaneously, double-spending the
asset. Potentially a user with the old v1 software may be tricked into
accepting an asset when the consensus of the v2 software is that the
asset has already been spent, and the v1-visible transaction is invalid.
Solution
=3D=3D=3D=3D=3D=3D=3D=3D
Split actions into a separate "decrement" and "increment" operations,
and ensure that v1 software can see the "decrement" of a balance, spend
of a transaction output etc. even if it does not see the corresponding
increment operation. This solves the double-spend problem and ensures v1
users can't be ripped off. With obvious analogy to the PoW case, we will
refer to this general principle as a embedded consensus system
soft-fork.
Note how with the Colored Coins technology this principle happens
implicitly and with miner validation: colored coins are valid
transaction outputs known to the host consensus system and moving them
=66rom one owner to another is guaranteed to result in the desctruction of
the colored coin from the point of view of any older software version.
Older software that does not support the newer colored coin kernel
specified by the new asset definition will simply see the respective
coins be destroyed in invalid transactions. Note how this implies that
asset definitions created by issuers should be careful to ensure that
kernels chosen should be designed such that the actioned specified by
one kernel can-not be interpreted differently by another; kernels should
be clearly incompatible with each other.
Balance-based systems
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mastercoin is a balance-based system where transactions increment and
decrement balances. Being balance-based, and lacking pruning, an even
simplier "scorched earth" approach will be used where each address is
associated with a maximum version number seen by transactions signed by
the address. Addresses with a max version number higher than what the
software understands are considered to be null and have no value of any
kind. (counterparty would be wise to do the same)
Upgrading implementation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Implementations should record in their databases the blockhash
associated with transactions that were not recognized yet affected the
state of the consensus. For instance a colored coin implementation
should record the blockhash and transaction ID where a given coin was
destroyed in an invalid transaction; after upgrading these "last
transaction understood" markers can be used to replay blockchain data to
arrive at the new consensus.
Similarly in the case of the Mastercoin system balances associated with
addresses that have been frozen should be still allowed to increment so
that replaying blockchain data from the last recognized transaction
arrives at a upgraded consensus.
As an aside, any embedded consensus system would be wise to have a way
of generating a master digest representing the state of the consensus in
the database. The Bitcoin Core gettxoutsetinfo command is a good model,
which provides hash_serialized, a digest representing the entire UTXO
set. In all systems this is useful for ensuring that different
implementations and instances have in fact arrived at a consensus.
1) BIP-16, Pay to Script Hash,
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
--=20
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
--G4iJoqBmSsgzjUCe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJS97btXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3NTgyOWY2MTY5Yzc5ZDdkNWFhYTIwYmZhOGRhNmU5ZWRi
MjM5M2M0Zjg2NjJiYTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftlogf/ZXzBTm0mvXa8x+mhe02Ea9Ju
5Z67uXq9LaVaGjCp1YoI+sG9/iIITCJB72nmZroxGXd8LA27zqylmp4i6bkP1qFS
XKRlFVsIgG1rGj27mHowofy5t/FanPIxE3CBXT2cAWgKUhU19p7TO7Bpsxy4FHFJ
nWI24w4ZX6RVnYCzCfy++WyOBs+69ZBjCho9FGL4VgfPJhgAI9RqdjHD9DnbBSkj
dAHotBDlpus7T9Ah4Eal+BbjmCLdX6Hkl3ETfgVCVKFGEipzpcIBWZGO1eQw0WFX
hr/lwoefRtve8ZLWtpA36gvxB7TL2SmFtJ7oNwEclhwVJ+IyFzmRlBB9LMq4PQ==
=o/Nn
-----END PGP SIGNATURE-----
--G4iJoqBmSsgzjUCe--
|
