<blockquote>
  <p>Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above?</p>
</blockquote>

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

<blockquote>
  <p>When would I encounter a situation where "all txins in a transaction are not associated with any witness data"</p>
</blockquote>

<p>When you're not spending any SegWit outputs.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>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 <em>in the scriptSig</em> of the inputs - not in the separate witness section.</p>

<blockquote>
  <p>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)?</p>
</blockquote>

<p>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.</p>

CC BY-SA 3.0
2018-01-06T23:21:28.953Z
Thanks, 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
CC BY-SA 3.0
2018-01-07T05:09:39.963Z
That's exactly right.
Pieter Wuille
CC BY-SA 3.0
2018-01-26T01:08:01.547Z
using 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
CC BY-SA 3.0
2018-01-26T04:36:37.320Z
For P2PKH, use P2PKH hashing. For P2WPKH, use BIP143 hashing.
Pieter Wuille
CC BY-SA 3.0
2018-01-06T23:09:39.260Z
2018-01-06T23:09:39.260Z
Pieter Wuille
<p>I'm trying to increase my knowledge of bech32 and SegWit and to that end am working my way through <a href="https://bitcoincore.org/en/segwit_wallet_dev/" rel="noreferrer">this explanation</a>. </p>

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

<pre><code>UXTO #1: 10 BTC (P2PKH)
UXTO #2: 10 BTC (P2WPKH)
</code></pre>

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

<p>So when Jamal constructs his transaction, he'd have:</p>

<pre><code>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)
</code></pre>

<p>(assume zero transaction fees in this example)</p>

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

<p>and next...</p>

<p>Regarding the article <a href="https://bitcoincore.org/en/segwit_wallet_dev/" rel="noreferrer">here</a>: It indicates that there are two supported transaction formats:</p>

<pre><code>(a) nVersion|txins|txouts|nLockTime
(b) nVersion|marker|flag|txins|txouts|witness|nLockTime
</code></pre>

<p>...and then later states that:</p>

<blockquote>
  <p>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)</p>
</blockquote>

<p>My questions are:</p>

<p>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". <strong>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?</strong> 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)?</p>

<segregated-witness><p2wpkh><bech32-address>
Can I mix P2PKH and P2WPKH inputs in the same transaction?
Festus Martingale
# Can I mix P2PKH and P2WPKH inputs in the same transaction?

(Asked by: username_0 on 2018-01-06)

I'm trying to increase my knowledge of bech32 and SegWit and to that end am working my way through [this explanation](https://bitcoincore.org/en/segwit_wallet_dev/).

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](https://bitcoincore.org/en/segwit_wallet_dev/): 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)?

**Tags:** segregated-witness, p2wpkh, bech32-address


---

## 1 answers

### Answer by username_1 on 2018-01-06. Score: 11 | Accepted answer

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

> **Comments:**
> **username_0**: Thanks, 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 ?  
> **username_1**: That's exactly right.  
> **username_0**: using 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?  
> **username_1**: For P2PKH, use P2PKH hashing. For P2WPKH, use BIP143 hashing.  

---

