Skip to content

Commit 4c59a11

Browse files
t-bastt-bast
committed
bLIP-0029: zero-reserve channels
Nodes can opt-in to remove the channel reserve requirements, which makes better use of their channel liquidity.
1 parent b273c85 commit 4c59a11

File tree

3 files changed

+152
-2
lines changed

3 files changed

+152
-2
lines changed

‎README.md

+1
Original file line numberDiff line numberDiff line change
@@ -25,3 +25,4 @@ For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
2525
| [10](./blip-0010.md) | Podcasting 2.0 | Satoshis Stream | Active |
2626
| [11](./blip-0011.md) | NameDesc | Hampus Sjöberg | Active |
2727
| [17](./blip-0017.md) | Hosted Channels | Anton Kumaigorodskiy | Active |
28+
| [xx](./blip-00xx.md) | Zero-reserve channels | Bastien Teinturier | Active |

‎blip-0002.md

+19-2
Original file line numberDiff line numberDiff line change
@@ -32,8 +32,9 @@ network split.
3232
* [Messages](#messages)
3333
* [TLV fields in BOLT messages](#tlv-fields-in-bolt-messages)
3434
* [`init`](#init)
35+
* [`open_channel2`](#open_channel2)
36+
* [`accept_channel2`](#accept_channel2)
3537
* [`ping`](#ping)
36-
* [`update_add_htlc`](#update_add_htlc)
3738

3839
### Feature bits
3940

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

5254
### Messages
5355

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

97+
#### `open_channel2`
98+
99+
The following table contains extension tlv fields for the `open_channel2` message:
100+
101+
| Type | Name | Link |
102+
|-------|-----------------------------|---------------------------|
103+
| 32768 | `zero_reserve` | [bLIP xx](./blip-00xx.md) |
104+
105+
#### `accept_channel2`
106+
107+
The following table contains extension tlv fields for the `accept_channel2` message:
108+
109+
| Type | Name | Link |
110+
|-------|-----------------------------|---------------------------|
111+
| 32768 | `zero_reserve` | [bLIP xx](./blip-00xx.md) |
112+
95113
#### `payment_onion_payload`
96114

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

104-
105122
#### `ping`
106123

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

‎blip-00xx.md

+132
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
```
2+
bLIP: xx
3+
Title: Zero-reserve channels
4+
Status: Active
5+
Author: Bastien Teinturier <[email protected]>
6+
Created: 2023-10-24
7+
License: CC0
8+
```
9+
10+
## Abstract
11+
12+
Standard lightning channels require nodes to lock some of their channel funds
13+
into a channel reserve, which cannot be used for payments made on that channel.
14+
This guarantees that both nodes always have an output in the commitment
15+
transaction, which they will lose if they publish a revoked commitment.
16+
17+
While this requirement is generally useful, it creates some inefficiencies
18+
since that liquidity can't be used to relay payments, and provides a bad user
19+
experience. In some settings, we may want to remove that channel reserve and
20+
allow nodes to use all of their channel funds.
21+
22+
## Copyright
23+
24+
This bLIP is licensed under the CC0 license.
25+
26+
## Specification
27+
28+
### TLV extensions
29+
30+
Additional TLV fields for the `open_channel2` message:
31+
32+
1. `tlv_stream`: `open_channel2_tlvs`
33+
2. types:
34+
1. type: 32768 (`zero_reserve`)
35+
2. data:
36+
* [`byte`:`use_zero_reserve`]
37+
38+
Additional TLV fields for the `accept_channel2` message:
39+
40+
1. `tlv_stream`: `accept_channel2_tlvs`
41+
2. types:
42+
1. type: 32768 (`zero_reserve`)
43+
2. data:
44+
* [`byte`:`use_zero_reserve`]
45+
46+
### Requirements
47+
48+
A node that wants to support zero-reserve channels:
49+
50+
* MUST set the `zero_reserve` feature bit
51+
52+
When sending `open_channel`:
53+
54+
* If `zero_reserve` was negotiated:
55+
* MAY set `channel_reserve_satoshis` to `0`
56+
57+
When receiving `open_channel`:
58+
59+
* If `channel_reserve_satoshis` is set to `0`:
60+
* If it wants to use `zero_reserve`:
61+
* MUST set `channel_reserve_satoshis` to `0` in `accept_channel`
62+
* Otherwise:
63+
* MUST send an `error` and forget the channel
64+
65+
When sending `open_channel2`:
66+
67+
* If `zero_reserve` was negotiated:
68+
* MAY set the `zero_reserve` TLV field to `1`
69+
70+
When receiving `open_channel2`:
71+
72+
* If `zero_reserve` is set to `1`:
73+
* If it wants to use `zero_reserve`:
74+
* MUST set the `zero_reserve` TLV field to `1` in `accept_channel2`
75+
* Otherwise:
76+
* MUST send an `error` and forget the channel
77+
78+
When sending or receiving `update_add_htlc`:
79+
80+
* If `zero_reserve` has been negotiated:
81+
* MUST ignore any channel reserve standard requirement
82+
83+
If the channel is not public, both nodes:
84+
85+
* When the funding transaction confirms:
86+
* MUST send a `channel_update` using the final `short_channel_id`
87+
88+
### Rationale
89+
90+
The use of zero-reserve is symmetrical: it is either offered to both nodes or
91+
unused.
92+
93+
### Fraud proofs
94+
95+
If one of the nodes publishes a revoked commitment, the other node can create
96+
a fraud proof that shows which node tried to cheat. This proof may be shared
97+
publicly to harm the cheating node's reputation.
98+
99+
That proof contains:
100+
101+
1. the revoked commitment transaction
102+
2. a proof of knowledge of the revocation secret
103+
3. a proof of knowledge of the private key associated to the main output of the
104+
honest participant
105+
4. if the channel is public, its `channel_announcement`
106+
5. if the channel is not public, a `channel_update` from the malicious peer
107+
that uses the final `short_channel_id`
108+
109+
The second and third items prove the identity of the honest user in that
110+
channel, while the last two items tie the identity of the malicious user to
111+
its public `node_id`.
112+
113+
## Motivation
114+
115+
In some cases, there may be some trust between nodes that the other node won't
116+
try to publish a revoked commitment: when that is the case, it is wasteful to
117+
enforce a channel reserve.
118+
119+
In other cases, different incentives may be sufficient to remove the need for
120+
channel reserves.
121+
122+
A mobile wallet using a service provider is a good candidate for removing the
123+
reserve requirements. The wallet user is regularly paying fees to the service
124+
provider: this incentivizes the service provider to offer zero-reserve, which
125+
provides a better user experience. The service provider isn't taking any risk
126+
here, as they should always be online and able to punish revoked transactions.
127+
It also makes sense for the wallet user to offer zero-reserve to the service
128+
provider: even on a mobile wallet, users should be able to react to revoked
129+
transactions. If the service provider publishes a revoked transaction, the
130+
wallet user can additionnally create a public proof that the service provider
131+
tried to cheat: this harms the service provider's reputation, which is another
132+
incentive for them to avoid cheating.

0 commit comments

Comments
 (0)