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:
i had same issue with 0.11.06 and 0.11.07
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.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!
Trying this now -_-. Was hoping it wouldn't come to this!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
OK, blockchain dl'ed, wallet.dat restored and all is working ^===^Trying this now -_-. Was hoping it wouldn't come to this!
No crash yet but still dl'ing blockchain.
Thats really good, but unfortunately, thats not enough, because of denomination recombination and splitting without denomination convertibility.- Removed non-denomational inputs, this vastly improves the anonymity provided by the system by removing any traceable element into the mixing of coins (UdjinM6)
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:Thats really good, but unfortunately, thats not enough, because of denomination recombination and splitting without denomination convertibility.
Look at this Tx:
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.
I said it again and again and I will say it again:
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.
Interesting. What are we gonna do when we introduce 0.01 denominations in order to adapt to a possible price increase?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.
0.11.09 running like a charm on windows 32bitOK, 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 think it will take some time until we are 10x in price terms. And once we are there we can simply switch to another set of denominations likeInteresting. 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.
10.00001000 DRK 1.00000100 DRK 0.10000010 DRK 0.01000001 DRK