Timeline for Quadratic hashing problem: Why not just create new OP code "CHECKSIG2" to fix?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 23, 2021 at 18:26 | history | edited | Claris | CC BY-SA 4.0 |
added 133 characters in body
|
| Feb 9, 2017 at 22:53 | comment | added | Nick ODell | That would be a reasonable solution, and it would work well in most cases. However, 143 allows ANYONECANPAY and SINGLE, which wouldn't work if only hashing once. | |
| Feb 9, 2017 at 22:43 | comment | added | pinhead |
Right so why not add a OP_CHECKSIG2 and new tx/address type as a soft fork that hashes the whole tx minus sigs one time and uses that hash for each input?
|
|
| Feb 9, 2017 at 22:36 | comment | added | Nick ODell | That's only for OP_CHECKSIG, correct. The new opcode is a data push of one byte of 0 to 16. | |
| Feb 9, 2017 at 22:31 | comment | added | pinhead |
But it's only critical to consensus for OP_CHECKSIG right? What if there was just a new op code that signed differently?
|
|
| Feb 9, 2017 at 22:28 | comment | added | Nick ODell | Because each hash is hashing something slightly different. The references of BIP143 go into more detail about this, but you should especially look at en.bitcoin.it/wiki/OP_CHECKSIG TL;DR: the input you're signing for has a part of the scriptPubKey of the previous transaction in it. This is consensus-critical; changing it requires a hardfork or the creation of a new way of signing transactions. | |
| Feb 9, 2017 at 21:47 | comment | added | pinhead | I understand that signatures can't be signed, I guess I don't know why the hash for each input Sig is different? If all sigs are removed prior to hashing, why isn't the whole blob hashed just once for the entire transaction? | |
| Feb 9, 2017 at 20:35 | history | answered | Nick ODell | CC BY-SA 3.0 |