OTD edits
@ -255,13 +255,7 @@ unsigned integers:
|
||||
++++
|
||||
****
|
||||
|
||||
Each input in a transaction must contain three fields:
|
||||
|
||||
- An _outpoint_ field
|
||||
|
||||
- A length-prefixed _input script_ field
|
||||
|
||||
- A _sequence_
|
||||
Each input in a transaction must contain three fields: an _outpoint_ field, a length-prefixed _input script_ field, and a _sequence_
|
||||
|
||||
We'll look at each of those fields in the following sections. Some
|
||||
inputs also include a witness stack, but this is serialized at the end of a
|
||||
@ -315,7 +309,6 @@ pieces of information from it:
|
||||
relative timelocks (described in <<relative_timelocks>>) and outputs
|
||||
of coinbase transactions (described in <<coinbase_transactions>>).
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
- Proof that the previous output exists in the blockchain (or as a known
|
||||
unconfirmed transaction) and that no other transaction has spent it.
|
||||
One of Bitcoin's consensus rules forbids any output from being spent
|
||||
@ -428,7 +421,6 @@ _multisignature_ script (_multisig_ for short). This is called the
|
||||
_setup transaction_. They then create a transaction that spends that
|
||||
output:
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
- The first version of the transaction, with nSequence 0 (0x00000000),
|
||||
pays Alice and Bob back the money they initially deposited. This is
|
||||
called a _refund transaction_. Neither of them broadcasts the refund
|
||||
|
@ -1676,7 +1676,6 @@ our tree with this knowledge as shown in <<diagram_mast3>>.
|
||||
.A MAST with the most-expected script in the best position.
|
||||
image::images/mbc3_0707.png["A MAST with the most-expected script in the best position"]
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
Now we only need to provide two commitments for the common case (saving 32
|
||||
bytes), although we still need three commitments for the less common cases.
|
||||
If you know (or can guess) the probabilities of
|
||||
|
@ -936,7 +936,7 @@ differences:
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>0</p></td>
|
||||
<td><p class="right">0</p></td>
|
||||
<td><p>6</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
@ -439,7 +439,7 @@ An extended comment in Bitcoin Core's source code, reproduced here with slight r
|
||||
significant problem in the design of Bitcoin's duplication of odd
|
||||
elements in its merkle tree:
|
||||
|
||||
[quote,Bitcoin Core _src/consensus/merkle.cpp_]
|
||||
[quote,Bitcoin Core src/consensus/merkle.cpp]
|
||||
____
|
||||
WARNING! If you're reading this because you're learning about crypto
|
||||
and/or designing a new system that will use merkle trees, keep in mind
|
||||
|
@ -939,6 +939,13 @@ slower than expected, the difficulty decreases (target increases).
|
||||
|
||||
The equation can be summarized as:
|
||||
|
||||
|
||||
[latexmath]
|
||||
++++
|
||||
\begin{equation}
|
||||
New\:Target = Old\:Target \times (20,160 minutes / Actual Time of Last 2015 Blocks)
|
||||
\end{equation}
|
||||
++++
|
||||
----
|
||||
New Target = Old Target * (20,160 minutes / Actual Time of Last 2015 Blocks)
|
||||
----
|
||||
@ -2049,6 +2056,12 @@ later.
|
||||
BIP9 offers a proposal state diagram to illustrate the various stages
|
||||
and transitions for a proposal, as shown in <<bip9states>>.
|
||||
|
||||
|
||||
[[bip9states]]
|
||||
.BIP9 state transition diagram.
|
||||
image::images/mbc3_1203.png[BIP9 Proposal State Transition Diagram]
|
||||
|
||||
|
||||
Proposals start in the +DEFINED+ state once their parameters are known
|
||||
(defined) in the Bitcoin software. For blocks with MTP after the start
|
||||
time, the proposal state transitions to +STARTED+. If the voting
|
||||
@ -2060,10 +2073,6 @@ timeout elapses before the voting threshold has been reached, the
|
||||
proposal state changes to +FAILED+, indicating a rejected proposal.
|
||||
+FAILED+ proposals remain in that state perpetually.
|
||||
|
||||
[[bip9states]]
|
||||
.BIP9 state transition diagram.
|
||||
image::images/mbc3_1203.png[BIP9 Proposal State Transition Diagram]
|
||||
|
||||
BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+
|
||||
and associated BIPs (68, 112, 113). The proposal named "csv" was
|
||||
activated successfully in July of 2016.
|
||||
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 66 KiB After Width: | Height: | Size: 66 KiB |
Before Width: | Height: | Size: 75 KiB After Width: | Height: | Size: 75 KiB |
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 166 KiB After Width: | Height: | Size: 166 KiB |
@ -67,6 +67,11 @@ section.less_space > h1:first-child {
|
||||
margin-top: 0 !important;
|
||||
|
||||
|
||||
/* right and center align options for table cells */
|
||||
.right { text-align: right; }
|
||||
|
||||
|
||||
|
||||
/*hack to align sidebars to top of page*/
|
||||
.less_space {margin-top: 0 !important;}
|
||||
|
||||
|