Strange nobody mentioned Nassim Taleb and his work on that matter: The Precautionary Principle - www.fooledbyrandomness.com/pp2.pdf
Quoting the first paragraph of the paper:
The precautionary principle (PP) states that if an action
or policy has a suspected risk of causing severe harm to the public domain (affecting general health or the environment globally), the action should not be taken in the absence of scientific near-certainty about its safety. Under these conditions, the burden of proof about absence of harm falls on those proposing an action, not those opposing it. PP is
intended to deal with uncertainty and risk in cases where the absence of evidence and the incompleteness of scientific knowledge carries profound implications and in the presence of risks of "black swans", unforeseen and unforeseable events of extreme consequence.
Untraceable money is an oxymoron, the whole point of money is that the whole network of people using it, can trust it is not forged out of someones ass, and is instead what its claimed to be.
Quick someone tell the federal reserve / ecb that QEs can't be used because they are an oxymoron (sorry can't resist).
That said it is possible to have an open ledger used to avoid duble spends without revealing anything about someone finance, just look for monero (xmr) or zerocash.
I don't know about "web" scale, but it will definitely scale horizontally without using any external tools/extensions.
There's still a somewhat annoying limitation that is related to the status of table partitioning in postgresql.
In fact the planner automatically choose the right child table, be it on the same db or into another server, for UPDATE and SELECT statements but not for INSERTs. This is a known limitation and there's active work to fix it but don't hold your breath though.
Yes you're right when talking about the steady dicrease in terms of full nodes. I think that introducing economic incentives for stimulate full node operators are badly needed.
I've recently read a proposal for such a scheme written by Justus Ranvier, you can find it here:
Users could use SPV clients in case of resource constraints, on the other hand there are incentives in place, that till now, have kept miners from shutting down their nodes.
Bitcoin core latest version (0.10.0) have reduced significantly the bootstrap time of a node (e.g. through "header-first" mechanism).
Future releases will introduce other improvements that will lead to a reduction in terms of network bandwidth/latency (O(1) block propagation, IBLT) and IO space (e.g. pruning)
That said it's true there's no economic incentives in place to "just" run a full node. Person that run full nodes does that for a lot of reasons modulo the economic one.
There are proposals (1) floating around to fix the situation through, guess what... economic incentives, but we are for from getting some sort of agreement, worse than that I dare say that in this case we're still struggling with problem awareness.
He admits the models will never be perfect, but thinks
that even a model that’s only right about 50 percent of
the time could help investors and entrepreneurs avoid
particularly bad ideas
dunno why but I can't stop thinking that tossing a coin could achieve the same goal :)
Ok now I got what you meant. thanks for the explanation.
Having said that your consideration about "on line nature" applies also to my mastercard in almost all the shops I usually buy stuff be it on line or off line. Without me providing the OTP and the payment processor verifying it I can't buy anything.
A little bit OT but worthy IMHO. There are quite a few SPV (1) client implementations that remove the need to have all the blockchain stored locally. The things are moving even further in these field with the implementation of the payment protocol (2)
50$ of transaction fee? At current price that means 0.075 btc per tx. I can assure you that you can mv btc from one address to another for a lot less. Even without paying any fee at all. It all depends on how "old" are the btc you're moving, the amount of btc , the number of addresses involved in the tx and if you're in a hurry or not.
Quick list of major features:
Parallel sequential scans, joins and aggregates
Elimination of repetitive scanning of old data by autovacuum
Synchronous replication now allows multiple standby servers for increased reliability
Full-text search for phrases
Support for remote joins, sorts, and updates in postgres_fdw
Substantial performance improvements, especially in the area of improving scalability on many-CPU servers