redy

No serious blockchain relies on proof-of-work. Bitcoin (being forked now) doesn't and ethereum (already forked twice) definitely doesn't.

Blockchains are a social construct and what ultimately protects them are the participants. Exactly like actual currencies they are subject to market forces; people either believe in and want the currency or they don't. It's this confidence that gives the currency strength.

More simply:

"On medium to long time scales, humans are quite good at consensus. Even if an adversary had access to unlimited hashing power, and came out with a 51% attack of any major blockchain that reverted even the last month of history, convincing the community that this chain is legitimate is much harder than just outrunning the main chain’s hashpower. They would need to subvert block explorers, every trusted member in the community, the New York Times, archive.org, and many other sources on the internet; all in all, convincing the world that the new attack chain is the one that came first in the information technology-dense 21st century is about as hard as convincing the world that the US moon landings never happened. These social considerations are what ultimately protect any blockchain in the long term, regardless of whether or not the blockchain’s community admits it (note that Bitcoin Core does admit this primacy of the social layer)." [1]

[1] https://medium.com/@VitalikButerin/a-proof-of-stake-design-p...

The subtlety here is making the distinction between confidence and resistance to attack. They're not the same thing at all. And what's interesting here is that, going off the model of real currencies, one could assume market forces will prevail here. Developed nations let their currencies float precisely because on the whole they're confident that the market will ultimately punish any malicious attacker who attempts to destroy the currency by selling large amounts of it.

It's sort of a silly question. It's like asking how telephones can solve a problem. The blockchain is a network not unlike the web, the telephone network, and the highway network. Networks don't solve problems in themselves they enable new collaboration models and collaborators solve the problem. People keep getting hung up on implementation details (BTC is one implementation) and silly hype (the fall of Fed!) which is how these things go. Ignore that.

Go to the source code. This stuff is open-source and well documented. Once you start reading the code this stuff makes sense. Write your own blockchain. In fact it's not that hard and it'll make the basic concepts really sink in.

This is a common error. The blockchain itself doesn't make money. Just like the internet itself doesn't make money. People build collaboration models on top of the communication protocols and they make money.

(You still need to pay the ISPs of course and eventually the ISPs become too powerful and start demanding bigger and bigger fees and then the whole thing turns to shit. See: Bitcoin, the internet.)

It's a public database. That's it. Anybody can write to the database and anybody can read from it.

The problem is that whenever you have a public anything there will be spam. People will come along and they will fill the space up with scam ads and porn and hate speech. See: the internet.

To prevent the database from filling up with spam you need to find a way to make people "pay" for writing to the blockchain. Nothing is free and if you're going to consume resources (storage and cpu) from other's computers then they ought to get something in return. That's what "transaction fees" are and that's why they're measured in costs per byte -- the people who are writing to this public, decentralized, highly resilient database are being charged storage fees.

So blockchains are the solution to spam. And unlike pre-existing spam solutions a blockchain doesn't require storage/delivery nodes to "whitelist" certain certificates or for certificate authorities and CRLs and all that wackiness. This is kinda remarkable.

This innovation enables all sorts of new models of collaboration (read: business models). Just today I saw a very interesting proposal for an Uber-like system built on a blockchain. Everything -- requests for transport, driver availability, driver fees, driver certification, passenger and driver ratings -- gets stored in the blockchain. Anybody can read, anybody can write. Here's the database, here's the type of "transactions" (records) -- go crazy. The interesting thing about this system is that it doesn't rely on huge bureaucracy to protect the database. (And what are many business firms but database maintainers and protectors?) Write whatever you want -- write pics of your cats if you like -- but it's going to cost you.

(There's another element of what's commonly called blockchain which is "block verification." The problem here is that when everybody has a copy of the database how do you decide whose copy of the database is authoritative? This is the concept of consensus and note that it's only a problem if the peers in the database don't trust one another. It's actually not so interesting but it is largely an implementation detail of public blockchains with different strategies proof-of-work, proof-of-stake, electoral-validation etc.)

It's because there is no meaningful parallel. Conversations are not economic transactions. Period. You can try to stretch analogies ("walking is illegal because of traffic lights!1") but that's stupid and unhelpful.

The Constitution doesn't guarantee a right to private communications. This is the problem. Period. The 4th amendment was sacrificed during the anti-drug/anti-black eighties. Right now the moment information leaves your home -- whether its a phone call or a letter or a bitcoin transaction -- the government has the right to intercept that. They don't even need a warrant in practice.

It's going to require a Constitutional amendment, really a new 4th amendment, that will clearly and unambiguously extend privacy to a person's communication and data. Complaining about taxes on barter isn't going to help and is nothing but distraction.

Mutiny is likely. American officers in particular will tend not to follow orders to commit an obvious war crime. This isn't an extralegal check , it's very much legal.

But the system will fail if "the whole chain is stupid." This is why it's so dangerous to have a President obsessed with loyalty.

This actually does look great.

There's real value here. In a world being overrun with services what's desperately needed is an orchestration language. Such a language is severely focused on consuming services/messages, converting data, and then uploading data/messages. This is the next Unix shell; a tool whose only purpose would be to stitch together services, pipe data, schedule execution, and display results. An integration dsl.

But it's not clear ballerina that can really do that. Would love to see a more real world example that demonstrates it really solves the integration/scripting problem.

There is no easy answer here. Where and when validation happens requires some careful analysis.

I find it helps a lot to think carefully about (1) message validation -- is this a valid message? (2) entity validation -- is this entity in a valid state? and (3) enterprise validation -- is the business system as a whole now in a valid state? These three questions map on to what is often an ACL, domain, and domain services layer. At the end of the day there's going to be corner cases though in which case as a rule of thumb there's something to be said for doing validation at the edges and moving it in closing to the center as needed. In my experience when it's not clear where validation belongs that often means nobody really understands that validation (or that validation is even wrong and is not what the business wants -- it happens!) and so there's something to be said for keeping it out of the core domain.

Clean architecture is just repackaged DDD. I sympathize with what Bob is trying to do though -- for some reason this stuff often doesn't "click" with many developers until they see it and then it seems "obvious."

I think it's hard to really explain why software should be built like this. This is why architects and senior devs and the like often end up ruling by dictat and simply laying down rules like "messages only in the ACL, no messaging in the domain." The problem that Clean Architecture and DDD are trying to solve are architectural and ultimately organizational problems and these problems are not clear to most developers who are just given a story and told to implement some new feature or story. The only hope is to make these these architectural problems everybody's problem. Spread the pain.

Microservices btw are no escape hatch. Microservices that don't get the essential system boundaries right are in fact going to become a horrible mess. If anything microservices make it more important to think carefully about the boundaries and the interfaces of the system.

See my comment below. The language of the business will almost always guide the design in the right direction. There are rare cases where the business is unaware of a more "essential truth." This isn't about OO it's about faithfully capturing the model of the domain which is all DDD is.

Registration is definitely not a property of the student.

It's always a good idea in these situations to appeal to real life. The actual business will point the way of the business simulation. In the real world we don't ask students to register for a course. Instead students ask the Registrar to register for a course. When the Registrar makes her decision she considers far more than just the internal state of the Student; she considers (1) does the course have any available seats? (2) has the Student met all the course pre-requisites and, most importantly, (3) has the student paid his tuition and is he even a valid member of the university community.

What the Student does have is a history and a context -- that is, a state -- that must be considered when registering for courses. The student may also have preferences -- courses he wants to register for.

The language of the business should guide these decisions always. A student submits a request tfor a course and it is the office of that accepts or denies this request.

Everybody knows "exactly once" means deduplication. This is not exactly a new problem.

That said it's still a difficult problem and I actually wish people would stop trying to roll their own schemes. For example, this scheme relies on examining a Kafka outbound topic to resolve in-doubt outbound messages. But what happens if the outbound message + commit is still "in flight" when the system recovers so the system retransmits the in-doubt outbound message and so rather than deduping it now is generating dupes? Yes, the chances of this are minimal which means it will happen.

60 years ago the US built the interstate highway system.

I think this is the point. The US spent roughly half a trillion dollars to build ~40,000 miles of road. There was a great deal of corruption as well as massive political conflict between federal, state and city agencies. Compare this to what the Nazis did in 1935 when the government hired 150,000 men and put them to work and finished construction five years later.

The point here isn't that decentralization is bad. But it's not difficult to see why these large federalized states like the US, India, Brazil do infrastructure so poorly.

What's changed in the last 5 or 6 decades?

The rise of highly sophisticated private actors that are, in fact, very, very good at extracting public monies. This is most visible in the military where the cost of outsourcing is so obscene that even Congress cannot deny it and now "in-sourcing" is a thing -- but really it afflicts almost everything the government does. This combination of decentralized, unsophisticated, weak government actors trying to match wits with highly sophisticated, numerate private actors is, in the end, a recipe for pillaging of the public treasury. (In fact one could argue that the 2008 global financial crisis is ultimately the best example of such pillaging.)

Another way to look at this is to understand that what people call "cost disease" is the other side of the growing pricing power of private firms. And, ultimately, these firms can charge such high prices because they have worked very hard to guarantee that governments will pay them. (See eg Medicare where by law the program cannot negotiate prices.)

It's also worth noting Singapore is certainly not a market-based system. Singapore's healtcare efficiency is completely the result of mandatory saving programs, a government funded insurance scheme for the poor and strict price controls[1].

As for China frankly I don't think anybody would seriously want to replicate what passed for healthcare in China. It's disturbingly common for patients to die because they cannot afford even routine surgeries in China.

[1] https://en.wikipedia.org/wiki/Healthcare_in_Singapore#Fundin...

Cost disease is definitely a real thing but you should be very wary of the diagnoses proposed by these amateur (libertarian) bloggers. Even a cursory analysis reveals that attempts to blame regulation, utilization, or government spending do not hold water -- all you have to do is compare the US to France, Germany and Japan.

A more plausible theory is that cost disease is largely due to (1) regulatory capture and weak institutions, (2) coordination costs between various institutions and (3) what ultimately boils down to corruption (public officials acting with private interests). If you really want to understand rising costs in health-care, military, and construction you should pay close attention to the rise in outsourcing and pseudo-government agencies (eg US defense contractors, supposedly "private" corporations where 70%+ of revenue comes from the government).

France, Japan, China -- these are in fact highly centralized economies which means that they are able to operate national, robust healthcare and military systems with surprising efficiency. UK, Brazil, India and of course the USA (par excellence) -- these are highly decentralized and federalized economies which means large scale initiatives are very prone to succumbing to the dangers referenced above.