Yeah collaborative custodians today can see all of your UTXOs, transactions, balances.
And in theory they could even censor you (at gov request) or hold you to ransom in the event that you need their assistance to sign.
(btw with FROST we can run a service like unchained but completely private)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021917.html
Thanks for sharing your feelings, but the cryptographic literature has been around for over 20 years and is well established.
Adding/removing signers isn't so much to do with the FROST signing protocol, but rather the things we can do with the secret shares that FROST uses:
In terms of implementations that we engineer, yes they will require review and thorough testing, which we will achieve.
There are some structural challenges with the daisy chain being so long. There's also a power draw limit.
You can use multiple USB ports rather than just one, if it suits your situation. In the future we'll have remote app-app communication also.
FROST requires each signing party to share a nonce, and the signing parties sign under the same agreed upon set of nonces.
You can share a whole bunch of these nonces upfront, storing them on the coordinator wallet ready for use. This way, signing can still be done in a single round.
A difference with FROST however is that you need to select the subset of signers
(signer_2, signer_3, signer_5)
that will be signing, from the beginning of the signing session. If this was a big deal then you could use tricks like combinations of concurrent signing sessions.Thankfully no!
FROST and other MPC Schnorr signing protocols create
partial signatures
which are signed independently, and then combined to form a final signature.So your keys can be as separate as you like.
Thanks for the question, here are some thoughts on this topic
Since each secret share of a FROST key is a point (index, secret share) that belongs to a polynomial with some interpolation threshold. A threshold number of parties can each evaluate their share of this joint polynomial at a new participant index.
Parties securely communicate these evaluations to the new party using a repairable threshold scheme, and the new party sums them to receive their secret share. This secret share belongs to the same polynomial and key as the other parties, can sign etc.
Removing a signer involves parties recreating their secret shares and a new polynomial, only this new polynomial retains the same joint-secret (x=0) and thus the same public key.
The removed signer never loses their secret share, only they will now be incompatible with every honest signer who has moved to a new polynomial.
I actually think there is currently an overeagerness to NIPify everything. And I don't mean you, just that I have seen a bunch of NIPs for protocols that don't really have anything to do with the base layer nostr protocol. I think people are viewing writing a NIP now as writing an "early bip" flex.
Not everything that runs on Nostr needs to get it's own NIP, though it could be useful to have a second directory for these protocols
This update is live on Umbrel -- Find the app in your app-store and give it a try!
https://nolooking.chaincase.app/
Multistage allows us to get rid of all the dependencies from the
build
stage, leaving just the compiled binary in the final image. Saves on heaps of storage space, keeps our apps slim!Fortunately umbrel doesn't need multistage builds to run (only for submission), so you can test a lazy single-stage Dockerfile just fine, and then make it multistage when it's ready to submit!
t-of-n
threshold multisig. If you create a 3-of-5 you can lose up to two devices.