Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Adam Back]

For those following this thread, we have now written a paper
describing the side-chains, 2-way pegs and compact SPV proofs.
(With additional authors Andrew Poelstra & Andrew Miller).

http://blockstream.com/sidechains.pdf

Adam

On 16 March 2014 15:58, Adam Back <adam@cypherspace.org> wrote:
> So an update on 1-way pegging (aka bitcoin staging, explained in quoted text
> at bottom): it turns out secure 2-way pegging is also possible (with some
> bitcoin change to help support it).  The interesting thing is this allows
> interoperability in terms of being able to move bitcoin into and out of a
> side chain.  The side chains may have some different parameters, or
> experimental things people might want to come up with (subject to some
> minimum compatibility at the level of being able to produce an SPV proof of
> a given form).
>
> At the time of the 1-way peg discussion I considered 2-way peg as desirable
> and it seemed plausible with bitcoin changes, but the motivation for 1-way
> peg was to make it less risky to make changes on bitcoin, so that seemed
> like a catch-22 loop.  Also in the 2-way peg thought experiment I had not
> realized how simple it was to still impose a security firewall in the 2-way
> peg also.
>
>
> So Greg Maxwell proposed in Dec last year a practically compact way to do
> 2-way pegging using SPV proofs.  And also provided a simple argument of how
> this can provide a security firewall.  (Security firewall means the impact
> of security bugs on the side-chain is limited to the people with coins in
> it; bitcoin holders who did not use it are unaffected). [1]
>
> How it works:
>
> 1. to maintain the 21m coins promise, you start a side-chain with no
> in-chain mining subsidy, all bitcoin creation happens on bitcoin chain (as
> with 1-way peg).  Reach a reasonable hash rate.  (Other semantics than 1:1
> peg should be possible, but this is the base case).
>
> 2. you move coins to the side-chain by spending them to a fancy script,
> which suspends them, and allows them to be reanimated by the production of
> an SPV proof of burn on the side-chain.
>
> 3. the side-chain has no mining reward, but it allows you to mint coins at
> no mining cost by providing an SPV proof that the coin has been suspended as
> in 2 on bitcoin.  The SPV proof must be buried significantly before being
> used to reduce risk of reorganization.  The side-chain is an SPV client to
> the bitcoin network, and so maintains a view of the bitcoin hash chain (but
> not the block data).
>
> 4. the bitcoin chain is firewalled from security bugs on the side chain,
> because bitcoin imposes the rule that no more coins can be reanimated than
> are currently suspend (with respect to a given chain).
>
> 5. to simplify what they hypothetical bitcoin change would need to consider
> and understand, after a coin is reanimated there is a maturity period
> imposed (say same as fresh mined coins).  During the maturity period the
> reanimation script allows a fraud proof to spend the coins back.  A fraud
> bounty fee (equal to the reanimate fee) can be offered by the mover to
> incentivize side-chain full nodes to watch reanimations and search for fraud
> proofs.
>
> 6. a fraud proof is an SPV proof with a longer chain showing that the proof
> of burn was orphaned.
>
> There are a few options to compress the SPV proof, via Fiat-Shamir transform
> to provide a compact proof of amount work contained in a merkle tree of
> proofs of work (as proposed by Fabien Coelho link on
> http://hashcash.org/papers/) with params like 90% of work is proven.  But
> better is something Greg proposed based on skip-lists organized in a tree,
> where 'lucky' proofs of work are used to skip back further.  (Recalling that
> if you search for a 64-bit leading-0 proof-of-work, half the time you get a
> 65-bit, quarter 66-bit etc.)  With this mechanism you can accurately
> prove the amount of proof of work in a compressed tree (rather than ~90%).
>
>
> 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).
>
>
> This pegging discussion involved a number of #bitcoin-wizards, Greg Maxwell,
> Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach, Luke Dashjr. The
> 2-way peg seems to have first been described by Greg.  Greg thought of
> 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2].
> (As a ZK-SNARK could compactly prove full validation of a side chain rules).
>
> There was also something seemingly similar sounding but not described in
> detail by Alex Mizrahi in the context of color coins in this post [3].
>
> Adam
>
> [1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
> [2] https://bitcointalk.org/index.php?topic=277389.40
> [3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554
> [4] http://www.cypherspace.org/p2p/auditable-namespace.html
>
> On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote:
>>
>> Coming back to the staging idea, maybe this is a realistic model that
>> could
>> work.  The objective being to provide a way for bitcoin to move to a live
>> beta and stable being worked on in parallel like fedora vs RHEL or
>> odd/even
>> linux kernel versions.
>>
>> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin
>> 0.x
>> stable and leap-frogs as beta becomes stable after testing.
>>
>> Its a live beta, meaning real value, real contracts.  But we dont want it
>> to
>> be an alt-coin with a floating value exactly, we want it to be bitcoin,
>> but
>> the bleeding edge bitcoin so we want to respect the 21 million coin limit,
>> and allow coins to move between bitcoin and betacoin with some necessary
>> security related restrictions.
>>
>> There is no mining reward on the betacoin network (can be merge mined for
>> security), and the way you opt to move a bitcoin into the betacoin network
>> is to mark it as transferred in some UTXO recognized way.  It cant be
>> reanimated, its dead.  (eg spend to a specific recognized invalid address
>> on
>> the bitcoin network).  In this way its not really a destruction, but a
>> move,
>> moving the coin from bitcoin to betacoin network.
>>
>> This respects the 21 million coin cap, and avoids betacoin bugs flowing
>> back
>> and affecting bitcoin security or value-store properties.  Users may buy
>> or
>> swap betacoin for bitcoin to facilitate moving money back from betacoin to
>> bitcoin.  However that is market priced so the bitcoin network is security
>> insulated from beta.  A significant security bug in beta would cause a
>> market freeze, until it is rectified.
>>
>> The cost of a betacoin is capped at one BTC because no one will pay more
>> than one bitcoin for a betacoin because they could alternatively move
>> their
>> own coin.  The reverse is market priced.
>>
>> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
>> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
>> bitcoins can be moved, and the old network switched off, with mining past
>> a
>> flag day moving to the betacoin.
>>
>> During the beta period betacoin is NOT an alpha, people can rely on it and
>> use it in anger for real value transactions.  eg if it enables more script
>> features, or coin coloring, scalabity tweaks etc people can use it.
>> Probably for large value store they are always going to prefer
>> bitcoin-stable, but applications that need the coloring features, or
>> advanced scripting etc can go ahead and beta.
>>
>> Bitcoin-stable may pull validated changes and merge them, as a way to pull
>> in any features needed in the shorter term and benefit from the betacoin
>> validation.  (Testing isnt as much validation as real-money at stake
>> survivability).
>>
>> The arguments are I think that:
>>
>> - it allows faster development allowing bitcoin to progress features
>> faster,
>>
>> - it avoids mindshare dilution if alternatively an alt-coin with a hit
>>  missing feature takes off;
>>
>> - it concentrates such useful-feature alt activities into one OPEN source
>>  and OPEN control foundation mediated area (rather than suspected land
>>  grabs on colored fees or such like bitcoin respun as a business model
>>  things),
>>
>> - maybe gets the developers that would've been working on their pet
>>  alt-coin, or their startup alt-coin to work together putting more
>>  developers, testers and resources onto something with open control (open
>>  source does not necessarily mean that much) and bitcoin mindshare
>>  branding, its STILL bitcoin, its just the beta network.
>>
>> - it respects the 21 million limit, starting new mining races probably
>>  dillutes the artificial scarcity semantic
>>
>> - while insulating bitcoin from betacoin security defects (I dont mean
>>  betacoin as a testnet, it should have prudent rigorous testing like
>>  bitcoin, just the very act of adding a feature creates risk that bitcoin
>>  stable can be hesitant to take).
>>
>> Probably the main issue as always is more (trustable) very high caliber
>> testers and developers.  Maybe if the alt-coin minded startups and
>> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
>> bits they are missing, we'll get more hands to work on something of
>> reusable
>> value to humanity, in parallel with their startup's objectives and as a
>> way
>> for them to get their needed features, while giving back to the bitcoin
>> community, and helping bitcoin progress faster.
>>
>> Maybe bitcoin foundation could ask for BTC donations to hire more
>> developers
>> and testers full time.  $1.5b of stored value should be interested to safe
>> guard their value store, and develop the transaction features.
>>
>> Adam
>>
>> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
>>>
>>>  This is exactly what I was planning to do with the
>>>  inappropriately-named "Ultimate Blockchain Compression".  [...]
>>>
>>>  For it to really work, it's gotta be part of the mainnet validation
>>>  rules, but no way it can be evaluated realistically without some kind of
>>>  "staging".
>>
>>
>>>  On 5/19/2013 11:08 AM, Peter Vessenes wrote:
>>>
>>>  I think this is a very interesting idea. As Bitcoiners, we often stuff
>>>  things into the 'alt chain' bucket in our heads; I wonder if this idea
>>>  works better as a curing period, essentially an extended version of the
>>>  current 100 block wait for mined coins.

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Daniel Murrell]

I've already added it here:
http://www.opencryptocurrencyreview.com/papers/123/enabling-blockchain-innovations-with-pegged-sidechains

I made this site to allow discussions on exactly these sorts of things
to be publicly visible and easily discoverable in the future (this is
why I replied to all).

Please let me know what you think of the site.

Daniel

p.s. I'm not trying to monetize this site. I just tried to make
something I thought could be useful.

On Wed, Oct 22, 2014 at 10:54 PM, Adam Back <adam@cypherspace.org> wrote:
> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf
>
> Adam
>
> On 16 March 2014 15:58, Adam Back <adam@cypherspace.org> wrote:
>> So an update on 1-way pegging (aka bitcoin staging, explained in quoted text
>> at bottom): it turns out secure 2-way pegging is also possible (with some
>> bitcoin change to help support it).  The interesting thing is this allows
>> interoperability in terms of being able to move bitcoin into and out of a
>> side chain.  The side chains may have some different parameters, or
>> experimental things people might want to come up with (subject to some
>> minimum compatibility at the level of being able to produce an SPV proof of
>> a given form).
>>
>> At the time of the 1-way peg discussion I considered 2-way peg as desirable
>> and it seemed plausible with bitcoin changes, but the motivation for 1-way
>> peg was to make it less risky to make changes on bitcoin, so that seemed
>> like a catch-22 loop.  Also in the 2-way peg thought experiment I had not
>> realized how simple it was to still impose a security firewall in the 2-way
>> peg also.
>>
>>
>> So Greg Maxwell proposed in Dec last year a practically compact way to do
>> 2-way pegging using SPV proofs.  And also provided a simple argument of how
>> this can provide a security firewall.  (Security firewall means the impact
>> of security bugs on the side-chain is limited to the people with coins in
>> it; bitcoin holders who did not use it are unaffected). [1]
>>
>> How it works:
>>
>> 1. to maintain the 21m coins promise, you start a side-chain with no
>> in-chain mining subsidy, all bitcoin creation happens on bitcoin chain (as
>> with 1-way peg).  Reach a reasonable hash rate.  (Other semantics than 1:1
>> peg should be possible, but this is the base case).
>>
>> 2. you move coins to the side-chain by spending them to a fancy script,
>> which suspends them, and allows them to be reanimated by the production of
>> an SPV proof of burn on the side-chain.
>>
>> 3. the side-chain has no mining reward, but it allows you to mint coins at
>> no mining cost by providing an SPV proof that the coin has been suspended as
>> in 2 on bitcoin.  The SPV proof must be buried significantly before being
>> used to reduce risk of reorganization.  The side-chain is an SPV client to
>> the bitcoin network, and so maintains a view of the bitcoin hash chain (but
>> not the block data).
>>
>> 4. the bitcoin chain is firewalled from security bugs on the side chain,
>> because bitcoin imposes the rule that no more coins can be reanimated than
>> are currently suspend (with respect to a given chain).
>>
>> 5. to simplify what they hypothetical bitcoin change would need to consider
>> and understand, after a coin is reanimated there is a maturity period
>> imposed (say same as fresh mined coins).  During the maturity period the
>> reanimation script allows a fraud proof to spend the coins back.  A fraud
>> bounty fee (equal to the reanimate fee) can be offered by the mover to
>> incentivize side-chain full nodes to watch reanimations and search for fraud
>> proofs.
>>
>> 6. a fraud proof is an SPV proof with a longer chain showing that the proof
>> of burn was orphaned.
>>
>> There are a few options to compress the SPV proof, via Fiat-Shamir transform
>> to provide a compact proof of amount work contained in a merkle tree of
>> proofs of work (as proposed by Fabien Coelho link on
>> http://hashcash.org/papers/) with params like 90% of work is proven.  But
>> better is something Greg proposed based on skip-lists organized in a tree,
>> where 'lucky' proofs of work are used to skip back further.  (Recalling that
>> if you search for a 64-bit leading-0 proof-of-work, half the time you get a
>> 65-bit, quarter 66-bit etc.)  With this mechanism you can accurately
>> prove the amount of proof of work in a compressed tree (rather than ~90%).
>>
>>
>> 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).
>>
>>
>> This pegging discussion involved a number of #bitcoin-wizards, Greg Maxwell,
>> Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach, Luke Dashjr. The
>> 2-way peg seems to have first been described by Greg.  Greg thought of
>> 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2].
>> (As a ZK-SNARK could compactly prove full validation of a side chain rules).
>>
>> There was also something seemingly similar sounding but not described in
>> detail by Alex Mizrahi in the context of color coins in this post [3].
>>
>> Adam
>>
>> [1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
>> [2] https://bitcointalk.org/index.php?topic=277389.40
>> [3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554
>> [4] http://www.cypherspace.org/p2p/auditable-namespace.html
>>
>> On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote:
>>>
>>> Coming back to the staging idea, maybe this is a realistic model that
>>> could
>>> work.  The objective being to provide a way for bitcoin to move to a live
>>> beta and stable being worked on in parallel like fedora vs RHEL or
>>> odd/even
>>> linux kernel versions.
>>>
>>> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin
>>> 0.x
>>> stable and leap-frogs as beta becomes stable after testing.
>>>
>>> Its a live beta, meaning real value, real contracts.  But we dont want it
>>> to
>>> be an alt-coin with a floating value exactly, we want it to be bitcoin,
>>> but
>>> the bleeding edge bitcoin so we want to respect the 21 million coin limit,
>>> and allow coins to move between bitcoin and betacoin with some necessary
>>> security related restrictions.
>>>
>>> There is no mining reward on the betacoin network (can be merge mined for
>>> security), and the way you opt to move a bitcoin into the betacoin network
>>> is to mark it as transferred in some UTXO recognized way.  It cant be
>>> reanimated, its dead.  (eg spend to a specific recognized invalid address
>>> on
>>> the bitcoin network).  In this way its not really a destruction, but a
>>> move,
>>> moving the coin from bitcoin to betacoin network.
>>>
>>> This respects the 21 million coin cap, and avoids betacoin bugs flowing
>>> back
>>> and affecting bitcoin security or value-store properties.  Users may buy
>>> or
>>> swap betacoin for bitcoin to facilitate moving money back from betacoin to
>>> bitcoin.  However that is market priced so the bitcoin network is security
>>> insulated from beta.  A significant security bug in beta would cause a
>>> market freeze, until it is rectified.
>>>
>>> The cost of a betacoin is capped at one BTC because no one will pay more
>>> than one bitcoin for a betacoin because they could alternatively move
>>> their
>>> own coin.  The reverse is market priced.
>>>
>>> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
>>> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
>>> bitcoins can be moved, and the old network switched off, with mining past
>>> a
>>> flag day moving to the betacoin.
>>>
>>> During the beta period betacoin is NOT an alpha, people can rely on it and
>>> use it in anger for real value transactions.  eg if it enables more script
>>> features, or coin coloring, scalabity tweaks etc people can use it.
>>> Probably for large value store they are always going to prefer
>>> bitcoin-stable, but applications that need the coloring features, or
>>> advanced scripting etc can go ahead and beta.
>>>
>>> Bitcoin-stable may pull validated changes and merge them, as a way to pull
>>> in any features needed in the shorter term and benefit from the betacoin
>>> validation.  (Testing isnt as much validation as real-money at stake
>>> survivability).
>>>
>>> The arguments are I think that:
>>>
>>> - it allows faster development allowing bitcoin to progress features
>>> faster,
>>>
>>> - it avoids mindshare dilution if alternatively an alt-coin with a hit
>>>  missing feature takes off;
>>>
>>> - it concentrates such useful-feature alt activities into one OPEN source
>>>  and OPEN control foundation mediated area (rather than suspected land
>>>  grabs on colored fees or such like bitcoin respun as a business model
>>>  things),
>>>
>>> - maybe gets the developers that would've been working on their pet
>>>  alt-coin, or their startup alt-coin to work together putting more
>>>  developers, testers and resources onto something with open control (open
>>>  source does not necessarily mean that much) and bitcoin mindshare
>>>  branding, its STILL bitcoin, its just the beta network.
>>>
>>> - it respects the 21 million limit, starting new mining races probably
>>>  dillutes the artificial scarcity semantic
>>>
>>> - while insulating bitcoin from betacoin security defects (I dont mean
>>>  betacoin as a testnet, it should have prudent rigorous testing like
>>>  bitcoin, just the very act of adding a feature creates risk that bitcoin
>>>  stable can be hesitant to take).
>>>
>>> Probably the main issue as always is more (trustable) very high caliber
>>> testers and developers.  Maybe if the alt-coin minded startups and
>>> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
>>> bits they are missing, we'll get more hands to work on something of
>>> reusable
>>> value to humanity, in parallel with their startup's objectives and as a
>>> way
>>> for them to get their needed features, while giving back to the bitcoin
>>> community, and helping bitcoin progress faster.
>>>
>>> Maybe bitcoin foundation could ask for BTC donations to hire more
>>> developers
>>> and testers full time.  $1.5b of stored value should be interested to safe
>>> guard their value store, and develop the transaction features.
>>>
>>> Adam
>>>
>>> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
>>>>
>>>>  This is exactly what I was planning to do with the
>>>>  inappropriately-named "Ultimate Blockchain Compression".  [...]
>>>>
>>>>  For it to really work, it's gotta be part of the mainnet validation
>>>>  rules, but no way it can be evaluated realistically without some kind of
>>>>  "staging".
>>>
>>>
>>>>  On 5/19/2013 11:08 AM, Peter Vessenes wrote:
>>>>
>>>>  I think this is a very interesting idea. As Bitcoiners, we often stuff
>>>>  things into the 'alt chain' bucket in our heads; I wonder if this idea
>>>>  works better as a curing period, essentially an extended version of the
>>>>  current 100 block wait for mined coins.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Bryan Bishop]

On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell <dsmurrell@gmail.com> wrote:
> p.s. I'm not trying to monetize this site. I just tried to make
> something I thought could be useful.

[Unsolicited administrivia follows.]

You have been posting this in a bunch of places for a while now, at
least three times today by my count on other mediums. I also observed
negative karma scores associated with these posts. Maybe you could
consider toning down the message frequency? I think by now everyone
knows you want them to use your site. I also think that in the limit
that it would be inappropriate for /everyone/ to post all possible
research sites, or even vaguely topical discussion sites, for every
paper posted. Personally, I would much rather have discussions happen
on the mailing list anyway, although if I had a different opinion I
certainly hope I would still send this message.

Thank you.

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Daniel Murrell]

Sorry Bryan, this was the first paper posted to this list since I've
been on it that I added to my site. I was quite excited about this.

I was not planning on and certainly won't be making this advertisement
after every paper posted on this list (I may do it on reddit). I did
post on reddit a few times yes, but I assumed that this list's user
base didn't overlap extremely (does it?). I'm not sure why my posts
got down voted there. The down voters gave me no constructive feedback
about the usefulness of my site, and neither have you.

Are you able to give me your feedback on the site I've spent quite
some time setting up privately so that we don't spam this list again?



On Wed, Oct 22, 2014 at 11:35 PM, Bryan Bishop <kanzure@gmail.com> wrote:
> On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell <dsmurrell@gmail.com> wrote:
>> p.s. I'm not trying to monetize this site. I just tried to make
>> something I thought could be useful.
>
> [Unsolicited administrivia follows.]
>
> You have been posting this in a bunch of places for a while now, at
> least three times today by my count on other mediums. I also observed
> negative karma scores associated with these posts. Maybe you could
> consider toning down the message frequency? I think by now everyone
> knows you want them to use your site. I also think that in the limit
> that it would be inappropriate for /everyone/ to post all possible
> research sites, or even vaguely topical discussion sites, for every
> paper posted. Personally, I would much rather have discussions happen
> on the mailing list anyway, although if I had a different opinion I
> certainly hope I would still send this message.
>
> Thank you.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Jeff Garzik]

Take the discussion of this site to another M-L, please.  It is off-topic.

Actual discussion of the paper and side-chains is on-topic.

This M-L is publicly archived.


On Wed, Oct 22, 2014 at 6:52 PM, Daniel Murrell <dsmurrell@gmail.com> wrote:
> Sorry Bryan, this was the first paper posted to this list since I've
> been on it that I added to my site. I was quite excited about this.
>
> I was not planning on and certainly won't be making this advertisement
> after every paper posted on this list (I may do it on reddit). I did
> post on reddit a few times yes, but I assumed that this list's user
> base didn't overlap extremely (does it?). I'm not sure why my posts
> got down voted there. The down voters gave me no constructive feedback
> about the usefulness of my site, and neither have you.
>
> Are you able to give me your feedback on the site I've spent quite
> some time setting up privately so that we don't spam this list again?
>
>
>
> On Wed, Oct 22, 2014 at 11:35 PM, Bryan Bishop <kanzure@gmail.com> wrote:
>> On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell <dsmurrell@gmail.com> wrote:
>>> p.s. I'm not trying to monetize this site. I just tried to make
>>> something I thought could be useful.
>>
>> [Unsolicited administrivia follows.]
>>
>> You have been posting this in a bunch of places for a while now, at
>> least three times today by my count on other mediums. I also observed
>> negative karma scores associated with these posts. Maybe you could
>> consider toning down the message frequency? I think by now everyone
>> knows you want them to use your site. I also think that in the limit
>> that it would be inappropriate for /everyone/ to post all possible
>> research sites, or even vaguely topical discussion sites, for every
>> paper posted. Personally, I would much rather have discussions happen
>> on the mailing list anyway, although if I had a different opinion I
>> certainly hope I would still send this message.
>>
>> Thank you.
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Melvin Carvalho]

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

On 22 October 2014 23:54, Adam Back <adam@cypherspace.org> wrote:

> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf
>

A very well written paper, thank you for putting it together and sharing.

Given it's the 6 year birthday of satoshi's white paper, I just read
through it again.

I find it interesting that bitcoin is never defined in Satoshi's paper,
indeed, it never appears after the first word.

The term Electronic Coin is defined.

The terminology of bitcoin / altcoin / altchain / blockchain in this paper
still leaves me slightly uneasy, and I try to use the terms electronic coin
and electronic cash, more often.

If satoshi were to come back and continue his work, would it be an altcoin,
would it be "The" blockchain, would it be bitcoin, or would what we know as
bitcoin become an alt.  I suspect these questions are nothing more than
academic curiosity.

But I think I'll get more used to it over time :)

In any case, happy birthday "bitcoin" :)


>
> Adam
>
> On 16 March 2014 15:58, Adam Back <adam@cypherspace.org> wrote:
> > So an update on 1-way pegging (aka bitcoin staging, explained in quoted
> text
> > at bottom): it turns out secure 2-way pegging is also possible (with some
> > bitcoin change to help support it).  The interesting thing is this allows
> > interoperability in terms of being able to move bitcoin into and out of a
> > side chain.  The side chains may have some different parameters, or
> > experimental things people might want to come up with (subject to some
> > minimum compatibility at the level of being able to produce an SPV proof
> of
> > a given form).
> >
> > At the time of the 1-way peg discussion I considered 2-way peg as
> desirable
> > and it seemed plausible with bitcoin changes, but the motivation for
> 1-way
> > peg was to make it less risky to make changes on bitcoin, so that seemed
> > like a catch-22 loop.  Also in the 2-way peg thought experiment I had not
> > realized how simple it was to still impose a security firewall in the
> 2-way
> > peg also.
> >
> >
> > So Greg Maxwell proposed in Dec last year a practically compact way to do
> > 2-way pegging using SPV proofs.  And also provided a simple argument of
> how
> > this can provide a security firewall.  (Security firewall means the
> impact
> > of security bugs on the side-chain is limited to the people with coins in
> > it; bitcoin holders who did not use it are unaffected). [1]
> >
> > How it works:
> >
> > 1. to maintain the 21m coins promise, you start a side-chain with no
> > in-chain mining subsidy, all bitcoin creation happens on bitcoin chain
> (as
> > with 1-way peg).  Reach a reasonable hash rate.  (Other semantics than
> 1:1
> > peg should be possible, but this is the base case).
> >
> > 2. you move coins to the side-chain by spending them to a fancy script,
> > which suspends them, and allows them to be reanimated by the production
> of
> > an SPV proof of burn on the side-chain.
> >
> > 3. the side-chain has no mining reward, but it allows you to mint coins
> at
> > no mining cost by providing an SPV proof that the coin has been
> suspended as
> > in 2 on bitcoin.  The SPV proof must be buried significantly before being
> > used to reduce risk of reorganization.  The side-chain is an SPV client
> to
> > the bitcoin network, and so maintains a view of the bitcoin hash chain
> (but
> > not the block data).
> >
> > 4. the bitcoin chain is firewalled from security bugs on the side chain,
> > because bitcoin imposes the rule that no more coins can be reanimated
> than
> > are currently suspend (with respect to a given chain).
> >
> > 5. to simplify what they hypothetical bitcoin change would need to
> consider
> > and understand, after a coin is reanimated there is a maturity period
> > imposed (say same as fresh mined coins).  During the maturity period the
> > reanimation script allows a fraud proof to spend the coins back.  A fraud
> > bounty fee (equal to the reanimate fee) can be offered by the mover to
> > incentivize side-chain full nodes to watch reanimations and search for
> fraud
> > proofs.
> >
> > 6. a fraud proof is an SPV proof with a longer chain showing that the
> proof
> > of burn was orphaned.
> >
> > There are a few options to compress the SPV proof, via Fiat-Shamir
> transform
> > to provide a compact proof of amount work contained in a merkle tree of
> > proofs of work (as proposed by Fabien Coelho link on
> > http://hashcash.org/papers/) with params like 90% of work is proven.
> But
> > better is something Greg proposed based on skip-lists organized in a
> tree,
> > where 'lucky' proofs of work are used to skip back further.  (Recalling
> that
> > if you search for a 64-bit leading-0 proof-of-work, half the time you
> get a
> > 65-bit, quarter 66-bit etc.)  With this mechanism you can accurately
> > prove the amount of proof of work in a compressed tree (rather than
> ~90%).
> >
> >
> > 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).
> >
> >
> > This pegging discussion involved a number of #bitcoin-wizards, Greg
> Maxwell,
> > Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach, Luke Dashjr.
> The
> > 2-way peg seems to have first been described by Greg.  Greg thought of
> > 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2].
> > (As a ZK-SNARK could compactly prove full validation of a side chain
> rules).
> >
> > There was also something seemingly similar sounding but not described in
> > detail by Alex Mizrahi in the context of color coins in this post [3].
> >
> > Adam
> >
> > [1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
> > [2] https://bitcointalk.org/index.php?topic=277389.40
> > [3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554
> > [4] http://www.cypherspace.org/p2p/auditable-namespace.html
> >
> > On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote:
> >>
> >> Coming back to the staging idea, maybe this is a realistic model that
> >> could
> >> work.  The objective being to provide a way for bitcoin to move to a
> live
> >> beta and stable being worked on in parallel like fedora vs RHEL or
> >> odd/even
> >> linux kernel versions.
> >>
> >> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin
> >> 0.x
> >> stable and leap-frogs as beta becomes stable after testing.
> >>
> >> Its a live beta, meaning real value, real contracts.  But we dont want
> it
> >> to
> >> be an alt-coin with a floating value exactly, we want it to be bitcoin,
> >> but
> >> the bleeding edge bitcoin so we want to respect the 21 million coin
> limit,
> >> and allow coins to move between bitcoin and betacoin with some necessary
> >> security related restrictions.
> >>
> >> There is no mining reward on the betacoin network (can be merge mined
> for
> >> security), and the way you opt to move a bitcoin into the betacoin
> network
> >> is to mark it as transferred in some UTXO recognized way.  It cant be
> >> reanimated, its dead.  (eg spend to a specific recognized invalid
> address
> >> on
> >> the bitcoin network).  In this way its not really a destruction, but a
> >> move,
> >> moving the coin from bitcoin to betacoin network.
> >>
> >> This respects the 21 million coin cap, and avoids betacoin bugs flowing
> >> back
> >> and affecting bitcoin security or value-store properties.  Users may buy
> >> or
> >> swap betacoin for bitcoin to facilitate moving money back from betacoin
> to
> >> bitcoin.  However that is market priced so the bitcoin network is
> security
> >> insulated from beta.  A significant security bug in beta would cause a
> >> market freeze, until it is rectified.
> >>
> >> The cost of a betacoin is capped at one BTC because no one will pay more
> >> than one bitcoin for a betacoin because they could alternatively move
> >> their
> >> own coin.  The reverse is market priced.
> >>
> >> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
> >> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
> >> bitcoins can be moved, and the old network switched off, with mining
> past
> >> a
> >> flag day moving to the betacoin.
> >>
> >> During the beta period betacoin is NOT an alpha, people can rely on it
> and
> >> use it in anger for real value transactions.  eg if it enables more
> script
> >> features, or coin coloring, scalabity tweaks etc people can use it.
> >> Probably for large value store they are always going to prefer
> >> bitcoin-stable, but applications that need the coloring features, or
> >> advanced scripting etc can go ahead and beta.
> >>
> >> Bitcoin-stable may pull validated changes and merge them, as a way to
> pull
> >> in any features needed in the shorter term and benefit from the betacoin
> >> validation.  (Testing isnt as much validation as real-money at stake
> >> survivability).
> >>
> >> The arguments are I think that:
> >>
> >> - it allows faster development allowing bitcoin to progress features
> >> faster,
> >>
> >> - it avoids mindshare dilution if alternatively an alt-coin with a hit
> >>  missing feature takes off;
> >>
> >> - it concentrates such useful-feature alt activities into one OPEN
> source
> >>  and OPEN control foundation mediated area (rather than suspected land
> >>  grabs on colored fees or such like bitcoin respun as a business model
> >>  things),
> >>
> >> - maybe gets the developers that would've been working on their pet
> >>  alt-coin, or their startup alt-coin to work together putting more
> >>  developers, testers and resources onto something with open control
> (open
> >>  source does not necessarily mean that much) and bitcoin mindshare
> >>  branding, its STILL bitcoin, its just the beta network.
> >>
> >> - it respects the 21 million limit, starting new mining races probably
> >>  dillutes the artificial scarcity semantic
> >>
> >> - while insulating bitcoin from betacoin security defects (I dont mean
> >>  betacoin as a testnet, it should have prudent rigorous testing like
> >>  bitcoin, just the very act of adding a feature creates risk that
> bitcoin
> >>  stable can be hesitant to take).
> >>
> >> Probably the main issue as always is more (trustable) very high caliber
> >> testers and developers.  Maybe if the alt-coin minded startups and
> >> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
> >> bits they are missing, we'll get more hands to work on something of
> >> reusable
> >> value to humanity, in parallel with their startup's objectives and as a
> >> way
> >> for them to get their needed features, while giving back to the bitcoin
> >> community, and helping bitcoin progress faster.
> >>
> >> Maybe bitcoin foundation could ask for BTC donations to hire more
> >> developers
> >> and testers full time.  $1.5b of stored value should be interested to
> safe
> >> guard their value store, and develop the transaction features.
> >>
> >> Adam
> >>
> >> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
> >>>
> >>>  This is exactly what I was planning to do with the
> >>>  inappropriately-named "Ultimate Blockchain Compression".  [...]
> >>>
> >>>  For it to really work, it's gotta be part of the mainnet validation
> >>>  rules, but no way it can be evaluated realistically without some kind
> of
> >>>  "staging".
> >>
> >>
> >>>  On 5/19/2013 11:08 AM, Peter Vessenes wrote:
> >>>
> >>>  I think this is a very interesting idea. As Bitcoiners, we often stuff
> >>>  things into the 'alt chain' bucket in our heads; I wonder if this idea
> >>>  works better as a curing period, essentially an extended version of
> the
> >>>  current 100 block wait for mined coins.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Alex Mizrahi]

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

> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf


Haven't seen any material discussion of this paper in this mailing list, so
I'll start.
(Otherwise, I've seen Peter Todd's reaction on reddit.)

This paper fails to demonstrate that sidechains are anything more than a
wishful thinking.
It can be distilled down to this:
"We want such and such features, hence we'll use DMMS, the same thing
Bitcoin uses, thus it will be secure!"
Um, no.
Alt-coins also use DMMS, but aren't as secure as Bitcoin.

So DMMS does not work by itself, it is a mechanism to secure a blockchain
using economic incentives.
The sidechains paper does not mention this, as far as I can tell.

In my opinion, this is not acceptable. If you're making a proposal, you
need to describe what conditions are required for it to work.

Authors are clearly aware of the problem and mention it in section 6
"Future directions" 6.1. "Hashpower attack resistance".
The problem is they do not make it clear that the proposal just makes no
sense until this is solved.

In the discussions on reddit I've noticed that pretty much everybody
believes that release of sidechains paper implies that the proposal is
complete and now we are just waiting the implementation.

It doesn't help that the paper itself tries to sweep the problem under the
rug and has misleading statements.
Particularly, I'm talking about section "4.2. Fraudulent transfers":

"Reorganisations of arbitrary depth are in principle possible, which could
allow an attacker to
completely transfer coins between sidechains before causing a
reorganisation longer than the contest
period on the sending chain to undo its half of the transfer. ... If the
attacker is allowed to return the transferred coins to  the original
chain, he would increase the number of coins in his possession at the
expense of other users of the sidechain.
Before discussing how to handle this, we observe that this risk can be made
arbitrarily small by
simply increasing the contest period for transfers."

Wow, really? Is this risk stochastic?

The first sentence implies that attacker is able to cause a reorganization
of an arbitrary depth, but the rest of the section implies that
reorganizations are a naturally occurring phenomenon.

All in all, I find this paper really disappointing. It's going to be
influential (9 co-authors, many of which are regarded as Bitcoin core
developers, must be good!) and hyped, and thus might focus research on an
area which is fundamentally flawed.

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

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Jorge Timón]

On Mon, Nov 3, 2014 at 1:12 PM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
>
>> For those following this thread, we have now written a paper
>> describing the side-chains, 2-way pegs and compact SPV proofs.
>> (With additional authors Andrew Poelstra & Andrew Miller).
>>
>> http://blockstream.com/sidechains.pdf
>
>
> Haven't seen any material discussion of this paper in this mailing list, so
> I'll start.
> (Otherwise, I've seen Peter Todd's reaction on reddit.)
>
> This paper fails to demonstrate that sidechains are anything more than a
> wishful thinking.
> It can be distilled down to this:
> "We want such and such features, hence we'll use DMMS, the same thing
> Bitcoin uses, thus it will be secure!"
> Um, no.
> Alt-coins also use DMMS, but aren't as secure as Bitcoin.
>
> So DMMS does not work by itself, it is a mechanism to secure a blockchain
> using economic incentives.
> The sidechains paper does not mention this, as far as I can tell.
>
> In my opinion, this is not acceptable. If you're making a proposal, you need
> to describe what conditions are required for it to work.

From the introduction "[...]Because signers prove computational work,
rather than proving secret knowledge as
is typical for digital signatures, we refer to them as miners. To
achieve stable consensus on the
blockchain history, economic incentives are provided where miners are
rewarded with fees and
subsidies in the form of coins that are valuable only if the miners
form a shared valid history,
incentivising them to behave honestly.[...]"

Ignoring altrustic miners, the irreversibility of a DMMS chain
obviously depends on the rewards received by miners on that chain.
Nobody is claiming that sidechains will be "as secure bitcoin", any 2
way pegged assets is always "more secure" (probably too vague of a
term in this context) in its original chain.

> Authors are clearly aware of the problem and mention it in section 6 "Future
> directions" 6.1. "Hashpower attack resistance".
> The problem is they do not make it clear that the proposal just makes no
> sense until this is solved.

Since all seigniorage from Bitcoin's initial distribution is spent on
mining subsidies for the main chain, it is not available to subsidize
sidechains too. Thus sidechains, in principle, reward their miners
with the same Bitcoin will use in the future: only transaction fees.
Since some people claim that won't be enough (is not always clear to
me if they believe that won't be enough for sidechains or also for
bitcoin when the subsidies are gone), we included this section with
other ideas we have explored to further. Some of them, like
"time-shifted fees" could be interesting for Bitcoin itself in the
future.

> It doesn't help that the paper itself tries to sweep the problem under the
> rug and has misleading statements.
> Particularly, I'm talking about section "4.2. Fraudulent transfers":
>
> "Reorganisations of arbitrary depth are in principle possible, which could
> allow an attacker to
> completely transfer coins between sidechains before causing a reorganisation
> longer than the contest
> period on the sending chain to undo its half of the transfer. ... If the
> attacker is allowed to return the transferred coins to  the original
> chain, he would increase the number of coins in his possession at the
> expense of other users of the sidechain.
> Before discussing how to handle this, we observe that this risk can be made
> arbitrarily small by
> simply increasing the contest period for transfers."
>
> Wow, really? Is this risk stochastic?
>
> The first sentence implies that attacker is able to cause a reorganization
> of an arbitrary depth, but the rest of the section implies that
> reorganizations are a naturally occurring phenomenon.

Reorganizations are both a naturally occurring phenomenon and
something that an attacker may cause to revert history.
Section "11. Calculations" of the Bitcoin whitepaper gives you this
formula (in C code):

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k <= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i <= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}
Also says "Given our assumption that p > q, the probability drops
exponentially as the number of blocks the
attacker has to catch up with increases."

In this case, the contest period determines z, the number of blocks
the attacker has to catch up from the honest chain.
So the longer the contest period is, the harder it is to succeed with
a fraudulent transfer.
For example, if a given sidechain chooses 52560 as the contest period
(1 year assuming 10 min blocks), it will be very hard for an attacker
to produce a fake alternative longest-than-the-last-year-of-history
fork to steal coins.
A sidechain with such an extreme contest period would probably not be
very practical though, since honest users would have to wait more than
a year to complete transfers from the parent chain to the sidechain
and viceversa.

I hope this clarifies our assumptions.

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Alex Mizrahi]

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

> From the introduction "[...]Because signers prove computational work,
> rather than proving secret knowledge as
> is typical for digital signatures, we refer to them as miners. To
> achieve stable consensus on the
> blockchain history, economic incentives are provided where miners are
> rewarded with fees and
> subsidies in the form of coins that are valuable only if the miners
> form a shared valid history,
> incentivising them to behave honestly.[...]"
>

This isn't applicable in case of sidechains: anybody with sufficient
hashpower will be able to unlock a locked coin on the parent chain by
producing an SPV proof.
"Only if the miners form a shared valid history" isn't a requirement here,
as miner will get bitcoins which aren't in any way connect to sidechain he
have wrecked.  Thus there is no incentive to behave honestly.

Thus sidechains, in principle, reward their miners
>
with the same Bitcoin will use in the future: only transaction fees.
> Since some people claim that won't be enough


Whether it is enough depends on a variety of factors, including existence
of other chains miner can mine.
You cannot assume that it is the same situation as with a simple
single-chain model.

E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining
bitcoins as usual, and in parallel work on an SPV proof to claim these 1000
BTC. (I assume that merged-mining is allowed.)
In this case the amount of fees which miners could collect by honest mining
on the sidechain is irrelevant, as long as it is smaller than 1000 BTC.

This is quite different from attacks which can be performed on vanilla
Bitcoin (see below), so I don't think you can say that the security model
is the same.

Also says "Given our assumption that p > q, the probability drops
>
exponentially as the number of blocks the
> attacker has to catch up with increases."
>

Yes, but that doesn't apply to reorganizations which attacker might cause
intentionally.
Hence I think it was disingenuous to include these two very different
treats into one section:
it sounds like you claim that attacker-induced reorganizations are
unlikely, while it isn't the case.

So the longer the contest period is, the harder it is to succeed with
> a fraudulent transfer.
>

Yes, but "harder" isn't same as "unlikely".

Another problem with this section is that it only mentions reorganizations.
But a fraudulent transfer can happen without a reorganization, as an
attacker can produce an SPV proof which is totally fake. So this is not
similar to double-spending, attacker doesn't need to own coins to perform
an attack.


> I hope this clarifies our assumptions.
>

Yep, thanks. It looks like you assume that sidechain security will be
similar to Bitcoin security in the long term.
Now quite the assumptions I've been looking for, but OK...

I'm sorry for the harsh tone, but I just find it hilarious that people who
explained that proof-of-stake is not going to work because an attacker
might collect everybody's past signing keys to rewrite the whole history
(I'm referring to this: https://download.wpsoftware.net/bitcoin/pos.pdf )
didn't bother to mention that miners can collude to wreck a sidechain and
get an awesome reward, basically for free.
something something the mote in thy brother's eye something something

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

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Jorge Timón]

On Mon, Nov 3, 2014 at 5:01 PM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
> This isn't applicable in case of sidechains: anybody with sufficient
> hashpower will be able to unlock a locked coin on the parent chain by
> producing an SPV proof.
> "Only if the miners form a shared valid history" isn't a requirement here,
> as miner will get bitcoins which aren't in any way connect to sidechain he
> have wrecked.  Thus there is no incentive to behave honestly.

But if the majority of the sidechain miners keep working on the honest
chain, anyone can submit a reorg proof during the contest period that
invalidates this "unlockment" on the parent chain.
Honest sidechain miners will get rewarded in the sidechain, and those
rewards will only be valuable if they form a shared valid history.

> Whether it is enough depends on a variety of factors, including existence of
> other chains miner can mine.
> You cannot assume that it is the same situation as with a simple
> single-chain model.

This is correct. There's many variables at play.

> E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining
> bitcoins as usual, and in parallel work on an SPV proof to claim these 1000
> BTC. (I assume that merged-mining is allowed.)
> In this case the amount of fees which miners could collect by honest mining
> on the sidechain is irrelevant, as long as it is smaller than 1000 BTC.

As explained many times, sidechains and merged mining are orthogonal:
pegged sidechains don't need to use merged mining just as merged
mining altchains don't need to be sidechains.
Anyway, I think you're somehow assuming that deciding to mine against
the sidechain instead of mining for its rewards.
This is simply not true. No matter how big the attack incentive is, if
you're assuming my 52560 contest period example and that the attacker
doesn't control the majority of the hashing power on the sidechain,
the probability of achieving a one-year reorg is negligible. In the
meantime honest nodes are getting some reward, let's say 0.1 BTC per
block. That's 5256 btc/year to the honest nodes vs 0 btc/year for the
attacker.
If the attacker controls, say, 10% of the network, he's losing 525.6
btc/year in opportunity costs for an extremely small chance of getting
1000 btc.

> This is quite different from attacks which can be performed on vanilla
> Bitcoin (see below), so I don't think you can say that the security model is
> the same.

We're not claiming that the security model is the same, we just
compare it to Bitcoin's because it's similar in many senses.

>> Also says "Given our assumption that p > q, the probability drops
>>
>> exponentially as the number of blocks the
>> attacker has to catch up with increases."
>
>
> Yes, but that doesn't apply to reorganizations which attacker might cause
> intentionally.

Yes, that's precisely the kind of reorganizations the BITCOIN
WHITEPAPER is talking about in section "11 Calculations":
reorganizations caused intentionally by an attacker. Please read it
again.
"q_z = probability THE ATTACKER will ever catch up from z blocks behind".

> Hence I think it was disingenuous to include these two very different treats
> into one section:
> it sounds like you claim that attacker-induced reorganizations are unlikely,
> while it isn't the case.

If it sounds to you like we're claiming that attacker-induced
reorganizations are not likely, maybe we could have expressed it some
other way. That was certainly not the intention.
That's not true for Bitcoin itself and that's not what we're claiming.

>> So the longer the contest period is, the harder it is to succeed with
>> a fraudulent transfer.
>
>
> Yes, but "harder" isn't same as "unlikely".

Exponentially harder with the number of blocks is good enough for me.

> Another problem with this section is that it only mentions reorganizations.
> But a fraudulent transfer can happen without a reorganization, as an
> attacker can produce an SPV proof which is totally fake. So this is not
> similar to double-spending, attacker doesn't need to own coins to perform an
> attack.

That would be a reorganization too, you can't create a completely fake
history for a sidechain, the attacker will share some of the chain's
history.
Yes, the attacker can create an SPV proof of a fake chain and in that
sense, this is different from a regular double-spend.
If honest miners control the majority of the hashing power, they will
produce a valid chain longer than the fake chain. And then anyone can
use that reorg proof to stop the attacker before the contest period.
You see, "SPV security" is not the same as "SPV security with more
than 52560 confirmations of the transaction I'm receiving".

>> I hope this clarifies our assumptions.
>
> Yep, thanks. It looks like you assume that sidechain security will be
> similar to Bitcoin security in the long term.
> Now quite the assumptions I've been looking for, but OK...
>
> I'm sorry for the harsh tone, but I just find it hilarious that people who
> explained that proof-of-stake is not going to work because an attacker might
> collect everybody's past signing keys to rewrite the whole history
> (I'm referring to this: https://download.wpsoftware.net/bitcoin/pos.pdf )
> didn't bother to mention that miners can collude to wreck a sidechain and
> get an awesome reward, basically for free.

Proof of work is not free, that's the whole point of proof of work.
As said, sidechains, like Bitcoin itself, relies on the assumption
that an attacker won't control a majority of the network. Satoshi's
paper just says that p must be greater than q.
We go beyond that precisely at the beginning of the "6.1 Hashpower
attack resistance" section:

"The main thrust of this paper surrounds two-way peg using SPV proofs,
which are forgeable by a
51%-majority and blockable by however much hashpower is needed to
build a sufficiently-long
proof during the transfer’s contest period. (There is a tradeoff on
this latter point — if 33%
hashpower can block a proof, then 67% is needed to successfully use a
false one, and so on.)"

I'm happy to keep trying to clarify things. But I think we will
advance faster if you first tell me what do you think the contest
period is for.
Because that's I think the source of your misunderstandings. From what
you're saying, I don't think you're having the contest period into
account at all.

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Andrew Poelstra]

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

On Mon, Nov 03, 2014 at 06:01:46PM +0200, Alex Mizrahi wrote:
> 
> Yes, but "harder" isn't same as "unlikely".
>

We are aware of the distintion between hardness (expected work) and
likelihood of successful attack -- much of Appendix B talks about this,
in the context of producing compact SPV proofs which are (a) hard to
forge, and (b) very unlikely to be forgeries.

We did spend some time formalizing this but due to space constraints
(and it being somewhat beside the point of the whitepaper beyond "we
believe it is possible to do"), we did not explore this in as great
depth as we'd have liked.
 
> Another problem with this section is that it only mentions reorganizations.
> But a fraudulent transfer can happen without a reorganization, as an
> attacker can produce an SPV proof which is totally fake. So this is not
> similar to double-spending, attacker doesn't need to own coins to perform
> an attack.
> 

Well, even in the absense of a reorganization, the attacker's false proof
will just be invalidated by a proof of longer work on the real chain.
And there is still a real cost to producing the false proof.


-- 
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
Web:   http://www.wpsoftware.net/andrew


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

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Possibly relevant...

https://www.iacr.org/archive/eurocrypt2002/23320001/euro02.ps

Some interesting stuff here too
http://des.cse.nsysu.edu.tw/asiacrypt2014/accepted/index.htm


Andrew Poelstra wrote:
> false proof

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJUV9mzAAoJEGxwq/inSG8C0qwIAJZdOmeSK7pIw2KTj0lQlPIp
MIc1w2KL+qIVXSrlqyNlcIhlW4gK+/cuYD+PZ7wSGHV2k9OD6AcOo3JfGYgk4LP/
3GIrY/+TQVoTRKVgTGvR2uqUILuwCPTtr/7Uy2s2y2mveyFda6ZA7sMeoeiTsQQe
9aPS6tLK0W7g+gbqM2QwC3G521iPJ9RE9JOsxCVxGplVUuOLpPzovQjFO3MKYdeu
eBq5ORr4ICvphk+yVygkQvw/AuYZjqTuKEjRfK0v5EryZM9Qsj/1pEhYAH8tdLrV
4NB5lDXIo3rt58wPqyeacMF6WW2LShb1VDl6Hnvi35GXURpBgxXM/N4pO+l444k=
=9q9h
-----END PGP SIGNATURE-----