-
Notifications
You must be signed in to change notification settings - Fork 55
Use Txid
, BlockHash
, DescriptorId
, and TxMerkleNode
where applicable
#764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
use crate::bitcoin::{Header, Transaction}; | ||
use crate::bitcoin::{BlockHash, Header, Transaction, Txid}; | ||
use crate::error::ElectrumError; | ||
use crate::types::Update; | ||
use crate::types::{FullScanRequest, SyncRequest}; | ||
|
@@ -131,12 +131,12 @@ impl ElectrumClient { | |
} | ||
|
||
/// Broadcasts a transaction to the network. | ||
pub fn transaction_broadcast(&self, tx: &Transaction) -> Result<String, ElectrumError> { | ||
pub fn transaction_broadcast(&self, tx: &Transaction) -> Result<Arc<Txid>, ElectrumError> { | ||
let bdk_transaction: BdkTransaction = tx.into(); | ||
self.0 | ||
.transaction_broadcast(&bdk_transaction) | ||
.map_err(ElectrumError::from) | ||
.map(|txid| txid.to_string()) | ||
.map(|txid| Arc::new(Txid(txid))) | ||
} | ||
|
||
/// Returns the capabilities of the server. | ||
|
@@ -177,7 +177,7 @@ pub struct ServerFeaturesRes { | |
/// Server version reported. | ||
pub server_version: String, | ||
/// Hash of the genesis block. | ||
pub genesis_hash: String, | ||
pub genesis_hash: Arc<BlockHash>, | ||
/// Minimum supported version of the protocol. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is a kotlin test that fails when I run locally here Its seems the hash type is returning the reverse byte order (little-endian)
This will happen for any other tests like these. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will investigate this, as I am not sure if this is an Electrum protocol quark or the result of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright 👍 On my test from here I did notice There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would expect that to be the case, since it is the consensus encoding. That is fine when going to and from bytes. What I am skeptical of is the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah! I see. 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for that catch! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure of what the code was before the fix I now see, but when I parse the bytes into a BlockHash I get the correct hash and the tests work well. For example: fn from(value: BdkServerFeaturesRes) -> ServerFeaturesRes {
let blockhash: BlockHash = BlockHash::from_bytes(value.genesis_hash.into_vec()).unwrap();
ServerFeaturesRes {
server_version: value.server_version,
genesis_hash: Arc::new(blockhash),
protocol_min: value.protocol_min,
protocol_max: value.protocol_max,
hash_function: value.hash_function,
pruning: value.pruning,
}
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The old state of the code was that. You should run The This is the rare (and only?) case we will be parsing bytes that have not been consensus serialized There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh sorry I ran my tests locally but didn't recompile, so they were passing but it's because I wasn't on my fixed code haha. Yes I see them fail now. Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Really odd. I'm trying to find out where this behavior is defined. The docs for Electrum are not clear: https://electrumx.readthedocs.io/en/latest/protocol-methods.html#server-features |
||
pub protocol_min: String, | ||
/// Maximum supported version of the protocol. | ||
|
@@ -190,9 +190,11 @@ pub struct ServerFeaturesRes { | |
|
||
impl From<BdkServerFeaturesRes> for ServerFeaturesRes { | ||
fn from(value: BdkServerFeaturesRes) -> ServerFeaturesRes { | ||
let hash_str = value.genesis_hash.to_hex_string(Case::Lower); | ||
let blockhash = hash_str.parse::<bdk_core::bitcoin::BlockHash>().unwrap(); | ||
ServerFeaturesRes { | ||
server_version: value.server_version, | ||
genesis_hash: value.genesis_hash.to_hex_string(Case::Lower), | ||
genesis_hash: Arc::new(BlockHash(blockhash)), | ||
protocol_min: value.protocol_min, | ||
protocol_max: value.protocol_max, | ||
hash_function: value.hash_function, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here we could return a straight
DescriptorId
instead of an Arc. Let me know if you had a reason to prefer the Arc.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything will be reference counted in the target language anyway, so it doesn't seem like a big deal to go with the
Arc
. The only thing that shouldn't useArc
isuniffi::Record
imoThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hate that this is not clear (or maybe it's just not clear for me?) and loosey goosey from the point of view of library builders.
There are places where removing an Arc will actually throw at compile time, others where the Arc gets added for you even if you don't have it there...