Bitcoin Forum

Currently merged mining mechanism is often recommended as a consensus mechanism for alt-currencies and whatnot: merged mining enables reuse of Bitcoin proof-of-work, which is nice.

However, it isn't the only way to re-use Bitcoin consensus. The alternative is to create a block chain which is fully dependent on Bitcoin.

It is usually called timestamping, see here: https://bitcointalk.org/index.php?topic=113337.0

Let's call a block chain based on timestamping a side-chain. (I don't know whether it's consistent with previous use, but at least side-chains were mentioned in a topic about timestamping.)

Side-chain is NOT an alternative chain (https://en.bitcoin.it/wiki/Alternative_chain) as it doesn't use block chain algorithm, that is, rules for finding the best chain are different.

However, they share a lot of similarities with merged mining: they can use identical machinery on the Bitcoin side, as it's only necessary to reference a hash of side-chain block in the Bitcoin block, and it is what merged mining is about on the Bitcoin side.

The difference is in the rules used to validate blocks and to build the best chain:

• side-chain ignores blocks not references by Bitcoin blocks which are part of best-chain (and this means that Bitcoin reorg triggers side-chain reorg)
• side-chain ignore blocks which do not extend the longest chain
• otherwise, it is just a longest chain of blocks which are referenced from Bitcoin blocks which are part of the best chain

Let's summarize the difference between merged-mined chains and side-chains:

Merged-mined chains re-use Bitcoin proof-of-work, but their best chain is fully independent from Bitcoin best chain. Thus it is possible that merged-mined chain will have a reorganization when there is no Bitcoin chain reorganization; and vice-versa: Bitcoin reorganization has no effect on a merged-mined chain. Thus we can say that merged-mined chains constitute an independent consensus system which merely re-uses Bitcoin proof-of-work, but doesn't depend on Bitcoin chain.

On the other hand, side-chain consensus is fully dependent on Bitcoin consensus: side-chain reorganization is impossible without Bitcoin reorganization. (But Bitcoin reorgs can easily trigger side-chain reorgs.) This means that side-chain consensus is almost as strong as Bitcoin consensus.

I hope now you see why I brought up this topic: if only a fraction of Bitcoin miners uses merged-mining, side-chain s are more secure against double-spends and "51% attacks" than merged-mined chains!

Thus, side-chains are, in a way, superior. Then why merged-mining is the recommended method?

Well, of course, side-chain design has its own trade-offs, and probably the biggest one is longer confirmation times.

Let's compare two situations:

1. 10% of Bitcoin hashpower works on a certain side-chain: side-chain is as strong as Bitcoin, but delay until first confirmation is 10x bigger. (On the other hand, getting 6 confirmations on the side chain will require only 2.7 more time than getting 6 confirmations on Bitcoin chain.)
2. 10% of Bitcoin hashpower works on a certain merged-mined chain: confirmations are fast, but a Bitcoin mining pool having more than 10% of hashpower can brutally destroy it basically for free.

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.

I think in the proposal for DIANNA this mining approach was used.

Yes:

https://dianna-project.org/wiki/Merged_Mining#DIANNA_Implementation

The obvious constructions have some problems.

What happens when Bitcoin block X  mines sidechain X  and bitcoin block X+1 mines sidechain X' (a fork)?

Okay, having answered that. Now answer what happens when Bitcoin block X  mines sidechain X  and bitcoin block X+1 mines sidechain X' (a fork), but sidechain X is _invalid_?

Okay, having answered that. What happens when its the sidechain along with bitcoin block X+1, X+2, etc. that are invalid? 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'?

I don't see problems as long as the sidechain rules are such that mined sidechain blocks payout some incentive to the miner within the sidechain.

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. If sidechain X and sidechain X' have the same sidechain-block-height, then it doesn't matter which one will be extended at the next block. It is exactly the same situation as it happens quite often with temporary bitcoin chains.

Everyone will neglect sidechain X because it is invalid. So also the next miner who wants to include the next sidechain block into a bitcoin block will extend the valid sidechain X', because otherwise he will not receive rewards in the sidechain.

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

I would say yes, almost as strong. Minor drawback is that in these special situations above, it might take one or two blocks more, to reach the same trustlevel as it would be the case in the bitcoin chain.

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

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.

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.

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"

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.

As I mentioned above, the core of side-chain algorithm is ignoring everything which doesn't look good.


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

Trivially fixed (https://bitcointalk.org/index.php?topic=21995.0) (you might recognize the idea by the more recent name of "Committed UTXO set"). :P

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.

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

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. :P

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

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"

No.

Peter Todd (retep) mentioned that merged mining is flawed in this comment (http://www.reddit.com/r/Bitcoin/comments/1oo1h2/mastercoin_pays_out_25000_in_btc_msc_to_winners/cctzerh)




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

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.

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!

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"

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.

Don't CampBX and Mpex support short selling already?

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"

Is it more profitable using merged mining?

I don't know, but MPex at least is almost certainly illegal.

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