5 ms·
In a BFT protocol based cryptocurrency, an attacker who acquired 2/3rds of the tokens in the network would be able to double spend at will and censor transactio
by zmanian 9y ago
In a BFT protocol based cryptocurrency, an attacker who acquired 2/3rds of the tokens in the network would be able to double spend at will and censor transactions to gain control of more of the network.
They would not be able to rewrite past history.
The only response to an attack would be hard fork.
- runeks 9y agoIf I want to bootstrap my node and I join a network where 2/3 of the nodes present a newly-created (false) transaction history, and the remaining nodes present the original transaction history, how would I be able to tell which chain to follow without trusted/special nodes? In other words, the plan of attack wouldn’t be altering the current chain (which indeed would require owning coins on it, because of proof-of-stake), but rather presenting a completely different chain to new nodes with a 2/3 node majority.
- zmanian 9y agoBecause someone needs to show you a valid set of transitions in the PKI from the original keys in the genesis block to the current attacker controlled PKI.
- runeks 9y agoIf the corresponding private key of a public key in the genesis block defines the correct transaction history then this system is not decentralized, but controlled by whoever owns this private key. In which case this entity might as well just sign blocks to avoid the double spend problem in a much simpler (albeit centralized) way.
- zmanian 9y agoI prefer if people differentiate between systems with a PKI and systems without a PKI. Systems without a PKI like PoW or PoET can be rather centralized like Bitcoin today or decentralized like Bitcoin before the emergence of mining pools. Systems with a PKI can have an onchain PKI like Cosmos. One of the challenges in an on chain PKI system is you need some of kind social pre-consensus on launch. The crowdfunding established an part of an initial pre-consensus but there are more moving pieces coming.
- runeks 9y ago> One of the challenges in an on chain PKI system is you need some of kind social pre-consensus on launch. The greatest challenge, in my opinion, is that there’s a central point of failure: just compromise whichever device stores the private key for the genesis block and you get to redefine history as you please. Compromising a Bitcoin mining pool cannot be compared to this, since it would just result in this pool’s miners losing their revenue and moving somewhere else (it can never enable rewriting the entire chain history).
- zmanian 9y agoYou would need to compromise 2/3rd of the keys in the genesis block. But yes but this tradeoff unlocks massively high transaction throughput.
- Ironchefpython 9y agoIf this system depends on trusting 2/3 of the keys in the genesis block, why not simply sign all individual transactions with keys in the genesis block, and unlock even higher transaction throughput? I mean if you gotta trust a centralized authority anyway, ditch the blockchain and make it simple.
- sunnya97 9y agoWhat centralized authority? The keys in the genesis block aren't owned by a single actor, but by multiple. You can keep the validator set static all the time (use the ones from the genesis block), this might be useful for private chains. But Tendermint also allows for dynamic validator sets. This is useful for Proof of Stake, where validators can come and go, and their voting power can change in accordance with changes in their stake deposits.
- zmanian 9y agoIt's hard to evaluate the security of a flippant comment but there is clearly a security benefit of live BFT system vs a non-BFT system.
- sunnya97 9y agoIt's not a single private key. There are a lot of validators, even in the genesis block, and we assume that at least 2/3 of these validators are honest.
- runeks 9y agoIt still puts an upper bound on the value of the underlying token, as the pressure for these validations to collude increases with the market value of the token in question. An outside attacker compromising keys isn’t the only way for the system to fail. Would you trust 100 validators with securing $10M? What about $100M or $1bn? The financial incentive to collude keeps increasing as the value increases.
- coinculture 9y agoThat's right. The first time you sync up, you're particularly vulnerable. You need to authenticate first against a trusted source.
- runeks 9y ago> You need to authenticate first against a trusted source. If the system depends on a trusted source, why not just have this trusted source sign blocks, thus solving the double spend problem without further ado?
- coinculture 9y agoIt's not some single centralized trusted source. It's a local trusted source. Like a friend or a shop or a website you make payments on that uses the network and has been keeping up to date. Ideally folks should check multiple sources to ensure they agree. In the same way folks need to figure out which software to download when they join the Bitcoin network.
- sunnya97 9y agoAlso, two other comments regarding weak subjectivity: When you join the bitcoin blockchain, you need some trusted source to tell you the hash of the correct genesis block. Also, if you want to follow a shorter fork chain like Ethereum Classic, you also need weak subjectivity to tell you the first block immediately after the fork, otherwise you might be tricked onto the longer malicious fork, Ethereum :P
- runeks 9y ago> When you join the bitcoin blockchain, you need some trusted source to tell you the hash of the correct genesis block. No, you don’t. There’s nothing special about the Bitcoin genesis block, it’s a block like any other. Whether you follow a chain that builds on top of this block or some other block has no bearing on the security of the system. It contains no keys that get to decide anything later on.