ビットコインの課題として、署名検証に影響を与えずにTXID（トランザクションの識別子）の異なるトランザクションを作れてしまうという、トランザクションのmalleability問題が存在します。
この問題がどうやって起きているのかというと、まずトランザクションに署名するということは、トランザクションの署名対象データ（unlocking script以外）のハッシュ値を生成し、そのハッシュ値に秘密鍵で署名し、その署名データをunlocking scriptにセットすることです。
そして、検証はこれを復号したものと署名対象データのハッシュ値が一致するかどうかを見ます。
以上から、unlocking scriptを改ざん（署名スクリプトの処理に影響のないデータをプッシュするなどしてできる）しても署名検証には影響を与えないことが分かります。
しかし、TXIDは、unlocking scriptも含めたデータから生成されるので、malleability問題が起こってしまいます。
それを根本的に解決するのがSegregated Witness（Segwit）です。
Segwitでは、トランザクションのインプットから署名を分離し、署名を別のデータ領域（witness）に移動することでこの問題を解決します。
未署名の状態でもTXIDが確定するので、未署名なトランザクションをインプットにしたトランザクションチェーンを作ることができるようになります。
この特性がLIghtning Networkなどで利用される双方向のマイクロペイメントチャネルの構築の際にも利用されています。
Segwitがアクティベートされても、それ以降作成するトランザクションがすべて無条件にSegwitのトランザクションになるわけではありません。
P2PKHやP2SHの形式で記述されたlocking scriptを持つUTXOを使用する際は、今まで通りインプットに署名をセットすることになります。
では具体的にSegwitが利用できるケースはというとlocking scriptに特別な意味を持つスクリプトがセットされているケースになります。
その場合の形式はP2PKHに対応する形でP2WPKH、P2SHに対応する形でP2WSHと呼ばれます。
また、これまではビット列を文字列に変換する際Base58というフォーマットを使っていましたが、SegwitではBech32という新しいフォーマットを使うそうです。
以上のように、Segwitを使うには色々ルールの変更があるみたいで、他にもブロックサイズの計算ルールが変更され、block weightと呼ばれる概念が追加されます。
これにより、ブロックに入れられるトランザクションの数が多少増えるみたいですが、恐らくこれは副次的な効果で、本質は初めにも述べたようにmalleability問題を解決することで、オフチェーンを使うペイメントチャネルを構築し、スケーラビリティ問題の解決を目指すという所だと思います。
