mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-03-13 06:32:13 +01:00
Code Issues Projects Releases Packages Wiki Activity
rust-lightning/lightning/Cargo.toml

71 lines
2.8 KiB
TOML
Raw Normal View History

Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
[package]
name = "lightning"
Bump crate versions to 0.1.0/invoice 0.33.0/dns-resolver 0.2 Sadly, dns-resolver got uploaded as 0.1.0 without a -beta1 tag (and yanked), and thus we release it here as 0.2.0.
2025-01-15 18:12:48 +00:00
version = "0.2.0+git"
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
authors = ["Matt Corallo"]
Update licenses and add missing fields in Cargo.toml files
2021-03-09 16:51:14 -05:00
license = "MIT OR Apache-2.0"
update repo name to use lightningdevkit
2021-12-26 22:53:16 -05:00
repository = "https://github.com/lightningdevkit/rust-lightning/"
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
description = """
A Bitcoin Lightning library in Rust.
Does most of the hard work, without implying a specific runtime, requiring clients implement basic network logic, chain interactions and disk storage.
Still missing tons of error-handling. See GitHub issues for suggested projects if you want to contribute. Don't have to bother telling you not to use this for anything serious, because you'd have to build a client around it to even try.
"""
Bump MSRV to rustc 1.63.0 and edition to 2021 .. which is a reasonable common ground, also supported by Debian stable.
2023-10-24 15:16:38 +02:00
edition = "2021"
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
Generate docs with features for docs.rs Enable generating docs using --all-features or --features="std" where applicable. Additionally, use doc_auto_cfg to tag items requiring a feature. https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#doc_auto_cfg-automatically-generate-doccfg This requires building with nightly, which is what is used by docs.rs. https://docs.rs/about/builds To test locally, use: RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc ...
2022-02-11 22:22:20 -06:00
[package.metadata.docs.rs]
Add the core functionality required to resolve Human Readable Names This adds a new utility struct, `OMNameResolver`, which implements the core functionality required to resolve Human Readable Names, namely generating `DNSSECQuery` onion messages, tracking the state of requests, and ultimately receiving and verifying `DNSSECProof` onion messages. It tracks pending requests with a `PaymentId`, allowing for easy integration into `ChannelManager` in a coming commit - mapping received proofs to `PaymentId`s which we can then complete by handing them `Offer`s to pay. It does not, directly, implement `DNSResolverMessageHandler`, but an implementation of `DNSResolverMessageHandler` becomes trivial with `OMNameResolver` handling the inbound messages and creating the messages to send.
2024-09-12 15:57:42 +00:00
features = ["std", "dnssec"]
Generate docs with features for docs.rs Enable generating docs using --all-features or --features="std" where applicable. Additionally, use doc_auto_cfg to tag items requiring a feature. https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#doc_auto_cfg-automatically-generate-doccfg This requires building with nightly, which is what is used by docs.rs. https://docs.rs/about/builds To test locally, use: RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc ...
2022-02-11 22:22:20 -06:00
rustdoc-args = ["--cfg", "docsrs"]
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
[features]
Introduce CommitmentTransaction, ChannelTransactionParameters CommitmentTransaction maintains the per-commitment transaction fields needed to construct the associated bitcoin transactions (commitment, HTLC). It replaces passing around of Bitcoin transactions. The ChannelKeys API is modified accordingly. By regenerating the transaction when implementing a validating external signer, this allows a higher level of assurance that all relevant aspects of the transactions were checked for policy violations. ChannelTransactionParameters replaces passing around of individual per-channel fields that are needed to construct Bitcoin transactions. Eliminate ChannelStaticData in favor of ChannelTransactionParameters. Use counterparty txid instead of tx in channelmonitor update.
2020-10-15 13:45:18 +02:00
# Internal test utilities exposed to other repo crates
Move `Features` into `lightning-types` `lightning-invoice` currently has a dependency on the entire `lightning` crate just because it wants to use some of the useful types from it. This is obviously backwards and leads to some awkwardness like the BOLT 11 invoice signing API in the `lightning` crate taking a `[u5]` rather than a `Bolt11Invoice`. This takes one more step, moving the `Features` types from `lightning` to `lightning-types`.
2024-08-09 14:20:50 +00:00
_test_utils = ["regex", "bitcoin/bitcoinconsensus", "lightning-types/_test_utils"]
Expose functional tests under _externalize_tests feature flag Also, introduce TestSignerFactory, a factory for dynamic signers and ext-functional-test-demo crate for testing this machinery.
2024-10-01 14:58:36 +02:00
_externalize_tests = ["inventory", "_test_utils"]
export "unsafe_revoked_tx_signing" feature Allows unsafe signing in dev code, such as functional testing of justice transactions outside our crate.
2020-07-03 13:41:21 -07:00
# 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.
unsafe_revoked_tx_signing = []
Implement dummy Mutex, Condvar and RwLock
2021-07-19 16:13:00 +02:00
Remove the `std` feature implications from the `lightning` crate Now that we don't have to have everything in our entire ecosystem use the same `std`/`no-std` feature combinations we should start by untangling our own features a bit. This takes one last step, removing the implications of the `std` feature from the `lightning` crate.
2024-08-17 21:13:08 +00:00
std = []
Implement dummy Mutex, Condvar and RwLock
2021-07-19 16:13:00 +02:00
Add the core functionality required to resolve Human Readable Names This adds a new utility struct, `OMNameResolver`, which implements the core functionality required to resolve Human Readable Names, namely generating `DNSSECQuery` onion messages, tracking the state of requests, and ultimately receiving and verifying `DNSSECProof` onion messages. It tracks pending requests with a `PaymentId`, allowing for easy integration into `ChannelManager` in a coming commit - mapping received proofs to `PaymentId`s which we can then complete by handing them `Offer`s to pay. It does not, directly, implement `DNSResolverMessageHandler`, but an implementation of `DNSResolverMessageHandler` becomes trivial with `OMNameResolver` handling the inbound messages and creating the messages to send.
2024-09-12 15:57:42 +00:00
dnssec = ["dnssec-prover/validation"]
Add low_r signature grinding default on, can be turned off via a feature gate
2022-03-25 20:34:02 +01:00
# Generates low-r bitcoin signatures, which saves 1 byte in 50% of the cases
grind_signatures = []
default = ["std", "grind_signatures"]
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
[dependencies]
Bump crate versions to 0.1.0/invoice 0.33.0/dns-resolver 0.2 Sadly, dns-resolver got uploaded as 0.1.0 without a -beta1 tag (and yanked), and thus we release it here as 0.2.0.
2025-01-15 18:12:48 +00:00
lightning-types = { version = "0.3.0", path = "../lightning-types", default-features = false }
lightning-invoice = { version = "0.34.0", path = "../lightning-invoice", default-features = false }
Add support for mapping old fields to new ones in TLV read macros As we've grown, we regularly face a question of whether to "break out" of our nice TLV-based struct/enum reading/writing macros in order to handle mapping legacy fields to new ones, or deal with keeping the legacy fields and handling at runtime what should be hanlded at (de-)serialization time. This attempts to address this tradeoff by adding support for a "legacy" TLV type. This TLV style allows us to write a a value which is not in the struct/enum's layout in memory but can be calculated from its contents at write-time. The field will also be read and can be use to calculate other fiels defined with `static_value` or `default_value`. It takes a type and a `$write` expression. They are always read as `option`s to retain a future ability to remove the `legacy` fields. Sadly, there's two issues with doing this trivially which force us into `proc-macro` land: (a) when matching the original struct we want to list the fields in the match arm so that we have them available to write. Sadly, we can't call a macro to have it write out the field name based on the field type, so instead need to pass the whole match to a proc-macro and have it walk through to find the types and skip fields that are `legacy`. (b) when building a final struct/enum after reading, we need to list a few `$field: $expr`s and cannot decide whether to include a field based on a regular macro. The proc-macros to do so aren't trivial, but they aren't that bad either. We could instead try to rewrite our TLV stream processing macros to handle a new set of TLVs which are passed via a separate argument, but as TLVs are required to in ordered by type this requires a good chunk of additional generated code in each TLV write. It also would result in a somewhat less ergonomic callsite as it would no longer fit into our existing list of TLVs.
2024-10-21 23:07:26 +00:00
lightning-macros = { version = "0.2", path = "../lightning-macros" }
Move `Payment{Hash,Preimage,Secret}` into a new crate `lightning-invoice` currently has a dependency on the entire `lightning` crate just because it wants to use some of the useful types from it. This is obviously backwards and leads to some awkwardness like the BOLT 11 invoice signing API in the `lightning` crate taking a `[u5]` rather than a `Bolt11Invoice`. This is the first step towards fixing that - moving the common types we need into a new `lightning-types` crate which both can depend on. Since we're using a new crate and can't depend on the existing `lightning` hex utility to implement `Display`, we also take this opportunity to switch to the new `Display` impl macro in `hex_conservative`.
2024-08-09 00:13:41 +00:00
Upgrade bech32 dependency, bech32 serialization improvements
2024-10-02 21:21:07 +02:00
bech32 = { version = "0.11.0", default-features = false }
Upgrade rust-bitcoin to 0.32.2.
2024-08-16 08:02:50 -07:00
bitcoin = { version = "0.32.2", default-features = false, features = ["secp-recovery"] }
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
Add DNS(SEC) query and proof messages and onion message handler This creates the initial DNSSEC proof and query messages in a new module in `onion_message`, as well as a new message handler to handle them. In the coming commits, a default implementation will be added which verifies DNSSEC proofs which can be used to resolve BIP 353 URIs without relying on anything outside of the lightning network.
2024-09-30 16:16:36 +00:00
dnssec-prover = { version = "0.6", default-features = false }
Drop `no-std` feature We drop the `lightning/no-std` feature and just take `hashbrown`,`possiblyrandom` and `libm` as required dependencies.
2024-09-13 13:14:40 +02:00
hashbrown = { version = "0.13", default-features = false }
possiblyrandom = { version = "0.2", path = "../possiblyrandom", default-features = false }
Add DNS(SEC) query and proof messages and onion message handler This creates the initial DNSSEC proof and query messages in a new module in `onion_message`, as well as a new message handler to handle them. In the coming commits, a default implementation will be added which verifies DNSSEC proofs which can be used to resolve BIP 353 URIs without relying on anything outside of the lightning network.
2024-09-30 16:16:36 +00:00
Update regex to 1.5.6
2022-06-01 17:25:15 +02:00
regex = { version = "1.5.6", optional = true }
Check lockorders in tests with a trivial lockorder tracker
2022-01-13 01:00:43 +00:00
backtrace = { version = "0.3", optional = true }
Put test utilities behind a feature flag. The utilities will still be part of cfg(test). The purpose of this is to enable other crates in the workspace to use the test utilities.
2020-09-16 17:27:13 -04:00
Drop `no-std` feature We drop the `lightning/no-std` feature and just take `hashbrown`,`possiblyrandom` and `libm` as required dependencies.
2024-09-13 13:14:40 +02:00
libm = { version = "0.2", default-features = false }
Expose functional tests under _externalize_tests feature flag Also, introduce TestSignerFactory, a factory for dynamic signers and ext-functional-test-demo crate for testing this machinery.
2024-10-01 14:58:36 +02:00
inventory = { version = "0.3", optional = true }
Actual no_std support
2021-08-01 18:22:06 +02:00
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
[dev-dependencies]
Update regex to 1.5.6
2022-06-01 17:25:15 +02:00
regex = "1.5.6"
Bump crate versions to 0.1.0/invoice 0.33.0/dns-resolver 0.2 Sadly, dns-resolver got uploaded as 0.1.0 without a -beta1 tag (and yanked), and thus we release it here as 0.2.0.
2025-01-15 18:12:48 +00:00
lightning-types = { version = "0.3.0", path = "../lightning-types", features = ["_test_utils"] }
Expose functional tests under _externalize_tests feature flag Also, introduce TestSignerFactory, a factory for dynamic signers and ext-functional-test-demo crate for testing this machinery.
2024-10-01 14:58:36 +02:00
lightning-macros = { path = "../lightning-macros" }
Add PersistenceNotifier to ChannelManager This will allow the ChannelManager to signal when it has new updates to persist, and adds a way for ChannelManager persisters to be notified when they should re-persist the ChannelManager to disk/backups. Feature-gate the wait_timeout function because the core lightning crate shouldn't depend on wallclock time unless users opt into it.
2020-11-19 12:53:16 -05:00
Make _test_utils depend on bitcoinconsensus feature
2021-04-28 16:23:39 -04:00
[dev-dependencies.bitcoin]
Upgrade rust-bitcoin to 0.32.2.
2024-08-16 08:02:50 -07:00
version = "0.32.2"
Actual no_std support
2021-08-01 18:22:06 +02:00
default-features = false
features = ["bitcoinconsensus", "secp-recovery"]
Introduce MuSig2-related types for Taproot channels.
2023-03-28 14:37:01 -07:00
Replace std's unmaintained bench with criterion Rather than using the std benchmark framework (which isn't maintained and is unlikely to get any further maintenance), we swap for criterion, which at least gets us a variable number of test runs so our benchmarks don't take forever. We also fix the RGS benchmark to pass now that the file in use is stale compared to today's date.
2023-05-11 06:03:57 +00:00
[target.'cfg(ldk_bench)'.dependencies]
criterion = { version = "0.4", optional = true, default-features = false }
Introduce MuSig2-related types for Taproot channels.
2023-03-28 14:37:01 -07:00
[target.'cfg(taproot)'.dependencies]
Upgrade rust-bitcoin to 0.32.2.
2024-08-16 08:02:50 -07:00
musig2 = { git = "https://github.com/arik-so/rust-musig2", rev = "6f95a05718cbb44d8fe3fa6021aea8117aa38d50" }
Use native check-cfg lint in cargo beta This uses the newly introduced conditional configuration checks that are now configurable withint Cargo (beta). This allows us to get rid of our custom python script that checks for expected features and cfgs. This does introduce a warning regarding the unknown lint in Cargo versions prior to the current beta, but since these are not rustc errors, they won't break any builds with the "-D warnings" RUSTFLAG. Moving to this lint actually exposed the "strict" feature not being present in the lightning-invoice crate, as our python script didnt correctly parse the cfg_attr where it appeared.
2024-07-12 11:23:50 +02:00
[lints]
workspace = true
Reference in a new issue Copy permalink