• 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

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.
 
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?
 
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
 
- 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:
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) :wink: 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.
 
Good thinking and interesting read (as always) :wink: 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.
 
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
 
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... :wink:
 
IMO, I think Aswan should become a core developer (if he is interested), Aswan has a great mind and is finding faults in the system which are making it stronger.
That would be awesome!
This is some good piece of time since he helps and gives his knowledge to improve to anonymity.
I`m +1 for this idea. Aswan eduffield would you? :grin:
 
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... :wink:

It wouldn't necessarily require a fork, just masternode compatibility with both systems. This would split the Darksend users into 2 groups. The ones that use the old and the ones that use the new system.
Currently, we have 3 people mixing their coins per DS Tx, so at least 3 people using the same denomination system have to enter the mixing process and choose the same MN in the same timeframe.
If there are 2 ppl using such a new denomination system and 1 person or 2 ppl using the old one, they would just have to keep looking for others using the same system.

While this could lead to people flocking to one system because it is then faster for mixing coins, there will probably always be some people using the system which has the smaller denominations, especially if price is rising. So I think there would be a slow but steady adoption of a change in the denomination system to if the new system has a smaller smallest denomination and price is not falling significantly.

So I actually like this idea and I think this could be huge, if done correctly.
Hell the 2 systems would even be compatible to use in A SINGLE TRANSACTION. With 6 people entering the MN pool, 3 of each denomination system, there could be a Tx including denominations of both systems and the user of each system would achieve the anonymity of the current 3 parties DS (because at least 3 use his system). There could be Transactions using 4 or 5 different denomination systems in a single Tx.

We're onto something here... :D

Lets say there are 4 denominations with each denomination being a 10 x multiple of the smaller denomination.
The smallest denomination is variable and can be chosen by each DS participant.
Masternodes support all of these denomination systems. In fact, it's not "systems" anymore, it's just one system supporting all this.
When 3 or more people using the same denominations choose the same MN at the same time, a DS Tx can happen.
If people who use different denominations use the same MN, they can all be in the same Tx if at least 3 people use the same denominations.

This is for recognizable convertible denominations UdjinM6 came up with and would be already awesome.

However, if they would be non-recognizable as I suggested, then different denomination sizes would be even more compatible because one could also convert between those different systems.
If there are 5 people in the MN pool all using 0.1, 1, 10, 100 and you are using 0.01, 0.1, 1, 10 - Then you could either throw in 10x 0.01 in order to get compatible, because then you can output this as a 0.1 denom, or they can all go to smaller denominations, making their 100 output as 10 x 10 (any may making 1x 0.1 into 10 x 0.01 for making it harder to actually trace your coins).

In most cases, converting to a higher denomination size is better because it creates less bloat.
This could also help when you have a small amount of anonymized DRK and you then get a bigger amount. They could be compatible that way.

This is just me writing all this while I am coming up with it.
If there are some mistakes, sorry.


That would be awesome!
This is some good piece of time since he helps and gives his knowledge to improve to anonymity.
I`m +1 for this idea. Aswan eduffield would you? :grin:


"Core Developer" or "Dev Team" kinda sounds like you are actually doing the coding, which I am not, so Idk if this would fit :)
 
It wouldn't necessarily require a fork, just masternode compatibility with both systems. This would split the Darksend users into 2 groups. The ones that use the old and the ones that use the new system.
Currently, we have 3 people mixing their coins per DS Tx, so at least 3 people using the same denomination system have to enter the mixing process and choose the same MN in the same timeframe.
If there are 2 ppl using such a new denomination system and 1 person or 2 ppl using the old one, they would just have to keep looking for others using the same system.

While this could lead to people flocking to one system because it is then faster for mixing coins, there will probably always be some people using the system which has the smaller denominations, especially if price is rising. So I think there would be a slow but steady adoption of a change in the denomination system to if the new system has a smaller smallest denomination and price is not falling significantly.

So I actually like this idea and I think this could be huge, if done correctly.
Hell the 2 systems would even be compatible to use in A SINGLE TRANSACTION. With 6 people entering the MN pool, 3 of each denomination system, there could be a Tx including denominations of both systems and the user of each system would achieve the anonymity of the current 3 parties DS (because at least 3 use his system). There could be Transactions using 4 or 5 different denomination systems in a single Tx.

We're onto something here... :D

Lets say there are 4 denominations with each denomination being a 10 x multiple of the smaller denomination.
The smallest denomination is variable and can be chosen by each DS participant.
Masternodes support all of these denomination systems. In fact, it's not "systems" anymore, it's just one system supporting all this.
When 3 or more people using the same denominations choose the same MN at the same time, a DS Tx can happen.
If people who use different denominations use the same MN, they can all be in the same Tx if at least 3 people use the same denominations.

This is for recognizable convertible denominations UdjinM6 came up with and would be already awesome.

However, if they would be non-recognizable as I suggested, then different denomination sizes would be even more compatible because one could also convert between those different systems.
If there are 5 people in the MN pool all using 0.1, 1, 10, 100 and you are using 0.01, 0.1, 1, 10 - Then you could either throw in 10x 0.01 in order to get compatible, because then you can output this as a 0.1 denom, or they can all go to smaller denominations, making their 100 output as 10 x 10 (any may making 1x 0.1 into 10 x 0.01 for making it harder to actually trace your coins).

In most cases, converting to a higher denomination size is better because it creates less bloat.
This could also help when you have a small amount of anonymized DRK and you then get a bigger amount. They could be compatible that way.

This is just me writing all this while I am coming up with it.
If there are some mistakes, sorry.





"Core Developer" or "Dev Team" kinda sounds like you are actually doing the coding, which I am not, so Idk if this would fit :)

You could be our cryptographer or privacy quality assurance officer, lol, I just came up with that.
 
Another question: 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?
It's saying that you are looking to send DRK from your wallet, even if it's non-anonymized funds (i.e. funds that have not been sent through Darksend, first.). The warning is because non-anonymized funds are easily tracked. Checking the Darksend box when sending DRK will get rid of the message, assuming you have run Darksend on your coins.
 
Good thinking and interesting read (as always) :wink: 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.

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
 
Back
Top