If you havent already taken a look at the Confidence Chains proposal, I suggest you do. It solves most of these issues in a very simple way.
https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/preview?pli=1
Topic: merged mining vs side-chains (another kind of merged mining) (Read 6946 times)
Don't CampBX and Mpex support short selling already?
I don't know, but MPex at least is almost certainly illegal.
Is it more profitable using merged mining?
Don't CampBX and Mpex support short selling already?
OTOH, short selling requires credit, thus trust, something hard to come by in black markets.
OTOH, short selling requires credit, thus trust, something hard to come by in black markets.
You could also effectively short a merge-mined system - in a trust-free decentralized manner - by using oracle betting like the system alp is working on.
"I bet Namecoin will have a hash rate of X on date Y"
Quote
We start with an assumption that there exist a financial market which allows one to profit when a price of a certain currency drops.
Recall that short selling is tightly regulated, for that exact reason. If such a market did exist, it'd probably be a black market (for now, at any rate). Anyway, you could apply the same argument to Bitcoin itself. The network is not that hard to DoS, so, perhaps everyone should just give up
It's easy to over think things. When Bitcoin was new a lot of very smart people I talked to about it came up with very reasonable and convincing arguments about why it couldn't work. All those people were wrong. By all means think things through, but be careful of falling into the trap of being too clever!
OTOH, short selling requires credit, thus trust, something hard to come by in black markets.
killerstorm: https://github.com/petertodd/decentralized-consensus-systems.git <- github repo for that paper; I just added a bunch of todo notes on what needs writing.
I think 99% of these arguments would go away if we had a simple library and some out of the box tutorials on how to make a parasitic consensus system. So many of these insecure schemes boil down to "it's less coding if I copy namecoin"
Quote
We start with an assumption that there exist a financial market which allows one to profit when a price of a certain currency drops.
Recall that short selling is tightly regulated, for that exact reason. If such a market did exist, it'd probably be a black market (for now, at any rate). Anyway, you could apply the same argument to Bitcoin itself. The network is not that hard to DoS, so, perhaps everyone should just give up
It's easy to over think things. When Bitcoin was new a lot of very smart people I talked to about it came up with very reasonable and convincing arguments about why it couldn't work. All those people were wrong. By all means think things through, but be careful of falling into the trap of being too clever!
It looks like merged mining is game-theoretically sound if we use a simple model, but more complex payoff model shows the difference between authentic PoW and merged mining.
We start with an assumption that there exist a financial market which allows one to profit when a price of a certain currency drops. It can be done through short-selling, or through derivatives like futures and options.
Attacker considers an attack where his actions will create a panic, which results in a price drop. Then he will win a financial bet and get his profit.
Suppose Bitcoin mining equipment cannot be leased in sufficient quantities, this means attacker needs to buy equipment to perform an attack.
He will sell this equipment after an attack, and thus he needs to take into account that if attack was successful, price of this equipment will drop: if Bitcoin mining is competitive, profit margins are small. Drop in price will make mining unprofitable, which means that many miners will try to sell their mining equipment, which will drastically decrease its price.
So attacker's profit is reduced by drop in value of equipment, and it can be negative, which strongly discourages attacks of this sort.
(BTW this also shows that miners shouldn't rent their equipment: if more than 50% is available for rent, they might end up with worthless equipment.)
Now let's consider what is different in case with merged mining:
If Bitcoin mining is by itself profitable, then short-sell-attack described above won't produce a significant drop in value of equipment. And so if we assume that this drop is negligible, attacker will perform a decision to attack when profit from short-selling a currency exceeds profit from mining it.
So, basically, it makes sense to attack as soon that this condition is met, which means that rational miners will likely destroy merged-mined currencies for profit once we'll have financial markets which allow short-selling of such currencies (with a sufficient liquidity).
Situation is different if merged-mining PoW is used together with PoS of some sort: attacker would require a significant stake for a successful attack, and this makes short-selling attacks less lucrative.
We start with an assumption that there exist a financial market which allows one to profit when a price of a certain currency drops. It can be done through short-selling, or through derivatives like futures and options.
Attacker considers an attack where his actions will create a panic, which results in a price drop. Then he will win a financial bet and get his profit.
Suppose Bitcoin mining equipment cannot be leased in sufficient quantities, this means attacker needs to buy equipment to perform an attack.
He will sell this equipment after an attack, and thus he needs to take into account that if attack was successful, price of this equipment will drop: if Bitcoin mining is competitive, profit margins are small. Drop in price will make mining unprofitable, which means that many miners will try to sell their mining equipment, which will drastically decrease its price.
So attacker's profit is reduced by drop in value of equipment, and it can be negative, which strongly discourages attacks of this sort.
(BTW this also shows that miners shouldn't rent their equipment: if more than 50% is available for rent, they might end up with worthless equipment.)
Now let's consider what is different in case with merged mining:
If Bitcoin mining is by itself profitable, then short-sell-attack described above won't produce a significant drop in value of equipment. And so if we assume that this drop is negligible, attacker will perform a decision to attack when profit from short-selling a currency exceeds profit from mining it.
So, basically, it makes sense to attack as soon that this condition is met, which means that rational miners will likely destroy merged-mined currencies for profit once we'll have financial markets which allow short-selling of such currencies (with a sufficient liquidity).
Situation is different if merged-mining PoW is used together with PoS of some sort: attacker would require a significant stake for a successful attack, and this makes short-selling attacks less lucrative.
No.
Peter Todd (retep) mentioned that merged mining is flawed in this comment
I believe it's actually even worse than that: merged mining is game-theoretically unsound. There is a fundamental difference between a proof of work which is spent on a particular purpose and reused proof-of-work.
Anyway, it looks like you and retep can't be right at the same time, which means one of you is wrong. Now fight
Peter Todd (retep) mentioned that merged mining is flawed in this comment
Quote from: retep
In this case "parasite" is a good thing, at least for the parasite, because we our "anti-parasitic consensus system" countermeasures will never be all that effective. It's certainly safer for the "parasite" to live in the host than it is for it to try to live outside of the host, vulnerable to large pools with flamethrowers and 51% attacks.
I've said some pretty nasty stuff about what I think about Mastercoin, but being embedded in the Bitcoin blockchain is one of the things they are doing right. (the particular way they are embedded is currently very flawed, but that can be improved)
I've said some pretty nasty stuff about what I think about Mastercoin, but being embedded in the Bitcoin blockchain is one of the things they are doing right. (the particular way they are embedded is currently very flawed, but that can be improved)
Quote from: dacoinminster
Mike Hearn told me that merged mining would work just as well for us if we'd just take the time to implement it instead of doing this the easy way. It sounds like you disagree with him?
Is that because so few miners actually do merged mining?
Is that because so few miners actually do merged mining?
Quote from: retep
Yes, merge-mining is really, really dangerous because it lets miners who want to attack your consensus system do so for free. Without >50% support you're in danger; IIRC BTC Guild is in a position where they could destroy namecoin singlehandedly at no cost to themselves.
edit: Though it's not like independently mined consensus systems are much different, hence why I think parasitic systems are the way to go. (unfortunately)
edit: Though it's not like independently mined consensus systems are much different, hence why I think parasitic systems are the way to go. (unfortunately)
Anyway, it looks like you and retep can't be right at the same time, which means one of you is wrong. Now fight
I think 99% of these arguments would go away if we had a simple library and some out of the box tutorials on how to make an alternative merge mined chain. So many of these bizarre schemes boil down to "it's less coding if I construct my protocol in _this_ way vs _that_ way"
How do SPV clients on the sidechain work?
Having answered that, can you still say that the consensus is 'almost as strong as Bitcoin consensus'?
Having answered that, can you still say that the consensus is 'almost as strong as Bitcoin consensus'?
SPV simply cannot work for side-chains, but consensus among full nodes is strong.
The question about merged mining vs side-chains arose in context of discussion about Mastercoin (parasitic consensus system), and as a parasitic consensus system Mastercoin doesn't work with SPV anyway.
By the way, while Namecoin transactions can be SPV'd, domain resolution requires scanning last N blocks where N is something like 36000. So loss of SPV won't be a big problem for Namecoin either...
Sorry, but I still think that SPV clients are possible in the side chain. At least if you pay block rewards in the sidechain.
Let's assume the main chain consists of blocks X1->X2->X3->X4->X5->X6->....
The corresponding side chain blocks are Y1->Y3->Y6->...
(The numbers correspond to some arbitrary time units)
Now the SPV client receives a transaction in the side-chain at block Y6 and the block is referenced in X6. It can now use the "Block Depth as a Transaction Validity Check" (https://en.bitcoin.it/wiki/Thin_Client_Security#Block_Depth_as_a_Transaction_Validity_Check) in a similar way as bitcoin SPV clients would do:
So the bitcoin blockchain will continue:
...->X7->X8->X9->X10->X11->X12->X13->X14->X15->X16->X17->X18....
and in some of the bitcoin-blocks are references to sidechain-blocks:
...->Y8->Y11->Y12->Y14->Y16->Y18....
The SPV client can assume that the miners that work in the bitcoin blockchain will not try to waste their bitcoin AND sidechain rewards. So after some number of blocks the SPV client can safely assume that the received transaction which was included in sidechain-block Y6 will stay there. There is also the incentive in the sidechain that every miner wants to prolong the longest chain because they want that their sidechain-reward will not be in an orphaned sidechain-block. So the block depth in the side chain can be used to infer probabilities of a sidechain reorg.
In the above example the miner of block X19 could choose to try an attack and do a reorg. There are two possibilies:
a) He tries to reorg the bitcoin blockchain and with it also the sidechain. The probability of success is very low because he would have to mine block X6b (with reference to Y6b) and would create a chainfork which is 12 blocks behind in the bitcoin blockchain. So this option is even harder than a bitcoin double spend after 6 blocks.
b) A more feasible attack is to try to do a reorg only in the sidechain: So he would mine block X19 and include a reference to sidechain block Y6b (which build on Y5). This would only create a sidechain fork. But the miners of blocks X20,21,22 and so on would still try to build on the longest sidechain Y18, because it gives them a higher probability that their mined sidechain blocks are not orphaned. So this attack can only be successfull if the attacker has more then 50% of the miners who mine on the sidechain.
So the principle is very similar to bitcoin SPV clients. The sidechain SPV clients just have to wait longer to reach the same level of trust as a Bitcoin SPV client. But I would not say that SPV clients cannot work in the sidechain!
Please correct my reasoning if I made a mistake...
Actually, SPV is pretty sketchy in case with normal merged mining too.
Assuming that the bitcoin hashrate is actually "free" to be turned around maliciously. This is tricky, it's like some of the arguments that Bitcoin is only secure if half of all existent (or potentially existent!) computing power is currently working on it. In any case, my comments were only in tepid complaint about "almost as strong as" in comparison to Bitcoin. There is more to consensus than just the blocks.None of this applies to your central purpose of your message: Parasitic altcoins have the same problem with internally invalid data or the inability to make efficient access to their state or to have reduced security compressed representations of their state. So quit letting me knock you off-topic with my pedantry.
Actually, SPV is pretty sketchy in case with normal merged mining too.
Suppose 10% of Bitcoin hashrate goes into merged mining of Foocoin. A bigger Bitcoin mining pool (having more than 10% of hashpower) wants either to discredit Foocoin or to profit from getting fake transactions confirmed by SPV clients.
So it simply creates a chain of blocks with fake transactions. SPV clients will see it as the best chain, and they will be easily fooled to accept these fake transactions.
The cost of this attack is the opportunity cost: if attacker mined Foocoin properly, he would have got fees and generated coins. It is very easy to estimate this cost and make a decision about attack. Currently, in most cases this opportunity cost in basically negligible.
Thus SPV for a merged mined chain is safe only relatively if more than 50% of Bitcoin hashrate is backing it.
I'm saying relatively safe because even attacker who has only 30% of hashpower can be lucky to create a continuous chain of blocks. Usually this kind of attack is unfeasible in case with Bitcoin because cost/opportunity cost is too high. But in case with merged mining attack might have negligible cost, so attacker can try to perform it for months, which increases chances of success. (Of course, he could be doing a double-spend attack instead, so he should choose whatever has higher impact.)
Suppose 10% of Bitcoin hashrate goes into merged mining of Foocoin. A bigger Bitcoin mining pool (having more than 10% of hashpower) wants either to discredit Foocoin or to profit from getting fake transactions confirmed by SPV clients.
So it simply creates a chain of blocks with fake transactions. SPV clients will see it as the best chain, and they will be easily fooled to accept these fake transactions.
The cost of this attack is the opportunity cost: if attacker mined Foocoin properly, he would have got fees and generated coins. It is very easy to estimate this cost and make a decision about attack. Currently, in most cases this opportunity cost in basically negligible.
Thus SPV for a merged mined chain is safe only relatively if more than 50% of Bitcoin hashrate is backing it.
I'm saying relatively safe because even attacker who has only 30% of hashpower can be lucky to create a continuous chain of blocks. Usually this kind of attack is unfeasible in case with Bitcoin because cost/opportunity cost is too high. But in case with merged mining attack might have negligible cost, so attacker can try to perform it for months, which increases chances of success. (Of course, he could be doing a double-spend attack instead, so he should choose whatever has higher impact.)
By the way, while Namecoin transactions can be SPV'd, domain resolution requires scanning last N blocks where N is something like 36000. So loss of SPV won't be a big problem for Namecoin either...
Trivially fixed (you might recognize the idea by the more recent name of "Committed UTXO set"). In any case, yea, I'm not intending to say bad things about the idea generally. But there are limitations to be aware of. Perhaps some of them are fixable, I haven't given it much thought. Thanks for following up.
What happens when Bitcoin block X mines sidechain X and bitcoin block X+1 mines sidechain X' (a fork)?
As I mentioned above, the core of side-chain algorithm is ignoring everything which doesn't look good.
How do SPV clients on the sidechain work?
Having answered that, can you still say that the consensus is 'almost as strong as Bitcoin consensus'?
Having answered that, can you still say that the consensus is 'almost as strong as Bitcoin consensus'?
SPV simply cannot work for side-chains, but consensus among full nodes is strong.
The question about merged mining vs side-chains arose in context of discussion about Mastercoin (parasitic consensus system), and as a parasitic consensus system Mastercoin doesn't work with SPV anyway.
By the way, while Namecoin transactions can be SPV'd, domain resolution requires scanning last N blocks where N is something like 36000. So loss of SPV won't be a big problem for Namecoin either...
Well, of course, side-chain design has its own trade-offs, and probably the biggest one is longer confirmation times.
It should be possible to add another proof-of-work system (i.e. scrypt) or proof-of-stake in the side-chain in addition to the grounding in the bitcoin blockchain to solve this.
Then arbitrary confirmation times could be implemented, right? I am not quite sure if these shorter confirmation times would actually be useful because a bitcoin reorg could always overrule the other proof-of-work blocks. But I think with certain sidechain protocol rules this could actually be very useful to reduce confirmation times.
For example you could specify that the scrypt difficulty is adjusted such that on an average every 2.5 minutes a scrypt block S is found.
At the same time you specify that the sidechain-blocks B that are incorporated in the bitcoin blockchain have to be build on top of at least three of these scrypt blocks.
So that the final chain will look like:
B-S-S-S-B-S-S-S-B-S-S-S-B-S......
An attacker who wants to do a double spend would need to have the majority of hashing power in bitcoin AND also a very large proportion of the hashing power in scrypt.
You would not only gain arbitrary confirmation times, but also more decentralization from ASICs. Even if an attacker with 90% hashing power in the bitcoin blockchain could not do a double spend on this sidechain. So it would be much more secure than Bitcoin.
Now let's compared these side-chains to "parasitic consensus systems" which were described in Peter Todd's (incomplete) article:
I think it's obvious that side-chain have same properties as parasitic consensus systems, except they have smaller footprint and need external storage.
This means that, for example, Mastercoin won't lose anything if it will be re-implemented in form of side chain, it would just need its own block storage and incentive system.
Quote
{Parasitic consensus systems}
A proof-of-work blockchain, such as the Bitcoin blockchain, can be made use of parasistically for a secondary consensus system. Recall the two fundemental proofs that a blockchain provides: consensus ordering/timestamping and and proof-of-publication. A Satoshi-style blockchain can be used as an ordered message publication service - it is not possible to completely prevent the publication of data without whitelisting censorship ...Thus for a given block height i we have a set of blocks B={b_0 ... b_i} containing messages M={m_0 ... m_j}. By applying a fixed set of rules to that set of messages multiple parties can independently arrive at the same state of the system.
... (here goes description of "string bling" system used as an example)
The Mastercoin system uses this principle. While not yet well developed, there exists an agreed upon set of rules that, from the contents of the Bitcoin blockchain, can derive a set of "Mastercoin" transactions and a final ledger state derived from data encoded in the Bitcoin blockchain.
Parasitic consensus systems inherently gain the benefits of the security of the underlying consensus system. Though the "string bling" system may have only a handful of users interested in it, an attacker attempting to change the state of the consensus of what strings have what bling would need to attack the Bitcoin blockchain directly - a signififantly harder problem. A merge-mined or independently mined string-bling implementation would probably never be secure against an attacker with a budget of even just a few thousands dollars, by parasiticly using the Bitcoin blockchain the attackers required budget swells to tens of millions.
A proof-of-work blockchain, such as the Bitcoin blockchain, can be made use of parasistically for a secondary consensus system. Recall the two fundemental proofs that a blockchain provides: consensus ordering/timestamping and and proof-of-publication. A Satoshi-style blockchain can be used as an ordered message publication service - it is not possible to completely prevent the publication of data without whitelisting censorship ...Thus for a given block height i we have a set of blocks B={b_0 ... b_i} containing messages M={m_0 ... m_j}. By applying a fixed set of rules to that set of messages multiple parties can independently arrive at the same state of the system.
... (here goes description of "string bling" system used as an example)
The Mastercoin system uses this principle. While not yet well developed, there exists an agreed upon set of rules that, from the contents of the Bitcoin blockchain, can derive a set of "Mastercoin" transactions and a final ledger state derived from data encoded in the Bitcoin blockchain.
Parasitic consensus systems inherently gain the benefits of the security of the underlying consensus system. Though the "string bling" system may have only a handful of users interested in it, an attacker attempting to change the state of the consensus of what strings have what bling would need to attack the Bitcoin blockchain directly - a signififantly harder problem. A merge-mined or independently mined string-bling implementation would probably never be secure against an attacker with a budget of even just a few thousands dollars, by parasiticly using the Bitcoin blockchain the attackers required budget swells to tens of millions.
I think it's obvious that side-chain have same properties as parasitic consensus systems, except they have smaller footprint and need external storage.
This means that, for example, Mastercoin won't lose anything if it will be re-implemented in form of side chain, it would just need its own block storage and incentive system.
It would "just" need that...
Yeah, I should cover side-chains... I've actually thought a fair bit about them before, and there are all kinds of ugly issues with data hiding and incentives.
Of course, at this rate maybe I should just rename the damn thing "Decentralized Consensus Systems: A survey"
Maybe you misunderstood the OP or maybe I did?
They can rely on the proof-of-work in the bitcoin blocks that are following. So similar to how bitcoin SPV's would handle the situation.
If I understood the OP correctly, a deciding factor is the length of the side chain.
Of course the bitcoin-blockchain would be the ultimate decider and could eventually trigger a massive reorg. But the sidechain-blocks (referenced by bitcoin blocks) are also building on top of other sidechain-blocks. Then you could eventually also have sidechain forks as shown in your examples, but the sidechain rules which pay mining rewards in the sidechain will make sure that all sidechain-miners try to build on top of the longest sidechain.
Everyone will neglect sidechain X because it is invalid. [...] SPV clients on the sidechain must have a bitcoin SPV client included. Then the client has to rely on the bitcoin block depth very similar to what a bitcoin SPV client would do... So nothing special...
These statements are inconsistent, SPV clients cannot reject the invalid chain. How can they distinguish between the latest bitcoin block being a correction of an invalid fork (they should believe it), or a gigantic reorg replacing a run of valid blocks (they should reject it)?Quote
This is the same situation as a temporary bitcoin chainfork, when two blocks were found roughly at the same time. The miner of the next block will then extend the sidechain which is longer, because this will give him the higher probability to create a sustainable side-chain block.
The point in this post is that the bitcoin chain is deciding the identity of the other chain, not the length of the other chain. It doesn't matter what side chain is longer, what chain get committed to the bitcoin chain in the future is the deciding factor.Of course the bitcoin-blockchain would be the ultimate decider and could eventually trigger a massive reorg. But the sidechain-blocks (referenced by bitcoin blocks) are also building on top of other sidechain-blocks. Then you could eventually also have sidechain forks as shown in your examples, but the sidechain rules which pay mining rewards in the sidechain will make sure that all sidechain-miners try to build on top of the longest sidechain.
Everyone will neglect sidechain X because it is invalid. [...] SPV clients on the sidechain must have a bitcoin SPV client included. Then the client has to rely on the bitcoin block depth very similar to what a bitcoin SPV client would do... So nothing special...
These statements are inconsistent, SPV clients cannot reject the invalid chain. How can they distinguish between the latest bitcoin block being a correction of an invalid fork (they should believe it), or a gigantic reorg replacing a run of valid blocks (they should reject it)?Quote
This is the same situation as a temporary bitcoin chainfork, when two blocks were found roughly at the same time. The miner of the next block will then extend the sidechain which is longer, because this will give him the higher probability to create a sustainable side-chain block.
The point in this post is that the bitcoin chain is deciding the identity of the other chain, not the length of the other chain. In this context, it doesn't matter what side chain is longer, what chain get committed to the bitcoin chain in the future is the deciding factor.Jump to: