I am trying to focus on posting source documents, as opposed to someone else’s reporting on source documents.
Yeah, and that’s called a fork. The chain doesn’t vanish; a new chain is created, forking off of the old one. That’s why we have both Ethereum and Ethereum Classic.
Oh wait, you’re talking about a 51% attack. Read the whole article that you linked. It is amazingly difficult to perform, and as the number of nodes goes up, it becomes even more difficult.
Has anyone successfully performed a 51% Attack on Bitcoin?
Nope, not yet.
Some miners have come close to reaching 50% or more of the total mining power over Bitcoin’s history, but nobody has actually performed a successful 51% Attack.
If Big Daddy Bitcoin hasn’t suffered a 51% attack, I find the risk of that happening vanishingly low.
https://hacken.io/discover/51-percent-attack/
There have been three. BTG, ETC and VTC. All three of those are Proof of Work. PoW is going by the wayside, I’m hopeful that Proton would be using Proof of Stake, which is a much more difficult model to 51% against. (You would need to possess 51% of the tokens.) Even if someone managed to do it, it would still be noticed pretty much immediately, and then you’d fork to a new chain and move on.
Context matters:
Proton rolled out the beta version of Key Transparency on their own private blockchain, meaning it’s not run by a decentralized series of validators, as with Bitcoin or Ethereum. Yen said Proton might move the feature to a public blockchain after the current version serves as a proof of concept.
It’s not rewriting history. We’re talking about validation of public keys. The exact same information can be added to a public non-beta chain, to satisfy the concerns about security that would come from maintaining a previously private beta chain into production.
You do realize that when it’s out of beta, they could easily drop the beta chain and start a brand new one, right? And that the methodology for someone adding their public key as well as the blockchain node application (wallet) would be open source, so that anyone can look at the code? And that Proton isn’t adding your public key to the chain, you are? And that being a beta blockchain kind of necessaily depends on having many nodes, in order to test scalability?
You’re out of your depth here, and I’m not going to bother explaining any further.
Proton rolled out the beta version of Key Transparency on their own private blockchain, meaning it’s not run by a decentralized series of validators, as with Bitcoin or Ethereum. Yen said Proton might move the feature to a public blockchain after the current version serves as a proof of concept.
https://finance.yahoo.com/news/blockchain-not-crypto-proton-mail-120000573.html
Because the Proton blockchain is currently private, the keys they are currently adding could easily be affected by a man in the middle attack.
No. That’s not how that works. Just because a blockchain is “private” doesn’t make it suddenly changeable, and it doesn’t mean there’s a unsafely small number of nodes. People commonly get invited to participate in beta testing; that’s kind of how software development works.
And there would be no way to invalidate those keys for any of the affected users, …
Remember when I said:
As long as there is an appropriate method for adding a legitimate entry to the chain, incorrectly entered data can be handled by appending corrected data on to the chain, and marking the error as such.
That hasn’t become untrue in the last hour.
As long as there is an appropriate method for adding a legitimate entry to the chain, incorrectly entered data can be handled by appending corrected data on to the chain, and marking the error as such. Sensitive data, in this case, would be along the lines of “I accidentally added my private key instead of my public key.” The action necessary here is the same as if I published my private key anywhere: stop using that key pair and generate a new one.
Right here:
Blockchains are an immutable ledger, meaning any data initially entered onto them can’t be altered. Yen realized that putting users’ public keys on a blockchain would create a record ensuring those keys actually belonged to them – and would be cross-referenced whenever other users send emails. “In order for the verification to be trusted, it needs to be public, and it needs to be unchanging,” Yen said.
The benefit of doing this with a blockchain instead of a privately held and maintained database is that the latter can be compromised, and you just have to trust “whoever” is maintaining that private database. Blockchain means that the ledger is distributed to many nodes, and any post-entry modification to that chain would be instantly recognized, and marked invalid by the other nodes operating the chain. Besides that, when you’re looking up a public key for a recipient on such a blockchain, you would be looking it up at a number of nodes large enough that in order for a malicious entry to come through, they would all have to be modified in the same way, at the same time, and you would have to be asking before the change got flagged. Poisoning blockchain data like this is simply not possible; that’s what makes this an especially secure option.
I feel like you don’t understand how blockchains work.