Nostr Web Client

I think it's hard to see how it's better than custodial Lightning for almost everything, and "offline" is heavily oversold. Someone can sign a token and promise you it's yours, but a promise is all it amounts to until you get online and talk to the mint. "Kind of offline". There's also some parts of the process where you might lose the coin altogether? A nice tip for the mint, but they'll never know it.

The biggest problem is that the mint operator is trapped. Coins aren't fungible across mints, so there's no way to hand things off to someone else. The only way for an operator, even an honest one, to stop is to rug everyone.

There were three motivations behind my Bitcoin Deposits proposal:

1) zero UTXOs

2) private key control

3) an exit path for honest operators

vnprc 4mo ago

Ecash is about a million percent more private than custodial lightning. All other use cases are either improved by the privacy properties or fall back to lightning baseline performance.

Examples:

1. "someone can promise a token is yours" no, actually the mint makes a cryptographically verifiable promise that the token is only claimable by the entity holding the correct private key. This is better than custodial lightning because they don't know your identity so they cannot selectively enforce these contracts. It's very possible to build some kind of staking/slashing mechanism or web of trust if you think reputation alone is not sufficient. It seems like this is a core feature of your proposal. It can applied to mints just as easily as custodial LN wallets.

1a. "a promise is all it amounts to until you get online and talk to the mint" no, you need to know the mint's public key beforehand and have some trust in that mint. In this case you can cryptographically verify the promise from a trusted party. If you don't already trust the mint then it reverts to the custodial lightning trust-me-bro model.

2. "Coins aren't fungible across mints" mints are connected via the lightning network so all it takes is a lightning transaction to reissue at another mint. Many wallets let you configure this automatically so you never even accept tokens from an untrusted mint. Personally, I think the endgame is to have mints directly swap each other's tokens but the cashu team has pushed back on this idea. We'll see where we land in time. IMO it's an obvious scaling strategy. I think we'll build it when demand is apparent, maybe as part of a different ecash protocol.

3. "There's also some parts of the process where you might lose the coin altogether?" yeah just like losing your lightning signing keys. Cashu uses deterministic secrets with a 12 word recovery seed phrase so you can recover your coins if you drop your phone in the toilet. This is equivalent to lightning. You should look at the spec, you have knowledge gaps for big important protocol features.

4. "The only way for an operator, even an honest one, to stop is to rug everyone." this is true today. I think we have to build expiring ecash to solve this problem. This is an inherent feature in ehash so I'll probably be the first to build it. Mining shares have a TTL, they are only valuable in a limited time window so if you wait too long they become worthless. Easy to enforce with a TTL on the token. Extend this functionality to bitcoin backed ecash and you end up with the same UX as ark: wallets have to periodically come online to refresh their balance.

I skimmed your proposal. I don't understand it yet but on the surface it seems to be 1. lacking in user privacy and 2. have an optimistic game theoretic security model. Current DOR lightning channels rely on optimistic game theory and the security problems are manifold. They do the best they can to minimize failures but the attack surface is just so large. This is why LN-symmetry is such a huge upgrade. Game theory is a weak foundation to build on IMO.

This proposal seems like a strict downgrade from ecash. You still have to trust someone and the user has zero privacy from the operator. (Correct me if I'm wrong.)

Reply to this note

Please Login to reply.

Discussion

vnprc 4mo ago

You didn't ask me but I think Spillman channels are going to be a very fruitful field of development to replace the shaky security foundation of lightning with stronger guarantees for onramps and offramps. Let the node operators assume the game theory risk in their channels, but the users need rock solid unilateral exit. If you build a wallet with Spillman channels I'll be very impressed. Now we're finally improving on the lightning security model.

But that's just like my opinion, man...

ynniv 4mo ago

There's a lot in here. I'll focus on ecash in this message.

"a promise is all it amounts to until you get online and talk to the mint"

I'm talking about offline functionality, which is one of the primary talking points for Cashu. When you receive a coin offline, you haven't really received anything until you swap it - hence "a promise". Offline you can verify that the coin was minted by a known public key, but not that you will have control over it. Not only can Alice can double-spend while her recipients are offline, but she can also go back online before anyone else and pay herself. Either way the promise is broken.

"mints directly swap each other's tokens"

I'm not pointing at scalability but transferability. If they were in some way fungible, an honest mint might have some pathway for moving coins and funds to another mint. The privacy features of ecash seem to preclude it, but I haven't looked this deeply into the math.

"just like losing your lightning signing keys"

I'm not talking about losing keys, I'm talking about failed atomic swap requests. This doesn't seem to be inherent in the math, but I've heard that the current protocol can make ensuring delivery error-prone.

"I think we have to build expiring ecash to solve this problem"

I was thinking about that, but it seems to solve the exit rug by continuously rugging people instead. At least, as an honest operator I would see it this way.

vnprc 4mo ago

I'll answer in order:

That's a great point! The solution is to add a timelock, just like an HTLC. This coin is only spendable with a signature from this pubkey until time T at which point it is redeemable by anyone with only the proofs. So if Alice locks some coins to Bob's pubkey then only Bob can redeem those tokens within the time window. After T, either party can redeem them. Alice has essentially locked herself out until time T. I believe this is the default flow, although I haven't verified it myself. I'd love to try it out if you're interested.

I don't understand your point. All cashu mints are lightning nodes. You can transfer the coins with a lightning transaction. The privacy properties of ecash ensure that mints must honor lightning withdrawals for everyone or suffer reputational damage from everyone.

Sometimes it's buggy. You can usually recover from your seed phrase to get those tokens back. This will improve in time as the protocol matures. Do you remember the early days of lightning? #reckless

Yes, exactly! It is a continuous rug. Further reading: https://gist.github.com/callebtc/ed5228d1d8cbaade0104db5d1cf63939

ynniv 4mo ago

HTLC's solve the speed-to-mint problem, but only if Alice is online when she decides to pay Bob. It's an interesting edge case, but most of the time when only one party is online it's the merchant. Either way, it's hard to frame this as a solution to the "offline" problem.

As for transferability, I mean my mint can't move all the coins and associated reserves to your mint if I want to leave. At least, I've never heard anyone suggest this

vnprc 4mo ago

If the merchant is online, the customer just sends the ecash and the merchant swaps it with the mint. This is the standard flow, no issue at all. If the merchant is offline and the customer is online the customer can lock the ecash to the merchant's pubkey with a timeout clause. The merchant must get online, probably within a few days, to claim the coins. These are very reasonable constraints that can be broadly applied to real world commerce. I think it is fair to call this a half-offline payment solution.

If the customer can prepare ahead of time you can do a truly offline payment, but it requires the customer to lock some coins to the merchant's pubkey before they go offline. So the sender of ecash needs to know ahead of time who they are sending to and they have to set a spending max. If they don't spend it all the leftover ecash is locked until the TTL expires. So offline spending is technically possible but not really practical solution for most use cases. For this reason, I avoid the term offline payments.

Just for comparison, in order to make an on-chain payment the sender must be online at time of payment, the recipient must be online and connected to a full node to verify payment. To make a lightning payment the sender and receiver must both be online at the same time for the entire duration of the payment flow. So half-offline payments are a substantial improvement over the current state of the art.

As for your second point, you are correct, a mint can't offload their ecash promises to another mint non-interactively. This is fundamentally a privacy tradeoff. This kind of non-interactivity is not possible in a private system. So your issue is a fundamental limitation of privacy preserving tech.

An example solution that sacrifices privacy would be to associate each ecash token with a static payment address or a pubkey. You essentially have a mint account now which means they can track all of your ecash payments but the mint gains the capability to non-interactively close your account and pay to your BOLT12 or silent payment address. I think this is kind of what your proposal does, with some reputation or staking/slashing incentives.

ynniv 4mo ago

I agree. In many ways my design is an attempt to fix ecash nostr:note1ychfgsuj9lr274enzsn85fwjyeehjss28r75kzltlner8xmkklzqyhcara

vnprc 4mo ago

This is a really impressive proposal that fixes some of the issues with ecash. They built a proof of concept at the last btc++. Check it out! https://gist.github.com/lukechilds/307341239beac72c9d8cfe3198f9bfff

ynniv 4mo ago

This is a cool idea! I think you get the same benefits from opening a channel with long activity requirements and support for splicing, but admittedly that's is a lot more complex than what you linked. I noticed your comment on pools, but I'm not sure these are practical given no one's complaining about stolen funds. The biggest problem is that you need a new UTXO every month-ish, which will soon be way beyond the means of most people globally

vnprc 4mo ago

It's possible to combine the Spillman channel open and close transactions into a single on-chain tx that renegotiates the channel state just like splicing does today. You could do it individually but it's super easy to bundle with other parties using an ark integration.

If you think about it in terms of payment flows Spillman makes a ton of sense for merchants and customers, the edge nodes of the lightning network. Merchants almost exclusively receive payments and consumers almost exclusively send payments so why do they need bidirectional payment channels? They don't.

Put your paycheck into a Spillman channel with a ~35 day timer (for a ~5 day grace period). Spend the balance down over the next month and when you get paid again top up the channel balance and extend the timeout with one on-chain tx. No need for toxic data, justice txs, tx pinning attacks, etc. It's just a more elegant and secure system.

Mining pools are like merchants in reverse. They only pay out rewards and almost never receive payments. There is no market demand for Spillman pool payouts because pools almost exclusively cater to large miners. They don't even offer lightning payouts, except for two small pools. The other problem is that large miners and pools are not sophisticated when it comes to bitcoin protocols. They don't even bother to upgrade to Sv2 which has been ready for years and has clear and obvious profitability benefits.

This is a subsidy problem. Large miners and the pools that cater to them make their money speculating on the value of bitcoin as an asset. Their profits are not determined by bitcoin usage because the subsidy is so much larger than transaction fees. Good news! This problem is going away.

Imagine a world with 10,000 small mining pools and billions of individual hashers mining for heat or to burn off their excess solar power. In this world micropayments and protocol security are of utmost importance. This is the future I am vibing into existence with my cypherpunk friends. It's gonna be AWESOME.

ynniv 4mo ago

Using Spillman for mining rewards is based.

(Not sure I've ever used "based" on purpose 🤔)

vnprc 4mo ago

coin

...wait for it...

based

ynniv 4mo ago

(and now Lightning / Deposits)

Ecash is more private than *KYC custodial Lightning*. But strip the identity away, and you have an address that makes and receives onion payments. Who sent me funds? Dunno. Who received my funds? Not really sure about that either - depends on how the invoice was constructed. What custodial Lightning has is 1) client logs, and 2) payment timings. There is the notable edge case where both wallets use the same custodian, providing full details.

But, what is a address? This is more private than on-chain transactions because not every transaction is available to the entire network. If there existed a protocol that was only as private as the chain, while simultaneously being as fast and cheap as Lightning, would there not be value in it? Imagine swapping value between this system and ecash based on when you plan to use it. I have.

I'm not convinced DOR Lightning is broken. If you push it into difficult corners it tends to break down, but for a few hundred dollars of hardware sitting on a relatively stable connection, it mostly just works. Instead of pushing it harder into uncomfortable territory, I propose that we build something on top of it. Messy? Sure. Half baked? Probably, there's only one guy in the kitchen.

Regarding Spillman channels, I'm not sure of the benefit. It's simpler, but doesn't seem to solve real problems on its own.