NIP-BC: Onchain Zaps (kind 8333)

[alexgleason]

This NIP introduces onchain zaps, as implemented by Ditto.

Big discussion here: https://ditto.pub/nevent1qgsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgqyz3ccj3j3lhzu756pyznc0qhe4umqhsu628c88cfef5j8k5jqwtks6w7gqw

[barrydeen]

NACK - I think this is gonna lead to just more p2tr dust utxos and confused users who can't move coins when we exit this low fee environment. Shouldn't be encouraging clients to implement this imo

[alexgleason]

ohhh now you don't like utxos??

[derekross]

NACK - I think this is gonna lead to just more p2tr dust utxos and confused users who can't move coins when we exit this low fee environment. Shouldn't be encouraging clients to implement this imo

The more that I've thought about this over the last few days, I agree with this take. Right now, this works based on the current price and current fee market. In the near future, this may not work if the fiat price increases and/or transaction fees increase. I like the proposal due to Zaps being hard to implement in a UX friendly manner that doesn't add centralization. However, I'm not certain if this is the best path forward.

[vitorpamplona]

lol, I was just thinking of re-making Bitcoin Core's Blockchain structure in Kotlin so that we can have the full chain on the phone to validate OTS records without depending on a block explorer... Now I have another idea :)

[alexgleason]

NACK - I think this is gonna lead to just more p2tr dust utxos and confused users who can't move coins when we exit this low fee environment. Shouldn't be encouraging clients to implement this imo

The more that I've thought about this over the last few days, I agree with this take. Right now, this works based on the current price and current fee market. In the near future, this may not work if the fiat price increases and/or transaction fees increase. I like the proposal due to Zaps being hard to implement in a UX friendly manner that doesn't add centralization. However, I'm not certain if this is the best path forward.

If you are not zapping $5, you don't understand this proposal. Zap $5. Stop being cheap. Would you drop 2 pennies into a guitar case? The whole mindset needs to shift.

[alexgleason]

The idea that if you got 100,000 likes it could convert into money for you is an idea from the dream that Nostr could actually replace Twitter. We're past that point. Nobody can actually survive off 21 sat zaps. It's not even worth the fee of converting Lightning into "real bitcoin"

[alexgleason]

Also, I suspect that people will be against this for ideological reasons when they have not even tried it. They think it can't work even though it's working right now.

[vitorpamplona]

Good thing that on nostr no one can stop anything

[jb55]

NACK in its current form. this would enable a mass utxo doxxing mechanism for everyone using these. let's do it properly with silent payments

[jb55]

I actually don't think the spam issue is that big of a deal since fees are low and the market will adapt to lightning or onchain depending on the fee market, but the privacy does concern me as it links utxos to nostr identities and that can be used to track the entire tx history of a person. would be an amazing resource for chainalytics

[alexgleason]

NACK in its current form. this would enable a mass utxo doxxing mechanism for everyone using these. let's do it properly with silent payments

This doesn't make sense to me. Zaps are already public. What are you worried about?

[barrydeen]

NACK in its current form. this would enable a mass utxo doxxing mechanism for everyone using these. let's do it properly with silent payments

This doesn't make sense to me. Zaps are already public. What are you worried about?

We don't know where the coins flow after the zap takes place, they don't consolidate with other utxos or show users exchange deposit address the way chain zaps will eventually flow

[fiatjaf]

This is incredibly short-sighted, but I think people should do it, because Lightning is stupid and miners have to be paid.

Also if we manage to bloat the UTXO set enough that could be promotion for Nostr, some people might even do a soft-fork to filter onchain zaps from Bitcoin.

[vitorpamplona]

Gotta love Claude:

Propose adding two optional tags to kind:8333:

["block", "<block-hash-hex>", "<height>"]
["proof", "<raw-tx-hex>", "<merkle-proof-hex>"]

Then a client with only the bitcoin headers chain (75 MB) can:

• Locate the header by block-hash (or by height).
• Hash the raw-tx-hex → txid; check it matches the i-tag txid.
• Walk the merkle proof up to the header's merkleRoot.
• Parse outputs from the raw tx, match scriptPubKey, sum.
• Confirmations = current tip height − block height + 1.

Per-event payload cost: ~1 KB

We only need block headers! Nothing else from the chain is touched — no transactions, no UTXOs, no scripts, no witness data, no mempool. That is a ~75 MB download for the entire chain, 1–10 minutes wall-clock, ~2 s CPU, ~72 MB on disk directly from the Bitcoin network.

Unless you expect more than 1M on-chain zap events on a session. At that time, the cost of downloading the 1-2GB of compact chain filters (Neutrino-style) is better than downloading 1M heavier onchain zap events.

[alexgleason]

@vitorpamplona added block and proof tags to the NIP

[jb55]

NACK in its current form. this would enable a mass utxo doxxing mechanism for everyone using these. let's do it properly with silent payments

This doesn't make sense to me. Zaps are already public. What are you worried about?

there is a huge difference. linking onchain zaps to utxos can leak someones entire bitcoin tx history. zaps reveal a single payment and nothing else (and its not even a proof, so its deniable)

[alexgleason]

Okay, I understand.

But the problem with silent payments is that you can lose money on relays, which is exactly what I was trying to avoid. My hope for this spec is that it can provide a path that is extremely frictionless and guarantees access to funds. We can only do that if your key is 1:1 Nostr to Taproot. All your payment data exists on the blockchain.

The way I imagine silent payments would work is that you'd tweak the recipient's pubkey and then send them an encrypted message with the tweak. This is already very similar to how nutzaps work, a major problem of which is that if you can't find the event on relays you can't get the money. I prioritize deliverability and access to funds in this design over privacy.

Silent payments could still be supported, but I don't think it should be the default path for the majority of users. It just needs to be clear to users that transactions are public, probably by surfacing onchain data in Nostr clients and in feeds, and letting them comment on it with NIP-73.

[jb55]

not sure what you mean you can lose the money on relays. with silent payments you can just put a silent payment address in your profile. we would then just need a mechanism for a bitcoin node to send an onchain zap signed by your key that verifies that the payment is correct, but it doesn't need to doxx any utxos.

we could have it send a private and public parts of the zap, where private shows more detailed information. the public part of the zap could have blinded amounts so its not as easy to trace onchain (or could even be optional)

[jb55]

another thing we should consider is zero-conf onchain zaps, like "tx pending". so you would have immediate feedback in apps. bitcoin core nodes have a walletnotify system for handling 0 and 1-conf bitcoin txs, so it would be perfect for this.

i already do private onchain zap notifications for all incoming txs using giftwrapped kind1s. standardizing this would be great.

[alexgleason]

Okay, I didn't really understand how silent payments work. That's mind blowing. 🤯 I'm still grokking it, but isn't it a downside that the client/wallet has to do a lot of work to figure out what your balance is? Chatting with Claude, you have to scan every block, so you can't just rely on an API like mempool.space. You need to either be running a full node or rely on a trusted server.