mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-02-02 02:41:42 +00:00
grammar fixes for ch05.asciidoc
This commit is contained in:
parent
87b5e66dab
commit
02888c1c0b
@ -23,7 +23,7 @@ Once a transaction has been created, it is signed by the owner (or owners) of th
|
||||
[[tx_bcast]]
|
||||
==== Broadcasting Transactions to the Bitcoin Network
|
||||
|
||||
First, a transaction needs to be delivered to the bitcoin network so that it can be propagated and be included in the blockchain. In essence, a bitcoin transaction is just 300-400 bytes of data and has to reach any one of tens of thousands of bitcoin nodes. The sender does not need to trust the nodes they use to broadcast the transaction, as long as they use more than one to ensure that it propagates. The nodes don't need to trust the sender or establish the sender's "identity". Since the transaction is signed and contains no confidential information, private keys or credentials, it can be publicly broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network. As long as the transaction can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node. Bitcoin transactions can therefore be transmitted to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copying and pasting into a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hoping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a public forum or sent as a text message or Skype chat message. Bitcoin has turned money into a relatively simple data structure (that is cryptographically verifiable), making it virtually impossible to stop anyone from creating and executing a bitcoin transaction.
|
||||
First, a transaction needs to be delivered to the bitcoin network so that it can be propagated and be included in the blockchain. In essence, a bitcoin transaction is just 300-400 bytes of data and has to reach any one of tens of thousands of bitcoin nodes. The sender does not need to trust the nodes they use to broadcast the transaction, as long as they use more than one to ensure that it propagates. The nodes don't need to trust the sender or establish the sender's "identity". Since the transaction is signed and contains no confidential information, private keys or credentials, it can be publicly broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network. As long as the transaction can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node. Bitcoin transactions can therefore be transmitted to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copying and pasting into a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hoping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a public forum or sent as a text message or Skype chat message. Bitcoin has turned money into a data structure, making it virtually impossible to stop anyone from creating and executing a bitcoin transaction.
|
||||
|
||||
[[tx_propagation]]
|
||||
==== Propagating Transactions on the Bitcoin Network
|
||||
@ -182,7 +182,7 @@ This is only the tip of the iceberg of possibilities that can be expressed with
|
||||
|
||||
[TIP]
|
||||
====
|
||||
Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. This is how bitcoin gets the power of "programmable money"
|
||||
Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. This is how bitcoin gets the power of "programmable money".
|
||||
====
|
||||
|
||||
==== Script Construction (Lock + Unlock)
|
||||
@ -252,7 +252,7 @@ Transactions are valid if the top result on the stack is TRUE (1), any other non
|
||||
|
||||
==== Turing Incompleteness
|
||||
|
||||
The bitcoin transaction script language contains many operators but is deliberately limited in one important way - there are no loops or complex flow control capabilities other than conditional flow control. This ensures that the language is not Turing Complete, meaning that scripts have limited complexity and predictable execution times. Script it is not a general-purpose language. These limitations ensure that the language cannot be used to create an infinite loop or other form of "logic bomb" that could be embedded in a transaction in a way that causes a Denial-of-Service attack against the bitcoin network. Remember, every transaction is validated by every full node on the bitcoin network. A limited language prevents the transaction validation mechanism from being used as a vulnerability.
|
||||
The bitcoin transaction script language contains many operators but is deliberately limited in one important way -- there are no loops or complex flow control capabilities other than conditional flow control. This ensures that the language is not Turing Complete, meaning that scripts have limited complexity and predictable execution times. Script it is not a general-purpose language. These limitations ensure that the language cannot be used to create an infinite loop or other form of "logic bomb" that could be embedded in a transaction in a way that causes a Denial-of-Service attack against the bitcoin network. Remember, every transaction is validated by every full node on the bitcoin network. A limited language prevents the transaction validation mechanism from being used as a vulnerability.
|
||||
|
||||
==== Stateless Verification
|
||||
|
||||
@ -471,7 +471,7 @@ The Pay-to-Script-Hash feature offers the following benefits compared to the dir
|
||||
* Complex scripts are replaced by shorter fingerprint in the transaction output, making the transaction smaller
|
||||
* Scripts can be coded as an address, so the sender and the sender's wallet don't need complex engineering to implement P2SH
|
||||
* P2SH shifts the burden of constructing the script to the recipient not the sender
|
||||
* P2SH shifts the burden in data storage for the long script from the output (which is set in the UTXO and therefore impacts memory) to the input (only stored on the blockchain)
|
||||
* P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set and therefore impacts memory) to the input (only stored on the blockchain)
|
||||
* P2SH shifts the burden in data storage for the long script from the present time (payment) to a future time (when it is spent)
|
||||
* P2SH shifts the transaction fee cost of a long script from the sender to the recipient who has to include the long redeemScript to spend it
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user