<unnamed>

Public Key

npub1v9qy0ry6uyh36z65pe790qrxfye84ydsgzc877armmwr2l9tpkjsdx9q3h

Profile Code

nprofile1qqsxzsz83jdwztcapd2qulzhspnyjvn6jxcypvrl0w3aahp40j4smfgpz4mhxue69uhkzem8wghxummnw3ezumrpdejqz9thwden5te0v35hgar09ec82c30wfjkccteqy8hwumn8ghj7cfwdehhxtnvdakqzrthwden5te0dehhxtnvdakqzyrhwden5te0dehhxarj9emkjmn9qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxg78n7zr

Publishing to

Last Notes

2026-08-17 16:10:38 CEST

- reply

https://image.nostr.build/add23aa53901ca2845d21682cde8cfdd22bdafec253f6e2761ff33b26e037139.jpg

2026-08-17 14:13:13 CEST

- reply

My argument was that 2-of-2 with one software seed (the coordinator) and one hardware was better than just single-sig on hardware.
I agree with you that 2-of-3, 3-of-5 etc. are better than either 2-of-2 or single-sig.
The benefit of 2-of-2 software+hardware (compared to single-sig) is that it protects against the ColdCard class of vulnerability without requiring any new equipment.

2026-08-12 22:57:15 CEST

- reply

Yeah, I don’t know what I’m gonna get around to fixing that. It may be quite a while. 🙏

2026-08-12 22:44:55 CEST

- reply

Correct. It’s not as simple as just adding a BIP39 passphrase to a single-sig.
In BIP39, technically speaking, every seed has a passphrase, it’s just that usually the passphrase is the default value, the empty string “”.
So, for each of your signers in your multisig, they’re already using a passphrase, and could be configured to use a different one.

2026-08-12 19:41:16 CEST

- reply

I’m not sure what you mean. Passphrases are indeed compatible with multisig.
The passphrase gets combined with the other seed material early in the process. So your multisig signers can be based on seed + passphrase, if you want.
If one were so inclined, one could even use the same signing device (same seed) with different passphrases to create a multisig wallet.

2026-08-04 06:38:01 CEST

- reply

Seems good! The only thing I’d recommend is strongly advising 24 words and not 12.
While 12 words is usually fine, the 12th word in a BIP39 seed phrase encodes 7 bits of entropy. So the user, ideally, should be picking those too. Otherwise, if the calculator just gives the first viable checksum, it could have those bits zeroed out, and the user only has 121 bits (before we discount any bias in their drawing mechanism).
Once you’re at 24 words, the final word only has 3 bits of entropy while the other 23 words encode 253 (with pick-and-replace) so it’s not a big deal if the calculator assigns those three bits a default value (000).
If you’re at 24 words anyway, pick-and-replace isn’t as crucial. The difference between pick-and-replace for 23 words and pick-without-replace is 253 bits vs. log2(2048!/2025!) = 241.8 bits. Still way above the 128 bit threshold.

2026-08-04 00:58:00 CEST

If you’re using a signing device (hardware wallet) you already have two things: the signing device itself, and some other software wallet.
It is not a big lift to upgrade to 2-of-2 multisig where one is the device and the other is your software wallet.
But this simple set up protects you from any single vendor bug. #Bitcoin

2026-08-04 00:21:17 CEST

- reply

It happens

2026-08-04 00:20:49 CEST

In society, ownership is what the law allows. The State licenses you to take limited actions.
Freedom means taking control and responsibility. People don’t want freedom. They want license.
#nevent1q…kav4

2026-08-03 23:42:10 CEST

- reply

We’re gonna need more dildos

2026-08-03 23:39:52 CEST

- reply

Agreed. Random number generation is not an important feature for a signing device to have.

2026-08-02 17:49:26 CEST

A hardware wallet has ONE JOB: to protect your seed material from leaks during use.
A lot of people were using their devices for more than that, to their detriment. #Bitcoin

2026-08-02 17:45:58 CEST

- reply

https://image.nostr.build/bee022991ff712fa430ea043424c0c6d9beeffb08b5c1adff7c5393379fb9d4e.jpg

2026-08-02 17:39:42 CEST

- reply

There are plenty of ways of assessing if a specific bit stream is “random”. It basically comes down to measuring diversity of values and looking for patterns.
The simplest check is “all zeros” or “all ones”. Those are obviously non-random at the scale of a Bitcoin seed (128 bits plus).
But a repeating pattern is also non-random. So alternating zeros and ones (“010101010…01”) is also obviously non-random as is other alternating patterns (“00110011…0011”).
The problem in the ColdCard case is that all of the seeds they produced would have passed these checks. The problem wasn’t in the diversity of zeros and ones in the seeds, or patterns resident within a specific seed.
The problem was the distribution of seeds. No local check on the produced values can assert a global problem like that. The only way to detect that class of problem is by auditing the code, which no one sufficiently did until now.

2026-08-02 17:33:18 CEST

- reply

If you’re going to those lengths anyway, I’d encourage you to consider multisig.
A very simple multisig setup would be 2-of-2 where one seed is in software, and the other is resident on a signing device. A desktop wallet like Sparrow makes this relatively easy to set up.
If you use Sparrow, one of the seeds will just be in the encrypted wallet file already, so it’d not any more difficult, practically, to sign than if you only had the signing device.
A 2-of-2 multisig doubles the bits of entropy in your system, making it significantly more secure than single sig.
Everyone’s trying to figure out how to put all their eggs in the most secure basket. Multisig is basket-diversification.

2026-08-02 17:17:42 CEST

- reply

I’m not familiar? If you send me a link I’ll take a look and provide feedback.

2026-08-02 17:08:33 CEST

- reply

Yeah definitely. I think it’ll depend on the person. Some people like you and me take it super seriously and are sweating bullets in a sound dampened bunker. Other people are lazily throwing dice in their dining room (“this is neat! Now I’m bored”).
Dice are a good source of entropy. But the problem is the human element. The system does not consist of the entropy source alone. It’s the source + the person + the tech.
So with respect to dice, it can fail in any of those three ways. The dice could be bad (unlikely). The person could get lazy or otherwise fuck up (likely). The hardware could have been tampered with or have a bug (unlikely).
I designed my SeedPicker Solitaire solution to be:
1. Easy to perform.
2. Hard to fuck up.
3. Fast.
4. Produce enough entropy.
People say do 100 dice rolls because that’s prudent and gives you a buffer. But it also causes people to get bored and skip steps.
While dice are good sources of entropy proper, they’re not as good sources of compliance as they could be. Hard to do (effort). Easy to fuck up (laziness). Slow.
Anyway, that’s my rationale for inventing a deck-of-shuffled-cards based system. A shuffled deck of cards has enough entropy. The skill of shuffling is widely dispersed and easily learned. The Solitaire technique yields enough entropy even if the user fucks it up in one way or another. (It takes multiple categorical fuckups to reduce your entropy to an attackable level).

2026-08-02 16:29:58 CEST

- reply

No worries! Don’t worry about the zaps. My node has been down for months and I’m too lazy to fix it. Maybe someday.

2026-08-02 15:22:22 CEST

- reply

HOW TO FUCK UP DICE ROLLS
The scenario we're considering is someone using a ColdCard to create a new Bitcoin seed with dice rolls. The question is, what can go wrong?
TOO FEW ROLLS
The simplest thing that can go wrong is entering too few dice rolls. For a fair die, 50 rolls is the minimum. 100 is plenty. If you only roll 20 times, your wallet will be at risk.
HUMAN LAZINESS
The most common way people screw up dice rolls is human laziness. People get bored halfway through and start mashing buttons or trying to "invent" random numbers in their heads, which drastically reduces entropy.
UNFAIR DICE
An unlikely thing to go wrong would be using wildly unfair die. A purist would recommend using casino dice, which are intentionally balanced, but many people will just use any available game dice.
A fair die encodes 2.585 bits of entropy per roll. Suppose your die so weighted that it NEVER lands on 6. In that case, you've only got log2(5) = 2.322 bits per roll.
At 50 rolls, you have 2.322 x 50 = 116.1 bits total. This is BELOW the minimum 128 bits required.
However, our hypothetical unfair die, rolled 100 times, produces 232.2 bits of entropy, which is ABOVE the 128-bit threshold. So even an unfair die can produce sufficient entropy if rolled enough times.
DATA ENTRY FAILURE
Hypothetically, the user could enter the values incorrectly. The buttons on a ColdCard are not always easy to press. Someone could roll the dice 100 times but fail to register some rolls, which would reduce the total entropy.
MENU SYSTEM FAILURE
Hypothetically, the user could fail to use the feature correctly. Maybe they got to the screen for entering dice rolls, entered all the numbers, but then hit BACK rather than proceeding to lock it in.
SUPPLY CHAIN ATTACK
Even if you do everything perfectly, you’re trusting the device.
One could imagine a scenario where the ColdCard had been physically tampered with (a supply chain attack) so that no matter what you enter for your dice rolls, it produces a seed the attacker already knows. A similar attack successfully drained funds from fake Trezor devices. While I haven't heard of it happening to a ColdCard, it's in the realm of possibility. https://www.kaspersky.com/blog/fake-trezor-hardware-crypto-wallet/48155/%5D(https://www.kaspersky.com/blog/fake-trezor-hardware-crypto-wallet/48155/
Those are the main failure points off the top of my head. I hope this helps!

2026-08-01 22:41:24 CEST

- reply

The sufficiency comes from the number of dice rolls.
If you roll one die, you get 1, 2, 3, 4, 5, or 6. (6 options)
If you roll two dice, you get 11, 12, 13, 14, 15, 16, 21, 22, 23, 24, 25, 26, 31, 32, 33, 34, 35, 36, 41, 42, 43, 44, 45, 46, 51, 52, 53, 54, 55, 56, 61, 62, 63, 64, 65, or 66. (6 x 6 = 36 options)
If you roll three dice, you get 111, 112, 113, 114, …, 663, 664, 665 or 666. (6 x 6 x 6 = 216 options)
And so on. Each dice you roll multiplies the total number of options by 6.
So if you roll 100 dice, the number of options is 6^100 = 6.533×10⁷⁷ This is an unimaginably vast number.
Vetting that the rolls produce the seed is secondary. The important point is that each roll multiplies the search space, and 100 is plenty.

2026-08-01 16:38:58 CEST

#Bitcoin #memestr
https://image.nostr.build/f81c382804d208fc76b64e3243e486d6a5ccb8687098ea595b4a16bc6e97efb2.jpg

2026-08-01 02:18:00 CEST

E N T R O P Y
#nevent1q…az3h

2026-08-01 00:22:03 CEST

- reply

The point of the airgap is to reduce the likelihood your seed leaks during signing.
The alternative is to plug the device into the machine (USB) or have it communicate over some other channel (BlueTooth, camera + QR codes).
Airgapped with PSBT or QR is the least leaky available option. But again, the point is to protect the seed during signing.
Not to generate seeds. Not to protect data at rest.

2026-07-31 23:01:41 CEST

- reply

He’s saying that knowing where the coin went won’t get it back.

2026-07-31 23:00:55 CEST

Possession may be 9/10 of the law. But it’s 10/10 of the #Bitcoin
#nevent1q…h998

2026-07-31 23:00:02 CEST

- reply

Great question. At some point, in order to use Bitcoin, you’re going to need a computer.
Hardware wallets compute all the time. For example, they compute addresses from XPUBs. They compute XPUBs from seeds and so on.
A BIP-39 checksum word contains bits from the SHA256 of the actual entropy payload. Calculating this SHA256 sum by hand is intractable.
So, in my opinion, the hardware wallet SHOULD be wiling to generate a checksum word for you based on the incoming entropy. ColdCard will do this. I believe SeedSigner will as well. Last I checked, Sparrow WILL NOT do this for you. There are various other tools that may have this capability.
But yeah, at the end of the day, you need multiple independent vendors to perform these kinds of calculations:
- Generating the last word of a BIP39 seed phrase
- Generating an XPUB from a seed phrase
- Generating a master key fingerprint (XFP) from a seed phrase
- Generating addresses from an XPUB
Hardware wallets are powerful enough to do these things. Whether and how many is up to the vendor to implement.

2026-07-31 22:22:59 CEST

- reply

Well, I meant hypothetically 😅

2026-07-31 22:19:55 CEST

- reply

You can get out in front of these by messaging your friends and family first.

2026-07-31 22:19:18 CEST

- reply

Plenty of months left in the year 🤝

2026-07-31 22:18:40 CEST

- reply

That’s the right question. Ultimately, that has to be done by a computer. It can either be a general purpose computer or a hardware wallet.
ColdCard has a way to enter dice rolls to generate a seed. SeedSigner also has this capability. There are other implementations as well.

2026-07-31 21:41:50 CEST

- reply

Ice cold

2026-07-31 21:40:59 CEST

- reply

Did not have that on my bingo card

2026-07-31 21:40:43 CEST

- reply

It depends on the computer. Generating good entropy on low power devices has long been a challenge.

2026-07-31 21:39:21 CEST

Listen, if you’re leaving ColdCard due to this issue and switching to Bitkey, just know that you haven’t changed your risk posture towards this class of issue.
You’re still trusting someone else with your seed generation. #Bitcoin

2026-07-31 21:37:06 CEST

- reply

100+ fair rolls should give you the same seed and security as other comparable devices for this task, like SeedSigner.

2026-07-31 21:31:15 CEST

- reply

What? Ballet, Bitkey, Satscard… what’s the difference?
All of them generate seed material that you cannot observe nor override. So from your perspective, they’re all vulnerable.

2026-07-31 21:30:10 CEST

- reply

The RNG is the only known issue, AFAIK.
So yes. Using a ColdCard, especially eternally quarantined (offline, PSBT) with your OWN seed material, should be just fine.
Even better is to add a passphrase (25th word) or upgrade to multisig.
For example, using Sparrow or BlueWallet, you can make a 2-of-2 with your ColdCard and a software seed as signers. This is a simple mitigation that doesn’t require any new hardware.

2026-07-31 21:26:00 CEST

- reply

The lesson of this whole debacle is that the only way to KNOW that no one else has your seed is to generate it yourself.
Therefore, any device that does not allow you to supply your own seed is unsuitable for use. Full stop.
So I would NEVER put serious amounts of coin secured by Bitkey, Ballet, Satscard, etc. because I can’t verify that their seed material has not been compromised.
I admit that my opinion in this matter is a bit of an outlier here.

2026-07-31 21:10:47 CEST

- reply

Story. Of. My. Life.

2026-07-31 21:09:28 CEST

- reply

Underrated observation

2026-07-31 21:08:20 CEST

- reply

Haha meant to say you don’t “provably” have a quorum. Thanks autocorrect.

2026-07-31 21:07:07 CEST

- reply

Don’t trust anyone! Build a multisig quorum from different vendors.
It’s very unlikely that they’ll all get fucked at the same time.

2026-07-31 21:04:51 CEST

- reply

I know the powers that be really like the Bitkey, but it’s functionally no different from the much maligned Ballet wallet.
The truth is that you do not probably have a quorum over your own seed material.

2026-07-31 20:58:23 CEST

- reply

The ColdCard problem is bad entropy generation.
The OpenDIME doesn’t even try to generate entropy. It leaves that entirely up to you.
So this current problem does not apply to the OpenDIME. You could choose not to use it for other reasons, but it’s not vulnerable to the same problem.

2026-07-31 20:55:02 CEST

- reply

Thank you! I hope that more people will adopt the mindset that they really do need to be in charge of their own entropy production. Everything depends on that.

2026-07-31 20:44:42 CEST

PSA: I’m available for podcast appearances if anyone needs someone to explain of the problem, describe mitigations, or discuss entropy generation approaches. 🙏 #Bitcoin
https://image.nostr.build/ae22194cadc095538df477bae4428b0a98c1117cbf7be1cb83e6cf4794af66fb.jpg

2026-07-31 20:39:52 CEST

DEFENSE
IN
DEPTH
#Bitcoin
#nevent1q…zhh5

2026-07-31 20:36:29 CEST

- reply

Most people are not ready to be unplugged

2026-07-31 20:35:56 CEST

- reply

That might save you in a bulk attack like this. If you’re attacker is just carrying out a premeditated set of transfers, they may not be watching to RBF on top of you again.

2026-07-31 20:25:41 CEST

- reply

Security is the only subject

2026-07-31 20:24:00 CEST

- reply

As far as I know: no, OpenDIME is NOT affected.
The ColdCard vulnerability has to do with generating entropy. The OpenDIME doesn’t even try. It forces you to provide the entropy in the form of a file that you drop on the device. Ideally, a photo that you took specifically for this purpose and then deleted everywhere else.

2026-07-31 20:21:07 CEST

- reply

Yeah, this is a nightmare scenario for them. As I have said elsewhere, and maintain, the hardware wallet has one job: to protect your seed material during use.
It is not your hardware wallet’s job to generate entropy. It is not your hardware wallet’s job to resist an attacker long-term with physical access.
But, I accept that my stance is unconventional.
People get into this field with the “don’t trust, verify“ mentality, but then they place all their trust in the single most important thing that must not fail. The generation of their seed.

2026-07-31 20:05:52 CEST

- reply

The algorithm that ColdCard uses performs SHA256 on the list of dice rolls as a string. So “5456325…31”.
Making this string longer than 100 has no downside, but also makes no practical difference to an attacker. 1000 rolls and 100 rolls both become 256 bits at the end of the day. So 256 bits is the search space no matter how many more rolls beyond 100 you do.

2026-07-31 20:02:28 CEST

- reply

I looked at the code years ago, but haven’t revisited it since. It was my opinion to just cut out the middleman and make the words yourself.

2026-07-31 20:01:07 CEST

- reply

Could be! That would make sense. It’s not a complicated algorithm. It’s basically SHA256 of the string representation of the concatenation of dice rolls.
There’s some nuance in how you byte encode the string for the binary SHA256 operation, but it would make sense for SeedSigner to have adopted ColdCard’s approach as a de facto standard.

2026-07-31 19:57:51 CEST

- reply

Great question. If your dice are fair, 100 is way more than enough. 50 is the real minimum threshold.
To assert that those rolls produce that seed, you need two devices from different manufacturers running the same algorithm.
For example, the algorithm ColdCard uses has been reproduced in Python. You could put the rolls into your ColdCard, write down the words, then put the same rolls into a computer and run the Python program to see that it yields the same words.
Of course, now you have a new problem: your seed has touched a general purpose computer. So ideally, you would use one that is eternally quarantined and has never touched the Internet.
Or, you can find another signing device manufacturer that uses the same algorithm. SeedSigner might. I’m not sure.
You can see now why just rolling dice is not the panacea that people make it out to be.

2026-07-31 19:52:33 CEST

Today in #Bitcoin
https://image.nostr.build/6a05683a73dbb776af0bfedf265f0fb05e7611310a5618db571c3ae8ef92de37.jpg

2026-07-31 19:48:07 CEST

- reply

Almost. But there’s a rolls-to-seed algorithm which most people TRUST to give them the right seed for their rolls.

2026-07-31 19:44:25 CEST

- reply

100 dice rolls, and that there wasn’t a bug in that code path (that we know of, so far).

2026-07-31 19:43:21 CEST

In Bitcoin, ownership is what you KNOW. You either know the keys and can move coins, or you don’t.
So, how do you KNOW that nobody that you has your seed? The only way is to generate it yourself.
If you trust ANYONE ELSE to generate your seed material, then you DON’T KNOW that no one else has it.
Therefore, you MUST generate your OWN ENTROPY in order to KNOW that it’s safe. #Bitcoin

2026-07-31 19:40:30 CEST

- reply

So, yes. In UX terms, the device should observe its low-entropy state and demand entropy before proceeding. Many systems do this. For example, old-school SSH key generators would have you wiggle your mouse around.
However, I’m going to be contrarian here and claim that STILL you should not let a machine generate your seed for you. Practically, the seed generation procedure is unauditable at the moment it’s happening.
To reliably generate a seed, you need to replicate the mechanism on multiple devices from different vendors. At that point, you may as well cut out the middle man and generate entropy you KNOW to be good, yourself, OFFLINE.

2026-07-31 19:30:47 CEST

- reply

This but unironically

2026-07-31 19:30:28 CEST

Your signing device has one job: to protect your seed material from leakage during use. The ColdCard has not failed in this.
People were trusting their ColdCards for an additional job: generating entropy. That was the mistake.
It does not help that wallet manufacturers encourage using the devices for entropy generation. #Bitcoin
#nevent1q…ezky

2026-07-31 19:28:34 CEST

- reply

Correct. 50+ independent, fair dice rolls produces sufficient entropy to hit Bitcoin’s 128 bit minimum security threshold.

2026-07-31 19:27:26 CEST

For people freaking out, here are a two relatively quick mitigations that don’t require any new hardware:
1. Using your existing ColdCard and seed, you can set up a passphrase. This acts like an entirely separate wallet on the same device. You can then sweep the coins to the passphrase sub-wallet.
2. Using your existing ColdCard and seed, set up a 2-of-2 wallet using that device and a software seed using Sparrow or Blue Wallet. Your attacker would have to both exploit the ColdCard vulnerability AND hack your software wallet to move those coins.
Stay frosty out there. #Bitcoin

2026-07-31 19:23:43 CEST

- reply

100%. Multi-vendor multisig is the way to go.
You can even do a simple 2-of-2, where one is on your hardware wallet, and the other is on the computer. An attacker would need to exploit a vulnerability like the current one AND hack your specific computer.
And that option doesn’t require and additional hardware. Just a software wallet like Sparrow or Blue Wallet.
Plus, the multivendor multisig stacks with other best practices. You can use pass phrases (25th words), you can use dice for generation, and these work just fine along with multisig.
Defense in depth.

2026-07-31 19:20:32 CEST

- reply

Some of us have been talking about this for a loooong time.

2026-07-31 19:18:43 CEST

- reply

The lesson here is don’t trust your seed generation to a computer, ever.

2026-07-31 19:17:05 CEST

- reply

Yeah, the failure rate is about 1:2500.

2026-07-31 19:16:18 CEST

NOT YOUR KEYS, NOT YOUR COINS.
NOT YOUR ENTROPY, NOT YOUR KEYS.
#Bitcoin
#nevent1q…d85p

2026-07-31 19:13:42 CEST

- reply

Truly sorry to hear that. 🙏

2026-07-31 17:18:24 CEST

- reply

Unpopular opinion: Never trust a signing device using entropy you yourself didn’t produce. You have no way of knowing how many devices out there are using the same seed.

2026-07-31 17:16:52 CEST

- reply

I made a few different designs. Shadowy Super Coder was the most popular. This was early in the AI slop era. Vintage slop.

2026-07-31 17:14:21 CEST

- reply

YEAAAAHH BUDDAYYY!!
https://image.nostr.build/bd8d52eade343e72f268a0d8bf4636661148a5b1c61429d96d4cf29d729f5cd1.jpg
https://image.nostr.build/9789d25ab504db543d09d515ae5e9ba290483013cf4e210ba47cfb6ffeb50591.jpg
https://video.nostr.build/335ff1e2aefe249ca7bb995a1b122bbd321601c162bf821622f8f79925ca373f.mov

2026-07-31 17:12:52 CEST

- reply

All things considered, a relatively simple and highly secure choice is 2-of-3 multisig using different vendors.
If you use Sparrow or Nunchuck to make a 2-of-3 with different vendors, it’s super unlikely that any two of them will have an active vulnerability exploited at the same time.
I’d still recommend rolling your own seed material, but using multisig with a quorum of independent vendors is even better.

2026-07-31 17:08:37 CEST

- reply

Correct. If you have two different vendors that implement the same dice-to-seed algorithm, then, yes, you can put the same rolls into them and assert that they produce the same seeds. This mitigates the vendor-vulnerability class of bug we’re talking about.
In fact, this multivendor approach applies to other deterministic but opaque algorithms like seed-to-XPUB. If you put a known good seed into a device and it shows you an XPUB, how do you KNOW that that seed goes to that XPUB?
The only way to be sure is to replicate the result on multiple independent devices from different vendors.

2026-07-31 17:05:09 CEST

- reply

It’s not just “move your coins”. You need to generate seed material using your OWN ENTROPY.
If all you do is move from ColdCard to a seed generated by SeedSigner or BitBox or Trezor, you haven’t changed your risk exposure to this class of vulnerability.
You’ve gone from one straw hut to another.

2026-07-31 17:02:07 CEST

- reply

It is indeed. You can run the SHA256-based code on two different devices and thereby verify that both yielded the same seeds from the same dice rolls.
If the devices are from the same manufacturer, then you’ve eliminated the possibility of only one of them being vulnerable. But you haven’t eliminated the possibility of vendor-level vulnerability.
So you need to run the same dice-to-seed code on two independent vendors’ hardware, without mixing in RNG data, to verify that yes, those rolls yield those words.
If one of your devices is ColdCard, what’s your other device? It needs to use the same algorithm for dice-to-seed as your ColdCard (though not necessarily the same exact implementation).

2026-07-31 16:42:07 CEST

- reply

Thank you for calling out the slop. I noticed too.

2026-07-31 16:40:45 CEST

- reply

That tracks. The OpenDIME uses entropy provided by the user in the form of an uploaded file. So yes, a bug reducing the entropy of random number generation shouldn’t affect it.

2026-07-31 16:39:26 CEST

- reply

Too soon 😅

2026-07-31 16:37:47 CEST

- reply

Think of it this way: a single dice roll produces a number from 1-6. The information content of this is log2(6) = 2.585.
That is, each roll produces about two and a half bits worth of entropy.
A 12-word seed phrase encodes 128 bits of entropy. 128 / 2.585 = 49.516. So, yes, to generate a 12-word seed phrase, you need to combine the entropy from 50+ independent dice rolls.
The same logic holds for a 24-word seed phrase which encodes 256 bits of entropy. For that you need the combined entropy of 100+ dice rolls.
BUT the key factor here that most people miss is HOW those rolls are combined. Somehow, your sequence of dice rolls (5-4-5-2-1-…-6-6-4) has to be converted into words (bacon-celery-zoo-…).
If that mechanism is the hardware wallet, then you’re STILL TRUSTING the device, albeit a different code path. How do you know that those rolls produce THAT seed?
So yes, dice rolls are a big step up from just trusting the device’s random number generator. But you’re still vulnerable to other not-yet-discovered bugs in the hardware.
To immunize yourself from ANY hardware bugs, you have to roll your own seed material OFFLINE.

2026-07-31 16:28:54 CEST

#Bitcoin #memestr
https://image.nostr.build/4ec5d49b697b306cc106508c113c2e85939e45ea541687342ec880345d5ef92b.jpg

2026-07-31 15:56:19 CEST

If you roll the dice and put them in the machine to produce your seed, you’re STILL TRUSTING THE DEVICE.
How do you know that those dice rolls yield THAT seed?
You’re out here thinking you’re paranoid using dice with a hardware wallet. I’m telling you, you are NOT PARANOID ENOUGH. #Bitcoin

2026-07-31 15:53:44 CEST

- reply

Hear me out, but there are at least one more level of paranoia you’re missing:
If you put the dice in the machine to produce the seed, you’re still trusting the dice-to-seed mechanism. How do you know that those rolls go to THAT seed?

2026-07-31 15:51:17 CEST

- reply

The security of your Bitcoin rests on the entropy in your seed. For this reason, I advocate rolling your own seed without trusting any device to do that for you.
There are different methods for doing this. You can cut out all 2048 words, jumble them in a hat, and pull words out one at a time.
Or you can flip a coin 128 or 256 times and convert those flips into seed words (there’s a 1-to-1 mapping between 11 coin flips and a BIP-39 seed word).
Personally, I prefer to deal words using a regular pack of playing cards. I developed a system for this. All you have to do is print out the lookup table, then shuffle and deal two cards. Each two-card tuple yields one seed word.
For example, drawing the eight of spades then nine of diamonds yields “celery”.
https://image.nostr.build/e2748be44407b33651328661eef989e9091cd31f2b3afd4532b2bf4e19d34a7d.jpg

2026-07-31 15:45:09 CEST

- reply

Not sure what relay I need to be on, but I can’t see the message you’re replying to.

2026-07-31 14:55:56 CEST

- reply

The problem affects single-sig wallets generated by the ColdCard from March 2021 onwards.
Defenses include:
- Roll your own seed words offline
- Add entropy to seeds (dice)
- Use a passphrase (25th word)
- Use multi-vendor multisig
While it’s fine to change vendors, just changing vendors but sticking to single sig doesn’t protect you from future vulnerabilities like this being discovered.
The single, fastest, easiest mitigation is to roll a new seed with your own entropy and sweep your coins into it.

2026-07-31 14:26:21 CEST

- reply

Multi-vendor multisig is even better. Any given provider may have a bug. Multiple independent vendors means you’re protected from any particular one.

2026-07-31 14:23:20 CEST

- reply

When you generate your seeds, don’t just let the device produce it. You have to add your own entropy in some form. Many people use dice rolls. I use playing cards.
Multi-vendor multisig is ideal. That way, if any particular vendor has a vulnerability (as in this case) your attacker still can’t move your coin.

2026-07-31 14:19:19 CEST

- reply

If you used your ColdCard to generate a seed from March 2021 onwards, it was done without sufficient entropy.
This means an attacker may be able to brute force guess your seed and move your coin. It has already happened. It’s an ongoing, live exploit.
Only single-sig wallets are known to have been affected so far.

2026-07-31 14:16:29 CEST

Worried about your #bitcoin seeds?
Shuffle up and deal your own. https://jimbojw.github.io/seed-picker-solitaire/seed-picker-solitaire.pdf
https://image.nostr.build/6d0a8e8a7fef4f0680056870ce730601f24d2d2fe3c9dedeaff1f7b27f63339b.jpg
https://image.nostr.build/bcaf4a86fc852d4542139e7e834d8b9798f51a53cbc9665971e2022fc5816966.jpg
https://image.nostr.build/67a5ccdb2bf3f44bece7710f0d30e931a1506932acad5bfeb73ab44ed867d7ae.jpg
https://image.nostr.build/c5be610ada77c456c10ddfb899a9e6821461f9d197a4a5cdb86401414931eaf3.jpg

2026-07-31 13:53:01 CEST

- reply

Well, here I’m gonna be a contrarian. Never share seeds.
Bitcoin is the world’s premier value transfer system. Transfer Bitcoin, not seeds.

2026-07-31 13:51:47 CEST

- reply

Asking the important questions.

2026-07-31 13:47:35 CEST

- reply

Better late than never

2026-06-24 03:39:40 CEST

- reply

Tit for tat with forgiveness is the optimal strategy in repeated interaction games