From: Peter Vessenes <peter@coinlab•com>
To: "Jorge Timón" <jtimon@monetize•io>
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
Date: Sat, 13 Jul 2013 11:32:39 -0700 [thread overview]
Message-ID: <CAMGNxUtnYy0qtdRw3Pz2xV9xztEg317MRs0_mNMEWGE5oAxnig@mail.gmail.com> (raw)
In-Reply-To: <CAC1+kJN9G_OcX8+Vr6gLgM+KRNDzYtijjWxwmcA=yrKhU_fWkQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10893 bytes --]
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ón <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ón <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=31643.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
> 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 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ón
> >
> > http://freico.in/
> >
>
>
> --
> Jorge Timón
>
> 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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter@coinlab•com * / 206.486.6856 / SKYPE: vessenes
900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110
[-- Attachment #2: Type: text/html, Size: 14394 bytes --]
next prev parent reply other threads:[~2013-07-13 19:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 14:01 Adam Back
2013-07-12 13:18 ` Peter Todd
2013-07-13 9:51 ` Jorge Timón
2013-07-13 9:53 ` Jorge Timón
2013-07-13 18:32 ` Peter Vessenes [this message]
2013-07-15 9:51 ` Peter Todd
2013-07-15 13:05 ` Jorge Timón
2013-07-15 20:29 ` Peter Todd
2013-07-16 3:54 ` Peter Vessenes
2013-07-13 18:42 ` Adam Back
2013-07-14 11:18 ` Jorge Timón
2013-07-14 19:22 ` John Dillon
2013-07-14 19:33 ` Luke-Jr
2013-07-14 19:42 ` Pieter Wuille
2013-07-14 19:52 ` John Dillon
2013-07-14 20:16 ` Luke-Jr
2013-07-15 0:12 ` Peter Todd
2013-07-15 1:51 ` Luke-Jr
2013-07-15 1:59 ` Peter Todd
2013-07-14 19:48 ` John Dillon
2013-07-15 0:14 ` Adam Back
2013-07-15 0:29 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMGNxUtnYy0qtdRw3Pz2xV9xztEg317MRs0_mNMEWGE5oAxnig@mail.gmail.com \
--to=peter@coinlab$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jtimon@monetize$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox