Set Commitment fee_per_kw for a New Channel

[JASchilz]

I encountered an error while trying to lncli openchannel with a c-lightning node:

[lncli] rpc error: code = Code(202) desc = feerate_per_kw 2000 below minimum 2201

Details below. The summary is that I'm requesting the ability to set the commitment fee_per_kw for an opening channel, perhaps as a global setting or perhaps as an option during channel creation. I encountered this issue on mainnet.

The error message is produced by c-lightning around openning.c#L602. There's a reference in their code to a relevant bolt spec indicating that a node should refuse channel creation if it believes that the proposed feerate_per_kw is too low.

The c-lightning feerate_per_kw appears equivalent to the LND fee_per_kw. To resolve this issue, I attempted to modify various user-configurable settings that might have an effect on the opening fee_per_kw. I can't say that any of the following should have an effect on channel fee_per_kw, but I tried them anyway:

• the lnd setting --bitcoin.feerate
• the --sat_per_byte/--conf-target options on openchannel
• using lncli's updatechanpolicy before opening a channel

Ultimately, I resolved the issue for myself by adjusting a hard coded target confirmation block in fundingmanager.go#L2293 from 3 to 2.

I'm not familiar enough with the architecture of this project to propose a solution to resolving a channel opening feerate negotiation.

[Roasbeef]

It's already possible to set the fee rate for the channel opening, see:

⛰ lncli openchannel -h
NAME:
   lncli openchannel - Open a channel to an existing peer.

USAGE:
   lncli openchannel [command options] node-key local-amt push-amt

DESCRIPTION:

  Attempt to open a new channel to an existing peer with the key node-key
  optionally blocking until the channel is 'open'.

  The channel will be initialized with local-amt satoshis local and push-amt
  satoshis for the remote node. Once the channel is open, a channelPoint (txid:vout)
  of the funding output is returned.

  One can manually set the fee to be used for the funding transaction via either
  the --conf_target or --sat_per_byte arguments. This is optional.

  NOTE: peer_id and node_key are mutually exclusive, only one should be used, not both.

OPTIONS:
   --peer_id value        the relative id of the peer to open a channel with (default: 0)
   --node_key value       the identity public key of the target peer serialized in compressed format
   --local_amt value      the number of satoshis the wallet should commit to the channel (default: 0)
   --push_amt value       the number of satoshis to push to the remote side as part of the initial commitment state (default: 0)
   --block                block and wait until the channel is fully open
   --conf_target value    (optional) the number of blocks that the transaction *should* confirm in, will be used for fee estimation (default: 0)
   --sat_per_byte value   (optional) a manual fee expressed in sat/byte that should be used when crafting the transaction (default: 0)
   --private              make the channel private, such that it won't be announced to the greater network, and nodes other than the two channel endpoints must be explicitly told about it to be able to route through it
   --min_htlc_msat value  (optional) the minimum value we will require for incoming HTLCs on the channel (default: 0)

We currently don't consider this an issue as this is due to fee estimation on testnet being wonky.

[Roasbeef]

Ah, you want the ability to manually set the commitment fee rate.

[JASchilz]

Thank you for the distinction. I've made edits to try clear that up.

[stevenroose]

What is the reasoning for allowing a user to specify both target nb of confirmations and sat/byte feerate for the funding tx, but hard coding the commitment to estimation for 3 blocks?

Couldn't the fee settings the user puts be used for both? Also,

// / The target number of blocks that the closure transaction should be confirmed by.
TargetConf int32 `protobuf:"varint,6,opt,name=target_conf,json=targetConf" json:"target_conf,omitempty"`
// / A manual fee rate set in sat/byte that should be used when crafting the closure transaction.
SatPerByte int64 `protobuf:"varint,7,opt,name=sat_per_byte,json=satPerByte" json:"sat_per_byte,omitempty"`

The arguments are for the closure transaction, (aka Closing Transaction from BOLT?), while in the RPC server they are translated to the funding tx params (unless somewhere deeper in the code, the closing tx reuses these params).

Would it make sense to have a minimum fee rate argument that overrules all the estimations (for 3 and 6 block for commitment and funding resp.) when estimation is lower? In that case, bad estimations (too low ones) won't be rejected by other implementations when a reasonable minimum rate is set.

[halseth]

It is a typo, "closure" should be "funding".

Currently you cannot set fee manually for the commitment tx, but that's a desired feature :)

[Roasbeef]

The commitment transaction uses that target atm in order to ensure we can be included into a block quickly in the case of force close. There's an open issue to set the fee rate, the issue is that we need dynamically update the fee as we detect network conditions change. So an implementation to fix the issue would either need to disable the auto fee adjustment all together, or something different entirely.

…

On Thu, Mar 15, 2018, 7:40 AM Steven Roose ***@***.***> wrote: What is the reasoning for allowing a user to specify both target nb of confirmations and sat/byte feerate for the funding tx, but hard coding the commitment to estimation for 3 blocks? Couldn't the fee settings the user puts be used for both? Also, // / The target number of blocks that the closure transaction should be confirmed by. TargetConf int32 `protobuf:"varint,6,opt,name=target_conf,json=targetConf" json:"target_conf,omitempty"`// / A manual fee rate set in sat/byte that should be used when crafting the closure transaction. SatPerByte int64 `protobuf:"varint,7,opt,name=sat_per_byte,json=satPerByte" json:"sat_per_byte,omitempty"` The arguments are for the *closure transaction*, (aka Closing Transaction from BOLT?), while in the RPC server they are translated to the funding tx params (unless somewhere deeper in the code, the closing tx reuses these params). Would it make sense to have a *minimum fee rate* argument that overrules all the estimations (for 3 and 6 block for commitment and funding resp.) when estimation is lower? In that case, bad estimations (too low ones) won't be rejected by other implementations when a reasonable minimum rate is set. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#687 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA87Lk7Ggq1mvqY_xwcO-bWsAawlwyh3ks5ten1QgaJpZM4Rv6HN> .