UkoeHB

The indexed tx private key method, as stated, has a flaw. If two outputs are sent to the same subaddress `(A_i, B_i)`, and their tx pub keys are `R_1` and...

There are some slight problems related to normal addresses here. 1. If a normal address transaction public key is just a random one e.g. `r_t G`, then it could also...

Note: Adding the final form of Janus mitigation would add an average 64 bytes per transaction (average output count is ~2.2, most of which have 1 tx pub key currently,...

Note that the necessity of implementing Janus for _all_ transactions, not just the potentially small minority which use subaddresses, means scanning times could double (although as @jtgrassie has pointed out,...

After talking with @knaccc, there are two new ideas to add here. 1. An alternate Janus mitigation would be for provers to make a 48-byte Schnorr signature on key `K^v`...

For posterity I am pasting the complete updated 'Janus base key method' here, since I'm removing it from my proposal (Monero repo issue #6456) in the name of less ambiguity....

Also deprecating the 48-byte Schnorr proof method, and pasting here for posterity. Originally ideated by @knaccc. Transaction authors make, for each sender-receiver shared secret to be Janus tested, a basic...

New idea - zero bytes in blockchain - mitigates Janus with just private view key - **cost**: larger addresses, modified output handling (for construction, identification, spending) ### New address format...

Without a fix for this issue, payment validators must maintain a full record of transactions received to their main wallet. Moreover, any 'tx engineering' protocol such as multisig, atomic swaps,...

Note: 2-out tx may get a bigger reduction in scan times from view tags, since they only (in practice) have 1 tx pub key so you normally only compute `generate_key_derivation()`...