• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.11.0 - Darkcoin Core Release

Ah, I just read your post about convertibility (missed it somehow). However, I did implement a fix to the issue you describe in 11.0.10, as it was a known issue. The solution is that if you submit 1DRK x 10, you'll get back 1DRK x 10 back with no change. Beyond that, I've added a lot of random noise so each of those outputs will be used randomly (not all at once) to improve anonymity.

Random is the key word here I think. Client side randomness when choosing which outputs to use for the current Tx will greatly improve anonymity.
I will test this asap.
Anyway, I like your idea. I might throw that together before InstantX while I'm in DS mode.

Thanks. denomination convertibility would be a huge benefit not only for the current implementation, but also for compatibility and scalability.
I am looking forward to this.


Edit:
^
The denomination amounts are reserved though, which is why they have the extra satoshi added to them. What about this:

0.1DRK+1
1.0DRK+10
10.0DRK+100
100.0DRK+1000

Each could be converted still, without having to use such common values.

This is exactly what UdjinM6 suggested and I think its a good solution that would be even better if it would just be 100, 10, 1 without any additions due to easier compatibility between systems using different smallest denomination amounts (because they otherwise wouldn't be compatible).

I don't actually see a reason for DS denominations to be distinguishable from normal payment amounts except for the client to know which funds to use as inputs. This, however, can be separately kept track of by the client.
 
Last edited by a moderator:
On the website (www.darkcoin.io) the image left of the text "Darkcoin Core (11.0.10) Release Now Available" links to the very first Onyx release instead of this topic..

KalsCq5.jpg


Other then that, updating! :D
Thanks, updated now.
 
Hey, well out of my league here but why not leave space for a future lower denomination by making it now:
This is exactly what UdjinM6 suggested and I think its a good solution that would be even better if it would just be 100, 10, 1 without any additions due to easier compatibility between systems using different smallest denomination amounts (because they otherwise wouldn't be compatible).

Hey, well out of my league here but why not leave space for a future lower denomination by making it now:

100.00010000 DRK
10.00001000 DRK
1.00000100 DRK
0.10000010 DRK

So that in the future you can add without much trouble:

0.01000001 DRK

Hah, apparently I missed a whole page of comments. Looks like we're on the right track though. I also like Minotaur's suggestion also, maybe we should even go further?

100.00100000 DRK
10.00010000 DRK
1.00001000 DRK
0.10000100 DRK
0.01000010 DRK (disabled presently)
0.00100001 DRK (disabled presently)
 
I don't actually see a reason for DS denominations to be distinguishable from normal payment amounts except for the client to know which funds to use as inputs. This, however, can be separately kept track of by the client.

Yea this is something I've been wondering as well. If you're depending on the 1 duff to know whether it's a denomination input or not, can't someone send 1.00000001 to an address you've given to him and see your other inputs when you're mixing?
 
Darksend users please update and remix your coins to try this and improve your anonymity

-
Found the collateral issue that's been causing users to get charged when they shouldn't be. Now collateral should be charged in about 1 in 40 sessions.

It might just be a string of bad luck but I updated to 0.10 and had three "Payment to yourself" fees in a row. All but 0.1 of my current Darksend Balance was from running it on 0.09.

I might transfer my wallet to cold storage and back before re-mixing it. Maybe that will fix the issue?

zb9jEbZ.png

4SE9D2e.png
 
See, it's discussions like this that reaffirms my decision to park my money here.

Uber-smart contributors, a responsive "door is always open" dev team, and a confident community.

When word of what we have created here becomes widespread, there may not be enough room in the Dark for the stampede!

/gushing
 
Yea this is something I've been wondering as well. If you're depending on the 1 duff to know whether it's a denomination input or not, can't someone send 1.00000001 to an address you've given to him and see your other inputs when you're mixing?

By this logic, if you eliminate the extra satoshis, can't someone send 1.00000000 to an address you've given to him and see your other inputs when you're mixing? I am honestly asking what would be the difference.
 
If this the case, might as well lose the duff and allow 100s to be broken into ten 10s or hundred 1s, whatever needs to be done to make pairs.
 
Try re-syncing from scratch and see if it goes away?

The wallet still has a terrible performance problem with large address counts (200) and transactions (7500)
I started a fresh blockchain pull three and a half hours ago and it's only gotten to "18 weeks behind" and is becoming unresponsive.
I stopped the wallet, restarted with --litemode but it's still very unresponsive while downloading the blockchain.
(am getting windows: "Not responding" errors now)

Probably related '-reindex' shows the same lock-up behavior.

note: this is an ssd system, so it's probably not disk-bound and is only using 13% cpu.
 
The wallet still has a terrible performance problem with large address counts (200) and transactions (7500)
I started a fresh blockchain pull three and a half hours ago and it's only gotten to "18 weeks behind" and is becoming unresponsive.
I stopped the wallet, restarted with --litemode but it's still very unresponsive while downloading the blockchain.
(am getting windows: "Not responding" errors now)

Probably related '-reindex' shows the same lock-up behavior.

note: this is an ssd system, so it's probably not disk-bound and is only using 13% cpu.
I didn't have any problem with qt on win7. Just tested and downloaded new blockchain in about 20 mins.
I think this amount of tx only deamons can handle
 
64bit or 32 bit windows wallet ? 32bit windows wallet doesnt seem to have sluggishness.. so far i can tell

edit : never mind .. during sync my 32 bit now also shows sluggishness .. specially when it has problems syncing
Almost same performance on windows 32 bit and 64 bit here.
I didn't have any problem with qt on win7. Just tested and downloaded new blockchain in about 20 mins.
I think this amount of tx only deamons can handle
Fastest update I've had so far, on a similar setup, it just keeps getting quicker.
 
I have one MN that seems to be spamming the debug file with this:

debug.log said:
2015-01-21 00:03:54 dseep - Asking source node for missing entry CTxIn(COutPoint(d75f43dcc7daba9f1128f9852eccde806998d017e88c0595e8ad34c5e0279616, 0), scriptSig=)
2015-01-21 00:03:58 dseep - Asking source node for missing entry CTxIn(COutPoint(30d0acc1d777398585b50da2feef25ea82698821ad64916be4d22470c6e7c8d2, 0), scriptSig=)
2015-01-21 00:04:04 dseep - Asking source node for missing entry CTxIn(COutPoint(80cc238a25d390d5e46b83d6a74bcbc7de995730e028c07dd78db828bc718ccf, 0), scriptSig=)
2015-01-21 00:04:07 dseep - Asking source node for missing entry CTxIn(COutPoint(0b3abc895a05b0a6d88f84e447919e23d019179cee019f234ce3985658e93495, 0), scriptSig=)
2015-01-21 00:04:11 dseep - Asking source node for missing entry CTxIn(COutPoint(ff07d14cfc5cfbe7e499f37f88a8f39e8a248c11eedfca5897965deaeb458a8d, 0), scriptSig=)
2015-01-21 00:04:12 dseep - Asking source node for missing entry CTxIn(COutPoint(fa4cb6bfced9ed479a18024b2df718b236115c0fa1b71e2728d1fbc28cc0d28e, 0), scriptSig=)
2015-01-21 00:04:13 dseep - Asking source node for missing entry CTxIn(COutPoint(54a057c8592c2d0e31e96007526a2e64d3120df912e948694caa4076769f36e1, 0), scriptSig=)

Any reason for this?
 
Latest client with new wallet, no coins. I tried to upload the network traffic window, what are valid file types? Darksend states 24% complete, and the START button has not been selected (no coins). Windows 7 64-bit, Intel I5-2450m, 8 Gb ram. Darkcoin 64-bit client.

The block update was screaming right along (500-600 mbps) until:
2015-01-21 00:28:12 UpdateTip: new best=00000000000fa333ae8e334c16fa2dec39d0791416394499bc46a67d795d63a3 height=40318 log2_work=54.468082 tx=167094 date=2014-03-26 14:05:56 progress=0.019066
2015-01-21 00:28:12 UpdateTip: new best=00000000004b4fabb2142285967fb89d9333d6ad3ff350a6b9474f7b249869ba height=40319 log2_work=54.468199 tx=167097 date=2014-03-26 14:08:24 progress=0.019067
2015-01-21 00:28:12 UpdateTip: new best=00000000004968411421494c3eb26f5fcf5e376d4b63907b13d0f303fac9cafe height=40320 log2_work=54.468316 tx=167098 date=2014-03-26 14:09:34 progress=0.019067
2015-01-21 00:28:12 nInstantXDepth 1
2015-01-21 00:28:12 Darksend rounds 2
2015-01-21 00:28:12 Anonymize Darkcoin Amount 10
2015-01-21 00:28:12 init message: Loading addresses...
2015-01-21 00:28:12 Loaded 6051 addresses from peers.dat 14ms
2015-01-21 00:28:12 mapBlockIndex.size() = 40321
2015-01-21 00:28:12 chainActive.Tip()->nHeight = 40320
2015-01-21 00:28:12 setKeyPool.size() = 1000
2015-01-21 00:28:12 mapWallet.size() = 0
2015-01-21 00:28:12 mapAddressBook.size() = 1
2015-01-21 00:28:12 AddLocal([2601:c:180:c6a:5dd3:7f8f:8b37:5562]:9999,1)
2015-01-21 00:28:12 AddLocal([2601:c:180:c6a:dd18:c62f:4e6d:d163]:9999,1)
2015-01-21 00:28:12 AddLocal([2001:0:9d38:6ab8:c5f:366d:b63d:532f]:9999,1)
2015-01-21 00:28:12 ext-ip thread start
2015-01-21 00:28:12 dnsseed thread start
2015-01-21 00:28:12 upnp thread start
2015-01-21 00:28:12 net thread start
2015-01-21 00:28:12 init message: Done loading
2015-01-21 00:28:12 addcon thread start
2015-01-21 00:28:12 dumpaddr thread start
2015-01-21 00:28:12 opencon thread start
2015-01-21 00:28:12 msghand thread start
2015-01-21 00:28:12 Initialization result: 1
2015-01-21 00:28:13 GetMyExternalIP() received [73.194.172.208] 73.194.172.208:0
2015-01-21 00:28:13 GetMyExternalIP() returned 73.194.172.208
2015-01-21 00:28:13 AddLocal(73.194.172.208:9999,4)
2015-01-21 00:28:13 ext-ip thread exit
2015-01-21 00:28:13 receive version message: /Satoshi:0.10.17.24/: version 70051, blocks=199711, us=73.194.172.208:60989, them=108.61.208.125:9999, peer=108.61.208.125:9999
2015-01-21 00:28:13 Added time data, samples 2, offset -14 (+0 minutes)
2015-01-21 00:28:14 receive version message: /Core:0.11.0.6/: version 70052, blocks=204572, us=73.194.172.208:60990, them=37.157.250.10:9999, peer=37.157.250.47:9999
2015-01-21 00:28:14 Added time data, samples 3, offset -15 (+0 minutes)
2015-01-21 00:28:14 UpdateTip: new best=00000000003ed7fb20d0e93bc8a48f7f9ec1508db1c50593595ec27a3d34a34f height=40321 log2_work=54.46844 tx=167099 date=2014-03-26 14:10:44 progress=0.019067
 
Last edited by a moderator:
Yeah, definitely would love to see the v10's drop from the network and not get paid. Lazy fucks.

At least this kind of confirms one thing. Masternode owners are a pretty diverse bunch. When I saw the network update too fast I always thought that most masternode owners were concentrated in a tight circle.
 
Yeah, definitely would love to see the v10's drop from the network and not get paid. Lazy fucks.

we should put out a 1-2 week warning when payments will be cut off if NOT updated to updated to v11
that should get this going !
 
My windows 32-bit wallet was syncing up to "24 hours behind" then it crashed. Restarted, it crashed again. Then I removed the 'bootstrap.dat.old' and it synced fine, not sure if that file had anything to do with it, wish I knew. (Bootstrap.dat has always helped to sync faster.)

BTW, has anyone noticed we forked to hell, yet the price is going up? lol
 
do NOT say the "F" word please
(freaks me out, and whoever else is watching) :wink:

Mac wallet id running fine,
crashed once on me, but now no problems, am trying to Mix 40 if anybody is up for it !
 
Back
Top