Quote from: Alice102030 on September 27, 2023, 03:36:53 PM

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

You can find him in https://bitcoindevlist.com/ (Bitcoin Donation Portal) for Bitcoin developers.

This developer has some amazing projects like Mining pool observer (Conflicting transactions).

Quote from: BlackHatCoiner on September 27, 2023, 06:45:12 PM

Quote from: albert0bsd on September 27, 2023, 03:44:07 PM

This situation is not new, blocks get orphan constantly

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

Orphan blocks also called as Stale blocks.

What is Orphan blocks

Quote

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".

In Mastering Bitcoin book, Andreas Antonopoulos explained more about orphan transactions and how pools handle those transactions.
Transaction pools

Quote

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.