Skip to content

Conversation

@thesimplekid
Copy link
Collaborator

@thesimplekid thesimplekid commented Oct 13, 2025

Add comprehensive specification for encoding Cashu payment requests using Bech32m format with TLV (Tag-Length-Value) serialization as an alternative to the existing CBOR+base64 format defined in NUT-18.

  • New specification file: 26.md defining NUT-26
  • Updated README.md to include NUT-26 in the specification table

The new Bech32m encoding format addresses several limitations of the legacy creqA (CBOR+base64) format:

  1. QR Code Efficiency: Bech32m uppercase encoding is alphanumeric-mode compatible
  2. Better Error Detection: Built-in Bech32m checksums provide data integrity validation
  3. Improved Human Readability: Clear creqb1 prefix identifies the format
  4. Standards Alignment: Consistent with Bitcoin addresses (BIP-173/350) and Lightning invoices
  • TLV-based serialization for flexible extensibility
  • Support for all NUT-18 payment request fields (id, amount, unit, mints, description, transports, NUT-10 conditions)
  • Compact encoding for common values (e.g., 'sat' as 0x00)
  • Nested TLV structures for complex types (transports, spending conditions)
  • Forward compatibility through unknown tag handling
  • Backward compatibility with legacy creqA format detection
  • Case-insensitive decoding with uppercase recommended for QR codes

The specification is marked as optional and depends on NUT-18.

  • update tests based on review changes

@thesimplekid thesimplekid marked this pull request as draft October 13, 2025 16:05
@thesimplekid
Copy link
Collaborator Author

thesimplekid commented Oct 13, 2025

cdk updated to use it here cashubtc/cdk@5388c28

@thesimplekid thesimplekid changed the title feat: Add NUT-26 Payment Request Bech32m Encoding specification feat: Add NUT-XX Payment Request Bech32m Encoding specification Dec 2, 2025
@thesimplekid thesimplekid marked this pull request as ready for review December 18, 2025 10:00
thesimplekid and others added 14 commits December 18, 2025 11:52
Add comprehensive specification for encoding Cashu payment requests using
Bech32m format with TLV (Tag-Length-Value) serialization as an alternative
to the existing CBOR+base64 format defined in NUT-18.

- New specification file: 26.md defining NUT-26
- Updated README.md to include NUT-26 in the specification table

The new Bech32m encoding format addresses several limitations of the legacy
creqA (CBOR+base64) format:

1. **QR Code Efficiency**: Bech32m uppercase encoding is alphanumeric-mode
   compatible, resulting in 30-60% smaller QR codes
2. **Better Error Detection**: Built-in Bech32m checksums provide data
   integrity validation
3. **Improved Human Readability**: Clear `creqb1` prefix identifies the format
4. **Standards Alignment**: Consistent with Bitcoin addresses (BIP-173/350)
   and Lightning invoices

- TLV-based serialization for flexible extensibility
- Support for all NUT-18 payment request fields (id, amount, unit, mints,
  description, transports, NUT-10 conditions)
- Compact encoding for common values (e.g., 'sat' as 0x00)
- Nested TLV structures for complex types (transports, spending conditions)
- Forward compatibility through unknown tag handling
- Backward compatibility with legacy creqA format detection
- Case-insensitive decoding with uppercase recommended for QR codes

The specification is marked as optional and depends on NUT-18.
Co-authored-by: lollerfirst <43107113+lollerfirst@users.noreply.github.com>
Co-authored-by: lollerfirst <43107113+lollerfirst@users.noreply.github.com>
Co-authored-by: lollerfirst <43107113+lollerfirst@users.noreply.github.com>
@Egge21M
Copy link
Contributor

Egge21M commented Dec 19, 2025

Fully implemented in cashubtc/cashu-ts#436

@Egge21M
Copy link
Contributor

Egge21M commented Dec 28, 2025

We are missing a signal for P2BK as @robwoodgate mentioned here: cashubtc/cashu-ts#436 (review)

@robwoodgate
Copy link
Contributor

We are missing a signal for P2BK as @robwoodgate mentioned here: cashubtc/cashu-ts#436 (review)

Wondering if some kind of general "tag" is possible that allows extension of the TLV schema without having to redefine it each time? I think this is what TSK was talking about on the p2bk nut pr?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants