From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UxwvX-0001Pb-Rg for bitcoin-development@lists.sourceforge.net; Sat, 13 Jul 2013 10:19:43 +0000 Received: from mail-la0-f48.google.com ([209.85.215.48]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UxwvV-0005sg-Qn for bitcoin-development@lists.sourceforge.net; Sat, 13 Jul 2013 10:19:43 +0000 Received: by mail-la0-f48.google.com with SMTP id lx15so8369913lab.35 for ; Sat, 13 Jul 2013 03:19:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=fiv9NwhmbKmACmLDzyaHrMOZ2IsNWbjLzr9kYu6OtTs=; b=e8iQidYfzIgwFbnK369x4QfJ5/KNNQKyThdtOLD0nNUT+Yq7Y2N2N+KNrCihZSUzMn LLt/szYoUA2hfVL75iL6SnsBhQgxSaBxbPSt9EkaxZDOpRA/8+Xwe6ud5vBQHbPDNR2O zcpBm8X7n/2e+aPu5ijRqc/NxvaqKR+PPRo7533yIUoUHCkSYL2xM2jz+qxahksdfbwQ xXiLYIxhf7AIC8qCmd7ZZUahiQP/mE36ghwXn+ujuePErntk73wJIgUmBDHD8g8cwlN/ XYLxePqBxOEZ4J01HQe21VzAV7FB5w+1p22LZGGvbNJsrDrDXhvxqvs2emcMXiMBeZ01 i3dA== MIME-Version: 1.0 X-Received: by 10.152.4.163 with SMTP id l3mr21094489lal.60.1373709224475; Sat, 13 Jul 2013 02:53:44 -0700 (PDT) Received: by 10.112.185.3 with HTTP; Sat, 13 Jul 2013 02:53:44 -0700 (PDT) X-Originating-IP: [80.27.103.246] In-Reply-To: References: <20130705140140.GA23949@netbook.cypherspace.org> <20130712131815.GA18716@petertodd.org> Date: Sat, 13 Jul 2013 11:53:44 +0200 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlWfbXxLLLeFpnMnBYr3T/PPDLgdEUmw1TeyQsG86NrMJm+OdvJ6zlnlWEJYoFvCwYE/Fzr X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1UxwvV-0005sg-Qn Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 10:19:44 -0000 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=F3n 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=3D31643.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 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 u= p >>> 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 >> >> 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 >> > > > -- > Jorge Tim=F3n > > http://freico.in/ > --=20 Jorge Tim=F3n http://freico.in/