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
|
Return-Path: <el33th4x0r@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 81637129A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 20:08:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com
[209.85.192.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8D3717A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 20:08:56 +0000 (UTC)
Received: by mail-qg0-f43.google.com with SMTP id e32so99286361qgf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 12:08:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=M5Ogjq7YCqZF5/9vVQzfclinlZ9KEBcd0DIDVR6X11Y=;
b=urchvR727x1Dnur3Imm1o9+o7wdJndZFi4Jh+RuSr3RYhEdbBQqkhPSGgsoLbil35I
9eax8o3l+8c/b99d2L5MNK3MUkqsIfTGvOWzKqPmPPRIp5WvktdDiJ4JmMx1lyJU6PaO
+YgDuhtYuGm2GCyrojqMzsLo+bTepsC3V1Lm4+QqgtV5vtEsklXzoiMA+aQoOL+TzCpg
iVnhZHnFIED4yZN14qIMeOgZt3I2aezyv0FVU1yRAthj7Y4Lang7ql4gZ60itNT2HZeX
AZxut2wTbLW9NNePiyMO3VRCFVUTUyOD9Q5G3VPfUuyANOxI1W9dP4PE1yKd0eOKKdgQ
6lnw==
X-Received: by 10.140.94.56 with SMTP id f53mr88506772qge.0.1451506135838;
Wed, 30 Dec 2015 12:08:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.29.73 with HTTP; Wed, 30 Dec 2015 12:08:36 -0800 (PST)
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Wed, 30 Dec 2015 15:08:36 -0500
Message-ID: <CAPkFh0tj4cXYuk8=8QJOP5z4qea6bv_sELhkfHO6nU16mMnnZA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11466d1c9db83b0528231b60
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] How to preserve the value of coins after a fork.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2015 20:08:57 -0000
--001a11466d1c9db83b0528231b60
Content-Type: text/plain; charset=UTF-8
Ittay Eyal and I just put together a writeup that we're informally calling
Bitcoin-United for preserving the value of coins following a permanent fork:
http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/
Half of the core idea is to eliminate double-spends (where someone spends a
UTXO on chain A and the same UTXO on chain B, at separate merchants) by
placing transactions from A on chain B, and by taking the intersection of
transactions on chain A and chain B when considering whether a payment has
been received.
The other half of the core idea is to enable minting of new coins and
collection of mining fees on both chains, while preserving the 21M maximum.
This is achieved by creating a one-to-one correspondence between coins on
one chain with coins on the other.
Given the level of the audience here, I'm keeping the description quite
terse. Much more detail and discussion is at the link above, as well as the
assumptions that need to hold for Bitcoin-United.
The high bit is that, with a few modest assumptions, it is possible to
create a cohesive coin in the aftermath of a fork, even if the core devs
are split, and even if one of the forks is (in the worst case) completely
non-cooperative. Bitcoin-United is a trick to create a cohesive coin even
when there is no consensus at the lowest level.
Bitcoin-United opens up a lot of new, mostly game-theoretic questions: what
happens to native clients who prefer A or B? What will happen to the value
of native-A or native-B coins? And so on.
We're actively working on these questions and more, but we wanted to share
the Bitcoin-United idea, mainly to receive feedback, and partly to provide
some hope about future consensus to the community. It turns out that it is
possible to craft consensus at the network level even when there isn't one
at the developer level.
Happy New Year, and may 2016 be united,
- egs & ittay
--001a11466d1c9db83b0528231b60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ittay Eyal and I just put together a writeup that we'r=
e informally calling Bitcoin-United for preserving the value of coins follo=
wing a permanent fork:<div><br></div><div>=C2=A0 =C2=A0 =C2=A0<a href=3D"ht=
tp://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/=
">http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-facti=
ons/</a></div><div><br></div><div>Half of the core idea is to eliminate dou=
ble-spends (where someone spends a UTXO on chain A and the same UTXO on cha=
in B, at separate merchants) by placing transactions from A on chain B, and=
by taking the intersection of transactions on chain A and chain B when con=
sidering whether a payment has been received.=C2=A0</div><div><br></div><di=
v>The other half of the core idea is to enable minting of new coins and col=
lection of mining fees on both chains, while preserving the 21M maximum. Th=
is is achieved by creating a one-to-one correspondence between coins on one=
chain with coins on the other.=C2=A0</div><div><br></div><div>Given the le=
vel of the audience here, I'm keeping the description quite terse. Much=
more detail and discussion is at the link above, as well as the assumption=
s that need to hold for Bitcoin-United.</div><div><br></div><div>The high b=
it is that, with a few modest assumptions, it is possible to create a cohes=
ive coin in the aftermath of a fork, even if the core devs are split, and e=
ven if one of the forks is (in the worst case) completely non-cooperative. =
Bitcoin-United is a trick to create a cohesive coin even when there is no c=
onsensus at the lowest level.</div><div><br></div><div>Bitcoin-United opens=
up a lot of new, mostly game-theoretic questions: what happens to native c=
lients who prefer A or B? What will happen to the value of native-A or nati=
ve-B coins? And so on.=C2=A0</div><div><br></div><div>We're actively wo=
rking on these questions and more, but we wanted to share the Bitcoin-Unite=
d idea, mainly to receive feedback, and partly to provide some hope about f=
uture consensus to the community. It turns out that it is possible to craft=
consensus at the network level even when there isn't one at the develo=
per level.=C2=A0</div><div><br></div><div>Happy New Year, and may 2016 be u=
nited,<br></div><div>- egs & ittay</div><div><br></div></div>
--001a11466d1c9db83b0528231b60--
|
