-
Notifications
You must be signed in to change notification settings - Fork 407
Update to rust-bitcoin v0.30.2 #2740
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
Conversation
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.
Thanks for looking into this!
Seems tests are failing due to invalid PoWs in lightning-block-sync
. I poked around a bit but couldn't immediately see what the issue is.
2930eb9
to
8fc4764
Compare
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2740 +/- ##
==========================================
- Coverage 88.55% 88.50% -0.06%
==========================================
Files 113 113
Lines 89330 89323 -7
Branches 89330 89323 -7
==========================================
- Hits 79110 79052 -58
- Misses 7849 7896 +47
- Partials 2371 2375 +4 ☔ View full report in Codecov by Sentry. |
8fc4764
to
768b975
Compare
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.
LGTM from my side, I think.
Given the size of the changeset and its invasiveness having a second reviewer seems appropriate though.
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.
Whew, LGTM. Good to squash if we want to fix check-commits
.
768b975
to
8220621
Compare
Squashed and found a way to drop one of the commits (wpaulino@9857df3). |
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.
Someone feel free to land this after CI passes if I'm AFK, since @tnull also ack'd previously.
8220621
to
6181985
Compare
6181985
to
ad56847
Compare
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.
LGTM! CI failure is unrelated, so I'm going ahead landing this.
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.
Congrats on merging this! I took a look to see what we can improve in bitcoin
and found some inspiration and also potential improvements on your side.
@@ -298,14 +302,14 @@ pub(crate) mod tests { | |||
fn from(data: BlockHeaderData) -> Self { | |||
let BlockHeaderData { chainwork, height, header } = data; | |||
serde_json::json!({ | |||
"chainwork": chainwork.to_string()["0x".len()..], | |||
"chainwork": chainwork.to_be_bytes().as_hex().to_string(), |
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.
FYI this could be format!("{:064x}", chainwork)
which conveys the intent better.
"time": header.time, | ||
"nonce": header.nonce, | ||
"bits": header.bits.to_hex(), | ||
"previousblockhash": header.prev_blockhash.to_hex(), | ||
"bits": header.bits.to_consensus().to_be_bytes().as_hex().to_string(), |
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.
format!("{08x}", header.bits.to_consensus())
would convey the meaning better but your code is actually faster because std formatting is over-complicated. I've opened an issue to support hex directly on CompactTarget
but that will still be slower than your code.
match WitnessProgram::new(*version, program.clone()) { | ||
Ok(witness_program) => Payload::WitnessProgram(witness_program), | ||
Err(_) => return None, | ||
} |
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.
So previously you'd accept invalid addresses but now you silently ignore them. Is this even correct? Maybe the error handling should be at creation of Fallback::SegWitProgram
, so the variant should change to store WitnessProgram
directly?
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.
These are parsing invoices provided by random scanning. We'd much rather succeed at parsing an invoice with invalid fallback addresses than ignore it, and better to provide some set of fallback addresses than nothing. That said, I'm pretty sure ~no one actually uses the fallback addresses in BOLT11, since unified QR codes via BIP 21 are a thing now.
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.
Perhaps add an API to check if any are invalid so that an application can emit a warning in such case?
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.
Given these things are basically unused, I'm not sure its worth any effort :)
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.
True, I think it should be at least be documented. I'd be pissed if a library silently dropped data even in edge cases.
@@ -4830,20 +4833,20 @@ mod tests { | |||
inputs_total_weight += inp; | |||
} | |||
} | |||
assert_eq!(base_weight + inputs_total_weight as usize, claim_tx.weight() + /* max_length_sig */ (73 * inputs_weight.len() - sum_actual_sigs)); | |||
assert_eq!(base_weight + inputs_total_weight, claim_tx.weight().to_wu() + /* max_length_sig */ (73 * inputs_weight.len() as u64 - sum_actual_sigs)); |
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.
It looks like this could be somehow replaced with predict_weight
(https://docs.rs/bitcoin/latest/bitcoin/blockdata/transaction/fn.predict_weight.html) but the whole code is complicated so I'm not sure what it does.
Anyway, in general we want to avoid operations on raw integers so it might be nice to understand your use case better. Note that Weight
doesn't impl Add
precisely because it breaks naive implementations once there's more than 252 inputs/outputs. I don't see such handling in your code so you might have the same bug here?
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.
We have a few places where we'd benefit from a weight estimation/prediction API. Now that there's one in rust-bitcoin, we should definitely switch over, just didn't want to handle that in this PR.
use crate::prelude::*; | ||
use crate::io; | ||
|
||
#[test] | ||
fn test_channel_id_v1_from_funding_txid() { | ||
let channel_id = ChannelId::v1_from_funding_txid(&[2; 32], 1); | ||
assert_eq!(channel_id.to_hex(), "0202020202020202020202020202020202020202020202020202020202020203"); | ||
assert_eq!(channel_id.0.as_hex().to_string(), "0202020202020202020202020202020202020202020202020202020202020203"); |
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.
Why not channel_id.to_string()
?
let our_node_id = SecretKey::from_slice(&hex::decode("2121212121212121212121212121212121212121212121212121212121212121").unwrap()[..]).unwrap(); | ||
let our_ephemeral = SecretKey::from_slice(&hex::decode("2222222222222222222222222222222222222222222222222222222222222222").unwrap()[..]).unwrap(); | ||
let our_node_id = SecretKey::from_slice(&<Vec<u8>>::from_hex("2121212121212121212121212121212121212121212121212121212121212121").unwrap()[..]).unwrap(); | ||
let our_ephemeral = SecretKey::from_slice(&<Vec<u8>>::from_hex("2222222222222222222222222222222222222222222222222222222222222222").unwrap()[..]).unwrap(); |
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.
Looks like hex_lit::hex
macro would help with these.
I tried to break up most of the changes into logical steps since there were so many things to fix, hopefully it helps.
A good follow-up to this would be to look into
ScriptBuf
uses that don't actually require the owned type.Fixes #2124.