Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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=63431311iu=/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?
On 14 October 2013 20:08, Adam Back a...@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
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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 a...@cypherspace.org mailto:a...@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
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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 a...@cypherspace.org mailto:a...@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).
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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 melvincarva...@gmail.com wrote: On 19 May 2013 15:23, Adam Back a...@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
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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 l...@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. -- 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?
On 19 May 2013 15:23, Adam Back a...@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
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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 melvincarva...@gmail.com wrote: On 19 May 2013 15:23, Adam Back a...@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 -- 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?
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?
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?
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?
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 andr...@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 -- 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?
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
