path: root/4d/9ddcf47f77d2349fd0762909af28b5f9cd8a77

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 <jtimon@monetize.io>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAC1+kJOerE75+rtMHiy27aDLwWC9juAYva4u_iMVihnePTOYig@mail.gmail.com>
References: <20130705140140.GA23949@netbook.cypherspace.org>
	<20130712131815.GA18716@petertodd.org>
	<CAC1+kJOerE75+rtMHiy27aDLwWC9juAYva4u_iMVihnePTOYig@mail.gmail.com>
Date: Sat, 13 Jul 2013 11:53:44 +0200
Message-ID: <CAC1+kJN9G_OcX8+Vr6gLgM+KRNDzYtijjWxwmcA=yrKhU_fWkQ@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
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 <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 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 <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 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 <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 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/