hoppe2

Here is what the wallet I built does. When it refreshes, it doesn't merge everything into one VTXO. It sets aside a few small "hot" coins for everyday payments and gathers the rest into a single "cold" coin (the names are my own). And when it pays, it uses a single coin whenever it can, because merging spreads the contagion.

Which coin it uses is also fixed: the most worn-out one first. The measure is the amount minus the exit cost, that is, what I could actually salvage on the worst day. The coin where that number is lowest, or already negative, gets spent first. A coin whose exit cost has passed its amount has nothing left to salvage, so piling a hundred more payments onto it costs me nothing further. Spending from a clean coin, on the other hand, eats into money I could have recovered in full.

Done this way, no matter how fast exit cost builds up, it stays quarantined inside one hot coin, and ownership of most of the balance remains intact.

Here is the actual state of my ark wallet. At refresh I split it into three hot coins of 5,000 sats each and one cold coin, then routed every payment through one of the hot coins. While that coin's balance fell by about 600 sats, it accumulated 123 transactions, and its exit cost is now around 87,000 sats. That is 20 times the coin's value, and more than the wallet's entire balance of about 67,000. Had I been spending from one merged coin, everything I own would be impossible to exit (possible, strictly speaking, but pointless). Yet the 52,000-sat cold coin can still leave for about 2,400 sats, 5% of its amount.

As you can see, an Ark wallet has a lot to get right, especially if it is to guarantee ownership without sacrificing usability. But I don't count that as a weakness, because everything that has to be done sits on the local side. What matters for ownership is not whether the logic is complicated, but whether it has dependencies. Even the simplest thing isn't fully mine if it needs someone else's cooperation. Something a bit complicated that depends only on client logic just takes some care to build.

Once a coin has been refreshed, the worst an ASP can do is refuse to cooperate, and then I simply exit. But if that exit costs more than the money, the promise is hollow. Keeping the exit cost down to a reasonable level is what makes it real. And if users can walk away cheaply, the only one ruined by a refusal is the ASP itself, so it has no reason to refuse in the first place.

Over the last four posts I looked at how Ark gains scalability while staying self-custodial. Today I want to look at another of its drawbacks: cost. In the first post I said that most criticisms of Ark are things a well-behaved client can overcome. This is the biggest of them.

Ark's self-custody rests on the right to exit unilaterally. But unlike Lightning, where a unilateral exit takes just two onchain transactions no matter how heavily the channel has been used, an Ark exit has no fixed size. To exit a VTXO, I have to replay its offchain transaction history onchain, in order. Not all the way back, of course; only as far as the last refresh. Still, if I've been spending actively offchain, that can mean dozens or even hundreds of transactions, and whoever exits pays the fees for all of them.

So every time a VTXO is spent, an "exit cost" quietly piles up behind it, separate from its face value. An onchain transaction costs a few hundred sats, so each time I pay a few dozen sats offchain, the onchain value of that coin drops by far more than what I spent. Keep going, and at some point the exit cost exceeds the amount of the coin itself. From then on, my cryptographic ownership of it is ownership in name only.

It gets worse, because exit cost is contagious. If I put a heavily used VTXO and a clean one into the same payment, the change inherits the history of both. Nothing I do offchain can shrink it. Only a refresh resets it to zero.

And a wallet left to its defaults drifts straight into the worst case. A refresh merges my whole balance into a single VTXO, so every small payment after that raises the exit cost of everything I own. Even when I do hold several VTXOs, the SDK's default coin selection reaches for the largest one first.

So is the unilateral exit an empty promise for anyone who actually uses Ark? No. And once again, the fix is entirely up to the client.

On my way to work, I didn’t realize until I got to the office that I’d taken my laptop home over the weekend. I really want to die. When am I ever going to achieve FIRE? Even if I can’t do that, I’d be perfectly happy just to get a job at a company that lets me work from home.

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.

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

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.

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.

has been closing channels. Is this related to the service being suspended after a recent attack, or are they just cleaning up low-usage channels? What's going on?

https://amboss.space/node/026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2

gm. I miscalculated the date and realized that something I thought could be reset today actually turns out to need waiting 10 more days.

I’ve decided I can confidently recommend Nostr to people around me once DMs are reliably delivered in about the top 5 apps by usage.

The most frustrating thing about Lightning is that, no matter how well I set things up, a payment fails if the counterparty’s side is misconfigured. The second annoyance is that when a payment fails, it’s hard to tell right away whether the problem is on my side or the other party’s. A better solution is needed.

In the past, while building a Nostr-related app, I realized that Nostr's pub-sub model lets you act as a server without needing a domain or a fixed IP — and I thought that was incredibly useful. Around the same time, looking at Lightning Address, I thought it was kind of lackluster, but figured it was unavoidable if you wanted a fixed receiving handle. Then not long ago I finally saw CLINK. Why didn't I think of that?!

I’m wondering whether there is a “pay‑to‑read” service on Nostr. On many platforms, if I click a link to read an article, I’m immediately prompted to log in, so I just close the page. A micro‑payment system could be a better solution for that.

Legacy social networks don’t have built‑in payment features, so it seems impossible there, but with Zap and Lightning becoming common on Nostr, it should be feasible, right?

Would it be difficult to implement the part that receives the payment and distributes it? I haven’t thought about it deeply yet. In my usage pattern, when I click a link to a long‑form article that interests me on Nostr, I’d probably be fine with a small payment request. Nostr makes it possible with a single click.

I've noticed a lot of controversy in Western societies about introducing ID numbers. Since I live in a country that adopted this system decades ago, let me give you a heads up on a few things:

Every single time you sign up for something, you'll experience hell.

Site operators will also experience hell trying to manage all that personal data.

You'll see news about personal data breaches pouring in almost every day.

Using issue #3 as an excuse, they'll demand even more personal information under the pretext of better distinguishing identity theft from legitimate use.

Idiots won't realize this whole mess stems from government policies that force companies to collect personal data in the first place—instead, they'll blame companies for "failing to manage it properly," causing social division.

Enormous amounts of time and manpower will be wasted handling personal data that never would have been leaked if it hadn't been collected in the first place.

Under the pretext of protecting personal information, government intervention in corporate operations will expand dramatically

I'm trying to switch the wallet setup in my phone's Nostr client to use a local relay (specifically

) and @zeus for fast responsiveness, but it doesn't work properly in almost all clients.

I suspect it's because they automatically block WS connections instead of WSS. Only amethyst allows zaps, but even there, balance and history checks don't work.

Blocking WS is fine, but localhost should be whitelisted as an exception.

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

How do I get rid of the red inquiry button floating on the screen? It's really annoying.

Am I the only one who thinks it's weird that the playback bar, play/pause button, or settings button cover the video when watching? Isn't this way too annoying?

https://zapstore.dev/apps/com.hoppe.cliprelay

I had Claude build me a clipboard sync tool using Nostr. I've always found it extremely cumbersome to copy something on one device and paste it on another by having to open a messenger app, find the chat-with-self room, paste it there, then on the other device open the same messenger, go to that chat room, tap on the message, and copy it again.

Sure, similar tools probably exist out there, but these days with Claude around, it's so quick to just ask an AI to build it—so I went ahead and made one.

Here are the app's key features:

• Supports only NIP-46 login (direct use of private keys is not supported. Aside from security concerns, the problem remains of how to transfer that private key to another device. Isn't it ridiculous if you still have to use a messenger just that one initial time to send it over?).
• Tracks in real-time the relays and Blossom server specified by the user, and transmits data through those servers.
• Text is encrypted using NIP-44 self-encryption; images are encrypted with an AES-GCM one-time key, then the encrypted binary is uploaded to Blossom, while the SHA-256 hash and decryption key are sent via NIP-44 encryption. General file types (beyond images) are not currently supported.
• Supported on Windows, Linux, Mac, and Android; iPhone is not supported.
• Usage: On desktops, after installation and login, there’s nothing else to do—copy on one device, and it automatically appears on the other's clipboard. On mobile, there is a persistent notification—after copying, tap the persistent notification to send it to the other device. When receiving, a separate incoming notification appears (distinct from the persistent one), and tapping it copies the content to the clipboard.
• Currently free. I'm considering a payment system for the future—specifically when large file support is added, I'm thinking of passing charges directly through the Blossom server (not that I intend to collect payment directly). Enabling economic incentives for Blossom server operators was actually one of my motivations for building this app. I plan to support it once a smoother payment standard emerges.
• On mobile, the app attempts to stay running continuously unless explicitly closed by the user (though this cannot be guaranteed).
• Care has been taken to ensure plaintext is never stored outside the app’s own storage (e.g., in notification systems), though this cannot be fully guaranteed.
• Clipboard history is stored plaintext on the device itself.
• Logging out deletes authentication data along with the history.
• The NIP-46 communication private key is stored in the OS-specific secure key storage.

I’ve put effort into encryption, but given my own technical limitations, I can't be certain there are no data leaks somewhere. I do not recommend using this app for highly sensitive or critical information. It’s intended only for everyday, routine use—something that replaces the kind of casual content you’d previously share over messenger apps.

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.

I'm currently using

mint through

, 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.