VitorPamplona
Vitor Pamplona

Nostr's Chief Android Officer - Amethyst Social

Public Key

npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

NIP-05 Address

Profile Code

nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppamhxue69uhkummnw3ezumt0d5qs6amnwvaz7tmwdaejumr0ds29vtzj

Publishing to

relay.primal.net/yonder-prism

Author Public Key

npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

Show more details

Last Notes

2026-05-21 02:30:08 UTC

Devs racing to deliver the latest Nostr feature https://npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z.blossom.band/a8c80ad3eca1703dc5e97b103f487eaaf51effb15a5a6bba64f2925eb3d53223.mp4

2026-05-21 00:56:50 UTC

- reply

I am still trying to figure out how to get only good outbox relays out of nip66 records that will accept posts from the user or good inbox relays, etc.

2026-05-21 00:06:09 UTC

- reply

Also FYI you are using nostr.band as inbox and outbox and that relay went bust a few months ago.
Maybe add nos.lol and nostr.mom to your public outbox and public inbox.
Since you are there, also reset your index and search relays to the defaults (just press the button)

2026-05-21 00:04:18 UTC

- reply

On-chain Gays

2026-05-21 00:02:56 UTC

- reply

Can you check if the Tor relays are connecting? We did a few changes on it and might have affected it.

2026-05-20 23:49:49 UTC

- reply

I think the issue is that most of the calendars are not geohash indexed :(

2026-05-20 23:44:40 UTC

It's back to the basics season

2026-05-20 23:37:27 UTC

- reply

Yes, we can do it

2026-05-20 23:30:37 UTC

Calendars are up!
#nevent1q…mhp6

2026-05-20 22:11:32 UTC

- reply

Yes. But maybe you are not in the right universe, though.

2026-05-20 22:07:36 UTC

- reply

@nprofile…0md0 says it's coming pre-installed to all Graphene OS users...

2026-05-20 22:00:07 UTC

- reply

Pretty cool, but I can see my transactions on Amethyst so mine is better :)

2026-05-20 21:35:08 UTC

- reply

one day...

2026-05-20 21:26:29 UTC

- reply

So, that is what people do when they take a break from Nostr... interesting... :)

2026-05-20 20:12:20 UTC

if you don't want your onchain zaps on Amethyst, you will be able to hit the zap the devs button and donate it to the devs.

2026-05-20 18:51:37 UTC

- reply

they can just check the chain for outputs.

2026-05-20 18:02:23 UTC

- reply

You can just burn them if you don't want. Some clients are already adding it.

2026-05-20 18:01:40 UTC

- reply

Without zaps, then? I can make a setting

2026-05-20 17:53:04 UTC

- reply

My tax agency is already looking at zaps in the lightning network. So, I am already having that fun.

2026-05-20 17:51:09 UTC

- reply

What should nyms do then? Mix it?

2026-05-20 17:34:31 UTC

How is this for guidance:
Your Taproot address is derived from your Nostr public key, so anyone who knows your npub can see this wallet's balance and transaction history on the blockchain.
To preserve your privacy, fund and drain this wallet from and to non-private accounts, like exchanges. Never mix these funds with your cold wallets, and treat them as money you can lose, since anyone in control of your nsec can spend it.

2026-05-20 17:24:41 UTC

- reply

We need a new name: zapalittlewithlargeamounts

2026-05-20 15:51:45 UTC

- reply

Are you still using those `w` params as opposed to kind 10133?

2026-05-20 15:29:11 UTC

Maybe we should rename the on-chain wallet to "Social Wallet".. In that way, everybody knows funds here can be seen and tracked by zaps. Use to have social fun not anything else. Drain it frequently in a private way, or just send it forward to other nostr creators.

2026-05-20 15:25:57 UTC

- reply

Not yet, but we do support Payment targets that does include most other chains and even regular bank accounts / venmo / cashapp / etc.
They are not zaps though. We don't generate a Zap event on Nostr when that happens.

2026-05-20 15:24:39 UTC

- reply

Silent Payments only hide the full balance. But people will still be able to collect all silent payments with a zap event and merge that into your "balance" in a similar way they do it with lightning right now.

2026-05-20 15:17:17 UTC

- reply

I think the problem is that people can see the balance if people dont move those UTXOs. Because in the end, you can get all the zap events on lightning and just rebuild a chain, since most people just re-circulate those zaps back into nostr. It's not a verifiable chain, but it is a chain nonetheless.

2026-05-20 15:13:05 UTC

- reply

The problem with public key cryptography is that anyone can lock money, in any chain, to your nsec. It doesnt even matter which curve we use as Nostr. Anyone can always send you any token or coin from any chain. There is not going to be any future where that doesn't happen. And in many cases, the sender can actually proove that you are the only one in control of those funds, like it or not.
Which means that you can't disallow people from sending you money in your key in the same way that you cannot block say Iran from dusting your UTXOs with tained coins that you are forbiden to have a relationship with.

2026-05-20 15:01:46 UTC

On-chain zaps made me rethink about the main reason we do **zaps** in the first place.
Zaps are supposed to be for the social fun. Its purpose is to be seen, to be public. "Private zaps" make little sense because they are just regular transactions, on-chain or not. Nobody can have any social fun with them.
The goal of the "Zap" (on-chain or not) is to publicly show your fiancial support to the creator to everybody else. Now, if the fun is not there anymore or you are scared about it, you should not even try to participate in the zap economy. There are other signals you can send to have fun online, including regular transactions (the old tip jar, payment targets, etc).
For the on-chain zaps future, we need to keep reminding ourselves that feature only works if we are using it correctly: to have **social fun**. It's not a regular wallet. It's a source of fun, pride and real signals that just so happens to use on-chain money. There are multiple ways to code it, with Silent Payments and all, but the purpose is to have fun with others. It is to be public.
So, I fully support this initiative. And Amethyst will support removing anything Zap in such a way that you can just do regular private transactions if you want. You cannot control what others do, but your side will be configurable.
#nevent1q…vzau

2026-05-20 14:22:16 UTC

- reply

I might need to get my claude to walk through your client to make sure we are fully interoperable if people remove zaps from Amethyst and add the payment targets button. Where is the code again?

2026-05-20 12:09:35 UTC

GM to everyone but those who are financially incentivized to keep Bitcoin as complicated as possible so that you can never run your own simple wallet and is required to either pay for a service or use a free one that sells your data to the highest bidder through six layers of C-corps.

2026-05-20 02:48:05 UTC

https://npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z.blossom.band/81bcf6a9a6adc454c867d478eb961f68d15ff97f3c8e012023238b3d488f3657.jpg

2026-05-19 21:54:03 UTC

Full support for NIP-52 calendars incoming!
https://video.nostr.build/27a948b2c35879c8fc35c9bc96cf71c5d1009cc09f4e35d0460b596846186bcf.mp4

2026-05-19 19:00:59 UTC

- reply

I use Zeus. I like Zeus. But it's no where near good enough and the channel management is an absolute shitshow. I just want an on-chain wallet. Ligthning is probably too complicated for most users anyway.

2026-05-19 18:37:46 UTC

- reply

That's how Bitcoin Core feels like too.

2026-05-19 15:16:43 UTC

- reply

Yep, the other stuff is more todo with untrusted senders (like anon zaps) faking the transaction, and/or sender and receiver colluding or the receiver building up a special large transaction that actually happens to himself just to show off. It's our own version of round-tripping fraud.

2026-05-19 15:12:47 UTC

- reply

In such a way that nobody else sees the zap, only receiver and sender? It's fine but, then it's not a zap in my mind, it's just a "tip jar" like we used to do in the old days.
Zaps are cool exactly because you can see people liking a note. It's the social component that is key. I think it will be sad to see it disappear. But it is more private..

2026-05-19 15:05:27 UTC

- reply

yep.. navigating those as well. The amount is a problem because given the time + amount, you can quickly find the transaction. So, I dont know if we will be able to ever publish the amount for others to see like we do with ln zaps.

2026-05-19 15:04:23 UTC

- reply

we can actually tie them for the owner of the nsec only.. the public can compute a silent payment address and send BTC to anyone without having that person setup an SP wallet. For the public, it will just be a new UTXO for each zap.

2026-05-19 15:02:44 UTC

- reply

we are testing silent payments already.. coming up

2026-05-19 12:38:27 UTC

Worse than this is the fact that today we don't have a single good Bitcoin native wallet on mobile. Everything goes through somebody's services or looks like it was made in Win95. They completely abandoned the core purpose of the Bitcoin idea.
#nevent1q…s496

2026-05-19 12:13:38 UTC

- reply

In my experience, we only have bad ideas. We are just figuring out which one is the least worse if them.

2026-05-19 12:11:45 UTC

I understand Bitcoin from a technical level since 2012 or so.. since then we have seen very cool and complicated signature types, lots of scripting wars, sidechains, lots of tokens, NFTs, VMs, OP code wars... Etc..
Just to realize what we always wanted is to create a simple wallet to receive and send without any third party.
GM.

2026-05-19 11:57:29 UTC

Yes, let's all use a custodial mint. What could go wrong? 😅 Mints disappear faster than 6 confirmations.
#nevent1q…2g59

2026-05-19 07:44:46 UTC

- reply

Its about the UX. Everything else we have tried has absolutely sucked big time for users. This is the first time in 4 years that we found a good experience out of anything related to Bitcoin on nostr.
Lots of problems, yes. But you can't deny how cool it is and how fast sats are moving, even on chain.

2026-05-19 07:38:46 UTC

- reply

Lots of things in nostr are retarded. We have literally one of the worst protocols ever made from an engineering standpoint. So forgive for not following the norm. The UX alone of having a quick hot wallet without relying on custody or channels or vendor APIs is beautiful. If we can fix the privacy issue, it will be better.. but as it stands might more sense than you think at first glance.

2026-05-19 06:55:36 UTC

- reply

Yeah. I walked over those papers (my PhD is in computer graphics... I spent 10 years developing GPU algorithms). There is one that claims full scan in 1 hour or so. That's good enough as fallback. Even if it takes 24 hours, it is still good enough because it is just fallback.

2026-05-19 06:27:48 UTC

- reply

I have, I see the issue.. but you are vastly exaggerating it.

2026-05-19 06:25:51 UTC

- reply

I can still scan.. I just don't need to do it in realtime.

2026-05-19 06:23:13 UTC

- reply

?
Block headers + per-receipt merkle proof + one elliptic-curve check is the entire verification path. The cost is roughly: 70 MB of Bitcoin headers, a few hundred lines of merkle/header/tx-parser code,

2026-05-19 03:18:30 UTC

Some people take themselves too seriously.
Others do not nearly enough.
And then there are the retards of Nostr.
Love you all.

2026-05-18 21:22:32 UTC

- reply

yep. Since LLMs are so freaking massive in size and memory use, we are likely to need the OS to keep one LLM model around and likely in memory for speed so that all apps can use the same model.

2026-05-18 21:10:47 UTC

- reply

Also, are you guys doing local LLM work? I think this could be quite important moving forward.

2026-05-18 21:03:25 UTC

- reply

Sir... there is no quality control on Nostr.

2026-05-18 20:42:11 UTC

- reply

yep... I am still wainting on the Silent Payments proposal. Looks like we have about 5 competing ways forward.

2026-05-18 18:52:00 UTC

- reply

Ohh.. we need to add a send to any BTC address...
Though maybe people dont want that function too since it would "pollute" other addresses out there.

2026-05-18 16:17:07 UTC

- reply

Yep, I still dont know what to put in the zap event, though. Because if I put the transaction, anyone can trace those UTXOs to the keys. If I don't anyone can fake zaps..

2026-05-18 15:48:02 UTC

Would people be happy with this way of automatically generating SP addresses for any npub out there?
### The address generation, end to end
**Inputs**
- `npub_pubkey`: 32-byte x-only secp256k1 point (BIP-340 convention, implicit even-y)
- `npub_privkey`: the corresponding 32-byte scalar (recipient only)
**Sender side (anyone with the npub)**
```
P_base = lift_x(npub_pubkey) // 33-byte point, even-y
tweak = int(tagged_hash("nip-XX/sp-scan", npub_pubkey)) mod n
B_spend = P_base // 1:1 with the npub
B_scan = P_base + tweak · G
```
Optional override: if the recipient has published a kind 10336 event carrying a hardened `B_scan_hardened`, use that instead of the derived `B_scan`. Senders that always paid the unhardened address before will keep matching, because the recipient's hardened wallet also runs detection against the unhardened `b_scan`.
**Address encoding (BIP-352 standard)**
```
payload = version(0x00) || compress(B_scan) || compress(B_spend) // 1 + 33 + 33 = 67 bytes
sp_address = bech32m("sp", payload) // → "sp1q…"
```
**Recipient side**
```
b_spend = npub_privkey // = identity privkey
b_scan = (npub_privkey + tweak) mod n // unhardened
or
b_scan = int(tagged_hash("nip-XX/sp-scan-hardened", npub_privkey)) // hardened (override)
```
**Parity / lift_x note.** The npub is x-only; SP math is on full points. Convention: always `lift_x` with even-y. The per-output key `P_k = B_spend + t_k · G` is the *internal* taproot key — the output script uses its x-only form (`P_k`'s x-coordinate as the taproot output key, no script path). Standard BIP-341 normalization applies.
That's the whole address spec: one tagged-hash tweak, one point addition, one bech32m encoding. No new event kinds required for the default case; one optional replaceable event for the safe-delegation override.
---
### Privacy features
- **On-chain unlinkability.** Every received output is a fresh-looking taproot key. A chain analyst with the npub can compute the SP address and *still* cannot identify any output as belonging to it (CDH-hard without `b_scan`). The recipient's income stream is invisible from chain alone.
- **No sender-recipient interaction.** Recipient can be offline indefinitely; sender pays using only the npub. No address handshake, no LNURL callback, no relay roundtrip required to pay.
- **Address is publicly safe to share.** Publishing the SP address (or letting it be derived from the npub) leaks nothing on-chain — it's just two public points, and observing them doesn't break CDH.
- **Light-client scanning preserves recipient privacy.** Tweak-index servers serve generic per-block public data computed from chain only; the recipient runs the final match locally with `b_scan`. The indexer never sees the scan key or learns which outputs are the recipient's.
- **Hint events (gift-wrapped) decouple discovery from public linkage.** The on-nostr receipt for fast detection is sealed with NIP-17, so relay observers see neither the sender, the recipient, nor the txid.
### Privacy limitations
- **The address is a public 1:1 function of the npub.** Anyone who knows your npub can compute your SP address — and therefore the social graph "this npub has an on-chain payment surface" is fully public. There is no unlinkable subaddress per payer; the trade for 1:1 is loss of identity-vs-address separation. (BIP-352 *labels* could provide per-payer subaddresses, but using them means each subaddress needs its own out-of-band publication, breaking the 1:1.)
- **The unhardened scheme makes scan delegation unsafe.** `b_scan` minus the public tweak equals `npub_privkey`. Any wallet shipping this MUST refuse to export the unhardened scan key. Safe delegation requires the recipient to publish a hardened override and hand out *that* `b_scan_hardened` — a manual opt-in step users will mostly skip.
- **Public hint events would destroy the on-chain privacy.** Gift-wrapping is not optional. If a client implementation defaults to public `["p", recipient_npub]`-tagged hint events, anyone querying relays can reconstruct the full receipt graph from txids in those events. This is the single biggest implementation footgun in the design.
- **Sender always learns one output.** Whoever made a payment knows exactly which output they created — including its key, amount, and txid. Standard for any payment system; mentioned for completeness. They cannot extrapolate to *other* payments the same recipient received.
- **Tweak-index queries leak metadata at the IP layer.** Even though the server doesn't see `b_scan`, it sees "this IP is requesting block tweaks." Mitigations are network-level (Tor, mixing, batching) and outside the spec.
- **On-chain amounts are public.** Bitcoin baseline. Once a tx is located (by anyone who learns the txid through whatever channel), the amount is visible. SP hides *which* tx, not *what was in it*.
- **Timing correlation across nostr and chain.** Even with gift-wrapped hints, an adversary watching both relays and the mempool can correlate "encrypted nostr event T+Δs after tx confirms" to link payments to recipients statistically. Mitigations are batching/delays/cover traffic, with the usual cost.
- **Override rotation is cache-sensitive.** Republishing kind 10336 with a new `B_scan_hardened` creates a window where senders see different versions; require `valid_from` plus an overlap period during which both keys remain detectable. Otherwise in-flight payments can land on a key the recipient no longer scans for.
### One-line summary
A nostr npub becomes an `sp1…` address via one tagged-hash tweak — sender-derivable, recipient-private, on-chain unlinkable, and nostr-unlinkable as long as hint events are gift-wrapped. The two structural costs are: (1) the npub→address mapping is public, so the address can't double as a private identity, and (2) the unhardened scan key is identity-equivalent, so scan delegation requires the opt-in hardened override.

2026-05-18 15:31:50 UTC

- reply

Which wallet do you want me to integrate? Everything I tried has issues: either the implementation is buggy, or there is no channels available, or when they do connect zaps/lightning transactions fail half of the time. This is even before all the KYC / trust requirements that each API has.
I already integrate with NWC, so people can use any wallet they want. But that is clearly not enough.

2026-05-18 15:29:37 UTC

- reply

I agree with all of these. To me things boil down to what is the easiest way to convey value between nostr users that leak the least amoung of information?
Maybe identifying on-chain transactions in the same way we identify lightning transactions on the zaps today is ok for most people... idk, people have been using it, so.. I assume it's not a problem.
What onchain zaps are solving is really the wallet setup, which is the biggest pain point on nostr right now. Having a place to send zaps even before the receiver is fully set up is key. The rest can change and use different privacy assumptions as they go.
We will probably going to settle for something in between, not fully private, but not fully public.

2026-05-18 15:23:31 UTC

- reply

Why do you think the problem of creating a wallet is made up? That's quite literally one of the main complains of Nostr across all clients. So much so that the answer has been let's use custodial solutions or KYC everyone to make shit work.

2026-05-18 15:18:11 UTC

- reply

That sounds like NIP-72 communities and/or NIP-28 chats. Both use an event as anchor to the discussion.

2026-05-18 15:17:13 UTC

- reply

I am not wrong, I am just "limited by the technology of my time". As soon as somebody makes something better, I will merge. But that has not happened yet. We will see.

2026-05-18 15:12:55 UTC

- reply

This is good, but it doesnt solve the problem we are trying to solve: it's too hard to create a lightning wallet to begin with.

2026-05-18 15:10:59 UTC

- reply

Are you bulding a "no-zap" client to combat the "only zaps" ones? :)

2026-05-18 15:10:02 UTC

- reply

Yes, I was talking about ZK proofs. That's the only way I see being able to please those complaining about on-chain traces forever.
Either that or we go back to the mess of trusting that zaps happened, like you described. Which is a massive problem today since it is quite easy to fake a zap and most clients offer Zap counts as a way to give reputation to a post in the feed.

2026-05-18 15:02:28 UTC

- reply

Não deu nada ainda moço...

2026-05-18 15:01:53 UTC

- reply

It's hard to say .. Most of the people complaining against onchain zaps are actually complaining about the idea of zaps themselves: a public signed event linking sender, receiver, amount for everyone to see.
I'd say yes. Zaps are always public. But that means that not even Silent Payments can fix this because it will link all individual silent transactions to the sender and receiver.

2026-05-18 14:46:41 UTC

To the Math wiz out there, the ideal solution would be an SP address that can be derived from the pubkey directly in such a way that nobody needs to "set it up" with a supporting client.
The goal is to send money to any npub without having to rely on whatever they are using as a client.
Of course, that would only make sense if the same derivation blocks the public from combining all silent payments to an npub into a single balance.
Zap events then would have to contain a proof of a bitcoin transaction without identifying it directly. Otherwise, anyone would simply merge all Zap Events to find somebody's balance on chain.
Let's hope somebody can find a solution here.

2026-05-18 14:36:49 UTC

Maybe this time around we will actually fix our longstanding UX issues in Nostr. We will see.
Let's just hope one of new Silent Payments NIPs are not worse than coordinating payments via NWC or having to trust a mint or a monitor.

2026-05-18 14:29:50 UTC

We need to do this again every friday
#nevent1q…dx4m

2026-05-18 14:27:27 UTC

"Nostr feels live again" is the mood we need for mondays.

2026-05-18 14:16:34 UTC

- reply

Looking forward

2026-05-18 12:52:49 UTC

- reply

Hum... Weird, let me see if there is an API issue. Are you behind Tor or VPN?

2026-05-18 12:45:58 UTC

- reply

Neither does your onchain wallet will have 1B in it. This is a nostr wallet, not your cold storage.

2026-05-18 12:44:47 UTC

- reply

Why not, what happened?

2026-05-18 12:44:32 UTC

- reply

Lots of proposals made to me don't work. So, I am still waiting.

2026-05-18 12:36:20 UTC

- reply

If you think it's false equivalency, you are in for a very disappointing ride with nostr.

2026-05-18 12:35:42 UTC

- reply

Yep, but they can also take your phone to use the lightning wallet in it to do the same. So, it's not changing much from that perspective.

2026-05-18 12:34:32 UTC

- reply

Maybe. But again that would be awesome if it actually happened. People finally using Bitcoin again.. and not this shit that is today.

2026-05-18 12:30:53 UTC

- reply

You can't change your npub as well. Just FYI.

2026-05-18 12:29:13 UTC

- reply

It's not that they couldn't, they didnt want to pay for it. Fees have never gotten so high that people couldnt move their money.

2026-05-18 12:27:07 UTC

- reply

Yep, every zap is fully traceable. You can pretty much assemble the entire chain of zap events for Nostr since the early days. And we don't even have blockchain.

2026-05-18 12:26:10 UTC

GM on-chain Nostr! The debate continues. No actual proposals were made yet. Lots of talk.. little action.

2026-05-18 12:23:49 UTC

- reply

Wouldn't that be awesome if it did?

2026-05-18 12:22:41 UTC

- reply

We could do it in such a way that receiving and sending in and out of Nostr is harder if that is the problem. So, once in, the money stays rotating between nostr keys in an identifiable way like what zaps do. Then in the end, it leaves via a mixing service for instance.
Anyway, lots to work yet.

2026-05-18 12:17:34 UTC

- reply

Why? Don't you think Nostr can succeed? It doesn't take much to make a good mixing service..

2026-05-18 12:14:34 UTC

- reply

So, who are the users that you estimate sent to Derick?

2026-05-18 12:09:33 UTC

- reply

Let's do it.. send a NIP on which way to do it that actually works. Right now a bunch of people are talking but nobody is doing shit. We need actual proposals/implementations from people that know what they are talking about.

2026-05-18 12:06:27 UTC

- reply

We can make all zaps go through a mixing service before coming out to an exchange if that is the problem.

2026-05-18 12:05:00 UTC

- reply

Correct. My goal is to make it available. Each user then decides if they want to use it or not.

2026-05-18 00:57:08 UTC

- reply

Yep, I have tested them all. They all suck. But I will implement silent payments as soon as anyone actually makes it work.

2026-05-18 00:41:35 UTC

- reply

Could work, but silent payments need a trusted monitor to the best of my knowledge. Also, right now there is only one wallet with silent payments. Everybody else is alpha code, full of bugs.

2026-05-17 23:20:49 UTC

- reply

@nprofile…xcpk it think there is a bit of confusion with the UI

2026-05-17 23:07:44 UTC

- reply

But he is not the only one. Lots of people are already using it

2026-05-17 22:22:01 UTC

- reply

See if resetting your index relays and search relays help. Just press the buttons on the relay list screen.

2026-05-17 21:02:40 UTC

- reply

Lol, I will post as many times to your replies as I want. Welcome to Nostr.