From 801b8e8efd89da8fa75a7548d7d58efa0254279e Mon Sep 17 00:00:00 2001 From: Clare Laylock Date: Thu, 2 Nov 2023 21:21:11 -0400 Subject: [PATCH] pagebreaks for 6 --- ch06_transactions.adoc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc index 1352216b..6f5c478b 100644 --- a/ch06_transactions.adoc +++ b/ch06_transactions.adoc @@ -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 ++++ +[role="less_space pagebreak-before"] We can verify our weight calculation by getting the total for Alice's transaction from Bitcoin Core: