I'm going to address only (c), I hope that's fine.

Think about OCEAN. They have bolt12 payouts. In order to use that, you just register your offer with them. Every share you submit is linked to that offer. They will try to pay you right away but if your node is offline, they simply write to the DB that this specific offer has made. Say 250k sats since the last payout. They MUST track whichiner has earned how much reward. There is no basically other way.

Except! If each miner receives ecash instead of that db entry, the miner can withdraw to a bolt12 offer of any wallet they want without ever having to register it. The miner doesn't need an account. It doesn't need accounting either. The pool simply issues ecash for valid work and miners withdraw whenever they like to whatever destination they like. There is no way to link *THE SUBMITTED SHARES* to the withdrawal if done right. That's simply not possible with ordinary accounting.

To (b), yes thats right but it's also trivial to fix using VPNs... It's not part of the problem I care about.

Reply to this note

Please Login to reply.

Discussion

Indeed, OCEAN’s approach leaves a long trail in the DB. I addressed this a bit more in the note below, but I think in practice the (bulk) withdraw you’d do with ecash would end up having similar privacy issues as today’s approach. You obviously can’t withdraw each single sat by itself (the fees would dominate, even on lightning), so you bulk-withdraw in batches. You’d have to have every user have the same bulk-withdraw randomization logic, with fresh BOLT12 (or different ecash mints) to withdraw to each time (otherwise you’d have clear fingerprints in the withdraw batches). And even then I’d bet with enough BOLT 12 blinded paths you’d be able to cluster most withdraws :/.

This just isn’t as simple as you’re thinking. I agree there’s a world where on an extreme margin this could improve privacy, but it’s a really tiny margin and a pool motivated to go look would probably be able to see through almost all of it :/

nostr:nevent1qqsprlhwvx7lnlac23l9p6p82dlwjtwddp93dp22fell4l87euerfvspz3mhxue69uhkummnw3ezummcw3ezuer9wcq37amnwvaz7tmwdaehgu3dwfjkccte9e3xjarrda5kutnwd9hx5cgpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpzamhxue69uhkummnw3ezuendwsh8w6t69e3xj7s5yslh4

If everyone withdraws every time, privacy gain is minimal. But (despite the obvious risk of a rug pull) using your ecash mining funds as a regular wallet to pay *other* things is a win. There's already something of a trust relationship, I guess

BTW, nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgkwaehxw309a5xjum59ehx7um5wghxcctwvshszrnhwden5te0dehhxtnvdakz7qrxnfk is there a standard way/protocol for a mint to announce a shutdown schedule? So wallets can (ideally automatically) move funds off?

Sadly ehash tokens aren’t bitcoin, they’re a floating amount of bitcoin which depends on the specific epoch they were mined in (and their value is generally determined a day or so after they were minted, at least with todays payout schemes). They’re not really great to pay with (and I’m not sure a pool would ever want to allow transfer of the ehash tokens for regulatory reasons to begin with…)

This would also depend on the anonymity set. If many shares have the same reward, they should be indistinguishable. One could argue that the whole point about accounting is to delay withdrawals, so it's harder and harder for the mint to correlate your payments.

To your second point: this was just very recently proposed and we are going to add an expiry date to each keyset so that wallets know when to rotate out into a new keyset or withdraw from the mint at an announced date.