Dumb take.
There are a bunch of other attack surface those wallets don't protect you against and there are lots of trade offs.
Second under Mitigations; COLDCARD has always done RFC6979 signatures. That with repro builds are perfectly adequate. jade requires pin servers to be secure that is a huge trade off. Bitbox requires usb, huge trade off.
nostr:note16748fqunfxq63y980gl7me3u7d6zklvg8tscg45fpfw2lhzpv05qw2l5y4
When the boys are out here sharpening iron with iron to make the ultimate security HWW 🥺🍿
How is Block running the key server, mobile app, and BitKey as a 2 of 3 isn't distributing risk?
Let alone the UTXO privacy concerns.
Everything has trade offs, you forgot a few.
The only question mark is the key server.
App is open source and reproduceable.
However in the Bitkey model effectively you have two hot keys (phone and key server) which is a big trade off even if it’s source viewable (it is not FOSS), and your hardware wallet has no screen so you could easily approve a transfer to an address other than you intended if someone has hijacked your phone and what appears on its screen. The Bitkey is a $150 glorified yubikey.
This is true, which is why it makes sense at the $25 promo price.
At the $150 asking price, it's a tapsigner with an added fingerprint sensor, but with additional tradeoffs and vendor lock-in.
I can only see this being a useful product if they keep the current model for entry-level users and unlock it for use as a blind signer for any multisig setup.
> if someone has hijacked your phone and what appears on its screen.
this is common for all blind signers, not a bitkey specific issue.
Any blind signer can be turned into a non-blind one with 2 things:
1. Extra code in the signer to check if the sign request is signed by the screen device
2. A screen device that shows the transaction, and produces a signature for it if approved (this can be less secure)
Yeah I agree if it was $25 it makes a lot more sense.
However I think other blind signers are marketed differently and sold to a largely different audience. My guess is people buying say a tapsigner and using Nunchuk are more educated on these trade offs.
I feel a bit sad reading posts like this. How the fuck will we ever get all this safe and usable for mainstream.
It's already safe and usable by mainstream. Some folks tend to make bigger issues of nothing new.
COLDCARD is excellent; thank you for your dedication to security.
Question: when someone buys a hardware wallet they provide a shipping address that can later be leaked. Ledger famously leaked customer emails and physical addresses for example. Any tips on mitigating that? Use an alias and ship to your employer’s address?
Coinkite deletes the shipping information after 90 days, but that's a promise you can't verify.
Best yet, is to use a alias, pay with bitcoin and ship to a pobox or hotel instead. Or buy in person from a reseller.
So what's your preferred standard for anti-exfil?
Anti-exfil makes even closed source hardware wallets somewhat trustworthy as the companion app has the user's back.
Nonce attacks are just one of a million types of attacks.
I want anti-klepto spec that is implemented on core and is transported via PSBT.
We don't want more vendor specific stuff
If it protects the user against a backdoor hidden deep in some fringe dependency, maybe "we" want anti-klepto.
Isn't it marvelous that the deterministic nature of Bitcoin can let a companion app verify a hardware wallet is following the protocol in a non-leaking way? I find this unbelievable and would want that for my hardware wallet to sleep sound at night, knowing that nobody can exfiltrate keys. No supplier. No library provider. No engineer around me. Not even with a gun to their head they could succeed.
The hyperbolic recommendations being made in some of the original posts… what is stopping ColdCard from adding this probable random capability?
Hardware limitation, or just developer hours?
Those posts Aside***
Lack of standards and transport, we will not expose people to USB risk for this. This to use PSBTs.
It's minimal additional data that fits comfortably into your BBQRs. Why bring up USB here?
The current spec used for this protocol is over usb and custom hwi.
Ideally there would be an extra field on PSBT. And the clients would include in it. We would taken take it and sign it. And to feel comfortable I want to see core with a proposed implementation of the client side.
Messing with nonces is dangerous as fuck.
Who will write the standard if not you or your peers?
At the end of the day you gotta choose something, cold card and bitbox are my choice.
