it makes UX slow and ugly for remote signing
you make a good point that opening 10 prompts at a time is also bad
there needs to be a method for the client to fetch the user's signer permissions in advance, so the client knows which requests are pre-authorized and can be done async
otherwise remote signing will suck more and more as new protocols develop and demand more background signing
The signPsbt prompt window is going to be very different from the signEvent window. Everything to know about each input and output will be displayed to the user, including the script.
The wallet (soon tm) will also have a `window.bitcoin.register_xpub` method for registering signed xpubs into an address book, which the signPsbt prompt will use to highlight addresses for simple verification.
this is covered by a) permissions, in your scenario the extension would delay the second request until the user responds to the first request
what is the rate limit on the damus relay?
"you are noting too much" how much is too much? 😭
actually I spoke to soon about nostrudel, it may be doing async requests to decrypt all, but it's still one event at a time (which is the fault of NIP-07).
there still needs to be a better way of batching signer requests, but this may require extending the NIP-07 interface
I put all this work into asynchronous batch handling of NIP-07 requests, and nostr clients just `await window.nostr.doSomething()` one request at a time.
It's actually pretty crazy that clients behave like this. This old and busted synchronous request paradigm needs to change, especially for:
* Primal, which requires signing of multiple events with each page refresh, all of them blocking.
* Nostrudel, which has a "decrypt all" button, but then decrypts events one at a time.
Does nos2x support asynchronous handling of requests? I didn't notice anything blocking, so I want to say yes (assuming you have permissions set).
If a client makes requests to a signing device, and those requests have a) permissions and b) no dependencies, then they shouldn't block other requests. Let the requests flow freely!
me going through the jira backlog
get the game streaming sats in real time. This is one of the coolest, funnest, and nerdiest things I've ever done. Will have a working demo this week.
Also, orphaned shares can't sign for anything. In fact, no single share can sign for anything. They can only contribute a part of the signature. You need a qurom of shares to participate in order to create a full signature. If you orphan a compromised share by deleting your other shares, then that orphan share is worthless.
window.nostr.getPublicKey() outputs your npub. Frostr doesn't change that.
Frostr works with your existing nsec and outputs your existing npub.
Frostr allows you to put your nsec into cold storage, and use it to generate new sets of shares offline. It doesn't change your nsec/npub.
Frostr simply splits your nsec into many shares, so that one device does not hold your entire npub, only a part of it.
BIP32 works with frostr (technically not yet, have to fix a bug first), so you can derive child keys from your nsec, and frostr can sign with those child keys.
BIP32 is not utilized by nostr AFAIK, so child npubs will not be recognized as an extension of your main npub. However if nostr protocol decides to implement BIP32 (or any key derivation scheme really), then frostr will work with it.
Using your nsec with frostr also does not lock you into using frostr. It doesn't do anything strange or proprietary to the final signature, so your bare nsec/pub will validate signatures made with frostr.
From a cryptography perspective, you cannot tell the difference between a signature from frostr, or from your bare nsec. They are the same signature.
I hope this helps.
not official until you show up for some bbq 🙅
honestly I didn't know of an ECDH solution until fairly recently. I stole it from Jesse Posner, full credit to him:
Once you construct the shared secret, you can plug that into any cipher scheme like normal. Frost2x already handles nip04 and nip44 encryption.
frost2x has NIP-44 integrated. Bifrost nodes construct the shared secret, then pass it into NIP-44 methods (from nostr-tools) for encryption and decryption. NIP-17 should be doable on top of that.
It is not well known, but you can perform a collaborative ECDH with the key shares. I have an example in the @cmdcode/frost library.
Just upgraded bifrost to perform single-round batch signing of messages, similar to how bitescrow worked with building covenants.
Batching signatures allows for very fast and robust signing of PSBTs and multi-transaction packages, which will hopefully unlock many kinds of bitcoin protocols over frost and nostr.
The frost2x wallet is almost complete:
```
window.bitcoin = {
getAccount() // done,
getBalance() // done,
getUtxos(amount) // done,
signPsbt(psbt, manifest) // in progress
}
```
Very exciting times ahead!
gm nostr
today is a great day to build a wallet
- Do I need to pick a coordinator among the 3 signers?
No, the node requesting the signature is the coordinator.
- What do I need to transfer from the offline nsec holder application to each of the app?
there are two encoded strings that you copy/paste: the group string and the share string. You do not need to transfer the nsec.
You can run igloo offline and air-gapped as a key manager, and another copy of igloo as a desktop signing node.
We have plans for a mobile app that will run as a remote signer using NIP-46. TBD.
frostr pretty much works this way by default, since the group key is the "user key", and all device keys have proofs that they are members of the group
