mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-01-18 13:24:36 +01:00
Code Issues Packages Projects Releases Wiki Activity
239d10ab2e
rust-lightning/.gitignore

18 lines
391 B
Plaintext
Raw Normal View History

initial checkin
2017-12-25 07:05:27 +01:00
/target/
Add a few more things to gitignore for bindings
2020-09-13 19:02:35 +02:00
c-bindings-gen/target/
lightning-c-bindings/target/
lightning-c-bindings/a.out
Provide remote channel public keys to signer
2020-01-17 01:51:15 +01:00
/hfuzz_target/
Add net-tokio/target to gitignore
2019-07-31 05:14:18 +02:00
/net-tokio/target/
initial checkin
2017-12-25 07:05:27 +01:00
**/*.rs.bk
Cargo.lock
Add net-tokio/target to gitignore
2019-07-31 05:14:18 +02:00
.idea
Multi-Hop Route Hint as per Bolt 12 now considered Bolt 12 details the process of picking up route hints from payee using the lightning invoice. This PR brings the changes to use multiple route hints from payee picked from the invoice. The route hints are processed in the following manner:- - `get_route()` receives the hints in `last_hops`. - Every `RouteHintHop` in `RouteHint` is processed based on feasiblity of channel capacity and fees. - If a `RouteHintHop` then preceeding `RouteHintHop`s are not processed. - A direct route is checked from `first_hops_targets` to the first `RouteHintHop` if the respective `RouteHint` is processed from the payee's end till the first `RouteHintHop`. `partial_route_hint_test`, `ignores_empty_last_hops_test`, `multi_hint_last_hops_test` and `last_hops_with_public_channel_test` test usage of partial route hints for building optimal route, processing empty route hint hops, complete usage of private route hints and presence of public channels in route hints respectively. Resolves: #945
2021-08-09 17:06:51 +02:00
lightning/target
Update .gitignore to ignore benchmark data files
2023-05-02 19:13:02 +02:00
lightning/net_graph-*.bin
lightning-rapid-gossip-sync/res/full_graph.lngossip
Macro for composing custom message handlers BOLT 1 specifies a custom message type range for use with experimental or application-specific messages. While a `CustomMessageHandler` can be defined to support more than one message type, defining such a handler requires a significant amount of boilerplate and can be error prone. Add a crate exporting a `composite_custom_message_handler` macro for easily composing pre-defined custom message handlers. The resulting handler can be further composed with other custom message handlers using the same macro. This requires a separate crate since the macro needs to support "or" patterns in macro_rules, which is only available in edition 2021. https://doc.rust-lang.org/edition-guide/rust-2021/or-patterns-macro-rules.html Otherwise, a crate defining a handler for a set of custom messages could not easily be reused with another custom message handler. Doing so would require explicitly duplicating the reused handlers type ids, but those may change when the crate is updated.
2023-01-03 18:24:30 +01:00
lightning-custom-message/target
Ignore lightning-transaction-sync build output
2023-04-27 23:29:04 +02:00
lightning-transaction-sync/target
Add a `lightning-dns-resolver` crate which answers bLIP 32 queries When a lightning node wishes to send payments to a BIP 353 human readable name (using BOLT 12), it first has to resolve that name to a DNS TXT record. bLIP 32 defines a way to do so over onion messages, and this completes our implementation thereof by adding the server side. It operates by simply accepting new messages and spawning tokio tasks to do DNS lookups using the `dnsse_prover` crate. It also contains full end-to-end tests of the BIP 353 -> BOLT 12 -> payment logic using the new server code to do the resolution. Note that because we now have a workspace crate which sets the "lightning/dnssec" feature in its `dev-dependencies`, a naive `cargo test` will test the "dnssec" feature.
2024-07-14 15:08:04 +02:00
lightning-dns-resolver/target
Check for no-std compatibility across dependencies To ensure no-std is honored across dependencies, add a crate depending on lightning crates supporting no-std. This should ensure any regressions are caught. Otherwise, cargo doesn't seem to catch some incompatibilities (e.g., f64::log10 unavailable in core) and seemingly across other dependencies as describe here: https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
2022-03-04 08:59:44 +01:00
no-std-check/target
Remove `Outpoint::to_channel_id` method To avoid confusion and for accuracy going forward, we remove this method as it is inconsistent with channel IDs generated during V2 channel establishment. If one wants to create a V1, funding outpoint-based channel ID, then `ChannelId::v1_from_funding_outpoint` should be used instead. A large portion of the library has always made the assumption that having the funding outpoint will always allow us to generate the channel ID. This will not be the case anymore and we need to pass the channel ID along where appropriate. All channels that could have been persisted up to this point could only have used V1 establishment, so if some structures don't store a channel ID for them they can safely fall back to the funding outpoint-based version.
2024-01-09 08:07:01 +01:00
msrv-no-dev-deps-check/target
Reference in New Issue Copy Permalink