1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-21 23:58:09 +00:00

pagebreaks for 6

This commit is contained in:
Clare Laylock 2023-11-02 21:21:11 -04:00
parent 2a1db37e96
commit 801b8e8efd

View File

@ -637,6 +637,7 @@ node implementations such as Bitcoin Core discourage the creation of
uneconomical outputs using policies that affect the relay and mining of
unconfirmed transactions.
[role="less_space pagebreak-before"]
The policies against relaying or mining transactions creating new
uneconomical outputs are called _dust_ policies, based on a metaphorical
comparison between outputs with very small values and particles with
@ -798,7 +799,7 @@ transactions out of order:
A problem with this construction in the legacy transaction format is
that every field, including the input script field that contains
signatures, is used to derive a transaction's identifier (txid). The
signatures, is used to derive a [.keep-together]#transaction's# identifier (txid). The
txid for Tx~0~ is part of the input's outpoint in Tx~1~. That means
there's no way for Alice and Bob to construct Tx~1~ until both
signatures for Tx~0~ are known--but if they know the signatures for
@ -957,6 +958,7 @@ template must only be spent with an empty input script. Notice the
difference here: old nodes _allow_ an empty input script; new nodes
_require_ an empty input script.
[role="less_space pagebreak-before"]
An empty input script keeps witnesses from affecting the txid, eliminating
circular dependencies, third-party transaction malleability, and
second-party transaction malleability. But, with no ability to put
@ -1238,6 +1240,7 @@ creation of uneconomical outputs as described in
</table>
++++
[role="less_space pagebreak-before"]
We can verify our weight calculation by getting the total for Alice's
transaction from Bitcoin Core: