Oddbean

Now applied this to aut-ct in a branch: https://github.com/AdamISZ/aut-ct/tree/delta Proving is now down to 1-2 seconds even for large trees like 500K, but this is more from me fixing inefficiencies in my code; the real advantage of their new technique for me is just that they made the algorithms much simpler, *and* we have an easy way to batch proofs now (though I haven't done it). So currently it's: 1-3 minutes to start up a server (which can be left running as long as you use the same curve tree) 1-2 seconds to do a single curve tree inclusion proof 50ms to verify a proof. This already usable for the kind of 'satoshi millionaire' proofs like the one in my blog post, with sets of 500K or so and even larger, but for some long running system which wants to update the curve tree with new utxos all the time, like lightning it should be possible to get rid of most of that startup cost by using an 'accumulator update' method as discussed in the paper(s). nostr:nevent1qqsq39904896te7zp39rq7fxkqdkee7ys4x4wwugw9jj5hpztxu96hqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygr8twz0ua0zz64eglr58rh9r898wafhdh0stkklhf3830gp9cwh9qpsgqqqqqqs8xrlev

I can totally see this mechanism being integrated into a nice business model. E.g. a company offering banks and lenders these proofs for certain users that want to use their services. Or, some form of "proof of rich" in digital identities. Bots can't easily accumulate wealth

Yeah there are a few variations on the basic concept. To me the most natural one is a public service like a nostr relay that wants to offer a cheap, *private* service but does not want to get swamped maliciously; bots could still use it, but not millions of bots.

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.

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.

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.

Appreciate it. Already got some recs from you a couple weeks ago (included your 02bp writing, moonmath manual, and a couple others I haven't gotten to yet. Luckily I have enough background on the non-crypto math to get up to speed at a reasonable rate, but still a long way to go. Will undoubtably have some questions down the line, but just taking in what I can for now