Hey! I’ve been working on this idea for some time in isolation. I’m in the process of building it. Apologies for not engaging in this discussion earlier. I didn’t realize there was such a robust discussion until I read the Optech year-in-review.
I believe I have solved many (all?) of the issues raised here and discovered several new insights. But in the process I have raised more questions that need answers. Let’s get into it:
You can’t redeem ecash multiple times
I tried this approach as well and decided that it was impossible to reissue an ecash token after the first payout because these tokens are inherently unlinkable to the underlying collateral (in this case a PoW mining share). You can do multiple redemptions by linking the tokens to the mining share, but in the process you destroy the privacy properties of ecash.
I think the correct solution is to only allow one redemption per eHash token. If miners hold the token until the share window expires they get the maximum payout. If they choose to redeem early they donate potential future rewards in that share window to all the other owners of shares in that window. Kind of like how destroying bitcoin only makes the remaining bitcoin more valuable.
If miners want immediate liquidity they can sell their eHash tokens. This closely emulates FPPS payouts without adding trust assumptions (more on this in the auditing section). This will create a new and highly efficient futures market.
To Bob McElrath’s point differentiating futures from forwards, eHash will be a futures instrument because cashu will be the standard. Users can buy and sell tokens from different mints through any exchange medium. Personally, I think decentralized and private nostr marketplaces are the right way to go here but that’s external to this proposal.
Payout Calculations
I go into detail on this in my talk. The key insight is that you can use Calle’s Proof of Liabilities protocol to enforce an arrow of time on mint operations. When a share is accepted, an eHash token will be issued within the current ecash epoch. Epochs are defined by the keyset used by the mint to sign blinded secrets. Epochs will be rotated at a regular time interval. The mint transitions to a new epoch by announcing a new keyset. This essentially ‘buckets’ all shares into time windows that can be used to calculate payouts and enforce a TTL for each token the mint issues.
I find it useful to think of this construction as a series of rolling contracts. Each ecash epoch is a different contract and eHash tokens issued in that epoch are a claim on the block rewards the pool wins within the share window of the contract. Coinbase transactions are peg-ins to the contract and eHash redemptions are peg-outs.
The really cool part is that with this arrow-of-time scheme you also get ecash mint auditing for free.
Auditing
An ecash mint is essentially a new kind of bank. In banking, there are two facets to auditing: assets and liabilities. Ehash tokens are liabilities and can be audited in a privacy-preserving fashion as described in the PoL protocol (linked above).
In the mining pool scenario each PoW mining share represents an asset, it is proof that some miner performed valuable work for the pool and should be compensated accordingly. I haven’t designed this protocol yet but I am keen to get there. This will also be very useful for existing pools since proving share validity is an unsolved problem for the industry at large.
In order to prove the validity of a mining share you need 3 pieces of information: block template, block header, and nonce(s). The goal is to prove that each share accepted by the pool corresponds to a valid block.[^*]
I think all you need is a lookup table of block template, header, and nonce data and a merkle sum tree of block header hashes. In order to prove an individual share’s validity you look up the block template, header, and nonce data, combine them into a full bitcoin block (with insufficient proof of work, probably), hash the header and provide a merkle proof for that header. The merkle sum tree is used to attest to the sum of difficulty of accepted shares. Ehash tokens are denominated in difficulty so this value can be directly compared to the sum of liabilities (mint proofs minus burn proofs (not including ecash redemptions)) from the Proof of Liabilities report. I haven’t fully scoped out the idea but it seems like a fairly straight-forward problem. Am I missing anything?
A really cool aspect of this proposal is that it actually closes all of the gaps that Calle describes in the PoL protocol. By comparing a proof of the collateral used to issue liabilities against the proof of liabilities we can fully audit all mint operations, leaving no possibility of hidden fraud on the part of the mint. (Please prove me wrong!)
I was surprised and encouraged by this realization. By exploring the architecture that would enable ecash mining shares I found solutions to problems that I wasn’t even trying to solve. It’s pretty fucking rad IMO. Keep reading for more solutions to seemingly unrelated problems. 
Goals of the Proposal
This was repeatedly brought up in this thread and I agree that unclear or unstated goals lead to confusion and dead end arguments, so let’s clear the air. I have three major goals in mind, in order of importance:
- distribute block template production
- create a new FOSS self-hostable KYC-free bitcoin onramp
- reduce the minimum threshold of mining withdrawals (enable pleb mining)
I originally started working on this problem with only last two goals in mind but then I had an insight that blew open the doors. Pseudonymous and transparent PPLNS payouts enable a layered approach to bitcoin mining. With PPLNS, you can run a small pool that mines upstream to a larger pool. This lets you skip over the 0-to-1 problem of launching a new pool. You don’t need to launch with enough hashrate to regularly find blocks. A small pool can mine to an account with a larger pool, receive payouts when the upstream pool finds a block, and issue payouts to downstream miners from those funds. This is a fundamentally more scalable arrangement than the monolithic mining pool model that everyone seems to carry around in their head.
It only makes economic sense with PPLNS pools because FPPS pools assume the role of pricing hashrate; PPLNS pools push the ‘luck risk’ or payout variability (and thus the pricing of hashrate) onto the miners. We’re building a decentralized ecash market for pricing hashrate, so mining to an FPPS pool account pays the upstream pool to provide a redundant service that free markets can do a better job at providing. This fee is wasted on an FPPS pool and only increases the cost to downstream miners.
With a diversity of hashpools mining upstream to a few large top-level mining pools we can finally realize the ideal of a big dumb mining pool that does nothing more than aggregate hashrate and distribute block rewards. The second layer pools can specialize in payout mechanisms, authentication (or lack thereof), block template production, and more.
I believe the biggest wins come later when hashpools can start experimenting with template selection and coinbase payouts. Paid template selection would enable hashpools to offer transaction accelerator and non-standard transaction services. Coinbase output markets enable the mining pool to be used as a coin mixer in a fundamentally more private manner than coinjoin services because coinbase outputs have no on-chain transaction history. 
I’ve written a lot on these topics elsewhere and this post is long enough already so I’ll stop here. But ponder this: what would bitcoin look like with a thousand small mining pools innovating in coinbase and block template future (or forward) instruments? The state can stop some of us some of the time but they can’t stop all of us all the time. Let’s fucking go.
[*] Valid within the bitcoin consensus rules at the current block height. The pool also needs to validate that the coinbase transaction includes the cashu keyset_id somewhere and pays the right amounts to the to the right outputs. The keyset_id commitment prevents miners from submitting shares to multiple pools.