rust-lightning/.gitignore

/target/
c-bindings-gen/target/
lightning-c-bindings/target/
lightning-c-bindings/a.out
/hfuzz_target/
/net-tokio/target/
**/*.rs.bk
Cargo.lock
.idea
lightning/target
lightning/ldk-net_graph-*.bin
lightning-custom-message/target
no-std-check/target
initial checkin 2017-12-25 01:05:27 -05:00			`/target/`
Add a few more things to gitignore for bindings 2020-09-13 13:02:35 -04:00			`c-bindings-gen/target/`
			`lightning-c-bindings/target/`
			`lightning-c-bindings/a.out`
Provide remote channel public keys to signer 2020-01-16 16:51:15 -08:00			`/hfuzz_target/`
Add net-tokio/target to gitignore 2019-07-31 03:14:18 +00:00			`/net-tokio/target/`
initial checkin 2017-12-25 01:05:27 -05:00			`*/.rs.bk`
			`Cargo.lock`
Add net-tokio/target to gitignore 2019-07-31 03:14:18 +00: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 20:36:51 +05:30			`lightning/target`
Add config support for 'their_channel_reserve_proportional_millionths' [#1498] It is proportion of the channel value to configure as the `their_channel_reserve_satoshis` for both outbound and inbound channels. It decides the minimum balance that the other node has to maintain on their side, at all times. 2022-07-18 16:58:10 -07:00			`lightning/ldk-net_graph-*.bin`
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 11:24:30 -06:00			`lightning-custom-message/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-03 23:59:44 -08:00			`no-std-check/target`