3

There is no way to explicitly know that your node is on a minority-hashrate fork because to do so would mean awareness of all the new rules that makes the majority-hashrate fork valid, and then determining that more proof-of-work is accumulated on that chain. For that to be possible, you must be running an upgraded node already. There are a few warning ...


3

By definition a node's idea of the blockchain is among all valid versions of history the one with the most total proof of work. Because chains are required to be valid, it is not possible to have a block in there that violates consensus rules. It doesn't matter what miners do; full nodes will still ignore the block entirely, as if it was never created.


3

No, it would not. --reindex only handles the data that is stored on disk. Blocks are stored in the order that they are received, which is what brought you to your current view of the blockchain. So all that would happen is that you end up at that same state. Switching to another blockchain fork requires your node to be aware of it, so you need to have ...


3

Something that is very similar to what you describe is the concept of "Uncle Blocks" used in Ethereum. Even there, though, there are no partial blocks and nobody would continue to mine on a "half-finished" block. Ethereum has significantly shorter block intervals which causes multiple blocks at the same height to be found often and allowing to reference them ...


3

What happens if now the 10% fork (chain A) will mine a block and send it to the network? When a miner building on top of chain A finds a valid block, it will relay the block to the rest of the network. For convention let us assume the fork (chain A and chain B) has happened at block height N. This is how different nodes on the network will react when they ...


2

The Bitcoin blockchain is not absolutely immutable, it is probabilistically immutable. We say this because the history of transactions (the blockchain) is secured by mining power, and mining success is a probabilistic. Given a certain amount of hashpower, we expect that we'll find a block within some certain amount of time - but it is possible to find the ...


2

First, a quick overview of what happens when you submit a transaction to the network: Each node that hears about your transaction will check to see if it is valid according to their view of the network. If it is valid, the node may broadcast the transaction to its peers, and may add the transaction to its local mempool. If it is invalid, the transaction ...


2

If a node X receives first the blockchain from A, and it approves it, when it receives the blockchain from B, it simply reject it ? It will keep the block locally as an alternate chain, but not immediately discard it. If a node X receives first then blockchain from A, and then the B's blockchain in which also a node C has put another correct block (so is ...


1

In my opinion block 398364 is the first BIP9 block. Block 370434 was signaling BIP101. As you say, BIP9 was not created at the moment and even if is was meant to signal BIP9, it would also signal csv and segwit which where not active at the time: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki Block 398364 uses a BIP9 format to ...


1

Forks of both are equally hard. What you're describing as "Ethereum forks" are actually tokens/smart-contracts that run on the Ethereum network, which isn't very common on Bitcoin (but there's Omni) EDIT: Remved Rootstock as per darosior's clarification. Its only to relation to Bitcoin is that it uses merged mining, just like Namecoin.


1

Split chains can be seen as separate coins, except that a transaction with inputs valid in both chains (maybe a coinbase before the fork) would be valid in both. In that miner's chain, the miner can spend his coinbase. The rest of the nodes will see the transaction as invalid and ignore it, as his block isn't part of the main chain. If the miner wants, the ...


1

There will be no effect on those other chains since they are now independent of each other, the private key corresponding to your previous UTXO will still hold the same amount of coins at the time of their fork from bitcoin core. Here is what happen when you run -upgradewallet from: https://bitcoin.org/en/release/v0.17.0#upgrading-non-hd-wallets-to-hd-...


1

When a fork like this happens, and a new cryptocurrency emerges, the blockchain history from before the fork remains the same. The amounts you have listed are the coins mined from before the fork + coins mined after the fork. The amount mined will always vary, because of possibly different rules or because the blocks don't always get mined exactly every 10 ...


1

The BCH chain shares all of the BTC history up until the point of the fork. If you're using the same address for BCH that you did for BTC in the past, any pre-fork BTC transactions will also appear as BCH transactions.


1

What is this "time lag" ? When a miner finds a block, they will broadcast it to the network. As with all real-world networks, there is a latency (“lag time”) for this information to be received by the other nodes in the network. Specifically, there will be some amount of latency between the miner that found the block, and other miners on the network. Even ...


1

No, as far as we know, Ethereum transactions cannot be reversed. The DAO hack exploited a badly coded smart contract. The smart contract runs on top of Ethereum, so there are two layers involved here: the Ethereum blockchain and virtual machine (EVM) and the smart contracts which run on the EVM. Neither the EVM or the Ethereum blockchain were exploited. ...


1

Every full node unilaterally checks each block for validity. When a block does not adhere to the consensus rules, a full node will not accept it as valid, will not consider included transactions as confirmed, and will not forward it to other nodes. A similar incident happened for example in July when Antminer accidentally claimed a higher block reward than ...


Only top voted, non community-wiki answers of a minimum length are eligible