v0.11.0 - Darkcoin Core Release

My synced mn says there're 2014 mns so there's no significant decrease yet.
https://drk.mn/blocks.html is up but mad and thinks there is 54% estimated payments for blocks that were before 204572 aswell. As I remember I looked there at the morning and it was ok. That makes me think there's a bug like time-bomb somewhere in the clients. Would like to see post-mortem.
 
Last edited by a moderator:
GilAlexander said:
My synced mn says there're 2014 mn's so there's no significant decrease yet.
https://drk.mn/blocks.html is up but mad and thinks there is 54% estimated payments for blocks that were before 204572 aswell. As I remember I looked there at the morning and it was ok. That makes me think there's a bug like time-bomb somewhere in the clients. Would like to see post-mortem.
Click to expand...
We are pioneers testing a new technology and new software. We're changing from the old litecoin code base to bitcoin code base. It's software, it's not a timed-bomb, there's no need to be panic. :tongue:
 
I have had some time to test the new Darksend and have found that it is a lot easier to trace coins than is has to be because of the fact that the outputs are not all DS denominations but sometimes just regular change amounts which are so high that they can be tied to a specific input, sometimes over several transactions, which makes the actual security go down to the equivalent of 1 round of the old DS when all DS Transactions are affected (like someone going for 4 rounds with all 4 rounds being affected by this).
In this case, there will be more than 4 DS Transactions but some coins may have 4 DS rounds after 4 DS transactions, and those are the leaking coins (the ones that only have an actual security of 1 round, the last round).

A simple fix would be to make every non DS denominated output be smaller than the smallest non DS denominated input. I think this is the first step to make this more secure. I am going to analyze several anonymization processes in the next days/weeks and I will try to find out more ways to trace coins through the chain. However, the problem I described above is significant and can be easily fixed so I thought I might let you know already :)
 
What will happen if there're a lot of masternodes which are capable :)1 in list) but stucked on the wrong chain\blockheight? Surely they aren't able to process darksend txs. Looks like that result in ds completely broken for a while. I can compare with some kind of attack when a lot of masternodes are evil but due to technical reasons.
Prove me wrong, but blockchain and masternode list are different things and there's no direct relation. Am I miss smth?
 
thelonecrouton said:
All my MNs shut down, blockheight stuck on 204572. 50/50 deamon shut down altogether / kept running but no more as MN.

edit: deleted blocks/chainstate/peers.dat, resyncing them all now.
Click to expand...

I had to delete the blockchain on my Masternodes (resync didn't help, but when you have a 1GBit connection it's a piece of cake) and all are fine now.

For the moment :grin:
 
Aswan said:
I have had some time to test the new Darksend and have found that it is a lot easier to trace coins than is has to be because of the fact that the outputs are not all DS denominations but sometimes just regular change amounts which are so high that they can be tied to a specific input, sometimes over several transactions, which makes the actual security go down to the equivalent of 1 round of the old DS when all DS Transactions are affected (like someone going for 4 rounds with all 4 rounds being affected by this).
In this case, there will be more than 4 DS Transactions but some coins may have 4 DS rounds after 4 DS transactions, and those are the leaking coins (the ones that only have an actual security of 1 round, the last round).

A simple fix would be to make every non DS denominated output be smaller than the smallest non DS denominated input. I think this is the first step to make this more secure. I am going to analyze several anonymization processes in the next days/weeks and I will try to find out more ways to trace coins through the chain. However, the problem I described above is significant and can be easily fixed so I thought I might let you know already :)
Click to expand...
Are you talking about the change amounts similar to what I posted on the Test thread, page 27, post #540 here?:
https://darkcointalk.org/threads/v0-11-0-x-testing.3401/page-27#post-36665

I had done another test before that test by sending all the change amounts back to myself and tried to mix again but DS would not mix again.
Also, maybe it's too early to test DS on Mainnet until all the current issues with stuck MNs and transactions get resolved? Thanks :)
 
moli said:
Are you talking about the change amounts similar to what I posted on the Test thread, page 27, post #540 here?:
https://darkcointalk.org/threads/v0-11-0-x-testing.3401/page-27#post-36665

I had done another test before that test by sending all the change amounts back to myself and tried to mix again but DS would not mix again.
Also, maybe it's too early to test DS on Mainnet until all the current issues with stuck MNs and transactions get resolved? Thanks :)
Click to expand...

No I am talking about this:

1.) Tx "caa2111b924b44437cce277f939f5d177b3ad96acce8bcb6d006f9e193602bf4" is splitting 350 DRK to get ready for DS

2.) Tx "b6b285ffbcc23db6e8c9e817378372fc47e7423d84e1b1af5d84c000d0e848e9" is DS round 1 for these funds. The 349.575 DRK are the biggest input. The output 227.47499967 DRK is the biggest output and is bigger than all other inputs, making it highly likely it is a change of the 349.575 DRK input. This can further be verified by looking at the mDRK numbers (which indicate relations between inputs/outputs if the amount of potential DS denominations is taking into account). So We got the change of this address.

3.) Tx "d6837f60aa13bfe02b9feea8509a1a96904927f7569cc29f29e45906291f87df" Uses out 227.47499967 DRK as input. It is very interesting that we also have an output of 227.47499967 DRK. This means the 227.47499967 DRK have not been mixed at all and should not have entered this DS Tx, This is an obvious design error. Furthermore, that tells us that it is highly likely that other smaller denominations derived from the initial input of 349.575 DRK in 2.) participated here. This becomes even more likely when looking at the Transaction the inputs for 3.) came from as we can see 2.) there not only for the 227.47499967 DRK input, but also for some DS denominations.

4.) Tx "366059bd66989564fb3f8dca5bf5144bae1b4cc21ade403a6cae3ca052804eaf" Is an easy one. Same this as above. This time only 285.82489983 DRK get transacted in total, with 227.47499967 DRK coming from 3.) Since there is an output of 215.37499945 DRK is can be easily linked. Also, there have been some DS denominations from 3.) and therefore also from 2.) mixed in this.

This means that with 4.) we have some freshly denominated coins that will only have 1 DS round and this is handled correctly by the client. However, we have also some denominations that we had in 2.) and WE KNOW THAT. These coins are marked with 3 DS rounds in the client, but in reality they only have the anonymity of a single round since we know they are involved.

This is why we need smaller non-denominated outputs, or even better, no non-denominated outputs at all.

When splitting the initial 350 DRK, why not split them into DS denominations? That way, this kind of tracking is not easily possible. Also, PLEASE finally make denominations convertible (removing 1 duff from all DS denominations). That way we have more liquidity since a 100 denom will not have to wait for other 100s, but can mix with 10s since it can be converted to 10s. With the current DS denomination system, it would lack 9 duffs and could simply not do this.

An additional suggestion is to make DS payments through a DS Tx possible. Because of the dead change issue we already have round up to the smallest denom when sending DS funds, so this wouldn't make it cost more.
When I want to send 5 DRK to someone, I could tell by client to do this but use a Darksend Tx for it. That means it would take a 10 denom, start a DS request with outputs of 1s, and once it is accepted it would send 5 DRK to the receiver and 5x1 DRK (DS denom) to 5 different addresses of mine. There could also be other coins of mine mixed in this Tx.
It would get rid of the extra Tx to send the coins since I mix my coins anyway, it is a lot harder to trace and it reduces bloat since there is no extra payment Tx in addition to the DS Tx.

The only disadvantage is that it would take longer because I would have to find ppl to mix with the moment I want to pay. However, with more and more adoption the waiting times will be reduced. Plus this can be optional. You can always pay the usual way if you want it to be fast.


Edit: Also, please change the recombining of DS denoms. It is like a soft reset of the already gotten anonymity especially when used in conjunction with the problem above =/

I feel like DS is now less safe than before =/
 
Lols, the irony... It's usually me having the problems nobody else has. Now, everyone else is having problems and mine are all working fine...

this not-quite-a-fork situation is not going to resolve until people get their butts on 0.11...
 
Aswan said:
No I am talking about this:

1.) Tx "caa2111b924b44437cce277f939f5d177b3ad96acce8bcb6d006f9e193602bf4" is splitting 350 DRK to get ready for DS

2.) Tx "b6b285ffbcc23db6e8c9e817378372fc47e7423d84e1b1af5d84c000d0e848e9" is DS round 1 for these funds. The 349.575 DRK are the biggest input. The output 227.47499967 DRK is the biggest output and is bigger than all other inputs, making it highly likely it is a change of the 349.575 DRK input. This can further be verified by looking at the mDRK numbers (which indicate relations between inputs/outputs if the amount of potential DS denominations is taking into account). So We got the change of this address.

3.) Tx "d6837f60aa13bfe02b9feea8509a1a96904927f7569cc29f29e45906291f87df" Uses out 227.47499967 DRK as input. It is very interesting that we also have an output of 227.47499967 DRK. This means the 227.47499967 DRK have not been mixed at all and should not have entered this DS Tx, This is an obvious design error. Furthermore, that tells us that it is highly likely that other smaller denominations derived from the initial input of 349.575 DRK in 2.) participated here. This becomes even more likely when looking at the Transaction the inputs for 3.) came from as we can see 2.) there not only for the 227.47499967 DRK input, but also for some DS denominations.

4.) Tx "366059bd66989564fb3f8dca5bf5144bae1b4cc21ade403a6cae3ca052804eaf" Is an easy one. Same this as above. This time only 285.82489983 DRK get transacted in total, with 227.47499967 DRK coming from 3.) Since there is an output of 215.37499945 DRK is can be easily linked. Also, there have been some DS denominations from 3.) and therefore also from 2.) mixed in this.

This means that with 4.) we have some freshly denominated coins that will only have 1 DS round and this is handled correctly by the client. However, we have also some denominations that we had in 2.) and WE KNOW THAT. These coins are marked with 3 DS rounds in the client, but in reality they only have the anonymity of a single round since we know they are involved.

This is why we need smaller non-denominated outputs, or even better, no non-denominated outputs at all.

When splitting the initial 350 DRK, why not split them into DS denominations? That way, this kind of tracking is not easily possible. Also, PLEASE finally make denominations convertible (removing 1 duff from all DS denominations). That way we have more liquidity since a 100 denom will not have to wait for other 100s, but can mix with 10s since it can be converted to 10s. With the current DS denomination system, it would lack 9 duffs and could simply not do this.

An additional suggestion is to make DS payments through a DS Tx possible. Because of the dead change issue we already have round up to the smallest denom when sending DS funds, so this wouldn't make it cost more.
When I want to send 5 DRK to someone, I could tell by client to do this but use a Darksend Tx for it. That means it would take a 10 denom, start a DS request with outputs of 1s, and once it is accepted it would send 5 DRK to the receiver and 5x1 DRK (DS denom) to 5 different addresses of mine. There could also be other coins of mine mixed in this Tx.
It would get rid of the extra Tx to send the coins since I mix my coins anyway, it is a lot harder to trace and it reduces bloat since there is no extra payment Tx in addition to the DS Tx.

The only disadvantage is that it would take longer because I would have to find ppl to mix with the moment I want to pay. However, with more and more adoption the waiting times will be reduced. Plus this can be optional. You can always pay the usual way if you want it to be fast.


Edit: Also, please change the recombining of DS denoms. It is like a soft reset of the already gotten anonymity especially when used in conjunction with the problem above =/

I feel like DS is now less safe than before =/
Click to expand...
I'm wondering because of the hard fork we're having, DS wasn't working properly in splitting that amount 227.47499967 DRK.. I'll wait until everybody has updated and we'll see.
 
moli said:
I'm wondering because of the hard fork we're having, DS wasn't working properly in splitting that amount 227.47499967 DRK.. I'll wait until everybody has updated and we'll see.
Click to expand...

Maybe that one Tx, but that does not invalidate all the other issues I have brought up. I hope they can get fixed =/
 
To help this process go more quickly...

delete your blocks and chainstate folders

remove peers.dat every time you restart the qt

restart the qt every time you get a whole lot of rejected/orphan blocks while pulling a completely new chain

Once you finally get a full chain, "cd ~/.darkcoin && scp -C -r blocks/ chainstate/ username@masternode:~/.darkcoin/"

This assures that all the masternodes get the correct chain without each one haveing to pull it, restart, delete peers.dat, etc just like the qt. You manually propagate a known good chain to all of your nodes so they can share it, and also so you don't have to fight like a bitch to get them all to pull on their own. Now all of your masternodes are sharing only known good chaindata.

Getting miners and pools to update will stop the monkeywrenching...
 
Last edited by a moderator:
All 3 of my p2pool nodes are up and running on Darkcoin Core version 11.00.07 with no issues!

Great job guys, now if I could only get the Windows 64 Bit wallet to work for my cold storage then I could call it a complete success. I had to fall back to using the 32 bit client to get the thing to synch and not shutdown.
 
My DRK client now also got stuck at some block (don't exactly know which one). This was right after a DS Tx, so this DS Tx has was shown as unconfirmed.
I looked for the TxID on an actual up to date chain but it was not there o_O
I let it -rescan the wallet which did not help.
I then deleted the blockchain and let it redownload the blockchain, which helped to get back up to date with the chain. However, since the Tx never made it into the blockchain, it was still shown as unconfirmed.
I waiting a bit longer so my client could rebroadcast the Tx. However, I eventually gave up after a few hours and did a -zapwallettxes.
After rescanning, the Tx in question was gone. Idk how it got there and why it didn't confirm. Maybe one of the DS participants did a double spend. however, this would probably have been recognized by my client.
We need some validation for Txs that behave like this so they can get automatically removed by the client if they are no longer valid.
 
My client has been stuck for 2 days. (At first it was mixing very well.) I had tried zapping the wallet several times over those 2 days. Today, it picked up and started mixing again. Yay!

Meanwhile, I loaded the Mac Client for the first time ever. Looks good, thanks devs! The question I have is regarding the "receive" addresses. After I created several, it seems there is no way to edit, the label or message. Am I missing something here? Thanks!

(Now I checked on my Windows (32) on XP. It seems to be the same way. I remember in the past these were editable.) Can someone confirm this feature is unavailable now? Thanks!
 
paperThin said:
My client has been stuck for 2 days. (At first it was mixing very well.) I had tried zapping the wallet several times over those 2 days. Today, it picked up and started mixing again. Yay!

Meanwhile, I loaded the Mac Client for the first time ever. Looks good, thanks devs! The question I have is regarding the "receive" addresses. After I created several, it seems there is no way to edit, the label or message. Am I missing something here? Thanks!

(Now I checked on my Windows (32) on XP. It seems to be the same way. I remember in the past these were editable.) Can someone confirm this feature is unavailable now? Thanks!
Click to expand...

Just double-click on an existing address.
 
crowning said:
Just double-click on an existing address.
Click to expand...
No dice. not in Mac nor in XP. I have a value of zero coins in those addresses. Do you think that could be a factor? I added 2 addresses to the wallet. I did not add any message nor label when they were created. They read (no message) and (no label). Am I missing something?
 
paperThin said:
No dice. not in Mac nor in XP. I have a value of zero coins in those addresses. Do you think that could be a factor? I added 2 addresses to the wallet. I did not add any message nor label when they were created. They read (no message) and (no label). Am I missing something?
Click to expand...
Go to "File" -> "Receiving addresses..." and then
crowning said:
Just double-click on an existing address.
Click to expand...
:grin:
 
You must log in or register to reply here.
Back
Top