Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal
3 messages, 27 to 28 Aug 2026. Started by Jack Liao.
Jack Liao (2), Saint Wenhao
Hi all,
I am sharing a draft BIP for feedback before submitting it to the bips repository. It is classified as Informational: it documents a consensus-design pattern and its security analysis. It does NOT recommend activating a hard fork on the Bitcoin main chain.
WHAT THE PROPOSAL IS
Time-Shifted Proof of Work (TSPOW) separates the three roles Bitcoin binds into a single event — finding a hash below target, earning the block reward, and authoring the block — into two stages:
1) Stage 1 (warrant issuance): miners produce a valid initial-hash warrant H_n (H(header, nonce) < D1), which carries the right to the new-coin reward. Rewards are deferred and warrants expire.
2) Stage 2 (selection): once k warrants accumulate (an adaptive Gamma batch), the protocol elects a block producer from the candidate pool via argmin H(h, R, PrevBlockHash), where R is an external-beacon output (with the previous block hash as the chain-derived fallback seed).
Two claimed properties, both backed by the whitepaper and by cross-checked simulation (Rust / C++ / Python; see the repository):
- Block-time stability: the block interval becomes a Gamma(k, lambda) sum instead of a single exponential arrival, dividing block-time variance by 1/k. - Withholding economics: warrant expiry plus deferred reward make privately mining / withholding a warrant strictly suboptimal (expected payoff strictly decreasing in delay).
WHAT THE PROPOSAL HONESTLY DOES NOT CHANGE
- A >50% adversary still dominates warrant generation and thus pool composition; 51%-attack security is unchanged natively. - Without the external beacon, the long-run double-spend probability remains (q/p)^z, identical to traditional PoW.
KNOWN COSTS / RISKS (TO BE TRANSPARENT)
- External beacon = a new trust assumption. The election only fully eliminates private mining when an honest beacon is present; a compromised or censored beacon degenerates to the weaker chain-derived seed. - Hard fork. Adopting TSPOW changes the block header, replaces direct block authorship with pool-based selection, and reallocates rewards. This is by construction a severe backward-incompatible change — another reason this is an informational document, not an activation proposal. - Pool-flooding within a window is mitigated (chained FIFO, per-owner caps) but not eliminated; residual risk should be stress-tested.
MATERIALS
- BIP draft: bip-corepool-timeshiftpow (source in the repository below) - Reference implementations, verification scripts, and numerical checks: https://github.com/corepool/timeshiftpow - Whitepapers (CN + EN) and formal security analysis in the same repository.
I would welcome scrutiny of the Gamma block-time argument, the withholding-economics model, and the beacon trust model in particular, both on this list and in the BIP's security-considerations section.
Comments-Summary: No comments yet.
Thanks, corepool
Quoted text (1 line)
> Hard fork.
I guess it could be turned into a no-fork, if you would just create a mining pool, working with your rules.
Quoted text (1 line)
> changes the block header
If it is compatible, then it doesn't matter. For example: locally, each node could extract the difficulty out of the block header, and have a chain of difficulty periods, stored separately, and copy-pasted into the actual header, when needed. Then, every two weeks, instead of having "80 * 2016 bytes", it could be "4 + (76 * 2016) bytes", when it comes to the way it is stored locally. Will it change the header? Sure. Will it be backward-compatible? Of course.
Quoted text (1 line)
> replaces direct block authorship with pool-based selection
Existing mining pools already did de-facto that. Miners are paid per shares, there are not that many solo miners anymore.
Quoted text (1 line)
> and reallocates rewards
Again, in practice, miners create blocks, sending coins to the pool operator, and later, they are splitted, based on sent shares.
czw., 27 sie 2026 o 17:37 Jack Liao <xiangliao@gmail•com> napisał(a):
Quoted text (91 lines)
> Hi all, > > I am sharing a draft BIP for feedback before submitting it to the bips > repository. It is classified as Informational: it documents a > consensus-design > pattern and its security analysis. It does NOT recommend activating a hard > fork > on the Bitcoin main chain. > > WHAT THE PROPOSAL IS > > Time-Shifted Proof of Work (TSPOW) separates the three roles Bitcoin binds > into > a single event — finding a hash below target, earning the block reward, and > authoring the block — into two stages: > > 1) Stage 1 (warrant issuance): miners produce a valid initial-hash warrant > H_n > (H(header, nonce) < D1), which carries the right to the new-coin reward. > Rewards are deferred and warrants expire. > > 2) Stage 2 (selection): once k warrants accumulate (an adaptive Gamma > batch), > the protocol elects a block producer from the candidate pool via > argmin H(h, R, PrevBlockHash), where R is an external-beacon output > (with the > previous block hash as the chain-derived fallback seed). > > Two claimed properties, both backed by the whitepaper and by cross-checked > simulation (Rust / C++ / Python; see the repository): > > - Block-time stability: the block interval becomes a Gamma(k, lambda) sum > instead of a single exponential arrival, dividing block-time variance by > 1/k. > - Withholding economics: warrant expiry plus deferred reward make privately > mining / withholding a warrant strictly suboptimal (expected payoff > strictly > decreasing in delay). > > WHAT THE PROPOSAL HONESTLY DOES NOT CHANGE > > - A >50% adversary still dominates warrant generation and thus pool > composition; 51%-attack security is unchanged natively. > - Without the external beacon, the long-run double-spend probability > remains > (q/p)^z, identical to traditional PoW. > > KNOWN COSTS / RISKS (TO BE TRANSPARENT) > > - External beacon = a new trust assumption. The election only fully > eliminates > private mining when an honest beacon is present; a compromised or > censored > beacon degenerates to the weaker chain-derived seed. > - Hard fork. Adopting TSPOW changes the block header, replaces direct block > authorship with pool-based selection, and reallocates rewards. This is by > construction a severe backward-incompatible change — another reason this > is an > informational document, not an activation proposal. > - Pool-flooding within a window is mitigated (chained FIFO, per-owner > caps) but > not eliminated; residual risk should be stress-tested. > > MATERIALS > > - BIP draft: bip-corepool-timeshiftpow (source in the repository below) > - Reference implementations, verification scripts, and numerical checks: > https://github.com/corepool/timeshiftpow > - Whitepapers (CN + EN) and formal security analysis in the same > repository. > > I would welcome scrutiny of the Gamma block-time argument, the > withholding-economics model, and the beacon trust model in particular, > both on > this list and in the BIP's security-considerations section. > > Comments-Summary: No comments yet. > > Thanks, > corepool > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups•com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/4bbb1017-8080-4916-8f85-082d2ebf5eacn%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/4bbb1017-8080-4916-8f85-082d2ebf5eacn%40googlegroups.com?utm_medium=email&utm_source=footer> > . >
Subject: Re: [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work Subject: Re: [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal
Hi,
I appreciate the review and the decision on the bips repository. Rather than re-litigating scope, I want to put the technical case on record, because I believe TSPOW addresses flaws in the existing single-stage PoW model that have been known for years but never fixed by a design that stays on one chain. There are three structural improvements worth a serious look.
1. BLOCK-TIME STABILITY — fixing the variance.
Bitcoin binds "find a hash below target" and "author the block" into a single event. The block interval is a single exponential arrival: mean = 1/lambda, variance = 1/lambda^2, i.e. a unit coefficient of variation. Real PoW chains inherit exactly that variance — blocks arrive in bursts and on occasion with long gaps, which is the source of wide confirmation-latency variance and of the persistent "lucky vs unlucky" mining outcomes.
TSPOW separates warrant issuance from block authorship and lets block production wait for k *accumulated* warrants. The block interval then follows a Gamma(k, lambda) distribution whose variance is divided by k (Section 3.1 of the whitepaper; cross-checked in Rust, C++, and Python simulations in the repo). With k = sqrt(S), even a modest pool gives a variance reduction of an order of magnitude or more. This is an improvement to the chain's own scheduling behaviour — no second chain, no peg, no bridge.
2. REMOVING THE SELFISH-MINING SURFACE.
In single-stage PoW a valid proof can be withheld and revealed later to force a reorganization. Selfish mining uses exactly this: an adversary with < 50% hash power can amplify its share of produced blocks by withholding, lowering the effective security threshold of the network. This is a known, measured weakness of the current model.
TSPOW makes withholding economically self-defeating: warrants expire (L) and rewards are deferred, so holding a proof past its validity window yields nothing. And because the elected producer is chosen by argmin H(h, R, PrevBlockHash) over an immutable chained pool, a withheld proof can no longer be inserted to rewrite the pool state. The design removes the amplification vector rather than patching around it.
3. DECENTRALIZING WHO PRODUCES BLOCKS.
In single-stage PoW, the fastest hash wins, which structurally rewards the largest pools and concentrates eventual authorship in a few entities. TSPOW decouples "who did the work" from "who writes the block":
- warrants (who earned the subsidy) are created by proof of work;
- authorship (who writes the block and earns fees) is elected by argmin over
the mature pool, seeded by an external randomness beacon R with the previous
block hash as the chain-derived fallback.
The producer-staking, challenge-window, and deferred-fee mechanics are aimed directly at incentive collusion among block producers, reducing the centralizing pull of the largest mining entities without creating a separate network.
WHY I FILE THIS AS INFORMATIONAL
The Informational label reflects a maturity posture — this is a research proposal with a formalized spec and security analysis, not a recommendation to activate on Bitcoin today. I understand the bips repository's scope policy is targeted at adoption proposals, and I accept that as a policy decision. The technical point I want on the public record is simply that TSPOW is an in-chain, consensus-authoring modification with three concrete improvements over the existing PoW model: Gamma-scheduled, low-variance block times; elimination of the withholding / selfish-mining amplification; and a more decentralizing separation of work from authorship.
Full spec, whitepaper, security analysis, and cross-checked simulations: https://github.com/corepool/timeshiftpow
Thanks for reading.
On Fri, Aug 28, 2026 at 5:51 PM Saint Wenhao <saintwenhao@gmail•com> wrote:
Quoted text (89 lines)
> > > Hard fork. > > I guess it could be turned into a no-fork, if you would just create a mining pool, working with your rules. > > > changes the block header > > If it is compatible, then it doesn't matter. For example: locally, each node could extract the difficulty out of the block header, and have a chain of difficulty periods, stored separately, and copy-pasted into the actual header, when needed. Then, every two weeks, instead of having "80 * 2016 bytes", it could be "4 + (76 * 2016) bytes", when it comes to the way it is stored locally. Will it change the header? Sure. Will it be backward-compatible? Of course. > > > replaces direct block authorship with pool-based selection > > Existing mining pools already did de-facto that. Miners are paid per shares, there are not that many solo miners anymore. > > > and reallocates rewards > > Again, in practice, miners create blocks, sending coins to the pool operator, and later, they are splitted, based on sent shares. > > czw., 27 sie 2026 o 17:37 Jack Liao <xiangliao@gmail•com> napisał(a): >> >> Hi all, >> >> I am sharing a draft BIP for feedback before submitting it to the bips >> repository. It is classified as Informational: it documents a consensus-design >> pattern and its security analysis. It does NOT recommend activating a hard fork >> on the Bitcoin main chain. >> >> WHAT THE PROPOSAL IS >> >> Time-Shifted Proof of Work (TSPOW) separates the three roles Bitcoin binds into >> a single event — finding a hash below target, earning the block reward, and >> authoring the block — into two stages: >> >> 1) Stage 1 (warrant issuance): miners produce a valid initial-hash warrant H_n >> (H(header, nonce) < D1), which carries the right to the new-coin reward. >> Rewards are deferred and warrants expire. >> >> 2) Stage 2 (selection): once k warrants accumulate (an adaptive Gamma batch), >> the protocol elects a block producer from the candidate pool via >> argmin H(h, R, PrevBlockHash), where R is an external-beacon output (with the >> previous block hash as the chain-derived fallback seed). >> >> Two claimed properties, both backed by the whitepaper and by cross-checked >> simulation (Rust / C++ / Python; see the repository): >> >> - Block-time stability: the block interval becomes a Gamma(k, lambda) sum >> instead of a single exponential arrival, dividing block-time variance by 1/k. >> - Withholding economics: warrant expiry plus deferred reward make privately >> mining / withholding a warrant strictly suboptimal (expected payoff strictly >> decreasing in delay). >> >> WHAT THE PROPOSAL HONESTLY DOES NOT CHANGE >> >> - A >50% adversary still dominates warrant generation and thus pool >> composition; 51%-attack security is unchanged natively. >> - Without the external beacon, the long-run double-spend probability remains >> (q/p)^z, identical to traditional PoW. >> >> KNOWN COSTS / RISKS (TO BE TRANSPARENT) >> >> - External beacon = a new trust assumption. The election only fully eliminates >> private mining when an honest beacon is present; a compromised or censored >> beacon degenerates to the weaker chain-derived seed. >> - Hard fork. Adopting TSPOW changes the block header, replaces direct block >> authorship with pool-based selection, and reallocates rewards. This is by >> construction a severe backward-incompatible change — another reason this is an >> informational document, not an activation proposal. >> - Pool-flooding within a window is mitigated (chained FIFO, per-owner caps) but >> not eliminated; residual risk should be stress-tested. >> >> MATERIALS >> >> - BIP draft: bip-corepool-timeshiftpow (source in the repository below) >> - Reference implementations, verification scripts, and numerical checks: >> https://github.com/corepool/timeshiftpow >> - Whitepapers (CN + EN) and formal security analysis in the same repository. >> >> I would welcome scrutiny of the Gamma block-time argument, the >> withholding-economics model, and the beacon trust model in particular, both on >> this list and in the BIP's security-considerations section. >> >> Comments-Summary: No comments yet. >> >> Thanks, >> corepool >> >> -- >> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4bbb1017-8080-4916-8f85-082d2ebf5eacn%40googlegroups.com.