Topic: someone fucked up and lost ALOT of money - page 2. (Read 30483 times)

OP_FALSE is referenced nowhere and OP_0 only exists in GetOpName(...)

GetOp2 reads the opcode and then if it's less than PUSHDATA4, will branch to the push data stack part, and then on line 538 if (opcode < OP_PUSHDATA1) nSize will be set to 0.

EvalScript also interprets it as a push n bytes to the stack in the if ( ... && 0 <= opcode ...) after the previous first block of if (opcode ==  ...).

The descriptions of the opcodes also describe this as a push-zero (alias OP_FALSE) rather than push-nothing (there are already 11 NOP opcodes, why do we need another?)

This script appears to me to be potentially solvable if OP_0 is a NOP, unsolvable otherwise.  However it does feel to me like interpreting it as push-zero makes a lot more sense.

I do recognize that this opcode is unlikely to have been used anywhere, but any use of it (or any successful claim of these coins) would make it impossible to make some kind of change here without causing a netsplit.

I recognize that I've probably gone badly off-topic with respect to this topic title now...

+1

So, MtGox finally GOXXXED himself? I am not surprised at all.

These abstract script descriptions are produced by Bitcoin's CScript.ToString(). It's a Bitcoin bug if they are incorrect.

It looks like OP_0 was intended to push a numerical 0. It's probably a bug if it doesn't push anything. (The script in this case is broken either way, though.)

There is a good reason why I use old versions of bitcoind (and GUI client). I just let you all test it for half a year or so... than it seems like a good and well tested software for me.  

I hope I'm not over-posting here, but as long as you're trying to clarify things.  BlockExplorer currently describes this as "OP_DUP OP_HASH160 0 OP_EQUALVERIFY OP_CHECKSIG".

With your explanation here, (assuming the "0" is "OP_0") the "0" sounds like it might be a bit... confusing.

Also, with OP_0 being an effective no-op (rather than push-zero), the datatype checking method I was mentioning prob wouldn't have done anything useful here (I doubt you're much surprised).  I'm also marking this back down from "structurally impossible" to "very improbable", there *may* be a path to claim, but it wouldn't be worth the effort to discover.

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

Testnet?

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.

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.

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

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

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!"

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.

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.

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...

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...

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?

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.