Vincenzo Palazzo vincenzopalazzo

You're right, my mistake — I was reading the timing wrong. If those records were stamped 24/05/26 18:01 and we're now around the same time on 25/05, we're at ~24 hours with zero change to the SOA serial. That is not normal DNSSEC re-sign latency. It's a stuck job on Infomaniak's side, not patience.

Action: open a support ticket now. Sunday-evening estimate is irrelevant on a Monday morning.

Ticket content (paste this verbatim)

Subject: DNSSEC zone re-sign appears stuck on xelena.ai

Records added/modified in the DNS Zone of xelena.ai on 2026-05-24 ~18:01 CEST are not visible in public DNS ~24h later. >

Yes — Option C is the right call, and your reasoning is exactly correct: the shared key K ships alongside the template offer in a single merchant→PoS handoff. No separate PoS keypair to register. From PoS's side, K is per-template state, not long-lived identity.

Concretely:

Setup (merchant → PoS, once per template):

K = random 32 bytes                       // generated by merchant
template_offer = OfferBuilder::deriving_signing_pubkey(...)
merchant ships {template_offer, K} → PoS  // application-layer channel; LDK doesn't care which

Option	Construction	Tradeoff
A. Order DB only (BLIP-0056 model, simplest)	`payment_token = ECIES_encrypt(merchant_pub, order_hash)`. Merchant validates `order_hash ∈ order_db`.	Depends on PoS→merchant out-of-band publication. Anyone can forge syntactically; only legitimate hashes pass DB check.
B. Sender-authenticated (signcryption)	PoS has its own `(pos_priv, pos_pub)`. `payment_token = signcrypt(pos_priv, merchant_pub, order_hash)`. Merchant verifies the sender was this specific PoS.	Need PoS pubkey known to merchant ahead of time (could be in the merchant's own config; or first appearance in the template-offer registration step). No more dependence on order DB integrity for forgery resistance.
C. PoS-authored MAC (shared secret)	PoS and merchant pre-share a key `K` at template-offer creation. `payment_token = ECIES_encrypt(merchant_pub, order_hash ‖ HMAC(K, order_hash))`. Merchant verifies HMAC on decryption.	Symmetric key per PoS — PR #86's model,

	You are working in the OCEAN mining dashboard / payout codebase.

	Goal:
	Improve the Lightning payout error UX so users stop seeing vague messages like:

	"Unknown payout error, contact lightning@ocean.xyz"

	Most Lightning payout failures are temporary route/liquidity/reachability issues, and OCEAN retries automatically. The UI should classify the raw CLN/lightning error into a user-friendly category, show a clear status and action, hide raw technical details behind an expandable section, and only tell users to contact support after sensible thresholds.

	Context:

	Hypothesis (written down)

	Core Hypothesis

	The long routes (7–9 hops) that triggered the xpay "Could not create payment onion: path too long" errors on the experimental node are primarily caused by insufficient local liquidity on the Ocean ↔ Megalithic.me channel, combined with the node’s extremely limited connectivity (only two active channels).

	Detailed Reasoning

	1. Topology
	• The experimental node has only two active channels.

	Found them.

	## LND-side fix

	The LND commit that fixes this exact `pong bytes exceeded` disconnect is:

	```text
	08b26b613745d5e1e63abed15746045d03c8f27a
	lnwire+peer: ignore no-reply pings
	```

	# bLIP-XXXX: Split Payments via BOLT 12

	```
	bLIP: XXXX
	Title: Split Payments via BOLT 12 Offers
	Status: Draft
	Author: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
	Created: 2026-04-11
	License: CC0
	```

	➜ qvac-doc-recognition git:(main) ✗ make dev
	Starting bot in development mode...

	> qvac-doc-recognition@1.0.0 dev /mnt/HC_Volume_103194752/github/qvac-doc-recognition
	> nodemon --exec tsx src/bot.ts

	[nodemon] 3.1.10
	[nodemon] to restart at any time, enter `rs`
	[nodemon] watching path(s): src/*/
	[nodemon] watching extensions: ts

	common_init_from_params: setting dry_penalty_last_n to ctx_size = 1024
	Failed to generate tool call example: Value is not callable: null at row 1, column 72:
	<\|im_start\|>{% for message in messages %}{{message['role'] \| capitalize}}{% if message['content'][0]['type'] == 'image' %}{{':'}}{% else %}{{': '}}{% endif %}{% for line in message['content'] %}{% if line['type'] == 'text' %}{{line['text']}}{% elif line['type'] == 'image' %}{{ '<image>' }}{% endif %}{% endfor %}<end_of_utterance>
	^
	{% endfor %}{% if add_generation_prompt %}{{ 'Assistant:' }}{% endif %}
	at row 1, column 42:
	<\|im_start\|>{% for message in messages %}{{message['role'] \| capitalize}}{% if message['content'][0]['type'] == 'image' %}{{':'}}{% else %}{{': '}}{% endif %}{% for line in message['content'] %}{% if line['type'] == 'text' %}{{line['text']}}{% elif line['type'] == 'image' %}{{ '<image>' }}{% endif %}{% endfor %}<end_of_utterance>