Replies (13)

also i would really like a device like a yubikey that works for nostr, so it's NFC as well as USB and at least uses a 6 digit pin to encrypt the keys, or better, is actually a full bip-340 signer inside so it demands a pin to unlock the stored key and then after some configured amount of time or when unplugged the decrypted key is lost or nuked
yeah, this is something that tapsigners do except only with multiple individual keys using protocol musig... musig2 support with schnorr would work too but that's a whole protocol change, shamir's secret shares would be fine for the interface side of it it's a hard problem, i can see a lot of people falling back to methods that have wide open physical vulnerability, but this is more of an issue for travelers than people working in an office or at their home where there is physical security
oh, it's not just a NFC card it's a fairly large piece of hardware it's a bit bulky, have you got plans for something smaller, maybe even doesn't have any inputs except maybe a button and an indicator light? also, what protocol is it working with? i quite like the concept of a device that has only NFC and USB and no wifi or mobile radio that is just for keeping my keys secure though, i could maybe go for this especially if i can use it to replace my whole login flow for browser and pc (linux)
musig is related to the protocol based, multi-signature - actually multiple signature - protocol based multisig, which allows N of M but requires each signature separately to be appended to the transaction musig2 uses schnorr signatures, as far as i know, in contrast, which only take up 64 bytes for (more or less) any number of signatories - another big difference is that this also dictates that the pubkey (which is a 32 byte bip-340 x-only pubkey, like on nostr) must also be listed in the transaction, whereas ecdsa signatures *contain* the pubkey that is hashed to get the relevant UTXO address (and i'm pretty sure that also means that all of the pubkeys listed must be derived from what would be the even (not 3 prefixed) 33 byte ECDSA public key i could be wrong on some details with this because i have not actually worked with BIP-340 outside of its use in nostr, but it just seemed intuitive to me that musig was a protocol for ecdsa and musig2, which came along with taproot, or very nearby, uses schnorr pubkey/signatures, and though it *can* be done - to embed the pubkey into the signature instead of the current scheme that requires you separately store the pubkey, this can't be done with schnorr composite signatures anyway so it logically must require the transaction to list the 32 byte x-only keys of the potential signatories and then the verification can proceed by verifying that N of M of those are part of the signature it's a little complicated to explain it, but i'm pretty sure that is the rationale and reason behind how it is and what MuSig and Musig2 are different i'm not an expert on bitcoin's transaction schemes or signatures because i simply have never written code to work with it
Moreso Passport in general, but both if you had thoughts on the matter. I like the safety and ease of the NFC connect concept, but i’m also not tech savvy enough to know if that kind of stuff is just slight of hand to focus attention on the good. Like is there bigger and more inherent risk in joining something trying to create a “security platform” where individual device security wouldn’t matter if the company isn’t secure in general or trustworthy enough. I guess i feel like I don’t want to get burned by a newer company haha. A lot of PTSD 😂😂