Re: [Bitcoin-development] Tree-chains preliminary summary

[Peter Todd <pete@petertodd.org>]

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

On Tue, Mar 25, 2014 at 02:03:57PM -0700, Mark Friedenbach wrote:
> > But moving value between chains is inconvenient; right now moving
> > value requires trusted third parties. Two-way atomic chain transfers
> > does help here, but as recent discussions on the topic showed there's
> > all sorts of edge cases with reorganizations that are tricky to 
> > handle; at worst they could lead to inflation.
> 
> This isn't true. The re-org issue is fairly handled in the 2-way pegging
> scheme that Greg Maxwell developed and Adam Back described a week ago on
> this list. Depending on the implementation it could even be configurable
> by the person performing the peg too - allowing the transfer to specify
> the confirmation depth required during the quieting period in order to
> protect against re-orgs up to a sufficient depth. I think this is worked
> out quite well with sufficient enumeration of edge cases, and I don't
> think they are particularly tricky to handle or lead to money-losing
> situations under the explicit security assumptions.
> 
> More importantly, to your last point there is absolutely no way this
> scheme can lead to inflation. The worst that could happen is theft of
> coins willingly put into the pegging pool. But in no way is it possible
> to inflate the coin supply.

I see your point, but gmaxwell accurately guesses below that when I'm
talking about inflation, I'm including the inflation of the alt too.
With tree-chains that's particularly obvious as the scheme doesn't try
to privilege one chain over another beyond parent-child relationships.


Incidentally, I understand that the pegged chains are meant to be
merge-mined. To me this seems problematic and cheap to attack. Consider
a merge-mined zerocoin sidechain: Can you profit from depositing some
coins, taking them out again, then reorging the zerocoin chain to undo
that withdrawl on the zerocoin side, and performing it all over again?
It'd be easy to drain the pegging pool that way, and with merge-mining
there's no inherent cost to you to do so. Not unique to zerocoin either
of course, just in that case who actually double-spent is unknowable.

> I will look at your proposal in more depth. But I also think you should
> give 2-way pegging a fair shake as pegging to side chains and private
> accounting servers may eliminate the need.

Well I'll certainly raid 2-way pegging for ideas. :) I think the big
difference between the two is how I'd like to see tree-chains reduce
dependence on miner validation - ideally miners wouldn't validate at all
if the efficiency can be regained with ZK-SNARKS or something. Dropping
validation from mining could also avoid the problem of how in Bitcoin
there is no explicit mechanism that actually forces miners to validate
the chain. Not unlike gmaxwell's "firedrill" ideas, you would be able to
"firedrill" clients at any point by just mining some invalid garage.

(not to say miners would certainly not do validation - you still want to
be able to pay them transaction fees, but in that case they're doing the
validation only for themselves)


On Tue, Mar 25, 2014 at 03:34:31PM -0700, Gregory Maxwell wrote:
> On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach <mark@monetize.io> wrote:
> > More importantly, to your last point there is absolutely no way this
> > scheme can lead to inflation. The worst that could happen is theft of
> > coins willingly put into the pegging pool. But in no way is it possible
> > to inflate the coin supply.
> 
> I don't think it would be entirely unfair to describe one of the
> possible ways a secondary coin becoming unbacked can play out as
> inflation— after all, people have described altcoins as inflation. In
> the worst case its no _worse_ inflation, I think, than an altcoin is—
> however.

Yup, and in the tree-chains model, every single chain is, from that
perspective, an altcoin.

-- 
'peter'[:-1]@petertodd.org
0000000000000000f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]