schemas: make required fields match the code

[daywalker90]

Fields added to required (source where unconditionally added):

• askrene-create-layer/layers[]. & askrene-listlayers/layers[]:
  biases, node_biases - plugins/askrene/layer.c:1512,1519
• bkpr-channelsapy/channels[]: fees_in_msat - plugins/bkpr/channelsapy.c:292
• bkpr-report: format (request) - plugins/bkpr/bookkeeper.c:520;
  format-hint - plugins/bkpr/report.c:499
• datastore & deldatastore: generation, hex - lightningd/datastore.c:19,20
• decode/offer_recurrence[]: compulsory_field - plugins/offers.c:880
• delpay/payments[]: groupid - lightningd/pay.c:144
• feerates/onchain_fee_estimates: unilateral_close_nonanchor_satoshis
  • lightningd/chaintopology.c:788
• fundchannel_start: channel_type - lightningd/opening_control.c:321
• help: format-hint - lightningd/jsonrpc.c:496
• hook/onion_message_recv & _secret: unknown_fields,
  reply_blindedpath.{first_path_key,hops} - lightningd/onion_message.c:30,31,66
• listchannels/channels[]: htlc_maximum_msat - plugins/topology.c:263
• listclosedchannels/closedchannels[]: channel_type
  • lightningd/closed_channel.c:43
• listconfigs: configs - lightningd/configs.c:275
• listpays/pays[]: amount_sent_msat - plugins/xpay/listpays.c:183
• listpeerchannels/channels[]: channel_type - lightningd/peer_control.c:959,
  lightningd/dual_open_control.c:128, lightningd/opening_control.c:48
• listpeers/peers[]: features - lightningd/peer_control.c:2619
• multifundchannel: failed - plugins/spender/multifundchannel.c:501
• notification/coin_movement: extra_tags - lightningd/coin_mvts.c:169
• offer: force_paths - lightningd/offer.c:24
• openchannel_init & openchannel_bump: requires_confirmed_inputs
  • lightningd/dual_open_control.c:3478
• parsefeerate: perkw - lightningd/chaintopology.c:823
• pay: destination - plugins/xpay/xpay.c:473, plugins/libplugin-pay.c:2144
• reckless (request): target/subcommand - plugins/recklessrpc.c:280
• renepay & renepaystatus/paystatus[]: groupid, destination
  • plugins/renepay/json.c:269,278,279
• sendonion: groupid - lightningd/pay.c:144; pending branch message - :299
• sendpay & waitsendpay: groupid - lightningd/pay.c:144
• splice_signed: outnum - lightningd/channel_control.c:548
• splicein & spliceout: psbt, txid - plugins/spender/splice.c:1763,1764

Fields removed from required (conditional in code):

• bkpr-editdescriptionbypaymentid/items[]: description
  • plugins/bkpr/chain_event.c:33-34, plugins/bkpr/channel_event.c:53-54
• createinvoice & sendinvoice: description - lightningd/invoice.c:64-65
• hook/invoice_payment: result - lightningd/invoice.c:237 (optional);
  failure_message only used when result is absent, now required there
  via if/then/else
• invoicerequest (request): description - plugins/offers_offer.c:693 (p_opt)
• splice_signed (request): channel_id - lightningd/channel_control.c:2511
  (p_opt)

Note: bkpr-editdescriptionbyoutpoint keeps description required: the
SQL refetch filters credit_msat > 0 (recorder.c:376-382) and the desc was
just stored keyed by outpoint (bookkeeper.c:853).

Adjust plugins to the now-required fields:

• lsps-plugin: peer.features is non-optional (listpeers)
• wss-proxy-plugin: listconfigs' configs object is non-optional

Important

26.09 FREEZE August 5th: Non-bugfix PRs not ready by this date will wait for 26.12.

RC1 is scheduled on August 17th

The final release is scheduled for September 7th.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

• The changelog has been updated in the relevant commit(s) according to the guidelines.
• Tests have been added or modified to reflect the changes.
• Documentation has been reviewed and updated as needed.
• Related issues have been listed and linked, including any that this PR closes.
• Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

[daywalker90]

I was curious if there were other schemas out of sync with reality with regards to the required field and let the LLM scan every schema and check the code if the required fields are correct. Turns out quite a few were not.

[Andezion]

Nice!!

[Andezion]

For fundchannel_start.channel_type are you sure that encode_scriptpubkey_to_addr() always succeeding for real funding outputs, given three other fields already share that assumption?

[daywalker90]

Clanker says yes it is always succeeding:

No changes needed — encode_scriptpubkey_to_addr always succeeds for this response. The chain:

     1. openingd always replies with funding_output_script = scriptpubkey_p2wsh(...) (openingd/openingd.c:510) — unconditionally P2WSH (OP_0 PUSHBYTES(32) <sha256>, bitcoin/script.c:
        268-277).
     2. That's the only source of fc->funding_scriptpubkey (lightningd/opening_control.c:342, from opening_funder_start_replied), and funding_started_success is only called from that
        path (opening_control.c:359).
     3. encode_scriptpubkey_to_addr recognizes P2WSH (is_p2wsh, common/addr.c:17-18) and encodes it as witness v0 with a 32-byte program. segwit_addr_encode only fails for invalid
        program lengths (not 2–40 bytes); 32 is always valid, and the buffer 73 + strlen(hrp) is always large enough.

     So the if (out) guard at opening_control.c:315 is defensive/paranoid but never triggers here — meaning funding_address, scriptpubkey, channel_type, and warning_usage are all
     always present. Adding channel_type to required was correct, and no fields need to be removed.

If it does not, serde would panic/error and someone would have complained by now, surely?

[Andezion]

Is disabled_channels in the askrene layer schemas dead?

[daywalker90]

Seems like it, but i know there are more dead fields in the schema. I don't want to add those in this PR and will make another one to remove dead fields.