Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

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