Let's look at an example of this type of transaction:
The following example is the same 1-of-2 multi-signature P2WSH script, but nested in a BIP16 P2SH output.
witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig: <0 <32-byte-hash>>
scriptPubKey: HASH160 ...
I suspect it's considered tacky in programmer circles to post an answer to one's own question, but in this case my mistake was rather dangerous so I'd like to share the details with y'all.
My question stated that the public 'push tx' APIs weren't giving viable error messages after refusing my hex-formatted raw transactions. The answer from Mr. Chow ...
I also believe I read that the signature part can account for 65% of the block size.
This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the ...
It's valid. In fact, pasting the transaction here actually shows a little checkmark next to the "signed" icon indicating a proper signature.
It is not valid. That website did not validate anything. It just checked whether there was something in the scriptWitness field, and if there was, it was marked as signed. That checkmark does not mean that it is valid....
What you can spend, and what you can send to depends on the wallet software and nothing else.
There are no inherent restrictions on any combination.
In case someone uses old software, they may not be able to send to bech32 addresses. But they'll get an error that the software doesn't recognize the address; no funds will be lost.
It's important to point out that segwit doesn't prevent malleability: in many ways the actual transaction data can still be changed by third parties. It just makes it harmless for the purposes of dependant transactions/higher level protocols, because when malleated, the resulting transaction will still have the same txid as the original.
To get this ...
Does that mean that non-SegWit transactions are still malleable?
Yes. Segwit does not change non-segwit inputs so the malleability fixes it introduces only apply to segwit inputs.
If so, what types of malleability could still happen in practice?
All of them (except the ones where the sender modifies the transaction himself). None of these are consensus ...
Only the private key for the second input is used in this signature as this signature is only for the second input. The first input is P2PK and is ignored in this example as it is non-segwit so the standard non-segwit sighash algorithm is used for it.
This is unrelated to segregated witness.
Since Bitcoin Core version v0.17, signatures have low R signatures. The signing operating is repeated until an R value is constructed that's below 2255. On average this only takes 2 attempts, but it makes all signatures equally long (71 bytes; rather than 50% 71 bytes and 50% 72 bytes), making them more predictable ...
The public key that you mentioned is indeed the key that was used to derive the P2SH(P2WPKH) address: 35yfMa3CRBiWny8DFdb4tUu9fn7fcdvVp9. The way in which a P2SH(P2WPKH) address is derived is as follows:
1. witness_script = hash160(pub_key) #this is equal to '4b9d2d3dd1174ad656754a0c664e7a129b131f3b'
2. witness_version = 0x00 #current SegWit version