v0.11.0 - Darkcoin Core Release

Aswan

Member
Jun 26, 2014
68
216
73
Hey, I've read through your posts and I believe all issues you bring up are presently fixed in 11.0.8. UdjinM6 wrote a nice patch which entirely removes non-denomination DRK from being in the pool at all. I'm going to compile and release this version in the morning, as a nice side effect, mixing should be about 100% faster too. We're getting to an almost perfectly working system, it's just taking some real work to do it the right way ;)

Changes are here:

https://github.com/darkcoin/darkcoin/pull/116/files

I have read through the code and I think at least one issue I have brought up is not fixed, plus I have some more on the list :)
Also, with each denomination size only allowed 10 times, this will make denomination combination necessary if there are more than 10 inputs of one kind of denomination which will cause non-DS denomination change to occur whenever this is the case.
Furthermore, this change would have some dead change characteristics if sent as "non-anonymous funds" in combination with others of its kind or in combination with the change of the initial denomination (when funds enter DS the first time).

This can be fixed by adding denomination convertibility (removing the additional 1 duff of each DS denomination).

The list is still long. I will send you an email :)

Edit: some corrections. forgive me, it's still early :)
 
Last edited by a moderator:

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
OSx 11.0.7 crashed the first time on exit (with active darkcoin.conf), but since then has been working perfectly updating a few nodes and general use.
 

studioz

Well-known Member
Sep 10, 2014
540
464
163
CANADA
dashbr.com
32-bit wallet is crashing immediately too. Same error. With -reindex or without.
i had same issue with 0.11.06 and 0.11.07
i went to hidden folder: press run,type: %appdata% , press enter
move or rename Darkcoin folder ,inside wallet.dat is where all your coins are ,make sure you dont lose/delete that file
then reinstall latest Darkcoin wallet.
let it download blockchain,can take some time,when uptodated ,close wallet
now,copy wallet.dat from old Darkcoin folder to new Darkcoin folder inside %appdata%
re-openwallet ,now you should be good and see your balance
 
Last edited by a moderator:
  • Like
Reactions: brownmon

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
What's the deal with miner XqCgbEhrpjQFAL5ro2euo9eACSgTP8hKSR paying only 10% to masternode, on top of the obvious wrong blocktemplate.
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,890
6,717
1,283
whow you guys and girls are so good !
respect to Aswan ,evan and UdhingM16 (sorry misspelling)
great team effort
can not wait for 11.0.8, will darksend myself invisable finally !
;)
 
  • Like
Reactions: splawik21

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
11.0.9 Core - All Users

Source: https://github.com/darkcoin/darkcoin
Windows .exe: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.11.0.9-win.zip
Mac OSX: https://raw.githubusercontent.com/darkcoinproject/darkcoin-binaries/master/darkcoin-0.11.0.9-osx.dmg
Linux: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.11.0.9-linux.tar.gz

Change Log:

11.0.8 / 11.0.9:

- Version Bump : Masternodes / Darksend users please update!
- Removed non-denomational inputs, this vastly improves the anonymity provided by the system by removing any traceable element into the mixing of coins (UdjinM6)
- Sessions now have randomized maximum amounts, also improving the anonymity
- corrected getblocktemplate coinbasevalue output, causing some mining issues
- "--litemode" added, which allows the client to run without Darksend, Masternodes or InstantX but still be compatible with the network (for slower computers or if you're not using any of that technology)
- MacOSX is now fixed and supported (flare and UdjinM6)
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,890
6,717
1,283
yeah
you guys rock !!
tx

Edit: Mac / PC wallets still do not work
but I am sure you guys still compiling
 
Last edited by a moderator:

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
Yep, windows link should be fixed. Let's wait for @edufield or flare to do this.
EDIT: Sorry guys, I removed the direct link as it brings too much traffic
 
Last edited by a moderator:
  • Like
Reactions: tungfa and madeyes

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,890
6,717
1,283
Same here. 0 bytes. Nothing in it.
I believe they are compiling it as it has been posted before
My MAC wallet is humming away nicely !
(1st time ever that i have that before the PC)
 

fernando

Powered by Dash
Dash Core Team
Moderator
Foundation Member
May 9, 2014
1,527
2,058
283
Tweeted. Is anyone else loving the subtle dig at Litecoin here with "Litemode"? Run a version that has no Darksend, Masternodes, or InstantX, just like Litecoin!

Intentional or not, that's hilarious!
Even without those features, Darkcoin is vastly superior to Litecoin. We are a Bitcoin fork now and we have more than a full year of Bitcoin development that Litecoin doesn't have.
 

brownmon

New Member
Oct 6, 2014
11
3
3
i had same issue with 0.11.06 and 0.11.07
i went to hidden folder: press run,type: %appdata% , press enter
move or rename Darkcoin folder ,inside wallet.dat is where all your coins are ,make sure you dont lose/delete that file
then reinstall latest Darkcoin wallet.
let it download blockchain,can take some time,when uptodated ,close wallet
now,copy wallet.dat from old Darkcoin folder to new Darkcoin folder inside %appdata%
re-openwallet ,now you should be good and see your balance
Trying this now -_-. Was hoping it wouldn't come to this!

No crash yet but still dl'ing blockchain.
 
  • Like
Reactions: studioz

brownmon

New Member
Oct 6, 2014
11
3
3
Trying this now -_-. Was hoping it wouldn't come to this!

No crash yet but still dl'ing blockchain.
OK, blockchain dl'ed, wallet.dat restored and all is working ^===^

(I did get another crash of the same kind when I tried to make an address in the 'Receiving addreses' window with the wallet locked though. You might want to see if you can reproduce that one.)

Another question: I'm sending some money myself to split an address so it looks like some of the money has been spent, from one address I chose in Coin Control and to and address I created in 'Receiving addresses'. I get a terrifying warning upon doing this -- "Do you want to send XXX DRK using ANY AVAILABLE FUNDS (NOT RECOMMENDED!)" -- What's with this warning?
 
  • Like
Reactions: studioz

studioz

Well-known Member
Sep 10, 2014
540
464
163
CANADA
dashbr.com
i didnt do no tx since,i just tried denomination and worked extremely fast
im going to bring kids to school now
when get back ill update 1st then try to tx to myself
 

Aswan

Member
Jun 26, 2014
68
216
73
- Removed non-denomational inputs, this vastly improves the anonymity provided by the system by removing any traceable element into the mixing of coins (UdjinM6)
Thats really good, but unfortunately, thats not enough, because of denomination recombination and splitting without denomination convertibility.

Look at this Tx:
7df9af07fa9e519555eb8bcfbe4cbf514b035fd8b763b0f5778298b5447f48cb
It has only DS denomination inputs. Let's look at the 100.00000001 DRK inputs. There are 4 of them. However, if we look at the outputs, there is only 1 100.00000001 DRK denomination.
This, in itself, is fine since it does not add additional traceability.
However, what happened to the other 100.00000001 DRK inputs?
Because we do not have denomination convertibility, there have been non DS denominations created when splitting these inputs. There are 3 of those (because 3 100.00000001 DRK inputs have been split):

1.) 60.39999983 DRK
2.) 25.79999988 DRK
3.) 22.29999980 DRK

The reason why did is bad is, that, first of all, one can easily tell how many denominations where split from the inputs. For 1.) it's 18 inputs plus the non DS denomination change, for 2.) its 13 and for 3.) its 21.
This can be done by simply done by looking at the smallest units, the duffs. Each DS has 1 duff at the eighth decimal place, so for each 1 duff missing from the end of the non-ds output, 1 denomination must have been created.

What we know so far:

1.) 100.00000001 DRK input - 60.39999983 DRK - 18 denominations
2.) 100.00000001 DRK input - 25.79999988 DRK - 13 denominations
3.) 100.00000001 DRK input - 22.29999980 DRK - 21 denominations

so Let's check if this can actually be correct. For 1.) the denominations could be 3 x 10.00000001 DRK, 6 x 0.10000001 DRK, but this could not add up to 18 and would miss 100.00000001 DRK by 9 duffs. It can only be 2 x 10.00000001 DRK, 10 x 1.00000001 DRK and 6 x 0.10000001 DRK. This, plus the 60.39999983 DRK add up to 100.00000001 DRK.

so we now know this:
1.) 100.00000001 DRK input - 60.39999983 DRK - 18 denominations - 2 x 10.00000001 DRK - 10 x 1.00000001 DRK - 0.10000001 DRK

We could do this for 2.) and 3.) we well and just as easy.
While this information may or may not be useful for traceability, it at least increases the probability of coins being successfully traced.

The Solution:
I said it again and again and I will say it again:
DENOMINATION CONVERTIBILITY!

With denomination convertibility, not only the input side will consist of only DS denominations, but also the output side, making this kind of investigation impossible.
All that needs to be done is remove 1 duff from each DS denomination.
100.00000001 DRK becomes 100 DRK
10.00000001 DRK becomes 10 DRK
1.00000001 DRK becomes 1 DRK
0.10000001 DRK becomes 0.1 DRK

With this, each denomination you, unlike before be a multiple of each other, which allows us to convert them into each other.

Going back to our example Tx: If this Tx had denomination convertibility, then 1.) would have an input of 100 DRK and could be split into 8x 10 DRK, 19x 1 DRK and 10x 0.1 DRK, totaling 100 DRK.
As you can see, we still have at least enough of each denomination to fulfill the needs of the original Tx (we have at least 2x 10 DRK, 10x 1 DRK and 6x 0.1 DRK).
The difference is that there are no non DS denominations output.

Now one could say this creates more outputs and therefore the Tx size and bloat increases. Well, yes and no. It creates 37 instead of 19 outputs in this case because I wanted to have at least the same amount of each denomination output for this 100 DRK as in the original Tx just to show you that it does not lack any capabilities. However, you could always just go for 10x10 DRK.

Also, with ab output of 60.39999983 DRK, this need to be re-denominated. Now because with 0.11.0.9 there are no more non DS inputs allowed in a DS Tx, they need do be re-denominated in a separate Tx. Talking about bloat, this is just as bad if not worse than just having the possibility of getting a few more denominated outputs right away, which do not have to go through another Tx.

And theres more. With the current denomination size, if something like this happens, there will always be a leftover. A change of some size slightly smaller than the lowest denomination. This change is similar to dead change.
When this happens in one transaction and then, 10 DS rounds later it happens again, there will be 2 changes left.
These 2 changes are too small to be in the Darksend pool and will not further be anonymized. However, if they are somehow linked, they will build an "analysis bridge" between their creation transactions which links them to the same user. In this case, this "analysis bridge" is bridging the analysis by 10 DS rounds. While is only link the coins that are in their Transactions, this might not de-anonymize all of the DS pool, but paybe part of it, which makes this whole part toxic for the other coins in the pool again.

I have described this phenomenon here: https://darkcointalk.org/threads/dead-change-an-anonymity-issue.3019/

This is especially bad because in such a scenario it is extremely likely that the 2 changes together would be enough to be mixed with Darksend again so people could get the idea to just combine them and send them in the DS pool, which in turn really hurts their anonymization process.

With denomination convertibility, this kind of dead change, the "analysis bridge" and re-denomination transactions would not happen.
As a bonus, it would improve anonymity in general because it leaves less possible analysis approaches.
 
Last edited by a moderator:

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
Thats really good, but unfortunately, thats not enough, because of denomination recombination and splitting without denomination convertibility.

Look at this Tx:
7df9af07fa9e519555eb8bcfbe4cbf514b035fd8b763b0f5778298b5447f48cb
It has only DS denomination inputs. Let's look at the 100.00000001 DRK inputs. There are 4 of them. However, if we look at the outputs, there is only 1 100.00000001 DRK denomination.
This, in itself, is fine since it does not add additional traceability.
However, what happened to the other 100.00000001 DRK inputs?
Because we do not have denomination convertibility, there have been non DS denominations created when splitting these inputs. There are 3 of those (because 3 100.00000001 DRK inputs have been split):

1.) 60.39999983 DRK
2.) 25.79999988 DRK
3.) 22.29999980 DRK

The reason why did is bad is, that, first of all, one can easily tell how many denominations where split from the inputs. For 1.) it's 18 inputs plus the non DS denomination change, for 2.) its 13 and for 3.) its 21.
This can be done by simply done by looking at the smallest units, the duffs. Each DS has 1 duff at the eighth decimal place, so for each 1 duff missing from the end of the non-ds output, 1 denomination must have been created.

What we know so far:

1.) 100.00000001 DRK input - 60.39999983 DRK - 18 denominations
2.) 100.00000001 DRK input - 25.79999988 DRK - 13 denominations
3.) 100.00000001 DRK input - 22.29999980 DRK - 21 denominations

so Let's check if this can actually be correct. For 1.) the denominations could be 3 x 10.00000001 DRK, 6 x 0.10000001 DRK, but this could not add up to 18 and would miss 100.00000001 DRK by 9 duffs. It can only be 2 x 10.00000001 DRK, 10 x 1.00000001 DRK and 6 x 0.10000001 DRK. This, plus the 60.39999983 DRK add up to 100.00000001 DRK.

so we now know this:
1.) 100.00000001 DRK input - 60.39999983 DRK - 18 denominations - 2 x 10.00000001 DRK - 10 x 1.00000001 DRK - 0.10000001 DRK

We could do this for 2.) and 3.) we well and just as easy.
While this information may or may not be useful for traceability, it at least increases the probability of coins being successfully traced.

The Solution:
I said it again and again and I will say it again:
DENOMINATION CONVERTIBILITY!

With denomination convertibility, not only the input side will consist of only DS denominations, but also the output side, making this kind of investigation impossible.
All that needs to be done is remove 1 duff from each DS denomination.
100.00000001 DRK becomes 100 DRK
10.00000001 DRK becomes 10 DRK
1.00000001 DRK becomes 1 DRK
0.10000001 DRK becomes 0.1 DRK

With this, each denomination you, unlike before be a multiple of each other, which allows us to convert them into each other.

Going back to our example Tx: If this Tx had denomination convertibility, then 1.) would have an input of 100 DRK and could be split into 8x 10 DRK, 19x 1 DRK and 10x 0.1 DRK, totaling 100 DRK.
As you can see, we still have at least enough of each denomination to fulfill the needs of the original Tx (we have at least 2x 10 DRK, 10x 1 DRK and 6x 0.1 DRK).
The difference is that there are no non DS denominations output.

Now one could say this creates more outputs and therefore the Tx size and bloat increases. Well, yes and no. It creates 37 instead of 19 outputs in this case because I wanted to have at least the same amount of each denomination output for this 100 DRK as in the original Tx just to show you that it does not lack any capabilities. However, you could always just go for 10x10 DRK.

Also, with ab output of 60.39999983 DRK, this need to be re-denominated. Now because with 0.11.0.9 there are no more non DS inputs allowed in a DS Tx, they need do be re-denominated in a separate Tx. Talking about bloat, this is just as bad if not worse than just having the possibility of getting a few more denominated outputs right away, which do not have to go through another Tx.

And theres more. With the current denomination size, if something like this happens, there will always be a leftover. A change of some size slightly smaller than the lowest denomination. This change is similar to dead change.
When this happens in one transaction and then, 10 DS rounds later it happens again, there will be 2 changes left.
These 2 changes are too small to be in the Darksend pool and will not further be anonymized. However, if they are somehow linked, they will build an "analysis bridge" between their creation transactions which links them to the same user. In this case, this "analysis bridge" is bridging the analysis by 10 DS rounds. While is only link the coins that are in their Transactions, this might not de-anonymize all of the DS pool, but paybe part of it, which makes this whole part toxic for the other coins in the pool again.

I have described this phenomenon here: https://darkcointalk.org/threads/dead-change-an-anonymity-issue.3019/

This is especially bad because in such a scenario it is extremely likely that the 2 changes together would be enough to be mixed with Darksend again so people could get the idea to just combine them and send them in the DS pool, which in turn really hurts their anonymization process.

With denomination convertibility, this kind of dead change, the "analysis bridge" and re-denomination transactions would not happen.
As a bonus, it would improve anonymity in general because it leaves less possible analysis approaches.
Good thinking and interesting read (as always) ;) The reason for 0.00000001 was to have a way to easily distinguish denominated amounts I believe. Round numbers are too "human". With that being sad what do you think of another approach to convertibility? smth like that:
100.00000001 DRK becomes 100.00001000 DRK
10.00000001 DRK becomes 10.00000100 DRK
1.00000001 DRK becomes 1.00000010 DRK
0.10000001 DRK stays 0.10000001 DRK
From first sight to me it looks like having both pros: it's recognizable and it's convertible at the same time.
 

Aswan

Member
Jun 26, 2014
68
216
73
Good thinking and interesting read (as always) ;) The reason for 0.00000001 was to have a way to easily distinguish denominated amounts I believe. Round numbers are too "human". With that being sad what do you think of another approach to convertibility? smth like that:
100.00000001 DRK becomes 100.00001000 DRK
10.00000001 DRK becomes 10.00000100 DRK
1.00000001 DRK becomes 1.00000010 DRK
0.10000001 DRK stays 0.10000001 DRK
From first sight to me it looks like having both pros: it's recognizable and it's convertible at the same time.
Interesting. What are we gonna do when we introduce 0.01 denominations in order to adapt to a possible price increase?
Also, I think a 0.01 denomination will be necessary for DarkSend fees in the future. I see a flaw with the current fee/collateral system which I have not publicly talked about so far. It is related to scalability and anonymity.
 

studioz

Well-known Member
Sep 10, 2014
540
464
163
CANADA
dashbr.com
OK, blockchain dl'ed, wallet.dat restored and all is working ^===^

(I did get another crash of the same kind when I tried to make an address in the 'Receiving addreses' window with the wallet locked though. You might want to see if you can reproduce that one.)

Another question: I'm sending some money myself to split an address so it looks like some of the money has been spent, from one address I chose in Coin Control and to and address I created in 'Receiving addresses'. I get a terrifying warning upon doing this -- "Do you want to send XXX DRK using ANY AVAILABLE FUNDS (NOT RECOMMENDED!)" -- What's with this warning?
0.11.09 running like a charm on windows 32bit
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
Interesting. What are we gonna do when we introduce 0.01 denominations in order to adapt to a possible price increase?
Also, I think a 0.01 denomination will be necessary for DarkSend fees in the future. I see a flaw with the current fee/collateral system which I have not publicly talked about so far. It is related to scalability and anonymity.
I think it will take some time until we are 10x in price terms. :rolleyes: And once we are there we can simply switch to another set of denominations like
Code:
 10.00001000 DRK
  1.00000100 DRK
  0.10000010 DRK
  0.01000001 DRK
This however will lead to incompatibility in mixing process between different protocol versions and could also bring some inconvenience but I don't think that's going to be a huge problem. Even Bitcoin did a hard fork once to change its fee... ;)
 
  • Like
Reactions: moli and Aswan