Closed torkelrogstad closed 1 week ago
The multiple versions of bitcoin
is annoying, and something that happens quite frequently as the bitcoin
crate often makes breaking API changes.
Trying to maintain a single version is futile. The best approach is to consistently use a recent version, and to use older versions compatible with dependencies as little as possible. Most crates using the bitcoin
crate re-export it so that this is easy to do.
If it were reasonable to do so, I'd lint for this
use other_crate::bitcoin::{...};
except when aliased or anonymous, ie.
use other_crate::bitcoin::{
self as other_crate_bitcoin, TxOut as OtherCrateTxOut, consensus::Encodable as _,
};
There are some exceptions though, eg. the wallet code needs to be compatible with BDK, so using bdk::bitcoin
at the module scope is fine.
Since this occurs often, perhaps we should publish a crate that facilitates easy conversion between types from different versions of bitcoin
?
Since this occurs often, perhaps we should publish a crate that facilitates easy conversion between types from different versions of bitcoin?
Wouldn't a new create just make the problem even worse by introducing yet another version? Or perhaps it's possible to implement this in a version-agnostic way. If so, that'd be really nice.
This should close #43
We're using two different version of rust-bitcoin throughout the project. One from bitcoin, and one re-exported from bdk. This leads to a bit wrangling back and forth to get the compiler to be happy. Would be very nice to converge on only one of these versions.
This should be fixed in a separate PR.
I opened an issue for this: #45
This RPC should insert a row into the bmm_requests
table that was added in #41
Closes #43
TODO:
cargo.toml
The code here has been used to construct seemingly valid BMM requests, for example here: https://mempool.drivechain.live/tx/48304f36b955f45901af77d2aa8f61893f7687ba3332601ad326da664bad1575
To try this for yourselves, you'll have to apply this patch in order to bypass the active sidechain + correct main hash checks:
You can then try the endpoint:
Note that in this case the hex printed to the console is not the TXID of the broadcasted TX! This is because the
txid
field of the response here is of typeConsensusHex
, and notReverseHex
. The actual TXID isb4847b9796816eff9fc9027e8e215a4e7391b6d9ae8e289532cd75e3d7866a51
.