Is Segwit really safe and reduced? In the Segwit rules, transactions propagated to legacy node doesn't have any signature. so it will be valid as well as in terms of fresh node(supporting Segwit).

First question:


  In this point, if Bob make a fraud transaction with Segwit, legacy
  node will accept, but it is not accepted in terms of fresh node. so,
  some group(legacy nodes) accept, other some groups(fresh nodes)
  doesn't accept. it means that proportion of fresh node should be
  bigger than proportion of legacy node. I think that this is really
  critical issue but current Bitcoin works well. we can say proportion
  of fresh node is bigger than legacy groups, but how it was achieved?
   when Segwit is appeared, at this time proportion of fresh node is
  maybe too small to overtake legacy groups.


Last question:


  Block size is physically 1MB. Regardless of the calculation rule is
  'Weight' or 'Bytes', the transaction size is always same physically. 
  Why some guys says that Segwit transaction is compact than traditional
  transaction?
  Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.


Sorry for my English.
In this point, if Bob make a fraud transaction with Segwit, legacy
  node will accept, but it is not accepted in terms of fresh node. so,
  some group(legacy nodes) accept, other some groups(fresh nodes)
  doesn't accept. it means that proportion of fresh node should be
  bigger than proportion of legacy node. I think that this is really
  critical issue but current Bitcoin works well. we can say proportion
  of fresh node is bigger than legacy groups, but how it was achieved?
   when Segwit is appeared, at this time proportion of fresh node is
  maybe too small to overtake legacy groups.


Segwit did not just show up out of nowhere with no warning and no software to enforce it. Segwit capable software was released long before its activation, thus allowing for sufficient time for nodes to upgrade.

As with all previous soft forks, the activation time was determined well in advance (kind of). It wasn't scheduled (one soft fork  did have a scheduled activation), but rather required that miners signal readiness to enforce Segwit's rules before they would actually activate and be enforced by nodes on the network. This signalling was done by setting a particular bit in the block version number. 1916 out of a period of 2016 blocks must have the bit set in order for the rules to be activated.

Furthermore, even after the signalling threshold was reached, there would still be another 2016 block grace period where Segwit is "locked in" but not yet active. This is just a grace period for people who haven't upgraded yet to upgrade now that they know that the Segwit rules are going to activate. After the grace period, the rules will activate.

With even the fastest activation (everyone started signalling as soon as possible and the threshold is reached in  the first signalling period), there are ~4 weeks from time of "release" to activation  for people to upgrade. It is likely that there wouldn't be a majority, but at the very least, miners would have upgraded and enforced the rules (in the ideal case, but reality does say otherwise). And once the fork becomes "locked in", it can be expected that many more people will upgrade as they do see the importance of enforcing all rules in effect.

In addition to the time it would take for signalling and lock in, there is also the signalling start time. Miners could only begin signalling for segwit activation after a predetermined time. Any signalling before that time would be ignored. This start time was set to be a few weeks after the release of the first mainnet segwit capable software. Specifically, Bitcoin Core 0.13.1 was released on Oct. 27, 2016. The start time was defined to be Midnight Nov. 15, 2016 UTC. So there was almost 3 weeks between the release of the software and the beginning of the first signalling period. In total, ~7 weeks between the  release of the software and the first possible activation time. This is sufficient time  for many nodes to upgrade, and ideally, enough to protect the network.

Lastly, it is not expected for any soft fork to be deployed at the first possible activation period. They are expected to take a few months as miners are typically slow to upgrade (usually auditing software, upgrading their custom software, etc.). So in practice, by the time a soft fork does activate, many, if not most, nodes have upgraded.

This whole deployment mechanism can be (and is) used for many soft forks. It is described by BIP 9.



And then let's look at what actually happened with Segwit's activation. Segwit took 11 months from the release of 0.13.1 to be fully deployed. By that time, the vast majority of the network had upgraded to segwit capable software.


  Block size is physically 1MB. Regardless of the calculation rule is 'Weight' or 'Bytes', the transaction size is always same physically. Why some guys says that Segwit transaction is compact than traditional transaction? Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.


Blocks are physically larger than 1 MB. The "block size limit" has been removed and replaced with the weight limit. It is true that physically, Segwit transactions are about the same size as non-segwit ones.

The "more compact" stems from a confusion between physical data size, and data size used for computation of the previous block size limit. Under the block size limit byte computation, segwit transactions are more compact. But when computing the actual number of bytes transmitted over the network, they are about the same.