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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WSlOT-0000Na-5z
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Mar 2014 10:49:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.107 as permitted sender)
client-ip=62.13.148.107; envelope-from=pete@petertodd.org;
helo=outmail148107.authsmtp.com;
Received: from outmail148107.authsmtp.com ([62.13.148.107])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WSlOQ-0007ML-Pw for bitcoin-development@lists.sourceforge.net;
Wed, 26 Mar 2014 10:49:13 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2QAmxdo013126;
Wed, 26 Mar 2014 10:48:59 GMT
Received: from tilt ([209.211.43.92]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2QAmqjf074099
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 26 Mar 2014 10:48:54 GMT
Date: Wed, 26 Mar 2014 06:48:52 -0400
From: Peter Todd <pete@petertodd.org>
To: Mark Friedenbach <mark@monetize.io>, Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140326104852.GB26997@tilt>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+"
Content-Disposition: inline
In-Reply-To: <CAAS2fgTovm7OtFFqdRYWDw5KxV+r5WD598JPnG5ydMYAs_gQWg@mail.gmail.com>
<5331EF3D.4000504@monetize.io>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3a2117e3-b4d4-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAQUFVQGAgsB AmIbWlReVFV7XGY7 aQpYcwdcY1RKXBtj
UldMSlVNFUsrA31w W19EBBl1cwVPcTBy Z0RqXj5YDUZ7dEEo
QVMGETkCeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA43BDMx AhsCFDQpBgUdXSg3
LhknLFcGDQ4KL0A3 OEEwMf9/
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 209.211.43.92/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
0.0 FAKE_REPLY_C FAKE_REPLY_C
X-Headers-End: 1WSlOQ-0007ML-Pw
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Tree-chains preliminary summary
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, 26 Mar 2014 10:49:13 -0000
--jho1yZJdad60DJr+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 25, 2014 at 02:03:57PM -0700, Mark Friedenbach wrote:
> > But moving value between chains is inconvenient; right now moving
> > value requires trusted third parties. Two-way atomic chain transfers
> > does help here, but as recent discussions on the topic showed there's
> > all sorts of edge cases with reorganizations that are tricky to=20
> > handle; at worst they could lead to inflation.
>=20
> This isn't true. The re-org issue is fairly handled in the 2-way pegging
> scheme that Greg Maxwell developed and Adam Back described a week ago on
> this list. Depending on the implementation it could even be configurable
> by the person performing the peg too - allowing the transfer to specify
> the confirmation depth required during the quieting period in order to
> protect against re-orgs up to a sufficient depth. I think this is worked
> out quite well with sufficient enumeration of edge cases, and I don't
> think they are particularly tricky to handle or lead to money-losing
> situations under the explicit security assumptions.
>=20
> More importantly, to your last point there is absolutely no way this
> scheme can lead to inflation. The worst that could happen is theft of
> coins willingly put into the pegging pool. But in no way is it possible
> to inflate the coin supply.
I see your point, but gmaxwell accurately guesses below that when I'm
talking about inflation, I'm including the inflation of the alt too.
With tree-chains that's particularly obvious as the scheme doesn't try
to privilege one chain over another beyond parent-child relationships.
Incidentally, I understand that the pegged chains are meant to be
merge-mined. To me this seems problematic and cheap to attack. Consider
a merge-mined zerocoin sidechain: Can you profit from depositing some
coins, taking them out again, then reorging the zerocoin chain to undo
that withdrawl on the zerocoin side, and performing it all over again?
It'd be easy to drain the pegging pool that way, and with merge-mining
there's no inherent cost to you to do so. Not unique to zerocoin either
of course, just in that case who actually double-spent is unknowable.
> I will look at your proposal in more depth. But I also think you should
> give 2-way pegging a fair shake as pegging to side chains and private
> accounting servers may eliminate the need.
Well I'll certainly raid 2-way pegging for ideas. :) I think the big
difference between the two is how I'd like to see tree-chains reduce
dependence on miner validation - ideally miners wouldn't validate at all
if the efficiency can be regained with ZK-SNARKS or something. Dropping
validation from mining could also avoid the problem of how in Bitcoin
there is no explicit mechanism that actually forces miners to validate
the chain. Not unlike gmaxwell's "firedrill" ideas, you would be able to
"firedrill" clients at any point by just mining some invalid garage.
(not to say miners would certainly not do validation - you still want to
be able to pay them transaction fees, but in that case they're doing the
validation only for themselves)
On Tue, Mar 25, 2014 at 03:34:31PM -0700, Gregory Maxwell wrote:
> On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach <mark@monetize.io> wrot=
e:
> > More importantly, to your last point there is absolutely no way this
> > scheme can lead to inflation. The worst that could happen is theft of
> > coins willingly put into the pegging pool. But in no way is it possible
> > to inflate the coin supply.
>=20
> I don't think it would be entirely unfair to describe one of the
> possible ways a secondary coin becoming unbacked can play out as
> inflation=E2=80=94 after all, people have described altcoins as inflation=
=2E In
> the worst case its no _worse_ inflation, I think, than an altcoin is=E2=
=80=94
> however.
Yup, and in the tree-chains model, every single chain is, from that
perspective, an altcoin.
--=20
'peter'[:-1]@petertodd.org
0000000000000000f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2
--jho1yZJdad60DJr+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGcBAEBCAAGBQJTMrCPAAoJEGJeboN5AaHKLVUL/A4xTP1AyZOg53I276npkmjv
O2rzIXHiQ7/pFoJCgVplXqDmpWEccDIe+37bbAtvFqpaaVHhWOs/7YmOjurEEH5P
e6bGfLa5u/eTnOfzVy3cPnDv1LlUjjFT5x38PnR3QV4aiKc3U9MYCaay61ejZPuU
LSmACZ1LQ/FwUBrtn4DYh/E3rUtsBfGhJpM1jPRJ0rx4+I2rYa8gvI56jGpiu/fn
JFOa8tmc28xXQPj1WLezGuqCv3aNkAQyZvbrQQHBgWkCQGZ/J3QpQu757bGHEpD0
emRkLuMGcaZPEg72Pi0OofqwEdp8SNpaVkgAWkqoScG/QNrZbJW4aWh4Mm2yF+qD
ZNR5NqJ2wO6U7TmLonGvlISLrQPmrw9hWLlD1Q1kjJof0mDWPYVhMSvWTju+M+s7
BfgG67UKEMMRUfAepNxraq7FVZfd9igmOFNvdEFUzHuNenPzYAhH6ok98tsgK/gf
K2dgrM73OAqmXA7mhEmCxSJrfr9afaJgPhaTVh418A==
=B4iC
-----END PGP SIGNATURE-----
--jho1yZJdad60DJr+--
|
