present time (payment) to a future time (when it is spent).
- P2SH shifts the transaction fee cost of a long script from the sender
to the recipient, who has to include the long redeemScript to spend
to the recipient, who has to include the long redeem script to spend
it.
==== RedeemScript and Validation
==== RedeemScript and Validation
You are not able to put a P2SH inside a P2SH redeemScript, because the
You are not able to put a P2SH inside a P2SH redeem script, because the
P2SH specification is not recursive. Also, while it is technically
possible to include +OP_RETURN+ (see <<op_return>>) in a redeemScript, as
possible to include +OP_RETURN+ (see <<op_return>>) in a redeem script, as
nothing in the rules prevents you from doing so, it is of no practical
use because executing +OP_RETURN+ during validation will cause the
transaction to be marked invalid.
Note that because the redeemScript is not presented to the network
Note that because the redeem script is not presented to the network
until you attempt to spend a P2SH output, if you create an output with the
hash of an invalid redeemScript, you will not be able to spend
it. The spending transaction, which includes the redeemScript,
hash of an invalid redeem script, you will not be able to spend
it. The spending transaction, which includes the redeem script,
will not be accepted because it is an invalid script. This creates a
risk, because you can send bitcoin to a P2SH address that cannot be spent later.
[WARNING]
====
((("warnings and cautions", "accidental bitcoin invalidation")))P2SH scriptPubKeys
contain the hash of a redeemScript, which gives no clues as to
the content of the redeemScript. The P2SH transaction will be
considered valid and accepted even if the redeemScript is invalid. You
((("warnings and cautions", "accidental bitcoin invalidation")))P2SH output scripts
contain the hash of a redeem script, which gives no clues as to
the content of the redeem script. The P2SH transaction will be
considered valid and accepted even if the redeem script is invalid. You
might accidentally receive bitcoin in such a way that it cannot later be
spent.
====
@ -763,7 +763,7 @@ from the UTXO set and cause the size of the UTXO database to forever
increase, or "bloat."
A compromise was reached
that allows a scriptPubKey starting with +OP_RETURN+ to
that allows an output script starting with +OP_RETURN+ to
add nonpayment data to a transaction output. However, unlike
the use of "fake" UTXOs, the +OP_RETURN+ operator creates an explicitly
_provably unspendable_ output, which does not need to be stored in the
@ -787,7 +787,7 @@ http://proofofexistence.com[Proof of Existence] digital notarization
service uses the 8-byte prefix +DOCPROOF+, which is ASCII encoded as +44
4f 43 50 52 4f 4f 46+ in hexadecimal.
Keep in mind that there is no scriptSig that corresponds to
Keep in mind that there is no input script that corresponds to
+OP_RETURN+ that could possibly be used to "spend" an +OP_RETURN+ output. The
whole point of an +OP_RETURN+ output is that you can't spend the money locked in that
output, and therefore it does not need to be held in the UTXO set as
@ -801,22 +801,22 @@ script to "RETURN" with a +FALSE+ and halt. Thus, if you accidentally
reference a +OP_RETURN+ output as an input in a transaction, that
transaction is invalid.
[[locktime_limitations]]
==== Transaction locktime limitations
[[lock_time_limitations]]
==== Transaction locktime limitations
+nLockTime+ has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.
Lock time has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.
((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction +nLockTime+ to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
* Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
* Bob may transmit the transaction after 3 months.
However:
* Alice can create another transaction, double-spending the same inputs without a locktime. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Alice can create another transaction, double-spending the same inputs without a locktime. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Bob has no guarantee that Alice won't do that.
It is important to understand the limitations of transaction +nLockTime+. The only guarantee is that Bob will not be able to redeem it before 3 months have elapsed. There is no guarantee that Bob will get the funds. To achieve such a guarantee, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem it before 3 months have elapsed. There is no guarantee that Bob will get the funds. To achieve such a guarantee, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
==== Check Lock Time Verify (OP_CLTV)
@ -828,7 +828,7 @@ timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
specification in BIP65, a new script operator called
_OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
+OP_CLTV+ is a per-output timelock, rather than a per-transaction timelock
as is the case with +nLockTime+. This allows for much greater
as is the case with lock time. This allows for much greater
flexibility in the way timelocks are applied.
In simple terms, by committing to the +OP_CLTV+ opcode in an
@ -837,21 +837,21 @@ specified time has elapsed.
[TIP]
====
While +nLockTime+ is a transaction-level timelock, +OP_CLTV+ is an
While lock time is a transaction-level timelock, +OP_CLTV+ is an
output-based timelock.
====
+OP_CLTV+ doesn't replace +nLockTime+, but rather restricts specific UTXO
+OP_CLTV+ doesn't replace lock time, but rather restricts specific UTXO
such that they can only be spent in a future transaction with
+nLockTime+ set to a greater or equal value.
lock time set to a greater or equal value.
The +OP_CLTV+ opcode takes one parameter as input, expressed as a number in
the same format as +nLockTime+ (either a block height or Unix epoch
the same format as lock time (either a block height or Unix epoch
time). As indicated by the +VERIFY+ suffix, +OP_CLTV+ is the type of opcode
that halts execution of the script if the outcome is +FALSE+. If it
results in TRUE, execution continues.
In order to use +OP_CLTV+, you insert it into the redeemScript of the
In order to use +OP_CLTV+, you insert it into the redeem script of the
output in the transaction that creates the output. For
example, if Alice is paying Bob's address, the output would normally
A Bitcoin address looks like +1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV+. It consists of a string of letters and numbers. It's really an encoded base58check version of a public key 160-bit hash. Just as you ask others to send an email to your email address, you would ask others to send you bitcoin to one of your Bitcoin addresses.
bip::
Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP-21 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.
Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP21 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.
bitcoin::
The name of the currency unit (the coin), the network, and the software.
@ -107,8 +107,8 @@ LevelDB::
Lightning Networks::
Lightning Network is a proposed implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.
Locktime::
Locktime, or more technically nLockTime, is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.
Locktime::
Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.
mempool::
The bitcoin Mempool (memory pool) is a collection of all transaction data in a block that have been verified by Bitcoin nodes, but are not yet confirmed.
@ -165,10 +165,10 @@ P2SH address::
P2SH addresses are Base58Check encodings of the 20-byte hash of a script, P2SH addresses use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". P2SH addresses hide all of the complexity, so that the person making a payment does not see the script.
P2WPKH::
The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified.
The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness structure instead of the input script. The output script is also modified.
P2WSH::
The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is about the cryptographic proof location change from the scriptSig field to the witness field and the scriptPubKey that is also modified.
The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is about the cryptographic proof location change from the input script to the witness structure and the output script that is also modified.
paper wallet::
In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes.
@ -200,11 +200,11 @@ Satoshi Nakamoto::
Script::
Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
ScriptPubKey (aka pubkey script)::
ScriptPubKey or pubkey script, is a script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script.
Output script::
A script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script.
ScriptSig (aka signature script)::
ScriptSig or signature script, is the data generated by a spender which is almost always used as variables to satisfy a pubkey script.
Input script::
The data generated by a spender which is almost always used as variables to satisfy an output script.
secret key (aka private key)::
The secret number that unlocks bitcoin sent to the corresponding address. pass:[<span class="keep-together">A secret</span>] key looks like the following: