Elias Rohrer
Elias Rohrer
During syncing, `lightning-block-sync` populates as a block header `Cache` that is crucial to be able to disconnected previously-connected headers cleanly in case of a reorg. Moreover, the `Cache` can have...
In #3623 we discovered that `test_trampoline_single_hop_receive` is flaky, likely depending on a particular `EntropySource` output. If we call `entropy_source.get_secure_random_bytes()` in `ChainMonitor`'s block connection code, `test_trampoline_single_hop_receive` fails with: ``` node 0...
In https://github.com/lightningdevkit/rust-lightning/pull/2708 we broke compatibility with serialization prior to 0.0.113. We should explore what parts of our serialization can be simplified now that we don't need to provide backwards compat...
Currently, it seems we would update the max liquidity bound even if forwarding would fail due to, e.g., `fee_insufficient(0x100d)`: ``` 2023-10-19 12:08:04 INFO (LDK): Got route: path 0: node_id: 0296b2db342fcf87ea94d981757fdf4d3e545bd5cef4919f58b5d38dfdd73bf5c9,...
Currently, the `LSPS2ServiceHandler::htlc_handling_failed` only only handles `HTLCDestination::NextHopChannel`, but it should likely at the very least also handle `HTLCDestination::UnknownNextHop` and `HTLCDestination::InvalidForward` variants, i.e., all for which we at least know the...
After previous discussions on #1044, the last spec meeting, and [Delving](https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723), it seems there was agreement from multiple sides that receiver-side delays were preferable to forwarding delays. Here, we propose...
Currently, bLIP-51 states: ``` In case the channel open failed - MUST set order_state to FAILED. - MUST issue a refund. ``` It is however not clear what constitutes a...
This is another preparatory step for receiver-side delays that we split out to err on the side of smaller, more reviewable PRs, especially since these changes are a nice cleanup...
In `lightning-liqudity` we historically at some point went with reusing LDK's `APIError` type, which was a weird choice even back then. However, we since added a bunch of additional error...
We simply add support for `bitcoin::Network::Testnet4`, which was added with release v0.32.4, which we hence deem the new minimal requirement for `lightning` and `lightning-invoice`.