summaryrefslogtreecommitdiff
path: root/01/b6afec3b457bc67a12c452673d098402d5183f
blob: bd10029abb43a08513c5df0b3952899785665ea7 (plain)
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
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 46E46A74
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 20:23:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com
	[209.85.215.66])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADF85433
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 20:23:47 +0000 (UTC)
Received: by mail-lf0-f66.google.com with SMTP id 90so4094695lfs.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 13:23:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=/updSCiZAZngu9aulkEfdQM7x6E1xmU3RqXf7jIn6uU=;
	b=pxmhsVKcRWE9bM68gr7LdbHB5fQaZ4GS8+6jhVPwgKRjDDg5V/0vfrCPBBrtfvzzBx
	f/dzhqNxA0Aetm+/wZa8TjRekMAeqaR5cvemrqiG2xB9PCPRBAwRpMY+L9VXkblYuGlB
	+y5ipzG8r+ByRg+c5ik173mpU7A8LooqOnv7G/wbzJvLv1PSJLW0oOw5rsQQCEq+wUh2
	VOZhMHYbuiA2HpeJF12SZgGW9MonGEGIjQOwKLws7wyLoHkIjwg5J5yMfHeOosjM/H1A
	Tkbwuivay8x6eUTTbJWPwf15oNoFazqmHOlGUHN+HSN7B5xs2UXqWYYodIOJ55rekQIE
	8n1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=/updSCiZAZngu9aulkEfdQM7x6E1xmU3RqXf7jIn6uU=;
	b=j3MovaKCoTivdSpuRZlgQrN650YECi5OlJUpwDpfw7vldsvVo9d5HbSEl7xjDSwqc1
	lmgfBgiDr1GofjtIpUn+Cw108hyx6AILO7xUDd76v/xlNqesiHvnrR8SJ9otTokLT7Yd
	NhMMiKebsJyYhav/KDjYYDR1Q2EKFE5Ex9NyauYKgtfW/xKqZz6PGOKVJnm2vldehxrN
	s70H2QdQGacPAwFZ3Nn9FcBdTs4GMak8aWHdFe1DrBQ6jL0nFB9WlSGa7zGLbFKV68RR
	1KoLhmCvKcupEluGsqdFVSk4auHUgCsuUK7RXv233nWKxtbtrVNfiGvqK5Q6SFL7qmNj
	lNcw==
X-Gm-Message-State: AMCzsaWwtXIetq6+5ucpUrbvIHSsVOYVpQRX1u3eXS3PGM8NMG7n5MVf
	nNqtpg/u8mSL/KbvVyuH905etXaSQ2Ex5rAvvdk=
X-Google-Smtp-Source: AOwi7QDIfc3xPzFWPfkgHhswO4oi9nc1zZHuBFpg/SgdNeAIuNqImQWbvfjoceA7Me7xE/nUPpRLf8qaIeBd5bByEqM=
X-Received: by 10.46.91.25 with SMTP id p25mr6600514ljb.46.1507667025851; Tue,
	10 Oct 2017 13:23:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.15.160 with HTTP; Tue, 10 Oct 2017 13:23:45 -0700 (PDT)
Received: by 10.25.15.160 with HTTP; Tue, 10 Oct 2017 13:23:45 -0700 (PDT)
In-Reply-To: <CA+XQW1hjjY3btufV36AS7JO=CQ7TMwK7ohJ4QETbNuGWyQ6=dA@mail.gmail.com>
References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com>
	<CA+XQW1jf-6HCic4beV5GSix8KRzJ-7nTc-ePipfs=ouwvHX0jA@mail.gmail.com>
	<CAGCathy2U7+Qy4gLB0S_j-kArvGHuELDgzweFR4grQQ9AZgAbg@mail.gmail.com>
	<CA+XQW1hjjY3btufV36AS7JO=CQ7TMwK7ohJ4QETbNuGWyQ6=dA@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Date: Tue, 10 Oct 2017 16:23:45 -0400
Message-ID: <CA+XQW1giGJxq9WWZ1XRuKM4kPeSOU018eBgX1MZhEVsH1EwzKQ@mail.gmail.com>
To: Lucas Clemente Vella <lvella@gmail.com>
Content-Type: multipart/alternative; boundary="001a114c17c683f889055b37159d"
X-Spam-Status: No, score=1.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU, FREEMAIL_FROM, FREEMAIL_REPLY, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalized sharding protocol for decentralized
 scaling without Miners owning our BTC
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 10 Oct 2017 20:23:48 -0000

--001a114c17c683f889055b37159d
Content-Type: text/plain; charset="UTF-8"

What if two sidechains are implemented at once? What if people get excited
about one sidechain today, but a second even-better one is published the
very next week? What if the original mainchain decides to integrate the
features of the sidechain that you just one-way pegged to?

In these cases, the user looses money, whereas in the two-way peg they
would not lose a thing.

While the one-way peg is interesting, it really doesn't compare.

Paul

On Oct 10, 2017 4:19 PM, "Lucas Clemente Vella" <lvella@gmail.com> wrote:

2017-10-09 22:39 GMT-03:00 Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.
linuxfoundation.org>:

> That is only a one-way peg, not a two-way.
>
> In fact, that is exactly what drivechain does, if one chooses parameters
> for the drivechain that make it impossible for any side-to-main transfer to
> succeed.
>
> One-way pegs have strong first-mover disadvantages.
>

I understand the first-mover disadvantages, but I keep thinking that if the
new chain is Pareto optimal, i.e. is in all aspects at least good as the
original chain, but in some so much better to justify the change, the
initial resistance is an unstable equilibrium. Like a herd of buffaloes
attacking a lion: the first buffalo to attack is in awful disadvantage, but
if a critical mass of the herd follows, the movement succeeds beyond
turning back, and every buffalo benefited, both those who attacked the lion
and those that didn't (because the lion was chased away or killed).

-- 
Lucas Clemente Vella
lvella@gmail.com

--001a114c17c683f889055b37159d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">What if two sidechains are implemented at once? What if p=
eople get excited about one sidechain today, but a second even-better one i=
s published the very next week? What if the original mainchain decides to i=
ntegrate the features of the sidechain that you just one-way pegged to?<div=
 dir=3D"auto"><br></div><div dir=3D"auto">In these cases, the user looses m=
oney, whereas in the two-way peg they would not lose a thing.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">While the one-way peg is interesting,=
 it really doesn&#39;t compare.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Paul</div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Oct 10, 2017 4:19 PM, &quot;Lucas Clemente Vella&quot; &lt;<a h=
ref=3D"mailto:lvella@gmail.com">lvella@gmail.com</a>&gt; wrote:<br type=3D"=
attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div class=3D"quoted-text">2017-10-09 22:=
39 GMT-03:00 Paul Sztorc via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.<wbr>linuxfoundation.org</a>&gt;</span>:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"auto"><div>That is only a one-way peg, not a two-way.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">In fact, that is exactly wh=
at drivechain does, if one chooses parameters for the drivechain that make =
it impossible for any side-to-main transfer to succeed.</div><div dir=3D"au=
to"><br></div><div>One-way pegs have strong first-mover disadvantages.</div=
></div></blockquote><div>=C2=A0</div></div><div>I understand the first-move=
r disadvantages, but I keep thinking that if the new chain is Pareto optima=
l, i.e. is in all aspects at least good as the original chain, but in some =
so much better to justify the change, the initial resistance is an unstable=
 equilibrium. Like a herd of buffaloes attacking a lion: the first buffalo =
to attack is in awful disadvantage, but if a critical mass of the herd foll=
ows, the movement succeeds beyond turning back, and every buffalo benefited=
, both those who attacked the lion and those that didn&#39;t (because the l=
ion was chased away or killed).<font color=3D"#888888"><br></font></div><fo=
nt color=3D"#888888"><div>=C2=A0</div></font></div><font color=3D"#888888">=
-- <br><div class=3D"m_9075039182185049432gmail_signature" data-smartmail=
=3D"gmail_signature">Lucas Clemente Vella<br><a href=3D"mailto:lvella@gmail=
.com" target=3D"_blank">lvella@gmail.com</a></div>
</font></div></div>
</blockquote></div><br></div>

--001a114c17c683f889055b37159d--