-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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.
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
Set Commitment fee_per_kw for a New Channel #687
Comments
It's already possible to set the fee rate for the channel opening, see:
We currently don't consider this an issue as this is due to fee estimation on testnet being wonky. |
Ah, you want the ability to manually set the commitment fee rate. |
Thank you for the distinction. I've made edits to try clear that up. |
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. |
It is a typo, "closure" should be "funding". Currently you cannot set fee manually for the commitment tx, but that's a desired feature :) |
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>
.
|
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. |
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?
|
IMO |
I should have mentioned, my issue is on mainnet. But what you say makes sense. |
How long has your |
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 ***@***.***> 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
<#687 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADeQVcB7c_ub4qXnOxqLncE_VJYOqQxlks5tm8XMgaJpZM4Rv6HN>
.
|
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 pi@BTC-NODE:~ $ lncli -v 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 Thanks for letting me know what I am doing wrong. Cheers ! |
@rubenkr it's that fees on mainnet are very low right now. The remote party doesn't like the fee level you're suggesting. |
@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? |
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 ***@***.***> 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
<#687 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA87Li59Uowggg45jhd4q0lVwtahJpniks5uABMlgaJpZM4Rv6HN>
.
|
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. |
This is closed, but is there an option to set a specific
and can't figure out how to override it. |
You can use |
i'm getting the same error trying to open a channel to a CLN node. err=You gave bad parameters: feerate_per_kw 2500 below minimum 5597 Also tried increasing the |
You're getting that error as the peer wants you to set a higher fee rate. |
How can i set a higher fee rate? Is it another setting then --sat_per_vbyte ? |
Changing the channel open fee doesn't seem to have any effect on the error feerate_per_kw 2500 below minimum 2921 |
The commitment fee rate for Anchor channels will never exceed the minimum of |
I encountered an error while trying to
lncli openchannel
with a c-lightning node: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 LNDfee_per_kw
. To resolve this issue, I attempted to modify various user-configurable settings that might have an effect on the openingfee_per_kw
. I can't say that any of the following should have an effect on channelfee_per_kw
, but I tried them anyway:--bitcoin.feerate
--sat_per_byte
/--conf-target
options on openchannelupdatechanpolicy
before opening a channelUltimately, 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.
The text was updated successfully, but these errors were encountered: