Cashu-based reward system for a pleb-friendly Bitcoin Mining Pool

[plebhash]

plebpool finds a block with $X_B$ sats in the coinbase (subsidy + fees)

The entire reward of $X_B$ on-chain sats is used to mint an equivalent $X_C$ e-cash sats on plebpool mint.

Everytime new e-cash is minted, a LN invoice fee ($F_{M}$) is paid by the plebpool mint. So the e-cash block reward has $X_C = X_B - F_M$ sats.

Let's imagine 3 miners contributed to finding this block.

• Alice has hashrate $h_A$
• Bob has hashrate $h_B$
• Carol has hashrate $h_C$

Therefore, a fair distribution would be:

• Alice: $\frac{h_A}{h_A+h_B+h_C} * X_C$ e-cash sats
• Bob: $\frac{h_B}{h_A+h_B+h_C} * X_C$ e-cash sats
• Carol: $\frac{h_C}{h_A+h_B+h_C} * X_C$ e-cash sats

Everytime the miner withdrawls their reward, an invoice fee $F_W$ is paid on LN. As a result, each miner will get the following rewards on LN:

• Alice: $\frac{h_A}{h_A+h_B+h_C} * X_C - F_W$ LN sats
• Bob: $\frac{h_B}{h_A+h_B+h_C} * X_C - F_W$ LN sats
• Carol: $\frac{h_C}{h_A+h_B+h_C} * X_C - F_W$ LN sats

Let's imagine Carol's hashrate is really small, such that $\frac{h_C}{h_A+h_B+h_C} * X_C - F_W < 0$. Carol will need to continue contributing hashrate and wait until plebpool finds new blocks, such that the total sum of her e-cash is enough to cover for $F_W$.

refs:

• https://en.bitcoin.it/wiki/Comparison_of_mining_pools
• https://ocean.xyz/docs/tides
• https://github.com/thesimplekid/cashu-rs-mint
• https://delvingbitcoin.org/t/building-intuition-for-the-cashu-blind-signature-scheme/506

[plebhash]

some tweets by @callebtc:

Bitcoin mining pools should issue rewards in ecash so that miners can mine without accounts and remain private. Miners then withdraw ecash to Lightning or on-chain whenever they want.

Nobody needs to know how much you've earned. This is more important than most people realize.

---

Mining pools should run their own mint. It's a perfect use case and the incentives are perfectly aligned.

---

How would it work?

With every submitted share, the user also submits a blinded message. If the pool seems the share is valid, it issues a blind signature in the success response. That's ecash.

The pool doesn't know who you are. It doesn't know how much you've mined in total.

---

Cons: there is no central place where the users rewards are stored. They would have to be accumulated in the mining pool software. If the user deletes the software (and all backups), there is no way to refund them. The price of anonymity.

Pros: no accounts. no tracking.

[plebhash]

With every submitted share, the user also submits a blinded message. If the pool seems the share is valid, it issues a blind signature in the success response. That's ecash.

Attaching blinded messages to shares in exchange for blind signatures as "share receipts" indeed could bring some interesting design possibilities for a trust-minimized share accounting mechanism.

If the pool establishes some level of transparency with regards to how many share receipts it has signed in total (as well as their difficulty targets), the miner can easily verify that they are getting a fair amount of sats when they redeem their share receipts. The pool could still inflate this number, but I guess that's an inherent issue with any mint. Also, every single pool in the industry today already requires a substantial amount of trust, so I think this is already some significant progress with regards to the state-of-the-art.

In practical terms, this idea would also require something like a new SV2 protocol extension to allow for new message formats that would be able to carry such info.

Of course, a new mining protocol could alternatively be established for these purposes. But I think it makes sense to leverage something that is already an industry standard for mining, like Stratum.

The pool doesn't know who you are. It doesn't know how much you've mined in total.

Anonimity between pool and miner is hard, I'm not sure it can be easily achieved (at least under Stratum).

On SV2, the communication wire between pool and miner is assumed to be a TCP socket with AEAD. Introducing something like Tor would incur delays, which in mining terms translate to economic penalties.

[a-moreira]

Interesting idea, very simple. I'm curious what the calculation would be considering the parameters you mentioned:

• the number of valid shares the miner submitted for this specific job
• the difficulty of each valid share
  AFAU this should be linear as well 🤔

[storopoli]

Since $\hat{h}$ is a function of the found shares $S$ why not simplify everything and just do:

$$R^t_p = \frac{S^t_p}{S^t} \cdot R^t$$

where $R_p$ is the reward of participant $p$, $R$ is the total reward, $S_p$ is the $p$'s found shares, $S$ is the total shares.
Anything that has the power $\cdot^t$ indicates that is with respect to timeframe $t$.

No need to estimate anything, just work with observed stuff.

[plebhash]

Difficulty of the share is know when it's submited, right? You plug it into D. The unknown is the current hashrate of the pool.

We don't plug the individual share's difficulty into $D$. I would plug it into $d$, while $D$ is the difficulty threshold of the mining channel agreed between miner and pool (in order to optimize for bandwidth and avoid spam).

I'm basing this rationale on Rosenfeld, which establishes:

A quantity known as the difficulty (which we will denote $D$) is adjusted periodically by the network and determines, as the name suggests, the difficulty of finding a valid block. The target value is chosen so that every computed hash will lead to a valid block with probability $\frac{1}{2^{32}D}$. ... Strictly speaking it is actually $\frac{2^{16}-1}{2^{48}D}$. We will ignore this distinction throughout the paper.

This is talking about actual blocks, not necessarily shares in a pool context, but the rationale still applies (a valid share means the pool will accept it as valid PoW and not label it as spam). My interpretation here is:

We establish $D$ as a difficulty threshold (not really the difficulty of one individual block/share), because the formula is presented as the probability that this is a VALID block/share. That means the actual block/share difficulty $d$ is above some threshold, and thus $P(d > D) = \frac{2^{16}-1}{2^{48}D} \approx \frac{1}{2^{32}D}$.

I'm relatively confident about this interpretation. And this is still useful for estimating the hashrate $\hat h$, because all the pool needs to do is verify that $d \geq D$ is true for every received share. But how do we implement such verification?

My previous question #7 (reply in thread) was:

There's a simple formula to calculate a difficulty parameter for any given block/share hash. We simply interpret each hash (H256) as an integer (U256), and do difficulty = u256(genesis_hash)/u256(hash).

I just want to make sure that it is safe to interpret that difficulty_target is the same as $D$. We should be able to reverse-engineer this from the $P(d > D)$ formula, since it's all probabilities around the bits of the genesis hash (0x00000000ffff0000000000000000000000000000000000000000000000000000 ). But I haven't been able to do this reverse-engineering yet.

$$R^t_p = \frac{S^t_p}{S^t} \cdot R^t$$

That would only work if the pool established an identical difficulty threshold for every miner, because this assumes that every share has the same value. It is a practical simplification, but unfortunately it doesn't scale well.

If we want to accomodate pleb miners, that means the pool needs to be able to establish communication channels with low difficulty thresholds. But if every communication channel has a low difficulty threshold, when a large miner comes in, it consumes too much bandwidth because it submits valid shares too often.

[plebhash]

The answer to my previous question is: yes, the difficulty_target in the calculations above is the same as $D$ in our formulas for hashrate estimation.

I found the answer here: https://en.bitcoin.it/wiki/Difficulty

The notation there is slightly different, so I will translate it into the terminology we've been using here:

We have been talking about difficulties in terms of $d$ (for specific block/share difficulty), and $D$ (for a difficulty threshold, which is the criteria for block/share validity).

Let's also establish that:

• $U256(\cdot)$ means we are interpreting some hash as a u256 integer
• $s$ is some block/share hash
• $T$ is the target hash, such that $s$ is only valid if $U256(s) < U256(T)$

The formulae to calculate $d$ and $D$ are:

$$ d = \frac{U256(T_{genesis})}{U256(s)} $$

$$ D = \frac{U256(T_{genesis})}{U256(T)} $$

We can also say that the probability of a valid share/block $P(d > D)$ can also be stated as $P(U256(s) < U256(T))$.

We know that $T_{genesis}$ = 0x00000000ffff0000000000000000000000000000000000000000000000000000

Which is basically 0xffff shifted left 208 times. If we switch to decimal notation, we have: $U256(T_{genesis}) = (2^{16} - 1) 2^{208}$

So we can say that $U256(T) = \frac{U256(T_{genesis})}{D} = \frac{(2^{16} - 1) 2^{208}}{D}$

But we also know that since $s$ follows a uniform distribution, then $P(U256(s) < U256(T)) = \frac{U256(T)}{2^{256}}$

So we finally arrive at the original formula for a valid block/share by Rosenfeld:

$$ P(d > D) = P(U256(s) < U256(T)) = \frac{(2^{16} - 1) 2^{208}}{2^{256}D} = \frac{(2^{16} - 1)}{2^{48}D} \approx \frac{1}{2^{32}D}$$

QED 🔨

[plebhash]

Also @storopoli , with regards to:

No need to estimate anything, just work with observed stuff.

As I mentioned , the formula you proposed is based on a impractical assumption that every share is submitted under the same difficulty target $D$.

But I did find a way to simplify the formula for rewards, such that it only depends on observed data:

$$ R_x = \frac{\hat{h}_x}{\sum{}^{} \hat{h}_i} * X_C = \frac{\frac{S2^{32}D_x}{t}}{\sum{}^{} \frac{S_i2^{32}D_i}{t}} * X_C = \frac{S_xD_x}{\sum{}{}S_iD_i} * X_C $$

We simply take the product $S_xD_x$ and divide it by the total sum of products $S_iD_i$.

We do this under the assumption that $\hat{h}$ is a reliable estimation ($t \to \infty$), but the actual value of $\hat{h}$ is never really used inside the formula.

[storopoli]

As I mentioned , the formula you proposed is based on a impractical assumption that every share is submitted under the same difficulty target

Great work!
By the way this is conceptually exactly as what I wanted to proposed.
Maybe I was unfortunate in formulating it clearly.

Thanks!

[vnprc]

I think directing the entire coinbase output into an ecash mint peg-in transaction sacrifices an opportunity to provide increased profit and privacy to users of the mining pool's services. I have two proposals to drive increased profits to the miners: 1) a rare sat ordinal auction and 2) an ecash-powered market for coinbase outputs. Proposal 2 also creates substantial privacy benefits for all users.

1. Rare Sat Auction

In the coinbase output of each new block the 'first' satoshi as defined by the ordinal protocol can be sent to an intermediate output, the connector output. This output can then be included in a PSBT signed with an ALL|ANYONECANPAY sighash flag and shared on ordinal trading marketplaces. This allows any interested party to 'bid' on the rare sat by adding additional inputs to the transaction. Thanks to the semantics of SIGHASH ALL|ANYONECANPAY the value of all added inputs must flow into the miner fee. This transparently and verifiably rewards the pool with all proceeds of the ordinal auction. Block template producers are incentivized to include the transaction paying the highest fee for the rare satoshi.

2. Market for Coinbase Outputs

If the pool uses a PPLNS payout scheme, newly earned bitcoin can be monetized via a privacy preserving auction using ecash tokens as a coinbase futures instrument. It works like this: the pool issues an ecash token for each hashrate share contributed by a miner. If latency is too high, the share difficulty threshold can be increased to give the mint enough time to generate each ecash token. All tokens are equal in value within the same ecash epoch, but their bitcoin value is not determined until the pool mines a new block. Tokens can be freely traded among market participants, but they must be returned to the mining pool before the next block in order to secure a coinbase output. Users can buy a coinbase output by providing a payout address and redeeming enough hashrate share tokens to exceed the payout threshold established by the mining pool. Leftover value from the coinbase should be sent to the pool's custodial wallet, to the ecash mint, or to a lightning node. This is a design decision left to pool operators, and is outside of the scope of this technical proposal.

This scheme will create a new private (as in privacy-preserving) free market for UTXOs. Hashrate producers can sell the share-backed ecash tokens they produce, likely for a premium. Purchasers of these tokens will recieve a KYC-free coinbase UTXO with no transaction history. This allows miners to profit from the pristine privacy properties of newly mined bitcoin and creates a free (as in speech) and fair market for privacy-minded bitcoiners to build wealth in secrecy.

An ecash mint must periodically rotate the private keys used to sign blinded ecash tokens in order to prevent the database of spent tokens from growing in an unbounded fashion. The period of time during which a private key is used by the mint to sign ecash tokens is known as an epoch. Backing ecash tokens with hashrate shares creates a natural boundary for ecash epochs. The mint simply needs to rotate the private key used to sign ecash tokens with each new block mined by the pool. This enables the mint to publish a proof of liabilities for each block, creating a fully transparent and verifiable record of all the work that went into producing the block. Users can use this report to verify that every ecash token that passed through their possession is accounted for and that the mint did not cheat.

In order to control the size of the coinbase transaction, the pool must set a payout threshold below which a coinbase output will not be created. All users who redeem more tokens than the threshold will recieve a coinbase output sent to the address they provided. All other users who redeemed less ecash tokens than required to qualify for a UTXO or who redeem their tokens after the block is mined can choose to maintain a custodial account with the pool or to receive payment via lightning or bitcoin-backed ecash tokens. Off-chain payment will require authentication with the pool. This is a design decision left to each pool operator and, as such, is outside of the scope of this technical proposal.

[plebhash]

Thanks a lot for your inputs @vnprc

1. Rare Sat Auction

Personally, I don't subscribe to ordinal theory, since it is not part of the actual Bitcoin protocol. I see it as an arbitrary abstraction that even though it creates speculative market forces that currently generate a lot of revenue to some actors (miners included), there's no reason to believe they will last very long.

As a protocol engineer, I'm motivated to build things that will last for generations to come, so I don't really feel compelled to channel my energy into pushing this idea forward, be it as specs or as code.

I'm not going to censor this as a topic of discussion here though. Anyone is free to contribute, I'm not the sole contributor here.

2. Market for Coinbase Outputs

This proposal is somewhat orthogonal to the initual value-proposition we were aiming for, which is to simply allow for small miners to combine their hashrate (as an alternative to solo/lottery), get some sats-backed ecash in return for each block the pool finds, and easily withdraw their rewards via LN (after they accumulate enough ecash to cover fees). In other words, we want to cater for pleb miners, without necessarily making too many compromises to optimize for profit or privacy.

It seems you are proposing to leverage blind signatures for a different purpose, which is similar to the direction that @callebtc was going on the tweets I quoted above. I think using blind signatures to represent shares is a great idea that could also be combined with our initial proposal, especially because it gives the miner some cryptographic proof for the shares they submit, which helps keeping the pool accountable.

But with regards to your proposal, I must admit don't fully understand it yet, and I see some problems (although I may have just misunderstood it):

the pool issues an ecash token for each hashrate share contributed by a miner. If latency is too high, the difficulty threshold can be increased to give the mint enough time to generate each ecash token. These tokens are all equal in value ...

If different shares were submitted under different difficulty thresholds, they must have different values when they are priced against sats. It's not fair if they are equal in value.

Let's imagine as an example:

• Alice has 10 TH/s
• Bob has 1 kH/s

And (for sake of simplicity) say the pool wants to receive shares from each miner every ~10s, so different difficulty thresholds are established for Alice and Bob.

Both Alice and Bob will submit a similar amount of shares on the same epoch, but Alice's shares represent a much bigger amount of PoW than Bob's. So it's not fair that when those share receipts are priced against sats, they hold the same value.

Note: I'm using "share receipt" to represent a blind signature that was signed by the pool when it received a valid share. I want to avoid the term ecash here, since it could be confused with ecash that's backed by sats.

... their bitcoin value is not determined until the pool mines a new block. Tokens can be freely traded among market participants, but they must be returned to the mining pool before the next block in order to secure a coinbase output.

What if the epoch ends, the pool didn't find any block, but the miner already sold their share receipts for some ecash sats? The buyer now holds value-less share receipts.

If this is a PPLNS-like reward scheme, then as time goes on and the pool doesn't find a block, shares become worthless. So I fail to see why some buyer would want something without a guarantee that they would eventually be able to redeem some sats from it.

Maybe I'm missing something with regards to the speculative aspect of this purchase (I'm still learning about hashrate markets).

[marathon-gary]

If different shares were submitted under different difficulty thresholds, they must have different values when they are priced against sats. It's not fair if they are equal in value.

Concur.
I will refer to blinded hash shares as eHash and bitcoin backed blinded tokens as eSats.

In the Cashu protocol for eSats, the mint uses a keyset to advertise denominations of eSats available. This keyset is not limited to denomination amounts and could be associated to any arbitrary data.

In the given example, I would suggest the pool provide a keyset that has various PoW difficulties that would be used for eHash.
i.e. Bob and Alice may both have 100 eHash shares, but Bob would have eHash associated with the eHash mint's lower difficulty target. This then allows the mint to weigh these eHash share appropriately before paying out rewards.

[vnprc]

Regarding the rare sat auction:

I don't really feel compelled to channel my energy into pushing this idea forward

I totally get it. I don't personally value rare sats more than common sats, but I find the protocol intellectually interesting and there clearly exists a real world demand which means it is economically rational to provide a market for rare sats. I am motivated to build tools that will outcompete the existing centralized mining pools. Ordinals are and will continue to be a profit driver for all mining pools, at least in the intermediate term.

If we want decentralized mining pools to be competitive and not just a LARP we need to build tools to tap into this market. However, this proposal is orthogonal to the topic of cashu-based pool payouts so I think it makes sense to split it out from this discussion thread.

Regarding ecash pool payouts:

If different shares were submitted under different difficulty thresholds, they must have different values when they are priced against sats.

Yes, this is correct. I was unclear in my original post. I have edited it to be more clear: "All tokens are equal in value within the same ecash epoch, but their bitcoin value is not determined until the pool mines a new block."

What if the epoch ends, the pool didn't find any block, but the miner already sold their share receipts for some ecash sats?

The ecash epoch only ends when a block is found. If the pool doesn't receive enough hashrate to ever mine a block, then the rewards never materialize and the share-backed-ecash, share receipt, eHash, or whatever we decide to call it is worthless. Every mining pool has the same problem, it is not unique to this proposal.

I would suggest the pool provide a keyset that has various PoW difficulties that would be used for eHash.

This is a great idea and I think it is fully compatible with this proposal. It helps to enable @plebhash's original goal of pleb-friendly mining. This enables participants to mine with small amounts of hashrate without assuming increased variability in rewards. The pool can establish a range of share difficulty targets with fixed relative values backed by tokens signed from a single ecash keyset.

[vnprc]

share-backed-ecash, share receipt, eHash, or whatever we decide to call it

omg y'all i figured it out...
hashtoken

[EthnTuttle]

👀

[callebtc]

Hey there! I'm by no means an expert on mining and mining pools so excuse me if my assumptions are naive. As far as I can tell though, I would implement an ecash-based reward system like this:

• miner sends mining share and blind messages to pool (blind messages are "proto ecash", they have no value yet)
• pool aggregates shares, finds block, and figures out which share gets how much based on the complicated math you guys discussed above
• based on each share's determined reward, the pool issues amounts and blind signatures on the corresponding blind messages from step 1 (now it's almost ecash)
• pool sends back blind signatures to miners. alternatively miners can remain offline and later request the blind signatures from the pool
• miner receives and unblinds the blind signatures, now it's real ecash
• miner accumulates ecash as long as they wish, and withdraws whenever they wish, as much as they wish, without the pool being able to correlate the withdrawal from the shares that were initially submitted, which was the goal of this whole dance

What do you gain?

• no accounts. it's probably easier to implement than current solutions
• there is no database that tracks which miner earned how much
• mine and withdraw, it's really that simple

If I'm missing something substantial here, please let me know.

Cheers!

[vnprc]

mine to a separate coinbase output which isn't public and publish all the shares for a separate payout address in the main share log

I don't understand how this attack is supposed to work. The point of cheating is to print ecash without doing the work of mining. If you have to mine shares to inflate the ecash supply, just mine honestly. It's less work and no risk of getting caught. I also don't understand how these fake shares would pass the share validation part, that is the whole purpose of that piece. I also don't understand what the pool is going to do when they actually win a block with a secret coinbase output. The whole jig is up at this point isn't it?

You could fix it by publishing the full header plus merkle tree plus coinbase transaction in the share log but actually having any third-party download it let alone validate that is going to be highly impractical

Doesn't 0xB10C basically do this already? You only need one watchdog to keep hashimints honest. Doesn't seem like a big lift to me. https://github.com/0xb10c/miningpool-observer

most pools basically max out their pool servers CPUs 24/7 to validate shares of sufficiently low difficulty

This part does concern me somewhat. The mint is going to be cranking out signatures extremely fast. I think we can just tune the share difficulty higher to moderate the CPU load on the ecash mint. Is there a reason pools need to use such a low difficulty? Edit: I think it should be possible to parallelize the mints, although this brings a lot of additional complexity.

[EthnTuttle]

Is there a reason pools need to use such a low difficulty?

Shares are at a lower difficulty than what the network's difficulty is. This is Proof that the hasher has been working. A higher hashrate hits a higher difficulty more often, probabilisticly. so if you have an S9, you want to show the pool you're trying, but you won't hit a Share PoW amount as often. A share is a PoW but it just doesn't meet the difficulty target for a block. by having the share target, lower, you can include miners with lesser hashrate. otherwise, they won't have many shares to show and prove their work.

[plebhash]

@vnprc if the pool makes public all shares it receives for the miners to verify, that implies that the miners will be calculating one sha256d hash for each share the pool receives.

That doesn't scale well. We can assume there's a really powerful CPU on the pool side, but that's not a practical assumption for the miner side.

[vnprc]

I think I understand the ecash mint operator attack @TheBlueMatt was describing. It works like this: the mint mines to a different block template with a single coinbase output to an address they control. In other words, they direct all of their hashrate to solo mining. But they can double dip by minting ecash tokens for each solo mining share they produce. This allows the mint to receive credit for those shares even though the mint's shares don't contribute to the pooling effort. If the mint wins a block it looks like an unknown solo miner won a block. This attack is only possible for the mint but since miners are anonymous the only countermeasure is to prove that the coinbase of the block template used to produce each share is correct. This will require the pool to publish the block template and complete block header (including nonce inputs: nonce, extranonce, version, timestamp, etc.) used to create every share that it accepts.

@plebhash all miners do not need to verify all of this data. Only one honest party needs to verify the shares to ensure the mint isn't cheating. If any cheating is discovered the verifier can publish the proof and the pool should lose all trust from miners. I think this will be sufficient deterrent for all hashipools to behave. Open question: would this problem be suitable for a zk proof?

As I pointed out previously, there is already a project by 0xB10C that does something very similar. Mining pool observer collects every block template from major pools and compares them against the bitcoin core block template produced at the same time. My proposal adds the computational burden of verifying that each pool share is mining to the correct coinbase output. Proofs only need to be published once for each block that the pool mines.

This is very similar to the proof of liabilities scheme that will be required to prove the mint didn't cheat in other ways. If you haven't read that proposal you really should. We will need to implement it whether or not we try to build share-backed ecash tokens.

If the computational, file storage, or bandwidth requirements are too onerous, pool share difficulty can be increased to compensate. This will increase payout variance for small miners, but, as you already pointed out, pleb miners are probably not very sensitive to increased payout variance. If it turns out this is a problem in practice I think we can use keysets to offer a variety of difficulty thresholds and charge a fee to incentivize miners to choose a higher difficulty target. We don't need to prematurely optimize this part; a single difficulty threshold is sufficient for a proof of concept.

[TheBlueMatt]

Sorry took me a bit to get back to this thread, yes, that is an accurate description of what I was describing.

Open question: would this problem be suitable for a zk proof?

Highly doubt we could make generating such proofs efficient (they're generally incredibly expensive!).

As I pointed out previously, there is already a project by 0xB10C that does something very similar. Mining pool observer collects every block template from major pools and compares them against the bitcoin core block template produced at the same time.

The Mining pool observer project does not validate any shares or have to do cryptographic operations at all, it simply connects to pools and logs what it sees, which is the work the pool gives it (updating once every 30 seconds or a minute). In order to defend against the attack I described an honest party must download the full share chain which has a lot of shares, and then actually validate all those shares, doing the required SHA256 operations that pools are doing constantly. You're right that you only need to get lucky and find the share(s) that are invalid and then publish them, but given the complexities involved I'm willing to bet in practice no one will check at all.

This is very similar to the proof of liabilities scheme that will be required to prove the mint didn't cheat in other ways. If you haven't read that proposal you really should. We will need to implement it whether or not we try to build share-backed ecash tokens.

Proof of liabilities requires a single user only download a very small amount of data and do only trivial verification for themselves. Of course it also suffers from a similar issue in that if the cheating is hidden in a part of the tree no one verifies then it doesn't catch the cheating. In practice very few users validate PoL systems, so they probably don't provide a lot of protection (but definitely better than nothing!).

If the computational, file storage, or bandwidth requirements are too onerous, pool share difficulty can be increased to compensate. This will increase payout variance for small miners, but, as you already pointed out, pleb miners are probably not very sensitive to increased payout variance.

The pool has to work for more than just pleb miners, you need some large miners to get enough hashpower to actually find blocks, and currently large miners demand FPPS with incredibly stable payouts, which is not super practical if you want a total share log volume that you can revalidate and download on demand.

If it turns out this is a problem in practice I think we can use keysets to offer a variety of difficulty thresholds and charge a fee to incentivize miners to choose a higher difficulty target. We don't need to prematurely optimize this part; a single difficulty threshold is sufficient for a proof of concept.

I'd humbly suggest that trying to do a public share log is the premature optimization - first build a traditional pool that does payouts using a mint, see if you can get enough hashpower to be a viable pool (this is an incredibly hard problem) then try to build something more.

[EthnTuttle]

I think a MVP could be:
pool with standard pool accounts mechanisms for shares, except the coinbase pays into an on-chain similar to cashubtc/nuts#107 and the accounting of the shares can be ecash locked to a nostr npub similar to (https://npub.cash/). The username for stratum would be the npub. This serves as a pseudonymous account system and seemingly has better trade offs than traditional pools (self-custody aside).

side thought: Can a coinbase splice into a LN channel? isn't a splice a predetermined delay anyway? so that delay could just be 100 blocks?

[plebhash]

pool with standard pool accounts mechanisms for shares

I don't think there's need for an account mechanism. Even if we don't follow the idea of share receipts (which I'm inclined to), it still makes sense to send a blinded message along with each share.

Those blinded messages are used to mint the ecash rewards after the block is found.

Therefore, I don't think any account mechanism is needed. Ideally, the pool shouldn't need to identify any miner for the purpose of reward distribution. From the perspective of the pool, it just uses the blinded messages when creating the ecash, while trusting that someone will be able to unblind the signatures on the other side.

That is basically what @callebtc laid out here: #7 (comment)

The pool is a blind entity. It blindly swaps shares for ecash, at a rate that is defined after the block is found.

The only identifier the pool keeps for miners is with regards to SV2 channels. Sure, some metadata could theoretically be collected on this dimension. But we don't really gain much from that, so why even bother writing code for a feature we don't really need?

In summary, accounts are a unnecessary feature, IMO.

We can simply focus our efforts in making sure the pool is doing the correct math for shares + blind sigs + ecash (KISS)

(that's one of the reasons I've been writing all these fancy equations above. I'm quite confident we have a solid grasp on the math foundation for share accounting for a PPLNS-style)

[plebhash]

btw, I'm drafting a NUT to formalize all these ideas:

https://github.com/plebemineira/nuts/blob/nut-pool/X.md

cc @callebtc @storopoli @lorenzolfm @a-moreira @jaonoctus @oleonardolima

[plebhash]

reminder: Github UI rendering of $\LaTeX{}$ equation on line 71 seems broken

$$ R_x^e = \frac{\hat{h}_x^e}{\sum_{i=1}^{N} \hat{h}^e_i} * \theta_C^e = \frac{\frac{|S_x^e|2^{32}D_x}{t_e}}{\sum_{i=1}^{N}\frac{|S_i^e|2^{32}D_i}{t_e}} * \theta_C^e =  \frac{|S_x^e|D_x}{\sum_{i=1}^{N} |S_i^e|D_i} * \theta_C^e $$

[EthnTuttle]

After reviewing TIDES, it seems that TIDES is orthogonal to the ecash impl and couple possibly be complimentary.
Do you think this nut-pool could use the TIDES accounting mechanism?

[EthnTuttle]

Phrased differently: a TIDES implementation built on Cashu seems doable.

[plebhash]

I still haven't read TIDES in-depth, but sounds like an interesting idea.

[EthnTuttle]

https://delvingbitcoin.org/t/ecash-tides-using-cashu-and-stratum-v2/870