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

[Melvin Carvalho]

On 14 October 2013 20:08, 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.
>

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 intentio

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

[coinscoins]

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


--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Alan Reiner]

Michael,

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

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

-Alan


On 10/14/2013 02:43 PM, Michael Gronager wrote:
> Hi Alan,
>
> What you describe in the ultimate blockchain compression I have already
> coded the authenticated datastructure part of in libcoin
> (https://github.com/libcoin/libcoin) - next step is to include a p2pool
> style mining, where a parallel chain serves several purposes:
> 1. to validate the root hash at a higher frequency than the 10 min
> 2. to enable distributed mining, easily (part of libcoind)
> 3. to utilize the soft fork by defining the root hash in coinbase blocks
> as v3 and once we cross the limit all blocks are v3.
>
> I will have a closer look at you bitcoin talk post to see how well my
> approach and ideas fit to yours.
>
> Michael
>
> On 20/5/13 08:34 , Alan Reiner wrote:
>> This is exactly what I was planning to do with the inappropriately-named
>> "Ultimate Blockchain Compression
>> ".  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 >> > 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

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

[Michael Gronager]

Hi Alan,

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

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

Michael

On 20/5/13 08:34 , Alan Reiner wrote:
> This is exactly what I was planning to do with the inappropriately-named
> "Ultimate Blockchain Compression
> ".  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 > > 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
>>

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

[Jeff Garzik]

On Mon, Oct 14, 2013 at 2:08 PM, Adam Back  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/

--
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

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

[Adam Back]

Coming back to the staging idea, maybe this is a realistic model that could
work.  The objective being to provide a way for bitcoin to move to a live
beta and stable being worked on in parallel like fedora vs RHEL or odd/even
linux kernel versions.

Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x
stable and leap-frogs as beta becomes stable after testing.

Its a live beta, meaning real value, real contracts.  But we dont want it to
be an alt-coin with a floating value exactly, we want it to be bitcoin, but
the bleeding edge bitcoin so we want to respect the 21 million coin limit,
and allow coins to move between bitcoin and betacoin with some necessary
security related restrictions.

There is no mining reward on the betacoin network (can be merge mined for
security), and the way you opt to move a bitcoin into the betacoin network
is to mark it as transferred in some UTXO recognized way.  It cant be
reanimated, its dead.  (eg spend to a specific recognized invalid address on
the bitcoin network).  In this way its not really a destruction, but a move,
moving the coin from bitcoin to betacoin network.

This respects the 21 million coin cap, and avoids betacoin bugs flowing back
and affecting bitcoin security or value-store properties.  Users may buy or
swap betacoin for bitcoin to facilitate moving money back from betacoin to
bitcoin.  However that is market priced so the bitcoin network is security
insulated from beta.  A significant security bug in beta would cause a
market freeze, until it is rectified.

The cost of a betacoin is capped at one BTC because no one will pay more
than one bitcoin for a betacoin because they could alternatively move their
own coin.  The reverse is market priced.

Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
decision is reached to promote 1.0 beta to 2.0 stable, the remaining
bitcoins can be moved, and the old network switched off, with mining past a
flag day moving to the betacoin.

During the beta period betacoin is NOT an alpha, people can rely on it and
use it in anger for real value transactions.  eg if it enables more script
features, or coin coloring, scalabity tweaks etc people can use it. 
Probably for large value store they are always going to prefer
bitcoin-stable, but applications that need the coloring features, or
advanced scripting etc can go ahead and beta.

Bitcoin-stable may pull validated changes and merge them, as a way to pull
in any features needed in the shorter term and benefit from the betacoin
validation.  (Testing isnt as much validation as real-money at stake
survivability). 

The arguments are I think that: 

- it allows faster development allowing bitcoin to progress features faster,

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

- it concentrates such useful-feature alt activities into one OPEN source
   and OPEN control foundation mediated area (rather than suspected land
   grabs on colored fees or such like bitcoin respun as a business model
   things),

- maybe gets the developers that would've been working on their pet
   alt-coin, or their startup alt-coin to work together putting more
   developers, testers and resources onto something with open control (open
   source does not necessarily mean that much) and bitcoin mindshare
   branding, its STILL bitcoin, its just the beta network.

- it respects the 21 million limit, starting new mining races probably
   dillutes the artificial scarcity semantic

- while insulating bitcoin from betacoin security defects (I dont mean
   betacoin as a testnet, it should have prudent rigorous testing like
   bitcoin, just the very act of adding a feature creates risk that bitcoin
   stable can be hesitant to take).

Probably the main issue as always is more (trustable) very high caliber
testers and developers.  Maybe if the alt-coin minded startups and
developers donate their time to bitcoin-beta (or bitcoin-stable) for the
bits they are missing, we'll get more hands to work on something of reusable
value to humanity, in parallel with their startup's objectives and as a way
for them to get their needed features, while giving back to the bitcoin
community, and helping bitcoin progress faster.

Maybe bitcoin foundation could ask for BTC donations to hire more developers
and testers full time.  $1.5b of stored value should be interested to safe
guard their value store, and develop the transaction features.

Adam

On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
>   This is exactly what I was planning to do with the
>   inappropriately-named "Ultimate Blockchain Compression".  [...]
> 
>   For it to really work, it's gotta be part of the mainnet validation
>   rules, but no way it can be evaluated realistically without some kind of
>   "staging".  

>   On 5/19/2013 11:08 AM, Peter Vessenes wrote:
>
>   I think this is a very interesting idea. As Bitcoiners, we often stuff
>   things into the

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

[Dennison Bertram]

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 <
denni...@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 
> wrote:
>
>
>
>
> On 19 May 2013 15:23, 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).
>>
>
> 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
>

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

[Dennison Bertram]

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  wrote:

> 
> 
> 
> On 19 May 2013 15:23, 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).
> 
> 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
--
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

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

[Melvin Carvalho]

On 19 May 2013 15:23, 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).
>

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

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

[Dennison Bertram]

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"  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.
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Luke-Jr]

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

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

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Dennison Bertram]

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

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

Sent from my iPhone

On Jun 14, 2013, at 11:25 PM, Andreas Petersson  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

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Andreas Petersson]

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

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

Andreas

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


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Luke-Jr]

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

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Adam Back]

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

Adam

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

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Peter Todd]

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
00b7dc90d34b08218b76687c0cd8a00878fea13d4ce98b0f4df0


signature.asc
Description: Digital signature
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Adam Back]

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

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

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

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

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

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

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

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

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

Adam

On Sun, May 19, 2013 at 03:23:59PM +0200, Adam Back wrote:
>Is there a way to experiment with new features - eg committed coins - that
>doesnt involve an altcoin in the conventional sense, and also doesnt impose
>a big testing burden on bitcoin main which is a security and testing risk?
>
>eg lets say some form of merged mine where an alt-coin lets call it
>bitcoin-staging?  where the coins are the same coins as on bitcoin, the
>mining power goes to bitcoin main, so some aspect of merged mining, but no
>native mining.  and ability to use bitcoins by locking them on bitcoin to
>move them to bitcoin-staging and vice versa (ie exchange them 1:1
>cryptographically, no exchange).
>
>Did anyone figure anything like that out?  Seems vaguely doable and
>maybe pr

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

[Jeff Garzik]

On Tue, May 21, 2013 at 11:37 PM, zooko  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.
jgar...@exmulti.com

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[zooko]

Folks:

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

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

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

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

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

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

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

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

Regards,

Zooko

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Luke-Jr]

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

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

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

[Alan Reiner]

This is exactly what I was planning to do with the inappropriately-named 
"Ultimate Blockchain Compression 
".  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 > 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 

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

[Peter Vessenes]

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  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  in San Jose In May?
--

[image: CoinLab Logo]PETER VESSENES
CEO

*pe...@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

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

[Adam Back]

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

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

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

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

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

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

Adam

--
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