script

[FabioCarpi]

im making a script execution routine in my program
for the multisig sig (ex: https://blockchain.info/pt/tx-index/70071473), have a OP_FALSE in the beginning
in the manual (https://en.bitcoin.it/wiki/Script), says the OP_FALSE put a blank value in the stack...
in my test, i got this

Code:

array (size=5)
  0 => string '' (length=0)
  1 => string '3045022015bd388f4be0da8fec78920d4651dc9da4a38efc97c2c956e1e5ccacec9d8d5d022100d69519f5362dedf2c7175693f001b1d253255a91068ce6561c57b366eb9e8adf01' (length=144)
  2 => string '304502207f0fdb0c5ff38c1237e31c9f96fd89461280cc9d3cc01eb954c8e7d8600a0926022100e55357b75648867503ae7d7a19e3a28adea46ba7f0f6b222db2fa01b8618c2c201' (length=144)
  3 => string '522102138eb535f6ea4aaf6898cacb7ddca70d82d85cc84e0a69ae08158f0fc066b0d92102d1e6d254e0a396c9f25e3bc2a4a98f68e7911a938e4b1608d53232e67ca7e4bd52ae' (length=142)
  4 => boolean true

Its correct? And this op_false is for what?

[1714790842]

1714790842

[1714790842]

1714790842

[amaclin]

Look here:
http://webbtc.com/tx/01ca013ca48b3dde57227086fbb884933cc24054578cb68bc7caeb4fb082638f

This is the same transaction.
But webbtc service has a feature "Debug --> Run Script" (at the right side)

Follow to http://webbtc.com/script/01ca013ca48b3dde57227086fbb884933cc24054578cb68bc7caeb4fb082638f:0
and look to "Execution Trace" : what operations are executed and what is the stack state

[FabioCarpi]

great site
thanks a lot

[doof]

great site
thanks a lot

Agreed.  Will book mark this one.

[Saitteld]

OP_FALSE is needed due to a bug in OP_CHECKMULTISIG. See https://en.bitcoin.it/wiki/Script#Crypto "Due to a bug, one extra unused value is removed from the stack." No, this bug should not be fixed

Another visualization of script execution: https://curiosity-driven.org/bitcoin-contracts See: Escrow - Executing script.

[readerbtc]

No, this bug should not be fixed

Why not? Sure, it would be a hard fork, but couldn't clients consider block height when executing opcodes and behave accordingly?

[amaclin]

Why not? Sure, it would be a hard fork, but couldn't clients consider block height when executing opcodes and behave accordingly?

Do you want to upgrade all clients in the world?
Tell me how to do it 

[readerbtc]

Won't they be upgraded, soon or later? I mean, hard forks will happen.

[Saitteld]

Either way Bitcoin is an interesting piece of software that needs to not only be backwards-compatible but forwards-compatible too.

Hard fork problem stems from old, not upgraded clients, they'd use the old logic and we can't ignore them. Just like amaclin said it's not upgrading most of the clients, it's upgrading all of them. And yes, in ideal world everyone would update and the bug would be fixed. But Bitcoin client does not have a spec so basically the Bitcoin Core code is the spec. Looking from this perspective maybe we shouldn't call this a "bug"?

By the way there are more interesting ... issues like that, see SIGHASH_SINGLE behavior when the number of inputs != number of outputs ( https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_SINGLE ).

[amaclin]

Looking from this perspective maybe we shouldn't call this a "bug"?

This is bug. Definitely a bug. The insect that we did not want to be here.
But this is a bug in a consensus code.
So, this is a bug in an amber
https://upload.wikimedia.org/wikipedia/commons/b/b6/Amber2.jpg

[readerbtc]

Looking from this perspective maybe we shouldn't call this a "bug"?

This is bug. Definitely a bug. The insect that we did not want to be here.
But this is a bug in a consensus code.
So, this is a bug in an amber
https://upload.wikimedia.org/wikipedia/commons/b/b6/Amber2.jpg

#liked

[gmaxwell]

That checkmultisig reads an extra element could be used in the future to make batch validation faster (as it needs some additional side information), or for other extensions.  It's commonly assumed to be a bug that it reads an extra item but might have just as well been another forward compatibility mechanism, or a left over behavior from an earlier approach.

[readerbtc]

That checkmultisig reads an extra element could be used in the future to make batch validation faster (as it needs some additional side information), or for other extensions.  It's commonly assumed to be a bug that it reads an extra item but might have just as well been another forward compatibility mechanism, or a left over behavior from an earlier approach.

I like bitcoin because it screws my notions of what is software.