Stacks Bootstrap Nodes - are there options?

According to documentation present here: Running a mainnet node | Stacks Docs, there are 3 bootstrap nodes.

02d[email protected]seed-0.mainnet.stacks.co:20444
02a[email protected]seed-1.mainnet.stacks.co:20444
036[email protected]seed-2.mainnet.stacks.co:20444

Is there anything special about these bootstrap nodes? Or can any Stacks Blockchain node act as a bootstrap node?

Also, what does “02da7a464ac770ae8337a343670778b93410f2f3fef6bea98dd1c3e9224459d36b” represent for the first bootstrap node? How do I get this value for my own node ?

Hello there!

There is nothing special about the 3 bootstrap nodes provided in the documentation, except perhaps that they are publicly available for free.

The hex value 02da… in [email protected]:20444 is the peer public key of the bootstrap node. The peer public key is derived from the local_peer_seed of the bootstrap node which is by default 0.

You can use your own node as a seed node to bootstrap other nodes. In your seed node config file, set the local_peer_seed to a private key. Then in the node you wish to initialize set the bootstrap node config file option to the seed node public key and host name.

You can use blockstack-cli to generate a key pair (source). Here secretKey is the private key and publicKey is the public key.

cargo run --bin blockstack-cli generate-sk

# Output
# {
#  secretKey: "b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001",
#  publicKey: "02781d2d3a545afdb7f6013a8241b9e400475397516a0d0f76863c6742210539b5",
#  stacksAddress: "ST2ZRX0K27GW0SP3GJCEMHD95TQGJMKB7G9Y0X1MH"
# }

Keep in mind that:

  • your seed node must be up to date and synchronized.

  • the seed node need not be a mining node.

  • the local_peer_seed option, which is used for p2p network, is different from the seed option, which is used for mining. Perhaps the option seed should be renamed to mining_seed to avoid confusion.

Thanks! Is there a recommended way or perhaps an example of how to create the public key / private key pair.

Would the following work for instance:
ssh-keygen -t ecdsa -b 521

This may work but the keys may be in a different format. I updated my reply above with instructions. Let me know if you have issues as I haven’t tested this.

Thanks. I was able to run that and generate the key pair. One more question is, if I have a running node that is fully synced, can I stop it and restart it with the local_peer_seed specified or would you recommend starting from scratch ?

You should be able to update the config and restart the node without issues. You can make a backup of the working directory in case you run into issues and need to revert.

You may consider making your new seed node publicly available to improve the bootstrapping decentralization.

1 Like

I have restarted my node with the local_peer_seed option. But the /v2/info endpoint returns results that are a bit different from the seed nodes from the docs.

http://seed-0.mainnet.stacks.co:20443/v2/info returns:

{
"peer_version": 402653189,
"pox_consensus": "e9d035f270b39b9f1aefe6311bc9488dba7478ce",
"burn_block_height": 748345,
"stable_pox_consensus": "4926f8989ba9ed10f132431056168c1aaa339ebb",
"stable_burn_block_height": 748338,
"server_version": "stacks-node 2.05.0.2.2-rc1 (feat/unwrap-to-error:db3c7a2+, release build, linux [x86_64])",
"network_id": 1,
"parent_network_id": 3652501241,
"stacks_tip_height": 70670,
"stacks_tip": "42210d3d374763691e0e5b90fff1489cd7e9550325429c16e59588ab2c512ae8",
"stacks_tip_consensus_hash": "e9d035f270b39b9f1aefe6311bc9488dba7478ce",
"genesis_chainstate_hash": "74237aa39aa50a83de11a4f53e9d3bb7d43461d1de9873f402e5453ae60bc59b",
"unanchored_tip": "d405c0f5d1374dfc1d0558f078d6fb07fad6c697ff47a84cf9b16d12e89e2545",
"unanchored_seq": 0,
"exit_at_block_height": null,
"node_public_key": "0291949a58fe5f331f272fed3830f7b45e7e23157e933f1e109e96b6fb7489085d",
"node_public_key_hash": "e9af2766ab040b9eca56730876e12d280192f187"
}

But my node produces the following:

{
"peer_version": 402653189,
"pox_consensus": "e9d035f270b39b9f1aefe6311bc9488dba7478ce",
"burn_block_height": 748345,
"stable_pox_consensus": "4926f8989ba9ed10f132431056168c1aaa339ebb",
"stable_burn_block_height": 748338,
"server_version": "stacks-node 2.05.0.1.0 (master:de541f9, release build, linux [x86_64])",
"network_id": 1,
"parent_network_id": 3652501241,
"stacks_tip_height": 70670,
"stacks_tip": "42210d3d374763691e0e5b90fff1489cd7e9550325429c16e59588ab2c512ae8",
"stacks_tip_consensus_hash": "e9d035f270b39b9f1aefe6311bc9488dba7478ce",
"genesis_chainstate_hash": "74237aa39aa50a83de11a4f53e9d3bb7d43461d1de9873f402e5453ae60bc59b",
"unanchored_tip": "d405c0f5d1374dfc1d0558f078d6fb07fad6c697ff47a84cf9b16d12e89e2545",
"unanchored_seq": 0,
"exit_at_block_height": null
}

Any thoughts on the 2 missing attributes node_public_key & node_public_key_hash in my node and whether it is related to the local_peer_seed configuration.

Would you share your config file? Make sure to remove remove any keys.

I have now 2 seed nodes running and starting a 3rd node that is pointing to only my own 2 seed nodes and bitcoin full node and sync is working fine.

Crossing my fingers that the full sync can happen much faster than 5 days with this current set up.

Thanks for your help. Will make your initial response as the solution @igorsyl !!

This is great news! Keep in mind that if you control both the seed node and new node, you can duplicate the seed node’s working directory and use it to bootstrap the new node.

Yes. That indeed makes sense.

I am starting a new venture - https://burnchain.io to provide Stacks infrastructure as a service.

For individuals and teams to have their own nodes (especially API nodes) it seems to me they need to have their own blockchain node that syncs from the very beginning and forwards data block by block to their own API node. Is this not the case?

Also, generally the trust assumptions I reckon are quite different with me providing a copy of my working directory vs. providing a seed node in close network proximity (Same VPC or peered VPC or PrivateLink etc.,) to allow for faster sync times.