From ab2094afc93a16059e04ab1ba52d75c5615c63fe Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 6 Sep 2017 16:59:53 -0400 Subject: [PATCH] Added Alert message details from Bitcoin back and removed feefilter --- _includes/devdoc/ref_p2p_networking.md | 130 +++++++++++++++++-------- _includes/references.md | 1 + 2 files changed, 88 insertions(+), 43 deletions(-) diff --git a/_includes/devdoc/ref_p2p_networking.md b/_includes/devdoc/ref_p2p_networking.md index aaaeaf32..a9ed41bc 100644 --- a/_includes/devdoc/ref_p2p_networking.md +++ b/_includes/devdoc/ref_p2p_networking.md @@ -713,68 +713,112 @@ d91f4854 ........................... Epoch time: 1414012889 {% endautocrossref %} - - #### Alert {% include helpers/subhead-links.md %} {% autocrossref %} *Added in protocol version 311.* -*Removed in protocol version 70013 and released in Bitcoin Core 0.13.0* +*Removed by Bitcoin in protocol version 70013, but retained by Dash.* -The legacy p2p network alert messaging system has been retired; however, internal alerts, partition detection warnings and the `-alertnotify` option features remain. See [Alert System Retirement](https://bitcoin.org/en/alert/2016-11-01-alert-retirement) for details. +The `alert` message warns nodes of problems that may affect them or the +rest of the network. Each `alert` message is signed using a key controlled +by respected community members, mostly Dash Core developers. -{% endautocrossref %} +To ensure all nodes can validate and forward `alert` messages, +encapsulation is used. Developers create an alert using the data +structure appropriate for the versions of the software they want to +notify; then they serialize that data and sign it. The serialized data +and its signature make up the outer `alert` message---allowing nodes +which don't understand the data structure to validate the signature and +relay the alert to nodes which do understand it. The nodes which +actually need the message can decode the serialized data to access the +inner `alert` message. -#### FeeFilter -{% include helpers/subhead-links.md %} +The outer `alert` message has four fields: -{% autocrossref %} +| Bytes | Name | Data Type | Description +|-------------|-----------------|------------------|------------- +| *Variable* | alert bytes | compactSize uint | The number of bytes in following alert field. +| *Variable* | alert | uchar | The serialized alert. See below for a description of the current alert format. +| *Variable* | signature bytes | compactSize uint | The number of bytes in the following signature field. +| *Variable* | signature | uchar | A DER-encoded ECDSA (secp256k1) signature of the alert signed with the developer's alert key. -*Added in protocol version 70013 as described by BIP133.* +Although designed to be easily upgraded, the format of the inner +serialized alert has not changed since the `alert` message was first +introduced in protocol version 311. -The `feefilter` message is a request to the receiving peer to not relay any -transaction inv messages to the sending peer where the fee rate for the -transaction is below the fee rate specified in the feefilter message. +| Bytes | Name | Data Type | Description +|----------|-------------------|---------------------------|------------- +| 4 | version | int32_t | Alert format version. Version 1 from protocol version 311 through at least protocol version 70002. +| 8 | relayUntil | int64_t | The time beyond which nodes should stop relaying this alert. Unix epoch time format. +| 8 | expiration | int64_t | The time beyond which this alert is no longer in effect and should be ignored. Unix epoch time format. +| 4 | ID | int32_t | A unique ID number for this alert. +| 4 | cancel | int32_t | All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future. +| *Varies* | setCancel count | compactSize uint | The number of IDs in the following setCancel field. May be zero. +| *Varies* | setCancel | int32_t | Alert IDs which should be canceled. Each alert ID is a separate int32_t number. +| 4 | minVer | int32_t | This alert only applies to protocol versions greater than or equal to this version. Nodes running other protocol versions should still relay it. +| 4 | maxVer | int32_t | This alert only applies to protocol versions less than or equal to this version. Nodes running other protocol versions should still relay it. +| *Varies* | user\_agent count | compactSize uint | The number of user agent strings in the following setUser\_agent field. May be zero. +| *Varies* | setUser\_agent | compactSize uint + string | If this field is empty, it has no effect on the alert. If there is at least one entry is this field, this alert only applies to programs with a user agent that exactly matches one of the strings in this field. Each entry in this field is a compactSize uint followed by a string---the uint indicates how many bytes are in the following string. This field was originally called setSubVer; since BIP14, it applies to user agent strings as defined in the `version` message. +| 4 | priority | int32_t | Relative priority compared to other alerts. +| *Varies* | comment bytes | compactSize uint | The number of bytes in the following comment field. May be zero. +| *Varies* | comment | string | A comment on the alert that is not displayed. +| *Varies* | statusBar bytes | compactSize uint | The number of bytes in the following statusBar field. May be zero. +| *Varies* | statusBar | string | The alert message that is displayed to the user. +| *Varies* | reserved bytes | compactSize uint | The number of bytes in the following reserved field. May be zero. +| *Varies* | reserved | string | Reserved for future use. Originally called RPC Error. -`feefilter` was introduced in Bitcoin Core 0.13.0 following the introduction -of mempool limiting in Bitcoin Core 0.12.0. Mempool limiting provides protection against -attacks and spam transactions that have low fee rates and are unlikely to be -included in mined blocks. The `feefilter` messages allows a node to inform its -peers that it will not accept transactions below a specified fee rate into -its mempool, and therefore that the peers can skip relaying inv messages for -transactions below that fee rate to that node. - -| Bytes | Name | Data Type | Description -|-------|---------|-----------|--------------- -| 8 | feerate | uint64_t | The fee rate (in satoshis per kilobyte) below which transactions should not be relayed to this peer. - -The receiving peer may choose to ignore the message and not filter transaction -inv messages. - -The fee filter is additive with bloom filters. If an SPV client loads a bloom -filter and sends a feefilter message, transactions should only be relayed if -they pass both filters. - -Note however that feefilter has no effect on block propagation or responses to -getdata messages. For example, if a node requests a merkleblock from its peer -by sending a getdata message with inv type MSG_FILTERED_BLOCK and it has -previously sent a feefilter to that peer, the peer should respond with a -merkleblock containing *all* the transactions matching the bloom filter, even -if they are below the feefilter fee rate. - -inv messages generated from a mempool message are subject to a fee filter if it exists. - -The annotated hexdump below shows a `feefilter` message. (The message +The annotated hexdump below shows an `alert` message. (The message header has been omitted.) -{% endautocrossref %} + {% highlight text %} -7cbd000000000000 ... satoshis per kilobyte: 48,508 +73 ................................. Bytes in encapsulated alert: 115 +01000000 ........................... Version: 1 +3766404f00000000 ................... RelayUntil: 1329620535 +b305434f00000000 ................... Expiration: 1330917376 + +f2030000 ........................... ID: 1010 +f1030000 ........................... Cancel: 1009 +00 ................................. setCancel count: 0 + +10270000 ........................... MinVer: 10000 +48ee0000 ........................... MaxVer: 61000 +00 ................................. setUser_agent bytes: 0 +64000000 ........................... Priority: 100 + +00 ................................. Bytes In Comment String: 0 +46 ................................. Bytes in StatusBar String: 70 +53656520626974636f696e2e6f72672f +666562323020696620796f7520686176 +652074726f75626c6520636f6e6e6563 +74696e67206166746572203230204665 +627275617279 ....................... Status Bar String: "See [...]" +00 ................................. Bytes In Reserved String: 0 + +47 ................................. Bytes in signature: 71 +30450221008389df45f0703f39ec8c1c +c42c13810ffcae14995bb648340219e3 +53b63b53eb022009ec65e1c1aaeec1fd +334c6b684bde2b3f573060d5b70c3a46 +723326e4e8a4f1 ..................... Signature {% endhighlight %} +**Alert key compromise:** Dash Core's source code defines a +particular set of alert parameters that can be used to notify users that +the alert signing key has been compromised and that they should upgrade +to get a new alert public key. Once a signed alert containing those +parameters has been received, no other alerts can cancel or override it. +See the `ProcessAlert()` function in the Dash Core [alert.cpp][core +alert.cpp] source code for the parameters of this message. + +{% endautocrossref %} + #### FilterAdd {% include helpers/subhead-links.md %} diff --git a/_includes/references.md b/_includes/references.md index 5ce17731..1dadbe3d 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -401,6 +401,7 @@ http://opensource.org/licenses/MIT. [bitcoinj micropayment tutorial]: https://bitcoinj.github.io/working-with-micropayments [block170]: https://www.biteasy.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee [casascius address utility]: https://github.com/casascius/Bitcoin-Address-Utility +[core alert.cpp]: https://github.com/dashpay/dash/blob/master/src/alert.cpp [core base58.h]: https://github.com/dashpay/dash/blob/master/src/base58.h [core chainparams.cpp]: https://github.com/dashpay/dash/blob/master/src/chainparams.cpp [core git]: https://github.com/dashpay/dash/