Pages:
Author

Topic: A cautionary note: I just forked webbtc.com/bitcoin-ruby via two different ways (Read 24873 times)

legendary
Activity: 1120
Merit: 1164
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.
legendary
Activity: 1792
Merit: 1111
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?
legendary
Activity: 1120
Merit: 1164
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?
legendary
Activity: 1792
Merit: 1111
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?
legendary
Activity: 1120
Merit: 1164
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.
legendary
Activity: 1792
Merit: 1111

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)?
legendary
Activity: 1120
Merit: 1164
legendary
Activity: 1792
Merit: 1111
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
Quote
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?
legendary
Activity: 1120
Merit: 1164

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

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

Thanks, fixed.
legendary
Activity: 1792
Merit: 1111

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

Quote
The transaction that uses SIGHASH_SINGLE type of signature should not have more outputs inputs than inputs outputs.
legendary
Activity: 1120
Merit: 1164

    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)
    legendary
    Activity: 1120
    Merit: 1164
    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?
    legendary
    Activity: 1792
    Merit: 1111

      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
      legendary
      Activity: 1120
      Merit: 1164
      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
      legendary
      Activity: 1792
      Merit: 1111
      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....


      legendary
      Activity: 1120
      Merit: 1164
      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
      legendary
      Activity: 1792
      Merit: 1111
      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
      legendary
      Activity: 1120
      Merit: 1164
      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.
      legendary
      Activity: 1120
      Merit: 1164
      ...and webbtc/coinbase is forked yet again on 0000000000000001e4241fd0b3469a713f41c5682605451c05d3033288fb2244

      Probably tx df95ff9ac165abe7adb0091b5f1020c25203fd0c16c95b4c7fa6a4475428ef1f, although there's a bunch of other possibilities in there.
      sr. member
      Activity: 263
      Merit: 250
      Pages:
      Jump to: