Subnostr

nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s and nostr:npub1sy5awfp57rlmak0c3mz6c9zpddamzzq9yuty60qlvs7msggg06xs5ndhej and nostr:npub1kwhxtsq92uw5emgmy6d56dascpzkxjjeh7d8xu7zrljjzj3k73yspf9h5l

I'm tagging you because I think you will most efficiently be able to tell me if I've confusing myself or if I have actually discovered an issue in the ZAP spec , nip-57 ... https://github.com/nostr-protocol/nips/blob/master/57.md ..

I am finding that when the SENDER of a zap has configured too many relays... like 10+.... then when the SENDER constructs the zap note...

https://github.com/nostr-protocol/nips/blob/6e7a618e7f873bb91e743caacc3b09edab7796a0/57.md?plain=1#L31

.... the zap note can get TOO LONG.

Because, according to the spec, the recipient's server must do this:

"the server should fetch a description hash invoice where the description is this zap request note and this note only"

https://github.com/nostr-protocol/nips/blob/6e7a618e7f873bb91e743caacc3b09edab7796a0/57.md?plain=1#L19

in other words: we need to stuff the text of this note into the description field of the invoice!

... so what happens if there are too many relays is that this note gets to be TOO LONG, and when we ask LND to make the invoice, we get...

Error creating invoice: [

503,

'AddInvoiceError',

{

err: Error: 2 UNKNOWN: memo too large: 1097 bytes (maxsize=1024)

This might seem like a theoretical problem but I can reproduce the issue by using #coracle ... adding a bunch of relays manually, and then trying to zap a note whose recipient is using an LND node... I can see that the LND node fails to generate the invoice with a "AddInvoiceError" ("memo too large").

And then, to make the problem go away, I can go back to Coracle, reduce my number of relays, and then I can send zaps fine, because the descriptions fall under LND's max-length.....

Now, of course, I could go and ask LND "why don't you allow bigger memos/descriptions" -- but, my guess is that you could do a denial of service attack against a lightning node by requesting a shit-ton of invoices with really big memos... at least you could fill up that node's database, right?

So, please tell me: Am I a pitifully confused developer, or did I discover something that needs to be added/fixed in the nip-57 spec, like should the spec say "Hey, if you are developing a client which is constructing zap requests, if your user has a ton of relays, cool, but don't put more than 4 relays into the zap note..."...

Or, am I just confusing myself and/or reading/implementing the spec, wrong? Or taking too many marijuana edibles?

thanks

Reply to this note

Please Login to reply.

Discussion

SLCW 11mo ago

If you're zapping via NWC, isn't the relay specified in the NWC connect string the only relay contacted when zapping? Or are you not talking about NWC?

Rizful.com 11mo ago

I don’t think this relates to NWC. I know it’s confusing, I had to go over that ground for a bit to realize (I think) that this is only related to NIP57.

SLCW 11mo ago

Oh I see. I haven't looked into nip57 too deeply, so I'll bow out now. Lol

Super Testnet 11mo ago

I don't believe nodes have to use the "memo" field for this. Note the phrase "description hash" in this sentence: "the server should fetch a description hash invoice where the description is this zap request note and this note only"

The purpose of the description hash field is so that you can have a description larger than what fits in the memo field. Instead of putting the full description in the memo, you just hash it and put the hash in the description hash field; then you can give the full description separately to your user.

Now, given that you tested this, it's probable that you found an *implementation* bug -- specifically, you found a zap implementation that assumes the description will fit in the memo field of a lightning invoice, which might *usually* work but -- as you found -- not always. The implementation should be updated to *check* if the description will fit in the memo field. If not, it should only put a snippet in there (or nothing at all) and instead use the *description hash* field.

Rizful.com 11mo ago

Got it.

Thanks.

I think the implementation bug is a bug in MY implementation (I wonder if others have done this too...) I interpreted "where the description is this zap request note and this note only" to mean that I HAD to put the FULL note into the description.

What you are suggesting, I think, would read like this if it were explained in the spec:

"...where the description is this zap request note and this note only, unless it's too long, in which case you can put a hash of this note in the description_hash field, then you can put something else in the description field, like the note truncated to fit the available length"

I wonder if the nip-57 spec should be tweaked to mention this.

cloud fodder 11mo ago

also ez to hit limits on nostr event size too with encoding all the relays if theres a lot of em.