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.
I'd be interested to hear how you plan on reducing the mining variance with a nonoutsourceable proof of work.
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)
Yes, it's absolutely essential that a switch to a nonoutsourceable puzzle also comes along with a variance reduction mechanism.
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.
I don't really understand the statement at the end that GHash has been "testing the waters" by sneaking above 50% for brief periods.
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%?
They could be withholding some of their own controlled hashing power and either not using it at all, or using it to mine for other pools. I haven't been paying a lot of attention but I've seen people claim that GHash has been doing this in order to understate how much mining power they actually have.
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.
It seems like this would completely shut out small time miners as they are by far the biggest beneficiaries of the pool reducing variance. Is that the right direction?
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?
> 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.
Outnumbered by who? The people securing the network right now are overwhelmingly doing it on pools. If the blockchain forks, the network not supported by pools may literally be unable to continue thanks to the extremely high difficulty it will have post-fork (as has happened with other, smaller coins, thanks to coin-hopping pools).
If most of the Bitcoin Core clients, including all the "light" wallet servers like Electrum and Mycelium, and businesses (like Coinbase) switched over, then the bitcoins created by the miners on the "old" blockchain will completely lose their value as they would not have any uses. They'd have no choice but to switch.
I am pretty sure there is nowhere in the world where 1/x of the people really get a 1/x say in anything.
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.
Regardless of the merits of this proposal, why write a blog post about it instead of submitting it to the Bitcoin developer mailing list?
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.
Bitcoin is only one of a wide range of digital currency's and seems likely to fail long term. Not for any specific reason just the odds of a first mover winning long term have historically been low. Which suggests the most useful discussions are going to occure with the designers of a new currency.
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.
With respect, that's an extremely bizarre attitude to take toward a software project. Even if it were true, which mailing list do you think has the greatest concentration of cryptocurrency expertise?
(And regarding your postscript, are you suggesting that developers shouldn't contribute to open source software projects because in twenty years they might fail?!)
Given that the blog post is advocating technical change to Bitcoin, I'm not certain how there could be any audience more relevant than the mailing list of Bitcoin developers.
Sure, but the idea goes beyond Bitcoin. "A Plan For Spam" is a great example of the same sort of post being far better served as a blog post than any mailing list. http://www.paulgraham.com/spam.html Why? because a simple edit and you can link to any refinements and the idea goes beyond email to any kink of SPAM.
Even if that were true, the post is very clearly advocating a change to Bitcoin itself. Don't you think it's just a little weird to suggest a technical change to a software project on a random blog, rather than discussing it first with the people who actually manage the project you're trying to change?
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.
Sort of. Email, IP, HTML, JavaScript, CSS, HTTPS, etc are all improvements and often minor ones on existing technology. The difference is really that computers where getting far more common in the early stages of the Internet which confuses the issue. EX: few people know about SGML even if all those ML languages use it's formatting. Gopher vs WWW. Hell even DNS is derivative the ARPANET used a HOSTS.TXT file.
I can discern two different approaches in the articles.
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?
What about a single entity controlling >40% of the mining power on the network?
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.
Even more worrying is the trend toward mining centralization in regions of the globe where energy is inexpensive. Almost certainly, if the project continues as is, we'll end up with a few large mining conglomerates located in these locations with cheap energy available.
Presumably because there's a lot of starting capital needed to start mining on the proverbial other side of the world. Once you have high-end power and maybe cooling taken care of, the price of an individual piece of hardware is pretty low.
Any ideas in the following "solution" that could work? I am sure there are problems with it, but it contains a general approach I have not seen suggested:
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.
It shouldn't be. Mining pools are a solution, not the problem. The problem is centralization transaction selection, which is an entirely orthogonal problem. The OP gets rid of pooling and pushes miners to hosted solutions, which is far, far worse.
If you control all the hardware in a pool there's no chance a miner would steal the coins, hence 'pools' in the sense of different owners would be eliminated, and the result would be a few individuals with large pools.
It seems to me that pools could still operate under this new protocol with a slight twist. Since the blockchain is public, every client that mines a block is public. So pools simply enforce the rule that every client in their pool that mines a block must immediately send the reward to the pool. Any client that fails to do so within a set period of time will be blacklisted from the pool. Clients still submit their proof of work to the pool in order to get credit for contribution, the only difference is this is now the 2-phase PoW.
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.
Co-author here. There is a common misconception that consensus of the Bitcoin community is correlated with the hashing power of the miners.
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.
It's likely possible now, because GHash doesn't actually own 51% of the hashrate. They own ~15% and the rest comes from their pool, and since this fork would strongly disincentivize pools, they'd likely not have the means to control the protocol.
There is nothing to enforce about a hardfork. This proposal will produce a mutually incompatible protocal, so unpatched clients would reject it as invalid, and patched clients would reject the unpatched clients as invalid. This is in contrast to the accidental fork we saw last year (or was it longer?), where the new client would accept as valid the old clients chain.
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.
"A $1500 mining card, available for preorder from Butterfly Labs"
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.
Preventing mining pools will only solve the 50% problem if the resulting network doesn't end up with even worse hash-power inequalities.
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.
the underlying problem is one can form a centralized system on top of a decentralized one but not the other way around. the real problem is validation of the transactions included in the mined blocks and not pooled mining.
Instead of trying to fight pools, why not embrace them? Tweak the protocol so instead of miners racing to a discreet payoff, all miners get a payout proportional to all of the mining work they do.
Finding the hash for the next block is fundamental to the entire blockchain concept. It sounds difficult to think of a scheme where the discreet payoff does not enter the equation.
That's how pooled mining works, but I think you have to trust the pool operator to do the % accounting. The % split is not recorded in the blockchain.
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.
People are starting to discuss that. If you create a difficulty/N block you could get a reward of 25/N BTC. This would lead to runaway blockchain bloat, though.
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.