Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
Sorry about that. Maybe more important, what's wrong with bitcoin and zerocoin being different currencies with an exchange rate completely decided by the market instead of trying to force 1:1 ??? On 7/13/13, Jorge Timón jti...@monetize.io wrote: I'm not sure I understand the whole proposal, but it seems to me that having different characteristics, bitcoins and zerocoins would be different currencies. I don't see the need to peg zerocoins to bitcoins. It is great to have an anonymous p2p currency, maybe some bitcoin users that use bitcoin because of the transparency they allow (public funds expenditures could be more transparent than they have ever been) don't like this hard-fork. Well, maybe this is not the main reason, but I think this could be highly controversial. Maybe everybody likes it, but can you expand more on the justifications to peg the two currencies? If you're requiring one chain look at the othe for validations (miners will have to validate both to mine btc) you don't need the cross-chain contract, you can do it better. Instead of doing this: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains You could do something like this: https://bitcointalk.org/index.php?topic=31643.0 This very idea has been proposed recently by othe people, but I can't find where. The problem with this is of course scalabilty. Once you do it for what chain, why not the others? You can't validate 100 chains to mine bitcoin even if they're all merged mined: that's asking miners too much. If zerocoin enjoys this privilege why not, for example? As some of you may know, Mark Friedenbach and I are working on a protocol modification to support issuance of arbitrary assets. Would be something like colored coins but better, we're calling it FreiMarkets. Of course these assets are not p2p like bitcoin or freicoin themselves: they have a centralized issuer. But if you allowed to sacrifice real bitcoins (as opposed to IOUs denominated in BTC like you have, for example, in ripple) so they appear in Freicoin's chain and turn them back, you could have p2p bitcoins inside Freicoin's chain. Maybe ripplers want that too. If FreiMarkets prove to work well on freicoin and be scalable enough, maybe a lot of scamcoins apply the hardfork too and they want to have p2p btc in their chain as well. Maybe I could have explained this without even mentioning FreiMarkets, but my point is that you're asking for a lot like it was nothing. Zerocoin-bitcoin fungibility hardfork is opening a little pandora's box. Are we ready? I was waiting for others to comment and I'm surprised that no one else has made any objection yet. But if no one's going to point out the controvery that is so obvious to me, I feel almost like a responsability to act like a Devil's advocate here. So if you make bitcoin and zerocoin fungible, I want bitcoins to be transferrable to freicoin's chain. And I warn you there will be many more people asking for the same thing on other chains. What criteria will we have to say yes or no? More On 7/12/13, Peter Todd p...@petertodd.org wrote: On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote: Do people think that should work? It seems to me it should with minimal, bitcoin changes. I think the rule for either-or mining should be as simple as skipping the value / double-spend validation of the blocks that are zerocoin mining blocks. Obviously zerocoin blocks can themselves end up on forks, that get resolved, but that fork resolution can perhaps be shared? (Because the fork resolution is simply to accept the longest fork). Yeah, there's been a lot of doom and gloom about zerocoin that is frankly unwarrented. For instance people seem to think it's impossible to make a blockchain with zerocoin due to the long time it takes to verify transactions, about 1.5 seconds, and never realize that verification can be parallelized. Anyway the way to do it is to get out of the model of large blocks and think about individual transactions. Make each transaction into its own block, and have each transaction refer to the previous one in history. (zerocoin is inherently linear due to the anonymity) Verification does *not* need to be done by every node on every transaction. Make the act of creating a transaction cost something and include the previous state of the accumulator as part of a transaction. Participants verify some subset of all transactions, and should they find fraud they broadcast a proof. Optionally, but highly recomended, make it profitable to find fraud, being careful to ensure that it's never profitable to create fraud then find it yourself. Anyway Bitcoin is limited to 7tx/s average so even without probabalistic verification it'd be perfectly acceptable to just limit transactions to one every few seconds provided you keep your blocksize down to one transaction so the rate isn't bursty. You're going to want to be
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
On Sat, Jul 13, 2013 at 11:51:14AM +0200, Jorge Timón wrote: I don't see the need to peg zerocoins to bitcoins. Without a bitcoin peg on the creation cost of zerocoins, it is hard for a new alt-coin to have a stable value. Bitcoin itself is volatile enough. Generally the available compute for mining is what it is, adding more alt-coins just dillutes the compute available for a given coin. (Modulo different mining functions like scrypt vs hashcash there is some non-overlapping available compute because different hardware is more efficient, or even cost-effective at all). Merge mining is less desirable for the alt-coin - its mining is essentially free, on top of bitcoin mining. Cost free is maybe a weaker starting point bootstrapping digital scarcity based market price. I think that serves to explain why bitcoin sacrifice as a mining method is a simple and stable cost starting point for an alt-coin. I think this could be highly controversial [alt-coin pegging]. Maybe everybody likes it, but can you expand more on the justifications to peg the two currencies? Bitcoin sacrifice related applications do not require code changes to bitcoin itself, which avoids the discussion about fairness of which alt-coin is supported, and about sacrifice-based pegging being added or not. I dont think it necessarily hurts investors in bitcoins as it just creates some deflation in the supply of bitcoin. If you're requiring one chain look at the othe for validations (miners will have to validate both to mine btc) you don't need the cross-chain contract, you can do it better. You can sacrifice bitcoins as a way to mine zerocoins without having the bitcoin network validate zerocoin. For all bitcoin clients care the sacrifice could be useless. Bi-directional sacrifice is more tricky. ie being allowed to re-create previously destroyed bitcoins, based on the sacrifice of zerocoin. That would have other coin validation requirements. But I am not sure 1:1 is necessarily far from the right price - the price is arbitrary for a divisible token, so 1:1 is as good as any. And the price equality depends on the extra functionality or value from the characteristics of the other coin. The only thing I can see is zerocoin is more cpu expensive to validate, the coins are bigger, but provide more payment privacy (and so less taint). Removing taint may mean that zercoins should be worth more. However if any tainted bitcoins can be converted to zerocoin via sacrifice at 1:1, maybe the taint issue goes away - any coins that are tainted to the point of value-loss will be converted to zerocoin, and consequently the price to convert back should also be 1:1? You could do something like this: https://bitcointalk.org/index.php?topic=31643.0 p2p transfer is a good idea. Adam -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
One very real issue for alt-currencies that don't peg to Bitcoin is that market liquidity is a bitch. By almost all standards current global Bitcoin liquidity is already very, very low. Too low for many transactions that come across my desk at least. There are a lot of reasons for that low liquidity, but to try and float a new pair for which the likely initial counter-asset is going to be Bitcoin means minuscule liquidity. Peter On Sat, Jul 13, 2013 at 2:53 AM, Jorge Timón jti...@monetize.io wrote: Sorry about that. Maybe more important, what's wrong with bitcoin and zerocoin being different currencies with an exchange rate completely decided by the market instead of trying to force 1:1 ??? On 7/13/13, Jorge Timón jti...@monetize.io wrote: I'm not sure I understand the whole proposal, but it seems to me that having different characteristics, bitcoins and zerocoins would be different currencies. I don't see the need to peg zerocoins to bitcoins. It is great to have an anonymous p2p currency, maybe some bitcoin users that use bitcoin because of the transparency they allow (public funds expenditures could be more transparent than they have ever been) don't like this hard-fork. Well, maybe this is not the main reason, but I think this could be highly controversial. Maybe everybody likes it, but can you expand more on the justifications to peg the two currencies? If you're requiring one chain look at the othe for validations (miners will have to validate both to mine btc) you don't need the cross-chain contract, you can do it better. Instead of doing this: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains You could do something like this: https://bitcointalk.org/index.php?topic=31643.0 This very idea has been proposed recently by othe people, but I can't find where. The problem with this is of course scalabilty. Once you do it for what chain, why not the others? You can't validate 100 chains to mine bitcoin even if they're all merged mined: that's asking miners too much. If zerocoin enjoys this privilege why not, for example? As some of you may know, Mark Friedenbach and I are working on a protocol modification to support issuance of arbitrary assets. Would be something like colored coins but better, we're calling it FreiMarkets. Of course these assets are not p2p like bitcoin or freicoin themselves: they have a centralized issuer. But if you allowed to sacrifice real bitcoins (as opposed to IOUs denominated in BTC like you have, for example, in ripple) so they appear in Freicoin's chain and turn them back, you could have p2p bitcoins inside Freicoin's chain. Maybe ripplers want that too. If FreiMarkets prove to work well on freicoin and be scalable enough, maybe a lot of scamcoins apply the hardfork too and they want to have p2p btc in their chain as well. Maybe I could have explained this without even mentioning FreiMarkets, but my point is that you're asking for a lot like it was nothing. Zerocoin-bitcoin fungibility hardfork is opening a little pandora's box. Are we ready? I was waiting for others to comment and I'm surprised that no one else has made any objection yet. But if no one's going to point out the controvery that is so obvious to me, I feel almost like a responsability to act like a Devil's advocate here. So if you make bitcoin and zerocoin fungible, I want bitcoins to be transferrable to freicoin's chain. And I warn you there will be many more people asking for the same thing on other chains. What criteria will we have to say yes or no? More On 7/12/13, Peter Todd p...@petertodd.org wrote: On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote: Do people think that should work? It seems to me it should with minimal, bitcoin changes. I think the rule for either-or mining should be as simple as skipping the value / double-spend validation of the blocks that are zerocoin mining blocks. Obviously zerocoin blocks can themselves end up on forks, that get resolved, but that fork resolution can perhaps be shared? (Because the fork resolution is simply to accept the longest fork). Yeah, there's been a lot of doom and gloom about zerocoin that is frankly unwarrented. For instance people seem to think it's impossible to make a blockchain with zerocoin due to the long time it takes to verify transactions, about 1.5 seconds, and never realize that verification can be parallelized. Anyway the way to do it is to get out of the model of large blocks and think about individual transactions. Make each transaction into its own block, and have each transaction refer to the previous one in history. (zerocoin is inherently linear due to the anonymity) Verification does *not* need to be done by every node on every transaction. Make the act of creating a transaction cost something and include the
