From 1c388d08808cb69ad12a7cd35563f347d1e745d0 Mon Sep 17 00:00:00 2001 From: qpj9q686j0lkck93nvex8dgu6cdtwmp7xch2wlqmmj Date: Tue, 7 Jul 2020 23:18:27 +0000 Subject: [PATCH 01/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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/56] 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 afa6e4641ed537fd3f4989e21afe298c94855d61 Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Mon, 5 Oct 2020 16:33:33 -0400 Subject: [PATCH 42/56] X[version/update/verack] consolidation/updates. Also fixing some additional formatting/linking inconsistencies. --- home.md | 2 +- protocol/network/messages.md | 23 +++++++++++--- protocol/network/messages/verack.md | 16 ++-------- protocol/network/messages/xupdate.md | 21 +++++++++++++ protocol/network/messages/xverack.md | 8 +++++ protocol/network/messages/xversion.md | 45 +++++++++++++++++++++++++++ protocol/p2p/xupdate.md | 18 ----------- protocol/p2p/xversion.md | 27 ---------------- protocol/p2p/xversionkeys.md | 24 -------------- 9 files changed, 96 insertions(+), 88 deletions(-) create mode 100644 protocol/network/messages/xupdate.md create mode 100644 protocol/network/messages/xverack.md create mode 100644 protocol/network/messages/xversion.md delete mode 100644 protocol/p2p/xupdate.md delete mode 100644 protocol/p2p/xversion.md delete mode 100644 protocol/p2p/xversionkeys.md diff --git a/home.md b/home.md index 35b8c0b..7c456bc 100644 --- a/home.md +++ b/home.md @@ -53,7 +53,7 @@ Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signat #### Other messages (extensions) -sendcmpct — get_xthin — xthinblock — thinblock — get_xblocktx — xblocktx — [xupdate](/protocol/p2p/xupdate) — [xversion](/protocol/p2p/xversion) —xverack +sendcmpct — get_xthin — xthinblock — thinblock — get_xblocktx — xblocktx — [xupdate](/protocol/network/messages/xupdate) — [xversion](/protocol/network/messages/xversion) — [xverack](/protocol/network/messages/xverack) ### Simple Payment Verification (SPV) [Bloom Filters](/objects/bloom__filter) diff --git a/protocol/network/messages.md b/protocol/network/messages.md index 1e8561a..50200b7 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -17,7 +17,6 @@ These design decisions were made with consideration to communication with untrus The P2P network has a variety of message types. All P2P messages follow a binary format with the following structure: - | Field | Length | Format | Description | |--|--|--|--| | net magic | 4 bytes | byte array[(BE)](/protocol/misc/endian/big) | See [net magic](#net-magic). | @@ -26,6 +25,8 @@ All P2P messages follow a binary format with the following structure: | payload checksum | 4 bytes | byte array[(BE)](/protocol/misc/endian/big) | The message checksum is the first 4 bytes of a double-sha256 hash of the payload. | | payload | variable | message-specific | See [message types](#message-types) for links to message-specific page, which describe the payload for each message. | +See [Example Message](#example-message) for a concrete example of this with a message that does not contain an extended payload. + ### Net Magic The network identifier is used to separate blockchains and test networks. @@ -91,11 +92,23 @@ Messages with an unrecognized `command string` are ignored by most implementatio | thinblock | | | | xblocktx | | | | xthinblock | | | -| [xupdate](/protocol/p2p/xupdate) | *Communicates a change in peer capabilities* | BCHUnlimited -| [xversion](/protocol/p2p/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited -| xverack | *Response to an [xversion](/protocol/p2p/xversion) message* | BCHUnlimited +| [xupdate](/protocol/network/messages/xupdate) | *Communicates a change in peer capabilities* | BCHUnlimited +| [xversion](/protocol/network/messages/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited +| [xverack](/protocol/network/messages/xverack) | *Response to an [xversion](/protocol/network/messages/xversion) message* | BCHUnlimited -# Example message +## Example message + +The below segments, when concatenated in order, create a sample [verack](/protocol/network/message/verack) message. + +| Label | Sample Value (Hexadecimal Representation) | +|-------|------| +| Net Magic[(BE)](/protocol/misc/endian/little) | `E3E1F3E8` | +| Command String ("verack")[(BE)](/protocol/misc/endian/big) | `76657261636B000000000000` | +| Payload Byte Count[(LE)](/protocol/misc/endian/little) | `00000000` | +| Payload Checksum[(LE)](/protocol/network/messages/message-checksum) | `5DF6E0E2` | + +### Full Sample Message (Hexadecimal) +`E3E1F3E876657261636B000000000000000000005DF6E0E2` # Node Specific Behavior diff --git a/protocol/network/messages/verack.md b/protocol/network/messages/verack.md index 3861cc9..4dc31f0 100644 --- a/protocol/network/messages/verack.md +++ b/protocol/network/messages/verack.md @@ -1,4 +1,4 @@ -# Handshake: Acknowledge ("verack") +# Handshake: Version Acknowledgement ("verack") The `verack` message is sent in reply to a [version](/protocol/network/messages/version) message. Sending a `verack` in response to a `version` message indicates to the remote that its connection and version has been accepted. @@ -7,16 +7,6 @@ There is no version negotiation functionality between nodes; therefore if the no This `verack` message consists of only a message header; the command string is "verack". -## Example Serialized Data +## Message Format -Net Magic[(BE)](/protocol/misc/endian/little) -`E3E1F3E8` - -Command String ("verack")[(BE)](/protocol/misc/endian/big) -`76657261636B000000000000` - -Payload Byte Count[(LE)](/protocol/misc/endian/little) -`00000000` - -Payload Checksum[(LE)](/protocol/network/messages/message-checksum) -`5DF6E0E2` \ No newline at end of file +This message has no contents. diff --git a/protocol/network/messages/xupdate.md b/protocol/network/messages/xupdate.md new file mode 100644 index 0000000..cdb1948 --- /dev/null +++ b/protocol/network/messages/xupdate.md @@ -0,0 +1,21 @@ +
{ +"title":"XUPDATE", +"related":["/protocol/network/messages","/protocol/network/messages/xversion"] +}
+ +# Handshake Extension: XVersion (“xversion”) + +This message notifies a peer about changes to protocol parameters. It follows the same format as [xversion](/protocol/network/messages/xversion) protocol parameters. Implementations **SHOULD** only send changed parameters, rather than every parameter. Note that some XVERSION parameters are not changeable and therefore will be ignored if they appear in this message. + +See the [xversion fields](/protocol/network/messages/xversion#xversion-fields) for detailed information about each parameter. + +## Message Format + +| Field | Length | Format | Description | +|--|--|--|--| +| number of values | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of values being sent. | +| values | variable | `number_of_values` * [xversion values](/protocol/network/messages/xversion#xversion-value-format) | The list of values to communicate. | + + +### Support +Supported by: **Bitcoin Unlimited** diff --git a/protocol/network/messages/xverack.md b/protocol/network/messages/xverack.md new file mode 100644 index 0000000..1725460 --- /dev/null +++ b/protocol/network/messages/xverack.md @@ -0,0 +1,8 @@ +# Handshake Extension: XVersion Acknowledgement (“xverack”) + +The `xverack` message is sent in reply to an [xversion](/protocol/network/messages/xversion) message. +Sending an `xverack` in response to a `version` message indicates to the remote that its XVersion values have been accepted. + +## Message Format + +This message has no contents. diff --git a/protocol/network/messages/xversion.md b/protocol/network/messages/xversion.md new file mode 100644 index 0000000..36ee743 --- /dev/null +++ b/protocol/network/messages/xversion.md @@ -0,0 +1,45 @@ +
{ +"title":"XVERSION", +"related":["/protocol/network/messages","/protocol/network/messages/xupdate","/protocol/network/messages/xverack"] +}
+ +# Handshake Extension: XVersion (“xversion”) + +This message notifies a peer about extended protocol parameters. This message MAY be sent during connection initialization. If sent, it MUST be sent immediately subsequent to the receipt of the [verack](/protocol/network/messages/verack.md) message, and before other non-initialization messages are sent. + +## Message Format + +| Field | Length | Format | Description | +|--|--|--|--| +| number of values | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of values being sent. | +| values | variable | `number_of_values` * [xversion values](#xversion-value-format) | The list of values to communicate. | + +### XVersion Value Format + +| Field | Length | Format | Description | +|--|--|--|--| +| field | variable | [variable length integer](/protocol/formats/variable-length-integer) | Indicates the field type of the value to follow. See [XVersion Fields](#xversion-fields). | +| size of value | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the value to follow. | +| value | `size_of_value` bytes | bytes | The value for the preceding field type (`key`). The format of the value is defined by the `field`, but must be the specified number of bytes. | + +#### XVersion Fields + +XVersion field identifiers are 32 bits and split into a 16 bit prefix and 16 bit suffix. Each development group is assigned a prefix so that new identifiers do not accidentally conflict. Once a field identifier is created by group A, it should be used by other software both to receive that information from A and to present that information to other software. Therefore, group A **MUST NOT** change the syntax or semantics of a field once defined. To change a field, create a new identifier and deprecate (by no longer using the original identifier). + +#### Prefix and Suffix Assignments + +##### Prefix Assignments +| Group | Value | +|-------------------------|-------| +| Reserved for versioning | 0 | +| Bitcoin Cash Node | 1 | +| Bitcoin Unlimited | 2 | + +See [xversionkeys.dat](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/xversionkeys.dat) for the most up-to-date field definitions defined by the BitcoinUnlimited full node. +Note that: +* *u64c* refers to a [variable length integer](/protocol/formats/variable-length-integer). +* *Changeable* fields MAY be changed during the course of a connection via the [xupdate](/protocol/network/messages/xupdate) message. + +### Support + +Supported by: **Bitcoin Unlimited** diff --git a/protocol/p2p/xupdate.md b/protocol/p2p/xupdate.md deleted file mode 100644 index b28659c..0000000 --- a/protocol/p2p/xupdate.md +++ /dev/null @@ -1,18 +0,0 @@ -
{ -"title":"XUPDATE", -"related":["/protocol","/protocol/p2p/xversion" ,"/protocol/p2p/xversionkeys"] -}
- -*Notifies peers about an XVERSION configuration value update* - -This message notifies a peer about changes to protocol parameters. It follows the same format as [XVERSION](/protocol/p2p/xversion.md) protocol parameters. Implementations **SHOULD** only send changed parameters, rather than every parameter. Note that some XVERSION parameters are not changeable and therefore will be ignored if they appear in this message. - -See the [XVERSION](/protocol/p2p/xversion.md) message for detailed information about each parameter. - -| compact int | compact int | variable bytes |... | compact int | 32 bytes | -|----------|---------|----------|---|---------|----------| -|[vector](/protocol/p2p/vector) size N of| key 1 | [vector](/protocol/p2p/vector) of bytes | | key N | [vector](/protocol/p2p/vector) of bytes - - -### Support -Supported by: **Bitcoin Unlimited** diff --git a/protocol/p2p/xversion.md b/protocol/p2p/xversion.md deleted file mode 100644 index f008d17..0000000 --- a/protocol/p2p/xversion.md +++ /dev/null @@ -1,27 +0,0 @@ -
{ -"title":"XVERSION", -"related":["/protocol","/protocol/p2p/xupdate","/protocol/p2p/xversionkeys"] -}
- -*Notifies peers about a protocol configuration value* - -This message notifies a peer about extended protocol parameters. This message MAY be sent during connection initialization. If sent, it MUST be sent immediately subsequent to the receipt of the [VERACK](/protocol/p2p/verack.md) message, and before other non-initialization messages are sent. - -| compact int | compact int | variable bytes |... | compact int | variable bytes | -|----------|---------|----------|---|---------|----------| -|[vector](/protocol/p2p/vector) size N of| key 1 | value 1 [vector](/protocol/p2p/vector) of bytes | | key N | value N [vector](/protocol/p2p/vector) of bytes - -The *value* is a vector of bytes. These bytes can be an object that is itself serialized, but **MUST** exist within the vector "envelope" so that implementations that do not recognize a field can skip it. The serialization format of the bytes inside the "envelope" is defined by the creator of the key, however, Bitcoin P2P network serialization is recommended since it is also used to encode/decode all the messages of this protocol. - -See [XVERSION specification](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/doc/xversionmessage.md) for additional details. - -### XVERSION Fields - -XVERSION field identifiers are 32 bits and split into a 16 bit prefix and 16 bit suffix. Each development group is assigned a prefix so that new identifiers do not accidentally conflict. Once a field identifier is created by group A, it should be used by other software both to receive that information from A and to present that information to other software. Therefore, group A **MUST NOT** change the syntax or semantics of a field once defined. To change a field, create a new identifier and deprecate (by no longer using the original identifier). - -#### Prefix and Suffix Assignments -See [xversionkeys](/protocol/p2p/xversionkeys.md) for a full list of assigned prefixes and field definitions. - -### Support - -Supported by: **Bitcoin Unlimited** diff --git a/protocol/p2p/xversionkeys.md b/protocol/p2p/xversionkeys.md deleted file mode 100644 index 7b8376c..0000000 --- a/protocol/p2p/xversionkeys.md +++ /dev/null @@ -1,24 +0,0 @@ -
{ -"title":"XVERSIONKEYS", -"related":["/protocol","/protocol/p2p/xversion","/protocol/p2p/xupdate"] -}
- - -### Prefix Assignments -| Group | Value | -|-------------------------|-------| -| Reserved for versioning | 0 | -| Bitcoin Cash Node | 1 | -| Bitcoin Unlimited | 2 | - - -#### Field Assignments - -See [xversionkeys.dat](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/xversionkeys.dat) for the most up-to-date field definitions defined by the BitcoinUnlimited full node. -Note that: -* *u64c* refers to a [compact int](/protocol/p2p/compact__int.md) serialization of an unsigned 64-bit value. -* *Changeable* fields MAY be changed during the course of a connection via the [XUPDATE](/protocol/p2p/xupdate) message. - -### Support - -Supported by: **Bitcoin Unlimited** From 6b1d747a23537d17ba93a4856b106f6d6bdab817 Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Mon, 5 Oct 2020 17:10:50 -0400 Subject: [PATCH 43/56] Link and content tweaks for example message. --- protocol/network/messages.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/network/messages.md b/protocol/network/messages.md index 50200b7..e01ed2d 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -105,9 +105,10 @@ The below segments, when concatenated in order, create a sample [verack](/protoc | Net Magic[(BE)](/protocol/misc/endian/little) | `E3E1F3E8` | | Command String ("verack")[(BE)](/protocol/misc/endian/big) | `76657261636B000000000000` | | Payload Byte Count[(LE)](/protocol/misc/endian/little) | `00000000` | -| Payload Checksum[(LE)](/protocol/network/messages/message-checksum) | `5DF6E0E2` | +| Payload Checksum[(LE)](/protocol/misc/endian/little) | `5DF6E0E2` | + +Below is the full, concatenated sample message (in hexadecimal): -### Full Sample Message (Hexadecimal) `E3E1F3E876657261636B000000000000000000005DF6E0E2` # Node Specific Behavior From bfe8f816c8876e41c36769cc9d86748ea74fad4f Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Tue, 6 Oct 2020 15:01:59 -0400 Subject: [PATCH 44/56] Markdown clean up/fixing a couple broken links. --- protocol/blockchain.md | 2 +- protocol/network/messages.md | 16 +++++++++++----- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/protocol/blockchain.md b/protocol/blockchain.md index 8102c19..a420759 100644 --- a/protocol/blockchain.md +++ b/protocol/blockchain.md @@ -22,7 +22,7 @@ Sibling blocks can happen if a block is created with sufficient work before the Sibling blocks are incompatible with one another, and eventually one will become orphaned. The [genesis block](/protocol/blockchain#genesis-block) is the first block in a chain, and has a block height of `0` (as its distance to the genesis block is zero). -As of [BIP-0034](/blockchain/forks/bip-34), the `block height` is included within the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction). +As of [BIP-34](/protocol/forks/bip-0034), the `block height` is included within the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction). ## Work diff --git a/protocol/network/messages.md b/protocol/network/messages.md index e01ed2d..47fea4a 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -2,11 +2,17 @@ The Bitcoin Cash Peer-to-Peer (P2P) Network protocol is a binary protocol used by Full Nodes and [SPV](/protocol/simple-payment-verification) Nodes, transmitted over TCP/IP. Individual nodes on the Bitcoin Cash network connect and create a mesh network where each node is indirectly connected to many others via just a couple of hops. -In the original Satoshi implementation of the P2P protocol the design of INV and getdata have been used for propagating transaction data using the rules of the gossip protocol values: forwarding validated transactions to a few peer-nodes who send it to others until the entire network has the transaction. This emergent behavior of the P2P layer allows fast propagation without undue strain on any individual node. +In the original Satoshi implementation of the P2P protocol the design of INV and getdata have been used for propagating transaction data using the rules of the gossip protocol values: forwarding validated transactions to a few peer-nodes who send it to others until the entire network has the transaction. +This emergent behavior of the P2P layer allows fast propagation without undue strain on any individual node. -The P2P protocol is designed around messages. Each message is separate and self-contained. Nodes should be tolerant of message-types they do not understand. It is best to simply ignore those. -Detailed descriptions of the messages follows below. Generally speaking, each message is an event that the node can choose to respond to. Events range from notifications of new data (transactions/blocks/etc) and -actual requests for such data to be send and last the actual data being sent. Or, in some specific cases a `reject` message. +The P2P protocol is designed around messages. +Each message is separate and self-contained. +Nodes should be tolerant of message-types they do not understand. +It is best to simply ignore those. +Detailed descriptions of the messages follows below. +Generally speaking, each message is an event that the node can choose to respond to. +Events range from notifications of new data (transactions/blocks/etc) and actual requests for such data to be send and last the actual data being sent. +Or, in some specific cases a `reject` message. These design decisions were made with consideration to communication with untrusted/uncooperative partners. @@ -98,7 +104,7 @@ Messages with an unrecognized `command string` are ignored by most implementatio ## Example message -The below segments, when concatenated in order, create a sample [verack](/protocol/network/message/verack) message. +The below segments, when concatenated in order, create a sample [verack](/protocol/network/messages/verack) message. | Label | Sample Value (Hexadecimal Representation) | |-------|------| From 35e031f959dc016e80669d70a36314f661669ba9 Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Wed, 7 Oct 2020 13:33:38 -0400 Subject: [PATCH 45/56] Removed negative lock time comments in transaction format. --- home.md | 2 +- protocol/blockchain/transaction.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/home.md b/home.md index 7c456bc..a382715 100644 --- a/home.md +++ b/home.md @@ -28,7 +28,7 @@ Pay To Public Key (P2PK) — Pay To Public Key Hash (P2PKH) — Pay To Script Hash (P2SH) — [Base58Check encoding (legacy)](/protocol/blockchain/encoding/base58check) — [Cashaddr Encoding](/protocol/blockchain/encoding/cashaddr) ### Cryptography -Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signatures — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature.md) +Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signatures — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature) ### Network upgrades [Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — BCH-UAHF (BUIP-55) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115 diff --git a/protocol/blockchain/transaction.md b/protocol/blockchain/transaction.md index c203cc1..aedf2c3 100644 --- a/protocol/blockchain/transaction.md +++ b/protocol/blockchain/transaction.md @@ -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[(LE)](/protocol/misc/endian/little) | 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`.

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.

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[(LE)](/protocol/misc/endian/little) | 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`.

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.

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 From 7f87dd4745e3ae1087fc804c913cfe01ae0741a0 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Thu, 8 Oct 2020 20:20:41 +0000 Subject: [PATCH 46/56] 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 47/56] 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 48/56] 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 49/56] wiki commit From b9780182ca659ae8b5adad4f6ebdb0b4a5d6294c Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Thu, 8 Oct 2020 17:36:44 -0400 Subject: [PATCH 50/56] Changes related to transaction signing semantics. --- home.md | 4 +- protocol/blockchain/transaction.md | 2 +- protocol/blockchain/transaction/signatures.md | 115 +++++++ .../transaction/unlocking-script.md | 2 +- protocol/forks/bch-uahf.md | 284 ++++++++++++++++++ protocol/network/messages/feefilter.md | 2 +- 6 files changed, 404 insertions(+), 5 deletions(-) create mode 100644 protocol/blockchain/transaction/signatures.md create mode 100644 protocol/forks/bch-uahf.md diff --git a/home.md b/home.md index a382715..337014f 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 Signatures](/protocol/blockchain/transaction/signatures) ### Blocks [Bitcoin Blocks](/protocol/blockchain/block) — @@ -31,7 +31,7 @@ Pay To Public Key (P2PK) — Pay To Public Key Hash (P2PKH) — Pay To Script Ha Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signatures — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature) ### Network upgrades -[Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — BCH-UAHF (BUIP-55) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115 +[Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — [BCH-UAHF (BUIP-55)](/protocol/forks/bch-uahf) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115 ### Network protocol diff --git a/protocol/blockchain/transaction.md b/protocol/blockchain/transaction.md index aedf2c3..4416e67 100644 --- a/protocol/blockchain/transaction.md +++ b/protocol/blockchain/transaction.md @@ -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[(LE)](/protocol/misc/endian/little) | 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[(BE)](/protocol/misc/endian/big) | The contents of the locking script. | ## Transaction Fee diff --git a/protocol/blockchain/transaction/signatures.md b/protocol/blockchain/transaction/signatures.md new file mode 100644 index 0000000..f709406 --- /dev/null +++ b/protocol/blockchain/transaction/signatures.md @@ -0,0 +1,115 @@ + +# 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. | + +For example, a hash type of `0x000000C2`, would indicate a signature generated for a Bitcoin Cash transaction with an anyone-can-pay, no-outputs-included preimage. + +## BCH Signatures + +### Preimage Format + +| Field | Length | Format | Description | +|--|--|--|--| +| transaction version | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The value of transaction's version field. | +| previous outputs hash | 32 bytes | bytes[(BE)](/protocol/misc/endian/big) | 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.

If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes. | +| sequence numbers hash | 32 bytes | bytes[(BE)](/protocol/misc/endian/big) | 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.

If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes. | +| previous output hash | 32 bytes | bytes[(LE)](/protocol/misc/endian/little) | The transaction ID of the previous output being spent. | +| previous output index | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | 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[(BE)](/protocol/misc/endian/big) | The subset of the locking script used for signing. See [Modified Locking Script](#modified-locking-script) | +| previous output value | 8 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The value of the transaction output being spent. | +| input sequence number | 8 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The sequence number of the input this signature is for. | +| transaction outputs hash | 32 bytes | bytes[(BE)](/protocol/misc/endian/big) | 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[(LE)](/protocol/misc/endian/little) | The lock time of the transaction. | +| hash type | 4 bytes | [Hash Type](#hash-type)[(LE)](/protocol/misc/endian/little) | Flags indicating the rules for how this signature was generated. | + +#### Previous Outputs Hash + +For each transaction input in the transaction, append the following information: + +| Field | Length | Format | Description | +|--|--|--|--| +| previous transaction hash | 32 bytes | bytes[(LE)](/protocol/misc/endian/little) | The hash of the transaction that generated the output to be spent. | +| output index | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | The index of the output to be spent from the specified transaction. | + +#### Sequence Numbers Hash + +For each transaction input in the transaction, append the following information: + +| Field | Length | Format | Description | +|--|--|--|--| +| sequence number | 4 bytes | unsigned integer[(LE)](/protocol/misc/endian/little) | 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[(LE)](/protocol/misc/endian/little) | 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[(BE)](/protocol/misc/endian/big) | The contents of the locking script. | + +### Signature Format + + + +## BTC Signatures + + +### Preimage Format + + +### Signature Format + diff --git a/protocol/blockchain/transaction/unlocking-script.md b/protocol/blockchain/transaction/unlocking-script.md index ff518a6..55cddf4 100644 --- a/protocol/blockchain/transaction/unlocking-script.md +++ b/protocol/blockchain/transaction/unlocking-script.md @@ -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). diff --git a/protocol/forks/bch-uahf.md b/protocol/forks/bch-uahf.md new file mode 100644 index 0000000..9f44772 --- /dev/null +++ b/protocol/forks/bch-uahf.md @@ -0,0 +1,284 @@ +
+  layout: specification
+  title: UAHF Technical Specification
+  category: spec
+  date: 2017-07-24
+  activation: 1501590000
+  version: 1.6
+
+ +## Introduction + +This document describes proposed requirements for a block size Hard Fork (HF). + +BUIP 55 specified a block height fork. This UAHF specification is +inspired by the idea of a flag day, but changed to a time-based fork due +to miner requests. It should be possible to change easily to a height-based +fork - the sense of the requirements would largely stay the same. + + +## Definitions + +MTP: the "median time past" value of a block, calculated from its nTime +value, and the nTime values of its up to 10 immediate ancestors. + +"activation time": once the MTP of the chain tip is equal to or greater +than this time, the next block must be a valid fork block. The fork block +and subsequent blocks built on it must satisfy the new consensus rules. + +"fork block": the first block built on top of a chain tip whose MTP is +greater than or equal to the activation time. + +"fork EB": the user-specified value that EB shall be set to at +activation time. EB can be adjusted post-activation by the user. + +"fork MG": the user-specified value that MG shall be set to at activation +time. It must be > 1MB. The user can adjust MG to any value once the +fork has occurred (not limited to > 1MB after the fork). + +"Large block" means a block satisfying 1,000,000 bytes < block +size <= EB, where EB is as adjusted by REQ-4-1 and a regular block +is a block up to 1,000,000 bytes in size. + +"Core rules" means all blocks <= 1,000,000 bytes (Base block size). + +"Extended BU tx/sigops rules" means the existing additional consensus rules (1) and +(2) below, as formalized by BUIP040 [1] and used by the Bitcoin Unlimited +client's excessive checks for blocks larger than 1MB, extended with rule +(3) below: +1. maximum sigops per block is calculated based on the actual size of +a block using +max_block_sigops = 20000 * ceil((max(blocksize, 1000000) / 1000000)) +2. maximum allowed size of a single transaction is 1,000,000 bytes (1MB) +3. maximum allowed number of sigops for a single transaction is 20k . + +NOTE 1: In plain English, the maximum allowed sigops per block is +20K sigops per the size of the block, rounded up to nearest integer in MB. +i.e. 20K if <= 1MB, 40K for the blocks > 1MB and up to 2MB, etc. + + +## Requirements + +### REQ-1 (fork by default) + +The client (with UAHF implementation) shall default to activating +a hard fork with new consensus rules as specified by the remaining +requirements. + +RATIONALE: It is better to make the HF active by default in a +special HF release version. Users have to download a version capable +of HF anyway, it is more convenient for them if the default does not +require them to make additional configuration. + +NOTE 1: It will be possible to disable the fork behavior (see +REQ-DISABLE) + + +### REQ-2 (configurable activation time) + +The client shall allow a "activation time" to be configured by the user, +with a default value of 1501590000 (epoch time corresponding to Tue +1 Aug 2017 12:20:00 UTC) + +RATIONALE: Make it configurable to adapt easily to UASF activation +time changes. + +NOTE 1: Configuring a "activation time" value of zero (0) shall disable +any UAHF hard fork special rules (see REQ-DISABLE) + + +### REQ-3 (fork block must be > 1MB) + +The client shall enforce a block size larger than 1,000,000 bytes +for the fork block. + +RATIONALE: This enforces the hard fork from the original 1MB +chain and prevents a re-organization of the forked chain to +the original chain. + + +### REQ-4-1 (require "fork EB" configured to at least 8MB at startup) + +If UAHF is not disabled (see REQ-DISABLE), the client shall enforce +that the "fork EB" is configured to at least 8,000,000 (bytes) by raising +an error during startup requesting the user to ensure adequate configuration. + +RATIONALE: Users need to be able to run with their usual EB prior to the +fork (e.g. some are running EB1 currently). The fork code needs to adjust +this EB automatically to a > 1MB value. 8MB is chosen as a minimum since +miners have indicated in the past that they would be willing to support +such a size, and the current network is capable of handling it. + + +### REQ-4-2 (require user to specify suitable *new* MG at startup) + +If UAHF is not disabled (see REQ-DISABLE), the client shall require +the user to specify a "fork MG" (mining generation size) greater than +1,000,000 bytes. + +RATIONALE: This ensures a suitable MG is set at the activation time so +that a mining node would produce a fork block compatible with REQ-3. +It also forces the user (miner) to decide on what size blocks they want to +produce immediately after the fork. + +NOTE 1: The DEFAULT_MAX_GENERATED_BLOCK_SIZE in the released client needs +to remain 1,000,000 bytes so that the client will not generate invalid +blocks before the fork activates. At activation time, however, the "fork MG" +specified by the user (default: 2MB) will take effect. + + +### REQ-5 (max tx / max block sigops rules for blocks > 1 MB) + +Blocks larger than 1,000,000 shall be subject to "Extended BU tx/sigops rules" +as follows: + +1. maximum sigops per block shall be calculated based on the actual size of +a block using +`max_block_sigops = 20000 * ceil((max(blocksize_bytes, 1000000) / 1000000))` + +2. maximum allowed size of a single transaction shall be 1,000,000 bytes + +NOTE 1: Blocks up to and including 1,000,000 bytes in size shall be subject +to existing pre-fork Bitcoin consensus rules. + +NOTE 2: Transactions exceeding 100,000 bytes (100KB) shall remain +non-standard after the activation time, meaning they will not be relayed. + +NOTE 3: BU treats both rules (1) and (2) as falling under the Emergent +Consensus rules (AD). Other clients may choose to implement them as +firm rules at their own risk. + + +### REQ-6-1 (disallow special OP_RETURN-marked transactions with sunset clause) + +Once the fork has activated, transactions consisting exclusively of a single OP_RETURN output, followed by a single minimally-coded data push with the specific magic data value of + + Bitcoin: A Peer-to-Peer Electronic Cash System + +(46 characters, including the single spaces separating the words, and +without any terminating null character) shall be considered invalid until +block 530,000 inclusive. + +RATIONALE: (DEPRECATED - see NOTE 2) To give users on the legacy chain (or other fork chains) +an opt-in way to exclude their transactions from processing on the UAHF +fork chain. The sunset clause block height is calculated as approximately +1 year after currently planned UASF activation time (Aug 1 2017 00:00:00 GMT), +rounded down to a human friendly number. + +NOTE 1: Transactions with such OP_RETURNs shall be considered valid again +for block 530,001 and onwards. + +NOTE 2: With the changes in v1.6 of this specification, mandatory use +of SIGHASH_FORKID replay protection on UAHF chain makes the use of this +opt-out protection unnecessary. Clients should nevertheless implement this +requirement, as removing it would constitute a hard fork vis-a-vis the +existing network. The sunset clause in this requirement will take care +of its expiry by itself. + + +### REQ-6-2 (mandatory signature shift via hash type) + +Once the fork has activated, a transaction shall be deemed valid only if +the following are true in combination: +- its nHashType has bit 6 set (SIGHASH_FORKID, mask 0x40) +- a magic 'fork id' value is added to the nHashType before the hash is + calculated (see note 4) +- it is digested using the new algorithm described in REQ-6-3 + +RATIONALE: To provide strong protection against replay of existing +transactions on the UAHF chain, only transactions signed with the new +hash algorithm and having SIGHASH_FORKID set will be accepted, by consensus. + +NOTE 1: It is possible for other hard forks to allow SIGHASH_FORKID-protected +transactions on their chain by implementing a compatible signature. +However, this does require a counter hard fork by legacy chains. + +NOTE 2: (DEPRECATED) ~~The client shall still accept transactions whose signatures~~ +~~verify according to pre-fork rules, subject to the additional OP_RETURN~~ +~~constraint introduced by REQ-6-1.~~ + +NOTE 3: (DEPRECATED) ~~If bit 6 is not set, only the unmodified nHashType will be used~~ +~~to compute the hash and verify the signature.~~ + +NOTE 4: The magic 'fork id' value used by UAHF-compatible clients is zero. +This means that the change in hash when bit 6 is set is effected only by +the adapted signing algorithm (see REQ-6-3). + +NOTE 5: See also REQ-6-4 which introduces a requirement for use of +SCRIPT_VERIFY_STRICTENC. + + +### REQ-6-3 (use adapted BIP143 hash algorithm for protected transactions) + +Once the fork has activated, any transaction that has bit 6 set in its +hash type shall have its signature hash computed using a minimally revised +form of the transaction digest algorithm specified in BIP143. + +RATIONALE: see Motivation section of BIP143 [2]. + +NOTE 1: refer to [3] for the specificaton of the revised transaction +digest based on BIP143. Revisions were made to account for non-Segwit +deployment. + + +### REQ-6-4 (mandatory use of SCRIPT_VERIFY_STRICTENC) + +Once the fork has activated, transactions shall be validated with +SCRIPT_VERIFY_STRICTENC flag set. + +RATIONALE: Use of SCRIPT_VERIFY_STRICTENC also ensures that the +nHashType is validated properly. + +NOTE: As SCRIPT_VERIFY_STRICTENC is not clearly defined by BIP, +implementations seeking to be compliant should consult the Bitcoin C++ +source code to emulate the checks enforced by this flag. + + +### REQ-7 Difficulty adjustement in case of hashrate drop + +In case the MTP of the tip of the chain is 12h or more after the MTP 6 block +before the tip, the proof of work target is increased by a quarter, or 25%, +which corresponds to a difficulty reduction of 20% . + +RATIONALE: The hashrate supporting the chain is dependent on market price and +hard to predict. In order to make sure the chain remains viable no matter what +difficulty needs to adjust down in case of abrupt hashrate drop. + +### REQ-DISABLE (disable fork by setting fork time to 0) + +If the activation time is configured to 0, the client shall not enforce +the new consensus rules of UAHF, including the activation of the fork, +the size constraint at a certain time, and the enforcing of EB/AD +constraints at startup. + +RATIONALE: To make it possible to use such a release as a compatible +client with legacy chain / i.e. to decide to not follow the HF on one's +node / make a decision at late stage without needing to change client. + + +### OPT-SERVICEBIT (NODE_BITCOIN_CASH service bit) + +A UAHF-compatible client should set service bit 5 (value 0x20). + +RATIONALE: This service bit allows signaling that the node is a UAHF +supporting node, which helps DNS seeders distinguish UAHF implementations. + +NOTE 1: This is an optional feature which clients do not strictly have to +implement. + +NOTE 2: This bit is currently referred to as NODE_BITCOIN_CASH and displayed +as "CASH" in user interfaces of some Bitcoin clients (BU, ABC). + + +## References + +[1] https://bitco.in/forum/threads/buip040-passed-emergent-consensus-parameters-and-defaults-for-large-1mb-blocks.1643/ + +[2] https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Motivation + +[3] [Digest for replay protected signature verification accross hard forks](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md) + +[4] https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-test-plan.md + + +END \ No newline at end of file diff --git a/protocol/network/messages/feefilter.md b/protocol/network/messages/feefilter.md index b404681..e816ba7 100644 --- a/protocol/network/messages/feefilter.md +++ b/protocol/network/messages/feefilter.md @@ -8,4 +8,4 @@ The recipient node may, but is not required to, begin to perform this filtering | Field | Length | Format | Description | |--|--|--|--| -| minimum fee per byte | 8 bytes | unsigned 64 bit integer[(LE)](/protocol/misc/endian/little.md) | The minimum number of satoshis per byte in fees desired by the sender. \ No newline at end of file +| minimum fee per byte | 8 bytes | unsigned 64 bit integer[(LE)](/protocol/misc/endian/little) | The minimum number of satoshis per byte in fees desired by the sender. \ No newline at end of file From a271f11b1ae75541c7ef0df132d3d388b56501a7 Mon Sep 17 00:00:00 2001 From: Andrew Stone Date: Fri, 9 Oct 2020 13:39:42 +0000 Subject: [PATCH 51/56] 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 52/56] 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}}} From a54718527e49f47db6cb7bd4a4a1062d916c6011 Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Tue, 13 Oct 2020 14:31:01 -0400 Subject: [PATCH 53/56] Re-adding unintegrated glossary/object pages. --- glossary/outpoint.md | 1 + glossary/output__script.md | 8 ++++++++ glossary/spv.md | 1 + glossary/utxo__set.md | 6 ++++++ objects/bloom__filter.md | 17 +++++++++++++++++ objects/wallet__objects.md | 19 +++++++++++++++++++ 6 files changed, 52 insertions(+) create mode 100644 glossary/outpoint.md create mode 100644 glossary/output__script.md create mode 100644 glossary/spv.md create mode 100644 glossary/utxo__set.md create mode 100644 objects/bloom__filter.md create mode 100644 objects/wallet__objects.md diff --git a/glossary/outpoint.md b/glossary/outpoint.md new file mode 100644 index 0000000..2593882 --- /dev/null +++ b/glossary/outpoint.md @@ -0,0 +1 @@ +An outpoint is a (transaction [hash identifier](/glossary/hash__identifier), index pair) that uniquely identifies a particular [UTXO](/glossary/UTXO). \ No newline at end of file diff --git a/glossary/output__script.md b/glossary/output__script.md new file mode 100644 index 0000000..b35db72 --- /dev/null +++ b/glossary/output__script.md @@ -0,0 +1,8 @@ +
+{ +"title":"Output Script", +"related":["/glossary/redeem__script","/glossary/input__script"] +} +
+ +The output script constrains the subsequent spend of Bitcoins. diff --git a/glossary/spv.md b/glossary/spv.md new file mode 100644 index 0000000..f1f402a --- /dev/null +++ b/glossary/spv.md @@ -0,0 +1 @@ +SPV is an acronym for "Simplified Payment Validation". \ No newline at end of file diff --git a/glossary/utxo__set.md b/glossary/utxo__set.md new file mode 100644 index 0000000..e5bba95 --- /dev/null +++ b/glossary/utxo__set.md @@ -0,0 +1,6 @@ + + + +The UTXO set contains information that describes the current spending constraints on every coin in the blockchain at a particular moment (generally "now"). This information is used to determine the validity of new transactions, and to report information such as wallet balances. + +This data is extracted from the blockchain, which contains the full history (all transfers, spent or unspent) of all coins since their creation. diff --git a/objects/bloom__filter.md b/objects/bloom__filter.md new file mode 100644 index 0000000..024ad0f --- /dev/null +++ b/objects/bloom__filter.md @@ -0,0 +1,17 @@ +
{ +"title":"Bloom Filter", +"related":["/protocol/p2p/filterload"] +}
+ +A bloom filter is an imperfect but efficient set membership test. The filter will never incorrectly report that member is NOT in the set. However, it may report that a member is in a set when it is actually not. See [wikipedia](https://en.wikipedia.org/wiki/Bloom_filter), or the [original paper](https://dl.acm.org/citation.cfm?id=362686.362692) for details. + +Therefore bloom filters are often used during set membership testing as a quick pre-check to eliminate most elements. + +### Use in the Bitcoin Peer-to-Peer Protocol +Bloom filters are used in the bitcoin peer-to-peer protocol to filter the transactions and blocks that a client is sent from another node. The client first "installs" a bloom filter that contains information about the objects it is interested in by sending a [FILTERLOAD](/protocol/p2p/filterload) message to a peer. The peer will subsequently only provide objects that match the installed filter. + +At a minimum, an [SPV](/glossary/SPV) client must insert addresses and [outpoints](/glossary/outpoint) into the bloom filter. The addresses will cause every transaction that pays INTO the wallet to be reported, and the outpoints will cause every transaction that pays OUT OF the wallet to be reported. + +Bitcoin Bloom filters have an additional feature. Based on the setting of a flag byte, it is possible to direct the peer to automatically insert new data into the bloom filter based on transactions that match. In particular, outpoints will be automatically inserted that correspond to the outputs of addresses that match the filter. This facility is extremely important because if a receive and spend occur within the same transaction, the client does not have the opportunity to update the filter. Bloom filters should therefore be sized with the expectation that new elements will be inserted. + +However, due to the bloom filter's tendency to have false positives, these insertions means that unnecessary data will be inserted into the filter, creating even more false positives in a positive feedback loop. Eventually the node will start sending a lot of unnecessary traffic to the client. Therefore, it is essential for clients to periodically refresh (using [FILTERLOAD](/protocol/p2p/filterload)) the bloom filter to remove these unnecessary entries. diff --git a/objects/wallet__objects.md b/objects/wallet__objects.md new file mode 100644 index 0000000..753c6c3 --- /dev/null +++ b/objects/wallet__objects.md @@ -0,0 +1,19 @@ +
+{ +"title": "Wallet Objects" +}
+ +The following graph shows the derivation relationship between wallet objects. + +```mermaid +graph TB +PrivK["Private Key"] ==>PubK[Public key] +PubK == RIPEMD and SHA256 ==> PubKH[Public Key Hash] +PubKH==>Address +Address==>PubKH +Script==>Address +style PubK fill:#906,stroke:#333,stroke-width:2px; +style PrivK fill:#f06,stroke:#333,stroke-width:8px; +style PubKH fill:#2f6,stroke:#333,stroke-width:2px; +style Address fill:#2f6,stroke:#333,stroke-width:2px; +``` \ No newline at end of file From 615e0d747ab831b1d42b34a620c01c79ca2700ad Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Tue, 13 Oct 2020 14:32:19 -0400 Subject: [PATCH 54/56] Re-adding explanation for BU not validating checksums. --- protocol/network/messages.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/network/messages.md b/protocol/network/messages.md index 47fea4a..5063e0f 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -123,4 +123,4 @@ Below is the full, concatenated sample message (in hexadecimal): ### Payload Checksum -Bitcoin Unlimited does not validate the message checksum \ No newline at end of file +Bitcoin Unlimited does not validate the message checksum since messages are sent via TCP which has its own checksum paradigm. From ab071542f670253af1a651d060760e8ce9334b72 Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Tue, 13 Oct 2020 14:50:20 -0400 Subject: [PATCH 55/56] Cleaning up various remaining items from BU PR #26. --- protocol/blockchain/hash.md | 9 +++++---- protocol/network/messages.md | 9 ++++----- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/protocol/blockchain/hash.md b/protocol/blockchain/hash.md index b9f2d1a..bbc161f 100644 --- a/protocol/blockchain/hash.md +++ b/protocol/blockchain/hash.md @@ -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. \ No newline at end of file +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. diff --git a/protocol/network/messages.md b/protocol/network/messages.md index 5063e0f..f81d509 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -9,10 +9,10 @@ The P2P protocol is designed around messages. Each message is separate and self-contained. Nodes should be tolerant of message-types they do not understand. It is best to simply ignore those. -Detailed descriptions of the messages follows below. + Generally speaking, each message is an event that the node can choose to respond to. -Events range from notifications of new data (transactions/blocks/etc) and actual requests for such data to be send and last the actual data being sent. -Or, in some specific cases a `reject` message. +Events can be notifications of new data (transactions/blocks/etc), requests for such data to be sent, or the sending of the data itself. +In some specific cases a message can indicate the rejection of another message, though this is optional and should not be relied upon. These design decisions were made with consideration to communication with untrusted/uncooperative partners. @@ -37,11 +37,10 @@ See [Example Message](#example-message) for a concrete example of this with a me The network identifier is used to separate blockchains and test networks. This reduces unnecessary load on peers, allowing them to rapidly ban nodes rather then forcing the peer to do a blockchain analysis before banning or disconnecting. -For Bitcoin Cash main net, the `net magic` field is always `0xE3E1F3E8`. +For Bitcoin Cash main net, the `net magic` field is always `0xE3E1F3E8` (the ASCII string, "cash", with each byte's highest bit set). Any message received that does not begin with the `net magic` is invalid. The `net magic` is designed to be unlikely to occur in normal data--the characters are rarely used upper ASCII, are not valid as UTF-8, and produce a large 32-bit integer with any alignment. -`0xE3E1F3E8` is the ASCII string, "cash", with each byte's highest bit set. ### Command String From 1dbef6b05548637104c2a4869b86b6567a5ed06a Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Tue, 13 Oct 2020 14:54:29 -0400 Subject: [PATCH 56/56] (Re-)adding website links to README. --- README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/README.md b/README.md index c7a6fda..5eaf585 100644 --- a/README.md +++ b/README.md @@ -2,3 +2,10 @@ This repository contains markdown documentation that specifies the Bitcoin Cash cryptocurrency protocol. +However, this repository should not be directly used for normal browsing because this document uses some markdown extensions. +Instead, read this documentation at one of the following places: + +- [reference.cash](http://reference.cash) +- [documentation.cash](http://documentation.cash) +- [bitcoinprotocol.cash](http://bitcoinprotocol.cash) +