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

Added Alert message details from Bitcoin back and removed feefilter

Browse source
This commit is contained in:
thephez 2017-09-06 16:59:53 -04:00
parent 3ff324fccf
commit ab2094afc9
2 changed files with 88 additions and 43 deletions
Download patch file Download diff file Expand all files Collapse all files

130
_includes/devdoc/ref_p2p_networking.md
View file

@ -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 %}
<!-- example below from Bitcoin Wiki but it's a network capture so I
(@harding) don't think it is subject to the wiki's copyright license; I
think it's public domain. TODO: replace with a more recent
alert the next time one is live on the network. -->
{% 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 %}

1
_includes/references.md
View file

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