|
|
|
@ -419,7 +419,7 @@ tracked the version of the transaction.
|
|
|
|
|
|
|
|
|
|
For example, imagine Alice and Bob want to bet on a game of cards. They
|
|
|
|
|
start by each signing a transaction that deposits some money into an
|
|
|
|
|
output with a script that requires signatures from both of them to spend, a
|
|
|
|
|
output with a script that requires signatures from both of them to ((("multisignature scripts")))((("setup transactions")))spend, a
|
|
|
|
|
_multisignature_ script (_multisig_ for short). This is called the
|
|
|
|
|
_setup transaction_. They then create a transaction that spends that
|
|
|
|
|
output:
|
|
|
|
@ -466,8 +466,8 @@ alternative scenarios:
|
|
|
|
|
got lucky and a block was discovered before Alice's version arrived,
|
|
|
|
|
it's Alice's version of the transaction that will get confirmed.
|
|
|
|
|
|
|
|
|
|
This type of protocol is what we now call a _payment channel_.
|
|
|
|
|
Bitcoin's creator, in an email attributed to him, called these
|
|
|
|
|
This type of protocol is what we now ((("payment channels")))call a _payment channel_.
|
|
|
|
|
Bitcoin's creator, in an email attributed to him, called((("high-frequency transactions"))) these
|
|
|
|
|
_high-frequency transactions_ and described a number of features added to
|
|
|
|
|
the protocol to support them. We'll learn about several of those other
|
|
|
|
|
features later and also discover how modern versions of payment channels
|
|
|
|
|