public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Tree-chains preliminary summary
Date: Thu, 17 Apr 2014 22:41:55 +0100	[thread overview]
Message-ID: <CAE-z3OX-sfZWqzPGZA3VGxDFvFV9GAVUEnnu4TccEZeH=pVB1w@mail.gmail.com> (raw)
In-Reply-To: <20140328151030.GJ3180@nl.grid.coop>

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1923 bytes --]

  reply	other threads:[~2014-04-17 21:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22  8:47 [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Peter Todd
2014-03-22 13:53 ` Jorge Timón
2014-03-22 19:34   ` Peter Todd
2014-03-22 20:12     ` Jorge Timón
2014-03-23 23:17       ` Troy Benjegerdes
2014-03-23 23:53         ` Mark Friedenbach
2014-03-24 20:34           ` Troy Benjegerdes
2014-03-24 20:57             ` Mark Friedenbach
2014-03-25 22:10               ` Troy Benjegerdes
2014-03-26  1:09                 ` kjj
2014-03-22 15:08 ` Troy Benjegerdes
2014-03-22 17:04   ` Mark Friedenbach
2014-03-22 19:08   ` Peter Todd
2014-03-23 22:37     ` Troy Benjegerdes
     [not found]     ` <532DE7E6.4050304@monetize.io>
2014-03-25 12:28       ` [Bitcoin-development] Tree-chains preliminary summary Peter Todd
2014-03-25 12:45         ` Gavin Andresen
2014-03-25 13:49           ` Peter Todd
2014-03-25 15:20             ` Mike Hearn
2014-03-25 16:47               ` Peter Todd
2014-03-25 17:37             ` Jeff Garzik
2014-03-25 18:02               ` Alan Reiner
2014-03-25 18:13                 ` slush
2014-03-25 19:47                   ` Peter Todd
2014-03-25 21:41                     ` Troy Benjegerdes
2014-03-25 20:40             ` Ricardo Filipe
2014-03-25 22:00               ` Troy Benjegerdes
2014-03-26 10:58               ` Peter Todd
2014-03-25 12:50         ` Peter Todd
2014-03-25 21:03         ` Mark Friedenbach
2014-03-25 22:34           ` Gregory Maxwell
2014-03-27 16:14             ` Jorge Timón
2014-03-28 15:10               ` Troy Benjegerdes
2014-04-17 21:41                 ` Tier Nolan [this message]
2014-03-26 10:48           ` Peter Todd
2014-08-03 17:23         ` Gregory Sanders
2014-03-24 21:17 ` [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Luke-Jr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE-z3OX-sfZWqzPGZA3VGxDFvFV9GAVUEnnu4TccEZeH=pVB1w@mail.gmail.com' \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox