Documentation

Transactions are typically not big, but in principle in future we could have ones over 64k large.

The kind of the transaction-submission protocol, and the types of the states in the protocol state machine.

We describe this protocol using the label "client" for the peer that is submitting transactions, and "server" for the one receiving them. The protocol is however pull based, so it is typically the server that has agency in this protocol. This is the opposite of the chain sync and block fetch protocols, but that makes sense because the information flow is also reversed: submitting transactions rather than receiving headers and blocks.

Because these client/server labels are somewhat confusing in this case, we sometimes clarify by using the terms inbound and outbound. This refers to whether transactions are flowing towards a peer or away, and thus indicates what role the peer is playing.

The value level equivalent of StBlockingStyle.

This is also used in MsgRequestTxIds where it is interpreted (and can be encoded) as a Bool with True for blocking, and False for non-blocking.

We have requests for lists of things. In the blocking case the corresponding reply must be non-empty, whereas in the non-blocking case and empty reply is fine.