-
Notifications
You must be signed in to change notification settings - Fork 913
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
channel funding tx fee too low #1194
Comments
I don't know the answer to your question (and thanks for the report; I believe c-lightning does need to handle this situation better), but as a workaround to get your channel set up you should be able to set |
I don't think that's the only problem, considering that there were several channels opened with the same bitcoind.conf. I wonder if there's any kind of fee estimation and it makes use of the fact that minrelayfee can be obtained from bitcoind and not use a lower one |
That's a weird one: according to the decoded message and the output being spent c-lightning is trying to create a transaction with a negative fees (950000 + 49543 - 999695 = -152 satoshi fee). Can you share the output of |
Here it is
|
Sorry, I was hoping to see what c-lightning believes the value of output |
After dev-rescan-outputs
|
Hm, also doesn't contain the output I was looking for, maybe it's marked as spent as well? Could you run the following and share the output?
|
here it is
|
My bad, it was in there, I just miscopied the txid: the following lines are what I was looking for
(hashes in the db are reversed since they are kept in the hash-order and not little-endian). Those values seem to match the actual output values: 0.00999695 BTC. The first transaction above is decoded into:
Which results in a fee of 0.00999695 - (0.00950000 + 0.00049543) = 1.52e-6, not negative, but rather on the small side. Probably just an artifact of |
@cdecker: Let me know if I'm missing something, but regardless of potential wacky responses from So unless the user notices and diagnoses the issue, lowers |
Yes, we should really impose a timeout on |
I think the timeout is a good idea, especially if something like |
Can you provide logs regarding what we got from |
I could only find one call to estimatesmartfee, but it is not related to any of those fundings (it's an earlier call and reads |
I am also seeing this behavior. |
here's a more complete log from lightningd from around the time of the failed funding
|
I'm also getting the same issue
|
Same here. Interestingly, I also got exactly the same fee in the funding tx: 152 satoshi. Coincidence? I don't think so. For reference, my funding tx (on testnet): This was between two of my own lightningd nodes (both v0.5.2-2016-11-21-2240-gb2ce619b). Edit: shouldn't the funding node be able to get out of this state by double-spending the funding tx? This could be the behavior if 'close' is called in this state. Behavior has to conform to the protocol though. |
Below is my latest attempt along with results from the
|
even with a more recent version v0.5.2-2016-11-21-2350-g234d67d, the problem remains, I can't seem to be able to fund any newly opened channels
|
It has not been fixed yet. The issue is that there is no bitcoind RPC command that lets us query the minimum relay fee. Possibly we need to make it into an option to lightningd, with a default similar or higher than bitcoind default, then when querying |
Yeah, I believe that you should use |
This is not so easy! Changing the fee changes the txid of the funding transaction. Unfortunately the txid of the funding transaction is negotiated beforehand because the first commitment transaction that returns the money back to the funder must get signed before the funding transaction is signed and broadcast. This means we need to restart the opening negotiation. In theory what we can do if we are the funder, and, we get this error 66:
(The above is almost similar to what we would do if we implement RBF on channel funding, BTW, but there are tricky issues regarding RBF which make it painful to implement for us now) But the above is significantly more complex and requires careful planning of the DB. The simple "if dumb |
|
See the fee calculations round down @ Lines 245 to 247 in 0a6e3d1
Just change that to
|
We can fix our own txs (and should) but the feerate to fee calc is a consensus issue detailed in the spec. This probably means we need to correct the feerate with a floor, so we negotiate so this Never Happens for commitment txs. And probing for our own minrelayfee is pointless: we need everyone else's. In practice, that's 1000. |
If feerate_per_kw is 1000, this is not a rounding problem! It's the old braindead bitcoind code. Fix incoming. |
Naively, this would be 4000 satoshi per sipa, but it's not since bitcoind's fee calculation was not rewritten to deal with weight, but instead bolted on using vbytes. The resulting calculations made me cry; I dried my tears on the thorns of BUILD_ASSERT (I know that makes no sense, but bear with me here as I'm trying not to swear at my bitcoind colleagues right now). Fixes: ElementsProject#1194 Signed-off-by: Rusty Russell <[email protected]>
Naively, this would be 250 satoshi per sipa, but it's not since bitcoind's fee calculation was not rewritten to deal with weight, but instead bolted on using vbytes. The resulting calculations made me cry; I dried my tears on the thorns of BUILD_ASSERT (I know that makes no sense, but bear with me here as I'm trying not to swear at my bitcoind colleagues right now). Fixes: ElementsProject#1194 Signed-off-by: Rusty Russell <[email protected]>
Naively, this would be 250 satoshi per sipa, but it's not since bitcoind's fee calculation was not rewritten to deal with weight, but instead bolted on using vbytes. The resulting calculations made me cry; I dried my tears on the thorns of BUILD_ASSERT (I know that makes no sense, but bear with me here as I'm trying not to swear at my bitcoind colleagues right now). Fixes: #1194 Signed-off-by: Rusty Russell <[email protected]>
"version" : "v0.5.2-2016-11-21-2262-gd363a68"
any channel I try to fund ends up with 66: min relay fee not met? and the log shows
my bitcoind is 0.16 and getnetworkinfo shows (relevant info : "relayfee": 1e-05)
is there a way to specify the fee for the funding transaction?
The text was updated successfully, but these errors were encountered: