About the discrepancy of "v" in public and private transaction

[kigawas]

According to EIP-155:

If block.number >= FORK_BLKNUM and CHAIN_ID is available, then when computing the hash of a transaction for the purposes of signing, instead of hashing only six rlp encoded elements (nonce, gasprice, startgas, to, value, data), you SHOULD hash nine rlp encoded elements (nonce, gasprice, startgas, to, value, data, chainid, 0, 0). If you do, then the v of the signature MUST be set to {0,1} + CHAIN_ID * 2 + 35 where {0,1} is the parity of the y value of the curve point for which r is the x-value in the secp256k1 signing process. If you choose to only hash 6 values, then v continues to be set to {0,1} + 27 as previously.

The public transaction is following the {0,1} + CHAIN_ID * 2 + 35 way as in ethereum, but the private transaction is still behaving like {0,1} + 27 + 10 as documented here.

GoQuorum replaces the data field of the Transaction with that hash, and changes the transaction’s v value to 37 or 38

If I set CHAIN_ID=1, probably 50% public transactions have the same "v"s as in private transactions. In this case, do any bugs occur?

[prd-fox]

Quorum will refuse to start if the chain ID is set to 1 for exactly this reason. The GoQuorum use of V for private transactions predates EIP155, so it was unlucky there it was chosen for this purpose. You can assume in a Quorum blockchain that any transaction with a V value of 37/38 is a private transaction, and not a replay protected transaction with a chain ID of 1.