Implement transaction broadcasting for Kyoto

[rustaceanrob]

The actual implementation comes down to listening for an info message that reports the transaction was sent to a peer. For simplicity I am ignoring any wallet updates, but if the user calls the Sync command they can catch them. Follows up #181

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added tests for the new feature
• I've added docs for the new feature
• I've updated CHANGELOG.md

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[tvpeter]

Probably my network is poor, I have not been able to successfully broadcast a tx but will keep trying.

Thank you for helping with this.

[rustaceanrob]

Probably my network is poor, I have not been able to successfully broadcast a tx but will keep trying.

I am working now to improve the broadcasting reliability in Kyoto, so there is a chance you are running into bugs of mine. However the code here wouldn't change, only internals of the node.

[tvpeter]

only internals of the node.

Would that require updating bdk-kyoto?

[rustaceanrob]

I believe bdk_kyoto would require a patch release as well. I should remark that I have successfully sent transactions with Kyoto over test networks and Bitcoin, so the improvements are more for reliability.

[notmandatory]

I also was unable to get it to broadcast (I'm using testnet4). It looks like it's never getting to this line:

tracing::info!("Successfully gossiped wtxid: {wtxid}");

This is my test command:

cargo run --features cbf -- --network testnet4 wallet --client-type cbf --database-type sqlite broadcast --psbt cHNidP8BAH0CAAAAAQTsUSSbQmlAXySimNJr91qPEdtAQ2oWSFnFzT2HU6LaAAAAAAD9////AhAnAAAAAAAAIlEgll6PCdGT5N+krKcTBtEXtPDmXWAJpaNnC31A0+2LQGB3eQcAAAAAABYAFF4qFgWGhpAQl6/0r/tSDyKH35qrj0ABAAABAJMCAAAAAfWnu2nwuiC8j50p1f4bBXNVSvOS8hlrvK5v1PEXqcOuAQAAAAD9////AyChBwAAAAAAFgAUWmkCfVH7+qtcUl0UN0qZPDkhmP5QhEkAAAAAABYAFHemwsX9qws0MwQ8kFuUloqvnFnFAAAAAAAAAAAZahdmYXVjZXQudGVzdG5ldDQuZGV2IHR4bgAAAAABAR8goQcAAAAAABYAFFppAn1R+/qrXFJdFDdKmTw5IZj+AQhrAkcwRAIgMdjz8lLAeg+gyQ0RgxdbwD4GnykPeAyjBKmaqFCy2DoCIB+P0wVMkbvjTb8MA0E9Ayb5Kl0UEVXLwRKbvdHz291hASEDIuApJoXbhnB4FRqHzde1fnqo0Wg9L4WBTpWpRocR0aMAAAA=

[rustaceanrob]

I think I've ironed out what is happening with this test. Because I don't allow for any buffer of time between the node starting and the attempting to send the transaction, Kyoto advertises the transaction sometime during the version handshake with the remote node. As a result the remote node just drops it on the floor. I will change this to broadcast after a short delay, and timeout with an error if the TxGossiped message is not emitted.

[tvpeter]

Because I don't allow for any buffer of time between the node starting and the attempting to send the transaction, Kyoto advertises the transaction sometime during the version handshake with the remote node. As a result the remote node just drops it on the floor.

That’s exactly what I thought. If there were a way to determine the number of established connections before attempting a broadcast, it would have simplified the process. That is why in the initial implementation, I allowed a 60-second buffer before broadcasting, which made it a bit more reliable.

[rustaceanrob]

There is Info::ConnectionsMet, but that is only emitted once the total requirement is met, but it would make the broadcast more reliable. I am going to add a short sleep, then await the TxGossiped with a timeout. If it fails for some reason, the user can try again. Thanks for the observation!

[rustaceanrob]

I was able to successfully broadcast a transaction with the most recent commit. I changed the default connections to 2, as there are only a couple CBF nodes on testnet4 and signet

[notmandatory]

Even with the latest commit I was unable to broadcast a Tx. I did a little debugging and found that I get info_subscriber.len() = 0 right before the while let Some(info) = info_subscriber.recv().await { ... code is called which means it returns None and nothing is ever broadcast.

@rustaceanrob what OS are you using? I'm on MacOS (M1). Could it be some timing difference or way tokio is handling multiple threads? I also tried adding a sleep prior to the above line and it didn't make a difference.

[rustaceanrob]

It sounds like your node is returning an error when calling "run". I suggest removing the light_client_data directory. The only time I've gotten errors is 1. the light_client_data directory is in use by another program 2. the wallet is requesting a sync lower than the headers Kyoto is able to load from SQL

[notmandatory]

You were right! I cleared the light_client_data directory and re-sync'd skipping the first 50K blocks and then I was able to broadcast.

I probably ran into this because the wallet data and light_client_data were in different spots and I probably removed one and not the other during testing, #183 puts them under the same parent. I still think this could use some better error reports to see when issues like this come up, but that can come in future PRs.

[notmandatory]

ACK 8ac6957

Please just rebase and fix the build warning and typo and then I'll merge it. Or if you're busy let me know and I'll do it. Thanks!

[notmandatory]

ACK 811f614