Skip to main content
Bitcoin

Return to Question

edited tags
Link
Murch ♦
Murch ♦
  • 77.9k
  • 35
  • 190
  • 641
Tweeted twitter.com/StackBitcoin/status/914266464634507265
Bumped by Community user
Bumped by Community user
Bumped by Community user
added 6 characters in body
Source Link
sr_gi
sr_gi
  • 3.3k
  • 1
  • 14
  • 37

As far as I know, the quadratic hashing problem came from the fact that every time a transaction is verified (or signed), the "unsigned transaction" that is hashed and verified changes depending on the transaction input that is being analysed. Basically, the target input ScriptSig is set to the ScriptPubKey of the UTXO to be redeemed, while the other inputs are emptiedleft empty.

However, what I can't see is what's the reason behind that. Why aren't all the ScriptSig fields assigned either to their UTXO ScriptPubkey field, or left empty? The way it was designed doesn't seems to provide any kind of benefit (at least I can't see it), while it makes you recreaterecalculate the double-sha256 every single time an input is analysed, leading to a quadratic hashing problem.

As far as I know, the quadratic hashing problem came from the fact that every time a transaction is verified (or signed), the "unsigned transaction" that is hashed and verified changes depending on the transaction input that is being analysed. Basically, the target input ScriptSig is set to the ScriptPubKey of the UTXO to be redeemed, while the other inputs are emptied.

However, what I can't see is what's the reason behind that. Why aren't all the ScriptSig fields assigned either to their UTXO ScriptPubkey field, or left empty? The way it was designed doesn't seems to provide any kind of benefit (at least I can't see it), while it makes you recreate the double-sha256 every single time an input is analysed, leading to a quadratic hashing problem.

As far as I know, the quadratic hashing problem came from the fact that every time a transaction is verified (or signed), the "unsigned transaction" that is hashed and verified changes depending on the transaction input that is being analysed. Basically, the target input ScriptSig is set to the ScriptPubKey of the UTXO to be redeemed, while the other inputs are left empty.

However, what I can't see is what's the reason behind that. Why aren't all the ScriptSig fields assigned either to their UTXO ScriptPubkey field, or left empty? The way it was designed doesn't seems to provide any kind of benefit (at least I can't see it), while it makes you recalculate the double-sha256 every single time an input is analysed, leading to a quadratic hashing problem.

Source Link
sr_gi
sr_gi
  • 3.3k
  • 1
  • 14
  • 37

ScriptSig content during signature (quadratic hashing)

As far as I know, the quadratic hashing problem came from the fact that every time a transaction is verified (or signed), the "unsigned transaction" that is hashed and verified changes depending on the transaction input that is being analysed. Basically, the target input ScriptSig is set to the ScriptPubKey of the UTXO to be redeemed, while the other inputs are emptied.

However, what I can't see is what's the reason behind that. Why aren't all the ScriptSig fields assigned either to their UTXO ScriptPubkey field, or left empty? The way it was designed doesn't seems to provide any kind of benefit (at least I can't see it), while it makes you recreate the double-sha256 every single time an input is analysed, leading to a quadratic hashing problem.