-
Notifications
You must be signed in to change notification settings - Fork 912
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
fundchannel fails with lnd node #4238
Comments
Huh. This is an error which "should not" happen. Can you provide logs? We use the term "urgent" rather than "fast" for feerates, so it seems likely to me that the problem is triggered by this. But it should lead to a -32602 parameter error, not a |
@ZmnSCPxj thank you for your response. I tried
with the result
|
This is what i have in logs
|
Can you enable |
@ZmnSCPxj I will look into this plugin and I will try to do that. |
Does it help you @ZmnSCPxj ?
|
There is something fairly strange with your setup, with multiple On the other hand, |
@ZmnSCPxj that's an alias
|
Your suggestion reminded me to check my setup and I indeed have specified plugin dir in config. |
@ZmnSCPxj Ok. I figured that out that lightning always load "important" plugins from Now, |
No more issues with |
I've not tested it yet. If you know a recipe for how to abandon not opened channel I can test it faster. There is an important for me peer with which I can't open a channel. The transaction failed to broadcast, and I ended up with this AWAITING_UNILATERAL state for days.
|
Ideally, we should really double-spend the funding transaction and force the outputs it spent to be re-spent on an If you are sure that nobody else has a copy of the funding/unilteral-close transaction (a random wog could just keep a copy and broadcast it later during a low-fee period, this is always a risk with onchain, which is why you should really avoid |
It looks like it is exactly what I need. Thank you very much @ZmnSCPxj, you are a legend. I will come back with the results later. |
@ZmnSCPxj thank you for the hint. The channel disappeared from my DB finally. |
Only occurs for |
@ZmnSCPxj I've tried to track problem with "non-matching" |
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes ElementsProject#4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
Turns out it was a malformed parameter from the shell being inserted verbatim into the JSON-RPC request, and thus failing the parser in See #4259 for a fix: we now parse the request in |
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes ElementsProject#4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes ElementsProject#4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes ElementsProject#4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes ElementsProject#4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes #4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes #4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes #4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
In a couple of places we accept arrays of strings and don't validate them. If we forward them, e.g., call a JSON-RPC method from the plugin, we end up embedding the unverified string in the JSON-RPC call without escaping, which then leads to invalid JSON being passed on. This at least partially causes ElementsProject#4238
We were masquerading errors when parsing the request by reporting only a bogus malformed `id` field in the response, when the real issue was that we were unable to parse the request in the first place (which caused the null-id error to be returned). Fixes ElementsProject#4238
If some parameter is malformed on the command line we could end up with a malformed JSON-RPC request, which would then result in very unhelpful error messages. Fixes ElementsProject#4238 Changelog-Changed: cli: `lightning-cli` now performs better sanity checks on the JSON-RPC requests it sends.
Issue and Steps to Reproduce
I'm trying to open a channel with
And I get an error which I do not understand.
getinfo
outputThe text was updated successfully, but these errors were encountered: