Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote: 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. Being able to have automated Bitcoin-Zerocoin P2P trading without an exchange is also significantly more desirable from a privacy standpoint. Basically it reduces the privacy risks of doing the exchange to spending the Zerocoins in the first place. -- 'peter'[:-1]@petertodd.org 00878c30a45104c48fd4e8037cb5b3ba1e14dc4d8bef72eff1be signature.asc Description: Digital signature -- 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 way sacrifice (btc to zerocoin) is a non-issue since there's no modification required for bitcoin and you can't do anything to prevent it anyway. The controversial thing is sacrificing something outside bitcoin's chain and new btc appearing. On merged mining. It is true that merged attacking the other chain is free, but it is still more profitable to just follow the rules and mine the other coin!! If someone considers that something he can sell in a market for btc is negative value...well, he's just dammed stupid. Proof of work is designed for rational actors, if you stop assuming miners are more or less rational everything falls apart. It is possible that the extra value is too little for some miners to bother. But the extra costs of validating something else are so little compared to chance-hashing that miners not merged mining namecoin right now are just stupid (irrational agents). You can merged mine and sell for btc right away. On prime proof of work...for me it's interseting only because it's moving towards SCIP-based mining but that should be the goal. Like Mark said, let's cure cancer while mining. That would end all mining is wasteful arguments about this great security system. This would make Ripple's consensus mechanism less attractive. People talking about new scrypts harder to ASIC-mine when that's the elephant in the room... Sorry, I'm going off-topic. SCIP-based merged mining for the win. On 7/15/13, Peter Todd p...@petertodd.org wrote: On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote: 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. Being able to have automated Bitcoin-Zerocoin P2P trading without an exchange is also significantly more desirable from a privacy standpoint. Basically it reduces the privacy risks of doing the exchange to spending the Zerocoins in the first place. -- 'peter'[:-1]@petertodd.org 00878c30a45104c48fd4e8037cb5b3ba1e14dc4d8bef72eff1be -- Jorge Timón http://freico.in/ -- 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
On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote: One way sacrifice (btc to zerocoin) is a non-issue since there's no modification required for bitcoin and you can't do anything to prevent it anyway. The controversial thing is sacrificing something outside bitcoin's chain and new btc appearing. Which is why I'm not proposing that. On merged mining. It is true that merged attacking the other chain is free, but it is still more profitable to just follow the rules and mine the other coin!! If someone considers that something he can sell in a market for btc is negative value...well, he's just dammed stupid. Proof of work is designed for rational actors, if you stop assuming miners are more or less rational everything falls apart. It is possible that the extra value is too little for some miners to bother. But the extra costs of validating something else are so little compared to chance-hashing that miners not merged mining namecoin right now are just stupid (irrational agents). You can merged mine and sell for btc right away. You are assuming value is the same for everyone - it's not. If I mine in a jurisdiction where zerocoin is banned, and the blocks I mine are public, the value of zerocoin blocks to me are at best zero. Equally it would be easy for the local authorities to ask that I merge mine zerocoin blocks to attack the chain - it doesn't cost me anything so what's the harm? I may even choose to do so to preserve the value of the coins I can mine legally - alt-coins are competition. Incedentally keep in mind it is likely that in the future pools will not allow miners to modify the work units they receive in any way as a means of combating block-withholding fraud; there may not be very many people willing or able to honestly merge-mine any given chain. Proof-of-sacrifice can be done in a way that is opaque to the master blockchain by creating txouts that look no different from any other txout. Hopefully not required, but it would be a good strategy against censorship of sacrifice-based chains. On prime proof of work...for me it's interseting only because it's moving towards SCIP-based mining but that should be the goal. Like Mark said, let's cure cancer while mining. That would end all mining is wasteful arguments about this great security system. This would make Ripple's consensus mechanism less attractive. People talking about new scrypts harder to ASIC-mine when that's the elephant in the room... Sorry, I'm going off-topic. SCIP-based merged mining for the win. SCIP is for now a dream. Give it a few more years and see how the technology shakes out. -- 'peter'[:-1]@petertodd.org 00582cc323897a582e9368a5c3dfbcdcf73e78b261703e1bd1ba signature.asc Description: Digital signature -- 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
I'm at the Aspen Institute right now talking about Bitcoin and I mentioned the perils of starting an alt-chain based on proof of work that pool operators might attack; funny synchronicity! Peter On Mon, Jul 15, 2013 at 2:29 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote: One way sacrifice (btc to zerocoin) is a non-issue since there's no modification required for bitcoin and you can't do anything to prevent it anyway. The controversial thing is sacrificing something outside bitcoin's chain and new btc appearing. Which is why I'm not proposing that. On merged mining. It is true that merged attacking the other chain is free, but it is still more profitable to just follow the rules and mine the other coin!! If someone considers that something he can sell in a market for btc is negative value...well, he's just dammed stupid. Proof of work is designed for rational actors, if you stop assuming miners are more or less rational everything falls apart. It is possible that the extra value is too little for some miners to bother. But the extra costs of validating something else are so little compared to chance-hashing that miners not merged mining namecoin right now are just stupid (irrational agents). You can merged mine and sell for btc right away. You are assuming value is the same for everyone - it's not. If I mine in a jurisdiction where zerocoin is banned, and the blocks I mine are public, the value of zerocoin blocks to me are at best zero. Equally it would be easy for the local authorities to ask that I merge mine zerocoin blocks to attack the chain - it doesn't cost me anything so what's the harm? I may even choose to do so to preserve the value of the coins I can mine legally - alt-coins are competition. Incedentally keep in mind it is likely that in the future pools will not allow miners to modify the work units they receive in any way as a means of combating block-withholding fraud; there may not be very many people willing or able to honestly merge-mine any given chain. Proof-of-sacrifice can be done in a way that is opaque to the master blockchain by creating txouts that look no different from any other txout. Hopefully not required, but it would be a good strategy against censorship of sacrifice-based chains. On prime proof of work...for me it's interseting only because it's moving towards SCIP-based mining but that should be the goal. Like Mark said, let's cure cancer while mining. That would end all mining is wasteful arguments about this great security system. This would make Ripple's consensus mechanism less attractive. People talking about new scrypts harder to ASIC-mine when that's the elephant in the room... Sorry, I'm going off-topic. SCIP-based merged mining for the win. SCIP is for now a dream. Give it a few more years and see how the technology shakes out. -- 'peter'[:-1]@petertodd.org 00582cc323897a582e9368a5c3dfbcdcf73e78b261703e1bd1ba -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110 -- 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
I was talking about bi-directional sacrifice. If zerocoin has it, I want the same on top of freicoin so that btc/frc can be traded p2p. Why zerocoin and not the 20 other altchains are going to ask for it? Ripplers will want it too, why not? All the arguments in favor of this pegging use zerocoin's point of view. Sure it would be much better for it, but are additional costs to the bitcoin network and you cannot do it with every chain. Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Bitcoins are worth because it costs to mine them is a Marxian labor thory of value argument. It's the other way arround as Menger taught us. On 7/13/13, Adam Back a...@cypherspace.org wrote: 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 -- Jorge Timón http://freico.in/ -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón jti...@monetize.io wrote: All the arguments in favor of this pegging use zerocoin's point of view. Sure it would be much better for it, but are additional costs to the bitcoin network and you cannot do it with every chain. Seems that Peter is describing a system that requires no changes at all to the Bitcoin codebase and thus there are no costs whatsoever. Peter: I'm a bit confused by this concept of bi-directional sacrifice though, I assume there exists only a sacrifice in one direction right? Wouldn't selling a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx moving it to the new owner only happens if a specific form of bitcoin tx happens too? Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Bitcoins are worth because it costs to mine them is a Marxian labor thory of value argument. It's the other way arround as Menger taught us. Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC channel and on bitcointalk as well if memory serves. I advise you to look up his description of the problem, almost everything he writes on the topic of crypto-coin theory is spot-on correct. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915 SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ= =b40P -END PGP SIGNATURE- -- 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
On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote: Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. But the total reward is what mining will tend toward equalizing in costs. In any case, the cryptocurrencies are neutral to cost of mining, or perhaps even benefit from it being as cheap as possible: if it's cheaper to mine, you can get an even higher difficulty/security out of it. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. I suspect you may mean a block that doesn't include transactions you want confirmed. In that case, you must not be paying sufficient fees for the miner to consider it worth their time, or must be doing something the miner considers fundamentally objectionable (in which case they won't be satisfied by any fee). But these miners, unless they are able to acquire over 50% of the hashrate (in which case the cryptocoin is compromised), are not the only ones mining blocks, and if another miner accepts your transactions there is no issue. Luke signature.asc Description: This is a digitally signed message part. -- 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
On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. I don't think that's what John means. If you have hash power for the parent chain, mining invalid blocks for the merge-mined chain costs you nothing. Yes, they will be invalid, but you've lost nothing. The basic assumption underlying mining security is that it is more profitable to collaborate with mining a chain (and profit from the block payout) than to attack it. In the case of merged mining, this assumption is not valid. -- Pieter -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:33 PM, Luke-Jr l...@dashjr.org wrote: Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. But the total reward is what mining will tend toward equalizing in costs. In any case, the cryptocurrencies are neutral to cost of mining, or perhaps even benefit from it being as cheap as possible: if it's cheaper to mine, you can get an even higher difficulty/security out of it. Again, you forget that there may exist miners for which the value of the coin is negative. Never mind that in practice you want there to exist a cost to encourage miners to actually pay attention to what they mind and to encourage them to update software when required and participate. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. Validating clients, not SPV clients. I suspect you may mean a block that doesn't include transactions you want confirmed. In that case, you must not be paying sufficient fees for the miner to consider it worth their time, or must be doing something the miner considers fundamentally objectionable (in which case they won't be satisfied by any fee). But these miners, unless they are able to acquire over 50% of the hashrate (in which case the cryptocoin is compromised), are not the only ones mining blocks, and if another miner accepts your transactions there is no issue. All those things simply change the amount of alt-coin the miner gets, which to the miner may have no reward. You also have the issue that we may be talking about a non-currency chain where reward is more nebulous. In any case, regarding a zerocoin chain, Peter's observation that proof-of-sacrifice allows a strong 51% attck defense is very clever and IMO is significantly stronger than proof-of-work mining, merged or not, would provide. It's essentially the ability to conjur up mining capacity on demand, but only by those who have a stake in the crypto-coin. It does depend on the existance of a proof-of-work chain, but we have a perfectly good one handy. PS: good to see you signing you email! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4wCFAAoJEEWCsU4mNhiPIcwH+gLYbUPDi/7ITK02wftqEV2E FSlzZ0W8aw7z7sF7hqPm7jpmtqbXdvQRSSy+XRDgWUxvF72o5oRTwOpY7xN8KOct 9rMwF35nld8An9FOjOB6NR3sIQxmAg9q7xoilZrOHyRFcz/UT0BexSZ3x5DrKIAB 6S7qalrGT0NWZx8CI0PRAzY8Nx+WouaoofBaypRaXBVJxigFqJlWNxgUM1FuoCL+ C1wn0hlbWfO42Mh9jdnFZXhH2Omd5V3PzIS/t2cJGTjrwr7nT6VAJu+0hbNZHI/q yg0TGbO/01pp4OVe7WdLz9OktMqqDdDZJd6HWLQk07zqHS3iRJ2cpRIO6k9UCk0= =oicX -END PGP SIGNATURE- -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: Invalid blocks are rejected by validating clients in all circumstances. I don't think that's what John means. If you have hash power for the parent chain, mining invalid blocks for the merge-mined chain costs you nothing. Yes, they will be invalid, but you've lost nothing. The basic assumption underlying mining security is that it is more profitable to collaborate with mining a chain (and profit from the block payout) than to attack it. In the case of merged mining, this assumption is not valid. You said it better than I did. Essentially I am worried about the chain being strangled at birth, merge-mining makes doing so cost nothing for the attacker. With zerocoin this is a particularly dangerous possibility due to those in the Bitcoin community who would like to see Bitcoin continue to have poor privacy properties. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4wF9AAoJEEWCsU4mNhiPtCgH/3QLvFer3QHNU7AP+nehwcgK QS3xLv60lvm+pYLVAp9xFyJ5SCHVGTPvWRBmoldk8xxh9ORHlNEsnrcx9ZONTJ4F ja4Alp9MLZK5S8dKk2juJNdKziyRkQci/nNwuqepX5JjCIRNZq1lcW4Be4W7InPt Ltrvp7lA03uNuAXxtlYnko4mEY5l1NiBp4BvhGZ6+GRdCltPeIk2m0NwLDHWd31t qFLnnPSw0/9FGVs7lOaWuxbMGwPzGrIu6TXm17dqgBsl+8JuP6zHFE1ccqIxKyb6 Tdf4yNvhsvE+qlTnmcQNxM9nMHL4uqBZqJR174fAKQzcNGzVLloqbmRqKzuw5o4= =leUJ -END PGP SIGNATURE- -- 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
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote: On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. I don't think that's what John means. If you have hash power for the parent chain, mining invalid blocks for the merge-mined chain costs you nothing. Yes, they will be invalid, but you've lost nothing. Nor gained anything. So the lesser chain maybe can't trust SPV. But trusting SPV was already a bad idea anyway. Note that the parent chain is not in any privileged position here either: a merged-mined chain could provide the value to the miner he is interested in, while he sees nothing of the parent chain. In short, merged mining is pretty much unavoidable in any case. The basic assumption underlying mining security is that it is more profitable to collaborate with mining a chain (and profit from the block payout) than to attack it. In the case of merged mining, this assumption is not valid. The basic assumption of SPV is that more people will be assisting rather than making invalid blocks. That motive doesn't necessarily need to be economic, nor do proper validating clients rely on it. The only real assumption behind mining is that the majority will not be aiming to reverse transactions with valid blocks. P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic idea as well ;) signature.asc Description: This is a digitally signed message part. -- 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
I think bi-directional sacrifice is probably not needed to assure a close to 1:1 bi-directional peg. (Bi-directional sacrifice meaning also to convert a zerocoin to a bitcoin you sacrifice a zerocoin and bitcoin would be modified to accept a zerocoin sacrifice as a way to replace a previously sacrificed bitcoin). I say that because if users who want zerocoins can obtain them at 1:1 exchange via sacrifice (a mathematical peg), it is of no additional cost to them to instead buy them from someone who previously obtained them via sacrifice for bitcoin (rather than sacrificing a new bitcoin). So presumably for goodwill, or nominal fee (a small discount), people would buy rather than sacrifice where there is availability. Adam On Sun, Jul 14, 2013 at 07:22:10PM +, John Dillon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón jti...@monetize.io wrote: All the arguments in favor of this pegging use zerocoin's point of view. Sure it would be much better for it, but are additional costs to the bitcoin network and you cannot do it with every chain. Seems that Peter is describing a system that requires no changes at all to the Bitcoin codebase and thus there are no costs whatsoever. Peter: I'm a bit confused by this concept of bi-directional sacrifice though, I assume there exists only a sacrifice in one direction right? Wouldn't selling a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx moving it to the new owner only happens if a specific form of bitcoin tx happens too? Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Bitcoins are worth because it costs to mine them is a Marxian labor thory of value argument. It's the other way arround as Menger taught us. Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC channel and on bitcointalk as well if memory serves. I advise you to look up his description of the problem, almost everything he writes on the topic of crypto-coin theory is spot-on correct. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915 SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ= =b40P -END PGP SIGNATURE- -- 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
On Sun, Jul 14, 2013 at 07:22:10PM +, John Dillon wrote: Peter: I'm a bit confused by this concept of bi-directional sacrifice though, I assume there exists only a sacrifice in one direction right? Wouldn't selling a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx moving it to the new owner only happens if a specific form of bitcoin tx happens too? Exactly. Basically you have one way of creating a Zerocoin: prove you sacrificed a Bitcoin in a specific way. (spend to unspendable, or spend to mining fees far into the future) Now when you sell a Zerocoin what you do is create a Zerocoin transaction with a txout that can only be spent if you can prove that a Bitcoin transaction exists with specific conditions with sufficient confirmations. The specific condition would most likely be it has a txout of a specific value and scriptPubKey. Basically you'd have a two-part scriptPubKey: if check bitcoin txout existance proof check zerocoin buyers signature is correct else check zerocoin sellers signature is correct check n blocks have passed Note how if the buyer screws up there is a fallback so the seller can retrieve their funds after some reasonable amount of time. Of course if the Bitcoin chain is re-orged Bad Things Happen(TM), but just set the required number of confirms to something reasonable and you're good to go. It does mean Zerocoin needs to have consensus on the Bitcoin blockchain, but that's required to verify sacrifice proofs anyway. Economically the idea works because Zerocoins are gradually consumed by the proof-of-sacrifice required to make Zerocoin transactions. If the process by which Bitcoins are sacrificed is to fees, rather than permanently, the overall affect is just a minor decrease in the Bitcoin money supply. If they are sacrificed permanently, it'll result in long-term Bitcoin deflation - potentially an issue as the blockreward decreases. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- 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
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote: On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote: P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic idea as well ;) Your ideas about making an alt-coin have anything to do with hashing power might be a lot more convincing if you hadn't 51% attacks alt-coins in the past. Slander like this does not belong on the dev ML. -- 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
On Mon, Jul 15, 2013 at 01:51:21AM +, Luke-Jr wrote: On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote: On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote: P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic idea as well ;) Your ideas about making an alt-coin have anything to do with hashing power might be a lot more convincing if you hadn't 51% attacks alt-coins in the past. Slander like this does not belong on the dev ML. I wasn't aware you denied that accusation, so my apologies; I retract that statement. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- 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
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
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
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 cautious about bandwidth requirements anyway to make sure participants can stay anonymous. As you suggest creating zerocoins from provably sacrificing bitcoins is the correct approach. The consensus algorithm should be that you sacrifice zerocoins (specifically fractions there-of - note how I'm assuming support for non-single-zerocoin amounts) and whatever chain has the highest total sacrifice wins. One way to think about proof-of-sacrifice is it's really proof-of-work, transferred. It also has the *big* advantage that to double-spend, or for that matter 51% the chain, you have to outspend everyone with a stake in the viability of the blockchain: they can sacrifice their zerocoins to combat you. In the case of a double-spend to rip off an online merchant the total amount you could profit is the same as the total amount they would rationally spend to stop you, and soon there will be collateral damage too increasing the amount third-parties are willing to sacrifice to stop you. You can't win. Of course, this does mean that even unsuccesful sacrifices need to be costly. You can make this acceptable to users by allowing a sacrifice to be reused, but only for the exact same transaction it was originally committed to. Sacrifices in this manner are *not* proof of stake. You really are giving up something by publishing the information that proves you made the sacrifice as that information can always be included in the consensus thereby taking away a limited resource. (your zerocoins) It's more heavily dependent on jam-free networks, and doesn't play nice with SPV, but zero-knowledge proofs will may help the latter. (you've got Bitcoin itself to act as a random beacon remember) Speaking of, another similar approach is to take advantage of how a Bitcoin sacrifice can be made publicly visible. Create a txout of some value like the following: OP_RETURN prev-ztc-blockhash blockhash ztc-created Now even if you fail to publish your blocks, at least the whole world knows how much they need to outspend to be sure you can't 51% attack the network. This approach and not-btc sacrifices can go hand in hand too, especially if nodes follow rules where they consider btc txout sacrifices as fixed and only subject to change by the bitcoin blockchain re-organizing. Advantages and disadvantages to both approaches. (remember that visible tx's can be censored by miners) Sacrifice to mining fees may be acceptable in the future too, but only if OP_DEPTH is implemented so as to not give Bitcoin miners bad incentives. (the sacrificed coins should go to fees *months* or even *years* after they have been sacrificed) Turning zerocoins back into Bitcoins is just supply and demand: sell them. You'll always lose a bit given by definition the maximum exchange rate is 1:1, but anonymity may be worth it. Others have written about cross-chain trading protocols, and I'll point out they are easier to implement if one chain has full visibility into what's happening on the other; zerocoin is most likely to be implemented as an extension to the bitcoin client itself. Finally if the transaction rate is too slow there's nothing wrong with running
[Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
Hi I presume everyone saw the announce from Matthew Green Ian Miers at JHU on the release of libzerocoin: https://github.com/Zerocoin/libzerocoin So now that raises the question of how can people experiment with real money with zerocoin. I think its fair to summarize there is resistance to merging into bitcoin as it slows validation, bloats the blockchain, and also a policy aspect it also imports cryptographic privacy into bitcoin. On the forum thread on zerocoin math etc I suggested maybe people interested to explore bitcoin could create an all-zerocoin alt-coin that is either-or mined and p2p exchangeable for bitcoin. 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). what about making an all zerocoin based alt-coin (no bitcoins, nothing but zerocoins), that is either-or mined with bitcoin. Then people can trade in and out of zerocoins by buying or selling them for bitcoin with an atomic transaction, probably p2p without some trusted exchange like mtgox. Either-or mined (as distinct from merge-mined) I mean that each mined coin set is either a set of 25 bitcoins or a set of 25 zerocoins. If its a zerocoin set its not a valid bitcoin set, and if its a bitcoin its not a valid zerocoin. I'm not sure the zerocoins or bitcoins have to do much with mining events for the other network other than check they have the expected number of bits as they wont automatically know how to validate the other network. Some miners may choose to validate both networks, but thats a choice for them. In that way people can experiment with zerocoin, without bloating the block chain, complicating bitcoin, and without slowing validation on the bitcoin network. And the two coins should have approximately the same cost (and maybe therefore value, though the price would be subject to demand/supply and any taint discount for bitcoins; zerocoins are taint free, or perfectly blended taint at least). Adam -- 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
