Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NUT-XX: Multinut payments #103

Merged
merged 15 commits into from
May 22, 2024
2 changes: 1 addition & 1 deletion 08.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
NUT-08: Lightning fee return
==========================

`optional`
`optional`, `depends on: NUT-05`

---

Expand Down
2 changes: 1 addition & 1 deletion 11.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
NUT-11: Pay to Public Key (P2PK)
==========================

`optional`
`optional`, `depends on: NUT-10`

---

Expand Down
61 changes: 61 additions & 0 deletions 14.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
NUT-14: Partial multi-path payments
==========================

`optional` `depends on: NUT-05`

---

In this document, we describe how wallets can instruct multiple mints to each pay a partial amount of a bolt11 Lightning invoice. The full payment is composed of partial payments (MPP) from multiple multi-path payments from different Lightning nodes. This way, wallets can pay a larger Lightning invoice combined from multiple smaller balances on different mints. Due to the atomic nature of MPP, either all payments wil be successful or all of them will fail.

The Lightning backend of the mint must support paying a partial amount of an Invoice and multi-path payments (MPP, see [BOLT 4](https://github.com/lightning/bolts/blob/master/04-onion-routing.md)). For example, the mint's Lightning node must be able to pay 50 sats of a 100 sat bolt11 invoice. The receiving Lightning node must support receiving multi-path payments as well.

# Multimint payment execution

`Alice`'s wallet coordinates multiple MPPs on different mints that support the feature (see below for the indicated settings). For a given Lightning invoice of `amount_total`, `Alice` splits the total amount into several partial amounts `amount_total = amount_1 + amount_2 + ...` that each must be covered by her individual balances on the mints she wants to use for the payment. Then she constructs multiple `PostMeltQuoteBolt11Request`'s that each include the corresponding partial amount (see below) that she sends to all mints she wants to use for the payment. The mints then respond with a normal `PostMeltQuoteBolt11Response` (see [NUT-05][05]). `Alice` proceeds to pay the melt requests at each mint simultaneously. When all mints have sent out the Lightning payment, she receives a successful response from all mints individually.

# Melt quote

To request a melt quote with a partial `amount`, the wallet of `Alice` makes a `POST /v1/melt/quote/{method}` request where `method` is the payment method requested (here `bolt11`).

```http
POST https://mint.host:3338/v1/melt/quote/bolt11
```

The wallet `Alice` includes the following `PostMeltQuoteBolt11Request` data in its request which includes an additional `amount` field compared to the standard request in [NUT-05][05]:

```json
{
"request": <str>,
"unit": <str_enum["sat"]>,
"amount": <int> # <-- new
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the overall idea of extending NUT-05 by adding a single field, instead of copying all the endpoints from NUT-05 and creating a new payment-method.
To make this backwards compatible the amount should be optional

<str|null>

otherwise this would break the api, because the PostMeltQuoteBolt11Request will be used for both endpoints NUT-05 (without mpp field) and NUT-14 (with mpp field).

}
```

Here, `request` is the bolt11 Lightning invoice to be paid, `unit` is the unit the wallet would like to pay with, and `amount` is the amount for the requested payment. The wallet then pays the returned melt quote the same way as in [NUT-05][05].

## Settings

The settings indicating that a mint supports this feature are in the `MeltMethodSetting` (see [NUT-05][05]) which is returned in the info endpoint ([NUT-06][06]). The mint MUST indicate `method` and `unit` pairs that support `mpp`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the mpp field be added to the settings from NUT-05 or would it be better to create new settings for NUT-14? Having explicit settings for NUT-14 would better fit in the overall picture, but would also add some redundancy. Would a mint always return the same min_max amounts, units etc. for both cases mpp=true and mpp=false or could there be differences?
If the mpp field will be part of the NUT-05 settings it has to be optional, otherwise it would break the api.


`MeltMethodSetting` is of the form:
```json
{
...,
"mpp": <bool>
}
```

Example `MeltMethodSetting`:

```json
{
"method": "bolt11",
"unit": "sat",
"min_amount": 100,
"max_amount": 10000,
"mpp": true
}
```

[05]: 05.md
[06]: 06.md