public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
@ 2013-07-05 14:01 Adam Back
  2013-07-12 13:18 ` Peter Todd
  0 siblings, 1 reply; 22+ messages in thread
From: Adam Back @ 2013-07-05 14:01 UTC (permalink / raw)
  To: Bitcoin-Dev

Hi

I presume everyone saw the announce from Matthew Green & Ian Miers at JHU on
the release of libzerocoin: https://github.com/Zerocoin/libzerocoin

So now that raises the question of how can people experiment with real money
with zerocoin.  I think its fair to summarize there is resistance to merging
into bitcoin as it slows validation, bloats the blockchain, and also a
policy aspect it also imports cryptographic privacy into bitcoin.

On the forum thread on zerocoin math etc I suggested maybe people interested
to explore bitcoin could create an all-zerocoin alt-coin that is either-or
mined and p2p exchangeable for bitcoin.

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).

> what about making an all zerocoin based alt-coin (no bitcoins, nothing but
> zerocoins), that is either-or mined with bitcoin.  Then people can trade
> in and out of zerocoins by buying or selling them for bitcoin with an
> atomic transaction, probably p2p without some trusted exchange like mtgox.
> 
> Either-or mined (as distinct from merge-mined) I mean that each mined coin
> set is either a set of 25 bitcoins or a set of 25 zerocoins.  If its a
> zerocoin set its not a valid bitcoin set, and if its a bitcoin its not a
> valid zerocoin.  I'm not sure the zerocoins or bitcoins have to do much
> with mining events for the other network other than check they have the
> expected number of bits as they wont automatically know how to validate
> the other network.  Some miners may choose to validate both networks, but
> thats a choice for them.
> 
> In that way people can experiment with zerocoin, without bloating the
> block chain, complicating bitcoin, and without slowing validation on the
> bitcoin network.  And the two coins should have approximately the same
> cost (and maybe therefore value, though the price would be subject to
> demand/supply and any taint discount for bitcoins; zerocoins are taint
> free, or perfectly blended taint at least).

Adam



^ permalink raw reply	[flat|nested] 22+ messages in thread

• * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
    2013-07-05 14:01 [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining Adam Back
  @ 2013-07-12 13:18 ` Peter Todd
    2013-07-13  9:51   ` Jorge Timón
    0 siblings, 1 reply; 22+ messages in thread
  From: Peter Todd @ 2013-07-12 13:18 UTC (permalink / raw)
    To: Adam Back; +Cc: Bitcoin-Dev
  
  [-- Attachment #1: Type: text/plain, Size: 5477 bytes --]
  
  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
  
  [-- Attachment #2: Digital signature --]
  [-- Type: application/pgp-signature, Size: 198 bytes --]
  
  ^ permalink raw reply	[flat|nested] 22+ messages in thread

• • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
      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:42     ` Adam Back
      0 siblings, 2 replies; 22+ messages in thread
    From: Jorge Timón @ 2013-07-13  9:51 UTC (permalink / raw)
      To: Peter Todd; +Cc: Bitcoin-Dev
    
    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/
    
    
    
    ^ permalink raw reply	[flat|nested] 22+ messages in thread

  • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
        2013-07-13  9:51   ` Jorge Timón
      @ 2013-07-13  9:53     ` Jorge Timón
        2013-07-13 18:32       ` Peter Vessenes
        2013-07-13 18:42     ` Adam Back
        1 sibling, 1 reply; 22+ messages in thread
      From: Jorge Timón @ 2013-07-13  9:53 UTC (permalink / raw)
        To: Peter Todd; +Cc: Bitcoin-Dev
      
      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/
      
      
      
      ^ permalink raw reply	[flat|nested] 22+ messages in thread

    • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
          2013-07-13  9:53     ` Jorge Timón
        @ 2013-07-13 18:32       ` Peter Vessenes
          2013-07-15  9:51         ` Peter Todd
          0 siblings, 1 reply; 22+ messages in thread
        From: Peter Vessenes @ 2013-07-13 18:32 UTC (permalink / raw)
          To: Jorge Timón; +Cc: Bitcoin-Dev
        
        [-- 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 --]
        
        ^ permalink raw reply	[flat|nested] 22+ messages in thread

      • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
            2013-07-13 18:32       ` Peter Vessenes
          @ 2013-07-15  9:51         ` Peter Todd
            2013-07-15 13:05           ` Jorge Timón
            0 siblings, 1 reply; 22+ messages in thread
          From: Peter Todd @ 2013-07-15  9:51 UTC (permalink / raw)
            To: Peter Vessenes; +Cc: Bitcoin-Dev
          
          [-- Attachment #1: Type: text/plain, Size: 875 bytes --]
          
          On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote:
          > 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.
          
          Being able to have automated Bitcoin<->Zerocoin P2P trading without an
          exchange is also significantly more desirable from a privacy standpoint.
          Basically it reduces the privacy risks of doing the exchange to spending
          the Zerocoins in the first place.
          
          -- 
          'peter'[:-1]@petertodd.org
          00000000000000878c30a45104c48fd4e8037cb5b3ba1e14dc4d8bef72eff1be
          
          [-- Attachment #2: Digital signature --]
          [-- Type: application/pgp-signature, Size: 490 bytes --]
          
          ^ permalink raw reply	[flat|nested] 22+ messages in thread

        • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
              2013-07-15  9:51         ` Peter Todd
            @ 2013-07-15 13:05           ` Jorge Timón
              2013-07-15 20:29             ` Peter Todd
              0 siblings, 1 reply; 22+ messages in thread
            From: Jorge Timón @ 2013-07-15 13:05 UTC (permalink / raw)
              To: Peter Todd; +Cc: Bitcoin-Dev
            
            One way sacrifice (btc to zerocoin) is a non-issue since there's no
            modification required for bitcoin and you can't do anything to prevent
            it anyway.
            The controversial thing is sacrificing something outside bitcoin's
            chain and new btc appearing.
            
            On merged mining. It is true that "merged attacking" the other chain
            is free, but it is still more profitable to just follow the rules and
            mine the other coin!!
            If someone considers that something he can sell in a market for btc is
            "negative value"...well, he's just dammed stupid. Proof of work is
            designed for rational actors, if you stop assuming miners are more or
            less rational everything falls apart. It is possible that the "extra
            value" is too little for some miners to bother. But the extra costs of
            validating something else are so little compared to chance-hashing
            that miners not merged mining namecoin right now are just stupid
            (irrational agents). You can merged mine and sell for btc right away.
            
            On prime proof of work...for me it's interseting only because it's
            moving towards SCIP-based mining but that should be the goal. Like
            Mark said, "let's cure cancer" while mining. That would end all
            "mining is wasteful" arguments about this great security system. This
            would make Ripple's consensus mechanism less attractive. People
            talking about new scrypts harder to ASIC-mine when that's the elephant
            in the room...
            Sorry, I'm going off-topic.
            SCIP-based merged mining for the win.
            
            
            
            On 7/15/13, Peter Todd <pete@petertodd•org> wrote:
            > On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote:
            >> 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.
            >
            > Being able to have automated Bitcoin<->Zerocoin P2P trading without an
            > exchange is also significantly more desirable from a privacy standpoint.
            > Basically it reduces the privacy risks of doing the exchange to spending
            > the Zerocoins in the first place.
            >
            > --
            > 'peter'[:-1]@petertodd.org
            > 00000000000000878c30a45104c48fd4e8037cb5b3ba1e14dc4d8bef72eff1be
            >
            
            
            -- 
            Jorge Timón
            
            http://freico.in/
            
            
            
            ^ permalink raw reply	[flat|nested] 22+ messages in thread

          • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                2013-07-15 13:05           ` Jorge Timón
              @ 2013-07-15 20:29             ` Peter Todd
                2013-07-16  3:54               ` Peter Vessenes
                0 siblings, 1 reply; 22+ messages in thread
              From: Peter Todd @ 2013-07-15 20:29 UTC (permalink / raw)
                To: Jorge Timón; +Cc: Bitcoin-Dev
              
              [-- Attachment #1: Type: text/plain, Size: 2832 bytes --]
              
              On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote:
              > One way sacrifice (btc to zerocoin) is a non-issue since there's no
              > modification required for bitcoin and you can't do anything to prevent
              > it anyway.
              > The controversial thing is sacrificing something outside bitcoin's
              > chain and new btc appearing.
              
              Which is why I'm not proposing that.
              
              > On merged mining. It is true that "merged attacking" the other chain
              > is free, but it is still more profitable to just follow the rules and
              > mine the other coin!!
              > If someone considers that something he can sell in a market for btc is
              > "negative value"...well, he's just dammed stupid. Proof of work is
              > designed for rational actors, if you stop assuming miners are more or
              > less rational everything falls apart. It is possible that the "extra
              > value" is too little for some miners to bother. But the extra costs of
              > validating something else are so little compared to chance-hashing
              > that miners not merged mining namecoin right now are just stupid
              > (irrational agents). You can merged mine and sell for btc right away.
              
              You are assuming value is the same for everyone - it's not.
              
              If I mine in a jurisdiction where zerocoin is banned, and the blocks I
              mine are public, the value of zerocoin blocks to me are at best zero.
              Equally it would be easy for the local authorities to ask that I merge
              mine zerocoin blocks to attack the chain - it doesn't cost me anything
              so what's the harm? I may even choose to do so to preserve the value of
              the coins I can mine legally - alt-coins are competition.
              
              Incedentally keep in mind it is likely that in the future pools will not
              allow miners to modify the work units they receive in any way as a means
              of combating block-withholding fraud; there may not be very many people
              willing or able to honestly merge-mine any given chain.
              
              Proof-of-sacrifice can be done in a way that is opaque to the master
              blockchain by creating txouts that look no different from any other
              txout. Hopefully not required, but it would be a good strategy against
              censorship of sacrifice-based chains.
              
              > On prime proof of work...for me it's interseting only because it's
              > moving towards SCIP-based mining but that should be the goal. Like
              > Mark said, "let's cure cancer" while mining. That would end all
              > "mining is wasteful" arguments about this great security system. This
              > would make Ripple's consensus mechanism less attractive. People
              > talking about new scrypts harder to ASIC-mine when that's the elephant
              > in the room...
              > Sorry, I'm going off-topic.
              > SCIP-based merged mining for the win.
              
              SCIP is for now a dream. Give it a few more years and see how the
              technology shakes out.
              
              -- 
              'peter'[:-1]@petertodd.org
              00000000000000582cc323897a582e9368a5c3dfbcdcf73e78b261703e1bd1ba
              
              [-- Attachment #2: Digital signature --]
              [-- Type: application/pgp-signature, Size: 198 bytes --]
              
              ^ permalink raw reply	[flat|nested] 22+ messages in thread

            • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                  2013-07-15 20:29             ` Peter Todd
                @ 2013-07-16  3:54               ` Peter Vessenes
                  0 siblings, 0 replies; 22+ messages in thread
                From: Peter Vessenes @ 2013-07-16  3:54 UTC (permalink / raw)
                  To: Peter Todd; +Cc: Bitcoin-Dev
                
                [-- Attachment #1: Type: text/plain, Size: 3431 bytes --]
                
                I'm at the Aspen Institute right now talking about Bitcoin and I mentioned
                the perils of starting an alt-chain based on proof of work that pool
                operators might attack; funny synchronicity!
                
                Peter
                
                
                On Mon, Jul 15, 2013 at 2:29 PM, Peter Todd <pete@petertodd•org> wrote:
                
                > On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote:
                > > One way sacrifice (btc to zerocoin) is a non-issue since there's no
                > > modification required for bitcoin and you can't do anything to prevent
                > > it anyway.
                > > The controversial thing is sacrificing something outside bitcoin's
                > > chain and new btc appearing.
                >
                > Which is why I'm not proposing that.
                >
                > > On merged mining. It is true that "merged attacking" the other chain
                > > is free, but it is still more profitable to just follow the rules and
                > > mine the other coin!!
                > > If someone considers that something he can sell in a market for btc is
                > > "negative value"...well, he's just dammed stupid. Proof of work is
                > > designed for rational actors, if you stop assuming miners are more or
                > > less rational everything falls apart. It is possible that the "extra
                > > value" is too little for some miners to bother. But the extra costs of
                > > validating something else are so little compared to chance-hashing
                > > that miners not merged mining namecoin right now are just stupid
                > > (irrational agents). You can merged mine and sell for btc right away.
                >
                > You are assuming value is the same for everyone - it's not.
                >
                > If I mine in a jurisdiction where zerocoin is banned, and the blocks I
                > mine are public, the value of zerocoin blocks to me are at best zero.
                > Equally it would be easy for the local authorities to ask that I merge
                > mine zerocoin blocks to attack the chain - it doesn't cost me anything
                > so what's the harm? I may even choose to do so to preserve the value of
                > the coins I can mine legally - alt-coins are competition.
                >
                > Incedentally keep in mind it is likely that in the future pools will not
                > allow miners to modify the work units they receive in any way as a means
                > of combating block-withholding fraud; there may not be very many people
                > willing or able to honestly merge-mine any given chain.
                >
                > Proof-of-sacrifice can be done in a way that is opaque to the master
                > blockchain by creating txouts that look no different from any other
                > txout. Hopefully not required, but it would be a good strategy against
                > censorship of sacrifice-based chains.
                >
                > > On prime proof of work...for me it's interseting only because it's
                > > moving towards SCIP-based mining but that should be the goal. Like
                > > Mark said, "let's cure cancer" while mining. That would end all
                > > "mining is wasteful" arguments about this great security system. This
                > > would make Ripple's consensus mechanism less attractive. People
                > > talking about new scrypts harder to ASIC-mine when that's the elephant
                > > in the room...
                > > Sorry, I'm going off-topic.
                > > SCIP-based merged mining for the win.
                >
                > SCIP is for now a dream. Give it a few more years and see how the
                > technology shakes out.
                >
                > --
                > 'peter'[:-1]@petertodd.org
                > 00000000000000582cc323897a582e9368a5c3dfbcdcf73e78b261703e1bd1ba
                >
                
                
                
                -- 
                
                ------------------------------
                
                [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: 5181 bytes --]
                
                ^ permalink raw reply	[flat|nested] 22+ messages in thread

    • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
        2013-07-13  9:51   ` Jorge Timón
        2013-07-13  9:53     ` Jorge Timón
      @ 2013-07-13 18:42     ` Adam Back
        2013-07-14 11:18       ` Jorge Timón
        1 sibling, 1 reply; 22+ messages in thread
      From: Adam Back @ 2013-07-13 18:42 UTC (permalink / raw)
        To: Jorge Timón; +Cc: Bitcoin-Dev
      
      On Sat, Jul 13, 2013 at 11:51:14AM +0200, Jorge Timón wrote:
      >I don't see the need to peg zerocoins to bitcoins.
      
      Without a bitcoin peg on the creation cost of zerocoins, it is hard for a
      new alt-coin to have a stable value.  Bitcoin itself is volatile enough.
      
      Generally the available compute for mining is what it is, adding more
      alt-coins just dillutes the compute available for a given coin.  (Modulo
      different mining functions like scrypt vs hashcash there is some
      non-overlapping available compute because different hardware is more
      efficient, or even cost-effective at all).
      
      Merge mining is less desirable for the alt-coin - its mining is essentially
      free, on top of bitcoin mining.  Cost free is maybe a weaker starting point
      bootstrapping digital scarcity based market price.
      
      I think that serves to explain why bitcoin sacrifice as a mining method is a
      simple and stable cost starting point for an alt-coin.  
      
      >I think this could be highly controversial [alt-coin pegging].  Maybe
      >everybody likes it, but can you expand more on the justifications to peg
      >the two currencies?
      
      Bitcoin sacrifice related applications do not require code changes to
      bitcoin itself, which avoids the discussion about fairness of which alt-coin
      is supported, and about sacrifice-based pegging being added or not.
      
      I dont think it necessarily hurts investors in bitcoins as it just creates
      some deflation in the supply of bitcoin.
      
      >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.
      
      You can sacrifice bitcoins as a way to mine zerocoins without having the
      bitcoin network validate zerocoin.  For all bitcoin clients care the
      sacrifice could be useless.
      
      Bi-directional sacrifice is more tricky.  ie being allowed to re-create
      previously destroyed bitcoins, based on the sacrifice of zerocoin.  That
      would have other coin validation requirements.
      
      But I am not sure 1:1 is necessarily far from the right price - the price is
      arbitrary for a divisible token, so 1:1 is as good as any.  And the price
      equality depends on the extra functionality or value from the
      characteristics of the other coin.  The only thing I can see is zerocoin is
      more cpu expensive to validate, the coins are bigger, but provide more
      payment privacy (and so less taint).  Removing taint may mean that zercoins
      should be worth more.  However if any tainted bitcoins can be converted to
      zerocoin via sacrifice at 1:1, maybe the taint issue goes away - any coins
      that are tainted to the point of value-loss will be converted to zerocoin,
      and consequently the price to convert back should also be 1:1?
      
      >You could do something like this:
      >
      >https://bitcointalk.org/index.php?topic=31643.0
      
      p2p transfer is a good idea.
      
      Adam
      
      
      
      ^ permalink raw reply	[flat|nested] 22+ messages in thread

    • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
          2013-07-13 18:42     ` Adam Back
        @ 2013-07-14 11:18       ` Jorge Timón
          2013-07-14 19:22         ` John Dillon
          0 siblings, 1 reply; 22+ messages in thread
        From: Jorge Timón @ 2013-07-14 11:18 UTC (permalink / raw)
          To: Adam Back; +Cc: Bitcoin-Dev
        
        I was talking about bi-directional sacrifice.
        If zerocoin has it, I want the same on top of freicoin so that btc/frc
        can be traded p2p.
        Why zerocoin and not the 20 other altchains are going to ask for it?
        Ripplers will want it too, why not?
        
        All the arguments in favor of this pegging use zerocoin's point of
        view. Sure it would be much better for it, but are additional costs to
        the bitcoin network and you cannot do it with every chain.
        
        Merged mining is not mining the coin for free. The total reward (ie
        btc + frc + nmc + dvc) should tend to equal the mining costs. But the
        value comes from demand, not costs. So if people demand it more it
        price will rise no matter how is mined. And if the price rises it will
        make sense to spend more on mining.
        "Bitcoins are worth because it costs to mine them" is a Marxian labor
        thory of value argument.
        It's the other way arround as Menger taught us.
        
        
        On 7/13/13, Adam Back <adam@cypherspace•org> wrote:
        > On Sat, Jul 13, 2013 at 11:51:14AM +0200, Jorge Timón wrote:
        >>I don't see the need to peg zerocoins to bitcoins.
        >
        > Without a bitcoin peg on the creation cost of zerocoins, it is hard for a
        > new alt-coin to have a stable value.  Bitcoin itself is volatile enough.
        >
        > Generally the available compute for mining is what it is, adding more
        > alt-coins just dillutes the compute available for a given coin.  (Modulo
        > different mining functions like scrypt vs hashcash there is some
        > non-overlapping available compute because different hardware is more
        > efficient, or even cost-effective at all).
        >
        > Merge mining is less desirable for the alt-coin - its mining is essentially
        > free, on top of bitcoin mining.  Cost free is maybe a weaker starting point
        > bootstrapping digital scarcity based market price.
        >
        > I think that serves to explain why bitcoin sacrifice as a mining method is
        > a
        > simple and stable cost starting point for an alt-coin.
        >
        >>I think this could be highly controversial [alt-coin pegging].  Maybe
        >>everybody likes it, but can you expand more on the justifications to peg
        >>the two currencies?
        >
        > Bitcoin sacrifice related applications do not require code changes to
        > bitcoin itself, which avoids the discussion about fairness of which
        > alt-coin
        > is supported, and about sacrifice-based pegging being added or not.
        >
        > I dont think it necessarily hurts investors in bitcoins as it just creates
        > some deflation in the supply of bitcoin.
        >
        >>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.
        >
        > You can sacrifice bitcoins as a way to mine zerocoins without having the
        > bitcoin network validate zerocoin.  For all bitcoin clients care the
        > sacrifice could be useless.
        >
        > Bi-directional sacrifice is more tricky.  ie being allowed to re-create
        > previously destroyed bitcoins, based on the sacrifice of zerocoin.  That
        > would have other coin validation requirements.
        >
        > But I am not sure 1:1 is necessarily far from the right price - the price
        > is
        > arbitrary for a divisible token, so 1:1 is as good as any.  And the price
        > equality depends on the extra functionality or value from the
        > characteristics of the other coin.  The only thing I can see is zerocoin is
        > more cpu expensive to validate, the coins are bigger, but provide more
        > payment privacy (and so less taint).  Removing taint may mean that zercoins
        > should be worth more.  However if any tainted bitcoins can be converted to
        > zerocoin via sacrifice at 1:1, maybe the taint issue goes away - any coins
        > that are tainted to the point of value-loss will be converted to zerocoin,
        > and consequently the price to convert back should also be 1:1?
        >
        >>You could do something like this:
        >>
        >>https://bitcointalk.org/index.php?topic=31643.0
        >
        > p2p transfer is a good idea.
        >
        > Adam
        >
        
        
        -- 
        Jorge Timón
        
        http://freico.in/
        
        
        
        ^ permalink raw reply	[flat|nested] 22+ messages in thread

      • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
            2013-07-14 11:18       ` Jorge Timón
          @ 2013-07-14 19:22         ` John Dillon
            2013-07-14 19:33           ` Luke-Jr
                                       ` (2 more replies)
            0 siblings, 3 replies; 22+ messages in thread
          From: John Dillon @ 2013-07-14 19:22 UTC (permalink / raw)
            To: Jorge Timón; +Cc: Bitcoin-Dev
          
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA256
          
          On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón <jtimon@monetize•io> wrote:
          > All the arguments in favor of this pegging use zerocoin's point of
          > view. Sure it would be much better for it, but are additional costs to
          > the bitcoin network and you cannot do it with every chain.
          
          Seems that Peter is describing a system that requires no changes at all to the
          Bitcoin codebase and thus there are no costs whatsoever.
          
          Peter: I'm a bit confused by this concept of "bi-directional sacrifice" though,
          I assume there exists only a sacrifice in one direction right? Wouldn't selling
          a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx
          moving it to the new owner only happens if a specific form of bitcoin tx
          happens too?
          
          > Merged mining is not mining the coin for free. The total reward (ie
          > btc + frc + nmc + dvc) should tend to equal the mining costs. But the
          > value comes from demand, not costs. So if people demand it more it
          > price will rise no matter how is mined. And if the price rises it will
          > make sense to spend more on mining.
          > "Bitcoins are worth because it costs to mine them" is a Marxian labor
          > thory of value argument.
          > It's the other way arround as Menger taught us.
          
          Merge mining is very much mining a coin for free. Ask not what the total reward
          is, ask that the marginal cost of merge mining an additional coin is. The issue
          is that unless there is a cost to mining a *invalid* block the merge mined coin
          has little protection from miners who mine invalid blocks, either maliciously
          or through negligence. If the coin isn't worth much, either because it's market
          value is low or the worth is negative to the malicious miner, your theories of
          value have nothing to do with the issue.
          
          Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC
          channel and on bitcointalk as well if memory serves. I advise you to look up
          his description of the problem, almost everything he writes on the topic of
          crypto-coin theory is spot-on correct.
          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.4.11 (GNU/Linux)
          
          iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts
          juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY
          HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915
          SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ
          vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj
          MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ=
          =b40P
          -----END PGP SIGNATURE-----
          
          
          
          ^ permalink raw reply	[flat|nested] 22+ messages in thread

        • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
              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:48             ` John Dillon
              2013-07-15  0:14           ` Adam Back
              2013-07-15  0:29           ` Peter Todd
              2 siblings, 2 replies; 22+ messages in thread
            From: Luke-Jr @ 2013-07-14 19:33 UTC (permalink / raw)
              To: bitcoin-development; +Cc: Jorge
            
            [-- Attachment #1: Type: Text/Plain, Size: 1871 bytes --]
            
            On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote:
            > > Merged mining is not mining the coin for free. The total reward (ie
            > > btc + frc + nmc + dvc) should tend to equal the mining costs. But the
            > > value comes from demand, not costs. So if people demand it more it
            > > price will rise no matter how is mined. And if the price rises it will
            > > make sense to spend more on mining.
            > 
            > Merge mining is very much mining a coin for free. Ask not what the total
            > reward is, ask that the marginal cost of merge mining an additional coin
            > is.
            
            But the total reward is what mining will tend toward equalizing in costs.
            In any case, the cryptocurrencies are neutral to cost of mining, or perhaps 
            even benefit from it being as cheap as possible: if it's cheaper to mine, you 
            can get an even higher difficulty/security out of it.
            
            > The issue is that unless there is a cost to mining a *invalid* block
            > the merge mined coin has little protection from miners who mine invalid
            > blocks, either maliciously or through negligence. If the coin isn't worth
            > much, either because it's market value is low or the worth is negative to
            > the malicious miner, your theories of value have nothing to do with the
            > issue.
            
            Invalid blocks are rejected by validating clients in all circumstances.
            
            I suspect you may mean a block that doesn't include transactions you want 
            confirmed. In that case, you must not be paying sufficient fees for the miner 
            to consider it worth their time, or must be doing something the miner 
            considers fundamentally objectionable (in which case they won't be satisfied 
            by any fee). But these miners, unless they are able to acquire over 50% of the 
            hashrate (in which case the cryptocoin is compromised), are not the only ones 
            mining blocks, and if another miner accepts your transactions there is no 
            issue.
            
            Luke
            
            [-- Attachment #2: This is a digitally signed message part. --]
            [-- Type: application/pgp-signature, Size: 1530 bytes --]
            
            ^ permalink raw reply	[flat|nested] 22+ messages in thread

          • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                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-14 19:48             ` John Dillon
                1 sibling, 2 replies; 22+ messages in thread
              From: Pieter Wuille @ 2013-07-14 19:42 UTC (permalink / raw)
                To: Luke-Jr; +Cc: bitcoin-development, Jorge
              
              On Sun, Jul 14, 2013 at 07:33:06PM +0000, Luke-Jr wrote:
              > > The issue is that unless there is a cost to mining a *invalid* block
              > > the merge mined coin has little protection from miners who mine invalid
              > > blocks, either maliciously or through negligence. If the coin isn't worth
              > > much, either because it's market value is low or the worth is negative to
              > > the malicious miner, your theories of value have nothing to do with the
              > > issue.
              > 
              > Invalid blocks are rejected by validating clients in all circumstances.
              
              I don't think that's what John means.
              
              If you have hash power for the parent chain, mining invalid blocks for the
              merge-mined chain costs you nothing. Yes, they will be invalid, but you've
              lost nothing.
              
              The basic assumption underlying mining security is that it is more profitable
              to collaborate with mining a chain (and profit from the block payout) than to
              attack it. In the case of merged mining, this assumption is not valid.
              
              -- 
              Pieter
              
              
              
              
              ^ permalink raw reply	[flat|nested] 22+ messages in thread

            • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                  2013-07-14 19:42             ` Pieter Wuille
                @ 2013-07-14 19:52               ` John Dillon
                  2013-07-14 20:16               ` Luke-Jr
                  1 sibling, 0 replies; 22+ messages in thread
                From: John Dillon @ 2013-07-14 19:52 UTC (permalink / raw)
                  To: Pieter Wuille; +Cc: Bitcoin Dev, Jorge
                
                -----BEGIN PGP SIGNED MESSAGE-----
                Hash: SHA256
                
                On Sun, Jul 14, 2013 at 7:42 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
                > On Sun, Jul 14, 2013 at 07:33:06PM +0000, Luke-Jr wrote:
                >> Invalid blocks are rejected by validating clients in all circumstances.
                >
                > I don't think that's what John means.
                >
                > If you have hash power for the parent chain, mining invalid blocks for the
                > merge-mined chain costs you nothing. Yes, they will be invalid, but you've
                > lost nothing.
                >
                > The basic assumption underlying mining security is that it is more profitable
                > to collaborate with mining a chain (and profit from the block payout) than to
                > attack it. In the case of merged mining, this assumption is not valid.
                
                You said it better than I did.
                
                Essentially I am worried about the chain being strangled at birth, merge-mining
                makes doing so cost nothing for the attacker. With zerocoin this is a
                particularly dangerous possibility due to those in the Bitcoin community who
                would like to see Bitcoin continue to have poor privacy properties.
                -----BEGIN PGP SIGNATURE-----
                Version: GnuPG v1.4.11 (GNU/Linux)
                
                iQEcBAEBCAAGBQJR4wF9AAoJEEWCsU4mNhiPtCgH/3QLvFer3QHNU7AP+nehwcgK
                QS3xLv60lvm+pYLVAp9xFyJ5SCHVGTPvWRBmoldk8xxh9ORHlNEsnrcx9ZONTJ4F
                ja4Alp9MLZK5S8dKk2juJNdKziyRkQci/nNwuqepX5JjCIRNZq1lcW4Be4W7InPt
                Ltrvp7lA03uNuAXxtlYnko4mEY5l1NiBp4BvhGZ6+GRdCltPeIk2m0NwLDHWd31t
                qFLnnPSw0/9FGVs7lOaWuxbMGwPzGrIu6TXm17dqgBsl+8JuP6zHFE1ccqIxKyb6
                Tdf4yNvhsvE+qlTnmcQNxM9nMHL4uqBZqJR174fAKQzcNGzVLloqbmRqKzuw5o4=
                =leUJ
                -----END PGP SIGNATURE-----
                
                
                
                ^ permalink raw reply	[flat|nested] 22+ messages in thread

              • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                  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
                  1 sibling, 1 reply; 22+ messages in thread
                From: Luke-Jr @ 2013-07-14 20:16 UTC (permalink / raw)
                  To: Pieter Wuille; +Cc: bitcoin-development, Jorge
                
                [-- Attachment #1: Type: Text/Plain, Size: 1969 bytes --]
                
                On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote:
                > On Sun, Jul 14, 2013 at 07:33:06PM +0000, Luke-Jr wrote:
                > > > The issue is that unless there is a cost to mining a *invalid* block
                > > > the merge mined coin has little protection from miners who mine invalid
                > > > blocks, either maliciously or through negligence. If the coin isn't
                > > > worth much, either because it's market value is low or the worth is
                > > > negative to the malicious miner, your theories of value have nothing
                > > > to do with the issue.
                > > 
                > > Invalid blocks are rejected by validating clients in all circumstances.
                > 
                > I don't think that's what John means.
                > 
                > If you have hash power for the parent chain, mining invalid blocks for the
                > merge-mined chain costs you nothing. Yes, they will be invalid, but you've
                > lost nothing.
                
                Nor gained anything. So the "lesser" chain maybe can't trust SPV.
                But trusting SPV was already a bad idea anyway.
                
                Note that the parent chain is not in any privileged position here either: a 
                merged-mined chain could provide the value to the miner he is interested in, 
                while he sees nothing of the parent chain. In short, merged mining is pretty 
                much unavoidable in any case.
                
                > The basic assumption underlying mining security is that it is more
                > profitable to collaborate with mining a chain (and profit from the block
                > payout) than to attack it. In the case of merged mining, this assumption
                > is not valid.
                
                The basic assumption of SPV is that more people will be assisting rather than 
                making invalid blocks. That motive doesn't necessarily need to be economic, 
                nor do proper validating clients rely on it. The only real assumption behind 
                mining is that the majority will not be aiming to reverse transactions with 
                valid blocks.
                
                P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as 
                (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic 
                idea as well ;)
                
                [-- Attachment #2: This is a digitally signed message part. --]
                [-- Type: application/pgp-signature, Size: 1530 bytes --]
                
                ^ permalink raw reply	[flat|nested] 22+ messages in thread

              • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                    2013-07-14 20:16               ` Luke-Jr
                  @ 2013-07-15  0:12                 ` Peter Todd
                    2013-07-15  1:51                   ` Luke-Jr
                    0 siblings, 1 reply; 22+ messages in thread
                  From: Peter Todd @ 2013-07-15  0:12 UTC (permalink / raw)
                    To: Luke-Jr; +Cc: bitcoin-development, Jorge
                  
                  [-- Attachment #1: Type: text/plain, Size: 433 bytes --]
                  
                  On Sun, Jul 14, 2013 at 08:16:41PM +0000, Luke-Jr wrote:
                  > P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as 
                  > (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic 
                  > idea as well ;)
                  
                  Your ideas about making an alt-coin have anything to do with hashing
                  power might be a lot more convincing if you hadn't 51% attacks alt-coins
                  in the past.
                  
                  -- 
                  'peter'[:-1]@petertodd.org
                  
                  [-- Attachment #2: Digital signature --]
                  [-- Type: application/pgp-signature, Size: 490 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 22+ messages in thread

                • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                      2013-07-15  0:12                 ` Peter Todd
                    @ 2013-07-15  1:51                   ` Luke-Jr
                      2013-07-15  1:59                     ` Peter Todd
                      0 siblings, 1 reply; 22+ messages in thread
                    From: Luke-Jr @ 2013-07-15  1:51 UTC (permalink / raw)
                      To: Peter Todd; +Cc: bitcoin-development, Jorge
                    
                    On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
                    > On Sun, Jul 14, 2013 at 08:16:41PM +0000, Luke-Jr wrote:
                    > > P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
                    > > well as (rewarded) Prime POW; maybe with no subsidy halving, to try a
                    > > new economic idea as well ;)
                    > 
                    > Your ideas about making an alt-coin have anything to do with hashing
                    > power might be a lot more convincing if you hadn't 51% attacks alt-coins
                    > in the past.
                    
                    Slander like this does not belong on the dev ML.
                    
                    
                    
                    ^ permalink raw reply	[flat|nested] 22+ messages in thread

                  • • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                        2013-07-15  1:51                   ` Luke-Jr
                      @ 2013-07-15  1:59                     ` Peter Todd
                        0 siblings, 0 replies; 22+ messages in thread
                      From: Peter Todd @ 2013-07-15  1:59 UTC (permalink / raw)
                        To: Luke-Jr; +Cc: bitcoin-development, Jorge
                      
                      [-- Attachment #1: Type: text/plain, Size: 725 bytes --]
                      
                      On Mon, Jul 15, 2013 at 01:51:21AM +0000, Luke-Jr wrote:
                      > On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
                      > > On Sun, Jul 14, 2013 at 08:16:41PM +0000, Luke-Jr wrote:
                      > > > P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
                      > > > well as (rewarded) Prime POW; maybe with no subsidy halving, to try a
                      > > > new economic idea as well ;)
                      > > 
                      > > Your ideas about making an alt-coin have anything to do with hashing
                      > > power might be a lot more convincing if you hadn't 51% attacks alt-coins
                      > > in the past.
                      > 
                      > Slander like this does not belong on the dev ML.
                      
                      I wasn't aware you denied that accusation, so my apologies; I retract
                      that statement.
                      
                      -- 
                      'peter'[:-1]@petertodd.org
                      
                      [-- Attachment #2: Digital signature --]
                      [-- Type: application/pgp-signature, Size: 490 bytes --]
                      
                      ^ permalink raw reply	[flat|nested] 22+ messages in thread

            • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
                2013-07-14 19:33           ` Luke-Jr
                2013-07-14 19:42             ` Pieter Wuille
              @ 2013-07-14 19:48             ` John Dillon
                1 sibling, 0 replies; 22+ messages in thread
              From: John Dillon @ 2013-07-14 19:48 UTC (permalink / raw)
                To: Luke-Jr; +Cc: Bitcoin Dev
              
              -----BEGIN PGP SIGNED MESSAGE-----
              Hash: SHA256
              
              On Sun, Jul 14, 2013 at 7:33 PM, Luke-Jr <luke@dashjr•org> wrote:
              >> Merge mining is very much mining a coin for free. Ask not what the total
              >> reward is, ask that the marginal cost of merge mining an additional coin
              >> is.
              >
              > But the total reward is what mining will tend toward equalizing in costs.
              > In any case, the cryptocurrencies are neutral to cost of mining, or perhaps
              > even benefit from it being as cheap as possible: if it's cheaper to mine, you
              > can get an even higher difficulty/security out of it.
              
              Again, you forget that there may exist miners for which the value of the coin
              is negative.
              
              Never mind that in practice you want there to exist a cost to encourage miners
              to actually pay attention to what they mind and to encourage them to update
              software when required and participate.
              
              >> The issue is that unless there is a cost to mining a *invalid* block
              >> the merge mined coin has little protection from miners who mine invalid
              >> blocks, either maliciously or through negligence. If the coin isn't worth
              >> much, either because it's market value is low or the worth is negative to
              >> the malicious miner, your theories of value have nothing to do with the
              >> issue.
              >
              > Invalid blocks are rejected by validating clients in all circumstances.
              
              Validating clients, not SPV clients.
              
              > I suspect you may mean a block that doesn't include transactions you want
              > confirmed. In that case, you must not be paying sufficient fees for the miner
              > to consider it worth their time, or must be doing something the miner
              > considers fundamentally objectionable (in which case they won't be satisfied
              > by any fee). But these miners, unless they are able to acquire over 50% of the
              > hashrate (in which case the cryptocoin is compromised), are not the only ones
              > mining blocks, and if another miner accepts your transactions there is no
              > issue.
              
              All those things simply change the amount of alt-coin the miner gets, which to
              the miner may have no reward. You also have the issue that we may be talking
              about a non-currency chain where reward is more nebulous.
              
              In any case, regarding a zerocoin chain, Peter's observation that
              proof-of-sacrifice allows a strong 51% attck defense is very clever and IMO is
              significantly stronger than proof-of-work mining, merged or not, would provide.
              It's essentially the ability to conjur up mining capacity on demand, but only
              by those who have a stake in the crypto-coin. It does depend on the existance
              of a proof-of-work chain, but we have a perfectly good one handy.
              
              PS: good to see you signing you email!
              -----BEGIN PGP SIGNATURE-----
              Version: GnuPG v1.4.11 (GNU/Linux)
              
              iQEcBAEBCAAGBQJR4wCFAAoJEEWCsU4mNhiPIcwH+gLYbUPDi/7ITK02wftqEV2E
              FSlzZ0W8aw7z7sF7hqPm7jpmtqbXdvQRSSy+XRDgWUxvF72o5oRTwOpY7xN8KOct
              9rMwF35nld8An9FOjOB6NR3sIQxmAg9q7xoilZrOHyRFcz/UT0BexSZ3x5DrKIAB
              6S7qalrGT0NWZx8CI0PRAzY8Nx+WouaoofBaypRaXBVJxigFqJlWNxgUM1FuoCL+
              C1wn0hlbWfO42Mh9jdnFZXhH2Omd5V3PzIS/t2cJGTjrwr7nT6VAJu+0hbNZHI/q
              yg0TGbO/01pp4OVe7WdLz9OktMqqDdDZJd6HWLQk07zqHS3iRJ2cpRIO6k9UCk0=
              =oicX
              -----END PGP SIGNATURE-----
              
              
              
              ^ permalink raw reply	[flat|nested] 22+ messages in thread

          • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
              2013-07-14 19:22         ` John Dillon
              2013-07-14 19:33           ` Luke-Jr
            @ 2013-07-15  0:14           ` Adam Back
              2013-07-15  0:29           ` Peter Todd
              2 siblings, 0 replies; 22+ messages in thread
            From: Adam Back @ 2013-07-15  0:14 UTC (permalink / raw)
              To: John Dillon; +Cc: Bitcoin-Dev
            
            I think bi-directional sacrifice is probably not needed to assure a close to
            1:1 bi-directional peg.
            
            (Bi-directional sacrifice meaning also to convert a zerocoin to a bitcoin
            you sacrifice a zerocoin and bitcoin would be modified to accept a zerocoin
            sacrifice as a way to replace a previously sacrificed bitcoin).
            
            I say that because if users who want zerocoins can obtain them at 1:1
            exchange via sacrifice (a mathematical peg), it is of no additional cost to
            them to instead buy them from someone who previously obtained them via
            sacrifice for bitcoin (rather than sacrificing a new bitcoin).  So
            presumably for goodwill, or nominal fee (a small discount), people would buy
            rather than sacrifice where there is availability.
            
            Adam
            
            On Sun, Jul 14, 2013 at 07:22:10PM +0000, John Dillon wrote:
            >-----BEGIN PGP SIGNED MESSAGE-----
            >Hash: SHA256
            >
            >On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón <jtimon@monetize•io> wrote:
            >> All the arguments in favor of this pegging use zerocoin's point of
            >> view. Sure it would be much better for it, but are additional costs to
            >> the bitcoin network and you cannot do it with every chain.
            >
            >Seems that Peter is describing a system that requires no changes at all to the
            >Bitcoin codebase and thus there are no costs whatsoever.
            >
            >Peter: I'm a bit confused by this concept of "bi-directional sacrifice" though,
            >I assume there exists only a sacrifice in one direction right? Wouldn't selling
            >a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx
            >moving it to the new owner only happens if a specific form of bitcoin tx
            >happens too?
            >
            >> Merged mining is not mining the coin for free. The total reward (ie
            >> btc + frc + nmc + dvc) should tend to equal the mining costs. But the
            >> value comes from demand, not costs. So if people demand it more it
            >> price will rise no matter how is mined. And if the price rises it will
            >> make sense to spend more on mining.
            >> "Bitcoins are worth because it costs to mine them" is a Marxian labor
            >> thory of value argument.
            >> It's the other way arround as Menger taught us.
            >
            >Merge mining is very much mining a coin for free. Ask not what the total reward
            >is, ask that the marginal cost of merge mining an additional coin is. The issue
            >is that unless there is a cost to mining a *invalid* block the merge mined coin
            >has little protection from miners who mine invalid blocks, either maliciously
            >or through negligence. If the coin isn't worth much, either because it's market
            >value is low or the worth is negative to the malicious miner, your theories of
            >value have nothing to do with the issue.
            >
            >Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC
            >channel and on bitcointalk as well if memory serves. I advise you to look up
            >his description of the problem, almost everything he writes on the topic of
            >crypto-coin theory is spot-on correct.
            >-----BEGIN PGP SIGNATURE-----
            >Version: GnuPG v1.4.11 (GNU/Linux)
            >
            >iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts
            >juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY
            >HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915
            >SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ
            >vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj
            >MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ=
            >=b40P
            >-----END PGP SIGNATURE-----
            
            
            
            ^ permalink raw reply	[flat|nested] 22+ messages in thread

          • * Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
              2013-07-14 19:22         ` John Dillon
              2013-07-14 19:33           ` Luke-Jr
              2013-07-15  0:14           ` Adam Back
            @ 2013-07-15  0:29           ` Peter Todd
              2 siblings, 0 replies; 22+ messages in thread
            From: Peter Todd @ 2013-07-15  0:29 UTC (permalink / raw)
              To: John Dillon; +Cc: Bitcoin-Dev
            
            [-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
            
            On Sun, Jul 14, 2013 at 07:22:10PM +0000, John Dillon wrote:
            > Peter: I'm a bit confused by this concept of "bi-directional sacrifice" though,
            > I assume there exists only a sacrifice in one direction right? Wouldn't selling
            > a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx
            > moving it to the new owner only happens if a specific form of bitcoin tx
            > happens too?
            
            Exactly.
            
            Basically you have one way of creating a Zerocoin: prove you sacrificed
            a Bitcoin in a specific way. (spend to unspendable, or spend to mining
            fees far into the future)
            
            Now when you sell a Zerocoin what you do is create a Zerocoin
            transaction with a txout that can only be spent if you can prove that a
            Bitcoin transaction exists with specific conditions with sufficient
            confirmations. The specific condition would most likely be it has a
            txout of a specific value and scriptPubKey. Basically you'd have a
            two-part scriptPubKey:
            
            if <check bitcoin txout existance proof> <check zerocoin buyers signature
            is correct> else <check zerocoin sellers signature is correct> <check n
            blocks have passed>
            
            Note how if the buyer screws up there is a fallback so the seller can
            retrieve their funds after some reasonable amount of time.
            
            Of course if the Bitcoin chain is re-orged Bad Things Happen(TM), but
            just set the required number of confirms to something reasonable and
            you're good to go. It does mean Zerocoin needs to have consensus on the
            Bitcoin blockchain, but that's required to verify sacrifice proofs
            anyway.
            
            Economically the idea works because Zerocoins are gradually consumed by
            the proof-of-sacrifice required to make Zerocoin transactions. If the
            process by which Bitcoins are sacrificed is to fees, rather than
            permanently, the overall affect is just a minor decrease in the Bitcoin
            money supply. If they are sacrificed permanently, it'll result in
            long-term Bitcoin deflation - potentially an issue as the blockreward
            decreases.
            
            -- 
            'peter'[:-1]@petertodd.org
            
            [-- Attachment #2: Digital signature --]
            [-- Type: application/pgp-signature, Size: 490 bytes --]
            
            ^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2013-07-16  4:22 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-05 14:01 [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining 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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox