BOLT 12 refund encoding and building #1908
Conversation
|
@valentinewallace @TheBlueMatt Looking for Concept ACK on the last three commits before I get too far into testing. Given the different semantics between refunds and |
This causes a compilation error if a new field is added but missed in the tests.
jkczyz
force-pushed
the
2022-11-refund
branch
from
e5f4c0b to
1990ae2
Compare
|
Ended up writing the tests as I don't expect the interface to change much even if the underlying representation does. |
Codecov ReportBase: 92.18% // Head: 92.15% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1908 +/- ##
==========================================
- Coverage 92.18% 92.15% -0.03%
==========================================
Files 94 95 +1
Lines 61379 62014 +635
Branches 61379 62014 +635
==========================================
+ Hits 56580 57148 +568
- Misses 4799 4866 +67
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
jkczyz
force-pushed
the
2022-11-refund
branch
from
1990ae2 to
4d7e296
Compare
|
So the question is basically if its okay to not reuse the |
Yeah, essentially. Could also convert it to Additionally, spontaneous invoices represent a third type of invoice, which is an |
That SGTM.
Well, we'd also be able to see that from the enum variant, no? |
Yup, would just be an alternative way of differentiating if not going with an enum. |
Refunds (i.e., `invoice_request` without an `offer`) will have its own contents type, so OfferContents::signing_pubkey can be required.
jkczyz
force-pushed
the
2022-11-refund
branch
from
4d7e296 to
9b92a09
Compare
Define an interface for BOLT 12 refunds (i.e., an `invoice_request` message without an `offer_node_id`). A refund is more generally an "offer for money". While it is encoded using the same TLV streams as an `invoice_request` message, it has different semantics.
Implement Bech32Encode for Refund, which supports creating and parsing QR codes for the merchant-pays-user (i.e., offer for money) flow.
Add a builder for creating refunds given a payer_id and other required fields. Other settings are optional and duplicative settings will override previous settings. Building produces a semantically valid `invoice_request` message representing the refund, which then may be communicated out of band (e.g., via QR code).
Tests for checking invoice_request message semantics when building a refund as defined by BOLT 12.
Tests for checking refund semantics when parsing invoice_request bytes as defined by BOLT 12.
jkczyz
force-pushed
the
2022-11-refund
branch
from
9b92a09 to
8e36737
Compare
0.0.114 - Mar 3, 2023 - "Faster Async BOLT12 Retries" API Updates =========== * `InvoicePayer` has been removed and its features moved directly into `ChannelManager`. As such it now requires a simplified `Router` and supports `send_payment_with_retry` (and friends). `ChannelManager::retry_payment` was removed in favor of the automated retries. Invoice payment utilities in `lightning-invoice` now call the new code (lightningdevkit#1812, lightningdevkit#1916, lightningdevkit#1929, lightningdevkit#2007, etc). * `Sign`/`BaseSign` has been renamed `ChannelSigner`, with `EcdsaChannelSigner` split out in anticipation of future schnorr/taproot support (lightningdevkit#1967). * The catch-all `KeysInterface` was split into `EntropySource`, `NodeSigner`, and `SignerProvider`. `KeysManager` implements all three (lightningdevkit#1910, lightningdevkit#1930). * `KeysInterface::get_node_secret` is now `KeysManager::get_node_secret_key` and is no longer required for external signers (lightningdevkit#1951, lightningdevkit#2070). * A `lightning-transaction-sync` crate has been added which implements keeping LDK in sync with the chain via an esplora server (lightningdevkit#1870). Note that it can only be used on nodes that *never* ran a previous version of LDK. * `Score` is updated in `BackgroundProcessor` instead of via `Router` (lightningdevkit#1996). * `ChainAccess::get_utxo` (now `UtxoAccess`) can now be resolved async (lightningdevkit#1980). * BOLT12 `Offer`, `InvoiceRequest`, `Invoice` and `Refund` structs as well as associated builders have been added. Such invoices cannot yet be paid due to missing support for blinded path payments (lightningdevkit#1927, lightningdevkit#1908, lightningdevkit#1926). * A `lightning-custom-message` crate has been added to make combining multiple custom messages into one enum/handler easier (lightningdevkit#1832). * `Event::PaymentPathFailure` is now generated for failure to send an HTLC over the first hop on our local channel (lightningdevkit#2014, lightningdevkit#2043). * `lightning-net-tokio` no longer requires an `Arc` on `PeerManager` (lightningdevkit#1968). * `ChannelManager::list_recent_payments` was added (lightningdevkit#1873). * `lightning-background-processor` `std` is now optional in async mode (lightningdevkit#1962). * `create_phantom_invoice` can now be used in `no-std` (lightningdevkit#1985). * The required final CLTV delta on inbound payments is now configurable (lightningdevkit#1878) * bitcoind RPC error code and message are now surfaced in `block-sync` (lightningdevkit#2057). * Get `historical_estimated_channel_liquidity_probabilities` was added (lightningdevkit#1961). * `ChannelManager::fail_htlc_backwards_with_reason` was added (lightningdevkit#1948). * Macros which implement serialization using TLVs or straight writing of struct fields are now public (lightningdevkit#1823, lightningdevkit#1976, lightningdevkit#1977). Backwards Compatibility ======================= * Any inbound payments with a custom final CLTV delta will be rejected by LDK if you downgrade prior to receipt (lightningdevkit#1878). * `Event::PaymentPathFailed::network_update` will always be `None` if an 0.0.114-generated event is read by a prior version of LDK (lightningdevkit#2043). * `Event::PaymentPathFailed::all_paths_removed` will always be false if an 0.0.114-generated event is read by a prior version of LDK. Users who rely on it to determine payment retries should migrate to `Event::PaymentFailed`, in a separate release prior to upgrading to LDK 0.0.114 if downgrading is supported (lightningdevkit#2043). Performance Improvements ======================== * Channel data is now stored per-peer and channel updates across multiple peers can be operated on simultaneously (lightningdevkit#1507). * Routefinding is roughly 1.5x faster (lightningdevkit#1799). * Deserializing a `NetworkGraph` is roughly 6x faster (lightningdevkit#2016). * Memory usage for a `NetworkGraph` has been reduced substantially (lightningdevkit#2040). * `KeysInterface::get_secure_random_bytes` is roughly 200x faster (lightningdevkit#1974). Bug Fixes ========= * Fixed a bug where a delay in processing a `PaymentSent` event longer than the time taken to persist a `ChannelMonitor` update, when occurring immediately prior to a crash, may result in the `PaymentSent` event being lost (lightningdevkit#2048). * Fixed spurious rejections of rapid gossip sync data when the graph has been updated by other means between gossip syncs (lightningdevkit#2046). * Fixed a panic in `KeysManager` when the high bit of `starting_time_nanos` is set (lightningdevkit#1935). * Resolved an issue where the `ChannelManager::get_persistable_update_future` future would fail to wake until a second notification occurs (lightningdevkit#2064). * Resolved a memory leak when using `ChannelManager::send_probe` (lightningdevkit#2037). * Fixed a deadlock on some platforms at least when using async `ChannelMonitor` updating (lightningdevkit#2006). * Removed debug-only assertions which were reachable in threaded code (lightningdevkit#1964). * In some cases when payment sending fails on our local channel retries no longer take the same path and thus never succeed (lightningdevkit#2014). * Retries for spontaneous payments have been fixed (lightningdevkit#2002). * Return an `Err` if `lightning-persister` fails to read the directory listing rather than panicing (lightningdevkit#1943). * `peer_disconnected` will now never be called without `peer_connected` (lightningdevkit#2035) Security ======== 0.0.114 fixes several denial-of-service vulnerabilities which are reachable from untrusted input from channel counterparties or in deployments accepting inbound connections or channels. It also fixes a denial-of-service vulnerability in rare cases in the route finding logic. * The number of pending un-funded channels as well as peers without funded channels is now limited to avoid denial of service (lightningdevkit#1988). * A second `channel_ready` message received immediately after the first could lead to a spurious panic (lightningdevkit#2071). This issue was introduced with 0conf support in LDK 0.0.107. * A division-by-zero issue was fixed in the `ProbabilisticScorer` if the amount being sent (including previous-hop fees) is equal to a channel's capacity while walking the graph (lightningdevkit#2072). The division-by-zero was introduced with historical data tracking in LDK 0.0.112. In total, this release features 130 files changed, 21457 insertions, 10113 deletions in 343 commits from 18 authors, in alphabetical order: * Alec Chen * Allan Douglas R. de Oliveira * Andrei * Arik Sosman * Daniel Granhão * Duncan Dean * Elias Rohrer * Jeffrey Czyz * John Cantrell * Kurtsley * Matt Corallo * Max Fang * Omer Yacine * Valentine Wallace * Viktor Tigerström * Wilmer Paulino * benthecarman * jurvis
Define an interface for BOLT 12 refunds (i.e., "offer for money" or merchant-pays-user flow), which are a special type of
invoice_requestcommunicated out-of-band (e.g., via QR code). As with other messages, the underlying format consists of the original bytes and the parsed contents.The bytes are later needed when constructing an
invoicemessage. This is because it must mirror all theofferandinvoice_requestTLV records, including unknown ones, which aren't represented in the contents. The contents will be used ininvoicemessages to avoid duplication.Also, defines a builder for constructing a refund given a required payer id and other fields.