Topic: Majority is not Enough: Bitcoin Mining is Vulnerable - page 5. (Read 51057 times)

I'm surprised you don't have this guy ignored already. Typical "everything about bitcoin is bad but I'm not going to understand what I am talking about" troll.

Now back to something interesting, like GBT. I didn't know you could use it to also push the block to the network yourself. Genius.

You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin.

You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin.

You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin.

Huh?

Which is fine so long as Bitcoin's central bank's client

Which is fine so long as Bitcoin's central bank's client remains the defacto standard. As other mining strategies are discovered there will be ore and more clients available running forked mining code.

It's not possible for pools to do this without miner cooperation - for example, by them using the stratum protocol. As long as miners are taking advantage of the GBT protocol, this attack is not possible since the miner finding the block will announce it to the network themselves.

The paper does not consider multiple selfish mining pools fighting against one another.

For simplicity, and without loss of generality, we assume that miners are divided into two groups, a colluding minority pool that follows the selfish mining strategy, and a majority that follows the honest mining strategy (others).

what part of my post indicated that I was "worked up"?

Whatever though. Continue to get yourselves worked up about an erroneous result.

...
Low latency connection itself is expensive, and we can nullify its advantage by relaying unverified block headers. People will always assume a block header is valid unless it is proven otherwise, and always mine on top of the first seen header. (I think creating invalid block header is very expensive and no one is trying to do this. Any stats for this?)
...

1) Make the nonce long enough that the extraNonce field is no longer needed in the coinbase transaction.

2) Now it's possible for miners to broadcast their Merkle tree as soon as they start hashing (10 minutes on average before they finish)

3) When they find a valid hash, now they only need to broadcast the block header because the rest of the network has (usually) already received and validated the Merkle tree.

4) Block header propagation is very fast and not dependent of the size of the blocks.

Despite the overhyped headline, this paper is important. It's part of a (long past due) movement towards modeling "rational participation" in Bitcoin. We are (surprisingly?) in a blind spot here as far as theoretical foundations go (the 30+ years of research in distributed systems, game theory, etc., have not looked at anything resembling Bitcoin). We do not yet have a sound way to argue that "Bitcoin (or X variant thereof) surely works," nor any impossibility results saying "nothing resembling Bitcoin can ever work."
 
Main points:
- Bitcoin is clearly *intended* to be incentive-compatible and encourage correct behavior. However the whitepaper only gives a proof for the "51% honest" model, which is unrealistic/trivial (if we just assume everyone's honest, there's no need for rewards in the first place). Even in this easy model, Bitcoin is novel among byzantine consensus protocols. Academics *should* have worked on this twenty years ago, but missed it! (except for this 2005 tech report)
- Practically speaking, we still seem to have a while to figure this stuff out before any systemic economic collapse will manifest. Even the mining pools still run bitcoind, not RationalMiner software. For the time being, majority honest is a reasonable approximation.
- Even if a 51% majority has limited ability to profit or attack, a systematic trend towards enabling 51% attacks would be a design flaw and existential threat. So we really need to find and fix things like this.
 
This paper fits neatly into a class of papers/posts that point out a particular way in which Bitcoin is not incentive-compatible (to call it an *attack* is just cyberhype), yet a simple fix (typically just to the messaging layer) is often at hand.
- Bitcoin and Red Balloons. There's no incentive for peers to relay transactions. Solution: bribe your peer conditional on the transaction getting accepted, now it's their problem too.
- This paper: If a mining pool is confident in its ability to detect and out-propagate competing blocks, then it can profit by witholding blocks until the last minute, making everyone else waste work. Solution: relay faster so no peer can get this advantage, or use random tie-breaking so this attack can't be pulled off consistently (the following two examples are me plugging my own posts). Regardless of propagation, a miner with more than 33% of the network's hashpower can profit disproportionately by witholding one block at a time. [edited, due to author pointing out this was oversimplified].
- https://gist.github.com/amiller/cf9af3fbc23a629d3084 An anomalously large single transaction fee would encourage miners to fight over the previous block, rather than building on each other's work. Solution: remove the 100-block coinbase maturity rule, which actually prevents a simple cooperative equilibrium where you take a cut of the huge fee for yourself and leave the rest for the next miners to fight over.
- https://bitcointalksearch.org/topic/a-non-outsourceable-puzzle-to-prevent-hosted-mining-and-mining-pools-309073 Natural economies of scale mean that "outsourced hosted mining" will be more cost effective and might drive out other participants, leading to more centralized control of resources, susceptible to coercion etc. Solution: a modified puzzle using (efficient) zero-knowledge proofs would make hosted mining (and mining pools, incidentally) impractical.
 
There are other similar "attacks" along the lines of "this may be a problem when people eventually run RationalMiner rather than HonestSatoshiReferenceClient", but for which the solutions are less obvious...
- Feather forking: https://bitcointalksearch.org/topic/feather-forks-enforcing-a-blacklist-with-sub-50-hash-power-312668  a small cartel of miners that want to enforce a transaction black-list could easily make it so that rational participants indifferent to the blacklist would rather appease the cartel than resist it. Possible solution: Adam Back is thinking very hard about how to make miners verify the correctness of transactions without learning anything else about them.
- Kroll. et al: Following *any* of the rules is at best a *focal point*, and slight rule tweaks like inflating the 21 million limit (just by a little bit) are probably a lot more plausible and easier to pull off than most people think. Possible solution: no idea
 
But we're still just scratching the surface of incentive-alignment glitches like this. Bitcoin will overcome the problems with easy fixes. I hope (but am skeptical) that if there's a bigger fix required, we can work it out and adopt it without waiting until it's too late and having to restart from scratch.
 
Above all, I wish we had a strong theoretical model we could use to knock out entire classes of problems rather than pointing them out and patching them one at a time. By analogy, the academic cryptography community did such a great job of moving from ad hoc ciphers to "provable security" that the mainstream security mantra is "don't roll your own crypto" unless you've proved a theorem first. Maybe someday they'll say the same thing about rolling your own incentive-consensus protocols. But the work hasn't been done yet, and we're currently still in the dark ages.

What other problems would it create and why are they more intractable?

Changing the header is absolutely not required to pre-forward the block. You simply pre-forward it along with a pointer to where the extra nonce goes, and when you solve it you send the resulting timestamp,nonce,extra nonce for substitution— even less data than the header in the most efficient case.  P2Pool already implements block pre-forwarding (though not that aggressively: rather than deny the ability to add transactions, it preforwards transactions and then sends the Merkle tree+header+extranonce) .

However, "10 minutes on average before they finish" isn't right... the whole network produces a block in that time, not each miner. Sending data only once every block per miner, instead of incrementally, would also massively delay transactions— the delays is not something we should encourage. Preforwarding also uses a LOT of extra bandwidth, because each non-successful miner is constantly broadcasting block data too.

In any case, I think making block propagation faster is useful generally— but you don't need to change _anything_ about Bitcoin to do it. You just need to make a little fast-block-daemon which runs its own protocol to relay blocks and that could be run in parallel to the current p2p network.

It's almost a bit orthogonal though, since a better positioned miner still has a _latency_ advantage. Making the data smaller doesn't beat the speed of light.