-
br-m<pubertus:matrix.org> where can we read about this? and what effect any changes with FCMP++ tx's will have on the anonymity set? will it e.g. still be possible to see what type of user is behind a tx based on the tx size? > <@articmine> Yes FCMP++ transactions are 4x the size
-
DataHoarder> what effect any changes with FCMP++ tx's will have on the anonymity set?
-
DataHoarderdecoys are now equivalent to eligible past outputs
-
br-m<jeffro256> > will it e.g. still be possible to see what type of user is behind a tx based on the tx size?
-
br-m<jeffro256> Not unless they put something non-standard in tx_extra or use a non-standard fee algorithm. Unless using non-standard tx construction code, the Carrot/FCMP++ tx size is solely a function of the number of inputs and number of outputs, plus a bit of wiggle room for different varints
-
br-m<jeffro256> It's also a function of the number of layers in the current FCMP tree, but that will be the same for all users
-
br-m<jeffro256> Actually, another fingerprint is the "reference block" of the FCMP tree. wallet2 will use the newest version of the tree available with 10 blocks of confirmation to do the FCMP membership proofs on. However, if you reference a very old block, or wait a long time to publish the transaction, external observers can see that the membership proofs are old
-
br-m<jeffro256> It doesn't leak the true spend, but shrinks the anonymity set to the total set of usable blockchain outputs at an earlier date
-
br-m<jeffro256> If you do it consistently, it can be a probabilistic fingerprint of your activity
-
br-m<jeffro256> The solution is write better code which does membership proofs right before broadcasting. In FCMP++ you can sign years in advance and do the membership proofs later with needing the spend key
-
br-m<jeffro256> You could pre-emptively sign a FCMP++ mainnet tx now, and wait to do membership proofs until the hard fork activates