TIDES guide

What it is

Forge Pool's TIDES pays its gateway miners from each block's own coinbase: every DATUM block pays the miners with work in a share log window, in proportion to that work. A gateway is a program that lets your own BCH2 node build each block while your miners' shares go to the pool. A DATUM block is a block found on a job the pool registered. A block a gateway finds while it mines solo is not a DATUM block: it pays that gateway's payout address in full. There is no pool wallet and no pool fee: your payout is an output of the block itself, paid to your address.

TIDES and DATUM were designed by OCEAN. Forge Pool's gateway protocol is its own implementation for Bitcoin Cash II (see Credits).

Who takes part

• Gateway miners. Miners connected to Forge Solo in TIDES mode, or to Forge Gateway, both running with a BCH2 node of their own. Their shares make up the TIDES window, and the DATUM blocks they find pay it.
• Not Forge Pool's own stratum ports. Miners pointed straight at Forge Pool are paid by the pool's PPLNS or solo payouts, as described on the Help page. Their shares are not in the TIDES window, and the blocks they find do not pay it.

How your shares are counted

Your node builds the block template. Each job your miners mine for the window is registered with the pool first, and the pool checks it before taking any share on it. Solo work is not registered, and its shares are not sent. The job must build on the pool's current block, pay exactly the TIDES split of a window snapshot the pool published in the last 10 minutes, claim only the block's subsidy plus the fees of the transactions it includes, and include only transactions the pool's node accepts.

Your gateway sends the pool every share your miners find that meets the job's share difficulty, except one on a block that has since been superseded, which it drops because the pool would refuse it, and one it has not been able to deliver for 10 minutes. The pool credits every share it receives except one that:

• comes from a gateway the pool has blocked, or in a request it cannot verify (a bad signature, or a gateway clock more than 2 minutes off the pool's),
• names a job it does not know or no longer holds,
• is on a block the pool has moved past,
• repeats a share it has already credited,
• is malformed, has a time outside the allowed range, or names an address that is not a BCH2 address, or
• has a hash that falls short of the job's share difficulty.

A share the pool could not take for the moment (it asked the gateway to slow down, or could not record the share) is sent again.

Every credited share counts as its job's share difficulty: not the higher difficulty its hash may happen to reach.

A job's share difficulty

It is the higher of two numbers, up to a maximum of 2⁴⁰:

• The pool's difficulty for your gateway. It starts at 16,384. It doubles when more than 24 credited shares a minute arrive from your gateway, and halves when fewer than 6 do (it aims at 12), at most once every 2 minutes, but never below 1,024. When the committed difficulty below is the higher number, that sets the pace instead.
• The difficulty the job commits to. Forge Solo and Forge Gateway write a share difficulty into the coinbase of each job they register while miners are connected: the power of two at or above twice the highest difficulty your miners work at, but never above the network difficulty. A difficulty a miner sets itself (d= in its password) counts once it has sent a share at it. Without a committed difficulty, a miner working at a high difficulty (a rented ASIC, say) would have each share credited at the pool's much lower difficulty. Because the number is in the coinbase, every share on the job hashes it, and it cannot be changed once a share is found.

This keeps the credit fair on average. The committed difficulty is set above the difficulty of every miner connected when the job is registered, up to the network difficulty, so each miner's shares are counted in full on average; a smaller miner sharing a gateway with a big one has fewer, larger shares credited. A miner that connects, or whose difficulty rises, is covered from the next job, within about 15 seconds. A difficulty a miner sets itself (d= in its password) counts once it has sent a share at it, so that miner is covered from the first job after that share.

The share log window

• The window holds up to 8 × the network difficulty of the most recent credited share work, from all gateways together. The network difficulty is that of the block being mined. The window is not full while the pool holds less credited work than that; the TIDES page shows how full it is.
• It slides. Once it is full, each new share pushes the same amount of the oldest work out. Its size follows the network difficulty, which can change at every block: when the difficulty falls, the oldest work can drop out too. The pool keeps the newest credited work, 1.25 × the window at the highest network difficulty of the last 7 days, so work that drops out this way comes back in if the difficulty rises again to a level seen in that week.
• Finding a block does not reset it, so a share goes on earning from every DATUM block found while it is in the window.
• The oldest share in the window may count only in part: the part that still fits.
• Your share of the window is your work in it divided by all the work in it.

How a block pays

• Every DATUM block, from your gateway or anyone else's, pays the TIDES split in its own coinbase: one output per address, straight to that address.
• The block's value is its subsidy plus the fees of the transactions in it. There is no pool fee.
• Each address is due its share of that value, plus any amount carried for it from earlier blocks.
• Amounts under 546 satoshis (the smallest output Forge Pool pays) get no output. They are carried forward and paid in a later DATUM block in which the address has work in the window and is due at least 546 satoshis. A carried amount is kept while the address is out of the window.
• The paid outputs are scaled so the coinbase pays out exactly the block's value. That moves the payouts, in total, by no more than the amounts this block carries forward plus the earlier carried amounts it pays. Satoshis left over from rounding go to the largest payout.
• A block pays the split from the window snapshot its job was registered with, so it can lag the live window. The pool republishes the window every 30 seconds and at every new block, and Forge Solo and Forge Gateway register a fresh job about every 15 seconds and at every new block. A job can use a snapshot the gateway fetched up to 25 seconds earlier, or up to 7 minutes earlier while the pool's snapshot cannot be fetched. A snapshot's carried amounts are the ones left by the DATUM blocks it builds on, confirmed or not, except for a short time after a reorg (see After a block is found). After a DATUM block is found, a job above it must use a snapshot the pool published since, for a block above it, so a block found on top of it splits from the carried amounts it left.
• While the window is empty, a DATUM block pays the payout address of the gateway that found it, in full. On Forge Gateway that is the gateway's payout address even when the miner that found the block logged in with its own address.
• When the pool accepts a DATUM block's share, it also submits the block to its own node; the gateway submits it to its node either way.

After a block is found

• A block is pending until it has 2 confirmations; then it is confirmed.
• A block that is still pending and not on the chain 6 blocks later is orphaned: it paid nothing, and nothing it carried takes effect.
• The pool checks confirmed and orphaned blocks against the chain every minute until their coinbase can be spent, 100 blocks after them. After that it does not check them again.
• A confirmed block that a reorg drops is orphaned if it is still not on the chain 6 blocks later; any dropped confirmed block above it is orphaned first. What it did to carried amounts is then undone: what it carried forward is taken out, and the carried amounts it paid are carried again. If the chain takes it back before then, nothing changes.
• An orphaned block that the chain takes back is confirmed again, and what it carried takes effect.
• While a dropped confirmed block waits to be orphaned, no block is confirmed, for up to about 6 blocks. Meanwhile a pending block on the chain still counts in the carried amounts of blocks found on top of it, so the wait delays its status, not what blocks pay.
• Until a dropped block is orphaned, the carried amounts still include what it did; until a block the chain took back is confirmed again, they leave it out. A DATUM block found in that time can pay an address a carried amount the chain no longer owes it (under 546 satoshis per address), and a carried amount the chain owes waits for a later block. A carried amount never goes below 0: if a block paid an address a carried amount it no longer had, the amount stops at 0, and if that block later leaves the chain, it gives back only what it took.
• Coinbase outputs can be spent 100 blocks after the block that paid them: the network's coinbase maturity rule, the same for every mined block.

Checking your TIDES

The TIDES page shows the window and how full it is, every miner's share of it, what a DATUM block found now would pay each address (the split of the newest window snapshot at the pool's current block value), carried amounts, and recent DATUM blocks. A miner's hashrate there is an estimate from its credited shares of the last 10 minutes.

Enter your address under Your TIDES for its window share, what a DATUM block found now would pay it (Next block pays), its carried amount and hashrate, and its 20 newest payouts. Paid (confirmed) and Awaiting confirmation add up its payouts in the last 500 DATUM blocks: Paid (confirmed) counts confirmed blocks, and Awaiting confirmation counts pending ones. A confirmed block that a reorg drops leaves Paid (confirmed) when it is orphaned.

How to join

With Forge Solo

Forge Solo, on Umbrel, Windows or Linux, joins the window once TIDES pool is chosen and saved under How blocks pay in its Settings. Its README has the install directions for Umbrel, Windows and Linux, and the app's own TIDES page explains the rest. The Forge Solo tab on the TIDES page has the short version.

• Every miner connected to your install is credited to your payout address, whatever username it uses.
• A block your install finds while it mines solo pays your payout address in full. It mines solo when Forge Pool cannot be reached or will not take a job, and at a new block until the pool has taken its work, if that takes more than 2 seconds.
• 1175 (ESF) merge-mining is off in TIDES mode.

With Forge Gateway

Forge Gateway connects your own BCH2 node and miners to the window without Forge Solo. Its README has the directions for Windows, Linux and a Mac (build it yourself), and says how your miners' usernames are credited; the Forge Gateway tab on the TIDES page has the short version.

• A miner whose username is its BCH2 address with the bitcoincashii: prefix, optionally followed by .workername, is credited to that address; one logged in with a worker name, to the gateway's payout address.
• A block the gateway finds while it mines solo pays its payout address in full. With Pool only set, it turns miners away instead of mining solo.

The numbers

Credits

DATUM and TIDES were designed and built by OCEAN: ocean.xyz/docs/datum, ocean.xyz/docs/tides. Forge Pool, Forge Solo and Forge Gateway follow their design: your node builds the block, and the coinbase pays the pool's miners directly. They are an independent implementation for Bitcoin Cash II and do not speak OCEAN's DATUM Protocol. Forge Pool is not affiliated with or endorsed by OCEAN.