[runeks]

If 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.

[coinculture]

That's right. The first time you sync up, you're particularly vulnerable. You need to authenticate first against a trusted source.

[runeks]

> 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]

It'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]

Also, 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]

> 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.

[zmanian]

Because 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]

If 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]

I 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]

> 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]

You would need to compromise 2/3rd of the keys in the genesis block. But yes but this tradeoff unlocks massively high transaction throughput.

[Ironchefpython]

If 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.

[zmanian]

It'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]

You would have to compromise the devices of validators who have atleast 2/3 of the voting power.

In Bitcoin, just compromise the devices of mining pools that have atleast 50% of the hashing power, and reconstruct a chain that is longer than the current canonical chain, thus rewriting the chain history.

[runeks]

> In Bitcoin, just compromise the devices of mining pools that have atleast 50% of the hashing power, and reconstruct a chain that is longer than the current canonical chain, thus rewriting the chain history.

Rewriting the Bitcoin blockchain using 100% of the current hashing power would take an entire year. Thus, with 50% of it it would take two years, assuming the network hashrate doesn't increase (which it does).

Don’t you think someone would notice — over the course of two years — that their mining pool has been compromised and no longer extends the current best chain?

Compromising Bitcoin mining pools lets you move hashing power somewhere else, which is noticeable since the extension of the current best chain would slow down. Compromising the genesis keys in PoS system let’s you create as many valid chains as you want in little to no time.

[sunnya97]

It'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]

It 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.