Quote from: aleksej996 on October 30, 2017, 10:32:57 AM

You don't really have to trust anyone when using a non-segwit node, I would disagree with that. As a soft fork, segwit doesn't break backwards compatibility. The fact that your node doesn't understand Segwit means that it can't use it, it won't show you the balance of your segwit addresses and it won't be able to send to them. It will just ignore it. Only way you need to trust a Segwit node is if you want to use a segwit address yourself or send to one while running a non-segwit node. It is pretty simple, it is almost like another layer to it from the clear user perspective. What really is happening there is that miners just agreed that they won't confirm certain types of transactions (non-valid segwit transactions), other then that it all seems normal to the old node.

Please learn how bitcoin actually works before trying to answer questions in the technical sub-forums. Your nonsense is not appreciated.

Quote from: pebwindkraft on October 30, 2017, 10:06:19 AM

Further achow101 says: "all witness data stripped out" - I am not yet sure how to interpret this, does it mean that script sig(s) in the legacy format remain empty? That would mean, the legacy client is still able to verify tx contents, but spending is the difference.

The scriptPubKey of the transaction that received the SegWit output contains the Witness Commitment. This commitment looks like an "anyone can pay" script to non-SegWit nodes. So it doesn't matter what is in the scriptSig of the transaction that spends the SegWit output. The non-SegWit node will accept it even if the scriptSig contains an invalid signature.

So, the transaction looks "valid", but to a non-SegWit node the output doesn't look like it is restricted to being spent only by the intended recipient. Then later when it is spent, a SegWit node can look at the witness data and verify that it the spending was properly authorized. Meanwhile, a non-SegWit node believes that the transaction is valid even if it is not properly authorized.

If you are running a SegWit node then you are not trusting anybody, and you are verifying that the transaction is correct (and as such you are verifying that the block containing the transaction is correct). If you are running a non-SegWit node, then you are effectively trusting that the longest chain that you've heard about has been verified by a SegWit node somewhere, since your node won't be able to tell the difference between a valid transaction spending a SegWit output and an invalid transaction spending a SegWit output.

A SegWit node will accept the longest VALID chain. If it hears about a longer chain, but that chain contains an invalid transaction, then the SegWit node will reject that longer chain.