BTCD SIMNET (AG Interface, BBIN Interface, MG Interface Simulation Environment) Single Node and Dual Node Run

In this article, I will introduce the AG interface, BBIN interface, and MG interface. Interested parties can add QQ2952777280 btcd startup and operation methods in the simnet simulation environment, including the use of wallets and the use of btcctl interactive rpc commands. Finally, I will briefly introduce the connection of multiple nodes in the simnet environment.

Background

Here I briefly introduce the four operating modes of btcd, including Mainnet, Regression, Testnet and Simnet.
First, give the parameter settings in the source code. Code

Mainnet is the Bitcoin mainnet. If you connect to this network, you can play Bitcoin in a straightforward manner. You may need to synchronize the mainnet blocks, maintain the blockchain information, and then mine on the mainnet. Mine and so on. We only do tests and experiments, so we do not choose to connect to the mainnet.
Testnet is a public testnet, all developers can access this network. In order to avoid someone maliciously hoarding the above Testnet bitcoin, this testnet will be emptied every certain period and restarted with a new founding block. Any software development intended for production on the Bitcoin backbone network should first be tested with test coins on the testnet. This can protect developers from money loss due to software errors, and also protect the network from accidental attacks due to software errors.
Regression stands for “regression testing” and allows users to create local blockchains for testing. Unlike testnet3, which is a public and shared test blockchain, the Regressiont blockchain is designed to operate as a closed system for local testing. The user starts the regtest blockchain from scratch to create a local genesis block. You can add other nodes to the network, or use a single node to run it to test the Bitcoin Core software
As for Simnet, it is also a network for local testing. In the source code, its configuration parameters and Regression are still different, such as ports Number, and some fork parameters, I didn’t dig into the details. You can go to the source code to see if different parameters affect your needs.

I put the details of Regression and Simnet configuration below for comparison

var RegressionNetParams = Params{
Name: “regtest”,
Net: wire.TestNet,
DefaultPort: “18444”,
DNSSeeds: []DNSSeed{},

// Chain parameters
GenesisBlock: &regTestGenesisBlock,
GenesisHash: &regTestGenesisHash,
PowLimit: regressionPowLimit,
PowLimitBits: 0x207fffff,
CoinbaseMaturity: 100,
BIP0034Height: 100000000, // Not active-Permit ver 1 blocks
BIP0065Height: 1351, // Used by regression tests
BIP0066Height: 1251, // Used by regression tests
SubsidyReductionInterval: 150,
TargetTimespan: time.Hour * 24 * 14, // 14 days
TargetTimePerBlock: time.Minute * 10, // 10 minutes
RetargetAdjustmentFactor: 4, // 25% less, 400% more
ReduceMinDifficulty: true,
MinDiffReductionTime: time.Minute * 20, // TargetTimePerBlock * 2
GenerateSupported: true,

// Checkpoints ordered from oldest to newest.
Checkpoints: nil,

// Consensus rule change deployments. //
// The miner confirmation window is defined as:
// target proof of work timespan / target proof of work spacing
RuleChangeActivationThreshold: 108, // 75% of MinerConfirmationWindow
MinerConfirmationWindow : 144,
Deployments: [DefinedDeployments]ConsensusDeployment{
DeploymentTestDummy: {
BitNumber: 28,
StartTime: 0, // Always available for vote
ExpireTime: math.MaxInt64, // Never expires
},
DeploymentCSV: {
BitNumber: 0,
StartTime: 0, // Always available for vote
ExpireTime: math.MaxInt64, // Never expires
} ,
DeploymentSegwit: {
BitNumber: 1,
StartTime: 0, // Always available for vote
ExpireTime: math.MaxInt64, // Never expires.
},
} ,

// Mempool parameters
RelayNonStdTxs: true,

// Human-readable part for Bech32 encoded segwit addresses, as defined in
// BIP 173.< br> Bech32HRPSegwit: “bcrt”, // always bcrt for reg test net

// Address encoding magics
PubKeyHashAdd rID: 0x6f, // starts with m or n
ScriptHashAddrID: 0xc4, // starts with 2
PrivateKeyID: 0xef, // starts with 9 (uncompressed) or c (compressed)

// BIP32 hierarchical deterministic extended key magics
HDPrivateKeyID: [4]byte{0x04, 0x35, 0x83, 0x94}, // starts with tprv
HDPublicKeyID: [4]byte{0x04, 0x35, 0x87, 0xcf} , // starts with tpub

// BIP44 coin type used in the hierarchical deterministic path for
// address generation.
HDCoinType: 1,
}

var SimNetParams = Params{
Name: “simnet”,
Net: wire.SimNet,
DefaultPort: “18555”,
DNSSeeds: []DNSSeed{}, // NOTE: There must NOT be any seeds.

// Chain parameters
GenesisBlock: &simNetGenesisBlock,
GenesisHash: &simNetGenesisHash,
PowLimit: simNetPowLimit,
PowLimitBits: 0x207fffff,
BIP0034Height: 0 , // Always active on simnet
BIP0065Height: 0, // Always active on simnet
BIP0066Height: 0, // Always active on simnet
CoinbaseMaturity: 100,
Subs idyReductionInterval: 210000,
TargetTimespan: time.Hour * 24 * 14, // 14 days
TargetTimePerBlock: time.Minute * 10, // 10 minutes
RetargetAdjustmentFactor: 4, // 25% less, 400 % more
ReduceMinDifficulty: true,
MinDiffReductionTime: time.Minute * 20, // TargetTimePerBlock * 2
GenerateSupported: true,

// Checkpoints ordered from oldest to newest.
Checkpoints: nil,

// Consensus rule change deployments.
//
// The miner confirmation window is defined as:
// target proof of work timespan / target proof of work spacing
RuleChangeActivationThreshold: 75, // 75% of MinerConfirmationWindow
MinerConfirmationWindow: 100,
Deployments: [DefinedDeployments]ConsensusDeployment{
DeploymentTestDummy: {
BitNumber: 28,
StartTime : 0, // Always available for vote
ExpireTime: math.MaxInt64, // Never expires
},
DeploymentCSV: {
BitNumber: 0,
StartTime: 0, // Always available for vote
ExpireTime: math.MaxInt6 4, // Never expires
},
DeploymentSegwit: {
BitNumber: 1,
StartTime: 0, // Always available for vote
ExpireTime: math.MaxInt64, // Never expires .
},
},

// Mempool parameters
RelayNonStdTxs: true,

// Human-readable part for Bech32 encoded segwit addresses, as defined in
// BIP 173.
Bech32HRPSegwit: “sb”, // always sb for sim net

// Address encoding magics
PubKeyHashAddrID: 0x3f, // starts with S< br> ScriptHashAddrID: 0x7b, // starts with s
PrivateKeyID: 0x64, // starts with 4 (uncompressed) or F (compressed)
WitnessPubKeyHashAddrID: 0x19, // starts with Gg
WitnessScriptHashAddrID: 0x28, // starts with ?

// BIP32 hierarchical deterministic extended key magics
HDPrivateKeyID: [4]byte{0x04, 0x20, 0xb9, 0x00}, // starts with sprv
HDPublicKeyID: [ 4]byte{0x04, 0x20, 0xbd, 0x3a}, // starts with spub

// BIP44 coin type used in the hierarchical deterministic path for
// address generation.< br> HDCoinType: 115, // ASCII for s
}

Run Bitcoin client

Generate wallet

First of all, one is also needed in the simulation environment For wallets, there can be multiple local accounts in the wallet, and one account can also have multiple addresses

btcwallet –simnet –create

Create a wallet in simnet mode< /p>

The operation is as follows:

A private passphrase is required. This passphrase must be remembered, and it will be used when unlocking the wallet later.
I will ask you if you need an additional layer of encryption Or if there is a local wallet seed that can be loaded, we don’t need to specify this when we start it for the first time

After the wallet is generated, there are logs and simnnet folders under the ~/.btcwallet folder

Enable the btcd service and btcwallet

After the wallet is generated, even if all the preparations are completed, let’s start the btcd service
btcd –simnet –rpcuser=rpcuser –rpcpass= rpcpass –rpclisten=0.0.0.0:18556 –listen=0.0.0.0:18555

The command is explained as follows:

simnet specifies the simulation environment (note that the commands following this parameter are all To add, it will be connected to the main network by default)
rpcuser specifies a user name for btcd
rpcpass specifies the password for the btcd user name
rpclisten specifies the rpc monitoring server (that is, the monitoring server we will interact with with btcctl later) )
listen specifies the btcd listening server (other nodes connect through this server)
Then we need to open another window, the above btcd command lets it run in the original window
Run command
btcwallet –simnet –username=rpcuser –password=rpcpass

The command is explained as follows:

username This username must be the same as the rpcuser specified when btcd is turned on, otherwise it cannot be authenticated.< br>password In the same way, the password must be the same as the rpcpass above.
The operation of the above two steps is as follows

The above is the operation window of btcwallet, and the following is the operation window of btcd mouth.
Because I added some output when debugging the code, some output in the window below may be different from yours.
You can see that when btcwallet is opened, btcd will display New websocket client 127.0.0.1:50754. This is the socket access of the wallet client

Use btcctl to operate the local blockchain

After btcd and btcwallet are started here, the service will be started. Next, we need to open another window and use the btcctl command to operate the blockchain. Note that the windows of btcd and btcwallet are not closed. Therefore, a total of three windows need to be opened for complete operation. btcd and btcwallet generally do not need to be moved, we can interact in the btcctl window.
I will take a screenshot here. I will not take a screenshot when I explain the commands later.

The next operations are some common operations. I will write a blog later. Briefly describe the commonly used commands of btcctl

View local accounts

btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet listaccounts

The command is explained as follows:

simnet also needs to specify the simulation environment
rpcuser needs to be the same as the rpcuser opened by btcd
rpcpass needs to be the same as the rpcpass opened by btcd
–wallet btcctl command There are two categories, one is related to wallets, and the other is not. In the next blog, I will introduce these commands in detail.
listacoounts lists all users under the current wallet and their balance balance
default There are only two accounts, default and imported.

Create an account

In order to make the transfer function easier to observe later, we create an account

Before creating an account, you need Unlock the wallet first. The walletpassphrase is the passphrase entered when the wallet was created earlier. I am here “hht”
btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet walletpassphrase “hht” 600

The unlock command is followed by a number, which means how long to unlock, The unit is second, 600s is unlocked for ten minutes
After the unlock command is entered, you can see the message “The wallet has been temporarily unlocked” on the btcwallet interface

After unlocking, you can create an account.
btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet createnewaccount kingsley

Here, create an account kingsley through createnewaccount.

After running this command on my server, the btcctl interface will freeze. I was stuck here for a long time, looking for a solution. However, I later discovered by accident that I only need to close the wallet ctrl+c (btcctl was also stopped), and then restart the wallet, and I found that the kingsley account has been created.
Maybe you will not encounter the same problem as me, because I have searched the Internet for a long time and have not found a solution for this problem. Maybe it is a bug in the wallet. If you know the reason, you are welcome to leave your opinion in the comments, thank you.

At this time, you can see that there are three users in listaccounts: default, imported, kingsley

Allocating addresses to users

It is not enough to have accounts in the wallet. Transfers between bitcoins are based on addresses, so we must assign an address to the account if we want to use the follow-up function. The account can have multiple addresses.

Now, we use the getaddressesbyaccount command to see the addresses under default and kingsley
btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet getaddressesbyaccount default

Yes Seeing that the default account and kingsley account do not have addresses, then generate addresses for them

Use the getnewaddress command to assign an address to default
btcctl –simnet –rpcuser=rpcuser –rpcpass= rpcpass –wallet getnewaddress default

Same as creating an account, after running this command on my server, the btcctl interface will freeze. The solution is the same, just close the wallet ctrl+c (btcctl is also stopped), and then restart the wallet.

Use the getnewaddress command to assign an address to kingsley
btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet getnewaddress kingsley

Use the getaddressesbyaccount command to see the default and The address under kingsley

The above-4: the client has been shutdown is the echo of btcctl after I killed btcwallet. You can see that default and kingsley have assigned addresses

Start mining to generate blocks

Now we have created two accounts locally, and each account has an address. We can do some operations related to the blockchain.
Now there is only one genesis block on the blockchain that is initialized when btcd is started. Let’s manually generate some blocks.

Before mining, you need to restart btcd and assign a miner address to btcd, so that block rewards mined later will be given to the account of this address

restart btcd, Specify the miner’s address, arbitrarily specify, I will use the above default address SX5uJ3YGgYBQ7iCkjWmZ4hGvsTuE7PvJgk
btcd –simnet –rpcuser=rpcuser –rpcpass=rpcpass –rpclisten=0.0.0.0:18556 –listen=0.0.0.0: 18555 –miningaddr=SX5uJ3YGgYBQ7iCkjWmZ4hGvsTuE7PvJgk –txindex

The command is explained as follows

miningaddr is the address of the specified miner, which is the account to which the reward will be given to this btcd client after mining
txindex is the parameter that needs to be specified later in order to use getrawtranscation to query transaction parameters. You can also choose not to specify here.
Reopen btcwallet
btcwallet –simnet –username=rpcuser –password=rpcpass

Generate the block manually through the generate command
btcctl –simnet –rpcuser=rpcuser- -rpcpass=rpcpass generate 300

This command can manually generate 300 blocks in the blockchain. Since there is no transaction data in the entire network, there is only one coinbase transaction in these generated blocks.
After the command is executed successfully, you can see that the three windows of btcd, btcwallet and btcctl have echoes, indicating that the block has been generated.
At this time, use the listaccounts command to see that the reward for the block just mined Enter the miner’s address

Note here, if the generated block amount is small, there may be no money in the miner’s account. This is probably similar to the existence of Ethereum gas. I haven’t studied the specific reasons. If you have any friends who know, please leave a message for exchange.

One more point here, about this generate manual block generation. Some people will ask him why he can not automatically mine.
This is possible, but there is a constraint in the source code. Another node must be connected to the btcd client to perform automatic mining. If you want to automatically mine, you must change the source code config. Change the defaultGenerate parameter in .go from the default false to true. In this way, when another node connects in, it will automatically perform mining. In the same way, in our test network, there is no transaction data for the time being. Whether it is a manually mined block or an automatically mined block, there are only coinbase transactions.
And, when the defaultGenerate parameter is changed to true

When opening btcd, you must specify the mining address, which is unrealistic when the test environment is just started, because there is not yet on the chain A legal address. Of course, it is also possible to specify a legal address in a format.
You can no longer use the generate function to manually generate a block. You must btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet setgenerate 0.
Transfers

Our default account now has a lot of bitcoins, we can try to transfer. The sendtoaddress command is used here. This command is transferred from the default account by default. There are also commands to transfer from a specified account to a specified account, but I haven’t used it much

The account must be unlocked before transferring.
btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass- -wallet walletpassphrase “hht” 600

Transfer 100 bitcoins from the default account to the kingsley account
btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass –wallet sendtoaddress SYaDYKqmywEGNUvVtCdnCdD2GpvSAWYBmn 100

There may be an error -32603: insufficient funds available to construct transaction
The reason is that there are not enough funds. If we encounter this problem, we can generate more blocks and get more money.

You can see that the hash of this transaction will be displayed after the transfer is successful.

Now we cannot see that Kingsley received the money in listaccounts, because although this transaction has been verified, it has not been written into the blockchain, so we need to manually generate a block to transfer this command Include in the blockchain

btcctl –simnet –rpcuser=rpcuser –rpcpass=rpcpass generate 1

When a new block is generated, the transaction just now After writing to the blockchain, this is listaccounts and you can see that there are already 100 bitcoins just transferred under the Kingsley account.

Other nodes connect to the local

The above description is the environment where there is only one btcd client and one btcwallet client locally, called machine A. In the simnet environment, any number of nodes can be connected to form a p2p network.
At the end of this article, I will briefly introduce how other nodes connect to the test network.

We start another server, called machine B, and configure the same btcd and btcwallet software as A.

The machine A is started according to the above method, no change is required.

If machine B wants to access the network where machine A is located, do as follows

Start the btcd client
btcd –simnet -u rpcuser -P rpcpass –rpclisten= 0.0.0.0:18556 –listen=0.0.0.0:18555 –simnet –connect=XXXX –miningaddr=XXXXXX
You can see that it is the same as before starting the Btcd command, you only need to add one more connect parameter and specify the A machine The IP address is just fine. This miningaddr is also the address of the miner after the successful mining of machine B. It is also possible to specify a default address of machine A. Then, if B digs out the money, give it to defaulta in A.
I should explain this very clearly.

Start the btcwallet client
This is exactly the same as machine A, because btcwallet operates a local wallet account. So it’s good to start normally.

When machine B is added, you can see that a new node is added in the btcd window of machine A, so that the two nodes are connected together. A cross-machine transfer can also be performed normally. Through this method, countless nodes can be connected. The method is similar, so I won’t repeat it here

Leave a Comment

Your email address will not be published.