I assume this 497 BTC output is unspendable?

[DeathAndTaxes]

In building a UTXO parser I came across a number of high value "custom" scripts and started looking at each of them individually.   They all look like really expensive mistakes.

They all have the same output signature.  Here is a link to the most expensive one (497 BTC)
https://blockchain.info/tx/03acfae47d1e0b7674f1193237099d1553d3d8a93ecc85c18c4bec37544fe386

OP_DUP OP_HASH160 OP_FALSE OP_EQUALVERIFY OP_CHECKSIG

If they indeed are unspendable (which I believe they are because it would require a signature from a pubkey which hashes to zero) and you didn't make one of these 23 txns well the good news is that is 2609.36304319 BTC destroyed, so your BTC are worth a little more.

Code:

TxId:Index                                                          Type      Length         Value
--------------------------------------------------------------------------------------------------
03acfae47d1e0b7674f1193237099d1553d3d8a93ecc85c18c4bec37544fe386:1  RawScript      5  497.00000000
aa62bdd690de061a6fbbd88420f7a7aa574ba86da4fe82edc27e2263f8743988:0  RawScript      5  367.75849319
2d00ef4895f20904d7d4c0bada17a8e9d47d6c049cd2e5002f8914bfa7f1d27b:1  RawScript      5  200.00000000
aebe39a99114f1b46fc5a67289545e54cbfec92d08fc8ffc92dc9df4a15ea05a:1  RawScript      5  143.62000000
6a86e6a5e8d5f9e9492114dafe5056c5618222f5042408ad867d3c1888855a31:0  RawScript      5  100.00000000
15ad0894ab42a46eb04108fb8bd66786566a74356d2103f077710733e0516c3a:1  RawScript      5  100.00000000
9edab6e7fadf1d6006315ff9394c08a7bf42e19cf61502200a1f73994f8da94b:1  RawScript      5  100.00000000
3ab5f53978850413a273920bfc86f4278d9c418272accddade736990d60bdd53:1  RawScript      5  100.00000000
835d4dcc52e160c23173658de0b747082f1937d1184e8e1838e9394bc62c0392:1  RawScript      5  100.00000000
5bd88ab32b50e4a691dcfd1fff9396f512e003d7275bb5c1b816ab071beca5ba:1  RawScript      5  100.00000000
0ca7f7299dc8d87c26c82badf9a303049098af050698c694fbec35c4b08fc3df:0  RawScript      5  100.00000000
07d33c8c74e945c50e45d3eaf4add7553534154503a478cf6d48e1c617b3f9f3:0  RawScript      5  100.00000000
81f591582b436c5b129f347fe7e681afd6811417973c4a4f83b18e92a9d130fd:1  RawScript      5  100.00000000
305fbc2ec7f7f2bc5a21d2dfb01a5fc52ab5d064a7278e2ecbab0d2a27b8c392:0  RawScript      5   98.48055000
6d39eeb2ae7f9d42b0569cf1009de4c9f031450873bf2ec84ce795837482e7a6:0  RawScript      5   98.00000000
633acf266c913523ab5ed9fcc4632bae18d2a7efc1744fd43dd669e5f2869ce5:0  RawScript      5   65.00000000
6d5088c138e2fbf4ea7a8c2cb1b57a76c4b0a5fab5f4c188696aad807a5ba6d8:0  RawScript      5   45.82000000
f0137a6b31947cf7ab367ae23942a263272c41f36252fcd3460ee8b6e94a84c1:0  RawScript      5   39.81000000
ddddf9f04b4c1d4e1185cacf5cf302f3d11dee5d74f71721d741fbb507062e9e:0  RawScript      5   37.00000000
3be0ac3dc1c3b7fa7fbe34f4678037ed733a14e801abe6d3da42bc643a651401:1  RawScript      5   35.78400000
7ad47a19b201ce052f98161de1b1457bacaca2e698f542e196d4c7f8f45899ab:0  RawScript      5   35.78000000
111291fcf8ab84803d42ec59cb4eaceadd661185242a1e8f4b7e49b79ecbe5f3:1  RawScript      5   24.31000000
64c01fedd5cf6d306ca18d85e842f068e19488126c411741e089be8f4052df09:1  RawScript      5   21.00000000

[1714769008]

1714769008

[theymos]

Right. He apparently used an empty string instead of a hash160. EQUALVERIFY compares strings, not numbers, so the 20-byte output of HASH160 will never equal the 0-byte OP_FALSE.

[gmaxwell]

This was MTGOX it made a bit of news back when it happened.

Like most epic failures it took a complex series of events to happen— that transaction was non-standard and wouldn't have been mined by normal nodes... but mtgox had an API to ask eligius to mine transactions of interest to it which bypassed all non-standardness checks and their system flagged those transactions for prioritization.

I'm sort of surprised that no one has even proposed a hardfork to recover those coins— esp. in light of mtgox somehow losing most of their customer's coins.

[DeathAndTaxes]

Ouc, well MtGox at least MtGox can point to the fact that they weren't the only ones to make this mistake.  A total of 2609.36304319 BTC over the years due to this single malformed template isn't pocket change.  It just struck me as strange as these 23 outputs represents the majority of the "custom" scripts in the UTXO and they all have the same error.

[gmaxwell]

Well MtGox wasn't the only one to do it.  2609.36304319 BTC over the years due to this single malformed template isn't a small chunk of change.  It just struck me as strange as these 23 outputs represents the majority of the "custom" scripts in the UTXO and they all are the same exact mistake.

They were all within a couple hours of each other AFAIK and all by MTGOX.  Am I incorrect?

[DeathAndTaxes]

They were all within a couple hours of each other AFAIK and all by MTGOX.  Am I incorrect?

OH.
Well you might be right and if that is the case well .... wow!

[Kluge]

I'm sort of surprised that no one has even proposed a hardfork to recover those coins— esp. in light of mtgox somehow losing most of their customer's coins.

... Huh. Knowing this was accidental, is there any moral obligation to recover lost funds through a hard fork, especially considering the now-victims weren't even the people who "directly" lost it?

Like... some guy accidentally drops $1.7M down a near-bottomless pit, and at the bottom of the pit are some kind of human-controlled robot miners who could bring it up with just a bit of fuss - should the controllers order the robots to bring the money up, or should it just sit there for all eternity because - hey, I'm not the idiot who dropped $1.7m down a pit?

This is a pretty unique situation... almost like we can "print" away the debt - except the coins were always there, just lost.

[gmaxwell]

It's a slippery slope, perhaps— "don't @#$@ with the behavior" is a clear position... but not really viable with the current state of the art in software engineering— otherwise bitcoin would have been dead with the integer overflow bug back in 2010.  I think the next reasonable compromise is "don't @#$@ with the behavior unless ~everyone agrees".  Sometimes its hard to tell what everyone would agree with, however.  Fixing obvious software bugs in the system itself seems to have gone without issue so far.

[DeathAndTaxes]

So somewhat off topic of my own topic but since it my draw people who know.

OP_DUP OP_HASH160 OP_PUSH_20 <data:20> OP_EQUALVERIFY OP_CHECKSIG
OP_DUP OP_HASH160 OP_PUSH_20 <data:20> OP_EQUALVERIFY OP_CHECKSIG OP_NOP
OP_DUP OP_HASH160 OP_PUSHDATA1 OP_PUSH_20 <data:20> OP_EQUALVERIFY OP_CHECKSIG
OP_DUP OP_HASH160 OP_PUSH_20 <data:20> OP_EQUALVERIFY OP_CHECKSIG OP_0

Note I use OP_PUSH_N as a psuedo op-code to refer to (0x01-0x4b) which pushes the next 1 to 75 bytes on the stack.  I just found it easier to spot variations in scripts most often these are removed when the script is displayed (and thus first and third scripts would appear identical).

The first is the standard Pay2PubKeyHash script.  
The second appends a OP_NOP but since it is never transferred to the stack it is spendable (just the same as standard P2PkH). Right?  
The third script uses a non-canonical way to push the data to the stack but is also spendable. Right?  
The last one I am unsure on; the OP_0 will leave the stack with a top value of zero but if OP_CHECKSIG has already been performed is the txn already valid.  Spendable or unspendable?

[theymos]

The second appends a OP_NOP but since it is never transferred to the stack it is spendable (just the same as standard P2PkH). Right? 

The OP_NOP is executed, but it doesn't change the result. It's spendable.

The third script uses a non-canonical way to push the data to the stack but is also spendable. Right? 

Yes.

The last one I am unsure on; the OP_0 will leave the stack with a top value of zero but if OP_CHECKSIG has already been performed is the txn already valid.  Spendable or unspendable?

That's unspendable. If the top stack item is false (zero, negative zero, or an empty string) when the script ends, then the script fails, regardless of what else happened in the script. (This is how OP_CHECKSIG works to begin with: it pushes OP_0 or 1 onto the stack, depending on the result of signature validation.)

[DeathAndTaxes]

Thanks.  Those were my assumptions although I wasn't committed on the third one.  Glad to see I was on track. 

[etotheipi]

I had the exact same experience.  I was debugging some of my Armory code and suddenly Armory started crashing on every rescan.  Turns out my initial cut at script identification didn't handle non-20-byte chunks of data inside that script template:

https://bitcointalk.org/index.php?topic=50232.0
https://bitcointalk.org/index.php?topic=50206.0

[DeathAndTaxes]

It's a slippery slope, perhaps— "don't @#$@ with the behavior" is a clear position... but not really viable with the current state of the art in software engineering— otherwise bitcoin would have been dead with the integer overflow bug back in 2010.  I think the next reasonable compromise is "don't @#$@ with the behavior unless ~everyone agrees".  Sometimes its hard to tell what everyone would agree with, however.  Fixing obvious software bugs in the system itself seems to have gone without issue so far.

Agreed it is a slippery slope and as Bitcoin gets larger people will have less and less of an incentive to re-inflate the supply be "undoing" lost coins.   It also brings up the issue of moral hazard.

If I lose 500 BTC due to a corrupt wallet should I be given compensation as someone who lost 500 BTC to a custom client error?

I agree the solution is better software.   Optimally even in custom transactions optimally there would be some validation of outputs.  A script analyzer probably can't tell the difference between a valid and invalid 20 byte value for comparison to HASH-160 output but it "could" know that a comparison between a HASH-160 output and a 1 byte value is never going to be valid.

P2SH introduces a new wrinkle into that dynamic in that the script is not known (to the network at large) until the output is spent.  This means the network can't help you to detect and block fatal flaws.  With P2SH it becomes more important for good validation of redeemScripts to occur before generating the resulting P2SH address (and users sending funds to it).  Obviously the scripting language is very open ended and catching all possible bad scripts is probably not possible but the more validation that can be done the better.

[smoothie]

wow this is crazy. 

Glad I wasn't this guy.

[gmaxwell]

This means the network can't help you to detect and block fatal flaws.

The inhibition of valid and interesting unusual use cases is enough that those protections had to eventually go in any case. See also: https://github.com/bitcoin/bitcoin/pull/4365

[sickpig]

Well MtGox wasn't the only one to do it.  2609.36304319 BTC over the years due to this single malformed template isn't a small chunk of change.  It just struck me as strange as these 23 outputs represents the majority of the "custom" scripts in the UTXO and they all are the same exact mistake.

They were all within a couple hours of each other AFAIK and all by MTGOX.  Am I incorrect?

http://www.righto.com/2014/03/the-programming-error-that-cost-mt-gox.html

[amaclin]

If they indeed are unspendable

They are unspendable today because today the majority of clients threat these outputs unspendable.

Let us imagine that tomorrow I create the client with the following changes:

BIP-XXX
1) All unspent outputs with the age more than ( 144 * 365 * 10 blocks == ~10 years ) go to a coinbase transaction and can not be spent as usual way.
2) Miners who vote for rule (1) should put the pattern "PLUS/BIP-XXX" into coinbase transaction
3) Miners who vote against rule (1) should put the pattern "MINUS/BIP-XXX" into coinbase transaction

Are you sure that miners will vote against my BIP? I am not
(Sorry, English is not my native language)

[spin]

It's easy, with hindsight (and the associated bias) to think that this loss was important to Mt.Gox.  The fact is it was not worth much at the time.  Even less than $1000?

Now it seems as something big, but how many other losses of $1000 dollars did Mt.Gox make.  They probably spent that much on an advertising campaign that never paid of or so many other decisions.  Or a fancy new desk for the receptionist or whatever.

The reason for Mt. Gox demise is not a singe series of transactions in 2011.  It's probably just poor management.  You can't fix that retrospectively.

[DeathAndTaxes]

If they indeed are unspendable

They are unspendable today because today the majority of clients threat these outputs unspendable.

Let us imagine that tomorrow I create the client with the following changes:

BIP-XXX
1) All unspent outputs with the age more than ( 144 * 365 * 10 blocks == ~10 years ) go to a coinbase transaction and can not be spent as usual way.
2) Miners who vote for rule (1) should put the pattern "PLUS/BIP-XXX" into coinbase transaction
3) Miners who vote against rule (1) should put the pattern "MINUS/BIP-XXX" into coinbase transaction

Are you sure that miners will vote against my BIP? I am not
(Sorry, English is not my native language)

Miners don't vote on BIP all users do.  That would be a hard fork.   If a super majority of users keep using the current fork which doesn't steal unused funds then some miners are free to mine the fork (just like they could mine an altcoin nobody uses) but that doesn't force anyone to use it.

I can't really see that your proposal would ever be accepted by a majority of users.

[amaclin]

That would be a hard fork.

Yes.

Miners don't vote on BIP all users do.

Imagine the situation when top-10 mining pools will accept this protocol change in 4 years from today.
There will be split of network in ~2018.
I think that the majority of users will follow the pool-owners
SPV-clients do not have right to vote at all about protocol changes. And the number of full nodes decreasing.

I can't really see that your proposal would ever be accepted by a majority of users.

I think that it is possible. I do not put 1 satoshi for this case of future events, but it is case of future.