Skip to content

Document lightning crate features #1478

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 1 commit into from
May 25, 2022
Merged

Conversation

mattfaltyn
Copy link
Contributor

Closes #1462.

Issue: We have a few features defined in Cargo.toml with comments describing their use, but we don't expose them in the crate-level lib.rs documentation, making docs pretty much invisible. We should copy the text over, expand it, and clarify it so that you can see the features on docs.rs.

Changes: I have added the features defined in Cargo.toml (with comments) into the crate-level lib.rs documentation - please let me know if you want more comprehensive descriptions and/or if the structure of the documentation should change. I am new to Rust and happy to learn :)

@mattfaltyn mattfaltyn changed the title Document lightning crate features #1462 Document lightning crate features May 12, 2022
Copy link
Collaborator

@TheBlueMatt TheBlueMatt 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 tackling this one!

//!
//! Some of the features include:
//!
//! 1. Internal test utilities exposed to other repo crates:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should document this - no one but us should ever use it, and we just use it for other creates in the same repo.

//! max_level_trace = []
//! ```
//!
//! 3. Allow signing of local transactions that may have been revoked or will be revoked, for functional testing (e.g. justice tx handling). This is unsafe to use in production because it may result in the counterparty publishing taking our funds.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets not document "unsafe in production" stuff :)

//! unsafe_revoked_tx_signing = []
//! _bench_unstable = []
//!
//! no-std = ["hashbrown", "bitcoin/no-std", "core2/alloc"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should add comments for no-std and std saying, well, "std enables things which require std, including std::io trait implementations and things which utilize time" and "no-std exposes write trait implementations from the core2crate"

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 having look!
So far I think you're mostly stating what the features are, but not what they do. It's probably best to keep it brief, but it would still be highly appreciated if you could at least roughly describe why a user would want to enable/disable a particular feature.

//! std = ["bitcoin/std"]
//! ```
//!
//! 4. Generate low-r bitcoin signatures, which saves 1 byte in 50% of the cases:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mh, from/for what does it save 1 byte in 50%? Could you explain what the feature does and maybe supply a reference for further reading, e.g., bitcoin/bitcoin#13666 or https://bitcoin.stackexchange.com/questions/111660/what-is-signature-grinding?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TheBlueMatt @tnull thank you for your comments and suggestions! I made the recommend changes!

//!
//! 2. Allow signing of local transactions that may have been revoked or will be revoked,
//! for functional testing (e.g. justice tx handling):
//! * `unsafe_revoked_tx_signing` - allows unsafe signing in dev code, such as functional testing of justice transactions outside our crate
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets not document test-only features like unsafe_revoked_tx_signing and _bench_unstable.

//! for functional testing (e.g. justice tx handling):
//! * `unsafe_revoked_tx_signing` - allows unsafe signing in dev code, such as functional testing of justice transactions outside our crate
//! * `_bench_unstable` - allows test features for benching
//! * `no-std ` - exposes write trait implementations from the `core2` crate
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not listed (ie with a 2. in front)?

//! `default` features are:
//!
//! * `std` - enables things which require `std`, including `std::io` trait implementations and things which utilize time
//! * `grind_signatures` - enables generation of [low-r bitcoin signatures](https://bitcoin.stackexchange.com/questions/111660/what-is-signature-grinding), which saves 1 byte per signature in 50% of the cases (see [bitcoin PR #13666](https://github.com/bitcoin/bitcoin/pull/13666))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we just move these to the list above and then list default features separately?

Copy link
Contributor Author

@mattfaltyn mattfaltyn May 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TheBlueMatt what other features are in default apart from std and grind_signatures? I just see those two in Cargo.toml.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just meant that we should maybe document std and grind_signatures in the same section as everything else, and then separately mention that default includes those two, rather than documenting them in a separate section.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see will do - thanks for the clarification!

//!
//! `default` features are:
//!
//! * `std` - enables things which require `std`, including `std::io` trait implementations and things which utilize time
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "things" is a bit unspecific/casual here. Maybe "functionalities", avoiding the obvious "features"?

//!
//! Available features are:
//!
//! 1. Skip logging of messages at levels below the given log level:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can switch the order here, so that the arguably more important (default) features are described up top, and the logging/debugging things are listed beneath?

@codecov-commenter
Copy link

codecov-commenter commented May 19, 2022

Codecov Report

Merging #1478 (7067373) into main (75ca50f) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1478      +/-   ##
==========================================
- Coverage   90.93%   90.93%   -0.01%     
==========================================
  Files          77       77              
  Lines       42394    42394              
  Branches    42394    42394              
==========================================
- Hits        38553    38550       -3     
- Misses       3841     3844       +3     
Impacted Files Coverage Δ
lightning/src/lib.rs 100.00% <ø> (ø)
lightning-net-tokio/src/lib.rs 75.91% <0.00%> (-0.31%) ⬇️
lightning/src/ln/functional_tests.rs 97.08% <0.00%> (-0.04%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 75ca50f...7067373. Read the comment docs.

@mattfaltyn
Copy link
Contributor Author

@TheBlueMatt @tnull made the recommended changes! Thanks for your continued reviews!

//! * `std`
//! * `grind_signatures`
//! * `no-std ` - exposes write trait implementations from the `core2` crate
//! * `justice_tx_handling` - allows signing of local transactions that may have been revoked or will be revoked for functional testing
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we ever want anyone using this - its basically a debug feature to enable unsafe behavior during testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good - I will remove it.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Can you rebase to clean up the git history (rather than merging in upstream changes, there shouldn't generally be any reason to do that) and we can land it? 🚀

//!
//! * `std`
//! * `grind_signatures`
//! * `no-std ` - exposes write trait implementations from the `core2` crate
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: maybe say "at least one of no-std or std are required"

@@ -17,6 +17,24 @@
//! figure out how best to make networking happen/timers fire/things get written to disk/keys get
//! generated/etc. This makes it a good candidate for tight integration into an existing wallet
//! instead of having a rather-separate lightning appendage to a wallet.
//!
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: a number of lines here have whitespace at EOL, would be nice to remove that.

@mattfaltyn
Copy link
Contributor Author

Looks good to me! Can you rebase to clean up the git history (rather than merging in upstream changes, there shouldn't generally be any reason to do that) and we can land it? 🚀

Rebased! Let me know if you want me to make any more changes :)

@TheBlueMatt
Copy link
Collaborator

Looks like there's still three commits? Can you squash down the fixup commits into a consistent git history that doesn't contain fixes for earlier commits in later ones.

@mattfaltyn mattfaltyn force-pushed the issue1462 branch 2 times, most recently from e95e8c0 to b68ad7a Compare May 21, 2022 03:44
@mattfaltyn
Copy link
Contributor Author

Looks like there's still three commits? Can you squash down the fixup commits into a consistent git history that doesn't contain fixes for earlier commits in later ones.

Not sure how I missed that - thanks for the heads up!

@TheBlueMatt
Copy link
Collaborator

Can you reword the commit from "Removed justice_tx_handling" to something about documenting features?

tnull
tnull previously approved these changes May 21, 2022
@mattfaltyn
Copy link
Contributor Author

Can you reword the commit from "Removed justice_tx_handling" to something about documenting features?

Yup! Done!

@mattfaltyn mattfaltyn requested a review from TheBlueMatt May 24, 2022 15:58
TheBlueMatt
TheBlueMatt previously approved these changes May 24, 2022
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though it looks like there's still EOL whitespace on a few lines. Also, if you fix that can you break lines at around 100 chars long?

@TheBlueMatt
Copy link
Collaborator

Please don't push merge commits to PRs, please rebase instead.

@mattfaltyn
Copy link
Contributor Author

Please don't push merge commits to PRs, please rebase instead.

Sorry I am having a hard time rebasing properly - any good guides to read?

@mattfaltyn
Copy link
Contributor Author

Would I be able to delete this PR and create a new one? It has become very messy and I don't want to make it a headache for you.

@tnull
Copy link
Contributor

tnull commented May 24, 2022

Sorry I am having a hard time rebasing properly - any good guides to read?

Not sure about a guide right now, but you basically just want to use git pull --rebase <remote> <branch> (for me typically git pull --rebase upstream main, assuming upstream is your remote pointing to this repository, not your fork).

You may also want to have a look at the man git-rebase, in particular at the section for git rebase --interactive, which allows you to not only rebase, but also to squash down commits etc.

Since I find that I almost always want to rebase instead of merge, I set

[pull]
	rebase = true

in my .gitconfig, which allows me to default to rebasing.

Would I be able to delete this PR and create a new one? It has become very messy and I don't want to make it a headache for you.

Don't worry! You're almost there, please don't give up now! :)

@TheBlueMatt
Copy link
Collaborator

I generally point people to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

@mattfaltyn
Copy link
Contributor Author

@TheBlueMatt @tnull Thank you for your support! I think I managed to clean things up with your help :)

@mattfaltyn
Copy link
Contributor Author

@tnull can you please re-approve this PR?

@tnull
Copy link
Contributor

tnull commented May 25, 2022

@tnull can you please re-approve this PR?

I already did, but I think we need to get another person that has merge rights to do that.

@mattfaltyn
Copy link
Contributor Author

@tnull can you please re-approve this PR?

I already did, but I think we need to get another person that has merge rights to do that.

Thanks for letting me know! @TheBlueMatt is there anything I should do at this point in time with regards to this PR?

@jkczyz jkczyz merged commit 440ea94 into lightningdevkit:main May 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document lightning crate features
5 participants