Did we give up custodial nsecbunker providers? What else do we need on that front? nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1zfss807aer0j26mwp2la0ume0jqde3823rmu97ra6sgyyg956e0s6xw445 nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk
Discussion
More stable Amber support for NIP-46 nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usjfpck and a desktop signer to do the same.
I have plans to make it multiplatform but haven't started working on it yet
I am not sure if it's a good use of your time.
But if you want...
Nsec.app has self-hosted mode (that nobody tried, obviously), need to wrap it with some cross-platform app framework to make a desktop app.
Are we not using Schnorr sigs? That should allow multi signature schemes where only collaborating machines can sign a message. Federated custody of social media keys. I could imagine endorsing such an nsecbunker using 3of3 sigs.
Would you run one?
Not sure. Maybe. I might sponsor somebody to set it up and maintain it.
Is it possible to take an nsec you already have and split it into 3 somehow, give one shard to each server and then they somehow collaborate to make a signature? I think you can't do MuSig2 for that, but maybe some other, simpler (less safe?) algorithm? I've asked nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7 this once but he never answered.
I just spent 15 minutes with perplexity ai trying to figure out if SeedXOR can be applied to nsec keys, and it seems very plausible. Not sure if this is helpful or even in the right direction.
You can if you use FROST. You can be the dealer and send keys that need to sign to each server. 3-of-3 is possible, but you can also do arbitrary k-of-n.
Good to know, that prompted me to take a better look at FROST, which for some reason I initially thought was more constrained than MuSig2 in this regard and would never support this flow.
nostr:npub1zswjq57t99f444z6485xtn0vfyjjfu8vqpnyj6uckuyem2446evqnxgc6x made a Fedimint module for for signing notes.
Is that a fork of the full Fedimint repository?
It does appear that it is. Iβm unsure what is actually needed. Maybe nostr:npub1zswjq57t99f444z6485xtn0vfyjjfu8vqpnyj6uckuyem2446evqnxgc6x can explain
Pretty sure I agree that FROST is closer to the mark in what @fiatjaf is looking for, but specifically the signing algorithm and not the keygen algorithm. FROST (and Pedersen DKG before it) were advancing the state of the art by allowing for no central party (or aggregator/dealer) to be in possession of the whole private key at any time, either in key generation, or in signing. Here I guess you want to reset back to the earlier SSS basic idea of having the central party know the key in advance, then construct the individual shares such that they sum to the pre-existing key x, instead of following FROST's KeyGen to generate the shares.
But the "massive caveats" I mentioned in the other post still apply; it seems unlikely you'd want to allow the possibility to collude to take your full key.
No, I don't want to reconstruct the key, I just want these providers to construct signatures, which apparently FROST can do safely -- I don't get why you can't do that with MuSig2 (wait, I guess it just doesn't work because MuSig2 has the "distributed key generation" step built in).
So I, as a user, don't have to do any cryptography or hold any keys during my daily life as a Nostr user, I can just instruct clients to fetch signatures from a server somewhere, and that server will coordinate with the 3 entities that hold my key shards to get a signature, then return the signature to the clients and, boom, I have a signed event.
Re : "No, I don't want to reconstruct the key", I don't really understand; I didn't use the word 'reconstruct' in that. "I just want these providers to construct sigs safely which apparently FROST can do". But the point that's at issue here is you want them to do that with *your* key. FROST and MuSig both allow multiple parties to collaborate to create signatures safely, with the main difference being that the former allows it for t of n and not only n of n. *Neither* provide for the key to come from some central party. As for distributed key gen, yes they both do it, they have to; but they do it in radically different mathematical ways (because of the t of n requirement for a start). And retrofitting them to allow you to start with a key "x" and then split it up and give it to them probably can work, but my caveat point is, if you care that they can collude to take the whole key, between them, then that's not great.** In FROST's case, it happens to be polynomial evaluations that you share, but it's still designed so that t of those shares (in a t of n scheme) are enough to reconstruct your signing key.
**In any such collaborative signing scheme, by definition, the key can be reconstructed by the authorised threshold t, because they can share their nonce contributions and extract the private key using the nonce. This isn't usually discussed, but here we have an external party that'd prefer not to be attacked by the group, so to speak.
Re "I didn't use the word 'reconstruct' in that".
Indeed, sorry, I misread.
For that you need 3 keys, op asked to do multisig from an existing single key.
I remember thinking "I don't know if that's possible" but also thinking "does that question make sense"? If i use some xor/whatever to make 3 shards, don't I still have the original secret key. If that doesn't matter, and you just want the others to attest, or something, then just use their own keys? I guess I just don't get your point.
Obviously both N of N and M of N collaborative control of newly generated keys is well understood (albeit a bit complicated!).
The point is that I have my own secret key that I generated, but it's annoying and unsafe to paste it in Nostr apps everywhere -- and we want people to use multiple apps for multiple tasks, all with the same identity.
So the solution is to have the NIP-46 bunker thing that keeps listening for requests to sign coming from authorized apps.
But I don't want to run such a bunker daemon, I have no idea of how to do it, it's annoying blablabla; therefore I want to delegate that task to some third-party to run this daemon for me.
But I don't want to give this third-party my key, it would be much better if I could split my key in 3 once, give 1 shard to a different provider and trust that they won't collude to recreate my key -- but then they cooperate to sign stuff on my behalf and is as if it was me who signed it.
If you want to use the service you would have to create your key from 3 keys I think. I don't think you can split the key if you started single-key.
OK yes I see. It seems difficult because a musig aggregated key is not a linear sum, to avoid the possibility that less than N can forge a full signature using key subtraction attacks. Constructing the key is an interactive process that produces an unpredictable final key, by design.
Perhaps you can attach a proof of knowledge of each "key portion" works though: you distribute secret keys x1, x2 and x3 such that x1 + x2 + x3 =x, your key. Then when they go through the signing process they add a signature over their key portion at the start. This prevents them from doing key subtraction to forge with < N parties. Then they can go through the normal process of 3 round MuSig - commit to their R portion, then reveal their R, then the final signature on P is the sum of the signatures on P1, P2, P3. Two obvious problems stand out: they can collude to extract your full key; usually that is not acceptable. And of course the fact that signing becomes interactive.
Overall it doesn't seem very practical, and heck, don't even quote me that it's possible or sound, I'm not sure. Even with the massive caveats above. Various kinds of delegation or setup with the initial key, whether using existing FROST or MuSig, feel like they make for a sounder approach.
I think we could make it so the possibility of these entities colluding is small and then tradeoff is reasonable for most people (but not for all, of course) -- the alternative of trusting a single provider to hold absolute power over your entire identity, like x.com, is far worse.
I don't get what you mean by "various kinds of delegation or setup with the initial key". What do you have in mind there?
About initial setup/delegation, my thinking is: a protocol could allow you to delegate authority to do specific things (like sign) by a direct signature on your main key saying "this sub-key is authorised to sign these events" and then that subkey could be generated collaboratively in a normal way. Common way of using digital signatures (delegation to another key), but admittedly it can be a can of worms...
A bunch of proposals for variants of doing that stuff have been (and continnue to be) suggested. I don't know what is the best way (they all look flawed to me given that there is no single source of truth for what is the latest update on the subkeys of each person) -- but even with all that decided and solved I think it's a bad idea because it would add so much complexity to clients and/or relays that Nostr would essentially cease to work or instantly centralize around a single big entity that would become the central source of all truth and the almighty index of all events. That's why I'm considering these other ways.
Understood. I agree it's a can of worms to do it at scale. Maybe for some smaller scale projects it can be a valid choice.
Subkeys will be time boxed like X.509 certificates or GPG subkeys have done for centuries.
Nostr won't stop existing but if this upgrade flushes some of the nincompoop devs out of the community that can't handle something this simple then that's a win-win.
nostr:npub10vlhsqm4qar0g42p8g3plqyktmktd8hnprew45w638xzezgja95qapsp42's reply below is correct, FROST with trusted dealer would solve your use-case here.
Of course nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7's point is also valid: If you want true multisig security you'd need to be certain that you securely erase the distributed shares on your machine afterwards, and of course erase the original secret key (except for maybe keeping a paper backup). Still, it's a valid approach if you are OK with those assumptions.
I'm currently working on a BIP340 compatibility pull request into the ZCashFoundation's FROST implementation (Rust), I believe it should work to produce valid Nostr sigs.
https://github.com/ZcashFoundation/frost/pull/730
If you use a python stack, check out nostr:npub1tr7ndmjkguzupvqhn9clasx4r08q2sklhal4g60844nsnnalw0tqpwnc05's FROST implementation here
https://github.com/jesseposner/FROST-BIP340
nostr:npub160t5zfxalddaccdc7xx30sentwa5lrr3rq4rtm38x99ynf8t0vwsvzyjc9 linked to my FROST BYOK article but that would only be practical if you wanted to create a joint key from existing (static) npubs. I don't think it's useful for splitting an existing key.
Are you saying we have proofs of concept or and now we need real products or that we need proofs of concept?
Some very talented devs on Nostr build too many proofs of concept and then abandon them for the next shiny thing instead of building them out into something truly useful and resilient.
I try to break that with hubstr.org π
Most Devs are bad in enduser UX and all are bad in doing the last 20% that a viable product needs. Just different skills π
Maybe their talent is just to make proofs-of-concept?
Maybe. It leaves users high and dry though when they move on to the next thing, and as a user I have very little desire to financially support a dev or project who builds this way. At some point βwe are earlyβ becomes just a poor excuse for letting things remain broken and half finished. But maybe for now, we are just early.
yes.
I think nsec.app and amber took a lot of wind out of these sails
perhaps it's a dumb idea giving your nsec to anyone?
i think maybe you did actually notice that there is a movement to reframe it from "private key" to "secret key" and there is a saying about secrets
"you can only keep a secret when the other person is dead"
Yes, it is a dumb idea; expecting the masses to deal with key management by themselves in the forseable future is also a dumb idea though...so, here we are
Nsec.app and local signers like Amber made custodial providers less interesting for tech savvy and diligent users that know how to self custody; but for onboarding a lot of casual newcomers, a custodial solution still seems a needed solution.
I'm reading the MuSign2 and Frost proposals, it's an interesting approach, but how do you ensure a robust infrastructure of more than 3 parties, which should be totally disconnected to demonstrate security? What incentives should these nsebunker providers have? Do they get paid? And should the user choose them randomly and pay them separately? And what happens if a payment is not made or if multiple nsecbunkers disappear at the same time breaking the quorum?
An alternative solution is to offer a single custodial nsecbunker, supported by a well-known entity (OpenSats?) and build a really clear user experience to lead the user (maybe forced after x amount of time?) to self-custody their key. Of course, this kind of structure would immediately become a centralized weakness, and thus a clear target for anyone who wants to destroy Nostr. Not to mention that it is not an absolutely easy structure to create and manage with good security standards; who would actually do it?
I don't know what would be the most effective way to proceed. I would probably try to elaborate the Frost approach, paired with a real good UI to enforce the user to keep a backup and validate it randomly every so often.
Technically you would still hold the key as a user, stored somewhere safe. You just wouldn't use it daily, as all your signing would be done by these providers in the cloud. So if they disappear you can get your key from storage and use it to create more shards. You could also distribute shards to multiple providers, like 5, and make the signature be possible with just 3 out of the 5, and so on.
I don't know about the incentives, it would be almost free for these providers to support a new user, so I'm not sure payments will be needed. I mean, Blockstream has been providing co-signing services for Green wallet users for years at zero cost, for example.
I would say we need to hurry because the bankers are starting to get their money backβ¦..
The Trusts are not funds registered under the Investment Company Act of 1940 as amended (β1940 Actβ) and are not subject to regulation under the 1940 act, unlike most exchange-traded products or ETFs. An investment in the Trusts is subject to a high degree of risk and heightened volatility. Digital assets are not suitable for an investor that cannot afford the loss of the entire investment.
And there will be losses
> Technically you would still hold the key as a user,
Good, so we align on my last sentence "paired with a real good UI to enforce the user to keep a backup".
That makes sense.