forked from ElementsProject/lightning
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Test is provided for lightning gossip not showing up #4
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reported-by: Shahana Signed-off-by: Rusty Russell <[email protected]>
[Moved into a separate commit --RR]
…ut points to docs.corelighting.org for the rest Signed-off-by: Rusty Russell <[email protected]>
Added documentation for splice_update & splice_signed and tweaked splice_init. Added corresponding schemas for splice_* commands Changelog-None
We use this file as a proxy for breaking changes in the signer protocol. It may not catch all the breaking changes, but it's a good first approximation.
This make ACINQ seize up, and not send revoke_and_ack. Eventually, this can cause a bad signature error, should payments go in both directions, which is a separate bug, but this is the trigger. See: ElementsProject#6500 Signed-off-by: Rusty Russell <[email protected]>
Updated bitcoin and elements versions to 22.0.
Less than 22 is obsolete anyway, so we should increment this from 16.0 at least! Closes: ElementsProject#6234 Signed-off-by: Rusty Russell <[email protected]>
Suggested-by: @Lagrang3 Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
I noticed this while debugging an issue with ACINQ, that we got upset, but didn't trigger a reconnect cycle. Signed-off-by: Rusty Russell <[email protected]> Changelog-Fixed: Protocol: We now close connection with a peer if adding an HTLC times out (which may be a TCP connectivity issue).
Signed-off-by: Rusty Russell <[email protected]>
…endpays and renepay Since bolt11_decode now insists that any `lightning:` prefix be removed, we need to make sure to use param_invstring not param_string for all bolt11 parameters: ``` 2023-08-07T05:55:32.515Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v23.08rc1-21-g0bf5ee6) 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x55dd94934154 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: common/daemon.c:75 (crashdump) 0x55dd949342e6 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x7f5cf5a3bcef 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x7f5cf5a9226b 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:78 (__pthread_kill_internal) 0x7f5cf5a9226b 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:89 (__GI___pthread_kill) 0x7f5cf5a9226b 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x7f5cf5a3bc45 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x7f5cf5a227fb 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./assert/assert.c:92 (__assert_fail_base) 0x7f5cf5a2271a 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: ./assert/assert.c:101 (__GI___assert_fail) 0x7f5cf5a33595 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: common/bolt11.c:734 (bolt11_decode_nosig) 0x55dd94929967 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: common/bolt11.c:953 (bolt11_decode) 0x55dd9492a44f 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: lightningd/pay.c:1730 (json_listsendpays) 0x55dd948d7d72 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:658 (command_exec) 0x55dd948b525b 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:786 (rpc_command_hook_final) 0x55dd948b5876 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:285 (plugin_hook_call_) 0x55dd948f6446 2023-08-07T05:55:32.515Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:874 (plugin_hook_call_rpc_command) 0x55dd948b5c77 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:984 (parse_request) 0x55dd948b6234 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1090 (read_json) 0x55dd948b670f 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:59 (next_plan) 0x55dd94ac9bf4 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:407 (do_plan) 0x55dd94aca823 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:417 (io_ready) 0x55dd94aca865 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:453 (io_loop) 0x55dd94accbff 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x55dd948b33c4 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1332 (main) 0x55dd948ba429 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x7f5cf5a2350f 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: ../csu/libc-start.c:381 (__libc_start_main_impl) 0x7f5cf5a235c8 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x55dd94881e74 2023-08-07T05:55:32.516Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff ``` Fixes: ElementsProject#6524 Signed-off-by: Rusty Russell <[email protected]> Changelog-None: broken in master since last release.
* fix flake8 errors * fix E126 error * fix E123 error
Apparently MacOS doesn't always have fdatasync, so use fsync. Even more importantly check whether it succeeds! Fixes: ElementsProject#6516 Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Peter Neuroth <[email protected]> [ Regenerated man pages --RR ]
…library. See: bitcoindevkit/bdk#1047 (comment) In general, futures produced by most libraries in the ecosystem of Rust, and bounds placed on users of famous runtimes like tokio and its spawn method all lack Sync requirements. Because of this, anyone who creates a callback using any sort of library that returns a non-Sync future (which most libraries fit this description) inside of it will get some cryptic error messages (async error messages still leave a lot to be desired). Removing these Sync requirements will make the library more useful.
I obviously like the word "capabilities" since I reused it to refer to the HSM's overall features :( Suggested-by: @ksedgwic Signed-off-by: Rusty Russell <[email protected]>
The nomenclature confusion mean that we were ANDING a capability with a message number (29) which always returned non-zero. We really do need a new capability which we can hand to channeld to make these splice txs. Signed-off-by: Rusty Russell <[email protected]>
EXPERIMENTAL_SPLICING=1 turns it on for *all* tests, to make sure we don't accidentally break those. But we can (and should!) run the splice test under every possible CI scenario. Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Lagrang3 <[email protected]>
We've stomped errno, so if exec fails we don't get a reliable result: ``` 2023-08-07T17:58:45.713Z **BROKEN** plugin-bcli: bitcoin-cli exec failed: Bad file descriptor ``` Signed-off-by: Rusty Russell <[email protected]>
This was recommended by @t-bast: if the final spec commits to something compatible, we can simply advertize and accept both features, but if it does change in incompatible ways we won't cause problems for nodes who implement the official spec. (I split this, so first, we remove the OPT_SPLICE entirely, to make sure we caught them all. --RR) Suggested-by: @t-bast Changelog-None
Signed-off-by: Rusty Russell <[email protected]>
Don't know how this is happening, but it is not harmful to ignore it for now. Fixes: ElementsProject#6531 Signed-off-by: Rusty Russell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Occasionally in my monkey testing, the new spliced channel will appear in the listchannels response, and generally be great. However, this behaviour is not consistent. The provided (failing) test should surface that behavior.
In a slightly related bit of work, I made it so listpeerchannels will not crash due to the new value in the old state.