user104637: I tried using the R scanner from the following link https://github.com/ca333/rng-scanner/blob/master/rscan.py, then I got results like this
Bitcoin Address : 3EZ5yV5FARDqEZTXzwWNt33XLVhv7hqAS2
R: 09a8bcef1c9f806b7ba1f6f07d2ac45469a0e860fb14e3e151ce1e710483
TxId : 9ae7ce79fa8501dd92ade347fae7c1737ccefa6db204a2fae485634c265d5494

then I open the transaction link and see the sigscript and witness of the transaction
https://www.blockchain.com/btc/tx/9ae7ce79fa8501dd92ade347fae7c1737ccefa6db204a2fae485634c265d5494

What does sigscript and witness mean of the transaction? Why are the sigscript and witness forms different from the transactions below?
https://www.blockchain.com/btc/tx/c525f9a78b92a1082ef690ef538c803fa4ed2f4b1c008a8effc3cba3ac6773d3


user112589: The scriptSig is a script that is used to satisfy the conditions of a scriptPubKey. Usually, the scriptSig pushes values such as a signature and public key onto the stack which are popped by opcodes such as OP_CHECKSIG in the scriptPublicKey that return a boolean.
The witness data is found in Segwit inputs and has the same information in the scriptSig, except it is interpreted as a stack rather than a script, because the scriptSig is supposed to only push values onto the stack in the first place. The rationale is that the scriptSig can be modified after the transaction has been signed, presenting malleability issues. It is actually changed just once by walle software, after replacing the dummy scriptPubKey script stored in that location with the real scriptSig after the transaction is signed, but there is a potential for it to be misued.
For Segwit inputs, the scriptSig is supposed to be empty (or a push of the redeemscript if it is nested inside a P2SH script) as specified in BIP 141. This is part of the reason why old wallet software can't receive bitcoins from Segwit addresses.

104637: <p>I tried using the R scanner from the following link <code>https://github.com/ca333/rng-scanner/blob/master/rscan.py</code>, then I got results like this</p>

<pre><code>Bitcoin Address : 3EZ5yV5FARDqEZTXzwWNt33XLVhv7hqAS2
R: 09a8bcef1c9f806b7ba1f6f07d2ac45469a0e860fb14e3e151ce1e710483
TxId : 9ae7ce79fa8501dd92ade347fae7c1737ccefa6db204a2fae485634c265d5494
</code></pre>

<p>then I open the transaction link and see the sigscript and witness of the transaction</p>

<pre><code>https://www.blockchain.com/btc/tx/9ae7ce79fa8501dd92ade347fae7c1737ccefa6db204a2fae485634c265d5494
</code></pre>

<p>What does sigscript and witness mean of the transaction? Why are the sigscript and witness forms different from the transactions below?</p>

<pre><code>https://www.blockchain.com/btc/tx/c525f9a78b92a1082ef690ef538c803fa4ed2f4b1c008a8effc3cba3ac6773d3
</code></pre>
 112589: <p>The scriptSig is a script that is used to satisfy the conditions of a scriptPubKey. Usually, the scriptSig pushes values such as a signature and public key onto the stack which are popped by opcodes such as <code>OP_CHECKSIG</code> in the scriptPublicKey that return a boolean.</p>
<p>The witness data is found in Segwit inputs and has the same information in the scriptSig, except it is interpreted as a stack rather than a script, because the scriptSig is supposed to only push values onto the stack in the first place. The rationale is that the scriptSig can be modified after the transaction has been signed, presenting malleability issues. It is actually changed just once by walle software, after replacing the dummy scriptPubKey script stored in that location with the real scriptSig after the transaction is signed, but there is a potential for it to be misued.</p>
<p>For Segwit inputs, the scriptSig is supposed to be empty (or a push of the redeemscript if it is nested inside a P2SH script) as specified in BIP 141. This is part of the reason why old wallet software can't receive bitcoins from Segwit addresses.</p>
