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
184
185
186
187
188
189
190
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <akaramaoun@gmail.com>) id 1Z4wAE-0000OQ-J3
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 19:04:50 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.177 as permitted sender)
client-ip=209.85.223.177; envelope-from=akaramaoun@gmail.com;
helo=mail-ie0-f177.google.com;
Received: from mail-ie0-f177.google.com ([209.85.223.177])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4wAD-0006uC-IG
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 19:04:50 +0000
Received: by iecrd14 with SMTP id rd14so19316996iec.3
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Jun 2015 12:04:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.56.104 with SMTP id z8mr5475643igp.45.1434481484203; Tue,
16 Jun 2015 12:04:44 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Tue, 16 Jun 2015 12:04:44 -0700 (PDT)
In-Reply-To: <CAL8tG==iJwqPBVTDap=8TC9eCUz4ExfxtGz6p75FXbQJXaByMQ@mail.gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
<CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
<557D2571.601@gmail.com>
<CAL8tG=kEv9AfQM+1Rv+tqBujFEjCp+BsjQ-1s7eJC-usogFFqw@mail.gmail.com>
<CAPg+sBjrSed4r+8-d2RGBVhbzaXxX+o=qqw2u-2jpF2RUqmEmA@mail.gmail.com>
<CAJHLa0OJg2hC4Ab4Yxy3ekH4WXD9hqHore8+sbF9r1r2SwT_zg@mail.gmail.com>
<20150616181724.GA4055@muck>
<CAL8tG==iJwqPBVTDap=8TC9eCUz4ExfxtGz6p75FXbQJXaByMQ@mail.gmail.com>
Date: Tue, 16 Jun 2015 19:04:44 +0000
X-Google-Sender-Auth: G_8P34fEaTtv2kSOqgUvVNJTnfs
Message-ID: <CAL8tG=m6qgANCunZAnm8m_r_tBYq9Kw3XgA7s_ZzKkyCyCEd8w@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0158a8424d8e710518a73f3d
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(akaramaoun[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z4wAD-0006uC-IG
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
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, 16 Jun 2015 19:04:50 -0000
--089e0158a8424d8e710518a73f3d
Content-Type: text/plain; charset=UTF-8
Actually, I have to think about this merge-mining thing a bit more. I'm
starting to think it's better to do without merge-mining at all. As I
explained in the forum post, the parent will put the hashes of its children
headers as transactions inside its blocks. Thus parents will have an
incentive to validate the children not by merge mining, but by collecting
fees from the children for putting those transactions inside (fees that can
be spent at the children chains). So, ya no merge mining needed for my
proposal. But I will think about it a bit more :)
On Tue, Jun 16, 2015 at 6:43 PM, Andrew <onelineproof@gmail.com> wrote:
>
>
> On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> Merge-mined sidechains are not a scaling solution any more than SPV is a
>> scaling solution because they don't solve the scaling problem for
>> miners.
>>
>> Some kind of treechain like sidechain / subchains where what part of the
>> tree miners can mine is constrained to preserve fairness could be both a
>> scaling solution, and decentralized, but no-one has come up with a solid
>> design yet that's ready for production. (my treechains don't qualify for
>> transactions yet; maybe for other proof-of-publication uses)
>>
>>
> Well doesn't my proposal solve the miner decentralization problem. Only
> the direct parent and children chains are merge mined. To be more clear,
> let the top chain to have level 1. Each chain that is a child of a chain of
> level n has level n+1. For any chain C, a block is accepted if the hash of
> its header has an appropriate number of trailing zeros (as usual). It can
> also be accepted with special transactions as I will explain. Let C be a
> chain of level n. Let C0,C1,....,C9 be its children (each of level n+1).
> For any i in {0,1,...,9}, any solution to the mining problem of C can be
> inserted as a special transaction inside Ci and this enables the block to
> be accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in
> {0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of
> C cannot be inserted as a special transaction inside of child Cij of Ci. So
> that means all of the chains are not merge mined, only localised parts,
> right?
>
> By the way, we can eventually get rid of the block size 1 MB limit by
> requiring more than just the header to be hashed, but that can be done in
> the future as soft fork with sidechains, and is a side topic.
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--089e0158a8424d8e710518a73f3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Actually, I have to think about this merge-mining thing a =
bit more. I'm starting to think it's better to do without merge-min=
ing at all. As I explained in the forum post, the parent will put the hashe=
s of its children headers as transactions inside its blocks. Thus parents w=
ill have an incentive to validate the children not by merge mining, but by =
collecting fees from the children for putting those transactions inside (fe=
es that can be spent at the children chains). So, ya no merge mining needed=
for my proposal. But I will think about it a bit more :)<br></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 16, 2015 at 6=
:43 PM, Andrew <span dir=3D"ltr"><<a href=3D"mailto:onelineproof@gmail.c=
om" target=3D"_blank">onelineproof@gmail.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote"><span class=3D"">On Tue, Jun 16, 2015 at 6:17=
PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org"=
target=3D"_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">Merge-mined sidechains are not a scaling solution any mo=
re than SPV is a<br>
scaling solution because they don't solve the scaling problem for<br>
miners.<br>
<br>
Some kind of treechain like sidechain / subchains where what part of the<br=
>
tree miners can mine is constrained to preserve fairness could be both a<br=
>
scaling solution, and decentralized, but no-one has come up with a solid<br=
>
design yet that's ready for production. (my treechains don't qualif=
y for<br>
transactions yet; maybe for other proof-of-publication uses)<span></span><b=
r>
<br></blockquote><div><br></div></span><div>Well doesn't my proposal so=
lve the miner decentralization problem. Only the direct parent and children=
chains are merge mined. To be more clear, let the top chain to have level =
1. Each chain that is a child of a chain of level n has level n+1. For any =
chain C, a block is accepted if the hash of its header has an appropriate n=
umber of trailing zeros (as usual). It can also be accepted with special tr=
ansactions as I will explain. Let C be a chain of level n. Let C0,C1,....,C=
9 be its children (each of level n+1). For any i in {0,1,...,9}, any soluti=
on to the mining problem of C can be inserted as a special transaction insi=
de Ci and this enables the block to be accepted in Ci (so C and C0,C1,...,C=
9 are merge mined. But, for any i in {0,1,...,9} and any j in {0,1,...,9}, =
any solution to the mining problem of C cannot be inserted as a special tra=
nsaction inside of child Cij of Ci. So that means all of the chains are not=
merge mined, only localised parts, right?<br></div></div><br></div><div cl=
ass=3D"gmail_extra">By the way, we can eventually get rid of the block size=
1 MB limit by requiring more than just the header to be hashed, but that c=
an be done in the future as soft fork with sidechains, and is a side topic.=
<br></div><span class=3D""><div class=3D"gmail_extra"><br clear=3D"all"><br=
>-- <br><div>PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</=
div>
</div></span></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</div>
</div>
--089e0158a8424d8e710518a73f3d--
|
