1hash pool just mined an invalid block again

[piotr_n]

Not sure if it is on any interest for anyone here, but I remember once, when a BU node mined an invalid block, people were shitting themselves all over the internet.

Well, not sure that kind of software 1hash pool uses, but they have just mined their second invalid block.

It's easy to find them these days, because nodes relay them before fully verifying.

The first invalid block they mined was #474294, with hash 00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232
The second one, just a few hours ago #477115, with hash 0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b

You can download both of them from here:
http://gocoin.pl/1hash/474294-00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232.bin
http://gocoin.pl/1hash/477115-0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b.bin

I haven't checked yet why exactly they are invalid, but I think the order of the transactions inside the block is screwed up.
They use an input from a tx that is only created later in the block.

I'm thinking they must be using come customised mining software which (sometimes) assembles the block incorrectly.
So I thought I'd let them know, before they mine the third broken block, still without anyone noticing

[1714100566]

1714100566

[1714100566]

1714100566

[1714100566]

1714100566

[achow101]

Both blocks are invalid because they included a transaction without including its unconfirmed parent.

I checked block 474294 and it contained transaction a6655ca47c62ffcbf6d3dcba34bc1af24a1eb0bcea54d3099d36201a66aec2a0 but not its parent transaction b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0e.

I'm still checking block 477115 for which transaction it is missing, but it triggered the same error message as 474294, so I believe it is caused by the same problem.

Update: Block 477115 is actually more interesting than 474294. It contains the transaction 7a122ef22468e4af16b010d7acf7aa81e5af3636423c613fd98246c179d79800 which is missing its parent 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d. But the interesting part is that the parent transaction is actually lower down in the block. So the problem here is that the transactions are in the wrong order, which means that they are probably permuting the order of their transactions.

One thing to notice is that 477115 contains 256 transactions and 474294 contains 255 transactions, both of which are good numbers of transactions to have for asicboost. Furthermore, this problem could be caused by permuting transactions as would need to be done for asicboost.

Edit: corrected transaction counts

[piotr_n]

One thing to notice is that both blocks contain exactly 256 transactions

I think 477115 has one tx less.

[piotr_n]

Both blocks are invalid because they included a transaction without including its unconfirmed parent.

For what I can see the transaction is there, but is placed later in the block.

See the 477115 one...

In this block, tx number 22 (while 0 is coinbase) is spending output 1 from txid 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d

9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d is included in that block, but at index 90 - so too late.

I believe 474294 had a similar problem, because I think I was checking it back them when in happened.

[achow101]

For what I can see the transaction is there, but is placed later in the block.

Yes, see my update

I believe 474294 had a similar problem, because I think I was checking it back them when in happened.

474294 is missing the parent entirely.

[piotr_n]

I believe 474294 had a similar problem, because I think I was checking it back them when in happened.

474294 is missing the parent entirely.

Yes, you're right. Sorry

[spin]

How do you analyse the block after the fact?  I mean what tools do you use etc.

[piotr_n]

How do you analyse the block after the fact?  I mean what tools do you use etc.

It's more of a process, rather than a tool.

E.g. for #477115

My node informed be that it rejected the block with a message like this:

Code:

AcceptBlock: Unknown input TxID: 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d

Looking into the code of the node, I see that this basically means that the block was trying to spend an input from an "non-existing" transaction (its ID is printed)

So I save the block on a disk in a separate file and then use a code like this:

Code:

package main

import (
	"fmt"
	"io/ioutil"
	"github.com/piotrnar/gocoin/lib/btc"
)

func main() {
	d, _ := ioutil.ReadFile("477115-0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b.bin")
	println(d)
	bl, _ := btc.NewBlock(d)
	println(bl)
	bl.BuildTxList()
	println(len(bl.Txs))
	for i, tx := range bl.Txs {
		fmt.Println(i, tx.Hash.String())
		for ii, inp := range tx.TxIn {
			fmt.Println("  ", ii, inp.Input.String())
		}
	}
}

... it will print all the TxID inside the block, as well as the inputs they are spending: https://pastebin.com/LtMKi8pC

Browsing the results for the problematic TxID (9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d), I see it in two places:

Code:

22 7a122ef22468e4af16b010d7acf7aa81e5af3636423c613fd98246c179d79800
   0 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d-001

[...]

90 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d
   0 796c96815be92f9351cbdd0cb52df426d4af18504a3734a3a4a8f5352555c4f2-000

This means that tx number 22 was trying to spend output from tx number 90.
Meaning: invalid block.


As for the other block (#474294)
Looking for the missing tx (b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0e), you don't find it inside the invalid block.
So you go to blockchain.info and look for it: https://blockchain.info/tx/b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0e
There you see that it was confirmed in (alternative) block #474294.
Which gets you to the conclusion that if (any) block #474294 was trying to spend it, while not including it, it obviously is the reason for it to be invalid.

[zawy]

Is it true that SW2x is preferred by some miners over SW because the set block size allows asicboost to work?

[spin]

How do you analyse the block after the fact?  I mean what tools do you use etc.

It's more of a process, rather than a tool.

Thanks for sharing your process.

[TechPriest]

Is it true that SW2x is preferred by some miners over SW because the set block size allows asicboost to work?

No. I don't think so, because in fact SW2x it's the same as SW. (BIP 91 and BIP 141 it's just different ways to implement SW)
Very interesting thread, thank for it, TS.
I have one question: What will happen to theese invalid blocks? They rejected by all nodes and became orphans or what?

[25hashcoin]

 Pools can mine whatever or however the fuck they please. That's the freedom nature of Bitcoin.

[piotr_n]

I have one question: What will happen to theese invalid blocks? They rejected by all nodes and became orphans or what?

They are just invalid - don't even qualify to be orphans.
So inconsistent with the protocol that it's quite impossible to build on top of them.

Pools can mine whatever or however the fuck they please. That's the freedom nature of Bitcoin.

Sure.
As far as I am concerned, everybody has freedom to throw his money into a fire.

[very_452001]

ELI5

What does this mean? Good or bad?

[piotr_n]

ELI5

What does this mean? Good or bad?

Good or bad?

It's bad for miners who use 1hash pool, as they are loosing profit by wasting their hash power on mining useless blocks.

It's good for all the other miners, as they are gaining profit, as the result of 1hash pool mining useless blocks.

For me - it's neither good or bad. Just found it interesting.

[fr4nkthetank]

Pools can mine whatever or however the fuck they please. That's the freedom nature of Bitcoin.

Yup damn right.  They are free to mine invalid blocks   The rest of the network also has freedom to say nope.  but hey at least it makes things interesting.

[pooya87]

ELI5

What does this mean? Good or bad?

Good or bad?

It's bad for miners who use 1hash pool, as they are loosing profit by wasting their hash power on mining useless blocks.

It's good for all the other miners, as they are gaining profit, as the result of 1hash pool mining useless blocks.

For me - it's neither good or bad. Just found it interesting.

+ Good, because it shows the consensus rules are working properly (or rather enforced properly by the nodes) by rejecting an invalid block fast and smooth.