Miner consolidation is a long-standing problem with Bitcoin itself.
When Ittay and I discovered selfish mining [1], we were quite worried about the size of mining pools at the time. Even though we also came up for a fix against selfish mining, the fix only prohibits selfish mining for pools <25%, and we also found that there can never be a fix to prohibit selfish mining for pools >=33%.
Things looked grim for a while, and we played a role in pushing back against GHash when they exceeded 51% around April of '14. The only tool that the community had at the time to break up large miners was just social pressure.
In part as a reaction to GHash crossing of the 51% line, we [2] and Andrew Miller et al [3] came up with techniques based on non-outsourceable puzzles. This is a cool technique that would make it difficult for miners to run large open pools. It does require a potentially disruptive change to Bitcoin, so it's good to have in one's back pocket if the mining situation gets out of hand, but it's not something you want to deploy.
Luckily, Ittay's subsequent work on the Miner's Dilemma [4] discovered an incredibly interesting result: it pays for miners to attack other miners who are running large open pools. This puts natural pressure on miners to not open themselves up to the public and accept people into their pools willy nilly. This in turn is, I think, fantastic news, as it means that the problem may take care of itself, at least when it comes to open pools.
Overall, the distribution of mining power is a point of concern for everyone in the Bitcoin space. The situation looked bleak at first, as it looked like there were few mechanisms to keep open pools from growing ever larger. But now we have a strong technical solution and a natural process that is well-characterized. Large solo miners still remain an ongoing concern.
This is interesting stuff, but it's still a stop gap. As you say, large solo miners are an ongoing concern.
If bitcoin ever makes it big, IMO, it'll be large corporations running mining operations. Just as the general population does most of its services through huge corporations, mining bitcoin will probably be done by them as well.
What do you think of Proof of Stake systems? Are they feasible? I'm working on one, btw, with a shared spending pool and an ability to vote to spend the pool, and to change the code of the official client, thereby changing the rules of the system.
All good questions, all of which are answered in the white paper. An "elected leader" is essentially the same thing as a miner that mines a block in Bitcoin. Miners can mine empty blocks in Bitcoin. This is OK, as others will step in for such defunct miners. Likewise, in Bitcoin-NG, another miner will step up if the elected leader does not mint microblocks.
Keep in mind also that NG would be layered on top of Bitcoin, so everything that works in Bitcoin will work in NG as well.
This sounds like a use case for Macaroons [1]. A primer and a public implementation can be found here [2]. There's also a JavaScript implementation [3].
Thanks, indeed, there are many alternative NTP servers [1]. But I believe time.nist.gov is the default time server during Ubuntu installation, so there are many hosts that depend entirely on time.nist.gov.
HyperDex provides scalable and high-performance transactions. While it is strongly (not eventually) consistent, the underlying technique we use to achieve atomicity of transactions is reminiscent of this approach.
On a related note, our experience is that a tightly implemented database can be much faster than a typical eventually consistent database. It would be great to see performance comparisons from TreodeDB.
That's cool. Indeed, it does look like one could use HypderDex's transactions and cond_put to make something close the batch write described in this post.
However, I don't see the part about Lamport clocks in HyperDex's API. Maybe one could implement that in a layer on top. The technique in the post allows a client to know if the values in its cache satisfy application invariants, even invariants that relate multiple rows. The Lamport clocks are key to making that part work.
I would very much like to provide performance numbers, and Jepsen results, and more for TreodeDB. Along that line though, I'm looking for contributors (or even a co-founder). I've gotten it this far on my own, but I really need help.
This well-illustrated post is technically about the core Synod agreement protocol in Paxos. Building a consistent distributed service on top requires additional scaffolding and infrastructure. Typically, people layer on a system that implements a "replicated state machine (RSM)" on top, which maintains the illusion of a single consistent object, even though it is composed of distributed replicas.
Also keep in mind that Raft, Zab, and View-Stamped replication (in reverse chronological order) are alternatives to the Synod protocol in Paxos. These protocols differ from Paxos by employing a different leader-election mechanism and slightly different way of maintaining their invariants.
There have been many Paxos variants. This site [1] shows the various Paxos variants over a timeline and points out their contributions.
Those of you interested in building replicated state machines using Paxos should take a look at OpenReplica [2]. It is a full Multi-Paxos implementation that takes any Python object and makes it distributed and fault-tolerant, like an RPC package on steroids.
It's critical to not conflate Bitcoin with ChangeTip. The two are, in effect, separate currencies. One is decentralized and backed by the blockchain, the other is centralized and backed by a company.
A litmus test for centralized currencies is to ask the question "can they create wealth out of the thin air by manipulating a database entry?" The answer is affirmative for ChangeTip. To their credit, they maintain proof-of-reserves online, so while we do not know the amounts held by their users, we have an idea of how much they can pay out. I applaud the transparency they have shown.
I agree with you about centralized versus decentralized solutions, but ChangeTIp clearly does NOT want to supplant bitcoin- they do their best to keep wallets small, and aren't trying to be a "bitcoin bank" / replacement ala Coinbase. Instead, they're driving adoption. What is there to complain about?
>For the record, I appreciate your technical critiques! But you seem to take a perverse delight in being the critic.
Ok, so you enjoy the technical content but disagree with the tone [1]? I can understand that. I genuinely feel sorry I don't have the time to build rapport. Many other bloggers regurgitate things we all agree on and make everyone feel warm and fuzzy inside. I figure that enough people already do this that I only need to chime in when the group-think is headed south.
They have no choice. There's no regulation around this so companies are forced to be transparent and convince their users they're legit.
We're just not used to companies being transparent because contracts around regulated industry are enforced by the force of law (threats of fine, imprisonment or violence).
We could have many more companies being transparent if only we didn't give them a way to use the force of law to convince users they're covered (think Bank of America and FDIC for instance. I'd rather Bank of America had to prove to me their investments are sound etc)
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.
No, this post, and the handy table inside, explains the various attacks possible at different percentages of the hash rate:
http://hackingdistributed.com/2014/06/16/how-a-mining-monopo...