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 <scriptSig> then keep the stack and run <scriptPubKey> (which it may already consider valid...?)

I am writing transactions manually and have stumbled across a rather bizarre situation.

Only one in a few of the transactions I broadcast to bitcoind is accepted, otherwise I get a

Code:

REJECT_NONSTANDARD

(Non-canonical DER signature).

So I got my hands dirty and tracked the rejection to be originating from this line: https://github.com/bitcoin/bitcoin/blob/9c5f0d542d1db507b3b9c87bd9de6d0d758d51c1/src/script/interpreter.cpp#L163

I read about DER encoding and checked how IsValidSignatureEncoding is enforcing it, but I do not know why OpenSSL generates not-DER-compliant (r, s) values?

How should I overcome this? I am thinking of something along the lines of (pseudocode):

Code:

Pair (r, s);
do
{
   (r, s) = sign(hash, pvtkey);
} while (r[0] >= 128 || s[0] >= 128); // where r[0], s[0] should be the very first byte of each value

But isn't that kind of redundant? Can I give OpenSSL any flag to produce a valid DER (R, S) pair in the first place?

Hello,

I posted this question on bitcoin.SE so I'll just leave the link here if anyone wants to answer that, but paste the full question here as well.

Link: https://bitcoin.stackexchange.com/questions/79991/how-is-bitcoind-shy-when-exchanging-version-packets

Question:

I am referring to this line of code: https://github.com/bitcoin/bitcoin/blob/be992701b018f256db6d64786624be4cb60d8975/src/net_processing.cpp#L1699

I understand the logic behind not sending a version packet to a newly accepted connection unless they send one first, but the code I linked to does not quite do that, or does it?

At that point we are already inside an if block which verifies that the command received is "version", so the peer has already sent us a version packet, irrespective of who initiated the connection. Am I missing something?