joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #1611 from achow101/devdoc-fixes

Browse source 
Various corrections to developer reference
This commit is contained in:
Will Binns 2017-05-25 18:45:29 -06:00 • committed by GitHub
commit bdbe5dae97
3 changed files with 18 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

2
_includes/devdoc/bitcoin-core/rpcs/rpcs/importaddress.md
View file

@ -41,7 +41,7 @@ The `importaddress` RPC {{summary_importAddress}}
- n: "Rescan"
t: "bool"
p: "Optional<br>(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 %}

21
_includes/devdoc/ref_p2p_networking.md
View file

@ -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
|----------|---------|------------------|-----------------
@ -1142,16 +1143,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.)

12
_includes/devdoc/ref_transactions.md
View file

@ -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.