public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [Bitcoin-development] is there a way to do bitcoin-staging?
@ 2013-05-19 13:23 Adam Back
  2013-05-19 15:08 ` Peter Vessenes
                   ` (3 more replies)
  0 siblings, 4 replies; 27+ messages in thread
From: Adam Back @ 2013-05-19 13:23 UTC (permalink / raw)
  To: Bitcoin-Dev

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
    2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
  @ 2013-05-19 15:08 ` Peter Vessenes
    2013-05-20  6:34   ` Alan Reiner
    2013-05-22  3:37   ` zooko
    2013-05-20  7:12 ` Luke-Jr
                     ` (2 subsequent siblings)
    3 siblings, 2 replies; 27+ messages in thread
  From: Peter Vessenes @ 2013-05-19 15:08 UTC (permalink / raw)
    To: Adam Back; +Cc: Bitcoin-Dev
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
      2013-05-19 15:08 ` Peter Vessenes
    @ 2013-05-20  6:34   ` Alan Reiner
      2013-10-14 18:08     ` Adam Back
      2013-10-14 18:43     ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
      2013-05-22  3:37   ` zooko
      1 sibling, 2 replies; 27+ messages in thread
    From: Alan Reiner @ 2013-05-20  6:34 UTC (permalink / raw)
      To: bitcoin-development
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
        2013-05-20  6:34   ` Alan Reiner
      @ 2013-10-14 18:08     ` Adam Back
        2013-10-14 18:21       ` Jeff Garzik
                               ` (3 more replies)
        2013-10-14 18:43     ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
        1 sibling, 4 replies; 27+ messages in thread
      From: Adam Back @ 2013-10-14 18:08 UTC (permalink / raw)
        To: Alan Reiner; +Cc: bitcoin-development
      
      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.
      
      
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
          2013-10-14 18:08     ` Adam Back
        @ 2013-10-14 18:21       ` Jeff Garzik
          2013-11-21 20:22       ` coinscoins
                                 ` (2 subsequent siblings)
          3 siblings, 0 replies; 27+ messages in thread
        From: Jeff Garzik @ 2013-10-14 18:21 UTC (permalink / raw)
          To: Adam Back; +Cc: Bitcoin Dev
        
        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/
        
        
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
          2013-10-14 18:08     ` Adam Back
          2013-10-14 18:21       ` Jeff Garzik
        @ 2013-11-21 20:22       ` coinscoins
          2013-11-21 20:35       ` Melvin Carvalho
          2014-03-16 22:58       ` [Bitcoin-development] 2-way pegging " Adam Back
          3 siblings, 0 replies; 27+ messages in thread
        From: coinscoins @ 2013-11-21 20:22 UTC (permalink / raw)
          To: bitcoin-development
        
        looks like Betacoin is already here - http://betacoin.org
        
        
        
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
          2013-10-14 18:08     ` Adam Back
          2013-10-14 18:21       ` Jeff Garzik
          2013-11-21 20:22       ` coinscoins
        @ 2013-11-21 20:35       ` Melvin Carvalho
          2013-11-21 21:11         ` [Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?) Adam Back
          2014-03-16 22:58       ` [Bitcoin-development] 2-way pegging " Adam Back
          3 siblings, 1 reply; 27+ messages in thread
        From: Melvin Carvalho @ 2013-11-21 20:35 UTC (permalink / raw)
          To: Adam Back; +Cc: Bitcoin Dev
        
        [-- 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 --]
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • • * [Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?)
            2013-11-21 20:35       ` Melvin Carvalho
          @ 2013-11-21 21:11         ` Adam Back
            0 siblings, 0 replies; 27+ messages in thread
          From: Adam Back @ 2013-11-21 21:11 UTC (permalink / raw)
            To: Melvin Carvalho; +Cc: Bitcoin Dev
          
          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 ...
          
          
          
          ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • * [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
          2013-10-14 18:08     ` Adam Back
                                 ` (2 preceding siblings ...)
          2013-11-21 20:35       ` Melvin Carvalho
        @ 2014-03-16 22:58       ` Adam Back
          2014-03-16 23:22         ` Jorge Timón
          2014-03-17 15:55         ` Gregory Maxwell
          3 siblings, 2 replies; 27+ messages in thread
        From: Adam Back @ 2014-03-16 22:58 UTC (permalink / raw)
          To: Bitcoin-Dev
        
        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.
        
        
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • • * Re: [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
            2014-03-16 22:58       ` [Bitcoin-development] 2-way pegging " Adam Back
          @ 2014-03-16 23:22         ` Jorge Timón
            2014-03-17 15:55         ` Gregory Maxwell
            1 sibling, 0 replies; 27+ messages in thread
          From: Jorge Timón @ 2014-03-16 23:22 UTC (permalink / raw)
            To: Adam Back; +Cc: Bitcoin-Dev
          
          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/
          
          
          
          ^ permalink raw reply	[flat|nested] 27+ messages in thread

        • * Re: [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
            2014-03-16 22:58       ` [Bitcoin-development] 2-way pegging " Adam Back
            2014-03-16 23:22         ` Jorge Timón
          @ 2014-03-17 15:55         ` Gregory Maxwell
            1 sibling, 0 replies; 27+ messages in thread
          From: Gregory Maxwell @ 2014-03-17 15:55 UTC (permalink / raw)
            To: Adam Back; +Cc: Bitcoin-Dev
          
          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)
          
          
          
          ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
        2013-05-20  6:34   ` Alan Reiner
        2013-10-14 18:08     ` Adam Back
      @ 2013-10-14 18:43     ` Michael Gronager
        2013-10-14 20:20       ` Alan Reiner
        1 sibling, 1 reply; 27+ messages in thread
      From: Michael Gronager @ 2013-10-14 18:43 UTC (permalink / raw)
        To: Alan Reiner; +Cc: bitcoin-development
      
      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
      > 
      
      
      
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
          2013-10-14 18:43     ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
        @ 2013-10-14 20:20       ` Alan Reiner
          0 siblings, 0 replies; 27+ messages in thread
        From: Alan Reiner @ 2013-10-14 20:20 UTC (permalink / raw)
          To: Michael Gronager; +Cc: bitcoin-development
        
        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
        >>
        
        
        
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
      2013-05-19 15:08 ` Peter Vessenes
      2013-05-20  6:34   ` Alan Reiner
    @ 2013-05-22  3:37   ` zooko
      2013-05-22  4:12     ` Jeff Garzik
      1 sibling, 1 reply; 27+ messages in thread
    From: zooko @ 2013-05-22  3:37 UTC (permalink / raw)
      To: Peter Vessenes; +Cc: Bitcoin-Dev
    
    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
    
    
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
        2013-05-22  3:37   ` zooko
      @ 2013-05-22  4:12     ` Jeff Garzik
        0 siblings, 0 replies; 27+ messages in thread
      From: Jeff Garzik @ 2013-05-22  4:12 UTC (permalink / raw)
        To: zooko; +Cc: Bitcoin-Dev
      
      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
      
      
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
    2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
    2013-05-19 15:08 ` Peter Vessenes
  @ 2013-05-20  7:12 ` Luke-Jr
    2013-06-13 13:39 ` Adam Back
    2013-06-15 11:18 ` Melvin Carvalho
    3 siblings, 0 replies; 27+ messages in thread
  From: Luke-Jr @ 2013-05-20  7:12 UTC (permalink / raw)
    To: bitcoin-development
  
  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
  
  
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
    2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
    2013-05-19 15:08 ` Peter Vessenes
    2013-05-20  7:12 ` Luke-Jr
  @ 2013-06-13 13:39 ` Adam Back
    2013-06-14 19:20   ` Peter Todd
    2013-06-15 11:18 ` Melvin Carvalho
    3 siblings, 1 reply; 27+ messages in thread
  From: Adam Back @ 2013-06-13 13:39 UTC (permalink / raw)
    To: Bitcoin-Dev
  
  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
  
  
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
      2013-06-13 13:39 ` Adam Back
    @ 2013-06-14 19:20   ` Peter Todd
      2013-06-14 20:50     ` Adam Back
      0 siblings, 1 reply; 27+ messages in thread
    From: Peter Todd @ 2013-06-14 19:20 UTC (permalink / raw)
      To: Adam Back; +Cc: Bitcoin-Dev
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
        2013-06-14 19:20   ` Peter Todd
      @ 2013-06-14 20:50     ` Adam Back
        2013-06-14 21:10       ` Luke-Jr
        0 siblings, 1 reply; 27+ messages in thread
      From: Adam Back @ 2013-06-14 20:50 UTC (permalink / raw)
        To: Peter Todd; +Cc: Bitcoin-Dev
      
      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.
      
      
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
          2013-06-14 20:50     ` Adam Back
        @ 2013-06-14 21:10       ` Luke-Jr
          2013-06-14 21:25         ` Andreas Petersson
          0 siblings, 1 reply; 27+ messages in thread
        From: Luke-Jr @ 2013-06-14 21:10 UTC (permalink / raw)
          To: bitcoin-development
        
        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
        
        
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
            2013-06-14 21:10       ` Luke-Jr
          @ 2013-06-14 21:25         ` Andreas Petersson
            2013-06-15  0:09           ` Dennison Bertram
            0 siblings, 1 reply; 27+ messages in thread
          From: Andreas Petersson @ 2013-06-14 21:25 UTC (permalink / raw)
            To: bitcoin-development
          
          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.
          
          
          
          
          ^ permalink raw reply	[flat|nested] 27+ messages in thread

        • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
              2013-06-14 21:25         ` Andreas Petersson
            @ 2013-06-15  0:09           ` Dennison Bertram
              2013-06-15  1:57             ` Luke-Jr
              0 siblings, 1 reply; 27+ messages in thread
            From: Dennison Bertram @ 2013-06-15  0:09 UTC (permalink / raw)
              To: Andreas Petersson; +Cc: bitcoin-development
            
            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
            
            
            
            ^ permalink raw reply	[flat|nested] 27+ messages in thread

          • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
                2013-06-15  0:09           ` Dennison Bertram
              @ 2013-06-15  1:57             ` Luke-Jr
                2013-06-15  8:43               ` Dennison Bertram
                0 siblings, 1 reply; 27+ messages in thread
              From: Luke-Jr @ 2013-06-15  1:57 UTC (permalink / raw)
                To: bitcoin-development
              
              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.
              
              
              
              ^ permalink raw reply	[flat|nested] 27+ messages in thread

            • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
                  2013-06-15  1:57             ` Luke-Jr
                @ 2013-06-15  8:43               ` Dennison Bertram
                  0 siblings, 0 replies; 27+ messages in thread
                From: Dennison Bertram @ 2013-06-15  8:43 UTC (permalink / raw)
                  To: Luke-Jr; +Cc: bitcoin-development
                
                [-- 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 --]
                
                ^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
    2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
                     ` (2 preceding siblings ...)
    2013-06-13 13:39 ` Adam Back
  @ 2013-06-15 11:18 ` Melvin Carvalho
    2013-06-15 13:26   ` Dennison Bertram
    3 siblings, 1 reply; 27+ messages in thread
  From: Melvin Carvalho @ 2013-06-15 11:18 UTC (permalink / raw)
    To: Adam Back; +Cc: Bitcoin-Dev
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
      2013-06-15 11:18 ` Melvin Carvalho
    @ 2013-06-15 13:26   ` Dennison Bertram
      2013-06-16 15:46     ` Dennison Bertram
      0 siblings, 1 reply; 27+ messages in thread
    From: Dennison Bertram @ 2013-06-15 13:26 UTC (permalink / raw)
      To: Melvin Carvalho; +Cc: Bitcoin-Dev
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [Bitcoin-development] is there a way to do bitcoin-staging?
        2013-06-15 13:26   ` Dennison Bertram
      @ 2013-06-16 15:46     ` Dennison Bertram
        0 siblings, 0 replies; 27+ messages in thread
      From: Dennison Bertram @ 2013-06-16 15:46 UTC (permalink / raw)
        To: Melvin Carvalho; +Cc: Bitcoin-Dev
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2014-03-17 15:55 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
2013-05-19 15:08 ` Peter Vessenes
2013-05-20  6:34   ` Alan Reiner
2013-10-14 18:08     ` Adam Back
2013-10-14 18:21       ` Jeff Garzik
2013-11-21 20:22       ` coinscoins
2013-11-21 20:35       ` Melvin Carvalho
2013-11-21 21:11         ` [Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?) Adam Back
2014-03-16 22:58       ` [Bitcoin-development] 2-way pegging " Adam Back
2014-03-16 23:22         ` Jorge Timón
2014-03-17 15:55         ` Gregory Maxwell
2013-10-14 18:43     ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
2013-10-14 20:20       ` Alan Reiner
2013-05-22  3:37   ` zooko
2013-05-22  4:12     ` Jeff Garzik
2013-05-20  7:12 ` Luke-Jr
2013-06-13 13:39 ` Adam Back
2013-06-14 19:20   ` Peter Todd
2013-06-14 20:50     ` Adam Back
2013-06-14 21:10       ` Luke-Jr
2013-06-14 21:25         ` Andreas Petersson
2013-06-15  0:09           ` Dennison Bertram
2013-06-15  1:57             ` Luke-Jr
2013-06-15  8:43               ` Dennison Bertram
2013-06-15 11:18 ` Melvin Carvalho
2013-06-15 13:26   ` Dennison Bertram
2013-06-16 15:46     ` Dennison Bertram

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox