<g​ingeropolous:monero.social> how does FCMP++ protocol stand up to massive reorgs?

<c​haser:monero.social> yes and no. the Carrot addressing protocol will give everyone address-conditional forward secrecy = you need to prevent a quantum adversary from learning any of the addresses derived from your mnemonic (github.com/jeffro256/carrot/blob/ma…address-conditional-forward-secrecy), and if you generate a Carrot-native mnemonic or derive a Carrot wallet from an e<clipped message>

<c​haser:monero.social> xisting hardware wallet mnemonic, you get internal forward secrecy = churned enotes and change from a transaction enters "post-quantum heaven" (github.com/jeffro256/carrot/blob/ma…rot.md#221-internal-forward-secrecy). IMHO in practice, the way most people use Monero (staying with old mnemonics, sharing addresses left and right, not churning, not generating a new tem<clipped message>

<c​haser:monero.social> porary mnemonic for each receive), this will obscure _some_ of the transaction graph from a quantum attacker, but still leave a lot of it available for tracing.

<b​oog900:monero.social> slightly worse than current protocol, the current one as long as your tx doesn't reference any recent outputs that have been reorged you are good. With FCMP you reference a block and you would want to reference the most recent block you can.

<b​oog900:monero.social> you would still follow the 10 block lock though FWIW, so most recent you can would be the block 10 blocks from the top