 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
You should call it V4 or V3.1 since the version "V3" I downloaded before didn't work and people already has it.
thanks anyway.. I will send some eth. once I'll mine :-)
well if i would go that way this version would be v1000, cause i make small changes all the time. Maybe i can go like V3.01 , V3.02 etc Use semantic versioning. MAJOR.MINOR.PATCH One could argue that adding a bios is a "bug fix" so you would go like this 3.0.1 3.0.2 3.0.3 3.0.4 3.0.1000 If you add a new backwards compatible feature increment the middle number 3.1.0 If you add a major, possibly backward compatibility breaking feature, increment the first number 4.0.0 Lookup semantic versioning for more info on how to use it. It's pretty simple and makes things very straight forward for the end user when deciding which version they want to use. |
|
|
|
|
I agree 100%. The only reason I reported this in the first place was to make the team aware of the issue so they could catalog it and decide if/when it needs to be fixed. It's hardly a critical issue, but it is a bug and I wanted to let the team know about it. Sounds like others have noticed too, but since it's not really a critical issue most of us just work around it.
|
|
|
|
i have the same issue as bret regarding "Clear Orphans" function. Exactly same as bret described it, although only other effect is i dont seem to get another stake until i restart the wallet. Restarting the wallet fixes it all. Also my wallet is not at all starved of resources except for bandwidth maybe.
EDIT: orphans are rare but they do happen for me.
This is exactly what happens to me. I don't see any more stakes (or possibly any transactions at all) when I use the "Clear Orphans" function. I haven't really looked too much into it but I can tell I stop staking and appear to stop syncing entirely after I run "Clear Orphans". Again, a wallet restart appears to fix everything, but it's kind of a habit for me to clear orphans every once in a while. |
|
|
|
|
Thanks for following up on this, appreciated.
My wallet is very old. But since I deleted the debug log a few weeks back, the log has only grown to 192KB, which is a good sign. I've had my wallet running almost continuously for years, not always staking, but always running. Lately I have been continuously staking just to see what happens. In the past I wouldn't stake as much.
My wallet probably does need consolidating. I suppose I could setup another virtual machine with a fresh wallet, split the coins evenly over an appropriate number of addresses. But how does that effect my staking, won't I be starting over? Is it really impacting the network that bad if I continuously stake and don't consolidate?
If that is the case, then at some point wouldn't it be a good idea to put a feature in the wallet to clean itself up? There could be people out there who are staking constantly and don't read the forums.
|
|
|
|
|
I definitely starve the wallet's resources. I run the wallet inside a virtual machine to prevent it from eating up all my resources and slowing down my machine (among many other reasons, like no usable mac version last I tried). The wallet tries to eat up all my RAM and CPU and I have plenty of it (16GB RAM and late model Core i7).
I am sure running inside a virtual machine is also causing it to have trouble finding peers. But honestly, I get a healthy stake and never have trouble syncing the wallet, usually syncs within a seconds of launch unless it has days worth of catching up to do.
The virtual machine could be why I am getting orphans. These are the same conditions I ran all the previous wallet versions under, which also produced orphans, but clearing them never caused an issue in the past. But I have no plans to remove the wallet from it's sandbox as long as it continues to be extremely resource hungry. I would rather starve it and get orphans than slow down everything else.
Anyway, I know the bug exists, I've tried it under fresh OS installs, after wallet restarts, etc and any time there are orphans to be cleared it glitches now. I've been dealing with the orphan problem for probably 12-18 months and never had the overview page glitch prior to this update. It's not a huge deal, easy to fix / workaround, but I can assure you the issue is present and seemingly unrelated to my particular setup. If you are not generating orphans than you would not be able to reproduce it.
Seems to me for every orphan you have staked, it hides a real transaction on the overview page when you clear them. Since it shows 4 transactions by default, if you have 4 orphans then they all get turned into [0.00] on the overview page. I think the case when I see only 1 or 2 changing to [0.00] is when I have only 1 or 2 orphans.
But like I said, I'm not too worried about fixing the orphan problem, I get plenty of UTC from staking and if I am missing out on a few a day I am fine with that. Just annoying when I clear the orphans then have to restart the wallet because I don't always remember to turn staking back on.
|
|
|
|
|
Ok, so it looks like the ones that are replaced with [0.00] might be actual orphans. When I perform clear orphans right after I open and re-sync the wallet everything is fine (no transactions are replaced with [0.00]).
So what I think is happening is that I am collecting orphans from staking and when I clear them something glitches and it removes the orphans but does not replace them with real transactions it just leaves my overview screen empty.
I am also fairly certain staking stops working when this happens. It may be because the wallet stops syncing or something else, but I left the wallet running for 30 minutes after it glitched and when I restarted it I was about 30 minutes behind.
|
|
|
|
Ultracoin QT Wallet 1.0.0.0 (Windows)
Found a bug. When I am in Overview then switch to Transactions and right click to Clear Orphans then switch back to Overview all my transactions show 0.00 with no address.
Switching between Overview to Transactions and back seems to be fine, but clearing orphans seems to clear everything out from them Overview section. This is the Windows version of the wallet.
Hi bret I have tried to replicate your issue on several machines (that were CPU mining and running synced wallet - so short on resources) - I can't. I run clear orphans function on Transactions - but all Transactions are still there with addresses etc? Were you doing this on a synced or unsynced wallet? I would just restart your wallet if the display issue persists after full sync. Cheers - usukan It's not a one-off thing. It happens to me every single time. Here are some pics to illustrate:     Sorry for all the blurring, I was over cautious on hiding potential private info. What usually happens is everything shows as [0.00] in the overview screen, sometimes I get the results of this particular screenshot where just some of my transactions are replaced with [0.00] in the overview screen, but the normal behavior is everything is changed to [0.00]. I found the only way to fix it was to restarted the wallet. It may be that this is related to staking? I have been staking here and there and usually that is when I need to clear orphans and when the problem happens. This is something new to 1.0.0.0 the previous wallets would not glitch when I cleared orphans. What else is odd is that once this happens, no further transactions show up until I quit and restart the wallet. |
|
|
|
|
Ultracoin QT Wallet 1.0.0.0 (Windows)
Found a bug. When I am in Overview then switch to Transactions and right click to Clear Orphans then switch back to Overview all my transactions show 0.00 with no address.
Switching between Overview to Transactions and back seems to be fine, but clearing orphans seems to clear everything out from them Overview section. This is the Windows version of the wallet.
|
|
|
|
Give up the ghost guys! Jesus!! Why would anyone want to buy this coin anymore? It's like Betamax trying to re launch now! You are way behind with no funds or dev. Don't waste 100's of hours of your time flogging a dead horse. Take your loss on your chin
Why would you tell anyone to drop interest in something they have passion about? Maybe you see this coin as dead, maybe others see this as an opportunity. Clearly the community still exists. Not sure how people discussing a coin you are no longer interested in concerns you or prompts you to such negative emotion. You can completely ignore this coin and go on with your life and vice versa. Thanks for the advice, but no thanks. If the coin was going to die it would have done so before the last hard fork. This is just the beginning for this coin, it has plenty of potential. Appreciate the trolling though, shows a lot about the quality of your character. |
|
|
|
|
In order for 2FA to work in QT the private keys would need to carry with them meta data about the 2FA which sounds like a nightmare. It would probably open up privacy concerns as it would be extremely easy to determine what keys are grouped into a wallet. You wouldn't need a central authority, but each private key would need the 2FA data associated with it so that the wallet could verify the 2FA code.
Wouldn't a strong password / pass phrase work just as well as 2FA for the wallet? That is really all 2FA protects you from, is weak / exposed passwords.
Correct me if I am wrong on any of the above points.
|
|
|
|
|
My debug.log was 17GB, any way I can keep that thing trimmed to say 500MB at most? Or should I use a 3rd party tool to handle log trimming? The only concern I have with a 3rd party utility is that the UltraCoin-QT program keeps the log file open constantly and I run into permission issues when I attempt to trim it.
Any suggestions other than shutting down the wallet, deleting the debug file and restarting the wallet (I'll never remember to do that).
|
|
|
|
I moved my miners away to zcash for the time being but I did try to break the current freeze earlier today for a couple of hours but it didn't happen.
But here's the thing. A block should have been found 91 times by now with the current difficulty as per the pool's stats but that didn't happen. Similar unlucky streaks happened a lot in the recent past.
At first I thought it was an issue with the pool but I solomined for about two hours but haven't find any blocks while I should have found blocks roughly about every 4 minutes based on the difficulty.
That's either some crazy variance or something's up - that I've never seen before.
Hi bathrobehero - yes the network is being spammed (either unintentional or not) with transactions with ridiculous amounts of inputs. The mempool is a beast with many horns. We are looking into a fix as I have mentioned in my PM to you just now. Cheers - usukan Would more hashing power help us? The short answer is no. Its not about hash power. bathrobehero has tried this yesterday with no success. It more about the pool and presstabs nodes/servers being spared from load of the excess spam transaction inputs and the associated data processing which is compromising the network. Alenevaa is looking into potential fixes and applying them. Cheers - usukan Isn't this a pretty serious vulnerability? A small group could cripple the network indefinitely. What are other devs doing to deal with something like this? Hi bret Not sure if you have noticed - but the network is up and running again. The spam transactions are still coming in but are being handled for now. There have been a number of tweaks made in the network to get us to the fork while we are still at the mercy of the old wallet and its shortcomings. Its important to note that once we get past the fork - its likely that the spam transactions that we are having now will not cause a problem because the block times will be regular/shorter because of efficient diff retargeting in the new wallet. The old wallet with massive diff swings and long blocks in high diff periods has exposed us to this vulnerability. Thats why we got PressTab to engineer a new wallet for us. The rules of the new wallet won't come ito play until after the fork. There are many vulnerabilities in every crypto - bitcoin can easily be spammed and often is to the point that the mempool grows, transactions are not included for very long periods and fees go up. Ethereum has been attacked for nearly 2 months now, multiple clients have been near impossible to sync and the network under serious stress at times - these guys have some of the brightest devs and lots of them - still took a long time to sort and will require 2 or more hardforks. Ultracoin is no different. There will always be a new challenge. I'm not a dev - so in laymans language I will try to explain things. First - if you know what the problem is - there is always a fix. It took us a few days to actually work out what the problem was here with UTC. UTC has been running for years and nothing like this had ever occurred before in my experience. Why all of a sudden from the 9th of October did someone start to send spammy transactions with 1000's of inputs in each block? These are all going to the largest UTC wallet that holds approx 25% of all UTC. So its unlikely this guy is trying to crash the network and destroy his value. So - there is pretty much a fix for anything we are presented with. Our approach in this particular situation is to apply softer fixes to get us past the fork point. If that does not work - we will need to apply deeper fixes. Deeper fixes could include issuing a new wallet with a sooner fork block and some other adjustments - or playing around with data limits in blocks via the wallet - and of course as PressTab mentions increasing fees. Problem is that fees won't really worry the guy currently sending the transactions. Almost every fix for this particular issue has drawbacks - since the new wallet is set up according to standard and accepted limits on block data size and has reasonable fees. If we play with these - there are negatives to consider. Take for instance if we alter the wallet/pool to allow smaller data in blocks. This would likely fix the current problem - but it may not be the best solution for the long term. This would apply to both POS and POW. This means that under normal operation less transactions/inputs can flow. This is not desirable because we want the wallet to handle short peaks of high load. It seems that the old wallet only gets us into trouble when the input load is high and sustained - during high diff/longer block times. So we would not be keen to issue a new wallet with lower maxdata limits for the long term use of UTC as this would compromise the max transaction rates. Considering that after the fork the new wallet will likely handle the current heavy load - we would be not keen to apply this fix for the short term unless we exhaust all other avenues. We would then likely have to fork back and we would annoy the hell out of BITTREX changing wallets all the time. Annoying BITTREX is not to be taken lightly. You can see now that the network is running all A OK right now with short block times. Transactions to the address receiving the multiple input transactions that were causing us trouble before are still continuing. I might add that these transactions have reduced inputs from over 400 to 100 (thanks if you have changed this Mr UXZCMmmsTjvW6bxsbbrL9vVaQmNHuWt56s) - and the most important thing is that short block times have reduced transactions to only a couple by both POW and POS. In summary - the sooner we can get to the fork and the new wallet rules come into play the better. In the meantime we will continue to tweak things under the old wallet environment to get to the fork and only escalate to deeper changes if its plainly obvious its absolutely required. Please note - you can expect further network disruptions until the fork block (if there are no changes in the frequency and nature of the spammy transactions) but we will endeavour to keep things moving as best we can. Cheers - usukan Thank you for the detailed and informative reply! This makes sense, hopefully the spamming is less after the fork. Until then we just have to see. |
|
|
|
I moved my miners away to zcash for the time being but I did try to break the current freeze earlier today for a couple of hours but it didn't happen.
But here's the thing. A block should have been found 91 times by now with the current difficulty as per the pool's stats but that didn't happen. Similar unlucky streaks happened a lot in the recent past.
At first I thought it was an issue with the pool but I solomined for about two hours but haven't find any blocks while I should have found blocks roughly about every 4 minutes based on the difficulty.
That's either some crazy variance or something's up - that I've never seen before.
Hi bathrobehero - yes the network is being spammed (either unintentional or not) with transactions with ridiculous amounts of inputs. The mempool is a beast with many horns. We are looking into a fix as I have mentioned in my PM to you just now. Cheers - usukan Would more hashing power help us? The short answer is no. Its not about hash power. bathrobehero has tried this yesterday with no success. It more about the pool and presstabs nodes/servers being spared from load of the excess spam transaction inputs and the associated data processing which is compromising the network. Alenevaa is looking into potential fixes and applying them. Cheers - usukan Isn't this a pretty serious vulnerability? A small group could cripple the network indefinitely. What are other devs doing to deal with something like this? |
|
|
|
I moved my miners away to zcash for the time being but I did try to break the current freeze earlier today for a couple of hours but it didn't happen.
But here's the thing. A block should have been found 91 times by now with the current difficulty as per the pool's stats but that didn't happen. Similar unlucky streaks happened a lot in the recent past.
At first I thought it was an issue with the pool but I solomined for about two hours but haven't find any blocks while I should have found blocks roughly about every 4 minutes based on the difficulty.
That's either some crazy variance or something's up - that I've never seen before.
Hi bathrobehero - yes the network is being spammed (either unintentional or not) with transactions with ridiculous amounts of inputs. The mempool is a beast with many horns. We are looking into a fix as I have mentioned in my PM to you just now. Cheers - usukan Would more hashing power help us? |
|
|
|
Hey there,
I've got some UTC. Do you know some casinos that accept ultracoin?
Cheers
Yes of course - BITTREX A lot of people gambled with their UTC over at Cryptsy.. but it's gone now :/ |
|
|
|
|
Where is all the hashing power coming from? Is it legit or is there still a glitch in the wallet?
The pools are showing a very small amount of hashing power on them (50Kh/s) while the network is showing 1.5Mh/s. Is there an unlisted pool running somewhere or is there one individual with a good amount of hashing power basically running the show on their own right now?
|
|
|
|
|
I'll take a guess.
Feb 14, 2017 @ 14:14:14 UTC
I donated 2500 to the pot as well.
|
|
|
|
is ultracoin death?
only devs have got ultracoins
Nope, we are many who hold  Cryptsy is a holder too. I know they have a few hundred thousand of my coins  |
|
|
|
I was just looking at the latest (current) retarget changes on github and I believe I found the issue with the retarget.
Firstly, there's
static const int64 nMaxAdjustDownV5 = 16; // 16% adjustment down
static const int64 nMaxAdjustUpV5 = 12; // 12% adjustment up
which means the diff can change as much as 16% down and 12% up which would be fine (I guess) but one problem is that this 16%/12% retarget happens every single block and it's always the maximum amount of change as far as I can see, not small changes.
Second problem is that once it overshots the difficulty and the blockchain stalls for like half a day and then finally a block is found, the difficulty won't decrease right away.
If I had to guess it's caused by this:
static const int64 nAveragingInterval5 = 240; // 240 blocks, 4 hours
which I'd guess means the difficulty average is based on the last 240 blocks meaning a bunch of super high (or super low) difficulty blocks has to be mined before the difficulty retarget starts adjusting - and when it does it overcompensates.
I might be completely wrong but I believe if the difficulty retarget wouldn't happen every single block, but maybe every 10 blocks or so then everything should be fine. Thoughts?
I'll take a look and see what I can do. When I do get a new wallet built, how do we get people to use it? |
|
|
|
I was bored so here's a basic visualization of the last 200 blocks (1635528-1635728) and the time between them (PoW+PoS together):  The first part of the graph is a flash mining period where the difficulty is way too low with 2-5 seconds between blocks and the spikes are when the difficulty is way too high. The highest time between two blocks being 7205 seconds or two hours. These 200 blocks were generated in 8.6 hours. The problem is the difficulty retarget is too slow to change (as in, it waits too many blocks before it changes and then it changes way to much) and it's predictable. Miners not mining during high difficulty periods (understandably so) make things worse. Someone needs to fix this issue who isn't rapture or Kracko and who will do it solely to benefit UTC as opposed to taking payments for it. I know I will be shouted down as a troll and my warnings and feedback ignored per usual. YAC is not solidly above UTC in marketcap. YAC never had a self-appointed "management team" who begged for donations to take trips to Vegas and Miami. There is a difference between good promotion and bad promotion btw. I could go on about the contradictory and wrong approach of centralized manipulation in crypto, but there is no point now to do that here. I want to say I have been right almost as much as rapture or Kracko has been wrong. However, it is really about being open-minded as opposed to this mentality of "I am the self-appointed leader, and it is my way or the highway." Pretty sure it is just UTC difficulty algo being too sensitive and 'correcting' too far either side of optimum. Things seem to get a lot more twitchy at these low low N15+ POW diffs. Also as a POS/POW hybrid adjusting teh difficulty is even more complicated as the POW diff is in feedback with the POS diff so that a weighting between the two is maintained. I don't feel like looking it up but I have a strong hunch that the YAC difficulty adjustment settings are not as sensitive so you will not see as much oscillation in difficulty if you are trying to compare the two coins.
Yeah, the Peercoin exponential retarget is much more precise. And of course, what scrypt-chacha folks are used to seeing behind a network rate. I definitely prefer the stability this retarget brings, but since it only uses the last two blocks it's vulnerable to time manipulation. Digishield can be oscillated more. It tends to overshoot a bit at the extremes. But while it swings more than before, the blocks still have an acceptable spacing over time. It appears to scale up nicely- Dogecoin doesn't appear to having any issues with it. I like the asymmetric rise/fall. Being able to correct downward faster than upward was a positive to making the coin more available to our dedicated miners by quickly recovering from those difficulty levels that leave the chain stuck. It's less affected from time manipulation. But, at the difficulty lows and the highs the network hash rate seems to go beyond the actual a bit when it overshoots. I was hoping someone else would have some input on this good discussion... I'm not smart enough to tackle how to strike the right balance with the difficulty adjustments. I know it has been a complaint with YAC in the past where it takes a couple weeks for the difficulty to adjust appropriately after the NFactor change. I feel this issue needs to be investigated because I don't think these difficulty swings are good. As a miner, I could just jump on when it is low and leave when it is high--maximizing my profits while hurting UTC. Am I missing something? Kracko, I still don't understand why you are punishing miners in order to balance your two pools while the network is completely unbalanced. Has there been a fork now? Is that why Cryptsy has UTC under maintenance? Meanwhile, it seems UTC will soon no longer have the largest marketcap for scrypt-chacha. And the coin that will be ahead of UTC has only one working pool. I am a big fan of decentralization, but the cost-benefit analysis of what you are doing is clear. Besides, that 3% takeaway from miners for the 'dev' fund becomes pretty meaningless as the price continues to fall. Just my thoughts... Duly noted. Sorry you feel that way, but yet again, the retarget is going to stay as it is. In my mind, a little bounciness is preferable to leaving your miners with an overly high difficulty for a couple weeks. Be it time manipulation or intermittent miners, there will be a fast recovery. The only one making an issue of the pools is you. There are no forks that I'm aware of. And you would have to ask Cryptsy, we haven't published any changes in production since the last release. May the best coin win. I don't know enough to tackle this myself, but I am a solid programmer would be willing to work with someone who does know more about the theory and various re-targeting algorithms to implement a fix. |
|
|
|
|
