bitcoind – How to mine the Genesis block at the bitcoin fork?

I forked bitcoin (0.17 version), changed the ports, generated the Genesis block and hardcoded it chainparams.cpp.
Then i tried to create new blocks in regtest mode and i succeeded.
Now i have switched to mainnet. But i don’t understand how to start mining.

  1. for mining, do I need to connect a second identical node to the first node?
  2. is there any way to do mining this from the console?

Now i am trying this: altcoin-cli generate 10 999999999, it has been working for a long time, but i doubt its success
When i write: altcoin-cli generate 10 in debug log i see:
CreateNewBlock(): block weight: 900 txs: 0 fees: 0 sigops 400

history – What is the longest blockchain fork that has been orphaned to date?

Short answer: 4 (Prior to the March 12, 2013 fork)

The Value Overflow incident seems to be the longest ever blockchain split. The problem with blockchain forks is that once they are resolved the only trace they leave is a log entry.

To reconstruct the following I used the printblocktree output that theymos gave me in this question and the information from

As far as I can see from the printblocktree there have been 90 blockchain forks observed by theymos in the blockchainrange (90392-189512).
This dataset has the following forks:

  • 1x block length 4 (starting from block 174161)
  • 1x block length 3 (starting from block 174120)
  • 4x block length 2 (starting from blocks 93669, 174233, 179217 and 179639)
  • 87x block length 1 (starting from blocks 90392, 90676, 90858, 91405, 92094, 93047, 93088, 93619, 93642, 93669, 93670, 93671, 93855, 94671, 98529, 99365, 100740, 101902, 102674, 105401, 109912, 117103, 118553, 120406, 123583, 128501, 130077, 130200, 155180, 157929, 161673, 162257, 163959, 165439, 165519, 166890, 167283, 167620, 167742, 167863, 168920, 169517, 171064, 173494, 174102, 174104, 174121, 174174, 174182, 174185, 174187, 174232, 174242, 174291, 174307, 174313, 174330, 174343, 174414, 174452, 174531, 174593, 174605, 175998, 176210, 176478, 177854, 178119, 178293, 179791, 179890, 180143, 181230, 181591, 181618, 182210, 182321, 183193, 183405, 183500, 183519, 184932, 186561, 187866, 188347, 188682 and 189512) does have quite a few more orphans in their database, apparently because they connect to a lot more nodes, but their history does not go back as far as theymos’ printblocktree.
The first blockchain fork that observed was based on block 142257 since then we observed 540 forks:

  • 2x block length 4 (starting from blocks 174161 and 173927)
  • 4x block length 3 (starting from blocks 174120, 174056, 174050 and 173956)
  • 14x block length 2 (starting from blocks 183873, 179639, 179217, 176924, 175847, 175226, 174233, 174093, 173988, 173985, 173691, 170059, 165518 and 155180)
  • 520x block length 1 (far too many to put them here…)

The problem is quite evident: while both see forks, theymos’ set has a smaller view of the network and misses or misinterprets forks (the one starting from 155180 is marked as a length 1 fork in the first results and as a length 2 in the second). We cannot be sure that catches all of the forks but we can be pretty certain that there was no fork longer than 4, as the fork would survive longer and would be seen by more nodes.

terminal – bash fork retry no child processes cpanel

sorry for my English language

i working on a node.js app test project on cpanel

i used cpanel terminal and i used nodemon index.js command then i got this message error:

jailshell: fork: retry: No child processes
jailshell: fork: retry: No child processes
jailshell: fork: retry: No child processes
jailshell: fork: retry: No child processes
jailshell: fork: retry: No child processes

how can stop this error?

chain reorganization – How often does temporary fork occur and how long does it last?

Blockchain forks occur when there are two blocks found at the same height. Only one of the two chaintips can become part of the best chain. A node will consider the first block it saw to be the valid block for that height, until another chaintip accumulates a greater total difficulty. When another chaintip pulls ahead, the node will reorganize to the best chain by reverting its current chaintip back to the last shared block and then applying the blocks from the best chain. This means that a blockchain fork is usually resolve whenever the block for the next height is found. The “best chain” is always a probabilistic determination, but the confidence quickly rises as more blocks get added. Nothing forbids a miner to continue mining on a stale chaintip. However, a miner is disincentivizes to do so, as they cannot expect to spend the block reward if the block never becomes part of the best chain. A miner with a large portion of the hashrate may try to extend a stale chaintip if they found the stale block in a selfish-mining attack.

Earlier in Bitcoin’s history there were some two dozen cases in which these competing chaintips found more than one block before they reconciled. You can read more about that in What is the longest blockchain fork that has been orphaned to date?. As far as I’m aware, we have not had a multi-block reorganization for multiple years.

If you have access to a Bitcoin client that has been running for a long time, you can get all stale blocks it saw by calling getchaintips. Obviously, your node might not have seen all stale blocks that have occurred. Any node syncing later, will only download the best chain, and not acquire these stale chaintips.

Headers-first sync introduced with Bitcoin Core 0.10.0 significantly reduced that. In 2016 the Fast Internet Bitcoin Relay Engine (fibre) replaced a previous effort (the “Bitcoin Relay Network”) to provide a supplementary relay network connecting especially mining entities that directly pushed new blocks to other participants.
The rate of stale blocks further dropped around the time that segwit got activated. Some people surmised back then that some miners had been running old versions of Bitcoin Core, and when segwit activation forced them to update to a segwit-compatible client, they leapfrogged a number of block relay improvements that had been added over the years. Another rumor was that some mining outlets (spending millions on mining hardware!) used micro-computers as their mining controllers which would take a while to validate new blocks, delaying their switch to the latest chaintip.

These days, it’s common that the network goes weeks without any stale blocks. BitMEX Research runs a forkmonitor which offers an RSS feed to alert users when stale blocks (and other block related events) occur. Unfortunately, it seems to me that the RSS feeds item list was reset and I was unable to find a list of their history of fork alerts. In lieu of that, let me note that BitMEX Research tweeted on 2020-01-26 that they had seen a stale block at height 614,732 and that this was the first stale block they had registered since 2019-10-16. Searching BitMEX Research’s tweets for “stale”, since 2020-01-26, they also tweeted about stale blocks on 2020-07-10, 2020-06-09, 2020-03-03, 2020-02-27, and 2020-02-22. If this is an exhaustive list, BitMEX research has recorded seven stale blocks since 2019-10-16.

Note that the “orphan block chart” provided by appears to be broken.

What is the point of a soft fork when it’s backwards compatible?

Seems you answer the first question yourself :-). Yes, it’s a fork as it enforces new rules. But it does allow you to run an older version of bitcoind (not recommended though, but supported) and still be part of the Bitcoin network.

is there any active “soft” branches in the network that I can transfer on ?

This would mean there was a network split, what a soft fork is trying to avoid.
There are still old clients running that for example do not enforce the last soft fork that occured (Segwit), but they are part of the Bitcoin network and not an alternate one because the change was backward-compatible.

In theory could we skip the proposed Taproot soft fork, activate Simplicity instead and use Simplicity to write the equivalent of Taproot scripts?

I think that’s both very premature, and misses the point.

Simplicity is a completely different approach to scripting, with significant advantages, but it’s being designed from the ground up. There is lots of progress, but it will require more than just the base layer.

You can’t just write scripts in Simplicity, and if you have one, you can’t just sign for it. There is work on improving that, by building something Miniscript-like for Simplicity, but it’s all a long way from being usable & integratable.

And even ignoring all that, if Simplicity was completely ready and usable and reviewed and everything… it would be strongly preferable to integrate it as a leaf version under Taproot. Doing it otherwise would remove some of the incentives for hiding policies that Taproot offers.

This question was answered by Pieter Wuille on Twitter.

what situation will lead the fabric network to a state fork

I have a question about in what situation it will lead the fabric network to a state fork?
I had met the state fork, see The mismatch of chaincode verison within fabric peers and MVCC_READ_CONFLICT error when update the fabric chaincode with composer, but I am not very certain about the reason. The offline peer will receive the txs and blocks from the orders and other peers when it is up.

blockchain – Is a hypothetical Bitcoin network on Mars guaranteed to fork from the one on Earth?

Electromagnetic waves take between ~4 and ~24 minutes (mean: ~14 minutes) to travel a one-way trip between Earth and Mars. Suppose I set up a Bitcoin network on Mars. Is it guaranteed to eventually fork from the Bitcoin network on Earth?

I would expect the Bitcoin network on Mars to fork from the one on Earth, because Bitcoin’s target inter-block time is 10 minutes, which is less than average time it takes for electromagnetic waves to travel between Earth and Mars. Am I correct?

c – Implementation of system() function in Linux using fork() , exec() and waipid() system calls

I have written the code for implementation of system() function in Linux using fork(), exec() and waitpid(). Could someone review the code and provide feedback. Thanks a lot.

#define size 30

char *get_command(int argc, char *argv());
int my_system(const char *command);

int my_system(const char *command)
    pid_t pid;
    int wstatus  = 0;
    int ret = 0;

    if (command == NULL)
        return 1;
    pid = fork();
    if (pid == -1) {
        return -1;
    } else if (pid == 0) {
        ret = execle("/bin/sh", "sh", "-c",command, (char *)NULL);
        if (ret == -1)
            return wstatus;

    } else {
        ret = waitpid(-1, &wstatus, 0);
        if (ret == -1)
            return -1;
    return wstatus;

char *get_command(int argc, char **argv)
    int i = 0;
    static char command(size);

    if (argc == 1)
        return NULL;

    strcpy(command, argv(1));
    for (i = 2; i < argc; i++) {
        strcat(command, " ");
        strcat(command, argv(i));
    return command;

int main(int argc, char *argv())
    int ret;
    char *command;

    command = get_command(argc, argv);
    ret = my_system(command);
    if (ret == 1)
        printf("Command is NULL, shell is availablen");
    else if (ret == -1)
        printf("Child process could not be created or error in the wait system calln");
    else if (ret == 127)
        printf("The Child process could not be executed in the shelln");
        printf("The status of the child process is :%dn", ret);
    return 0;

coinbase transaction: a bitcoin fork idea to help compress the blockchain

I have thought of a soft fork that can help with storage costs.

Why don't we force miners to embed the height of the TX Merkle tree into the first two bytes of the 4-byte block header version?

It would have two advantages:

  • It would fix the brute-force weakness of the leaf node (CVE-2017-12842), which is currently only fixed by standardization rules but not by consensus rules.

  • Similar to the description in BIP 141, we can enter a node type that is not a pruned node or a full full node, but would have txindex=1 for transactions with unspent exits. Those nodes would first store entire blocks. When the next block arrives, using their txindex they would search for the block, find the transaction, and check if all exits are spent. If so, they would remove the transaction from that block's storage but only keep its hash. This would save a lot of space since it seems to me that most query scenarios of a txindex enabled node would use gettransaction in transactions with unspent exits?

Any comment? I don't think it's worth sending this to bitcoin-ml.