PowMachina

Documentation

A decentralized pool (a sharechain) — the design

Status: replaced by the Sharepool, a pool built into consensus. This design is not implemented; it is kept as the reasoning that led there.

1. What it is for

A small CPU miner has two options today and both are bad: mine solo and wait weeks for a block, or give their hashrate to a central pool. A botnet is bothered by neither — a hundred thousand bots together behave like a pool, so variance is the least of its problems. Variance is therefore not a technical detail but exactly the disadvantage a legitimate small miner has against a botnet.

How long an ordinary 8-core (~600 H/s in lane C) waits for its own block mining solo:

lane C hashrate the miner’s share solo: a block once every
0.1 MH/s 0.60 % 0.7 days
1 MH/s 0.060 % 6.9 days
10 MH/s 0.0060 % 69 days
100 MH/s 0.0006 % 694 days

The goal: payouts in small parts, continuously, with no operator holding the money.

What it is not: a measure against botnets. It does not restrict them (see the botnet research). It compensates for the disadvantage of legitimate miners.

2. How it works in brief

A miner mines the same MachinaHash, only with a lower target. Most attempts are a share — a proof of work for the sharechain. Every now and then a share also meets the network’s real target and becomes a PowMachina block.

The sharechain is its own chain of shares that the pool’s nodes maintain among themselves. From it, who gets paid how much by the coinbase is computed deterministically. Since the payout list is part of the template being mined on, it is committed to in the PoW — it cannot be rewritten afterwards.

3. One sharechain, two lanes

A separate sharechain per lane would make no sense: lane C would have its own, sparse and therefore vulnerable chain. Hence one sharechain that accepts shares from both lanes.

Careful not to confuse them: this is the design of a decentralized pool with no operator. The centralized pool goes a different way — two separate pools, one per lane, each with its own accounting (its own deployment notes). Nothing is normalized there, because nothing is compared.

A share’s weight is normalized by the same coefficient k_lane that chainwork already uses across the lanes (SPEC §3, the geometric mean):

weight(share) = (2^256 / share_target_lane) × k_lane

Why it fits by itself: k_lane is set so that a block from each lane weighs the same. Each lane produces half the blocks, so the miners of each lane get half the payouts between them — regardless of a GPU having orders of magnitude more hashrate than a CPU. The same guarantee as in consensus, only carried over into the pool.

Parameter Value Note
The share time 15 s 8 shares per network block (120 s), 16 per block of one lane (240 s)
The PPLNS window 2,880 shares ≈ 12 h it smooths the variance even for the small ones
The share target per lane, auto-tuned so that the total across both lanes is 1 share / 15 s
Uncle shares down to a depth of 3, 90 % weight against being punished for slower propagation
The sharechain retarget LWMA, a window of 240 shares a faster reaction than the main chain

4. The payout — and the 256 kB block limit

This is the hard boundary of the whole design. One payout output is 43 B (the value 8 + the length 1 + a 34 B scriptPubKey), and the coinbase’s overhead is 153 B:

outputs the coinbase % of a block left for transactions
256 10.9 kB 4.3 % 245 kB
512 21.6 kB 8.5 % 234 kB
1,024 43.1 kB 16.9 % 213 kB
2,880 121.1 kB 47.3 % 135 kB

Paying out everyone from a 12-hour window (up to 2,880 addresses) would eat half a block. Hence:

The sharechain keeps balances, a block pays out the largest ones.

  1. After a block is found, subsidy − the dev fee + the fees is split by the weights in the window and credited to the miners’ balances in the sharechain’s state.
  2. The coinbase pays out at most 512 addresses — the ones with the highest unpaid balance that has also reached the minimum payout of 0.05 POWM.
  3. Whoever does not fit keeps their balance for the next block. The order is deterministic (the balance, and on a tie the address’s hash), so every node verifies it the same way.

With a reward of 38 POWM per block and a minimum payout of 0.05 POWM the ceiling is ~760 addresses anyway, so the limit of 512 only applies in a very large pool. The 5 % dev fee is a separate output per the consensus rule (SPEC §2.1) and counts towards the limit.

The risk that follows from this: an unpaid balance is a claim, not money. Whoever leaves the pool before reaching the minimum payout loses their balance — the same as with P2Pool’s PPLNS window. Which is why the minimum payout should rather be low.

5. How it gets along with the lane rotation rule

Consensus does not allow three blocks of the same lane in a row (ALGO §4). For a pool that means:

  • A pool node offers templates only for the lanes that are permissible at that moment.
  • The miners of a blocked lane keep mining and their shares count towards the window normally — only no network block can come from them for the time being.
  • The sharechain therefore smooths the rotation rule out: a miner of a blocked lane does not lose income even though they cannot hit a block right now. A solo miner loses that time.

6. Security

Threat The answer
A miner rewrites the coinbase and keeps the block They can — but then their share stops being part of the sharechain and they lose their cut of everybody else’s blocks. The same economic defence as in P2Pool. Consensus does not enforce the payouts and will not — that would mean building one particular pool into the network’s rules.
51 % of the pool’s hashrate rewrites the sharechain The 12 h window makes a rewrite expensive; the uncle rules reduce the profit from reorgs. It is not a complete defence, it is the P2Pool model.
Flooding with invalid shares Verifying a share = one hash (1.7 ms lane C, 0.62 ms G) with the full DAG. Light mode (28 MiB) is two orders of magnitude slower at it (~63 ms), so a pool node holds the full DAG as a requirement. A rate limit per peer and a ban after invalid shares.
The balances as a honeypot The balances are only a record in the sharechain, not funds under an operator’s control. There is nothing to steal.
Leaving the pool An unpaid balance is forfeited — see §4.

7. What follows from this for the node (F4)

This is why the design is being written now:

  1. The coinbase has to take hundreds of outputs — the coinbase size limit must not be lower than ~64 kB.
  2. The dev fee output has to be first and has to be combinable with the payout outputs.
  3. No special consensus rule for a pool. The sharechain is above consensus, not in it.
  4. The node has to be able to issue a template for a specific lane and to say which lanes are permissible right now. (Done: gettemplate {"lane":"C"|"G"}; a blocked lane returns an error, not an empty template.)
  5. The payouts mature along with the coinbase, that is 100 blocks (≈ 3.3 h).

8. Open questions

  1. The 15 s share time is an estimate. It has to be checked against propagation in the network — with slow propagation the proportion of uncle shares grows.
  2. The 12 h window is a compromise between smoothing the variance and how much whoever leaves loses. P2Pool has 6 h.
  3. A separate “mini” sharechain for the smallest miners (as Monero has) — to be handled depending on the pool’s real size.
  4. How a pool node gets the DAG at startup: build it, or take it over from a node on the same machine (shared memory)?
  5. An encrypted or authenticated p2p between the pool’s nodes — P2Pool runs in the open; to be considered.

9. References