From: "Jorge Timón" <jtimon@monetize•io>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin-Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
Date: Sun, 16 Mar 2014 16:22:32 -0700 [thread overview]
Message-ID: <CAC1+kJOFa8=dXthyWTj5oJN=vkXYvqeKmmr+yG=GM8TFnU_Y6Q@mail.gmail.com> (raw)
In-Reply-To: <20140316225819.GA19846@netbook.cypherspace.org>
Some comments.
On 3/16/14, Adam Back <adam@cypherspace•org> wrote:
> 6. a fraud proof is an SPV proof with a longer chain showing that the proof
> of burn was orphaned.
As discussed, "reorg proof" it's a more appropriate term since the
reorg can happen without any fraud. It also prevents the term from
being confused with the fraud proof that auditors (full nodes that
can't create blocks) produce for private chains.
> Apart from pegging from bitcoin to a side-chain, if a private chain is made
> with same rules to the side-chain it becomes possible with some
> modifications to the above algorithm to peg the side-chain to a private
> chain. Private chain meaning a chain with the same format but signature of
> single server in place of hashing, and timestamping of the block signatures
> in the mined side chain. And then reactive security on top of that by full
> nodes/auditors trying to find fraud proofs (rewrites of history relative to
> side-chain mined time-stamp or approved double-spends). The reaction is to
> publish a fraud proof and move coins back to the side chain, and then
> regroup on a new server. (Open transactions has this audit + reactive
> model
> but as far as I know does it via escrow, eg the voting pools for k of n
> escrow of the assets on the private server.) I also proposed the same
> reactive audit model but for auditable namespaces [4].
>
> Private chains add some possiblity for higher scaling, while retaining
> bitcoin security properties. (You need to add the ability for a user to
> unilaterally move his coins to the side-chain they came from in event the
> chain server refuses to process transactions involving them. This appears
> to be possible if you have compatible formats on the private chain and
> side-chain).
In this case you can't require a side chain proof of burn to move back
to the side chain or the funds could be locked by the dishonest
private chain operator (accountant in freimarkets[1] terminology). By
allowing unilateral withdrawals, you impose on the private chain the
task of observing the side chain looking for double-spends, censoring
those transactions or maybe updating its committed utxo when it has
proofs that the coins have been withdrawn.
[1] http://freico.in/docs/freimarkets.pdf
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers
--
Jorge Timón
http://freico.in/
next prev parent reply other threads:[~2014-03-16 23:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
2013-05-19 15:08 ` Peter Vessenes
2013-05-20 6:34 ` Alan Reiner
2013-10-14 18:08 ` Adam Back
2013-10-14 18:21 ` Jeff Garzik
2013-11-21 20:22 ` coinscoins
2013-11-21 20:35 ` Melvin Carvalho
2013-11-21 21:11 ` [Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?) Adam Back
2014-03-16 22:58 ` [Bitcoin-development] 2-way pegging " Adam Back
2014-03-16 23:22 ` Jorge Timón [this message]
2014-03-17 15:55 ` Gregory Maxwell
2013-10-14 18:43 ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
2013-10-14 20:20 ` Alan Reiner
2013-05-22 3:37 ` zooko
2013-05-22 4:12 ` Jeff Garzik
2013-05-20 7:12 ` Luke-Jr
2013-06-13 13:39 ` Adam Back
2013-06-14 19:20 ` Peter Todd
2013-06-14 20:50 ` Adam Back
2013-06-14 21:10 ` Luke-Jr
2013-06-14 21:25 ` Andreas Petersson
2013-06-15 0:09 ` Dennison Bertram
2013-06-15 1:57 ` Luke-Jr
2013-06-15 8:43 ` Dennison Bertram
2013-06-15 11:18 ` Melvin Carvalho
2013-06-15 13:26 ` Dennison Bertram
2013-06-16 15:46 ` Dennison Bertram
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='CAC1+kJOFa8=dXthyWTj5oJN=vkXYvqeKmmr+yG=GM8TFnU_Y6Q@mail.gmail.com' \
--to=jtimon@monetize$(echo .)io \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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