V12.1 Testnet Launch Thread

Status
Not open for further replies.
UdjinM6 said:
Ah, right, you are also missing subtractfeefromamount param
try
Code: 
sendmany "TestDash1" "{\"ySJmSKL7dw4RiSCUSmpKAk1zUpgP5nN2Ln\":0.01,\"yRpRRQoy7FhY3sZVgQpdCPP6Vd31Vpp6qw\":0.02,\"ySQmPqJZ1ju1qV4ckJQhoiUHkTGo3pVm1J\":0.02,\"yTv8Ni2NbAVkwESskx8YxzEUHdnqHz1amX\":0.02,\"yesY4Ka84aVzQ5RGwRwpJQfmfzfDCzZfhX\":0.02}" 6 "Testing" "[]" true
Click to expand...

that worked great .. thanks

Fq9zaz0.jpg
 
Well, I still have the same problem. I got to 24% then transactions stopped confirming and I got a conflicted transaction and my wallet says "found unconfirmed denominated outputs...." again.
 
TanteStefana said:
Well, I still have the same problem. I got to 24% then transactions stopped confirming and I got a conflicted transaction and my wallet says "found unconfirmed denominated outputs...." again.
Click to expand...
"found unconfirmed denominated outputs...." generally shouldn't be a problem for -privatesendmultisession mode, wallet should just use other available outputs.
 
Don't know how to test IS properly, so I made batch file which InstantSend random amount of Dash to another wallet every 20 sec. And it 100% (200+ transactions) fine and had 5 confirmations on receive like this:
Code: 
05.06.2016 20:48:52,74 cebac061daa2009b1aac14a188d80d8eec973b4f4c8c47079b9cb7bb2e25e061
{
  "amount": 2.00000000,
  "confirmations": 5,
  "bcconfirmations": 0,
  "trusted": true,
  "txid": "cebac061daa2009b1aac14a188d80d8eec973b4f4c8c47079b9cb7bb2e25e061",
  "walletconflicts": [
  ],
  "time": 1465148928,
  "timereceived": 1465148928,
  "bip125-replaceable": "no",
  "details": [
    {
      "account": "",
      "address": "yd91uXMnv1GbZx1ogPXtcfC68KWyxKReyF",
      "category": "receive",
      "amount": 2.00000000,
      "label": "",
      "vout": 0
    }
  ],
  "hex": "01000000015523696d4276ce3b7fab514f715d6c0ef25e0b506859ea3040483bd7194b97f1010000006a473044022056aeb4855e92ee7441cfaef727fde5efc30432136616a8ad4f2ecab39b2714a60220686bffa845707244b66afaf389659200a298b1403956eb59487b567b4fbcf2de012102c8d49107010741ea45aca0387b946acb0f02bf30332200969d7d3e5633ff63f1feffffff0200c2eb0b000000001976a914b8812855a7b18378c504701334f9af4a691cac1d88ac0067fb38000000001976a914c9a9205be9d3883ad701ff08fc670e48e5d701f188ac00000000"
}
05.06.2016 20:49:15,18 9fbb21c1a1711f4a2d43c0fb07064fc3e11681218e10481175e579146aaa6aff
{
  "amount": 10.00000000,
  "confirmations": 5,
  "bcconfirmations": 0,
  "trusted": true,
  "txid": "9fbb21c1a1711f4a2d43c0fb07064fc3e11681218e10481175e579146aaa6aff",
  "walletconflicts": [
  ],
  "time": 1465148951,
  "timereceived": 1465148951,
  "bip125-replaceable": "no",
  "details": [
    {
      "account": "",
      "address": "yj8W1iXnz7nBTEvGE4cSgXnJJu8BDse33j",
      "category": "receive",
      "amount": 10.00000000,
      "label": "",
      "vout": 1
    }
  ],
  "hex": "01000000017fe33cf8bfb0e6168a5ecfda1e062fee6381d521d994840b68ce84a13ab01ad1010000006a4730440220018638a0c170fad0ff0fd493f00e9ab96d983858cdb17199557c437dc65dc210022005883c11f3590e42c880161572c4e56a765761a17670e540242275bcfc81449b012102a2f283cde49a56f6fe8f8622f5ba7c1a39410ab9dc4075c48829833f35f9b5cdfeffffff020040420f000000001976a914585f59d75b4f5f9bf6a4763c68c967885da76be188ac00ca9a3b000000001976a914fa38f569eb5bbd83d60bcb72ec470240c72b032188ac00000000"
}
First I tested with PS and IS on, but due to incorrect receive log script not sure about result...
 
UdjinM6 said:
"found unconfirmed denominated outputs...." generally shouldn't be a problem for -privatesendmultisession mode, wallet should just use other available outputs.
Click to expand...

I'm not using -privatesendmultisession. If we're supposed to use that, why isn't it default? I think the wallet should work without special commands. Unless the reason it isn't working is because of a problem only in testnet that doesn't occur in mainnet.
 
TanteStefana said:
I'm not using -privatesendmultisession. If we're supposed to use that, why isn't it default? I think the wallet should work without special commands. Unless the reason it isn't working is because of a problem only in testnet that doesn't occur in mainnet.
Click to expand...
I already answered "why" few times I believe :p - we need to make sure that user understand what he is doing and why this can be dangerous (keypool depletion), best way to secure that would be implementation of HD wallet. And that's basically why I think we shouldn't make it default yet, first should appear in Wallet -> Expert features imo.

Draft version of UI that would warn user is working like that:
Screen Shot 2016-06-06 at 5.50.46.png

(there will be no smile and arrow in final version btw, though... :D)
 
UdjinM6 said:
I already answered "why" few times I believe :p - we need to make sure that user understand what he is doing and why this can be dangerous (keypool depletion), best way to secure that would be implementation of HD wallet. And that's basically why I think we shouldn't make it default yet, first should appear in Wallet -> Expert features imo.

Draft version of UI that would warn user is working like that:
View attachment 2478
(there will be no smile and arrow in final version btw, though... :D)
Click to expand...
I think you should add the smile and arrow...
 
UdjinM6 said:
I already answered "why" few times I believe :p - we need to make sure that user understand what he is doing and why this can be dangerous (keypool depletion), best way to secure that would be implementation of HD wallet. And that's basically why I think we shouldn't make it default yet, first should appear in Wallet -> Expert features imo.

Draft version of UI that would warn user is working like that:
View attachment 2478
(there will be no smile and arrow in final version btw, though... :D)
Click to expand...

I can understand that, but I still think that private send should still work without it, and it doesn't. I'm still stuck at 24%. I can go up 1 % if i restart the wallet zapping txes, but then get completely stuck again within a percent. This isn't slow, this is not working.

I think it should work, even if it's slow. Am I wrong?

If we make private send not an option unless you enable this feature, I can understand. Another thing, the wallet could hold 10,000 coins by default. I have much more in one of my wallets and yet it doesn't seem slow to start or anything. Anyway, if it can't work in "normal" mode, then I think it shouldn't be an option, no?

I say this because otherwise we will get nothing but complaints from users :) and it looks unprofessional and sloppy to put users through such frustration :)
 
Last edited:
Can you explain
UdjinM6 said:
I already answered "why" few times I believe :p - we need to make sure that user understand what he is doing and why this can be dangerous (keypool depletion), best way to secure that would be implementation of HD wallet. And that's basically why I think we shouldn't make it default yet, first should appear in Wallet -> Expert features imo.

Draft version of UI that would warn user is working like that:
View attachment 2478
(there will be no smile and arrow in final version btw, though... :D)
Click to expand...
Can you explain what the keypool is?
 
halso said:
Can you explain

Can you explain what the keypool is?
Click to expand...
To put it simply - keypool is a set of newly generated but yet unused addresses which are available for your even if your wallet is locked so 1) you can request 1000 "new" addresses without unlocking your wallet and 2) when you backup your wallet you already have 1000 change (or whatever you use them for) addresses and can recover them in case something goes wrong. So it also gives you some gap in time when you can feel more or less safe (wallet is making automatic backups on each (re)start by default).
 
Dedicated tMN updated to v0.12.1.0-ee31604. Looking pretty healthy from the tMN side, but I haven't had a chance to test mixing with this version yet.

I notice on the testnet tools post (https://www.dash.org/forum/threads/testnet-tools-resources.1768/) we're directing people to #darkcoin-test for IRC. This should probably be changed to #dashpay (or maybe #dashpay-dev, but it's been just the git bot and I in there for the longest time now). It would also be a good idea to mention it's on Freenode and maybe also provide a link like https://webchat.freenode.net/?channels=#dashpay for convenience. :)
 
GNULinuxGuy said:
Dedicated tMN updated to v0.12.1.0-ee31604. Looking pretty healthy from the tMN side, but I haven't had a chance to test mixing with this version yet.

I notice on the testnet tools post (https://www.dash.org/forum/threads/testnet-tools-resources.1768/) we're directing people to #darkcoin-test for IRC. This should probably be changed to #dashpay (or maybe #dashpay-dev, but it's been just the git bot and I in there for the longest time now). It would also be a good idea to mention it's on Freenode and maybe also provide a link like https://webchat.freenode.net/?channels=#dashpay for convenience. :)
Click to expand...
I think better place is dash_testnet channel on digital cash slack, isn't it?
 
Comodore said:
I think better place is dash_testnet channel on digital cash slack, isn't it?
Click to expand...
I think it's best to avoid encouraging people to rely on a proprietary service given the nature of this project. From what I hear Slack has some decent features, but those features do not provide enough utility for me to justify using it.
 
AjM said:
Cant we make backup during mix process, i mean when new key is added?
Click to expand...

UdjinM6 said:
Not sure about the first one but we could probably save keymap size on start in some tmp variable, show (sizeOnStart + keypoolSize - currentSize) and warn if it's very low (like 10%) or even stop mixing completely... smth like the way notebooks behave when they run out of battery... hmm...
Click to expand...

This gave me an idea...

While it's possible for us nerds to mount a different block device, say, sshfs to be crude, to ~/.dash/backups/

Wouldn't it be nice to add on to that idea a little bit?

What if the client used a password or gpg key to transparently pass the backups through before it ever touches spinning rust? Kind of like the client's own loopback, the way transparent drive encryption is handled by the kernel... Maybe I just don't trust Trezor and would like to autobackup to a cloud and have nothing but ascii armor hit the disk, ever?

Instead of making a backup on startup/shutdown, make a schedule, and allow the client to stay active during the process. And to augment, or disable, the over-writing of old backups. Since the client knows itself so well, the creation of a new backup can be tied to the key creation rate... Pump the wallet.dat through the gpg onto remote storage every X keys... Maybe add a bit of 7z magic to it, too? Hell, If I can understand it and do something similar with "|" and ">" on cli, surely it's not a terribly difficult feature add? No, don't tell me about deterministic seeds. That's the opposite of the level of security I'm going for... It helps morons at the cost of security.

A more grown-up way to manage backups built right in, instead of having to get your nerd on to do it.

This probably belongs in a different thread, but it's where I found the breadcrumbs.
 
Last edited:
Latest builds (git-4d4a9df) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-561/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-508/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-517/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-513/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/866: [UI] Column alignement of Transaction-Tab adjusted
Merge https://github.com/dashpay/dash/pull/867: Implement an option to enable/disable advanced PrivateSend UI
Merge https://github.com/dashpay/dash/pull/868: checkbox image for wallet themes

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/
 
flare said:
Latest builds (git-4d4a9df) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-561/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-508/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-517/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-513/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/866: [UI] Column alignement of Transaction-Tab adjusted
Merge https://github.com/dashpay/dash/pull/867: Implement an option to enable/disable advanced PrivateSend UI
Merge https://github.com/dashpay/dash/pull/868: checkbox image for wallet themes

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/
Click to expand...
Sweet. Update when I get home.
 
@flare @UdjinM6

Nice to see the keypool count happening ;) Finally I get to have an idea of mine implemented hehe - I feel so proud

So again I pose this idea. Just like on wallet creation/password setting, where the wallet is forced to restart to accept changes, can't we have that same behaviour when one presses "Start Mixing"? The wallet could restart and refill itself with an absurd amount of keys. A pop-up warning about backups could show up, saying it's a one time thing and probably going to take a few minutes, and a new backup will be required. That way we could have multisession by default?

Crypto's are by default the responsibility of the user to do it right. This is not a toy, its real money. I once destroyed many darks because I almost forgot that there is no change address for paper wallets, and that is not the paper-wallet creator's fault. Many folk forget passwords. Crypto's are about giving power and thus responsibility to the end user. It's with Evo that we're changing this paradigm.

I much prefer to see on big warning sign pop-up explaining what is going to happen and make multisession default, than to keep PS crawling and stagnating because a legacy keypool size is a mere 1000.

.
 
  • Like
Reactions: AjM
yidakee said:
@flare @UdjinM6

Nice to see the keypool count happening ;) Finally I get to have an idea of mine implemented hehe - I feel so proud

So again I pose this idea. Just like on wallet creation/password setting, where the wallet is forced to restart to accept changes, can't we have that same behaviour when one presses "Start Mixing"? The wallet could restart and refill itself with an absurd amount of keys. A pop-up warning about backups could show up, saying it's a one time thing and probably going to take a few minutes, and a new backup will be required. That way we could have multisession by default?

Crypto's are by default the responsibility of the user to do it right. This is not a toy, its real money. I once destroyed many darks because I almost forgot that there is no change address for paper wallets, and that is not the paper-wallet creator's fault. Many folk forget passwords. Crypto's are about giving power and thus responsibility to the end user. It's with Evo that we're changing this paradigm.

I much prefer to see on big warning sign pop-up explaining what is going to happen and make multisession default, than to keep PS crawling and stagnating because a legacy keypool size is a mere 1000.

.
Click to expand...
Well, probably... My main concern about 10000 keys is that it gives kind of false feeling of safety imo. If file gets corrupted in a bad and unpredictable way due to some combination of disk and power failure then much more funds could be potentially lost there without a proper backup. I would prefer to have 1000 keys (which is already 10 times more than Bitcoin Core wallet has by default btw) and to actually force general user to backup more often. At least by restarting his wallet time to time (I would avoid messing up with wallet.dat file while wallet is running for now). Power user can refill keypool with whatever amount of keys he wants via keypoolrefill but he would need to explicitly do this via RPC so at least we can assume that he is more or less aware of such action consequences.
 
Status
Not open for further replies.
Back
Top