TIDES是一种比特币矿池收益结算系统，能在无需矿池运营方作为托管方持有和缓冲比特币奖励的前提下，把收益波动（方差）降到最低。在实际运行中，TIDES的收益会随时间趋近于最高，且具备可审计性，便于矿工独立验证是否获得了公平的份额。此外，TIDES还可以采用非托管（Non-custodial）的方式来实现。
本文假设读者对比特币挖矿的通用原理至少具备基础了解，并主要介绍 TIDES 这一矿池挖矿奖励系统。虽然TIDES是专为CONVOY比特币矿池设计的，但本文的大部分内容并非针对 CONVOY 或任何其他矿池对 TIDES 的具体实现，而是对该奖励系统本身进行的通用性阐述。
针对特定矿池的细节通常会特别注明，各个矿池也可以根据自身具体需求来调整 TIDES 奖励系统的相关参数。
在比特币挖矿领域，为矿工实现公平、低波动（低方差）且透明的收益分配至关重要。传统的矿池挖矿模式往往难以解决收益波动大、实际分账缺乏透明度以及矿池运营方完全托管所带来的风险等难题。TIDES引入了一种全新的解决方案来应对这些问题。
TIDES最初是专为 CONVOY 比特币矿池设计的，优化了区块奖励的分配过程，确保矿工能够以可证明精准的方式获得其应得的公平份额。本文深入探讨了TIDES的运行机制，剖析了其相比传统系统的优势，以及如何以非托管（Non-custodial）的方式落地实现。
创生交易（Generation Transaction）：区块中的第一笔交易，由矿工创建。该交易包含 CoinBase（有时也被称为“Coinbase 交易”），用于发放区块奖励（新生成的比特币以及交易手续费）。
运气（Luck）：在本文语境下，指找到一个（或一系列）区块预计所需的工作量与实际完成的工作量之比。“运气差（Bad luck）”表示找到区块所需的工作量多于预期；“运气好（Good luck）”则表示所需的工作量少于预期；而“100% 运气”是实际工作量完全等于预期工作量。
全网难度（Network Difficulty）：衡量平均每找到一个区块所需工作量的指标。比特币网络每隔 2016个区块调整一次难度，以维持平均 10 分钟的出块（区块发现）时间。
收益方差（Payout Variance）：由于出块（区块发现）的概率性本质，导致挖矿收益随着时间推移产生的波动。高方差会显著影响矿工收益的稳定性；较低的波动性通常更符合预期。如果不加入矿池，单体比特币挖矿的收益方差通常极高，堪比买彩票。
份额 / 证明（Share / Proof，可互换使用）：一种工作量证明（PoW），用于证明矿工正在对经校验符合矿池预期的数据进行计算。每个份额都有一个目标值（Target），代表矿工为产生该份额平均需要完成的工作量。
份额日志（Share log）：提交至矿池的所有有效证明（Proofs）的记录。
份额日志窗口（Share log window）：份额日志中最新提交的（“顶部”）一批证明，包含相当于最近 8 个区块工作量的数据（8 × 全网难度）。
目标难度（Target difficulty）：一份证明（Proof）必须超越的难度，超越后才能被认定为有效的矿池份额（Pool share）；同时，它也可以指矿工或矿池成功挖出（发现）一个区块所必须超越的难度标准。
聪（Satoshi）：比特币的最小计价单位，等于 0.00000001 BTC。
透明性（Transparent）：TIDES 极为透明，允许矿工自行计算其在区块奖励中的分账比例，从而核实实际收益是否与预期相符。
索引（Index）：每个份额都在当前窗口内被跟踪记录，并按顺序建立索引，序列不会丢失。
独立（Distinct）：每个份额均被单独存储和跟踪，并保留原始顺序。不采用任何会导致收益分辨率降低的“平移”（shifts）或其他聚合/平均化等手段，所有份额始终保持独立清晰。
扩展（Extended）：TIDES 的份额日志容量极其庞大。在当前比特币全网难度下，它可跟踪相当于最近八（8）个区块工作量的数据用于发放当前奖励。这不仅将收益波动（方差）降低到了可接受的水平，同时平衡了新加入矿工接入所需的时间。此外，即便旧份额已不在当前窗口内，也不会被直接丢弃，以便在未来难度提高时重新调回窗口内。
份额/证明（Shares / Proofs）：如前文定义，矿池接收到的每一份已提交的工作量证明都会存储于份额日志中。过去比特币矿池通常将其称为“份额”（share），但“证明”（proof）这一表达更不易产生歧义，因此本文中两者互换使用。
TIDES 负责处理比特币矿池中工作量证明（PoW）提交的追踪与矿工收益的分配，其基本流程可拆解为几个明确的步骤。
TIDES 接收来自矿池软件（即接收远程挖矿硬件连接并组织这些算力工作的实际服务器）的已验证工作量证明。
TIDES 独立于所使用的软件和协议。虽然在撰写本文时，该领域由 Stratum 协议主导，但 TIDES 仅需要工作量证明即可出于矿池收益分配的目的追踪有效份额。这些份额的来源可以是任何具备矿池托管能力且能保证工作有效的软件。
经矿池软件验证有效且接收的证明（Proofs）均会按照接收到的先后顺序添加至份额日志的顶部。每份证明在份额日志中折算的份额数量等于该证明的目标难度，份额日志本质上是矿工为矿池所完成的哈希计算次数的度量。
随着矿工继续工作，份额会按顺序被持续添加至份额日志的顶部。
份额不会从份额日志中被移除，核心要点在于所有份额均保持有序。
当矿池中的任意矿工成功挖出一个区块时，系统会根据该区块对应的全网难度来计算份额日志窗口的尺寸（share_log_window，单位：难度为 1 的份额数）。在此之前，该窗口只能是一个估值，因为我们无法精准预测出块的具体时间和难度（尽管全网难度大约每两周才调整一次）。
份额日志窗口（share_log_window）的大小相当于该区块难度的 8 倍工作量份额。矿池可根据其对收益方差的容忍度，将此值设定为其他值。
在 8 个区块工作量大小的窗口下，可确保所有已提交的份额至少获得一次奖励的概率达到 99.9665%，每个份额将平均被奖励 8 次。
区块总奖励（区块补贴加上交易手续费）作为计算收益分账的基础（current_block_reward，单位：聪）。
每位矿工在日志内的份额都会被统计：从份额日志最顶部的份额开始，沿日志向后倒查，直到累计统计满 share_log_window 数量的份额为止；由此每位矿工在窗口内的份额计数都存在且被储存（miner_shares_in_window[...]，单位：难度为 1 的份额数）。
随后，区块奖励将根据每位矿工在份额日志窗口顶部所占的份额百分比进行按比例切分，奖励金额向下取整至最接近的聪。
以上展示了在未扣除矿池手续费情况下的奖励计算方式。在 TIDES机制下，矿池手续费可以通过多种方式进行计算。通常份额本身会被打上标记（Flag），用以指示在处理奖励时其手续费的计算规则。有关手续费结构的具体实现细节超出了本文的讨论范围（详见“矿池手续费”章节）。
假设所有获得奖励的份额均适用统一的矿池手续费率（pool_fee_percentage），则计算矿池收取的总手续费（pool_fee，单位：聪）公式如下：
虽属于理想化情况，但在计算奖励的实际实现中，矿池手续费将在针对每位矿工计算时向下取整至最接近的“聪”。
注：再次强调，份额绝不会从份额日志中被移除。因此，当单个份额处于份额日志顶部窗口内时，通常预计会获得多次奖励（平均 8 次）。当窗口尺寸按本文档所述设定为全网难度的 8 倍时，平均获奖次数即为 8 次。
技术说明：份额日志窗口的顶部位置取决于该工作任务实际下发给爆块矿工时份额日志所处的最顶部位置，而非区块被实际发现（爆块）的时刻。（此为防止作弊，详见“边缘情况”章节。）
假设在发现某个区块时，有位矿工在份额日志窗口中所占的总工作量比例为 5%。若区块总奖励为 6.25 BTC，则该矿工可分得的奖励为 6.25 BTC × 5% = 0.3125 BTC，非常容易理解。如果另有 1 BTC 的交易手续费可申领，使区块总奖励达到 7.25 BTC，则在本例中该矿工将获得 7.25 BTC × 5% = 0.3625 BTC。
每有新的区块被发现，矿工都会获得其应得的区块奖励分账。所以随着时间推移，总收益会趋向于在 100%运气下的最大可能收益。虽然收益始终会存在一定的方差，但因庞大的窗口尺寸，长期来看平均收益将无限趋近于 100%运气。
这提供给矿工每一个区块奖励的可证明公平（Provably Fair）的分账，并且是最大可能收益。
有关此机制在实际运作中的示例，请参阅“份额生命周期（Life of Shares）”章节。
TIDES 的具体实现决不能降低份额日志中的精度。每一份有效的证明提交都必须被单独追踪，并且须保留其提交顺序和所完成的工作量。与其他往往仅对较短时间窗口内的提交进行统计和聚合的奖励系统不同，TIDES 在无论何时都能精准到单个份额。TIDES 中绝不存在算力“偏移/平移”（shifts）或类似降低贡献分辨率的情况。
然而，这极其消耗资源，尤其是在需要为执行直接出块支付（direct generation payouts）等操作而持续计算奖励时。虽然可以通过优化手段尽可能提高该流程的资源利用效率，但系统仍需针对每位矿工准确追踪海量的数据。
比特币目前的全网难度为 127,479,855,693,691。当窗口设定为全网难度的 8 倍（network_difficulty × 8）时，TIDES 必须对 1,019,838,845,549,529（约 1020 万亿）个份额持续进行奖励计算。
任何所进行的优化都决不能损害矿工在任意给定时间内处于窗口中的工作量精度，也不能打乱矿工提交工作量的顺序。
此外，由于窗口大小会随全网难度的调整而改变，TIDES 实现机制也不能完全丢弃任何份额，即使已不再处于份额日志窗口内。矿池管理员可根据资源情况进行裁定，将最无用的老旧份额日志进行归档，但也不会将其彻底销毁。
矿池需要收取手续费以覆盖开支。矿池手续费旨在单份份额的层面上进行处理。每份份额在被挖出时，都会被打上对应的费率标志（Fee rate flag）。每当有区块被发现且该份额获得奖励时（即该份额处于当时份额日志窗口顶部的范围内），系统将根据该特定费率标志对应的费率，从该份额的奖励总量中扣除矿池手续费。
不同的费率取决于该份额被挖出时矿池所适用的规则。份额一旦被挖出，将永久保留其费率标志，除非矿池的后续政策触发了变更。
根据挖矿方式及矿池的具体规则，矿工在份额日志中拥有的份额可能会对应不同的费率。例如，矿池可能会对使用特定模板或某种特定类型矿机的行为提供费率折扣；或者对使用特定节点或特定软件实现的行为收取额外手续费。这完全取决于矿池的自主设定。
技术说明：当在份额日志窗口内对份额进行汇总统计时，具备不同费率的份额除了包含在按矿工汇总的总计数中外，还会分别归集到各自的“费率桶”（buckets）中。随后，系统会按照相应的百分比，从各个费率桶的汇总算力中扣除对应的手续费，并向下取整至最接近的聪。
随着全网难度的变更，当区块被发现时需要发放奖励的份额日志窗口尺寸也会随之调整。
如果全网难度上升，窗口尺寸将随之扩大。此前已滑出窗口的较旧份额会重新回到窗口内。
如果全网难度下降，窗口尺寸将随之缩小。此前尚处于窗口内的较旧份额将不在窗口之内。
对于在整个当前份额日志窗口期间持续在该矿池挖矿的矿工而言，其单区块收益（reward-per-block）不会产生实质性变化，因为在难度调整时，他们在份额日志窗口中的算力占比并不会发生大幅变动。
这确保了在跨越难度调整周期时，能够实现尽可能最低的方差以及单位工作量上高度一致的收益表现。
需要注意的是， 在区块被发现之前，窗口仅作为一个估算值存在。它只能根据当前难度以及份额日志的顶部位置来进行预估。
TIDES 与区块奖励的具体数值（即区块补贴加上交易手续费，current_block_reward）完全无关。
无论区块奖励数额大小，矿工在区块被发现时均可简单地按比例获得其应得的公平分账。由于份额日志中的份额是基于完成的工作量计数的，而非某种预先计算的比特币数量，因此区块奖励数额的变化不会改变收益分账的百分比。矿工的份额便是其在份额日志顶部所占的算力比例。无论区块奖励的变化是由交易手续费的高低、区块补贴减半还是其他因素所导致，份额日志中记录的工作量永远都是唯一的决定因素。
TIDES 机制并不关心具体的矿机，奖励是按用户而非按矿机进行计算的。用户旗下所有矿机提交的工作量总和，才是用于收益计算的依据。
TIDES 的实现方案及其相关优化可用于生成每台矿机的统计数据，并能按区块生成这些数据以预估每台矿机的收益。然而，单台矿机所占区块奖励部分的预估往往不够精准，误差范围在 ±1 聪以内。庞大的矿机数量可能会引发统计数据偏差。
因此，实际的比特币收益账务核算应当基于用户维度进行，而非基于单台矿机维度。
采用出块直接支付（Payouts from the generation）来实现 TIDES 能够极大提升安全性，确保了矿工的奖励与其贡献直接绑定，无需信任矿池运营方后再进行收益分发。这使得矿池本身对由比特币网络直接发放给矿工的资金拥有极低（甚至完全没有）控制权。矿工可以主动审计其正在挖矿的区块模板，以确保模板正确地分账。
只要条件允许，TIDES 系统的开发都应当优先采用这种将区块奖励直接发给矿工的直付模式。
在两种可能的情况下，当区块被发现时，份额日志中的份额总量可能达不到当前全网难度下 8 个区块的工作量。
这种情况可能发生在：
- 基于 TIDES 机制的矿池首次启动时，提交的工作量还达不到当前全网难度下的 8 个区块工作量。
- 全网难度短时间内出现极大幅度的飙升，而矿池在该全网算力中所占的份额未能跟上这一爆发式增长。
如发生这种情况，TIDES 不会使用“全网难度 × 8”作为切分奖励的分母（share_log_window），而是使用份额日志中的实际总工作量（share_log_total）。奖励将在少于 8 个区块工作量的份额之间进行切分，但每个份额获得的单笔奖励会相应变大——这在实现公平分账的同时，会带来更高的方差。
奖励是与基于矿工在份额日志中个人贡献的区块奖励成正比的。如果在区块被发现时，矿工提交的工作量不足以换取至少 1 聪的收益，该部分收益将会丢失，因为 TIDES 本身没有与单个区块无关的奖励概念。
在实际操作中，对于在矿池中持续运行的任何现代挖矿设备而言均不是问题，即使在矿池达到极高哈希算力的情况下也是如此。
这其实将那些根本无法进行有效挖矿的设备（例如 CPU 矿工）排除在外，因为它们无法贡献足够的工作量来在每个区块中赚取任何奖励。
份额日志的顶部位置始终取决于下发给矿工的特定工作任务生成时份额日志所处的位置。其结果是，在工作任务下发时的日志顶部位置与区块被真正发现时的日志顶部位置之间，存在一定的份额计数延迟（Latency）。
这是故意这样设计的，为防止恶意矿工在出块后故意暂扣中奖份额（Block Winning Share）一段时间，试图在将份额提交给矿池之前往日志顶部刷入更多份额以套取更多奖励。
这不会影响整体收益，该区块的窗口尺寸依然保持不变，所以奖励仍按正常方式计算。窗口在时间维度上只是被稍稍向过去倒退了一点（在实际操作中，根据多种因素的不同，通常最多倒退 40 秒）。
虽然这不会直接影响矿工的收益，但理论上在某些极端情况下可能会引发视觉困惑。例如，如果一个新矿工刚加入矿池，而此时恰好产出了一个区块，那么这位新矿工可能无法从该区块中分得任何奖励。 尽管在区块被发现的瞬间，他们的份额确实已经存在于份额日志的顶部，但在找到该区块的工作任务最初下发给矿工时，他们的份额尚未进入日志顶部——即便这个区块本身就是由该新矿工亲自挖出的。
此处予以说明系为了保证机制阐述的完整性，再次强调，并不会影响整体收益。
由于 TIDES 的工作机制，当任务下发给矿工时，收益可以预先被计算。矿池可以利用该数据直接通过区块的创生交易向矿工支付收益，无需对矿工的收益承担责任。
当向矿工下发任务时，该任务会在内部打上发给矿工时处于份额日志最顶部的份额 ID（Share ID），以及一份创生交易——该交易能够根据当时的日志顶部位置，为正在挖掘的区块向所有矿工适当地支付收益。
这可能会导致区块所奖励的份额日志窗口，相比于区块被真正发现的时刻，处于过去较短的一段时间；但这能确保区块中的奖励金额与该窗口内的实际应得奖励完全匹配，且不会影响整体收益。（详见上文“技术边缘情况”章节。）
每当产出一个区块，系统都会针对份额日志中的份额进行收益奖励。然而，出于各种原因，实际支付并不一定与每次奖励同步发生。通常情况下，微额支付并不划算，因为大量粉尘级别的交易（Dust payments）在后续进行花费或转移时既低效又不具备成本效益。
矿池可能会采用其他替代方法来支付这些较小金额的收益，例如通过累积收益直至总额超过最低门槛（详见下文）、集成闪电网络（Lightning Network）或其他方式。
然而，矿池如何追踪和处理支付，超出了 TIDES 本身的讨论范围——因为 TIDES 属于奖励系统，而非支付系统。TIDES 确实让矿池与矿工双方更轻松地验证公平支付，但其本身并不直接处理支付结算。
TIDES 本身并没有最低支付门槛的概念，TIDES 仅负责将区块奖励拆分计算至“聪”。矿池可以自行实现支付逻辑，例如仅在满足预设条件（如收益累计达到预设的数值门槛）时，才向矿工实际发放收益。
份额的生命周期始于矿工向矿池提交一份有效的工作量证明（PoW）。该份额及其目标难度会立即记录在份额日志的顶部。份额日志的顶部始终包含矿池从任意矿工处接收到的最新份额。
同样需要注意的是，份额的价值与其所代表的实际工作量内在地绑定在一起——份额的目标难度越高，其在日志中的价值就越大，占用的窗口空间也越多。
换个角度来看，份额日志以尽可能精准且务实的方式，追踪矿工完成的有效哈希计算数量；而份额日志窗口则按顺序包含了矿池内所有矿工完成的哈希证明，从而以此确定每位矿工具体的公平奖励。
提交之后，该份额便成为包含最近 8 个区块工作量的份额日志窗口中最顶部的份额。该份额在窗口内至关重要的位置决定了其获取奖励的资格。份额按顺序建立索引，较旧的提交记录位于其下方，较新的提交记录位于其上方。
份额日志可视化示例：其中左上角为最新份额，右下角为最旧份额。矿工在份额日志顶部拥有一份份额。
在上方的示例图示中可以看到“U”已经提交了其第一份份额，该份额现已处于份额日志的顶部。当前份额日志窗口已被高亮显示。
示例矿工在份额日志中位置演进过程
随着“U”提交更多份额，窗口中属于“U”的份额占比将会增加。“U”在份额日志窗口中的百分比最终会稳定在其占矿池整体算力的比例附近，从而确保他们获得的所有奖励分账绝对公平。根据矿池占全网哈希算力的百分比不同，矿工需要经历一段时间才能将份额均匀分布在整个份额日志中。
每当矿池发现新区块时，系统都会根据最新区块的难度重新计算份额日志窗口（示例图示中以红线描边的份额）。在此过程中，窗口内的每一份份额都会被评估其对发现该区块所做出的贡献。总区块奖励会在窗口内的所有份额之间进行按比例分配，每一份份额都会根据其目标难度相对于窗口内所有份额总和的比值，分得相应比例的收益。（为简单起见，此处示例图示中的所有份额目标难度均假设为 1）
仔细观察可以发现，即使份额已不再处于份额日志顶部的窗口之内，所有矿工提交的所有份额顺序仍被完整保留，新份额只会被插入到顶部位置。
示例矿工在份额日志中的新旧份额
TIDES 的一个独特之处在于，份额在获得奖励后并不会从份额日志中被移除。事实上，矿池会永久保留这些份额，绝不会被删除，以确保始终存在一个完整的份额窗口（参见“难度调整”）。只要某个份额依然处于份额日志窗口之内，每当有新区块被发现时，它就始终具备获得奖励的资格。
所以，单个份额可以被多次奖励。平均而言，一份份额预计会被奖励 8 次；但受矿池运气的影响，其实际获奖次数可能会多于或少于 8 次。对于在矿池中持续挖矿的矿工来说，收益方差能够在跨越超过 8 个区块工作量的过程中被平滑消除，最终达到预期收益。
换个角度来看，在一段运气较低的短时间内（即发现区块所需的工作量高于平均水平），一份份额被奖励的次数会少于 8 次；而在一段运气较高的短时间内（即发现区块所需的工作量低于平均水平），一份份额被奖励的次数则会超过 8 次。
然而在较长的时间跨度内，这一平均值会趋向于平均运气。例如，如果一份份额被奖励了 7 次，而另一份份额被奖励了 9 次，其最终结果依然符合预期的工作量奖励水平。
难度上调后的示例矿工图示
如果难度上升，矿工“U”此前较旧的份额将会重新包含在适用于更高难度区块的份额日志窗口之内。然而，“U”在份额日志窗口中的算力百分比保持不变。在上文的示例中，全网难度翻倍，因此份额日志窗口的尺寸也扩大了一倍。
注：示例图示基于伪随机数据生成；由于示例数值（如难度和份额日志窗口尺寸）整体较小，其方差（波动性）高于实际系统中的真实表现。在实际应用中，难度调整时的百分比偏差几乎微乎其微。
虽然难度调整会改变新区块被发现的频率，但它改变的是每个份额的总奖励（任何矿池都一样），或者是 Solo 挖矿时单位时间内的有效总收益。然而，只要矿工挖矿时间足够长、足以让较旧的份额重新回到窗口内，难度调整就不会改变该矿工在份额日志中的百分比。在 TIDES 机制下，其单区块收益最终保持不变。
在现实中，随着矿工的加入与离开、设备的升级与淘汰等，矿池的哈希算力会出现波动。矿工自身的哈希算力也并非 100% 恒定。但 TIDES 的运行机制确保了当矿池发现区块时，你能根据自己的贡献获得公平的分账，并且这些变量会尽可能地趋于平稳。
在上一章节中提到，只要满足以下所有条件，一个份额就会被给予奖励：
- 矿池成功发现了一个区块，并……
- 该份额在当时处于份额日志顶部的窗口之内。
TIDES 的一个核心要点在于：由于矿池不会通过缓冲资金来人为试图消除所有方差，因此矿工只有在矿池成功发现区块时才会产生新的收益。
每当矿池发现一个区块，窗口内的所有份额都会获得奖励。这对于一个新矿工来说会是什么样呢？在我们的示例中，假设矿池拥有平均运气，且每当提交的份额数量恰好达到全网难度（network_difficulty）时就会成功发现一个区块。这能更好地反映长期的平均水平。
新矿工收益图表。以恒定哈希算力进行挖矿。X 轴：加入矿池以来产出的区块数量；Y 轴：收益（无单位）。红色：累计总收益；蓝色：单区块收益。
如图表所示，在 TIDES 机制下，矿工在每个区块开始获得全额奖励之前，会经历一段实际上的“算力爬坡（Ramp up）”周期。上述图表是无单位的，因为在假设平均运气的前提下，它适用于任何恒定算力、恒定难度等场景。在实际操作中，运气和其他因素会对该过程产生影响，但其核心概念保持不变。
该设计的初衷是尽可能消除方差。为了做到这一点，份额日志窗口必须足够大。而正因为窗口很大，你的工作量需要一段时间才能均匀地分布在整个窗口之中。随着矿池总哈希算力相对于全网算力的提升，区块产生的时间间隔会缩短，使得份额日志内达到算力均匀分布所需的实际物理时间也随之减少。
一旦窗口内有了份额，它们就会充当缓冲器，为你自己的收益平滑消除方差。不管你为什么暂时或永久停止挖矿，你在份额日志中依然保有份额，只要这些份额尚未滑出窗口，它们在矿池产出新区块时就仍可获得奖励。
离线后的新矿工收益图表。X 轴：加入矿池以来产出的区块数量；Y 轴：收益（无单位）。红色：累计总收益；蓝色：单区块收益。
在上述示例中，矿工在第 24 个区块后离线，份额仍会在一段时间内（相当于 8 个区块的工作量）保留在窗口之中。与 PPS 类型的矿池相比，这是一个显著优势——因为在设备停机、维护或响应电力限电（Curtailment）期间，你依然可以继续获得部分收益；而一旦重新上线，收益又会逐步恢复至稳定的奖励水平。
Q. 既然 TIDES不需要矿池准备缓冲资金，那它是如何防止投机（如切池套利/Pool Hopping）的？
A. 由于份额永远不会被删除，因此当发现区块时，奖励窗口内始终存在份额。矿工无法通过切池来获取额外优势，因为这只会导致其份额集中在份额日志窗口的某个特定位置，而在其他位置则为空。因此如果实际发生：即使矿工在发现块后切入矿池（正如在普通按比例分配的矿池中爆块时投机者所做的那样），他们也无法获得任何特殊收益，因为上一个“轮次”（TIDES 本身并没有“轮次”的概念）的份额并未被丢弃。相反，假设矿池产出了下一个区块，该矿工也只能根据其贡献的实际哈希算力拿到属于自己的公平分红。
Q. 我听说 TIDES 的收益比 [其他奖励系统] 要低，这是真的吗？
A. 不是真的，TIDES 在数学上是可证明公平的（Provably Fair）。如果你想的话，你可以核对矿池发现的区块、查看矿池的整体哈希算力，并对比你自身设备记录的已提交份额，以此来确认你是否获得了区块奖励中属于你的公平分账。矿池甚至可以通过其 API 开放更详尽的数据，以便在更精准的层面上进行验证。
Q. TIDES 会分享区块中的交易手续费吗？是如何分配的？
A. 会的。矿工不仅能按比例公平分得区块补贴（Block Subsidy），还能分得交易手续费。每当发现一个区块时，包含交易手续费在内的总区块奖励（Full Reward）都会被用于计算并按比例切分给所有矿工。
Q. 我已经挖了[一段时间]了，但还没收到任何比特币！矿池肯定是在作弊，是不是？是不是？！
A. 与 FPPS 等算力租赁性质的结算系统不同，TIDES 只能用实际挖出的比特币来向矿工发放奖励。也就是说，分发的比特币唯一来源于矿池成功发现的区块。此外，矿池通常还会设置一个最低支付门槛；只有在满足以下条件时，你才会收到打款：a) 在你的份额存在于份额日志期间，矿池成功爆块并为你带来了比特币收益；b) 你累计赚取的比特币达到了最低支付门槛。简而言之，这可能需要一点时间，但你终将获得属于你的那份公平奖励。
Q. 系统显示我每个区块分到的收益太少了！我本该拿得比这多得多！为什么会这样？
A. 你每个区块获得的收益取决于多个因素。例如，如果在矿池总哈希算力为 1 Eh/s 时，你每个区块能赚取 1 BTC；那么当矿池总算力暴增至 2 Eh/s 时，你每个区块分到的收益就会降至 0.5 BTC……但矿池爆块的频率会提升一倍。虽然单区块收益会随着矿池的总哈希算力而上下波动，但无论出块频率是快是慢，你在一段时间内累计赚取的比特币数量，终将趋向于对应你个人算力的理论期望值。
Q. 我的 [非 ASIC 矿机或旧型号 ASIC 矿机名称] 算力够快吗，可以用 TIDES 进行挖矿吗？
A. TIDES 不在乎你使用的是哪种类型的矿机，只要你提交的是有效份额，就会被添加到份额日志中。话虽如此，你需要拥有一台（或通过多台汇总的）矿机，能够在你可以接受的时间范围内，达到矿池设定的最低支付门槛。对于 CPU 矿机或骗局性质的“兴趣体验型”矿机（Scammy hobby miners）而言，这在人的有生之年里是根本不可能实现的。即便是某些较旧型号的 ASIC 矿机，可能也需要数月甚至数年的时间才能达到矿池设定的最低支付门槛。
Q. 如果使用 TIDES 的矿池在其区块中挖出了天价交易手续费（就像在其他矿池中发生过几次的那样）会怎样？矿工也能从中分得属于他们的那份收益吗？还是说矿池可以剥夺矿工的奖励，并将其“退还”或私自扣留？
A. TIDES 旨在以非托管（Non-custodial）的方式落地实施，这意味着矿工应当直接通过创生交易获得支付，且在矿池甚至未曾拥有资金管辖权之前，矿工就已经拿到了对该笔天价交易手续费的分账。TIDES 根本不在乎交易手续费是 100 聪还是 100 个比特币，整个区块的总奖励（Full Block Reward）都会按比例切分给所有矿工。
Q. 听起来和 PPLNS 非常像。TIDES 难道就是 PPLNS ？
A. TIDES 是 PPLNS 本应有的终极形态。TIDES 并非迄今为止其他所有“PPLNS”矿池所实现的那种“伪 PPLNS”——在那些矿池中，份额要么按“班次（Shifts）”进行统计而丧失精度（导致收益降低），要么使用的“N”值极低（导致高方差与收益损失）甚至更差。相反，TIDES 能够追踪记录所有的份额，并在每个区块产生时，为最新的 network_difficulty × 8（全网难度 × 8）个份额发放奖励。这意味着你的收益是 100% 公平的、尽可能高的，并且在每个区块上都是完全可验证的。简而言之，TIDES 无法与任何现有或历史上的 PPLNS 矿池进行直接类比。
Q. 我只能断断续续地挖矿，或者一天中只在特定时间段挖矿。我还能使用 TIDES 模式吗？
A. 可以。实际上，由于份额日志独特的运行机制， TIDES 很可能会比其他奖励系统带来更稳定的收益。在一个份额日志窗口的时间跨度内，你最终在日志中所占的份额百分比会对应你的平均哈希算力，并以此为基础赚取奖励。而且，由于你在份额日志中始终保有份额（只要你会重新上线），你就能源源不断地获得奖励。一般情况下，你不会错过离线期间矿池产出的区块分红，也不会因离线而受到任何惩罚。只要你的份额还在窗口之内，它们就绝不会被直接丢弃。虽然相比于持续挖矿的矿工，你的收益方差（波动）会略高一些，但即使你每天只挖一小段时间，也依然能获得相当平稳的收益。
Q. 我想在用 TIDES 的矿池中挖矿，我如何才能使收益最大化？
A. 为了获得最低的方差和最高的潜在收益，你应该将矿机切至该矿池并保持持续挖矿。通过这种方式，你的份额能够始终最大程度地填满份额日志，从而实现收益的最大化并将其方差降至最低。
Q. TIDES 机制本身是去中心化的吗？
A. 很遗憾，出于份额日志运行机制的本质特性，TIDES 本身无法做到去中心化。持续更新奖励计算及其他统计数据所需的巨大计算量与验证工作，根本无法以一种合理的方式在去中心化架构下完成。但是，TIDES 是在数学上可证明公平的（Provably Fair）。如果某个矿池运行了 TIDES 但未能做到 100% 公平，这一情况将会立刻被揭发；而 FPPS 这类支付模式则是完全不透明的，几乎不可能对其进行精准核验。
Q. TIDES 与去中心化挖矿兼容吗？
A. TIDES 对工作量的类型保持中立，只要其最终能达成有效的比特币联合挖矿工作量证明（PoW）即可。该份额既可以来自于传统的中心化系统（由矿池端生成区块模板并进行挖矿，例如 Stratum 协议），也可以来自于去中心化的模板联合挖矿系统。这对 TIDES 来说没有任何区别。
话虽如此，TIDES 的设计允许矿池根据多种因素收取不同的费率。由于 TIDES 中的每一个份额都是独立的，因此每个份额都可以标记属于自己的费率。通过这种方式，矿工可以在同一个用户账户下使用多种包含不同费率的方法进行挖矿，并且依然能获得公平的奖励分账，同时在单份额粒度（Per-share Resolution）上被精准收取与其具体工作量相适应的手续费。这也使得矿池能够非常容易地通过为此类协议下发现的份额提供更低费率，来鼓励去中心化挖矿。
Q. 听起来太复杂了。总结下来是什么意思？
A. 总结来说，你应该选择采用 TIDES 模式的矿池进行挖矿，以确保你始终能公平分得所挖出区块的奖励。没有套路，没有猫腻，且底层专为非托管（Non-custodial）架构设计。唯有纯粹、公平的挖矿。
TIDES 引入了一种立足于公平、透明且简单直接的收益分配机制，彻底革新了比特币矿池的格局。不同于那些经常让矿工无法确知收益是否真正公平的传统模式，TIDES 提供了一条清晰明确的路径，确保每位参与者都能获得其应得的奖励分账。这一举措为比特币挖矿收益系统树立了全新的高标准。