path: root/d7/6ff1dc656fbf5b45851615112154bb7e48fb87

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 <peter@coinlab.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAC1+kJN9G_OcX8+Vr6gLgM+KRNDzYtijjWxwmcA=yrKhU_fWkQ@mail.gmail.com>
References: <20130705140140.GA23949@netbook.cypherspace.org>
	<20130712131815.GA18716@petertodd.org>
	<CAC1+kJOerE75+rtMHiy27aDLwWC9juAYva4u_iMVihnePTOYig@mail.gmail.com>
	<CAC1+kJN9G_OcX8+Vr6gLgM+KRNDzYtijjWxwmcA=yrKhU_fWkQ@mail.gmail.com>
From: Peter Vessenes <peter@coinlab.com>
Date: Sat, 13 Jul 2013 11:32:39 -0700
Message-ID: <CAMGNxUtnYy0qtdRw3Pz2xV9xztEg317MRs0_mNMEWGE5oAxnig@mail.gmail.com>
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <jtimon@monetize.io> 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 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 <pete@petertodd.org> 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 <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 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

<div dir=3D"ltr">One very real issue for alt-currencies that don&#39;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.<div>

<br></div><div>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</div><div><br></div><div>Peter<=
/div>

<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Jul 13, 2013 at 2:53 AM, Jorge Tim=F3n <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jtimon@monetize.io" target=3D"_blank">jtimon@monetize.i=
o</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Sorry about that.<br>
Maybe more important, what&#39;s wrong with bitcoin and zerocoin being<br>
different currencies with an exchange rate completely decided by the<br>
market instead of trying to force 1:1 ???<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 7/13/13, Jorge Tim=F3n &lt;<a href=3D"mailto:jtimon@monetize.io">jtimon@=
monetize.io</a>&gt; wrote:<br>
&gt; I&#39;m not sure I understand the whole proposal, but it seems to me t=
hat<br>
&gt; having different characteristics, bitcoins and zerocoins would be<br>
&gt; different currencies.<br>
&gt; I don&#39;t see the need to peg zerocoins to bitcoins.<br>
&gt; It is great to have an anonymous p2p currency, maybe some bitcoin<br>
&gt; users that use bitcoin because of the transparency they allow (public<=
br>
&gt; funds expenditures could be more transparent than they have ever been)=
<br>
&gt; don&#39;t like this hard-fork. Well, maybe this is not the main reason=
,<br>
&gt; but I think this could be highly controversial.<br>
&gt; Maybe everybody likes it, but can you expand more on the<br>
&gt; justifications to peg the two currencies?<br>
&gt; If you&#39;re requiring one chain look at the othe for validations (mi=
ners<br>
&gt; will have to validate both to mine btc) you don&#39;t need the cross-c=
hain<br>
&gt; contract, you can do it better.<br>
&gt;<br>
&gt; Instead of doing this:<br>
&gt;<br>
&gt; <a href=3D"https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_acr=
oss_chains" target=3D"_blank">https://en.bitcoin.it/wiki/Contracts#Example_=
5:_Trading_across_chains</a><br>
&gt;<br>
&gt; You could do something like this:<br>
&gt;<br>
&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D31643.0" target=
=3D"_blank">https://bitcointalk.org/index.php?topic=3D31643.0</a><br>
&gt;<br>
&gt; This very idea has been proposed recently by othe people, but I can&#3=
9;t<br>
&gt; find where.<br>
&gt;<br>
&gt; The problem with this is of course scalabilty. Once you do it for what=
<br>
&gt; chain, why not the others?<br>
&gt; You can&#39;t validate 100 chains to mine bitcoin even if they&#39;re =
all<br>
&gt; merged mined: that&#39;s asking miners too much.<br>
&gt; If zerocoin enjoys this privilege why not, for example?<br>
&gt;<br>
&gt; As some of you may know, Mark Friedenbach and I are working on a<br>
&gt; protocol modification to support issuance of arbitrary assets. Would<b=
r>
&gt; be something like colored coins but better, we&#39;re calling it<br>
&gt; FreiMarkets. Of course these assets are not p2p like bitcoin or<br>
&gt; freicoin themselves: they have a centralized issuer.<br>
&gt; But if you allowed to sacrifice real bitcoins (as opposed to IOUs<br>
&gt; denominated in BTC like you have, for example, in ripple) so they<br>
&gt; appear in Freicoin&#39;s chain and turn them back, you could have p2p<=
br>
&gt; bitcoins inside Freicoin&#39;s chain.<br>
&gt; Maybe ripplers want that too. If FreiMarkets prove to work well on<br>
&gt; freicoin and be scalable enough, maybe a lot of scamcoins apply the<br=
>
&gt; hardfork too and they want to have p2p btc in their chain as well.<br>
&gt;<br>
&gt; Maybe I could have explained this without even mentioning FreiMarkets,=
<br>
&gt; but my point is that you&#39;re asking for a lot like it was nothing.<=
br>
&gt; Zerocoin-bitcoin fungibility hardfork is opening a little pandora&#39;=
s<br>
&gt; box. Are we ready?<br>
&gt;<br>
&gt; I was waiting for others to comment and I&#39;m surprised that no one =
else<br>
&gt; has made any objection yet. But if no one&#39;s going to point out the=
<br>
&gt; controvery that is so obvious to me, I feel almost like a<br>
&gt; responsability to act like a Devil&#39;s advocate here.<br>
&gt; So if you make bitcoin and zerocoin fungible, I want bitcoins to be<br=
>
&gt; transferrable to freicoin&#39;s chain. And I warn you there will be ma=
ny<br>
&gt; more people asking for the same thing on other chains. What criteria<b=
r>
&gt; will we have to say yes or no?<br>
&gt; More<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 7/12/13, Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@=
petertodd.org</a>&gt; wrote:<br>
&gt;&gt; On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote:<br>
&gt;&gt;&gt; Do people think that should work? =A0It seems to me it should =
with<br>
&gt;&gt;&gt; minimal,<br>
&gt;&gt;&gt; bitcoin changes. =A0I think the rule for either-or mining shou=
ld be as<br>
&gt;&gt;&gt; simple<br>
&gt;&gt;&gt; as skipping the value / double-spend validation of the blocks =
that are<br>
&gt;&gt;&gt; zerocoin mining blocks. =A0Obviously zerocoin blocks can thems=
elves end up<br>
&gt;&gt;&gt; on<br>
&gt;&gt;&gt; forks, that get resolved, but that fork resolution can perhaps=
 be<br>
&gt;&gt;&gt; shared?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; (Because the fork resolution is simply to accept the longest f=
ork).<br>
&gt;&gt;<br>
&gt;&gt; Yeah, there&#39;s been a lot of doom and gloom about zerocoin that=
 is<br>
&gt;&gt; frankly unwarrented. For instance people seem to think it&#39;s im=
possible<br>
&gt;&gt; to make a blockchain with zerocoin due to the long time it takes t=
o<br>
&gt;&gt; verify transactions, about 1.5 seconds, and never realize that<br>
&gt;&gt; verification can be parallelized.<br>
&gt;&gt;<br>
&gt;&gt; Anyway the way to do it is to get out of the model of large blocks=
 and<br>
&gt;&gt; think about individual transactions. Make each transaction into it=
s own<br>
&gt;&gt; block, and have each transaction refer to the previous one in hist=
ory.<br>
&gt;&gt; (zerocoin is inherently linear due to the anonymity)<br>
&gt;&gt;<br>
&gt;&gt; Verification does *not* need to be done by every node on every<br>
&gt;&gt; transaction. Make the act of creating a transaction cost something=
 and<br>
&gt;&gt; include the previous state of the accumulator as part of a transac=
tion.<br>
&gt;&gt; Participants verify some subset of all transactions, and should th=
ey<br>
&gt;&gt; find fraud they broadcast a proof. Optionally, but highly recomend=
ed,<br>
&gt;&gt; make it profitable to find fraud, being careful to ensure that it&=
#39;s<br>
&gt;&gt; never profitable to create fraud then find it yourself.<br>
&gt;&gt;<br>
&gt;&gt; Anyway Bitcoin is limited to 7tx/s average so even without probaba=
listic<br>
&gt;&gt; verification it&#39;d be perfectly acceptable to just limit transa=
ctions to<br>
&gt;&gt; one every few seconds provided you keep your &quot;blocksize&quot;=
 down to one<br>
&gt;&gt; transaction so the rate isn&#39;t bursty. You&#39;re going to want=
 to be<br>
&gt;&gt; cautious about bandwidth requirements anyway to make sure particip=
ants<br>
&gt;&gt; can stay anonymous.<br>
&gt;&gt;<br>
&gt;&gt; As you suggest creating zerocoins from provably sacrificing bitcoi=
ns is<br>
&gt;&gt; the correct approach. The consensus algorithm should be that you<b=
r>
&gt;&gt; sacrifice zerocoins (specifically fractions there-of - note how I&=
#39;m<br>
&gt;&gt; assuming support for non-single-zerocoin amounts) and whatever cha=
in has<br>
&gt;&gt; the highest total sacrifice wins. One way to think about<br>
&gt;&gt; proof-of-sacrifice is it&#39;s really proof-of-work, transferred. =
It also<br>
&gt;&gt; has the *big* advantage that to double-spend, or for that matter 5=
1% the<br>
&gt;&gt; chain, you have to outspend everyone with a stake in the viability=
 of<br>
&gt;&gt; the blockchain: they can sacrifice their zerocoins to combat you. =
In the<br>
&gt;&gt; case of a double-spend to rip off an online merchant the total amo=
unt<br>
&gt;&gt; you could profit is the same as the total amount they would ration=
ally<br>
&gt;&gt; spend to stop you, and soon there will be collateral damage too<br=
>
&gt;&gt; increasing the amount third-parties are willing to sacrifice to st=
op<br>
&gt;&gt; you. You can&#39;t win.<br>
&gt;&gt;<br>
&gt;&gt; Of course, this does mean that even unsuccesful sacrifices need to=
 be<br>
&gt;&gt; costly. You can make this acceptable to users by allowing a sacrif=
ice to<br>
&gt;&gt; be reused, but only for the exact same transaction it was original=
ly<br>
&gt;&gt; committed to.<br>
&gt;&gt;<br>
&gt;&gt; Sacrifices in this manner are *not* proof of stake. You really are=
<br>
&gt;&gt; giving up something by publishing the information that proves you =
made<br>
&gt;&gt; the sacrifice as that information can always be included in the<br=
>
&gt;&gt; consensus thereby taking away a limited resource. (your zerocoins)=
 It&#39;s<br>
&gt;&gt; more heavily dependent on jam-free networks, and doesn&#39;t play =
nice with<br>
&gt;&gt; SPV, but zero-knowledge proofs will may help the latter. (you&#39;=
ve got<br>
&gt;&gt; Bitcoin itself to act as a random beacon remember)<br>
&gt;&gt;<br>
&gt;&gt; Speaking of, another similar approach is to take advantage of how =
a<br>
&gt;&gt; Bitcoin sacrifice can be made publicly visible. Create a txout of =
some<br>
&gt;&gt; value like the following:<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 OP_RETURN &lt;prev-ztc-blockhash&gt; &lt;blockhash&gt; &lt=
;ztc-created&gt;<br>
&gt;&gt;<br>
&gt;&gt; Now even if you fail to publish your blocks, at least the whole wo=
rld<br>
&gt;&gt; knows how much they need to outspend to be sure you can&#39;t 51% =
attack the<br>
&gt;&gt; network. This approach and not-btc sacrifices can go hand in hand =
too,<br>
&gt;&gt; especially if nodes follow rules where they consider btc txout<br>
&gt;&gt; sacrifices as &quot;fixed&quot; and only subject to change by the =
bitcoin<br>
&gt;&gt; blockchain re-organizing. Advantages and disadvantages to both<br>
&gt;&gt; approaches. (remember that visible tx&#39;s can be censored by min=
ers)<br>
&gt;&gt;<br>
&gt;&gt; Sacrifice to mining fees may be acceptable in the future too, but =
only<br>
&gt;&gt; if OP_DEPTH is implemented so as to not give Bitcoin miners bad<br=
>
&gt;&gt; incentives. (the sacrificed coins should go to fees *months* or ev=
en<br>
&gt;&gt; *years* after they have been sacrificed)<br>
&gt;&gt;<br>
&gt;&gt; Turning zerocoins back into Bitcoins is just supply and demand: se=
ll<br>
&gt;&gt; them. You&#39;ll always lose a bit given by definition the maximum=
 exchange<br>
&gt;&gt; rate is 1:1, but anonymity may be worth it. Others have written ab=
out<br>
&gt;&gt; cross-chain trading protocols, and I&#39;ll point out they are eas=
ier to<br>
&gt;&gt; implement if one chain has full visibility into what&#39;s happeni=
ng on the<br>
&gt;&gt; other; zerocoin is most likely to be implemented as an extension t=
o the<br>
&gt;&gt; bitcoin client itself.<br>
&gt;&gt;<br>
&gt;&gt; Finally if the transaction rate is too slow there&#39;s nothing wr=
ong with<br>
&gt;&gt; running multiple parallel zerocoin blockchains, although given the=
<br>
&gt;&gt; usecase of moving your funds through zerocoin for anonymity, and u=
sing<br>
&gt;&gt; the clean coins that come out the other side, there&#39;s no reaso=
n to think<br>
&gt;&gt; the zerocoin chain transaction rate needs to be especially high an=
yway.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_b=
lank">petertodd.org</a><br>
&gt;&gt; 0000000000000013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf<b=
r>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Jorge Tim=F3n<br>
&gt;<br>
&gt; <a href=3D"http://freico.in/" target=3D"_blank">http://freico.in/</a><=
br>
&gt;<br>
<br>
<br>
--<br>
Jorge Tim=F3n<br>
<br>
<a href=3D"http://freico.in/" target=3D"_blank">http://freico.in/</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
See everything from the browser to the database with AppDynamics<br>
Get end-to-end visibility with application monitoring from AppDynamics<br>
Isolate bottlenecks and diagnose root cause in seconds.<br>
Start your free trial of AppDynamics Pro today!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48808831&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div dir=3D"ltr"><br><hr style=3D"font-family:Times;font-size:medium;border=
-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-s=
tyle:solid;border-top-color:rgb(204,204,204);margin:10px 0px">

<p style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1=
em"><span style=3D"color:rgb(50,90,135);text-transform:uppercase"><img src=
=3D"http://coinlab.com/static/images/email_logo.jpg" align=3D"right" alt=3D=
"CoinLab Logo" width=3D"130">PETER=A0<span style=3D"font-weight:bold">VESSE=
NES=A0</span><br>

<span style=3D"color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p><p=
 style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1em=
"><span style=3D"color:rgb(96,58,23);font-size:0.9em"><strong><a href=3D"ma=
ilto:peter@coinlab.com" style=3D"text-decoration:none;color:rgb(96,58,23)" =
target=3D"_blank">peter@coinlab.com</a>=A0</strong>=A0/=A0=A0206.486.6856 =
=A0/=A0<span style=3D"font-size:0.7em;text-transform:uppercase">SKYPE:</spa=
n>=A0vessenes=A0</span><br>

<span style=3D"color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase=
">900 Winslow Way East / SUITE 100 =A0/ =A0Bainbridge Island, WA 98110</spa=
n></p></div>
</div>

--047d7b3a89c658005b04e168dbb0--