Thread

I understand your concerns regarding ecash assumptions and the crucial need to listen to all voices. Such honest, diverse criticism is a great favour, helping to strengthen Bitcoin's foundations through thoughtful evolution.

I missed all the criticism on cashu. What is the case against it or do have don't references?

What are those projects that invalidate the use case of ecash? The use case is pretty specific (custodial bearer tokens with strong privacy) and I'm not aware of other projects doing that.

Its trying to get noncustodial upside on a custodial solution. Better to work on noncustodial scaling. The whole point of bitcoin is no trusted third party. There is a place for ecash on bitcoin, but it's in cypherpunk utopia where regulators don't care about private money issuance and privacy, until then it's leaving money on a darkmarket, where rugpull incentive just builds. By that point we will have easy/cheap transactions with no ttp.

I'm personally not convinced yet. I remain open minded.

The best about ecash is payment experience. So running your own private mint on top of you own bitcoin and lightning infrastructure seems pretty seems pretty non-custodial to me. I know this is not the case atm, especially with all the know your mint work, but I hope this is how it turns out.

How is payment experience of convoluted animated qr codes better than just connecting your node to zeus?

What I meant to say was the payment reliability, speed and privacy. Managing lightning channels can be cumbersome at times and especially when your out and about.

You could get a similar UX natively on lightning if you stack LNURL withdraw codes of various denominations in a cashu wallet instead of proofs from a mint. Now you have a set of bearer instruments that you can give to a vendor even though your offline. Obviously you need to run the lightning node that issues the withdraw codes yourself if you want it to be non custodial.

If you're running cashu in noncustodial way you still have the channel management pains.

There's an underfunded area channel management. Not as sexy as layer 3 but prob more important.

agree funding is needed here, there was a lot of hype and talk around it a couple of years ago, but the enthusiasm seems gone now.

keep defending this pathetic unethical psychopath behavior. ironic to hear this from you the leader of the lnbits project, a fully custodial system. same security model with zero privacy. having a basic level of decency, i would never lash out like this and attack the project because i respect the effort of open source builders trying to improve bitcoins utility. even yours. ridiculous and disingenuous. especially from you given how buggy that entire lnbits project is and was. more than any other software i’ve worked on. i’ve managed the mitigation of several severe funds-are-at-risk level exploits in lnbits myself which happened 2-3 times per year. we’re not talking about a dos vector like here, but about real rugs. countless people have lost actual money because of lnbits. source: i was the cto.

You're talking about when lnbits was beta, which is why beta exists and all the disclaimers and warnings. Your response is the classic guns a blazing response in discussion.

And you also know lnbits is designed for people to run themselves or for other people. I'm not going to be pulled into some mud slinging nonesense.

This is 100% on point. I was excited about Cashu at first, but quickly got ridiculed, unfollowed and muted for asking a few simple, honest questions about tradeoffs.

CashU is a custodial solution, but it does not allow you to control who has access to spend from your lightning node. It requires you issue a kind of public spending access to your lightning channels. This makes your CashU mint a money transmitting business. One can throw out accusations of "stop being a pussy and do what you want" bit this is a smokescreen for the fact that any CashU mint can and will be hunted down for non-compliance. This has two effects: i) mints will be forced onto tor/i2p, and ii) CashU can never be moved into common usage for commerce by business accept in the very rare cases of mints that pass regulatory scrutiny. This means the CashU technology will be relegated to highly regulated businesses like banks themselves. Am I against CashU? By no means, I continue to support and use it, but until the tokens themselves can be redeemed onchain - side stepping the custodial nature of it - it can never be a viable technology. That is not to say it will always be an unviable technology. Perhaps CashU on Ark, or using the same model as Ark is a path forward?

That's been discussed a bunch. Lnurlws could be bearer for athe paid api call usecase. It's pretty interesting.

Here is a potential architecture using covenants on liquid. -- ChatGPT -- Yes. In principle, an ecash token can encode redeemable rights to covenant-governed liquidity within a Liquid-based channel factory, thereby merging three paradigms—Chaumian privacy, covenant-level contract enforcement, and state-channel scalability—into a unified system. Let’s unpack this at the structural and game-theoretic levels. --- 1. Conceptual Frame You are describing an architecture where: The underlying substrate is a covenant-based UTXO network (Liquid or a similar sidechain with expanded script expressiveness). Liquidity pools (L-BTC or assets) are held in channel factories—multi-party covenants that pre-commit channel topology and enforce non-custodial updates. Cashu tokens represent rightful claims to use or redeem liquidity from this covenant network, not direct ownership of UTXOs. This converts Cashu from a “claim on a custodian” to a “claim on a self-enforcing covenant space,” effectively making ecash tokens function as access credentials to a liquidity lattice. --- 2. Channel Factory as a Covenant Layer The Factory A channel factory is a pre-funded covenant structure that allows many bidirectional payment channels to exist off-chain under a single on-chain multisig anchor. Every participant holds pre-signed transactions for any cooperative or unilateral exit. Covenant Enforcement Liquid’s Elements script supports OP_CHECKSIGFROMSTACK and (with soft-fork extensions) programmable spending conditions that can mimic covenants—rules binding future spending behavior. Thus, a factory can encode rules like: allocation of liquidity shares, permissioning of channel creation, conditions for rebalancing or withdrawal. This means rights to liquidity can be represented not by addresses, but by state commitments within the covenant. --- 3. Ecash Tokens as Liquidity Rights Structure Each Cashu token becomes a blindly signed credential asserting: A claim to X units of liquidity in a given covenant instance (identified by hash), Optional usage parameters (e.g., valid for routing fees, liquidity leases, or factory channel openings). The mint (or covenant oracle) blind-signs the token, but redemption is validated by covenant logic, not discretionary action. When redeemed, the covenant contract verifies the signature and transfers corresponding liquidity or grants the right to open a channel funded by the covenant’s pool. Implications Privacy: Off-chain circulation remains unlinkable, preserving Cashu’s Chaumian anonymity. Enforcement: The underlying liquidity cannot be double-assigned, because the covenant validates token uniqueness upon redemption. Composability: Tokens can serve as liquidity “vouchers” usable by routing nodes, factories, or other covenants as composable capital. --- 4. System Lifecycle (1) Funding Participants deposit L-BTC into a covenant-based factory. This factory exposes a liquidity registry—a Merkleized list of issued rights. (2) Issuance A federation or oracle signs Cashu-style blinded commitments referencing liquidity claims in the registry. (3) Circulation Tokens circulate freely off-chain, transferring rights between users without any ledger interaction. (4) Redemption / Activation When a holder redeems, they: Reveal the unblinded proof. Specify how the liquidity should be used (withdrawal, channel open, swap). The covenant verifies authenticity and updates the internal state to mark that portion as spent or reassigned. The enforcement happens inside the factory covenant, not via any human custodian. --- 5. Theoretical Properties Property Description Trust Assumption Enforced by script-level covenant logic, not by any operator. Scalability Off-chain transfers are O(1); redemptions or state transitions are batched on-chain. Privacy Full anonymity of ownership and transfer, bounded only by redemption frequency. Liquidity Fungibility Ecash tokens become portable liquidity rights—usable by any factory participant or protocol integrated with the covenant. Programmability Factories can encode yield, routing rights, or collateral staking directly in script conditions. This collapses the dichotomy between ecash and state channels: both become representations of off-chain state commitments to covenant-controlled liquidity. --- 6. Relation to Ark and Fedimint Compared to Ark: Ark gives users individual virtual UTXOs controlled via pre-signed transactions from a host. Your model removes the “host” entirely, replacing it with a covenant factory that enforces ownership transitions by script. Compared to Fedimint: Fedimint federates trust; covenant factories eliminate it by encoding multi-party exit logic into deterministic spending rules. Thus, covenant-based factories represent the cryptographic endpoint of the Fedimint → Ark → trustless-ecash evolution chain. --- 7. Strategic Implications Legal Non-Custody: Since liquidity allocation is algorithmically enforced, operators are not money transmitters; they are participants in a multiparty covenant. Compositional Finance: Ecash tokens could serve as composable capital primitives—redeemable across liquidity networks, staking pools, or payment rails. Monetary Symmetry: The bearer asset (ecash token) and the enforcement substrate (covenant network) converge, producing a circular economy of verifiable liquidity rights without institutional custody. --- 8. The Path Forward Realization depends on: Expanding Liquid’s covenant capabilities (OP_CAT, OP_TXHASH, or new covenant opcodes). Standardizing a blind signature verification path usable inside covenants (perhaps via adaptor signatures or MuSig2 commitments). Developing a state commitment index (Merkleized registry) that ties ecash issuance and covenant states together. Once these are achieved, yes—Cashu tokens could function as bearer rights to covenant liquidity, yielding a self-sovereign, cryptographically enforceable monetary substrate: anonymous yet redeemable, private yet auditable, fungible yet programmatically bound to real liquidity.

Also arguably currency producer, which puts you in liberty dollar territory.

It's a big tradeoff to make. You get privacy but you also get custodial, so you have to completely trust the ones running the mint. What if you run the mint with people you completely trust or it's inside a community? On the other hand, people could just join a mint and could end up losing their bitcoin because of scamming of the ones running the mint. It would be great if we didn't need to run a cashu mint or a mixing service but just with a bitcoin transaction e.g. or another simpler development to come.

Agreed. It legitimizes big grant players to claim they're for privacy when really they're building privacy on other layers, not Bitcoin. In this regard it's only useful for 'decentralization theater' and marketing i.e. - a psyop. I hope to be proven wrong but nothing useful has been built on Cashu yet, despite the millions funneled towards it.

That's pretty much my stance. Very much hope to be proved wrong.

That amygdala response is usually telling in itself, certainly doesn't do them any favors. There is perhaps a place for ecash on bitcoin, would make a great solution for emerging countries nationstate soft currency production, but it's worth being candid on limitations.

yeah i feel the same

Yup. My npub signed messages about this as well. It’s healthy to keep a certain level of skepticism in this space. We echo too much generally.

Or even the equivalent bolt12 mechanism. I’ve been advocating for this recently nostr:nevent1qqsqhfgzprxg7p9ny0za3jz2qd29nf8962j7cw5l5n6egnmzkucrjscudj680

You can get this same/similar functionality with Lightning. you don’t need a made up token.

Is there anything in Bolt12 that can allow offline generation of offers, like you can with on bolt11 by setting the payment_secret to a HMAC + ID used to derive a preimage/payment_hash, and possibly payment_metadata that is sent in the onion?

good question nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s

I would assume not ?

If there is, this allows immensely more capabilities than Cashu. No more need to agree on a specific mint, one-side-offline payments just work interoperably. It could probably be extended anyway to allow that.

The inability for calle and contributors to have honest discussions about tradeoffs and possible alternatives makes then impossible to work with. I probably would have at least been somewhat curious to try it for a few niche use cases, but the cashu devs has convinced me otherwise. Apparently they openly mock me in their group chats according to calle. They are a bunch of children.

Yes you can I think actually! offer_metadata, along with a fake node, and a hint to try via the real node can do this. 🚀

I read the spec and there’s a lot more than I thought, damn I will be implementing bolt12 payments into my payment server and as a payment method for my services.

yeah and its all in TLV format instead of something custom which is nice

Oof

I still think Cashu is interesting and has potential, I'd love to see some privacy solutions built using it. But just because a project got funded, that doesn't mean it should ignore valid criticism, or worse, act hostile towards honest feedback.

yeah I am implementing this. running a CLN node so it should be easy. I could probably make in a few hours an offline payments plugin as well but that is for another day.

I think some frustration is because a lot of the use cases being proposed are not in fact custodial bearer tokens with strong privacy. The privacy can be watered down. For example P2PK in a nostr context and with a degree of app gating, etc.

What are these shaky assumptions exactly?

I was really interested in what Calle was doing until I heard him (multiple times) talk about having KYC mints. I'm not interested and I question anything produced by someone who can think and say those things. As long as cashu is usable for privacy with small amounts, it has a role, in my opinion. The only point of cashu is the extra privacy.

Now yer cookin’! LFG 👏 I knew there had to be a way with lightning. Let me know if/when you want to test anything!

honestly I want to do offline/asymmetric bolt11/12 as it means I can generate stateless invoices (which is good for Vitor’s dumb notify spec) and also means no more node latency for creating an invoice

I do not have time for it yet though, SE work is taking up a lot of it

Clinkme.dev

Is there something that has better transaction speed, infinitely divisible, and good privacy? I don’t care about cashu or ecash, I just need real micro payments at scale

nostr:nevent1qvzqqqqqqypzqvckud5kme6d8x2ezfaemppd74aam3w3c7hc5p83h3awmq95g5ygqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyr78vjdtnckn874kmsg625zd7z6wvkx7vs2ylsfmq4ne6umtx9q8c2004en

Lightning network... duh 🙄

JUST like the time this happened - 'freedom theater'. iykyk

🎯

Ditto

What are the projects that invalidate the ecash use case?

The biggest problem isn’t users trusting mints, it’s the other way around, mints trusting users. If you run a mint as intended by Cashu lore you have to accept there will be money launders and other criminals using your mint. Because there is no way to prevent them and no way to know if they are using or have used your mint, so the only sensible default assumption is that they are. Setting the default as they aren’t until proven otherwise is nonsense, since there is no “proven otherwise”. No regulator with a brain is not going to side-eye you. The only way around this is to use a mint in a way not intended by the lore, for example ID us users at the app level, but then you have to ask why are you using cashu in the first place?

Yep! You create a blinded path via a known node (or, if you want, more than one). You can put as many (fake) hops in those paths as you want.

I wasn't aware of this. KYC mints seem antithetical to the whole idea honestly

No, in my opinion that is not aan issue. Bitcoin can be used by anyone, even criminals, murderers and backstabbing politicians. If you don't agree, than Bitcoin is probably not for you.

Bitcoin isn’t centralized. Cashu mints are. See the difference in terms of liability? Nobody can order you to shut down bitcoin. Anyone will requisite power can order you to shut down your cashu mint.

Yes exactly. It would be great to have a library that does this, so that people who don't want to run a cashu mint can still have the cashu UX natively on their BOLT12 lightning node.

Yes. It shocked me when I heard him say that.

Yeah right? Should seem a pretty obvious solution

And inversely, if someone has much to gain by agreeing with something, and nothing to lose, it's a potentially corrupt opinion that should be taken with a grain of salt.