Karpelès’ Mt. Gox Bitcoin Fork Proposal Remains Closed, Coins Unmoved

Mark Karpelès’ attempt to create a special Bitcoin consensus rule for stolen Mt. Gox funds remains closed and inactive. The record for Bitcoin Core pull request #34695 shows that he proposed the change on February 27, 2026, targeted 79,956 BTC, set activation to INT_MAX and saw the submission closed and locked as spam that same day. No corresponding rule entered Bitcoin Core or became active on the network.

The coins targeted by the proposal have not been recovered through a fork. A current ledger view of the 1Feex address displays a confirmed balance of 79,957.26863850 BTC and no spent outputs; the slight difference from the proposal’s figure reflects small deposits received by the address over time. The relevant update is therefore unchanged in substance: the proposed exception never activated, and the historically significant holding remains unspent.

What the proposed hard fork would have changed

Karpelès, the former chief executive of Mt. Gox and the GitHub user MagicalTux, proposed replacing the normal signature check for outputs locked to one specified address. A valid signature from a designated recovery key would have been accepted in place of authorization from the private key associated with the existing output.

That distinction makes the proposal a hard fork, not an ordinary wallet-recovery technique. Software enforcing the existing rules would regard such a recovery transaction as invalid, while software adopting the exception could accept it after activation. Agreement on that change would have required coordination well beyond publishing a patch.

The code was intentionally inactive when submitted. Its activation setting functioned as a placeholder, leaving advocates to choose a real block height and secure adoption among participants that validate or economically recognize Bitcoin. Closing the pull request meant that this particular submission had no path into Bitcoin Core; it did not itself constitute a binding vote by every node operator, miner, exchange, custodian or holder.

Why the repository closure is not a network ballot

The proposal met an immediate procedural rejection. An automated repository account closed it under contribution-quality heuristics, the Bitcoin organization restricted the discussion as spam, and a Bitcoin Core contributor directed serious debate over consensus changes to the Bitcoin development mailing list.

Those actions establish what happened inside the Bitcoin Core repository, but Bitcoin has no central electorate capable of recording an authoritative community-wide vote. It is therefore more precise to say that the submitted patch was swiftly closed and gained no implementation route than to claim that the entire Bitcoin community formally voted against it.

The distinction does not improve the proposal’s practical prospects. Karpelès or another group could publish independent software or prepare a separate specification, but users would still have to choose that rule set. Without broad adoption, an attempted activation could leave old and new software disagreeing over which transactions and blocks are valid.

The dispute was about precedent, not patch size

The code targeted a narrow set of outputs, yet the policy consequence would have reached far beyond one address. Bitcoin normally determines spendability from the conditions attached to an output and the consensus rules applied by validating software. The proposal would instead have changed those conditions retrospectively because of the funds’ alleged history and proposed legal destination.

The argument for an exception rests on unusual circumstances: a publicly tracked dormant holding, an identified class of creditors and an established Japanese rehabilitation proceeding. The inactive setting also meant the patch could not redirect anything without a further decision on activation and substantial ecosystem coordination.

The opposing case concerns what would follow from accepting that reasoning. Other victims, courts or governments could seek comparable changes for stolen assets, judgments or sanctions. Participants would then face pressure to evaluate legal ownership claims and historical evidence that the original Bitcoin scripts do not express.

A chain split would also be a concrete technical risk if economically relevant participants enforced different rules. The shortness of a code change does not reduce the difficulty of aligning node operators, infrastructure providers and markets around a transaction that one rule set accepts and another rejects. The central obstacle was therefore legitimacy and coordination, not whether the patch could be written compactly.

Creditor repayments remain a separate process

The disputed address should not be confused with bitcoin and other assets already controlled by the Mt. Gox rehabilitation estate. The trustee can distribute estate assets through the Japanese proceeding, but that authority does not supply the private key needed to spend an unrelated on-chain output under Bitcoin’s existing rules.

The rehabilitation process remains unfinished. The official Mt. Gox rehabilitation notice sets October 31, 2026, Japan time, as the revised deadline for base, early lump-sum and intermediate repayments, replacing the previous October 31, 2025 deadline. That administrative extension neither activates Karpelès’ proposal nor places the disputed coins under the trustee’s control.

This separation is the most useful current clarification for creditors and observers. An active court-supervised repayment process continues for eligible claims and recoverable estate assets, while the proposed protocol intervention remains outside Bitcoin’s adopted rules. Progress on one track does not imply progress on the other.

Where the proposal stands

The observable outcome is straightforward: the pull request remains closed, its recovery rule never activated, and the targeted holding remains unspent. There is no evidence that the proposal is awaiting deployment or has been accepted into Bitcoin Core.

The episode nevertheless illustrates a boundary in Bitcoin governance. Anyone can publish code seeking a consensus exception, and repository maintainers can decline to merge it, but neither side can unilaterally determine the rules recognized by the wider network. In this case, no coalition emerged to carry the proposed exception beyond a closed code submission.

Also read:

• MicroStrategy’s Bitcoin Death March Accelerates: 1,550 More Coins Bought, $1 Billion Cash Cushion Built for the Coming Bloodbath
• $375 Billion Underfunded: Atomico Shows Why Europe’s VC Remains Fragmented and Government-Heavy
• Bithumb's $44 Billion Bitcoin Blunder: A Massive Internal Error That Shook Crypto Markets