Contains two modifications to improve ASIC resistance: shuffle and integer math.

Shuffle makes use of the whole 64-byte cache line instead of 16 bytes only, making Cryptonight 4 times more demanding for memory bandwidth.

Integer math adds 64:32 bit integer division followed by 64 bit integer square root, adding large and unavoidable computational latency to the main loop.

More or less complete description of these changes and performance numbers are here: https://github.com/SChernykh/xmr-stak-cpu/blob/master/README.md

Discussion that preceded this pull request: https://github.com/SChernykh/xmr-stak-cpu/issues/1

If ASICs are going to be a recurring problem, can you change the POW to maybe 5 or 10 different options every block based on the hash value of the previous block? That way the software could be changed in GPUs whereas ASICs would hopefully require different hardware for each POW if they are logically and/or mathematically independent enough. Even better would be if a POW could change a single variable to require a different ASIC, then the previous hash would be used to set the variable for the next block.

Note: This PR replaces #1753. Most importantly, the idea of disposable addresses was dropped, due to its potential danger of being misused by uneducated users which leads to on-chain tx linkability. See the relevant discussion here.

GUI version

1. Motivation

Suppose you publish a Monero wallet address for donation on your Twitter/etc profile page. Furthermore, you have an anonymous identity for some secret project where you also want to receive donation in Monero. Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have.

Another relevant scenario is when you want to buy Monero anonymously through ShapeShift. If you used the same Monero address repeatedly for multiple purchases, ShapeShift would know that the same person bought that much of Monero through those purchases (although they don't know your contact info as they don't require account registration). You can anonymize the process by creating a temporary wallet for every purchase and transferring the fund to your real wallet afterwards. This is doable, but clearly tedious.

The scheme proposed in this PR provides an effective solution for such scenarios, where the recipient can create multiple wallet "subaddresses" that appear unrelated to each other to outside observers, and the recipient can recognize all incoming transfers to those subaddresses with almost no additional cost. Note that this scheme only introduces additional procedures for the wallet software to construct and interpret transactions, while not requiring any change in the consensus rule (thus requiring no hard fork).

2. How it works cryptographically

Suppose Bob's wallet address is (A, B) = (a*G, b*G) where a and b are his view and spend secret keys, respectively. Likewise, Alice's address is (X, Y) = (x*G, y*G). Bob is receiving Monero from Alice, but he wants to do so without using his real address (A, B) in order to prevent Alice from knowing that the recipient is him. In the above example with ShapeShift, Bob would be you and Alice would be ShapeShift.

2.1. Generating a subaddress

Bob generates his i-th subaddress (i=1,2,...) as a pair of public keys (C,D) where:

m = Hs(a || i)
M = m*G
D = B + M
C = a*D

We call i the index of the subaddress. Note that (A,B) and (C,D) are unlinkable without the knowledge of the view secret key a. Bob then registers D to a hash table T stored in his wallet cache (akin to the aggregate addresses scheme):

T[D] <- i

To handle his main address in a unified way, Bob also registers B to the hash table:

T[B] <- 0

In other words, the index 0 is treated as a special case in this scheme representing the original standard address.

2.2. Sending to a subaddress

When Alice constructs a transaction that transfers some fund to a subaddress (C, D), she first chooses a random scalar s and generates a tx pubkey:

R = s*D

Note that the tx secret key r such that R = r*G is unknown to Alice because she doesn't know the secret key of D. She then computes an output pubkey for the destination:

P = Hs(s*C)*G + D

She finally computes an output pubkey to herself as her change:

Q = Hs(x*R)*G + Y

Importantly, without the knowledge of the tx secret key r as explained above, Alice can include her change output in the transaction only because she knows her own view secret key x. ~~In other words, only single-destination transfers are possible in this scheme, and multi-destination transfers (e.g. pool payouts) require the use of standard addresses.~~ (2017-08-01) Now this scheme supports multi-destination transfers by introducing additional tx keys.

Also note that Alice can prove her payment to Bob by using s.

2.3. Receiving by a subaddress

Bob checks if an output pubkey P in a new transaction belongs to him or not by computing

D' = P - Hs(a*R)*G

and looking for D' in the hash table. If the transaction was indeed bound to Bob's subaddress (C,D), D' should equal to D because

a*R = a*s*D
    = s*a*D
    = s*C

Therefore, Bob should be able to find D' in the hash table:

i <- T[D']

and obtain the private key of P:

p = { Hs(a*R) + b                   i == 0
    { Hs(a*R) + b + Hs(a || i)      otherwise

2.4. Grouping subaddresses

When sending funds to Bob's subaddress (C,D), Alice can choose to send the change to her i-th subaddress (X_i,Y_i) instead of her main address (X,Y) by replacing Y with Y_i when deriving the change's output pubkey:

Q = Hs(x*R)*G + Y_i

Using this scheme, it's now possible to maintain balances of subaddresses separately, making them virtually function as separate wallets. In order to maintain subaddresses in an organized manner, we propose a simple scheme of grouping subaddresses as follows: we define the index of subaddresses as a pair of indices (i,j) with i, the major index, representing a group of subaddresses (called an account) and j, the minor index, representing a particular subaddress within that account. Incoming transfers to subaddresses belonging to the same account (i,0), (i,1), ... are summed up to form a single balance, and any spending of those outputs will transfer the change to the base subaddress (i,0). The index (0,0) represents the original standard address.

3. How it works in the CLI

3.1. Synopsis

Existing commands with updated syntax:

address
address new <label text with white spaces allowed>
address all
address <index_min> [<index_max>]
address label <index> <label text with white spaces allowed>

balance [detail]

show_transfers [in|out|pending|failed|pool] [index=<N1>[,<N2>,...]] [<min_height> [<max_height>]]
incoming_transfers [available|unavailable] [index=<N1>[,<N2>,...]]
unspent_outputs [index=<N1>[,<N2>,...]] [<min_amount> [<max_amount>]]

transfer [index=<N1>[,<N2>,...]] [<priority>] [<mixin_count>] <address> <amount> [<payment_id>]
locked_transfer [index=<N1>[,<N2>,...]] [<priority>] [<mixin_count>] <addr> <amount> <lockblocks> [<payment_id>]
donate [index=<N1>[,<N2>,...]] [<priority>] [<mixin_count>] <amount> [<payment_id>]

sweep_all [index=<N1>[,<N2>,...]] [<mixin_count>] <address> [<payment_id>]
sweep_below <amount_threshold> [index=<N1>[,<N2>,...]] [<mixin_count>] address [<payment_id>]

New commands:

account
account new <label text with white spaces allowed>
account switch <index>
account label <index> <label text with white spaces allowed>

3.2. Managing accounts

Initially, the wallet has only one account corresponding to the major index 0. The account index is indicated as the number after / in the command prompt:

[wallet/0 9uPkEU]: 

You can create a new account by using the command account new:

account new <label text with white spaces allowed>

[wallet/0 9uPkEU]: account new eBay selling   
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        0.000000000000        0.000000000000               Default
       1 Bd2qqa        0.000000000000        0.000000000000          eBay selling
----------------------------------------------------------------------------------
          Total        0.000000000000        0.000000000000

[wallet/1 Bd2qqa]: address
0  Bd2qqam2EKc8NRzTYg9QPJZ81Ey1WRp1Bcnmjzf28K3edRyr1rcLbjiQZdR7tsuTUJBahi32RSDb1cuqsACaEDwGRMZ4Eaa  eBay selling

Note the change of the address. The command account switch lets you switch between accounts:

[wallet/1 Bd2qqa]: account switch 0
Currently selected account: [0] Default
Balance: 0.000000000000, unlocked balance: 0.000000000000

[wallet/0 9uPkEU]: address
0  9uPkEUFcFujaw1YCDHhcvuUqQm9cGBBuu5KkGggFR9XMjQtXtFzUDbRU9oy4XYer9SeaSGAhtoT1xDsBuVDRqfg9GG2ji9U  Default

The command account with no arguments shows the list of all the accounts along with their balances:

[wallet/0 9uPkEU]: account
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        0.000000000000        0.000000000000               Default
       1 Bd2qqa        0.000000000000        0.000000000000          eBay selling
----------------------------------------------------------------------------------
          Total        0.000000000000        0.000000000000

At any time, the user operates on the currently selected account and specifies the minor index in various commands when necessary via the index parameter; i.e. in the following description, we use the term "index" to mean the minor index.

3.3. Generating subaddresses

The command address shows the "base" address at index=0 (which corresponds to the original standard address when the currently selected account is at index=0). The command address new lets you create a new address at one index beyond the currently existing highest index associated with this account. You can assign a label to the address if necessary:

address new <label text with white spaces allowed>

[wallet/0 9uPkEU]: address new ShapeShift purchase on 2017-Jul-08
1  BZ9PfXYboScf2vs4EcnMBdT2dvzmE1hLnZixxnmAP2vs52jQiLTmDzTDhdwVyuBWMhCeiTxD4bVCJipsfmGxtBTwSq4HwAh  ShapeShift purchase on 2017-Jul-08

Note that this command is intended to be used for generating "throwaway" addresses; i.e. when you just want a fresh new address to receive funds to the currently selected account (e.g. when purchasing XMR through ShapeShift). If instead you want to maintain a separate balance associated with a new address, create a new account by the command account new.

The commands address all and address <index_min> [<index_max>] show lists of addresses that have been generated so far:

[wallet/0 9uPkEU]: address all
0  9uPkEUFcFujaw1YCDHhcvuUqQm9cGBBuu5KkGggFR9XMjQtXtFzUDbRU9oy4XYer9SeaSGAhtoT1xDsBuVDRqfg9GG2ji9U  Default
1  BZ9PfXYboScf2vs4EcnMBdT2dvzmE1hLnZixxnmAP2vs52jQiLTmDzTDhdwVyuBWMhCeiTxD4bVCJipsfmGxtBTwSq4HwAh  ShapeShift purchase on 2017-Jul-08
2  BfhF533yqmNfxfgoDXK1411DYveWMU1xRQzMPPpHVrZgeoCoVrQ9GCjY1mvDQQaoiCZYhKhGVHLkm51cgZYfDUpt5Bw4ZgB  ShapeShift purchase on 2017-Jul-09
3  BhTfiQY1Xj6AKXPUtDbunJPmqrbkha5qvNgYoipp6L7FQ8KTDciDWjF3YQ5g2dCLNLjJoUEJKVeYt9Rpb8tgDzT36fSoS9D  
4  BYoaHkHjFEY371Jq9fY9x9TJjaMeDXBYS9AfqCJ7SJoe5vuJLDPsyhU3RzDFNXKkEqBDqQMX1bDuUQbXKXctTGXY9ZgdGa1  ShapeShift purchase on 2017-Jul-11
5  BcxioZpKqYaZsSDHP6pmesaV7gMrPYxvHXsnkG5ceVGkasPR83cEJyvGNpckYvs2wP76HsM1KGo1mbEmmiburnCUT4aSEv1  ShapeShift purchase on 2017-Jul-13
6  BZzdxkqM8fJhZLATeyD3bd2cSrehGsANH4CgyJ4DBUamJAdyRTqkZ1W3kvN1UpzLz1iQU8XfEQUi15QyobFyMQVb3LDj4gZ  ShapeShift purchase on 2017-Jul-17
7  BYNUQQfEtg2gshraM8RPGvPUNbWcHHu33Tzhxy8ZrL7r7MYDkdPUCDFYxNawBNSAdjhKUCsiWjg5tQoReRMKGQ1fJS2QuEB  ShapeShift purchase on 2017-Jul-21

[wallet/0 9uPkEU]: address 3 6
3  BhTfiQY1Xj6AKXPUtDbunJPmqrbkha5qvNgYoipp6L7FQ8KTDciDWjF3YQ5g2dCLNLjJoUEJKVeYt9Rpb8tgDzT36fSoS9D  
4  BYoaHkHjFEY371Jq9fY9x9TJjaMeDXBYS9AfqCJ7SJoe5vuJLDPsyhU3RzDFNXKkEqBDqQMX1bDuUQbXKXctTGXY9ZgdGa1  ShapeShift purchase on 2017-Jul-11
5  BcxioZpKqYaZsSDHP6pmesaV7gMrPYxvHXsnkG5ceVGkasPR83cEJyvGNpckYvs2wP76HsM1KGo1mbEmmiburnCUT4aSEv1  ShapeShift purchase on 2017-Jul-13
6  BZzdxkqM8fJhZLATeyD3bd2cSrehGsANH4CgyJ4DBUamJAdyRTqkZ1W3kvN1UpzLz1iQU8XfEQUi15QyobFyMQVb3LDj4gZ  ShapeShift purchase on 2017-Jul-17

~~The command integrated_address also takes an optional argument to specify the index:~~ (2017-08-01) The integrated subaddresses format was dropped as subaddresses are expected to be replacing the role of payment IDs

The command address label lets you set the label of an address:

address label <index> <label text with white spaces allowed>

[wallet/0 9uPkEU]: address label 3 test test
3  BhTfiQY1Xj6AKXPUtDbunJPmqrbkha5qvNgYoipp6L7FQ8KTDciDWjF3YQ5g2dCLNLjJoUEJKVeYt9Rpb8tgDzT36fSoS9D  test test

Note that the label of the base address is treated as the label of the currently selected account. You can change account labels by using either address label or account label:

[wallet/0 9uPkEU]: address label 0 My home account  
0  9uPkEUFcFujaw1YCDHhcvuUqQm9cGBBuu5KkGggFR9XMjQtXtFzUDbRU9oy4XYer9SeaSGAhtoT1xDsBuVDRqfg9GG2ji9U  My home account

[wallet/0 9uPkEU]: account label 1 My secret business account
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        0.000000000000        0.000000000000       My home account
       1 Bd2qqa        0.000000000000        0.000000000000 My secret business account
----------------------------------------------------------------------------------
          Total        0.000000000000        0.000000000000

3.4. Checking funds and balances

Here the wallet finds a few incoming transfers by some of its subaddresses (indicated by the major-minor index pairs):

Height 949115, txid <2c9d55d65f67243f771729ecd93a089ca0fcde3451f5a7740a4df70d8240b95b>, 0.130000000000 XMR, idx 0/1
Height 949115, txid <68ee8848bbb953e3a0bc8d3175e8724c3fb04cd2e49244c76d26d5b2fa2a6da2>, 0.020000000000 XMR, idx 0/0
Height 949115, txid <01f3865e63613413f6de4d4cd2b2638b679aa604c06299ad4b562364afc8cf5a>, 0.110000000000 XMR, idx 0/1
Height 949115, txid <b3bd13988448ef3bb95e6f3bf007f42ebc4f0d21346b6c4d45e42d53caa3e297>, 0.120000000000 XMR, idx 0/1
Height 949115, txid <05a97709858358ec8bb008cc8ad7f70e35ec07219cc8744138473200bb9922ec>, 0.230000000000 XMR, idx 0/2
Height 949115, txid <9a1527acdce60bbe38c8c7e9d3bfe894108d5b30eb630904a3b3afd5059b3344>, 0.210000000000 XMR, idx 0/2
Height 949115, txid <6716c0707b4c198777adbcda6b630b6248ef07fb86d20ba4469dcf661f5b35ee>, 0.010000000000 XMR, idx 0/0
Height 949115, txid <04bf1d9a5b8b3fe74d26bd068844f4709b22c92f6a3b5594f217c22df88f8184>, 0.030000000000 XMR, idx 0/0
Height 949115, txid <02b76b48467a806c6e45ce6fdf59df3c694f857f450a450537a9769f911fee46>, 0.220000000000 XMR, idx 0/2
Height 949116, txid <92f3b54a3044eddf3fd84742852f8a81b55e92055281c945bd7dee85e589ccc2>, 1.010000000000 XMR, idx 1/0
Height 949117, txid <d2617a1da91203247f8b904cf05906973cc9a64bff8d6ab4d956f22cb5d5271e>, 1.030000000000 XMR, idx 1/0
Height 949117, txid <441b07d91f64adf1b4f8350ca33902ed4aab306df3f66e1673d35a151186140c>, 1.020000000000 XMR, idx 1/0
Height 949126, txid <0f5fcd710b94e49b61fedf93de92b444021292fbffb57c281ee6952190dc0bbf>, 1.110000000000 XMR, idx 1/1
Height 949126, txid <73a83e4de08d84d9d72c707c0406fcba92994a56feb42102e3ca7c3733613c5e>, 1.210000000000 XMR, idx 1/2
Height 949126, txid <9bdba78cd150cf4027282cdabb5893c0c7fb4c0d8ddf0f9096598b4bea87af69>, 1.230000000000 XMR, idx 1/2
Height 949126, txid <22e4ac8469654903da34ce06ab06840648338d9d9dfc3f59714777d7a5a5256b>, 1.120000000000 XMR, idx 1/1
Height 949126, txid <36b14c61ad93c4a8d16f10d88525222391717d87099bb30cd8c3da6c90849818>, 1.130000000000 XMR, idx 1/1
Height 949126, txid <99b7c48a24e44c3336dc0f4b884ad33e89668e4dd9c288c67e60ffea9506ed26>, 1.220000000000 XMR, idx 1/2
[wallet/0 9uPkEU]: account
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        1.080000000000        1.080000000000       My home account
       1 Bd2qqa       10.080000000000       10.080000000000 My secret business account
----------------------------------------------------------------------------------
          Total       11.160000000000       11.160000000000

The command balance shows the total balance of all the funds received by all the addresses belonging to the currently selected account. You can see the details about how much funds are received by which address by providing an optional argument detail:

[wallet/0 9uPkEU]: balance
Currently selected account: [0] My home account
Balance: 1.080000000000, unlocked balance: 1.080000000000

[wallet/0 9uPkEU]: balance detail
Currently selected account: [0] My home account
Balance: 1.080000000000, unlocked balance: 1.080000000000
Balance per address:
        Address               Balance      Unlocked balance                 Label Outputs
       0 9uPkEU        0.060000000000        0.060000000000       My home account       3
       1 BZ9PfX        0.360000000000        0.360000000000 ShapeShift purchase on 2017-Jul-08       3
       2 BfhF53        0.660000000000        0.660000000000 ShapeShift purchase on 2017-Jul-09       3

[wallet/0 9uPkEU]: account switch 1
Currently selected account: [1] My secret business account
Balance: 10.080000000000, unlocked balance: 10.080000000000

[wallet/1 Bd2qqa]: balance detail
Currently selected account: [1] My secret business account
Balance: 10.080000000000, unlocked balance: 10.080000000000
Balance per address:
        Address               Balance      Unlocked balance                 Label Outputs
       0 Bd2qqa        3.060000000000        3.060000000000 My secret business account       3
       1 BcGvNd        3.360000000000        3.360000000000                             3
       2 BgtuJh        3.660000000000        3.660000000000                             3

Other commands for showing detailed information about funds have some changes of syntax:

show_transfers [in|out|pending|failed|pool] [index=<N1>[,<N2>,...]] [<min_height> [<max_height>]]
incoming_transfers [available|unavailable] [index=<N1>[,<N2>,...]]

[wallet/1 Bd2qqa]: show_transfers index=0
  949116     in      03:34:43 AM       1.010000000000 92f3b54a3044eddf3fd84742852f8a81b55e92055281c945bd7dee85e589ccc2 0000000000000000 0 - 
  949117     in      03:35:30 AM       1.030000000000 d2617a1da91203247f8b904cf05906973cc9a64bff8d6ab4d956f22cb5d5271e 0000000000000000 0 - 
  949117     in      03:35:30 AM       1.020000000000 441b07d91f64adf1b4f8350ca33902ed4aab306df3f66e1673d35a151186140c 0000000000000000 0 - 

[wallet/1 Bd2qqa]: incoming_transfers index=1,2
               amount   spent    unlocked  ringct    global index                                                               tx id      addr index
       1.110000000000       F    unlocked  RingCT          219516  <0f5fcd710b94e49b61fedf93de92b444021292fbffb57c281ee6952190dc0bbf>               1
       1.210000000000       F    unlocked  RingCT          219518  <73a83e4de08d84d9d72c707c0406fcba92994a56feb42102e3ca7c3733613c5e>               2
       1.230000000000       F    unlocked  RingCT          219520  <9bdba78cd150cf4027282cdabb5893c0c7fb4c0d8ddf0f9096598b4bea87af69>               2
       1.120000000000       F    unlocked  RingCT          219522  <22e4ac8469654903da34ce06ab06840648338d9d9dfc3f59714777d7a5a5256b>               1
       1.130000000000       F    unlocked  RingCT          219524  <36b14c61ad93c4a8d16f10d88525222391717d87099bb30cd8c3da6c90849818>               1
       1.220000000000       F    unlocked  RingCT          219526  <99b7c48a24e44c3336dc0f4b884ad33e89668e4dd9c288c67e60ffea9506ed26>               2

3.5. Transferring funds

The apparently unrelated subaddresses might get statistically linked if funds transferred to different subaddresses are used together as inputs in new transactions. For example, suppose Bob published two subaddresses (C1,D1) and (C2,D2) in different places, and Alice repeatedly transferred funds to these addresses not knowing that they both belong to Bob. If Bob repeatedly used outputs received by these subaddresses together as inputs in new transactions, Alice would notice multiple instances of transactions where each of the input ring signatures contains the output she created for the payments to these subaddresses. The probability of such transactions occurring by chance would be fairly low, so she can confidently guess that these subaddresses belong to the same person.

To prevent this kind of potential risk of linkability, the wallet tries its best to avoid using outputs belonging to different subaddresses together as inputs in a new transaction. If there exist any subaddresses with enough unlocked balance for the requested transfer, the wallet chooses one randomly. If there is no such subaddress, the wallet uses the minimal number of subaddresses to cover the required amount while showing a warning message. You can also explicitly tell the wallet from which subaddresses the outputs should be picked by using an optional argument index=<N1>[,<N2>,...]:

transfer [index=<N1>[,<N2>,...]] [<priority>] [<mixin_count>] <address> <amount> [<payment_id>]

[wallet/1 Bd2qqa]: balance detail
Currently selected account: [1] My secret business account
Balance: 10.080000000000, unlocked balance: 10.080000000000
Balance per address:
        Address               Balance      Unlocked balance                 Label Outputs
       0 Bd2qqa        3.060000000000        3.060000000000 My secret business account       3
       1 BcGvNd        3.360000000000        3.360000000000                             3
       2 BgtuJh        3.660000000000        3.660000000000                             3

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 3  
Spending from address index 2
Sending 3.000000000000.  The transaction fee is 0.023390640000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 3
Spending from address index 1
Sending 3.000000000000.  The transaction fee is 0.023390640000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 3.2
Spending from address index 1
Sending 3.200000000000.  The transaction fee is 0.023390640000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 3.2
Spending from address index 2
Sending 3.200000000000.  The transaction fee is 0.023390640000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 3.5
Spending from address index 2
Sending 3.500000000000.  The transaction fee is 0.023390640000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 5
Spending from address index 1
Spending from address index 2
WARNING: Outputs of multiple addresses are being used together.
Sending 5.000000000000.  The transaction fee is 0.025061400000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer index=0,1 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 5
Spending from address index 0
Spending from address index 1
WARNING: Outputs of multiple addresses are being used together.
Sending 5.000000000000.  The transaction fee is 0.025061400000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 9
Spending from address index 0
Spending from address index 1
Spending from address index 2
WARNING: Outputs of multiple addresses are being used together.
Sending 9.000000000000.  The transaction fee is 0.028402920000
Is this okay?  (Y/Yes/N/No): n
Error: transaction cancelled.

The command sweep_all has a similar syntax:

sweep_all [index=<N1>[,<N2>,...]] [<mixin_count>] <address> [<payment_id>]

If you omit the index parameter, one subaddress to be swept is chosen randomly (with index 0 being chosen last). You can use index=<N> to specify which subaddress to be swept. You can also either use index=<N1>,<N2>,... to sweep balances of multiple or all subaddresses.

[wallet/1 Bd2qqa]: sweep_all 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk
Spending from address index 1
Sweeping 3.360000000000 for a total fee of 0.023390080000.  Is this okay?  (Y/Yes/N/No)n
Error: transaction cancelled.

[wallet/1 Bd2qqa]: sweep_all index=1,2 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk
Spending from address index 1
Spending from address index 2
WARNING: Outputs of multiple addresses are being used together.
Sweeping 7.020000000000 for a total fee of 0.025060800000.  Is this okay?  (Y/Yes/N/No)n
Error: transaction cancelled.

Note that the change always goes to the base subaddress at index=0:

[wallet/1 Bd2qqa]: transfer 9svHk1wHPo3ULf2AZykghzcye6sitaRE4MaDjPC6uanTHCynHjJHZaiAb922PojE1GexhhRt1LVf5DC43feyrRZMLXQr3mk 1
Spending from address index 1
Sending 1.000000000000.  The transaction fee is 0.021719360000
Is this okay?  (Y/Yes/N/No): y
Money successfully sent, transaction <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>

Height 949248, txid <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>, 0.088280640000 XMR, idx 1/0
Height 949248, txid <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>, spent 1.110000000000, account 1

[wallet/1 Bd2qqa]: balance detail
Currently selected account: [1] My secret business account
Balance: 9.058280640000, unlocked balance: 8.970000000000
Balance per address:
        Address               Balance      Unlocked balance                 Label Outputs
       0 Bd2qqa        3.148280640000        3.060000000000 My secret business account       4
       1 BcGvNd        2.250000000000        2.250000000000                             2
       2 BgtuJh        3.660000000000        3.660000000000                             3

3.6. Restoring wallet from seed

One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet stores 200 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the highest index created so far. The wallet also generates 50 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the highest index created so far. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Note that the wallet expands the hashtable by itself as it finds incoming transfers to subaddresses at new higher indices, so normally the user won't need to worry about the management of the hashtable. Even if the differences of indices are bigger than those predifined numbers, you can still make the wallet recognize the incoming transfers by manually expanding the hashtable and rescanning the blockchain.

Here's an example: First, we generate 360 new addresses for the 1st account:

[wallet/1 Bd2qqa]: address all
0  Bd2qqam2EKc8NRzTYg9QPJZ81Ey1WRp1Bcnmjzf28K3edRyr1rcLbjiQZdR7tsuTUJBahi32RSDb1cuqsACaEDwGRMZ4Eaa  My secret business account (used)
1  BcGvNdmZj9V9r7NKAKzEELUVVSVfXMmUUbfQrjSBuDt6MU5bdtmYAEC6TR5VuZQv5yZvynzQ3aoJTUjtM9FD5AnP9PCHVSk   (used)
2  BgtuJhWFPi9DABnpdtQs9rWfQN33DZQZi2yzoQucEAP8EoPxNDitssoA14ZVQthSyPHWB8SLV48qAc25A1EykehQ7NzDXDb   (used)
3  BYfn1Fc5xwECX2HbNATqfuQCG82sMZufY46ZsiP1xBbR3S6fVj2P4d4MLRrqVBZcFHUQmdiCsKa3ec5aaNVk35ZYHQnLbu1  
...
150  BgjoPu6qBNVT1E9c3PDaaw9zbehhG29vBQAH8mSeC79K7z2qb12ZtTH1ijo4Tn7DYQPm2aZq68yrnLcoi18baf9JQxmn2bZ  
...
360  BZ1xAbycuHyKwangpgEn7NTWk2geNbcJgJ46iCkRBu8Gc2UXTACeRcUGWneGA1mPfkKmpy7ya4ST9dZex3RN2qi5BLdQRxy  

Next, we generate 70 accounts and print the base addresses of the 15th and 70th accounts:

[wallet/70 BbXfcf]: account
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        1.080000000000        1.080000000000       My home account
       1 Bd2qqa        9.058280640000        9.058280640000 My secret business account
       2 BaTkbd        0.000000000000        0.000000000000                      
       3 BeaUVm        0.000000000000        0.000000000000                      
...
      70 BbXfcf        0.000000000000        0.000000000000                      
----------------------------------------------------------------------------------
          Total       10.138280640000       10.138280640000

[wallet/0 9uPkEU]: account switch 15
Currently selected account: [15] 
Balance: 0.000000000000, unlocked balance: 0.000000000000

[wallet/15 BhQjPZ]: address
0  BhQjPZ8XUkojSdcB8jhB4uTeqLQVHtfsYTxTm3n32yXM37qXqN8RdTXduKSEH4rrAp4ZuUFbv8Wak3i1QudCJhvwJVUU5dx  

[wallet/15 BhQjPZ]: account switch 70
Currently selected account: [70] 
Balance: 0.000000000000, unlocked balance: 0.000000000000

[wallet/70 BbXfcf]: address
0  BbXfcfWRiUAcG7hoXvdRY8QtVisRPj1EQEbMoWWHGPXqQKVKWoSNNgbPEuSFm6YuDHUVaWwyqu876WKZrUmVMk8DLsrSMSN  

Then we send funds to these addresses (at indices of 1/150, 1/360, 15/0, 70/0) from another wallet:

[wallet/0 9svHk1]: transfer BgjoPu6qBNVT1E9c3PDaaw9zbehhG29vBQAH8mSeC79K7z2qb12ZtTH1ijo4Tn7DYQPm2aZq68yrnLcoi18baf9JQxmn2bZ 1  
Money successfully sent, transaction <ddb1d29f54f4de8e88fddd31379d6bf30ba4d311ae648d05c9962cfb59e494b1>

[wallet/0 9svHk1]: transfer BZ1xAbycuHyKwangpgEn7NTWk2geNbcJgJ46iCkRBu8Gc2UXTACeRcUGWneGA1mPfkKmpy7ya4ST9dZex3RN2qi5BLdQRxy 2
Money successfully sent, transaction <c4292519b328fcfa8f92300d55a33a1d9a2b1788b0988c501adea6a51452f52a>

[wallet/0 9svHk1]: transfer BhQjPZ8XUkojSdcB8jhB4uTeqLQVHtfsYTxTm3n32yXM37qXqN8RdTXduKSEH4rrAp4ZuUFbv8Wak3i1QudCJhvwJVUU5dx 3
Money successfully sent, transaction <8c473e823e6b1262a55b8456c19f1b9fba0090c089222435c3bccdbeac10fc99>

[wallet/0 9svHk1]: transfer BbXfcfWRiUAcG7hoXvdRY8QtVisRPj1EQEbMoWWHGPXqQKVKWoSNNgbPEuSFm6YuDHUVaWwyqu876WKZrUmVMk8DLsrSMSN 4
Money successfully sent, transaction <27d55c3af091cccb9e9fc6eb17f0e3e6ff700af066fb6471a3533c4f19af70c3>

Now we delete the cache of the receiving wallet 9uPkEU and re-generate it by scanning the blockchain again (which gives the same effect as restoring the wallet from the seed):

Monero 'Wolfram Warptangent' (v0.10.3.1-a261d3b)
Logging to /Users/kenshi/dev/github/kenshi84/monero/build/release/bin/monero-wallet-cli.log
Wallet password: *
Opened wallet: 9uPkEUFcFujaw1YCDHhcvuUqQm9cGBBuu5KkGggFR9XMjQtXtFzUDbRU9oy4XYer9SeaSGAhtoT1xDsBuVDRqfg9GG2ji9U
**********************************************************************
Use "help" command to see the list of available commands.
**********************************************************************
Starting refresh...
Height 949115, txid <2c9d55d65f67243f771729ecd93a089ca0fcde3451f5a7740a4df70d8240b95b>, 0.130000000000 XMR, idx 0/1
Height 949115, txid <68ee8848bbb953e3a0bc8d3175e8724c3fb04cd2e49244c76d26d5b2fa2a6da2>, 0.020000000000 XMR, idx 0/0
Height 949115, txid <01f3865e63613413f6de4d4cd2b2638b679aa604c06299ad4b562364afc8cf5a>, 0.110000000000 XMR, idx 0/1
Height 949115, txid <b3bd13988448ef3bb95e6f3bf007f42ebc4f0d21346b6c4d45e42d53caa3e297>, 0.120000000000 XMR, idx 0/1
Height 949115, txid <05a97709858358ec8bb008cc8ad7f70e35ec07219cc8744138473200bb9922ec>, 0.230000000000 XMR, idx 0/2
Height 949115, txid <9a1527acdce60bbe38c8c7e9d3bfe894108d5b30eb630904a3b3afd5059b3344>, 0.210000000000 XMR, idx 0/2
Height 949115, txid <6716c0707b4c198777adbcda6b630b6248ef07fb86d20ba4469dcf661f5b35ee>, 0.010000000000 XMR, idx 0/0
Height 949115, txid <04bf1d9a5b8b3fe74d26bd068844f4709b22c92f6a3b5594f217c22df88f8184>, 0.030000000000 XMR, idx 0/0
Height 949115, txid <02b76b48467a806c6e45ce6fdf59df3c694f857f450a450537a9769f911fee46>, 0.220000000000 XMR, idx 0/2
Height 949116, txid <92f3b54a3044eddf3fd84742852f8a81b55e92055281c945bd7dee85e589ccc2>, 1.010000000000 XMR, idx 1/0
Height 949117, txid <d2617a1da91203247f8b904cf05906973cc9a64bff8d6ab4d956f22cb5d5271e>, 1.030000000000 XMR, idx 1/0
Height 949117, txid <441b07d91f64adf1b4f8350ca33902ed4aab306df3f66e1673d35a151186140c>, 1.020000000000 XMR, idx 1/0
Height 949126, txid <0f5fcd710b94e49b61fedf93de92b444021292fbffb57c281ee6952190dc0bbf>, 1.110000000000 XMR, idx 1/1
Height 949126, txid <73a83e4de08d84d9d72c707c0406fcba92994a56feb42102e3ca7c3733613c5e>, 1.210000000000 XMR, idx 1/2
Height 949126, txid <9bdba78cd150cf4027282cdabb5893c0c7fb4c0d8ddf0f9096598b4bea87af69>, 1.230000000000 XMR, idx 1/2
Height 949126, txid <22e4ac8469654903da34ce06ab06840648338d9d9dfc3f59714777d7a5a5256b>, 1.120000000000 XMR, idx 1/1
Height 949126, txid <36b14c61ad93c4a8d16f10d88525222391717d87099bb30cd8c3da6c90849818>, 1.130000000000 XMR, idx 1/1
Height 949126, txid <99b7c48a24e44c3336dc0f4b884ad33e89668e4dd9c288c67e60ffea9506ed26>, 1.220000000000 XMR, idx 1/2
Height 949248, txid <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>, 0.088280640000 XMR, idx 1/0
Height 949248, txid <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>, spent 1.110000000000, account 1
Height 949344, txid <ddb1d29f54f4de8e88fddd31379d6bf30ba4d311ae648d05c9962cfb59e494b1>, 1.000000000000 XMR, idx 1/150
Height 949344, txid <8c473e823e6b1262a55b8456c19f1b9fba0090c089222435c3bccdbeac10fc99>, 3.000000000000 XMR, idx 15/0
Refresh done, blocks received: 24696                            
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        1.080000000000        1.080000000000               Default
       1 Bd2qqa       10.058280640000        9.058280640000                      
       2 BaTkbd        0.000000000000        0.000000000000                      
       3 BeaUVm        0.000000000000        0.000000000000                      
       4 BfH7tK        0.000000000000        0.000000000000                      
       5 BfDmWH        0.000000000000        0.000000000000                      
       6 BfwsE7        0.000000000000        0.000000000000                      
       7 Bam7fW        0.000000000000        0.000000000000                      
       8 BePNm3        0.000000000000        0.000000000000                      
       9 BgkPAD        0.000000000000        0.000000000000                      
      10 BYQtBx        0.000000000000        0.000000000000                      
      11 BZEjtF        0.000000000000        0.000000000000                      
      12 BbkUr7        0.000000000000        0.000000000000                      
      13 Bg34Jy        0.000000000000        0.000000000000                      
      14 BYqzux        0.000000000000        0.000000000000                      
      15 BhQjPZ        3.000000000000        0.000000000000                      
----------------------------------------------------------------------------------
          Total       14.138280640000       10.138280640000
Currently selected account: [0] Default
Balance: 1.080000000000, unlocked balance: 1.080000000000
Background refresh thread started

Note that at this point, the wallet was able to successfully recognize incoming transfers to indices of 1/150 and 15/0, but failed to recognize incoming transfers to 1/360 and 70/0 because 360 > 150 + SUBADDRESS_LOOKAHEAD_MINOR and 70 > 15 + SUBADDRESS_LOOKAHEAD_MAJOR. You can make the wallet recognize those incoming transfers by manually expanding the hashtable and rescanning the blockchain:

[wallet/1 Bd2qqa]: address new
151  BaTjSeUuSX4KtS6DmQXRfcN3xkTAyuG2NMg3r6JpR4JujotNw8dvGKBbVehURSoMSpSsKJQTWi4eQCJxsjXuXber9WUKQ53  

...

[wallet/1 Bd2qqa]: address new
161  BbA5zmZzn9ZPvzazMHBjQzXZHaYDjWeWfN258AZufhPK3i2uF6GCdvGMMksA7qMmXxcswEfkwucuuJPDYGvR77Ux7iczJzD  

[wallet/1 Bd2qqa]: account new
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        1.080000000000        1.080000000000               Default
       1 Bd2qqa       10.058280640000        9.058280640000                      
       2 BaTkbd        0.000000000000        0.000000000000                      
       3 BeaUVm        0.000000000000        0.000000000000                      
       4 BfH7tK        0.000000000000        0.000000000000                      
       5 BfDmWH        0.000000000000        0.000000000000                      
       6 BfwsE7        0.000000000000        0.000000000000                      
       7 Bam7fW        0.000000000000        0.000000000000                      
       8 BePNm3        0.000000000000        0.000000000000                      
       9 BgkPAD        0.000000000000        0.000000000000                      
      10 BYQtBx        0.000000000000        0.000000000000                      
      11 BZEjtF        0.000000000000        0.000000000000                      
      12 BbkUr7        0.000000000000        0.000000000000                      
      13 Bg34Jy        0.000000000000        0.000000000000                      
      14 BYqzux        0.000000000000        0.000000000000                      
      15 BhQjPZ        3.000000000000        0.000000000000                      
      16 BePZ3e        0.000000000000        0.000000000000                      
----------------------------------------------------------------------------------
          Total       14.138280640000       10.138280640000

...

[wallet/20 BgjB9f]: account new
        Account               Balance      Unlocked balance                 Label
       0 9uPkEU        1.080000000000        1.080000000000               Default
       1 Bd2qqa       12.058280640000        9.058280640000                      
       2 BaTkbd        0.000000000000        0.000000000000                      
       3 BeaUVm        0.000000000000        0.000000000000                      
       4 BfH7tK        0.000000000000        0.000000000000                      
       5 BfDmWH        0.000000000000        0.000000000000                      
       6 BfwsE7        0.000000000000        0.000000000000                      
       7 Bam7fW        0.000000000000        0.000000000000                      
       8 BePNm3        0.000000000000        0.000000000000                      
       9 BgkPAD        0.000000000000        0.000000000000                      
      10 BYQtBx        0.000000000000        0.000000000000                      
      11 BZEjtF        0.000000000000        0.000000000000                      
      12 BbkUr7        0.000000000000        0.000000000000                      
      13 Bg34Jy        0.000000000000        0.000000000000                      
      14 BYqzux        0.000000000000        0.000000000000                      
      15 BhQjPZ        3.000000000000        0.000000000000                      
      16 BePZ3e        0.000000000000        0.000000000000                      
      17 BcMMgP        0.000000000000        0.000000000000                      
      18 Bf7N2v        0.000000000000        0.000000000000                      
      19 BbNHEQ        0.000000000000        0.000000000000                      
      20 BgjB9f        0.000000000000        0.000000000000                      
      21 Bd1dhR        0.000000000000        0.000000000000                      
----------------------------------------------------------------------------------
          Total       16.138280640000       10.138280640000


[wallet/21 Bd1dhR]: rescan_bc
Starting refresh...
Height 949115, txid <2c9d55d65f67243f771729ecd93a089ca0fcde3451f5a7740a4df70d8240b95b>, 0.130000000000 XMR, idx 0/1
Height 949115, txid <68ee8848bbb953e3a0bc8d3175e8724c3fb04cd2e49244c76d26d5b2fa2a6da2>, 0.020000000000 XMR, idx 0/0
Height 949115, txid <01f3865e63613413f6de4d4cd2b2638b679aa604c06299ad4b562364afc8cf5a>, 0.110000000000 XMR, idx 0/1
Height 949115, txid <b3bd13988448ef3bb95e6f3bf007f42ebc4f0d21346b6c4d45e42d53caa3e297>, 0.120000000000 XMR, idx 0/1
Height 949115, txid <05a97709858358ec8bb008cc8ad7f70e35ec07219cc8744138473200bb9922ec>, 0.230000000000 XMR, idx 0/2
Height 949115, txid <9a1527acdce60bbe38c8c7e9d3bfe894108d5b30eb630904a3b3afd5059b3344>, 0.210000000000 XMR, idx 0/2
Height 949115, txid <6716c0707b4c198777adbcda6b630b6248ef07fb86d20ba4469dcf661f5b35ee>, 0.010000000000 XMR, idx 0/0
Height 949115, txid <04bf1d9a5b8b3fe74d26bd068844f4709b22c92f6a3b5594f217c22df88f8184>, 0.030000000000 XMR, idx 0/0
Height 949115, txid <02b76b48467a806c6e45ce6fdf59df3c694f857f450a450537a9769f911fee46>, 0.220000000000 XMR, idx 0/2
Height 949116, txid <92f3b54a3044eddf3fd84742852f8a81b55e92055281c945bd7dee85e589ccc2>, 1.010000000000 XMR, idx 1/0
Height 949117, txid <d2617a1da91203247f8b904cf05906973cc9a64bff8d6ab4d956f22cb5d5271e>, 1.030000000000 XMR, idx 1/0
Height 949117, txid <441b07d91f64adf1b4f8350ca33902ed4aab306df3f66e1673d35a151186140c>, 1.020000000000 XMR, idx 1/0
Height 949126, txid <0f5fcd710b94e49b61fedf93de92b444021292fbffb57c281ee6952190dc0bbf>, 1.110000000000 XMR, idx 1/1
Height 949126, txid <73a83e4de08d84d9d72c707c0406fcba92994a56feb42102e3ca7c3733613c5e>, 1.210000000000 XMR, idx 1/2
Height 949126, txid <9bdba78cd150cf4027282cdabb5893c0c7fb4c0d8ddf0f9096598b4bea87af69>, 1.230000000000 XMR, idx 1/2
Height 949126, txid <22e4ac8469654903da34ce06ab06840648338d9d9dfc3f59714777d7a5a5256b>, 1.120000000000 XMR, idx 1/1
Height 949126, txid <36b14c61ad93c4a8d16f10d88525222391717d87099bb30cd8c3da6c90849818>, 1.130000000000 XMR, idx 1/1
Height 949126, txid <99b7c48a24e44c3336dc0f4b884ad33e89668e4dd9c288c67e60ffea9506ed26>, 1.220000000000 XMR, idx 1/2
Height 949248, txid <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>, 0.088280640000 XMR, idx 1/0
Height 949248, txid <6f6678b4c6b3c60bcb7eb642bc819a1b99e9c75feb7c292b3656ea7b3b4f1a62>, spent 1.110000000000, account 1
Height 949344, txid <c4292519b328fcfa8f92300d55a33a1d9a2b1788b0988c501adea6a51452f52a>, 2.000000000000 XMR, idx 1/360
Height 949344, txid <ddb1d29f54f4de8e88fddd31379d6bf30ba4d311ae648d05c9962cfb59e494b1>, 1.000000000000 XMR, idx 1/150
Height 949344, txid <27d55c3af091cccb9e9fc6eb17f0e3e6ff700af066fb6471a3533c4f19af70c3>, 4.000000000000 XMR, idx 70/0
Height 949344, txid <8c473e823e6b1262a55b8456c19f1b9fba0090c089222435c3bccdbeac10fc99>, 3.000000000000 XMR, idx 15/0
Refresh done, blocks received: 24699                            
Currently selected account: [21] 
Balance: 0.000000000000, unlocked balance: 0.000000000000

4. ToDo

• Review
• Unit test & performance test
• Update MRL-0006

5. Related links

• Reddit post mentioning this PR: https://www.reddit.com/r/Monero/comments/6e8f83/proposal_for_subaddresses_by_kenshi84_pull/

• Reddit post with some questions and answers: https://www.reddit.com/r/Monero/comments/5vgjs2/subaddresses_and_disposable_addresses/

• Question on StackExchange: https://monero.stackexchange.com/questions/3673/what-is-a-sub-address

• Community feedback: https://www.reddit.com/r/Monero/comments/67565e/feedback_requested_do_you_want_monero_to_have/

• Original post in MRL issue #7

Acknowledgements

• @JollyMort for initial discussions since the very beginning
• @knaccc for bringing up the concept of sub-addresses with a modified DH key exchange idea, and also for pointing out the fact that the change can be sent to any subaddresses
• @RandomRun for the second generation modified DH key exchange idea that solves the problem of discovery of the main wallet keys
• @luigi1111 for various suggestions and guidance

Currently Monero is pending a hard fork to modify the PoW in order to invalidate existing rumored and reported ASIC designs, and in addition to continue making such changes repeatedly to attempt to prevent ASIC development and deployment on the network. For various reasons, there are longer-term concerns with this strategy, particularly going forward, including:

1. Continued and repeated ad-hoc modifications to the PoW algorithm may accidentally (or even maliciously) introduce exploits.
2. ASIC developers may build in more flexibility to their designs to be able to accommodate small algorithm tweaks (indeed this may already be the case, we don't know).
3. Potential for favoritism/corruption if plans for tweaks are leaked or influenced far enough ahead of time that some favored ASIC developers may have enough lead time to produce ASICs, while others do not.
4. A belief that ASICs may be desirable as a means to facilitate industrial scale mining and growing the network beyond what might be called a hobby mining phase.
5. Potential for increased monopolization if the strategy is only partially effective (i.e. keeps all but one ASIC developer from succeeding)
6. Dependence of the network on continued frequent hard forking independent of the need for functional upgrades. This carries with it a greater degree of centralization necessary to design, implement and coordinate these forks, without any real plan to transition beyond it.

For these reasons I would propose that we consider (which does not necessarily mean implement) abandoning the ASIC-hostile approach and instead consider adopting an ASIC-friendly approach in a future hard fork.

By ASIC-friendly, I mean something that not only can reasonably be implemented in an ASIC, but which minimizes barriers to creating ASICs, minimizes their costs, facilitates the development of a wide range of compatible hardware at attractive price points, and minimizes opportunities for clever proprietary advantages. By doing so we may maximize the likelihood of a competitive ASIC market developing and minimize the degree of (temporarily or sustained) monopolization. This could possibly be achieved by using a simple, well-known, and well understood algorithm such as SHA3.

There are numerous other potential advantages and disadvantages of this approach relative to Monero's current PoW algorithm and strategy, which can be discussed in comments.

Postscript: My personal view has always been largely ASIC-hostile (primarily based on my analysis the history of the Bitcoin ASIC market when Monero launched in 2014, but reinforced by the continued evolution of the Bitcoin and other coin ASIC markets over the past four years), however I am open to the possibility that unintended consequences of attempting to maintain this approach may cause more harm than overall benefits, in which case it should be dropped.

TL;DR There is an edit at the bottom of this post highlighting what is going on because a lot has changed over many discussions, and better alternatives are being explored.

You may want to grab a drink for this one...

As we all know there will be a hardfork in September 2017 that will raise the mandatory ringsize to 4 based on the recommendations of MRL-4, but this paper was published before RingCT was found to have extraordinary savings in transaction size for transactions with larger ringsizes.

We have 7 months to explore alternatives and I would like to discuss some viable options for raising the mandatory ringsize for the v5 hardfork, so that we do not need to again change it in a future hardfork unless certain circumstances arise.

It is important to note that raising the ringsize of a transaction will increase the time it takes to verify transactions for nodes, but as far as I am aware this scales linearly(?). So this can be maintained to a reasonable degree and if we assume processor speeds continue to improve, then this problem does not greatly impact the scalability of the Monero network in comparison to the relative gains of privacy for its users. Optimizations in ring signatures and rangeproofs will certainly ease these concerns.

There are two options I would like to explore:

1. Simply raising the mandatory ringsize to a value greater than 4 that can take full advantage of RingCT's optimizations in transaction size without sacrificing very much performance. Ring size 8 could for example easily be used instead of 4 and still have very good performance for example.

and the more interesting option

2. Raising the mandatory ringsize and have it be static so no other ringsizes are accepted in the Monero network. Static ringsizes 9, 12, or 15 would be good options and I will explain a bit more about why those ringsizes specifically are special later below.

The first option would be simple to implement and the optimizations of RingCT would be immediately realized with very little added cost. However the second option will bolster privacy on the Monero network by a much higher degree. By enforcing only one valid ringsize for transactions this removes any confusion and complexity for new users who do not understand why you would want to increase the ringsize of a transaction if transactions in Monero are all already private. Since the protocol would be enforcing a static ringsize, then all transactions would be homogenous and would circumvent analysis of transactions by adversaries who may know that for example exchange x uses ringsize y for all their outgoing transactions, or that there is a user that regularly specifies atypical ringsizes like 41 for all their transactions. This removes a human element to transactions that could save people from unintentionally reducing their privacy as well as other users' privacy.

In the future, businesses and services could be 'assigned' very specific ringsizes that would stick out on the blockchain for passive observers to more easily identify their outputs in other ring signatures, this is only hypothetical and one of many possible scenarios where irregular ringsizes could reduce privacy in the Monero network.

I believe that this is a very valuable and natural addition to Monero since the protocol already makes decisions to protect its users like dynamic fees and randomly choosing their ring partners according to specific parameters. A static ringsize would just further streamline the user experience while defending against many attacks via passive analysis of ring signatures.

In addition to the arguments I made for a static ringsize I will also propose a new output selection algorithm to assist a static ringsize. Going back to why I had specifically mentioned static ringsizes 9, 12, and 15 is because if a third of ring partners are chosen randomly from the past five days and the remaining two thirds of ring partners are chosen at random then a few narrow edge cases that would threaten privacy would be completely eliminated or at the very least much less impactful than only having a default ringsize 4.

I will demonstrate these claims with some hypothetical scenarios using a ringsize of 12 as an example.

Scenario 1: Alice sends Bob a transaction with an output that is two days old. In Alice's ring signature are four inputs from the past five days chosen by our output selection algorithm(plus Alice's real spend) and eight additional inputs chosen at random.

Alice has complete financial privacy as her real output is masked with the other 12 ring partners without any major inconsistencies in our output selection algorithm. Since there is a chance at least one of those eight outputs chosen at random could have been from the last five days the additional recent output in the ring signature is not entirely suspicious. This will still be taken into account by passive observers since a lot of people will be spending money soon after it has been received. Possible scenarios where this would definitely question the legitimacy of randomly chosen outputs and directly threaten privacy is discussed in more depth later.

Scenario 2: Same as Scenario 1 but instead Alice has an output that is one month old. Our output selection algorithm will again choose four random outputs from the past five days and eight outputs at random.

Now the problem is Alice has an output that is older than the outputs that would be specified from the last five days and if the other eight random outputs do not coincide with the last five days then only four recent outputs will exist in the ring signature. This is a direct indication that none of those outputs is the real spent output because only four recent outputs would be chosen from our algorithm anyway, hence being fake. Luckily the other eight random outputs still mask Alice's real output so this scenario does not greatly threaten her privacy as the transaction would effectively still have the strength of ringsize 8 down from 12.

Scenario 2 is less likely to occur if a larger timespan is chosen for recent outputs in our algorithm so the randomly chosen outputs have a higher chance to be in that timespan, but since money is typically spent within a short time after being received this will directly weaken the obfuscation of our recent outputs selected for a ring signature.

The output inconsistencies in Scenario 2 cannot be solved very well without adding additional formality to the output selection algorithm making it easier to single out specific outputs that are not consistent with our output selection rules like in Scenario 2. With a ringsize of 12 at the very least an effective strength of ringsize 8 would still exist for a transaction.

However if an observer were able to find inconsistencies within a transaction with multiple inputs, all or at least some, containing more than four outputs younger than five days old it is incredibly unlikely the other eight random outputs for each input's ring signature would contain very recent outputs. This would question the legitimacy of the eight other outputs older than five days giving the transaction a hypothetical strength equal to the number of outputs in the ring signature younger than five days old or at the absolute bare minimum the strength of ringsize 4.

These scenarios will need to be accepted to exist and thankfully do not completely destroy the privacy of a transaction with poorly chosen ring partners by the output selection algorithm.

Increasing the static ringsize would decrease the likelihood of these contradictions in ring signatures, but it is a tradeoff with transaction sizes. Ideally most transactions would be able to take full advantage of ringsize 12, but the privacy of ringsizes 4 and 8 can still be obtained in worst case scenarios.

I personally prefer ringsize 12 because at the bare minimum when the output selection is not in your favour then at the very least ringsize 4 can still be obtained, which is the original ringsize scheduled for v5 hardfork. Ultimately any ringsize greater than 9 that is a multiple of 3 can be used and if we take into account optimizations of ring signatures and rangeproofs then even larger ringsizes, factors of 3s, could be considered.

The privacy that would be gained with a static ringsize 12 far outweighs any short term scalability issues that may arise in my opinion and would be a boon to the privacy and security of the Monero network while having good safe guards for maintaining a minimum privacy level of ringsize 4.

I hope valuable discussions can be made from this post and further optimizations that can further the security of the network can be discovered.

Thanks for taking the time to read my writeup. Any input is greatly appreciated.

EDIT: If anyone is just now finding this discussion and does not want to go through the entire backlog(I don't blame you ;) ) then to catch everyone up to speed what is happening right now is I have been surveying bitcoin transactions for the age of outputs and categorizing them by the last day, week, month, year, and older than a year to get the probability of these outputs being spent to help construct an output selection algorithm for Monero's ring signatures.

After long discussions with @iamsmooth, having only one static ringsize may be a bit extreme and does not give a user the freedom to increase their ringsize for transactions. @moneromooo-monero mentioned possibly having three static ringsizes for users to choose from. I have been favoring having only three static ringsizes because of its similarity to users being able to choose three different fee options based on urgency, we could have three ringsize options based on paranoia for users to choose from.

So for the time being we are just trying to narrow down what an output selection algorithm would look like. I have to thank @iamsmooth for giving critical feedback and nitpicking different ideas. There is no need to be increasing the ringsize from 4 after we come to a conclusion on a suitable output selection, however I still favor giving the mandatory ringsize a slight bump(to 6?) based on ringct savings in transaction size, but if there is no consensus for doing so ringsize 4 is still a strong option.

Hello. I'm trying to build monero under this OS with illumos kernel. Now I'm stuck at 90% before which I had to do many dirty hacks. Maybe you will merge them to the code later after some reworking. And FYI, I'm not a C-programmer.

0. Preparation.

pkg install git cmake gcc-49 pkg-config system/header <don't remember all packages>
wget https://raw.githubusercontent.com/zeromq/cppzmq/master/zmq.hpp -O /usr/include/zmq.hpp
git clone https://github.com/monero-project/monero.git

And here are my build iterations of cd monero && make

• Iteration 1 Result:

make[3]: Entering directory '/root/monero.build/build/release'
[  1%] Building C object external/miniupnpc/CMakeFiles/libminiupnpc-static.dir/igd_desc_parse.c.o
In file included from /usr/include/stdio.h:37:0,
                 from /root/monero.build/external/miniupnpc/igd_desc_parse.c:10:
/usr/include/sys/feature_tests.h:400:2: error: #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications       require the use of c99"
 #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \
  ^
make[3]: *** [external/miniupnpc/CMakeFiles/libminiupnpc-static.dir/build.make:63: external/miniupnpc/CMakeFiles/libminiupnpc-static.dir/igd_desc_parse.c.o] Error 1
make[3]: Leaving directory '/root/monero.build/build/release'
make[2]: *** [CMakeFiles/Makefile2:150: external/miniupnpc/CMakeFiles/libminiupnpc-static.dir/all] Error 2
make[2]: Leaving directory '/root/monero.build/build/release'
make[1]: *** [Makefile:141: all] Error 2
make[1]: Leaving directory '/root/monero.build/build/release'
make: *** [Makefile:63: release-all] Error 2

Solution: Add next code in file external/miniupnpc/CMakeLists.txt in block if (NOT WIN32) line 35

  if (CMAKE_SYSTEM_NAME MATCHES "(SunOS|Solaris)")
    add_definitions (-D__EXTENSIONS__ -std=c99)
  endif ()

• Iterarion 2 Result:

[  5%] Building C object external/unbound/CMakeFiles/unbound.dir/services/cache/dns.c.o
In file included from /root/monero.build/build/release/external/unbound/config.h:1173:0,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/root/monero.build/external/unbound/compat/fake-rfc2553.h:52:0: warning: "_SS_MAXSIZE" redefined
 # define _SS_MAXSIZE 128 /* Implementation specific max size */
 ^
In file included from /usr/include/sys/socket.h:48:0,
                 from /root/monero.build/build/release/external/unbound/config.h:918,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/usr/include/sys/socket_impl.h:70:0: note: this is the location of the previous definition
 #define _SS_MAXSIZE 256 /* Implementation specific max size */
 ^
In file included from /root/monero.build/build/release/external/unbound/config.h:1173:0,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/root/monero.build/external/unbound/compat/fake-rfc2553.h:54:8: error: redefinition of ‘struct sockaddr_storage’
 struct sockaddr_storage {
        ^
In file included from /usr/include/sys/socket.h:48:0,
                 from /root/monero.build/build/release/external/unbound/config.h:918,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/usr/include/sys/socket_impl.h:96:8: note: originally defined here
 struct sockaddr_storage {
        ^
In file included from /usr/include/sys/socket.h:48:0,
                 from /root/monero.build/build/release/external/unbound/config.h:918,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/usr/include/sys/socket_impl.h:96:8: note: originally defined here
 struct sockaddr_storage {
        ^
In file included from /root/monero.build/build/release/external/unbound/config.h:1173:0,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/root/monero.build/external/unbound/compat/fake-rfc2553.h:68:8: error: redefinition of ‘struct in6_addr’
 struct in6_addr {
        ^
In file included from /usr/include/sys/socket.h:53:0,
                 from /root/monero.build/build/release/external/unbound/config.h:918,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/usr/include/netinet/in.h:105:8: note: originally defined here
 struct in6_addr {
        ^
/root/monero.build/external/unbound/compat/fake-rfc2553.h:69:10: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ toke
n
  uint8_t s6_addr[16];
          ^
In file included from /root/monero.build/build/release/external/unbound/config.h:1173:0,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/root/monero.build/external/unbound/compat/fake-rfc2553.h:74:8: error: redefinition of ‘struct sockaddr_in6’
 struct sockaddr_in6 {
        ^
In file included from /usr/include/sys/socket.h:53:0,
                 from /root/monero.build/build/release/external/unbound/config.h:918,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/usr/include/netinet/in.h:419:8: note: originally defined here
 struct sockaddr_in6 {
        ^
In file included from /root/monero.build/build/release/external/unbound/config.h:1173:0,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/root/monero.build/external/unbound/compat/fake-rfc2553.h:136:8: error: redefinition of ‘struct addrinfo’
 struct addrinfo {
        ^
In file included from /root/monero.build/external/unbound/compat/fake-rfc2553.h:45:0,
                 from /root/monero.build/build/release/external/unbound/config.h:1173,
                 from /root/monero.build/external/unbound/services/cache/dns.c:41:
/usr/include/netdb.h:112:8: note: originally defined here
 struct addrinfo {
        ^
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/external/unbound && /usr/bin/gcc -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DDEFAULT
_DB_TYPE=\"lmdb\" -DPER_BLOCK_CHECKPOINT -D_GNU_SOURCE -I/root/monero.build/external/easylogging++ -I/root/monero.build/src -I/root/mo
nero.build/contrib/epee/include -I/root/monero.build/external -I/root/monero.build/external/unbound -I/root/monero.build/build/release
/external/unbound -DNDEBUG -Ofast -o CMakeFiles/unbound.dir/services/cache/dns.c.o   -c /root/monero.build/external/unbound/services/c
ache/dns.c
<EXCLUDED>

Problem in redefinition of structures sockaddr_storage, in6_addr, sockaddr_in6 and addrinfo in external/unbound/compat/fake-rfc2553.h after system headers in /usr/include. I studied structures in fake-rfc2553.h and decided to exclude them at all. So I commented out next code in external/unbound/config.h.cmake.in:

#ifndef HAVE_GETADDRINFO
struct sockaddr_storage;
#include "compat/fake-rfc2553.h"
#endif

and next code in external/unbound/CMakeLists.txt:

if (NOT HAVE_GETADDRINFO)
  list(APPEND compat_src
    compat/fake-rfc2553.c)
endif ()

• Iteration 3 Result:

[ 30%] Building C object src/crypto/CMakeFiles/obj_cncrypto.dir/chacha8.c.o
In file included from /root/monero.build/src/common/int-util.h:33:0,
                 from /root/monero.build/src/crypto/chacha8.c:12:
/root/monero.build/src/common/int-util.h:206:1: error: static assertion failed: "BYTE_ORDER is undefined. Perhaps, GNU extensions are
not enabled"
 static_assert(false, "BYTE_ORDER is undefined. Perhaps, GNU extensions are not enabled");
 ^
In file included from /root/monero.build/src/crypto/chacha8.c:12:0:
/root/monero.build/src/common/int-util.h:209:5: warning: "BYTE_ORDER" is not defined [-Wundef]
 #if BYTE_ORDER == LITTLE_ENDIAN
     ^
<SIMILAR ERRORS EXCLUDED>
cc1: all warnings being treated as errors
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/crypto && /usr/bin/gcc -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DDEFAULT_DB_TY
PE=\"lmdb\" -DMINIUPNP_STATICLIB -DPER_BLOCK_CHECKPOINT -DSTATICLIB -DUPNP_STATIC -I/root/monero.build/external/easylogging++ -I/root/
monero.build/src -I/root/monero.build/contrib/epee/include -I/root/monero.build/external -I/root/monero.build/external/unbound/libunbo
und -I/root/monero.build/external/db_drivers/liblmdb -fno-strict-aliasing -maes -std=c11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith
 -Wundef -Wvla -Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-variable -Wno-err
or=unused-variable -Wno-error=undef -Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Waggregate-re
turn -Wnested-externs -Wold-style-definition -Wstrict-prototypes -march=x86-64   -fno-strict-aliasing -DNDEBUG -Ofast    -Werror -o CM
akeFiles/obj_cncrypto.dir/chacha8.c.o   -c /root/monero.build/src/crypto/chacha8.c
make: Fatal error: Command failed for target `src/crypto/CMakeFiles/obj_cncrypto.dir/chacha8.c.o'
Current working directory /root/monero.build/build/release
*** Error code 1
The following command caused the error:
make -f src/crypto/CMakeFiles/obj_cncrypto.dir/build.make src/crypto/CMakeFiles/obj_cncrypto.dir/build
make: Fatal error: Command failed for target `src/crypto/CMakeFiles/obj_cncrypto.dir/all'
<EXCLUDED>

Solution: add next code in src/common/int-util.h before #if defined(__ANDROID__) line 39:

#if defined(__sun) && defined(__SVR4)
#include <endian.h>
#endif

• Iteration 4 Result:

[ 30%] Building CXX object src/crypto/CMakeFiles/obj_cncrypto.dir/crypto.cpp.o
In file included from /usr/include/boost/thread/detail/platform.hpp:17:0,
                 from /usr/include/boost/thread/mutex.hpp:12,
                 from /root/monero.build/src/crypto/crypto.cpp:37:
/usr/include/boost/config/requires_threads.hpp:47:5: error: #error "Compiler threading support is not turned on. Please set the correc
t command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)"
 #   error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux),
-pthreads (Solaris) or -mthreads (Mingw32)"
     ^
<EXCLUDED>
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/crypto && /usr/bin/c++  -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DDEFAULT_DB_T
YPE=\"lmdb\" -DMINIUPNP_STATICLIB -DPER_BLOCK_CHECKPOINT -DSTATICLIB -DUPNP_STATIC -I/root/monero.build/external/easylogging++ -I/root
/monero.build/src -I/root/monero.build/contrib/epee/include -I/root/monero.build/external -I/root/monero.build/external/unbound/libunb
ound -I/root/monero.build/external/db_drivers/liblmdb -DZMQ_STATIC -fno-strict-aliasing -maes -std=c++11 -D_GNU_SOURCE   -Wall -Wextra
 -Wpointer-arith -Wundef -Wvla -Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-v
ariable -Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cp
p -Wno-reorder -Wno-missing-field-initializers -march=x86-64   -fno-strict-aliasing -DNDEBUG -Ofast    -Werror -o CMakeFiles/obj_cncry
pto.dir/crypto.cpp.o -c /root/monero.build/src/crypto/crypto.cpp
make: Fatal error: Command failed for target `src/crypto/CMakeFiles/obj_cncrypto.dir/crypto.cpp.o'
<EXCLUDED>

Solution: add next code in monero/CMakeLists.txt before if (UNIX AND NOT APPLE) line 323:

if (CMAKE_SYSTEM_NAME MATCHES "(SunOS|Solaris)")
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthreads")
endif ()

• Iteration 5 Result:

[ 34%] Building C object src/crypto/CMakeFiles/obj_cncrypto.dir/random.c.o
/root/monero.build/src/crypto/random.c:99:1: error: destructor priorities are not supported
 FINALIZER(deinit_random) {
 ^
/root/monero.build/src/crypto/random.c:107:1: error: constructor priorities are not supported
 INITIALIZER(init_random) {
 ^
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/crypto && /usr/bin/gcc -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DDEFAULT_DB_TYPE=\"lmdb\" -DMINIUPNP_STATICLIB -DPER_BLOCK_CHECKPOINT -DSTATICLIB -DUPNP_STATIC -I/root/monero.build/external/easylogging++ -I/root/monero.build/src -I/root/monero.build/contrib/epee/include -I/root/monero.build/external -I/root/monero.build/external/unbound/libunbound -I/root/monero.build/external/db_drivers/liblmdb -fno-strict-aliasing -maes -std=c11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla -Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-variable -Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Waggregate-return -Wnested-externs -Wold-style-definition -Wstrict-prototypes -march=x86-64   -fno-strict-aliasing -DNDEBUG -Ofast    -Werror -o CMakeFiles/obj_cncrypto.dir/random.c.o   -c /root/monero.build/src/crypto/random.c
make: Fatal error: Command failed for target `src/crypto/CMakeFiles/obj_cncrypto.dir/random.c.o'

Solution (found on https://github.com/xianyi/OpenBLAS/issues/700): remove (101) in src/crypto/initializer.h lines 35 and 36. I understand that it's a dirty hack but I don't know how to write else..if there. Need a better solution.

• Iteration 6 Result:

[ 39%] Building CXX object src/common/CMakeFiles/obj_common.dir/util.cpp.o
/root/monero.build/src/common/util.cpp: In function ‘std::string tools::get_nix_version_display_string()’:
/root/monero.build/src/common/util.cpp:404:11: error: expected ‘;’ before ‘un’
   utsname un;
           ^
/root/monero.build/src/common/util.cpp:404:13: error: statement has no effect [-Werror=unused-value]
   utsname un;
             ^
/root/monero.build/src/common/util.cpp:406:13: error: ‘un’ was not declared in this scope
   if(uname(&un) < 0)
             ^
/root/monero.build/src/common/util.cpp:408:26: error: ‘un’ was not declared in this scope
   return std::string() + un.sysname + " " + un.version + " " + un.release;
                          ^
/root/monero.build/src/common/util.cpp:409:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1plus: all warnings being treated as errors
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/common && /usr/bin/c++  -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DDEFAULT_DB_TYPE=\"lmdb\" -DMINIUPNP_STATICLIB -DPER_BLOCK_CHECKPOINT -DSTATICLIB -DUPNP_STATIC -I/root/monero.build/external/easylogging++ -I/root/monero.build/src -I/root/monero.build/contrib/epee/include -I/root/monero.build/external -I/root/monero.build/external/unbound/libunbound -I/root/monero.build/external/db_drivers/liblmdb -DZMQ_STATIC -pthreads -fno-strict-aliasing -maes -std=c++11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla -Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-variable -Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Wno-reorder -Wno-missing-field-initializers -march=x86-64   -fno-strict-aliasing -DNDEBUG -Ofast    -Werror -o CMakeFiles/obj_common.dir/util.cpp.o -c /root/monero.build/src/common/util.cpp
make: Fatal error: Command failed for target `src/common/CMakeFiles/obj_common.dir/util.cpp.o'

Solution: change utsname un; in src/common/util.cpp to struct utsname un; line 404. I don't remember how I came up with this. Dirty hack. Need a better solution.

• Iteration 7 Result:

[ 45%] Building CXX object src/cryptonote_core/CMakeFiles/obj_cryptonote_core.dir/blockchain.cpp.o
In file included from /usr/include/boost/asio/detail/socket_types.hpp:81:0,
                 from /usr/include/boost/asio/detail/impl/pipe_select_interrupter.ipp:31,
                 from /usr/include/boost/asio/detail/pipe_select_interrupter.hpp:82,
                 from /usr/include/boost/asio/detail/select_interrupter.hpp:27,
                 from /usr/include/boost/asio/detail/dev_poll_reactor.hpp:31,
                 from /usr/include/boost/asio/detail/reactor.hpp:25,
                 from /usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
                 from /usr/include/boost/asio/detail/task_io_service.hpp:198,
                 from /usr/include/boost/asio/impl/io_service.hpp:71,
                 from /usr/include/boost/asio/io_service.hpp:767,
                 from /root/monero.build/src/cryptonote_core/blockchain.h:32,
                 from /root/monero.build/src/cryptonote_core/blockchain.cpp:39:
/usr/include/net/if.h:97:9: error: template argument required for ‘struct map’
  struct map *if_memmap;  /* rmap for interface specific memory */
         ^
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/cryptonote_core && /usr/bin/c++  -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DDEFAULT_DB_TYPE=\"lmdb\" -DMINIUPNP_STATICLIB -DPER_BLOCK_CHECKPOINT -DSTATICLIB -DUPNP_STATIC -I/root/monero.build/external/easylogging++ -I/root/monero.build/src -I/root/monero.build/contrib/epee/include -I/root/monero.build/external -I/root/monero.build/external/unbound/libunbound -I/root/monero.build/external/db_drivers/liblmdb -DZMQ_STATIC -pthreads -fno-strict-aliasing -maes -std=c++11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla -Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-variable -Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Wno-reorder -Wno-missing-field-initializers -march=x86-64   -fno-strict-aliasing -DNDEBUG -Ofast    -Werror -o CMakeFiles/obj_cryptonote_core.dir/blockchain.cpp.o -c /root/monero.build/src/cryptonote_core/blockchain.cpp
make: Fatal error: Command failed for target `src/cryptonote_core/CMakeFiles/obj_cryptonote_core.dir/blockchain.cpp.o'

Solution: move #include "blockchain.h" in src/cryptonote_core/blockchain.cpp higher in the includes (for example to the line 36).

• Iteration 8 Result:

[ 46%] Building CXX object src/cryptonote_core/CMakeFiles/obj_cryptonote_core.dir/tx_pool.cpp.o
/usr/include/net/if.h:97:9: error: template argument required for ‘struct map’
  struct map *if_memmap;  /* rmap for interface specific memory */
         ^

Solution (same as in previous iteration): move #include "blockchain.h" in src/cryptonote_core/tx_pool.cpp higher in the includes) for example to the line 36).

• Iteration 9 Result:

[ 48%] Linking CXX static library libblockchain_db.a
[ 48%] Built target blockchain_db
[ 48%] Generating blocks.o
ld: fatal: file binary: open failed: No such file or directory
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/blocks && cd /root/monero.build/src/blocks && /usr/bin/ld -r -b binary -o /root/monero.build/build/release/src/blocks/blocks.o blocks.dat
make: Fatal error: Command failed for target `src/blocks/blocks.o'

Problem is in link editor:

# /usr/bin/ld --version
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1755 (illumos)
# /usr/gnu/bin/ld --version
GNU ld (GNU Binutils) 2.25.1
Copyright (C) 2014 Free Software Foundation, Inc.

In Solaris version option '-b' have other purpose not the binary format as in GNU version. So I fixed this by overriding CMAKE_LINKER in src/blocks/CMakeLists.txt line 29:

if (CMAKE_SYSTEM_NAME MATCHES "(SunOS|Solaris)")
  set(CMAKE_LINKER "/usr/gnu/bin/ld")
endif ()

• Iteration 10 Result:

[ 55%] Building CXX object tests/core_tests/CMakeFiles/coretests.dir/block_reward.cpp.o
In file included from /usr/include/boost/asio/detail/socket_types.hpp:81:0,
                 from /usr/include/boost/asio/detail/impl/pipe_select_interrupter.ipp:31,
                 from /usr/include/boost/asio/detail/pipe_select_interrupter.hpp:82,
                 from /usr/include/boost/asio/detail/select_interrupter.hpp:27,
                 from /usr/include/boost/asio/detail/dev_poll_reactor.hpp:31,
                 from /usr/include/boost/asio/detail/reactor.hpp:25,
                 from /usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
                 from /usr/include/boost/asio/detail/task_io_service.hpp:198,
                 from /usr/include/boost/asio/impl/io_service.hpp:71,
                 from /usr/include/boost/asio/io_service.hpp:767,
                 from /root/monero.build/contrib/epee/include/net/net_utils_base.h:32,
                 from /root/monero.build/src/p2p/net_node_common.h:34,
                 from /root/monero.build/src/cryptonote_core/cryptonote_core.h:39,
                 from /root/monero.build/tests/core_tests/chaingen.h:51,
                 from /root/monero.build/tests/core_tests/block_reward.cpp:31:
/usr/include/net/if.h:97:9: error: template argument required for ‘struct map’
  struct map *if_memmap;  /* rmap for interface specific memory */
         ^

Again as in iterations 7 and 8. I could not resolve it by moving up header include in various files so I just forgot about tests, removed 'build' dir and from now building with make release-static.

• Iteration 11 Result:

[ 75%] Building CXX object src/rpc/CMakeFiles/obj_daemon_rpc_server.dir/daemon_handler.cpp.o
In file included from /usr/include/boost/asio/detail/socket_types.hpp:81:0,
                 from /usr/include/boost/asio/detail/impl/pipe_select_interrupter.ipp:31,
                 from /usr/include/boost/asio/detail/pipe_select_interrupter.hpp:82,
                 from /usr/include/boost/asio/detail/select_interrupter.hpp:27,
                 from /usr/include/boost/asio/detail/dev_poll_reactor.hpp:31,
                 from /usr/include/boost/asio/detail/reactor.hpp:25,
                 from /usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
                 from /usr/include/boost/asio/detail/task_io_service.hpp:198,
                 from /usr/include/boost/asio/impl/io_service.hpp:71,
                 from /usr/include/boost/asio/io_service.hpp:767,
                 from /root/monero.build/contrib/epee/include/net/net_utils_base.h:32,
                 from /root/monero.build/src/p2p/net_node_common.h:34,
                 from /root/monero.build/src/cryptonote_core/cryptonote_core.h:39,
                 from /root/monero.build/src/rpc/daemon_handler.h:34,
                 from /root/monero.build/src/rpc/daemon_handler.cpp:29:
/usr/include/net/if.h:97:9: error: template argument required for ‘struct map’
  struct map *if_memmap;  /* rmap for interface specific memory */
         ^

And again... Solution: move #include "cryptonote_core/cryptonote_core.h" higher in src/rpc/daemon_handler.h line 31.

• Iteration 12 Result:

[ 84%] Building CXX object src/wallet/CMakeFiles/obj_wallet.dir/wallet2.cpp.o
In file included from /usr/include/boost/asio/detail/socket_types.hpp:81:0,
                 from /usr/include/boost/asio/detail/impl/pipe_select_interrupter.ipp:31,
                 from /usr/include/boost/asio/detail/pipe_select_interrupter.hpp:82,
                 from /usr/include/boost/asio/detail/select_interrupter.hpp:27,
                 from /usr/include/boost/asio/detail/dev_poll_reactor.hpp:31,
                 from /usr/include/boost/asio/detail/reactor.hpp:25,
                 from /usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
                 from /usr/include/boost/asio/detail/task_io_service.hpp:198,
                 from /usr/include/boost/asio/impl/io_service.hpp:71,
                 from /usr/include/boost/asio/io_service.hpp:767,
                 from /usr/include/boost/asio/basic_io_object.hpp:19,
                 from /usr/include/boost/asio/basic_socket.hpp:20,
                 from /usr/include/boost/asio/basic_datagram_socket.hpp:20,
                 from /usr/include/boost/asio.hpp:21,
                 from /root/monero.build/contrib/epee/include/net/net_helper.h:39,
                 from /root/monero.build/contrib/epee/include/net/http_client.h:40,
                 from /root/monero.build/src/wallet/wallet2.h:46,
                 from /root/monero.build/src/wallet/wallet2.cpp:41:
/usr/include/net/if.h:97:9: error: template argument required for ‘struct map’
  struct map *if_memmap;  /* rmap for interface specific memory */
         ^

Same problem... Solution: this time move #include "net/http_client.h" higher in src/wallet/wallet2.h line 35.

• Iteration 13 For now it is my last iteration in which I completely stuck. Result:

[ 90%] Linking CXX executable ../../bin/monero-wallet-rpc
Undefined                       first referenced
 symbol                             in file
bind                                ../../external/unbound/libunbound.a(outside_network.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
recv                                ../../external/unbound/libunbound.a(netevent.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
send                                ../../external/unbound/libunbound.a(netevent.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
__xnet_connect                      CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getservbyname                       ../../external/unbound/libunbound.a(str2wire.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
if_indextoname                      CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
__xnet_socket                       CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
__xnet_getsockopt                   CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getsockname                         CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
accept                              CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
listen                              CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
if_nametoindex                      CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
sendto                              ../../external/unbound/libunbound.a(netevent.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
socket                              ../../external/unbound/libunbound.a(outside_network.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getprotobyname                      ../../external/unbound/libunbound.a(str2wire.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getprotobynumber                    ../../external/unbound/libunbound.a(wire2str.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
setsockopt                          CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getsockopt                          ../../external/unbound/libunbound.a(netevent.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
connect                             ../../external/unbound/libunbound.a(outside_network.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
__xnet_getaddrinfo                  CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getaddrinfo                         ../../external/unbound/libunbound.a(listen_dnsport.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
getpeername                         CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
recvfrom                            ../../external/unbound/libunbound.a(netevent.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
freeaddrinfo                        CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
inet_addr                           ../../contrib/epee/src/libepee.a(string_tools.cpp.o)  (symbol belongs to implicit dependency /lib/libnsl.so.1)
inet_pton                           CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libnsl.so.1)
inet_ntoa                           ../../contrib/epee/src/libepee.a(string_tools.cpp.o)  (symbol belongs to implicit dependency /lib/libnsl.so.1)
inet_ntop                           CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libnsl.so.1)
__xnet_bind                         CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
gai_strerror                        ../../external/unbound/libunbound.a(listen_dnsport.c.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
__xnet_recvmsg                      CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
__xnet_sendmsg                      CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
shutdown                            CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o  (symbol belongs to implicit dependency /lib/libsocket.so.1)
ld: fatal: symbol referencing errors. No output written to ../../bin/monero-wallet-rpc
collect2: error: ld returned 1 exit status
*** Error code 1
The following command caused the error:
cd /root/monero.build/build/release/src/wallet && /usr/bin/cmake -E cmake_link_script CMakeFiles/wallet_rpc_server.dir/link.txt --verbose=
make: Fatal error: Command failed for target `bin/monero-wallet-rpc'
Current working directory /root/monero.build/build/release
*** Error code 1
The following command caused the error:
make -f src/wallet/CMakeFiles/wallet_rpc_server.dir/build.make src/wallet/CMakeFiles/wallet_rpc_server.dir/build
make: Fatal error: Command failed for target `src/wallet/CMakeFiles/wallet_rpc_server.dir/all'
Current working directory /root/monero.build/build/release
*** Error code 1
The following command caused the error:
make -f CMakeFiles/Makefile2 all
make: Fatal error: Command failed for target `all'
Current working directory /root/monero.build/build/release
*** Error code 1
make: Fatal error: Command failed for target `release-static'

I suspect that problem in my excluded fake-rfc2553 in unbound module. But my brain is blowed up already and I can't invent nothing anymore.

So can anybody help me to move forward or fix my hacks? Perhaps I'm doing wrong something.

Seems like this is the cause:

cc1: error: unrecognized command line option '-maes'
cc1: error: unrecognized command line option '-march=native'

Full log: https://kojipkgs.fedoraproject.org//work/tasks/3387/27023387/build.log

I2P-Java is a relatively mature project with active developers.

A few years ago, it would have been unthinkable to have to ask people to separately install a 200 MB JVM on their machine before being able to run a Monero wallet that wanted to route connections through I2P-Java.

Things have changed since then. Java 9 implemented modularization to allow zero dependency native apps with small footprints. This brings the footprint of an app with a bundled JVM down to as low as 22 MB (11 MB with compression). The end user will have no idea they're running a JVM, and no JVM will be installed. This means no conflicts with any other JVMs they may previously have installed. Even better, we now have the open source (GPLv2) OpenJDK. See https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/

zab_, one of the I2P developers, has noted in the Monero reddit that we could interface with I2P-Java via the SAM library https://github.com/i2p/libsam3 or via the lower level I2CP protocol https://geti2p.net/en/docs/protocol/i2cp (zab_'s comment here).

Hi guys

I have a brand new RockPro64 running Arbian on eMMC and writing the data do an NVMe. I must have tried 10 times already with different degrees of progress (between about 10%-47%) before failure with different errors.

The latest log:

popping blocks from the stack does not work:

my drive is not full yet:

my monerod.conf file has reasonably settings afaik:

Please tell me it cant be hardware related? It is brand new? Is there a way to test?

This issue is quite minor, simply opening the wallet again fixes the issue. It has happened a couple of times now so I’ve created an issue to document it.

selsta@mbpR ~/d/m/b/D/l/r/bin> ./monero-wallet-cli --wallet-file ledger
2018-10-08 20:09:40,705 INFO  [default] Page size: 4096
This is the command line monero wallet. It needs to connect to a monero
daemon to work correctly.
WARNING: Do not reuse your Monero keys on another fork, UNLESS this fork has key reuse mitigations built in. Doing so will harm your privacy.

Monero 'Beryllium Bullet' (v0.13.0.1-rc-ac567452)
Logging to ./monero-wallet-cli.log
Wallet password: 
Error: failed to load wallet: Wrong sequence_idx

/cc @cslashm

This is a proposed tweak to the cryptonote algorithm for the next release. This was designed to "augment" CNv2, and reduce the chances of pre-built boards for those changes. Advantages:

• Works with or without CNv2 changes by @SChernykh .
• Any manufactured boards that implement one pass of the primary loop in the original, v1, or CNv2 algorithm is unlikely to work.
• Any manufactured boards that have an implementation of the 8-byte multiply then 8-byte add routine (which could be leveraged in in v0, v1, or v2) is unlikely to work.
• XORing was used because it is not distributive or associative over addition or multiplication. So XOR should require an order for the operations around the multiply/add sections of the original and CNv2 design.

Negatives:

• Any existing design for the original, v1, or CNv2 is probably easy to update.
• Any highly custom RISC/microcoded chip is unlikely to have much additional penalty (i.e. if some chips were designed for use with CNv2 instructions, this doesn't change performance much).

Feedback from the community is strongly encouraged. Possible additional techniques could involve mixing information from earlier stages of the pipeline or CNv2 stages.

Issue mentioned by @plowsof in #8697

when service monerod is running, if you monerod exit the service gets uninstalled (?). so if e.g. the GUI implements this - clicking 'stop daemon' would uninstall the service, (run time flags will reveal that its in service mode)

As of libreadline >= 8.1, bracketed paste sequences are enabled by default. This turns them off. This along with #8693, should mean that with environment variable NO_COLOR present, no escape sequences are generated in the output, just plain text.

current behaviour:

1. from a terminal with admin rights monerod.exe --data-dir G:\\ --install-service
2. monerod is added to services but not running
3. monerod.exe --start-service - runs, and works perfectly
4. restart system - monerod service is "stopped"/not running after boot.

with SERVICE_AUTO_START:: 4. restart system - monerod service is running as expected.

notes: (fixed by #8700 ) when service monerod is running, if you monerod exit the service gets uninstalled (?). so if e.g. the GUI implements this - clicking 'stop daemon' would uninstall the service, (run time flags will reveal that its in service mode)

gcc (Gentoo Hardened 12.2.1_p20221224 p7) 12.2.1 20221224

FAILED: src/common/CMakeFiles/obj_common.dir/threadpool.cpp.o 
/usr/bin/ccache /usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++ -DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB -DBOOST_ASIO_ENABLE_SEQUENTIAL_STRAND_ALLOCATION -DDEFAULT_DB_TYPE=\"lmdb\" -DHAVE_EXPLICIT_BZERO -DHAVE_HIDAPI -DHAVE_READLINE -DHAVE_STRPTIME -DPER_BLOCK_CHECKPOINT -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/external/rapidjson/include -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/external/easylogging++ -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/contrib/epee/include -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/external -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2_build/generated_include -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2_build/translations -I/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/external/db_drivers/liblmdb -I/usr/include/hidapi  -O2 -pipe -march=native -ftree-vectorize -malign-data=cacheline -mtls-dialect=gnu2 -pthread -maes -march=native -fno-strict-aliasing -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla -Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Wno-reorder -Wno-missing-field-initializers -fPIC  -Wformat -Wformat-security -fstack-protector -fstack-protector-strong -fcf-protection=full -fstack-clash-protection -Werror=switch -Werror=return-type -fno-strict-aliasing -ftemplate-depth=900 -std=c++14 -MD -MT src/common/CMakeFiles/obj_common.dir/threadpool.cpp.o -MF src/common/CMakeFiles/obj_common.dir/threadpool.cpp.o.d -o src/common/CMakeFiles/obj_common.dir/threadpool.cpp.o -c /var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp
In file included from /var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp:29:
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.h:96:10: error: ‘deque’ in namespace ‘std’ does not name a template type
   96 |     std::deque<entry> queue;
      |          ^~~~~
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.h:33:1: note: ‘std::deque’ is defined in header ‘<deque>’; did you forget to ‘#include <deque>’?
   32 | #include <boost/thread/thread.hpp>
  +++ |+#include <deque>
   33 | #include <cstddef>
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp: In member function ‘void tools::threadpool::submit(waiter*, std::function<void()>, bool)’:
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp:88:36: error: ‘queue’ was not declared in this scope; did you mean ‘sigqueue’?
   88 |   if (!leaf && ((active == max && !queue.empty()) || depth > 0)) {
      |                                    ^~~~~
      |                                    sigqueue
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp: In member function ‘void tools::threadpool::run(bool)’:
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp:155:11: error: ‘queue’ was not declared in this scope; did you mean ‘sigqueue’?
  155 |     while(queue.empty() && running)
      |           ^~~~~
      |           sigqueue
/var/tmp/portage/net-p2p/monero-0.18.1.2/work/monero-0.18.1.2/src/common/threadpool.cpp:164:19: error: ‘queue’ was not declared in this scope; did you mean ‘sigqueue’?
  164 |     e = std::move(queue.front());
      |                   ^~~~~
      |                   sigqueue

For privacy reasons, time functions use GMT, to avoid logs leaking timezones. It'd make more sense to use localtime for wallet output (which are not logged by default), but that adds inconsistencies which can also be confusing. So add a Z suffix for now to make it clear these are not local time.