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