A cautionary note: I just forked webbtc.com/bitcoin-ruby via two different ways

[jl2012]

Here's a good test if you think you have a hope of re-implementing Bitcoin exactly: a59012de71dafa1510fd57d339ff488d50da4808c9fd4c001d6de8874d8aa26d

Tell me how that transaction got mined in detail.

The HASH160 of 0xac91 is 0x827fe37ec405346ad4e995323cea83559537b89e so it is valid?

EDIT: The HASH160 of 0xac is 0x17be79cf51aa88feebb0a25e9d6a153ead585e59

So actually there is no CHECKSIG done here

[Peter Todd]

Here's a good test if you think you have a hope of re-implementing Bitcoin exactly: a59012de71dafa1510fd57d339ff488d50da4808c9fd4c001d6de8874d8aa26d

Tell me how that transaction got mined in detail.

The HASH160 of 0xac91 is 0x827fe37ec405346ad4e995323cea83559537b89e so it is valid?

EDIT: The HASH160 of 0xac is 0x17be79cf51aa88feebb0a25e9d6a153ead585e59

So actually there is no CHECKSIG done here

You need to learn how P2SH works: BIP16

[jl2012]

Here's a good test if you think you have a hope of re-implementing Bitcoin exactly: a59012de71dafa1510fd57d339ff488d50da4808c9fd4c001d6de8874d8aa26d

Tell me how that transaction got mined in detail.

The HASH160 of 0xac91 is 0x827fe37ec405346ad4e995323cea83559537b89e so it is valid?

EDIT: The HASH160 of 0xac is 0x17be79cf51aa88feebb0a25e9d6a153ead585e59

So actually there is no CHECKSIG done here

You need to learn how P2SH works: BIP16

Yes, I was wrong.

For the second input, the serialized script is simply OP_CHECKSIG. So one can use ANY public key with a correct signature to redeem it, right? (normally, the public key is part of the serialized script)

For the first one, the serialized script is OP_CHECKSIG OP_NOT. So one can use any public key with a WRONG signature to redeem it.

I didn't check the validity of the signature but obviously they use the same signature and public key...... So there must be something wrong in my interpretation....

[Peter Todd]

Yes, I was wrong.

For the second input, the serialized script is simply OP_CHECKSIG. So one can use ANY public key with a correct signature to redeem it, right? (normally, the public key is part of the serialized script)

For the first one, the serialized script is OP_CHECKSIG OP_NOT. So one can use any public key with a WRONG signature to redeem it.

I didn't check the validity of the signature but obviously they use the same signature and public key...... So there must be something wrong in my interpretation....

Compare the scriptSigs against the one in this transaction: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f

[jl2012]

Compare the scriptSigs against the one in this transaction: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f

I can't read C++, but it seems it works like this:

• For the first input, it is an invalid SIGHHASH_SINGLE signature, so the overall script is valid (with OP_NOT)

• For the second input, for the same reason as 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f, it is valid

[Peter Todd]

Also, here's another fun puzzle: 61d47409a240a4b67ce75ec4dffa30e1863485f8fe64a6334410347692f9e60e

How is the byte string 000080 not true, yet any other non-zero bytestring does evaluate as true?

[Peter Todd]

Compare the scriptSigs against the one in this transaction: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f

I can't read C++, but it seems it works like this:

• For the first input, it is an invalid SIGHHASH_SINGLE signature, so the overall script is valid (with OP_NOT)

• For the second input, for the same reason as 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f, it is valid

[/list]

Ok, but then if the signature is valid on the second input, how can the exact same signature be valid for a totally different transaction spending normal inputs? (the second one I provided, 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f)

[jl2012]

Ok, but then if the signature is valid on the second input, how can the exact same signature be valid for a totally different transaction spending normal inputs? (the second one I provided, 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f)

Didn't you explain it in the OP? If one uses SIGHASH_SINGLE without a corresponding output, a signature for 0000000000000000000000000000000000000000000000000000000000000001 is valid

BTW, there is a typo on the wiki:
https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_SINGLE

The transaction that uses SIGHASH_SINGLE type of signature should not have more outputs inputs than inputs outputs.

[Peter Todd]

Ok, but then if the signature is valid on the second input, how can the exact same signature be valid for a totally different transaction spending normal inputs? (the second one I provided, 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f)

Didn't you explain it in the OP? If one uses SIGHASH_SINGLE without a corresponding output, a signature for 0000000000000000000000000000000000000000000000000000000000000001 is valid

Yup, exactly - come to think of it the example would have been better done by spending three outputs, with two valid-yet-the-same-signature ones.

BTW, there is a typo on the wiki:
https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_SINGLE

The transaction that uses SIGHASH_SINGLE type of signature should not have more outputs inputs than inputs outputs.

Thanks, fixed.

[jl2012]

Also, here's another fun puzzle: 61d47409a240a4b67ce75ec4dffa30e1863485f8fe64a6334410347692f9e60e

How is the byte string 000080 not true, yet any other non-zero bytestring does evaluate as true?

https://en.bitcoin.it/wiki/Script

The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

so 000080 = 0?

[Peter Todd]

Yup! Good job!

[jl2012]

Ok, but then if the signature is valid on the second input, how can the exact same signature be valid for a totally different transaction spending normal inputs? (the second one I provided, 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f)

Didn't you explain it in the OP? If one uses SIGHASH_SINGLE without a corresponding output, a signature for 0000000000000000000000000000000000000000000000000000000000000001 is valid

Yup, exactly - come to think of it the example would have been better done by spending three outputs, with two valid-yet-the-same-signature ones.

Is this behavior intentional (with legitimate use) or unintentional (aka. bug)?

[Peter Todd]

Is this behavior intentional (with legitimate use) or unintentional (aka. bug)?

Definitely a bug. If SignatureHash() had returned 0 in that case rather than 1 you could use it to steal everyone's coins apparently due to how ECC signatures work.

[jl2012]

Is this behavior intentional (with legitimate use) or unintentional (aka. bug)?

Definitely a bug. If SignatureHash() had returned 0 in that case rather than 1 you could use it to steal everyone's coins apparently due to how ECC signatures work.

Somewhere I read Gavin said that there was a bug that allow everyone to spend everyone's coins (now fixed). Do you know which one he was referring to?

[Peter Todd]

Somewhere I read Gavin said that there was a bug that allow everyone to spend everyone's coins (now fixed). Do you know which one he was referring to?

Hint: The OP_RETURN opcode used to return true, not false.

Why is that a problem?

[jl2012]

Somewhere I read Gavin said that there was a bug that allow everyone to spend everyone's coins (now fixed). Do you know which one he was referring to?

Hint: The OP_RETURN opcode used to return true, not false.

Why is that a problem?

I find your conversation with Gavin here: http://sourceforge.net/mailarchive/forum.php?thread_name=CANEZrP3qgo-VC5YHTSLOH5rGdv5PP4e2V6qECQVfvMgJXFbx-g@mail.gmail.com&forum_name=bitcoin-development

It seems to me that a script was always declared as true when it hit an OP_RETURN, and the rest of the script was ignored. So the fix was to make OP_RETURN returning false, and to execute the scriptSig and scriptPubKey separately. So even if the scriptSig is true, it still needs to run the scriptPubKey.

So what will happen in this case now? : scriptSig = OP_FALSE, scriptPubKey = OP_NOT. As the scriptSig is false, will it stop there as false, or the scriptPubKey will make the overall outcome as true?

[Peter Todd]

I find your conversation with Gavin here: http://sourceforge.net/mailarchive/forum.php?thread_name=CANEZrP3qgo-VC5YHTSLOH5rGdv5PP4e2V6qECQVfvMgJXFbx-g@mail.gmail.com&forum_name=bitcoin-development

It seems to me that a script was always declared as true when it hit an OP_RETURN, and the rest of the script was ignored. So the fix was to make OP_RETURN returning false, and to execute the scriptSig and scriptPubKey separately. So even if the scriptSig is true, it still needs to run the scriptPubKey.

Roughly correct, except that the scriptSig doesn't return a value, it returns a stack. Same with the scriptPubKey really, it's  just in that case we take the top value of that stack to determine if the script succeeded or not.

So what will happen in this case now? : scriptSig = OP_FALSE, scriptPubKey = OP_NOT. As the scriptSig is false, will it stop there as false, or the scriptPubKey will make the overall outcome as true?

Right, since it returns a stack, not a value, the scriptPubKey is executed and the overall outcome is true.

Speaking of, OP_RETURN doesn't really return false, rather, it makes the script fail. It probably would have been better called OP_FAIL.