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.
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.
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.
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.
See http://tendermint.com
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.
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.