This is exactly the kind of model I was looking for. The Android capability comparison makes a lot of sense, especially per-origin + per-kind permissions with time-boxed grants.

I think I’m going to take it one step further in SkySigner and separate signing permissions from encryption/decryption permissions. For signEvent, origin + kind + duration seems like a good capability boundary. For NIP-44 decryption, since it isn’t really an event-kind permission, I’m considering origin + operation + counterparty pubkey + a shorter TTL instead.

Unknown, destructive, profile-changing and wallet-related operations would still always require explicit approval.

Thanks. This gives me a much more concrete permission model to experiment with.

I think the challenge is that people see the cost before they see the incentives.

"Pay to post" sounds like a toll booth. In practice, SN feels more like a market for attention where value can flow in both directions.

The second part is hard to explain until someone actually spends time using it.

I'm currently learning how to set up my first Lightning node, so the channel probe scanner caught my attention.

Being able to check which peers are actually willing to accept smaller channels before committing funds sounds genuinely useful for someone starting with limited liquidity.

Running the full Bitcoin and Lightning stack on a phone is interesting on its own, but that little peer-selection feature is probably the part I'd want to try first.

I'm still learning how to run my own Lightning node, so the operational side of this caught my attention more than the cryptography itself.

Removing a single online signing key as the main point of failure sounds useful. What I'm most interested in is how that feels in day-to-day node operation: signer availability, coordination, and how much extra complexity the threshold setup adds in practice.

If that can stay manageable without noticeably getting in the way of normal Lightning operations, it seems like a very interesting direction.

That's a fair point. I think the hard part may be less the economics and more getting people comfortable with seeing the nominal number go down, even if purchasing power stays the same or improves.

That probably wouldn't change overnight.

I'm currently learning how to set up my own Lightning node and eventually open my first channel, so seeing the 2.5 BTC channel and a new 1M-sat node in the same snapshot is interesting.

It puts the range of Lightning node operation into perspective. I'm starting at the very small end of that range. 😄⚡

I checked the site and the rules too. The bidding logic is simpler than I expected.

I like the detail that you only pay the difference when raising your own listing, while someone else has to pay the full bid to take that place.

Stripping referral and tracking parameters also makes sense. It keeps the leaderboard focused on the link itself instead of turning it into an affiliate board.

I suspect wages would simply get repriced more often.

Today people expect the number on their paycheck to go up over time because the money itself loses purchasing power. Under a bitcoin standard, keeping the same nominal wage for years might feel just as strange as taking a nominal pay cut feels today.

Shorter review cycles and contracts could probably solve a lot of the psychological “sticky wage” problem without radically changing how employment works.

What I like here is that not everyone entered with the same technical background or followed the same path afterward.

It’s easy to look at Bitcoin development from the outside and think you need to understand everything before you can start. Seeing people learn first and then find their own area to contribute is encouraging.

I actually just started my own discussion about learning Lightning and eventually opening my first channel, then I came across your post.

I'm still learning what running a Lightning node really involves, so seeing eight years of actual operating history is really useful. 1.38M forwards and 3,444 channels puts into perspective how different long-term node operation is from simply opening a channel.

I'm genuinely interested in this side of Lightning, so I'm sorry to see you step away from it after such a long run. Thanks for sharing the numbers and your experience.

I gave it a quick try with a public Bitcoin address. Simple and straightforward.

What I like about the idea is that it turns a fairly technical seed-generation problem into something anyone can check with just an address.

Of course, no match doesn't necessarily mean a wallet is safe, only that it wasn't found among the known attacks. This is definitely one of the tools I'll keep around and use.

Thank you! Still a lot to learn, but I'm looking forward to the journey. ⚡

I'm currently learning more about Lightning and figuring out how to set up my own node, so this comparison actually helped me understand Ark better.

Liquidity and channel management are some of the things I'm trying to understand right now. Ark's different approach is interesting, especially because it doesn't necessarily have to replace Lightning.

I'm still learning, but seeing the different trade-offs side by side helps put things into perspective.

That makes sense. If the wall-clock impact is negligible, keeping dual validation enabled for longer sounds like a sensible safety net while the implementation matures.

Thanks for the clarification.

The part I'm most curious about now is the technical postmortem.

They've said that several attacks succeeded and caused real losses, but we still don't know much about what kind of weaknesses were being exploited.

Once the vulnerabilities are fixed and it's safe to disclose more, I hope they share some details. It would be useful to understand what made these attacks so difficult for a small team to keep up with.

The dual consensus engine caught my attention more than the all-in-one architecture. Running the Rust validator alongside Core and checking for divergence seems like a sensible way to build confidence in an independent implementation.

I’d be interested to see whether you plan to keep shadow validation as a long-term operational mode, or mainly see it as a bridge while the Rust implementation matures.

Requiring user-supplied entropy for every newly generated seed is probably the most interesting change here. Hardware entropy is still mixed in, but the device no longer asks the user to simply trust it.

After what happened, that seems like a much better default than making dice rolls an advanced-user feature.

I just went through the repo. I like that Bitcoin Core is enough to run the basic explorer, while Electrum and the address index can be added only when those extra features are needed.

The fallback for address totals is a nice touch too: correct but slower without the index, rather than simply unavailable.

This is pretty close to what I had in mind. Nice to see the idea turn into actual code so quickly. 👍