FROST certainly has potential to reduce L1 transaction costs and add flexibility and privacy in a system like Bitkey. Right this moment weāre focused on a few other things though, you can see more about our roadmap here: https://bitkey.build/building-better-bitcoin-self-custody/
Nah, I just mostly use socials for representing what Iām building for people and engaging on that. The rest of the time Iām reading and listening and learning here
Hereās an entire article where the author bashes seed phrase recovery without once suggesting a better method that isnāt centralizing, and nowhere in the article does it state that said author is employed by a company that sells a hardware wallet without seed phrase recovery. š¤
https://bitcoinmagazine.com/technical/a-seed-phrase-isnt-self-custody-its-a-liability
You can read about what we think can be better on our blog (e.g. https://bitkey.build/seedless-is-safer/), and when I have it Iāll link a video of our Bitcoin Las Vegas panel that expresses some of it as well. Also, I agree there should be a disclosure, will see if we can add one
You can always move your bitcoin without Block using the two keys you hold, even if Block servers are unreachable. And if you canāt get the Bitkey app from the app stores anymore, you can move your bitcoin using Bitkeyās Emergency Access Kit (https://support.bitkey.world/hc/en-us/articles/24395170222868-What-is-an-Emergency-Access-Kit-and-how-does-it-work) using your hardware and cloud backup. Are there other scenarios youāre looking to use seed phrases for?
Right here on nostr works just fine. What do you have in mind?
You can consolidate, but not yet manage UTXOs directly in Bitkey. Could you tell me more about how you want to manage UTXOs? Individual UTXO choice per transaction, or more like two separate accounts, something else?
This is one of the big things weāre working on (check out the post!)
Hopefully can help here - DMāed
nostr:npub1yk3pjtw0xnpmuvnf3z6un72z42t83xye69d4jsfxq2z54pera85qcwyya6 friendly reminder, as I could not find details on the landing page š
The inheritance plan relies on the Block/Bitkey server to fulfill claims. If we were to go out of business, we'd aim to give 6 months' notice so customers can sweep their bitcoin. After that, theyād need new arrangements to manage inheritance. If youāre using Bitkey and see us go out of business, you could move your funds to another wallet.
If you're concerned about Block going out of business before your beneficiary completes a claim, consider setting up a backup method. You can add their fingerprint to your Bitkey and share a copy of your Emergency Access Kit to ensure they have access to your funds if needed.
Bitkey did not make clear to use the inheritance feature you need to buy two bitkeys. This makes it both double the cost and much less noob friendly imo. Still a great start but a downside that shouldāve been made much clearer. https://support.bitkey.world/hc/en-us/articles/32959918821012-I-have-been-invited-to-become-a-beneficiary-what-do-I-do
As part of the inheritance protocol, your beneficiary must store a decryption key to access an encrypted version of your mobile key stored by Block. They need their own Bitkey wallet (app + hardware) to securely store this information long-term and benefit from our recovery protections. Ultimately this is a safety-focused choice in our design - storing keys long-term is hard, and this protocol is based on your beneficiary having a key, not on their government ID or anything like that. And Iāll look into where we might be able to clarify this more/earlier.
For anyone wondering, I believe this is where keypairs are made:
https://github.com/proto-at-block/bitkey/blob/main/app/core/crypto/src/keys.rs
So now I need to find references to this, but github is claiming there are none š
I will keep progress updates on this š§µ
It is frustrating that nobody from bitkey is monitoring this, all other wallet providers I have contacted are very active on š and have been very helpful š¤
https://github.com/rust-bitcoin/rust-bitcoin/blob/162094322fc75c92d1241f2afd4514131683856d/bitcoin/src/crypto/key.rs#L413 (for mobile and server) & https://github.com/proto-at-block/bitkey/blob/main/firmware/lib/crypto/src/ecc.c#L51 (for firmware)
hope that helps!
Curious how #bitkey will help people stay in control of their funds when they lose part of their wallet? Check out the recovery paper weāve shared today - and let us know what you think! https://bitkey.build/sharing-our-recovery-design/
Great questions.
On (1): the phone can't modify information signed by the hardware, it just forwards it to the server. Bitkey hardware ships with a key (not the one used for signing transactions) that can be used to sign messages and which Bitkey servers can verify. If a compromised phone attempts to modify what the hardware has signed, the server would know they've been tampered with and would be able to surface that to the user via a channel like email.
On (2): if the Bitkey servers that communicate the addresses or transaction details to you in the proposed solution were compromised, what they show/send you wouldn't match your phone's screen.
Not 100% sure I understand your setup, but seems like probably one of these:
If itās bluewallet on your phone plus Ledger: If your phone is sufficiently compromised, you canāt trust the address shown in bluewallet, or the QR code youāre scanning..
If itās desktop plus bluewallet on your phone: if your desktop is sufficiently compromised, you canāt trust the address there, or a QR code scanned from thereā¦
What do you usually compare it against? Curious both about what type of device youāre using with your hardware wallet and what specifically youāre usually comparing the wallet screen to
I thought Jack had reposted their article from yesterday about seed phrases (https://bitkey.build/seed-phrases-are-sharp-edges/) and responded before I saw it was a new article about hardware device screens.
I donāt agree with all the reasoning in that seed phrase article. Ultimately, someone has to control the seed. If the user doesnāt keep a copy themselves, then theyāre deferring trust somewhere else.
āSeedlessā custody generally puts a lot of trust in the device securing that seed. Without a seed backup, hardware failures are catastrophic for singlesig setups. I would never do seedless unless it were multisig. But even with seedless multisig, losing a device means you have to deal with a more complicated key rotation process, rather than just recovering the same seed into a new device.
In Blockās Bitkey setup, it sounds like itās seedless multisig āuntil you need to export the seedā. Itās yet to be seen how sovereign that recovery can be or if youāll have to ultimately get permission to access a seed or move to a different multisig coordinator. It sounds prone to lock-in, but Iād need to read more about the technical details to know.
There are trade offs to various approaches, and I donāt think their seed phrase article properly highlights those trade offs.
ā
But like I said, the article Jack linked in the OP is a different topic - hardware device screens. It seems pretty well reasoned, but I only skimmed it. I donāt know if I agree with all the listed attack vectors and risks associated with over-reliance on device screens. I prefer a screen on the device, but screenless might work well enough in their setup, since itāll have a server-side component to help verify data.
Regardless, itās a unique approach, and Iām interested to see how it develops. Will probably be a good onboarding option for less technical people.
Thanks for the feedback! When we share details of the key portability feature Iād love to hear what you think. Youāre right that in multisig there are ways to recover from losing a device without needing the seed, and weāre trying to make that easy for the owner to do using the other device in the multisig setup. You can read more about this in another one of our posts: https://bitkey.build/losing-your-keys-without-losing-your-coins/
Donāt think you need a screen on the hardware (or the āserver as a screenā option) to check for clipboard malware - you can catch that on the device youāre doing the copying on
Our final post in this week's security series is a big one: why screens aren't all they're cracked up to be, why we think they keep people from self-custody, & how Bitkey can help without a screen on the hardware. Take a read, let us know what you think: https://bitkey.build/screens-are-not-a-panacea/