Return to Answer

I will attempt to answer the question while considering what had been discussed through other channels: Reddit, IRC/Slack Pt.1 & Pt.2

Update May-2017: there has been some novel research into this, and it will be possible to tweak the sending wallet to allow sending to a special address acting as an "alias". The funds would go to the same wallet regardless of the number of these "alias" addresses used. The scheme makes it so that given an "alias" address, you can't work out the regular address or other aliases. Again, the actual records on the blockchain would never store any public address (be it regular, integrated, or alias), but the sender would generate a seemingly-random one-time destination address, as usual.

Read up on Github: https://github.com/monero-project/monero/pull/1753

I will attempt to answer the question while considering what had been discussed through other channels: Reddit, IRC/Slack Pt.1 & Pt.2

• There was talk about using payment ID as k and also consideration of using integratted addresses. Later it was realized that integrated addresses can't really work with this scheme as there is a chicken-egg problem involved in those :)
• There are surely different ways to go about generating (c,d) from (a,b,k) so this could use some further examination.
• There was a suggestion to look into bi-linear groups, but I can only mention it as I know nothing about this.
• Further consideration would be needed to see how this would fit together with payment IDs. Also, k should be protected from pruning, if it's ever implemented.
• Some other clumsy scenario with handling these kind of addresses?
• Some neat crypto-magic which could help in solving this in the most elegant way?

• There was talk about using payment ID as k and also consideration of using integratted addresses. Later it was realized that integrated addresses can't really work with this scheme as there is a chicken-egg problem involved in those :)
• There are surely different ways to go about generating (c,d) from (a,b,k) so this could use some further examination.
• There was a suggestion to look into bi-linear groups, but I can only mention it as I know nothing about this.
• Further consideration would be needed to see how this would fit together with payment IDs. Also, k should be protected from pruning, if it's ever implemented.
• Some other clumsy scenario with handling these kind of addresses?
• Some neat crypto-magic which could help in solving this in the most elegant way?
• What happens if we make a transaction sending to multiple addresses in the same tx?

• There was talk about using payment ID as k and also consideration of using integratted addresses. Later it was realized that integrated addresses can't really work with this scheme as there is a chicken-egg problem involved in those :)
• There are surely different ways to go about generating (c,d) from (a,b,k) so this could use some further examination.
• There was a suggestion to look into bi-linear groups, but I can only mention it as I know nothing about this.
• Further consideration would be needed to see how this would fit together with payment IDs. Also, k should be protected from pruning, if it's ever implemented.
• Some other clumsy scenario with handling these kind of addresses?

• There was talk about using payment ID as k and also consideration of using integratted addresses. Later it was realized that integrated addresses can't really work with this scheme as there is a chicken-egg problem involved in those :)
• There are surely different ways to go about generating (c,d) from (a,b,k) so this could use some further examination.
• There was a suggestion to look into bi-linear groups, but I can only mention it as I know nothing about this.
• Further consideration would be needed to see how this would fit together with payment IDs. Also, k should be protected from pruning, if it's ever implemented.
• Some other clumsy scenario with handling these kind of addresses?
• Some neat crypto-magic which could help in solving this in the most elegant way?