v0.11.0.x Core Testing

Status
Not open for further replies.

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Yeah, it's not officially released yet. I think everyone got confused because there's someone running a few masternodes on v11.
Thanks, Evan. Could you also please look at the unresolved issues created on JIRA?

Thank you.
 

Sub-Ether

Well-known Member
Mar 31, 2014
1,516
1,254
183
Been doing some benchmarks, wallet took 17 mins to update 24 weeks (seemed to get stuck a little on block 89311 but carried on).
The mixing of 1000 test coins did 19% in 41 minutes,
and now upto 330 darksend tdrk have been mixed in 2 hours and 32 minutes (so 1 third complete)
I make that 2.2 tdrk per minute so far, or 3126 tdrk per day.

Additional:
881 mixed tdrk in 4 hrs 20 mins, so has speeded up to 3.4 tdrk per minute and 4879 tdrk per day is projected..
 
Last edited by a moderator:

qwizzie

Well-known Member
Aug 6, 2014
1,602
754
183
the people using v11 on mainnet for testing purposes, will they be doing two pairing mixing with current version (security risk) or does
it automatically switch to three pairing if the wallet is being used on mainnet ?
 

camosoul

Grizzled Member
Sep 19, 2014
2,263
1,130
1,183
As far as I could see, mn payments does not work on v11... There was not a single mn payment on testnet since v11 started.
I've gotten plenty of payments with 0.11.0.4 on mainnet... See, it's good that somebody tests this stuff...

<3 drk.mn



There's even a 0.11.0.3 out there...
 
Last edited by a moderator:

elbereth

Active Member
Dash Support Group
Mar 25, 2014
447
469
133
Costa Rica
dashninja.pl
Dash Address
XkfkHqMnhvQovo7kXQjvnNiFnQhRNZYCsz
Well payments are not done with a masternode so you test nothing on that front... Try finding a block with a 0.11.0.4 + masternode payment and then your test will be meaningful.
 
  • Like
Reactions: moli

camosoul

Grizzled Member
Sep 19, 2014
2,263
1,130
1,183
Well payments are not done with a masternode so you test nothing on that front... Try finding a block with a 0.11.0.4 + masternode payment and then your test will be meaningful.
I'm not mining with it, so point taken.

The pair inquiry is also valid.

I'm also no using darksend, so that isn't tested, either...

DRK has so many things going on, it's more than just loading up a client and getting a green light. Things to do, or not do... Things to test, or not test. So fancy and pretty...

The test's use thus far is that it did not explode and lose coins or do anything else wildly unpredictable/bad. Whee! Evan said it works on mainnet. It does. Wonder how he knew that...

All I cared to see was that start-many was finally working. It is. Yay test! I can run nodes now! People who have been holding off on it can run nodes! People who already run nodes and want to enjoy the process of not sucking really bad can now be happy! It is no longer horrible to run many masternodes! Good thing! Happy time! Test good! There might even be people who didn't want to deal with running their own MN who now have the chance since it's like 100 times easier.

You can use a 0.11.0.4 to fire up 0.10.17.24 nodes if you want it that way. I felt like going all out... Dirty test environment is dirty.

Is that really such a bad thing?
 
Last edited by a moderator:

qwizzie

Well-known Member
Aug 6, 2014
1,602
754
183
I seem to have a problem using v11 in combination with IPVanish (a VPN service provider), i can only get v11 to work on Testnet by either
deleting IPVanish or by running IPVanish. If i disconnect IPVanish the UPnP Port Mapping correctly maps my own IP address
but then throws socket receiver error messages at me preventing any peer connections build up.
I dont have any peers connection problems using v.0.10.17.24 (or.25) on Mainnet in combination with IPVanish, i'm a bit worried if v11.0 hits Mainnet i will be having the same peer connection problems.

Debug.log v11.0.4 on Testnet with peer connection problems:

2015-01-11 13:26:14 ERROR: Read : Failed to open file D:\TestDarkcoinData1\testnet3\peers.dat
2015-01-11 13:26:14 Invalid or missing peers.dat; recreating
2015-01-11 13:26:14 Loaded 0 addresses from peers.dat 0ms
2015-01-11 13:26:14 mapBlockIndex.size() = 90338
2015-01-11 13:26:14 chainActive.Tip()->nHeight = 90336
2015-01-11 13:26:14 setKeyPool.size() = 1000
2015-01-11 13:26:14 mapWallet.size() = 5
2015-01-11 13:26:14 mapAddressBook.size() = 1
2015-01-11 13:26:14 AddLocal([2001:0:9d38:6abd:142f:1df1:2685:742b]:19999,1)
2015-01-11 13:26:14 ext-ip thread start
2015-01-11 13:26:14 opencon thread start
2015-01-11 13:26:14 upnp thread start
2015-01-11 13:26:14 net thread start
2015-01-11 13:26:14 addcon thread start
2015-01-11 13:26:14 dnsseed thread start
2015-01-11 13:26:14 init message: Done loading
2015-01-11 13:26:14 msghand thread start
2015-01-11 13:26:14 dumpaddr thread start
2015-01-11 13:26:14 Loading addresses from DNS seeds (could take a while)
2015-01-11 13:26:14 Initialization result: 1
2015-01-11 13:26:15 GetMyExternalIP() received [myownIPaddress] myownIPaddress:0
2015-01-11 13:26:15 GetMyExternalIP() returned myownIPaddress
2015-01-11 13:26:15 AddLocal(myownIPaddress:19999,4)
2015-01-11 13:26:15 ext-ip thread exit
2015-01-11 13:26:16 UPnP: ExternalIPAddress = myownIPaddress
2015-01-11 13:26:16 AddLocal(myownIPaddress:19999,3)
2015-01-11 13:26:19 UPnP Port Mapping successful.
2015-01-11 13:26:21 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:25 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:26 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:26 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:27 5 addresses found from DNS seeds
2015-01-11 13:26:27 dnsseed thread exit
2015-01-11 13:26:28 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:29 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:30 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:31 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:32 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:34 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:34 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:35 socket recv error De externe host heeft een verbinding verbroken. (10054)
2015-01-11 13:26:37 socket recv error De externe host heeft een verbinding verbroken. (10054)

Debug.log of v0.10.17.25 on Mainnet : no problems building up peer connections (8 connections)

2015-01-11 13:51:23 No coin database inconsistencies in last 289 blocks (1704 transactions)
2015-01-11 13:51:23 block index 21500ms
2015-01-11 13:51:24 nFileVersion = 101724
2015-01-11 13:51:24 wallet 313ms
2015-01-11 13:51:24 nInstantXDepth 1
2015-01-11 13:51:24 Darksend rounds 4
2015-01-11 13:51:24 Anonymize Darkcoin Amount 10
2015-01-11 13:51:24 Loaded 10911 addresses from peers.dat 62ms
2015-01-11 13:51:24 RandAddSeed() 239668 bytes
2015-01-11 13:51:24 mapBlockIndex.size() = 196641
2015-01-11 13:51:24 nBestHeight = 196616
2015-01-11 13:51:24 setKeyPool.size() = 1000
2015-01-11 13:51:24 mapWallet.size() = 72
2015-01-11 13:51:24 mapAddressBook.size() = 4
2015-01-11 13:51:24 AddLocal([2001:0:9d38:6abd:142f:1df1:2685:742b]:9999,1)
2015-01-11 13:51:24 dnsseed thread start
2015-01-11 13:51:24 upnp thread start
2015-01-11 13:51:24 net thread start
2015-01-11 13:51:24 addcon thread start
2015-01-11 13:51:24 Loading addresses from DNS seeds (could take a while)
2015-01-11 13:51:24 opencon thread start
2015-01-11 13:51:24 msghand thread start
2015-01-11 13:51:24 dumpaddr thread start
2015-01-11 13:51:24 refreshWallet
2015-01-11 13:51:24 trying connection 82.211.21.16:9999 lastseen=9.0days
2015-01-11 13:51:24 connected 82.211.21.16:9999
2015-01-11 13:51:24 send version message: version 70051, blocks=196616, us=[2001:0:9d38:6abd:142f:1df1:2685:742b]:9999, them=82.211.21.16:9999, peer=1
2015-01-11 13:51:25 Added time data, samples 2, offset -31 (+0 minutes)
2015-01-11 13:51:25 Moving 82.211.21.16:9999 to tried
2015-01-11 13:51:25 receive version message: /Satoshi:0.10.17.25/: version 70051, blocks=201364, us=217.122.139.212:49653, them=82.211.21.16:9999, peer=1
2015-01-11 13:51:25 Added 1 addresses from 5.45.101.232: 182 tried, 10730 new
2015-01-11 13:51:25 27 addresses found from DNS seeds
2015-01-11 13:51:25 dnsseed thread exit
2015-01-11 13:51:25 send initial getblocks peer=1
2015-01-11 13:51:25 ProcessSyncCheckpoint: pending for sync-checkpoint 000000000006223c3f5fd21030586f6cfac2779306429c908afee9b8d7cdea66
2015-01-11 13:51:26 SetBestChain: new best=000000000010fd370fd869484bea5bb18a289c0bc840095294ba9129306ece5d height=196635 log2_work=60.756438 tx=767665 date=2015-01-02 22:57:58 progress=0.990860
2015-01-11 13:51:26 received block 000000000017d143bea3c921feab15722541d1720255b72c68ae46a0ee248bf6 peer=1
2015-01-11 13:51:26 UPnP: ExternalIPAddress = MyownIPaddress
2015-01-11 13:51:26 AddLocal(MyownIPAddress:9999,3)
2015-01-11 13:51:28 UPnP Port Mapping successful.
2015-01-11 13:51:29 connection timeout
2015-01-11 13:51:29 ERROR: GetMyExternalIP() : connection to 91.198.22.70:80 failed
2015-01-11 13:51:34 connection timeout
2015-01-11 13:51:34 ERROR: GetMyExternalIP() : connection to 74.208.43.192:80 failed
2015-01-11 13:51:33 received block 00000000001263dc4989842b4c82699cc7df584aef66df24dd31c97a98d9722a peer=2
 
Last edited by a moderator:

vertoe

Three of Nine
Mar 28, 2014
2,573
1,652
1,283
Unimatrix Zero One
I seem to have a problem using v11 in combination with IPVanish (a VPN service provider), i can only get v11 to work on Testnet by either
deleting IPVanish or by running IPVanish. If i disconnect IPVanish the UPnP Port Mapping correctly maps my own IP address
but then throws socket receiver error messages at me preventing any peer connections build up.
I dont have any peers connection problems using v.0.10.17.24 (or.25) on Mainnet in combination with IPVanish, i'm a bit worried if v11.0 hits Mainnet i will be having the same peer connection problems.

Debug.log v11.0.4 on Testnet with peer connection problems:
*snip

Debug.log of v0.10.17.25 on Mainnet : no problems building up peer connections (8 connections)
*snip
did you try to manually add nodes? just asking, the log entry looks like your vpn us cutting the connection. does it work with v10 on testnet? could you check that?
 

qwizzie

Well-known Member
Aug 6, 2014
1,602
754
183
did you try to manually add nodes? just asking, the log entry looks like your vpn us cutting the connection. does it work with v10 on testnet? could you check that?
i tried adding nodes, tried putting exclusions in my firewall for the v11 test directories (firewall controlled by ESET Smart Security btw). i tried v10 on Testnet, exact same problems.
The problems disappear right after i start IPVanish again, so IPVanish seems to be blocking my Testnet peer connections somehow when its disconnected. Very weird.
I dont even need to close v11 or v10 on Testnet .. i can just keep the client open, start up IPVanish and it starts building peer connections again. And it doesnt behave like this on Mainnet.. very weird.

edit 1: i might i have the excusions in my firewall incorrect (was actually adding exclusion for antivirus .. not the firewall) .. making some changes to see if thats it.

edit 2: yep .. thats it allright. makes perfect sense now, IPVanish overrules Eset's firewall so thats why it could build peer connections when it got activated. I will need to make firewall exclusions for every single test darkcoin-qt.exe
 
Last edited by a moderator:

vertoe

Three of Nine
Mar 28, 2014
2,573
1,652
1,283
Unimatrix Zero One
i tried adding nodes, tried putting exclusions in my firewall for the v11 test directories (firewall controlled by ESET Smart Security btw). i tried v10 on Testnet, exact same problems.
The problems disappear right after i start IPVanish again, so IPVanish seems to be blocking my Testnet peer connections somehow when its disconnected. Very weird.
I dont even need to close v11 or v10 on Testnet .. i can just keep the client open, start up IPVanish and it starts building peer connections again. And it doesnt behave like this on Mainnet.. very weird.

edit 1: i might i have the excusions in my firewall incorrect (was actually adding exclusion for antivirus .. not the firewall) .. making some changes to see if thats it.

edit 2: yep .. thats it allright. makes perfect sense now, IPVanish overrules Eset's firewall so thats why it could build peer connections when it got activated. I will need to make firewall exclusions for every single test darkcoin-qt.exe
Testnet is using different ports (19999) than mainnet (9999) that's why maybe.
 

camosoul

Grizzled Member
Sep 19, 2014
2,263
1,130
1,183
the people using v11 on mainnet ... will they be doing two pairing mixing with current version
Excerpt from debug.log of 0.11.0.4 on mainnet:
Code:
2015-01-12 01:02:18 IS DARKSEND MASTER NODE
2015-01-12 01:02:18 InstantXDepth 1
2015-01-12 01:02:18 Darksend rounds 2
2015-01-12 01:02:18 Anonymize Darkcoin Amount 2
Is that saying what it appears to be saying?

Could probably change the 2 to a 3 and recompile...

But, I have a hunch there is going to be a few bumps in the version number quite shortly...

Other aspects of the mixing procedure/depth assure that this doesn't really matter at a whole 1.2% of the network...

Not a security risk. Proves that such a change by a malicious node is lost in the wash and has no measure-able impact. May as well try to publish your own blockchain where you win every block mined... Same general (non)effect.
 

vertoe

Three of Nine
Mar 28, 2014
2,573
1,652
1,283
Unimatrix Zero One
i just merged bitcoin-0.9.4 into darkcoin-0.11

this includes mainly openssl security fixes as discussed here:
OpenSSL Compatibility with Client

full change log:

Validation:
- consensus: guard against openssl's new strict DER checks
- fail immediately on an empty signature
- Improve robustness of DER recoding code

Command-line options:
- Make -proxy set all network types, avoiding a connect leak.

P2P:
- Limit the number of new addressses to accumulate

RPC:
- Disable SSLv3 (in favor of TLS) for the RPC client and server.

Build system:
- gitian: openssl-1.0.1i.tar.gz -> openssl-1.0.1k.tar.gz
- build: Fix OSX build when using Homebrew and qt5
- Keep symlinks when copying into .app bundle
- osx: fix signing to make Gatekeeper happy (again)

Miscellaneous:
- Refactor -alertnotify code
- doc: Add instructions for consistent Mac OS X build names
https://github.com/darkcoin/darkcoin/pull/106

waiting for for eduffield and flare to pull the triggers (in that order ;-)
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Aswan, oblox, anyone, can you trace this tx back to its origin address:

731fe63009611a07cfaae4b88d0c8608eac74217fc0c38eceb1272f9c7c6484c

The tx went through 8/9 rounds. The origin address has ending "...sXNx".

Thanks. :)
 

Aswan

Member
Jun 26, 2014
68
216
73
Aswan, oblox, anyone, can you trace this tx back to its origin address:

731fe63009611a07cfaae4b88d0c8608eac74217fc0c38eceb1272f9c7c6484c

The tx went through 8/9 rounds. The origin address has ending "...sXNx".

Thanks. :)

With the testnet explorer it's a real pain manually tracking transactions :)

I had some success tracking it, but didn't chase too far because of the testnet explorer not making it any easier. With the chainz.cryptoid.info explorer it used to be much easier, but they don't have one for testnet.

Lets call 731fe63009611a07cfaae4b88d0c8608eac74217fc0c38eceb1272f9c7c6484c Tx 0).

The Txs that lead to your Tx:
1) 7cb9b81c5befd95f38ea11e21157aeaafcfe9c5981da8c5ff41d071ea28881e0 - sends 400.00000004 DRK to 0)
2) 41ca6cde66e4ae880a43ffee3eb76f5c50e623f1b9c0d285ba90102f41486daa - sends 90.00000009 DRK to 0)
3) 0299644af5ae2c275043a1d351e0187197fe315e1c7fffb2420a409649e1accf - sends 0.10000001 DRK to 0)
4) 9fd30dd2cb0a52fe0834a0c8c93a416237d1f05c5e0b7ad5dc4dd053bd3f6235 - sends 500.00000005 DRK to 0)
5) 9a559dcb54fb7196b2246951fddf7c7c0072add05f50475ff2f7a57aba97a61b - sends 100.00000001 DRK to 0)

From there, I found

6) 10e98361fa86832c03153ba5a672188dc4b62a5e5ebb92b7d0caa5ba3c27cf1d - This transaction sends 778.0712995 DRK to y3r2VcndLy14d6KQEm3ac5u21imVjHN9CW, which is then used in 2) to pay for 0). I know this because the other inputs of 2) are not big enough, leaving only the 778.0712995 DRK output as the funds in question. Also, 2) has an output of 668.07129939 DRK, which is, when substracted from 778.0712995, 110,00000011DRK or 11x 10.00000001. This adds extra evidence those 2 are related.
What is interesting is, 6) not only leads to 2, but also to 4) and 5).

Goind further, these 778.0712995 DRK can be traced to 7) 20f3fda7cb19602cf581fc7c2464a34c5372c94ac88e635d9e82c35898520ce7 - In a similar fashion we have no other input that is big enough to be corelated with our output that has already been tied to Molis Tx. It's an input of 883.00000019 DRK in 6), coming from 7).

Interestingly enough, 6) only has a total input of 936.64272834 DRK. However, it also sends 70 DRK to 4), which is more than the leftover if we substract the big input from the total input. This meant, that the 883.00000019DRK is not only related to 2), but also to 4), adding additional evidence that we are on the right path.
6) also sends 40 DRK to 5), but this is not enough to exceed the leftover, so we cannot be certain that it's directly coming from the 883.00000019 DRK.

Looking at the inputs of 7), we can see a total input of 1023.0000015 DRK. Looking for a big input that can be tied to our big output of 883.00000019 DRK does not work this time since the biggest single input is 100.00000001 DRK. However, there is a more than the leftover (which is 139.99999996 DRK) total input from a single Tx, which means that we can be 100% sure that at least some of our funds come from this Tx. Inspecting the Tx, we can see 810.00000018 DRK coming from that Tx, leaving the difference of 73.00000001 DRK we can look for in the other transactions (because of the 1 duff at the end of this amount and the fact that this is not enough to properly DS-Denominate this amount, I think it is highly likely that at least one of the non DS-denominated inputs is related to the 73.00000001 DRK. However, since we already identified where most of the DRK came from, we will persue them first and maybe come back later).

This leads us to 8) - c9274a038b2253633bbf0b4c8f932a1838b8f4e352a9a5899034e0dcc95e883a - The Tx that send 810.00000018 DRK to 7).

This is where it gets interesting since the only non-DS-denomination outputs we have are 2x 80.0000008 DRK. This is interesting and means that we can probably count out 16 x 10.00000001 from the input list as not related to out funds (since we didn't have any 80.00000008 DRK inputs in 7). This makes life a bit easier, but still not easy since this time we do not have and other non-DS denominations.

From here on, one could look for inputs adding up to 810.00000018 DRK coming from as few Transactions as possible, in the best case scenario (for tracking purposes) this would be a single Tx.
If this does not lead anywhere, one could go back to the 73.00000001 DRK from 7) and keep going or go back to 1) or 3), which we haven't talked about at all.

As I said, its a real pain using the testnet explorer to manually do all this, which is why I am doing to stop here.

I conclude:
Moli said it was an 8 rounds DS Tx.
1), 2), 3), 4) and 5) therefore belong to DS round 8
therefore 6) belongs to DS round 7,
7) belongs to DS round 6
and 8) belongs to DS round 5.

We have been able to track a part of the funds over 3 DS rounds to DS round 5 and have then stopped chasing, while also admitting that with 8), things get a little more difficult.
While not having traced the the funds all the way back to its origin address, we have found out that there are different DS Txs which provide a different level of anonymity. I wish there would be more Txs like 8) and less Txs like 6), which making the linking of the bit input to the big output an easy task.
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
With the testnet explorer it's a real pain manually tracking transactions :)

I had some success tracking it, but didn't chase too far because of the testnet explorer not making it any easier. With the chainz.cryptoid.info explorer it used to be much easier, but they don't have one for testnet.

Lets call 731fe63009611a07cfaae4b88d0c8608eac74217fc0c38eceb1272f9c7c6484c Tx 0).

The Txs that lead to your Tx:
1) 7cb9b81c5befd95f38ea11e21157aeaafcfe9c5981da8c5ff41d071ea28881e0 - sends 400.00000004 DRK to 0)
2) 41ca6cde66e4ae880a43ffee3eb76f5c50e623f1b9c0d285ba90102f41486daa - sends 90.00000009 DRK to 0)
3) 0299644af5ae2c275043a1d351e0187197fe315e1c7fffb2420a409649e1accf - sends 0.10000001 DRK to 0)
4) 9fd30dd2cb0a52fe0834a0c8c93a416237d1f05c5e0b7ad5dc4dd053bd3f6235 - sends 500.00000005 DRK to 0)
5) 9a559dcb54fb7196b2246951fddf7c7c0072add05f50475ff2f7a57aba97a61b - sends 100.00000001 DRK to 0)

From there, I found

6) 10e98361fa86832c03153ba5a672188dc4b62a5e5ebb92b7d0caa5ba3c27cf1d - This transaction sends 778.0712995 DRK to y3r2VcndLy14d6KQEm3ac5u21imVjHN9CW, which is then used in 2) to pay for 0). I know this because the other inputs of 2) are not big enough, leaving only the 778.0712995 DRK output as the funds in question. Also, 2) has an output of 668.07129939 DRK, which is, when substracted from 778.0712995, 110,00000011DRK or 11x 10.00000001. This adds extra evidence those 2 are related.
What is interesting is, 6) not only leads to 2, but also to 4) and 5).

Goind further, these 778.0712995 DRK can be traced to 7) 20f3fda7cb19602cf581fc7c2464a34c5372c94ac88e635d9e82c35898520ce7 - In a similar fashion we have no other input that is big enough to be corelated with our output that has already been tied to Molis Tx. It's an input of 883.00000019 DRK in 6), coming from 7).

Interestingly enough, 6) only has a total input of 936.64272834 DRK. However, it also sends 70 DRK to 4), which is more than the leftover if we substract the big input from the total input. This meant, that the 883.00000019DRK is not only related to 2), but also to 4), adding additional evidence that we are on the right path.
6) also sends 40 DRK to 5), but this is not enough to exceed the leftover, so we cannot be certain that it's directly coming from the 883.00000019 DRK.

Looking at the inputs of 7), we can see a total input of 1023.0000015 DRK. Looking for a big input that can be tied to our big output of 883.00000019 DRK does not work this time since the biggest single input is 100.00000001 DRK. However, there is a more than the leftover (which is 139.99999996 DRK) total input from a single Tx, which means that we can be 100% sure that at least some of our funds come from this Tx. Inspecting the Tx, we can see 810.00000018 DRK coming from that Tx, leaving the difference of 73.00000001 DRK we can look for in the other transactions (because of the 1 duff at the end of this amount and the fact that this is not enough to properly DS-Denominate this amount, I think it is highly likely that at least one of the non DS-denominated inputs is related to the 73.00000001 DRK. However, since we already identified where most of the DRK came from, we will persue them first and maybe come back later).

This leads us to 8) - c9274a038b2253633bbf0b4c8f932a1838b8f4e352a9a5899034e0dcc95e883a - The Tx that send 810.00000018 DRK to 7).

This is where it gets interesting since the only non-DS-denomination outputs we have are 2x 80.0000008 DRK. This is interesting and means that we can probably count out 16 x 10.00000001 from the input list as not related to out funds (since we didn't have any 80.00000008 DRK inputs in 7). This makes life a bit easier, but still not easy since this time we do not have and other non-DS denominations.

From here on, one could look for inputs adding up to 810.00000018 DRK coming from as few Transactions as possible, in the best case scenario (for tracking purposes) this would be a single Tx.
If this does not lead anywhere, one could go back to the 73.00000001 DRK from 7) and keep going or go back to 1) or 3), which we haven't talked about at all.

As I said, its a real pain using the testnet explorer to manually do all this, which is why I am doing to stop here.

I conclude:
Moli said it was an 8 rounds DS Tx.
1), 2), 3), 4) and 5) therefore belong to DS round 8
therefore 6) belongs to DS round 7,
7) belongs to DS round 6
and 8) belongs to DS round 5.

We have been able to track a part of the funds over 3 DS rounds to DS round 5 and have then stopped chasing, while also admitting that with 8), things get a little more difficult.
While not having traced the the funds all the way back to its origin address, we have found out that there are different DS Txs which provide a different level of anonymity. I wish there would be more Txs like 8) and less Txs like 6), which making the linking of the bit input to the big output an easy task.
Interesting...
The reason for that behavior of combining smaller denominations during mixing is because of these lines I believe:
https://github.com/darkcoin/darkcoin/blob/v0.11.0.x/src/wallet.cpp#L2167-L2171
This should be done in some other way.
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
With the testnet explorer it's a real pain manually tracking transactions :)

I had some success tracking it, but didn't chase too far because of the testnet explorer not making it any easier. With the chainz.cryptoid.info explorer it used to be much easier, but they don't have one for testnet.

Lets call 731fe63009611a07cfaae4b88d0c8608eac74217fc0c38eceb1272f9c7c6484c Tx 0).

The Txs that lead to your Tx:
1) 7cb9b81c5befd95f38ea11e21157aeaafcfe9c5981da8c5ff41d071ea28881e0 - sends 400.00000004 DRK to 0)
2) 41ca6cde66e4ae880a43ffee3eb76f5c50e623f1b9c0d285ba90102f41486daa - sends 90.00000009 DRK to 0)
3) 0299644af5ae2c275043a1d351e0187197fe315e1c7fffb2420a409649e1accf - sends 0.10000001 DRK to 0)
4) 9fd30dd2cb0a52fe0834a0c8c93a416237d1f05c5e0b7ad5dc4dd053bd3f6235 - sends 500.00000005 DRK to 0)
5) 9a559dcb54fb7196b2246951fddf7c7c0072add05f50475ff2f7a57aba97a61b - sends 100.00000001 DRK to 0)

From there, I found

6) 10e98361fa86832c03153ba5a672188dc4b62a5e5ebb92b7d0caa5ba3c27cf1d - This transaction sends 778.0712995 DRK to y3r2VcndLy14d6KQEm3ac5u21imVjHN9CW, which is then used in 2) to pay for 0). I know this because the other inputs of 2) are not big enough, leaving only the 778.0712995 DRK output as the funds in question. Also, 2) has an output of 668.07129939 DRK, which is, when substracted from 778.0712995, 110,00000011DRK or 11x 10.00000001. This adds extra evidence those 2 are related.
What is interesting is, 6) not only leads to 2, but also to 4) and 5).

Goind further, these 778.0712995 DRK can be traced to 7) 20f3fda7cb19602cf581fc7c2464a34c5372c94ac88e635d9e82c35898520ce7 - In a similar fashion we have no other input that is big enough to be corelated with our output that has already been tied to Molis Tx. It's an input of 883.00000019 DRK in 6), coming from 7).

Interestingly enough, 6) only has a total input of 936.64272834 DRK. However, it also sends 70 DRK to 4), which is more than the leftover if we substract the big input from the total input. This meant, that the 883.00000019DRK is not only related to 2), but also to 4), adding additional evidence that we are on the right path.
6) also sends 40 DRK to 5), but this is not enough to exceed the leftover, so we cannot be certain that it's directly coming from the 883.00000019 DRK.

Looking at the inputs of 7), we can see a total input of 1023.0000015 DRK. Looking for a big input that can be tied to our big output of 883.00000019 DRK does not work this time since the biggest single input is 100.00000001 DRK. However, there is a more than the leftover (which is 139.99999996 DRK) total input from a single Tx, which means that we can be 100% sure that at least some of our funds come from this Tx. Inspecting the Tx, we can see 810.00000018 DRK coming from that Tx, leaving the difference of 73.00000001 DRK we can look for in the other transactions (because of the 1 duff at the end of this amount and the fact that this is not enough to properly DS-Denominate this amount, I think it is highly likely that at least one of the non DS-denominated inputs is related to the 73.00000001 DRK. However, since we already identified where most of the DRK came from, we will persue them first and maybe come back later).

This leads us to 8) - c9274a038b2253633bbf0b4c8f932a1838b8f4e352a9a5899034e0dcc95e883a - The Tx that send 810.00000018 DRK to 7).

This is where it gets interesting since the only non-DS-denomination outputs we have are 2x 80.0000008 DRK. This is interesting and means that we can probably count out 16 x 10.00000001 from the input list as not related to out funds (since we didn't have any 80.00000008 DRK inputs in 7). This makes life a bit easier, but still not easy since this time we do not have and other non-DS denominations.

From here on, one could look for inputs adding up to 810.00000018 DRK coming from as few Transactions as possible, in the best case scenario (for tracking purposes) this would be a single Tx.
If this does not lead anywhere, one could go back to the 73.00000001 DRK from 7) and keep going or go back to 1) or 3), which we haven't talked about at all.

As I said, its a real pain using the testnet explorer to manually do all this, which is why I am doing to stop here.

I conclude:
Moli said it was an 8 rounds DS Tx.
1), 2), 3), 4) and 5) therefore belong to DS round 8
therefore 6) belongs to DS round 7,
7) belongs to DS round 6
and 8) belongs to DS round 5.

We have been able to track a part of the funds over 3 DS rounds to DS round 5 and have then stopped chasing, while also admitting that with 8), things get a little more difficult.
While not having traced the the funds all the way back to its origin address, we have found out that there are different DS Txs which provide a different level of anonymity. I wish there would be more Txs like 8) and less Txs like 6), which making the linking of the bit input to the big output an easy task.
Aswan, thank you for this analysis. This is Testnet with just 2 participants at each round, maybe it's even more difficult to trace on Mainnet with 3 participants?

At this point, I would really like to see eduffield let us do more than 8 rounds or even unlimited if someone has the time and money to keep running Darksend and paying fees. :)
 

bituzer

Member
Apr 23, 2014
19
26
78
better try to optimize those 8 rounds first, that seems to be enough work to click through while analyzing
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
At this point, I would really like to see eduffield let us do more than 8 rounds or even unlimited if someone has the time and money to keep running Darksend and paying fees. :)
I agree, is someone wants to set DS rounds to 9, or 27, or 99999 then we should let them. It's not like they can't just move everything to a different address and start over, but why make it difficult?
 
  • Like
Reactions: splawik21 and moli

qwizzie

Well-known Member
Aug 6, 2014
1,602
754
183
okay, i confess that made me use google :)

keypass integration as in :

KeePass is a completely open-source password manager that stores all your sensitive data locally ??
Does this mean it will remember yr passphrase locally ?

My googling lead me here btw : http://www.howtogeek.com/165882/how...wser-across-your-computers-and-on-your-phone/

Edit :

Seems to run with commandline options and also seems to construct an url for KeePass entry to store the wallet passphrase if i read Github correctly ?

-keepass : Use KeePass 2 integration using KeePassHttp plugin (default: 0)
-keepassport=<port> Connect to KeePassHttp on port <port> (default: 19455)
-keepasskey=<key> KeePassHttp key for AES encrypted communication with KeePass
-keepassid=<name> KeePassHttp id for the established association
-keepassname=<name> Name to construct url for KeePass entry that stores the wallet passphrase

Would like some more info about this (first time i heard about KeePass as you can see :)

I agree with oblox, you guys are putting out a lot of updates today .. good work.
 
Last edited by a moderator:

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
You guys are crushing it, seriously. Kudos. If it's your goal to make Darkcoin substantially different by its anniversary, you've already succeeded. But by no means slow down or anything. ;)
 

vertoe

Three of Nine
Mar 28, 2014
2,573
1,652
1,283
Unimatrix Zero One
kudos for keypass freynder - he might get back to us with some more detailed information. here are the commit notes:

Implemented KeePass Integration

More info regarding KeePass: http://keepass.info/

KeePass integration will use KeePassHttp (https://github.com/pfn/keepasshttp/) to facilitate communications between the client and KeePass. KeePassHttp is a plugin for KeePass 2.x and provides a secure means of exposing KeePass entries via HTTP for clients to consume.

The implementation is dependent on the following:
- crypter.h for AES encryption helper functions.
- rpcprotocol.h for handling RPC communications. Could only be used partially however due some static values in the code.
- OpenSSL for base64 encoding. regular util.h libraries were not used for base64 encoding/decoding since they do not use secure allocation.
- JSON Spirit for reading / writing RPC communications

The following changes were made:
- Added CLI options in help
- Added RPC commands: keepass <genkey|init|setpassphrase>
- Added keepass.h and keepass.cpp which hold the integration routines
- Modified rpcwallet.cpp to support RPC commands

The following new options are available for darkcoind and darkcoin-qt:
-keepass Use KeePass 2 integration using KeePassHttp plugin (default: 0)
-keepassport=<port> Connect to KeePassHttp on port <port> (default: 19455)
-keepasskey=<key> KeePassHttp key for AES encrypted communication with KeePass
-keepassid=<name> KeePassHttp id for the established association
-keepassname=<name> Name to construct url for KeePass entry that stores the wallet passphrase

The following rpc commands are available:
- keepass genkey: generates a base64 encoded 256 bit AES key that can be used for the communication with KeePassHttp. Only necessary for manual configuration. Use init for automatic configuration.
- keepass init: sets up the association between darkcoind and keepass by generating an AES key and sending an association message to KeePassHttp. This will trigger KeePass to ask for an Id for the association. Returns the association and the base64 encoded string for the AES key.
- keepass setpassphrase <passphrase>: updates the passphrase in KeePassHttp to a new value. This should match the passphrase you intend to use for the wallet. Please note that the standard RPC commands walletpassphrasechange and the wallet encrption from the QT GUI already send the updates to KeePassHttp, so this is only necessary for manual manipulation of the password.

Sample initialization flow from darkcoin-qt console (this needs to be done only once to set up the association):
- Have KeePass running with an open database
- Start darkcoin-qt
- Open console
- type: "keepass init" in darkcoin-qt console
- (keepass pops up and asks for an association id, fill that in). Example: mydrkwallet
- response: Association successful. Id: mydrkwalletdarkcoin - Key: AgQkcs6cI7v9tlSYKjG/+s8wJrGALHl3jLosJpPLzUE=
- Edit darkcoin.conf and fill in these values
keepass=1
keepasskey=AgQkcs6cI7v9tlSYKjG/+s8wJrGALHl3jLosJpPLzUE=
keepassid=mydrkwallet
keepassname=testwallet
- Restart darkcoin-qt

At this point, the association is made. The next action depends on your particular situation:
- current wallet is not yet encrypted. Encrypting the wallet will trigger the integration and stores the password in KeePass (Under the 'KeePassHttp Passwords' group, named after keepassname.
- current wallet is already encrypted: use "keepass setpassphrase <passphrase>" to store the passphrase in KeePass.

At this point, the passphrase is stored in KeePassHttp. When Unlocking the wallet, one can use keepass as the passphrase to trigger retrieval of the password. This works from the RPC commands as well as the GUI.
here is the keypass discussion thread: https://darkcointalk.org/threads/proposal-keepass-integration.3343/
 

kryptofoo

Member
Jul 21, 2014
114
36
78
Germany
kudos for keypass freynder - he might get back to us with some more detailed information. here are the commit notes:



here is the keypass discussion thread: https://darkcointalk.org/threads/proposal-keepass-integration.3343/
Having 3rd party software manage and transmit wallet passwords sure makes me nervous. Not for myself (I would not use this until it is widely tested by a very large community) but for others who may run into trouble if it is buggy or worse.
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
Please Update To v0.11.0.5

-changed max rounds to 16
-Fixed masternode payments issue - Masternode payments have been broken on testnet, this patch fixes them. Enforcement will turn on after the network has updated
-Bitcoin 0.9.4 upstream changes (Vertoe)
-KeePass integration - Can we get a few people to test this please? (Freynder)
-Darksend balance shows sendable amount now.
-Fixed "darksend is disabled" inaccurate message
-Fixed crashing on -reindex and -gen
-Fixed darksend balance update on click
-Fix for random segfaultfrom Masternode::Check
-Unlock coins when using Darksend reset button

--------

CI-builds for v0.11.0.5

Linux
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/v11/darkcoin-0.11.0.5-linux.tar.gz

Windows & Mac
- Having some issues, will push up binaries later
 

qwizzie

Well-known Member
Aug 6, 2014
1,602
754
183
Having 3rd party software manage and transmit wallet passwords sure makes me nervous. Not for myself (I would not use this until it is widely tested by a very large community) but for others who may run into trouble if it is buggy or worse.
its by default ''off'' so no need to worry, you have to run commandline options to activate it. But its good to have it tested on Testnet.. see if it works as intended.
 
Status
Not open for further replies.