This neither increases privacy nor simplifies accounting. nostr:note1mp82734y7uq3rtmact48e83fns0yexvy2jdfn7sce85c3an2a2rqedvq26
Discussion
Do tell
Privacy issues on pools are almost entirely “what IP is connecting, from where” (as this likely lets you find the physical farm, which is by far the biggest concern with pools). Changing the payout scheme to have more privacy might also seem like it would prevent the pool from knowing the exchange a specific miner uses, but in practice each miner gets a fairly specific amount paid out, so the pool can match payouts with miners. Sure, the miner could go to substantial effort to hide their activities (like taking payout to another ecash mint) but (a) that’s likely to be relatively rare so it’ll stick out anyway and (b) they could do that just as well if the pool just does lightning payouts or even on chain payouts.
I’m not really sure where “simplifies accounting” even comes from, tbh. Accounting for a pool isn’t complicated? You just, like, keep track of a share count for each user. Even with a fancy payout scheme you’d have to do that anyway, if only because users want to see it in a fancy dashboard. So fancy payouts are just added complexity.
Of course pools *should* do payouts in ways that increase payout frequency so that small miners have less outstanding balance with a pool at any time, but making shares ecash tokens is substantially overkill.
Ecash enables accountless mining pools. I think your mind is stuck in the account based model and this thinking leads you to false conclusions.
As nostr:nprofile1qy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqpq2rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sa96tzn said, pool redemptions decouple submitted work from redeemed value. The pool won't be able to link these two because eHash tokens can be freely traded before redemption. The value represented by a proof of work share can go through any number of splits, joins, and trades before it is redeemed. How do you disentangle that using IP tracking? You could try, but if there is any significant volume...good luck with that.
BOLT12 and on-chain addresses just add the account aspect back in. This is a strict reduction in privacy for the user. They can certainly choose this option if the pool offers it but in terms of privacy it is better to receive ecash mining rewards and spend it directly. This way all your activities occur within the anonymity set of the ecash mint.
The ecash model simplifies accounting because the pool no longer needs to track the work of every user that connects to it. Instead, the pool accounts for all shares within a time window and that's it. Instead of maintaining hundreds or thousands of accounts in perpetuity the pool manages one 'account' per hour with a prearranged start and end date. I prefer to think of them as contracts. When the contract end date approaches all the assets (mining shares) and liabilities (eHash tokens) of the contract can be zeroed out and removed from the books. The pool never needs to carry a balance for users that have not met their withdrawal threshold.
This is a dramatic simplification in accounting because it removes an entire class of liabilities that need to be tracked. The business owner no longer needs to be concerned with unredeemed shares.
The eHash tokens (1token = 1share) need to be redeemed first by the miners, before they can be traded.
So, the pool needs to send them *somewhere* - otherwise they remain on the pool's books.
The tokens are probably locked to the miner's npub until he withdraws - which is an "account" (same as some pool use Bitcoin addresses as accounts)
Right?
> The eHash tokens (1token = 1share) need to be redeemed first by the miners, before they can be traded.
No, that is the entire value proposition of eHash. Trade it before it matures.
> The tokens are probably locked to the miner's npub until he withdraws
Again, no. The miner submits a blinded message (random number) with each share. The mint returns a blind signature over the blinded message. The miner unblinds it to get a valid signature from the mint's private key that commits to a secret value that the mint has never seen before. In order to redeem the token, the miner or whoever they have traded with presents the unblinded secret + unblinded signature. The mint has never seen this value before but it knows with cryptographic assurances that it is a valid ecash token.
"trade it before it matures"
1) how can I, the user (=miner), trade something I have no possession of??
The token either resides in the mint (=is not yet redeemed by the miner), or is already redeemed by the miner meaning the miner has been paid already.
2) The pool runs the mint? Or is the mint a separate party?
PPS: how the fuxk is i quote respond in amethyst?
Ecash lets the mint custody some value and issue a bearer asset IOU in exchange for the custodied value. It's digital free banking. https://en.wikipedia.org/wiki/Free_banking
The hard money value is custodied by the mint. The bearer asset ecash token is custodied by the user. I hope that is clear.
In my model the pool runs a mint. They are one and the same.
> PPS: how the fuxk is i quote respond in amethyst?
lol I just manually do it. "> message" is email formatting for a quote. Some nostr clients respect, some don't. 🤷
I know what ecash is, thx 😉
When the miner does work (submits shares), the pool/mint credits him with eHash tokens in his book.
They remain in the pool's book (custody), until the miner withdraws them; that can be once a day, once an hour, whatever.
My question was/is, how would the miner be able to trade this eHash token *when it is still in custody with this pool*??
He has nothing in hand, other than a promise (which he can't even prove). Who would trade for this?? They would trade for an IOU (from the miner) of an IOU (from the pool)
You are making assumptions and running away with them. Slow down and think it through, Hoss.
> When the miner does work (submits shares), the pool/mint credits him with eHash tokens in his book.
correct
> They remain in the pool's book (custody), until the miner withdraws them; that can be once a day, once an hour, whatever.
Currently, mints do not expire ecash tokens. This is unsustainable and it doesn't scale. We are going to a place with expiring ecash tokens. Mark my words. In my model, all eHash tokens expire a fixed amount of time after the token fully matures. If the user doesn't redeem it for ecash in time, the value is lost.
> My question was/is, how would the miner be able to trade this eHash token *when it is still in custody with this pool*??
As explained in my previous email, there are two assets being custodied. The user custodies a bearer asset token. An IOU. The pool custodies the proof of work share while it accrues value from each block the pool finds in the maturity window. The user can hold or trade the IOU while the mint keeps track of the proof of work share. I hope this is clear now.
> He has...a promise (which he can't even prove).
All pool and mint operations will be verifiable after the fact.
> Who would trade for this??
Any market maker seeking privacy or willing to take on a little risk for a larger bitcoin payout would be incentivized to buy these tokens. Any miner seeking access to immediate liquidity would be incentivized to sell them.
> All pool and mint operations will be verifiable after the fact.
This is an understatement. Miners can actually prove the value backing their share before it matures or is redeemed. Although, if they trade it away they lose the ability to fully verify it.
They can even prove what block template they were mining on. And I have some ideas on how to leverage this. ;-)
> The user custodies a bearer asset token.
No. The bearer asset token (eHash) is minted by the mint (=pool). And yes, that balance accrues, then more shares the miner submits. But the token
But these tokens remain in custody with the pool - until the miner withdraws them. Then, and only then, he can trade them.
Up until then (when he eventually withdraws the token and therefore takes ownership of them) he can only trade claims to the tokens. Hence my comment "he can trade IOUs of IOUs".
Now the core question: Why would anyone trade for these claims to the token (who are then claims to actual Bitcoin)???
Firstly, the miner would have to prove to the buyer that he is entitled to these token that are currently accruing with the pool. So a) there has to be some record, some ledger (account) at the pool level to keep track of how is owned what. And b) the miner has to proove to/convince the buyer that he is actually the person who is owed this token balance. (How?)
Secondly, even if we assume the miner were to find a buyer for these IOUs of IOUs, they are less worth than actual bitcoin; they'd trade for 90cents on the dollar. Why on earth would any miner sell his bitcoin at a discount?
"Need for immediate liquidity" you say???? Are to you telling me there are miners how have intra-day liquidity requirements, such that they would be forced to sell at a discount??
Because even now, any miner/seller can already get payouts on a daily basis via Lightning (https://academy.braiins.com/en/braiins-pool/faqs/rewards/#are-there-any-limits-for-lightning-payouts)! And keep 100% of his bitcoin, instead of 90% (or whatever the discount would be at which he can sell). Or every ~1.5day if they use BOLT12 payouts at OCEAN.
Bottom line - I still dont see why this construct would make sense
Keep noodling on it, maybe it will make sense one day. I'm not gonna wait for you. I'll be busy building the future.
No matter what you do you still have an “account”, even if it’s not a formal concept. If you have a (group of) miners connected over TCP to the pool, that’s basically an account. You also have to ultimately withdraw the ecash tokens and turn them into bitcoin. You aren’t going to do that one token at a time (fees would dominate, even if you’re withdrawing to another ecash mint over lightning), which again basically creates an “account”. You’re just playing semantics here.
As for “it simplifies accounting”, I think you’re wayyyyy overthinking the complexity of accounting in a pool. It’s a really trivial Postgres DB and that’s it. Most of the complexity is to provide additional features users want like hashrate monitoring, device monitoring, etc. that obviously doesn’t change since users still want that info!
Matt, you are playing semantics not me.
> it removes an entire class of liabilities that need to be tracked. The business owner no longer needs to be concerned with unredeemed shares.
This is the actual win. It simplifies life for the pool operator and reduces barriers to entry as a new mining pool.
> Most of the complexity is to provide additional features users want like hashrate monitoring, device monitoring, etc. that obviously doesn’t change since users still want that info!
Yes. And this is a dumb model. We can do better.
nostr:note1h29j4dt3kzreamzmpg8u9xkzxmwxnjwv8x4y0hmetg7yuqjmjq9sp29flx
> > it removes an entire class of liabilities that need to be tracked. The business owner no longer needs to be concerned with unredeemed shares.
WHAT?! No pool should ever, ever, ever not track the total liabilities in each ecash epoch. Sure, they can *in theory* stop tracking individual shares, but they still need to track the total shares and the shares redeemed to ensure bugs in the ecash system don’t bankrupt them.
> we can do better
Sadly, users want, like, a UI that tells them their hashrate and monitors their devices and such. That should be run locally, on that I assume we agree, but actually building that is the hard part here, not anything related to ecash. The ecash part doesn’t improve complexity here, you move the tracking locally but you still have to build it (and it’s harder to build cause you have to build it to run on the miners end)!
> No pool should ever, ever, ever not track the total liabilities in each ecash epoch.
You are jumping to conclusions. The pool tracks liabilities with absolute precision. The value add for the pool is that expiring ecash forces users to exit their position and claim their rewards. This allows the pool to zero out their liabilities in a rolling time window fashion.
> actually building that is the hard part here
Free and open source software means I can build it once and give it away to the world for free.
> You are jumping to conclusions. The pool tracks liabilities with absolute precision. The value add for the pool is that expiring ecash forces users to exit their position and claim their rewards. This allows the pool to zero out their liabilities in a rolling time window fashion.
This isn’t a unique feature of ecash. The pool could do this today if they wanted. Similarly they could not do it in an ecash system, if they want.
> FOSS means I can build this once
True, and to be clear I think this is something that should be built and would be great for the mining ecosystem unrelated to ecash! If miners start doing monitoring locally pools can track less things and that’s better for everyone. I’m still very skeptical that the last step of jumping to ecash-based shares is useful.
> they could not do it in an ecash system
Not sure I follow. This is possible and I am building it.
> I think this is something that should be built and would be great for the mining ecosystem unrelated to ecash! If miners start doing monitoring locally pools can track less things and that’s better for everyone.
Yes. It is orthogonal to eHash, (something you helped me realize :) but this is the tech we need to save bitcoin.
Nobody else has built it so I will build it. I'm gonna need help, tho.
I plan to elaborate at nostr:nprofile1qqsxhwmaw842y4zzzk580cfke4l5jr6xyh44v3v6pk59dnyzjm2a7vqcd5flv in May.
> Not sure I follow. This is possible and I am building it.
I was pointing out that liability expiry is unrelated to ecash. Pools can define liability expiry any way they want in their ToS. With or without ecash.
> local mining monitoring
Awesome! Glad it’s being built. Way too many years in the process… Have you chatted with the Sv2 folks about this? They have a protocol (starting to be) designed for auditing what shares you submitted that they want to standardize for proxy or device -> local monitoring agent.
You mean this repo? https://github.com/demand-open-source/share-accounting-ext
We are planning to migrate to a SRI extension using the share accounting extension as a model. I wasn't aware that it could be used on a proxy. That's pretty sick. 🤙
I see the benefits of ecash in some contexts, but for mining payouts specifically, wouldn’t an LN setup with blinded paths or reusable payment codes already solve a lot of these concerns? Miners running rigs can surely operate an LN node and keep it always online, making payouts private without needing to change the payout scheme entirely. Curious if I’m missing something here.
> refuses to elaborate
So badically you're saying if you change your IP often, you have perfect privacy and nothing can be improved further?
I know that's not true but I do wonder how you would end up with that opinion.
Huh? No? I’m saying the privacy issues with pools are not solved by adding an ecash intermediary. One of those issues is IPs, but I list other issues too:)
So you agree that ecash payouts improve privacy.
Please go reread my note?
I don't get the argument. Accounting software keeps track of everyone's balance. This doesn't have anything to do with LN or bolt12 or whatever. You have an account, then you withdraw (with whatever payment method you like).
We can get rid of the accounting using ecash.
(a) you’re drastically overthinking the complexity of accounting here - it’s like the simplest possible Postgres DB? (b) users want actual features which require more tracking, which is where the complexity lies, nostr:nevent1qqs88h9gh45wrzdhkgmt99zqlqzgnmelp4063rxfp0xtxr4spdawexcpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpzamhxue69uhhyetvv9ujucm4wfex2mn59en8j6gpzamhxue69uhkummnw3ezuendwsh8w6t69e3xj7spz3mhxue69uhhyetvv9ujuerpd46hxtnfdue7exlp
I've built accounting software for years, I know what I'm talking about. I thought we're talking about privacy right now.
So do you agree that ecash improves privacy compared to accounting software tracking every miner's balance?
Wait you’re the one who changed the topic? You said something about privacy, I said “go reread my note, I explained it” then you jumped to “accounting is hard”. No, ecash for mining pools does not materially improve privacy. Also, no, ecash for mining pools does not materially change the actual share accounting that has to happen as most of it is unrelated to the money itself.
Scroll up, I've been talking about privacy the entire thread, It's you bringing up complexity, not me.
I really just asked a simple question: does ecash improve privacy compared to ordinary accounting?
It does, in a very simple way.
The practical privacy issues in pools are not addressed, at all, by using ecash. This goes both for payouts (as ecash tokens have to be turned into Bitcoin) and IP privacy issues. Worse, other features pools are expected to offer today make for absolutely zero practical change to pool operation even if you use ecash!
But also, uhhhh, you definitely weren’t talking about privacy here, you changed the topic 🤷♂️ nostr:nevent1qqsdtzt4pst8j0plrrv5qm5u8awyp5aap4375jfct7f4dcdxhmsu5qskl3kxx
I asked you a simple question, you're not answering it. Of course, ecash privacy is better than normal accounting.
You might be imagining some elaborate ecash scheme or something. This is not that. The pool can do whatever it's doing right now but just get rid of accounts. It's simple and there are practically zero compromises.
If you don't know what the idea is about, I'm happy to explain it in a call. I'm sure you'll understand better where I'm coming from.
I totally understand your argument here but you didn’t address any of my points - (a) this isn’t actually practical because no one would use such a pool, (b) this doesn’t solve the IP-level privacy issues (which are the biggest issues for privacy on a pool by farrrrr!), (c) this doesn’t actually improve payout privacy since there’s a privacy loss when the user goes to (bulk) withdraw (basically the privacy ends up being the same as just doing lightning withdraws from the pool!)
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.
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 :/
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.
with all due respect nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg, Matt Corallo is a ridiculous clown. Your life energy and talent are better spent elsewhere.
What's your argument? I'm pretty sure you're wrong.