= 27d567bc2d48d9f40e9ccc20ea370b15)
Mark_Friedenbach comments on Ethereum creator Vitalik Buterin mentions LessWrong, discusses the various camps and ideologies in Cryptocurrency development - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
= f037147d6e6c911a85753b9abdedda8d){kind=logo}
Comments (27)
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.