[Bitcoin-development] is there a way to do bitcoin-staging?

[Bitcoin-development] is there a way to do bitcoin-staging?

[Adam Back]

Is there a way to experiment with new features - eg committed coins - that
doesnt involve an altcoin in the conventional sense, and also doesnt impose
a big testing burden on bitcoin main which is a security and testing risk?

eg lets say some form of merged mine where an alt-coin lets call it
bitcoin-staging?  where the coins are the same coins as on bitcoin, the
mining power goes to bitcoin main, so some aspect of merged mining, but no
native mining.  and ability to use bitcoins by locking them on bitcoin to
move them to bitcoin-staging and vice versa (ie exchange them 1:1
cryptographically, no exchange).

Did anyone figure anything like that out?  Seems vaguely doable and
maybe productive.  The only people with coins at risk of defects in a new
feature, or insufficiently well tested novel feature are people with coins
on bitcoin-staging.

Yes I know about bitcoin-test this is not it.  I mean a real live system,
with live value, but that is intentionally wanting to avoid forking bitcoins
parameters, nor value, nor mindshare dillution.  In this way something
potentially interesting could move forward faster, and be les risky to the
main bitcoin network.  eg particularly defenses against 

It might also be a more real world test test (after bitcoin-test) because
some parameters are different on test, and some issues may not manifest
without more real activity.

Then also bitcoin could cherry pick interesting patches and merge them after
extensive real-world validation with real-money at stake (by early
adopters).

Adam

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Peter Vessenes]

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

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.

An alternate setup comes to mind; I can imagine this working as a sort of
gift economy; people pay real BTC for merge-mined "beta BTC" as a way to
support development. There is no doubt a more elegant and practical
solution that might have different economic and crypto characteristics.



On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam@cypherspace.org> wrote:

> Is there a way to experiment with new features - eg committed coins - that
> doesnt involve an altcoin in the conventional sense, and also doesnt impose
> a big testing burden on bitcoin main which is a security and testing risk?
>
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging?  where the coins are the same coins as on bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged mining, but no
> native mining.  and ability to use bitcoins by locking them on bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
>
> Did anyone figure anything like that out?  Seems vaguely doable and
> maybe productive.  The only people with coins at risk of defects in a new
> feature, or insufficiently well tested novel feature are people with coins
> on bitcoin-staging.
>
> Yes I know about bitcoin-test this is not it.  I mean a real live system,
> with live value, but that is intentionally wanting to avoid forking
> bitcoins
> parameters, nor value, nor mindshare dillution.  In this way something
> potentially interesting could move forward faster, and be les risky to the
> main bitcoin network.  eg particularly defenses against
>
> It might also be a more real world test test (after bitcoin-test) because
> some parameters are different on test, and some issues may not manifest
> without more real activity.
>
> Then also bitcoin could cherry pick interesting patches and merge them
> after
> extensive real-world validation with real-money at stake (by early
> adopters).
>
> Adam
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Are you coming to Bitcoin2013 <http://bitcoin2013.com> in San Jose In May?
------------------------------

[image: CoinLab Logo]PETER VESSENES
CEO

*peter@coinlab.com * /  206.486.6856  / SKYPE: vessenes
71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Alan Reiner]

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

This is exactly what I was planning to do with the inappropriately-named 
"Ultimate Blockchain Compression 
<https://bitcointalk.org/index.php?topic=88208.0>".  I wanted to 
reorganize the blockchain data into an authenticated tree, indexed by 
TxOut script (address), instead of tx-hash.  Much like a regular merkle 
tree, you can store the root in the block header, and communicate 
branches of that tree to nodes, to prove inclusion (and exclusion!) of 
TxOuts for any given script/address.  Additionally, you can include at 
each node, the sum of BTC in all nodes below it, which offers some other 
nice benefits.

I think this idea is has epic upside-potential for bitcoin if it works 
-- even "SPV" nodes could query their unspent TxOut list for their 
wallet from any untrusted peer and compare the result directly to the 
blockheaders/POW.  Given nothing but the headers, you can verify the 
balance of 100 addresses with 250 kB.  But also epic failure-potential 
in terms of feasibility and cost-to-benefit for miners.  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".  
Therefore, I had proposed that this be merge-mined on a "meta-chain" 
first...get a bunch of miners on board to agree to merge mine and see it 
in action.  It seemed like a perfectly non-disruptive way to prove out a 
particular idea before we actually consider making a protocol change 
that significant.  Even if it stayed on its own meta chain, as long as 
there is some significant amount of hashpower working on it, it can 
still be a useful tool.

Unfortunately, my experience with merged mining is minimal, so I'm still 
not clear how feasible/reliable it is as an alternative to direct 
blockchain integration.  That's a discussion I'd like to have.

-Alan


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.
>
> An alternate setup comes to mind; I can imagine this working as a sort 
> of gift economy; people pay real BTC for merge-mined "beta BTC" as a 
> way to support development. There is no doubt a more elegant and 
> practical solution that might have different economic and crypto 
> characteristics.
>
>
>
> On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam@cypherspace.org 
> <mailto:adam@cypherspace.org>> wrote:
>
>     Is there a way to experiment with new features - eg committed
>     coins - that
>     doesnt involve an altcoin in the conventional sense, and also
>     doesnt impose
>     a big testing burden on bitcoin main which is a security and
>     testing risk?
>
>     eg lets say some form of merged mine where an alt-coin lets call it
>     bitcoin-staging?  where the coins are the same coins as on
>     bitcoin, the
>     mining power goes to bitcoin main, so some aspect of merged
>     mining, but no
>     native mining.  and ability to use bitcoins by locking them on
>     bitcoin to
>     move them to bitcoin-staging and vice versa (ie exchange them 1:1
>     cryptographically, no exchange).
>
>     Did anyone figure anything like that out?  Seems vaguely doable and
>     maybe productive.  The only people with coins at risk of defects
>     in a new
>     feature, or insufficiently well tested novel feature are people
>     with coins
>     on bitcoin-staging.
>
>     Yes I know about bitcoin-test this is not it.  I mean a real live
>     system,
>     with live value, but that is intentionally wanting to avoid
>     forking bitcoins
>     parameters, nor value, nor mindshare dillution.  In this way something
>     potentially interesting could move forward faster, and be les
>     risky to the
>     main bitcoin network.  eg particularly defenses against
>
>     It might also be a more real world test test (after bitcoin-test)
>     because
>     some parameters are different on test, and some issues may not
>     manifest
>     without more real activity.
>
>     Then also bitcoin could cherry pick interesting patches and merge
>     them after
>     extensive real-world validation with real-money at stake (by early
>     adopters).
>
>     Adam
>
>     ------------------------------------------------------------------------------
>     AlienVault Unified Security Management (USM) platform delivers
>     complete
>     security visibility with the essential security capabilities.
>     Easily and
>     efficiently configure, manage, and operate all of your security
>     controls
>     from a single console and one unified framework. Download a free
>     trial.
>     http://p.sf.net/sfu/alienvault_d2d
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> -- 
> Are you coming to Bitcoin2013 <http://bitcoin2013.com> in San Jose In 
> May?
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter@coinlab.com <mailto:peter@coinlab.com> * /  206.486.6856  / 
> SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Luke-Jr]

This sounds similar to the "bitcoin2" branch I created a while back - 
basically a "next"-like branch, but for hardforking changes that refused to 
run without the -testnet option. There's so much non-hardforking code that can 
be written/tested, at this point, that I think it was and maybe is premature 
to be writing hardforking code outside of necessity. But perhaps if you want 
to play around, it might be a good starting point (it can probably merge up to 
latest master, and trivial to rebase if not).

On Sunday, May 19, 2013 1:23:59 PM Adam Back wrote:
> Is there a way to experiment with new features - eg committed coins - that
> doesnt involve an altcoin in the conventional sense, and also doesnt impose
> a big testing burden on bitcoin main which is a security and testing risk?
> 
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging?  where the coins are the same coins as on bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged mining, but no
> native mining.  and ability to use bitcoins by locking them on bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
> 
> Did anyone figure anything like that out?  Seems vaguely doable and
> maybe productive.  The only people with coins at risk of defects in a new
> feature, or insufficiently well tested novel feature are people with coins
> on bitcoin-staging.
> 
> Yes I know about bitcoin-test this is not it.  I mean a real live system,
> with live value, but that is intentionally wanting to avoid forking
> bitcoins parameters, nor value, nor mindshare dillution.  In this way
> something potentially interesting could move forward faster, and be les
> risky to the main bitcoin network.  eg particularly defenses against
> 
> It might also be a more real world test test (after bitcoin-test) because
> some parameters are different on test, and some issues may not manifest
> without more real activity.
> 
> Then also bitcoin could cherry pick interesting patches and merge them
> after extensive real-world validation with real-money at stake (by early
> adopters).
> 
> Adam
> 
> ---------------------------------------------------------------------------
> --- AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[zooko]

Folks:

I'm very interested in this idea. I got really excited about it and started
trying to write up schemes to implement it. Like much of Bitcoin, it gets my
head spinning, but then it turns out I don't really understand it.

Because when my write-ups of implementations all turned to dust and ashes, then
I reconsidered, and I realized that I don't actually understand how the
proposed thing is different than testnet. The proposed difference seems to be
about assigning real value to the coins on this "beta bitcoin blockchain", but
that's mostly not up to developers, except possibly through some crazy scheme
which forces "beta bitcoins" to be exchangeable for real bitcoins... Actually,
no, not even then.

So I guess what is *really* exciting about this idea has nothing to do with
making the "beta" coins valuable nor with novel schemes for linking
semi-independent blockchains. What is really exciting about it is a shared
codebase that the Bitcoin core developers are (at least nominally) paying
attention to, and that you can play with on some public blockchain.

So if that's the right goal, then the solution is a branch or a fork on github,
and a name such as "bitcoin-next" or "bitcoin-staging" or whatever that confers
a certain aura of relevance.

And maybe some publicly celebrated list of the testnet blockchain forks which
have been inevitably created by this "bitcoin-next" codebase.

It would give people with the "better Bitcoin bug" (such as me) a common
codebase to aim pull requests at, and to fork on github.

Like Peter Vessenes says, this idea sounds like an alternative to "go do it on
an alt coin".

This feels different to me from the "go do it on an alt coin" idea, because I
suspect most bitcoin core devs aren't really paying that much attention to alt
coin. I know *I'm* not paying attention to them, because I'm already overloaded
with things to learn. Having to learn about alt coins in order to try to
communicate with bitcoin core devs that may or may not be really paying
attention to the alt coin sounds daunting.

Regards,

Zooko

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Jeff Garzik]

On Tue, May 21, 2013 at 11:37 PM, zooko <zooko@zooko.com> wrote:
> Folks:
>
> I'm very interested in this idea. I got really excited about it and started
> trying to write up schemes to implement it. Like much of Bitcoin, it gets my
> head spinning, but then it turns out I don't really understand it.
>
> Because when my write-ups of implementations all turned to dust and ashes, then
> I reconsidered, and I realized that I don't actually understand how the
> proposed thing is different than testnet. The proposed difference seems to be
> about assigning real value to the coins on this "beta bitcoin blockchain", but
> that's mostly not up to developers, except possibly through some crazy scheme
> which forces "beta bitcoins" to be exchangeable for real bitcoins... Actually,
> no, not even then.

Note that testnet operates under the threat of being reset at any
time, if someone comes along and destroys its usefulness with spam or
mining or whatnot.  That guarantees it remains a testing tool, and not
a real alt-currency.  The current testnet is the third iteration,
hence you see "testnet3" in some source code.

This option is always available for any merge-mined chain as well,
ensuring little real value is assigned to the test chain.

But that is a binary decision:  If you don't have a reset-the-chain
policy, you have a de facto "it is a real currency" policy.


> So I guess what is *really* exciting about this idea has nothing to do with
> making the "beta" coins valuable nor with novel schemes for linking
> semi-independent blockchains. What is really exciting about it is a shared
> codebase that the Bitcoin core developers are (at least nominally) paying
> attention to, and that you can play with on some public blockchain.
>
> So if that's the right goal, then the solution is a branch or a fork on github,
> and a name such as "bitcoin-next" or "bitcoin-staging" or whatever that confers
> a certain aura of relevance.
>
> And maybe some publicly celebrated list of the testnet blockchain forks which
> have been inevitably created by this "bitcoin-next" codebase.
>
> It would give people with the "better Bitcoin bug" (such as me) a common
> codebase to aim pull requests at, and to fork on github.

A fork of the bitcoin.git codebase has the nice attribute of making it
easy to "upstream" any useful changes that are not specific to that
one alt-coin.


> This feels different to me from the "go do it on an alt coin" idea, because If
> suspect most bitcoin core devs aren't really paying that much attention to alt
> coin. I know *I'm* not paying attention to them, because I'm already overloaded
> with things to learn. Having to learn about alt coins in order to try to
> communicate with bitcoin core devs that may or may not be really paying
> attention to the alt coin sounds daunting.

What's neat about bitcoin is that it invented a whole new /category/
of technology.  It's not just /an/ invention, but opened up all this
new experimentation with the new concept of money itself.

However for the bitcoin.git reference implementation, it makes more
sense to focus on supporting existing bitcoin users.  That permits
alt-coins to bubble up (or not) organically, and at the same time
reduces user confusion.  We have enough trouble explaining the basics
of bitcoin to the world; trying to keep follow every alt-coin
bandwagon just muddies the waters from a messaging standpoint.

alt-coin changes fall into two categories:
1) Rule changes.  We don't want these.
2) Generic bug fixes, cleanups, changes etc.  It would be nice to see
improvements bubble up, benefitting everybody.


-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Adam Back]

I had one thought towards this which is a different kind of merged mining.

I think a "fair" merged mining aiming for price parity would be done by the
miner having to choose the altcoin or btc at mine time, and altcoin chain
considering btc mine unspendable and bitcoin considering ac unspendable.

In terms of validation which miners are currently doing to help SVP clients,
it implies verification of both chains.  Or more incrementally each mine
should indicate in its serialization which chain it has validated.  This wa
about a hypothethical pure zerocoin altcoin hence zc/zerocoin:

Maybe we can say that a mergemine does not count as a validation of the
network for the respective network unless there is serialization in the
coinbase indicating that the network is validated.  In that way you could
have zerocoin mined and zerocoin validated, zero mined and bitcoin validated
(strange but possible), zerocoin mined and both zero and bit coin validated,
and also the same for bitcoin mined and zerocoin validated (strange but
possible), bitcoin mined and bitcoin validated (normal bitcoin ignoring
zerocoin) and bitcoin mined and bitcoin and zerocoin validated.  Then the
validation events on zerocoin network might not be as frequent.  Maybe
miners will tend to validate both networks as then they can claim fees on
both networks, even if the protocol prevents direct merged mining on both
networks (one or the other mined, and whatever chains validated as indicated
by coinbase serialization).

(I described it in this thread
https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768 which
is mostly about understanding zerocoin, but digressed at that point to a
hypothetical pure zerocoin alt-coin that retains a fair merged mine and
exchangeless tradeability with main bitcoin.)

I think another gap is the exchangeless tradeability.  Apparently the
contract based proposals have race conditions, and ransom issues (refuse to
complete agreed commitment phase without being part-paid again).  I didnt
follow that discussion yet but Greg Maxwell and Sergio Lerner were
discussing and that seemed to be their conclusion, and Sergio's proposed
solution relied on a non-standard and not-fully-worked-through assumption
for the alt-coin (probably non-SPV compatible I think).

ps I thought it was quite interesting that seemingly you could make a pure
zerocoin alt-coin, it turns out you could direct mine them, and do zc-zc
transactions.  

They are fixed denomination however I think you could extend them with
homomorphic amounts.  I noticed Matthew Green mentioned this idea in his
presentation at microsoft research (saw in the video they have put online). 
 From my perspective (he didnt specify how other than as an attribute) its
something like a Brands credential where you can prove in ZK that two
attributes sum to a given value without revealing the attributes at all. 
The missing last part is you have to prove that the attributes are less than
some threshold to avoid people cheating and adding q to their balance. 
(Arithmetic in the exponents is modulo q in the subgroup used in zerocoin). 
There are several approaches to doing this some of them not that cheap (eg
involving k DSA-like signatures to prove vale v < 2^k).  The idea of proving
it is less than k where k is say 128 is that then to add q, you have to
spend 2^128 coins which you cant do.  You can either make the values
uncertain by having v eg have 44 bits of useful precision and a few binary
00s and then 80-bits of randomness, or you can use a second never disclosed
random attribute like in a Pederson commitment or Brands credential eg 
c=g^v h^r mod p where r is random and never disclosed, but the user proves
knowledge of discrete log representation of c in terms of powers of g and h.
The downside of k signatures is validation CPU cost, and worse transaction
size.

There are several other approaches which seem to be able to prove v < 2^k
with less than k, eg even 1 DSA-like signature.  I need to gather that info
in one place and write something referencing the literature I found so far. 
A homomorphically verifiable coin balance transfer could be interesting
outside of zerocoin - eg for bitcoin, or an alt-coin.

Adam

On Sun, May 19, 2013 at 03:23:59PM +0200, Adam Back wrote:
>Is there a way to experiment with new features - eg committed coins - that
>doesnt involve an altcoin in the conventional sense, and also doesnt impose
>a big testing burden on bitcoin main which is a security and testing risk?
>
>eg lets say some form of merged mine where an alt-coin lets call it
>bitcoin-staging?  where the coins are the same coins as on bitcoin, the
>mining power goes to bitcoin main, so some aspect of merged mining, but no
>native mining.  and ability to use bitcoins by locking them on bitcoin to
>move them to bitcoin-staging and vice versa (ie exchange them 1:1
>cryptographically, no exchange).
>
>Did anyone figure anything like that out?  Seems vaguely doable and
>maybe productive.  The only people with coins at risk of defects in a new
>feature, or insufficiently well tested novel feature are people with coins
>on bitcoin-staging.
>
>Yes I know about bitcoin-test this is not it.  I mean a real live system,
>with live value, but that is intentionally wanting to avoid forking bitcoins
>parameters, nor value, nor mindshare dillution.  In this way something
>potentially interesting could move forward faster, and be les risky to the
>main bitcoin network.  eg particularly defenses against
>
>It might also be a more real world test test (after bitcoin-test) because
>some parameters are different on test, and some issues may not manifest
>without more real activity.
>
>Then also bitcoin could cherry pick interesting patches and merge them after
>extensive real-world validation with real-money at stake (by early
>adopters).
>
>Adam

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Peter Todd]

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

On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote:
> I had one thought towards this which is a different kind of merged mining.
> 
> I think a "fair" merged mining aiming for price parity would be done by the
> miner having to choose the altcoin or btc at mine time, and altcoin chain
> considering btc mine unspendable and bitcoin considering ac unspendable.

One way to look at what you are describing is to say you want to prove
your sacrifice of potential BTC earnings. That goes back to the PoW
hashcash stuff I mentioned earlier, and is accomplished by simply mining
shares with an unspendable coinbase to prove you did work that could
have resulted in Bitcoins, but didn't.

-- 
'peter'[:-1]@petertodd.org
00000000000000b7dc90d34b08218b76687c0cd8a00878fea13d4ce98b0f4df0

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Adam Back]

Agreed.  What I mean is a coinbase for parity-priced alt-coin would be
intentionally considered (and required by the alt-coin to be considered) an
invalid bitcoin address, and vice versa.  The difference is for this purpose
it is both valid alt-coin coinbase (as well as unspendable bitcoin
coinbase).

Adam

On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote:
>On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote:
>> I had one thought towards this which is a different kind of merged mining.
>>
>> I think a "fair" merged mining aiming for price parity would be done by the
>> miner having to choose the altcoin or btc at mine time, and altcoin chain
>> considering btc mine unspendable and bitcoin considering ac unspendable.
>
>One way to look at what you are describing is to say you want to prove
>your sacrifice of potential BTC earnings. That goes back to the PoW
>hashcash stuff I mentioned earlier, and is accomplished by simply mining
>shares with an unspendable coinbase to prove you did work that could
>have resulted in Bitcoins, but didn't.

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Luke-Jr]

Note that the "earn a mixture of BTC and TBC, but not both in full volume" 
only works for TBC because the price is by definition fixed with BTC.
I'm not sure how you could implement something like this for an altcoin where 
the price is floating independently of Bitcoin.. that is, how you would know 
the right amount of Bitcoin to require sacrificed.

Luke


On Friday, June 14, 2013 8:50:31 PM Adam Back wrote:
> Agreed.  What I mean is a coinbase for parity-priced alt-coin would be
> intentionally considered (and required by the alt-coin to be considered) an
> invalid bitcoin address, and vice versa.  The difference is for this
> purpose it is both valid alt-coin coinbase (as well as unspendable bitcoin
> coinbase).
> 
> Adam
> 
> On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote:
> >On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote:
> >> I had one thought towards this which is a different kind of merged
> >> mining.
> >> 
> >> I think a "fair" merged mining aiming for price parity would be done by
> >> the miner having to choose the altcoin or btc at mine time, and altcoin
> >> chain considering btc mine unspendable and bitcoin considering ac
> >> unspendable.
> >
> >One way to look at what you are describing is to say you want to prove
> >your sacrifice of potential BTC earnings. That goes back to the PoW
> >hashcash stuff I mentioned earlier, and is accomplished by simply mining
> >shares with an unspendable coinbase to prove you did work that could
> >have resulted in Bitcoins, but didn't.
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Andreas Petersson]

my initial idea (not sure if it is good) was to have an asymetric market.
lets say you want to create altcoin ALC. ALC are merge-mined with btc,
though without block reward.
to create 1 ALC you have two choices: destroy 1 BTC, or buy 1 ALC for a
floating amount from an exchange.

in my book, this would automatically lead to a slightly lower price for
1 ALC, and an automatic ceiling of 1 BTC, since you could always
sacrifice BTC to gain ALC.
but it would not diverge drastically lower, since apparently somebody
was willing to destroy 1 BTC to create it. maybe it could even trade
slightly higher because traded ALC could be spendable instantly while
sacrificed ALC would need a 120 blocks maturing period.
the "beauty" of that system is also it does not inflate the
cryptocurrency realm.

Andreas

Am 14.06.2013 23:10, schrieb Luke-Jr:
> Note that the "earn a mixture of BTC and TBC, but not both in full volume" 
> only works for TBC because the price is by definition fixed with BTC.
> I'm not sure how you could implement something like this for an altcoin where 
> the price is floating independently of Bitcoin.. that is, how you would know 
> the right amount of Bitcoin to require sacrificed.

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Dennison Bertram]

It seems so much easier to just allow bitcoin testnet to be used more widely for larger scale bitcoin staging. People can assign value as they wish to testnet bitcoins but at their own risk/peril. This incremental amount of value though would allow for testing of larger ideas, ideas that perhaps might not be appropriate in their nascent stages to apply for bitcoin. 

Have your seen 'proof of existence'? It's basically a bitcoin notary service that proves a document existed before it gets inserted into the blockchain. While a good idea- you could argue that it's blockchain spam as well- especially if one were to adapt it to high volumes in the future for notarizing permanently things like tweets (for example) or combining it with something like colored coins. These are great ideas, but maybe better suited to a proto bitcoin without needing to fashion a brand new coin. 

Sent from my iPhone

On Jun 14, 2013, at 11:25 PM, Andreas Petersson <andreas@petersson.at> wrote:

> my initial idea (not sure if it is good) was to have an asymetric market.
> lets say you want to create altcoin ALC. ALC are merge-mined with btc,
> though without block reward.
> to create 1 ALC you have two choices: destroy 1 BTC, or buy 1 ALC for a
> floating amount from an exchange.
> 
> in my book, this would automatically lead to a slightly lower price for
> 1 ALC, and an automatic ceiling of 1 BTC, since you could always
> sacrifice BTC to gain ALC.
> but it would not diverge drastically lower, since apparently somebody
> was willing to destroy 1 BTC to create it. maybe it could even trade
> slightly higher because traded ALC could be spendable instantly while
> sacrificed ALC would need a 120 blocks maturing period.
> the "beauty" of that system is also it does not inflate the
> cryptocurrency realm.
> 
> Andreas
> 
> Am 14.06.2013 23:10, schrieb Luke-Jr:
>> Note that the "earn a mixture of BTC and TBC, but not both in full volume" 
>> only works for TBC because the price is by definition fixed with BTC.
>> I'm not sure how you could implement something like this for an altcoin where 
>> the price is floating independently of Bitcoin.. that is, how you would know 
>> the right amount of Bitcoin to require sacrificed.
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Luke-Jr]

Timestamping ("proof of existence") doesn't need a coin at all. Just collect 
all the hashes you need timestamped into a PoE merkle tree and add that to the 
merged mining MT. It's pretty simple and straightforward, just needs someone 
to implement it.

On Saturday, June 15, 2013 12:09:09 AM Dennison Bertram wrote:
> Have your seen 'proof of existence'? It's basically a bitcoin notary
> service that proves a document existed before it gets inserted into the
> blockchain. While a good idea- you could argue that it's blockchain spam
> as well- especially if one were to adapt it to high volumes in the future
> for notarizing permanently things like tweets (for example) or combining
> it with something like colored coins. These are great ideas, but maybe
> better suited to a proto bitcoin without needing to fashion a brand new
> coin.

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Dennison Bertram]

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

That is true, but someone is already running it as a service on the blockchain itself. See:

https://www.proofofexistence.com/

You can imagine similar  services cropping up for things like torrents, sending btc tweets, etc. While I am not saying these things are particularly refined ideas in and of themselves, people should have an opportunity to play with them, and better testnet. 

Sent from my iPhone

On Jun 15, 2013, at 3:57 AM, "Luke-Jr" <luke@dashjr.org> wrote:

> Timestamping ("proof of existence") doesn't need a coin at all. Just collect 
> all the hashes you need timestamped into a PoE merkle tree and add that to the 
> merged mining MT. It's pretty simple and straightforward, just needs someone 
> to implement it.
> 
> On Saturday, June 15, 2013 12:09:09 AM Dennison Bertram wrote:
>> Have your seen 'proof of existence'? It's basically a bitcoin notary
>> service that proves a document existed before it gets inserted into the
>> blockchain. While a good idea- you could argue that it's blockchain spam
>> as well- especially if one were to adapt it to high volumes in the future
>> for notarizing permanently things like tweets (for example) or combining
>> it with something like colored coins. These are great ideas, but maybe
>> better suited to a proto bitcoin without needing to fashion a brand new
>> coin.

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Melvin Carvalho]

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

On 19 May 2013 15:23, Adam Back <adam@cypherspace.org> wrote:

> Is there a way to experiment with new features - eg committed coins - that
> doesnt involve an altcoin in the conventional sense, and also doesnt impose
> a big testing burden on bitcoin main which is a security and testing risk?
>
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging?  where the coins are the same coins as on bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged mining, but no
> native mining.  and ability to use bitcoins by locking them on bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
>
> Did anyone figure anything like that out?  Seems vaguely doable and
> maybe productive.  The only people with coins at risk of defects in a new
> feature, or insufficiently well tested novel feature are people with coins
> on bitcoin-staging.
>
> Yes I know about bitcoin-test this is not it.  I mean a real live system,
> with live value, but that is intentionally wanting to avoid forking
> bitcoins
> parameters, nor value, nor mindshare dillution.  In this way something
> potentially interesting could move forward faster, and be les risky to the
> main bitcoin network.  eg particularly defenses against
>
> It might also be a more real world test test (after bitcoin-test) because
> some parameters are different on test, and some issues may not manifest
> without more real activity.
>
> Then also bitcoin could cherry pick interesting patches and merge them
> after
> extensive real-world validation with real-money at stake (by early
> adopters).
>

Interesting idea.  I wonder if ripple could be used to set up a transfer
system between the 'main' and 'staging' systems ...


>
> Adam
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Dennison Bertram]

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

Why use ripple and not just use the testnet? 

The advantageous of allowing testnet to be used as an alt-coin are That Non standard transactions can be tested in a pseudo live environment where because the coins have some nominal value people are incentivized to try and steal and come up with clever ways of gamin the system. This sort of knowledge would be invaluable if non standard transactions are ever going to become a reality on main net. 

It also allows developers a chance to develop in advance new technologies and services that currently won't run on bitcoin main net but might be enabled in the future at which point they can switch over to main net. Additionally without any development happening with non standard transactions as currently there is no economic incentive , there might be a strong argument to never bother enabling non standard transactions as the risk of doing so might not justify in many people's minds  the benefits as if no one develops anything in advance  most users might not find the theoretical possibilities worth the risk, thus permanently hobbling the full potential of satoshis idea. Rather if testnet were allowed to act as an alt coin something cool might be developed that the main net users might desire enough to overcome the inertia of the status quo. 

Additionally it should be considered that the time in the future when non standard transactions might be enabled  might be so far in the future when bitcoin has hit mass adoption and changing anything might require far more political negotiations between users and devs then currently. Meaning that perhaps much more proof of functionality and value as well as testing might e required. 

Dennison

Sent from my iPhone

On Jun 15, 2013, at 1:18 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 19 May 2013 15:23, Adam Back <adam@cypherspace.org> wrote:
>> Is there a way to experiment with new features - eg committed coins - that
>> doesnt involve an altcoin in the conventional sense, and also doesnt impose
>> a big testing burden on bitcoin main which is a security and testing risk?
>> 
>> eg lets say some form of merged mine where an alt-coin lets call it
>> bitcoin-staging?  where the coins are the same coins as on bitcoin, the
>> mining power goes to bitcoin main, so some aspect of merged mining, but no
>> native mining.  and ability to use bitcoins by locking them on bitcoin to
>> move them to bitcoin-staging and vice versa (ie exchange them 1:1
>> cryptographically, no exchange).
>> 
>> Did anyone figure anything like that out?  Seems vaguely doable and
>> maybe productive.  The only people with coins at risk of defects in a new
>> feature, or insufficiently well tested novel feature are people with coins
>> on bitcoin-staging.
>> 
>> Yes I know about bitcoin-test this is not it.  I mean a real live system,
>> with live value, but that is intentionally wanting to avoid forking bitcoins
>> parameters, nor value, nor mindshare dillution.  In this way something
>> potentially interesting could move forward faster, and be les risky to the
>> main bitcoin network.  eg particularly defenses against
>> 
>> It might also be a more real world test test (after bitcoin-test) because
>> some parameters are different on test, and some issues may not manifest
>> without more real activity.
>> 
>> Then also bitcoin could cherry pick interesting patches and merge them after
>> extensive real-world validation with real-money at stake (by early
>> adopters).
> 
> Interesting idea.  I wonder if ripple could be used to set up a transfer system between the 'main' and 'staging' systems ...
>  
>> 
>> Adam
>> 
>> ------------------------------------------------------------------------------
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Dennison Bertram]

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

Is there a relatively easy way to switch between Testnet versions in the
client? On the forums I am in discussion with one member who mentioned the
idea of a Main net, a testnet and a "beta-net" where the coins on the
beta-net would be allowed to have value. It seems like simple and logical
way to do this would be something like a "testnet=1, testnetversion=3" in
the bitcoin.conf file. Is this possible?


On Sat, Jun 15, 2013 at 3:26 PM, Dennison Bertram <
dennison@dennisonbertram.com> wrote:

> Why use ripple and not just use the testnet?
>
> The advantageous of allowing testnet to be used as an alt-coin are
> That Non standard transactions can be tested in a pseudo live environment
> where because the coins have some nominal value people are incentivized to
> try and steal and come up with clever ways of gamin the system. This sort
> of knowledge would be invaluable if non standard transactions are ever
> going to become a reality on main net.
>
> It also allows developers a chance to develop in advance new technologies
> and services that currently won't run on bitcoin main net but might be
> enabled in the future at which point they can switch over to main net.
> Additionally without any development happening with non standard
> transactions as currently there is no economic incentive , there might be a
> strong argument to never bother enabling non standard transactions as the
> risk of doing so might not justify in many people's minds  the benefits as
> if no one develops anything in advance  most users might not find the
> theoretical possibilities worth the risk, thus permanently hobbling the
> full potential of satoshis idea. Rather if testnet were allowed to act as
> an alt coin something cool might be developed that the main net users might
> desire enough to overcome the inertia of the status quo.
>
> Additionally it should be considered that the time in the future when non
> standard transactions might be enabled  might be so far in the future when
> bitcoin has hit mass adoption and changing anything might require far more
> political negotiations between users and devs then currently. Meaning that
> perhaps much more proof of functionality and value as well as testing might
> e required.
>
> Dennison
>
> Sent from my iPhone
>
> On Jun 15, 2013, at 1:18 PM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
>
> On 19 May 2013 15:23, Adam Back <adam@cypherspace.org> wrote:
>
>> Is there a way to experiment with new features - eg committed coins - that
>> doesnt involve an altcoin in the conventional sense, and also doesnt
>> impose
>> a big testing burden on bitcoin main which is a security and testing risk?
>>
>> eg lets say some form of merged mine where an alt-coin lets call it
>> bitcoin-staging?  where the coins are the same coins as on bitcoin, the
>> mining power goes to bitcoin main, so some aspect of merged mining, but no
>> native mining.  and ability to use bitcoins by locking them on bitcoin to
>> move them to bitcoin-staging and vice versa (ie exchange them 1:1
>> cryptographically, no exchange).
>>
>> Did anyone figure anything like that out?  Seems vaguely doable and
>> maybe productive.  The only people with coins at risk of defects in a new
>> feature, or insufficiently well tested novel feature are people with coins
>> on bitcoin-staging.
>>
>> Yes I know about bitcoin-test this is not it.  I mean a real live system,
>> with live value, but that is intentionally wanting to avoid forking
>> bitcoins
>> parameters, nor value, nor mindshare dillution.  In this way something
>> potentially interesting could move forward faster, and be les risky to the
>> main bitcoin network.  eg particularly defenses against
>>
>> It might also be a more real world test test (after bitcoin-test) because
>> some parameters are different on test, and some issues may not manifest
>> without more real activity.
>>
>> Then also bitcoin could cherry pick interesting patches and merge them
>> after
>> extensive real-world validation with real-money at stake (by early
>> adopters).
>>
>
> Interesting idea.  I wonder if ripple could be used to set up a transfer
> system between the 'main' and 'staging' systems ...
>
>
>>
>> Adam
>>
>>
>> ------------------------------------------------------------------------------
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
> _______________________________________________
>
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 

Dennison Bertram, photographer and film maker

www.dennisonbertram.com

dennison@dennisonbertram.com

Milan: +39 320 781 0128

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Adam Back]

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] is there a way to do bitcoin-staging?

[Jeff Garzik]

On Mon, Oct 14, 2013 at 2:08 PM, Adam Back <adam@cypherspace.org> wrote:
> 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.

Quite a neat idea...


> - it avoids mindshare dilution if alternatively an alt-coin with a hit
>    missing feature takes off;

FWIW, litecoin devs are open to having litecoin be a bit of a staging
area for new bitcoin features.  Obviously there is some self-interest
there -- "we have new cool stuff first!" -- nevertheless, it is a live
test that could demonstrate problems with new features before they
land in bitcoin-stable.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Michael Gronager]

Hi Alan,

What you describe in the ultimate blockchain compression I have already
coded the authenticated datastructure part of in libcoin
(https://github.com/libcoin/libcoin) - next step is to include a p2pool
style mining, where a parallel chain serves several purposes:
1. to validate the root hash at a higher frequency than the 10 min
2. to enable distributed mining, easily (part of libcoind)
3. to utilize the soft fork by defining the root hash in coinbase blocks
as v3 and once we cross the limit all blocks are v3.

I will have a closer look at you bitcoin talk post to see how well my
approach and ideas fit to yours.

Michael

On 20/5/13 08:34 , Alan Reiner wrote:
> This is exactly what I was planning to do with the inappropriately-named
> "Ultimate Blockchain Compression
> <https://bitcointalk.org/index.php?topic=88208.0>".  I wanted to
> reorganize the blockchain data into an authenticated tree, indexed by
> TxOut script (address), instead of tx-hash.  Much like a regular merkle
> tree, you can store the root in the block header, and communicate
> branches of that tree to nodes, to prove inclusion (and exclusion!) of
> TxOuts for any given script/address.  Additionally, you can include at
> each node, the sum of BTC in all nodes below it, which offers some other
> nice benefits.
> 
> I think this idea is has epic upside-potential for bitcoin if it works
> -- even "SPV" nodes could query their unspent TxOut list for their
> wallet from any untrusted peer and compare the result directly to the
> blockheaders/POW.  Given nothing but the headers, you can verify the
> balance of 100 addresses with 250 kB.  But also epic failure-potential
> in terms of feasibility and cost-to-benefit for miners.  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". 
> Therefore, I had proposed that this be merge-mined on a "meta-chain"
> first...get a bunch of miners on board to agree to merge mine and see it
> in action.  It seemed like a perfectly non-disruptive way to prove out a
> particular idea before we actually consider making a protocol change
> that significant.  Even if it stayed on its own meta chain, as long as
> there is some significant amount of hashpower working on it, it can
> still be a useful tool. 
> 
> Unfortunately, my experience with merged mining is minimal, so I'm still
> not clear how feasible/reliable it is as an alternative to direct
> blockchain integration.  That's a discussion I'd like to have.
> 
> -Alan
> 
> 
> 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.
>>
>> An alternate setup comes to mind; I can imagine this working as a sort
>> of gift economy; people pay real BTC for merge-mined "beta BTC" as a
>> way to support development. There is no doubt a more elegant and
>> practical solution that might have different economic and crypto
>> characteristics.
>>
>>
>>
>> On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam@cypherspace.org
>> <mailto:adam@cypherspace.org>> wrote:
>>
>>     Is there a way to experiment with new features - eg committed
>>     coins - that
>>     doesnt involve an altcoin in the conventional sense, and also
>>     doesnt impose
>>     a big testing burden on bitcoin main which is a security and
>>     testing risk?
>>
>>     eg lets say some form of merged mine where an alt-coin lets call it
>>     bitcoin-staging?  where the coins are the same coins as on
>>     bitcoin, the
>>     mining power goes to bitcoin main, so some aspect of merged
>>     mining, but no
>>     native mining.  and ability to use bitcoins by locking them on
>>     bitcoin to
>>     move them to bitcoin-staging and vice versa (ie exchange them 1:1
>>     cryptographically, no exchange).
>>
>>     Did anyone figure anything like that out?  Seems vaguely doable and
>>     maybe productive.  The only people with coins at risk of defects
>>     in a new
>>     feature, or insufficiently well tested novel feature are people
>>     with coins
>>     on bitcoin-staging.
>>
>>     Yes I know about bitcoin-test this is not it.  I mean a real live
>>     system,
>>     with live value, but that is intentionally wanting to avoid
>>     forking bitcoins
>>     parameters, nor value, nor mindshare dillution.  In this way something
>>     potentially interesting could move forward faster, and be les
>>     risky to the
>>     main bitcoin network.  eg particularly defenses against
>>
>>     It might also be a more real world test test (after bitcoin-test)
>>     because
>>     some parameters are different on test, and some issues may not
>>     manifest
>>     without more real activity.
>>
>>     Then also bitcoin could cherry pick interesting patches and merge
>>     them after
>>     extensive real-world validation with real-money at stake (by early
>>     adopters).
>>
>>     Adam
>>
>>     ------------------------------------------------------------------------------
>>     AlienVault Unified Security Management (USM) platform delivers
>>     complete
>>     security visibility with the essential security capabilities.
>>     Easily and
>>     efficiently configure, manage, and operate all of your security
>>     controls
>>     from a single console and one unified framework. Download a free
>>     trial.
>>     http://p.sf.net/sfu/alienvault_d2d
>>     _______________________________________________
>>     Bitcoin-development mailing list
>>     Bitcoin-development@lists.sourceforge.net
>>     <mailto:Bitcoin-development@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> -- 
>> Are you coming to Bitcoin2013 <http://bitcoin2013.com> in San Jose In
>> May? 
>> ------------------------------------------------------------------------
>>
>> CoinLab LogoPETER VESSENES 
>> CEO
>>
>> *peter@coinlab.com <mailto:peter@coinlab.com> * /  206.486.6856
>>  / SKYPE: vessenes 
>> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>>
>>
>>
>> ------------------------------------------------------------------------------
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Alan Reiner]

Michael,

Very interesting that you have tackled that off the radar.  I didn't
know anyone else was working on anything similar.  I'm sure you saw the
recent Armory-funding announcement, so understandably I have other
priorities in recent past and near future, but I think you should
connect with Mark Friedenbach about this topic.  He solicited donations
for working on my idea, and has been doing proof-of-concept for for the
last few months.  In fact, he was just looking for funding for another 3
months, and Armory Technologies, Inc, just offered up 50 BTC for him to
continue (@Mark, whoops, I haven't actually paid you yet; contact me to
work out details).

For now, my ability to participate directly is limited, but I am still
very interested to see the ideas developed further, as well as provide a
first test of this whole staging-area idea.  I devised it originally for
the UBC/Reiner-tree concept, but there's no reason it couldn't be used
for any other type of sweeping change to the protocol. 

-Alan


On 10/14/2013 02:43 PM, Michael Gronager wrote:
> Hi Alan,
>
> What you describe in the ultimate blockchain compression I have already
> coded the authenticated datastructure part of in libcoin
> (https://github.com/libcoin/libcoin) - next step is to include a p2pool
> style mining, where a parallel chain serves several purposes:
> 1. to validate the root hash at a higher frequency than the 10 min
> 2. to enable distributed mining, easily (part of libcoind)
> 3. to utilize the soft fork by defining the root hash in coinbase blocks
> as v3 and once we cross the limit all blocks are v3.
>
> I will have a closer look at you bitcoin talk post to see how well my
> approach and ideas fit to yours.
>
> Michael
>
> On 20/5/13 08:34 , Alan Reiner wrote:
>> This is exactly what I was planning to do with the inappropriately-named
>> "Ultimate Blockchain Compression
>> <https://bitcointalk.org/index.php?topic=88208.0>".  I wanted to
>> reorganize the blockchain data into an authenticated tree, indexed by
>> TxOut script (address), instead of tx-hash.  Much like a regular merkle
>> tree, you can store the root in the block header, and communicate
>> branches of that tree to nodes, to prove inclusion (and exclusion!) of
>> TxOuts for any given script/address.  Additionally, you can include at
>> each node, the sum of BTC in all nodes below it, which offers some other
>> nice benefits.
>>
>> I think this idea is has epic upside-potential for bitcoin if it works
>> -- even "SPV" nodes could query their unspent TxOut list for their
>> wallet from any untrusted peer and compare the result directly to the
>> blockheaders/POW.  Given nothing but the headers, you can verify the
>> balance of 100 addresses with 250 kB.  But also epic failure-potential
>> in terms of feasibility and cost-to-benefit for miners.  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". 
>> Therefore, I had proposed that this be merge-mined on a "meta-chain"
>> first...get a bunch of miners on board to agree to merge mine and see it
>> in action.  It seemed like a perfectly non-disruptive way to prove out a
>> particular idea before we actually consider making a protocol change
>> that significant.  Even if it stayed on its own meta chain, as long as
>> there is some significant amount of hashpower working on it, it can
>> still be a useful tool. 
>>
>> Unfortunately, my experience with merged mining is minimal, so I'm still
>> not clear how feasible/reliable it is as an alternative to direct
>> blockchain integration.  That's a discussion I'd like to have.
>>
>> -Alan
>>
>>
>> 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.
>>>
>>> An alternate setup comes to mind; I can imagine this working as a sort
>>> of gift economy; people pay real BTC for merge-mined "beta BTC" as a
>>> way to support development. There is no doubt a more elegant and
>>> practical solution that might have different economic and crypto
>>> characteristics.
>>>
>>>
>>>
>>> On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam@cypherspace.org
>>> <mailto:adam@cypherspace.org>> wrote:
>>>
>>>     Is there a way to experiment with new features - eg committed
>>>     coins - that
>>>     doesnt involve an altcoin in the conventional sense, and also
>>>     doesnt impose
>>>     a big testing burden on bitcoin main which is a security and
>>>     testing risk?
>>>
>>>     eg lets say some form of merged mine where an alt-coin lets call it
>>>     bitcoin-staging?  where the coins are the same coins as on
>>>     bitcoin, the
>>>     mining power goes to bitcoin main, so some aspect of merged
>>>     mining, but no
>>>     native mining.  and ability to use bitcoins by locking them on
>>>     bitcoin to
>>>     move them to bitcoin-staging and vice versa (ie exchange them 1:1
>>>     cryptographically, no exchange).
>>>
>>>     Did anyone figure anything like that out?  Seems vaguely doable and
>>>     maybe productive.  The only people with coins at risk of defects
>>>     in a new
>>>     feature, or insufficiently well tested novel feature are people
>>>     with coins
>>>     on bitcoin-staging.
>>>
>>>     Yes I know about bitcoin-test this is not it.  I mean a real live
>>>     system,
>>>     with live value, but that is intentionally wanting to avoid
>>>     forking bitcoins
>>>     parameters, nor value, nor mindshare dillution.  In this way something
>>>     potentially interesting could move forward faster, and be les
>>>     risky to the
>>>     main bitcoin network.  eg particularly defenses against
>>>
>>>     It might also be a more real world test test (after bitcoin-test)
>>>     because
>>>     some parameters are different on test, and some issues may not
>>>     manifest
>>>     without more real activity.
>>>
>>>     Then also bitcoin could cherry pick interesting patches and merge
>>>     them after
>>>     extensive real-world validation with real-money at stake (by early
>>>     adopters).
>>>
>>>     Adam
>>>
>>>     ------------------------------------------------------------------------------
>>>     AlienVault Unified Security Management (USM) platform delivers
>>>     complete
>>>     security visibility with the essential security capabilities.
>>>     Easily and
>>>     efficiently configure, manage, and operate all of your security
>>>     controls
>>>     from a single console and one unified framework. Download a free
>>>     trial.
>>>     http://p.sf.net/sfu/alienvault_d2d
>>>     _______________________________________________
>>>     Bitcoin-development mailing list
>>>     Bitcoin-development@lists.sourceforge.net
>>>     <mailto:Bitcoin-development@lists.sourceforge.net>
>>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>> -- 
>>> Are you coming to Bitcoin2013 <http://bitcoin2013.com> in San Jose In
>>> May? 
>>> ------------------------------------------------------------------------
>>>
>>> CoinLab LogoPETER VESSENES 
>>> CEO
>>>
>>> *peter@coinlab.com <mailto:peter@coinlab.com> * /  206.486.6856
>>>  / SKYPE: vessenes 
>>> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> AlienVault Unified Security Management (USM) platform delivers complete
>>> security visibility with the essential security capabilities. Easily and
>>> efficiently configure, manage, and operate all of your security controls
>>> from a single console and one unified framework. Download a free trial.
>>> http://p.sf.net/sfu/alienvault_d2d
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> ------------------------------------------------------------------------------
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[coinscoins]

looks like Betacoin is already here - http://betacoin.org

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

[Melvin Carvalho]

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

On 14 October 2013 20:08, Adam Back <adam@cypherspace.org> 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.
>

I think there may be a simpler way to do this.

Create a new genesis block for a staging network, but in all other aspects,
as far as possible, keep the properties the same as bitcoin.

Do not actively be opposed to it being traded, but people need to know
that, although there is no intention to reset the chain, new and
potentially not fully tested, changes can be rolled into the network.
Anyone mining staging coins should be prepared for the value to go to zero.

Perhaps also a "straw poll" voting system could be set up for those that
own staging coins could sign messages saying which patches they would like
to test out next.  When patches are stable in the staging area, they could
be "promoted" to the main net ...


>
> 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.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

[Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?)

[Adam Back]

Yeah but that sounds pretty much like test-net and starts a new digital
scarcity on an alpha-qa level network, with an implied promise that maybe if
you're lucky your coins might survive the alpha testing and have some value.

I'm not talking about some slightly stabler version of test-net.

Probably bitcoin staging is the wrong name.  I mean like development of
bitcoin 1.x in parallel with bitcoin 0.x which includes like test net for
both, and strong (though maybe not quite as high) assurance of qa and care
as bitcoin 0.x.  Just as a way to get features like Mark Freidenbach's
freimarket script extensions, and some of the disabled scripts validated on
1.x testnet and then after rigorous testing deployed onto 1.x  Because they
are new features even with good testing that introduces non-zero risk, hence
the 1 way peg idea.  Welcome to suggest better names for the idea...

Of course maybe the other issue is insufficient people with the skills and
motivation to support two parallel efforts.

It gives somewhere to code and test and then deploy clearly useful things
but that dont warrant a hard fork.

Adam

Melvin wrote:
>   I think there may be a simpler way to do this.
>   Create a new genesis block for a staging network, but in all other
>   aspects, as far as possible, keep the properties the same as bitcoin.
>   Do not actively be opposed to it being traded, but people need to know
>   that, although there is no intention to reset the chain, new and
>   potentially not fully tested, changes can be rolled into the network.
>   Anyone mining staging coins should be prepared for the value to go to
>   zero.
>   Perhaps also a "straw poll" voting system could be set up for those
>   that own staging coins could sign messages saying which patches they
>   would like to test out next.  When patches are stable in the staging
>   area, they could be "promoted" to the main net ...

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

[Adam Back]

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] 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Jorge Timón]

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/

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

[Gregory Maxwell]

On Sun, Mar 16, 2014 at 3:58 PM, Adam Back <adam@cypherspace.org> wrote:
> 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.

One point to note here is that the if the whole move and quieting
period stuff sounds
cumbersome— thats because it is. Even with the best efficiency optimizations the
security requirements result in somewhat large and slow transactions—
and thats totally fine!

A key point here is that normally someone who needs to use coins on one chain or
the other can use fast atomic cross-chain transactions[1][2] and not
bother with the
slow direct movement across. The cross chain swapping, however, requires an
(untrusted) counterparty on the other chain, while the 2-way peg migrations can
be performed alone in order to provide liquidity and balance demand.


[1] https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
(Hm the citation there is weird, that predates TierNolan's post)
[2] https://bitcointalk.org/index.php?topic=321228.0
CoinSwap: Transaction graph disjoint trustless trading
(private version)