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: