there are two type of segwit as P2SH starting with 3 and Native SegWit (bech32) starting with bc1, but don’t know which of the two segwit one, is better and is compatible to transfer and receive from a legacy one?
Generally speaking the “bc1” native SegWit address is better. It’s completely redesigned comparing to the classical/legacy Base58 encoding invented by Satoshi.
Alphabets in a “bc1” address can be either all upper-case or all lower-case, the former fits QR code better, resulting in a more compact QR code. Without mixed-case alphabets, “bc1” address is also easier to be read orally.
“bc1” (P2WPKH) addresses take the least bytes in transactions comparing to “3” (P2SH-P2WPKH) addresses or “1” (P2PKH) addresses, therefore its miner fee is the cheapest among three address types.
Bitcoins can be freely transferred among all three address types.
However, when you are receiving bitcoins, there’s a compatibility issue around “bc1” addresses, that some (old) wallets (including the withdrawal interface of some exchanges) simply don’t recognize it.
When you are sending bitcoins from SegWit addresses, there’s nothing to worry about, except a minor issue that a 0-conf SegWit transaction may not show up in the payee’s view, if the payee is using an old wallet which is not SegWit-aware. In that situation, it will finally show up in the payee’s view when it gets included into the blockchain.
By the way, SegWit addresses, including both “3” and “bc1”, currently doesn’t support the “sign/verify message” feature in Bitcoin Core. Some developers also worried about abuses of this function IIRC. Trezor and Electrum had implemented this feature in ways which were not compatible with each other. In the future, maybe we could see this standardized by BIP322.
a segwit wallet helps to reduce the size of the tx, and reduce fee
Currenty SegWit doesn’t really reduce the size of the transaction. The “bc1” native SegWit address only reduce the size by several bytes. The “3” P2SH SegWit address on the contrary cosumes more bytes in the block, because P2SH wrapping itself requires a 20-byte hash.
Mostly it’s just a discount (aka. “virtual byte”, or vB for short), that the “witness” part (mostly digital signatures and pubkeys) would be counted as 1/4 of its actual size. Obviously, only transactions spending coins from SegWit addresses enjoy that discount.
However, SegWit has other benefits, like Signing of input values, which simplifies unsigned transaction format, especially PSBT, which could benefit offline/cold/hardware wallets and transactions involving multiple parties (related). Update: it turns out that this improvement doesn’t really work for SegWit, then Taproot fixes this issue: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd
