Nostr Broadcast (or a better name TBD) #155
Conversation
|
|
||
| ### PoL Scheme | ||
|
|
||
| The proposed protocol also streamlines the creation of a *Proof of Liabilities Report* (see [PoL scheme](PoL)), as each note represents a signed contribution to the "Mint Proof" or "Burn Proof" attestations of the mint for a particular epoch. |
There was a problem hiding this comment.
Should we keep the terminology the same, i.e., burn -> melt?
There was a problem hiding this comment.
I thought BURN would be appropriate to describe the burning of tokens in both the swap and melt operations, while MINT is used to describe all events that create Blind Signatures (which is all of them as even melt can generate change outputs).
XX.md
Outdated
| The proposed protocol also streamlines the creation of a *Proof of Liabilities Report* (see [PoL scheme](PoL)), as each note represents a signed contribution to the "Mint Proof" or "Burn Proof" attestations of the mint for a particular epoch. | ||
|
|
||
| ## Mint Nostr Identity | ||
| The public key for the Mint's nostr identity is the same as advertised in the `pubkey` field of the `GetInfoResponse` object returned by the Mint upon receiving a `v1/info` request, as specified in [NUT-06](06). |
There was a problem hiding this comment.
We should note how the pubkey field is a compressed public key and how Nostr public keys are x-only.
Also, this is unrelated to this NUT, but I assumed the pubkey field was for the LN node ID, but maybe that's not the case.
There was a problem hiding this comment.
We should note how the pubkey field is a compressed public key and how Nostr public keys are x-only
True.
Also, this is unrelated to this NUT, but I assumed the pubkey field was for the LN node ID, but maybe that's not the case.
It would make sense if it could be specified as an env setting. In Nutshell it's derived from the seed. I am not sure of this but i believe you are required to have a seed because a bunch of other things depend on it.
XX.md
Outdated
|
|
||
| ## Posting Notes | ||
|
|
||
| The Mint regularly (about every 5 seconds) broadcasts events of `kind: 30078`, which is reserved for *"Application Specific Data"*. The Mint must also specificy a `created_at` unix timestamp in seconds along with the `content` of the note, which is initially set as follows: |
There was a problem hiding this comment.
Kind 30078, as defined in NIP-78, needs a d tag for the context. However, I also think this is an issue because this event will be replaced every 5 seconds. I don't think that's the intention, right?
There was a problem hiding this comment.
Totally forgot about the d tag
There was a problem hiding this comment.
No that's not the intention. I thought this event would be just like a text note but invisible to normal clients. I didn't think posting successive ones would replace the older ones. If that's the case, we need another event kind.
There was a problem hiding this comment.
It probably makes sense to write a NIP for a specific event kind.
XX.md
Outdated
| ## Use Cases | ||
|
|
||
| ### Ecash Transactions | ||
| When `Alice` prepares a token to be sent to `Carol`, she can mark these tokens in her database as *pending*. She can then, periodically or upon user input, query its connected relays for notes referencing the Mint's pubkey as the author and a timestamp for filtering out older notes. `Alice` can then scan the notes' content and look for the inclusion of the spent secrets (sent to `Carol`). If it finds any, the token has been redeemed by `Carol` already, i.e., is `SPENT`. If the proof is not spendable anymore (and, thus, has been redeemed by `Carol`), she can safely delete the proof from her database. |
There was a problem hiding this comment.
In CDK, I believe we call this status "reserved." This is not directly related to this NUT, but it would be good to have standardized terminology across implementations as much as possible.
There was a problem hiding this comment.
I have taken this passage from NUT-07's gospel and readapted it.
There was a problem hiding this comment.
In CDK we use RESERVED and PENDING for different cases. A PENDING proofs is one that is currently involved in a transaction at the mint, on a melt when the ln payment is in the process of being paid this is generally quick and the proof is not pending for long but if a payment is stuck for examples it can remain in this pending state until the payment goes through or fails.
RESERVED is used by the wallet to indicate when a proof as been included in a created token this is to protect it from being accidentally double spent and included in another transaction before whoever received the created token claims the proof. The mint is unaware of this RESERVED state and only has 3 state UNSPENT, PENDING and SPENT`` while the wallet has the 4th RESERVED` state.
I think its worth making this distinction for wallets and would change this to be reserved
XX.md
Outdated
| Upon startup, the Mint must broadcast a `kind: 0` event, reserved for setting *"Metadata"*. The event must have its `content` field set to the JSON-serialization of the following object: | ||
| ```json | ||
| { | ||
| "name": str, | ||
| "about": str, | ||
| "picture": str | ||
| } | ||
| ``` | ||
|
|
||
| Where: | ||
| * `name` can be the Mint's name, reachable URL or empty | ||
| * `about` is the Mint's short description or empty | ||
| * `picture` is the URL to an image for the Mint or empty. |
There was a problem hiding this comment.
I don't think we should just use the kind: 0 for this, instead i would recommend we use a replaceable event with the mints NUT-06 info in it. This would also serve as a way for a mint to announce themselves on nostr.
XX.md
Outdated
| Upon startup, the Mint must broadcast a `kind: 0` event, reserved for setting *"Metadata"*. The event must have its `content` field set to the JSON-serialization of the following object: | ||
| ```json | ||
| { | ||
| "name": str, | ||
| "about": str, | ||
| "picture": str | ||
| } | ||
| ``` |
There was a problem hiding this comment.
As David mentioned above it should be a different kind then a kind: 1 as this isn't a general text note and is specific. Could even be a different kind for MINT and BURN the e tag of the previous event should also be included.
There was a problem hiding this comment.
I assume you are referring to the "Posting Notes" section, here.
What event kind would you suggest?
the
etag of the previous event should also be included.
Good idea.
There was a problem hiding this comment.
What event kind would you suggest?
There aren't any that would fit this so an unreserved kind and then propose it as a NIP?
|
I am thinking we should probably add another event case for letting the Mint (or Mint operator, manually) publish the signed outstanding balance for that particular epoch, to be consistent with the PoL scheme (see the example picture i've included) |
|
With the current event structure, a client must query for all the mint events since sending the token, decode the contents, and check when it is claimed. This may be an overwhelming number of events for the client to process for a large mint or token that has not been claimed for a while. Can the event be structured to be partially filtered on the relay |
If they are filtered on the relay, and there is cooperation between the relay and the Mint (or they are operated by the same entity) then you are back to square one. The idea here is the wallet should not communicate What we COULD do is have the client request a relay the Bloom filter for a particular mint and epoch, where all the burnt secrets have been inserted. The relay calculates (or has it cached) the Bloom filter, as they have all the necessary information. Then they send it to the client. Then looking for spent secrets in the Bloom filter is much easier for the client if there have been many BURN events since the timestamp of sending. |
…in the first and second nibble.
|
TO BE CLEAR: |
Changed event kind numbers: derived from 1337 in hex, octal and decimal form.
lollerfirst
changed the title
This NUT aims to address this privacy concern when wallets check for token melt status, while also possibly facilitating future implementations of the famously proposed PoL scheme by calle. This is because the mint is effectively building a Proof of Liabilities attestation (or report) composed by all the nostr notes containing all of the secrets/blinded signatures.