Skip to content

Instantly share code, notes, and snippets.

@vincenzopalazzo

vincenzopalazzo/gist:03e3cb7772d0cd10cf83636bea1b16e7

Created May 1, 2026 18:38
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save vincenzopalazzo/03e3cb7772d0cd10cf83636bea1b16e7 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save vincenzopalazzo/03e3cb7772d0cd10cf83636bea1b16e7 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.md
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, which you'd asked to avoid. Falls back to symmetric crypto.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment