how can I compute subaddress Sa(a,i) where a is the account index and
i is the subaddress index within the account?
You're right, it is not fully explained in either of those links.
Take a look at get_subaddress_spend_public_keys and get_subaddress_secret_key in the source code.
You'll see in the code that subaddress_index is a struct containing "major"...
You don't. Subaddresses also solve the problem integrated addresses were designed for (allowing source identification in a single address). Since you can now generate a subaddress per source/client/customer, you don't need to assign a payment id anymore, so the ability to make integrated subaddresses was not added.
There are disposable addresses and subaddresses. Subaddresses are cool because you can have different addresses and still have them go to the same wallet. But they wouldn't be linked together. As pebx mentioned, there is a limit on the amount of subaddresses. You can generate as many subaddresses as you want, but the wallet cache file size gets bigger and ...
I will quote some comments from kenshi84 (who submitted the pull request).
Subaddresses are just like the standard address that you can use for receiving funds repeatedly. For example, you can use subaddress of index=1 for receiving your salary and index=2 for raising funds for your secret project, and no one can find the link between them.
The number of ...
Disposable addresses require the sender to use an unencrypted payment id specified by the receiver.
This means that if funds are sent to a disposable address more than once, an observer can tell that two transactions on the blockchain have the same recipient because both transactions will share the same payment id. It may have been difficult to educate ...
Monero "looks ahead" 200 subaddress indices from the highest subaddress index that it observes it has received an incoming payment to.
Therefore if you ever issue more than 200 subaddresses in a row and none of those receive any funds to them, then you need to force your wallet to scan beyond the subaddress index that it would normally stop looking beyond.
It was decided that there should not be such a thing as an integrated subaddress. Only your main Monero address can become an integrated address (this functionality is retained for backwards compatibility).
The reason for this is that integrated addresses stand out on the blockchain. It is possible to see the difference between a payment sent to a standard ...
Yes, you may use accounts to help managing subaddresses, but you don't have to. If you don't care which address receives coins as long as it goes to your wallet, just leave it.
Accounts work like this:
By default you get a single account with number 0.
You may switch current account context by issuing account switch <number> or by account new which ...
When restoring a wallet from the seed, the wallet automatically expands the internal subaddress table such that it can recognize incoming transfers to new subaddresses. If you type address all, the wallet displays a list of subaddresses in use so far:
[wallet 9xLMUj]: address all
The new cli command is called address.
address [ new <label text with white spaces allowed> | all | <index_min>
[<index_max>] | label <index> <label text with white spaces allowed>]
To create a new sub-address for the current account use address new.
You can view all addresses with the address all command.
Each sub-address ...
You could do that, if you want something way more cumbersome than giving a different address to everyone. Another, more secure way is to get the sender to generate a proof of sending a transaction (see get_tx_proof and check_tx_proof), but that is also more cumbersome than using a subaddress per sender.
Subaddresses are deterministic. Your wallet will only search ahead 200 subaddresses at a time in order to check for incoming funds at those addresses. Therefore it would not be recommended to attempt to discover 'vanity' subaddresses, because it would later be more complicated to restore your wallet from seed and instruct it to search for incoming funds at ...
The multiple accounts feature is currently only available in monero-wallet-cli. The GUI does allow for a user to generate and subsequently use multiple subaddresses though (confined to the same account for now). Furthermore, the GUI contributors have stated intention of adding the multiple accounts feature. In fact, there's already a preliminary pull request ...
Given an output pubkey P in a new transaction with its tx pubkey being R, you can recognize it as your incoming transfer by using your private viewkey a, looking for P - Hs(a*R)*G in your hashtable and finding an entry recoding the sub-address's index j. Its private key P=x*G is obtained as x = Hs(a*R) + b + Hs(a || j). So you need both of the original ...
Accounts are groupings of subaddresses for presentation purposes. There is also the side effect that when you spend out of an account, any outputs received at any subaddresses within that account may be combined. This is purely wallet logic.
Funds cannot usually be spent across subaddresses which span multiple accounts because of wallet logic. The wallet ...
After digging through the code and asking some more on IRC, it looks like the salt is "SubAddr" https://github.com/kenshi84/monero/blob/53ad5a0f42174bca57e24485ef3d40e4b9cf5599/src/cryptonote_basic/cryptonote_format_utils.cpp#L134 so it is really more like Hs(prefix || a || i). thank you to the people who helped me on #monero-dev
No. The wallet needs to support sub-addresses so the balance can be calculated correctly. Consider the scenario below:
You create a wallet in MyMonero and send 5 XMR.
You restore this wallet in the GUI.
You receive 2 XMR in a sub-address (acquired via GUI).
The MyMonero wallet will continue to show the balance of 5 XMR while the GUI will show 7 XMR.
Let's say you own a 4 XMR output that is stored in your wallet. When you send 3 XMR to Bob, you will spend that 4 XMR output, and you are creating a new 3 XMR output for Bob and a new 1 XMR change output for yourself.
This change output is not labelled as "change" in the transaction that is created. It's just an output that the wallet can see originated ...
You don't need your addresses to be "tagged".
Quoting the help:
[wallet 456789]: help transfer
transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <address> <amount>) [<payment_id (obsolete)>]
Transfer <amount> to <address>. If the ...
If wallet addresses are like bank account numbers, then subaddresses are like having lots of different bank account numbers for the same bank account.
This means that if you want Alice and Bob to pay you, you can give out a different bank account number to each of them. They then can't confer to figure out they're dealing with the same person.
This also ...
This is such an example transaction on stagenet where I sent 1 XMR to a subaddress and 2 XMR to a standard address (and the change goes back to myself):
The tx_extra contains the following information:
Each account is simply another subaddress. Therefore the math is identical to the usual subaddresses calculation - it is still represented by an i index in:
PSi = Hs(pV0 || i) G + PS0
(using Mastering Monero's notation).
However, it's worth noting that the calculation for the subaddress secret key is actually m = Hs(a || index_major || index_minor), and ...
To my understanding, if not specified, account_index will default to 0, while subaddr_indices will allow the wallet to use outputs from specified sub-address indexes as inputs.
If you specify multiple subaddr_indices, you restrain the wallet to only pick from those. But it will depend on the outputs available and the amount you want to transfer. It could ...
A payment ID is part of a transaction, not an address. Therefore, yes, if the exchange supports adding a payment ID field, it will be added to the transaction and you can view the payment ID in your wallet incoming transfers.
The unlock time in the rpc tx field is different from the standard ten block unlocking time.
If you want your funds to be immediately spendable you need to modify the CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE in the config file and recompile the wallet:
The unlock time field in the ...