vincenzopalazzo

 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0
 [Fido2Client] started mediated request, available credentials: 0

vincenzopalazzo

contentscript.js:14083 MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added. Use emitter.setMaxListeners() to increase limit
n @ contentscript.js:14083
contentscript.js:14083 MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 end listeners added. Use emitter.setMaxListeners() to increase limit
n @ contentscript.js:14083
contentscript.js:14083 ObjectMultiplex - orphaned data for stream "app-init-liveness"
warn @ contentscript.js:14083
contentscript.js:14083 ObjectMultiplex - orphaned data for stream "app-init-liveness"
warn @ contentscript.js:14083
contentscript.js:14083 ObjectMultiplex - orphaned data for stream "background-liveness"
warn @ contentscript.js:14083

vincenzopalazzo

bLIP: XX
Title: BOLT 12 Merchant Cashback Vouchers
Status: Draft
Author: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Created: 2026-06-07
License: CC0

Abstract

vincenzopalazzo

➜  oceanln-cli git:(main) ✗ oceanln payout --offer lno1pg7y7s69g98zq5rp09hh2arnypnx7u3qvf3nzutjvscrwwr8vank27fcwdjxsar6xvengef489ux5mnrw34rjatsd3uhyunxx3applgpwyp3ffm4y0gae0zak4sgrmwtcf9tsg9ntc6r5mr8dytkmec8c9udg4cz3vx7lpl3m3spngc326t5t30d88q8pqfg4927kmaq796mygpfrc8syqsrnmwpdvy0lv63e963w9z4m9hvzewr463mcca6k86yk2lg7kc9w5q8ghzt0v736fs227t8tay56e9k40yksam26w6n2ueumsjqchln04s8c4p7t8h0azd8wnp9zhcnc8jsef8n2rzm5qd3xv83gd4a30cmk0aqdpv6054wlvrqedq6qsy7p76emskvhv7mr40vnpn04js2yylhpa63nhdxczlcduyk5qnqaa9uxzsm0lmrvhgzs7fhmh2phj65fkfsjvn3xkphr7v6ag90mt3max2m77vccgrsgu9qqaqwusr09c6an7tcx5alxs54qvaqkxfq43gr329lex74dr83pluy9tg807avqvrljmrfdv6z5r5ccfkx0h59mv2fdgv5fekv0r62puh7nk2fjpme4w6d7d980d72yxv3a8e27n7nzjls7qxw4el7dygq3j52yau0wp7qwstgnh3zhqj8dev2wrzee96pzgyxcetcv5hxzurszcss8r4vpc6alsl6rmzpq34xl5cas24cuf0pc9f607mv4p8ytuhwvpva --message '{"height":952226,"lightning_bolt12":"lno1pg7y7s69g98zq5rp09hh2arnypnx7u3qvf3nzutjvscrwwr8vank27fcwdjxsar6xvengef489ux5mnrw34rjatsd3uhyunxx3applgpwyp3ffm4y0gae0zak4sgrmwtcf9tsg9ntc6r5mr8dytk

vincenzopalazzo

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:

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. >

vincenzopalazzo

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.

vincenzopalazzo

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
```

vincenzopalazzo

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

vincenzopalazzo

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,