(WIP) Ceremony #11
(WIP) Ceremony #11
Conversation
This file is created to begin the discussion of precisely what steps are needed in the re-vault ceremony.
|
|
||
| ## Objectives | ||
|
|
||
| Prior to the ceremony, it is assumed that the architectural configuration has been specified, the devices and machines have been aquired and the appropriate software has been installed (including blockchain download for all full nodes). |
There was a problem hiding this comment.
and the appropriate software has been installed
What precisely need to be installed prior to the ceremony ? On the top of my head i'd say that since they will have to configure xpubs and onions, they'll need a Revault wallet. So they'll need a synced bitcoind (i'm assuming this but since they don't need no balance nor transaction i'm not even sure it's required).
There was a problem hiding this comment.
I suppose it should be specified according to the role of the machine.
Sync Server: sync server app, tor
Co-signers: bitcoind (fully synced), co-signer app, tor
Watchtowers: bitcoind (fully synced), watchtower app, tor
Manager PC: bitcoind (fully synced), revault wallet
Non-manager PC: bitcoind (fully synced), revault wallet
Hardware Security Module: wallet functionality (including PSBT, and secure PST storage)
What is missing?
There was a problem hiding this comment.
tor for the wallets too, otherwise looks good.
|
|
||
| Prior to the ceremony, it is assumed that the architectural configuration has been specified, the devices and machines have been aquired and the appropriate software has been installed (including blockchain download for all full nodes). | ||
|
|
||
| 1. Each non-manager gets the hidden service details (.onion) for the set of co-signing servers that are each operated by a manager. |
There was a problem hiding this comment.
This is the other way around 😅
There was a problem hiding this comment.
I thought: managers generate .onion details prior to ceremony. During the ceremony these are shared with non-managers?
There was a problem hiding this comment.
Yeah, that's what i said:
| 1. Each non-manager gets the hidden service details (.onion) for the set of co-signing servers that are each operated by a manager. | |
| 1. Each manager gets the hidden service details (.onion) for the set of co-signing servers that are operated by each non-manager. |
There was a problem hiding this comment.
I think I didn't state it clearly but I think we agree. Just to clarify:
Managers generate .onion details when they set up the co-signing server. They will manage this machine and restrict physical access to it. During the ceremony the .onion address is shared with non-managers. Non-managers communicate with the co-signing servers but don't know where they are and cannot physically access them.
|
|
||
| 1. Each non-manager gets the hidden service details (.onion) for the set of co-signing servers that are each operated by a manager. | ||
|
|
||
| 2. Participants generate master (public, private) key pairs for their wallets. These must be backed up for disaster recovery processes. |
There was a problem hiding this comment.
Hmm one could argue that the backup need to be done prior to exchanging the keys.. This makes me wonder if we won't end up with both a private and shared ceremony.
There was a problem hiding this comment.
Yes, each participant will need to set up their infrastructure before the ceremony, and we should specify that clearly. Both ceremonies are 'private' so maybe individual and group ceremony?
There was a problem hiding this comment.
That's the words I was looking for !
| 1. Each non-manager gets the hidden service details (.onion) for the set of co-signing servers that are each operated by a manager. | ||
|
|
||
| 2. Participants generate master (public, private) key pairs for their wallets. These must be backed up for disaster recovery processes. | ||
| > Securing back-ups will likely occur outside of the ceremony since each participant will do this independently. (Unless a variant of social recovery is employed among participants (as with [tatoshi wallet](https://tatoshi.io/)). |
There was a problem hiding this comment.
Yeah, but I think it's outside the scope of this doc
There was a problem hiding this comment.
To be more precise: I think we shoudl document what should be done, not how it should be done.
| > Securing back-ups will likely occur outside of the ceremony since each participant will do this independently. (Unless a variant of social recovery is employed among participants (as with [tatoshi wallet](https://tatoshi.io/)). | ||
| 3. Participants exchange master public keys. | ||
|
|
||
| 4. Participants generate (public, private) key pairs for (authenticated and encrypted) communication for distributed signing processes, as defined by BOLT8. |
There was a problem hiding this comment.
How do they exchange them ? If 256 bits keys i hardly imagine all of them being able to copy 64 hex characters N*(N-1) times without any error.
There was a problem hiding this comment.
We need to figure out where they are generated and stored. But I agree, some out-of-band communication like QR code could work.
First draft of the specification for the ceremony.