* [bitcoindev] [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal
@ 2026-08-27 11:43 Jack Liao
2026-08-28 9:51 ` Saint Wenhao
0 siblings, 1 reply; 3+ messages in thread
From: Jack Liao @ 2026-08-27 11:43 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3415 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 3932 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal
2026-08-27 11:43 [bitcoindev] [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal Jack Liao
@ 2026-08-28 9:51 ` Saint Wenhao
2026-08-28 21:16 ` Jack Liao
0 siblings, 1 reply; 3+ messages in thread
From: Saint Wenhao @ 2026-08-28 9:51 UTC (permalink / raw)
To: Jack Liao; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5172 bytes --]
> 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
> <https://groups.google.com/d/msgid/bitcoindev/4bbb1017-8080-4916-8f85-082d2ebf5eacn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CACgYNOKLNCP4_CkWUU5H0cDCcwqbKY%2B%2BKxP33gjKJKOd861BFQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5989 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal
2026-08-28 9:51 ` Saint Wenhao
@ 2026-08-28 21:16 ` Jack Liao
0 siblings, 0 replies; 3+ messages in thread
From: Jack Liao @ 2026-08-28 21:16 UTC (permalink / raw)
To: Saint Wenhao; +Cc: Bitcoin Development Mailing List
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:
>
> > 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.
--
BR.
Jack.
--
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/CAB8jPP4Pw%2BvuDvi4ruznvOQGUMMTq9gdm7EdJn4Ms-ZGUGQArw%40mail.gmail.com.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-08-28 21:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-27 11:43 [bitcoindev] [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal Jack Liao
2026-08-28 9:51 ` Saint Wenhao
2026-08-28 21:16 ` Jack Liao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox