v0.11.0 - Darkcoin Core Release

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,895
6,723
1,283
My wallet is stuck with block 204572, i have done total chain redownload and zapwallettxes, no help, its stuck.
Oveview tab shows its 100% update, but debug info show block 204572, no any movement.
same here
i have a transfer come in and it is stuck on
5 confirmations
and
Block 204572
(since an hours or so)
 
  • Like
Reactions: GilAlexander

jpr

Active Member
May 11, 2014
493
393
133
Masternodes stuck on 204572. ./darkcoind getinfo gives a message
"errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."
 
  • Like
Reactions: GilAlexander

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,895
6,723
1,283
All my Masternodes report the same....the only wallet which works right now is a (self-build) v0.11.0.7 wallet.
can I go back to the old (last before 11) wallet just to make sure my transfer gets in ?

or just wait ?
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,335
571
283
Finland
Still my wallet is stuck in block 204572, all my masternodes same, stuck.
Current block is 204645.

{
"version" : 110006,
"protocolversion" : 70052,
"walletversion" : 61000,
"balance" : 0.00000000,
"darksend_balance" : 0.00000000,
"blocks" : 204572,
"timeoffset" : 0,
"connections" : 19,
"proxy" : "",
"difficulty" : 4083.62714253,
"testnet" : false,
"keypoololdest" : 1421345330,
"keypoolsize" : 1001,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."
}
 

splawik21

Grizzled Member
Dash Core Team
Moderator
Foundation Member
Dash Support Group
Apr 8, 2014
1,923
1,280
1,283
doing the same, let you know in ~25 min ;)
 

feeleep

New Member
Oct 18, 2014
29
33
13
something is wrong with this version: I updated wallet on my pool and found blocks were rejected by deamon. I had to revert to previous version. Unfortunately I dont have debug.log file but there were messages that masternode payee cannot be found...
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
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.
 
Last edited by a moderator:

Aswan

Member
Jun 26, 2014
68
216
73
Interesting.

Look at this DS Tx: d6837f60aa13bfe02b9feea8509a1a96904927f7569cc29f29e45906291f87df

It has an Input of 227.47499967 DRK and am output of 227.47499967 DRK. Seems like the coins haven't been mixed at all, yet they appear in a DS Tx and bloat the chain o_O
 

GilAlexander

Member
Jun 26, 2014
84
23
48
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:

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
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.
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:
 

Aswan

Member
Jun 26, 2014
68
216
73
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 :)
 

GilAlexander

Member
Jun 26, 2014
84
23
48
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?
 

crowning

Well-known Member
May 29, 2014
1,415
1,997
183
Alpha Centauri Bc
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.
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 :D
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
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 :)
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 :)
 

Aswan

Member
Jun 26, 2014
68
216
73
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 :)
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 =/
 
  • Like
Reactions: moli