someone fucked up and lost ALOT of money

[odysseus654]

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

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.

[1713941092]

1713941092

[1713941092]

1713941092

[1713941092]

1713941092

[Vladimir]

enjoy using custom clients  

also do this every single day  

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.  

[theymos]

BlockExplorer currently describes this as "OP_DUP OP_HASH160 0 OP_EQUALVERIFY OP_CHECKSIG".

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

[Hawkix]

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

[ThiagoCMC]

I was just thinking today about resetting the -testnet with new rules to make it more stable/useful...

+1

[odysseus654]

BlockExplorer currently describes this as "OP_DUP OP_HASH160 0 OP_EQUALVERIFY OP_CHECKSIG".

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

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

[genjix]

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

[finway]

Thanks for the contribution (destroy ).

[greyhawk]

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.

That is why you do test runs of your scripts/programs before releasing them into the wild. This is something several "exchanges" have now failed to do correctly and in turn got punished for it.

[phillipsjk]

There is some discussion about having miners reject bad transactions.  Wouldn't that just cause a huge split in the network if only half the people upgraded the client and then that happened?

Client doesn't have anything to do with miners.
Miners already can include or reject any transaction for any reason.

Each miner (or pool) decides which transactions (if any) to include in the block they are hashing.

You two are talking about two different things. Miners are allowed to exclude any transactions they want, but they all have to agree on which transactions are valid.

Currently, most miners reject most turing-complete strange scripts, but still accept the full set of op-codes as valid. This is important because each miner must verify the validity or every transaction in the block-chain. For example a rogue miner generating a block with a 100BTC coin creation transaction will be ignored by the honest nodes.

TL:DR: Even if we wanted to prohibit coin destruction (I did not know it was unambiguously possible), it would create a split in the block-chain.

PS: I am still of the opinion that the protocol is essentially untouchable at least until the block-reward drops. What part of "experimental currency" don't people understand? We have to expect a few "flaws". Those flaws will be easier to interpret if we don't monkey with the experiment.

Edit: All Turing-complete scripts must be invalid. Else all miners would stall on the first endless loop included in the block-chain. Currently, "strange" transactions are transactions other than: tranferring a coin from one (set of) address to another, and coin creation.

[matonis]

Thanks for the excellent insight on this, genjix. Deflation through attrition.

[ribuck]

All Turing-complete scripts must be invalid...

Bitcoin scripts do not form a turing complete language (there's no loop or "goto"), so the question doesn't arise.

[edit: this was a deliberate design decision by Satoshi]

[odysseus654]

Also, (reading the same webpage I saw the OP_FALSE on) I do see that a number of commands were disabled "for security reasons", so there already are plenty of eyes ensuring that malicious scripts can't crash the blockchain.  The disabled commands are described as: 4 commands to split or combine strings, 4 bitwise operations, and 7 commands that multiply or divide numbers.

[genjix]

Also, (reading the same webpage I saw the OP_FALSE on) I do see that a number of commands were disabled "for security reasons", so there already are plenty of eyes ensuring that malicious scripts can't crash the blockchain.  The disabled commands are described as: 4 commands to split or combine strings, 4 bitwise operations, and 7 commands that multiply or divide numbers.

There's a Solver in the code that matches transactions to only 2 allowed templates/formats. Without passing this template, transactions cannot make it into the memory pool and don't get propagated.

If you wish to make a new tx type you have to lobby for it to be included in the list of templates.

[molecular]

Or it sounds like the mainline client does validation of the protocol message.  Perhaps this could be broken out into a library that everyone could use to validate the protocol message before it was sent?

No, it's not a flaw. You can read the chatlog I pasted on page 2 for more information why.

Must've been quite exhausting to keep arguing for such a long time with the guy that just seemed to refuse to even consider your viewpoint. I really admire your patience there, genjix.

[molecular]

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.

It's highly improbably that 50% would be able to evaluate the matter at hand and make that decision within the timeframe that allows to "undo" this without too much damage (blocks mined after questionable block).

So people might come up with the idea of proxying this decision-making. This might put the decision-making into too few hands, of course, and all the decentralization is down the drain.

I don't think this is a good idea, therefore.

Maybe MagicalTux should try to get some insurance against fuckups like this. Might be expensive and put a lot of hassle on him by ways of auditor wanting to see all code pre-production

[Fluttershy]

Thanks for the excellent insight on this, genjix. Deflation through attrition.

Only thing is since you posted, the market's gone back down to nearly what it was before the incident.

[casascius]

...
So people might come up with the idea of proxying this decision-making. This might put the decision-making into too few hands, of course, and all the decentralization is down the drain.

I don't think this is a good idea, therefore.
...

In a way, this has already happened.  Surely the three (or so) largest pools already constitute exactly what you have described.

[molecular]

...
So people might come up with the idea of proxying this decision-making. This might put the decision-making into too few hands, of course, and all the decentralization is down the drain.

I don't think this is a good idea, therefore.
...

In a way, this has already happened.  Surely the three (or so) largest pools already constitute exactly what you have described.

True. I think this is not a good situation.

I've seen in other threads that some people think mining in a bigger pool is more profitable. Pretty sad... there's so many small pools that'd deserve to become medium-sized.

[chickenado]

Maybe MagicalTux should try to get some insurance against fuckups like this. Might be expensive and put a lot of hassle on him by ways of auditor wanting to see all code pre-production

500k BTC are uninsurable, because it is practically impossible to replace them once lost.