Can I mix P2PKH and P2WPKH inputs in the same transaction?

I'm trying to increase my knowledge of bech32 and SegWit and to that end am working my way through this explanation.

Here's a hypothetical situation I'm trying to understand. Let's say Jamal has access to a a couple of UXTOs.

UXTO #1: 10 BTC (P2PKH)
UXTO #2: 10 BTC (P2WPKH)

Further, let's say Jamal wants to send 11 BTC to Tyrone. Tyrone provides a bech32 address of BC1_XXX.

So when Jamal constructs his transaction, he'd have:

Inputs: 
    UXTO#1 10 BTC (P2PKH)
    UXTO#2 10 BTC (P2WPKH)

Outputs
    BC1_XXX 11 BTC
    BC1_CHANGE 9 BTC (a newly created P2WPKH address)

(assume zero transaction fees in this example)

Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above? None of the examples I've viewed thus far have covered this scenario.

and next...

Regarding the article here: It indicates that there are two supported transaction formats:

(a) nVersion|txins|txouts|nLockTime
(b) nVersion|marker|flag|txins|txouts|witness|nLockTime

...and then later states that:

If all txins in a transaction are not associated with any witness data, the transaction MUST be serialized in the original transaction format, without marker, flag, and witness. For example, if none of the txins are coming from segwit UTXO, it MUST be serialized in the original transaction format. (exception: coinbase transaction)

My questions are:

When would I encounter a situation where "all txins in a transaction are not associated with any witness data"? It says this situation would arise if "none of the txins are coming from segwit UTXO". But even in the case where the inputs came exclusively from P2PKH (not P2WPKH) UTXOs, wouldn't I still have witness data (i.e. the signatures) that need to be "segregated" at in the 'witness' portion of the transaction? Or is it saying that if all inputs are non-segwit, it means the transaction itself is non-segwit, and I should therefore use format (a) -- despite having segwit output(s)?

Festus Martingale

Posted 2018-01-06T22:57:19.300

Reputation: 683

Answers

Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above?

Yes, absolutely. In the same way that you can mix multisig and P2SH and P2PK inputs in the same transaction.

When would I encounter a situation where "all txins in a transaction are not associated with any witness data"

When you're not spending any SegWit outputs.

But even in the case where the inputs came exclusively from P2PKH (not P2WPKH) UTXOs, wouldn't I still have witness data (i.e. the signatures) that need to be "segregated" at in the 'witness' portion of the transaction?

No, those signatures would be "witness data" (in an abstract sense), but they're not segregated. Spends of P2PKH outputs require a pubkey and signature in the scriptSig of the inputs - not in the separate witness section.

Or is it saying that if all inputs are non-segwit, it means the transaction itself is non-segwit, and I should therefore use format (a) -- despite having segwit output(s)?

Exactly. When you're using P2SH, nobody even knows the outputs are SegWit outputs, so it clearly can't matter. All that matters is whether any witnesses are needed for spending.

Pieter Wuille

Posted 2018-01-06T22:57:19.300

Reputation: 54 032

1Thanks, man. That's great info. So to confirm: in the Jamal/Tyrone example, where the inputs contain one P2PKH and one P2WPKH, the transaction will follow transaction format B and furthermore, the signature for the P2PKH input will be included in the ScriptSig while the signature for the P2WPKH input will be included in the witness section ? – Festus Martingale – 2018-01-06T23:21:28.953

1That's exactly right. – Pieter Wuille – 2018-01-07T05:09:39.963

1using this same example, when creating my signature for the P2PKH input, shall I sign a hash based on the new digest algorithm presented in BIP 143 or shall I sign a hash based on the original digest algorithm that I've used in the past for purely P2PKH (non-segwit) transactions? – Festus Martingale – 2018-01-26T01:08:01.547

2For P2PKH, use P2PKH hashing. For P2WPKH, use BIP143 hashing. – Pieter Wuille – 2018-01-26T04:36:37.320