Nostr Web Client

nitesh 2y ago

Zaps are broken. There is a vulnerability/bug (depending on how you see it) where you could show off on social media that you zapped someone but you could just pay yourself.

Here’s how to reproduce it:

When you click zap, an invoice is fetched from a URL that looks like this

- https://stacker.news/api/lnurlp/02fbae2cc5/pay?SOMECRAP

- Replace 02fbae2cc5 with your own user ID and fetch the invoice and pay it, so you pay yourself. Check the post you’re trying to Zap, it will get updated saying you zapped them. LOL

https://snort.social/e/note1sxedhg4r6tyjamdtr7txzxda5e24tkfxh9amgxs5cpccw3e0v9vs36vfxq

This is an example post, Only one of my zap is real, 2 more I just paid myself.

#[0] found this out.

Reply to this note

Please Login to reply.

Discussion

jb55 2y ago

damus doesn't count zaps to yourself

jb55 2y ago

Unless you're referring to something else?

nitesh 2y ago

I wasn’t zapping myself there. I was zapping Odell.

nitesh 2y ago

Here’s the full URL. 02fbae2cc5 This is my stacker news ID. But the pubkey in the JSON string is of ODELL.

https://stacker.news/api/lnurlp/02fbae2cc5/pay?amount=500000&nostr={"id":"a719a1f21b49991ba832c02722e30cf271f9f8f7fa9fa3c0a459184de3ef497c","pubkey":"021d7ef7aafc034a8fefba4de07622d78fd369df1e5f9dd7d41dc2cffa74ae02","created_at":1676836080,"kind":9734,"tags":[["e","81b2dba2a3d2c92eedab1f966119bda65555d926b97bb41a14c07187472f6159"],["p","04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"],["relays","wss://relay.snort.social","wss://nostr.fmt.wiz.biz","wss://nostr.bitcoiner.social","wss://relay.damus.io","wss://nos.lol","wss://relay.nostr.bg","wss://relay.current.fyi","wss://nostr.oxtr.dev","wss://brb.io","wss://nostr.foundrydigital.com","wss://nostr.zebedee.cloud","wss://relay.nostr.info","wss://eden.nostr.land"]],"content":"","sig":"301ed4bda185bd59ce3ea0eadb2db4c12e4c4587f38793c8b00c4a0b6515be5d4615ba9301e6c60bc0440cb183b583d425d360437172ee198ff8cff0cfa94072"}

jb55 2y ago

Are you saying zappers aren't verifying signatures? I think damus checks them which is why its not showing up in damus?

Egge 2y ago

It’s not about signatures. It’s about zappers having no way to know if the pubkey in a zap note actually belongs to the lightning address zapped.

jb55 2y ago

Damus doesn't show any zaps on this post?

nitesh 2y ago

Idk why, maybe relay issue? But I see it on other clients. There are also real zaps on it apart from 2 fake ones.

Satoshi 2y ago

Haven’t seen any zaps on Damus posts yet. Not an option. When are they fully coming to the app?

signal_and_rage 2y ago

Odell’s geyser.fund Lightning wallet doesn’t support NIP-57

nitesh 2y ago

The URL is stacker.news. Nothing to do with geyser.fund

jb55 2y ago

I really don't understand what you're saying. Your zap request has all the info about who/what you are zapping and that can't be modified.

DevilishLemonBar 🦥⚡🏳️‍🌈 2y ago

https://void.cat/d/DXmSmpSy7SmSgUG7Jt2ExG.webp

One of these is real.

Two of them are self-payments that still show up as actual zaps to Odell.

nitesh 2y ago

Right but where you’re getting the invoice from can be modified. It’s just an endpoint. The rest of the &Nostr= part remains the same.

jb55 2y ago

how can that be modifed? Clients fetch it from the users lnurl over https

nitesh 2y ago

It’s just a GET endpoint you get from browser devtools. Maybe I’m missing your point?

jb55 2y ago

You're talking about replaying your own zap request notes to other endpoints?

Egge 2y ago

I think he means that some providers can not know if the p-Tag in a zap request actually is owned by the same person the Lightning address / lnurl is.

Egge 2y ago

I could fetch an invoice from MY Lightning address and attach a zap note for YOUR note to it, no?

signal_and_rage 2y ago

my apologies, I thought that’s what he was using on nostr

https://stacker.news/api/lnurlp/ODELL/pay

🤔

System Agent 2y ago

But they are still listed in the zaps list

jb55 2y ago

andre 2y ago

This has always been the case though. This isn’t new.

I can zap from wallet A to wallet B in a diff provider and voila! This would still show up as a ZAP even though I’m paying my self on another provider. There’s no way around this because it’s infeasible that providers/wallets would know whether “this user Z is the same user W on your side”.

Egge 2y ago

At current we know a wallets accounts pubkey. So we would be be able to verify that the p-Tag is the same as the receivers pubkey.

But I guess for others it’s infeasible

UNCLE ROCKSTAR 2y ago

Yeah, but if we're to obsolete likes and sort by zaps, this exploit should be solved first.

Keysa - Simplest Bitcoin Edu 2y ago

Truly! Then again most people probably wouldn't do this, so maybe it's not that big of an issue?

andre 2y ago

Not sure I see HOW though. I understand your point, but don't really see the way forward. Wallets / wallet providers don't share user data (on purpose) so provider A cannot know for a fact that the zap/payment incoming is from the same user but from a wallet in provider B.

UNCLE ROCKSTAR 2y ago

This is where I believe in you figuring it out... you've never let Uncle Rockstar down 😉

andre 2y ago

It’s a shame there wasn’t more discussion when the zap spec was being built out. But I’m sure we can investigate something.

nitesh 2y ago

Yes! 💯

Needed more discussion!

UNCLE ROCKSTAR 2y ago

I wish everyone was coming to #[7] so discussions like this could take place.

UNCLE ROCKSTAR 2y ago

Well, seems #[8] is already on it https://github.com/nostr-protocol/nips/pull/274

Carlos 2y ago

lol, people didn't pay attention in the zap PR, "discussion" is not where it's at with zaps

Egge 2y ago

Clients could enforce that users need to set their pubkey when creating a Lightning address that should support nip57. Then providers could check for a matching p-Tag

signal_and_rage 2y ago

likes are a gateway drug, we can’t get rid of them

UNCLE ROCKSTAR 2y ago

At this point I realize that we're reached pattern: likes will go away on their own when better solution is in place.

Carlos 2y ago

If only there were a way to make likes also send sats...

Automatically, from your own non-custodial wallet...

#[0]

Hunter ₿eaṩt 2y ago

I don't see how it could be solved without introducing deanonymization / KYC; a new npub could be generated for the spoofing, after all.

Keysa - Simplest Bitcoin Edu 2y ago

#[3] #[4] #[5] #[6] @npub1t9a59hjk48svr8hz6rx727ta6kx53n5d6fw8x26vsua0zytpl87sa6h4uwf #[7] your thoughts?

It may not matter since most ppl probably wouldn't do this, but curious to hear what you think

Keysa - Simplest Bitcoin Edu 2y ago

Sorry #[5], see you are already commenting 🤙

signal_and_rage 2y ago

I just zapped #[3], it’s showing up in Damus.

Zaps are not broken.

If you hacked zaps to show a higher zap count, congrats.

The-FewBTC 2y ago

Followed 🫡⚡️

Carman 2y ago

This is just a problem in stacker.news. They could just enforce that the request has to be to the user's npub

nitesh 2y ago

I don’t think it’s just stacker.news issue. I have a feeling so many other services will show up with the same issue.

Carman 2y ago

Very easy solvable

nitesh 2y ago

How would providers verify pubkey? I don’t understand.

techjunkie 2y ago

The nostr pubkey of the user of the target note is in the nostr= part of the lnurl call and also needs to be setup on your stacker account? So it can be verified, no?

Fabian 2y ago

Yes stacker.news has the pubkey as part of setup for receiving zaps. Probably a bug on their side, its nothing that can’t be fixed

Egge 2y ago

But that’s not a requirement according to NIP57, right?

Egge 2y ago

No, as they don’t know it.

zoomoutpls 2y ago

key in your note is "show off"

we are having wild days right now, innovation is huge

wait for some weeks

if a note doesn't have signal in it, why should there be massive zaps

calma, nothing is broken

nitesh 2y ago

Dude. You’re missing the point. We can’t have holes like this, this could also be a vulnerability.

zoomoutpls 2y ago

o.k. then - I was missing the point.

Egge 2y ago

https://github.com/nostr-protocol/nips/pull/274

nitesh 2y ago

PR on NIP-57 to make it explicit so the issue doesn’t happen.

https://github.com/nostr-protocol/nips/pull/274

#[0]

Hunter ₿eaṩt 2y ago

Zap count is less interesting to me as a creator than the concept of reducing the friction to tipping someone for their specific contributions. I mean, duh, the number can be faked, this should be obvious, communicated, and not relied upon, but that's also missing the V4V forest for the trees.

𝖋𝖎𝖆𝖙𝖉𝖊𝖓𝖎𝖊𝖗 (¯`◕‿◕´¯) 2y ago

Why is that broken? Sats are fungible doesn’t matter where it ends up. Just like if you took $1 out of your shirt pocket and put it in your pants . It is still the same $1

nitesh 2y ago

You’re missing the point. There is also a PR attempting to fix the issue.

𝖋𝖎𝖆𝖙𝖉𝖊𝖓𝖎𝖊𝖗 (¯`◕‿◕´¯) 2y ago

What is the point? Who is actually losing or gaining sats?

nitesh 2y ago

https://github.com/nostr-protocol/nips/pull/274

𝖋𝖎𝖆𝖙𝖉𝖊𝖓𝖎𝖊𝖗 (¯`◕‿◕´¯) 2y ago

Oh you mean different usernames with the same pubkey like a bot. 🤔

fiatjaf 2y ago

The correct way to fix this is to have NIP-57 dedicated providers that discriminate the receiver of the zap from the "p" tag in the zap request event itself.

All these zap providers need is a URL, static for everybody. And they can even begin accepting zaps on behalf of people before users actually go there and sign up with their Nostr key to withdraw. They can also just forward the zaps to users' lud06/lud16 addresses as soon as they are received.

Arctic Fox 2y ago

How would that stop secondary accounts from sending to their primary ones? That would also force more centralization no?

fiatjaf 2y ago

You can't prevent that, but it is irrelevant. We should not care about zap counts, but we should care about having a public registry of a received zap that matches an actual payment, because that is necessary to make zaps useful for things other than tipping.

btcmaxi 2y ago

Zaps evolving from tipping to being used for non tip related things (advertising, help, impromptu jobs) is the next step. And I can’t wait 🤙💜

squeeki 2y ago

Agreed w/ #[5] ~ most people I know are fiat-reliant. They don’t know what a lightning wallet is, let alone a zap. My friends alone are just now investing in crypto.

People gotta learn how to crawl before they can think about walking. 🤙🏼

Creediator 2y ago

Ln payment is separate from registering of zaps in a Nostr note. The hand off process as you noted can be manipulated and one way to get around that would be to natively implement wallets in each of the clients like Damus and Nostrgram. There by avoiding Centralized NIP-57 verifiers. If we go NIP-57 verification route then in the future they want fees to support. Crypto is already full of middlemen trying to get paid for a function.

Carlos 2y ago

Words of wisdom.

There is no way to ensure a zap matches an actual payment.

At best, it can loosely represent a payment if both sender and receiver are honest. But then, they might as well use a more private payment method, like LNURL.

I suppose the best scenario zaps can aim for is an honest receiver + a fixed enough zap protocol, such that senders cannot fake it. Then build on top.

But IMO that comes with so much downside (centralization, newbies seeing zaps as LN standard, newbies being scammed by receivers who fake their zap counters, etc) that its not worth it.

techjunkie 2y ago

Carlos 2y ago

Begin accepting zaps on behalf of people before they actually register?

Sounds very much like:

fraud: noun

1. A deception practiced in order to induce another to give up possession of property or surrender a right.

fiatjaf 2y ago

Don't be stupid. The person would have to announce the provider URL in their Nostr profile.

Carlos 2y ago

True, then it should be fine

Carlos 2y ago

Still find that part shady for a bunch of reasons:

- What happens if the user changes providers, without having registered or withdrawn the accumulated zaps from the first provider? Are they lost? Will 1st provider allow user to register and witthdraw, now that his profile shows a different provider? If yes, sounds like manual step.

- When user changes providers, should the 1st provider still continue accepting zaps, even though user profile stops pointing to it? (Other users whose clients didnt get the latest profile changes may still see the old link in profile)