Nostr notes by SatsAndSports

I first started my Raspberry Pi node in August. It was Core v26 ...

2026-06-05T07:03:54Z

In reply to nevent1q…tudg
_________________________

I first started my Raspberry Pi node in August. It was Core v26

Literally the first thing I did was increase datacarriersize to 1MB and lower the fee rate

So don't assume the pre-30 nodes have any problem with v30

I would encourage encryption more broadly, to make it easier for ...

2026-06-04T20:49:53Z

In reply to nevent1q…xumt
_________________________

I would encourage encryption more broadly, to make it easier for blossom servers to just randomly host any data

You might worry this would lead to repetition of data. But one idea is to encrypt the data with an encryption key that is derived from the hash of the *cleartext* data. This would give us many of the benefits of encryption, but wouldn't encourage duplication

Sorry. I just made it up, that's kinda what I want But ...

2026-06-04T19:02:04Z

In reply to nevent1q…teq0
_________________________

Sorry. I just made it up, that's kinda what I want

But actually, there is a BUD: https://github.com/hzrd149/blossom/blob/master/buds/10.md

Unfortunately, it doesn't mention encryption

When I paste an image into my nostr client, I believe it should encrypt the data before pushing and then include the decryption key in the URL somehow (best to do this after a hash, as we do not want that to be sent to the blossom server)

Nostr event nevent1qqsy7v4fdq45reekz0sc9rfpqgts4q8lkmmqe5meta0jxpekyd5cl9qzyqfwuq73z6z2zfwas7lg08pgryzpt03l8v0v566w6apm6a8lmzqwv7eqg4y

2026-06-04T16:58:39Z

In reply to nevent1q…p9as
_________________________

blossom:<sha256>#<optional_decryption_key><optional_relay_hints>

Nostr event nevent1qqs08epspnhq2gddhn747khsf4mcf6krd60ndhwushz9hqw8ckgks4czyqfwuq73z6z2zfwas7lg08pgryzpt03l8v0v566w6apm6a8lmzqwvcrhn23

2026-06-03T21:33:54Z

In reply to nevent1q…849q
_________________________

> Is the coinbase a secret from the miners? No, I'm not ...

2026-06-03T20:32:19Z

In reply to nevent1q…8c5a
_________________________

> Is the coinbase a secret from the miners?

No, I'm not proposing that

It's just an observation that the secret key behind the coinbase output (for simplicity, I'm assuming just one coinbase output) is something that the mining pool will not want to share with the hashers, as that would allow the hashers to steal the funds

And because this secret key is secret, we can require the pool to provide a signature that the hashers can't create, and this means that the miner (not the hasher) will be the first to learn if a given block is a winning block

In general though, I think I agree with you. But if it becomes a problem, it might be difficult to get consensus to activate

I remember reading Meditations as a teenager, then I gradually ...

2026-06-03T14:16:19Z

In reply to nevent1q…5ed7
_________________________

I remember reading Meditations as a teenager, then I gradually forgot about it

But it, and stoicism, keep coming up. Including on some podcasts that I listen to

(Also, I'm going through mild caffeine withdrawal now, so I need to be stoic about the pain 🙂)

I find the opposite actually. I've always loved coding, and I ...

2026-06-03T05:10:08Z

In reply to nevent1q…8jap
_________________________

I find the opposite actually. I've always loved coding, and I love it more than ever thanks to AI

> yet this makes the act of building software less fun for people who actually enjoy writing code

Any time I realize I've designed an interface badly, or otherwise the code needs some sort of redesign, the AI can update it all for me quickly and quite reliably. And if it fails, I kinda like intervening and breaking the task down into multiple steps so that we can do it correctly

I'm able to think more clearly than every in terms of the interfaces and architecture and so on.

Mostly focussing on stress testing of MONAD, especially of the ...

2026-06-02T14:56:57Z

Mostly focussing on stress testing of MONAD, especially of the networking, in recent days.

Turns out that my little laptop can't take 250,000 TCP connections attempting to connect to the same ip_addr:port at the same time 😀. So I'll bind lots of listeners across 127.x.y.z

quoting
nevent1q…vl4x
I've worked out how to add Tor-style hidden services (.onion) to MONAD, and have coded some of the logic already

A more useful evening than following Nostr drama 😂

nevent1q…6vzw

I don't really mind that "attack" is possible. The ...

2026-06-02T13:02:19Z

In reply to nevent1q…9n77
_________________________

I don't really mind that "attack" is possible. The problem is that the attack is more valuable to big miners than it is to small miners

And in Bitcoin, it's important to help the small miners, relative to the big miners

A small notary/miner could burn 10 sats and charge 11 sats, taking 1 sat as the fee

A large miner could do a fake burn where they really spend only 7 sats, but they can notarize it as 10 sats. They could charge 9 sats for this notarization

The large miner can then undercut the small miner and make a bigger profit. The mitigation is to either send the funds to an OP_RETURN or send it to the very far future

I'm hoping that people will be incentivized to run more ...

2026-06-01T20:10:24Z

In reply to nevent1q…0s4c
_________________________

I'm hoping that people will be incentivized to run more relays, due to the cashu payments, and therefore it'll be fast

I think bandwidth won't be a problem, but latency might be when this is deployed across various devices spread across the internet (and across the FIPS mesh)

I think I can keep the number of round trips down to a minimum, to enable faster establishment of connections. But we'll see what happens when I finally fully implement, and test, it

All Cashu devs have been very proactive in being transparent ...

2026-06-01T19:33:30Z

In reply to nevent1q…35lw
_________________________

All Cashu devs have been very proactive in being transparent about the rug risk

It is - as you say - "obvious"

In any walk of live, repetition is boring. Do you really think that you were the first person to ever ask this?

Ask new and interesting questions, don't repeat the same questions that have been asked *and transparently answered* a hundred times already

I've worked out how to add Tor-style hidden services (.onion) ...

2026-06-01T19:27:12Z

I've worked out how to add Tor-style hidden services (.onion) to MONAD, and have coded some of the logic already

A more useful evening than following Nostr drama 😂

quoting
nevent1q…6vzw
A random update on what I've been doing. This project isn't quite ready, but I'm very happy with my progress since I got back into this about ten days ago. I hope to ask for testers soon:

MONAD is a system with some similarities to Tor, and also to the everyday usage of the word "VPN", a system to allow you to access websites and systems while obfuscating your location, e.g. access Netflix from another country. I started it as a demo for Sovereign Engineering (nprofile…0yke) and now I'm going to try to get a usable system out

It's funded by Cashu, specifically by the Spilman channels, so that you can easily pay tiny amounts (one sat, or even one millisat) as needed to keep the stream alive. This helps privacy because it makes it easier to use a different payment for each session, so that the relay operator can't easily link your sessions together

Like Tor, you can select multiple relays in a chain for extra privacy, and you pay each one separately. It's onion routing, with sessions nested inside each other

Lots of encryption of course, using secp256k1. And blinded paths already implemented as an option, in order that the client doesn't know the IP address (or FIPS address) of every relay fips (nprofile…the5)

A few days out of date, I'll update it fully when it's ready for some testing:
https://github.com/SatsAndSports/MONAD

Cashu (nprofile…8aw4)

Whether it's 21 sats or 21,000,000 sats doesn't matter ...

2026-06-01T15:42:08Z

In reply to nevent1q…275k
_________________________

Whether it's 21 sats or 21,000,000 sats doesn't matter

Noobs will sweep them to an exchange, or link them with their cold storage, or otherwise spend them in an anti-private way

For noobs, we should have sane default behaviour. Cashu is king for zaps and ease of use

This doesn't seem like much of a conspiracy Some people are ...

2026-06-01T15:27:41Z

In reply to nevent1q…6m7k
_________________________

This doesn't seem like much of a conspiracy

Some people are donating *their own money* to freedom tech in a way that you think is non-optimal

So what?

If the burn sats went directly to the miner within the same ...

2026-06-01T15:12:52Z

In reply to nevent1q…sam7
_________________________

If the burn sats went directly to the miner within the same block, i.e. they were burned by giving them away as miner fees, then there is an attack that any miner - large or small - can easily do

(Given that this problem exists, the notarization proposal uses a different approach)

Any miner, in the naive system, could trivially do a "fake burn", by paying sats to themselves

As discussed, a mitigation is to delay them until the future

If the burn sats are moved a small amount into the future, then large miners have an advantage over small miners, as the large miners can still do a (small) fake burn because they know some of the "burned" sats will come back to themselves;

If a mining pool has 40% of hashrate, they can announce a service where you give them 10 sats and they will "fake burn" 15 says. They'll get 6 of those sats back

That's why a few of us have advocated from the start that it should be sent decades into the future, using CLTV

Getting hooked on coding freedom tech again is cool and all. But ...

2026-05-31T23:43:20Z

Getting hooked on coding freedom tech again is cool and all. But now it's well after midnight and I'm too excited to sleep

I'm enjoying using state machines. Old state goes in with an ...

2026-05-30T17:38:43Z

I'm enjoying using state machines. Old state goes in with an Event (e.g. payment received), and a new State and a list of Effects (e.g. update balance) comes out.

I really feel that AI is improving the quality, not just the quantity, of my work. When I realize The Right Way™ to do something, my agent can just do the refactor easily.

All the quality things that some devs ignore (testing, documentation, specs, ...) are also really good at educating the agent about how to write good code

quoting
nevent1q…h9pr
A random update on what I've been doing. This project isn't quite ready, but I'm very happy with my progress since I got back into this about ten days ago. I hope to ask for testers soon:

MONAD is a system with some similarities to Tor, and also to the everyday usage of the word "VPN", a system to allow you to access websites and systems while obfuscating your location, e.g. access Netflix from another country. I started it as a demo for Sovereign Engineering (nprofile…0yke) and now I'm going to try to get a usable system out

It's funded by Cashu, specifically by the Spilman channels, so that you can easily pay tiny amounts (one sat, or even one millisat) as needed to keep the stream alive. This helps privacy because it makes it easier to use a different payment for each session, so that the relay operator can't easily link your sessions together

Like Tor, you can select multiple relays in a chain for extra privacy, and you pay each one separately. It's onion routing, with sessions nested inside each other

Lots of encryption of course, using secp256k1. And blinded paths already implemented as an option, in order that the client doesn't know the IP address (or FIPS address) of every relay fips (nprofile…the5)

A few days out of date, I'll update it fully when it's ready for some testing:
https://github.com/SatsAndSports/MONAD

Cashu (nprofile…8aw4)

Really nice talk. It has lots of interesting analogies to link ...

2026-05-29T20:15:50Z

In reply to nevent1q…qzqy
_________________________

Really nice talk.

It has lots of interesting analogies to link technical details with interesting ideas, and I think a less technical audience can still find it equally thought-provoking even if they are fuzzy on the technical details

It's a great idea, and I hope it catches on It's ...

2026-05-29T17:15:05Z

In reply to nevent1q…wqxh
_________________________

It's a great idea, and I hope it catches on

It's important that the sats are either burned in a conventional way, like an OP_RETURN, or sent to miners *in the future* via anyone-can-spend outputs that are timelocked for a long time

Last time I checked, Thomas's implementation does the long-term lockup, but I'm not sure of the status of the paper.

The reason we can't burn them by giving them *immediately* to today's miners is that the miner could simply advertize a notarization service that says "give me 10 sats and I'll do 'fake notarization' for 1 million sats" where the miner just pays fees to themselves

> So please redirect your private-key-sharing rage to the ...

2026-05-29T16:24:25Z

In reply to nevent1q…kj62
_________________________

> So please redirect your private-key-sharing rage to the authors of BIP352 who introduced the concept in the first place.

This is not a valid complaint Tim. You can't blame the authors of BIP352 for this

In the conventional usage of BIP352, the recipient generates both keys separately. They *might* choose to share *one* of those keys with a third party scanning service

That's cool. It simplifies things for the recipient, by allowing the third party to see all the transactions

The problem with your proposal is that, if the scan key is shared with a third-party scanning service, that service can also steal the funds

Your proposal has certain pros and cons, like every proposal. And that's fine, you are free to promote your idea. But it's not appropriate for you to deflect by blaming the authors of BIP352 for flaws introduced by you

This is an extraordinarily long. It could be rewritten to be much ...

2026-05-29T15:59:00Z

In reply to nevent1q…rr0l
_________________________

This is an extraordinarily long. It could be rewritten to be much more concise. There is considerable repetition

_"Private fund control: only the holder of the matching private spend path can sweep or spend the detected outputs."_

This sentence is misleading. You should warn that - in your scheme - anyone that knows the private *scan* key is able to immediately compute this private *spend* key and therefore they can steal the funds

You could rewrite your entire proposal into about five sentences, and that would be enough to fully explain the system, including this serious issue about how the *private scan key* must not be shared with any third-party scanning service

Make on-chain payments by making a Lightning payment to a swap ...

2026-05-29T15:48:19Z

In reply to nevent1q…5ce9
_________________________

Make on-chain payments by making a Lightning payment to a swap provider such as Boltz so they make the on-chain payment for you

With this, none of your on-chain UTXOs are involved in the payment

(There are fully trustless variants of this, where the swap operator can't take your lightning payment without giving you the same preimage that you can then use to cause the on chain payment to happen)

Hi Tim, For people that can't run their own Frigate server ...

2026-05-29T15:41:05Z

In reply to nevent1q…crry
_________________________

Hi Tim,
For people that can't run their own Frigate server and who are determined to receive via SP, it can make sense for them to share the private *scan* key to a trusted operator that can scan on their behalf

But we must ensure that the users don't use any scheme (for example, your scheme) which will allow the scanner to derive the private *spend* key (and nostr identity nsec) from that private *scan* key

Hzrd's system might be workable instead of yours, because his scheme requires the recipient to advertise an SP address on nostr

Lots of tradeoffs here, but their are some schemes that are simply not credible

A random update on what I've been doing. This project ...

2026-05-29T12:06:36Z

A random update on what I've been doing. This project isn't quite ready, but I'm very happy with my progress since I got back into this about ten days ago. I hope to ask for testers soon:

MONAD is a system with some similarities to Tor, and also to the everyday usage of the word "VPN", a system to allow you to access websites and systems while obfuscating your location, e.g. access Netflix from another country. I started it as a demo for Sovereign Engineering (nprofile…0yke) and now I'm going to try to get a usable system out

It's funded by Cashu, specifically by the Spilman channels, so that you can easily pay tiny amounts (one sat, or even one millisat) as needed to keep the stream alive. This helps privacy because it makes it easier to use a different payment for each session, so that the relay operator can't easily link your sessions together

Like Tor, you can select multiple relays in a chain for extra privacy, and you pay each one separately. It's onion routing, with sessions nested inside each other

Lots of encryption of course, using secp256k1. And blinded paths already implemented as an option, in order that the client doesn't know the IP address (or FIPS address) of every relay fips (nprofile…the5)

A few days out of date, I'll update it fully when it's ready for some testing:
https://github.com/SatsAndSports/MONAD

Cashu (nprofile…8aw4)

Among my technical pre-coiner friends, the vast majority are ...

2026-05-29T10:00:56Z

In reply to nevent1q…qzqy
_________________________

Among my technical pre-coiner friends, the vast majority are French. So I look forward to orange-pilling (bacon-pilling?) them with this slide

Best I can do on the stoicism is binge listen to Alex ...

2026-05-28T21:56:19Z

In reply to nevent1q…c5yq
_________________________

Best I can do on the stoicism is binge listen to Alex O'Connor's philosophy podcasts

He has broad interests, and I listen to most of his discussions. Stoicism and other ancient philosophies are discussed every now and then

https://fountain.fm/episode/8TApRhXcaGuyFdcxNvBy

Mining decentralization isn't about giving power to small ...

2026-05-28T17:09:47Z

In reply to nevent1q…xvmu
_________________________

Mining decentralization isn't about giving power to small miners. It's about removing power from all miners

And we, the tolerant minority, will ensure it stays that way

I know thanks. I was thinking about other contexts where they ...

2026-05-28T13:10:43Z

In reply to nevent1q…7tpc
_________________________

I know thanks. I was thinking about other contexts where they tweak by multiplying the public key by the tweak instead of adding it

If I remember correctly, multiplication is used instead of addition is used somewhere in Lightning

A' = t A

instead of

A' = A + tG

Thanks for the write-up of that, semisol. Makes sense I was ...

2026-05-28T12:36:48Z

In reply to nevent1q…rmus
_________________________

Thanks for the write-up of that, semisol. Makes sense

I was thinking of multiplication in a different context, where it is sometimes a bit better than addition, but you're right that it doesn't help here

How would this work with unreliable relays? If I can't find ...

2026-05-27T10:21:53Z

In reply to nevent1q…2d8m
_________________________

How would this work with unreliable relays?

If I can't find the event that you reference, is it because you've fabricated a reference, or because I simply don't have access to your earlier event?

"I'm only here to save the people ..." Why does your ...

2026-05-27T08:49:09Z

In reply to nevent1q…gugw
_________________________

"I'm only here to save the people ..."

Why does your tone make me think you're a BIP110 fan? 🤔

Love the great work you're doing! And the transparency

2026-05-27T06:45:26Z

In reply to nevent1q…8zl6
_________________________

Love the great work you're doing! And the transparency

Nice! Is there a way to fully integrate nut-zaps into Amethyst? ...

2026-05-27T06:39:10Z

In reply to nevent1q…n5kx
_________________________

Nice!

Is there a way to fully integrate nut-zaps into Amethyst? So that a brand new user - where a third party already knows their npub - can open a Nostr app for the first time and already see some Cashu tokens that have already been sent to them by that third party via some sort of DM

I don't know enough about NUT60/61, but it would be cool to have something like that work - with zero setup - for new users

The game theory on this is against BIP110, not for it. If ...

2026-05-27T06:16:35Z

In reply to nevent1q…g6wl
_________________________

The game theory on this is against BIP110, not for it.

If necessary, the opponents will run a URSF; this is also a user-rejected soft fork and it will oppose BIP110

I'm in the Telegram group to plan the URSF. We already know our approach, it's very simple

Our URSF will - if necessary - reject certain blocks to ensure BIP110 never activates; we'll block "at the last minute", e.g. the block that would achieve 55%

The URSF has one huge advantage: the non-BIP110 miners today (99.9% of the hashrate) are already following the rules of our URSF. They don't need to do anything to be compatible; they already make the blocks that will be accepted by the URSF

As long as some miners continue to do nothing, then our URSF guarantees that there will be a non-BIP110 chain tip

The telegram group is very quiet however, because we know BIP110 is a failure and therefore there is nothing for us to do

Mechanic isn't very technical. He is deliberately careless and inaccurate, for example his bizarre insistence that STRC is a stablecoin which is recorded on the Blockchain

Lots of interesting FUD in this anti-stablecoins piece. This one ...

2026-05-26T20:38:41Z

Lots of interesting FUD in this anti-stablecoins piece. This one paragraph stood out to me, making the false claim that dollars are issued by the Fed. The vast majority of dollars that normal people use nowadays are bank deposits, issued out of thin air by commercial banks with the same mechanism used by stablecoins.

(I'm not necessarily defending stablecoins. I'm just cringing at the bizarre arguments that we're going to see rolled out against Bitcoin again and again)

The complaints he makes about stablecoins also apply identically to the conventional banking sector that he is desperate to defend. Commercial banks generate IOUs ('deposits' is essentially synonymous with 'stablecoins') for this purpose in order to buy other assets (loans, T-bills, ...)

His comments about 'stability' and so on, very predictably without realising that commercial banks are as bad

In fact, the balance sheets of stablecoin companies are better if anything! Their assets are t-bills, compared to the range mortgage and private credit crap that commercial banks have.

I wish more people, *especially Bitcoiners* actually knew the facts about how commercial banking works. No conspiracy theories, just the sort of boring factual analysis that helps you see all the bullshit here and also to help you see through all the pleb slop

https://xcancel.com/fintechfrank/status/2059239138042298571

I just took a look at the BIPs repo, thinking that maybe I can be ...

2026-05-26T19:46:04Z

I just took a look at the BIPs repo, thinking that maybe I can be slightly helpful by looking the open PRs and maybe trying to find some very small thing that I can be helpful with

The first open PR at the moment is a childish attack by two feds on BIP-54

https://github.com/bitcoin/bips/pull/2175

If they're willing to withdraw to a Cashu mint, then they ...

2026-05-26T16:49:44Z

In reply to nevent1q…p5yd
_________________________

If they're willing to withdraw to a Cashu mint, then they should accept the zaps via Cashu in the first place

Our goal isn't just to ensure that nerds have safe options, but that the default experience for relative noobs isn't a privacy shitshow

Cool! Can't say I fully understand yet, hence my stupid ...

2026-05-26T11:56:21Z

In reply to nevent1q…etwv
_________________________

Cool!

Can't say I fully understand yet, hence my stupid question:

> The mitigation is fee-policy homogenization

I take it that homogenization means that everybody should use the same policy. i.e. the default policy should actually be hardcoded as the *only* policy?

Does that mean that we should be aggressive refuse to join with people that don't use the default?

False comparison. The Cashu mint can only steal my funds The ...

2026-05-26T10:02:12Z

In reply to nevent1q…hzfu
_________________________

False comparison.

The Cashu mint can only steal my funds

The Frigate server, *with your insecure variant of Silent Payments*, can steal the funds *and* steal your Nostr nsec and therefore your identify

With a better variant of the SP proposal, the Frigate couldn't steal anything and would only have the ability to track your (Nostr on-chain zapped) UTXOs

How exactly does the secure enclave work? As a Cashu user, I can ...

2026-05-26T08:51:26Z

In reply to nevent1q…tua6
_________________________

How exactly does the secure enclave work?

As a Cashu user, I can see that the blinded messages are signed by a key that is controlled by the provider of the enclave?

So the mint operator, and the mint code, doesn't directly have access to private key material?

And I can check with the enclave provider to see their keys, and verify for myself that the keys in the keyset are derived from that enclave's key?

And so the trust transfers to the operator of the enclave (and the manufacturer of certain hardware), not the mint operator?

and this: "Tim and hzrd deserve a lot of credit for their ...

2026-05-26T08:08:44Z

In reply to nevent1q…hdx3
_________________________

and this:

"Tim and hzrd deserve a lot of credit for their perserverance here. I don't think people appreciate the gravity of this discovery yet."

If you wrote this a few days ago, I would forgive this as just a normal human mistake. It's natural to get very excited about these topics and about *apparent* discoveries. But you know now that Tim's proposal is fatally flawed, and that it doesn't do any SP-derivation that isn't already obvious to a relevant expert

(I forget the details of hzrd's proposal: it may be (much) better than Tim's flawed proposal)

This is false: "Then, Tim Bouma made a major ...

2026-05-26T08:02:55Z

In reply to nevent1q…t676
_________________________

This is false:

"Then, Tim Bouma made a major breakthrough."

There's an obvious flaw (with, I think, an easy fix) in Tim's proposal. You know this already. It will allow anybody who offers SP-scanning services the ability to steal the funds and the nsec and the identity

Everyone who really understands SP knows how to derive an SP from a Nostr key pair (and how to do it in a way that's safer than Tim's). Those experts don't need Tim's sloppy proposal and sloppy code. It didn't add anything to the discussion

The problem with you and Tim isn't that you make mistakes. We all do, and I've made cryptographic mistakes. It's that you double down after your mistakes are pointed out. Tim (and you) could have humbly said "I withdraw my original proposal, as it's crap, and I'd like to learn how to fix it". Many of us would have loved to help

The first thing I'd say is that nothing particularly changed ...

2026-05-26T05:49:18Z

In reply to nevent1q…56qq
_________________________

The first thing I'd say is that nothing particularly changed in 1971, the gold standard isn't so relevant to the big picture

The invention of the telegraph, in the 1800s, was a big deal. For the first time, information could move faster than people and goods, and it cross the Atlantic in weeks instead of seconds

Debt and credit were always possible and existed for thousands of years, see David Graeber's "Debt, the first 5000 years", and people could always lend money that they didn't have

Therefore, fractional reserve banking essentially existed forever, but the telegraph made it really easy and efficient. Moving gold physically is obviously very difficult, and so credit scaled up big time with the telegraph

People will always be tempted to lend money they don't already have, thereby *creating* money. It's not easy to ban it, as there's a natural incentive to do it. The only disincentive is interest rates; if you create credit, the market will force you to pay interest or they'll destroy that money by demanding that you convert the IOUs for the real money

For now, people don't create Bitcoin-denominated credit because we all generally agree it's value will go up, and therefore the market won't agree on the (positive) interest rates that would be needed to enable such credit

But that will change eventually, when Bitcoin's purchasing power levels off, and so credit (and therefore fractional reserve banking) will exist in Bitcoin

The feature of Bitcoin that "fixes this" is the Lighting Network, as it enables instant settlement. The real bitcoin can be sent over the telegraph just as fast as the credit, and therefore there is less incentive to create credit

> All tweaks are reversible by the server and so they can ...

2026-05-25T21:40:50Z

In reply to nevent1q…sg6z
_________________________

> All tweaks are reversible by the server and so they can derive your nsec easily

You could *multiply* by the tweak 't', instead of adding +t*G, and that might be safer, because dividing by 't' is much harder than reversing the addition -t*G

I don't claim to like this proposal, nor that my idea is valid in this case; just throwing this out as something to think about. Cryptography is interesting and fun

You should write a service which backs up every follow list that ...

2026-05-25T11:00:29Z

In reply to nevent1q…5gu3
_________________________

You should write a service which backs up every follow list that has ever been broadcast and makes it available for a small amount of bitcoin 😃

Don't take tbouma seriously. They've been spamming AI ...

2026-05-25T08:57:54Z

In reply to nevent1q…8cf9
_________________________

Don't take tbouma seriously. They've been spamming AI slop for a while; and they themselves are either a bot or have succumbed to AI psychosis

Just a few minutes ago, I was thinking about how - while LLMs are great for so much coding - they are simply unable to come up with new, safe, protocols. You've pointed out a good example of that

(I have an idea to fix this particular problem, but I don't want to help them 😀)

This is the video where I learned - just last year - how ...

2026-05-24T21:44:22Z

In reply to nevent1q…2ups
_________________________

This is the video where I learned - just last year - how Lightning works

If you watch it, you'll realise how ridiculous it is to say "L2 == IOU"

https://youtu.be/yKdK-7AtAMQ

I was on a bike camping in Scandinavia last July I'd just ...

2026-05-24T16:33:42Z

In reply to nevent1q…2uf8
_________________________

I was on a bike camping in Scandinavia last July

I'd just started listening to Bitcoin podcasts, and a couple of them kept mentioning nostr and cashu

I think I remember Super Testnet's enthusiasm for both

That's pure AI slop It means quantum computing in the first ...

2026-05-24T08:30:42Z

In reply to nevent1q…tpx0
_________________________

That's pure AI slop

It means quantum computing in the first sentence; QC is irrelevant

And then it's a long sloppy rant that I'm not reading

Some people are unable to be concise nowadays. Use AI to make your rants shorter, not longer. Skill issue if you don't know how to do that

No development needed If it ain't broke, don't fix it

2026-05-24T07:41:54Z

In reply to nevent1q…nlkf
_________________________

No development needed

If it ain't broke, don't fix it

I'm switching to X this evening, away from Nostr, because ...

2026-05-23T18:47:56Z

I'm switching to X this evening, away from Nostr, because I'm getting bored of the repetition - and egotistical attacks - that's on Nostr

When the total value is more than 10,000 says, automatically send ...

2026-05-23T00:13:26Z

In reply to nevent1q…mu2u
_________________________

When the total value is more than 10,000 says, automatically send them to boltz.exchange, in return for a zap to your Lightning address

That doesn't help those of who don't have any high-volume ...

2026-05-22T23:44:22Z

In reply to nevent1q…cer4
_________________________

That doesn't help those of who don't have any high-volume non-KYC options

Phoenix can receive to a Bolt12 offer But I think the problem is ...

2026-05-22T10:52:15Z

In reply to nevent1q…aqus
_________________________

Phoenix can receive to a Bolt12 offer

But I think the problem is that only a few Nostr clients are able to send zaps to Bolt12. But that will improve

In fact, I'm not even sure where in the kind0 (or suitable alternative kind) a user is supposed to advertise their Bolt12 offer

I'm beginning to lose some of the excitement I had a few days ...

2026-05-21T22:09:49Z

In reply to nevent1q…fwea
_________________________

I'm beginning to lose some of the excitement I had a few days ago about using Ark as the easy way to onboard new users. I zap you by creating a Ark tree where the leaf pays (a tweaked version of) your npub

My initial enthusiasm was based on the fact that this kept the payments off-chain (unless somebody needs to exercise unilateral exit). But the bad news is that the Ark still can see the payment and will learn something about how you spend the funds later.

I haven't given up on it though. In the ideal case, typical users will 'upgrade' their Ark balance to a real Lightning channel sooner or later (e.g. Phoenix).

Lots of potential, but risky too

So I'm happily sticking with Cashu, for using and contributing a little to dev here and there

A small pedantic correction, just an implementation detail: This ...

2026-05-21T21:47:14Z

In reply to nevent1q…zt6k
_________________________

A small pedantic correction, just an implementation detail:

This says that the two (derived) pubkeys are listed in the 'data' field, separated by a comma. But only one key (doesn't matter which one) goes there. If we're doing an n-of-m, then we put one key in 'data' and we put m-1 keys into 'pubkeys'. So in this case, it's one key each in 'data' and 'pubkeys'.

The 'Complex example' from the Cashu docs:
https://github.com/cashubtc/nuts/blob/main/11.md#complex-example

(I haven't really read this, but skimmed it and this popped out)

Does Cashu come under "use a custodial wallet and sell my ...

2026-05-21T19:50:25Z

In reply to nevent1q…3jke
_________________________

Does Cashu come under "use a custodial wallet and sell my soul"?

Bark on mainnet with NWC seems to be out today basically, just in ...

2026-05-21T18:46:40Z

In reply to nevent1q…xq2j
_________________________

Bark on mainnet with NWC seems to be out today basically, just in time to save us from the death of Lightning 😀

From a thread involving Derek Ross (npub18am…p424) and Matthew Vuk

https://xcancel.com/matthewvuk2/status/2057479294301945999

I'm guessing the point is that any miner that has opinions on ...

2026-05-21T18:38:21Z

In reply to nevent1q…gf3n
_________________________

I'm guessing the point is that any miner that has opinions on Bitcoin is an attacker

Attackers should stay humble and manage energy and heat, and maximize fees via techniques such as Cluster Mempool

On Silent Payments, I'm getting much more optimistic in the ...

2026-05-21T18:21:41Z

On Silent Payments, I'm getting much more optimistic in the last hour or so, since deciding to dig into more detail. Seems like about 150 KB per block (BIP158 filter + 33 bytes per tx) is sufficient in terms of bandwidth. And this table of CPU-only scan times is much better than I expected.

There is room for further bandwidth improvements. According to the BIP (352), if you want a couple of weeks a huge fraction of relevant UTXOs are already spent, and so the 150KB can be shrunk further by discarding transactions which no longer have any unspent taproot outputs.

It's still not realistic for everybody, especially noobs, to run their own 'sovereign scanner' like this. But it's interesting nonetheless.

https://github.com/sparrowwallet/frigate#cpu-performance

Burn a few sats, and attach proof-of-burn to each Nostr event in ...

2026-05-21T11:20:33Z

In reply to nevent1q…slgj
_________________________

Burn a few sats, and attach proof-of-burn to each Nostr event in order to discourage spam

ThomasV (nprofile…7976) was working on making this very efficient, combining large numbers of proofs into a Merkel tree

I went for three weeks, but got nerd-sniped into staying for 6 ...

2026-05-21T11:17:19Z

I went for three weeks, but got nerd-sniped into staying for 6

quoting
nevent1q…s0qc
MEN WANTED for an uncertain journey, no wages, very hard problems, summer in Madiera, 6 weeks of intense experimentation, more than vibes, short-term success doubtful, honor and recognition of fixing the internet in case of success.

SEC-08 runs from 20 July - 28 August. Apply here:

https://sovereignengineering.typeform.com/SEC-08

nevent1q…8klf

I agree lots of things are bad now. But that's why we have ...

2026-05-21T11:10:33Z

In reply to nevent1q…z559
_________________________

I agree lots of things are bad now. But that's why we have smart folks like all of you working on freedom tech, and everyone is learning and moving quickly!

What do you mean by "not trying to fool users into thinking that zaps can ever be private"

(My question isn't about whether zaps are on or off the chain; it's a general question about "zaps")

Essentially by definition, a zap is a public announcement that A has sent X sats to B

Maybe you're saying something like this: "Given the constraint that the above announcement will be public, we want to optimize everything else (privacy, ease of use [especially for noobs], ...)"

I apologize, @nprofile…9k9u I was quite rude here I've ...

2026-05-21T09:51:55Z

In reply to nevent1q…p5s0
_________________________

I apologize, jb55 (nprofile…9k9u)

I was quite rude here

I've since changed my mind on the topic and agree with you more about on chain zaps. But, regardless of this change of mind, I owe you an apology for my tone

Unlike a lot of other debates (e.g.
BIP-110), this debate has lots of smart people working in good faith and I see lots of people changing their mind. This is bullish for freedom tech, as long as we don't all tear each other apart in the process

What's your point? It's a non-trusted coordinator And we ...

2026-05-20T19:14:26Z

In reply to nevent1q…ynkl
_________________________

What's your point?

It's a non-trusted coordinator

And we could use a different coordinator, i.e. a different Ark, for each such operation

Use an ephemeral Ark server to collaboratively swap UTXOs (e.g. ...

2026-05-20T18:54:01Z

Use an *ephemeral* Ark server to collaboratively swap UTXOs (e.g. on-chain zaps) to *Lightning*, trustlessly. Receive on Bolt12 for extra privacy and unlinkability

Thoughts? I'm assuming we can put a HTLC in the Ark's vUTXOs

quoting
nevent1q…cnte
I think the Ark protocol (not tied to a single Ark operator) is the trustless solution, to allow us to swap our on-chain zaps to *Lightning*

Arks gives everybody unilateral exit, allowing a large number of users to have balances, but where everything is compressed into a single UTXO. So we gather a number of Nostr users, each of which have a number of on-chain zaps, and we collaboratively sign one big transaction that creates our 'Ark round', i.e. this single UTXO, consuming all the on-chain zaps.

When that confirms, the operator of the Ark starts paying us via Lightning. With the preimage they receive from each of us, they then have the info needed to 'steal' our Ark balance. I didn't mention this in the previous paragraph, but each user's Ark vUTXO will be a bit complex, including a timelock and a hash

So they get my on-chain funds (via Ark) if, and only if, they pay me the same amount via Lightning. If they don't, then - after a timelock - then I can unilaterally exit to get my money back

In the happy path, they get all our preimages and - by presenting all those preimages on the blockchain - they can sweep all the funds to their own UTXO. Quite small on-chain footprint

Privacy: if we present Bolt12 invoices to the operator, and use Tor and other best practices, then the users should feel very private

I think the Ark protocol (not tied to a single Ark operator) is ...

2026-05-20T18:46:33Z

In reply to nevent1q…k0g8
_________________________

I think the Ark protocol (not tied to a single Ark operator) is the trustless solution, to allow us to swap our on-chain zaps to *Lightning*

Arks gives everybody unilateral exit, allowing a large number of users to have balances, but where everything is compressed into a single UTXO. So we gather a number of Nostr users, each of which have a number of on-chain zaps, and we collaboratively sign one big transaction that creates our 'Ark round', i.e. this single UTXO, consuming all the on-chain zaps.

When that confirms, the operator of the Ark starts paying us via Lightning. With the preimage they receive from each of us, they then have the info needed to 'steal' our Ark balance. I didn't mention this in the previous paragraph, but each user's Ark vUTXO will be a bit complex, including a timelock and a hash

So they get my on-chain funds (via Ark) if, and only if, they pay me the same amount via Lightning. If they don't, then - after a timelock - then I can unilaterally exit to get my money back

In the happy path, they get all our preimages and - by presenting all those preimages on the blockchain - they can sweep all the funds to their own UTXO. Quite small on-chain footprint

Privacy: if we present Bolt12 invoices to the operator, and use Tor and other best practices, then the users should feel very private

.. although now I think my proposal could be harmful. Somebody ...

2026-05-20T17:11:00Z

In reply to nevent1q…h23g
_________________________

.. although now I think my proposal could be harmful. Somebody who is trying to broadcast a Lightning penalty transcation should be able to use huge fees to force it on chain ASAP

Let's soft fork to smooth out the fees If the total fees in a ...

2026-05-20T17:09:28Z

In reply to nevent1q…zy7c
_________________________

Let's soft fork to smooth out the fees

If the total fees in a block are more than twice the median fees of recent blocks, the excess fees must be anyone-can-spend coinbase outputs which are locked to at least 100 blocks in the future

"most people" is doing a lot of heavy lifting here: > ...

2026-05-20T15:38:38Z

In reply to nevent1q…mt02
_________________________

"most people" is doing a lot of heavy lifting here:

> "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"

(I love your work on all this, and I'm trying to be neutral-ish as we all move to the best solutions. I'm just pointing out that I find this argument a bit weak)

I don't think the issue has ever been about "seeing the balance", or about watching the public zaps going around within Nostr. As you quite rightly said, zaps are about being transparent about the fact that person A zapped person B an amount X

The privacy challenge arises when people try to swap in and out of Nostr, that's where the tracking fears start. Following the money within Nostr was never the issue; the issue arises when try to take the money out of Nostr, like using your on-chain Nostr zaps to make a non-Nostr payment

I think I have an idea to discourage this. It's not entirely ...

2026-05-19T22:07:03Z

In reply to nevent1q…xls2
_________________________

I think I have an idea to discourage this. It's not entirely novel, but I think it can be done as a soft fork (I've heard others suggest it would require a hard fork).

Alongside the existing requirement that the hash of the header be smaller than the current 'target', I would add a new requirement to include a signature of a message - signed by the coinbase output's key - where that signature begins with four zero bytes.

The controller of the coinbase - i.e. the pool operator - might be tempted to share the private key with the 'hashers' in order for the hashers to compute the signature locally. But of course the controller won't want to share the private key, and instead the hashers will submit their shares to the controller such that the controller will compute the signature and check if they have achieved a full block.

With this, the hashers don't know if their 'mining share' is a 'full block' and therefore they don't know which shares to withhold.

Unfortunately, we would also need to softfork a new signature scheme with deterministic signatures, which also means a new curve. "BLS signatures — Boneh–Lynn–Shacham — often used over pairing-friendly curves such as BLS12-381."

Also, this signature would need to be passed 'out of band', i.e. it's an extension to the relay protocol. But it's a soft fork because nodes don't need to be upgraded. Non-upgraded nodes might be "confused" because they would see an *apparent* drop in difficulty

Which is why we'll use Ark as a Lightning channel factory ...

2026-05-19T21:06:01Z

In reply to nevent1q…8mkg
_________________________

Which is why we'll use Ark as a Lightning channel factory eventually

Alongside Cashu of course

> That should put an end to the debate of using your social ...

2026-05-19T19:57:30Z

In reply to nevent1q…vzgw
_________________________

> That should put an end to the debate of using your social nsec as a wallet.

It ends the privacy part of the debate, but not the 'dusty' part

If we're going to have small amounts, let's try to do something to be more efficient (like make it an Ark vTXO)

(tagging @npub1ye5…knpr too. An implementation, with full demo, ...

2026-05-19T19:53:31Z

In reply to nevent1q…vzgw
_________________________

(tagging hzrd149 (npub1ye5…knpr) too. An implementation, with full demo, of the SP-from-npub)

Has anyone built the tool to show the intersection of: - Npubs ...

2026-05-19T15:44:56Z

In reply to nevent1q…4z3r
_________________________

Has anyone built the tool to show the intersection of:

- Npubs with events on relays (only those with a kind0?)

and

- keys on the blockchain

?

How about I make an Ark payment to a key X, where X is some ...

2026-05-19T15:06:16Z

In reply to nevent1q…msl2
_________________________

How about I make an Ark payment to a key X, where X is some (SP-)tweaked version of your public key

So then I can zap you a small (SP) payment by sending you the relevant Ark data

If you don't claim the data, perhaps because the Nostr hint is lost, perhaps we can include a timelock that allows me to reclaim after a month

It's a much better debate than - for example - BIP110 I'm ...

2026-05-19T09:16:29Z

In reply to nevent1q…lxpz
_________________________

It's a much better debate than - for example - BIP110

I'm changing my mind, gradually being against on-chain zaps, and I know others are learning and are changing their mind too

When people are acting in good faith, and they are all smart (perhaps smart in different ways 🙂), then we end up in a good place (eventually)

Love the work everyone is doing on everything in Nostr and ...

2026-05-19T08:14:45Z

In reply to nevent1q…2fzq
_________________________

Love the work everyone is doing on everything in Nostr and Bitcoin. Thanks Vitor et Al!

🔗⚡🥜

I'm learning lots from you all, and I'm sure we'll end up with even better tools and protocols than we have now

Trying to think of a variant of Silent Payments, perhaps ...

2026-05-19T08:04:11Z

Trying to think of a variant of Silent Payments, perhaps involving a second scan key (i.e. three keys in total), where holders of one scan private key are able to find all UTXOs spendable by you, *but they'll also find a lot of false positives*

The motivation is to allow clients that are still quite light (they don't need to scan *every* transaction on chain) by transferring much of the work to a third party such that the third party still doesn't learn my transaction history

Already been done? Already been debunked? I've just been nerd-sniped by the on-chain-zap wars?

[I'm just thinking out loud here, saying stuff you all likely ...

2026-05-19T06:27:12Z

In reply to nevent1q…rpm0
_________________________

[I'm just thinking out loud here, saying stuff you all likely know already. And I'm learning lots about these topics (e.g. Silent Payments) on the way]

The idea for Silent Payments is to share the private scan key with a third party service so that it can scan the chain for you, but it can't steal your coins (as it doesn't have the spend key)

But I guess that doesn't really scale. Too many people will stay with those services - and not switch to their own scanner - and we won't therefore have made much progress

How about an sp... derivation scheme that changes every day, so that the scanners only see one day of activity?

If all this on-chain zap controversy ends up with many clients ...

2026-05-18T23:44:29Z

If all this on-chain zap controversy ends up with many clients having lots of code for doing on-chain operations, then it will all have been worth it if the clients eventually extend to full coinjoin support

Come for the on chain zaps, stay for the large scale deployment of privacy tech such as nostr-coordinated coinjoins

quoting
nevent1q…jvxp
Nostr is weird. You push Nostr backwards and it still moves forward. 🫠

Two groups push in opposite directions, each accusing the other ...

2026-05-18T23:37:45Z

Two groups push in opposite directions, each accusing the other of going backwards

Only in open source can we see this resolving into something even better that is liked by everybody

quoting
nevent1q…jvxp
Nostr is weird. You push Nostr backwards and it still moves forward. 🫠

I'm very happy to have just submitted a PR again, after a few ...

2026-05-18T22:12:34Z

I'm very happy to have just submitted a PR again, after a few months where I was doing stuff but nothing substantive

And I'm doing the boring stuff of making a PR to fix things, instead of exciting shiny new stuff 😀

#BearMarketsAreForBuilders

As an atheist who knows more about the Bible than most ...

2026-05-18T20:52:39Z

As an atheist who knows more about the Bible than most Christians, I find it funny to watch Bitcoiners treat the Bitcoin White Paper as holy scripture

(I'm writing this to pass the time while my agent works on a big PR; I'm sorry for filling your timeline with this human slop 😀) #HumanSlop

Like Americans who are unable to form their own opinion on the balance of power between their three branches of US government [*], some Bitcoiners are unable to form their own opinion on Bitcoin. They quote Satoshi's white paper, and forum posts, and then switch their brain off. Big blocks or small? Knots versus the TolerantMinority? Mempoolfullrbf?

Evangelical Christians look crazy when struggling with all the contradictions in the Bible. Even the four Gospels contradict each other in so many ways. This isn't surprising or interesting really; the contradictions get boring to any scholar pretty quickly. The really interesting study of the Bible is when you realize that it was written by dozens of different authors - across multiple genres - who had very different goals in their writing.

Satoshi may have been multiple people. And even if Satoshi was one person, they changed their mind sometimes. That's cool. Stop trying to identify a single non-consistent viewpoint in Satoshi's writings.

And even if Satoshi was consistent on a given topic, they might have been wrong. Satoshi is irrelevant. There is a long list of people (i.e. everyone) that don't control bitcoin, and Satoshi is top of that list

Given this question, the Euthyphro dilemma first asked by Plato:

"Is something good because God [Satoshi] commands it, or does God [Satoshi] command it because it is good?"

my answer is "Bitcoin doesn't care what Satoshi thinks, even if some Bitcoiners do care; I form my own opinion on what is good, incentivized by Bitcoin"

====

[*] For example, to paraphrase what I've heard a few times: "the founding fathers[**] made it into a republic not a democracy, and therefore I approve of the current slide into dictatorship because I think it's what the founding fathers wanted and I don't ask myself what is good for me"

[**] More like 'Building Boys'; many of them were quite young men

Oh thanks, I've just learned from you that the problem I ...

2026-05-18T17:06:32Z

In reply to nevent1q…0yww
_________________________

Oh thanks, I've just learned from you that the problem I describe in my final point has already been solved in the existing SP protocol.

Love the general idea, and I'll try to read it all in detail ...

2026-05-18T16:33:43Z

In reply to nevent1q…krt6
_________________________

Love the general idea, and I'll try to read it all in detail soon

-----

I think the main challenge will be not about deriving the SP code, but more about whether nostr relays are sufficiently reliable that recipients will get the encrypted hint each time

-----

You mention an event sent after the tx confirms. Why wait until the confirmation?

Why not either send it immediately, or with a short random delay to avoid timing-based analysis?

---------

Are there SP(-like) schemes where you can give a little bit of private information to a scanner such that the scanner can find your transactions but scanner can't steal the funds. My goal is to make things very light on the client side, so that semi-trusted scanning services can do the heavy lifting. (I'm asking this out of technical curiously; not because I think it's the right privacy trade-off)

Thanks for clarifying. I'm trying to be neutral-ish on this ...

2026-05-18T15:21:34Z

In reply to nevent1q…nea4
_________________________

Thanks for clarifying. I'm trying to be neutral-ish on this topic now, and to just clarify the questions. (And maybe I shouldn't have dismissed ZK so much; I don't really understand ZK well enough to have an opinion on whether it's ready for this now)

==== Continuing to think out loud ... ===

Even if we have a perfect ZK system, if the amount is public then it probably won't be too difficult to find an on-chain transaction with the same amount and which was broadcast to the mempool at the same time as the Nostr event. If there was only one transaction in the block with an output worth exactly 69420 sats, then it's not very well hidden

This argues that the amount should be hidden too; and that's moving further and further from what we think of as a 'zap'

If we really want the amount to be public, but somehow obfuscate the amount in the blockchain, then maybe the 'on-chain' transaction should actually be an Ark transaction, and therefore it's confirmed when the next Ark round happens on chain. Then we would like a (ZK) proof that the recipient has unilateral exit from a given confirmed UTXO

What's the goal? More precisely, what do you mean by ...

2026-05-18T15:04:40Z

In reply to nevent1q…9rkw
_________________________

What's the goal? More precisely, what do you mean by 'proof'? I don't think you're really asking about SP, and key derivation, and Diffie-Hellman shared tweaks, or any of that. You're asking more about proofs that a transaction happened

> Zap events then would have to contain a proof of a bitcoin transaction without identifying it directly.

There is no such proof, except maybe with some zero-knowledge magic, and I don't think ZK systems are mature enough and scalable enough and simple enough to be used for this today

Is it sufficient that both the sender and receiver sign an event which basically says "trust us, this on-chain zap happened"? Or do you really need a proof that the transaction happened?

PS: at 49m20s, Erin said "everyone is made at the (Core) ...

2026-05-18T13:24:22Z

In reply to nevent1q…glt2
_________________________

PS: at 49m20s, Erin said "everyone is made at the (Core) Devs"

Not true. I think Core have been impeccable, where the only mistake is that they were too slow to increase the default datacarriersize

My opinion might be bullshit 🙂, I'm not asking everyone to agree, my point is that very many folks are not unhappy with Core

These podcasters are obviously not plebs/Knotzis/BIP110ers, but they fall into their framing of the discussions

I think they often say things that are incorrect, but much of the ...

2026-05-18T13:03:13Z

In reply to nevent1q…3q4j
_________________________

I think they often say things that are incorrect, but much of the time they're trolling 🙂

I've listened to couple of episodes of the Hell Money Podcast ...

2026-05-18T11:58:44Z

I've listened to couple of episodes of the Hell Money Podcast recently

At 39m13s into this, they said that BlockStream had tried - and failed - to launch a sidechain: "They never figured out a way to do sidechains that had tradeoffs that they found acceptable"

I don't know if the Hell Money Podcast ever has guest episodes, buy maybe they should have someone from Blockstream (npub1jg5…6n8n) to discuss Liquid 😀

I would tag the hosts, Erin Redwing and Casey Rodarmor, but I don't think they're on Nostr

https://www.youtube.com/watch?v=Et6f9RQ7GbM

It wouldn't allow the 'latest state wins' thing, that ...

2026-05-18T09:49:06Z

In reply to nevent1q…20aq
_________________________

It wouldn't allow the 'latest state wins' thing, that requires a bitcoin soft fork

From the point of view of Lightning, Nostr is just a very convenient (but unreliable) data-storage system and therefore it doesn't change the fundamental security model of Lightning

Replaceable events are cool and all, but there is no guarantee that the old event is deleted

I mostly agree Vitor, but it depends on what you mean by ...

2026-05-18T09:41:03Z

In reply to nevent1q…jpxv
_________________________

I mostly agree Vitor, but it depends on what you mean by "everything". A zap is a public record that one person made a payment to another person

The question is whether the public record should also (implicitly or explicitly, it doesn't matter) point to the on-chain transaction

That appears to be the real issue you all are discussing, and the issue would still exist even if each payment was to a different address

Define "Noisy Payment" as a Silent Payment, but with a public event linking to the txid. Would that be a fix for onchain zaps, because it avoids address reuse; or equally harmful because the public can still see all the transactions?

Thanks to Paul Sztorc for distracting us from BIP-110 And thanks ...

2026-05-17T16:25:19Z

Thanks to Paul Sztorc for distracting us from BIP-110

And thanks to on-chain zaps for distracting us from both of those dumb forks

Alex Gleason (nprofile…ae9u)

Without jumping into (probably irrelevant) details of an ...

2026-05-17T16:22:56Z

In reply to nevent1q…jhnz
_________________________

Without jumping into (probably irrelevant) details of an alternative solution, what do people really want here?

Zaps are public. Everyone can see the npub of the sender and of the receiver, (and the amount too?). I hope everyone agrees with that definition of zap; if not, then we're talking past each other

In that context, what are the actual concerns?

You'd like the txid to be private, and generally to keep the onchain activity private?

So you're happy that there is a nostr event with the sender and receiver, telling the world that an on chain zap occurred, but you don't want to announce any on-chain address or txid?

If the amount is public, then it might be easy to find the transaction simply by looking at the transactions at the right time with the right amount

Let's assume that "zap" means "public". i.e. ...

2026-05-17T15:58:03Z

In reply to nevent1q…04y3
_________________________

Let's assume that "zap" means "public". i.e. If A zaps B, then everyone can see that A zapped B

In that context, it doesn't matter if the on-chain address is re-used. If each payment has a different address, then everyone can still see the public zap events, and everyone can see all the addresses and the balance

Therefore, I don't think anybody actually has a problem with address re-use *in the context of on-chain zaps*. The real question is whether people like public on-chain payments

If you're so concerned about privacy of payments between ...

2026-05-16T23:07:02Z

In reply to nevent1q…f9tv
_________________________

If you're so concerned about privacy of payments between Nostr users:

- write the pull request for Silent Payments

and

- explain to me how I can see this long list of zaps on your profile:

and what's your point? The fact that you voiced these ...

2026-05-16T22:35:08Z

In reply to nevent1q…gcq2
_________________________

and what's your point?

The fact that you voiced these concerns, and your concerns didn't stop people (welcome to cryptoanarchy, people can just do things), means that maybe your concerns weren't a showstopper after all

As long as I can send some message inside an OP_RETURN, and this ...

2026-05-16T22:26:22Z

In reply to nevent1q…wnt0
_________________________

As long as I can send some message inside an OP_RETURN, and this message is displayed in the zap notification, then I approve