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.

Sign up for GitHub

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

Jump to bottom

bLIP-0030: zero-reserve channels #30

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

bLIP-0030: zero-reserve channels #30

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2b41937
bLIP-0030: zero-reserve channels
t-bast Oct 24, 2023
95f7ad1
Use empty TLV flag
t-bast Oct 25, 2023
a912d64
Prevent empty commitment transactions
t-bast Nov 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,3 +25,4 @@ For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
| [10](./blip-0010.md) | Podcasting 2.0 | Satoshis Stream | Active |
| [11](./blip-0011.md) | NameDesc | Hampus Sjöberg | Active |
| [17](./blip-0017.md) | Hosted Channels | Anton Kumaigorodskiy | Active |
| [xx](./blip-0030.md) | Zero-reserve channels | Bastien Teinturier | Active |
21 changes: 19 additions & 2 deletions blip-0002.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,8 +32,9 @@ network split.
* [Messages](#messages)
* [TLV fields in BOLT messages](#tlv-fields-in-bolt-messages)
* [`init`](#init)
* [`open_channel2`](#open_channel2)
* [`accept_channel2`](#accept_channel2)
* [`ping`](#ping)
* [`update_add_htlc`](#update_add_htlc)

### Feature bits

Expand All @@ -48,6 +49,7 @@ bLIPs may reserve feature bits by adding them to the following table:
| --------- | ---------------------- | ------------------------------------------------- | ---------------- | -------------------------------- | -------------------------------- |
| 54/55 | `keysend` | A form of spontaneous payment | N | `var_onion_optin` | [bLIP 3](./blip-0003.md) |
| 256/257 | `hosted_channels` | This node accepts requests for hosted channels | IN | | [bLIP 17](./blip-0017.md) |
| 258/259 | `zero_reserve` | This node may accept zero-reserve channels | IN | | [bLIP 30](./blip-0030.md) |

### Messages

Expand Down Expand Up @@ -92,6 +94,22 @@ The following table contains extension tlv fields for the `init` message:
|-------|-----------------------------|--------------------------------|
| 65536 | `tlv_field_name` | Link to the corresponding bLIP |

#### `open_channel2`

The following table contains extension tlv fields for the `open_channel2` message:

| Type | Name | Link |
|-------|-----------------------------|---------------------------|
| 32768 | `zero_reserve` | [bLIP 30](./blip-0030.md) |

#### `accept_channel2`

The following table contains extension tlv fields for the `accept_channel2` message:

| Type | Name | Link |
|-------|-----------------------------|---------------------------|
| 32768 | `zero_reserve` | [bLIP 30](./blip-0030.md) |

#### `payment_onion_payload`

The following table contains extension tlv fields for the `payment_onion_payload` message:
Expand All @@ -101,7 +119,6 @@ The following table contains extension tlv fields for the `payment_onion_payload
| 7629169 | `podcasting_2_0` | [bLIP 10](./blip-0010.md) |
| 5482373484 | `keysend_preimage` | [bLIP 3](./blip-0003.md) |


#### `ping`

The following table contains extension tlv fields for the `ping` message:
Expand Down
157 changes: 157 additions & 0 deletions blip-0030.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,157 @@
```
bLIP: 30
Title: Zero-reserve channels
Status: Active
Author: Bastien Teinturier <[email protected]>
Created: 2023-10-24
License: CC0
```

## Abstract

Standard lightning channels require nodes to lock some of their channel funds
into a channel reserve, which cannot be used for payments made on that channel.
This guarantees that both nodes always have an output in the commitment
transaction, which they will lose if they publish a revoked commitment.

While this requirement is generally useful, it creates some inefficiencies
since that liquidity can't be used to relay payments, and provides a bad user
experience. In some settings, we may want to remove that channel reserve and
allow nodes to use all of their channel funds.

## Copyright

This bLIP is licensed under the CC0 license.

## Specification

### TLV extensions

Additional TLV fields for the `open_channel2` message:

1. `tlv_stream`: `open_channel2_tlvs`
2. types:
1. type: 32768 (`zero_reserve`)

Additional TLV fields for the `accept_channel2` message:

1. `tlv_stream`: `accept_channel2_tlvs`
2. types:
1. type: 32768 (`zero_reserve`)

### Requirements

A node that wants to support zero-reserve channels:

* MUST set the `zero_reserve` feature bit

When sending `open_channel`:

* If the `zero_reserve` feature was negotiated:
* MAY set `channel_reserve_satoshis` to `0`

When receiving `open_channel`:

* If `channel_reserve_satoshis` is set to `0`:
* If it wants to use `zero_reserve`:
* MUST set `channel_reserve_satoshis` to `0` in `accept_channel`
* Otherwise:
* MUST send an `error` and forget the channel

When receiving `accept_channel`:

* If `channel_reserve_satoshis` was set to `0` in `open_channel`, and it is
not set to `0` in `accept_channel`:
* MUST send an `error` and forget the channel

When sending `open_channel2`:

* If the `zero_reserve` feature was negotiated:
* MAY set the `zero_reserve` TLV field

When receiving `open_channel2`:

* If the `zero_reserve` TLV field is set:
* If it wants to use `zero_reserve`:
* MUST set the `zero_reserve` TLV field in `accept_channel2`
* Otherwise:
* MUST send an `error` and forget the channel

t-bast marked this conversation as resolved.
Show resolved Hide resolved
When receiving `accept_channel2`:

* If `zero_reserve` was set in `open_channel2`, and it is not set in
`accept_channel2`:
* MUST send an `error` and forget the channel

When sending `update_add_htlc`:

* If `zero_reserve` has been negotiated:
* MUST ignore any channel reserve standard requirement
* If the resulting commitment transaction would have no outputs:
* MUST NOT send `update_add_htlc`

When receiving `update_add_htlc`:

* If `zero_reserve` has been negotiated:
* MUST ignore any channel reserve standard requirement
* If the resulting commitment transaction would have no outputs:
* MUST send an `error` and fail the channel

If the channel is not public, both nodes:

* When the funding transaction confirms:
* MUST send a `channel_update` using the final `short_channel_id`
Comment on lines +102 to +103
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note this requirement, which is necessary when using scid_alias. Without that, the channel updates would only be signed with a local alias, which doesn't allow tying the channel_update to a specific on-chain outpoint.

This feels hacky though: we could instead introduce a dedicated proof for the zero-reserve case. This could be as simple as a TLV in channel_ready that contains a signature of the funding output's script using the private key associated with the node_id.


### Rationale

The use of zero-reserve is symmetrical: it is either offered to both nodes or
unused.
Comment on lines +107 to +108
Copy link

Choose a reason for hiding this comment

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

What is the rationale to make the zero-reserve specification symmetrical? Is that because it's already possible to do one-sided zero reserve?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why wouldn't we make it symmetrical? In order to get the full benefits for a mobile wallet user, you have to allow the LSP side to also be 0-reserve, otherwise you don't benefit from the maximum amount of inbound liquidity.

Copy link

Choose a reason for hiding this comment

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

@t-bast You don't get the full benefit of inbound liquidity, but you do make sure the LSP has something to lose if it tries to cheat. There's value to that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think it actually adds value in practice. In an LSP-wallet relationship, the LSP has enough incentives not to publish a revoked commitment. I detailed those in this thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004136.html

That was the reasoning behind this symmetrical 0-reserve proposal. That doesn't mean you have to use it! If you prefer an asymmetrical proposal, there's always room for another bLIP for that.


In theory, the channel could be in a state where the commitment transaction has
no outputs, if all of the channel liquidity is allocated to pending dust HTLCs.
This state wouldn't make sense: all of the channel value would be burned to
miner fees. We make sure we never get into this state. In practice though, this
should never happen since nodes set `max_dust_htlc_exposure_msat` to ensure
that dust HTLCs don't grow unbounded and set `max_htlc_value_in_flight_msat` to
restrict their exposure to pending HTLCs.

### Fraud proofs

If one of the nodes publishes a revoked commitment, the other node can create
a fraud proof that shows which node tried to cheat. This proof may be shared
publicly to harm the cheating node's reputation.

That proof contains:

1. the revoked commitment transaction
2. a proof of knowledge of the revocation secret
3. a proof of knowledge of the private key associated to the main output of the
honest participant
4. if the channel is public, its `channel_announcement`
5. if the channel is not public, a `channel_update` from the malicious peer
that uses the final `short_channel_id`

The second and third items prove the identity of the honest user in that
channel, while the last two items tie the identity of the malicious user to
its public `node_id`.

## Motivation

In some cases, there may be some trust between nodes that the other node won't
try to publish a revoked commitment: when that is the case, it is wasteful to
enforce a channel reserve.

In other cases, different incentives may be sufficient to remove the need for
channel reserves.

A mobile wallet using a service provider is a good candidate for removing the
reserve requirements. The wallet user is regularly paying fees to the service
provider: this incentivizes the service provider to offer zero-reserve, which
provides a better user experience. The service provider isn't taking any risk
here, as they should always be online and able to punish revoked transactions.
It also makes sense for the wallet user to offer zero-reserve to the service
provider: even on a mobile wallet, users should be able to react to revoked
transactions. If the service provider publishes a revoked transaction, the
wallet user can additionnally create a public proof that the service provider
tried to cheat: this harms the service provider's reputation, which is another
incentive for them to avoid cheating.