Small request...

[camosoul]

When one uses coin control to explicitly select dust/change that has not been denominated, and send it to a single, larger chunk such that it may get denominated, it'd be nice if the darksend check box would remove itself... Obviously I won't be darksending stuff that isn't denominated...

To say it another way, make the darksend check box "smart" in accordance with coin control selection.

 

[moli]

When one uses coin control to explicitly select dust/change that has not been denominated, and send it to a single, larger chunk such that it may get denominated, it'd be nice if the darksend check box would remove itself... Obviously I won't be darksending stuff that isn't denominated...

To say it another way, make the darksend check box "smart" in accordance with coin control selection.

Wondering if this could be done... UdjinM6 ?

 

[camosoul]

To add to this... As we push for more acceptance, the DARKSEND controls "Reset Darksend" and "Try mix" could be relegated to a setting checkbox, much like coin control can be turned on and off...

Advanced coin controls can be hidden, why not the advanced darksend controls? Just makes sense to me...

Perhaps the entire button thing could be removed and it just starts mixing by default while advising the operator of this fact.

I should note that my clients STILL stall frequently. They just stop all comms and stop pulling blocks for no apparent reason every 24 to 48 hours. If storing peers in peers.dat results in the use of peers that fail, uh, why not just stop having a peers.dat? I'm only going to delete it and make it start over anyway, so, uh, why not just do that by default by not having a peers.dat to begin with?

Darksend freezes because the last denom never appears as confirmed. This, due to the halt of all comms resulting in receiving no more blocks. No more comms == no more blocks == darksend stops mixing because no more confirms. Close client, delete peers.dat, restart client, it instantly starts pulling blocks again, confirms, hit the button, starts denoming again... So, if all I'm ever going to do with peers.dat is delete it to make it work again, why not just not have the damn thing? All it does it gum up the works and get deleted anyway... my command line for running the client is:

"rm peers.dat && ./dash-qt --litemode & tail -f debug.log" litemode because mn hot wallet and don't want to forget and click mix button... litemode == no mix button to human and mess up my 1000 inputs...

Since this problem is not affected by any of the darksend control buttons, they serve no use for this issue, and this issue should not preclude their move to a "check mark to enable" type feature such as coin control. So why ramble about it? PEople might see this bug as a need for the buttons since it is a mix problem on the surface. But the mixing fail is just a symptom of the no-reason comm blackout, and this, not actually related.

 

[TaoOfSatoshi]

Yes, the peers.dat issue has to be refined before we release version 1.0.0, for sure.

 

[camosoul]

Yes, the peers.dat issue has to be refined before we release version 1.0.0, for sure.

In the name of science, I don't know for certain that is it data stored in peers.dat that is causing the comms blackout. IT may still ahppen and be rectified by a restart without peers.dat, but since I don't have a control method against which to test that ( I don't have a cleint that is identical with the exception of not storing any peers data), I have to leave the matter as unproven, but there is an inference that they are related.

I can prove the converse, by restarting the client without deleting peers.dat, and ,sometimes, it slowly starts pulling blocks. But deleting peers.dat makes it instantly haul ass every time, no maybes.

There's definitely something to it. It's probably not even the file itself. There's probably just some poison nodes. But getting rid of them without having to delete a file would really help the barely-human neophytes who have never seen a command prompt and are afraid to touch file management.

At the least, this file should be deleted upon startup by default. I realize it's meant to act as a cache. But, there's still two ways to look at that. It can still be an ACTIVE cache, but not be a persistent session-to-session cache. Delete on exit? No, because client might crash and not get deleted. Build in a deletion of peers.dat into the startup sequence. Most sane people can do that, but we've already saturated sane people. This needs to be done for people who can't do anything for themselves. Besides, telling someone "Oh, yeah, it's busted if you don't do this constant nonsense file maintenance" does the opposite for instilling confidence...

We could partly band-aid the issue by simply having the client delete the file on every startup. It never hurts performance to do that, and always fixes the problem with flying colors. Then, of course, it still eventually fails, so we really haven't come to the root of a true fix. But it makes the work around less stupid looking...

"Restart" is not an uncommon "fix" for people running Windows and Mac... They'll write it off no different from any other time they have to do that because Commercial OS sucks. In this case, it won't be true, but they never pay enough attention to know the difference, and it's fixed without putting a bunch of "OK, totally clueless moron, dig around in your filesystem and be really careful not to fuck up or you lose all your money!"

Isn't it better just to tell them to restart the client? Hell, they won't even listen to that and they'll restart the whole damn computer... Let it fix itself.

 

[TaoOfSatoshi]

In the name of science, I don't know for certain that is it data stored in peers.dat that is causing the comms blackout. IT may still ahppen and be rectified by a restart without peers.dat, but since I don't have a control method against which to test that ( I don't have a cleint that is identical with the exception of not storing any peers data), I have to leave the matter as unproven, but there is an inference that they are related.

I can prove the converse, by restarting the client without deleting peers.dat, and ,sometimes, it slowly starts pulling blocks. But deleting peers.dat makes it instantly haul ass every time, no maybes.

There's definitely something to it. It's probably not even the file itself. There's probably just some poison nodes. But getting rid of them without having to delete a file would really help the barely-human neophytes who have never seen a command prompt and are afraid to touch file management.

At the least, this file should be deleted upon startup by default. I realize it's meant to act as a cache. But, there's still two ways to look at that. It can still be an ACTIVE cache, but not be a persistent session-to-session cache. Delete on exit? No, because client might crash and not get deleted. Build in a deletion of peers.dat into the startup sequence. Most sane people can do that, but we've already saturated sane people. This needs to be done for people who can't do anything for themselves. Besides, telling someone "Oh, yeah, it's busted if you don't do this constant nonsense file maintenance" does the opposite for instilling confidence...

We could partly band-aid the issue by simply having the client delete the file on every startup. It never hurts performance to do that, and always fixes the problem with flying colors. Then, of course, it still eventually fails, so we really haven't come to the root of a true fix. But it makes the work around less stupid looking...

"Restart" is not an uncommon "fix" for people running Windows and Mac... They'll write it off no different from any other time they have to do that because Commercial OS sucks. In this case, it won't be true, but they never pay enough attention to know the difference, and it's fixed without putting a bunch of "OK, totally clueless moron, dig around in your filesystem and be really careful not to fuck up or you lose all your money!"

Isn't it better just to tell them to restart the client? Hell, they won't even listen to that and they'll restart the whole damn computer... Let it fix itself.

...or maybe I should make "TAO'S DELETE PEERS.DAT GUIDE FOR DUMMIES".

You would like that, wouldn't you Camo? :wink:

 

[crowning]

When one uses coin control to explicitly select dust/change that has not been denominated, and send it to a single, larger chunk such that it may get denominated, it'd be nice if the darksend check box would remove itself... Obviously I won't be darksending stuff that isn't denominated...

To say it another way, make the darksend check box "smart" in accordance with coin control selection.

Wondering if this could be done... UdjinM6 ?

Technically it can be done when you're in the Coin-Control dialogue, but it wouldn't make sense to have it _only_ there.
I have to check how this (disable Darksend checkbox when either there are no denominated funds available or dust/change only) can be done in general.

Not sure if the efforts would be worth the gain, though...

 

[crowning]

At the least, this file should be deleted upon startup by default. I realize it's meant to act as a cache. But, there's still two ways to look at that. It can still be an ACTIVE cache, but not be a persistent session-to-session cache. Delete on exit? No, because client might crash and not get deleted. Build in a deletion of peers.dat into the startup sequence.

The funny thing is it's ONLY read at startup, so if we would delete it we could get rid of it anyway...would be interesting how many users actually have problems with peers.dat.

 

[UdjinM6]

When one uses coin control to explicitly select dust/change that has not been denominated, and send it to a single, larger chunk such that it may get denominated, it'd be nice if the darksend check box would remove itself... Obviously I won't be darksending stuff that isn't denominated...

To say it another way, make the darksend check box "smart" in accordance with coin control selection.

It is smart already but in the other way - it will try to darksend only denominated inputs ignoring anything that is not yet denominated i.e. it's "DS checkbox" who controls inputs from the CoinControl not the CoinControl who controls the "DS checkbox".

To add to this... As we push for more acceptance, the DARKSEND controls "Reset Darksend" and "Try mix" could be relegated to a setting checkbox, much like coin control can be turned on and off...

Advanced coin controls can be hidden, why not the advanced darksend controls? Just makes sense to me...

Perhaps the entire button thing could be removed and it just starts mixing by default while advising the operator of this fact.

I should note that my clients STILL stall frequently. They just stop all comms and stop pulling blocks for no apparent reason every 24 to 48 hours. If storing peers in peers.dat results in the use of peers that fail, uh, why not just stop having a peers.dat? I'm only going to delete it and make it start over anyway, so, uh, why not just do that by default by not having a peers.dat to begin with?

Darksend freezes because the last denom never appears as confirmed. This, due to the halt of all comms resulting in receiving no more blocks. No more comms == no more blocks == darksend stops mixing because no more confirms. Close client, delete peers.dat, restart client, it instantly starts pulling blocks again, confirms, hit the button, starts denoming again... So, if all I'm ever going to do with peers.dat is delete it to make it work again, why not just not have the damn thing? All it does it gum up the works and get deleted anyway... my command line for running the client is:

"rm peers.dat && ./dash-qt --litemode & tail -f debug.log" litemode because mn hot wallet and don't want to forget and click mix button... litemode == no mix button to human and mess up my 1000 inputs...

Since this problem is not affected by any of the darksend control buttons, they serve no use for this issue, and this issue should not preclude their move to a "check mark to enable" type feature such as coin control. So why ramble about it? PEople might see this bug as a need for the buttons since it is a mix problem on the surface. But the mixing fail is just a symptom of the no-reason comm blackout, and this, not actually related.

I agree about "Try Mix" and "Resend Darksend" buttons, they should be moved under some advanced settings checkbox.

Yes, I have this issues (when wallet stops to receive blocks sometimes) too but it has nothing to do with peers.dat on my side - the problem is with "block" message propagation itself - some blocks do not arrive on time and block index do not rebuild itself, not sure why yet.

 

[camosoul]

the problem is with "block" message propagation itself - some blocks do not arrive on time and block index do not rebuild itself, not sure why yet.

Ah, so restarting the client should fix that whether peers.dat is deleted or not. My experiments have shown 100% unanimously that there is still a difference in behavior tho. If I do not delete peers.dat after a comms halt, it will very slowly, sometimes, pull blocks again after a client restart. If I do delete peers.dat, it's instantaneous perfection after a restart. Maybe it's a combination of problems.

I always look to the artificial generation of a problem by a nefarious entity, because it's a top-down approach. Even if that's not true, you'll find the issue if you start at the top instead of skipping over potential issues because you don't want to seem paranoid.

Many a time, especially since I've become a target of the guvtrash, I've spent days trying to solve what should be a simple issue, only to find out that it was caused by guvtrash doing a sloppy job of spying or sabotaging... It's become my go-to theory now. Even when not true, it saves a lot of headache...

The funny thing is it's ONLY read at startup, so if we would delete it we could get rid of it anyway...would be interesting how many users actually have problems with peers.dat.

I watch it change size as the client runs, so it has to be at least written at some point. Where does it come from in the first place? Why does it keep getting bigger?

What UdjinM6 said suggests that the "peers.dat problem" is actually a symptom of something else simply getting stored by a peer cache system that is in fact working as it should so no reason to mess with it.

With a masternode system in place, it seems to me the whole mechanism is vestigial. Regardless of whether it's causing a problem or not, why are we still dragging along this dead weight?

 

[camosoul]

You would like that, wouldn't you Camo? :wink:

Crypto can never have enough lazy, entitled retards...

 

[camosoul]

It is smart already but in the other way - it will try to darksend only denominated inputs ignoring anything that is not yet denominated i.e. it's "DS checkbox" who controls inputs from the CoinControl not the CoinControl who controls the "DS checkbox".

I see your point, but I was suggesting the opposite form of smart be implemented for precisely that reason. If I have gone to the trouble of enabling coin control, then deliberately selecting non-denominated outputs, darksend should uncheck itself because duh. Why make me go to an extra click when it is already obvious that I don't wanna do darksend?

I agree about "Try Mix" and "Resend Darksend" buttons, they should be moved under some advanced settings checkbox.

I suggest that the whole thing, even the "start denoming" button, be moved to "checkbox to enable" and simply have an advisory message letting the lUser know what's going on. It gives a tutorial experience and multi-layered approach to introducing the concept of Denoming and Masternodes to lUsers. They can learn about it through the explanation messages before having to be in control of a thing they have no idea was even there or why or how... "Oh, cool, it's mixing my coins. Masternodes are doing it? Oh, cool, a 2-tier network that's already working for me, that's a major advancement none of the clone-coins have..."

 

[UdjinM6]

I watch it change size as the client runs, so it has to be at least written at some point. Where does it come from in the first place? Why does it keep getting bigger?

Wallet reads peers.dat on start and then it flushes peers list to disk every N minutes.

I see your point, but I was suggesting the opposite form of smart be implemented for precisely that reason. If I have gone to the trouble of enabling coin control, then deliberately selecting non-denominated outputs, darksend should uncheck itself because duh. Why make me go to an extra click when it is already obvious that I don't wanna do darksend?

Yes, I see... Maybe you're right about that one and that would be more intuitive behavior...

I suggest that the whole thing, even the "start denoming" button, be moved to "checkbox to enable" and simply have an advisory message letting the lUser know what's going on. It gives a tutorial experience and multi-layered approach to introducing the concept of Denoming and Masternodes to lUsers. They can learn about it through the explanation messages before having to be in control of a thing they have no idea was even there or why or how... "Oh, cool, it's mixing my coins. Masternodes are doing it? Oh, cool, a 2-tier network that's already working for me, that's a major advancement none of the clone-coins have..."

I see your point but to start mixing you need to unlock wallet somehow anyway so there should be some "Start" button to initiate the process (ask user for his passphrase) imo.

 

[camosoul]

I see your point but to start mixing you need to unlock wallet somehow anyway so there should be some "Start" button to initiate the process (ask user for his passphrase) imo.

Ah, yeah. I don't do encrypted wallets. Forgot about that.

I'm fully informed of the associated risks as well as the benefits.

Bottom line is that it needs to be simplified and have some tool-tip explanations, or maybe a "what's this?" approach, so the answers and explanations come one piece at a time, as they do it.

I'm sure my original idea and be merged with keeping that one button up there. "Why am I clicking this button? What's it doing? Why do I care?"

Might even take it to the next level... Have the interface be tutorial-oriented to begin with. Have the ability to shut that off.

Ever play Eve Online? Ridiculously complex and difficult game. It has a tutorial mode to help newcomers that works a lot like what I've described, or they'd lose almost all of their potential customers after spending all that advertising budget to pull them in. See where I'm going with this? Even if we spend a ton of money and resources promoting, we run them off as soon as they get here...

They're stupid. Catering to that stupidity doesn't solve the problem. We need to educate the stupidity in a way it can handle, so that the stupid goes away. That person will then educate their friends, and their friends, etc...

Before someone tries to troll on it; idiots on client and idiots on MN are not even close to the same thing. One should be educated, the other discouraged.

 

[camosoul]

Wallet reads peers.dat on start and then it flushes peers list to disk every N minutes.

In networks that don't have high-availability nodes, I can see the use of this.

In DASH, isn't this vestigial? We haz MNs. High-availability. Do we really need a peer node cache in this environment?

Even if it has nothing at all to do with the blocktime comms freeze issue, isn't it something we could lose?

 

[UdjinM6]

In networks that don't have high-availability nodes, I can see the use of this.

In DASH, isn't this vestigial? We haz MNs. High-availability. Do we really need a peer node cache in this environment?

Even if it has nothing at all to do with the blocktime comms freeze issue, isn't it something we could lose?

There's a lot of low level network specific functionality connected to peers.dat info afaik. And I guess it would be better to find a way not to drop it but to use mncache.dat (mn ip list) info to provide peers.dat some additional info and/or give MN nodes higher priorities or smth like that. I need to read through the code it's related to (i'm not so familiar with it) before I can answer more detailed...

 

[camosoul]

There's a lot of low level network specific functionality connected to peers.dat info afaik.

Perhaps, getting info for who to listen to for blocks, and then listening forever when getting no response thus making it halt comms and stall?

And I guess it would be better to find a way not to drop it but to use mncache.dat (mn ip list) info to provide peers.dat some additional info and/or give MN nodes higher priorities or smth like that. I need to read through the code it's related to (i'm not so familiar with it) before I can answer more detailed...

Couldn't there be a "not write it to disk at all" option? I realize it's old code pulled over from BTC and largely untouched... But even this seems like it's still just hanging around because RAM is a scary place... Why even bother to write such dynamic data to disk in the first place? As far as RAM usage goes, the whole MN list doesn't take up 1MB...

mncache.dat does make sense because it's largely static. Switching those dependencies to that instead of peers.dat would make more sense. Why remain dependent upon the derps when we can pick a source whose whole point was to be better than that... MNs are supposed to make the network better, this is just another way they can do that.

I still think this isn't being as good as it could be. I'm not the boss tho, so if it at least works... I'm a perfectionist, so please don't take it as an insult or a criticism. It seems that establishing good IX locks would be bettered by deliberately NOT using cached data that may be stale or dead. Whatever it pings first and responds, there we go that's the most responsive so that's what we use... Makes IX more reliable.

Anyway, check mark for buttons!