HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
jlopp
physical-bitcoin-attacks
HTML2018–2026
jlopp / physical-bitcoin-attacks

physical-bitcoin-attacks

A list of known attacks against Bitcoin / crypto asset owning entities that occurred in meatspace.

18Distinct people
23Mentions
0Explicit recommenders
909GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A list of known attacks against Bitcoin / crypto asset owning entities that occurred in meatspace.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 7:24:48 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year23 dated mentions

Observed mentions: 2018-12-27 20:36:20 UTC to 2026-10-22 20:21:02 UTC.

02462018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC523
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC624
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

What Hacker News says

4 sources
The tradeoffs of the design itself sacrifice payee safety and philosophically imply that the lives of its users are secondary to socially engineering goals which they dishonestly deny are incompatible with same. https://github.com/jlopp/physical-bitcoin-attacks That is objectively, justifiably classifiable as manipulative and destructive. To clarify: I assert that taxation and a functioning state, and the safety and security of the users of an online currency are absolutely not incompatible with one another—and I'm not even implicitly asserting that the definition of a "functioning state" is some kind of weird ancap impossible libertarian ideal.
In Getting ready to operate GNU Taler in Germany
> The developer signing the build provides sufficient guarantees. There are tons of documented cases of people resorting to physical attacks to obtain valuable cryptographic signing keys stored in full in one place. https://github.com/jlopp/physical-bitcoin-attacks I can only guess the people painting targets on their backs that big are woefully unaware of it, or living in deep survivors bias. Trusting control of the entire internet to the laptop memory holding the PGP signing key that signs debian packages of GCC was always an insane thing to do, and still is. Imagine what happens when one of those maintainers decides they like bribes or do not like being hit with rubber hoses. Quorum signing of full source bootstrapped deterministic builds completed on independently owned and geo-distributed hardware produced by different vendors is cur
Read the rest
rently the only viable solution to greatly reduce the incentive to coerce maintainers.
In Bootstrappable Builds: How and Why
To counter the dismissal of general hardware as a cold wallet, your view on threat models itself is a bit hopeful. Best summarized by xkcd, https://xkcd.com/538/ Having a dedicated device that screams "hey I have bitcoin" is almost always going to be more of a risk than a dedicated general compute device of plausible deniability. A device such as a phone with wireless and usb data disabled, encrypted, accessing data stored in an app that has it's own encryption on top. Its cute to romanticize the idea that some threat actor will be up against some impossibly secure device, the reality tends to be a lot simpler https://github.com/jlopp/physical-bitcoin-attacks especially if they find you have dedicated hardware with the sole purpose of securing crypto.
In Bitcoin on the Home Server: Sovereignty with Coldcard, Sparrow and Fulcrum

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.