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.
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)?