How to Disincentivize Large Bitcoin Mining Pools
hackingdistributed.com
hackingdistributed.com
Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions
http://cs.umd.edu/~amiller/nonoutsourceable_full.pdf
But the general idea comes across very well in this blog post.
The main difference between this post and our "weakly-nonoutsourceable" scheme is that ours uses a custom hash-based signature scheme, which has exactly the properties we require. The SIG scheme in the original post would be hard to instantiate otherwise (ECDSA, for example, totally doesn't work).
The "strongly-nonoutsourceable" scheme, which uses zero-knowledge moon-math, is aimed at also discouraging cloud-mining, which is also a serious concern.
Without a scheme to reduce the variance, nonoutsourceable puzzles would almost certainly lead to increased centralization (smaller miners effectively never solve the puzzle without collusion).
(I notice you're not calling for an immediate hard fork of bitcoin like Ittay Eyal and Emin Gün Sirer are)
I have no clear winning solution for this part, but I've got a few ideas and have discussed them with Peter Todd, who also has ideas here. Basically the approach should be to internalize P2Pool, and to let miners choose a lower difficulty if they want (for a proportionally lower portion of the reward).
This is really subtle though. It would increase the amount of bandwidth needed. It would be easier to discourage / punish a block that has less difficulty. Also, some component of the reward should still be a high-variance jackpot... the nonoutsourceable puzzle is only effective when there's a luck component, and thus a big incentive for the real worker to defect.
So there's a ton more work to do. It's definitely not time for an immediate hard fork. But the discussion should begin.
This seems to imply that the people running GHash can choose exactly what percentage of the mining power their pool represents at any given moment. But as a pool, wouldn't these fluctuations instead represent genuine variability in how many people are mining for GHash vs everyone else? How could GHash decide to "get brazen" and go to 55%?
What this means is that at any time GHash could take all that extra mining power and point it at their own pool and therefore increase their percentage.
Also, completely shutting out the pools might lead to a true hard fork where the pools keep going their own way. Especially if one of them has >50% of the hashing power. Will they be willing to die, given that operating a large pool must be quite lucrative?
I'm not an expert, but I think that they wouldn't have a choice, since they would be outnumbered, and no one would recognize the legitimacy of their new bitcoins. Having 51% of the hashing power doesn't give them 51% of the vote when it comes to this community decision.
taxation without representation...
Things like votes are attempts to make it so, but as a practical matter if you only get to vote between a few choices created by blocks of power in which you are not an elite (i.e political parties), your vote cannot possibly reflect what you want in any meaningful way.
Tragically, people are so used to voting between choices other people set out for them that they delude themselves into thinking that they are being fairly represented, and that their beliefs really should line up in one of a few belief-bundles determined by team names.
I can't believe they didn't realize that to begin with. It's such a large chunk of 20th century human history.
These authors have written a lot about the mining pool problem in recent days, but don't appear to have engaged in any discussion on bitcoin-development. It feels like a very passive-aggressive way of proposing a solution to a problem, by publicly announcing it instead of engaging the current dev team directly.
PS: I can't think of a single technology over 20 years old where the first mover is still the leader. Bell telephone company is the longest run I an think of.
(And regarding your postscript, are you suggesting that developers shouldn't contribute to open source software projects because in twenty years they might fail?!)
Cryptocurrencies are also a far more specialised field than spam prevention. The blog post outlines a strategy for dealing with large mining cartels in a widely-used cryptocurrency. I'd suggest that maintaining a serious crypto-currency is something that very few people in the world have the expertise to do reliably. When your intended audience is, at most, a few thousand, or maybe even a few hundred cryptographers, I really don't see the point in putting it on a blog to a general audience.
Russian rockets, to an extent. Big(gest) share of world launches, hardware inheritance from world first ICBM, first launched in 1957.
Popular internet protocols tend to evolve rather than get replaced (cf. nearly every protocol ever).
A) Hard Bitcoin Fork article's approach: You publish a zero-knowledge proof that you have a solution, but not the solution itself. See my summary: https://news.ycombinator.com/item?id=7891243
B) Current article's approach: require that the solution be signed with the (primary?) recipient's private key.
A) prevents collaboration because a member who finds the solution can keep it for themselves, and its content is not revealed (only a ZKP is) so the pool doesn't even recognize it as "their" solution.
B) prevents collaboration because you'd have to give out the private key to any contributor, all of whom would send out competing spend messages as soon as the solution went out.
Can anyone who understands them confirm my summary?
Given the increasing barrier to entry to mining, where even $1500 worth of cutting edge mining hardware is just a tiny drop in the ocean, won't this be the future of Bitcoin? A few whales, and a whole lot of insignificant chaff.
If a miner wants to be part of a pool they must publish their participation in that pool (signed with their private sig) prior to the next block being worked on (or longer if deemed necessary, we are still talking minutes). They can only change pools once a day. Anyone in the pool solving the block will result in the block chain dividing the winnings among the pool.
Then there is a rule that no pool can win more than once a day (or some other time limit).
This allows small miners to pool together to reduce their risk, while incentivizing pools to stay under a certain percentage of computing power as going over that would actually decrease their expected returns.
Small miners get the complete advantage of reduced risk, while large miners are incentivized to stay under a limit.
This may not be a foolproof solution, but perhaps it contains elements useful to a solution.
The purpose of a pool is to coordinate work amongst untrusted parties.
This solution solves nothing.
This eliminates mining pools entirely.
The only players who need mining pools are the small individual miners.
The end result of this change would be a move towards centralization.
Exactly the opposite of the intended effect.
This does increase the risk slightly, because a miner could contribute until such time as they successfully mine a block, keep the reward for themselves, get blacklisted, and then create a new key and rejoin the pool. This could be mitigated by enforcing rules like all pool members must refuse to participate in any transaction involving a blacklisted address, which if widespread enough (and if the blacklist is shared among pools) would force blacklisted clients to deal with mixing services. Pools could also try to strike agreements with other large players (e.g. bitcoin exchanges, mixing services, etc) for them to respect the pool blacklist.
So the real question is whether the increased risk is tolerable, and whether a pool under this new scheme can wield enough influence to get enough large players to respect their blacklist in order for it to be effective.
Couldn't they just run more servers?
A miner can have 51% of the hashing power, but if the blocks he produces are not accepted by clients (i.e. people with wallets, merchants, and the like), his 51% hash power is completely useless. His blocks need to be recognized by the clients, and if the clients decide that they do not want centralized mining pools, and decide that they only accept blocks with a second cryptopuzzle in them, miners who fail to switch will produce blocks that are unrecognized and therefore useless.
Would you get effectively two kinds of BTC? (aka. a network partition?)
Practically, this could be implemented as blocks after block X must follow the new rule, blocks X and earlier must follow the old rule. Where X is sufficiently far in the future to allow for people to update.
Don't try to buy mining hardware from Butterfly labs. There are others that actually ship their hardware on time. This is like the situation where every article on bitcoin mentioned MtGox as "the" exchange, even after it stopped usd withdrawals and was the most expensive place to buy bitcoins.
But I think it would have worse inequalities, or at least, not be obviously better.
If you can't trust hashing partners, then the largest users will be those who can enforce "cooperation" some other way, probably by being independently wealthy. That, it seems, has a sharper power drop-off than the ever-fluid mining pools.
[Made the same point in the previous discussion https://news.ycombinator.com/item?id=7891243]
The block reward payout destination address is part of the coinbase that everyone is trying to mine. You can't have the actual block contain a list of all active miners; as the list of miners changes, the target coinbase hash changes too. There wouldn't be any incentive for anyone to try to mine a coinbase containing rewards towards other miners. That would just be giving away your block reward to others for free: If you are actually able to find a block before anyone else, you should have tried to find a block that maximizes payout to yourself.