Closed kenrogers closed 2 weeks ago
vercel[bot]
commented
1 year ago The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated |
|---|---|---|---|---|
| stacks-docs | ✅ Ready (Inspect) | Visit Preview | 💬 Add your feedback | Mar 16, 2023 at 6:05PM (UTC) |
kenrogers
commented
1 year ago @igorsyl I have a few more questions on how the relay, coordinator, and signer work together.
donpdonp
commented
1 year ago * Is there anywhere I can look to see what all the different config options mean?
the option name and the source code are the only 'documentation' currently. toml supports comments so having the default config include comment lines would go a long way.
* How do users set what Stacks RPC endpoint they are connecting to in the signer?.... So does a signer not need to connect directly to a Stacks node? What about bitcoind?
a signer communicates with other signers through the in-development relay feature of stacks-node. currently the signer config http_relay_url points to a stand-in app to relay data to other signers. this signer config item should change to stacks_node_rpc_url.
* Does the relay URL correspond to a relay server that a signer would connect to, and does that then correspond to a specific coordinator that they would be connecting to?
currently the relay is the bridge between all signers and the coordinator. the stacks-node will take on that role in the future. the config file should reflect this now, so i'll note that as a todo.
* How does a signer find and choose a relay server to connect to?
I imagine this is the same as setting up a new stacks-node - the default config file has a seed that points to a hiro.so node.
* Coordinators do need to generate new private keys correct? Do they do that through the CLI like I outlined in the doc and add that to their toml file?
The coordinator is not currently using a local private key and the config file has no setting currently for it. This feature is not flushed out yet so it may change. There is also some confusing terminology around this key. I'll call it the communcation key as it would be used to encrypt traffic between coordinator and signers. The config file has spots for the stx address private key and the btc address private key, but I imagine the communication key will be generated and stored automatically with no config impact other than a folder to store working files in general.
* How do signers determine what configuration options to set in their toml file?
like stacks-node, the distributed config file will have sensible defaults. I expect that a signer will work with no config edits once the infrastructure is in place - the mainnet stacks nodes include all required sbtc functionality.
* Does a DKG signing round correspond to a 2 week stacking cycle where we generate a new list of public keys to act as signers?
A signing round is run any time a btc operation is needed, such as on every peg-in and peg-out operation, so its happening all the time.
* What are the minimum and recommended hardware requirements for running the signers/coordinators/relays?
this hasnt been investigated but its safe to say the requirements will be less than a stacks-node, or put another way stacks-signer and stacks-coordinator will run on anything stacks-node runs on.
xoloki
commented
1 year ago
- Does a DKG signing round correspond to a 2 week stacking cycle where we generate a new list of public keys to act as signers?
A signing round is run any time a btc operation is needed, such as on every peg-in and peg-out operation, so its happening all the time.
Each DKG round corresponds to a stacking cycle. But signing rounds happen frequently.
CLAassistant
commented
8 months ago
All committers have signed the CLA.
Description
Adding sBTC documentation to the docs website.
Additionally, editing some of the existing documentation to better reflect Stacks as an L2 with the Nakamoto release.