You've already forked specification
Merge remote-tracking branch 'upstream/master'
This commit is contained in:
Christopher-Zeng
@@ -0,0 +1,106 @@
|
||||
# Chainwork Proof
|
||||
|
||||
The idea of chainwork is intrinsic to blockchains. Nodes switch to the chain tip with the most cumulative "work" to help preserve the blockchain assumption that the majority of the miners on a chain are honest. Chainwork is calculated by summing the "work" done in each block in the chain.
|
||||
|
||||
Is summing work a valid operation?
|
||||
|
||||
More formally, *is the expected number of hashes to solve one block candidate with work W is equal to the expected number of hashes to solve N block candidates with work W/N?*
|
||||
|
||||
## Warm-up
|
||||
|
||||
For every block candidate, a target (specified in a nonstandard floating point form in the block header as 'nBits') is calculated. Any hash less than this target solves the block. Under the random oracle model (that is, assuming that cryptographic hash functions produce unpredictable output), this is equivalent to rolling a $2^{256}$ sided die with any number less than or equal to the target resulting in a "win". The probability of this is:
|
||||
|
||||
$$
|
||||
P(target) = (target + 1)/2^{256} \tag1
|
||||
$$
|
||||
|
||||
*We add one to target because the number range of target is from 0 to $2^{256}-1$, rather than 1 to $2^{256}$.*
|
||||
|
||||
Equation 1 is about the target, but we sum work. We need the relationship between work and target which is defined in the code as follows:
|
||||
|
||||
$$
|
||||
work = 2^{256}/ (target + 1)
|
||||
$$
|
||||
|
||||
or, solving for target:
|
||||
|
||||
$$
|
||||
T(work) = (2^{256}/work) -1 \tag2
|
||||
$$
|
||||
|
||||
Finally we need an equation from general statistics. The expected number of trials before a success for such a random variable is given by (see [wikipedia](https://en.wikipedia.org/wiki/Geometric_distribution#Properties)):
|
||||
|
||||
$$
|
||||
E(probability\_of\_success) = 1/probability\_of\_success \tag3
|
||||
$$
|
||||
|
||||
'Trials' in our case are individual attempts to solve a block. So if the expected number of trials of two different processes are the same then we can say those two processes would take the same amount of work (on average).
|
||||
|
||||
## Proof
|
||||
|
||||
Recall our question "*is the expected number of hashes to solve one block candidate with work W is equal to the expected number of hashes to solve N block candidates with work W/N?*"
|
||||
|
||||
With the above definitions this can be expressed in mathematical notation:
|
||||
|
||||
$$
|
||||
E(P(T(work))) \stackrel{?}{=} n * E(P(T(work/n))) \tag4
|
||||
$$
|
||||
|
||||
With all of our preparation, this proof is easy. But I'll go through each step to make it convenient to read along.
|
||||
|
||||
First we'll replace the functions with their defintions on the left side **to prove that what the blockchain community calls "work" is the expected number of hashes**.
|
||||
|
||||
$$
|
||||
E(P(T(work))) = E(P((2^{256}/work) -1))
|
||||
$$
|
||||
|
||||
$$
|
||||
= E(((2^{256}/work) -1 + 1)/2^{256})
|
||||
$$
|
||||
|
||||
$$
|
||||
= E((2^{256}/work)/2^{256})
|
||||
$$
|
||||
|
||||
$$
|
||||
= E(1/work)
|
||||
$$
|
||||
|
||||
$$
|
||||
= work
|
||||
$$
|
||||
|
||||
|
||||
Second we'll do the same on the right side and simplify to prove that the result is the same:
|
||||
|
||||
First, substitute the definition of T() (eqn 2):
|
||||
|
||||
$$
|
||||
n * E(P(T(work/n))) = n * E(P((n*2^{256}/work) -1)
|
||||
$$
|
||||
|
||||
Next, substitute the definition of P() (eqn 1):
|
||||
|
||||
$$
|
||||
= n * E( ((n*2^{256}/work))/2^{256})
|
||||
$$
|
||||
|
||||
Third, substitute the defintion of E() (eqn 3):
|
||||
|
||||
$$
|
||||
= \dfrac{n}{\frac{(n*2^{256}/work )}{2^{256}}}
|
||||
$$
|
||||
|
||||
Finally, simplify:
|
||||
|
||||
$$
|
||||
= \dfrac{n*2^{256}} {(n*2^{256}/work)}
|
||||
$$
|
||||
|
||||
$$
|
||||
= \dfrac{n*2^{256}*work} {n*2^{256}}
|
||||
$$
|
||||
|
||||
$$
|
||||
= work
|
||||
$$
|
||||
@@ -24,9 +24,10 @@ Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be
|
||||
- `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
|
||||
- `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
|
||||
|
||||
In contrast to many hashing algorithm implementations, Bitcoin Cash block and transaction hashes use a little-endian representation.
|
||||
This means they are displayed and sent over the network with the least-significant byte first.
|
||||
And ultimately permits a block hash stored in memory to be interpreted without swapping endianness for integer operations such as the comparison with the block difficulty during block validation or mining.
|
||||
In contrast to many other protocols, Bitcoin Cash sometimes treats block and transaction hashes as a number, for example when comparing with block difficulty during block validation or mining.
|
||||
In these situations, the output byte array of the hashing algorithm is interpreted as a 256 bit number in little-endian format, particularly when transmitted over the network.
|
||||
This is the opposite of standard protocol design, so it may be simpler to think of hashes as byte arrays that occasionally are turned into little-endian numbers, than as numbers with a lot of display/encoding caveats.
|
||||
|
||||
## RIPEMD-160
|
||||
[RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.
|
||||
Since its brevity is also a potential liability for the anonymity it provides (since shorter hashes generally provide less collision-resistance), it is used in conjunction with SHA-256 when generating an address from a public key.
|
||||
@@ -35,4 +36,4 @@ This SHA-256 then RIPEMD-160 process has its own operation for ease-of-use, [OP_
|
||||
## Murmur
|
||||
|
||||
[MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter).
|
||||
The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer.
|
||||
The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer.
|
||||
|
||||
@@ -22,14 +22,25 @@ For more details on how the target is calculated, see [Difficulty Adjustment Alg
|
||||
|
||||
## Difficulty
|
||||
|
||||
Though the term difficulty is often used colloquially to refer generally to the changes to the target as blocks are mined, it can also refer specifically to the integer value of one target divided by another. Generally, the numerator is a base target, e.g. the [genesis block](/protocol/blockchain#genesis-block) target, while the denominator is the target of the block whose "difficulty" is to be calculated. This results in two benefits relative to using targets directly:
|
||||
Though the term difficulty is often used colloquially to refer generally to the changes to the target as blocks are mined, it can also refer specifically to the integer value of one target divided by another.
|
||||
Generally, the numerator is a base target, e.g. the [genesis block](/protocol/blockchain#genesis-block) target, while the denominator is the target of the block whose "difficulty" is to be calculated.
|
||||
This results in two benefits relative to using targets directly:
|
||||
|
||||
- **More Intuitive:** Higher numbers mean the block required more hashing power to mine, while lower number mean less hashing power was required. Increased difficulty is easier to understand than decreased target, even though these means the same thing.
|
||||
- **More Manageable:** The difficulty calculation produces much more human-readable numbers than trying to interpret targets as an integer directory.
|
||||
|
||||
## Chainwork
|
||||
|
||||
Chainwork is a representation of the work performed through a block's entire history. It is calculated using the difficulties of each of the blocks in the chain. The work for a single block is calculated as <code>2<sup>256</sup> / (target + 1)</code>, or equivalently in 256-bit two's-complement arithmetic, <code>(~target / (target + 1)) + 1</code>, where `~` is the bitwise NOT operation. The chainwork for a block is the sum of its work with the work of all the blocks preceeding it. As such, when a new block is mined, its chainwork is simply its work plus the chainwork of the block before it.
|
||||
Chainwork is a representation of the work performed through a block's entire history.
|
||||
It is the [expected](https://en.wikipedia.org/wiki/Expected_value) number of hashes required to re-solve every block in the chain.
|
||||
It is calculated using the difficulties of each of the blocks in the chain.
|
||||
The work for a single block is calculated as <code>2<sup>256</sup> / (target + 1)</code>, or equivalently in 256-bit two's-complement arithmetic, <code>(~target / (target + 1)) + 1</code>, where `~` is the bitwise NOT operation.
|
||||
The chainwork for a block is the sum of its work with the work of all the blocks preceeding it.
|
||||
As such, when a new block is mined, its chainwork is simply its work plus the chainwork of the block before it.
|
||||
|
||||
This algorithm implies that summing chainwork makes sense.
|
||||
More formally, the expected number of hashes to solve one block candidate with work `W` is equal to the expected number of hashes to solve `N` block candidates with work `W/N`.
|
||||
This, and that chainwork is the expected number of hashes, is proved [here](/protocol/blockchain/chainwork-proof).
|
||||
|
||||
## Extra Nonce
|
||||
|
||||
@@ -40,4 +51,4 @@ As a result, there was a need for additional data to be varied.
|
||||
The only other parameter of the block header that a miner has any power over is the merkle root.
|
||||
In order to change the merkle root, the transactions in the block would need to be changed.
|
||||
But since the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction) is already created by the miner of the block, and updating its hash would allow for efficient re-calculation of the merkle root, putting this "extra nonce" in the coinbase transaction was the logical conclusion.
|
||||
Ultimately, the extra nonce is included as a part of the coinbase message, usually following the block height that is required to be first.
|
||||
Ultimately, the extra nonce is included as a part of the coinbase message, usually following the block height that is required to be first.
|
||||
|
||||
@@ -18,7 +18,7 @@ Verification of a transaction ensures that:
|
||||
| transaction inputs | variable | `input_count` [transaction inputs](#transaction-inputs) | Each of the transaction's inputs serialized in order. |
|
||||
| output count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of output in the transaction. |
|
||||
| transaction outputs | variable | `output_count` [transaction outputs](#transaction-outputs) | Each of the transaction's outputs serialized in order. |
|
||||
| lock-time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The block height or timestamp after which this transaction is allowed to be included in a block. If less than `500,000,000`, this is interpreted as a block height. If equal or greater than `500,000,000`, this is interpreted as a unix timestamp in seconds. If less than zero, this is interpreted as an error. Ignored, including less than zero case, if all of the transaction input sequence numbers are `0xFFFFFFFF`.<br/><br/>Note that at 10 minutes per block, it will take over 9,500 years to reach block height 500,000,000. Also note that when Bitcoin was created the unix timestamp was well over 1,000,000,000.<br/><br/>Additionally, since [BIP-113](/protocol/forks/bip-0113), when the lock-time is intepreted as a time, it is compared to the [median-time-past](#median-time-past) of a block, not it's timestamp. |
|
||||
| lock-time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The block height or timestamp after which this transaction is allowed to be included in a block. If less than `500,000,000`, this is interpreted as a block height. If equal or greater than `500,000,000`, this is interpreted as a unix timestamp in seconds. Ignored if all of the transaction input sequence numbers are `0xFFFFFFFF`.<br/><br/>Note that at 10 minutes per block, it will take over 9,500 years to reach block height 500,000,000. Also note that when Bitcoin was created the unix timestamp was well over 1,000,000,000.<br/><br/>Additionally, since [BIP-113](/protocol/forks/bip-0113), when the lock-time is intepreted as a time, it is compared to the [median-time-past](#median-time-past) of a block, not it's timestamp. |
|
||||
|
||||
### Median-Time-Past
|
||||
|
||||
@@ -74,7 +74,7 @@ A Transaction Output that is being spent by a Transaction Input is often referre
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
|
||||
| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the unlocking script in bytes. |
|
||||
| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the locking script in bytes. |
|
||||
| locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
|
||||
|
||||
## Transaction Fee
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
|
||||
# Transaction Signatures
|
||||
|
||||
Transaction signatures are central to how [Bitcoin Cash transactions](/protocol/blockchain/transaction) are generally secured, preventing people other than the intended recipient of funds from spending them. Bitcoin Cash signatures are created using [asymmetric cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) and involve generating a [hash](/protocol/blockchain/hash) of the transaction and performing a signature operation using the sender's private key. Anyone with the corresponding public key can then verify the validity of the signature. As described in [Standard Scripts](/protocol/blockchain/transaction/locking-script#standard-scripts), the [OP_CHECKSIG and related operations](/protocol/blockchain/script#cryptography) are used to validate signatures included in the unlocking script of a future transaction input.
|
||||
|
||||
However, there are a number of issues with signing a transaction that must be addressed:
|
||||
|
||||
1. Transactions are identified by hashes of the full contents of the transaction
|
||||
2. The signatures are a part of the transaction data
|
||||
3. The signatures are created from a hash of the transaction's data
|
||||
|
||||
Points (1) and (2) mean that if the signature is changed, the transaction's hash will change. Points (2) and (3) mean that the data that the signature hash preimage (i.e. the data that is hashed and signed) must not be the full transaction data. In addition, because signatures relate only to a single input to a transaction (i.e. spending an unspent transaction output or UTXO) the may be multiple signatures in a transaction potentially created by different private keys, or even different people.
|
||||
|
||||
As a consequence of these factors, signatures have more parameters than may be immediately obvious, and the details of how signatures are generated can be, and have been, changed in a number of ways. These parameters are encoded in the [Hash Type](#hash-type).
|
||||
|
||||
In addition, as a part of [BCH-UAHF](/protocol/forks/bch-uahf) (activated in block 478,559), the transaction signed format changed from the legacy [Bitcoin (BTC) method](#btc-signatures) to the [Bitcoin Cash (BCH) Signatures](#bch-signatures). In both cases, there is a signature preimage format (input) and a signature format (output).
|
||||
|
||||
### Hash Type
|
||||
|
||||
Parameters that change the way a signature hash is generated are encoded in the hash type field.
|
||||
This field (which is always included in the preimage), is contained in 4 bytes.
|
||||
The two least significant bits have the following collective meaning:
|
||||
|
||||
| Value | Meaning |
|
||||
|--|--|
|
||||
| `0x01` | `SIGHASH_ALL`. This is the default and indicates that all outputs are included in the signature preimage. |
|
||||
| `0x02` | `SIGHASH_NONE`. Indicates that no outputs are included in the signature preimage. |
|
||||
| `0x03` | `SIGHASH_SINGLE`. Indicates that only the output with the same index as the input the signature is being generated for will be included in the signature preimage. |
|
||||
|
||||
In conjunction with the above values, the higher-order bits act as a bitmask with the following meaning:
|
||||
|
||||
| Bit | Meaning |
|
||||
|--|--|
|
||||
| `0x00000040` | `SIGHASH_FORKID`. If set, indicates that this signature is for a Bitcoin Cash transaction. Required following BCH-UAHF, to prevent transactions from being valid on both the BTC and BCH chains. |
|
||||
| `0x00000080` | `SIGHASH_ANYONECANPAY`. Indicates that only information about the input the signature is for will be included, allowing other inputs to be added without impacting the signature for the current input. |
|
||||
|
||||
Combining these, there are 6 valid signature hash types in Bitcoin Cash. Only the least significant byte (LSB) is shown in binary, since the rest of the bits are zero.
|
||||
|
||||
| Signature hash type | Value (hex) | LSB (bin) | Description |
|
||||
| -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- |
|
||||
| SIGHASH_ALL \| SIGHASH_FORKID | 0x00000041 | 0b01000001 | Signature applies to all inputs and outputs. |
|
||||
| SIGHASH_NONE \| SIGHASH_FORKID | 0x00000042 | 0b01000010 | Signature applies to all inputs and none of the outputs. |
|
||||
| SIGHASH_SINGLE \| SIGHASH_FORKID | 0x00000043 | 0b01000011 | Signature applies to all inputs and the output with the same index. |
|
||||
| SIGHASH_ALL \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C1 | 0b11000001 | Signature applies to its own input and all outputs. |
|
||||
| SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C2 | 0b11000010 | Signature applies to its own input and none of the outputs. |
|
||||
| SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C3 | 0b11000011 | Signature applies to its own input and the output with the same index.|
|
||||
|
||||
## BCH Signatures
|
||||
|
||||
In Bitcoin Cash, transaction signature uses the transaction digest algorithm described in [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), in order to minimize redundant data hashing in verification and to cover the input value by the signature.
|
||||
|
||||
### Preimage Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| transaction version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of transaction's version field. |
|
||||
| previous outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of previous outputs spent by the inputs of the transaction. See [Previous Outputs](#previous-outputs-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes. |
|
||||
| sequence numbers hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of sequence numbers of the inputs of the transaction. See [Sequence Numbers](#sequence-numbers-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes. |
|
||||
| previous output hash | 32 bytes | hash<sup>[(LE)](/protocol/misc/endian/little)</sup> | The transaction ID of the previous output being spent. |
|
||||
| previous output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent. |
|
||||
| modified locking script length | variable | [variable length integer](/protocol/format/variable-length-integer) | The number of bytes for `modified_locking_script`. |
|
||||
| modified locking script | `modified_locking_script_length` bytes | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The subset of the locking script used for signing. See [Modified Locking Script](#modified-locking-script) |
|
||||
| previous output value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of the transaction output being spent. |
|
||||
| input sequence number | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number of the input this signature is for. |
|
||||
| transaction outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the outputs of the transaction. See [Transaction Outputs](#transaction-outputs-hash) for the hash preimage format. |
|
||||
| transaction lock time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The lock time of the transaction. |
|
||||
| hash type | 4 bytes | [Hash Type](#hash-type)<sup>[(LE)](/protocol/misc/endian/little)</sup> | Flags indicating the rules for how this signature was generated. |
|
||||
|
||||
#### Previous Outputs Hash
|
||||
|
||||
The double-SHA256-hash of the following data is used.
|
||||
|
||||
For each transaction input in the transaction, append the following information:
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| previous transaction hash | 32 bytes | bytes<sup>[(LE)](/protocol/misc/endian/little)</sup> | The hash of the transaction that generated the output to be spent. |
|
||||
| output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent from the specified transaction. |
|
||||
|
||||
#### Sequence Numbers Hash
|
||||
|
||||
The double-SHA256-hash of the following data is used.
|
||||
|
||||
For each transaction input in the transaction, append the following information:
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number field of the transaction input. |
|
||||
|
||||
#### Modified Locking Script
|
||||
|
||||
The locking script included in the signature preimage is, first, dependent on the type of locking script included in the previous output. For non-[P2SH](/protocol/blockchain/transaction/locking-script#pay-to-script-hash-p2sh) outputs, the locking script itself is used. However, for P2SH outputs, the redeem script is used instead.
|
||||
|
||||
Second, the selected script (locking script or redeem script) is modified as follows.
|
||||
|
||||
* Find the [`OP_CODESEPARATOR`](/protocol/blockchain/script#cryptography) operation in the script preceding the expected [signature-verification operation](/protocol/blockchain/script#cryptography) (e.g. `OP_CHECKSIG`).
|
||||
* Remove all operations before this point.
|
||||
* Remove any remaining `OP_CODESEPARATOR` operations.
|
||||
|
||||
The resulting script is what is included in the signature preimage.
|
||||
|
||||
#### Transaction Outputs Hash
|
||||
|
||||
If the hash type is `SIGHASH_NONE` then the hash should be all `0x00` bytes.
|
||||
|
||||
If hash type is `SIGHASH_SINGLE` then only the output with the same index as the input being signed is included.
|
||||
If no such output exists (i.e. there are fewer outputs than the index of the input to be signed), this is again all `0x00` bytes.
|
||||
|
||||
Otherwise, all outputs of the transaction should be signed (i.e. `SIGHASH_ALL`).
|
||||
|
||||
For each transaction output to be signed (per the hash mode), append the following information:
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
|
||||
| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the locking script in bytes. |
|
||||
| locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
|
||||
|
||||
### Signature Format
|
||||
|
||||
|
||||
|
||||
## BTC Signatures
|
||||
|
||||
|
||||
### Preimage Format
|
||||
|
||||
|
||||
### Signature Format
|
||||
|
||||
@@ -5,4 +5,4 @@ This is accomplished by first executing the unlocking script and then executing
|
||||
If this execution triggers no failures and leaves a single non-zero (TRUE) value on the stack, the UTXO has been successfully unlocked.
|
||||
One way to look at this is that the unlocking script provides an initial state that acts as an inverse to the previously published locking script.
|
||||
|
||||
For more information about how script execution works, see [Script](/protocol/blockchain/script).
|
||||
For more information about how script execution works, see [Script](/protocol/blockchain/script). For information on how signatures (which typically go in the unlocking script) are generated, see [Transaction Signatures](/protocol/blockchain/transaction/signatures).
|
||||
|
||||
Reference in New Issue
Block a user