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.
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.
