pull down to refresh
0 sats \ 0 replies \ @utxoclub 18 Oct \ parent \ on: What Are Your Thoughts About 'Self Zapping' Own Post On SN? meta
shhhhh 😉
seems like it's proprietary hardware
Our signature multisig setup involves daisy-chained devices for a fantastic user experience during key generation.
This dual usb-c port daisy-chaining requires custom hardware.
You can flash onto off-the-shelf esp-32 if you so desire.
It's not air gapped.
Airgapping is overrated, a good overview here:
https://bitbox.swiss/blog/does-airgap-make-bitcoin-hardware-wallets-more-secure/
Think about how interactive keygen can verifiably includes randomness from multiple devices:
- You don't need to trust that your device generates secure randomness
- You don't need to trust that your device uses that randomness
- You don't need to trust that your devices display addresses derived from that randomness
frostsnap achieves these with a simple UX.
What will happen if you lose one of those devices? RIP your coins.
Not even close, it's a
t-of-n threshold multisig.
If you create a 3-of-5 you can lose up to two devices.Each device has a backup.
So even if you lose one, just restore it from your backup.
Why waste your sats on this when you can just write the keys down on a piece of paper?
I'd love to hear your trustless setup that non-technical people can carry out securely.
(frostsnap is it)
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/