Topic: Mining an invalid block (Read 214 times)

Of course, they are rarely free of bugs but is it free of bugs now or not? I mean Ordinals were unexpected many consider them errors and a mistake that should not happen. I came to reality when came to know about ordinals but the invalid block information was totally new and the amount of BTC created in that transaction was huge.

There are even many threads on that issue on this forum. But they were created a long time ago so I did not come to read them.

Should this be the attack that made it possible for the attacker to create 184+ billion coins in 2010 and was swiftly responded to.


https://news.bitcoin.com/bitcoin-history-part-10-the-184-billion-btc-bug/

https://bitcointalksearch.org/topic/m.9503

Loads of failed attacks have been attempted on the bitcoin network but I'm glad it happened at a much early stage in the life of bitcoin network and the blockchain technology entirely as it could be easily contained and the publicity still low, those failed malicious attempts today has given much credibility to the network.

In addition to Cricktor's answer above, simply because that's what happens in Bitcoin Core: https://github.com/bitcoin/bitcoin/blob/058488276f8dc244fe534ba45ec8dd2b4b198a2e/src/node/miner.cpp#L283

But yes, it is also the most efficient way to order transactions when it comes to updating your candidate block and swapping in newer transactions with higher fees.

No, except for mandatory rules like coinbase transaction must be the first in any block and for linked/interdependant transactions parent comes before a child transaction. To my knowledge any other order is irrelevant.

If a miner has less transactions in his mempool than fit into a block he doesn't need to make a choice and no particular ordering is required except for above stated mandatory rules.

If a miner has more transactions in his mempool than fit into a block he needs to make some sort of choice which usually is to cram as many transactions into the available space in the candidate block usually in the order of high to lower feerate per transaction or transaction package (interdependant transactions). Another limiting factor is sum of SIG_OPs of all transactions in the candidate block which must not exceed current limit of 80,000.

I assume that such feerate based ordering is applied almost always because it's a "natural" code path, it doesn't hurt to do it as long as you don't violate mandatory ordering rules. You could avoid having two separate code paths (one for all transactions fit into the candidate block, no particular ordering needed except mandatory rules ordering; the other where you have to pick a subset of transactions from your mempool because not all would fit into a block).

In pool reality things are likely more complicated to allow to include arbitrary transactions into your candidate block for whatever reasons.

You cannot "bypass" a network rule. Your transaction either agrees with the rules, or it doesn't. If it's the latter, then the full nodes (which are literally what we call "Bitcoin network") will reject it. If you want to validate something that is invalid, then your only option is to fork the client and enforce your rules.

How is the block reward relevant with the frequency of invalid blocks?

There is no doubt. They do not belong to the Bitcoin blockchain.

To which major error are you referring to?

Is there any particular reason they do that? My guess is that by sorting the transaction array, it makes it trivial to make out which transactions aren't worth as much as new incoming transactions.

That's correct. Independent individual transaction which do not depend on any other transactions in that same block can be ordered in any order the miner likes. In reality, almost all miners simply order transactions from highest to lowest fee rates. You can see this in action if you open the most recent block here and simply start scrolling down the list of transactions. It starts at 413 sats/vbyte and decreases as you go down.

The only other stipulation on order of transactions is that the first transaction in the block must be the Coinbase transaction.

I think I mix everything up. From your explanation i deduced that all independent transactions do not take order in the block. But for dependent transactions (parent and Child) broadcasted almost the same. Now both waiting in the mempool and a miner decides to pick any transaction to his own candidate block then picks the child first, without the knowledge of the parent which happens to be the output to be used for the child, he would render that child invalid first until it verifies the parent and then the child precedes it. If so this then the only place where order of transaction in a block is required.

It sounds like you are misunderstanding the process.

All transactions in a block need to be valid. Miners don't put valid transactions "at the bottom of the block", nor does validating a transaction "take it down" the block or move it anywhere else in the block.

What usually happens is that a mining pool constructs a candidate block from transactions in their mempool. Transactions in their mempool will first be grouped in to "packages", where any child transactions with unconfirmed parents will be considered as a package, and the fee rate for the whole package calculated. The mining pool will then order individual transactions and packages by fee rate, and then pick the highest fee rate transactions/packages to fill their candidate block. They then attempt to mine that block. The order of the transactions does not change from this point on (unless they create a new candidate block), as it if did, it would invalidate the Merkle root and therefore invalidate their mining attempts. Any packages of multiple transactions will be ordered so the parent transaction comes before the child transaction. By doing this, the parent transaction is verified first, meaning the node now knows about the outputs it creates before those outputs are spent by the child transaction.

I don't want to put words in their mouth but I think the point was when BTC was worth a lot less people were willing to play around a lot more to figure out what would work and what would not without going to testnet. Now that there is a significant value placed on blocks things like what happened with Mara are going to be a lot less.

-Dave

It was a typo/grammar error from me, what I meant was although a block can consist of both a parent and child transactions, and since miners usually put the transaction which they confirm as valid at the bottom of the block, broadcasting two dependent transactions (parent and child) at the same time and validating the child first (takes it down) before the parent will definitely render the child transaction invalid first till after the parent is received later on base on protocol rule


I don’t quite get this statement, bitcoin block reward was 50 bitcoin before it started reducing by half after every 210000 blocks (usually every four years) and the current reward is 6.25 bitcoin.

The probability of finding invalid blocks in the past will be higher given that the block reward was 50k or less, but now we are talking about more than 150k unless there is bad programming software, I do not think that such blocks will be mined, especially since they are invalid because Not following the protocol and not because of a major error as happened in 2013.

If we return to the case of block 809478 MARA pool, the transactions are correct and the block is correct, but since there is no “partially right”, the error in the transaction order makes the entire block invalid.

As others said already that would be a waste of time, energy and thus money for this evil miner. There's no benefit for this miner to mine invalid blocks because the rest of the network would reject such invalid blocks.

Invalid blocks happen rather rarely. As far as my nodes logged such invalid blocks, there were about three of them in approx. the last six months (none in maybe a year or more before as far as I remember before since about end of July 2021, see P.S. at the end):

• block 783426 and 784121: mined by F2pool and invalid due to exceeding the SIG_OPS limit of all transactions within a block which is currently 80,000
• block 809478: mined by MARA pool and invalid due to wrong order of some interdependent transactions, namely at least one child transaction occurring before its parent

The invalid blocks didn't cause any disruption as the Bitcoin network worked as intended. Other consensus compliant nodes rejected the invalid blocks.



What do you mean by "lower block"? Parent and child transaction, at least one dependent pair of transactions, were in the same block but their order in the invalid block was wrong because of some foolish transaction sorting: the child preceded the parent transaction which is not allowed.



Complex software and design is rarely free of bugs, welcome to reality. Important is in the end that bugs get fixed before they can disrupt the whole thing. And as far as I perceive it, Core devs aren't reckless to implement fancy features without carefully evaluating their possible consequences (that is sometimes very hard if not nearly impossible).


P.S.
I checked my "oldest" RaspiBlitz node that has the longest history of chaintip branches of all my nodes (use bitcoin-cli getchaintips to get a list of all those your own node knows about) and above three invalid blocks were the only ones that this node knows about from end of July 2021 on.

I was going to say, that no one could bypass the network's rules because that would shake the base of the decentralization factor of the BTC blockchain but dear Pooya87 thanks for bringing this overflow incident in front of us. I did not know about it.

I am shocked to see, that BTC blockchain was not perfect at the start. I am a later joiner (2021)

It is possible for a miner to mine an invalid block. This can be done accidentally where an invalid transaction is mined without proper validation and if included in a block renders it invalid. This also can be done intentionally by the miner(s) but it will never get to propagate Long into the network before it is rendered invalid block by other nodes and also other blocks mined on top of this. That is the sweet part of decentralization, many nodes needs to verify a block, so even if one miner is doing it intentionally they would just be wasting their hash rate or power.

A recent example of this case happened last week where Marathon miner mined an invalid block due to a transaction in a wrong order (probably the child transaction is in a lower block to the parent transaction)

Anybody can mind an invalid block, create invalid transactions, do whatever that is breaking the consensus rules,... BUT none of it would be accepted by the full nodes that would be validating everything they receive. That's how the decentralized network works.

If anybody finds a way to bypass the consensus rules and pass something invalid, then it would be a problem and needs to be fixed. We had this situation once in 2010 that an invalid block was mined and accepted by nodes because there existed a bug in the implementation. It was fixed and the invalid block was discarded.
Read more: https://en.bitcoin.it/wiki/Value_overflow_incident

If that happened, that block would've been included exclusively in that specific miner's blockchain,
the rest of the network just rejected it for being invalid and most likely accepted a valid block of the same height from other miners.

The key factor here is it's not just the miner who'll decide which block to include to their blockchain but the full nodes (whole network) as well.

I don't know if i should be asking this, but since we've got experts here who I know would be able to explain. I decided to study about the Blockchain recently, and came across something that raises some questions about the Blockchain security.The question is

If it were possible for someone to consistently mine invalid blocks and bypass the network's rules, wouldnt it indicate a significant issue with the Bitcoin network's security?