Quote

Cool, excited to read it! Thanks for the link. Any plans for open-sourcing hardware, too?

We are inclined towards open sourcing that too. We just don't have a timeline for that at this point.

Quote

My main complaint / critique with your concept of splitting the seed and having people store the cards in different location is, that it makes the everyday usage less convenient. This looks like a reasonably solid cold-storage setup for non-technical people, who could find it difficult to create and deploy a paper-based multisig setup.

But for me, a hardware wallet is a convenient, yet secure (from software & hardware attacks) way to spend Bitcoin any day, anywhere. Of course, a 'hardware wallet' setup which stores the seed in multiple distributed locations, will be more secure, but it will be much less convenient when trying to spend. I'd personally probably just use it in single-sig mode (if possible) or store all the cards together to be able to use it quickly; although that would kill its main selling point.

Well, you don't need all of the 5 shards together to spend your Bitcoins. You just need the X1 wallet and any 1 of the 4 X1 cards. If you are optimising for convenience, you can store an X1 wallet and X1 card together. If you want to optimize for security, just keep the X1 cards as geographically distributed as possible. Completely depends on the user. The UX difference with other hardware wallets is just that you additionally need to tap an X1 card to authorize a transaction.

Quote

KYC data is not even saved by you or your provider, but actually by another service behind 'onramper', so I don't even know if users get to know where their data ended up and who to contact if they want it deleted.

Onramp is optional for the users to use. We will definitely keep this in mind before we decide to go ahead with the integration.

Quote

Downside: someone discovers a hardware / firmware bug in the JavaCard and those cards will need to be replaced with new, secure cards, as there is no update mechanism to fix the issue (unlike Trezor and Ledger who fixed hardware attacks through firmware upgrades).

The Javacard is audited by SERMA SAFETY AND SECURITY ITSEF which are one of the World's best in Javacard security. Currently, it has been battle-tested over a period of 1 year of internal beta testing as well. Yes, if it ever comes to that, the cards will need to be replaced. But the same thing could be argued for a bug in the bootloader and secure element of some of the most popular hardware wallets since even they are not upgradeable. With Cypherock, at least your funds are not at risk since the private keys as a whole are never stored completely in the Javacards.

Quote

This is a little bit disingenuous.. Cheesy

Did you somehow multiply 2x5 (because of the 5 keys) to get to the conclusion that it's 10x safer? Safer than what? What's the benchmark? Throwing out a number like that to impress newbies is not very cool. You and I know that it's hard to quantify how much safer this setup will be, since you don't know how (well) people will deploy / store their 5 keys.

We know it is hard to quantify the security. The fact that your seed/private keys do not have a single point of failure at rest where most of the attack vectors exist for current hardware wallets. Given decent geographical distribution of the cards, we may even argue that the security delta might be even higher. We considered an average here. I would say the security delta is even greater for Bitcoin multisig.