diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2014-04-17 22:41:55 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-17 21:42:02 +0000 |
| commit | 5c665e7f8bd7cb48cdf66286712ca7d89ecd81ff (patch) | |
| tree | 9e51c1ede26cd697f4569cb311004e22e1f423e7 | |
| parent | 5848af0251c7758c57e77cbe1dc6610a83455e6f (diff) | |
| download | pi-bitcoindev-5c665e7f8bd7cb48cdf66286712ca7d89ecd81ff.tar.gz pi-bitcoindev-5c665e7f8bd7cb48cdf66286712ca7d89ecd81ff.zip | |
Re: [Bitcoin-development] Tree-chains preliminary summary
| -rw-r--r-- | b1/c1cd1594c0fcf0e4ab07d3fc7711a3889522de | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/b1/c1cd1594c0fcf0e4ab07d3fc7711a3889522de b/b1/c1cd1594c0fcf0e4ab07d3fc7711a3889522de new file mode 100644 index 000000000..6050d3ce2 --- /dev/null +++ b/b1/c1cd1594c0fcf0e4ab07d3fc7711a3889522de @@ -0,0 +1,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-- + + |