physical-bitcoin-attacks is a curated record of physical attacks on crypto holders

A dataset about the physical world, not about cryptography

The repository collects a specific and uncomfortable category of event: attacks that happened to people who hold crypto assets, in the physical world. The description is a list of known attacks against Bitcoin or crypto asset owning entities that occurred in meatspace, and the README puts the scope immediately.

The word meatspace is doing the work here. Everything in the list involves a person, a place and a threat. A row from December 29 2014 records the Bitcoin developer Hal Finney being SWATted in Santa Barbara, California after months of harassment and extortion. A row from February 2015 records the Bitcoin trader Dean Katz being robbed of 12,000 dollars at gunpoint in New York. A row from July 11 2016 records the cryptocurrency executive Tadas Kasputis being kidnapped at a car wash in Kaunas, Lithuania. The threat model is coercion, applied to whoever holds the keys.

The audience is twofold and they use the data differently. Security researchers and people designing physical custody arrangements read it to understand what actually happens to key holders, whether that is a home invasion, an armed robbery during a trade, or a kidnapping that ends with a transfer demand. Journalists and analysts use the linked maps and dashboards to see the shape of the problem over time and by place.

What makes this repository more useful than a news archive is the structure. Every incident is one row, with a date, a named victim, a location and a description, and each description carries links to the reporting, usually with an archived copy so the citation survives.

The repository is maintained by a single author, and the repository listing shows the pieces: attacks.json, excluded.json, index.html, a tools/ directory, a CONTRIBUTING.md, a LICENSE file, and a folder named protect against wrench attacks. The primary language of the repository is HTML, which tells you the map is a static site built from the data rather than a service.

Four columns and a link, and the archival practice behind them

The table in the README has four columns: Date, Victim, Location and Description. The Description cell is where the reporting lives, and it is where the project's care shows.

Look at the citation pattern in the rows. The March 14 2017 entry, in which three Emiratis posing as police kidnapped and robbed three Indian Bitcoin traders in Dubai of 25 BTC, links to an archive.is snapshot and to the original Khaleej Times article. The February 16 2017 London entry links to a web.archive.org snapshot of a LocalBitcoins forum thread, the original forum link, a Bitcoin Uncensored interview with the victim, and a second forum link described as the robber's side of the story.

That last detail is the most methodologically interesting thing in the repository. In a case where the account comes from the person who was robbed, the list links to the account of the person who did the robbing, so a reader can see both sides. Whether the two accounts agree is left to the reader.

The archiving is not incidental. archive.is and web.archive.org snapshots are used throughout, which means a row does not rot when a news site reorganises its archive or a forum thread is deleted. For a dataset whose value is the citation, that is the difference between a durable reference and a list of dead links.

The dates are also inconsistent on purpose, in a sense. Most rows carry a full date, but some carry only a year, for instance the 2017 entry about a gang in Boyacá, Colombia that used a woman as bait to lure cryptocurrency merchants. Where the exact day is unknown, the entry says so rather than inventing precision, and the description carries the detail that the gang was broken up with arrests in July 2019 and that all five members accepted kidnapping charges.

The Location column is what makes the map possible. Rows record Santa Barbara, Atlanta, Amsterdam, New York, Kaunas, West Palm Beach, Toronto, Delhi, Auraiya, Gifu, Dubai and Florianopolis, which is a dataset with a spatial dimension and not just a chronology.

excluded.json is the part that makes the list honest

Two data files sit at the root of the repository, attacks.json and excluded.json. The naming is the interesting part, because the second file implies a curation policy rather than a simple collection.

A list of attacks needs a rule for what goes in, and the README points to CONTRIBUTING.md for what qualifies and how to add entries. That guide is where the criteria live, and the presence of an exclusions file beside the main data suggests that borderline cases, things that were considered and rejected, are recorded rather than silently dropped. That is a meaningful difference for anyone analysing the data, because it distinguishes a missing entry from a deliberately excluded one.

The tools/ directory indicates that the data is processed rather than hand maintained in its final form. The index.html at the root is the entry point, and the README points to an interactive map hosted on the project pages, along with a separate Crypto Crime Dashboard and a statistics site. Between the table, the JSON files, the map and the dashboards, the same underlying data is presented at several levels of detail, from a person reading a single incident to a person looking at a distribution over time.

The research output sits alongside the data too. The repository carries Wrench_Attacks_Research.pdf, an academic paper analysing physical attacks using Bitcointalk as a data source. That is a different collection method from this list, which relies on news reporting, and the contrast is instructive: forum posts capture incidents that never reached a newsroom, while this list captures incidents that were reported but may not have been discussed on the forum.

For an engineer building a dataset pipeline, the useful takeaway is that the raw data is small, human curated, and link backed, and the tooling in tools/ is what turns it into the map and the statistics.

How to use it: the map, the dashboards, and contributing an entry

There is nothing to install here, and the README says where to get what you need instead.

For interactive use, the project points to its map at jlopp.github.io/physical-bitcoin-attacks/, and to the Crypto Crime Dashboard for a different view of the same information. For statistical breakdowns of attack attributes, the README points to gart.io/stats, and for a separate comprehensive list of attacks it points to bitcoin-wrench-attacks.zaup.org. That last one is worth reading as a cross check, because two independently maintained lists will not contain the same incidents, and the difference is a rough measure of the coverage problem described later.

The raw data itself is the JSON in the repository, and the table in the README is a readable rendering of it.

Contributing is the other way to use the project. The README asks that you open an issue or a pull request if you are aware of an attack that is not listed, and directs you to CONTRIBUTING.md for what qualifies and how to add entries. A pull request with a new row needs the same structure as the existing ones, a date, a victim, a location and a description with links, which means an archived copy of the source is valuable, since the maintainers will be checking them.

The repository also holds a folder named protect against wrench attacks, which points at the practical side of the project. For high level analyses and best practices, the README recommends a 2020 presentation called The Hodlguard, a primer on physical security in Bitcoin, with its slides, and a 2025 presentation by Jameson with updated metrics and advice. A 2026 reader looking for how to store coins safely has a reading list attached to the dataset.

The coverage problem is stated in the first line

The limitation is not hidden, and it is stated before the table. The README says the list is not comprehensive and that many attacks are not publicly reported.

That single sentence changes how any analysis should be read. A dataset of unreported attacks is a dataset of the attacks that reached a journalist, a police report or a court record. The list is therefore biased towards events that are notable enough to be written about, and it is likely to under-represent attacks in places with less English language reporting, attacks against people who did not report them, and repeat or attempted attacks that never became news items.

There is a second, subtler filter. A row needs a victim and a location to be placed on a map, and it needs a date. Incidents where the holder was anonymous, or where the exchange took place in a way that obscured the location, are harder to include, even when they were reported.

The practical consequence is that the data is good for describing what happened and how it happened, and weak for estimating how often it happens. A row count is not a rate. Anyone drawing conclusions about, say, which cities are most dangerous, or about a trend over time, is reading a property of the reporting rather than of the risk.

That is not a criticism of the project so much as a statement of what a curated, cited, human built list can be. The alternative sources in the README make the same point in a different way. The academic paper uses Bitcointalk as a data source, which captures a different population of incidents, and the external lists are maintained by other people with their own coverage. Comparing the three is the closest thing to a coverage estimate that the project offers.

Unlicensed data, no releases, and a steady update cadence

The licence is the Unlicense, which is about as permissive as a licence can be for a data project, and it matches the intent of the content being news citations and short factual descriptions. The LICENSE file sits at the root beside the README and the data files.

There are no GitHub releases, and for this kind of repository that is the right shape. A tag would freeze a snapshot of a list that is meant to grow, and the sensible way to consume it is to take the current state of the data files, or to track the master branch. The repository is not archived, and the last push was on 2026-10-19, so the list is being extended in near real time.

The publishing pipeline is visible in the .github/ directory and in the tools/ folder. The index.html and the map are the artefacts, attacks.json and excluded.json are the sources, and the tools/ directory holds whatever turns one into the other.

One thing the README does not document, and that an adopter should establish for themselves, is the update cadence in any formal sense. There is no published schedule and no changelog, only the commit history. The table rows do show that entries continue to be added for recent years, and the presence of a Wikipedia-style archive link in the February 2017 row that points at a snapshot dated 2026 shows the project revisits older citations as they break.

For anyone planning to use this data, the honest summary is that it is current, cited, and permissive, and that its weakness is not accuracy but coverage, a limitation the author states in the first paragraph.

Editorial conclusion

Adopt physical-bitcoin-attacks if you are designing physical security for a crypto holder, writing about real world theft of digital assets, or looking for a structured dataset with links to primary reporting rather than an anecdote. Do not adopt it as a complete census, because the README states the list is not comprehensive and that many attacks are not publicly reported, and do not use it for prevalence estimates without accounting for the bias towards reported and English language cases. Before you rely on it, read CONTRIBUTING.md for what qualifies as an entry, check the excluded.json file to see what the maintainers deliberately left out, and verify the individual rows you rely on against the archived links, since the citations are snapshots of news pages that can change or disappear.

Frequently asked questions

Official sources

1. Issues
2. jlopp/physical-bitcoin-attacks on GitHub
3. License: Unlicense
4. Project website
5. README