Recevoir
Silex
₿silex@21pay.org
Un nom. Deux rails. Des adresses toujours neuves.
- Lightning
- BOLT 12 · lno
- On-chain
- BIP-352 · sp1q
- DNS
- silex.user._bitcoin-payment.21pay.org
BIP-352 · BOLT 12 · BIP-353
Silent Payments et une offre Lightning statique dans le même QR. Le portefeuille dérive une destination neuve à chaque paiement — on-chain ou Lightning — sans interaction, sans réutilisation, sans serveur web.
Recevoir
₿silex@21pay.org
Un nom. Deux rails. Des adresses toujours neuves.
1
identifiant
₿silex@21pay.org — dictable, imprimable, éternel.
2
rails
Lightning d’abord. Silent Payment en repli. Un bouton.
∞
adresses
Chaque paiement produit une sortie ou un hash unique.
Rail A · BOLT 12
L’offre ne change jamais. Chaque paiement demande une facture fraîche par onion message, avec chemins aveuglés. Pas de LNURL, pas d’HTTPS vers le destinataire.
Rail B · BIP-352
L’expéditeur dérive une sortie Taproot par ECDH sur ses propres inputs. L’adresse sp1q n’apparaît jamais à la chaîne. Le destinataire scanne, sans notification.
Bitcoin a toujours su payer. Il n’a jamais eu un identifiant unique, privé, et dual-rail. C’est exactement le trou que comblent Silent Payments + BOLT 12 dans une enveloppe BIP-321, résolue par DNSSEC.
Politique de routage
if lightning_reachable(offer):
pay_bolt12(invoice_request)
else:
pay_silent(derive_taproot(inputs, Bscan))
# jamais réutiliser une adresse classiqueL’expéditeur ne choisit pas le rail. Alice paie Silex. Le portefeuille décide. C’est toute l’UX.