Hi Keysa!

I was reading through your guide and had a question. When it comes to rolling and then ordering the dice your handout says “Carefully place them in a row, with the octal one on the left side. The order of the next two doesn’t matter.”

I asked ChatGPT about this. If the two D16 aren’t differentiated it only allows for 1,088 combinations. But if you put the D16 in the same order every roll (D8, D16a, D16b) you then have 2,048 possible combinations (which matches the bip39 wordlist word count).

Reply to this note

Please Login to reply.

Discussion

This is fascinating! nostr:npub1337xxyne0pw52zgd984xqqs2q7qhqpt7phhn7xp6t9yt406vrvescdpkdt did you know this?

The order in which you GRAB them doesn’t matter. But ultimately YOU ARE ordering them when you write them down. So they are ordered when the exercise is finished, yielding 2048 possible combinations, which is perfect given there are exactly 2048 words in the BIP 39 word list.

we tested zaps on this note… we made six attempts to⚡zap this note, at me@dplus.plus, over a period of about 3 hours. six of the zaps were successfully paid... please check for 6 satoshis received. however, we did find that only one of the payments produced zap receipts in time for our server to recognize them. this is a problem because the user who zapped you would not see an active ⚡icon after zapping. they might think the zap failed, and therefore might not zap you again.... if you wanted to fix this... you could try getting a free rizful lightning address -- https://rizful.com ... if u get it set up, pls reply here so we can do this ⚡zap test again.

I am showing zap receipts for all six.

interesting test case! your granular data is below.... interesting that it was #3 where we saw the zap receipt... this can sometimes happen due flakiness on whatever server you have producing your zap receipts -- or could possibly be whatever relays you are sending zap receipts to... or could be something else...

Individual Zap Attempts:

1. Attempted at: 2025-12-28 04:52:07 UTC

LNURL: 1710ms

Callback/Invoice Generate: 1040ms

Attempt ➡ Lightning Confirmation: 2602ms

Lightning Confirmation ➡ Zap Receipt: N/A

---

2. Attempted at: 2025-12-28 05:49:51 UTC

LNURL: 1605ms

Callback/Invoice Generate: 1071ms

Attempt ➡ Lightning Confirmation: 1058ms

Lightning Confirmation ➡ Zap Receipt: N/A

---

3. Attempted at: 2025-12-28 06:38:14 UTC

LNURL: 552ms

Callback/Invoice Generate: 921ms

Attempt ➡ Lightning Confirmation: 5153ms

Lightning Confirmation ➡ Zap Receipt: 4049ms

---

4. Attempted at: 2025-12-28 07:01:14 UTC

LNURL: 1794ms

Callback/Invoice Generate: 1083ms

Attempt ➡ Lightning Confirmation: 1038ms

Lightning Confirmation ➡ Zap Receipt: N/A

---

5. Attempted at: 2025-12-28 07:36:26 UTC

LNURL: 1929ms

Callback/Invoice Generate: 1100ms

Attempt ➡ Lightning Confirmation: 1171ms

Lightning Confirmation ➡ Zap Receipt: N/A

---

6. Attempted at: 2025-12-28 08:18:20 UTC

LNURL: 547ms

Callback/Invoice Generate: 1074ms

Attempt ➡ Lightning Confirmation: 1013ms

Lightning Confirmation ➡ Zap Receipt: N/A

---

what zap receipt implementation are you using? are you sure it is sending the zap receipt to the relays specified in the zap attempt?

I made my own zap receipt server with some random relays hardcoded. Maybe that’s the issue.

Yep. Check out this line in the nip 57 spec:

https://github.com/nostr-protocol/nips/blob/fa9281af8b7c964542dd1145ba61a9fd851af713/57.md?plain=1#L22

" publish it to the `relays` specified in the `zap request`."

... almost everyone gets this wrong the first time they create a zap receipt server... we definitely did...

Okay… maybe I should add a few extra relays though just in case? Like at least one that I’m connected to so I can see my own zap receipts.