tSLMs on fresh addresses

[buhtignew]

Today I've created two new addresses using the following commands: address set locator_test -f and address set locator_test1 -f. The relative outputs were:

Label: locator_test
Value: mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw
New address created: mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw with label (name): locator_test
Address already is saved in your wallet, ready to use.

and

Stored address:
Label: locator_test1
Value: myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y
New address created: myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y with label (name): locator_test1
Address already is saved in your wallet, ready to use.

After that I've run address cache mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw, which I've interrupted (CTRL+Z from inside the pacli_env process) at block 2800. Then I've run address cache mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw -b 30, address cache mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw -b 100, address cache mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw -b 5000 and address cache mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw -b 5000.

For the address myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y I've run address cache "[myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y]" (interrupted pacli_env after 400 blocks),address cache "[myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y]" -s 422300,address cache "[myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y]" -s 422100,address cache "[myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y]" -e,address cache "[myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y]" -s 422100`.

Right now I'm seeing 759.98 tSlms on mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw and 813.43 tSlms on myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y.

However I haven't moved anything towards those addresses.

The address myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y was created after the block 422381 but if I run address cache myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y -s 422300 I'm getting the following output:

Processing block: 422300
Processing block: 422400
Processing block: 422500
You have reached the tip of the blockchain.
Storing new locator block heights.
0 matching transactions found in the scanned blocks.

(I've run address cache myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y -e before).

I can't tell for sure what was the block before I've created the address mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw, but it was like view minutes before the other one. However if I run address cache mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw -s 421000 the output is:

Processing block: 421000
Processing block: 421100
Processing block: 421200
Processing block: 421300
Processing block: 421400
Processing block: 421500
Processing block: 421600
Processing block: 421700
Processing block: 421800
Processing block: 421900
Processing block: 422000
Processing block: 422100
Processing block: 422200
Processing block: 422300
Processing block: 422400
Processing block: 422500
You have reached the tip of the blockchain.
Storing new locator block heights.
0 matching transactions found in the scanned blocks.

I assume that addresses weren't created anew, but were already in my wallet without pacli knowing it.

I've run address set locator_test2 -f right now and got 626.71 tSLMs on it. The address cache locator_test2 -s 421000 output is:

Processing block: 421000
Processing block: 421100
Processing block: 421200
Processing block: 421300
Processing block: 421400
Processing block: 421500
Processing block: 421600
Processing block: 421700
Processing block: 421800
Processing block: 421900
Processing block: 422000
Processing block: 422100
Processing block: 422200
Processing block: 422300
Processing block: 422400
Processing block: 422500
You have reached the tip of the blockchain.
Storing new locator block heights.
0 matching transactions found in the scanned blocks.

I've compared the outputs of address list before and after locator_test2 creation and they are identical, except for the new address added, i.e. the 626.71 tSlms hasn't been taken from none other address.

Update: The output of transaction list mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw, transaction list locator_test2 and transaction list myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y is the same:

Searching transactions (this can take several minutes) ...
No matching transactions found.

[d5000]

Can you provide me the private keys of these addresses so I can import them? Otherwise it's impossible to reproduce this problem.

[buhtignew]

Here are them:

mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw cS4A2o73g3Ysca1ev6cZbFafsAE4yT4DgrWX2rgXvJCkiiwC4iAX
myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y cNs7DpcWqw13tCM4nRKWjD4UktTHyrSJ7DRohNiYPBAoAhYD5cJj
mgpKAUYnTyo9FKEhHKYeXMzBFkLdPBuW8j cTgZ1ZAkyzFyNwa8mUUQWorXdfj3GyxkKwdga4pHvGiY148ne8x2

You don't have the same issue while creating fresh addresses with pacli, do you?

[d5000]

I have reproduced the issue now. It is like you suspected: Pacli (or better: the slimcoind getnewaddress command, which is called by the address set -f code) provides an used address in some cases (I did a couple of tests, in a considerable number of cases - about 30-40% - when I generate a fresh address the address was already used).

All transactions to these addresses were mining transactions and are already a bit older (more than 10k confirmations).

I found this related issue at Stackexchange: https://github.com/bitcoin/bitcoin/issues/10411

In the stackexchange thread the reason was that the wallet file was used by another node. It seems that if you use an address for mining, the client blacklists it for the "getnewaddress" command so no used address would be given out. But it was another SLM client using it when the coins were mined, the blacklisting does not work, and if you use the wallet file in your main node afterwards, then an used address can be given out by getnewaddress.

I was wondering if these coins were mined or minted (PoB or PoS) when I had loaded your wallet, perhaps it mined then on my node to some of your "empty" addresses of the keypool*, but only my node knows about these transactions so it didn't blacklist it?

In my case it's also possible that something similar happened because I used several different wallet files for tests, so it's possible one node minted to an address and the other node didn't know about that.

I did now the following: I refilled the keypool with slimcoind keypoolrefill. Then I generated 10 addresses with address set -f. All were unused. Perhaps this solves the problem. Perhaps you can try that too and report if there are still some used addresses?

I think this is something we have to observe if it continues to happen in the future, but if not, then probably the explanation of Stackexchange is correct, and then it's nothing we have really to worry.

---

*keypool is a number of keys Bitcoin/Slimcoin generates as a reserve for new addresses. In other words: when getnewaddress is called, the address isn't generated "on the fly" but it's one of those stored already in the keypool. It is regularly refilled but you can also refill it manually with the keypoolrefill command.

[buhtignew]

I've run slimcoind keypoolrefill and then 10 times address set -f as you suggested.

Here are the addresses that have been added to my address list:

new_after_refill   | mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH | 879.38
new_after_refill1  | mnYTcGF8vVuSAYeoxxNaFWX94QUFM92YZf | 784.57
new_after_refill3  | n3qWzoBX24abCSq8hMMzmCb8dh5ePnhdmL | 540.44
new_after_refill4  | n454R3cUohDkjPvfkpjMZysWjp6FkR8mfC | 622.88
new_after_refill5  | n1zrFcgeDhcMP3PGyttiKviAW92TMrQf6r | 682.16
new_after_refill6  | mffwdnxCEFgM2GoZD1Cd6yibPB43RewaVA | 651.01
new_after_refill7  | n3eHVFDPbBHuq9CrNjirJ33GNTQuMnRZVy | 420.44
new_after_refill8  | mkxLRzTvrEpPbFxkp4tnRGXQ6UKcKH25TA | 198.53
new_after_refill9  | mtYvCVBtEayA5y6szGSrSgGwHQfe44Bgh2 | 91.55
new_after_refill2  | mk9WFSTqgtTJbwb5g6pGpByTRbYKiSaX3w | 21.43

Would you be able to find the above addresses in your version of my wallet.dat? (Using slimcoind dumpprivkey [relative_address], for instance.) I'm wondering whether they were already in my wallet, used as change address.

Another test I'd try is whether your version of my wallet would create the same addresses if you run address set -f on your side.

What worries me most is that there are no transactions connected with those amount in my transaction list [relative_address] output. Does pacli consider only the transactions that have to do with tokens?

However, I've run slimcoind getbalance after I've created the above addresses, trying to understand whether my wallet's balance is changing by each new non-empty address created. Then I've run address set -f 10 times again and all the new addresses I've got were empty this time:

fresh_after_refill  | n4UW9h3QvBRxdF9prmT8cP8p13Vm8VYJn9 | 0.0
fresh_after_refill1 | mue63g5tHoM4qLQNBYzF7kSHbj8yvKfVYz | 0.0
fresh_after_refill2 | mr99o4xUWMaVNmueFuqHMvZwRPxkLiQe8U | 0.0
fresh_after_refill3 | mpo8FqEPH5iSakV9GZAhRwTrvHeJ98CWBv | 0.0
fresh_after_refill4 | mwUJwJePvN3cNPaNB3LJkTLWenAXQV9ekw | 0.0
fresh_after_refill5 | n4CLjrpKA5oLuEn63M3iWfGP7fyQvxkg6b | 0.0
fresh_after_refill6 | myGqHjaG4BVnh51rh1g6w8mH2oJQZ3QCJP | 0.0
fresh_after_refill7 | mwahMEM12h4m3nuq58MwetYDYPbYUr918i | 0.0
fresh_after_refill8 | mtJoREAk9dRQQXR6KNAkXb1gYAd5LCkML9 | 0.0
fresh_after_refill9 | mxTq1JuXLMZjaKA8LkdySk3sMwhRz4FEG2 | 0.0

I assume that for some reason the queue of non-empty addresses is over on my side for the moment.

[d5000]

Indeed I'm able to dump the privkeys of your addresses, so they were already in the keypool when I checked your wallet file.

What worries me most is that there are no transactions connected with those amount in my transaction list [relative_address] output.

I was until now able to see the transactions of all those addresses I checked, including some of yours (those you provided me the private key).

It is possible that you need to rescan the blockchain first (restart slimcoind with -rescan, possibly then restart once again) for the transactions to become visible. For me that was the case with one of your addresses, but after the rescan the transactions appeard. Don't forget the -v flag for transaction list because all transactions to these addresses will be very likely mining/minting transactions.

Regarding your used addresses you got even after keypoolrefill: I've read that a rescan can prevent the "getnewaddress provides used addresses" behaviour too. Perhaps what's needed in these cases is always keypoolrefill + rescan.

Let's continue to observe this checking fresh addresses regularly. If it persists, we can continue to investigate, but the problem is not pacli but the Slimcoin client.

[buhtignew]

I've looked up all the fresh addresses with balances using transaction list -v and they all have coinbase transactions. There was no need to rescan with slimcoind.

I've noticed that some of the addresses went on generating coins since I first published their tSLMs amounts here.

Specifically mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw has 1965.13 tSLMs right now, myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y has 1660.5 tSLMs and mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH has 1099.56.

All the others are not receiving coin for the moment.

I'm trying to understand why is it that my wallet is receiving coins on those addresses, in order to be able to reproduce or at least to predict such events.

So my first assumption was that they were generated when I've temporary begun mining with my CPU because the test blockchain wasn't moving.

So I've created the following table that shows the addresses in order of their "creation" with address set -f command, the first and the last block where the coins were received:

mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw 351479 - 426082
myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y 351544 - 426088
mgpKAUYnTyo9FKEhHKYeXMzBFkLdPBuW8j 413768 - 414116
mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH 413647 - 426068
mnYTcGF8vVuSAYeoxxNaFWX94QUFM92YZf 413652 - 414132
n3qWzoBX24abCSq8hMMzmCb8dh5ePnhdmL 413764 - 414131
n454R3cUohDkjPvfkpjMZysWjp6FkR8mfC 413771 - 414121
n1zrFcgeDhcMP3PGyttiKviAW92TMrQf6r 413649 - 414125
mffwdnxCEFgM2GoZD1Cd6yibPB43RewaVA 413643 - 414124
n3eHVFDPbBHuq9CrNjirJ33GNTQuMnRZVy 413641 - 414111
mkxLRzTvrEpPbFxkp4tnRGXQ6UKcKH25TA 413779 - 414112
mtYvCVBtEayA5y6szGSrSgGwHQfe44Bgh2 413642 - 413973
mk9WFSTqgtTJbwb5g6pGpByTRbYKiSaX3w 413873 - only one transaction

However since some of the addresses are still generating coins the assumption is most probably wrong.

Since my slimcoin.conf has the minting disabled (by the line reservebalance=1000000001 while my balance agreeing to slimcoind getbalance is 219313.32105000) the only reason I see is PoB mining, which looks strange to me, because I was expecting the PoB transactions to be received by the address from which the original burn transaction was made. Is my expectation wrong? _

Regarding your used addresses you got even after keypoolrefill: I've read that a rescan can prevent the "getnewaddress provides used addresses" behaviour too. Perhaps what's needed in these cases is always keypoolrefill + rescan.

We probably should test this idea provided we truly need pacli's fresh addresses to be without SLMs on them. If not the fresh address command can be described as "importing a new address from the slimcoind keypool into pacli". If it doesn't interfere with anything else we can just warn the users that the fresh addresses may have SLMs on them sometimes.

I was also thinking about the strategy to exclude the addresses with transactions on them. In other coins there is dumpwallet command, which apparently slimcoind doesn't have. Using the list of the addresses provided by that command we'd be able to prevent the addresses with transaction on them being imported by pacli. However since we don't have that command, the idea is not to be considered.

[d5000]

The last idea, to test the addresses has a balance on them, can be implemented easily. It would make the command a bit slower however (not by much, basically by the time address balance takes).

I'd however wait with such a solution to see if this problem appears again.

I think your expectation that you should normally not be minting is correct, and I can offer no explanation for it as of now. gen is set to 0 in your slimcoin.conf, correct? I'll look into the addresses myself I found out were used.

[buhtignew]

gen is set to 0 in your slimcoin.conf, correct?

Yes my slimcoin.conf for the testnet contains the line gen=0.

I think your expectation that you should normally not be minting is correct, and I can offer no explanation for it as of now.

I think its depends on how the PoB minted coins are generated. If the mechanism is similar to the pacli token claiming procedure we have, by using the addresses that are different from original one the devs have greatly helped the slimcoin's users privacy, if on the opposite the blocks are generated by the nodes there should be a mechanism that makes the nodes retrieving the addresses of the wallet that are not the original ones, in such a case I wouldn't be that sure it's that good for the users privacy.

The last idea, to test the addresses has a balance on them, can be implemented easily.

Do we really need the fresh addresses to be without coins when created?

[d5000]

I have checked the blocks where your and my minting transaction to the "fresh" but "used" addresses were generated. Until now, all were PoW blocks, so the problem is not PoS or PoB minting not being disabled properly.

In my case 3 addresses from those I generated "freshly" were "used", I've seen that the coinbase transactions were all in the window between 13000 and 15000 confirmations, thus around block 413000, i.e. when your server just was about to be restarted. It is possible that I have mined some coins there but it is a bit strange because while I'ved tried to mine the difficulty was so high that it seemed to me that the blockchain was not advancing. Perhaps I was wrong with this and it did advance actually ... I don't remember it well.

In your case yes, I see that you continue to mine (until about 1500 blocks ago) like you wrote, and that the recent transactions are also coinbase transactions on PoW blocks, i.e. that it's PoW mining.

So my question is: are you perhaps using the same wallet file for the server and the local client? Or at least it was the same file at the start (i.e. you could have copied your wallet to the server but then never touched it again), because it's possible that the initial keypool was big enough to create all your addresses you needed until now?

If this is not possible, just to be sure: what does slimcoind getmininginfo say?

Do we really need the fresh addresses to be without coins when created?

Regarding the potential consequences that sometimes "used" addresses could be generated, the main issue is privacy, but also the principle of least astonishment of course.

What could be interesting for now and what I'm adding currently is a --check_usage or -c option for address set -f, i.e. that the check if the address was already used is not provided by default but only if the user requests it.

Edit: I implemented this option in commit 9174976, alongside fixing a bug which allowed to store invalid addresses. I decided to check transactions, not balances, which is much slower but also more reliable, because if checking balances, if the address was emptied somehow, it could have been "used" even if no balance was shown.

[buhtignew]

So my question is: are you perhaps using the same wallet file for the server and the local client? Or at least it was the same file at the start (i.e. you could have copied your wallet to the server but then never touched it again), because it's possible that the initial keypool was big enough to create all your addresses you needed until now?

I think it's possible that I've copied my local wallet to the server initially and that I've started it as well. So it might be that the server was mining with the addresses of my local wallet. However it seems to me to remember that I've deleted that wallet after a while (but not yesterday when all of my addresses seem to have stopped mining).

I've tried to discover whether the wallet I'm using right now on the server is the same of the local one.

So I've tried the following commands there:

slimcoind getreceivedbyaddress mmWqnW9DkPq2Dosm8ikmNvd8xfaeynp6iw
slimcoind getreceivedbyaddress myu48LbhEumui6yMkdD5DgYYf7STgEtF7Y
slimcoind getreceivedbyaddress mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH

and got 0.00000000.

Then I've run slimcoind getaccountaddress mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH and got mpzxsut8XKiA5tytoSzAnKSR2ogwSn2ygR While slimcoind getaccount mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH output was error: {"code":-5,"message":"Invalid slimcoin address"}.

To be more sure I've tried to install pacli on the server, but was not able to use it. I'll open another issue about.

However basing the above outputs I think the server wallet is not the same as the local one.

If this is not possible, just to be sure: what does slimcoind getmininginfo say?

The output on the local wallet is:

 {
    "blocks" : 428034,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 0.00632980,
    "errors" : "",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "networkghps" : 0.00028617,
    "pooledtx" : 0,
    "testnet" : true
}

Thus for the the moment I'd assume that my local wallet went on receiving rewards generated by the server wallet even after the server wallet was deleted. Another hypothesis that pops up in my mind is that you've been mining with the wallet containing my addresses till yesterday. Which is strange since you'd know you did it. The third assumption I had is that someone who is reading our discussion here has taken the private keys I've published above and had mined a bit, but the private key of the address mwvsHNwNQ8eiRFGHNqnpD7EdoFk5zzAdYH wasn't published. In short just I don't know what to think :-) _

I decided to check transactions, not balances, which is much slower but also more reliable, because if checking balances, if the address was emptied somehow, it could have been "used" even if no balance was shown.

I've tested it. It was not that slow. Would it make sense to make this procedure default?

[d5000]

Another hypothesis that pops up in my mind is that you've been mining with the wallet containing my addresses till yesterday. Which is strange since you'd know you did it.

Maybe you're on something ... I just saw that in the slimcoin.conf I'd used with your wallet I had put gen=1. I had fired it up some days ago when I looked first into this problem.

I saw the block range of recent mining to your addresses is relatively narrow - 1500 to 2052 confirmations. I looked at the timeframe and it was all during the same day (May 06-07). It's possible thus that it was me indeed ...

Perhaps it's a mix of both ... You said that for some of the addresses on the server you didn't get an error, and for some you did. So maybe the server is still running with the old wallet but some of the addresses were generated newly.

You can simply know with the dumpprivkey command on the server which addresses are known by the server's wallet, this is the most reliable method - those which provide you a private key are known, those which not, are not. I would not use the account-related commands as they tend to be unreliable.

If all the recent transactions come from block 425400 to 426500 approximately then it was probably indeed me. I wonder why I didn't notice that as it was for several hours, but it's possible. So I apologize for the confusion :)

I've tested it. It was not that slow. Would it make sense to make this procedure default?

Here it takes at least 1-2 minutes (maybe because I have more addresses/transactions in my wallet). I think that's too slow to make it default.

[buhtignew]

You can simply know with the dumpprivkey command on the server which addresses are known by the server's wallet, this is the most reliable method

Of course, how could I've forgotten about dumpprivkey command? I've checked all the addresses - none of them is known by the server's wallet.

If all the recent transactions come from block 425400 to 426500 approximately then it was probably indeed me.

Then the issue is solved. The most recent block mined by "my" wallet were 426088, 426088 and 426068. Which can be explained by the fact you've been mining with my wallet.dat since the blocks are in the range you've mentioned.

The other addresses were mining earlier and it can be explained by me having started mining on my local machine to push the blockchain forward.

Here it takes at least 1-2 minutes (maybe because I have more addresses/transactions in my wallet). I think that's too slow to make it default.

If so it wouldn't make sense to make it default, of course.

I think we can close this issue now.