Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.176 as permitted sender)
	client-ip=209.85.215.176; envelope-from=adam.back@gmail.com;
	helo=mail-ea0-f176.google.com; 
Date: Thu, 13 Jun 2013 15:39:32 +0200
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130613133932.GA13028@netbook.cypherspace.org>
References: <20130519132359.GA12366@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130519132359.GA12366@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Precedence: list

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