From 2952c309cb19e7129d6f2579b078eddac0fabf35 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Sun, 21 May 2017 23:22:55 -0400 Subject: [PATCH 1/4] Correct Compact Size Uint ranges --- _includes/devdoc/ref_transactions.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_includes/devdoc/ref_transactions.md b/_includes/devdoc/ref_transactions.md index 089bfbc1..6c4d27a2 100644 --- a/_includes/devdoc/ref_transactions.md +++ b/_includes/devdoc/ref_transactions.md @@ -406,12 +406,12 @@ regular unsigned integers. For other numbers up to 0xffffffffffffffff, a byte is prefixed to the number to indicate its length---but otherwise the numbers look like regular unsigned integers in little-endian order. -| Value | Bytes Used | Format -|-----------------------|------------|----------------------------------------- -| <= 252 | 1 | uint8_t -| <= 0xffff | 3 | 0xfd followed by the number as uint16_t -| <= 0xffffffff | 5 | 0xfe followed by the number as uint32_t -| <= 0xffffffffffffffff | 9 | 0xff followed by the number as uint64_t +| Value | Bytes Used | Format +|-----------------------------------------|------------|----------------------------------------- +| >= 0 && <= 252 | 1 | uint8_t +| >= 253 && <= 0xffff | 3 | 0xfd followed by the number as uint16_t +| >= 0x10000 && <= 0xffffffff | 5 | 0xfe followed by the number as uint32_t +| >= 0x100000000 && <= 0xffffffffffffffff | 9 | 0xff followed by the number as uint64_t For example, the number 515 is encoded as 0xfd0302. From 7e9305eb8a9a0476fbccc2aed5f0abcc0bf9e216 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Sun, 21 May 2017 23:37:50 -0400 Subject: [PATCH 2/4] Make reject message code descriptions more accurate Changed extra data *is* to *may include* since the extra data does not necessarily have to include what was stated. --- _includes/devdoc/ref_p2p_networking.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_includes/devdoc/ref_p2p_networking.md b/_includes/devdoc/ref_p2p_networking.md index 1374d5ab..82ab8e23 100644 --- a/_includes/devdoc/ref_p2p_networking.md +++ b/_includes/devdoc/ref_p2p_networking.md @@ -1142,16 +1142,16 @@ ascending code number (primary) and alphabetic in reply to (secondary) --> | Code | In Reply To | Extra Bytes | Extra Type | Description |------|-------------------|-------------|------------|---------------- | 0x01 | *any message* | 0 | N/A | Message could not be decoded. Be careful of `reject` message feedback loops where two peers each don't understand each other's `reject` messages and so keep sending them back and forth forever. -| 0x10 | `block` message | 32 | char[32] | Block is invalid for some reason (invalid proof-of-work, invalid signature, etc). Extra data is the rejected block's header hash. -| 0x10 | `tx` message | 32 | char[32] | Transaction is invalid for some reason (invalid signature, output value greater than input, etc.). Extra data is the rejected transaction's TXID. -| 0x11 | `block` message | 32 | char[32] | The block uses a version that is no longer supported. Extra data is the rejected block's header hash. +| 0x10 | `block` message | 32 | char[32] | Block is invalid for some reason (invalid proof-of-work, invalid signature, etc). Extra data may include the rejected block's header hash. +| 0x10 | `tx` message | 32 | char[32] | Transaction is invalid for some reason (invalid signature, output value greater than input, etc.). Extra data may include the rejected transaction's TXID. +| 0x11 | `block` message | 32 | char[32] | The block uses a version that is no longer supported. Extra data may include the rejected block's header hash. | 0x11 | `version` message | 0 | N/A | Connecting node is using a protocol version that the rejecting node considers obsolete and unsupported. -| 0x12 | `tx` message | 32 | char[32] | Duplicate input spend (double spend): the rejected transaction spends the same input as a previously-received transaction. Extra data is the rejected transaction's TXID. +| 0x12 | `tx` message | 32 | char[32] | Duplicate input spend (double spend): the rejected transaction spends the same input as a previously-received transaction. Extra data may include the rejected transaction's TXID. | 0x12 | `version` message | 0 | N/A | More than one `version` message received in this connection. -| 0x40 | `tx` message | 32 | char[32] | The transaction will not be mined or relayed because the rejecting node considers it non-standard---a transaction type or version unknown by the server. Extra data is the rejected transaction's TXID. -| 0x41 | `tx` message | 32 | char[32] | One or more output amounts are below the dust threshold. Extra data is the rejected transaction's TXID. -| 0x42 | `tx` message | | char[32] | The transaction did not have a large enough fee or priority to be relayed or mined. Extra data is the rejected transaction's TXID. -| 0x43 | `block` message | 32 | char[32] | The block belongs to a block chain which is not the same block chain as provided by a compiled-in checkpoint. Extra data is the rejected block's header hash. +| 0x40 | `tx` message | 32 | char[32] | The transaction will not be mined or relayed because the rejecting node considers it non-standard---a transaction type or version unknown by the server. Extra data may include the rejected transaction's TXID. +| 0x41 | `tx` message | 32 | char[32] | One or more output amounts are below the dust threshold. Extra data may include the rejected transaction's TXID. +| 0x42 | `tx` message | | char[32] | The transaction did not have a large enough fee or priority to be relayed or mined. Extra data may include the rejected transaction's TXID. +| 0x43 | `block` message | 32 | char[32] | The block belongs to a block chain which is not the same block chain as provided by a compiled-in checkpoint. Extra data may include the rejected block's header hash. The annotated hexdump below shows a `reject` message. (The message header has been omitted.) From 1320506accf1ce20fc6b833af6fa985b6da84190 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Sun, 21 May 2017 23:40:53 -0400 Subject: [PATCH 3/4] Clarify about empty headers messages --- _includes/devdoc/ref_p2p_networking.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/_includes/devdoc/ref_p2p_networking.md b/_includes/devdoc/ref_p2p_networking.md index 82ab8e23..38d6ce99 100644 --- a/_includes/devdoc/ref_p2p_networking.md +++ b/_includes/devdoc/ref_p2p_networking.md @@ -271,8 +271,9 @@ to the `getheaders` message will include as many as 2,000 block headers. *Added in protocol version 31800.* -The `headers` message sends one or more block headers to a node which -previously requested certain headers with a `getheaders` message. +The `headers` message sends block headers to a node which +previously requested certain headers with a `getheaders` message. A headers +message can be empty. | Bytes | Name | Data Type | Description |----------|---------|------------------|----------------- From 2b0611effb1839cc374b93ce3fc83b04138a3ea5 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Mon, 22 May 2017 13:46:34 -0400 Subject: [PATCH 4/4] Remove incorrect note in importaddress Remove incorrect note that said imporaddress would not rescan stuff already in the wallet. Those addresses and scripts already in the wallet will still be rescanned. --- _includes/devdoc/bitcoin-core/rpcs/rpcs/importaddress.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/devdoc/bitcoin-core/rpcs/rpcs/importaddress.md b/_includes/devdoc/bitcoin-core/rpcs/rpcs/importaddress.md index d3e409ee..41e24818 100644 --- a/_includes/devdoc/bitcoin-core/rpcs/rpcs/importaddress.md +++ b/_includes/devdoc/bitcoin-core/rpcs/rpcs/importaddress.md @@ -41,7 +41,7 @@ The `importaddress` RPC {{summary_importAddress}} - n: "Rescan" t: "bool" p: "Optional
(0 or 1)" - d: "Set to `true` (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transaction affecting the newly-added address or pubkey script). Set to `false` to not rescan the block database (rescanning can be performed at any time by restarting Bitcoin Core with the `-rescan` command-line argument). Rescanning may take several minutes. Notes: if the address or pubkey script is already in the wallet, the block database will not be rescanned even if this parameter is set" + d: "Set to `true` (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transaction affecting the newly-added address or pubkey script). Set to `false` to not rescan the block database (rescanning can be performed at any time by restarting Bitcoin Core with the `-rescan` command-line argument). Rescanning may take several minutes." {% enditemplate %}