Really cool that you’re actually building this. Kudos!
How do people validate shares? A share is a full bitcoin block, including all transactions, but having a PoW less than Bitcoin’s difficulty target… This means a “share” is up to 4MB of data. See General Considerations for Decentralized Mining Pools for Bitcoin for details on this. If block templates are truly arbitrary, this means that any share mining a tx that is not in the share-validator’s mempool cannot be validated. Even if all txs are known at best I have to store and download the txid list for every share. At worst I have to download an entire 4MB graffiti block full of txs I’ve never seen before.
Let me suggest something. Braidpool will be a public blockchain (DAG) with each entry (bead) in the DAG being a share. I’ve proposed using using Deterministic Block Templates to mitigate this problem. The idea being that Braidpool beads carry bitcoin transactions, which for any given set of braid tips defines a committed mempool. Tx selection can then proceed using any deterministic algorithm on this committed mempool. Proof of a share is then only the share header (bead ~ 2kb or so), which implicitly commits to a tx set in a committed mempool, and a block header independently computable via the defined deterministic algorithm. Thus the block template nor its txs need to be separately stored and or transmitted for verification (as long as the share verifier is running a Braidpool node – the data within is entirely public).
Now, this is really only possible with a consensus algorithm on that mempool. Because TIDES and Cashu don’t have any such publicly known list of txs or consensus, that means that shares in your scheme require transporting or storing a tremendous amount of data.
Braidpool is limited on the size of shares it can support, by the restriction on how many beads (shares) can be mined in a given period of time and consensus decide upon them. This is limited by the latency of transmitting shares, and given the 600s block time and observed latencies, this is a bead time around 250ms - 1000ms, so for round numbers let’s call it 600ms or 1000x shares per Bitcoin block. If a miner wins one share per bitcoin block (so has 0.1% of the bitcoin hashrate) he’d have a monthly revenue variance of about 1.5%. Variance reduction is the main point of pools in the first place, and this is really the floor in variance of where miners want to be, given their margins. If you’re a smaller miner than that you either accept higher variance or want to find another payout solution. However 0.1% of the network at today’s hashrate of 800M Th/s is about 4000 S21-class devices. This is a fairly large operation corresponding to 13MW of power. For miners smaller than 4000 devices we need to find another solution.
This is where I think an eCash mint can come in. I’ve proposed Braidpool sub-pools for this, which is another instance of Braidpool that takes payment from shares in the parent pool, instead of Bitcoin. Shares in this sub-pool could be eCash tokens leveraging the corresponding Braidpool sub-pool instance for share information and validation. This could get us down to ~1.5% monthly variance for miners having as few as ~4 S21-class devices. Smaller miners than this (e.g. Bitaxe) could use sub-sub-pools, but at this point the payouts are so small that it’s even difficult to put them on-chain because of the dust limit, so Lightning or eCash tokens are really required because of the small denominations.
I don’t know that it makes much sense to worry about the BitAxe folks though, they’re really playing a lottery, not expecting steady income. Running a BitAxe on a sub-pool is still a pretty nice lottery.
Cheers, – Bob