Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

[Alex Mizrahi <alex.mizrahi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

>  The goal is to have an opportunity cost to breaking the rules.
>

You could as well have said "The goal is to implement it in a specific way
I want it to be implemented."
This makes zero sense.
You aren't even trying to compare properties of different possible
implementations, you just outright reject the alternatives.

So the thing is, relying on opportunity cost is rather problematic.

1. can't work when system isn't heavily used (you'll have to rely on the
honesty of miners instead)
2. chicken-and-egg: system is not secure until it is heavily used, and it
isn't heavily used until it is secure
3. finally, if the expected profit from attack is higher than the
opportunity cost of it, it just makes no sense

Let's put 1 and 2 aside. For the start, you need to prove that attack
cannot yield profits which are higher than honest mining.

The problem with it is that the total amount of money is much higher than
the amount of money which is being transacted in a short time frame. And it
is much higher than what fees might yield within a reasonable time frame.

So if there is a way to attack the whole (with a profit proportional to the
whole), you won't be able to rely on opportunity cost to prevent the attack.

Usually at this point people say "we assume that miners aren't going to
collude, otherwise even Bitcoin is not secure".
Well, this is BS. The fact that a pool can acquire more than 50% of total
hashpower was successfully demonstrated by ghash.io.
But the thing is, Bitcoin doesn't offer one a good way to attack the whole,
as there are powerful factors which will work against the attacker.
But this is not the case with sidechains (or any merged-mined chains, for
that matter).
And once you have a clear incentive, collusion is much more likely.


> Proof of Burn is a real cost for following the rules.
>

 So what? As long as cost is less than revenue, it is OK.

[-- Attachment #2: Type: text/html, Size: 2688 bytes --]