From: Peter Todd <pete@petertodd•org>
To: Mark Friedenbach <mark@monetize•io>,
Gregory Maxwell <gmaxwell@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Tree-chains preliminary summary
Date: Wed, 26 Mar 2014 06:48:52 -0400 [thread overview]
Message-ID: <20140326104852.GB26997@tilt> (raw)
In-Reply-To: <CAAS2fgTovm7OtFFqdRYWDw5KxV+r5WD598JPnG5ydMYAs_gQWg@mail.gmail.com> <5331EF3D.4000504@monetize.io>
[-- 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 --]
next prev parent reply other threads:[~2014-03-26 10:49 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
2014-03-26 10:48 ` Peter Todd [this message]
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=20140326104852.GB26997@tilt \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
--cc=mark@monetize$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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