NUT-00: CBOR-encoded TokenV4 #109

Merged
callebtc merged 6 commits from tokenv4_cbor into main 2024-07-09 14:23:52 +00:00
callebtc commented 2024-04-05 08:44:57 +00:00 (Migrated from github.com)

This PR proposes a new TokenV4 binary encoding format using CBOR that reduces token size by around 40%.

It is implemented as a WIP and POC in https://github.com/cashubtc/nutshell/pull/502

Todo:

  • example and test cases
This PR proposes a new TokenV4 binary encoding format using CBOR that reduces token size by around 40%. It is implemented as a WIP and POC in https://github.com/cashubtc/nutshell/pull/502 Todo: - [x] example and test cases
davidcaseria (Migrated from github.com) reviewed 2024-04-08 13:36:22 +00:00
davidcaseria (Migrated from github.com) commented 2024-04-08 13:36:22 +00:00

Should the secret be of type bytes?

Should the secret be of type `bytes`?
callebtc (Migrated from github.com) reviewed 2024-04-08 14:28:43 +00:00
callebtc (Migrated from github.com) commented 2024-04-08 14:28:43 +00:00

The secret is a UTF-8 encoded string, so converting it to bytes doesn't save space in this case (in my tests with CBOR).

The secret is a UTF-8 encoded string, so converting it to bytes doesn't save space in this case (in my tests with CBOR).
AngusP (Migrated from github.com) reviewed 2024-04-11 13:09:30 +00:00
AngusP (Migrated from github.com) commented 2024-04-11 12:57:53 +00:00

Would be nice to give the same token in v3 encoding, as a size comparison and also as a test case

Would be nice to give the same token in v3 encoding, as a size comparison and also as a test case
@ -199,0 +272,4 @@
{
"i": h'00ad268c4d1f5826',
"p": [
{
AngusP (Migrated from github.com) commented 2024-04-11 13:05:54 +00:00

Nit: When compressing keys to a single char, if possible it's nice to have no collisions to avoid confusion, and also makes expanding to readable names trivial with a dict (no context needed). Here it's only "m" and "s" that can have two meanings

  • I'd suggest "m" for memo becomes "o" (memO)
  • "s" in DLEQ could be something else, not sure what it stands for... could be "g" from siGnature (I think it's a Schnorr sig along with e?), though that may be confused with the g generator point, so it could also be "p" from resPonse
Nit: When compressing keys to a single char, if possible it's nice to have no collisions to avoid confusion, and also makes expanding to readable names trivial with a dict (no context needed). Here it's only `"m"` and `"s"` that can have two meanings * I'd suggest `"m"` for `memo` becomes `"o"` (memO) * `"s"` in DLEQ could be something else, not sure what it stands for... could be `"g"` from siGnature (I think it's a Schnorr sig along with `e`?), though that may be confused with the `g` generator point, so it could also be `"p"` from resPonse
callebtc (Migrated from github.com) reviewed 2024-04-19 10:32:00 +00:00
@ -199,0 +272,4 @@
{
"i": h'00ad268c4d1f5826',
"p": [
{
callebtc (Migrated from github.com) commented 2024-04-19 10:32:00 +00:00

In my view, I think it's fine that labels are duplicated since this object isn't meant for human consumption anyway...

In my view, I think it's fine that labels are duplicated since this object isn't meant for human consumption anyway...
callebtc (Migrated from github.com) reviewed 2024-04-19 10:33:24 +00:00
callebtc (Migrated from github.com) commented 2024-04-19 10:33:24 +00:00

I'll work on this!

I'll work on this!
thesimplekid (Migrated from github.com) reviewed 2024-04-21 20:55:25 +00:00
thesimplekid (Migrated from github.com) left a comment

LGTM, maybe just add a test vector for it

LGTM, maybe just add a test vector for it
AngusP (Migrated from github.com) approved these changes 2024-04-22 13:09:54 +00:00
thesimplekid (Migrated from github.com) reviewed 2024-06-06 15:17:40 +00:00
thesimplekid (Migrated from github.com) commented 2024-06-06 15:17:40 +00:00
```json
{
 "m": str, # mint URL
  "p": [ # proofs
      {
        "i": bytes, # keyset ID
        "a": uint, # amount
        "s": str, # secret
        "c": bytes, # signature
        "d": { # DLEQ proof
          "e": bytes,
          "s": bytes,
          "r": bytes
           }
       }
        ...
      ],
  "u": str <optional>, # unit
  "e": str <optional> # memo
}

Following some discussion in other channels. I think its best to remove the support for mulimint tokens in V4. It adds unnecessary complexity to the token.

```suggestion ```json { "m": str, # mint URL "p": [ # proofs { "i": bytes, # keyset ID "a": uint, # amount "s": str, # secret "c": bytes, # signature "d": { # DLEQ proof "e": bytes, "s": bytes, "r": bytes } } ... ], "u": str <optional>, # unit "e": str <optional> # memo } ``` Following some discussion in other channels. I think its best to remove the support for mulimint tokens in V4. It adds unnecessary complexity to the token.
elnosh (Migrated from github.com) reviewed 2024-06-11 22:12:41 +00:00
elnosh (Migrated from github.com) commented 2024-06-11 22:12:41 +00:00

should it say that the DLEQ field is optional?

should it say that the DLEQ field is optional?
callebtc (Migrated from github.com) reviewed 2024-06-11 22:15:41 +00:00
callebtc (Migrated from github.com) commented 2024-06-11 22:15:41 +00:00

Agreed! Please feel free to commit to the PR or suggest a change!

Agreed! Please feel free to commit to the PR or suggest a change!
elnosh (Migrated from github.com) reviewed 2024-06-11 22:49:49 +00:00
elnosh (Migrated from github.com) commented 2024-06-11 22:49:49 +00:00
          "d": { # DLEQ proof (optional) 
            "e": bytes,
            "s": bytes,
            "r": bytes
          }
```suggestion "d": { # DLEQ proof (optional) "e": bytes, "s": bytes, "r": bytes } ```
callebtc commented 2024-06-30 11:12:32 +00:00 (Migrated from github.com)

Done ed29eb2

Done [ed29eb2](https://github.com/cashubtc/nuts/pull/109/commits/ed29eb240aa06d3d9ea58c083664e7a35241f852)
thesimplekid (Migrated from github.com) approved these changes 2024-07-01 14:18:03 +00:00
thesimplekid (Migrated from github.com) left a comment
ACK d9b5499a703b66049ce7368d2a8ea26b406ff4ff
Sign in to join this conversation.
No description provided.