From: Saint Wenhao <saintwenhao@gmail.com>
To: Jack Liao <xiangliao@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [bitcoin-dev] Draft BIP for discussion: Time-Shifted Proof of Work (TSPOW) — an informational consensus-design proposal
Date: Fri, 28 Aug 2026 11:51:04 +0200 [thread overview]
Message-ID: <CACgYNOKLNCP4_CkWUU5H0cDCcwqbKY++KxP33gjKJKOd861BFQ@mail.gmail.com> (raw)
In-Reply-To: <4bbb1017-8080-4916-8f85-082d2ebf5eacn@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2026-08-28 9:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2026-08-28 21:16 ` Jack Liao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACgYNOKLNCP4_CkWUU5H0cDCcwqbKY++KxP33gjKJKOd861BFQ@mail.gmail.com \
--to=saintwenhao@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=xiangliao@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox