OP_CHECKSIGVERIFY incorrectly checks for a hash type suffix of signatures about elements HOT 10 CLOSED

concept ACK on creating some sort of algebraic data type, but since types aren't interpreted until they are popped off the stack w/ the given op code in the script i'm not sure that is possible. Is there any specification on what OP_CHECKSIGFROMSTACK does?

Does it verify the data one the stack hashes to the same value which we signed with the private key corresponding to the public key on the stack? What is the use case for this?

from elements.

@Christewart OP_CHECKSIGROMSTACK takes from the stack

1. a pub key
2. a message (arbitrary data)
3. a signature

Then it hashes the message once with SHA256 and does an ECDSA digital signature verification with the pub key and the signature and the hashed message, and pushes the result of that verification.

This signature does not have a sighash-type tacked on the end, so it is one byte shorter than the singature that appears with CHECKSIG. The error is that the code still checks if the last byte of the signature is a valid sighash-type value.

I'm not sure what the principle use case is. Something about bonds.

from elements.

Another possible solution is just appending a hash type, and then replacing pubKey.verify with a custom function that verifies signatures similar to how TransactionSignatureChecker.checkSig does.

from elements.

I think it's a question if the "good" solution is worth the squeeze. As this problem only affects policy, by far the least disruptive change is to simply turn off the strictenc flag for that call, which literally only turns off the sighash type check.

Better solutions require monkeying around with a lot more code. I did figure a one-line change that at least lets us add the signature check to the sigcache, but that's orthogonal to this.

Also, even if we add signature hash types to this type, we still can't simply use the normal calls because the API expects things like scriptCode, etc. It's not super clean and either means we duplicate code or touch consensus-critical API, which results in a HF regardless.

from elements.

It seems you mean CHECKSIGFROMSTACKVERIFY here, right?

from elements.

@instagibbs yes; I've corrected my comment.

from elements.

@instagibbs This is more of a meta question, but how concerned are we about hard forking this blockchain at this early stage? Are we committed to soft forks or can we make sweeping changes that would be easier as a HF. It's not like we have PoW to worry about yet and the system is extremely centralized with 7 functionaries.

from elements.

@Christewart Policy here is to not hard-fork an already-existing chain. Before starting a subsequent chain we can do any changes we like.

from elements.

this should be corrected by adding an exception in the policy in the current elements-0.13.1 codebase.

from elements.

Fixed long ago.

from elements.