v0.10.15 - Onyx Release

By then we hopefully will have reached a point at which hard-forking has become practically impossible. Look at bitcoin. The broader the user base gets and the more mainstream and "non-enthusiast" we go, the harder managing a hard-fork becomes.
 
I'm not sure how it would be done but I do think there is some merit in having at least a portion of the masternode coins available to mix with other users when others are not mixing. It seems we are running into the case of slow downs on mainnet because not enough people are mixing at the same time to pair with. I don't know if there is a way to say >1000 coins in the wallet/addresses to secure the masternode and to have it appear on the masternode list but use maybe 200-300 coins to pair out. This might mean it would only take 700-800 dark to "secure" a node with the remainder to 1000 being used to darksend with others. However, the 700-800 isn't enough by itself to appear on the list, the wallet would need to have 1000 or more coins. Because darkcoin knows the change addresses, it could count the total coins and know whether there is 1k sitting there to keep the node on the list, no?

Just an idea. I figured looking into this again could help solve issues with end-users unable to find pairs on a network that clearly has the coins sitting there.
 
The other idea I had was a dedicated wallet for people wanting to provide continuous pairings to darksend. Basically, it would be built off the existing wallet, but any coins sent to addresses in that client would automatically go through the darksend process 8 rounds. After anon'ing all the coins, the whole balance is automatically sent to a fresh address in the wallet where the process begins again. That way, there is always denominations out there for people to pair with. I don't know about you guys, but I would have no problem sending some DRK to a specialized wallet to help the network (at least as a intermediate step until I accumulate 1000 coin chunks to continue setting up masternodes). Logistics of the whole thing still to be determined.

Again, just ideas. Obviously I want the darksend process to be as easy as possible and to work when people want it to work.
 
oblox said:
The other idea I had was a dedicated wallet for people wanting to provide continuous pairings to darksend. Basically, it would be built off the existing wallet, but any coins sent to addresses in that client would automatically go through the darksend process 8 rounds. After anon'ing all the coins, the whole balance is automatically sent to a fresh address in the wallet where the process begins again. That way, there is always denominations out there for people to pair with. I don't know about you guys, but I would have no problem sending some DRK to a specialized wallet to help the network (at least as a intermediate step until I accumulate 1000 coin chunks to continue setting up masternodes). Logistics of the whole thing still to be determined.

Again, just ideas. Obviously I want the darksend process to be as easy as possible and to work when people want it to work.
Click to expand...
I'm thinking of multiple obfuscated IPs we're mixing .. but i have to log off now, ttyl..
 
93.4% of the masternodes are 0.10.15.13 now. However, I am stilling getting disconnected like others reported. Should we see the enforcement soon with that many adoptions? I'm worrying if there is another exploit. drk.mn reports it is a few percent active after its upgrade to 0.10.15.13 while poolhash reports inactive. But, grep from masternode list says 1 instead of 0. The grep returns 0 when all monitoring nodes (i.e. both drk.mn and poolhash) give inactive status.

Is there any tcp port should be open to keep this active? Or, anything that I should pay attention to.
 
Good thinking oblox. I'm having this exact issues at the moment. I've never used DS on main net yet but thought I'd give it a go with some coins over the weekend. Sadly, nothing seems to be happening! It's a brand new clean wallet with the lasted daemon so there shouldn't be a problem. All I can put it down to is lack of 'liquidity' for the mixing service.
 
GermanRed+ said:
93.4% of the masternodes are 0.10.15.13 now. However, I am stilling getting disconnected like others reported. Should we see the enforcement soon with that many adoptions? I'm worrying if there is another exploit. drk.mn reports it is a few percent active after its upgrade to 0.10.15.13 while poolhash reports inactive. But, grep from masternode list says 1 instead of 0. The grep returns 0 when all monitoring nodes (i.e. both drk.mn and poolhash) give inactive status.

Is there any tcp port should be open to keep this active? Or, anything that I should pay attention to.
Click to expand...

One of my MN's dropped over earlier today. Had to restart it. wasn't anything to do with my set up (i have two running on the same VPS) so the network must have got grumpy with it for some reason.
 
oblox said:
The other idea I had was a dedicated wallet for people wanting to provide continuous pairings to darksend. Basically, it would be built off the existing wallet, but any coins sent to addresses in that client would automatically go through the darksend process 8 rounds. After anon'ing all the coins, the whole balance is automatically sent to a fresh address in the wallet where the process begins again. That way, there is always denominations out there for people to pair with. I don't know about you guys, but I would have no problem sending some DRK to a specialized wallet to help the network (at least as a intermediate step until I accumulate 1000 coin chunks to continue setting up masternodes). Logistics of the whole thing still to be determined.

Again, just ideas. Obviously I want the darksend process to be as easy as possible and to work when people want it to work.
Click to expand...

Maybe an administered MN sharing pool.. say 50 or 100 MNs, all or most of which coins are constantly mixing
 
Walter said:
One of my MN's dropped over earlier today. Had to restart it. wasn't anything to do with my set up (i have two running on the same VPS) so the network must have got grumpy with it for some reason.
Click to expand...

Mine was dropped multiple times in the past 8 hours or less. Is there any way to debug this? I tried to run masternode debug but I don't know how to use it. It only returns "successfully started masternode" which has nothing to do with debug. I had masternode started already before the debug command. It is really weird to see returned message are unrelated nonsense.
 
When we get wafflepool, trademybit, and miningpoolhub updated, we will be around 85% on Onyx. I doubt you will be seeing nodes kick offline (I had to start 3 this morning as well). Conflicting masternode lists on two different protocols I'm sure isn't helping the stability of the MN's.
 
Walter said:
One of my MN's dropped over earlier today. Had to restart it. wasn't anything to do with my set up (i have two running on the same VPS) so the network must have got grumpy with it for some reason.
Click to expand...
Unless your MN itself reported '<IP>:0' when you ran 'masternode list | grep <IP>' on it, I don't think there is any point to restarting it. I certainly wouldn't bother because some other MN (eg one of chaeplin's or elbereth's) temporarily reported it as ':0' due to network issues. I've had MNs completely missing from chaeplin's site for example, which still got paid because the pool or whatever could see them when chaeplin's MNs didn't at the time.

Version bumps on testnet have always kicked off older versions instantly, not sure what's different here, or why it needs to be different?

Speaking as a numpty who doesn't understand a whole lot, I think enforcement should be instant upon version release. Support the network or lose out. Delaying everything by weeks doesn't seem to offer much advantage to my untrained eye.
 
We dont have 93% yet it is the sum of unknown and 0.10.15.13 nodes so it is ~65% now.

My MNs ~37% out of 100% get disconnected couple times a day but i dont do anything after a while they became active again...
 
Walter said:
One of my MN's dropped over earlier today. Had to restart it. wasn't anything to do with my set up (i have two running on the same VPS) so the network must have got grumpy with it for some reason.
Click to expand...
I have two MN:s dropped offline today, other MN:s ok.
Drknet is strugling with many different versions...
 
splawik21 said:
We dont have 93% yet it is the sum of unknown and 0.10.15.13 nodes so it is ~65% now.

My MNs ~37% out of 100% get disconnected couple times a day but i dont do anything after a while they became active again...
Click to expand...
They are not getting disconnected at all, it's just that whatever client you are running the search from has received recent bad information from other deprecated clients. Or something like that. I think. :confused:
 
AjM said:
I have two MN:s dropped offline today, other MN:s ok.
Drknet is strugling with many different versions...
Click to expand...
Try to delete peers.dat - it may contain old v14 peers. After restart the peer will get v15 peers from the dnsseeder to connect to.
 
flare said:
Try to delete peers.dat - it may contain old v14 peers. After restart the peer will get v15 peers from the dnsseeder to connect to.
Click to expand...
Yep, i always delete peers.dat when upgrading darkcoind.
Last time was oct 16 when onyx was puplished.
 
flare said:
Try to delete peers.dat - it may contain old v14 peers. After restart the peer will get v15 peers from the dnsseeder to connect to.
Click to expand...
I will try this and let you guys know....
 
AjM said:
Yep, i always delete peers.dat when upgrading darkcoind.
Last time was oct 16 when onyx was puplished.
Click to expand...
Yeah, but dnsseeder was updated on 17th, so your fresh updated darkcoind got provided with outdated peers and the more these updated your peer got orphaned and dropped of the network.

Nevertheless i agree: the update behaviour has to be improved. As i see it problem is that protocolversion field is used as version identifier for two networks: darkcoin and masternode. This seems to not work out in case of network wide major updates.
 
You must log in or register to reply here.
Back
Top