* [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 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: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: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-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
* 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-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
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