Bitcoin Forum
September 21, 2017, 04:11:42 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why TxPrev.PkScript is inserted into TxCopy during signature check?  (Read 3366 times)
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 535


View Profile WWW
August 22, 2012, 12:59:06 PM
 #1

In the https://en.bitcoin.it/wiki/OP_CHECKSIG wiki, the process behind OP_CHECKSIG is described.

Why  TxPrev.PkScript is inserted into TxCopy ?
(In the source code the method is called SignatureHash() and the temporary tx is TxTmp not TxCopy, and the input is nIn.)

I think that the point is to "mark" the transaction input that is being signed to prevent one signature to be used for more than one input.
But why not only insert a single char '*' into the script of input nIn ? Why a big chunk of the  TxPrev.PkScript is inserted ?

What is the functionality I'm missing?

Thanks, Sergio.







1506010302
Hero Member
*
Offline Offline

Posts: 1506010302

View Profile Personal Message (Offline)

Ignore
1506010302
Reply with quote  #2

1506010302
Report to moderator
1506010302
Hero Member
*
Offline Offline

Posts: 1506010302

View Profile Personal Message (Offline)

Ignore
1506010302
Reply with quote  #2

1506010302
Report to moderator
1506010302
Hero Member
*
Offline Offline

Posts: 1506010302

View Profile Personal Message (Offline)

Ignore
1506010302
Reply with quote  #2

1506010302
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506010302
Hero Member
*
Offline Offline

Posts: 1506010302

View Profile Personal Message (Offline)

Ignore
1506010302
Reply with quote  #2

1506010302
Report to moderator
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1050


View Profile WWW
August 22, 2012, 02:12:00 PM
 #2

Why  TxPrev.PkScript is inserted into TxCopy ?

Ask Satoshi...

(I suspect the answer is that it felt safer to him for some subjective and not very well-founded reason)

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
August 22, 2012, 03:17:22 PM
 #3

I suspect this is left over from the first release of Bitcoin which had a broken way of running scripts - they were literally concatenated with an OP_CODESEPARATOR which meant you could steal anyones money by crafting a custom transaction. It may have been cruft left over from development at that point.
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 535


View Profile WWW
August 22, 2012, 03:25:50 PM
 #4

Very interesting software archeology Smiley

Like a part of DNA of an extinguished specimen that got trapped in the DNA of Bitcoin.

2112
Legendary
*
Offline Offline

Activity: 1946



View Profile
August 22, 2012, 03:36:59 PM
 #5

Very interesting software archeology Smiley
Like a part of DNA of an extinguished specimen that got trapped in the DNA of Bitcoin.
Very wise statement. Bitcoin is like amber, the bugs inside are to be admired for their beauty as long as possible.
https://bitcointalk.org/index.php?topic=46498.msg556688#msg556688

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
mmeijeri
Hero Member
*****
Online Online

Activity: 714

Martijn Meijering


View Profile
December 24, 2013, 08:37:26 PM
 #6

I think that the point is to "mark" the transaction input that is being signed to prevent one signature to be used for more than one input.

Doesn't the signature already apply to the hash of the previous transaction and the index in it? Why would you need any additional data at all?

ROI is not a verb, the term you're looking for is 'to break even'.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
December 24, 2013, 11:53:45 PM
 #7

I think that the point is to "mark" the transaction input that is being signed to prevent one signature to be used for more than one input.

Doesn't the signature already apply to the hash of the previous transaction and the index in it? Why would you need any additional data at all?

Bitcoin prior to the v0.1 release had a system where the scriptSig and scriptPubKey were concatenated prior to evaluation; OP_CODESEPARATOR was included in scripts (or scriptSigs) explicitly to mark what part of that concatenated script was to be hashed. The mechanism was broken because OP_RETURN could be used in a scriptSig to return prematurely, but other than that oversight the idea was sound. (the actual v0.1 release inserted OP_CODESEPARATOR explicitly prior to calling EvalScript, breaking the idea, so I'm not sure if Satoshi actually realized what could have been made possible)

Inserting this script into the txcopy scriptSig was the mechanism by which items in the scriptSig could be included in the signature. Something interesting about SignatureHash is you can use non-standard hashtypes in a backwards compatible way: nHashType is ANDed with mask 0x1f, or 0b00011111, prior to testing against SIGHASH_SINGLE and SIGHASH_NONE, which means that if they are set to anything other than those two values the signature hash is calculated without modifying vout. Similarly bits 6 and 7 of nHashType are completely ignored. Had the original design been kept additional SignatureHash() flags could have easily and efficiently been added in a soft-fork, for instance:

scriptPubKey: <pubkey> OP_CHECKSIG
scriptSig: <additional hashed data> <signature>

OP_CHECKSIG has defunct code to remove the signature from the concatenated script prior to calling SignatureHash(), so the final concatenated script inserted into the txin scriptSig would be:

<additional hashed data> <pubkey> OP_CHECKSIG

That additional hashed data could have be, for instance, the hash of the values going into the transaction to allow for signatures to cover fees. Similarly it could have been used with SIGHASH_NONE to redefine how signatures worked. Though note that for this to be a soft fork failure to match that additional data would have to be handled with as an immediate fail, turning OP_CHECKSIG into OP_CHECKSIGVERIFY with respect to the new features.

Having said that we can still do this, although it gets less efficient. Basically you just make an entire second signature, ~72 bytes worth, and have the special signature hash bits trigger the OP_CHECKSIG code to check it as well. For instance:

scriptPubKey: <pubkey> OP_CHECKSIG
scriptSig: <sig2> <sig1>

Where sig1 uses the old signature algorithm, and sig2 uses a new algorithm. For pre-soft-fork nodes sig2 is just useless data and does nothing, but for post-soft-fork nodes if sig2 is invalid the transaction fails.

mmeijeri
Hero Member
*****
Online Online

Activity: 714

Martijn Meijering


View Profile
December 25, 2013, 11:37:03 AM
 #8

(the actual v0.1 release inserted OP_CODESEPARATOR explicitly prior to calling EvalScript, breaking the idea, so I'm not sure if Satoshi actually realized what could have been made possible)

It seems so needlessly complicated that it must have had a reason. I wonder if maybe he intended to add a 'sticky' flag that required conditions on an output to be concatenated onto any new outputs it was spent to. The whole thing is very confusing to me though, and I'm having great trouble understanding your post.

ROI is not a verb, the term you're looking for is 'to break even'.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
December 26, 2013, 01:31:21 AM
 #9

(the actual v0.1 release inserted OP_CODESEPARATOR explicitly prior to calling EvalScript, breaking the idea, so I'm not sure if Satoshi actually realized what could have been made possible)

It seems so needlessly complicated that it must have had a reason. I wonder if maybe he intended to add a 'sticky' flag that required conditions on an output to be concatenated onto any new outputs it was spent to. The whole thing is very confusing to me though, and I'm having great trouble understanding your post.

It's confusing to me too; I didn't clue into the soft-fork stuff until about the third or fourth time I looked at that code.

Keep in mind Bitcoin had pretty poor software engineering in v0.1, so finding features that turned out to be poorly thought through shouldn't be surprising.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!