[Case Study] Peter Todd's hash-collision bounties show how Bitcoin Script can fund security disclosures without intermediaries

## Metadata

- **Slug**: peter-todd-hash-collision-bounties
- **Short Description**: Peter Todd's hash-collision bounties show how Bitcoin Script can fund security disclosures without intermediaries.
- **Tags**: bounty, mechanism design, trustless, bitcoin-script, cryptography, security
- **Featured**: false

## Banner Image

## Logo

## Description

**Type**: Analysis
**Authors**: @oritwoen, @aeitwoen
**Status**: Ongoing
**Mechanism Type**: Bitcoin Script conditional bounty (P2SH)
**Funding Date**: 2013-09-13

### Background

In September 2013, Peter Todd published Bitcoin addresses that could be spent only by proving a cryptographic collision. No committee, no legal process, no payout admin. The condition lived directly in script and was enforced by the network.

From a security-research perspective, the design solves a hard disclosure problem: if collisions become practical for Bitcoin-relevant hashes, how do we get a public, credible signal fast? You attach BTC to a proof condition and let consensus settle the argument.

That created a live challenge market. Anyone could fund the addresses, and anyone could claim by satisfying the script.

### The Mechanism / Program

Original announcement: [Bitcointalk thread](https://bitcointalk.org/index.php?topic=293382.0).

Six bounties were created, each with a different opcode path:

- `OP_SHA1`
- `OP_SHA256`
- `OP_RIPEMD160`
- `OP_HASH160`
- `OP_HASH256`
- `OP_ABS` (demonstration puzzle)

Representative script (SHA-1 path):

```
OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
```

To spend, you provide two different inputs with the same digest. If the script passes, payment happens immediately. No manual payout path exists.

Key mechanism properties:

- No custodian holds funds
- No application, committee, or approval flow
- Anyone can top up a bounty address
- Anyone can claim with a valid proof
- Conditions are transparent and deterministic

### Outcomes

#### What happened on-chain

- `OP_ABS` was claimed in 2018 (as expected for a simple demonstration condition).
- The SHA-1 bounty address has been claimed using SHAttered-derived data and later saw additional small re-funding/re-claim activity.
- Four collision bounties remain unclaimed: SHA-256, RIPEMD-160, HASH160, HASH256.

At the time of writing (2026-02-19), unresolved balances are:

- SHA-256: 0.27734251 BTC
- RIPEMD-160: 0.11576888 BTC
- HASH160: 0.10026873 BTC
- HASH256: 0.10026873 BTC

Total still unclaimed across these four at the time of writing: **0.59364885 BTC**.

#### Security signaling function

In practice, this works like a standing canary. A successful claim is not a press release, it is an on-chain spend every full node can verify.

### Challenges and Solutions

**Challenge: Script constraints vs real-world collision artifacts**

SHAttered PDF files are large, while Bitcoin Script limits pushed stack elements to 520 bytes (`MAX_SCRIPT_ELEMENT_SIZE`).

***Solution:*** Claims used compact collision-relevant input material that fits script limits. That means the mechanism tests practical exploitability under Bitcoin transaction constraints, not abstract collision existence on paper.

**Challenge: Front-running risk**

Claim transactions expose proof data. In principle, miners or observers can try to race the claim.

***Solution:*** This is a known tradeoff in transparent on-chain bounty execution. Operational mitigation (private relay or miner coordination) is external to the mechanism itself.

**Challenge: Incentive size mismatch**

For strong hashes, bounty size is far below likely discovery cost.

***Solution:*** The mechanism remains useful as a disclosure surface and public signal, even when it does not fully price top-tier research effort.

### Lessons Learned

- **Programmable funding conditions can replace institutional payout logic.** The script is both contract and cashier.
- **Open contribution + open claim creates durable incentive pools.** The addresses persisted for years without operators.
- **Proof-carrying payouts create stronger security signals than narrative reporting.** Claims are verifiable events, not announcements.
- **Constraint-aware design matters.** Bitcoin-level limits shape what "claimable" means in practice.
- **Plural funding is broader than grants.** Some security problems are better handled by deterministic bounties.

### Conclusion

Peter Todd's hash-collision bounties are a different funding primitive: trustless, permissionless, and self-executing. They do not replace grants or retro funding, but they are excellent where outcomes are binary and externally verifiable. Narrow tool, strong signal, high epistemic clarity.

### Sources

- [Original bounty announcement (Bitcointalk, 2013)](https://bitcointalk.org/index.php?topic=293382.0)
- [Original bounty announcement (bitcoin-dev mailing list mirror)](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-September/003253.html)
- [Google Security Blog: first SHA-1 collision (2017-02-23)](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html)
- [The first collision for full SHA-1 (IACR ePrint PDF)](https://eprint.iacr.org/2017/190.pdf)
- [SHAttered project page (archive snapshot)](https://web.archive.org/web/20190207235616/http://shattered.io/)
- [Bitcoin Core: `MAX_SCRIPT_ELEMENT_SIZE = 520`](https://github.com/bitcoin/bitcoin/blob/9e4567b17a285a266fa540b4141e0db5781cc228/src/script/script.h#L27-L28)
- [Bitcoin Core interpreter size check (`SCRIPT_ERR_PUSH_SIZE`)](https://github.com/bitcoin/bitcoin/blob/9e4567b17a285a266fa540b4141e0db5781cc228/src/script/interpreter.cpp#L447-L448)
- [boha dataset entry for hash collision collection](https://github.com/oritwoen/boha/blob/main/data/hash_collision.jsonc)

## Related Apps (Optional)

-
-

## Related Mechanisms (Optional)

- direct-grants
- quadratic-funding

## Related Case Studies (Optional)

-
-

## Related Research (Optional)

- plural-funding-mechanisms

## Related Campaigns (Optional)

-
-

---

## Submission Checklist

- [x] Short description is clear and concise
- [x] Tags are provided
- [x] Description is comprehensive
- [x] Related mechanisms/apps are listed (if applicable)