Skip to content

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

Merged
merged 2 commits into from
Nov 23, 2023

Conversation

wpaulino
Copy link
Contributor

@wpaulino wpaulino commented Nov 21, 2023

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.

@wpaulino wpaulino added this to the 0.0.119 milestone Nov 21, 2023
Copy link
Contributor

@tnull tnull left a 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.

@wpaulino wpaulino force-pushed the rust-bitcoin-30-update branch 2 times, most recently from 2930eb9 to 8fc4764 Compare November 21, 2023 21:23
@codecov-commenter
Copy link

codecov-commenter commented Nov 21, 2023

Codecov Report

Attention: 53 lines in your changes are missing coverage. Please review.

Comparison is base (870a0f1) 88.55% compared to head (ad56847) 88.50%.

Files Patch % Lines
lightning/src/chain/channelmonitor.rs 86.88% 5 Missing and 3 partials ⚠️
lightning-block-sync/src/convert.rs 77.77% 0 Missing and 4 partials ⚠️
lightning-invoice/src/lib.rs 63.63% 4 Missing ⚠️
lightning/src/chain/mod.rs 0.00% 4 Missing ⚠️
lightning/src/ln/channel.rs 88.88% 4 Missing ⚠️
lightning/src/sign/mod.rs 90.00% 2 Missing and 2 partials ⚠️
lightning-block-sync/src/init.rs 25.00% 3 Missing ⚠️
lightning/src/events/bump_transaction.rs 81.25% 3 Missing ⚠️
lightning-block-sync/src/poll.rs 60.00% 2 Missing ⚠️
lightning-block-sync/src/rest.rs 60.00% 2 Missing ⚠️
... and 12 more

❗ 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.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@tnull tnull left a 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.

Copy link
Contributor

@valentinewallace valentinewallace left a 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.

@wpaulino wpaulino force-pushed the rust-bitcoin-30-update branch from 768b975 to 8220621 Compare November 22, 2023 23:50
@wpaulino
Copy link
Contributor Author

Squashed and found a way to drop one of the commits (wpaulino@9857df3).

Copy link
Contributor

@valentinewallace valentinewallace left a 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.

@wpaulino wpaulino force-pushed the rust-bitcoin-30-update branch from 6181985 to ad56847 Compare November 22, 2023 23:58
Copy link
Contributor

@tnull tnull left a 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.

@tnull tnull merged commit 70ea110 into lightningdevkit:main Nov 23, 2023
Copy link
Contributor

@Kixunil Kixunil left a 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(),
Copy link
Contributor

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(),
Copy link
Contributor

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,
}
Copy link
Contributor

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?

Copy link
Collaborator

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.

Copy link
Contributor

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?

Copy link
Collaborator

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 :)

Copy link
Contributor

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));
Copy link
Contributor

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?

Copy link
Contributor Author

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");
Copy link
Contributor

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();
Copy link
Contributor

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.

@wpaulino wpaulino deleted the rust-bitcoin-30-update branch November 27, 2023 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bump rust-bitcoin to 0.30.0
7 participants