Join GitHub today
[Obsolete] Sub-addresses and disposable addresses #1753
(This PR replaces #1345)
Reddit post with some questions and answers:
Question on StackExchange:
Original post in MRL issue #7:
Assumptions & Characteristics
Generating a sub-address
To handle his main address in a unified way, Bob also registers
In other words, index=0 is a special case in this scheme corresponding to the original standard address.
Sending to a sub-address
When constructing a transaction, Alice first chooses a random scalar
She then computes an output pubkey to Bob:
She finally computes an output pubkey to herself as her change:
Note that Alice can prove her payment to Bob by using
Receiving by a sub-address
Bob checks if an output pubkey
and looking for
Therefore, Bob should be able to find
and obtain the private key of
Bob can generate a one-time disposable address associated with one of his sub-addresses
Bob can also generate one-time disposable addresses associated with his main address
Sending to a disposable address
Alice's procedure is exactly the same as above: she first generates a tx pubkey:
and then generates an output pubkey
Importantly, she finally attaches the payment ID
Receiving by a disposable address
When Bob processes a new transaction, he first computes
and looks for
and looks for
Bob can obtain the private key of
|Suitable for transfer to multiple destinations (e.g. pool payouts)?||No||No|
|Suitable for repetitive transfers?||Yes||No (same payment ID stored in the blockchain without encryption)|
|Guaranteed to produce different address each time?||No (same address from same index)||Yes|
Case 1: Pool payouts
Use the standard address. Neither sub-addresses nor disposable addresses can be used for transfers to multiple destinations.
Case 2: Putting up donation addresses on your anonymous Twitter etc. accounts
Use sub-addresses. If you used a disposable address, all donations going to that address would share the same payment ID which gets stored in the blockchain without encryption (as opposed to the case with integrated addresses where payment IDs get stored in the blockchain after encryption) and hence the link among those transactions would be immediately clear to everyone.
Case 3: Buying XMR at account-less exchanges (e.g. ShapeShift) anonymously
Use disposable addresses. Sub-addresses could also serve the purpose of generating different addresses, but you need to make sure to use different indices to generate different addresses, or else you'll end up reusing the same address and the exchange will notice it. Disposable addresses are always guaranteed to be new and different every time you issue them.
- Crypto & code reviewing
- Unit test, performance test, etc
- GUI integration
- Update MRL-0006
referenced this pull request
Feb 21, 2017
Yes, they look the same on the blockchain, for example,
Btw, the little 'd' in the
6 times, most recently
Feb 22, 2017
2 times, most recently
Feb 24, 2017
referenced this pull request
Mar 6, 2017
referenced this pull request
Mar 6, 2017
@knaccc: Are there logs of that IRC chat? Also, I would like to understand better the method you propose to scan for additional addresses for only a 5% cost increase. Is that part of the IRC discussion, or posted somewhere else?
@kenshi84: As I pointed out in previous comments, using
Would there be a problem in simply replacing
Each one of these schemes have pros and cons for different use cases, so it would be great to leave the door open for experimentation, should someone like to implement them in the future using your work on subaddresses. (I am thinking mostly about using subaddresses in phone or light wallets, and being able to organize and separate accounts, like in Mycelium, while keeping a reasonable amount of privacy with respect to the third parties involved.)
My question is: the way you are building things, will this kind of tweaking still be possible, or will there be any protocol or consensus changes in how subaddresses are recognized that would make that hard? My guess is that even if you go for the
@RandomRun It was a discovery I made from using a Java SUPERCOP ref10 implementation.
As I'm sure you know, EC multiplication in general is performed by doubling and adding as necessary.
Prior to performing a scalar multiplication to determine
In my tests in Java, I discovered that the most time consuming part of the process is the precomputation rather than the actual scalar multiplication operation following the precomputation. Therefore once
It could well be the case that this degree of speedup is peculiar to the Java SUPERCOP ref10 implementation and that the C implementation may not experience such a dramatic speedup. This idea therefore needs to be tested and validated by someone with C experience.
The IRC chat was in #monero-dev - I think you can see it all if you look at the Slack history.
@RandomRun That's interesting. What if instead of
The advantage of this is that the auditor can be only told how to examine one particular subaddress, but if the auditor needed to know about all subaddresses you would not need to share
(edit: my personal preference is for option 3 above)
@RandomRun I just realized there is a possible attack if the scheme is changed to attempt to give out auditor access to just a single subaddress.
An ecdhinfo amount
Therefore if you knew
This is a possible reason to preserve @kenshi84's original scheme instead of modifying it to allow auditor access to only specific subaddresses.
@knaccc: Thanks for the clarification regarding EC computation. That was a nice discovery!
Whether the auditor will be able to derive the whole sub-tree (if we are going for HD wallets eventually), I am not sure this specific scheme would allow for that. I believe BIP0032 contains some good ideas on how to build our keys to preserve the tree structure, though.
About the possible attack:
I didn't know that that was how the auditor recovered the real output amount from a ringCT transaction. Could you point me to a reference so I can learn more on that? (I thought that the "ecdhInfo" field of a transaction only stored the points,
Since the traditional address view key is
@RandomRun Haha yes the decoding of RingCT amounts was a difficult discovery that involved going through the source code with a lot of patience. This is the function
I also tested the function
The main issue that comes to mind is that this would involve scalar multiplication of
Another thought is whether there is an attack if a huge list of publicly listed monero address public spend keys (e.g. because they appear in search engine results) could be used to test against each output to discover any subaddresses with a shared view key.
Indeed, that is a good observation. When I first made a suggestion to modify subaddresses, I was thinking about replacing the transaction key
And added later in that thread:
So if your time complexity reduction from doubling to just 5% increase works, hopefully that might not be a problem anymore?
If there were a different
Time savings only occur when for the same user, you scalar multiply with a particular group element more than once.
@knaccc I would like some clarification on your thoughts on the "precomputation" for the subaddresses. Your description seems to indicate that there is a way to reuse a precomputed table for scalar multiplication but I do not see where this can occur. The receiver is still doing two scalar multiplications for every output. It should be possible to remove one of the scalar mulitplications in your scheme since an additional restriction was added - there can only be two outputs going to different addresses.
Each transaction has a unique
What does it mean precompute R? I mean, it's already there in the TX, so what's there to compute? Do I understand well that the "precompute R" trick would be in the following:
Suppose that we have a multi-wallet with privView keys
Now, what can we precompute? We can sort the keys by privView. Then, we prepare a multi-wallet specific table with a calculated offset chain for each privView, like this:
Now, with this table, for each TX we can do:
Is this right? Would it be faster? We multiply
By the way, this concept of precomputation isn't some new invention of mine, it's literally a method called
I posted this in IRC -> https://github.com/monero-project/monero/blob/master/src/crypto/crypto-ops.c#L1963 is where
Sorry for my long silence.
The idea of "per-subaddress selective auditing" that you and @knaccc have been discussing is somewhat interesting, but IMHO I'm quite skeptical about it. Let me rephrase your proposed idea in my own words: the original equation for the
is now replaced by
The wallet owner gives the sub-address
Maybe possibly this approach might be useful, but I'm skeptical because the auditor can easily find links among many sub-addresses
The auditor can simply add those detected
In my original intent, sub-addresses are meant to be passed to people and very often made publicly known (or forcibly made so by leaks), so the auditor will have access to all those found sub-addresses anyway. So I don't really see a privacy improvement in this approach.
The fundamental reason that makes this "selective auditing" idea difficult to realize I think is the fact that the same
@kenshi84: What you are suggesting requires that the auditor knows the sub-address itself. If he is just looking at blockchain data, he won't find the
Your observation, together with @knaccc's observation about decoding transactions amounts using
I wonder if selective auditing could be achieved by using more keys, like some stealth address generalization that would involve say
I hacked together some C to test the pre-computed scalar multiplication issue. The speedup in C is 2.68x, which is dramatically lower than the Java 20x speedup. Therefore the "Option 2" "R precomp" looks like it's off the table. I suspect the Java situation is complicated by object creation overhead that does not affect the C implementation.
A conversation took place on IRC today:
which led to a conclusion that we drop the disposable address idea for now (with a possibility to revisit it in the future), and we design the alias idea (both for general and one-time uses) on top of the sub-address scheme, eliminating the potential risk of txes being linked due to reuse of disposable addresses by uneducated users.
This PR will be closed in favor of a new PR that will be created soon^TM.