Bitcoin Forum
December 06, 2024, 11:14:22 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: A cautionary note: I just forked webbtc.com/bitcoin-ruby via two different ways  (Read 24862 times)
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
February 04, 2014, 03:00:21 AM
Last edit: February 04, 2014, 03:13:22 AM by jl2012
 #21

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

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Peter Todd (OP)
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1164


View Profile
February 04, 2014, 03:15:48 AM
 #22

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
February 04, 2014, 03:37:34 AM
 #23

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



Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Peter Todd (OP)
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1164


View Profile
February 04, 2014, 03:40:05 AM
 #24

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
February 04, 2014, 03:52:44 AM
 #25


    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

    Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
    LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
    PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
    Peter Todd (OP)
    Legendary
    *
    expert
    Offline Offline

    Activity: 1120
    Merit: 1164


    View Profile
    February 04, 2014, 03:53:15 AM
     #26

    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 (OP)
    Legendary
    *
    expert
    Offline Offline

    Activity: 1120
    Merit: 1164


    View Profile
    February 04, 2014, 03:55:47 AM
     #27


      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
      Legendary
      *
      Offline Offline

      Activity: 1792
      Merit: 1111


      View Profile
      February 04, 2014, 04:10:46 AM
       #28


      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.

      Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
      LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
      PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
      Peter Todd (OP)
      Legendary
      *
      expert
      Offline Offline

      Activity: 1120
      Merit: 1164


      View Profile
      February 04, 2014, 04:17:12 AM
       #29


      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.

      jl2012
      Legendary
      *
      Offline Offline

      Activity: 1792
      Merit: 1111


      View Profile
      February 04, 2014, 06:22:11 AM
       #30

      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?

      Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
      LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
      PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
      Peter Todd (OP)
      Legendary
      *
      expert
      Offline Offline

      Activity: 1120
      Merit: 1164


      View Profile
      February 04, 2014, 09:18:40 AM
       #31

      Yup! Good job!

      jl2012
      Legendary
      *
      Offline Offline

      Activity: 1792
      Merit: 1111


      View Profile
      February 04, 2014, 09:29:13 AM
       #32


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

      Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
      LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
      PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
      Peter Todd (OP)
      Legendary
      *
      expert
      Offline Offline

      Activity: 1120
      Merit: 1164


      View Profile
      February 04, 2014, 09:48:33 AM
       #33

      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
      Legendary
      *
      Offline Offline

      Activity: 1792
      Merit: 1111


      View Profile
      February 04, 2014, 10:36:01 AM
       #34

      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?

      Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
      LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
      PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
      Peter Todd (OP)
      Legendary
      *
      expert
      Offline Offline

      Activity: 1120
      Merit: 1164


      View Profile
      February 04, 2014, 01:50:09 PM
       #35

      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
      Legendary
      *
      Offline Offline

      Activity: 1792
      Merit: 1111


      View Profile
      February 05, 2014, 04:24:03 AM
       #36

      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?

      Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
      LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
      PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
      Peter Todd (OP)
      Legendary
      *
      expert
      Offline Offline

      Activity: 1120
      Merit: 1164


      View Profile
      February 05, 2014, 05:51:34 AM
       #37

      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.

      Pages: « 1 [2]  All
        Print  
       
      Jump to:  

      Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!