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. View quoted note →

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?" View quoted note →

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