Oddbean new post about | logout
 For this particular usecase, I am not super bullish because:

1. micro payments (ecash, lightning) allow services to monetize directly. This was not possible before due to a technical limitation, so businesses got creative and explored a whole bunch of indirect monetization avenues.

2. even for public and free services, something simpler like running pagerank-ish algos (pagerank, personalized pagerank, trustrank...) on the follow graph/zap graph would do the job.

Btw I am actually building 2.

There is defo a place for "proof of rich" in identity. For example giving a free luxury service only to rich people. E.g. try this yacht for free!

Everyone would enjoy a free day on the see, so the business must filter. 
 Yes, some good feedback there. On the first point: I've always thought that this kind of thing specifically addresses the most stringent privacy requirement (or, tries to). So if you consider things like DOS on LN or Tor or other similar networks, LN micropayments can def solve it, but they can't achieve the same anon properties as anonymous usage tokens of this form. In practice, does that matter, given that LN has a decent chunk of privacy built in (if not perfect)? I think only for certain scenarios would you say, no, that's not good enough (there's also a bit of a bootstrap problem to defend LN with LN).

Ecash is faster but suffers from the trust and network effect problem, which are intertwined. Which mint? Crossing mints means more complexity and trust issues maybe? But again, you can imagine niches where it might be ideal.

I'm not going to comment so much on the web of trust kind of ideas that you mention you're working on, but i can imagine them having big advantages w.r.t. user not having to do anything, compared to some commitment like a payment or a token of ownership.

Re: proof of rich, ultimately I *suspect* you're right that it's more useful for higher (not necessarily rich but at least 'larger amounts') size money proofs/commitments than for small or micro- ones, but one never knows how a tech finds its use case until you see it in action, I guess.
 
 Btw another thing about ecash that I think people get wrong a lot is, the fact that it has a central point of failure is not just about trusting with money but it's just a really bad feature of an architecture; consider how much worse the privacy of it is because you have to send messages to a central server every time you make a transaction. 
 > you have to send messages to a central server every time you make a transaction.

This is not necessary. As long as the ecash wallet has enough coins of different denominations, the sender does not need to send a message to the mint server.

For example, Keychat’s ecash wallet will exchange a large number of 1-sat coins with the mint server at once, and these coins are then used as stamps. The sender doesn’t need to continuously send messages to the mint server. 
 Those 1 sat tx can become inefficient over time, mints are expected to incurr fees at some point (a minimum fee of 1 sat is realistic). There are msat keysets where this becomes cheaper though. 
 Sure, sorry to both you and @calle if I was unclear, I obviously do understand that only the receiving party (say, merchant) has to be online/contact the mint. I still think that it is an extremely bad architectural feature that each transaction requires such an online message *to a central party* to be sent. Btw it's important to note that many of the early papers (say 1990 period) on ecash were discussions around achieving offline payment, i.e., avoiding this problem. There was one paper that Chaum co-authored with someone else and there was def one by Brands, probably tons of others. They all focused on an idea of "proved fraud" in case of double spend, thus they used punishment mechanisms. I discussed this quite a lot in the early part of my talk in London, because I thought it was a pretty fascinating issue. 
 Only one of the parties usually has to contact the server at time of transaction. 
 Unless both parties use the same mint, it may be common for receivers to "cash out" at time of transaction to make sure they get their funds 
 Super interesting comments.

> Crossing mints means more complexity and trust issues maybe? But again, you can imagine niches where it might be ideal.

nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qyg8wumn8ghj7mn0wd68ytnddakj7xph5zr some time ago shared the "multi nut payment" or some other silly 🥜 name :)

The idea is that you can have your wealth spread across 1000s of mints, while still being able to pay a single lightning invoice. Just wanted to share that in case u didn't know.

Another very practical observation on the limit of the privacy of your scheme (which, don't get me wrong I find really interesting):

The person has to own an UTXO. Not many people today own an UTXO, so the anonset is already much smaller than the whole world. And for the future, well that'll probably remain small because of the onchain fees.


 
 Yeah but credit money is always going to scale way easier, that's inherent I think.