Quote from: xdrpx on November 18, 2016, 04:45:10 PM

How does the separated signatures in scriptPubKey that Segregated Witness nodes will be able to see, be split from the main input field of a transaction while reducing the size of the block? Won't the people running full nodes have to download this separated part of the signature output called segregated witness still and it would still add to additional data being downloaded because now a block can hold and have more capacity + the segwit signatures has to be downloaded as a separate component?

There are now two transaction formats - legacy and segwit.

A node that doesn't support segwit will receive transactions in the legacy format. These transactions will not have the witness data, thus no signatures or public keys. This works because the witness program allows anybody to spend the output. A node that supports segwit will not accept a legacy transaction that attempts to spend an output using a witness program. Thus the need to get 95% of the miners to support segwit.

A non-segwit node won't accept a segwit transaction because the format is invalid by the old rules. So you need to get a large number of non-mining nodes to also support segwit so that the segwit transactions will be relayed across the network.

You have control over the type of transactions that you create since the initial implementation of segwit uses a P2SH address (address starts with '3') instead of a P2PKH address (address starts with '1'). Existing wallets will continue to create legacy transactions that will be accepted by both types of nodes.

I have tested this using my own wallet and Bitcoin Core 0.13.1. Sending a segwit transaction results in a reject with the message that segwit is not active yet. Sending a legacy transaction spending a segwit output results in a reject with the message that the witness data is missing.