Wonder who this solominer is? 88.6.216.9

[twmz]

Orphans are primarily due to the enabling of BIP16, I suspect.

I thought this as well but there has hardly been any P2SH transactions.

510b5a44935109e249a704c2900aa9d8303166062e81d2ac852c965b6266dcee      
d0636198ea55fadee5b4ccc07c85012db7d07c2d25790b3aec770c86617801c0      
9ab59e2d4be16c470160eb9b9a9d9799eaf29af0461aea131e748659d806fa1a
658fc92061f1c4125d5cd1034eb8a1f09bfebd32a988d855eb7ee63689759a21
b0539a45de13b3e0403909b8bd1a555b8cbe45fd4e3f3fda76f3a5f52835c29d
9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6

are the only ones ever.

This is the broken P2SH transaction that has single handedly caused 35 (and counting) blocks to orphan:

http://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2

In several cases, it actually caused several others to orphan because unupgraded miners built on top of the blocks that included this tx and created 2-4 block long forks that eventually lost the race.

[1714483488]

1714483488

[1714483488]

1714483488

[1714483488]

1714483488

[rjk]

This is the broken P2SH transaction that has single handedly caused 35 (and counting) blocks to orphan:

http://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2

In several cases, it actually caused several others to orphan because unupgraded miners built on top of the blocks that included this tx and created 2-4 block long forks that eventually lost the race.

Interesting, can you describe what is broken about it, and why it is continuing to cause issues?

[twmz]

This is the broken P2SH transaction that has single handedly caused 35 (and counting) blocks to orphan:

http://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2

In several cases, it actually caused several others to orphan because unupgraded miners built on top of the blocks that included this tx and created 2-4 block long forks that eventually lost the race.

Interesting, can you describe what is broken about it, and why it is continuing to cause issues?

I don't understand the broken-ness well enough to explain it, but the smarter-than-me developers in bitcoin-dev said the script is invalid in some subtle way that the current bitcoin versions recognize and reject and that old bitcoin versions don't recognize and think is valid.

It's still causing problems because every time a block that contains the transaction is orphaned, the old bitcoin versions see that this transaction still exists in their list of transactions that haven't yet made it in to a block and so they try to put it in a block again (which causes that block to get orphaned by the new bitcoin versions that reject the transaction and so the cycle repeats over and over).

[rjk]

This is the broken P2SH transaction that has single handedly caused 35 (and counting) blocks to orphan:

http://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2

In several cases, it actually caused several others to orphan because unupgraded miners built on top of the blocks that included this tx and created 2-4 block long forks that eventually lost the race.

Interesting, can you describe what is broken about it, and why it is continuing to cause issues?

I don't understand the broken-ness well enough to explain it, but the smarter-than-me developers in bitcoin-dev said the script is invalid in some subtle way that the current bitcoin versions recognize and reject and that old bitcoin versions don't recognize and think is valid.

It's still causing problems because every time a block that contains the transaction is orphaned, the old bitcoin versions see that this transaction still exists in their list of transactions that haven't yet made it in to a block and so they try to put it in a block again (which causes that block to get orphaned by the new bitcoin versions that reject the transaction and so the cycle repeats over and over).

Makes me wonder if there needs to be some kind of expiry, so that if a transaction is submitted more than x times and rejected for whatever reason, it should no longer be re-transmitted.

[jamesg]

I don't understand the broken-ness well enough to explain it, but the smarter-than-me developers in bitcoin-dev said the script is invalid in some subtle way that the current bitcoin versions recognize and reject and that old bitcoin versions don't recognize and think is valid.

Sounds to me that this transaction was intentionally created to put MM out of business for a while and to do exactly what it is doing to miners who didn't upgrade.

[DeathAndTaxes]

This is the broken P2SH transaction that has single handedly caused 35 (and counting) blocks to orphan:

http://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2

In several cases, it actually caused several others to orphan because unupgraded miners built on top of the blocks that included this tx and created 2-4 block long forks that eventually lost the race.

Interesting, can you describe what is broken about it, and why it is continuing to cause issues?

I don't understand the broken-ness well enough to explain it, but the smarter-than-me developers in bitcoin-dev said the script is invalid in some subtle way that the current bitcoin versions recognize and reject and that old bitcoin versions don't recognize and think is valid.

It's still causing problems because every time a block that contains the transaction is orphaned, the old bitcoin versions see that this transaction still exists in their list of transactions that haven't yet made it in to a block and so they try to put it in a block again (which causes that block to get orphaned by the new bitcoin versions that reject the transaction and so the cycle repeats over and over).

Makes me wonder if there needs to be some kind of expiry, so that if a transaction is submitted more than x times and rejected for whatever reason, it should no longer be re-transmitted.

Why? I love it.  Tx processing nodes should be up to date. Period. Casual users don't need the latest code but miners form the tx processing backbone.  Could you imagine VISA releasing a major critical upgrade and a month after the hard deadline some merchant banks still hadn't gotten around to upgrading their systems? 

Miners need to take their role more seriously.  If they can't be bothered to upgrade even when given a months of notice, provided a deadline, and warned they risk losing all revenue .... well IMHO they shouldn't be mining.  Racking up huge losses may convince them to either a) take it more seriously or b) quit.  Either one is fine by me.  The network is made stronger.

[DeathAndTaxes]

Sounds to me that this transaction was intentionally created to put MM out of business for a while and to do exactly what it is doing to miners who didn't upgrade.

This.  Miners who upgraded have been rewarded with "bonus" compensation split equally by hashing power (it just sucks I got 2GH/s offline right now).  Negligent miners are facing financial consequences for their idiocy.  I would like to thank who ever released the "killer tx".

[rjk]

Sounds to me that this transaction was intentionally created to put MM out of business for a while and to do exactly what it is doing to miners who didn't upgrade.

This.  Miners who upgraded have been rewarded with "bonus" compensation split equally by hashing power.  Negligent miners are facing financial consequences for their idiocy.  I would like to thank who ever released the "killer tx".

I agree, and I had thought that valid blocks from upgraded miners were being orphaned by it somewhere along the way, but that doesn't seem to be the case here.

[DeathAndTaxes]

so you can still mine empty block or not ?

Yes.  There has been no protocol change which prohibits empty blocks.

[disclaimer201]

If empty blocks pose a threat, the bitcoin developers should consider to correct it, even if it isn't without dangers. Bitcoin is great but I'm sure it isn't perfect. A programmer can hardly think of every possible loophole/attack vector. I agree quick solutions should be avoided. Let's see and watch if it happens again. Is MM still mining, and if so, is he still extending his mining /or botnet operation?

[P4man]

Is MM still mining, and if so, is he still extending his mining /or botnet operation?

Doesnt look like it:

[Clipse]

Is MM still mining, and if so, is he still extending his mining /or botnet operation?

Doesnt look like it:

Network hashrate is still at ~11-11.5GH excluding the badluck, I dont think that Mystery miner is gone unless some other mysterious 1-1.5TH user replaced him.

You are looking at the 1 TX blocks, its pretty obvious that is gone but the hashrate isnt.

[DeathAndTaxes]

Network hashrate is still at ~11-11.5GH excluding the badluck, I dont think that Mystery miner is gone unless some other mysterious 1-1.5TH user replaced him.

Oh I forgot to tell everyone.  My 30 BFL Rig Boxes finally arrived and I just happened to power them up on 1 April.

[jamesg]

Network hashrate is still at ~11-11.5GH excluding the badluck, I dont think that Mystery miner is gone unless some other mysterious 1-1.5TH user replaced him.

Oh I forgot to tell everyone.  My 30 BFL Rig Boxes finally arrived and I just happened to power them up on 1 April.

This nice little graph would seem to indicate otherwise....

[DeathAndTaxes]

Variance and stuff (the answers to anything BTC related).

[wogaut]

Is MM still mining, and if so, is he still extending his mining /or botnet operation?

Doesnt look like it:

Network hashrate is still at ~11-11.5GH excluding the badluck, I dont think that Mystery miner is gone unless some other mysterious 1-1.5TH user replaced him.

You are looking at the 1 TX blocks, its pretty obvious that is gone but the hashrate isnt.

Oh I forgot to post that I fixed my software patch:

I'm working on a patch that solves block hashes analytically without requiring to brute-force SHA. Then, you simply set the blocktime variable to the desired value and off you go.
I'm in the testing phase right now, set it to 1 block per hour, just to make sure I won't destabilize the bitcoin enterprise, but I still need to add tx to the equation; people seem to get uncomfortable with all these zero tx blocks right now.
Well, once I fixed that I will offer the patch for just $9.95 to everybody!  

Just not sure if I'm ready to make it available to the public yet  

[Clipse]

Network hashrate is still at ~11-11.5GH excluding the badluck, I dont think that Mystery miner is gone unless some other mysterious 1-1.5TH user replaced him.

Oh I forgot to tell everyone.  My 30 BFL Rig Boxes finally arrived and I just happened to power them up on 1 April.

This nice little graph would seem to indicate otherwise....

Simple, lets look at the end of this diff adjustment. If hashrate is still ~11-11.5TH which I suspect it would be I highly doubt it was suddenly replaced with the last 7days by new miners rather than just variance even out for next difficulty adjustment.

If the hashrate is lower well then we have our answer, MM got hit by a baby fatality.

Now we just need to bring out a new BIP patch whenever some suspected botnet appears, if it did crush their botnet setup it would seem to be a huge job to update them

[kjj]

I don't understand the broken-ness well enough to explain it, but the smarter-than-me developers in bitcoin-dev said the script is invalid in some subtle way that the current bitcoin versions recognize and reject and that old bitcoin versions don't recognize and think is valid.

Sounds to me that this transaction was intentionally created to put MM out of business for a while and to do exactly what it is doing to miners who didn't upgrade.

Except that he wasn't including any transactions, so he wouldn't include the poison transaction or any that depend on it.

[DeathAndTaxes]

Except that he wasn't including any transactions, so he wouldn't include the poison transaction or any that depend on it.

But if his bitcoind is out of date he would see the invalid block as valid and continue to build upon that making any block he generates invalid (tx or not).  A block built on an invalid block is by definition invalid.

[kjj]

Except that he wasn't including any transactions, so he wouldn't include the poison transaction or any that depend on it.

But if his bitcoind is out of date he would see the invalid block as valid and continue to build upon that making any block he generates invalid (tx or not).  A block built on an invalid block is by definition invalid.

But the majority of the network would overrule him and even his broken node would have the correct current latest hash most of the time.  He would need to be using a node that not only is still accepting invalid blocks, but is only accepting invalid blocks.  I don't think that the recent changes have orphaned any old versions; my old 0.4.0 node is still going strong.

Also, the graphs don't show a sharp transition on the 1st.  Does anyone know when the first orphan fork happened?