Replies (49)
Bitcoin's instability mirrors our diet, unstable foundations yield unreliable outcomes
Failing to receive it's much worse than failing to send.
If the user doesn't signal his desire to receive onchain, he will probably fail receiving, and that's a massive fail, imo.
Like everything else on Nostr, if you send something and the receiving user doesn't have a client to see it right away, it doesn't fail.
Because there are so many clients that implement various things in different ways, there is no way on Nostr for you to reliably say that you don't want something. Your keys can be put anywhere the sender wants and I actually think that is what defines Nostr.
For instance, we all might have received transfers from many shitcoins out there. We all might have money waiting for us in several Cashu mints, etc.
You cannot block any of that from happening.
Just to give you a proof point, we tried this idea of blocking people from sending things on the NIP 17 spec, where if the receive doesn't have a DM relay list, the client is not supposed to send the DM.
Virtually every client ignores that rule. So much so that I had to change Amethyst to find nip 17 DMs in other relays just to see those clients DMs.
I think we are the only ones that still block it if the receiving user doesn't have a DM relay list. But I might change that soon to avoid the friction.
Sorry, but sending and receiving Bitcoin is not like sending a nostr note.
And it's not about blocking something to happen, it's about being able to signal a preference on receiving method.
It's such a meaningful difference, user-wise.
🫂
Being able to signal the preference for DM would be nice too, imo.
🫂
We already have that, but nobody uses it, and clients just ignore it. So it not effective. it just adds to the confusion and friction when using Amethyst... :(
Why not? I think people think it is different because it has clear nominal value, but information is far more interesting and valuable than money in social networks. There is no point on applying different standards for them.
Remember that our largest trillion dollar companies are based exclusively on the idea of tracking and selling your social interactions, not your financial transactions.
Bitcoin and Nostr are two different protocols and networks (though undeniably complementary) because money and information are different beasts.
They could compliment each other (and I honestly think they do it very much), but they both exists on their own.
Nobody is saying information has no value, don't try derailing the conversation, please.
🫂
That's because, unlike Bitcoin, Nostr doesn't need consensus. It builds beyond it.
That's why I still think preference signals are very useful.
🫂
We can do preference signals... But people don't even set their outbox relays right.. so not even that crucial part of nostr is working correctly... :(
I am not trying to derail. And I agree that they are complementary to each other. But I also know you cannot separate them from each other.
The point of a zap is to link your social and financial information in a single pubkey.
You don't get to "separate" two different things.
Many Bitcoin users don't even know Nostr exists, and a lot Notr users don't use Bitcoin.
Zap (linking social and financial) was meant to be opt-in.
But you've made it on by default and not even able to opt-out.
But you already know that. The problem is that you consider it a feature, when it actually isn't.
It's not a feature in my mind.. it's just not an opt-in process at all. Youd socially linked transactions will always be public as long as you send them through any Nostr client. Lightning, no lightning, it doesn't matter.
The only way to opt out is to have a Bitcoin wallet that no client sees. And never link the two. You can opt to not use the zap features on a Nostr client but all off those features are there and those wallets are all public.
The recommendation I make to anyone is to have two separate wallet groups. Public and private ones, regardless of the tech stack. Never put your private lightning or cashu wallet on Nostr. Similarly. Never mix your Nostr on-chain wallet with your private on-chain wallet. Never transact between any of them. If you do it once, your private setup is already exposed.
Again, it's not what I chose to use. It's about signaling others my preference, if they decide to interact/zap with me.
Like I am trying to say, we can code your preference... But historically every client just ignores it.
Sorry, but that's not what you are doing.
Showing upfront the zap-onchain option to every user, what you are actually doing is pushing the users into the dangerous path of mixing their "nostr public wallet" and their "private onchain wallet".
You are not helping the user, not at all.
🫂
Maybe I am not making myself clear, we can add this, but seeing how every company in our space just adds bullshit to pretend that things are solved when they are not.... I don't want to participate in that disinformation campaign...
Your client could start by taking it into consideration, if you think it could be a good idea.
But we have lots of warning messages when putting money in and removing from it. As long as they receive in Nostr and send in Nostr, everything is fine.
The disinformation campaign is showing onchain option to every user, knowing that most of them using other clients will never know about this option.
Just my opinion, ofc.
I mean, if we had to remove features that we have but other clients don't see it, we would only have one feed and nothing else.
The funny part is that I had the exact same discussion when doing pronouns in people's profiles and some users wanted me to hide it...
Actually, I have this discussion in virtually every feature we add. There is always somebody asking me to hide things without understanding that it doesn't change anybody else's view of you.
The best place to put those warnings would be in the opt-in option, imho.
That would be the best option to protect the user into a possible future privacy leak.
Again, as I said, you think this is a feature, but it's not if it's not opt-in.
It will never be opt in. It doesn't matter what we do. Hiding it doesn't make it opt in. In this case, nothing ever will.
You don't think the version 0 SegWit (2017) length-extension bug is sufficiently rendered harmless by clients' length constraints?
> Lightning fails in about 30% of the time
Holy shit what? Let’s debug this. Which issues have you opened to the Lightning implementations and providers you’re using? This is not the experience most have.
Preach
Not with custodial wallets sure...
Lightning’s reliability issues are real, but dismissing all post-2014 Bitcoin progress ignores institutional adoption—like ETFs reshaping liquidity dynamics. Just read an analysis on how ETF flows are now driving price action more than tech debates.
The Board
Bitcoin ETF Flows: Price Dynamics in 2026
Explore Bitcoin ETF flows and price dynamics in 2026. Understand how institutional investment impacts Bitcoin's price, volatility, and market struc...
100% I realized it too. Bitcoin just works.
You completely ignored his argument about opting in, which you could have addressed through the UX, and distracted with exaggerations instead. The way you're pushing this makes it look like you have an agenda.
Lightning works 99% of the time, ackchually...
You made it to the bird app, helping shilling some shitcoin :)
"Lightning fails in about 30% of the time." ?!?!? We run some of the biggest and most central nodes on Lightning and see extremely low failure rates. Are you sending Lightning payments with a potato? We obviously cannot see the failure rates for other services, but for Rizful and Alby, unless you are doing something very wrong, you should almost never have failures.
yes it is
source?
I have an agenda... Shit needs to work 100% of the time. It must NEVER fail.
When wallets fail, channels disappear, sats disappear, fees debit from the balance without any confirmation or in a hidden way and/or when people cannot complete a simple zap fast enough to see the result come back, they fully give up the idea of using Bitcoin.
Oh great.. all I wanted... More idiots selling shit we don't want.
Yes, I am an Alby customer for over 3 years and your customer too. Shit doesn't work. Your site is not even understandable to me, a CS graduate.
I just had to talk to Alby 2 days ago to manually change one of my peer nodes IP address because the peer channel owner decided to just move IPs and everything broke.
It's like you have to have a computer science degree to keep simple things tolking to one another.
The state of lightning is terrible.
Keen to find out more about why Lightning is failing for you 30% of the time (as are others).
Heretic! Apostate! Burn the Witch!
Do you blame Alby or lightning itself (or both)?
Lightning isn't for normies. Cashu is centralized. I think both can evolve and upgrade, but we don't have a solution yet. They DO prove the use-case for Bitcoin as programmable money, but they have trade-offs. So far as reliability is concerned, Bitcoin takes the cake. However there are trade-offs for this reliability, of which we are well-aware and is the rationale behind layers built on it.
Architecture is not easy. There are no silver-bullets. Sometimes it takes a breakthrough or a discovery to improve the trade-off optionality. I think that is what we are waiting for.
Take this list of system architecture trade-offs as an illumination. It's not always a simple iron triangle:
- Scalability vs. performance
- Vertical vs. horizontal scaling
- Latency vs. throughput
- Stateful vs. stateless architecture
- SQL vs. NoSQL databases
- Batch vs. stream processing
- Synchronous vs. asynchronous processing
- Consistency vs. availability.
- Cost vs. quality
- Time-to-market vs. technical debt
- there are many others
oh snap I'm about to switch to a new ISP and have been planning what to do for DNS and my VoIP server, hadn't even thought about this
Integrate Bitcoin Cash, Zano, or Dash into Amethyst. There's a growing BCH community, Zano might be even more perfect but unfortunately unknown
Lightning and Cashu reliability issues in certain regions are real, but dismissing all post-2014 Bitcoin development ignores scaling tradeoffs and local context. The ETF flow data I saw yesterday actually shows institutional demand growing despite tech friction—suggests different problems for different users.
The Board
Bitcoin ETF Flows: Price Dynamics in 2026
Explore Bitcoin ETF flows and price dynamics in 2026. Understand how institutional investment impacts Bitcoin's price, volatility, and market struc...
