Ordering mine today. Still looking at Q3 shipping?

Awesome! Yep locked in for September shipping.

Nice! Is there a plan to add blind schnoor signatures eventually? After remote signing?

I think the cryptography for that is partly sorted out but we don’t have concrete designs on a blind signing service tbh. Do you have any thoughts about what you’d like to see?

I’m too retarded to provide specific direction other than stating the obvious: privacy good, people want backups so they’re not solely responsible, while also not opening themselves up to being surveilled and increasing their risk of wrench’s / 6102s. When you say partly sorted and rough designs, what are you thinking along the lines of?

I think that what remains is to show that you can do blind Schnorr + FROST naively without modifying the blind schnorr signing algorithm and the FROST signing algorithm. There’s also work on making ZKPs so you can prove things about the tx without revealing the whole tx (e.g. you could put a spending limit). Right privacy good but it also makes it had to be a backup for someone unless they can identify themselves as the true owner of the coins. Maybe there’s something there though where the blind signer would only sign if you prove the utxo it’s spending (without revealing which one) is older than X months to enforce a sort of scriptless degrading recovery mechanism. What would be cool would be to make the blind signer programmable so we don’t have to think too much about how to build the product — even better make it a reasoning AI prompt that you set up yourself to vet anyone who claims to be the rightful owner of your coins in the future. i.e. upload yourself to the cloud so you can grief your progeny as they try to claim their inheritance.

Hmmm I’ve been thinking about this problem of the blind signer as I have been vibe coding this:

GitHub

GitHub - kiwihodl/Seed-E: A neutral, non-custodial directory for third-party Bitcoin signing services, designed to be integrated directly into wallets.

A neutral, non-custodial directory for third-party Bitcoin signing services, designed to be integrated directly into wallets. - kiwihodl/Seed-E

And once I figure out the right approach I’ll build it in flutter + rust. I don’t think “traditional” multisig should be used, because of the poor key management should a key get compromised.. but it seems blind schnoor signatures and BIP32 seeds with blinded xpubs are the best option. Regarding the blind signers validation, can you take the presumption that their key / work should not need any proof other than it’s an empty PSBT from the person who bought the service? So that this person can request a signature, whether in the seed-e (lol, will change name) or the frost snap wallet and this is all the proof needed? By being blinded you’re kind of treated like a hot key in terms of just signing, but have metal backup of keys share / seed.. I’m not sure the best solution here, I’m early into just throwing things at the wall to see what sticks.

But how do you know if it’s the person who bought the service or not? Email login?

That’s the clients responsibility to ensure good opsec - username, password, 2FA, master key if they loose any of the inputs forementioned and need to change password / 2FA. Still thinking it through, adding unique keys per key purchased and request and using it to mitigate replay attacks. Client follows provider on Keybase, they should probably have some secured comms.. but signature requests and PSBT sharing should go through the platform to ensure the 7day (minimum) wait before the provider signs, which should be ample time for the client to be alerted and contact the provider. There will be better ways of proving the client is who they say they are, signing xyz message or something.. still thinking it through what the best approach is, and actually if it’s for me to even decide that or let people figure it out themselves and just provide the means to do that as I iterate through.