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 multiple parallel zerocoin blockchains, although given the usecase of moving your funds through zerocoin for anonymity, and using the clean coins that come out the other side, there's no reason to think the zerocoin chain transaction rate needs to be especially high anyway. -- 'peter'[:-1]@petertodd.org 0000000000000013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf
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=48808831&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoinfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/bitcoin-development