The rare case happened where a lockfile sha-sum contained a "Ctlv" which
spell-check complained about. Stupid lockfiles that don't know it is
actually "cltv"!
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
There was a problem with a ‘highlight’ that was misunderstood as a
spelling mistake in lib-wally. Since ‘hightlight’ is already filtered
out, we simply instruct grep to ignore upper/lower case when filtering.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Changelog-Added: The `htlc_accepted_hook` now gets the TLV-stream
attached to the HTLC passed through as `extra_tlvs` and can replace it.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Adds some testcases for custom tlvs, set by a htlc_accepted_hook. We
check that the custom tlvs replace the update_add_htlc_tlvs and get
forwarded to the peer. We also check that a malformed tlv will result in
a **BROKEN** behaviour.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Add serializing and deserializing of the extra tlvs to to the
htlc_accepted_hook to allow plugin users to replace the tlv stream that
is attached to the update_add_htlc message on forwards.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This appends the extra_tlvs to the internal channeld_offer_htlc wire
msg. We also recombine the extra_tlvs with the blinded path key for
forwarding htlcs.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This appends the extra_tlvs to the internal wire htlcs "added" and
"existing" for the extra tlvs to be handed to lightningd.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We currently only consider known tlv types in the internal
representation of a htlc. This commit adds the remaining unknown tlv
fields to the htlc as well. This is in prepareation to forward these to
the htlc_accepted_hook.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
json_tok_streq(…) and json_get_member(…) are convenience wrappers for
json_tok_strneq(…) and json_get_membern(…) respectively. Unfortunately, using
them incurs a performance penalty in the common case where they are called with
a string literal argument because the compiler is unable to substitute a
compile-time constant in place of the buried call to strlen(…).
For example,
json_get_member(buf, tok, "example");
…will have worse performance than…
json_get_membern(buf, tok, "example", strlen("example"));
…because the former is forced to scan over "example" at run-time to count its
length whereas the latter is able to elide the strlen(…) call at compile time.
Hoist these convenience functions up into common/json_parse_simple.h and mark
them as inline so that the compiler can elide the strlen(…) call in the common
case of calling these functions with a string literal argument.
Changelog-None
We cannot use subd_req() here: replies will come out of order, and the
we should not simply assign the reponses in FIFO order.
Changelog-Fixed: lightningd: don't get confused with parallel ping commands.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
One reason why ping processing could be slow is that, once we receive
a message from the peer to send to a subdaemon, we don't listen for
others until we've drained that subdaemon queue entirely.
This can happens for reestablish: slow machines can take a while to
set that subdaemon up.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Requested-by: Michael at Boltz
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Plugins: `xpay` now publishes `pay_part_start` and `pay_part_end` notifications on every payment send attempt.
Implement the sending of `start_batch` and `protocol_batch_element` from `channeld` to `connectd`.
Each real peer wire message is prefixed with `protocol_batch_element` so connectd can know the size of the message that were batched together.
`connectd` intercepts `protocol_batch_element` messages and eats them (doesn’t forward them to peer) to get individual messages out of the batch.
It needs this to be able to encrypt them individiaully. Afterwards it recombines the now encrypted messages into a single message to send over the wire to the peer.
`channeld` remains responsible for making `start_batch` the first message of the message bundle.
The new spec sends `batch_size` in `start_batch` and removes it from `commitment_signed` so we need to stop processing it in `commitment_signed`.
Since the tlv is now reduced to one element and that automagically turns it into a direct use TLV so we have to update the code everywhere it is referenced.
We add `start_batch` to match t-bast’s splicing spec and we add a new internal wire type `WIRE_PROTOCOL_BATCH_ELEMENT` using the type number 0
Changelog-Added: support for `start_batch`
This replaces the old "iterate through each peer, then each peer's channel" suboptimality.
A bit of care required that we don't expose scids if we're forwarding,
but that was already carefully handled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We allowed NULL for stub channels, but just don't put the stub scid
into the hash tables. This cleans up all the callers to make it
clear this is a non-optional parameter.
We opencode channel_set_random_local_alias, since there's only one caller now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have a migration which ensures this, but then I discovered that did
*not* address channels without an SCID yet. So fixed the migration, and
simpligied the code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: we now allow routing through old short-channel-ids once a splice is done (previously we would refuse, leading to a 6 block gap in service).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There can be any number of these, and it will be useful to allow
routing by older scids (when other nodes haven't seen our gossip, or
even before we *can* announce the new post-splice channel).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When we had to use the number to the db_bind call, these annotations made
sense, but since 0bcff1e76d (for v23.08) we
removed that.
So remove all the counters, which are simple overhead if we want to
change something.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since the signature data may vary, we must copy the new psbt into splicing->current_psbt.
This never occured during normal operation, but when doing a cross splice there may be vital signature(s) in the psbt that came from another splice that get dropped without this step.
When doing a cross channel splice, inputs move from having no SIGHASH to having SIGHASH_ALL assigned.
This causes psbt_get_changeset to flag the input as having changed, as the sighash value is compared.
This causes the second channel splice to `tx_remove_input` the input as it doesn’t match anymore, breaking the splice.
We fix this by removing the sighash value from input comparisions.
When doing a multi channel splice, we need to break the deadlock by signing the shared output early (even though it is not sent to the peer until later).
Previous behavior was to fail on abort when we have signatures in the inflight — change this behavior to fail on abort if we have sent our peer our signatures.
We used to use a check on the active psbt to see if our splice signature was in it — but now we need to generate the signature early.
So we have to add a field tracking if we’ve sent it and add it to the database, wire protocols, and inflight objects.
