Break long paragraphs lines

Author: edilmedeiros

10_compact_size_unsigned_integers.md

@@ -1,20 +1,35 @@
 # Compact Size Unsigned Integers
 
-We'll talk more about the Segwit soft fork and how the transaction format changed later on in this course. For now, we're going to assume the transactions we're decoding are serialized according to the legacy, pre-segwit format. This means the next field after the version will be the number of inputs.
+We'll talk more about the Segwit soft fork and how the transaction format changed later on in this course.
+For now, we're going to assume the transactions we're decoding are serialized according to the legacy, pre-segwit format.
+This means the next field after the version will be the number of inputs.
 
-If you have read [Mastering Bitcoin 3rd Edition, Chapter 6](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#length-of-transaction-input-list), you'll remember that the next byte represents the length of the transaction input list encoded as a compactSize usigned integer. The compactSize integer indicates how many bytes to read to determine the number of inputs. For example, if the length is less than 253, then the next byte is simply interpreted as an unsigned 8-bit integer (the `u8` data type in Rust). If the length is greater than 252 and less than 2^16, then we would expect to see the byte `fd` (or the integer 253) followed by two additional bytes interpreted as a `u16` integer, etc. This is the table we can use as reference:
+If you have read [Mastering Bitcoin 3rd Edition, Chapter 6](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#length-of-transaction-input-list), you'll remember that the next byte represents the length of the transaction input list encoded as a compactSize usigned integer.
+The compactSize integer indicates how many bytes to read to determine the number of inputs.
+For example, if the length is less than 253, then the next byte is simply interpreted as an unsigned 8-bit integer (the `u8` data type in Rust).
+If the length is greater than 252 and less than 2^16, then we would expect to see the byte `fd` (or the integer 253) followed by two additional bytes interpreted as a `u16` integer, etc.
+This is the table we can use as reference:
 
 ![Compact Size Unsigned Integer Type](images/compactSize.png)
 
-So let's write a function to read a compactSize unsigned integer. Let's think about this a bit. What kind of argument do we want to accept? And what should the return type be? Take a moment to fill out the function signature and come back.
+So let's write a function to read a compactSize unsigned integer.
+Let's think about this a bit.
+What kind of argument do we want to accept? And what should the return type be? Take a moment to fill out the function signature and come back.
 
 <hr/>
 
-For the argument type, we have to remember that we're still passing around the same mutable reference to the slice so that we can keep reading it and moving the pointer. So we'll keep the same argument type as in the `read_version` function.
+For the argument type, we have to remember that we're still passing around the same mutable reference to the slice so that we can keep reading it and moving the pointer.
+So we'll keep the same argument type as in the `read_version` function.
 
-Now, what should the return type be? Well, the input length can be an 8-bit, 16-bit, 32-bit or a 64-bit unsigned integer? So if we need to specify just one type for the length, let's choose the highest one as it will contain any other possibility. `fn read_compact_size(transaction_bytes: &mut &[u8]) -> u64`
+Now, what should the return type be? Well, the input length can be an 8-bit, 16-bit, 32-bit or a 64-bit unsigned integer? So if we need to specify just one type for the length, let's choose the highest one as it will contain any other possibility.
+`fn read_compact_size(transaction_bytes: &mut &[u8]) -> u64`
 
-From here, it is fairly straightforward if/else logic. As the chart above shows in the Format column, we can tell how many bytes to read based on the byte value. If it is less than 253, then the byte is the length. If it is equal to 254, then we need to read the next two bytes. If it is equal to 255, then we need to read the next three bytes and so on. So let's implement this using a standard if/else statement block which you're probably familiar with.
+From here, it is fairly straightforward if/else logic.
+As the chart above shows in the Format column, we can tell how many bytes to read based on the byte value.
+If it is less than 253, then the byte is the length.
+If it is equal to 254, then we need to read the next two bytes.
+If it is equal to 255, then we need to read the next three bytes and so on.
+So let's implement this using a standard if/else statement block which you're probably familiar with.
 
 ```rust
 fn read_compact_size(transaction_bytes: &mut &[u8]) -> u64 {
@@ -41,12 +56,17 @@ fn read_compact_size(transaction_bytes: &mut &[u8]) -> u64 {
 
 A few things to point out here:
 1. `0..253` syntax is a [range type](https://doc.rust-lang.org/std/ops/struct.Range.html#), which has a method called `contains` to check if a value is in the given range.
-2. The number of bytes read match the integer type. For example, 2 bytes give us a `u16` type. 4 bytes give us a `u32` type. 
-3. We **cast** each type into a `u64`. We can convert between primitive types in Rust using the [`as` keyword](https://doc.rust-lang.org/std/keyword.as.html).
-4. Notice how there are are no semicolons for each ending line, such as `u32::from_le_bytes(buffer) as u64`. This is the equivalent of returning that value from the function. We could also write it as `return u32::from_le_bytes(buffer) as u64;` but implicit return without semicolon is more idiomatic.
+2. The number of bytes read match the integer type.
+For example, 2 bytes give us a `u16` type, and 4 bytes give us a `u32` type. 
+3. We **cast** each type into a `u64`.
+We can convert between primitive types in Rust using the [`as` keyword](https://doc.rust-lang.org/std/keyword.as.html).
+4. Notice how there are are no semicolons for each ending line, such as `u32::from_le_bytes(buffer) as u64`.
+This is the equivalent of returning that value from the function. We could also write it as `return u32::from_le_bytes(buffer) as u64;` but implicit return without semicolon is more idiomatic.
 
-We're going to make one more change. While standard if/else statements work fine, Rust provides pattern matching via the `match` keyword and this is a good opportunity to use it as it is commonly used in Rust codebases. https://doc.rust-lang.org/book/ch06-02-match.html
 
+We're going to make one more change.
+While standard if/else statements work fine, Rust provides pattern matching via the `match` keyword and this is a good opportunity to use it as it is commonly used in Rust codebases.
+https://doc.rust-lang.org/book/ch06-02-match.html
 ```rust
 fn read_compact_size(transaction_bytes: &mut &[u8]) -> u64 {
     let mut compact_size = [0; 1];
@@ -73,11 +93,17 @@ fn read_compact_size(transaction_bytes: &mut &[u8]) -> u64 {
 }
 ```
 
-What do you think? The `match` looks nicer doesn't it? Take a moment to get familiar with the syntax. Each of the `arm`'s has a pattern to match followed by `=>` and then some code to return for that given pattern. 
+What do you think?
+The `match` looks nicer doesn't it?
+Take a moment to get familiar with the syntax.
+Each of the `arm`'s has a pattern to match followed by `=>` and then some code to return for that given pattern. 
 
-We sometimes see an arm with the underscore symbol (`_` ) as the pattern to match. This represents a catchall pattern that will capture any value not already covered by the previous arms. However, in our case, this is not needed since the previous arms are exhaustive and capture all the possible scenarios. Remember a `u8` can only have a value between `0` and `255`.
+We sometimes see an arm with the underscore symbol (`_` ) as the pattern to match.
+This represents a catchall pattern that will capture any value not already covered by the previous arms.
+However, in our case, this is not needed since the previous arms are exhaustive and capture all the possible scenarios.
+Remember a `u8` can only have a value between `0` and `255`.
 
-Now all we have to do is update our `main` function to call this and return the number of inputs. 
+Now all we have to do is update our `main` function to call this and return the number of inputs.
 
 ```rust
 fn main() {
@@ -99,10 +125,15 @@ Version: 1
 Input Length: 2
 ```
 
-Pretty neat! We're making good progress. But even though our code compiles, how can we be sure we've written it correctly and that this function will return the appropriate number of inputs for different transactions? We want to test it with different arguments and ensure it is returning the correct compactSize. We can do this with unit testing. So let's look into setting up our first unit test in the next section.
+Pretty neat! We're making good progress.
+But even though our code compiles, how can we be sure we've written it correctly and that this function will return the appropriate number of inputs for different transactions?
+We want to test it with different arguments and ensure it is returning the correct compactSize.
+We can do this with unit testing.
+So let's look into setting up our first unit test in the next section.
 
 ### Quiz
-*How do nodes know whether the transaction is a legacy or a segwit transaction as they read it? How do they know whether to view the next field after the version as an input length encoded as compactSize or as the marker and flag for a Segwit transaction?*
+*How do nodes know whether the transaction is a legacy or a segwit transaction as they read it?
+How do they know whether to view the next field after the version as an input length encoded as compactSize or as the marker and flag for a Segwit transaction?*
 
 <hr/>