From 1c388d08808cb69ad12a7cd35563f347d1e745d0 Mon Sep 17 00:00:00 2001 From: qpj9q686j0lkck93nvex8dgu6cdtwmp7xch2wlqmmj Date: Tue, 7 Jul 2020 23:18:27 +0000 Subject: [PATCH 01/47] wiki commit From b1e424b7272f5e385ad37fe36c86eb485e060d29 Mon Sep 17 00:00:00 2001 From: qpj9q686j0lkck93nvex8dgu6cdtwmp7xch2wlqmmj Date: Tue, 7 Jul 2020 23:18:35 +0000 Subject: [PATCH 02/47] wiki commit From cb237daa4c7c1077b209dd668f514b267e3acd28 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 10 Jul 2020 15:52:16 +0000 Subject: [PATCH 03/47] wiki commit From b1d09630d521bcdf3accf8cac542fd4daec50a8d Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 10 Jul 2020 15:52:21 +0000 Subject: [PATCH 04/47] wiki commit From 490c7b906cac2c84b6b8135baf49aaaecb68118d Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 10 Jul 2020 16:25:47 +0000 Subject: [PATCH 05/47] wiki commit From 9cf82286c991feafb297ff05b2b74f6b25c621e0 Mon Sep 17 00:00:00 2001 From: qz0d57rhar22dmrwr57xrn2psqt3f7pfwyerrpesge Date: Fri, 10 Jul 2020 20:56:39 +0000 Subject: [PATCH 06/47] wiki commit From b8d276d93e60af0a0700f3739c8c3ee192aff2f2 Mon Sep 17 00:00:00 2001 From: Skynow Date: Mon, 13 Jul 2020 03:08:55 +0000 Subject: [PATCH 07/47] wiki commit From 6a7eac0d0a911938193d05b0dac16546c4274060 Mon Sep 17 00:00:00 2001 From: qz0d57rhar22dmrwr57xrn2psqt3f7pfwyerrpesge Date: Tue, 14 Jul 2020 00:05:45 +0000 Subject: [PATCH 08/47] wiki commit From 4c2fd192157066a1479edd812409dfcf61ee7b91 Mon Sep 17 00:00:00 2001 From: Skynow Date: Wed, 15 Jul 2020 16:01:26 +0000 Subject: [PATCH 09/47] wiki commit From bc2713b775244a4d8ce43aab2636e49b756b5042 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 16:31:55 +0000 Subject: [PATCH 10/47] wiki commit From c964a7c96dc7f8c6c05cfc8c231a82f2ad1b04ca Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 16:32:57 +0000 Subject: [PATCH 11/47] wiki commit From 677332c4bc8589f18f32b6ba1079cd7d7f60ff67 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 16:50:02 +0000 Subject: [PATCH 12/47] wiki commit From 20ec81d80c5b5122a2e425373475cbbcf4da11ae Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 17:09:57 +0000 Subject: [PATCH 13/47] wiki commit From 9717a84e3bb5a1b2d6b7441e4554fc2faa08c505 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 17:18:12 +0000 Subject: [PATCH 14/47] wiki commit From 2a4e56889a2dc2a77ad0465f2486923f6a589eb1 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 17:18:35 +0000 Subject: [PATCH 15/47] wiki commit From 21e05256b56eb0e00867e9f0f36c93cd32db6ec6 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sat, 18 Jul 2020 18:08:09 +0000 Subject: [PATCH 16/47] wiki commit From 54db5f90ccad9499cc070b18c0ee5452e2c1f9f2 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Mon, 20 Jul 2020 14:33:50 +0000 Subject: [PATCH 17/47] wiki commit From 48bb74cc882085672f1c8d857fb6b9316f9cd83b Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Wed, 22 Jul 2020 01:25:55 +0000 Subject: [PATCH 18/47] wiki commit From d3b2d2536a3bfd0d87b6a999b464c48a72dcdc3d Mon Sep 17 00:00:00 2001 From: Skynow Date: Thu, 23 Jul 2020 00:08:18 +0000 Subject: [PATCH 19/47] wiki commit From e6fdd16fa3d4782ae6da2a175c2ef6d7ea8779d0 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 23 Jul 2020 14:23:45 +0000 Subject: [PATCH 20/47] wiki commit From cd837e3d3dd2d4f365a69f1e0d3a3349ea10e3f6 Mon Sep 17 00:00:00 2001 From: Skynow Date: Thu, 23 Jul 2020 20:22:45 +0000 Subject: [PATCH 21/47] wiki commit From 93d86012b624cf2764218c4dd9736e048a3cc7d3 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Wed, 29 Jul 2020 20:05:35 +0000 Subject: [PATCH 22/47] wiki commit From f646dd0c43e5c1a251eb9f501c6e96cf3aa4b3b5 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 30 Jul 2020 02:45:27 +0000 Subject: [PATCH 23/47] wiki commit From c938c3167ef996761f2e2ecba46cb17573ff3e80 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 31 Jul 2020 20:59:13 +0000 Subject: [PATCH 24/47] wiki commit From 00d1b1c91eff2b045dc6dc34a9b23694b5d5772b Mon Sep 17 00:00:00 2001 From: Skynow Date: Mon, 3 Aug 2020 22:07:53 +0000 Subject: [PATCH 25/47] wiki commit From 82f5d6ae1fcb405458bedd30f8b37503bfd40009 Mon Sep 17 00:00:00 2001 From: Skynow Date: Thu, 6 Aug 2020 18:41:04 +0000 Subject: [PATCH 26/47] wiki commit From af049e9944ea914b76d37ba95f78f5107d23b53f Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Wed, 12 Aug 2020 20:47:25 +0000 Subject: [PATCH 27/47] wiki commit From 4a4b534a1865c505bdd47222285ca4f8e6c6deda Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Tue, 18 Aug 2020 22:59:16 +0000 Subject: [PATCH 28/47] wiki commit From 38fd9935ee54e2a27b690a28d9b92a4325f87250 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Tue, 18 Aug 2020 23:01:44 +0000 Subject: [PATCH 29/47] wiki commit From c3d29a7c08d7319166860f1ca514cae3a38f0227 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 28 Aug 2020 14:55:30 +0000 Subject: [PATCH 30/47] wiki commit From 1a10c6685f4d0f0ebc76bbedbf540b7d97e2848e Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Mon, 31 Aug 2020 16:47:34 +0000 Subject: [PATCH 31/47] wiki commit From 56448102855150cee1f5a30c8c99aff943cd63cc Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Mon, 31 Aug 2020 16:49:43 +0000 Subject: [PATCH 32/47] wiki commit From 1ec8bee70103a53ef1d927549b47a4eeaafd50c6 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Wed, 2 Sep 2020 00:38:37 +0000 Subject: [PATCH 33/47] wiki commit From c2595f8e5ecd4d89039f79be38e59328c051cf99 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Sun, 6 Sep 2020 12:13:31 +0000 Subject: [PATCH 34/47] wiki commit From bab7a9600080e12f7a853924d57e1a538d50f231 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Mon, 14 Sep 2020 13:30:23 +0000 Subject: [PATCH 35/47] wiki commit From fff6559bb749536fd009e4e0d903015fdbd0410e Mon Sep 17 00:00:00 2001 From: lugaxker Date: Sat, 26 Sep 2020 16:43:09 +0200 Subject: [PATCH 36/47] Create the transaction signature page. --- .../transaction/transaction-signature.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 protocol/blockchain/transaction/transaction-signature.md diff --git a/protocol/blockchain/transaction/transaction-signature.md b/protocol/blockchain/transaction/transaction-signature.md new file mode 100644 index 0000000..727730d --- /dev/null +++ b/protocol/blockchain/transaction/transaction-signature.md @@ -0,0 +1,65 @@ +# Transaction signature + +Generally, every input of a [transaction](/protocol/blockchain/transaction) must contain one or more signatures so that the transaction is valid. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. + +In scripts using these opcodes, *signatures* are checked against *public keys*. + +The `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` opcodes require a sigle signature which is checked against a single public key: + +``` + CHECKSIG(VERIFY) +``` + +For `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` behavior, see [Multisignature spec](/protocol/blockchain/cryptography/multisignature). + +## Transaction digest algorithm (preimage format) + +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. + +Since it is impossible to sign signatures themselves, it is necessary to have a *preimage* which represents the transaction without signatures. Therefore, a preimage must be built for any input which requires a transaction signature. + +The preimage consists of the following elements: + +| Field | Length | Format | Description | +| ----------------------------------- | -------- | -------------------------------------------------------------------- | ----------------------------------------------------------- | +| version | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The version of the transaction format. Must be `1` or `2`. | +| previous outputs hash | 32 bytes | hash[(BE)](/protocol/misc/endian/big) | The double SHA256 of the serialization of **all** input outpoints (txids + indexes) of the transaction. If the `SIGHASH_ANYONECANPAY` flag is set, it is `0x00...00`. | +| sequences hash | 32 bytes | hash[(BE)](/protocol/misc/endian/big) | The double SHA256 of the serialization of **all** input sequences of the transaction. If `SIGHASH_ANYONECANPAY`, `SIGHASH_SINGLE` or `SIGHASH_NONE` is used, this field is `0x00...00`. | +| previous output transaction id | 32 bytes | hash[(LE)](/protocol/misc/endian/big) | The identifier of the transaction containing the previous output, i.e., the output spent by this input. | +| previous output index | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The index of the previous output inside the transaction. | +| previous output locking script size | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the previous locking script in bytes. | +| previous output locking script | variable | bytes[(BE)](/protocol/misc/endian/big) | The locking script of the output spent by this input. If the previous output is a P2SH output, then this field must be the redeem script. | +| previous output value | 8 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The value in satoshis of the output spent by this input. | +| sequence number | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The sequence number of this input. | +| outputs hash | 32 bytes | hash[(BE)](/protocol/misc/endian/big) | The double SHA256 of the serialization of **all** output values and locking scripts (including size) of the transaction. If `SIGHASH_SINGLE` is used: if this input index is smaller than the number of outputs, this field is the double SHA256 of the output value and locking script of the same index as the input; otherwise it is `0x00...00`. If `SIGHASH_NONE` is used, this field is `0x00...00`. | +| locktime | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The locktime of the transaction. | +| signature hash type | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The signature hash type used to sign this input. See description below. | + +The signing algorithm (whether it is ECDSA or Schnorr algorithm) is applied to **the double SHA256 hash of this preimage**. + +## Signature hash type + +A signature (ECDSA or Schnorr) is ALWAYS followed by the signature hash type used to sign the input. Signature hash type indicates which part of the transaction is hashed to be signed. + +Version and locktime are always signed. All inputs are included unless the `SIGHASH_ANYONECANPAY` flag is set. + +The signature hash flags are: + +| Flag | Value (hex) | Value (bin) | Description | +| -------------------- | ----------- | ----------- | ---------------------------------------- | +| SIGHASH_ALL | 0x01 | 0b00000001 | Sign all outputs. | +| SIGHASH_NONE | 0x02 | 0b00000010 | Sign none of the outputs. | +| SIGHASH_SINGLE | 0x03 | 0b00000011 | Sign only the ouput with the same index. | +| SIGHASH_ANYONECANPAY | 0x80 | 0b10000000 | Sign only its own input. | +| SIGHASH_FORKID | 0x40 | 0b01000000 | Bitcoin Cash modifier flag. | + +Signature hash flags are combined using the bitwise OR operator (`|`) in order to get the **signature hash type** of the input. There are 6 valid signature hash types in Bitcoin Cash: + +| Signature hash type | Value (hex) | Value (bin) | Description | +| -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- | +| SIGHASH_ALL \| SIGHASH_FORKID | 0x41 | 0b01000001 | Signature applies to all inputs and outputs. | +| SIGHASH_NONE \| SIGHASH_FORKID | 0x42 | 0b01000010 | Signature applies to all inputs and none of the outputs. | +| SIGHASH_SINGLE \| SIGHASH_FORKID | 0x43 | 0b01000011 | Signature applies to all inputs and the output with the same index. | +| SIGHASH_ALL \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc1 | 0b11000001 | Signature applies to its own input and all outputs. | +| SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc2 | 0b11000010 | Signature applies to its own input and none of the outputs. | +| SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc3 | 0b11000011 | Signature applies to its own input and the output with the same index.| From eef5b73d386deaa4c750804a3d3aec5ebcd3441b Mon Sep 17 00:00:00 2001 From: lugaxker Date: Sat, 26 Sep 2020 16:45:41 +0200 Subject: [PATCH 37/47] Uppercase titles. --- protocol/blockchain/transaction/transaction-signature.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/blockchain/transaction/transaction-signature.md b/protocol/blockchain/transaction/transaction-signature.md index 727730d..cad24d4 100644 --- a/protocol/blockchain/transaction/transaction-signature.md +++ b/protocol/blockchain/transaction/transaction-signature.md @@ -1,4 +1,4 @@ -# Transaction signature +# Transaction Signature Generally, every input of a [transaction](/protocol/blockchain/transaction) must contain one or more signatures so that the transaction is valid. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. @@ -12,7 +12,7 @@ The `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` opcodes require a sigle signature whic For `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` behavior, see [Multisignature spec](/protocol/blockchain/cryptography/multisignature). -## Transaction digest algorithm (preimage format) +## Transaction Digest Algorithm (Preimage Format) 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. @@ -37,7 +37,7 @@ The preimage consists of the following elements: The signing algorithm (whether it is ECDSA or Schnorr algorithm) is applied to **the double SHA256 hash of this preimage**. -## Signature hash type +## Signature Hash Type A signature (ECDSA or Schnorr) is ALWAYS followed by the signature hash type used to sign the input. Signature hash type indicates which part of the transaction is hashed to be signed. From 76c53c10e9eef4ab3dc296cb6cabe95db73c5df7 Mon Sep 17 00:00:00 2001 From: lugaxker Date: Sat, 26 Sep 2020 16:47:53 +0200 Subject: [PATCH 38/47] Add a link to the Transaction Signature section. --- home.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/home.md b/home.md index 1cf586e..5a79aed 100644 --- a/home.md +++ b/home.md @@ -8,7 +8,7 @@ [Blockchain basics](/protocol/blockchain) — [Protocol hashing algorithms](/protocol/blockchain/hash) — Memory Pool ### Transactions -[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script)— [Locking Script](/protocol/blockchain/transaction/locking-script) +[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script) — [Locking Script](/protocol/blockchain/transaction/locking-script) — [Transaction Signature](/protocol/blockchain/transaction/transaction-signature) ### Blocks [Bitcoin blocks](/protocol/blockchain/block) — From b7e082987eece46c0ca2231126d9df3bb3746158 Mon Sep 17 00:00:00 2001 From: lugaxker Date: Fri, 2 Oct 2020 10:35:11 +0200 Subject: [PATCH 39/47] Change title from 'Transaction Signature' to 'Transaction Signing' --- home.md | 2 +- .../{transaction-signature.md => transaction-signing.md} | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) rename protocol/blockchain/transaction/{transaction-signature.md => transaction-signing.md} (99%) diff --git a/home.md b/home.md index 5a79aed..57e9030 100644 --- a/home.md +++ b/home.md @@ -8,7 +8,7 @@ [Blockchain basics](/protocol/blockchain) — [Protocol hashing algorithms](/protocol/blockchain/hash) — Memory Pool ### Transactions -[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script) — [Locking Script](/protocol/blockchain/transaction/locking-script) — [Transaction Signature](/protocol/blockchain/transaction/transaction-signature) +[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script) — [Locking Script](/protocol/blockchain/transaction/locking-script) — [Transaction Signing](/protocol/blockchain/transaction/transaction-signing) ### Blocks [Bitcoin blocks](/protocol/blockchain/block) — diff --git a/protocol/blockchain/transaction/transaction-signature.md b/protocol/blockchain/transaction/transaction-signing.md similarity index 99% rename from protocol/blockchain/transaction/transaction-signature.md rename to protocol/blockchain/transaction/transaction-signing.md index cad24d4..18f3627 100644 --- a/protocol/blockchain/transaction/transaction-signature.md +++ b/protocol/blockchain/transaction/transaction-signing.md @@ -1,4 +1,4 @@ -# Transaction Signature +# Transaction Signing Generally, every input of a [transaction](/protocol/blockchain/transaction) must contain one or more signatures so that the transaction is valid. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. From 1a06ff6582ac6c2a6a535f372b1e4f41c0a751b1 Mon Sep 17 00:00:00 2001 From: lugaxker Date: Fri, 2 Oct 2020 10:48:29 +0200 Subject: [PATCH 40/47] Update the Transaction Signing section as per #27. --- protocol/blockchain/transaction/transaction-signing.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/blockchain/transaction/transaction-signing.md b/protocol/blockchain/transaction/transaction-signing.md index 18f3627..8c489be 100644 --- a/protocol/blockchain/transaction/transaction-signing.md +++ b/protocol/blockchain/transaction/transaction-signing.md @@ -1,8 +1,10 @@ # Transaction Signing -Generally, every input of a [transaction](/protocol/blockchain/transaction) must contain one or more signatures so that the transaction is valid. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. +Generally, every input of a must contain one or more signatures so that the transaction is valid. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. -In scripts using these opcodes, *signatures* are checked against *public keys*. +Generally, every input of a [transaction](/protocol/blockchain/transaction) require one or more signature. The signatures enforce (sign) what the transaction looks like and make it impossible for a third party to temper with without invalidating the transaction. + +This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. In scripts using these opcodes, *signatures* are checked against *public keys* and the transaction signature (as described below). The `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` opcodes require a sigle signature which is checked against a single public key: @@ -22,7 +24,7 @@ The preimage consists of the following elements: | Field | Length | Format | Description | | ----------------------------------- | -------- | -------------------------------------------------------------------- | ----------------------------------------------------------- | -| version | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The version of the transaction format. Must be `1` or `2`. | +| version | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The version of the transaction format. Currently `1` or `2`. | | previous outputs hash | 32 bytes | hash[(BE)](/protocol/misc/endian/big) | The double SHA256 of the serialization of **all** input outpoints (txids + indexes) of the transaction. If the `SIGHASH_ANYONECANPAY` flag is set, it is `0x00...00`. | | sequences hash | 32 bytes | hash[(BE)](/protocol/misc/endian/big) | The double SHA256 of the serialization of **all** input sequences of the transaction. If `SIGHASH_ANYONECANPAY`, `SIGHASH_SINGLE` or `SIGHASH_NONE` is used, this field is `0x00...00`. | | previous output transaction id | 32 bytes | hash[(LE)](/protocol/misc/endian/big) | The identifier of the transaction containing the previous output, i.e., the output spent by this input. | From e9096a929f5b00fb18d3a6837129c6ea074faece Mon Sep 17 00:00:00 2001 From: lugaxker Date: Fri, 2 Oct 2020 16:54:12 +0200 Subject: [PATCH 41/47] Remove old introduction phrase. --- protocol/blockchain/transaction/transaction-signing.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/blockchain/transaction/transaction-signing.md b/protocol/blockchain/transaction/transaction-signing.md index 8c489be..589659c 100644 --- a/protocol/blockchain/transaction/transaction-signing.md +++ b/protocol/blockchain/transaction/transaction-signing.md @@ -1,7 +1,5 @@ # Transaction Signing -Generally, every input of a must contain one or more signatures so that the transaction is valid. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. - Generally, every input of a [transaction](/protocol/blockchain/transaction) require one or more signature. The signatures enforce (sign) what the transaction looks like and make it impossible for a third party to temper with without invalidating the transaction. This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. In scripts using these opcodes, *signatures* are checked against *public keys* and the transaction signature (as described below). From 7f87dd4745e3ae1087fc804c913cfe01ae0741a0 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 8 Oct 2020 20:20:41 +0000 Subject: [PATCH 42/47] wiki commit --- protocol/blockchain/chainwork-proof.md | 104 +++++++++++++++++++++++++ protocol/blockchain/proof-of-work.md | 2 + 2 files changed, 106 insertions(+) create mode 100644 protocol/blockchain/chainwork-proof.md diff --git a/protocol/blockchain/chainwork-proof.md b/protocol/blockchain/chainwork-proof.md new file mode 100644 index 0000000..265b689 --- /dev/null +++ b/protocol/blockchain/chainwork-proof.md @@ -0,0 +1,104 @@ +# 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} +$$ + +*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 +$$ + +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 +$$ + +'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 + +In mathematical notation we need to prove that: + +$$ +E(P(T(work))) = n * E(P(T(work/n))) +$$ + +With all of our preparation, this proof is easy. But I'll go through each step to make it easy to read along. + +First we'll replace the functions with their defintions on the left side **to prove that "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(): + +$$ +n * E(P(T(work/n))) = n * E(P((n*2^{256}/work) -1) +$$ + +Next, substitute the definition of P(): + +$$ + = n * E( ((n*2^{256}/work))/2^{256}) +$$ + +Third, substitute the defintion of E(): + +$$ += \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 +$$ \ No newline at end of file diff --git a/protocol/blockchain/proof-of-work.md b/protocol/blockchain/proof-of-work.md index 1a52968..200eaed 100644 --- a/protocol/blockchain/proof-of-work.md +++ b/protocol/blockchain/proof-of-work.md @@ -31,6 +31,8 @@ Though the term difficulty is often used colloquially to refer generally to the 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 2256 / (target + 1), or equivalently in 256-bit two's-complement arithmetic, (~target / (target + 1)) + 1, 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 is proved [here](/protocol/blockchain/chainwork-proof). + ## Extra Nonce Ideally in such a proof-of-work system, the dynamic parameters of the data being hashed (i.e. the block header) would provide enough variability to guarantee any possible output of the hash function used. From 4f1a0babbb181f09f4574ab22accbaf3a9f915bb Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 8 Oct 2020 20:47:08 +0000 Subject: [PATCH 43/47] wiki commit From 2422c269091a8a39b2d0ffc1489587f0cb31fd52 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 8 Oct 2020 20:56:44 +0000 Subject: [PATCH 44/47] wiki commit From 72b8b18cbea219eb842bf4a6fec2eb58c50bc0fb Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 8 Oct 2020 20:56:51 +0000 Subject: [PATCH 45/47] wiki commit From a271f11b1ae75541c7ef0df132d3d388b56501a7 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 9 Oct 2020 13:39:42 +0000 Subject: [PATCH 46/47] wiki commit --- protocol/blockchain/proof-of-work.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/blockchain/proof-of-work.md b/protocol/blockchain/proof-of-work.md index 200eaed..5635add 100644 --- a/protocol/blockchain/proof-of-work.md +++ b/protocol/blockchain/proof-of-work.md @@ -29,9 +29,9 @@ Though the term difficulty is often used colloquially to refer generally to the ## 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 2256 / (target + 1), or equivalently in 256-bit two's-complement arithmetic, (~target / (target + 1)) + 1, 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 2256 / (target + 1), or equivalently in 256-bit two's-complement arithmetic, (~target / (target + 1)) + 1, 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 is proved [here](/protocol/blockchain/chainwork-proof). +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 From 1e7fc8eb6669e613f11637295d2aa78b3642fd18 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 9 Oct 2020 20:04:16 +0000 Subject: [PATCH 47/47] wiki commit --- protocol/blockchain/chainwork-proof.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/protocol/blockchain/chainwork-proof.md b/protocol/blockchain/chainwork-proof.md index 265b689..1d7c9bc 100644 --- a/protocol/blockchain/chainwork-proof.md +++ b/protocol/blockchain/chainwork-proof.md @@ -11,7 +11,7 @@ More formally, *is the expected number of hashes to solve one block candidate wi 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} +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}$.* @@ -25,28 +25,30 @@ $$ or, solving for target: $$ -T(work) = (2^{256}/work) -1 +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 +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 -In mathematical notation we need to prove that: +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))) = n * E(P(T(work/n))) +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 easy to read along. +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 "work" is the expected number of hashes**. +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)) @@ -71,19 +73,19 @@ $$ 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(): +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(): +Next, substitute the definition of P() (eqn 1): $$ = n * E( ((n*2^{256}/work))/2^{256}) $$ -Third, substitute the defintion of E(): +Third, substitute the defintion of E() (eqn 3): $$ = \dfrac{n}{\frac{(n*2^{256}/work )}{2^{256}}}