MagicalTux commented at 7:29 pm on February 27, 2026: none

Consensus: Allow recovery of MtGox stolen funds (79,956 BTC)

Summary

This proposal adds a consensus rule that allows spending the unspent outputs locked to address 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF using a signature from the MtGox recovery address 1zUrwsmiJxs19c8SJ8FyGZRXD1zUW77Wj, so that the funds can be returned to MtGox creditors through the existing court-supervised rehabilitation process.

The rule activates at a configurable block height (currently set to INT_MAX, i.e. inactive) and requires community consensus on an activation date before it has any effect.

Transaction: e67a0550848b7932d7796aeea16ab0e48a5cfe81c4e8cca2c5b03e0416850114

Background

In June 2011, a compromise of MtGox’s systems led to approximately 79,956 BTC being moved to address 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF. The private key for this address is controlled by the attacker, not by MtGox or its creditors.

These coins have not moved in over 15 years. They are among the most well-known and publicly tracked UTXOs in Bitcoin’s history.

MtGox filed for bankruptcy in 2014, later converted to civil rehabilitation under Japanese courts. Trustee Nobuaki Kobayashi has been overseeing distributions to creditors from funds that were recoverable. However, the 79,956 BTC at this address remain permanently out of reach through conventional means — nobody involved in the rehabilitation has the private key, and the attacker has shown no indication of moving or returning the funds in 15 years.

A court-supervised distribution process already exists and is actively paying creditors. If these coins were recoverable, the legal and logistical framework to distribute them to their rightful owners is already in place.

Why this proposal exists

This proposal is not an attempt to bypass the normal Bitcoin development process. It is an attempt to start a discussion about whether the Bitcoin community considers this specific, exceptional case worth addressing.

The MtGox trustee has declined to pursue on-chain recovery, citing the uncertainty of whether such a consensus change would ever be adopted. This creates a deadlock: the trustee won’t act without certainty, and the community can’t evaluate the idea without a concrete proposal. This patch breaks that deadlock by providing something concrete to discuss.

What makes this case unique

This is not a generic “undo a transaction” or “freeze someone’s coins” request. Several factors make the MtGox theft fundamentally different from other loss scenarios:

Unambiguous theft. The movement of these coins was the result of a documented system compromise, confirmed by law enforcement investigations in multiple jurisdictions. There is no dispute about whether these coins were stolen.
15 years of inactivity. The coins have not moved since 2011. If the attacker intended to spend them, they have had ample opportunity. The prolonged dormancy suggests the keys may be lost entirely, meaning these coins are effectively burned — contributing nothing to Bitcoin’s economy while representing a significant loss to creditors.
Existing legal framework. A Japanese court-supervised rehabilitation process is actively distributing recovered MtGox funds to verified creditors. The legal infrastructure to handle these coins already exists and has been operating for years. This is not a case where recovered funds would have no clear destination.
Known and finite scope. This targets a single, specific address with a well-documented history. The proposal is narrowly scoped to this one case and cannot be extended to other addresses without a separate consensus change.
UTXO set cleanup. The address has accumulated thousands of dust outputs over the years from people sending small amounts to it. Recovery would allow cleaning these up, providing a minor but real benefit to every node operator.

Technical design

The implementation is minimal and narrowly scoped:

A new script verification flag SCRIPT_VERIFY_MTGOX_RECOVERY is added.
In VerifyScript(), when this flag is active and the scriptPubKey being evaluated is a P2PKH script paying to the theft address’s pubkey hash (a0b0d60e5991578ed37cbda2b17d8b2ce23ab295), the evaluator substitutes the recovery address’s pubkey hash (0adef795ddccb55150bedcf0af6c222fa821ccd2) before script execution.
The flag is activated at a configurable block height (MtGoxRecoveryHeight in consensus params), currently set to INT_MAX (inactive).
No other consensus rules are changed. The substitution only affects this exact scriptPubKey pattern.

This is a hard fork: it makes a previously invalid transaction valid. All nodes on the network would need to upgrade before the activation height.

Arguments in favor

Justice for creditors. Tens of thousands of people lost money in the MtGox collapse. A significant portion of those losses stem directly from this theft. The legal process to return funds exists but cannot reach these coins without protocol-level action.
Minimal technical risk. The change is small (under 50 lines of logic), narrowly scoped to one address, and gated behind an activation height. It does not alter any general-purpose consensus rule or script opcode behavior.
Precedent is already limited. Bitcoin has made exceptional consensus changes before. The value overflow bug fix (2010) and the BIP-50 chain fork resolution (2013) both involved the community coordinating to override normal protocol behavior in response to exceptional circumstances. This proposal is more conservative than either, affecting only a single well-defined UTXO set.
Coins are likely dead anyway. If the attacker’s keys are lost, these coins are permanently removed from circulation. Recovery would return them to productive economic use through legitimate owners.
UTXO hygiene. The address has become a magnet for dust. Allowing it to be swept cleans up the UTXO set.

Arguments against

Immutability precedent. Bitcoin’s core value proposition includes the guarantee that consensus rules will not be changed to redirect specific UTXOs. Even a well-justified exception could erode confidence in that guarantee. If it can be done once, the argument goes, it can be done again.
Subjectivity of “deserving” cases. Who decides which thefts merit protocol intervention? Other large thefts (Bitfinex, various DeFi exploits) might seek similar treatment. Drawing the line is inherently political.
Hard fork coordination cost. A hard fork requires every node on the network to upgrade. The coordination cost and chain-split risk are significant, especially for a change that benefits a specific group of creditors rather than the network as a whole.
Attacker may still hold keys. If the attacker is still alive and in possession of the keys, this change could provoke them to move the coins before activation, or create a race condition. (Counter-argument: if the attacker moves the coins, they become traceable through chain analysis and law enforcement can act.)
Legal complexity. The intersection of protocol-level changes with an active legal proceeding in a specific jurisdiction creates novel legal questions. Different jurisdictions may view the legitimacy of such a change differently.
Moral hazard. If the protocol can bail out victims of theft, it may reduce incentives for proper security practices, or create expectations that future thefts will be similarly remedied.

What this proposal is NOT

Not a template. This is not intended to establish a general mechanism for recovering stolen funds. It is a one-time, hardcoded exception for a specific case with unique characteristics.
Not unilateral. The activation height is set to INT_MAX. This code does nothing until the community agrees on a concrete activation height. The purpose of this PR is to facilitate discussion, not to force a change.
Not a soft fork. This is honestly presented as a hard fork. There is no attempt to disguise the nature of the change.

Open questions for discussion

Is the Bitcoin community willing to make a one-time exception for a case with these specific characteristics? If not, what would the threshold be?
What activation mechanism is appropriate? A fixed height, BIP9 miner signaling, or something else?
Should there be a time-lock or expiry? For example, should the recovery window be limited (e.g. 1 year after activation), after which the rule deactivates?

Anything else? Please comment below.

How to test

The change is gated by MtGoxRecoveryHeight in consensus params. On regtest or testnet, this can be set to a low value to test the recovery flow:

Create a P2PKH output paying to the theft address hash
Set MtGoxRecoveryHeight to a low block height
Mine past the activation height
Spend the output using a signature from the recovery key
Verify the transaction is accepted

Files changed

File	Purpose
`src/script/interpreter.h`	New `SCRIPT_VERIFY_MTGOX_RECOVERY` flag
`src/script/interpreter.cpp`	ScriptPubKey substitution logic in `VerifyScript()`
`src/consensus/params.h`	`MtGoxRecoveryHeight` consensus parameter
`src/kernel/chainparams.cpp`	Mainnet activation height (currently `INT_MAX`)
`src/policy/policy.h`	Flag included in mandatory verification flags
`src/validation.cpp`	Height-gated flag activation in `GetBlockScriptFlags()`

consensus: allow recovery of MtGox stolen funds (79,956 BTC)

Add a consensus rule that permits spending outputs locked to the MtGox
theft address (1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF) using a signature
from a designated recovery address (1zUrwsmiJxs19c8SJ8FyGZRXD1zUW77Wj),
so the funds can be returned to creditors through the existing
court-supervised rehabilitation process.

The rule is gated behind a configurable activation height
(MtGoxRecoveryHeight, defaulting to INT_MAX / inactive) and a new
script verification flag (SCRIPT_VERIFY_MTGOX_RECOVERY). It has no
effect until the community agrees on a concrete activation height.

This is a hard fork proposal targeting a single, well-documented theft
where the stolen coins have been dormant for over 15 years and a legal
distribution framework already exists.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

1482ba9eaa

DrahtBot commented at 7:30 pm on February 27, 2026: contributor

♻️ Automatically closing for now based on heuristics. Please leave a comment, if this was erroneous. Generally, please focus on creating high-quality, original content that demonstrates a clear understanding of the project’s requirements and goals.

📝 Moderators: If this is spam, please replace the title with ., so that the thread does not appear in search results.

DrahtBot closed this on Feb 27, 2026

DrahtBot commented at 7:30 pm on February 27, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

MagicalTux commented at 7:31 pm on February 27, 2026: none