2019-09-09 18:35:56 -07:00
|
|
|
//! Definitions of network messages.
|
|
|
|
|
2019-09-13 05:29:17 -07:00
|
|
|
use std::io;
|
|
|
|
|
2019-09-14 09:00:59 -07:00
|
|
|
use byteorder::{BigEndian, LittleEndian, WriteBytesExt};
|
2019-09-11 19:24:16 -07:00
|
|
|
use chrono::{DateTime, Utc};
|
|
|
|
|
2019-09-13 05:29:17 -07:00
|
|
|
use zebra_chain::types::Sha256dChecksum;
|
|
|
|
|
2019-09-12 03:36:50 -07:00
|
|
|
use crate::meta_addr::MetaAddr;
|
2019-09-14 08:16:01 -07:00
|
|
|
use crate::serialization::{ReadZcashExt, SerializationError, WriteZcashExt, ZcashSerialization};
|
2019-09-12 03:23:51 -07:00
|
|
|
use crate::types::*;
|
2019-09-10 13:27:10 -07:00
|
|
|
|
2019-09-09 18:35:56 -07:00
|
|
|
/// A Bitcoin-like network message for the Zcash protocol.
|
|
|
|
///
|
|
|
|
/// The Zcash network protocol is mostly inherited from Bitcoin, and a list of
|
|
|
|
/// Bitcoin network messages can be found [on the Bitcoin
|
|
|
|
/// wiki][btc_wiki_protocol].
|
|
|
|
///
|
|
|
|
/// That page describes the wire format of the messages, while this enum stores
|
|
|
|
/// an internal representation. The internal representation is unlinked from the
|
|
|
|
/// wire format, and the translation between the two happens only during
|
|
|
|
/// serialization and deserialization. For instance, Bitcoin identifies messages
|
|
|
|
/// by a 12-byte ascii command string; we consider this a serialization detail
|
|
|
|
/// and use the enum discriminant instead. (As a side benefit, this also means
|
|
|
|
/// that we have a clearly-defined validation boundary for network messages
|
|
|
|
/// during serialization).
|
|
|
|
///
|
|
|
|
/// [btc_wiki_protocol]: https://en.bitcoin.it/wiki/Protocol_documentation
|
2019-09-10 09:57:58 -07:00
|
|
|
//
|
|
|
|
// XXX not all messages are filled in yet. Messages written as { /* XXX add
|
|
|
|
// fields */ } are explicitly incomplete and we need to define a mapping between
|
|
|
|
// the serialized message data and the internal representation. Note that this
|
|
|
|
// is different from messages like GetAddr which have no data (and so have no
|
|
|
|
// fields).
|
2019-09-09 18:35:56 -07:00
|
|
|
pub enum Message {
|
|
|
|
/// A `version` message.
|
|
|
|
///
|
2019-09-10 13:27:10 -07:00
|
|
|
/// Note that although this is called `version` in Bitcoin, its role is really
|
|
|
|
/// analogous to a `ClientHello` message in TLS, used to begin a handshake, and
|
|
|
|
/// is distinct from a simple version number.
|
|
|
|
///
|
2019-09-09 18:35:56 -07:00
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#version)
|
2019-09-10 13:27:10 -07:00
|
|
|
Version {
|
|
|
|
/// The network version number supported by the sender.
|
|
|
|
version: Version,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
2019-09-10 13:27:10 -07:00
|
|
|
/// The network services advertised by the sender.
|
|
|
|
services: Services,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
2019-09-10 13:27:10 -07:00
|
|
|
/// The time when the version message was sent.
|
2019-09-11 19:24:16 -07:00
|
|
|
timestamp: DateTime<Utc>,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
|
|
|
/// The network address of the node receiving this message.
|
2019-09-12 03:36:50 -07:00
|
|
|
///
|
|
|
|
/// Note that the timestamp field of the [`MetaAddr`] is not included in
|
|
|
|
/// the serialization of `version` messages.
|
|
|
|
address_receiving: MetaAddr,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
|
|
|
/// The network address of the node emitting this message.
|
2019-09-12 03:36:50 -07:00
|
|
|
///
|
|
|
|
/// Note that the timestamp field of the [`MetaAddr`] is not included in
|
|
|
|
/// the serialization of `version` messages.
|
|
|
|
address_from: MetaAddr,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
|
|
|
/// Node random nonce, randomly generated every time a version
|
|
|
|
/// packet is sent. This nonce is used to detect connections
|
|
|
|
/// to self.
|
2019-09-10 13:27:10 -07:00
|
|
|
nonce: Nonce,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
2019-09-10 13:48:28 -07:00
|
|
|
/// The Zcash user agent advertised by the sender.
|
2019-09-10 13:27:10 -07:00
|
|
|
user_agent: String,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
|
|
|
/// The last block received by the emitting node.
|
2019-09-10 13:27:10 -07:00
|
|
|
start_height: zebra_chain::types::BlockHeight,
|
2019-09-10 13:43:14 -07:00
|
|
|
|
|
|
|
/// Whether the remote peer should announce relayed
|
|
|
|
/// transactions or not, see [BIP 0037](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki)
|
2019-09-11 19:44:13 -07:00
|
|
|
relay: bool,
|
2019-09-10 13:27:10 -07:00
|
|
|
},
|
2019-09-09 23:59:49 -07:00
|
|
|
|
2019-09-09 18:35:56 -07:00
|
|
|
/// A `verack` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#verack)
|
2019-09-11 11:11:48 -07:00
|
|
|
Verack,
|
2019-09-09 23:59:49 -07:00
|
|
|
|
2019-09-09 18:35:56 -07:00
|
|
|
/// A `ping` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#ping)
|
2019-09-10 13:27:10 -07:00
|
|
|
Ping(Nonce),
|
2019-09-09 23:59:49 -07:00
|
|
|
|
2019-09-09 18:35:56 -07:00
|
|
|
/// A `pong` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#pong)
|
2019-09-10 13:27:10 -07:00
|
|
|
Pong(
|
2019-09-09 18:35:56 -07:00
|
|
|
/// The nonce from the `Ping` message this was in response to.
|
2019-09-10 13:27:10 -07:00
|
|
|
Nonce,
|
|
|
|
),
|
2019-09-10 09:57:58 -07:00
|
|
|
|
|
|
|
/// A `reject` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#reject)
|
2019-09-11 11:11:48 -07:00
|
|
|
Reject {
|
|
|
|
/// Type of message rejected.
|
|
|
|
// Q: can we just reference the Type, rather than instantiate an instance of the enum type?
|
|
|
|
message: Box<Message>,
|
|
|
|
|
|
|
|
/// RejectReason code relating to rejected message.
|
|
|
|
ccode: RejectReason,
|
|
|
|
|
|
|
|
/// Human-readable version of rejection reason.
|
|
|
|
reason: String,
|
|
|
|
|
|
|
|
/// Optional extra data provided for some errors.
|
|
|
|
// Currently, all errors which provide this field fill it with
|
|
|
|
// the TXID or block header hash of the object being rejected,
|
|
|
|
// so the field is 32 bytes.
|
|
|
|
//
|
|
|
|
// Q: can we tell Rust that this field is optional? Or just
|
|
|
|
// default its value to an empty array, I guess.
|
2019-09-11 19:44:13 -07:00
|
|
|
data: [u8; 32],
|
2019-09-11 11:11:48 -07:00
|
|
|
},
|
2019-09-10 09:57:58 -07:00
|
|
|
|
|
|
|
/// An `addr` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#addr)
|
2019-09-12 03:36:50 -07:00
|
|
|
Addr(Vec<MetaAddr>),
|
2019-09-10 09:57:58 -07:00
|
|
|
|
|
|
|
/// A `getaddr` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#getaddr)
|
|
|
|
GetAddr,
|
|
|
|
|
|
|
|
/// A `block` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#block)
|
|
|
|
Block {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `getblocks` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#getblocks)
|
|
|
|
GetBlocks {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `headers` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#headers)
|
|
|
|
Headers {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `getheaders` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#getheaders)
|
|
|
|
GetHeaders {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// An `inv` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#inv)
|
|
|
|
// XXX the bitcoin reference above suggests this can be 1.8 MB in bitcoin -- maybe
|
|
|
|
// larger in Zcash, since Zcash objects could be bigger (?) -- does this tilt towards
|
|
|
|
// having serialization be async?
|
2019-09-11 19:44:13 -07:00
|
|
|
Inventory {
|
|
|
|
/// Number of inventory entries.
|
|
|
|
count: u64,
|
|
|
|
|
|
|
|
/// Inventory vectors.
|
|
|
|
inventory: Vec<zebra_chain::types::InventoryVector>,
|
|
|
|
},
|
2019-09-10 09:57:58 -07:00
|
|
|
|
|
|
|
/// A `getdata` message.
|
|
|
|
///
|
2019-09-11 19:44:13 -07:00
|
|
|
/// `getdata` is used in response to `inv`, to retrieve the content of
|
|
|
|
/// a specific object, and is usually sent after receiving an `inv`
|
|
|
|
/// packet, after filtering known elements.
|
|
|
|
///
|
2019-09-10 09:57:58 -07:00
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#getdata)
|
2019-09-11 19:44:13 -07:00
|
|
|
GetData {
|
|
|
|
/// Number of inventory entries.
|
|
|
|
count: u64,
|
|
|
|
|
|
|
|
/// Inventory vectors.
|
|
|
|
inventory: Vec<zebra_chain::types::InventoryVector>,
|
|
|
|
},
|
2019-09-10 09:57:58 -07:00
|
|
|
|
|
|
|
/// A `notfound` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#notfound)
|
2019-09-11 19:44:13 -07:00
|
|
|
// See note above on `Inventory`.
|
|
|
|
NotFound {
|
|
|
|
/// Number of inventory entries.
|
|
|
|
count: u64,
|
|
|
|
|
|
|
|
/// Inventory vectors.
|
|
|
|
inventory: Vec<zebra_chain::types::InventoryVector>,
|
|
|
|
},
|
2019-09-10 09:57:58 -07:00
|
|
|
|
|
|
|
/// A `tx` message.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#tx)
|
|
|
|
Tx {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `mempool` message.
|
|
|
|
///
|
|
|
|
/// This was defined in [BIP35], which is included in Zcash.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#mempool)
|
|
|
|
/// [BIP35]: https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki
|
|
|
|
Mempool {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `filterload` message.
|
|
|
|
///
|
|
|
|
/// This was defined in [BIP37], which is included in Zcash.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock)
|
|
|
|
/// [BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
|
|
|
|
FilterLoad {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `filteradd` message.
|
|
|
|
///
|
|
|
|
/// This was defined in [BIP37], which is included in Zcash.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock)
|
|
|
|
/// [BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
|
|
|
|
FilterAdd {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `filterclear` message.
|
|
|
|
///
|
|
|
|
/// This was defined in [BIP37], which is included in Zcash.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock)
|
|
|
|
/// [BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
|
|
|
|
FilterClear {/* XXX add fields */},
|
|
|
|
|
|
|
|
/// A `merkleblock` message.
|
|
|
|
///
|
|
|
|
/// This was defined in [BIP37], which is included in Zcash.
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock)
|
|
|
|
/// [BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
|
|
|
|
MerkleBlock {/* XXX add fields */},
|
2019-09-09 18:35:56 -07:00
|
|
|
}
|
|
|
|
|
2019-09-11 19:44:13 -07:00
|
|
|
/// Reject Reason CCodes
|
|
|
|
///
|
|
|
|
/// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#reject)
|
2019-09-11 11:11:48 -07:00
|
|
|
#[repr(u8)]
|
|
|
|
#[allow(missing_docs)]
|
|
|
|
pub enum RejectReason {
|
|
|
|
Malformed = 0x01,
|
|
|
|
Invalid = 0x10,
|
|
|
|
Obsolete = 0x11,
|
|
|
|
Duplicate = 0x12,
|
|
|
|
Nonstandard = 0x40,
|
|
|
|
Dust = 0x41,
|
|
|
|
InsufficientFee = 0x42,
|
2019-09-11 19:44:13 -07:00
|
|
|
Checkpoint = 0x43,
|
2019-09-11 11:11:48 -07:00
|
|
|
}
|
2019-09-13 05:29:17 -07:00
|
|
|
|
|
|
|
// Q: how do we want to implement serialization, exactly? do we want to have
|
|
|
|
// something generic over stdlib Read and Write traits, or over async versions
|
|
|
|
// of those traits?
|
|
|
|
//
|
|
|
|
// Note: because of the way the message structure is defined (checksum comes
|
|
|
|
// first) we can't write the message headers before collecting the whole body
|
|
|
|
// into a buffer
|
|
|
|
//
|
|
|
|
// Maybe just write some functions and refactor later?
|
|
|
|
|
2019-09-14 08:16:01 -07:00
|
|
|
impl ZcashSerialization for Message {
|
|
|
|
fn write<W: io::Write>(
|
|
|
|
&self,
|
|
|
|
mut writer: W,
|
|
|
|
magic: Magic,
|
|
|
|
version: Version,
|
|
|
|
) -> Result<(), SerializationError> {
|
2019-09-13 05:29:17 -07:00
|
|
|
// Because the header contains a checksum of
|
|
|
|
// the body data, it must be written first.
|
|
|
|
let mut body = Vec::new();
|
2019-09-14 08:16:01 -07:00
|
|
|
self.write_body(&mut body, magic, version)?;
|
2019-09-13 05:29:17 -07:00
|
|
|
|
|
|
|
use Message::*;
|
|
|
|
// Note: because all match arms must have
|
|
|
|
// the same type, and the array length is
|
|
|
|
// part of the type, having at least one
|
|
|
|
// of length 12 checks that they are all
|
|
|
|
// of length 12, as they must be &[u8; 12].
|
|
|
|
let command = match *self {
|
|
|
|
Version { .. } => b"version\0\0\0\0\0",
|
|
|
|
Verack { .. } => b"verack\0\0\0\0\0\0",
|
|
|
|
Ping { .. } => b"ping\0\0\0\0\0\0\0\0",
|
|
|
|
Pong { .. } => b"pong\0\0\0\0\0\0\0\0",
|
|
|
|
Reject { .. } => b"reject\0\0\0\0\0\0",
|
|
|
|
Addr { .. } => b"addr\0\0\0\0\0\0\0\0",
|
|
|
|
GetAddr { .. } => b"getaddr\0\0\0\0\0",
|
|
|
|
Block { .. } => b"block\0\0\0\0\0\0\0",
|
|
|
|
GetBlocks { .. } => b"getblocks\0\0\0",
|
|
|
|
Headers { .. } => b"headers\0\0\0\0\0",
|
|
|
|
GetHeaders { .. } => b"getheaders\0\0",
|
|
|
|
Inventory { .. } => b"inv\0\0\0\0\0\0\0\0\0",
|
|
|
|
GetData { .. } => b"getdata\0\0\0\0\0",
|
|
|
|
NotFound { .. } => b"notfound\0\0\0\0",
|
|
|
|
Tx { .. } => b"tx\0\0\0\0\0\0\0\0\0\0",
|
|
|
|
Mempool { .. } => b"mempool\0\0\0\0\0",
|
|
|
|
FilterLoad { .. } => b"filterload\0\0",
|
|
|
|
FilterAdd { .. } => b"filteradd\0\0\0",
|
|
|
|
FilterClear { .. } => b"filterclear\0",
|
|
|
|
MerkleBlock { .. } => b"merkleblock\0",
|
|
|
|
};
|
|
|
|
|
|
|
|
// Write the header and then the body.
|
2019-09-14 08:20:23 -07:00
|
|
|
writer.write_all(&magic.0)?;
|
2019-09-13 05:29:17 -07:00
|
|
|
writer.write_all(command)?;
|
|
|
|
writer.write_u32::<LittleEndian>(body.len() as u32)?;
|
|
|
|
writer.write_all(&Sha256dChecksum::from(&body[..]).0)?;
|
2019-09-14 08:16:01 -07:00
|
|
|
writer.write_all(&body)?;
|
2019-09-13 05:29:17 -07:00
|
|
|
|
2019-09-14 08:16:01 -07:00
|
|
|
Ok(())
|
2019-09-13 05:29:17 -07:00
|
|
|
}
|
|
|
|
|
2019-09-14 08:16:01 -07:00
|
|
|
/// Try to read `self` from the given `reader`.
|
|
|
|
fn try_read<R: io::Read>(
|
|
|
|
_reader: R,
|
|
|
|
_magic: Magic,
|
|
|
|
_version: Version,
|
|
|
|
) -> Result<Self, SerializationError> {
|
2019-09-13 05:29:17 -07:00
|
|
|
unimplemented!()
|
|
|
|
}
|
|
|
|
}
|
2019-09-14 09:00:59 -07:00
|
|
|
|
|
|
|
impl Message {
|
|
|
|
/// Write the body of the message into the given writer. This allows writing
|
|
|
|
/// the message body prior to writing the header, so that the header can
|
|
|
|
/// contain a checksum of the message body.
|
|
|
|
fn write_body<W: io::Write>(
|
|
|
|
&self,
|
|
|
|
mut writer: W,
|
|
|
|
m: Magic,
|
|
|
|
v: Version,
|
|
|
|
) -> Result<(), SerializationError> {
|
|
|
|
use Message::*;
|
|
|
|
match *self {
|
|
|
|
Version {
|
|
|
|
ref version,
|
|
|
|
ref services,
|
|
|
|
ref timestamp,
|
|
|
|
ref address_receiving,
|
|
|
|
ref address_from,
|
|
|
|
ref nonce,
|
|
|
|
ref user_agent,
|
|
|
|
ref start_height,
|
|
|
|
ref relay,
|
|
|
|
} => {
|
|
|
|
writer.write_u32::<LittleEndian>(version.0)?;
|
|
|
|
writer.write_u64::<LittleEndian>(services.0)?;
|
|
|
|
writer.write_i64::<LittleEndian>(timestamp.timestamp())?;
|
|
|
|
|
|
|
|
// We represent a Bitcoin net_addr as a `MetaAddr` internally.
|
|
|
|
// However, the version message encodes net_addrs without the
|
|
|
|
// timestamp field, so we encode the `MetaAddr`s manually here.
|
|
|
|
writer.write_u64::<LittleEndian>(address_receiving.services.0)?;
|
|
|
|
address_receiving.addr.ip().write(&mut writer, m, v)?;
|
|
|
|
writer.write_u16::<BigEndian>(address_receiving.addr.port())?;
|
|
|
|
|
|
|
|
writer.write_u64::<LittleEndian>(address_from.services.0)?;
|
|
|
|
address_from.addr.ip().write(&mut writer, m, v)?;
|
|
|
|
writer.write_u16::<BigEndian>(address_from.addr.port())?;
|
|
|
|
|
|
|
|
writer.write_u64::<LittleEndian>(nonce.0)?;
|
|
|
|
user_agent.write(&mut writer, m, v)?;
|
|
|
|
writer.write_u32::<LittleEndian>(start_height.0)?;
|
|
|
|
writer.write_u8(*relay as u8)?;
|
|
|
|
}
|
|
|
|
_ => unimplemented!(),
|
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Try to deserialize a [`Message`] from the given reader.
|
|
|
|
pub fn try_read_body<R: io::Read>(
|
|
|
|
_reader: R,
|
|
|
|
_magic: Magic,
|
|
|
|
_version: Version,
|
|
|
|
) -> Result<Self, SerializationError> {
|
|
|
|
unimplemented!()
|
|
|
|
}
|
|
|
|
}
|