Quote from: aliashraf on June 29, 2017, 04:18:17 AM

Let's take a moment and chew it: Current light clients can't check UTXO and prevent double spends, post-SegWit 'semi-ligh' clients can.

The only thing the 'SegWit semi-ligh' client you describe can do is verify that no historical inflation occurred. It cannot be used to verify incoming SegWit payments in a meaningful way beyond what a light client today can do, so it's useless for any economically relevant entity to rely upon.

Quote from: aliashraf on June 29, 2017, 04:18:17 AM

It is how SegWit encourages this kind of nodes and leaves no incentive to remain a prehistoric fat and resource consuming dinosaur. Clear?

Perfectly clear, but I disagree. Nodes can already prune history, and I think in the future nearly every node will. This does not impact security, as they still download and verify everything. If you feel like running a 'semi-ligh' node which is basically useless, still needs to maintain the full UTXO set (likely the largest resource cost of running a node in the near future), and in return only get a small constant factor of bandwidth reduction, be my guest.

Quote from: aliashraf on June 29, 2017, 04:18:17 AM

That 'only' difference is a huge one Roll Eyes

No, it's a technicality. The same data is still committed to in the wtxid. It's just moved.

Quote from: aliashraf on June 29, 2017, 04:18:17 AM

When something is discarded from SHA2 process and txId, it is no longer necessary for validating the integrity of the hashing process and the block header

This is wrong. The witnesses are committed to by the wtxid, which are included in the witness merkle tree, which is committed to by the coinbase, which contributes to the block header.

You cannot change a witness and expect a block to still be valid, except to your pointless 'semi-ligh' node.

Quote from: aliashraf on June 29, 2017, 04:18:17 AM

and we just need UTXO to check double spend and become a full node
... Oops! we got a validator node (in your terminology) without any obligation to store the signatures for future use.

Again, nodes already don't have any obligation to store signatures (or anything) for future use.