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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Wau4I-0007M4-4i
for bitcoin-development@lists.sourceforge.net;
Thu, 17 Apr 2014 21:42:02 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.48 as permitted sender)
client-ip=209.85.216.48; envelope-from=tier.nolan@gmail.com;
helo=mail-qa0-f48.google.com;
Received: from mail-qa0-f48.google.com ([209.85.216.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wau4H-0000NQ-5w
for bitcoin-development@lists.sourceforge.net;
Thu, 17 Apr 2014 21:42:01 +0000
Received: by mail-qa0-f48.google.com with SMTP id s7so922226qap.21
for <bitcoin-development@lists.sourceforge.net>;
Thu, 17 Apr 2014 14:41:55 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.81.71 with SMTP id w7mr15092186qck.8.1397770915730; Thu,
17 Apr 2014 14:41:55 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Thu, 17 Apr 2014 14:41:55 -0700 (PDT)
In-Reply-To: <20140328151030.GJ3180@nl.grid.coop>
References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop>
<20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io>
<20140325122851.GA9818@savin> <5331EF3D.4000504@monetize.io>
<CAAS2fgTovm7OtFFqdRYWDw5KxV+r5WD598JPnG5ydMYAs_gQWg@mail.gmail.com>
<CAC1+kJMkiVLEnHKibWbaCdtEwCE30M4SPM96H6Nq7kZey-_4eg@mail.gmail.com>
<20140328151030.GJ3180@nl.grid.coop>
Date: Thu, 17 Apr 2014 22:41:55 +0100
Message-ID: <CAE-z3OX-sfZWqzPGZA3VGxDFvFV9GAVUEnnu4TccEZeH=pVB1w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133b2b0e8f55104f743e69a
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
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: 1Wau4H-0000NQ-5w
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: Thu, 17 Apr 2014 21:42:02 -0000
--001a1133b2b0e8f55104f743e69a
Content-Type: text/plain; charset=UTF-8
How does this system handle problems with the lower chains after they have
been "locked-in"?
The rule is that if a block in the child chain is pointed to by its parent,
then it effectively has infinite POW?
The point of the system is that a node monitoring the parent chain only has
to watch the header chain for its 2 children.
A parent block header could point to an invalid block in one of the child
chains. That parent block could end up built on top of before the problem
was discovered.
This would mean that a child chain problem could cause a roll-back of a
parent chain. This violates the principle that parents are dominant over
child chains.
Alternatively, the child chain could discard the infinite POW blocks, since
they are illegal.
P1 -> C1
P2 -> ---
P3 -> C3
P4 -> C5
It turns out C4 (or C5) was an invalid block
P5 -> C4'
P6 -> ---
P7 -> C8'
This is a valid sequence. Once P7 points at C8, the alternative chain
displaces C5.
This displacement could require a compact fraud proof to show that C4 was
an illegal block and that C5 was built on it.
This shouldn't happen if the miner was actually watching the log(N) chains,
but can't be guaranteed against.
I wonder if the proof of stake "nothing is at stake" principle applies
here. Miners aren't putting anything at stake by merge mining the lower
chains.
At minimum, they should get tx-fees for the lower chains that they merge
mine. The rule could require that the minting reward is divided over the
merge mined chains.
--001a1133b2b0e8f55104f743e69a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>How does this system handle =
problems with the lower chains after they have been "locked-in"?<=
br><br></div>The rule is that if a block in the child chain is pointed to b=
y its parent, then it effectively has infinite POW?<br>
<br></div>The point of the system is that a node monitoring the parent chai=
n only has to watch the header chain for its 2 children.<br><br></div>A par=
ent block header could point to an invalid block in one of the child chains=
.=C2=A0 That parent block could end up built on top of before the problem w=
as discovered.<br>
<br></div>This would mean that a child chain problem could cause a roll-bac=
k of a parent chain.=C2=A0 This violates the principle that parents are dom=
inant over child chains.<br><br></div>Alternatively, the child chain could =
discard the infinite POW blocks, since they are illegal.<br>
<br></div><div>P1 -> C1<br></div><div>P2 -> ---<br></div><div>P3 ->=
; C3<br></div><div>P4 -> C5<br><br></div><div>It turns out C4 (or C5) wa=
s an invalid block<br><br></div><div>P5 -> C4'<br></div><div>P6 ->=
; ---<br>
</div><div>P7 -> C8'<br><br></div><div>This is a valid sequence.=C2=
=A0 Once P7 points at C8, the alternative chain displaces C5.<br><br></div>=
<div>This displacement could require a compact fraud proof to show that C4 =
was an illegal block and that C5 was built on it.<br>
<br></div><div>This shouldn't happen if the miner was actually watching=
the log(N) chains, but can't be guaranteed against.<br></div><div><br>=
</div><div>I wonder if the proof of stake "nothing is at stake" p=
rinciple applies here.=C2=A0 Miners aren't putting anything at stake by=
merge mining the lower chains.<br>
<br></div><div>At minimum, they should get tx-fees for the lower chains tha=
t they merge mine.=C2=A0 The rule could require that the minting reward is =
divided over the merge mined chains.<br></div></div>
--001a1133b2b0e8f55104f743e69a--
|
