fixed typos in pdf #2

pm47 · 2015-08-18T10:03:56Z

No description provided.

rustyrussell · 2015-08-19T02:10:12Z

Thanks!

For the change to asynchronous updates as specified by BOLT #2, we need to know when the other side acknowledged a packet. This creates a simple callback mechanism for it. Signed-off-by: Rusty Russell <[email protected]>

We don't actually implement closing when we have HTLCs (we should allow it, as that's what the clearing phase is for), since soon we'll rewrite HTLC to match the async HTLC protocol of BOLT #2. Note that this folds the close paths, using a simple check if we have a close transaction. That's a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell <[email protected]>

And divide fees as specified there. We still use fixed values rather than floating, and we don't send or handle update_fee messages. Signed-off-by: Rusty Russell <[email protected]>

We now keep a list of commitment transaction states for "us" and "them", as well as a "struct channel_state" for staged changes. We manipulate these structures as we send out packets, receive packets, or receive acknowledgement of packets. In particular, we update the other nodes' staging_cstate as we send out our requests, and update our own staging_cstate are we receive acks. When we receive a request, we update both (as we immediately send out our ack). The RPC output is changed; rather than expose the complexity, we expose our last committed state: what would happen if we have to drop to the blockchain now. Signed-off-by: Rusty Russell <[email protected]>

This reflects the BOLT #1/#2 protocol change, as suggeted by Pierre. Signed-off-by: Rusty Russell <[email protected]>

From BOLT#2 (rev 8ee09e749990a11fa53bea03d5961cfde4be4616): Thus each node (conceptually) tracks: ... 3. Two *unacked changesets*: one for the local commitment (their proposals) and one for the remote (our proposals) 4. Two *acked changesets*: one for the local commitment (our proposals, acknowledged) and one for the remote (their proposals, acknowledged). (Note that an implementation MAY optimize this internally, for example, pre-applying the changesets in some cases). In our case, we apply the unacked changes immediately into staging_cstate, and save them in an unacked_changes array. That array gets applied to staging_cstate as soon as it's acked (we only allow one outstanding update_commit, so we only need one array). Signed-off-by: Rusty Russell <[email protected]>

If we send an HTLC #1, then get disconnected before a confirm, we will forget it. But we've incremented peer->htlc_id_counter, so when we offer it again we'll make it HTLC #2, which is non-consecutive. To make this clear, we always start htlc ids at 0 now. That revealed the bugs handled in the previous patch. Signed-off-by: Rusty Russell <[email protected]>

To match 8ad8041990dc "wire-protocol: rename reconnect_pkt to init_pkt, add feature bits." Signed-off-by: Rusty Russell <[email protected]>

828eda6, in particular, it has the new address format for node_announcement. Signed-off-by: Rusty Russell <[email protected]>

This object is basically the embodyment of BOLT #2. Each HTLC already knows its own state; this moves them between states and keeps them consistent. Signed-off-by: Rusty Russell <[email protected]>

lightning/bolts#138: BOLT 2: htlc-cltv must be in blocks. Signed-off-by: Rusty Russell <[email protected]>

Only the side *accepting* the connection gives a `minumum_depth`, but both sides are supposed to wait that long: BOLT #2: ### The `funding_locked` message ... #### Requirements The sender MUST wait until the funding transaction has reached `minimum-depth` before sending this message. Signed-off-by: Rusty Russell <[email protected]>

… channel yet. Valgrind error file: /tmp/lightning-8k06jbb3/test_disconnect/lightning-7/valgrind-errors ==32307== Uninitialised byte(s) found during client check request ==32307== at 0x11EBAD: memcheck_ (mem.h:247) ==32307== by 0x11EC18: towire (towire.c:14) ==32307== by 0x11EF19: towire_short_channel_id (towire.c:92) ==32307== by 0x12203E: towire_channel_update (gen_peer_wire.c:918) ==32307== by 0x1148D4: send_channel_update (channel.c:185) ==32307== by 0x1175C5: peer_conn_broken (channel.c:1010) ==32307== by 0x13186F: destroy_conn (poll.c:173) ==32307== by 0x13188F: destroy_conn_close_fd (poll.c:179) ==32307== by 0x13B279: notify (tal.c:235) ==32307== by 0x13B721: del_tree (tal.c:395) ==32307== by 0x13BB3A: tal_free (tal.c:504) ==32307== by 0x130522: io_close (io.c:415) ==32307== Address 0xffefff87d is on thread 1's stack ==32307== in frame #2, created by towire_short_channel_id (towire.c:88) Signed-off-by: Rusty Russell <[email protected]>

The variable `block` (instace of `struct block`) is allocated on the stack without being initialized, i.e. its member `prev` points to nowhere. This causes a segmentation fault on my machine on the binding of "prev_hash" on running `wallet_block_add`, as the following core-dump analysis shows: $ egdb ./wallet/test/run-wallet ./run-wallet.core [...] Core was generated by `run-wallet'. Program terminated with signal SIGSEGV, Segmentation fault. ---Type <return> to continue, or q <return> to quit--- #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 97 TLOOP1(*dst++ = *src++); (gdb) bt #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 ElementsProject#1 0x000008f73e838f60 in sqlite3VdbeMemSetStr () from /usr/local/lib/libsqlite3.so.37.12 ElementsProject#2 0x000008f73e83cb11 in bindText () from /usr/local/lib/libsqlite3.so.37.12 ElementsProject#3 0x000008f44bc91345 in db_sqlite3_query (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:77 ElementsProject#4 0x000008f44bc91122 in db_sqlite3_exec (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:110 ElementsProject#5 0x000008f44bcbb3b2 in db_exec_prepared_v2 (stmt=0x8f6845bf028) at ./wallet/db.c:2055 ElementsProject#6 0x000008f44bcc6890 in wallet_block_add (w=0x8f688b5bba8, b=0x7f7ffffca788) at ./wallet/wallet.c:3556 ElementsProject#7 0x000008f44bce2607 in test_wallet_outputs (ld=0x8f6a35a7828, ctx=0x8f6a35c0268) at wallet/test/run-wallet.c:1104 ElementsProject#8 0x000008f44bcddec0 in main (argc=1, argv=0x7f7ffffcaaf8) at wallet/test/run-wallet.c:1930 Fix by explicitely setting the whole structure to zero. [ Rebuilt generated files, too --RR ]

The variable `block` (instace of `struct block`) is allocated on the stack without being initialized, i.e. its member `prev` points to nowhere. This causes a segmentation fault on my machine on the binding of "prev_hash" on running `wallet_block_add`, as the following core-dump analysis shows: $ egdb ./wallet/test/run-wallet ./run-wallet.core [...] Core was generated by `run-wallet'. Program terminated with signal SIGSEGV, Segmentation fault. ---Type <return> to continue, or q <return> to quit--- #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 97 TLOOP1(*dst++ = *src++); (gdb) bt #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 #1 0x000008f73e838f60 in sqlite3VdbeMemSetStr () from /usr/local/lib/libsqlite3.so.37.12 #2 0x000008f73e83cb11 in bindText () from /usr/local/lib/libsqlite3.so.37.12 #3 0x000008f44bc91345 in db_sqlite3_query (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:77 #4 0x000008f44bc91122 in db_sqlite3_exec (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:110 #5 0x000008f44bcbb3b2 in db_exec_prepared_v2 (stmt=0x8f6845bf028) at ./wallet/db.c:2055 #6 0x000008f44bcc6890 in wallet_block_add (w=0x8f688b5bba8, b=0x7f7ffffca788) at ./wallet/wallet.c:3556 #7 0x000008f44bce2607 in test_wallet_outputs (ld=0x8f6a35a7828, ctx=0x8f6a35c0268) at wallet/test/run-wallet.c:1104 #8 0x000008f44bcddec0 in main (argc=1, argv=0x7f7ffffcaaf8) at wallet/test/run-wallet.c:1930 Fix by explicitely setting the whole structure to zero. [ Rebuilt generated files, too --RR ]

The variable `block` (instace of `struct block`) is allocated on the stack without being initialized, i.e. its member `prev` points to nowhere. This causes a segmentation fault on my machine on the binding of "prev_hash" on running `wallet_block_add`, as the following core-dump analysis shows: $ egdb ./wallet/test/run-wallet ./run-wallet.core [...] Core was generated by `run-wallet'. Program terminated with signal SIGSEGV, Segmentation fault. ---Type <return> to continue, or q <return> to quit--- #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 97 TLOOP1(*dst++ = *src++); (gdb) bt #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 ElementsProject#1 0x000008f73e838f60 in sqlite3VdbeMemSetStr () from /usr/local/lib/libsqlite3.so.37.12 ElementsProject#2 0x000008f73e83cb11 in bindText () from /usr/local/lib/libsqlite3.so.37.12 ElementsProject#3 0x000008f44bc91345 in db_sqlite3_query (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:77 ElementsProject#4 0x000008f44bc91122 in db_sqlite3_exec (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:110 ElementsProject#5 0x000008f44bcbb3b2 in db_exec_prepared_v2 (stmt=0x8f6845bf028) at ./wallet/db.c:2055 ElementsProject#6 0x000008f44bcc6890 in wallet_block_add (w=0x8f688b5bba8, b=0x7f7ffffca788) at ./wallet/wallet.c:3556 ElementsProject#7 0x000008f44bce2607 in test_wallet_outputs (ld=0x8f6a35a7828, ctx=0x8f6a35c0268) at wallet/test/run-wallet.c:1104 ElementsProject#8 0x000008f44bcddec0 in main (argc=1, argv=0x7f7ffffcaaf8) at wallet/test/run-wallet.c:1930 Fix by explicitely setting the whole structure to zero. [ Rebuilt generated files, too --RR ]

@rustyrussell

This will fix a crash that I caused on armv7 and by looking inside the coredump with gdb (by adding an assert on n that must be different from null) I get the following stacktrace ``` (gdb) bt \#0 0x00000000 in ?? () \#1 0x0043a038 in send_backtrace (why=0xbe9e3600 "FATAL SIGNAL 11") at common/daemon.c:36 \#2 0x0043a0ec in crashdump (sig=11) at common/daemon.c:46 \#3 <signal handler called> \#4 0x00406d04 in node_announcement (map=0x938ecc, nann_off=495146) at common/gossmap.c:586 \#5 0x00406fec in map_catchup (map=0x938ecc, num_rejected=0xbe9e3a40) at common/gossmap.c:643 \#6 0x004073a4 in load_gossip_store (map=0x938ecc, num_rejected=0xbe9e3a40) at common/gossmap.c:697 \#7 0x00408244 in gossmap_load (ctx=0x0, filename=0x4e16b8 "gossip_store", num_channel_updates_rejected=0xbe9e3a40) at common/gossmap.c:976 \#8 0x0041a548 in init (p=0x93831c, buf=0x9399d4 "\n\n{\"jsonrpc\":\"2.0\",\"id\":\"cln:init#25\",\"method\":\"init\",\"params\":{\"options\":{},\"configuration\":{\"lightning-dir\":\"/home/vincent/.lightning/testnet\",\"rpc-file\":\"lightning-rpc\",\"startup\":true,\"network\":\"te"..., config=0x939cdc) at plugins/topology.c:622 \#9 0x0041e5d0 in handle_init (cmd=0x938934, buf=0x9399d4 "\n\n{\"jsonrpc\":\"2.0\",\"id\":\"cln:init#25\",\"method\":\"init\",\"params\":{\"options\":{},\"configuration\":{\"lightning-dir\":\"/home/vincent/.lightning/testnet\",\"rpc-file\":\"lightning-rpc\",\"startup\":true,\"network\":\"te"..., params=0x939c8c) at plugins/libplugin.c:1208 \#10 0x0041fc04 in ld_command_handle (plugin=0x93831c, toks=0x939bec) at plugins/libplugin.c:1572 \#11 0x00420050 in ld_read_json_one (plugin=0x93831c) at plugins/libplugin.c:1667 \#12 0x004201bc in ld_read_json (conn=0x9391c4, plugin=0x93831c) at plugins/libplugin.c:1687 \#13 0x004cb82c in next_plan (conn=0x9391c4, plan=0x9391d8) at ccan/ccan/io/io.c:59 \#14 0x004cc67c in do_plan (conn=0x9391c4, plan=0x9391d8, idle_on_epipe=false) at ccan/ccan/io/io.c:407 \#15 0x004cc6dc in io_ready (conn=0x9391c4, pollflags=1) at ccan/ccan/io/io.c:417 \#16 0x004cf8cc in io_loop (timers=0x9383c4, expired=0xbe9e3ce4) at ccan/ccan/io/poll.c:453 \#17 0x00420af4 in plugin_main (argv=0xbe9e3eb4, init=0x41a46c <init>, restartability=PLUGIN_STATIC, init_rpc=true, features=0x0, commands=0x6167e8 <commands>, num_commands=4, notif_subs=0x0, num_notif_subs=0, hook_subs=0x0, num_hook_subs=0, notif_topics=0x0, num_notif_topics=0) at plugins/libplugin.c:1891 \#18 0x0041a6f8 in main (argc=1, argv=0xbe9e3eb4) at plugins/topology.c:679 ``` I do not know if this is a solution because I do not know when I can parse a node announcement for a node that it is not longer in the gossip map. So, I hope this is just usefult for @rustyrussell Changelog-Fixed: fixes `FATAL SIGNAL 11` on gossmap node announcement parsing. Signed-off-by: Vincenzo Palazzo <[email protected]>

The issue is that common_setup() wasn't called by the fuzz target, leaving secp256k1_ctx as NULL. UBSan error: $ UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \ ./fuzz-channel_id crash-1575b41ef09e62e4c09c165e6dc037a110b113f2 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 1153355603 INFO: Loaded 1 modules (25915 inline 8-bit counters): 25915 [0x563bae7ac3a8, 0x563bae7b28e3), INFO: Loaded 1 PC tables (25915 PCs): 25915 [0x563bae7b28e8,0x563bae817c98), ./fuzz-channel_id: Running 1 inputs 1 time(s) each. Running: crash-1575b41ef09e62e4c09c165e6dc037a110b113f2 bitcoin/pubkey.c:22:33: runtime error: null pointer passed as argument 1, which is declared to never be null external/libwally-core/src/secp256k1/include/secp256k1.h:373:3: note: nonnull attribute specified here #0 0x563bae41e3db in pubkey_from_der bitcoin/pubkey.c:19:7 #1 0x563bae4205e0 in fromwire_pubkey bitcoin/pubkey.c:111:7 #2 0x563bae46437c in run tests/fuzz/fuzz-channel_id.c:42:3 #3 0x563bae2f6016 in LLVMFuzzerTestOneInput tests/fuzz/libfuzz.c:23:2 #4 0x563bae20a450 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) ElementsProject#5 0x563bae1f4c3f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ElementsProject#6 0x563bae1fa6e6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ElementsProject#7 0x563bae223052 in main (tests/fuzz/fuzz-channel_id+0x181052) (BuildId: f7f56e14ffc06df54ab732d79ea922e773de1f25) ElementsProject#8 0x7fa7fa113082 in __libc_start_main ElementsProject#9 0x563bae1efbdd in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bitcoin/pubkey.c:22:33 in

The issue is that common_setup() wasn't called by the fuzz target, leaving secp256k1_ctx as NULL. UBSan error: $ UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \ ./fuzz-channel_id crash-1575b41ef09e62e4c09c165e6dc037a110b113f2 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 1153355603 INFO: Loaded 1 modules (25915 inline 8-bit counters): 25915 [0x563bae7ac3a8, 0x563bae7b28e3), INFO: Loaded 1 PC tables (25915 PCs): 25915 [0x563bae7b28e8,0x563bae817c98), ./fuzz-channel_id: Running 1 inputs 1 time(s) each. Running: crash-1575b41ef09e62e4c09c165e6dc037a110b113f2 bitcoin/pubkey.c:22:33: runtime error: null pointer passed as argument 1, which is declared to never be null external/libwally-core/src/secp256k1/include/secp256k1.h:373:3: note: nonnull attribute specified here #0 0x563bae41e3db in pubkey_from_der bitcoin/pubkey.c:19:7 #1 0x563bae4205e0 in fromwire_pubkey bitcoin/pubkey.c:111:7 #2 0x563bae46437c in run tests/fuzz/fuzz-channel_id.c:42:3 #3 0x563bae2f6016 in LLVMFuzzerTestOneInput tests/fuzz/libfuzz.c:23:2 #4 0x563bae20a450 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) #5 0x563bae1f4c3f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) #6 0x563bae1fa6e6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) #7 0x563bae223052 in main (tests/fuzz/fuzz-channel_id+0x181052) (BuildId: f7f56e14ffc06df54ab732d79ea922e773de1f25) #8 0x7fa7fa113082 in __libc_start_main #9 0x563bae1efbdd in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bitcoin/pubkey.c:22:33 in

The function is tiny and was only used in one location. And that one location was leaking memory. Detected by ASan: ==2637667==ERROR: LeakSanitizer: detected memory leaks Direct leak of 7 byte(s) in 1 object(s) allocated from: #0 0x4cd758 in __interceptor_strdup #1 0x64c70c in json_stream_log_suppress_for_cmd lightning/lightningd/jsonrpc.c:597:31 #2 0x68a630 in json_getlog lightning/lightningd/log.c:974:2 ... SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).

It is possible for db_column_bytes() to return 0 and for db_column_blob() to return NULL even when db_column_is_null() returns false. We need to short circuit in this case. Detected by UBSan: db/bindings.c:479:12: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here #0 0x95f117 in db_col_arr_ db/bindings.c:479:2 #1 0x95ef85 in db_col_channel_type db/bindings.c:459:32 #2 0x852c03 in wallet_stmt2channel wallet/wallet.c:1483:9 #3 0x81f396 in wallet_channels_load_active wallet/wallet.c:1749:23 #4 0x81f03d in wallet_init_channels wallet/wallet.c:1765:9 ElementsProject#5 0x72f1f9 in load_channels_from_wallet lightningd/peer_control.c:2257:7 ElementsProject#6 0x672856 in main lightningd/lightningd.c:1121:25

Fixes nullability errors detected by UBSan: wire/fromwire.c:173:46: runtime error: null pointer passed as argument 1, which is declared to never be null external/libwally-core/src/secp256k1/include/secp256k1.h:432:3: note: nonnull attribute specified here #0 0x65214a in fromwire_secp256k1_ecdsa_signature wire/fromwire.c:173:6 #1 0x659500 in printwire_secp256k1_ecdsa_signature devtools/print_wire.c:331:1 #2 0x646ba2 in printwire_channel_update wire/peer_printgen.c:1900:7 #3 0x637182 in printpeer_wire_message wire/peer_printgen.c:128:11 #4 0x65a097 in main devtools/decodemsg.c:85:10

The function is tiny and was only used in one location. And that one location was leaking memory. Detected by ASan: ==2637667==ERROR: LeakSanitizer: detected memory leaks Direct leak of 7 byte(s) in 1 object(s) allocated from: #0 0x4cd758 in __interceptor_strdup #1 0x64c70c in json_stream_log_suppress_for_cmd lightning/lightningd/jsonrpc.c:597:31 #2 0x68a630 in json_getlog lightning/lightningd/log.c:974:2 ... SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).

It is possible for db_column_bytes() to return 0 and for db_column_blob() to return NULL even when db_column_is_null() returns false. We need to short circuit in this case. Detected by UBSan: db/bindings.c:479:12: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here #0 0x95f117 in db_col_arr_ db/bindings.c:479:2 #1 0x95ef85 in db_col_channel_type db/bindings.c:459:32 #2 0x852c03 in wallet_stmt2channel wallet/wallet.c:1483:9 #3 0x81f396 in wallet_channels_load_active wallet/wallet.c:1749:23 #4 0x81f03d in wallet_init_channels wallet/wallet.c:1765:9 #5 0x72f1f9 in load_channels_from_wallet lightningd/peer_control.c:2257:7 #6 0x672856 in main lightningd/lightningd.c:1121:25

Fixes nullability errors detected by UBSan: wire/fromwire.c:173:46: runtime error: null pointer passed as argument 1, which is declared to never be null external/libwally-core/src/secp256k1/include/secp256k1.h:432:3: note: nonnull attribute specified here #0 0x65214a in fromwire_secp256k1_ecdsa_signature wire/fromwire.c:173:6 #1 0x659500 in printwire_secp256k1_ecdsa_signature devtools/print_wire.c:331:1 #2 0x646ba2 in printwire_channel_update wire/peer_printgen.c:1900:7 #3 0x637182 in printpeer_wire_message wire/peer_printgen.c:128:11 #4 0x65a097 in main devtools/decodemsg.c:85:10

… ctx by values, doubts about waitpid() and parent process.

'closing_signed' and 'closing_complete' are channel closing negotiation messages defined in BOLT ElementsProject#2. While `closing_signed` has a wire fuzz test, `closing_complete` does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

'closing_signed' and 'closing_complete' are channel closing negotiation messages defined in BOLT ElementsProject#2. While 'closing_signed' has a wire fuzz test, 'closing_complete' does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

Changelog-Added: 'closing_signed' and 'closing_complete' are channel closing negotiation messages defined in BOLT ElementsProject#2. While 'closing_signed' has a wire fuzz test, 'closing_complete' does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

Changelog-None: 'closing_signed' and 'closing_complete' are channel closing negotiation messages defined in BOLT ElementsProject#2. While 'closing_signed' has a wire fuzz test, 'closing_complete' does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

Changelog-None: 'closing_signed' and 'closing_sig' are channel closing negotiation messages defined in BOLT ElementsProject#2. While 'closing_signed' has a wire fuzz test, 'closing_sig' does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

Changelog-None: 'closing_signed' and 'closing_complete' are channel closing negotiation messages defined in BOLT ElementsProject#2. While 'closing_signed' has a wire fuzz test, 'closing_complete' does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

Changelog-None: 'closing_signed' and 'closing_sig' are channel closing negotiation messages defined in BOLT ElementsProject#2. While 'closing_signed' has a wire fuzz test, 'closing_sig' does not. Add a test to perform a round-trip encoding check (towire -> fromwire) similar to the other wire fuzzers.

We are supposed to allocate of the ctx we're passed, not tmpctx. Doesn't matter for now, because we don't use this result with anything which outlives tmpctx, but we're going to: ``` ==47574==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040005a8f38 at pc 0x55d3c584d252 bp 0x7ffddfb1b090 sp 0x7ffddfb1b088 READ of size 8 at 0x6040005a8f38 thread T0 #0 0x55d3c584d251 in json_add_closed_channel /home/runner/work/lightning/lightning/lightningd/closed_channel.c:27:3 #1 0x55d3c584ca5a in json_listclosedchannels /home/runner/work/lightning/lightning/lightningd/closed_channel.c:118:3 #2 0x55d3c58c0cbe in command_exec /home/runner/work/lightning/lightning/lightningd/jsonrpc.c:808:8 ``` Signed-off-by: Rusty Russell <[email protected]>

fixed typos in pdf

a97d390

rustyrussell merged commit a97d390 into ElementsProject:master Aug 19, 2015

rustyrussell added a commit that referenced this pull request Apr 12, 2016

protocol: move ack out of header into specific packets.

0f35441

This reflects the BOLT #1/#2 protocol change, as suggeted by Pierre. Signed-off-by: Rusty Russell <[email protected]>

rustyrussell added a commit that referenced this pull request Oct 17, 2016

init: add comments as per updated BOLT #2.

5797dc6

To match 8ad8041990dc "wire-protocol: rename reconnect_pkt to init_pkt, add feature bits." Signed-off-by: Rusty Russell <[email protected]>

rustyrussell added a commit that referenced this pull request Jan 4, 2017

wire/gen_peer_wire_csv: update to latest spec #2

bdc4972

828eda6, in particular, it has the new address format for node_announcement. Signed-off-by: Rusty Russell <[email protected]>

rustyrussell added a commit that referenced this pull request Mar 28, 2017

lightningd/channel: quote BOLT #2 for checking expiry.

d332a97

lightning/bolts#138: BOLT 2: htlc-cltv must be in blocks. Signed-off-by: Rusty Russell <[email protected]>

rustyrussell added a commit that referenced this pull request Mar 28, 2017

lightningd/channel: quote BOLT #2 for checking expiry.

fcf8029

lightning/bolts#138: BOLT 2: htlc-cltv must be in blocks. Signed-off-by: Rusty Russell <[email protected]>

rustyrussell added a commit that referenced this pull request Apr 1, 2017

lightningd/channel: quote BOLT #2 for checking expiry.

88ff1d0

lightning/bolts#138: BOLT 2: htlc-cltv must be in blocks. Signed-off-by: Rusty Russell <[email protected]>

rustyrussell added a commit that referenced this pull request Apr 1, 2017

lightningd/channel: quote BOLT #2 for checking expiry.

3a9c559

lightning/bolts#138: BOLT 2: htlc-cltv must be in blocks. Signed-off-by: Rusty Russell <[email protected]>

instagibbs mentioned this pull request Jan 9, 2018

lightningd hanging after calling getpeers #541

Closed

sfmcnally mentioned this pull request Feb 9, 2018

'dev-forget-channel' on channel in state ONCHAIND_THEIR_UNILATERAL crashes lightningd #946

Closed

rustyrussell mentioned this pull request Feb 22, 2018

Funding channel causes crash due to "UNIQUE constraint failed: peers.node_id" #1029

Closed

bitonic-cjp mentioned this pull request Feb 23, 2018

CHANNELD_AWAITING_LOCKIN after 65+ confirms #1063

Closed

SimonVrouwe mentioned this pull request Mar 3, 2018

consistent FATAL SIGNAL 11 RECEIVED + segfault after broadcasting revoked commit-tx #1160

Closed

arowser mentioned this pull request Mar 23, 2018

Disable backtrace on mac #1258

Merged

robtex mentioned this pull request Mar 25, 2018

lightning_channeld: Writing out status 65520: Broken pipe #1269

Closed

kandycoder mentioned this pull request Aug 24, 2021

Feature suggestion: Better inspection of closed channels #4734

Closed

rustyrussell mentioned this pull request Oct 25, 2023

implementation HTLC Endorsement to Mitigate Channel Jamming #6714

Closed

niftynei mentioned this pull request May 8, 2024

splice: Script for complex splices #6980

Merged

s373nZ added a commit to s373nZ/lightning that referenced this pull request Sep 23, 2024

bcli: Prototype ElementsProject#2: plugin_timer() after pipecmd, pass…

5ad6a19

… ctx by values, doubts about waitpid() and parent process.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fixed typos in pdf #2

fixed typos in pdf #2

Uh oh!

pm47 commented Aug 18, 2015

Uh oh!

rustyrussell commented Aug 19, 2015

Uh oh!

Uh oh!

fixed typos in pdf #2

fixed typos in pdf #2

Uh oh!

Conversation

pm47 commented Aug 18, 2015

Uh oh!

rustyrussell commented Aug 19, 2015

Uh oh!

Uh oh!