Matt Corallo

Cleanup `PackageTemplate`a bit

1

Digging into better aggregation turned up a bunch of nonsense in `PackageTemplate` that is gonna lead to us breaking things in the future, so since I actually understand how the...

Support paying directly to Human Readable Names using bLIP 32

2

Based on #3179 this fully implements BIP 353 sends using bLIP 32 DNS resolution with a wonderfully simple API: ``` pub fn pay_for_offer_from_human_readable_name( &self, name: HumanReadableName, amount_msats: u64, payment_id: PaymentId,...

Add support for parsing the dns_resolver feature bit

1

This feature bit is used to indicate that a node will make DNS queries on behalf of onion message senders, returning DNSSEC TXT proofs for the requested names. It is...

BOLT 12 Proof of Payment

1

We currently don't support proof of payment for sent BOLT 12 payments because the user needs the `Bolt12Invoice` in the `PaymentSent` `Event`. This will require a bit of involvement, we'll...

Stop relying on ChannelMonitor persistence after manager read

4

When we discover we've only partially claimed an MPP HTLC during `ChannelManager` reading, we need to add the payment preimage to all other `ChannelMonitor`s that were a part of the...

Stop Sending ChannelUpdates in onion failures

1

These are optional now, and while other nodes might use them, they shouldn't do so for long (though lnd has said they'll keep using them, but only for fast-retires when...

Should `ChannelMonitor` keys be converted to `ChannelId`s (and what to do with spliced `ChannelMonitor`s)

1

`ChannelMonitor`s are currently indexed by funding `OutPoint`s, which is fine, except with splicing we're gonna have channels that change funding but don't change `ChannelId`. This made sense, I thought, because...

https://github.com/lightningdevkit/rust-lightning/pull/3313#discussion_r1763355396 cc @valentinewallace in case you want to take this up

https://github.com/lightningdevkit/rust-lightning/pull/3106#issuecomment-2338322456