Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Uy5bn-0003oI-G8 for bitcoin-development@lists.sourceforge.net; Sat, 13 Jul 2013 19:35:55 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; envelope-from=peter@coinlab.com; helo=mail-vc0-f174.google.com; Received: from mail-vc0-f174.google.com ([209.85.220.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Uy5bl-0002gu-Cd for bitcoin-development@lists.sourceforge.net; Sat, 13 Jul 2013 19:35:55 +0000 Received: by mail-vc0-f174.google.com with SMTP id kw10so8488306vcb.19 for ; Sat, 13 Jul 2013 12:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=aiXnuSund+JmXqdSdpD1ce25U0q+ufCCky7HiFFj/kc=; b=RLkuIW9GqZUZ7bwF5YS3Sy4XkIVkeJ0prk4FrPWFXnfIEQATIb1oJRBLURwmuUVggo yThvysD81zC5a6YeyBHWG7498JYLty++b0KjTl4hKZM2Hn4Qehc68+yD6goiJE6+4kCt CQ2yrGmd1zphJxuVBke6Y0s3TztiXg+FDTTcuMHduWpwAJ/HqM3NuJKWwL5m/vTKZTvi LsikFypp+QVrmI7jihF7yCYw/vv5+yVOoUtsPtGZUnjJWLVJP55IMJF8Ve0fKb6pnZXP OtD8BU1okqQ0Yb3tMZeG5lfDzc1CmV7g9wCYRDgGy4hMDadlQfd5g2zQJcDEw+WCKF/v ncOA== X-Received: by 10.220.88.68 with SMTP id z4mr26666583vcl.10.1373740379662; Sat, 13 Jul 2013 11:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.166.20 with HTTP; Sat, 13 Jul 2013 11:32:39 -0700 (PDT) In-Reply-To: References: <20130705140140.GA23949@netbook.cypherspace.org> <20130712131815.GA18716@petertodd.org> From: Peter Vessenes Date: Sat, 13 Jul 2013 11:32:39 -0700 Message-ID: To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= Content-Type: multipart/alternative; boundary=047d7b3a89c658005b04e168dbb0 X-Gm-Message-State: ALoCoQkdMhwOftNUpKQs5fnVl1r3TcdLkNy659Z5R72cOjw/77i6FP3/V316lQR4jPR9QZxiXVen X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Uy5bl-0002gu-Cd 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 19:35:55 -0000 --047d7b3a89c658005b04e168dbb0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=F3n 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=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 ar= e > >>> 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 ow= n > >> 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 probabalist= ic > >> verification it'd be perfectly acceptable to just limit transactions t= o > >> 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 i= s > >> 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 h= as > >> 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% t= he > >> chain, you have to outspend everyone with a stake in the viability of > >> the blockchain: they can sacrifice their zerocoins to combat you. In t= he > >> 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 wit= h > >> 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 t= he > >> 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 exchang= e > >> 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 th= e > >> other; zerocoin is most likely to be implemented as an extension to th= e > >> 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 thi= nk > >> the zerocoin chain transaction rate needs to be especially high anyway= . > >> > >> -- > >> 'peter'[:-1]@petertodd.org > >> 0000000000000013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf > >> > > > > > > -- > > Jorge Tim=F3n > > > > http://freico.in/ > > > > > -- > Jorge Tim=F3n > > 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=3D48808831&iu=3D/4140/ostg.= clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --=20 ------------------------------ [image: CoinLab Logo]PETER VESSENES CEO *peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes 900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110 --047d7b3a89c658005b04e168dbb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One very real issue for alt-currencies that don't peg = to Bitcoin is that market liquidity is a bitch. By almost all standards cur= rent global Bitcoin liquidity is already very, very low. Too low for many t= ransactions that come across my desk at least.

There are a lot of reasons for that low liquidity, but to tr= y and float a new pair for which the likely initial counter-asset is going = to be Bitcoin means minuscule liquidity.=A0

Peter<= /div>



On Sat, Jul 13, 2013 at 2:53 AM, Jorge Tim=F3n &l= t;jtimon@monetize.i= o> 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=F3n <jtimon@= monetize.io> wrote:
> I'm not sure I understand the whole proposal, but it seems to me t= hat
> 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<= br> > 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 (mi= ners
> will have to validate both to mine btc) you don't need the cross-c= hain
> 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= 9;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<= br> > 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.<= br> > 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 ma= ny
> 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 <pete@= petertodd.org> wrote:
>> On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote:
>>> Do people think that should work? =A0It seems to me it should = with
>>> minimal,
>>> bitcoin changes. =A0I think the rule for either-or mining shou= ld be as
>>> simple
>>> as skipping the value / double-spend validation of the blocks = that are
>>> zerocoin mining blocks. =A0Obviously zerocoin blocks can thems= elves 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 f= ork).
>>
>> Yeah, there's been a lot of doom and gloom about zerocoin that= is
>> frankly unwarrented. For instance people seem to think it's im= possible
>> to make a blockchain with zerocoin due to the long time it takes t= o
>> 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 it= s own
>> block, and have each transaction refer to the previous one in hist= ory.
>> (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 transac= tion.
>> Participants verify some subset of all transactions, and should th= ey
>> find fraud they broadcast a proof. Optionally, but highly recomend= ed,
>> make it profitable to find fraud, being careful to ensure that it&= #39;s
>> never profitable to create fraud then find it yourself.
>>
>> Anyway Bitcoin is limited to 7tx/s average so even without probaba= listic
>> verification it'd be perfectly acceptable to just limit transa= ctions 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 particip= ants
>> can stay anonymous.
>>
>> As you suggest creating zerocoins from provably sacrificing bitcoi= ns is
>> the correct approach. The consensus algorithm should be that you >> sacrifice zerocoins (specifically fractions there-of - note how I&= #39;m
>> assuming support for non-single-zerocoin amounts) and whatever cha= in 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 5= 1% 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 amo= unt
>> you could profit is the same as the total amount they would ration= ally
>> spend to stop you, and soon there will be collateral damage too >> increasing the amount third-parties are willing to sacrifice to st= op
>> 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 sacrif= ice to
>> be reused, but only for the exact same transaction it was original= ly
>> 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:
>>
>> =A0 =A0 OP_RETURN <prev-ztc-blockhash> <blockhash> <= ;ztc-created>
>>
>> Now even if you fail to publish your blocks, at least the whole wo= rld
>> 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 min= ers)
>>
>> 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 ev= en
>> *years* after they have been sacrificed)
>>
>> Turning zerocoins back into Bitcoins is just supply and demand: se= ll
>> 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 ab= out
>> cross-chain trading protocols, and I'll point out they are eas= ier to
>> implement if one chain has full visibility into what's happeni= ng on the
>> other; zerocoin is most likely to be implemented as an extension t= o the
>> bitcoin client itself.
>>
>> Finally if the transaction rate is too slow there's nothing wr= ong with
>> running multiple parallel zerocoin blockchains, although given the=
>> usecase of moving your funds through zerocoin for anonymity, and u= sing
>> the clean coins that come out the other side, there's no reaso= n to think
>> the zerocoin chain transaction rate needs to be especially high an= yway.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf >>
>
>
> --
> Jorge Tim=F3n
>
> http://freico.in/<= br> >


--
Jorge Tim=F3n

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/gam= pad/clk?id=3D48808831&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--
=

3D=PETER=A0VESSE= NES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 = =A0/=A0SKYPE:=A0vessenes=A0
900 Winslow Way East / SUITE 100 =A0/ =A0Bainbridge Island, WA 98110

--047d7b3a89c658005b04e168dbb0--