Topic: Several developers, miners, and researchers reported that Bitcoin mining develop (Read 189 times)

Unfortunately, that's the outcome of complete decentralisation. As soon as the decentralied system becomes too large, mistakes and misunderstanding between nodes arise. In blockchain system it leads to forking (hard forks or soft forks)... Also, internet connection is a specific problem: miners do have high data processing speed, while connections between nodes don't. This also leads to information exchange problems, which eventually lead to strong need of centralisation, which opposes the whole concept of blockchain system. A loop is then repeated...

means the marathon digital got 6.25BTC for mining an invalid block?
do the invalid block which got mined is placed in a real bitcoin blockchain or any other blockchain? or not added to any blockchain?
and if the invalid block was mined, so of course there were wrong transaction(or transaction from 0 balance wallet) or double spending was happened?

Several developers, miners, and researchers reported that Bitcoin mining developer name Marathon Digital mined an invalid block 809478.

Anonymous Bitcoin developer 0xB10C said in his post on Twitter that MaraPool was warned about a "transaction order problem". This was later confirmed by Jameson Lopp, co-founder of CasaHODL crypto equity custody solutions.

Invalid Bitcoin block rejected by all node operators. According to BitMEX Research, the reason why the block was invalid was an order placed by mistake.

Marathon Digital, have not yet responded to CoinDesk's request for comment.

What do you understand about this?
As Bitcoin miners create new blocks, they race to solve solutions. Each miner tries to solve these problems to replace a new block, and the first miner to solve it correctly wins Bitcoin (BTC) as rewards combined with the new block.

The Bitcoin network does not accept invalid blocks and requires miners to mine blocks according to certain rules. Blocks that do not comply with these rules will be rejected by the network and will not earn any rewards made. In short, the extraction of an invalid block indicates that the execution of transactions will suffer a great loss.

This is not what happened. Orphaned blocks are valid blocks, they just belong on a less-worked chain and are therefore ignored.

What really happened is this: the developer was trying to mine a block which was invalid, because of ordering. According to this Twitter post, the developer included TX A that spends an UTXO from a TX B which was included after A. That's invalid from a protocol perspective.

Orphan blocks also called as Stale blocks.

Anonymous Bitcoin developer 0xB10C said in his post on Twitter that MaraPool was warned about a "transaction order problem".

This is not what happened. Orphaned blocks are valid blocks, they just belong on a less-worked chain and are therefore ignored.

Usually when people say "orphan block", they mean a Stale Block, which is a well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. The Block Reward in a stale block is no longer spendable on the difficultywise-longest and well-formed blockchain; therefore whoever mined that block does not actually get the reward (or the transaction fees). This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional".

Conceptually, calling the above type of block an orphan block doesn't make any sense, since it does have a parent. Indeed, in the Bitcoin source code and in more technical discussions, orphan blocks and stale blocks are two separate things: both are not part of the longest valid chain, but in an orphan block it is because the parent is unknown, whereas in a stale block it is because that part of the chain is known to no longer be longest. However, in general discussions people almost always mean "stale block" but say "orphan block".

Almost every node on the Bitcoin network maintains a temporary list of unconfirmed transactions called the memory pool, mempool, or transaction pool. Nodes use this pool to keep track of transactions that are known to the network but are not yet included in the blockchain. For example, a wallet node will use the transaction pool to track incoming payments to the user’s wallet that have been received on the network but are not yet confirmed.

As transactions are received and verified, they are added to the transaction pool and relayed to the neighboring nodes to propagate on the network.

Some node implementations also maintain a separate pool of orphaned transactions. If a transaction’s inputs refer to a transaction that is not yet known, such as a missing parent, the orphan transaction will be stored temporarily in the orphan pool until the parent transaction arrives.

When a transaction is added to the transaction pool, the orphan pool is checked for any orphans that reference this transaction’s outputs (its children). Any matching orphans are then validated. If valid, they are removed from the orphan pool and added to the transaction pool, completing the chain that started with the parent transaction. In light of the newly added transaction, which is no longer an orphan, the process is repeated recursively looking for any further descendants, until no more descendants are found. Through this process, the arrival of a parent transaction triggers a cascade reconstruction of an entire chain of interdependent transactions by re-uniting the orphans with their parents all the way down the chain.

Both the transaction pool and orphan pool (where implemented) are stored in local memory and are not saved on persistent storage; rather, they are dynamically populated from incoming network messages. When a node starts, both pools are empty and are gradually populated with new transactions received on the network.

Some implementations of the Bitcoin client also maintain an UTXO database or pool, which is the set of all unspent outputs on the blockchain. Bitcoin Core users will find it in the chainstate/ folder of their client’s data directory. Although the name "UTXO pool" sounds similar to the transaction pool, it represents a different set of data. Unlike the transaction and orphan pools, the UTXO pool is not initialized empty but instead contains millions of entries of unspent transaction outputs, everything that is unspent from all the way back to the genesis block. The UTXO pool may be housed in local memory or as an indexed database table on persistent storage.

Whereas the transaction and orphan pools represent a single node’s local perspective and might vary significantly from node to node depending upon when the node was started or restarted, the UTXO pool represents the emergent consensus of the network and therefore will vary little between nodes. Furthermore, the transaction and orphan pools only contain unconfirmed transactions, while the UTXO pool only contains confirmed outputs.

I don't find any issue with it, either it was done mistakenly or deliberately, or maybe that miner might be testing or showing off to a newbie that the BTC blockchain can not be tricked.

Making 35 invalid blocks in a day vs 1 if so can this fuck up the block chain speed?

I am asking if this is a way to attack the actual block chain at a low cost.

Developers have the testnet availale to test and prevent those errors.

Is that what you asked or i understand it wrong?

So was the developer tested this deliberately or was it an accidental mistake.

It seems to me if I do exactly what the developer did a could case an invalid block correct?

Making 35 invalid blocks in a day vs 1 if so can this fuck up the block chain speed?

Thank you for the clarification, so basically they don't included the parent transaction in the same block, and the parent was still unconfirmed.

So was the developer tested this deliberately or was it an accidental mistake.

So could the developer's mistake/error/system test be duplicated a lot at a low cost?

Several developers, miners, and researchers reported that Bitcoin mining developer name Marathon Digital mined an invalid block 809478.

So could the developer's mistake/error/system test be duplicated a lot at a low cost?

This is not what happened. Orphaned blocks are valid blocks, they just belong on a less-worked chain and are therefore ignored.

What really happened is this: the developer was trying to mine a block which was invalid, because of ordering. According to this Twitter post, the developer included TX A that spends an UTXO from a TX B which was included after A. That's invalid from a protocol perspective.

According to this Twitter post, the developer included TX A that spends an UTXO from a TX B which was included after A.

This situation is not new, blocks get orphan constantly

What do you understand about this?
As Bitcoin miners create new blocks, they race to solve solutions. Each miner tries to solve these problems to replace a new block, and the first miner to solve it correctly wins Bitcoin (BTC) as rewards combined with the new block.

The Bitcoin network does not accept invalid blocks and requires miners to mine blocks according to certain rules. Blocks that do not comply with these rules will be rejected by the network and will not earn any rewards made. In short, the extraction of an invalid block indicates that the execution of transactions will suffer a great loss.