1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-12-11 01:08:15 +00:00

Fix misplaced word "though" in the phrase "Though centralized implementations". Use a semicolon to break up a long sentence. Attempt to clarify some phrases using different words.

This commit is contained in:
Cragin Godley 2014-10-25 19:02:00 -04:00
parent 9a4ca75610
commit 5cf430ecd6

View File

@ -34,7 +34,7 @@ Traditional security architecture is based upon a concept called the _root of tr
Bitcoin security architecture is different. In bitcoin the consensus system creates a trusted public ledger which is completely de-centralized. A correctly validated blockchain uses the genesis block as the root of trust, building a chain of trust up to the current block. Bitcoin systems can and should use the blockchain as their root of trust. When designing a complex bitcoin application that consists of services on many different systems, you should carefully examine the security architecture in order to ascertain where trust is being placed. Ultimately the only thing that should be explicitly trusted is a fully validated blockchain. If your application explicitly or implicitly vests trust in anything but the blockchain, that should be a source of concern as it introduces points of vulnerability. A good method to evaluate the security architecture of your application is to consider each individual component and evaluate a hypothetical scenario where that component is completely compromised and under the control of a malicious actor. Take each component of your application, in turn, and assess the impacts on the overall security if that component is compromised. If your application is no longer secure when components are compromised that shows that you have implicitly misplaced trust in those components. A bitcoin application without vulnerabilities should be vulnerable only to a compromise of the bitcoin consensus mechanism. Meaning that its root of trust is based on the strongest part of the bitcoin security architecture. Bitcoin security architecture is different. In bitcoin the consensus system creates a trusted public ledger which is completely de-centralized. A correctly validated blockchain uses the genesis block as the root of trust, building a chain of trust up to the current block. Bitcoin systems can and should use the blockchain as their root of trust. When designing a complex bitcoin application that consists of services on many different systems, you should carefully examine the security architecture in order to ascertain where trust is being placed. Ultimately the only thing that should be explicitly trusted is a fully validated blockchain. If your application explicitly or implicitly vests trust in anything but the blockchain, that should be a source of concern as it introduces points of vulnerability. A good method to evaluate the security architecture of your application is to consider each individual component and evaluate a hypothetical scenario where that component is completely compromised and under the control of a malicious actor. Take each component of your application, in turn, and assess the impacts on the overall security if that component is compromised. If your application is no longer secure when components are compromised that shows that you have implicitly misplaced trust in those components. A bitcoin application without vulnerabilities should be vulnerable only to a compromise of the bitcoin consensus mechanism. Meaning that its root of trust is based on the strongest part of the bitcoin security architecture.
The numerous examples of bitcoin exchanges serve to underscore this point as their security architecture and design fails even under the most casual scrutiny. Though centralized implementations had invested trust explicitly in numerous components outside the bitcoin blockchain, such as hot wallets, centralized ledger databases, vulnerable encryption keys, etc. Worse yet, in most cases those trusted components lacked even the most rudimentary security controls. The numerous examples of bitcoin exchange failures serve to underscore this point; their security architecture and design would fail to pass even the most casual inspection. Their centralized implementations invested trust explicitly in numerous components outside the bitcoin blockchain such as hot wallets, centralized ledger databases, vulnerable encryption keys, etc. Worse yet, in most cases those trusted components lacked even the most rudimentary security controls.
=== User Security Best Practices === User Security Best Practices