mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-02-24 23:08:36 +01:00
Code Issues Projects Releases Packages Wiki Activity
rust-lightning/lightning/Cargo.toml

68 lines
2.5 KiB
TOML
Raw Normal View History

Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
[package]
name = "lightning"
Update versions to 0.0.124 and invoice 0.32 types 0.1 release
2024-08-30 15:05:24 +00:00
version = "0.0.124"
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"]
Drop log-limiting features Previously, LDK offered two ways to limit log outputs: filtering during runtime client-side by matching on any given `Record`'s `Level` value, as well as at compile time through the `max_level_*` feature flags. It turns out the latter approach was always broken when used outside of the `lightning` crate. Here, we therefore simply drop the feature-based filtering.
2024-11-28 11:54:22 +01:00
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]
Update versions to 0.0.124 and invoice 0.32 types 0.1 release
2024-08-30 15:05:24 +00:00
lightning-types = { version = "0.1.0", path = "../lightning-types", default-features = false }
lightning-invoice = { version = "0.32.0", path = "../lightning-invoice", default-features = false }
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 }
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"
Update versions to 0.0.124 and invoice 0.32 types 0.1 release
2024-08-30 15:05:24 +00:00
lightning-types = { version = "0.1.0", path = "../lightning-types", features = ["_test_utils"] }
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