user101041: This is a discussion that has already been had here, but bear with me.
We're gonna be talking about tx faae7e55db14a32e083cbf6a91db8a5ab6a3b05e050d9cefdec80b47f966848e

all I got is the encoded transaction
it has been marked as segwit (marker + flag)
tx has 3 inputs, only the last one is segwit
the segwit input has a script sig: 1600140c6259927541c4f8e88fc1398691e2661d15591a
got to decode the witnesses section correctly, implied there is only one

In the previous discussion, they mentioned that a segwit input is easily spotted as it has an empty script sig.
The segwit input we have here has a script sig... I know it's segwit cause I looked in a blockchain explorer. How can my software programatically tell it's segwit just by looking at the transaction's data?

user208: The way the BIP141 segwit rules consider transactions is simply that every transaction input (even non-segwit ones) have a witness stack. Non-segwit inputs are required to have an empty witness stack however.
If every transaction input has an empty witness stack, the old pre-segwit transaction serialization is used for the transaction. If at least one inout has a non-empty witness stack, the BIP144 transaction serialization format (including marker & flag) is used. The non-segwit inputs then simply have an empty witness.
Now, there is a consensus rule that says that unless a transaction input is a segwit spend, its witness stack must be empty. An input is a segwit spend if the UTXO it spends is a witness program (OP_n + push of 2-40 bytes), or if it is a P2SH UTXO, whose redeemScript is such a witness program. If an input is a segwit spend, the scriptSig must be exactly empty or exactly the P2SH redeemScript and nothing else. If an input is not a segwit spend, the witness stack must be empty. But all of this is rules that govern whether a transaction is valid w.r.t. its witnesses and scriptSigs; it is unrelated to whether the transaction has witnesses.

101041: <p>This is a discussion that has already been had <a href="https://bitcoin.stackexchange.com/questions/68413/how-do-i-determine-whether-an-input-or-output-is-segwit">here</a>, but bear with me.</p>
<p>We're gonna be talking about tx <code>faae7e55db14a32e083cbf6a91db8a5ab6a3b05e050d9cefdec80b47f966848e</code></p>
<ul>
<li>all I got is the encoded transaction</li>
<li>it has been marked as segwit (marker + flag)</li>
<li>tx has 3 inputs, only the last one is segwit</li>
<li>the segwit input has a script sig: <code>1600140c6259927541c4f8e88fc1398691e2661d15591a</code></li>
<li>got to decode the witnesses section correctly, implied there is <code>only one</code></li>
</ul>
<p>In the previous discussion, they mentioned that a segwit input is easily spotted as it has an empty script sig.</p>
<p>The segwit input we have here <code>has a script sig</code>... I know it's segwit cause I looked in a blockchain explorer. How can my software programatically tell it's segwit just by looking at the transaction's data?</p>
 208: <p>The way the BIP141 segwit rules consider transactions is simply that <em>every</em> transaction input (even non-segwit ones) have a witness stack. Non-segwit inputs are required to have an empty witness stack however.</p>
<p>If every transaction input has an empty witness stack, the old pre-segwit transaction serialization is used for the transaction. If at least one inout has a non-empty witness stack, the BIP144 transaction serialization format (including marker &amp; flag) is used. The non-segwit inputs then simply have an empty witness.</p>
<p>Now, there is a consensus rule that says that unless a transaction input is a segwit spend, its witness stack <em>must</em> be empty. An input is a segwit spend if the UTXO it spends is a witness program (OP_n + push of 2-40 bytes), or if it is a P2SH UTXO, whose redeemScript is such a witness program. <em>If</em> an input is a segwit spend, the scriptSig <em>must</em> be exactly empty or exactly the P2SH redeemScript and nothing else. If an input is <em>not</em> a segwit spend, the witness stack must be empty. But all of this is rules that govern whether a transaction is valid w.r.t. its witnesses and scriptSigs; it is unrelated to whether the transaction <em>has</em> witnesses.</p>
