This is simply wrong. When presented with a valid history and a simulation how do you tell them apart?
If say the guaranteed protection against forks for the short term is up to a year, that means clients need to sync with the network at least every year. If you're always syncing, you won't be fooled by sham blockchains because it doesn't follow from your last trusted blockchain tip. If it does follow from your last trusted blockchain tip and you were syncing at least every year, then it's a short-range fork, and the consequences will be severe for the attacker -- it's unlikely to happen.
Even without syncing often, the client can get the blockchain hash from external trusted sources (or many trusted sources from existing validators), and sync thereon. Both of these solutions can be utilized to create a practical and secure solution.
The money spent on mining is not wasted.
New coins are worth something. People will compete to produce them, resulting in marginal value ~= marginal cost. You can either make this simple enough that it's obvious that's what is going on, or you can hide it behind complexity. Proof of stake hides it: it creates bizarre problems like a black market in private keys that used to hold lots of coins so that you can generate new POS coins. Other options (complete pre-mine, for instance) come with their own problems.
Forcing people to spend lots of real resources generating coins has a really desirable side effect: it means that many of the producers will be forced to sell the coins they mine, which means there will be a market for those looking to buy them.
For the same reason, ASIC miners causing hash rate explosions are not a bad thing. The economic incentives don't care about capital costs vs electric costs, just that cost to produce = selling price. The centralization is bad, yes, but the other complaints commonly raised aren't actually a bad thing.
POS and other non-POW schemes lose one of Bitcoin's most appealing features: trustless history. I can tell from my copy of the blockchain that it is valid. If someone disagrees, they can simply present their version with a stronger POW, and I can easily tell who is correct without trusting either party.
If you can have similar or better security properties as mining without the cost incurred by the competition of energy expenditure, then the mining is wasteful.
While absolute trustless history seems good, it has a significant drawback as well: it isn't anti-fragile. That is, there is no way for the network to become stronger after recovering from a double spend attack, e.g. by slashing stake of the attackers.
You don't need long-range fork protection as long as the expiration of a block hash is known in advance. That is, short-range fork protection is all you need as long as the range is long enough -- e.g. a year. And this can be done entirely without mining.
Forget saving for retirement, even if that is the stated reason. Perhaps people are actually saving for the sake of saving, and it happens that they start using the savings when they can work no longer.
Why save at all? Maybe to help your children when they need your help. Maybe it's fun.
That said, everything depends on what you want out of life. If you must believe that you will live on after death through cyropreservation, then it makes sense live and let freeze. But I would rather choose to prepare for a situation where cryopreservation is not possible within my lifetime, until I am convinced otherwise. I'm not yet convinced.
Disclaimer: rambling ahead.
One thing that struck me while reading your discussion post is that, even with simulated AI that can be saved, copied, and replayed, it isn't obvious nor given that we can merge these clone instances into a single 'averaged' instance.
We could, if we could arbitrarily shrink an instance to only require 1/Nth the resources (or time). The shrunken instance would be less perfect, but there is power in the ability to run numerous nested (sets in sets, like a tree) instances simultaneously.
I now have undeniable proof that it is not worthwhile to worry about acasually dangerous ideas, but you'll have to simulate me through deduction to find out what this proof is. #basilisk
Subscribe to RSS Feed
= f037147d6e6c911a85753b9abdedda8d)
You are outsourcing the trust problem, not solving it.
It's solved for everyone who is always periodically syncing.
Also, if you're comfortable with Bitcoin's security model, then for Tendermint you only need to get a trusted block hash (after a long period of being offline) if and only if you detect a fork in the block-chain. Most of the time there won't be.