|
|
|
@ -1,17 +1,21 @@
|
|
|
|
|
[[tx_fees]]
|
|
|
|
|
== Transaction Fees
|
|
|
|
|
|
|
|
|
|
The digital signature we saw Alice create in <<c_signatures>> only
|
|
|
|
|
++++
|
|
|
|
|
<p class="fix_tracking">
|
|
|
|
|
The digital signature we saw Alice create in <a data-type="xref" href="#c_signatures">#c_signatures</a> only
|
|
|
|
|
proves that she knows her private key and that she committed to a
|
|
|
|
|
transaction that pays Bob. She can create another signature that
|
|
|
|
|
instead commits to a transaction paying Carol--a transaction that spends
|
|
|
|
|
the same output (bitcoins) that she used to pay Bob. Those two
|
|
|
|
|
transactions((("conflicting transactions")))((("transactions", "conflicts in"))) are now _conflicting transactions_ because only one
|
|
|
|
|
transactions are now <em>conflicting transactions</em> because only one
|
|
|
|
|
transaction spending a particular output can be included in the valid
|
|
|
|
|
blockchain with the most proof of work--the blockchain that full nodes
|
|
|
|
|
use to determine which keys control which bitcoins.
|
|
|
|
|
</p>
|
|
|
|
|
++++
|
|
|
|
|
|
|
|
|
|
To protect himself against conflicting transactions, it would be wise
|
|
|
|
|
To((("conflicting transactions")))((("transactions", "conflicts in"))) protect himself against conflicting transactions, it would be wise
|
|
|
|
|
for Bob to wait until the transaction from Alice is included in the
|
|
|
|
|
blockchain to a sufficient depth before he considers the money he
|
|
|
|
|
received as his to spend (see <<confirmations>>).
|
|
|
|
|