someone fucked up and lost ALOT of money

[Steve]

I would be against any effort to put additional "spendability" checking into the main client.  The domain of possible transactions that are unspendable would be too large for that to be effective in any general way.  Sure, you could catch this particular form if it ever happened again, but you may as well call that rule the "mtgox screw up #214" rule...and it's highly unlikely that such a rule would ever catch a transaction in the future (because mtgox will have fixed the problem and it's unlikely that anyone else would create an unspendable transaction like this in the future).  With such rules, you are also making assumptions about the creator of the transaction that they didn't want to destroy coins.  You would also be altering what constitutes a valid transaction (and hence effectively changing the language).

If anything, create a toolkit outside the main client that tells you whether a transaction conforms to a handful of explicitly defined transaction types.  This is what mtgox should have had in place in their system (and ideally written by someone other than the person that built the code to produce their transactions).

[1714134836]

1714134836

[1714134836]

1714134836

[1714134836]

1714134836

[1714134836]

1714134836

[1714134836]

1714134836

[DeathAndTaxes]

If anything, create a toolkit outside the main client that tells you whether a transaction conforms to a handful of explicitly defined transaction types.  This is what mtgox should have had in place in their system (and ideally written by someone other than the person that built the code to produce their transactions).

Exactly.  Current there is very little "high level" support for BTC protocol.  That is easy to understand why since it is young and in flux but just as people don't construct TCP/IP packets by hand or contstruct binary VISA interchange packets by hand in the future nobody will with Bitcoin either.

Eventually high level libraries will emerge (.net, python, php, java, C++, etc) that encapsulate error checking, validation in a higher level, more abstract, and more developer safe manner.

Something like (C# .Net)

Code:

import BitcoinDotNet 

BitcoinNetworkStream stream = new BitcoinNetworkStream()

SimpleTransaction t = new SimpleTransaction()
t.Amount = ....
t.Destination = ....
t.Sign(myWallet)

try
{
  stream.SendTransaction(t)
}
catch (InvalidDestinationException e)
{
/// oops we tried to send it somewhere invalid

}

[grndzero]

Unless he was using a totally nonstandard bitcoin client AND wallet.dat

https://bitcointalk.org/index.php?topic=34028.0

Code:

Delete transactions from your wallet
Under "Delete a key from your wallet:"
Key is the hash of the transaction you want to delete (type "all" to delete them all)
Type: Transaction

[casascius]

The way I understand it, these transactions were nonstandard enough that normal miners and clients would already refuse to relay or process them (but will accept them in a mined block). And that the only way these got into a block was that he teamed up with Luke-Jr's Eligius mining pool which has been modified to explicitly allow these nonstandard transactions for a fee (or other negotiated arrangement).

[etotheipi]

Keep in mind in this discussion, that once you go outside the scope of isStandard(), there is really no computationally-feasible way to evaluate if a script is "invalid" like this.  Sure, you could've written error-checking to catch the case that you accidentally plugged OP_0 in between OP_HASH160 and OP_EQUALVERIFY... but there's literally an infinity of other ways you could create an invalid transaction that wouldn't be caught by that condition.

How is the client supposed to know that a non-std script is invalid?  Try every possible TxIn-script -- all 256^200 scripts less than 200 bytes?  What if he had a valid script but accidentally plugged in all 20 '0x00' bytes instead of the target hash?  Or accidentally reversed the endian of the target address before signing?  Added or truncated a byte by accident?  Hashed one too many times?   Sure, you can catch some of these if you clutter your codebase with dozens of validation checks... but there's still billions of other feasible ways to create invalid scripts that just cannot be caught no matter if you have a billion checks.

Just as an example:  what if you accidentally reversed the hash of the target address?   The target "address" is actually just a hash of a public-key and no one knows whether there even is a public key that exists to match that address.  the BE and LE version of the same address are completely indistinguishable to someone who doesn't have the public key that created it.  You only know there is a public key when someone actually supplies it to spend the TxOut.  But until that happens, it is literally impossible (without trying all 2^256 private keys) to know whether that TxOut is spendable.

[casascius]

Ultimately these coins are gone. Since more coins have been mined since then, any work to evict the transaction from the blockchain would do more damage to miners.

Imagine this were 500000 BTC and every MtGox user were at risk of a major loss. (which would certainly hit the news and damage the community).

A feature that allowed a miner to vote out a block or a transaction would be valuable. If 50%+ did it, the error would simply vanish. Democracy at work. But it would only work if that 50% voted immediately.

[sturle]

We're the only long running exchange that hasn't been compromised

I don't think Bitcoin Central has been compromised either, or has it?  Free software as well. :-)

[Mageant]

It's basically the same effect as when somebody loses their wallet. So what are we worried about?
It this happens a lot, then just make Bitcoins more divisible by adding more decimals.

[odysseus654]

I'm not sure I'm convinced that these coins are "unspendable".

Wouldn't this just be an extremely-high-difficulty problem to solve?

Anyone wanna guess how many Thash it would take to get an address that hashes to zero?

[etotheipi]

In order to spend these coins, you have to furnish a public key that, when you apply ripemd160(sha256(pubKey)) is equal to "0x00".  Unfortunately, ripemd160 only produces 20-byte hashes.  Even if you somehow did have a string that produces such an impossible hash, good luck finding the associated private key...

[odysseus654]

If this is a case of "bad datatype" then rather than just "extremely unlikely success" then it seems like it could be mechanically verified as impossible to complete.  I know there are an infinite number of possible transaction scripts, but they should be able to match parameters to function calls and do basic type checking...

[EDIT] Also, we can still potentially "make democracy work" and void this transaction at any point.  It does require >90% buy-in though (i.e. for everyone to adopt a client with modified rules).  Of course, another "good luck" on getting that to happen without a *REALLY* good reason...

[EhVedadoOAnonimato]

If this is a case of "bad datatype" then rather than just "extremely unlikely success" then it seems like it could be mechanically verified as impossible to complete.  I know there are an infinite number of possible transaction scripts, but they should be able to match parameters to function calls and do basic type checking...

Somebody said earlier in this thread that it's probably impossible to do such verification in polynomial time.
The protocol obviously cannot rely on heuristics, and a "transaction blacklist" in the protocol is definitely not desirable either. Such kind of things could eventually be done by an external tool through which you could validate your custom scripts, as also said by someone else in this thread. But the only reasonable behavior to the protocol is to accept them all.

[ribuck]

But the only reasonable behavior to the protocol is to accept them all.

Agreed.

Any software that blocks (some) unspendable transactions can be applied at the time the transaction is created. There's no reason why someone else (i.e. the miner) needs to do the blocking.

[bitcoinminer]

Congrats!  Expensive lessons are always the best.

"Let me try to send a ton of money via a non-standard client and see what happens!"

"Shouldn't we try with like, 0.01 BTC?"

"Fuck no!  I'm a programmer!  Let's send the whole wallet!"

[odysseus654]

I'm not quite sure I understand where the "polynomial time" came from, although there's a strong whiff of Gödel in that statement.  While I recognize that we cannot prove absolute correctness we can at least do some structural sanity checks, assuming there is an indeterminate number of items of arbitrary type on top of the stack or something.  Heck, Java does a heck of a lot heavier check than this when loading code.  And I don't see how this would change Bitcoin at all, or eliminate any possible "strange scripts" people could come up with.

I don't really understand the "minor is not the gatekeeper of transactions" thingy either.  What prevents double-spend transactions from entering the blockchain?  I'm assuming that anyone can broadcast anything they want almost by definition (i.e. we have to accept that badly-performing clients exist).  Either the miner has to block malicious transactions or we have to ignore malicious transactions that are already in the block chain.  I recognize that misformed scripts are nowhere near "malicious", but the same rules could apply here.  We don't need 100% buy-in by miners either, this doesn't really change Bitcoin, miners already are permitted to accept all or none of the transactions at their discretion.

I realize that I'm entering a very intense firestorm with this opinion and would probably immediately be declared too inexperienced and/or wrong

[genjix]

This one change might be 8 lines of code.

100 of these future changes to partially protect the scripting language imperfectly.

An additional 1k lines of code total.

1 month of extra work.

An ambiguous restricted bloated standard that nobody understands. Multiple revisions and re-revisions to re-enable disabled behaviour and odd-corner cases nobody imagined where people need to abuse the scripting language in their own weird way.

Many buggy implementations.

Conclusion: KISS

[rotrott]

It would be nice if there was something that let novice bitcoin programmers know if they were doing something (possibly) stupid.  I know, I know, don't hire stupid programmers, but let's step into the real world.  Not everyone is going to be a bitcoin pro from the offset.  There's no need to punish users of a poorly programmed service if we can do something to help these programmers learn...

I understand the level some of you guys are at, but not everyone starts there.

[odysseus654]

It would be nice if there was something that let novice bitcoin programmers know if they were doing something (possibly) stupid.  I know, I know, don't hire stupid programmers, but let's step into the real world.  Not everyone is going to be a bitcoin pro from the offset.  There's no need to punish users of a poorly programmed service if we can do something to help these programmers learn...

Considering how few "strange scripts" there are on blockexplorer (although it's not reporting any more with the huge flood from this one block), I'd say that the moment you start writing your own scripts or not just copy/pasting the two scripts that are used everywhere you are pretty much running without a safety net.

[memvola]

It would be nice if there was something that let novice bitcoin programmers know if they were doing something (possibly) stupid.

Testnet?

[genjix]

i added an explanation to the op. basically OP_0 is defined, but there is no op that pushes a 0 to the stack. Instead it's actually interpreted as push 0 bytes to the stack. See script.h GetOp2