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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1WSYVx-0001JX-M8
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Mar 2014 21:04:05 +0000
Received: from mail-pa0-f49.google.com ([209.85.220.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WSYVw-00074j-QD
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Mar 2014 21:04:05 +0000
Received: by mail-pa0-f49.google.com with SMTP id lj1so966448pab.8
for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Mar 2014 14:03:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=pmOlTaFyAeBszPxq/zvtgNvEPPK80ro/OV2JFldRahQ=;
b=EfMLYS9bdavbei/PXjHHPW7uFpQXBpX6rPfKcshpJncUsCFyx5+rWivHDs1xhKxC7w
12ZkM+g/BjhhUHIsq5QAtSdRwABYTXzWteiPs/tMnVEOjlSRT8XYe0ydgCTOH/aGtxDE
hycb5SIF+F1M4QemEONBPLd6hy1e2M5vSuzTMCuAX6eUiCGVnnUmSS1HarAgJ7tDWltO
7RaFHLYSWyhyHgvXjqNtKeHVQv06l/V10lh9ZIPYZJrwFXHTQlQKdXgIrS7BlXFDB39J
S+gXohQHVZpLM2WiukaqDn86omToBpS40EOjZVFnrWEkfkC8j8L1fb94p68lJTXIcFoj
T+QA==
X-Gm-Message-State: ALoCoQkhqPv+1Euk+nXJIgM/jojVMcfuGEs7KlifKfWPFlfbU8nDJwxlk2suTK+6dhiGKcHk32mJ
X-Received: by 10.68.201.226 with SMTP id kd2mr13528960pbc.157.1395781438901;
Tue, 25 Mar 2014 14:03:58 -0700 (PDT)
Received: from [192.168.127.190] ([207.86.76.198])
by mx.google.com with ESMTPSA id
ix6sm42478113pbd.66.2014.03.25.14.03.57 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 25 Mar 2014 14:03:58 -0700 (PDT)
Message-ID: <5331EF3D.4000504@monetize.io>
Date: Tue, 25 Mar 2014 14:03:57 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>
References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop>
<20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io>
<20140325122851.GA9818@savin>
In-Reply-To: <20140325122851.GA9818@savin>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WSYVw-00074j-QD
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: Tue, 25 Mar 2014 21:04:06 -0000
I'm afraid I'm going to be the jerk that requested more details and then
only nitpicks seemingly minor points in your introduction. But its
because I need more time to digest the contents of your proposal. Until
then:
> 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
> handle; at worst they could lead to inflation.
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.
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 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.
|
