@@ -15,6 +15,7 @@ const DEFAULT_LDK_WALLET_SYNC_INTERVAL_SECS: u64 = 30;
15
15
const DEFAULT_FEE_RATE_CACHE_UPDATE_INTERVAL_SECS : u64 = 60 * 10 ;
16
16
const DEFAULT_PROBING_LIQUIDITY_LIMIT_MULTIPLIER : u64 = 3 ;
17
17
const DEFAULT_LOG_LEVEL : LogLevel = LogLevel :: Debug ;
18
+ const DEFAULT_ANCHOR_PER_CHANNEL_RESERVE_SATS : u64 = 25_000 ;
18
19
19
20
// The 'stop gap' parameter used by BDK's wallet sync. This seems to configure the threshold
20
21
// number of derivation indexes after which BDK stops looking for new scripts belonging to the wallet.
@@ -62,6 +63,9 @@ pub(crate) const WALLET_KEYS_SEED_LEN: usize = 64;
62
63
/// | `trusted_peers_0conf` | [] |
63
64
/// | `probing_liquidity_limit_multiplier` | 3 |
64
65
/// | `log_level` | Debug |
66
+ /// | `anchor_channels_config` | Some(..) |
67
+ ///
68
+ /// See [`AnchorChannelsConfig`] for more information on its respective default values.
65
69
///
66
70
/// [`Node`]: crate::Node
67
71
pub struct Config {
@@ -104,6 +108,21 @@ pub struct Config {
104
108
///
105
109
/// Any messages below this level will be excluded from the logs.
106
110
pub log_level : LogLevel ,
111
+ /// Configuration options pertaining to Anchor channels, i.e., channels for which the
112
+ /// `option_anchors_zero_fee_htlc_tx` channel type is negotiated.
113
+ ///
114
+ /// Please refer to [`AnchorChannelsConfig`] for further information on Anchor channels.
115
+ ///
116
+ /// If set to `Some`, new channels will have Anchors enabled, i.e., will be negotiated with the
117
+ /// `option_anchors_zero_fee_htlc_tx` channel type. If set to `None`, new channels will be
118
+ /// negotiated with the legacy `option_static_remotekey` channel type.
119
+ ///
120
+ /// **Note:** Please note that if set to `None` *after* some Anchor channels have already been
121
+ /// opened, no dedicated emergency on-chain reserve will be maintained for these channels,
122
+ /// which can be dangerous if only insufficient funds are available at the time of channel
123
+ /// closure. We *will* however still try to get the Anchor spending transactions confirmed
124
+ /// on-chain with the funds available.
125
+ pub anchor_channels_config : Option < AnchorChannelsConfig > ,
107
126
}
108
127
109
128
impl Default for Config {
@@ -120,6 +139,66 @@ impl Default for Config {
120
139
trusted_peers_0conf : Vec :: new ( ) ,
121
140
probing_liquidity_limit_multiplier : DEFAULT_PROBING_LIQUIDITY_LIMIT_MULTIPLIER ,
122
141
log_level : DEFAULT_LOG_LEVEL ,
142
+ anchor_channels_config : Some ( AnchorChannelsConfig :: default ( ) ) ,
143
+ }
144
+ }
145
+ }
146
+
147
+ /// Configuration options pertaining to 'Anchor' channels, i.e., channels for which the
148
+ /// `option_anchors_zero_fee_htlc_tx` channel type is negotiated.
149
+ ///
150
+ /// Prior to the introduction of Anchor channels, the on-chain fees paying for the transactions
151
+ /// issued on channel closure were pre-determined and locked-in at the time of the channel
152
+ /// opening. This required to estimate what fee rate would be sufficient to still have the
153
+ /// closing transactions be spendable on-chain (i.e., not be considered dust). This legacy
154
+ /// design of pre-anchor channels proved inadequate in the unpredictable, often turbulent, fee
155
+ /// markets we experience today. In contrast, Anchor channels allow to determine an adequate
156
+ /// fee rate *at the time of channel closure*, making them much more robust in the face of fee
157
+ /// spikes. In turn, they require to maintain a reserve of on-chain funds to be able to get the
158
+ /// channel closure transactions confirmed on-chain, at least if the channel counterparty can't
159
+ /// be trusted to do this for us.
160
+ ///
161
+ /// See [BOLT 3] for more technical details on Anchor channels.
162
+ ///
163
+ ///
164
+ /// ### Defaults
165
+ ///
166
+ /// | Parameter | Value |
167
+ /// |----------------------------|--------|
168
+ /// | `trusted_peers_no_reserve` | [] |
169
+ /// | `per_channel_reserve_sats` | 25000 |
170
+ ///
171
+ ///
172
+ /// [BOLT 3]: https://github.com/lightning/bolts/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions
173
+ #[ derive( Debug , Clone ) ]
174
+ pub struct AnchorChannelsConfig {
175
+ /// A list of peers which we trust to get the required channel closing transactions confirmed
176
+ /// on-chain.
177
+ ///
178
+ /// Channels with these peers won't count towards the retained on-chain reserve and we won't
179
+ /// take any action to get the required transactions confirmed ourselves.
180
+ ///
181
+ /// **Note:** Trusting the channel counterparty to take the necessary actions to get the
182
+ /// required Anchor spending and HTLC transactions confirmed on-chain is potentially insecure
183
+ /// as the channel may not be closed if they refuse to do so, potentially leaving the user
184
+ /// funds stuck *or* even allow the counterparty to steal any in-flight funds after the
185
+ /// corresponding HTLCs time out.
186
+ pub trusted_peers_no_reserve : Vec < PublicKey > ,
187
+ /// The amount of satoshis we keep as an emergency reserve in our on-chain wallet in order to
188
+ /// be able to get the required Anchor output spending and HTLC transactions confirmed when the
189
+ /// channel is closed.
190
+ ///
191
+ /// **Note:** Depending on the fee market at the time of closure, this reserve amount might or
192
+ /// might not suffice to successfully spend the Anchor output and have the HTLC transactions
193
+ /// confirmed on-chain, i.e., you may want to adjust this value accordingly.
194
+ pub per_channel_reserve_sats : u64 ,
195
+ }
196
+
197
+ impl Default for AnchorChannelsConfig {
198
+ fn default ( ) -> Self {
199
+ Self {
200
+ trusted_peers_no_reserve : Vec :: new ( ) ,
201
+ per_channel_reserve_sats : DEFAULT_ANCHOR_PER_CHANNEL_RESERVE_SATS ,
123
202
}
124
203
}
125
204
}
0 commit comments