I understand that currently, if an user wants to avoid re-using Monero addresses to avoid off-chain linkability (ie same address used for withdrawal from 2 exchanges and the exchanges releasing their logs to some entity), he has to create a new wallet for each transaction. This is cumbersome considering that for each wallet, entire blockchain needs to be scanned for outputs belonging to it,
Recently, a proposal which hopes to address this issue was presented on Reddit by user kenshi84. The idea describes a way to avoid Monero address re-use while maintaining normal performace when scanning the blockchian.
As previously discussed in StackExchange, exchanges can link withdrawal transactions if one uses the same receiving Monero address repeatedly, and it is recommended to create a one-time Monero address for each withdrawal to make sure no exchanges can ever link any withdrawals. Since such one-time Monero address generation can be tedious and error-prone, I came up with an idea of slightly modifying the protocol as follows:
Instead of telling the exchange the actual Monero address
(A,B), a user (receiver) tells the exchange an integer
k>0and a one-time Monero address
D=a^k B. Note that it is impossible to link
(C,D)using k without knowing the viewkey
a. The exchange then generates the one-time stealth address using
(C,D)as in the current protocol, but it also adds
kto the transaction data along with
R. The receiver can test if a given transaction output belongs to him or not by computing one-time Monero private view+spend keys
d=a^k b. Address reuse can be avoided by making sure to use a new value for
athat hasn't appeared in the blockchain.
Can this idea be useful?
Latter on in the comments he adds that this could be an improvement over HD wallets:
(...)I guess there's one advantage of this proposal over HD wallet though: when checking if a given tx output belongs to him or not, with HD wallet one needs to check against all the previously created Monero addresses (ie. linearly growing cost), whereas in this proposal one only needs to check against one address computed from k (ie. constant cost).
And also that this could be implemented just using the already available payment IDs:
(...)I think the additional task of generating unique k is quite similar to generating unique payment id. In fact, this proposal can be thought of as a replacement to the current payment id scheme, and k can be passed to the sender in the form of integrated address.
kenshi84's idea sounded extremely promising to me, so I would like to hear more about its viability.
I'm curious about the following aspects of the proposal:
- What would be the benefit over a HD wallet scheme?
- Would it affect the blockchain size if implemented?
- Would there be any loss in privacy if such a scheme was to be used?
- Would there be any risk to user funds?
- Is a protocol change required for this to work or could it be done entirely wallet-side?
- Are there any other points to consider?