Lnd: 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 [e-mail] 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
https://github.com/lightningnetwork/lnd/issues/687#issuecomment-373398976,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA87Lk7Ggq1mvqY_xwcO-bWsAawlwyh3ks5ten1QgaJpZM4Rv6HN
.

[stevenroose]

That's why I suggested that a minimum fee rate could be a good idea. So that lnd can still overrule when fees rise, but a user can still make sure he has a certain priority when lnd's fee estimation suggests lower fee rates.

[chrisrico]

I'm running into a related issue trying to connect to a c-lightning node. The other side is not accepting the channel because my fee rate is _too high_. Perhaps both a (local) minimum and maximum could be set at the channel level when opening?

[lncli] rpc error: code = Code(189) desc = You gave bad parameters:feerate_per_kw 43000 above maximum 6310

[Roasbeef]

IMO clightning should _relax_ the constraints. Note that the _initiator_ is the only that actually pays the fees on the commitment transaction. Therefore they don't really incur a direct penalty by accepting a higher fee rate. Also worth pointing out that this is testnet, and fee estimation is a bit wonky as fees don't matter on testnet at all.

[chrisrico]

I should have mentioned, my issue is on mainnet. But what you say makes sense.

[Roasbeef]

You gave bad parameters:feerate_per_kw 43000

How long has your btcd node been active? That's a very high fee per kw, especially given how low fee rates are on mainnet these days.

[chrisrico]

I use bitcoind backend, my node has been running almost constantly since
v0.16 RC1.

On Mon, Apr 9, 2018, 3:34 PM Olaoluwa Osuntokun [e-mail]
wrote:

You gave bad parameters:feerate_per_kw 43000

How long has your btcd node been active? That's a very high fee per kw,
especially given how low fee rates are on mainnet these days.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lightningnetwork/lnd/issues/687#issuecomment-379885229,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADeQVcB7c_ub4qXnOxqLncE_VJYOqQxlks5tm8XMgaJpZM4Rv6HN
.

[rubenkr]

I have the similar issues here trying to connect to a node it says:

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

pi@BTC-NODE:~ $ uname -a
Linux BTC-NODE 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l GNU/Linux

pi@BTC-NODE:~ $ lncli -v
lncli version 0.4.1 commit=

bitcoind 0.16

Also trying to set fee manually has no luck:

lncli openchannel --node_key xxxx --connect xx.xx.xx.xx:9735 --sat_per_byte 253 --local_amt 20000
[lncli] rpc error: code = Code(202) desc = feerate_per_kw 250 below minimum 253

Thanks for letting me know what I am doing wrong.

Cheers !

[Roasbeef]

@rubenkr it's that fees on mainnet are very low right now. The remote party doesn't like the fee level you're suggesting.

[slush0]

@Roasbeef I have the same issue as @rubenkr, other node is rejecting with "You gave bad parameters:feerate_per_kw 250 below minimum 253".

Thanks to your comment, I understand what's going wrong, but the solution isn't obvious to me. I didn't find any configuration regards suggesting fee rate from my node's side. The only parameter I see is --sat_per_byte, but regardless of its value, the error message is still the same. What I'm doing wrong?

[Roasbeef]

You're not doing anything wrong, it's that the c-lightning node you're
trying to connect to doesn't like your fees, since they're so low on
mainnet. If you update to master then we've added this temp fee floor.

On Sun, Jun 24, 2018, 3:31 PM Marek Palatinus [e-mail]
wrote:

@Roasbeef https://github.com/Roasbeef I have the same issue as @rubenkr
https://github.com/rubenkr, other node is rejecting with "You gave bad
parameters:feerate_per_kw 250 below minimum 253".

Thanks to your comment, I understand what's going wrong, but the solution
isn't obvious to me. What I'm doing wrong? I didn't find any configuration
regards suggesting fee rate from my node's side. The only parameter I see
is --sat_per_byte, but regardless of its value, the error message is still
the same.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/lightningnetwork/lnd/issues/687#issuecomment-399792909,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA87Li59Uowggg45jhd4q0lVwtahJpniks5uABMlgaJpZM4Rv6HN
.

[Roasbeef]

With #3599 it will no longe be critical to set the fee of the commitment transaction, as you'll be able to adjust the fee after broadcast.