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