When doing things like `waitsendpay` without specifying the `groupid`
we likely want to use the latest `groupid` we created, since that's
the one in flight. This adds a function to quickly retrieve that.
Suggested by @cdecker
P.S: Also this include an API refactoring from my previous solution, also this it is suggested by @cdecker.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Before:
Ten builds, laptop -j5, no ccache:
```
real 0m36.686000-38.956000(38.608+/-0.65)s
user 2m32.864000-42.253000(40.7545+/-2.7)s
sys 0m16.618000-18.316000(17.8531+/-0.48)s
```
Ten builds, laptop -j5, ccache (warm):
```
real 0m8.212000-8.577000(8.39989+/-0.13)s
user 0m12.731000-13.212000(12.9751+/-0.17)s
sys 0m3.697000-3.902000(3.83722+/-0.064)s
```
After:
Ten builds, laptop -j5, no ccache: 8% faster
```
real 0m33.802000-35.773000(35.468+/-0.54)s
user 2m19.073000-27.754000(26.2542+/-2.3)s
sys 0m15.784000-17.173000(16.7165+/-0.37)s
```
Ten builds, laptop -j5, ccache (warm): 1% faster
```
real 0m8.200000-8.485000(8.30138+/-0.097)s
user 0m12.485000-13.100000(12.7344+/-0.19)s
sys 0m3.702000-3.889000(3.78787+/-0.056)s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This touches a lot of text, mainly to change "if `option_anchor_outputs`"
to "if `option_anchors`"
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
After some discussion with @shesek, and my own usage, we agreed that
a more comprehensive interface, which explicitly supports grouping,
is desirable.
Thus keys are now arrays, with the semantic that a key is either a
parent or has a value, never both.
For convenience in the JSON schema, we always return them as arrays,
though we accept simple strings as arguments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We add a generation counter, and allow update or del conditional
on a given generation.
Formalizes error codes, too, since we have more now.
Suggested-by: @shesek
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This actually caused the flake in test_funding_reorg_private, where
l1 and l2 might not mark the original channel disabled. In fact, they
should *remove* it as it gets reorged out.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Return false if the timelock didn't mature yet, not the other way
around.
Also, the check shouldn't be strict: if the CSV is 1 it is valid
at utxo->blockheight + 1.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
Turns out we didn't actually test this at all, and next commit does :(
offer_status_in_db: 4 is invalid
lightningd: FATAL SIGNAL 6 (version v0.10.0-459-g48fbd45-modded)
0x5608cd360855 send_backtrace
common/daemon.c:39
0x5608cd3608ff crashdump
common/daemon.c:52
0x7f9af1dae20f ???
???:0
0x7f9af1dae18b ???
???:0
0x7f9af1d8d858 ???
???:0
0x5608cd30a47e fatal
lightningd/log.c:819
0x5608cd3430c5 offer_status_in_db
wallet/wallet.h:1424
0x5608cd34f1f3 wallet_offer_disable
wallet/wallet.c:4494
0x5608cd33ae2e json_disableoffer
lightningd/offer.c:256
0x5608cd3038fc command_exec
lightningd/jsonrpc.c:643
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit introduces the code cleanup suggested by the TODO comment in the code.
Basically, it moves the code from the if-else statement to a switch statement without the default case. I used the basic idea of the code used in PR #4507.
Changelog-Changed: None.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Not an API break: reserve=true|false still works for fundpsbt and utxopsbt,
but we also allow a raw number in there.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tor v2 hidden services have been deprecated for a while:
https://blog.torproject.org/v2-deprecation-timeline .
This prevents user from being able to set them in the configuration
and to connect to them while still letting us be able to parse them
for gossip.
Changelog-Deprecated: lightningd: v2 Tor addresses. Use v3. See https://blog.torproject.org/v2-deprecation-timeline.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
This means remembering the connection direction. We also use the address to try
to reconnect, which we shouldn't bother with if they connect to us.
For peers from the database, we currently always save the addr: we shouldn't really
do this if they connected to us, since it's not useful for reconnecting (we don't
show the addr in JSON reply to listpeers unless we're connected, so it's only an
internal issue). This is left for future work.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
