The #328 squash commit (986f30d) was created by soft-resetting the
autoclose branch onto origin/master, but the branch's index still held
a tree from before the #327 merge, so the commit silently reverted
Boss/Mod/JitRebalancer.cpp and tests/boss/test_jitrebalancer.cpp to
their pre-guard state. master and the v0.16.3-rc1 tag therefore lack
the fix for #323 that the CHANGELOG describes. GitHub's up-to-date
check passed because it checks ancestry, not tree content, and CI
passed because the guard's tests were reverted along with the guard.
Restore both files from the post-#327 master tip (5839241); nothing
else has touched them since, and git diff 5839241986f30d confirms
the reversion was limited to these two files.
Restores the fix for #323.
close was issued with unilateraltimeout=180 on a fixed timer,
without regard to the peer's connection state, while one complaint
source (ComplainerByLowConnectRate) selects peers specifically for
a low connect rate. Closing while the peer is offline escalates
to a unilateral force-close after 3 minutes, against exactly the
peers least likely to negotiate a mutual close in time.
Check the peer's channels for a live connection (listpeerchannels
peer_connected) before issuing close, and defer while the peer is
offline. Poll close candidates every 10 minutes rather than once
per solicitation cycle, so a flaky peer's brief online windows are
actually caught. If the peer stays offline for close_patience
(3 days), close anyway and let the short unilateral timeout
escalate; the first-deferred time is persisted in a new
PeerComplaintsDesk_closepending table so restarts do not reset
the patience window. The fees_low gate applies only to that
unilateral path: a mutual close even at high feerates is cheaper
than a unilateral at low feerates, so connected peers are closed
immediately regardless of feerate.
Add tests/boss/test_peercomplaintsdesk_main.cpp covering the close
paths: a connected peer closes immediately; an offline peer defers
and the deferral survives a restart; within patience it holds;
expired patience holds at high fees and closes at low fees;
dropping below the complaint threshold sweeps the deferral;
channel destruction clears it; disabled auto-close closes nothing.
The test drives the module over the bus with a mock CLN on a
socketpair.
Reported by an external security researcher via private disclosure.
Fixes#324
The fee budget check reads out_expenditures, which is only
persisted once a rebalance completes (up to 120 s per run). Each
incoming HTLC spawned an independent rebalance run with no guard,
so concurrent HTLCs to the same underfunded channel each passed
the check against the same stale value, multiplying the intended
25%-of-earnings aggregate cap by the number of concurrent triggers.
Skip HTLC-triggered rebalances for a node that already has one in
flight, mirroring the working guard in EarningsRebalancer. Skipped
HTLCs are released immediately and proceed without JIT rebalancing;
a retry after the in-flight run completes sees both the refilled
channel and the updated budget.
Update the parallel-calls unit test to the new semantics: exactly
one of three concurrent calls is let in, only it requests a
rebalance, and the guard clears once the run completes.
Reported by an external security researcher via private disclosure.
Fixes#323
The claim of a returning self-payment matched payment_hash and
payment_secret but not the HTLC amount. Answering the hook with
resolve settles the HTLC at once, so lightningd's own
final_incorrect_htlc_amount check is skipped. The last-hop peer
relays our onion (and thus the secret) intact but chooses the offered
amount, so it could settle a reduced HTLC, learn the preimage, and
claim the full amount upstream.
Record the intended amount at Claimer::generate() time and resolve
only an exact match; a mismatch is left to normal handling, which
fails the HTLC for lack of an invoice.
The same issue was recently fixed in sling (daywalker90/sling@835f36e8).
Fixes#322.
CLN deprecated and then removed the implicit-bech32 default for the
newaddr command. Modern CLN (tested on v26.04.1) responds to
newaddr with only {"p2tr": "..."} and prints the warning
jsonrpc: Note: disallowing deprecated newaddr.addresstype.defaultbech32
This hit our existing code at line 38, which extracted res["bech32"]
unconditionally. Jsmn::Object::operator[] returns an Object with
null pimpl when the key is missing, and the std::string conversion
operator then throws TypeError. The exception propagates up the
Ev::Io chain and is swallowed silently, so Msg::ResponseNewaddr is
never raised.
Downstream symptom: SwapManager hangs forever in state 0
(NeedsOnchainAddress) after restart. Its getting_address flag was
set true when it raised the request, and only clears when the
queue empties via the response chain that never completes. Every
subsequent Timer10Minutes tick short-circuits on the still-true
flag and does nothing.
Fix matches the draft on origin/boltzapi-v2-taproot-reverse-swaps
commit c3dd1de: explicitly request newaddr p2tr and read res["p2tr"].
This is a breaking change for CLN v23.05 and older, but those are
two-plus years out of support already.
CLN's channel_state_changed notification used to emit the sentinel
value "unknown" for old_state when there was no previous state.
That value was deprecated in v25.05 and is last-supported in v26.04;
as of v26.06 the old_state field is simply omitted instead (see
doc/developers-guide/deprecated-features.md, entry
"channel_state_changed.old_state.unknown").
The notification handler unconditionally extracted old_state, which
throws Jsmn::TypeError when the field is absent. The throw was
caught by the surrounding handler, logged as Error
("Unexpected channel_state_changed payload: ..."), and then the
handler returned without taking action. Functional behavior was
unchanged compared to the legacy "unknown" path (both result in
no destruction event), but the new release variant produced noisy
Error log lines for every state-changed notification on nodes
running v26.06+.
Add an explicit has() check and leave old_state as the default
empty string when absent. The empty string will not match either
"CHANNELD_NORMAL" or "CHANNELD_AWAITING_LOCKIN", so the handler
falls through to the no-op return -- the same outcome the legacy
catch-and-log path produced, but silently.
This is the third and final commit of the v26.06 compatibility
PR (preceded by the Dowser and Matchmaker/ActiveProber commits).
Both Lightning DNS seeds are no longer operational: lseed.bitcoinstats.com
returns SERVFAIL and lseed.darosior.ninja is confirmed dead by its
maintainer. The empty seed list is handled gracefully with a warning
log. Retained the original IRC discussion as historical context for future seed
selection.
This introduces a number of changes:
* We can no longer implicitly capture `this` in `[=]() { ... }`,
we have to explicitly capture it: `[=, this]() { ... }`.
* We added a newer version of the `AX_CXX_COMPILE_STDCXX` macro as
the stable Debian does not have the latest version yet, and it is
the latest version that has support for C++20.
Introduce `--clboss-max-rebalance-fee-ppm` to cap the fee allowed for a
single rebalance. Both JitRebalancer and EarningsRebalancer register and
use this option, defaulting to 5000 ppm (0.5%). Documentation updated to
explain the new setting.
- Register and implement the new clboss-feerates command in OnchainFeeMonitor
- Document the command in README and note it in the changelog
- Update RPC manifest tests to include the new command
Addresses ([#229])
This allows effective feerates (PPM) to be computed for earnings and
expenses.
This PR updates the schema automatically. Downgrading to previous
will require manual DB migration (but is possible). Downgrade
commands are in a comment in EarningsTracker.c
This commit modifies the schema of EarningsTracker to allow storing
and accessing earning and expenditure data in specific time ranges.
All existing strategies and reports still use all data from all time
so this PR should not change any balancing behavior.
After we've run w/ this for a while we'll have time-based data
collected and can evaluate how to improve the strategies.
Fixes ([#222])
Prior to ElementsProject/lightning@780f32d (`v23.05`) both `fee` and
`fee_msat` were sent for compatibility. The ForwardFeeMonitor was
checking for the presence of the `fee` field before processing the
record. This needed to be updated to `fee_msat`.
The logged version now looks like:
plugin-clboss: clboss v0.13.2 (v0.13.2-rc1-3-g44832e2)
A new "info" chunk is added to clboss-status:
"info": {
"version": "v0.13.2",
"git_commit_hash": "44832e2258069641a6149bdc90b7e5fc12219f77",
"git_describe": "v0.13.2-rc1-3-g44832e2"
},
The list of seeds that we currently have is really old
and also are really random.
What I did is to peak some of the most popular nodes (including some CLN
nodes) and update our list of seeds.
However, I am open to an objection is some of you want to keep ar add others
seeds nodes.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Previously, CLBOSS initialized the OnchainFeeMonitor with 2 weeks of
synthetic data collected at an arbitrary time on an unknown
system. This historical data often failed to accurately determine
low/high fee conditions until 2 weeks had passed.
This update changes the initialization to use a smaller amount of
deliberately conservative history. This approach discourages CLBOSS
from prematurely declaring a low-fee environment, while still allowing
it to recognize low fees after a few days.
The new size is designed to have 50% influence on the lower 20th
percentile after 24 hours (24 * 6 * 20% * 0.5 = 14.4). This influence
decreases over time: to 25% after two days, 10% after five days, and
continues to decay until it has no effect after two weeks.
It's important to note that CLBOSS will still function in high fee
environments to manage initial liquidity, so this change does not
impact its ability to operate effectively.
Construct a "compatibility struct" to convert `listpeerchannels`
output into legacy `listpeers` format.
Tests written using the legacy listpeers format can use the
`convert_legacy_listpeers` utility to construct a compatibility
struct.
The test_peerjudge_datagatherer malformed test needed to be malformed
differently to achieve the desired effect.
