are you on testnet or regtest? I'd be interested to see the example, I have from time to time similiar "experience"...
It is clear, that bitcoin demands for the shortest representation of data. So you have to use (from the wiki https://en.bitcoin.it/wiki/Script):
0x01-0x4b (special) ... The next opcode bytes is data to be pushed onto the stack
for data, which has less than 75 OpCodes.
I'd just like to play with the examples on regtest ...
Topic: scriptPubKey not verified upon locking, but when trying to unlock it - page 2. (Read 403 times)
November 01, 2018, 03:07:13 AM
October 31, 2018, 09:34:24 AM
I've been playing with multisig transactions today and I wrote a transaction that would lock the funds with the following scriptPubKey: (not using P2SH !)
<2> pubkey1 pubkey2 pubkey3 <3> OP_CHECKMULTISIG
When I wrote the actual hex for that, I used wrong opcodes for pushing to the stack, basically for pushing "2" I used a "0102" command, just like I saw pushing to the stack works with larger values encountered in signatures and pubkeys (0x47/48 for sigs, 0x21 (33 in decimal) for pubkeys, etc). I did not know there are special opcodes with meaning "push this exact value to the stack".
But guess what, my transaction was broadcast successfully...
Now when I tried to spend those funds, I kept getting: mandatory-script-verify-flag-failed (Data push larger than necessary) (code 16)
So I spent couple hours debugging the raw hex digit by digit trying to figure out what the hell was wrong. But of course there was nothing wrong with this spending hex, the problem was already irreversible (funds lost forever in the first transaction). I got to the bottom of it by printing the whole "trouble script" in bitcoind and recompiling, that's how I saw it has nothing to do with my spending scriptSig but with the previous scriptPubKey.
Now I have 2 questions about all this:
1) why it worked in the first place, doesn't the scriptPubKey go via the same validation rules as the scriptSig ?
2) why would bitcoind even care about the scriptPubKey of the UTXO i'm trying to spend, i thought it was supposed to just first run then keep the stack and run (which it may already consider valid...?)
<2> pubkey1 pubkey2 pubkey3 <3> OP_CHECKMULTISIG
When I wrote the actual hex for that, I used wrong opcodes for pushing to the stack, basically for pushing "2" I used a "0102" command, just like I saw pushing to the stack works with larger values encountered in signatures and pubkeys (0x47/48 for sigs, 0x21 (33 in decimal) for pubkeys, etc). I did not know there are special opcodes with meaning "push this exact value to the stack".
But guess what, my transaction was broadcast successfully...
Now when I tried to spend those funds, I kept getting: mandatory-script-verify-flag-failed (Data push larger than necessary) (code 16)
So I spent couple hours debugging the raw hex digit by digit trying to figure out what the hell was wrong. But of course there was nothing wrong with this spending hex, the problem was already irreversible (funds lost forever in the first transaction). I got to the bottom of it by printing the whole "trouble script" in bitcoind and recompiling, that's how I saw it has nothing to do with my spending scriptSig but with the previous scriptPubKey.
Now I have 2 questions about all this:
1) why it worked in the first place, doesn't the scriptPubKey go via the same validation rules as the scriptSig ?
2) why would bitcoind even care about the scriptPubKey of the UTXO i'm trying to spend, i thought it was supposed to just first run
Jump to: