hoppe2

Public Key

npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera

NIP-05 Address

Profile Code

nprofile1qqsq46s8tvqsldv466q5743nqz8gwrth5tzr6nw6z4zwsucwqzv4z3qpz4mhxue69uhhyetvv9ujuamfwdczuarpd34sz9thwden5te0wfjkccte9ejxjar5duh8qatzenwm3d

Publishing to

relay.wisp.talk

relay.ditto.pub

Author Public Key

npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera

Show more details

Last Notes

2026-10-22 00:14:10 UTC

- reply

gm ☕

2026-10-03 15:58:03 UTC

This is where Ark's greatest achievement comes in. Many people can take part in an Ark refresh at the same time, and yet the transaction size does not grow in proportion to the number of participants; it stays fixed. In other words, unlike other onchain transactions, the transactions generated by Ark activity don't consume block space exclusively for a single person. They consume truly O(1) block space, which is qualitatively different from something like the batched withdrawals commonly seen at exchanges (a batched withdrawal needs as many outputs as there are recipients).
So, taking all of this into account, Ark scales Bitcoin significantly, but in a completely different direction from Lightning. To use internet speed as an analogy, Lightning offers low latency, while Ark offers high throughput. Ark doesn't guarantee Lightning-level immediacy for large amounts, but in most transactions, amounts above a certain size don't really need immediacy anyway; what matters is throughput. And once full ownership has been secured through a refresh, I can spend freely from then on. The resulting VTXOs will still be marked as theoretically double-spendable, but since the only person who could double-spend them is me, their safety is guaranteed.
Ark also lets users send and receive payments and transfers across ASPs "atomically" through the Lightning nodes run by ASPs, without bearing the burden of running a node themselves. This should vastly improve on Lightning's weakness in reliability and dramatically reduce failure rates. Being able to receive without keeping anything running is another great advantage.
Of course, users do bear a liveness requirement. It's true that anyone who wants a fully unilateral exit needs to be fairly diligent about maintaining that liveness. But only those who want that need to do so.
In conclusion, I believe Ark can be called self-custodial when used with a precise understanding of how it works, and I expect that, thanks to its overwhelming convenience, it will play the most important role if a world where people pay with bitcoin ever arrives.
#nevent1q…h3hz

2026-10-03 15:37:03 UTC

Therefore, as long as the client-side wallet app behaves properly, nearly complete self-custody can be guaranteed for nearly everyone. In particular, for people whose usage pattern is occasionally receiving large sums and spending them in small amounts, it can guarantee almost total ownership, provided the wallet app pairs a sensible refresh strategy with coin control. And that is not difficult at all, because it requires no cooperation from the ASP; it is entirely up to the client.
Receiving a substantial amount on Layer 2 while knowing it could still be double-spent may be hard to accept. But this, too, is the kind of problem that can be managed with the right mental model. The answer is simply to refresh right away and not count the funds as received until the refresh is done. In other words, they should be treated the same as zero-confirmation funds onchain.
Having explained this far, I expect the following objection:
"The whole point of a Layer 2 is that onchain is slow and expensive. If certainty requires a refresh, and a refresh is an onchain transaction, then why bother using it at all? Doesn't that mean waiting for onchain block confirmations anyway? Besides, the reason Lightning isn't a complete solution is that even though channels can be used freely once opened, the chain could never handle it if every person made even a single onchain transaction. Isn't this the same thing? In fact, unlike Lightning, where a channel can be reused indefinitely once opened, this has to be done every time a lump sum comes in, so doesn't it require even more onchain transactions?"
#nevent1q…ykcn

2026-10-03 15:20:52 UTC

So what does it mean that someone other than me can touch my funds on Layer 2? It means that if the previous owner of a VTXO I hold (essentially, bitcoin on Layer 2) colludes with the ASP, a double spend becomes possible. I may think I've received the money, but in reality it could have been double-spent so that someone else receives it too, and if that person withdraws onchain first, I have no recourse.
Some might conclude from this that it isn't self-custody at all, but that's not the case. A VTXO can have its history reset through a process called "refresh," either periodically or whenever its owner wants. Put simply, a refresh is an onchain transaction, and through it the VTXO becomes something only I can withdraw. This is cryptographically guaranteed.
And since the only party who can wrongfully touch my VTXO is its previous owner, once I've refreshed, every change VTXO that comes back to me as I spend from then on belongs to me alone, because every previous owner is me.
#nevent1q…ma6g

2026-10-03 15:08:08 UTC

I really like the Lightning Network, but there's one thing its critics say that I can't help but agree with: Lightning alone cannot solve Bitcoin's scaling problem. In fact, that was the very first thing I asked the Bitcoiners here publicly when I first came to Nostr (though I never got a single answer).
This is obvious to anyone who can do a bit of arithmetic, which is why everyone is exploring new Layer 2s to complement Lightning. I'm no exception, and of all of them, I consider Ark the most promising. Its detractors call it a "fake L2" or even a "scam." So which side has the stronger case? Let's look at whether their arguments actually hold up.
For a Layer 2 to be called self-custodial, it must satisfy the following conditions:
An onchain deposit must atomically result in Layer 2 funds.
A Layer 2 withdrawal must atomically result in an onchain UTXO.
I must be able to perform #2 entirely on my own, without any help from the Ark Service Provider, and even in an adversarial environment.
No one but me should be able to touch my funds on Layer 2.
Ark satisfies 1, 2, and 3. The only one it doesn't fully satisfy is #4, and that is the strongest criticism against Ark. There are other criticisms too, but most of them are drawbacks that can all be overcome as long as the client behaves correctly. I see those as UX issues, not something to be addressed from a custody standpoint.

2026-10-03 05:54:38 UTC

- reply

Seems you're pretty pessimistic about Lightning. Does Monero intend to solve everything on layer 1? I was told that you fundamentally can never achieve scalability with layer 1 alone, and it was fairly convincing. I heard that block size is an absolute limit that constrains scale, and even if you try to make block size flexibly enlargeable to get around it, that just makes it even harder for ordinary people to run nodes. Combined with the fact that you can't prune the UTXO set for privacy reasons, and that transaction sizes are inherently larger, it's a design that's far more disadvantageous for scaling than Bitcoin—and the only reason it hasn't hit that problem yet is that there are far fewer users. If users grow, they argued, it'll become far harder to use than Bitcoin. Ultimately scale can only be solved with layer 2, but due to Monero's nature it's too hard to build a layer 2, so eventually ordinary people won't be able to run nodes, and the moment they delegate operation to experts, all of Monero's advantages become meaningless—that was their argument. It sounded plausible to me. What's the Monero brothers' answer to this?
I'm not attacking, I'm just asking because I'm curious. I also think the idea of Lightning, especially having ordinary people run it, is quite unrealistic. I just don't know much about Monero.

2026-09-03 14:28:05 UTC

- reply

If everyone followed the standard, things would work with a reasonable amount of effort. But once we start relying on nonstandard behavior, it may be convenient in the short term, yet it eventually becomes the de facto standard. Wouldn’t it be better to avoid using hardcoded relays?

2026-08-06 12:20:17 UTC

- reply

Good Morning — what's gonna blow up today?

2026-08-06 11:57:04 UTC

- reply

It reminds me of how hardcore Bitcoiners used to trash gold over storage costs whenever they argued with gold bugs. From my position of holding both, I thought 'that's really not true at all,' but I didn't bother jumping in.

2026-08-04 00:18:28 UTC

- reply

2026-08-03 07:56:21 UTC

- reply

2026-08-01 12:58:23 UTC

- reply

GM Derek

2026-07-31 13:53:57 UTC

What’s the best way to connect to Chinese open-source models like GLM 5.2, DeepSeek, or Kimi? Would something like OpenCode be good? I’ve only used Claude Code with Opus, so I’m not really sure. I’m a bit tight on money lately, so I probably need to look for something cheaper.

2026-07-27 00:12:31 UTC

- reply

That’s exactly why all those things—RWA, STO, and the like—are basically scams.

2026-07-21 15:28:43 UTC

- reply

how can i access fips?

2026-07-16 01:37:12 UTC

I think I’ll get fired at work this year. Being a developer doesn’t seem to suit me, so I’m considering doing manual labor.

2026-07-09 03:49:18 UTC

- reply

Laws and order should not be constraints governing us, but services we voluntarily choose.
In other words, all matters must be based on mutual agreements.
For example, private insurance companies could provide judgment services.
Someone might argue, "Without a single unified legal system, disputes will never end."
However, the response would be: Even now, disputes with foreigners aren't governed by a single law, yet they generally function effectively.

2026-07-08 17:08:03 UTC

- reply

Ark has the same "back up your proof every vtxo" requirement. And the same limitation: the moment you receive offchain vtxo(and proof), you can unilaterally exit, but it isn't exclusive either — a colluding previous owner + ASP could still double-spend your prior state.
What's better about Ark is the periodic batch round (an onchain tx). When you participate, your old VTXO gets forfeited, which kills the stale state a prior owner could've exited with — so exclusivity is restored and only you, the latest owner, hold full ownership.
And the batch settlement is O(1) onchain regardless of participant count — thousands of participants still settle into a single shared Taproot output that just looks like a normal address. (You only unroll the tree if you unilaterally exit.) That amortizes the fee across everyone, so at scale the per-user burden becomes almost negligible.

2026-07-08 16:52:57 UTC

- reply

The DA dependency isn't really the issue imo — if a holder backs up their proof each tx, a withheld proof just means it's treated as unreceived. Worst case a UX problem, handled in the background.
Spark's real problem, as I understand it, isn't that — it's that even with every proof in hand, you don't quite get true self-custody. Not because UE is impossible, but because it may not be exclusive: as I understand it the federation can equivocate, so a colluding prior owner could double-spend. And if exit exclusivity rests on federation honesty, that's not self-enforcing — or am I missing something?

2026-07-07 00:17:13 UTC

- reply

I want to try it, but there’s nowhere to get it here.

2026-06-30 07:09:13 UTC

- reply

What percentage of messages are spam for an account as popular as yours? Is the spam filter active, making it impossible to check?

2026-05-20 00:26:14 UTC

- reply

I've actually built a fully non-KYC service before, and the thing is, it becomes extremely vulnerable to spam attacks. Then you end up piling on all this complexity just to mitigate it, and from the user's perspective the UX becomes genuinely awful. Anyone on Nostr probably feels this to some degree... and then what happens is maintenance becomes a nightmare, users go "wtf is this, it sucks, I'm out." That's just how it goes.
The other classic solution is using reputation to filter spam — but then we basically just killed the whole point of anonymity

2026-05-10 05:33:58 UTC

There used to be a few things about real estate that I just couldn't wrap my
head around.
Take the 'squatting' controversy in the West, for example. The idea that someone
could illegally occupy a vacant house, stay there long enough, and suddenly gain
rights that make it impossible for the owner to evict them seemed absurd. I
honestly thought America was turning into a socialist country when I first heard
about it.
Then there’s the fact that anyone can legally snoop on a property's registry
just by knowing the address. I couldn't understand why complete strangers were
allowed to check if a house was rented, owned, or heavily mortgaged just to
guess someone's net worth.
Or the lack of absolute 'legal conclusiveness' in the real estate registry. You
hear these incredibly unfair stories of people buying a house trusting the
official state ledger, only to lose their home later because the ledger had been
forged sometime in the past.
And finally, the concept of a tenant's 'opposing power'—the rule that a tenant
must officially register their move-in to protect their deposit. I always
thought, "If I signed a lease and handed over my money, shouldn't my deposit
just be naturally guaranteed?"
Life is full of laws that don't seem to make sense, so I mostly just brushed
them off at the time. But as I dove into Bitcoin and started questioning what it
truly means to 'own' something, all these disjointed mysteries suddenly clicked
into place.
The complex rules around a tenant's rights exist for a very specific reason. A
lease is basically a private contract (a claim) between the tenant and the
'previous owner.' When the house is sold, from the perspective of the new owner
who legitimately paid for the property rights, it is logically correct to argue,
"Your deal was with the last guy, not me. Get out of my house."
But what happens if the law just unconditionally protects the seemingly
vulnerable tenant? A scammer could take out a massive mortgage, default on it,
and then pull out a fake, backdated lease agreement made with a relative to
screw over the bank when they come to seize the asset.
That is why 'public disclosure' is required. By making the existence of a
legitimate contract public at a specific time (like registering a move-in date),
the government promises to review and recognize that right later. It’s a
compromise. And the reason anyone is allowed to look up another person's
property registry is precisely to maintain this public disclosure system.
But herein lies the critical dilemma: the ledger managed by the government—which
effectively acts as a 'monopolistic sequencer'—doesn't perfectly guarantee the
truth.
This is exactly why courts don't grant absolute legal conclusiveness to the real
estate registry. Historically, there have been too many cases where the name
written on the state ledger didn't match the true owner of the land. Fraudsters
have long exploited wars or administrative chaos to manipulate the ledger and
hijack property rights while the true owner was unaware.
So, to make up for this flawed ledger, what happens if the law starts
prioritizing 'actual physical possession' over paper documents? You end up with
the exact squatting crisis we see in the West today.
Whichever path is chosen, scams exploiting the legal loopholes will inevitably
follow. The fundamental reason real estate is so legally tangled and fraught
with endless lawsuits is that, technically speaking, perfectly proving ownership
of a physical asset is impossible. It can only ever be 'presumed.'
High-level verification requires massive costs. People wanted to protect their
assets but didn't want to bear those verification costs, so they handed this
complex arbitration over to a central authority: the government. This has become
the root of many modern social problems. When the government unfairly takes a
side, or when it becomes a player itself and intervenes in the market, we are
left completely defenseless.
This is the core reason why I don't see real estate as the ultimate store of
wealth. I look beyond simple inflation hedging to the true essence of an asset:
"Can I truly own it? Can I prove my ownership without needing anyone's
permission?"
For me, the only assets that pass that test are physical precious metals and
Bitcoin.

2026-05-05 03:51:39 UTC

- reply

https://ark-protocol.org/
you means this? I’m also looking at this lately, and it seems promising. My only worry about Bitcoin is that—even if every micro‑payment were made exclusively through Lightning channels—true self‑custody would require every person to have at least one channel. With the current architecture, just creating a single channel per person would take decades, and the problem only gets worse as the population grows. According to Ark’s documentation, in the ideal case a unilateral escape can be cryptographically guaranteed without a single on‑chain payment, although each batch settlement still needs an on‑chain transaction—but the fee could be $1/n$. That suggests a massive scale‑up possible in a way that differs from Lightning. I’m reviewing the theory and the code to see if it’s real, and I’d like to hear other well‑known developers mention it as well.

2026-04-28 00:44:48 UTC

- reply

So BitVM has that issue? If I'm understanding correctly, Bitcoin L1 can't verify ZK proofs at consensus level, so anchoring relies on operator good faith?
If that's right, then maybe the more natural approach for Bitcoin L2s is to compose only from primitives that L1 can directly verify. Ark protocol seems to fit that mold - periodic batch settlements using only what L1 natively understands, with each settlement providing on-chain finality at fees split across all participants.
Curious whether you've looked at how Ark handles this differently, or if you see issues with that approach too?

2026-04-23 10:46:09 UTC

@npub1xnf…lpr5 Apps connected via NWC are extending beyond a single page, but scrolling isn't working, so the initially registered ones are not visible.

2026-04-13 13:19:50 UTC

- reply

Maybe their profile metadata isn't on their write relays, or they haven't specified any write relays at all. Some clients might just be 'smarter' and fetch profile info from major relays automatically, which is why it shows up there

2026-03-20 00:10:42 UTC

Nostr client developers really need to make it easier to add friends via QR codes — especially when meeting users in person, not just following them online.
Many clients are quite inconvenient in this aspect, and some don't even have this feature at all. It's unreasonable to expect users to manually type long public keys, and given that Nostr is decentralized, search functions are already limited. It’s frustrating that even when you meet someone in real life, adding them as a contact can be such a hassle.

2026-03-19 12:50:37 UTC

- reply

make sense

2026-03-19 00:43:00 UTC

- reply

Great!!

2026-03-18 23:15:38 UTC

- reply

I clicked to check the details, and it said the connection wasn't secure. But when I clicked again, it suddenly said there was no problem with the certificate. I'm not sure what's going on. I tried to capture a screenshot of the English message, so I switched the settings to English, and then it suddenly showed everything as normal with no issues. Then, I switched back to the local language, and now the warning has disappeared. It seems like there might have been some issue with the local language version. Not sure what caused it, though.

2026-03-18 15:17:44 UTC

- reply

I already starred it before, so I tried leaving a zap, but it didn't work. It says it's not connected to the NWC relay. Could this be related? Maybe the domain certificate has expired or something...
https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.blossom.band/0572e7207f419c1955bed9e4ca7c83f691fe61610e0959cc79da110f614407d2.jpg

2026-03-18 14:02:24 UTC

- reply

Yeah, it's really frustrating. When I first encountered Nostr and heard it was trying to solve the problem that other social networks don't show notes from people i follow in chronological order, I didn't really understand it—especially as someone who doesn't really use social media. But lately, I've come to understand it perfectly.

2026-03-18 00:54:14 UTC

- reply

It's hard to reverse a negative first impression, so I believe it's better to ensure at least minimal usability and comfort before promoting a service. Besides, it's difficult to recommend a social platform (whether a microblogging app, messenger, or anything similar) if users aren't confident that their direct messages will actually be delivered.

2026-03-18 00:25:24 UTC

I was using Zeus Wallet and thought I wouldn't need Alby anymore since it supports NWC, so I uninstalled Alby. But it turns out Zeus isn't as reliable for payments—while it works fine when using Zeus directly, it often fails when connecting through apps via NWC. Probably because Zeus runs locally on mobile, whereas Alby operates via server. Looks like I'll have to reinstall Alby.

2026-03-18 00:14:17 UTC

- reply

permanent storage (best-effort) for paid users, and volatile storage for free users to save space

2026-03-13 00:33:45 UTC

- reply

I see that spam filtering is being handled, but simply blocking known spammers every time isn't a real solution. Eventually, is WOT (Web of Trust) the only answer? Or perhaps a PageRank-like scoring system based on extensive collection of kind 3 events?
I'm also curious how your relay operates. I've considered attaching tiny amounts of e-cash as economic incentive for relay operators, which could contribute to a healthier ecosystem. But since events are commonly pooled and broadcast simultaneously to multiple relays (especially since there are usually several tagged recipients in a p-tag, and each user likely has at least two or three inbox relays), I'm not sure users would accept the added complexity. Plus, managing different policies(price) across relays would make implementation quite cumbersome.

2026-03-12 00:49:58 UTC

- reply

Oh, I see. thk

2026-03-12 00:34:24 UTC

- reply

You mean this is a non custodial wallet? But how is that possible if I'm not running my own Lightning node and opening channels myself? Given how quickly the setup was completed, it doesn't seem like an embedded LN node is being used either.

2026-03-03 08:01:27 UTC

- reply

I tried to leave a review, but it asked me to break through the captcha, so I just left a zap instead ✌

2026-02-23 23:49:55 UTC

I'm currently using @nprofile…vavr mint through @nprofile…p4uv , and I'm reaching out with a question. I'm personally developing a service that requires payment via hold invoice, and during development, I was testing the expiration/cancellation behavior by paying a hold invoice using the Keychat Cashu wallet. The payment attempt initially seemed to fail—although the payment did reach the recipient side, it remained in a "pending" state since it wasn't settled, which is expected. I didn't mind the unclear UI indication, since most wallets don't clearly display pending states anyway.
However, the next day, after the invoice expired as intended and the payment properly failed, I noticed that the deducted balance in my Keychat wallet wasn't restored. Normally, when a hold invoice is canceled, the mint's Lightning node should recover the funds and reflect that credit back to the user's balance. If this were my own Lightning node, the balance recovery would have happened automatically. But with the Cashu wallet, since I had already paid ecash to the mint to initiate the payment, my balance was deducted up front. From the mint’s perspective, once the ecash was spent, the balance was marked as spent—even though settlement never occurred. And since the control had already been effectively transferred, the mint likely considered the payment as completed on its end. It doesn’t appear to track the subsequent cancellation status.
Moreover, due to the anonymous nature of ecash, the mint likely can't identify who made the payment—even if they wanted to issue a refund, it might not be possible. I can provide proof of the hold invoice and confirmation that it was ultimately canceled (via DM). Surely a refund shouldn’t be impossible? I understand it might not be easy to verify, and while I understand if no refund can be issued (it's only 5,028 sats, not a large amount), this highlights a bigger issue: going forward, such payments need to be properly handled. Otherwise, it effectively means users permanently lose funds to the mint even when payments fail. This isn't just an issue with Minibits, but likely all #cashu mints. A proper mechanism needs to be developed to handle these cases.

2026-02-20 00:43:06 UTC

- reply

GM. It's nice to see someone on Nostr who's in the same time zone as I am.

2026-02-08 06:58:53 UTC

- reply

I thought the spec said that files with identical content should always produce the same hash, but in practice, that doesn't seem to be the case. It looks like the hash is being generated by including metadata such as upload time as well.

2026-02-03 05:39:06 UTC

- reply

Even if it's possible to make the exact amount with the current token combinations, it still ends up using just the tokens I have on hand, which can result in multiple inputs—like sending 256 using two 128s, for example. Swapping to send a single 256 token looks cleaner. But would making that the default behavior be wasteful due to the extra network round trip?

2026-02-03 01:53:40 UTC

- reply

It would be great if, when issuing tokens, it could automatically send the exact amount using the minimum number of tokens—like finding the optimal combination. If the available tokens can't form the precise amount, it could fetch suitable denominations from the mint to make up the difference. It would be convenient if this were handled automatically at the library level. Do you know if such a feature already exists?
@nprofile…xnfk @nprofile…vcku

2026-02-03 01:47:24 UTC

- reply

Yeah, that's right. I've seen others solve it by creating animated QR codes, but that brings compatibility issues and loses the charm of printing and handing it over, lol. But if we just make it tiny and packed, it probably won't scan well either...
For now, I'm just sticking to issuing tokens in denominations that match Cashu's unit (like 256 or 128), so I don't need to include that many tokens anyway—this works fine for me.

2026-02-01 11:53:09 UTC

There's a feature in Keychat wallet where sending "pay ecash" returns an ecash token, but sometimes it comes with a QR code and sometimes it doesn't. What's the difference? I'd like to provide a smooth experience where users can simply pass along a QR code, but when it only returns a token, I have to send it via DM, which is a bit inconvenient.
#asknostr @nprofile…p4uv

2026-01-31 02:45:13 UTC

- reply

Also can I convert my current balance into an eCash token form and send it to someone else? I'm trying to transfer the full amount cleanly without leaving change in my yakihonne wallet. @npub1yzv…rf8q

2026-01-31 01:41:46 UTC

- reply

Is it not possible to receive a Cashu token in the form of a QR code? I thought the "Redeem" option at the top was meant for that, but it doesn't seem to work.

2026-01-27 00:46:18 UTC

Sometimes, while using a VPN, Nostr-related apps occasionally fail to work properly. Since they always start working again as soon as I turn the VPN off, it's nearly certain that the VPN is the apparent cause. I initially thought the VPN might be blocking WebSocket connections to relays, but since the apps often work perfectly fine even when the VPN is on, that doesn't seem to fully explain it. What's more puzzling is that @npub142g…xrj0 always works without any issues, regardless of whether the VPN is active or not. I can't figure out the reason for this inconsistency.

2026-01-16 00:41:12 UTC

- reply

Full compatibility? cool. Does it provide migration support for makers? Those with fidelity bonds might find switching difficult, so it would be ideal if simply copying the existing data folder would allow full functionality.

2026-01-16 00:31:01 UTC

- reply

jumble is my favorite client in terms of UI, but it definitely has a bit of a loading lag—especially during initial startup. I've always thought that Nostr clients would benefit greatly from an architecture where a separate background process handles subscription to relays and manages writing events into a local database. Would the development complexity increase drastically with this approach? Perhaps, but I believe the advantages gained from such a design would be substantial. While completely rebuilding existing clients might not be practical, I hope developers creating new clients will seriously consider this kind of architecture.

2026-01-14 10:42:20 UTC

- reply

I'm currently using the Qwen3 235B A22B 2507 model. Are there any newly released models that offer better performance and better cost-effectiveness? For example, models with nearly similar performance but significantly cheaper, or slightly more expensive models that deliver much better performance? Performance criteria can be based on general user experience.

2026-01-09 18:38:36 UTC

I believe providing economic incentives to relay operators is essential for the nostr ecosystem, and among the possible approaches, attaching e-cash when publishing events seems optimal to me. I’ve been skeptical of subscription-based payment models, and more importantly, with standards like NIP-17, users send their DMs not from their main pubkey but a temporary one—making subscription models fundamentally incompatible.
Recently, I noticed increasing spam accumulating on my personal relay, which became quite unpleasant. I thought there must already be a NIP addressing this, so I went looking—but found nothing. Hmm? I decided to try implementing a solution myself, even if just according to my own idea. But immediately after starting, I understood why such a standard hasn’t emerged yet.
It turned out to be too complicated. When publishing an event, devs familiar with the nostr ecosystem typically use an outbox model, publishing across different sets of relays dynamically. However, most clients don’t publish to individual relays one by one, but broadcast to all target relays via nostr-tools(or something like that). This means if we want to attach e-cash to a *specific relay only*, implementation complexity spikes dramatically.
Moreover, what happens if the relay’s price changes? How should the relay behave if it receives the same event again (e.g., due to a re-synchronization or backfill)? Should already-sent e-cash be refunded, and if so, how? And if refunded, must that e-cash be redeemable again? When you dig into all these edge cases one by one, the feasibility of such a system becomes questionable.
The most practical implementation so far might be keychat approach, but even that was designed for a messaging app rather than a social network—and still doesn’t integrate well with the idea of an inbox-relay model for DMs.

2026-01-09 04:56:38 UTC

- reply

you can use ollama in vscodium via cline (an vscode extension)

2026-01-08 00:26:56 UTC

- reply

So at first, I thought that when I left a comment, the inbox relay of the tagged person had a paid relay, which is why that popup appeared.

2026-01-08 00:24:30 UTC

- reply

That's weird. Even though I'm not using those relays (neither inbox nor outbox), I occasionally get a payment request popup on Amethyst.
PS. Is that popup message following some standard NIP related to the monetization process of relays? For example, receiving a response like "refused: payment required," and then displaying a popup to the user showing something like "this relay requires $X per month," with pricing information included in tags or similar structures?

2025-12-29 23:16:13 UTC

- reply

The one and only thing you realize the more you study history is that people learn absolutely nothing from history.

2025-12-29 03:08:49 UTC

- reply

I think providing Relay operators with some form of economic incentive is essential for a sustainable, decentralized communication ecosystem, and attaching ecash to messages seems like the most sensible solution. I'm not sure if users will accept it, though...

2025-12-24 00:31:32 UTC

- reply

When an individual has, in any way, accepted or validated a statist system, they cannot entirely disclaim responsibility for its outcomes. As thinkers of the Austrian School have long emphasized, such systems operate inevitably through coercion, privilege, and the suppression of spontaneous order—regardless of which faction happens to hold office. It’s therefore ironic when people celebrate the targeting of those they dislike, only to express shock when the machinery turns against others. If, after recognizing this pattern, one still believes the highest priority is preventing a particular party from gaining office, then of course they would support another—even if it means endorsing the very structure they claim to oppose. Haha.

2025-12-23 00:30:03 UTC

- reply

I want to change it to cln, but I hate to close the channel that's already open, so I can't bring myself to do it

2025-12-23 00:26:59 UTC

- reply

I never realized NIP-17 was this vulnerable to gaslighting—I thought scale was its only weakness. This definitely shifts the conversation toward whether Nostr needs an MLS-style approach for secure groups.

2025-12-22 16:23:53 UTC

- reply

I'm living in this country, and it's fucking terrible. Especially in Korea, there's a personal identification ID for everyone, and real-name verification is mandatory for virtually all financial systems. Since this is mostly done through phone, avoiding it is nearly impossible.
I'm only fortunate because I've already moved all my assets into Bitcoin and physical gold/silver, but my monthly salary still comes in fiat currency... I really need to figure out a way to quickly switch to earning Bitcoin as income, but I can't find a feasible solution yet. Alternatively, I should make as much money as I need to live on as fast as possible and flee to a country with a lower cost of living. Honestly, the whole situation here is just utterly fucked.

2025-12-22 00:33:37 UTC

- reply

I decided to have steak for dinner tonight.

2025-12-17 13:57:09 UTC

- reply

genius

2025-12-17 00:37:34 UTC

- reply

Just two more to find — let’s go

2025-12-11 11:41:37 UTC

- reply

You're right about that. Since this isn't a research paper, this should be enough.

2025-12-11 10:55:28 UTC

- reply

What I meant wasn’t the airport itself, but border control—there was some room for misunderstanding. Even those granted entry are forced to give up all privacy, subjected to interrogation and scrutiny by the state. And nighttime curfews in parks? That goes without saying. I could keep listing such examples forever.
In a society where property rights are truly protected, pursuing one’s own interests without force isn’t flawless—but it is by far the best system we have. Nothing beats it. You might cite cases where profit-seeking leads to neglect of safety or fairness, but even those cases are almost always driven by government coercion. Take the most tragic reality of our time: children being killed in bombings during war—there’s a clear, horrifying example. Who’s most responsible for enabling such horrors? Right. The government.

2025-12-11 09:49:31 UTC

- reply

The landowner of private property will exert every effort to attract people to their land in order to gain profit—voluntarily, not because they're forced to. This is far more sustainable. In contrast, public spaces, which are supposed to be freely accessible, often end up being even more restrictive. Just go to an airport once, and you'll understand.

2025-12-11 08:55:48 UTC

- reply

Expression of strong support for freedom of speech typically leads to counterarguments like the cases mentioned by @npub1000…vwqk and @npub1t3g…l5g4 — situations which most people, including the original poster, would find unacceptable (for example, threatening or sexually harassing someone's children). Faced with such cases, the original argument usually retreats, resulting in the conclusion that completely unrestricted free speech is impossible. In my view, this conclusion generally stems from profoundly statist biases.
Specifically, it arises from the illusion that vice can only be corrected through the coercive force of a violent monopoly — the state.
However, genuine freedom of speech can only be consistently and logically achieved through rigorous defense of private property rights. Notice how problematic examples are almost always set in "public spaces" — but the very existence of such spaces is the root of the problem.
Imagine a fully free society. In this world, there is no such thing as a "public space." Every piece of land is privately owned, and access is granted solely at the owner's discretion. In such a scenario, offensive or insulting speech? There would be no need for laws restricting speech. Instead, basic common courtesy — polite requests to refrain from offensive remarks — would suffice. If someone ignores the landowner's request, they become, by definition, a trespasser. They will then be treated as an unlawful intruder — subject to removal or other responses appropriate to illegal entry on private property. Ta-da! No law restricting freedom of speech, yet vice is corrected?
We must abandon the illusion that only state violence can correct immoral behavior.

2025-12-11 00:25:57 UTC

- reply

which client support quote zap event?

2025-12-03 16:45:13 UTC

- reply

#nevent1q…9275
I have a question for a hardcore Bitcoiner: what are your thoughts on the issue linked here? If you look at my history, you’ll see that I’m not trying to troll or start an argument—I am asking out of genuine curiosity.
I consider you to be one of the most influential Bitcoiners on Nostr (unlike those who just treat Bitcoin as a "get rich quick" scheme based on hearsay). I’m asking you specifically because I believe you have likely given serious thought to problems like this.
It seems inevitable that in the future, the mempool will be flooded with just channel-opening transactions. When that day comes, and ordinary people can no longer afford the fees for even a single on-chain transaction, how will they be able to own Bitcoin?
If there is no way for them to do so, wouldn't that essentially negate Bitcoin’s greatest advantage? If there is a solution, what is it?
Oh, of course. Regardless of the ultimate debate over whether gold or Bitcoin is the 'true money' that will endure longer, I do agree with you that those selling Bitcoin now to buy gold and silver will soon regret it. But just to be clear, my question isn't about the near future.

2025-11-28 11:57:36 UTC

Snorkeling with sharks in the Maldives https://blossom.primal.net/2d16014efb7d57eb2f04563d3653b65a738e812c57fbe88245659014f3cf0681.mp4

2025-11-27 10:59:12 UTC

- reply

Are there any technologies that can remotely disable surveillance cameras? Something like a miniaturized EMP or similar?

2025-11-27 03:49:47 UTC

- reply

I think the true final boss might be IP addressing and the routing system itself.

2025-11-24 13:32:40 UTC

Being at a resort with a poor internet connection has made the performance differences between Nostr clients strikingly obvious. nosotros seems to be the best. Of course, this might require a deduction based on how well it adheres to the Outbox model, so a simple comparison based on initial loading speed alone might not be a fair assessment.

Originally, the top performer in this area was @nprofile…wywf but it slowed down a bit after the Outbox model update a few months ago.
In reality, we can't really know how perfectly nostr clients construct the feed using the Outbox model. Since most people designate at least one large, popular relay as their outbox relay, it would be difficult to notice if a client doesn't actually support the Outbox model.
As a side note, @nprofile…mh2x android was the only one that worked even when the internet connection was completely severed. This must be due to it fetching the feed from a local database rather than a relay, building the feed, and continuing to accumulate data in the local DB in the background. It's fast, too.

2025-11-21 00:55:12 UTC

- reply

"when a member sends a group message, it essentially sends a one-to-one message to the other members. Therefore, the encryption security of small groups is almost equivalent to that of one-to-one chats, but the number of members it can support is limited."
Because of this, some Nostr clients seem to have trouble distinguishing whether a message delivered to me is from a small group chat or a 1-to-1 DM. I've been switching between so many different clients that I've forgotten which ones they were.

2025-11-17 00:24:25 UTC

Questions about @npub1h0u…rwx8
* Direct Message Sorting: When I receive DMs through Keychat, the messages are often out of order, not sorted by the correct chronological time. This seems to be due to sorting by the randomly chosen time for metadata protection, following the NIP-17 standard. However, doesn't the encrypted data inside the seal contain the true timestamp of when the message was written?
* Duplicate DMs: The DMs I receive are consistently displayed twice, as duplicates. I have no idea why this is happening.
* Signal Protocol and NIP-17: I understand that Keychat uses the Signal Protocol, yet I still receive DMs from clients that do not support it. Does this mean that while sending messages uses the Signal Protocol, receiving messages supports both NIP-17 and the Signal Protocol?
* Transaction Fees and Refunds: I saw in the documentation that sending a message (adopting a "postal system" model) consumes 1 sat via ecash. However, it seems to be immediately refunded. What is the reason for this refund? Could it be because I sent a DM to someone using a client that doesn't support the Signal Protocol, and the message therefore couldn't be delivered? In other words, does Keychat have a system to refund the sat if the message delivery fails?

2025-11-15 13:38:37 UTC

There is a single reason why I cannot be completely positive about the future of Bitcoin. It's the scalability issue, and many people would say the Lightning Network is the answer. Of course, I've realized its usefulness by actually running a node, but I'm not fully convinced that it will work perfectly even when Bitcoin is used as the true money itself in the future.
This is because an on-chain transaction is still required to open a channel, and Bitcoin's block size is fixed at 1 megabyte at the consensus level.
I agree that the proper way to solve the scaling problem is through the Lightning Network, after solving the transaction malleability issue with SegWit, rather than increasing the block size. Increasing the block size requires a hard fork, is not a fundamental solution, and makes it increasingly difficult for individuals to run a node.
However, can the Lightning Network be a fundamental solution? If the population continues to grow while Bitcoin's supply and block size are fixed, won't there inevitably come a day when people cannot afford the fee for even a single transaction, even if they work their whole lives? Even if everything is processed through Lightning, at least as many channel opening transactions as the number of people being born are needed, and that number will only continue to increase, right?
This is a mathematically foreseen problem if we accept the assumption that the population will grow, not just a curse from pessimistic critics driven by jealousy. Consequently, won't the common people be unable to achieve true ownership in the genuine sense of the word?
I'm curious about the stance of nostr user on this. The positions I've encountered so far are as follows, and I can't agree with any of them:
* Solve it with a hard fork. -> This is the stupidest solution. How is this different from Bitcoin Cash?
* The population won't grow that much. -> Is the future of humanity that pessimistic?
* Ownership can be managed in a form like ecash. -> Does this mean complete ownership is solely the privilege of the rich and earlier generations? Doesn't this negate Bitcoin's greatest advantage?
* A solution will eventually emerge that guarantees complete ownership and is affordable for common people, no matter how large the population. -> Isn't this overly optimistic?
This is the reason why, even after understanding the Lightning Network, I bought Bitcoin with all the money I had left, and continue to buy Bitcoin with my salary (excluding living expenses), but I haven't been able to go all-in by selling my gold. Is there a solution I don't know about? If someone knows, please let me know.

2025-11-07 23:24:48 UTC

- reply

Hello. Thanks for the test. You are Megalithic.me, correct? I was really helped by your documentation when setting up the node initially, so it's good to hear from you. Anyway, since the server hosting my Lightning address is run by an amateur, the connection is a bit unstable. It was turned off and on again yesterday while some work was being done. It's strange because by the time you replied, the work should have been finished. I tested sending from my separate wallet just now, and it did go through.
However, this has happened before. For example, transfers to my address from Wallet of Satoshi didn't work. I don't know the reason. When I inquired with them, I received a response suggesting it might be because my server supports too limited TLS options, but looking at my Nginx configuration, that doesn't seem to be the case. Anyway, it's a mystery. I'm starting to think it might be best to just leave the operation to a professional, as you advised. I plan to do so if I see a few more failures.

2025-11-07 10:47:32 UTC

Just in case anyone doesn't know, your follow list is completely public data on Nostr, and due to how decentralized SNS works, it is the type of data that is rarely but is recommended to be broadcast to almost all relays.
And this information is utilized for various purposes. The most common use is to act as a filter to screen out unpleasant spam. Since Nostr has no administrators (censors), a separate mechanism is needed to filter spam, and it's typically used to make an assumption like: posts by people who are followed by the people I follow are probably not spam, and so on.
If you still see an unpleasant image despite such filtering, it means someone in your follow list is following the spammer who posted that unpleasant image, which naturally leads to users trying to find out who that person is.
Of course, I know that following someone doesn't necessarily mean agreement, support, or affection for that person, but your taste can be questioned, so I hope you manage your follow list with a bit more caution.
If you feel those around you don't know this, please boost this so they can become aware without feeling awkward. Lol.
I should also check my own follow list to see if I've accidentally followed anyone

2025-11-07 02:00:49 UTC

#foodstr
https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.blossom.band/0e30c53edd962702e32057d63f75f49e9a454d9806e5974f5703c1c955a59cd4.jpg

2025-11-03 03:17:17 UTC

- reply

I lost it :( My precious 5 sats (7 including fees) are gone lol.

2025-11-02 13:54:42 UTC

Today, I finished migrating the translation service for #jumble to a self-hosted setup. I initially looked into LibreTranslate, as it was an available option, and discovered it's an open-source translation model. However, after testing it, the quality was significantly lower than Jumble's official translation service—to the point of being unusable.
Then, I remembered that the translation performance from Ollama, which I use regularly, is quite impressive. So, I built a simple adapter that mimics the LibreTranslate API but delegates the actual translation work to Gemma3:27B running via Ollama. It's working perfectly.

2025-11-01 07:59:14 UTC

- reply

Most people don't really understand what inflation actually means. In that state, nothing you say will make any difference.

2025-10-30 01:50:49 UTC

- reply

If on-chain transactions are inconvenient, they can use Lightning channels; if channel liquidity management is inconvenient, they can run a Chashu mint — so if someone still insists on creating an alt, it means they have some other agenda.

2025-10-30 01:06:27 UTC

- reply

Feeds from individuals following thousands of different pubkeys are fundamentally impossible to paginate in a true sense, and I see this as the biggest performance issue with nostr. That's why most people say the most practical solution is for each person to keep their following list at a reasonable size.
However, from my past experience studying Neo4j’s internal structure, I realized that structural support is actually possible for paginating notes from arbitrary lists of pubkeys in reverse chronological order. Unlike current typical relay architectures—where we have to fetch a batch of events per pubkey, then merge and re-sort them—it felt like Neo4j’s structure could directly query only the exact amount of data needed for a given limit and offset, making the operation much more efficient.
But is this just theoretical? Would it actually not be that much faster in practice?

2025-10-28 06:51:13 UTC

- reply

The most important reason why Bitcoin is great is that it operates independently of traditional systems, functioning regardless of what laws or politicians do. People who keep talking about politicians needing to "do something" or worrying about what happens "if politicians regulate it" clearly still don't understand what Bitcoin is.

2025-10-25 10:07:51 UTC

I've been using amethyst and amber together, and even though I haven't received any DMs, I keep getting requests to decrypt something. Does anyone know what this is?
#asknostr

2025-10-23 14:30:31 UTC

- reply

Even more annoying than websites asking me to accept cookies is the government creating stupid legal regulations that force those ridiculous cookie warnings to keep popping up.

2025-10-13 01:09:19 UTC

I learned about the ketogenic diet and discovered bulletproof coffee. I made it, and it's really delicious! Most importantly, it keeps me full until lunch when I have it in the morning.
https://cdn.nostrcheck.me/640432e57eb602031b79d70f09e7be069b0fc227da55c9a0ff5dbcc35791e441.webp

2025-10-07 09:16:50 UTC

I'm using a MacBook Pro with M4 Pro Apple chip and 48GB of RAM to run a local LLM via Ollama. I'm wondering which model would be most suitable. When I ran Qwen3:30B, memory usage went up to about 31GB, so I think I could probably handle a slightly stronger model, but I'm not sure exactly which one to pick because there are so many options.
#devstr #asknostr

2025-09-26 14:00:00 UTC

I'm watching several videos about health and diet, and I'm more shocked than when I encountered Bitcoin and studied money and economics. If this is true, the corruption of modern medicine is beyond the malice of the Federal Reserve in economics. The problem is, unlike economics, I don't have the ability to verify the claims made about medicine and diet.

2025-09-25 14:18:08 UTC

#nevent1q…w9gj
Here’s why you shouldn’t ask AI about finance or cryptography, and most notably, the technical aspects of Bitcoin. I asked because it didn't make sense to me, and the AI responded with a lengthy and complex explanation. If you just go along with it, it sounds plausible, but no matter how much I thought about it, the answer didn't seem right. Eventually, I asked someone knowledgeable, and they said there probably wasn't a special reason for it. It was just one of Bitcoin's many oddities that was originally designed that way and now can't be changed. If these AI systems don’t know, they should just say so. Instead, even when they don't know, they throw out all these sophisticated words, making it sound convincing.

2025-09-25 13:50:59 UTC

- reply

I asked that person about the question, and he also didn't think there was any particular reason it had to be that way. It seems likely to be one of those things in Bitcoin’s history that weren't technically necessary, but were simply implemented by Satoshi that way—and now it can't really be changed, so it's just left as-is. Looks like my guess was right.

2025-09-24 20:06:18 UTC

- reply

Don’t rush. I still haven’t gotten an answer, lol.

2025-09-23 23:09:14 UTC

- reply

Right, I’ll follow your suggestion and ask by email. The blog looks very professional, and I think he’ll be able to answer my question well. Thanks for recommending

2025-09-23 15:48:52 UTC

- reply

I read the blog post you linked, but I still don't understand. In the attached screenshot, the blog states that the reason for putting the previous locking script in the empty signature space is to indicate that we recognize the original locking script. Does that make sense? It's not hidden information; anyone can find it since the txid and vout are specified.
https://cdn.nostrcheck.me/ebc5fb4ccd63e238945f8877738de1f0f16959017feea3dc7c62c2569bb64596.webp
https://cdn.nostrcheck.me/cb5a012f01d420be5284a75ee2ff66c310b26abe4028ce7ce50ce3d7b080f0af.webp

2025-09-23 00:45:12 UTC

When signing a Bitcoin transaction, there's a space within the transaction data reserved for the signature itself. Obviously, since the signature hasn't been created yet, we can't fill in the actual signature at this point—we create it later and insert it.
The issue is that instead of just leaving this space empty, it's filled in with the locking script (scriptPubKey) of the UTXO being spent. Does anyone know why it's done this way?
Is there some vulnerability that would arise if we left it blank when signing, or did Satoshi just design it this way arbitrarily, and now it's too late to change?
I asked an AI, but either I asked poorly or it just gave me nonsense answers.
#asknostr #devstr #bitcoin

2025-09-22 10:13:42 UTC

I've been wondering why many Nostr web apps that support NIP-46 "Bunker Login" only seem to support the case where the bunker initiates the connection. When a user isn't logged in, there's no easy way to transfer the token created by the bunker (unless you use an external messenger or email, which is a clunky solution).
It seems much more convenient for the client to create the token, display it as a QR code, and have the signer(@npub1am3…xrv7) scan it.
I recently learned while working on Jumble's code that the reason for this was a lack of support in nostr-tools for the client-initiated token creation method. Now that nostr-tools supports this feature, supporting the login flow to allow the client to create and send the token to the bunker would make the entire process much smoother.