profile
viewpoint

ElementsProject/lightning 1778

c-lightning — a Lightning Network implementation in C

SimonVrouwe/lightning 1

c-lightning — a Lightning Network implementation in C

SimonVrouwe/bips 0

Bitcoin Improvement Proposals

SimonVrouwe/bitcoin 0

Bitcoin Core integration/staging tree

SimonVrouwe/lightning-rfc 0

Lightning Network Specifications

SimonVrouwe/lightning_notes 0

just some random notes about lightning network

SimonVrouwe/pgp-key 0

my pgp key

PR opened ElementsProject/lightning

Reviewers
Weekly cleanups -- release edition

Mostly some cosmetic changes to the release tools, but they address some pitfalls that caused my to restart the release process a couple of times (0.9.3 vs v0.9.3 in the changelog for example).

+50 -8

0 comment

6 changed files

pr created time in 8 hours

issue commentElementsProject/lightning

Upgrading installed C-Lightning package breaks running instance in potentially dangerous ways

hardlink (or if that fails, copy) the subdaemons and builtin plugins to a subdaemons/ directory in the $LIGHTNINGDIR.

That would fail if $LIGHTNINGDIR is mounted noexec. Atypical but not unreasonable.

whitslack

comment created time in a day

issue commentElementsProject/lightning

Upgrading installed C-Lightning package breaks running instance in potentially dangerous ways

An idea would be for lightningd to hardlink (or if that fails, copy) the subdaemons and builtin plugins to a subdaemons/ directory in the $LIGHTNINGDIR. That way we have a sample of the plugins at startup. When starting, we erase the entire directory at once.

We could also have --version of each subdaemon and builtin plugin include a sha256sum of the concatenation of (or maybe a merkle directory tree of) their source code (git log -1 is not enough in a development env since we could have a modified version locally running) just to ensure that the expected versions are the same, in case of a race condition where an update is in a halfway state when the daemon is restarted.

whitslack

comment created time in a day

issue openedElementsProject/lightning

Upgrading installed C-Lightning package breaks running instance in potentially dangerous ways

While you all are considering a fundamental redesign of C-Lightning's daemon organization, I would request that you please consider what happens when a C-Lightning installation is upgraded on disk while an instance of that installation is running.

It is customary in the Linux world for the system package manager to upgrade installed packages simply by replacing executable files on disk with newer versions, irrespective of whether those executables may currently be running. This is fine under POSIX semantics, as the mapped VMAs of any running processes will maintain references to the inodes of the replaced versions, preventing them from being deallocated on disk, even after their link counts drop to zero, until no more VMAs reference them. Thus, running daemons will continue running the old code until they are subsequently restarted. While this works just fine for most daemons, it fails spectacularly for C-Lightning, which spawns subdaemons at arbitrary times by execveing their executable images on disk without regard for whether those images are of the same (or compatible) version as their parent daemons.

One potential solution would be to use a "zygote" process in the manner of Chromium/Chrome. A zygote process starts once upon startup of the top-level process and has the sole purpose of forking child processes, which in turn subsequently differentiate into whatever subdaemon specialization is needed, notably without execveing anything on disk. However, this pattern may not be well-suited to C-Lightning, given its capability for dynamically loading and unloading plugins.

Another possibility would be for the top-level lightningd process to open every critical subdaemon executable file at startup, and then when spawning a subdaemon, the appropriate /proc/self/fd/<n> symlink should be execved rather than /usr/libexec/c-lightning/<whatever>. This would have the effect of executing whatever version of the subdaemon was installed at the time when lightningd was launched, irrespective of whatever version of the subdaemon might be installed at the time of spawning. The downsides are: this only works on Linux, and the process name of the subdaemon will then be some opaque number, though I think there may be some tricks to rewrite that for the benefit of ps, top, and friends. Spawning non-critical plugins could still be done by execveing whatever happens to be on disk at the time, with the understanding that the version of the plugin on disk may speak a different protocol than the parent process.

One last potential solution (really more of a punt) would be for subdaemons simply to handshake on a protocol version upon spawning. This wouldn't allow continued operation in the event of a version mismatch, but it would at least protect against accidental catastrophe due to internal protocol changes.

Impetus for this request? I have personally experienced my C-Lightning node dying upon attempting to spawn a new subdaemon after I had upgraded the installed package on disk. Note that this does not happen immediately upon upgrading the package on disk but will happen at some unpredictable time afterward. To mitigate this problem, I have hacked up the Gentoo ebuild for C-Lightning so that it cowardly refuses to upgrade an installation of C-Lightning if it notices that an instance may be running, but this is gross and runs contrary to the expectations of users, who expect that they can upgrade packages on disk and then restart their services afterward to switch to the new versions.

created time in a day

issue commentElementsProject/lightning

rebalancing (circular payment), crash c-lightning

@PsySc0rpi0n: You might want to use the rebalance plugin rather than attempting to implement rebalancing yourself manually.

Yes, I will try it maybe today. However I only want to balance this one channel, so I have to use the other option that gives me more control instead of rebalance all channels.

PsySc0rpi0n

comment created time in a day

issue commentElementsProject/lightning

Pay plugin is crashing C-Lightning

So now, as of v0.9.3, neither pay nor legacypay work. Thus, I am no longer able to send payments out from my C-Lightning node at all. :sob:

  • The pay command crashes the pay plugin, which causes lightningd to abort. (Sorry to everyone who was actively forwarding an HTLC through my node at that moment!)
  • The legacypay command no longer works, always returning error code 206 with message similar to "Route wanted fee of 1500153500msat". (That's a fee of 0.0102% of my payment, which should be allowed since I specified maxfeepercent=0.1.)
saubyk

comment created time in a day

issue commentElementsProject/lightning

option to skip OUR_DELAYED_RETURN_TO_WALLET

Agreed! I have never understood the need for sweeping the delayed output into a P2WPKH address if it is known that no newer channel state exists than that with which the channel was unilaterally closed (and so no justice transaction can ever claim the funds) — and if that isn't known, then the node should not be risking a unilateral closure in the first place, so I think we can say that anytime a node initiates a unilateral closure, it is reasonable to assume that no newer channel state exists. Under such assumption, why then does the delayed output of the unilateral closure need to be swept at all? Couldn't we simply place that output in the wallet to allow it to be spent in due course of node operations (i.e., for an explicit withdrawal or future channel opening)?

gallizoltan

comment created time in a day

issue commentElementsProject/lightning

rebalancing (circular payment), crash c-lightning

@PsySc0rpi0n: You might want to use the rebalance plugin rather than attempting to implement rebalancing yourself manually.

PsySc0rpi0n

comment created time in a day

pull request commentElementsProject/lightning

Drive by fixes

ACK https://github.com/ElementsProject/lightning/pull/4344/commits/89a46d028e56b4bbb78d7c53c8d9c0b4f2de1154

niftynei

comment created time in 2 days

issue commentElementsProject/lightning

rebalancing (circular payment), crash c-lightning

@cdecker, so for now, it will not be possible to perform the rebalancing using this circular payment technique for now, right?

PsySc0rpi0n

comment created time in 2 days

issue commentElementsProject/lightning

rebalancing (creating an invoice and paying it with the same node), crash c-lightning

Yes, a 0-hop route will end up failing here:

https://github.com/ElementsProject/lightning/blob/04f139f092324a2cbfbdf2c17b6cfd0cd687834d/plugins/libplugin-pay.c#L419

PsySc0rpi0n

comment created time in 2 days

issue commentElementsProject/lightning

rebalancing (creating an invoice and paying it with the same node), crash c-lightning

Strictly speaking we support paying to ourselves, we just won't create a circular route for it in pay / gossipd, which I think leads to a 0-hop route, which then crashes in the pay plugin. I'll take a look at it.

PsySc0rpi0n

comment created time in 2 days

issue commentElementsProject/lightning

rebalancing (creating an invoice and paying it with the same node), crash c-lightning

@ZmnSCPxj, @darosior told me in IRC that self-payments are supported... Do we or do we not support them? I'm confused.

PsySc0rpi0n

comment created time in 2 days

issue commentElementsProject/lightning

rebalancing (creating an invoice and paying it with the same node), crash c-lightning

Below is the decodepay of your invoice:

{
   "currency": "bc",
   "created_at": 1611185549,
   "expiry": 604800,
   "payee": "03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91",
   "msatoshi": 985000000,
   "amount_msat": "985000000msat",
   "description": "Rebalancing_boltx_cahnnel",
   "min_final_cltv_expiry": 18,
   "payment_secret": "6abe4211afc8145f7bf303d3452898b5f0a6f326e982208904c033673809f351",
   "features": "028200",
   "routes": [
      [
         {
            "pubkey": "026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2",
            "short_channel_id": "665969x1380x0",
            "fee_base_msat": 1000,
            "fee_proportional_millionths": 1,
            "cltv_expiry_delta": 40
         }
      ]
   ],
   "payment_hash": "2e3678e78eccc3be3d5061a8bdc21b503a28f8faa89bff8df0da026adfbfca8f",
   "signature": "3045022100a745e28059fbbff9ed764d7e70a0e6b5f3f09b72d08abc042d50d8f21106a3cf02206f53dd1c8f55bfa328c90dd48c720c92009ffd9032ea9ff855aa83f4bfc543eb"
}

So there is a routehint from 026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2 to your node, which makes sense. Not sure what is causing the negative fees though.

PsySc0rpi0n

comment created time in 2 days

issue commentElementsProject/lightning

rebalancing (creating an invoice and paying it with the same node), crash c-lightning

Note that we do not actually support self-paying via pay... previous versions did an early-out, probably we need to reimplement that. Instead, consider something from plugins or look into CLBOSS for automatic management.

The crashing line is:

https://github.com/ElementsProject/lightning/blob/ff8830876dc2ead010dc4a6453abb7e30ec637ce/plugins/libplugin-pay.c#L426

Which occurs because we are apparently generating a route that gives negative fees:

https://github.com/ElementsProject/lightning/blob/ff8830876dc2ead010dc4a6453abb7e30ec637ce/plugins/libplugin-pay.c#L417-L427

PsySc0rpi0n

comment created time in 2 days

issue openedElementsProject/lightning

rebalancing (creating an invoice and paying it with the same node), crash c-lightning

Issue and Steps to Reproduce

<!-- Describe your issue and tell us how to reproduce it (include any useful information). -->

I have one channel that needs to be rebalanced. The balance is now around 15% / 85% (Out/In) and the total capacity is around 1.5 million sats. 1.4 million sats is now inbound capacity. So I tried to create an invoice with 985k sats (because I have another channel with 100% Incoming capacity of 1 million sats, minus reserves and fees) to try to send them through this channel and the logs says the follwoing:

2021-01-20T23:33:14.730Z DEBUG gossipd: Trying to find a route from (me) to 03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91 for 1000msat 2021-01-20T23:33:14.730Z INFO gossipd: find_route: this is 03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91, refusing to create empty route 2021-01-20T23:33:14.730Z DEBUG gossipd: REPLY WIRE_GOSSIPD_GETROUTE_REPLY with 0 fds 2021-01-20T23:33:14.731Z DEBUG plugin-pay: cmd 36918 partid 0: Not using a routehint 2021-01-20T23:33:14.731Z DEBUG plugin-pay: cmd 36918 partid 0: The destination is not directly reachable excluding attempts without routehints 2021-01-20T23:33:14.731Z DEBUG gossipd: REPLY WIRE_GOSSIPD_GETCHANNELS_REPLY with 0 fds 2021-01-20T23:33:14.732Z INFO plugin-pay: cmd 36918 partid 0: Initial limit on max HTLCs: 90, Destination 03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91 has 6 channels, assuming 15 HTLCs per channel 2021-01-20T23:33:14.732Z INFO plugin-pay: cmd 36918 partid 1: Split into 6 sub-payments due to initial size (985000000msat > 160000000msat): new partid 2, new partid 3, new partid 4, new partid 5, new partid 6, new partid 7 2021-01-20T23:33:14.733Z DEBUG gossipd: REPLY WIRE_GOSSIPD_GETCHANNELS_REPLY with 0 fds pay: channel_update 576683x1919x0 ignored: fee 7/6000000 cltv 4 too large pay: channel_update 577477x1902x1 ignored: fee 7/6000000 cltv 4 too large pay: channel_update 577480x1296x0 ignored: fee 7/6000000 cltv 4 too large pay: channel_update 577480x1297x0 ignored: fee 7/6000000 cltv 4 too large pay: channel_update 577555x1983x0 ignored: fee 7/6000000 cltv 4 too large pay: channel_update 586709x610x0 ignored: fee 100000/100000000 cltv 144 too large pay: channel_update 660870x1328x0 ignored: fee 1000/1500000 cltv 50 too large pay: channel_update 665892x421x0 ignored: fee 1000/10000000 cltv 40 too large pay: channel_update 666486x2306x0 ignored: fee 1000/10000000 cltv 40 too large pay: channel_update 577590x1455x0 ignored: fee 7/6000000 cltv 4 too large pay: channel_update 666853x820x0 ignored: fee 1000/10000000 cltv 40 too large pay: channel_update 665401x1883x1 ignored: fee 1000/10000000 cltv 40 too large pay: channel_update 666900x1026x1 ignored: fee 1000/10000000 cltv 40 too large pay: channel_update 666529x884x0 ignored: fee 1000/10000000 cltv 40 too large pay: FATAL SIGNAL 6 (version v0.9.2-67-gff88308) 0x55d40d2222c7 send_backtrace common/daemon.c:38 0x55d40d22236d crashdump common/daemon.c:51 0x7fd88dcb483f ??? ???:0 0x7fd88dcb47bb ??? ???:0 0x7fd88dc9f534 ??? ???:0 0x55d40d20a4e8 payment_route_fee plugins/libplugin-pay.c:426 0x55d40d20b5cb payment_getroute plugins/libplugin-pay.c:807 0x55d40d20e730 payment_continue plugins/libplugin-pay.c:1897 0x55d40d212674 adaptive_splitter_cb plugins/libplugin-pay.c:3461 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d20eb81 retry_step_cb plugins/libplugin-pay.c:2039 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d2116dd waitblockheight_cb plugins/libplugin-pay.c:3031 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d211b1f presplit_cb plugins/libplugin-pay.c:3198 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d2127f8 payee_incoming_limit_step_cb plugins/libplugin-pay.c:3556 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d2103d0 routehint_step_cb plugins/libplugin-pay.c:2554 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d211084 shadow_route_cb plugins/libplugin-pay.c:2878 0x55d40d20e6e6 payment_continue plugins/libplugin-pay.c:1889 0x55d40d2110ed direct_pay_override plugins/libplugin-pay.c:2899 0x55d40d21146d direct_pay_listpeers plugins/libplugin-pay.c:2963 0x55d40d205117 handle_rpc_reply plugins/libplugin.c:560 0x55d40d205a80 rpc_read_response_one plugins/libplugin.c:707 0x55d40d205b9d rpc_conn_read_response plugins/libplugin.c:727 0x55d40d23a0dc next_plan ccan/ccan/io/io.c:59 0x55d40d23ac59 do_plan ccan/ccan/io/io.c:407 0x55d40d23ac97 io_ready ccan/ccan/io/io.c:417 0x55d40d23ce5d io_loop ccan/ccan/io/poll.c:445 0x55d40d20811c plugin_main plugins/libplugin.c:1403 0x55d40d203c8c main plugins/pay.c:2103 0x7fd88dca109a ??? ???:0 0x55d40d1fcd99 ??? ???:0 0xffffffffffffffff ??? ???:0 pay: FATAL SIGNAL 11 (version v0.9.2-67-gff88308) 0x55d40d2222c7 send_backtrace common/daemon.c:38 0x55d40d22236d crashdump common/daemon.c:51 0x7fd88dcb483f ??? ???:0 0x0 ??? ???:0 2021-01-20T23:33:14.899Z INFO plugin-pay: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.899Z BROKEN plugin-pay: Plugin marked as important, shutting down lightningd! 2021-01-20T23:33:14.900Z DEBUG connectd: Shutting down 2021-01-20T23:33:14.914Z DEBUG 02ab6d60e2e46e1af91c671234c914f99a3826c1c7e3a358cc46a0bcf37663adb2-channeld-chan#10: Status closed, but not exited. Killing 2021-01-20T23:33:14.915Z DEBUG 03e691f81f08c56fa876cc4ef5c9e8b727bd682cf35605be25d48607a802526053-channeld-chan#18: Status closed, but not exited. Killing 2021-01-20T23:33:14.916Z DEBUG 026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2-channeld-chan#37: Status closed, but not exited. Killing 2021-01-20T23:33:14.916Z DEBUG 0239e4dc85543cd84b712850072dc5e1bf0190c44b64dbe822581013f849a794a4-channeld-chan#46: Status closed, but not exited. Killing 2021-01-20T23:33:14.917Z DEBUG 03691d4dc8789455bf9241b9f808aaca92099851b1db92f4031e2ae997f3eea711-channeld-chan#47: Status closed, but not exited. Killing 2021-01-20T23:33:14.918Z DEBUG 03e9e5a2ae70e42d012c2cecc5a2662630b97efeb13c4080168e19f23a518051c5-openingd-chan#48: Status closed, but not exited. Killing 2021-01-20T23:33:14.918Z DEBUG 02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b-openingd-chan#50: Status closed, but not exited. Killing 2021-01-20T23:33:14.919Z DEBUG 03968d7f8825d1e34e7d38993617cb6a861f7bcf78e6fe1b1043272350960d1f51-channeld-chan#58: Status closed, but not exited. Killing 2021-01-20T23:33:14.920Z DEBUG 032cc4541b25e86e39a7d450a979c1a9adbe2878df3a93fcb59c96c700bfe26aa3-openingd-chan#64: Status closed, but not exited. Killing 2021-01-20T23:33:14.920Z DEBUG 03295d2e292565743a40bd44da227a820f8730877bc3dfadebade8785bcf355258-openingd-chan#65: Status closed, but not exited. Killing 2021-01-20T23:33:14.921Z DEBUG gossipd: Shutting down 2021-01-20T23:33:14.937Z DEBUG hsmd: Shutting down 2021-01-20T23:33:14.937Z INFO plugin-autoclean: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.937Z INFO plugin-bcli: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.937Z INFO plugin-keysend: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.937Z INFO plugin-txprepare: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.937Z INFO plugin-spenderp: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.937Z INFO plugin-backup.py: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.938Z INFO plugin-summary.py: Killing plugin: Plugin exited before completing handshake. 2021-01-20T23:33:14.938Z INFO plugin-backup.py: Killing plugin: Plugin exited before completing handshake.

getinfo output

{ "id": "03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91", "alias": "CryptoAnarchMoV", "color": "03fef7", "num_peers": 6, "num_pending_channels": 0, "num_active_channels": 6, "num_inactive_channels": 0, "address": [ { "type": "torv3", "address": "isvcxqviqbhrzpzpcmeh6u5ve42pvcjdukckec4mhdcwhnkff6qexdqd.onion", "port": 9735 } ], "binding": [ { "type": "ipv4", "address": "127.0.0.1", "port": 9735 } ], "version": "v0.9.2-67-gff88308", "blockheight": 666962, "network": "bitcoin", "msatoshi_fees_collected": 25005, "fees_collected_msat": "25005msat", "lightning-dir": "/home/psysc0rpi0n/.lightning/bitcoin" }

Channel needing rebalancing:

{ "channels": [ { "source": "026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2", "destination": "03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91", "short_channel_id": "665969x1380x0", "public": true, "satoshis": 1575817, "amount_msat": "1575817000msat", "message_flags": 1, "channel_flags": 0, "active": true, "last_update": 1610884769, "base_fee_millisatoshi": 1000, "fee_per_millionth": 1, "delay": 40, "htlc_minimum_msat": "1000msat", "htlc_maximum_msat": "1575817000msat", "features": "" }, { "source": "03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91", "destination": "026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2", "short_channel_id": "665969x1380x0", "public": true, "satoshis": 1575817, "amount_msat": "1575817000msat", "message_flags": 1, "channel_flags": 1, "active": true, "last_update": 1611098741, "base_fee_millisatoshi": 1000, "fee_per_millionth": 250, "delay": 34, "htlc_minimum_msat": "1msat", "htlc_maximum_msat": "1560059000msat", "features": "" } ] }

Channel I was trying to use to send the funds for the rebalancing:

{ "channels": [ { "source": "03968d7f8825d1e34e7d38993617cb6a861f7bcf78e6fe1b1043272350960d1f51", "destination": "03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91", "short_channel_id": "666671x1102x0", "public": true, "satoshis": 1000000, "amount_msat": "1000000000msat", "message_flags": 1, "channel_flags": 0, "active": true, "last_update": 1611014880, "base_fee_millisatoshi": 1000, "fee_per_millionth": 1, "delay": 40, "htlc_minimum_msat": "1000msat", "htlc_maximum_msat": "1000000000msat", "features": "" }, { "source": "03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91", "destination": "03968d7f8825d1e34e7d38993617cb6a861f7bcf78e6fe1b1043272350960d1f51", "short_channel_id": "666671x1102x0", "public": true, "satoshis": 1000000, "amount_msat": "1000000000msat", "message_flags": 1, "channel_flags": 1, "active": true, "last_update": 1611098672, "base_fee_millisatoshi": 1000, "fee_per_millionth": 250, "delay": 34, "htlc_minimum_msat": "1msat", "htlc_maximum_msat": "990000000msat", "features": "" } ] }

The invoice I created:

$ lightning-cli invoice 985000000msat "revalance-boltz-01" "Rebalancing_boltx_cahnnel" { "payment_hash": "2e3678e78eccc3be3d5061a8bdc21b503a28f8faa89bff8df0da026adfbfca8f", "expires_at": 1611790349, "bolt11": "lnbc9850u1psq30vdpp59cm83euwenpmu02svx5tmssm2qaz37864zdllr0smgpx4hale28sdpg2fjkyctvv9hxx6twva0kymmvw3u97cmpdphxuetvxqyjw5qcqpjsp5d2lyyyd0eq2977lnq0f522yckhc2duexaxpzpzgycqekwwqf7dgsrzjqfsktpgyjffp7jkg40vmmqygzg6yd5fx7eyv5d0xp7ypwlwpf88tyz3fwyqq2eqqqqqqqqlgqqqqqqgq9q9qy9qsq5az79qzelwllnmtkf4l8pg8xkhelpxmj6z9tcppd2rv0yygx508k757arj84t0ar9rysm4yvwgxfyqyllkgr965llp264ql5hlz586cph60xlx" }

created time in 2 days

PR opened ElementsProject/lightning

Drive by fixes

Few small fixes I found while re-doing the dual-funding code for RBF

+23 -23

0 comment

5 changed files

pr created time in 2 days

issue openedElementsProject/lightning

Crash at init exchange (on EXPERIMENTAL=1 rc1 with rusty's node)

I think @rustyrussell 's has EXPERIMENTAL=1 too. That must be related to init's signaling for anchors or offers (didn't dig yet)

2021-01-17T17:12:06.733Z DEBUG   connectd: Now try LN connect out for host ki5uack5xb4gicfnpfavzdibojfu3qvwtlg3ca7eyjxik7tgwfxummqd.onion
2021-01-17T17:12:06.733Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-connectd: Connected out, starting crypto
2021-01-17T17:12:07.683Z DEBUG   hsmd: Client: Received message 1 from client
2021-01-17T17:12:07.684Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-connectd: Connect OUT
2021-01-17T17:12:07.684Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-connectd: peer_out WIRE_INIT
2021-01-17T17:12:08.445Z DEBUG   02a04446caa81636d60d63b066f2814cbd3a6b5c258e3172cbdded7a16e2cfff4c-gossipd: Received channel_update for channel 597745x2428x1/1 now DISABLED
2021-01-17T17:12:09.083Z DEBUG   031015a7839468a3c266d662d5bb21ea4cea24226936e2864a7ca4f2c3939836e0-gossipd: Received channel_update for channel 625548x1197x1/1 now DISABLED
2021-01-17T17:12:09.094Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-gossipd: seeker: disabling gossip
2021-01-17T17:12:09.129Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-connectd: peer_in WIRE_INIT
2021-01-17T17:12:09.129Z **BROKEN** connectd: FATAL SIGNAL 11 (version v0.9.2)
2021-01-17T17:12:09.130Z **BROKEN** connectd: backtrace: common/daemon.c:43 (send_backtrace) 0x55a146d5c7cb
2021-01-17T17:12:09.130Z **BROKEN** connectd: backtrace: common/daemon.c:51 (crashdump) 0x55a146d5c81a
2021-01-17T17:12:09.130Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-chan#5497: Peer has reconnected, state CHANNELD_NORMAL
2021-01-17T17:12:09.135Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-channeld-chan#5497: pid 278110, msgfd 67
2021-01-17T17:12:09.135Z DEBUG   024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-chan#5497: Already have funding locked in (and ready to announce)
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x7f55ed6d5cff
2021-01-17T17:12:09.137Z DEBUG   hsmd: Client: Received message 9 from client
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x7f55ed73002a
2021-01-17T17:12:09.137Z DEBUG   hsmd: new_client: 5497
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: connectd/connectd.c:698 (destroy_io_conn) 0x55a146d517b8
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: ccan/ccan/io/poll.c:244 (destroy_conn) 0x55a146d9a491
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: ccan/ccan/io/poll.c:264 (cleanup_conn_without_close) 0x55a146d9a529
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:463 (io_close_taken_fd) 0x55a146d98b9e
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: connectd/connectd.c:511 (peer_connected) 0x55a146d50f75
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: connectd/peer_exchange_initmsg.c:94 (peer_init_received) 0x55a146d54a9f
2021-01-17T17:12:09.137Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:59 (next_plan) 0x55a146d97e22
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:407 (do_plan) 0x55a146d989a9
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:417 (io_ready) 0x55a146d989e7
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: ccan/ccan/io/poll.c:445 (io_loop) 0x55a146d9aba6
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: connectd/connectd.c:1703 (main) 0x55a146d54765
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x7f55ed6c0d09
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x55a146d4de89
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0xffffffffffffffff
2021-01-17T17:12:09.138Z **BROKEN** connectd: FATAL SIGNAL (version v0.9.2)
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: common/daemon.c:43 (send_backtrace) 0x55a146d5c7cb
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: common/status.c:206 (status_failed) 0x55a146d66c5b
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: common/subdaemon.c:25 (status_backtrace_exit) 0x55a146d66eab
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: common/daemon.c:54 (crashdump) 0x55a146d5c823
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x7f55ed6d5cff
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x7f55ed73002a
2021-01-17T17:12:09.138Z **BROKEN** connectd: backtrace: connectd/connectd.c:698 (destroy_io_conn) 0x55a146d517b8
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/poll.c:244 (destroy_conn) 0x55a146d9a491
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/poll.c:264 (cleanup_conn_without_close) 0x55a146d9a529
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:463 (io_close_taken_fd) 0x55a146d98b9e
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: connectd/connectd.c:511 (peer_connected) 0x55a146d50f75
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: connectd/peer_exchange_initmsg.c:94 (peer_init_received) 0x55a146d54a9f
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:59 (next_plan) 0x55a146d97e22
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:407 (do_plan) 0x55a146d989a9
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/io.c:417 (io_ready) 0x55a146d989e7
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: ccan/ccan/io/poll.c:445 (io_loop) 0x55a146d9aba6
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: connectd/connectd.c:1703 (main) 0x55a146d54765
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x7f55ed6c0d09
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0x55a146d4de89
2021-01-17T17:12:09.139Z **BROKEN** connectd: backtrace: (null):0 ((null)) 0xffffffffffffffff
2021-01-17T17:12:09.139Z **BROKEN** connectd: STATUS_FAIL_INTERNAL_ERROR: FATAL SIGNAL

created time in 2 days

push eventElementsProject/lightning

ZmnSCPxj jxPCSnmZ

commit sha dc83862fc20eae888856035e478e07bd74f4f7fc

doc/PLUGINS.md: Fix typo.

view details

YOSHIDA Masanori

commit sha ff2535651ec3bac23f053f677ec81d989887f97a

lightningd: remove unused pid_fd member in struct lightningd Signed-off-by: YOSHIDA Masanori <masanori.yoshida@gmail.com> Changelog-None

view details

niftynei

commit sha e4cd5eac28913e29711ae735f9da1127dde94909

htlc.h: move NUM_SIDES to define, not enum member

view details

ZmnSCPxj jxPCSnmZ

commit sha ff090ecfe62fe39ba4b69e5e30dd9b840a9ed8a1

doc/TOR.md: Add missing instructions to add user to Tor group. Changelog-None Fixes: #4208

view details

niftynei

commit sha 78d32b12d0afe9f73cf5b7b8fc78278608286960

nit,df test plugin: change up how feerate is formatted Suggested-by: @cdecker

view details

niftynei

commit sha 5b6b012af9d0a2b1ca39d1bb190944a4a3111308

mfc: add happy path-way for v2 in multifundchannel Tested and works with both sides funding! Yay. Doesn't do any amount of reasonable cleanup or handling of errors.

view details

niftynei

commit sha e0c4865eeaa2aa6d84f7b73b0410eb3e74de9f58

mfc: add a 'fail_destination' helper Caches state at which we failed + sets error

view details

niftynei

commit sha 991ae65e9e543ce5841c8b8587a58601016d8c51

mfc-df: track destination's openchannel version Plus method to help count/tabulate how many of each we've got around still.

view details

niftynei

commit sha a31b0787211f5264760065f0ffbe156a60ad20e2

mfc: consolidate to a single FAILED state

view details

niftynei

commit sha 95de8b11743c140f375b882b82035675220e76ca

mfc-df: have both paths use redo_multifundchannel Still need handling of failure for v2 opens (no rpc exists?!)

view details

niftynei

commit sha 381658dee6da11d5723042d18e5e4333a1499403

mfc-df: merge openchannel_init/fundchannel_start results These happen simultaneously, and should resolve to the same place when they're finished.

view details

niftynei

commit sha 3d2c0951d57e2bbcd925e4b1e7ef72b8e51c8e48

mfc-df: rework how openchannel_update works, callbacks

view details

niftynei

commit sha c90a19f7396161fde863eae4a7ac4aec46c306f9

mfc-df: only add outputs for v1 outs; go to openchannel_update if v2s We only have output scripts for v1 protocols after the fundchannel_start/openchannel_init round. We need to add them before we get into the openchannel_update rounds, however, so we do that here.

view details

niftynei

commit sha d7c06b5b0e888a30d0b448418bc1473fe1805705

mfc-df: once we've gotten the PSBT finalized, we wait for peer sigs We need our peer's signatures to arrive before we sign/broadcast the funding transaction (but only if there's v2 peers present)

view details

niftynei

commit sha a34425abd162684a81dfa8d022c8fc4d7bc5dda2

mfc-df: after sigs are collected, go sign the psbt

view details

niftynei

commit sha 3e19b6c8f55620f125477e6b855b90a681efd042

mfc-df: after psbt signed, send to openchannel_signed if v2s If there's an v2 destinations, they'll broadcast the tx for us

view details

niftynei

commit sha c6b45e052bfb6dbda362f753bbf0b07207170847

mfc-df: after openchannel_signed is finished, we call finished We done!?

view details

niftynei

commit sha da98a9d0aff2a33d4535bbb8ca251ddb1ea940b5

df-accepter plugin: temporarily dont pass in signpsbt

view details

niftynei

commit sha 405453859c04deedf14df60700eddc425a6eabc4

mfc-df: add 'happy path' tests for the v1+v2 things We can't test disconnects et.al. quite yet because the 'cancel' flow for openchannelv2 still needs to be resolved

view details

niftynei

commit sha 6077eca660132b8747c229c705ffa0e7ce5ff0f7

df: pass back 'close_to' for completed/commitment secured channels When commitments are secured, also return the 'close_to' script if we've got a local_upfront_shutdown_script set.

view details

push time in 2 days

created tagElementsProject/lightning

tagv0.9.3

c-lightning — a Lightning Network implementation in C

created time in 2 days

push eventElementsProject/lightning

Christian Decker

commit sha 015ac37d924e31bb87b8597da9f863e82270657b

release: Update the changelog for v0.9.3

view details

push time in 3 days

push eventElementsProject/lightning

Antoine Poinsot

commit sha 48595674fa78ebeb55035aca4c439bb39385031a

hsmtool: don't streq() on NULL This would cause a segfault on the default network parameter for `dumponchaindescriptors`. Introduced in 1513a2d07e Changelog-Fixed: hsmtool: fix a segfault on `dumponchaindescriptors` without network parameter Signed-off-by: Antoine Poinsot <darosior@protonmail.com>

view details

push time in 3 days

PR merged ElementsProject/lightning

hsmtool: fix a segfault on `dumponchaindescriptors` default network parameter

fixes https://github.com/ElementsProject/lightning/issues/4339

+2 -2

2 comments

1 changed file

darosior

pr closed time in 3 days

issue closedElementsProject/lightning

rc1: hsmtool segfault

The dumponchaindescriptors command segfaults on mainnet if we don't provide a network parameter (bitcoin is the default).

Self-assignment..

closed time in 3 days

darosior

pull request commentElementsProject/lightning

hsmtool: fix a segfault on `dumponchaindescriptors` default network parameter

Simple enough not to require an rc3, so I'll sneak it in :-)

Thanks @darosior for fixing this and @ZmnSCPxj for reviewing.

darosior

comment created time in 3 days

pull request commentElementsProject/lightning

hsmtool: fix a segfault on `dumponchaindescriptors` default network parameter

Well that's a bugfix for 0.9.3 (happened with rc1).

darosior

comment created time in 3 days

pull request commentElementsProject/lightning

add failing test for rpc_command calling another rpc method.

Erk, this is reentrant of course. Not sure the best way to handle this!

fiatjaf

comment created time in 3 days

more