develop
Clare Laylock 6 months ago
parent c8151590cd
commit 57d6ab58e0

@ -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.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 66 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 75 KiB

After

Width:  |  Height:  |  Size: 75 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

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;}

Loading…
Cancel
Save