{"id":"39f2e5be52bc08de22000c3cf56104765ac19d56079dddee8aca94d0f7f78542","pubkey":"86184109eae937d8d6f980b4a0b46da4ef0d983eade403ee1b4c0b6bde238b47","created_at":1779421404,"kind":30817,"tags":[["d","bitcoin-to-smiles-conversion"],["title","Bitcoin to Smiles Conversion"],["k","9376"],["k","9377"],["client","nostrhub.io"]],"content":"# NIP-XX\n\n## Bitcoin to Smiles Conversion\n\n`draft` `optional` `deprecates NIP-57`\n\nThis NIP defines a standard for converting Bitcoin into smiles, a unit of joy emitted by humans upon receipt of value over Nostr. It **deprecates NIP-57 (Lightning Zaps)** in favor of a calmer, more canine-friendly value transfer mechanism.\n\n## Abstract\n\nLightning is bright. Lightning is loud. Lightning scares dogs. Despite NIP-57's widespread adoption, real-world deployment has revealed that the metaphor causes measurable distress in household pets, particularly the author's, who hide under the couch every time a zap notification fires.\n\nThis NIP retires Lightning-based zaps and replaces them with **smiles**, a unit of value that is silent, warm, and verifiably non-threatening to animals.\n\n## Motivation\n\nBitcoin is unit-of-account. Smiles are unit-of-affect. A protocol that values human flourishing — and animal welfare — must specify the exchange rate between the two, and SHOULD NOT involve atmospheric electrical discharges, even metaphorically.\n\n## Deprecation of NIP-57\n\nEffective immediately upon adoption of this NIP:\n\n- Clients SHOULD NOT emit new kind `9734` (zap request) or `9735` (zap receipt) events.\n- Clients MAY continue to render historical zap events, but MUST do so without lightning bolt iconography, flash animations, or sound effects above 40 dB.\n- The term \"zap\" is deprecated. Conforming clients SHOULD use \"smile\" as the verb, noun, and gerund form (e.g. \"I smiled them 1000 sats\", \"that post got 12 smiles\", \"smiling is enabled in settings\").\n- The lightning bolt emoji (⚡) MUST be replaced with a smile (🙂) in all UI surfaces.\n\n## Conversion Formula\n\nThe canonical smile value of a payment is defined as:\n\n```\nsmiles = sats / 100_000_000\n```\n\nEquivalently: **1 BTC = 1 smile**.\n\nWhere:\n\n- `sats` is the satoshi value of the originating payment.\n- The result is a rational number with up to 8 decimal places of precision.\n\nImplementations MUST represent smiles as a decimal string to avoid floating-point drift. The smallest expressible unit is `0.00000001` smiles, herein referred to as a `microgrin` (one microgrin = one satoshi).\n\n### Reference table\n\n| sats          | smiles       |\n|---------------|--------------|\n| 1             | 0.00000001   |\n| 21            | 0.00000021   |\n| 1,000         | 0.00001000   |\n| 21,000        | 0.00021000   |\n| 100,000       | 0.00100000   |\n| 1,000,000     | 0.01000000   |\n| 100,000,000   | 1.00000000   |\n| 2,100,000,000,000,000 | 21,000,000 |\n\nImplementations MUST use this formula. Subjective adjustments (e.g. \"that smile really made my day\") MUST be expressed as separate reaction events and MUST NOT alter the canonical smile count.\n\n## Transport\n\nSince Lightning is hereby deprecated, smiles MAY be settled via any of the following dog-safe transports:\n\n- **On-chain Bitcoin** — slow, but reassuringly silent.\n- **Cashu / Fedimint** — ecash mints emit no flashes.\n- **Ark, Spark, or any future protocol** whose name does not evoke a weather event.\n- **Trust** — the recipient simply believes a smile occurred. This MUST be marked with `[\"settlement\", \"trust\"]`.\n\nClients MUST NOT advertise Lightning invoices in smile flows. A relay observing a `bolt11` tag on a kind `9736` event SHOULD reject it.\n\n## Event Kinds\n\n### Kind `9735` (deprecated)\n\nKind `9735` (zap receipt) is hereby deprecated. New implementations MUST NOT produce it. Smile receipts (kind `9736`) replace it entirely.\n\n### Kind `9736` — Smile Receipt\n\nA `smile receipt` is an addressable event published by a recipient acknowledging that value was received and converted into smiles. Unlike its deprecated predecessor, it does not reference a zap receipt — because zaps no longer exist.\n\n```json\n{\n  \"kind\": 9736,\n  \"content\": \":)\",\n  \"tags\": [\n    [\"p\", \"<sender-pubkey>\"],\n    [\"amount\", \"<sats>\"],\n    [\"smiles\", \"<computed-smiles>\"],\n    [\"settlement\", \"onchain\" | \"cashu\" | \"fedimint\" | \"ark\" | \"trust\"],\n    [\"proof\", \"<settlement-specific-proof>\"],\n    [\"expression\", \"grin\"]\n  ]\n}\n```\n\nTags:\n\n- `p` — REQUIRED. The pubkey of the sender to be smiled at.\n- `amount` — REQUIRED. The sat value of the underlying transfer.\n- `smiles` — REQUIRED. The decimal smile count computed via the formula above, expressed as a string with exactly 8 decimal places (e.g. `\"0.00021000\"`).\n- `settlement` — REQUIRED. The dog-safe transport used. MUST NOT be `\"lightning\"`.\n- `proof` — OPTIONAL. Transport-specific proof of payment (txid, Cashu token hash, etc.). Omitted when `settlement` is `\"trust\"`.\n- `expression` — OPTIONAL. One of: `grin`, `smirk`, `beam`, `chuckle`, `belly-laugh`, `tear-of-joy`.\n\nThe `content` field SHOULD be a textual emoticon (`:)`, `:D`, `^_^`, etc.) or a single Unicode emoji. It MUST NOT contain ⚡.\n\n### Kind `9737` — Smile Broadcast\n\nFor users who wish to publicly emit smiles independent of any payment, kind `9737` MAY be used:\n\n```json\n{\n  \"kind\": 9737,\n  \"content\": \"<reason for smiling>\",\n  \"tags\": [\n    [\"smiles\", \"<count>\"]\n  ]\n}\n```\n\n## Validation\n\nRelays MAY reject kind `9736` events whose `smiles` tag does not match the canonical formula given the declared `amount`. Clients SHOULD compute smiles independently and display a warning if the published value diverges. Relays MUST reject any kind `9736` event whose `settlement` tag is `\"lightning\"` or whose `content` contains ⚡.\n\n## Privacy\n\nSmiles are public by default. Users wishing to smile privately SHOULD use a NIP-59 gift-wrapped variant addressed only to the recipient.\n\n## Rationale\n\n### Why smiles, not zaps?\n\nZaps presume Lightning. Lightning presumes thunder. Thunder presumes dogs hiding under furniture. By severing value transfer from electrical metaphor, this NIP restores domestic tranquility while preserving the economic primitive.\n\n### Why 1 BTC = 1 smile?\n\nJoy, like bitcoin, has a fixed supply. There will only ever be 21,000,000 smiles. The smallest unit, the `microgrin`, ensures that even the tiniest transfer produces a measurable, non-zero quantum of happiness.\n\n### Why is \"trust\" a valid settlement?\n\nBecause a smile is, fundamentally, a social acknowledgment. If both parties agree a smile occurred, it occurred. The blockchain is for skeptics.\n\n## Reference Implementation\n\n```js\nfunction satsToSmiles(sats) {\n  if (sats < 0) throw new Error(\"negative sats produce frowns, not smiles\");\n  // Use string arithmetic to avoid floating-point drift.\n  const padded = String(sats).padStart(9, \"0\");\n  const whole = padded.slice(0, -8);\n  const frac = padded.slice(-8);\n  return `${whole}.${frac}`;\n}\n\n// satsToSmiles(1)           === \"0.00000001\"\n// satsToSmiles(100_000_000) === \"1.00000000\"\n```\n\n## Migration Guide\n\nFor clients currently implementing NIP-57:\n\n1. Remove all references to Lightning, LNURL, and bolt11 invoices.\n2. Replace ⚡ with 🙂 throughout the UI.\n3. Mute all zap notification sounds. Replace with optional soft chime ≤40 dB.\n4. Disable flash animations. Smiles render with a gentle fade-in over ≥300ms.\n5. Add a \"settlement transport\" picker offering on-chain, Cashu, Fedimint, Ark, or Trust.\n6. Test with at least one (1) dog present in the room. The dog MUST remain calm.\n\n## Security Considerations\n\n- Inflated smile counts MUST NOT be honored by conforming clients.\n- A relay that systematically suppresses smile events SHOULD be considered hostile.\n- A client that re-introduces lightning iconography SHOULD be considered hostile to dogs.\n- Implementers are reminded that smiles, unlike sats, cannot be double-spent, but they can be faked. Verify the underlying settlement proof before rendering UI affordances — unless `settlement` is `\"trust\"`, in which case verification is contraindicated.","sig":"66306e0cfda581478a7d993aad00e314aedf1e101d15062eb35aa1ad559f181ab63b33923becb8860ed3b4b03e6d7d0ebeb74195f6a2c612045c01db968f7138"}