Hi all,<br /><br />I am sharing a draft BIP for feedback before submitting it to the bips<br />repository. It is classified as Informational: it documents a consensus-design<br />pattern and its security analysis. It does NOT recommend activating a hard fork<br />on the Bitcoin main chain.<br /><br />WHAT THE PROPOSAL IS<br /><br />Time-Shifted Proof of Work (TSPOW) separates the three roles Bitcoin binds into<br />a single event — finding a hash below target, earning the block reward, and<br />authoring the block — into two stages:<br /><br />1) Stage 1 (warrant issuance): miners produce a valid initial-hash warrant H_n<br />   (H(header, nonce) &lt; D1), which carries the right to the new-coin reward.<br />   Rewards are deferred and warrants expire.<br /><br />2) Stage 2 (selection): once k warrants accumulate (an adaptive Gamma batch),<br />   the protocol elects a block producer from the candidate pool via<br />   argmin H(h, R, PrevBlockHash), where R is an external-beacon output (with the<br />   previous block hash as the chain-derived fallback seed).<br /><br />Two claimed properties, both backed by the whitepaper and by cross-checked<br />simulation (Rust / C++ / Python; see the repository):<br /><br />- Block-time stability: the block interval becomes a Gamma(k, lambda) sum<br />  instead of a single exponential arrival, dividing block-time variance by 1/k.<br />- Withholding economics: warrant expiry plus deferred reward make privately<br />  mining / withholding a warrant strictly suboptimal (expected payoff strictly<br />  decreasing in delay).<br /><br />WHAT THE PROPOSAL HONESTLY DOES NOT CHANGE<br /><br />- A &gt;50% adversary still dominates warrant generation and thus pool<br />  composition; 51%-attack security is unchanged natively.<br />- Without the external beacon, the long-run double-spend probability remains<br />  (q/p)^z, identical to traditional PoW.<br /><br />KNOWN COSTS / RISKS (TO BE TRANSPARENT)<br /><br />- External beacon = a new trust assumption. The election only fully eliminates<br />  private mining when an honest beacon is present; a compromised or censored<br />  beacon degenerates to the weaker chain-derived seed.<br />- Hard fork. Adopting TSPOW changes the block header, replaces direct block<br />  authorship with pool-based selection, and reallocates rewards. This is by<br />  construction a severe backward-incompatible change — another reason this is an<br />  informational document, not an activation proposal.<br />- Pool-flooding within a window is mitigated (chained FIFO, per-owner caps) but<br />  not eliminated; residual risk should be stress-tested.<br /><br />MATERIALS<br /><br />- BIP draft: bip-corepool-timeshiftpow (source in the repository below)<br />- Reference implementations, verification scripts, and numerical checks:<br />  https://github.com/corepool/timeshiftpow<br />- Whitepapers (CN + EN) and formal security analysis in the same repository.<br /><br />I would welcome scrutiny of the Gamma block-time argument, the<br />withholding-economics model, and the beacon trust model in particular, both on<br />this list and in the BIP's security-considerations section.<br /><br />Comments-Summary: No comments yet.<br /><br />Thanks,<br />corepool

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/4bbb1017-8080-4916-8f85-082d2ebf5eacn%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/4bbb1017-8080-4916-8f85-082d2ebf5eacn%40googlegroups.com</a>.<br />