Node setup issues
Last updated
Last updated
The hardware requirements are listed below:
| Validator | Light Node | Full/Bridge Node | |
|---|---|---|---|
After running curl -sL1 https://nubit.sh | bash, you should see the following message:
For further check:
You will receive a response similar to the following to verify that your node is running successfully:
If you have watched this hint during the execution of nubit.sh, you are running the latest node and we'll do a hot update after this version.
For early supporters who executed nubit.sh before this version, please re-execute curl -sL1 https://nubit.sh | bash again.
Currently, the light node uses an absolute path, and generally, there's no need to manually set environment variables. Here are some environment variable values for your reference. If any of them is broken, please go to $HOME/nubit-node and fix it. Thanks for your patience!
The operation would never be reverted!
To uninstall nubit-node, please run the following command:
Please make sure to save your wallet and Nubit address mnemonic or key so you can re-import them later. For instructions on importing an existing key, please refer to Manage Keys.
A light node itself doesn't create transactions; it verifies and relays transactions created by wallets or other nodes. It's a more resource-efficient way to participate in the Bitcoin network while maintaining a level of security and decentralization.
To explore more interactions with Nubit DA such as transfer and submit blob, please get NUB first and refer to Interact with Nubit DA and Access Nubit DA Explorer.
Yes, running multiple nodes on the same IP address can cause issues. It is not recommended to do so.
Please add --rpc.skip-auth to your light node start command.
A syncing-up problem causes this error. We kindly ask you to remove the old inverted_index folder.
The commands will be:
Then:
For Windows users utilizing WSL, we apologize if this solution does not address your issue. We are currently unable to support all Windows versions. If possible, we kindly suggest switching to a Linux or Mac system. Thank you for your understanding and patience.
The upgrading from the oldest version problem causes this error. We kindly ask you to download the config.toml from our website.
The commands will be:
Then:
The upgrading from the oldest version problem causes this error. We kindly ask you to download the config.toml from our website.
The commands will be:
Then:
You need to claim some tokens from the faucet page. Please refer to Get NUB for more details.
Q: If you encounter the following error messages when executing the nubit binary on Ubuntu x86-64 (version 20.04 or earlier):
A: This issue is caused by the absence of GLIBC 2.32 / 2.34 in older versions of x86-64 Ubuntu. To resolve this issue, you can:
Switch to an OS that includes GLIBC 2.32 / 2.34, such as ARM64 Ubuntu 20.04 or x86-64 Ubuntu 22.04.
Or you can manually configure the GLIBC dependencies if you prefer to handle it yourself.
Q: What preparations are needed when using `nubit state` to query addresses and balances, or encountering a "nubit: command not found" error when interacting with Nubit DA?
A: First, ensure that the node is continuously running. Running curl -sL1 https://nubit.sh | bash will help fix this bug automatically. For more details, please refer to environment variables.
This is an affair due to user permission of your local env. Please grant enough permission to your current path, like:
This error typically occurs because another light node is already running and has locked the store.
Q: Why does the PEER ERROR appear when starting the light node?
A: Firstly, please note that this error does not affect the normal operation of your node.
The error may occur due to one of the following reasons:
Scenario 1: The peer you are trying to connect to has registered their address on the p2p network but has subsequently stopped their node. This results in an inability to establish a connection.
Scenario 2: The peer you are trying to connect to has restarted their light node after stopping it and deleting the $HOME/.nubit-light-nubit-alphatestnet-1 directory. This causes your key to change. Although your IP and port remain the same, the key change leads to authentication failure, and thus, the connection cannot be established.
We hope this clarifies the issue. If you have any further questions, please feel free to reach out to our support team.
If you encounter an error similar to the following when running your node:
This is often caused by conflicts due to multiple keys in your Nubit node. Please follow these steps to resolve the issue:
Use the following command to list your Nubit addresses:
Use the following command to delete any additional keys:
For optimal management, we recommend saving only one set of keys named my_nubit_key and avoiding the retention of multiple keys.
When you initialize your node, a set of my_nubit_key key is automatically generated for you.
We don’t support batch requests.
Yes, WS connections are supported.
First, initialize your own light/full node. Assume you have finished Run a Node (Advanced) step by step.
After the node initialization, you should export the environment variables:
The node RPC could be accessed by the websocket protocol directly.
Please refer to Nubit DA Node APIs.
The following methods could be cached / saved to database:
Blob: Get, GetAll, GetProof, Included
Header: GetBtcHeight, GetByHash, GetByHeight, GetHeightRangeAtBtcHeight, GetRangeByHeight
Share: GetEDS, GetShare, GetSharesByNamespace, SharesAvailable
Other methods are not recommended to be cached since they will change with time or be light enough to be not cached.
Use header.SyncState , this method will return the latest block height in its responded field height .
Use header.SyncWait to check whether the node is healthy or not. This method will block until the node is synced to the network's latest head.
Blob: Get, GetAll, GetProof, Included (~1s)
Header: GetHeightRangeAtBtcHeight (~2s)
Yes, the full node (archive node) is the only node that stores all data in the network.
There is no need to sync the snapshot now.
The consensus-node is a validator node that does not produce blocks. It needs to be run as a data source for the bridge. It can also produce blocks, but currently, we have not delegated tokens to these validators.
It is not necessary to provide RPC to users. The node's RPC is for internal use. Users can run their own light nodes for accessing RPC.
Bridge nodes, when exposed to the public network, can automatically provide P2P connections to light node users.
| Environment Variable | Content |
|---|---|