This PR contains #29415 + two more commits that add functional and fuzz tests.
Putting those in a separate PR not to burden the main one, since the tests are extensive:
code: 1036 insertions(+), 91 deletions(-)
tests: 548 insertions(+), 5 deletions(-)
Co-authored-by: brunoerg <brunoely.gc@gmail.com>
We will open a short-lived connection to a random Tor or I2P peer,
send our transaction to that peer and close the connection.
Implement opening `ConnectionType::PRIVATE_BROADCAST` connections with
the following properties:
* Only to Tor or I2P (or IPv4/IPv6 through the Tor proxy, if provided)
* Open such connections only when requested and don't maintain N opened
connections of this type.
* Since this is substantially different than what
`OpenNetworkConnection()` does, open the private broadcast connections
from a different thread instead of modifying `OpenNetworkConnection()`
to also open those types of connections.
Rename `PeerManager::RelayTransaction()` to
`PeerManager::InitiateTxBroadcastToAll()`. The transaction is not
relayed when the method returns. It is only enqueued for a possible
broadcasting at a later time. Also, there will be another method which
only does so to Tor or I2P peers.
Extend `node::TxBroadcast` with a 3rd option to not add the
transaction to the mempool and broadcast privately.
This is a non-functional change - `BroadcastTransaction()` will not
do anything if the 3rd options is passed and is not used by any of
its callers.
Extend `PeerManager` with a transaction storage and a new method
`ScheduleTxForPrivateBroadcast()` which:
* adds a transaction to that storage and
* calls `CConnman::PrivateBroadcastAdd()` to open dedicated privacy
connections that will pick an entry from the transaction storage and
broadcast it.
Change the order in which code snippets are executed as a result of
receiving the `VERSION` message. Move the snippets that do
`MakeAndPushMessage()` near the end. This will help with handling of
private broadcast connections - they do not require any of that.
This is a non-functional change.
For connections of type `ConnectionType::PRIVATE_BROADCAST`:
* After receiving VERACK, relay a transaction from the list of
transactions for private broadcast and disconnect
* Don't process any messages after VERACK
* Don't send any messages other than the minimum required for the
transaction relay
Remove the transaction from the list of transactions to broadcast after
we receive it from the network.
Only remove the transaction if it is the same as the one we sent: both
txid and wtxid match. Don't remove transactions that have the same txid
and different wxtid. Such transactions show that some of the private
broadcast recipients malleated the witness and the transaction made it
back to us. The witness could be either:
* invalid, in which case the transaction will not be accepted in
anybody's pool; or
* valid, in which case either the original or the malleated transaction
will make it to nodes' mempools and eventually be mined. Our response
is to keep broadcasting the original. If the malleated transaction
wins then we will eventually stop broadcasting the original when it
gets stale and gets removed from the "to broadcast" storage cause it
is not acceptable in our mempool.
Periodically check for stale transactions in peerman and if found,
reschedule new connections to be opened by connman for broadcasting
them.
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
