 |
April 14, 2026, 04:51:33 PM |
|
The official BTCP telegram no longer works
Nor the discord links
Yet when a friend tracked down Jay Pujanes on Facebook he showed an update from a telegram channel lookin like from this year but i cant imagine where this telegram channel could possibly be.
Jay blocks and bans anyone who questions the status or how long the project is taking he gives the same generic updates over and over
BTCP Project Progress Report: Inflation Detection & Remediation
Date: February, 2026
Subject: Exhaustive Status Report (Inception to Phase 3)
1. Core Rationale
The primary objective of the project was to secure the integrity of the Bitcoin Private (BTCP) supply. Following the hyper-inflation event induced by a bug in the underlying codebase at the time which allowed for illicit coins to be minted, it became clear a clean-up of the UTXO was required. It also became critical to migrate the node code from the legacy Java codebase to a flexible Python environment. This migration allowed for:
● Granular Blockchain Forensics: Enabling byte-level inspection of blocks to confirm or deny the existence of illicitly minted coins.
● Surgical Remediation: Developing the tooling necessary to excise illegitimate funds without harming innocent users (a "surgical burn" vs. a "rollback").
● Modernization: Transitioning to a maintainable codebase for future stability.
2. Significant Obstacles Faced
A. The "Phantom" Inflation (The JoinSplit Anomaly)
● The Issue: Early in the migration, our Python parser incorrectly reported a catastrophic inflation event of ~1.6 Trillion BTCP in Block 570,100.
● The Root Cause: This was a technical "red herring." The parser anticipated the standard Zcash Sprout ciphertext size (1202 bytes). However, BTCP legacy blocks utilized a larger, non-standard padded size (60164 bytes), a quirk inherited from its ZClassic (ZCL) lineage which used this specific padding structure at the time.
● The Impact: This size mismatch caused the parser to "drift" while reading the binary block data. Consequently, it interpreted random encrypted bytes (ciphertext) as 64-bit integer values for `vpub_new` (value unshielded). This resulted in erroneous reports of ~1.6 Trillion BTCP being minted in Block 570,100, masking the true activity.
B. Ledger Corruption & Identity Mismatches
● The Issue: Importing malformed data caused a divergence in Transaction IDs (TXIDs). The hash of the same transaction differed between our local database and historic block and chain state data.
● The Impact: This "Identity Crisis" broke the ability to trace funds. If we could not agree on the ID of a transaction, we could not track where its output went.
● Resolution: We had to implement a "Deep MRI" scanner to re-align our hashing algorithms with the exact byte-structure of the legacy chain.
3. Key Accomplishments
Note on Methodology: It is critical to highlight that we received no historic working documents, source files, or configuration data. All blockchain parameters and legacy settings had to be deduced via rigorous trial-and-error and reverse engineering. This forensic discovery process spanned several months and was a prerequisite for the accomplishments below.
Phase 1: Diagnosis & Detection (Completed)
● "Deep MRI" Tooling: Developed `inspect_block_mri` tool to analyze the raw hex data of the blockchain byte-by-byte. This allowed us to calculate the exact offset, correct the parser to the 1202-byte standard, and successfully validate the block data against known checkpoints.
● Identification of "Patient Zero": Successfully pinpointed the true start of the exploit: ~15,000+ BTCP illicitly unshielded from Block 574,162.
● Mapping the "Main Event": Traced the massive unshielding of ~1.2 Million BTCP during the "No Sunshine" anomaly (Block 679,986+) outlined by a well respected and competent veteran contributor.
● Evidence Compilation: Generated an illicit_activity list, a mathematically verifiable ledger of every single probable illegitimate unshielding event.
Phase 2: Surgical Taint Analysis (In verification stage)
● Entity Clustering: We moved beyond simple lists of addresses. We grouped thousands of seemingly unrelated addresses into unified "Bad Actor" entities based on their transaction behavior (shared inputs).
● The Kill List: Generate a final_burn list. This list targets only the specific addresses holding the proceeds of the exploit and their direct downstream clusters.
we have heard this stuff for years from them
Jay threatened to sue my friend for calling him a fraud on facebook which of course Jay doesnt get what Anti Slapp is and that he cant sue for that especially when he bans everyone and none of the telegram or discord links work nor is sny of the project on github to show progress which would be accurate then or understandable why these things are said
|
