If you have coins currently pending in the mempool, you won't be able to send with even 0 mixins because your funds are still appearing as 'used'. It doesn't matter if you cancel them or if they are showing as canceled. If the transaction hash is still in the mempool, those funds will be inaccessible until the original transaction processes.

Guys it's like none of you read my previous post   I'll make the text very large so you don't skim over it.

Not every single large TX can go into a single block, otherwise we would have a 100 MB block. We currently have about a 1 MB block size. CryptoNote requires by design that network block size grows at a slow rate based upon the cumulative size of the transactions thus far. In our young network, there were few transactions outside of coinbase mined ones, so the purpose of the 65k block upgrade was to periodically allow inclusion of large txs into the blockchain outside of normal growth restrictions.

The 65000 block upgrade is working as intended. However, it will take time for the rest of the large pending TXs to proceed. We did only allow for these special case large blocks to go into the chain every 5 blocks to mitigate attack vectors. Normally this is about ten minutes time, but in the face of the current high difficulty and minimal hash power on the network, it's taking quite a bit longer.

Why is your balance on the pool not showing up? Because blocks are not being found. It takes 60 blocks for your balance to update. Go look at the explorer, we are finding blocks at a very slow rate.

Why are your transactions pending? Because blocks are not being found.

Why are blocks not being found? Because the difficulty is high, because there was an influx of NiceHash power.

When will this be remedied? In 7-10 days, we will issue a hardfork to adjust the difficulty algorithm. We have provided solutions on how to decrease large transaction size, which is reducing the anonymity level/mixin level. Set it to 0.

The explorer is now showing block 65k + properly, had to adjust the forknote code a bit. Thanks for letting us know.



In regards to why there are still pending large TXs: not every single large TX can go into a single block, otherwise we would have a 100 MB block. We currently have about a 1 MB block size. CryptoNote requires by design that network block size grows at a slow rate based upon the cumulative size of the transactions thus far. In our young network, there were few transactions outside of coinbase mined ones, so the purpose of the 65k block upgrade was to periodically allow inclusion of large txs into the blockchain outside of normal growth restrictions.

The 65000 block did indeed include two large TXs, one at 742kb in size and another at 104kb. Prior to the upgrade these TXs wouldn't have processed for a long time. However, it will take time for the rest of the large pending TXs to proceed. We did only allow for these special case large blocks to go into the chain every 5 blocks to mitigate attack vectors. Normally this is about ten minutes time, but in the face of the current high difficulty and minimal hash power on the network, it's taking quite a bit longer.

If your wallet is stuck on 64,999, you're not running 1.3.0.

We're working on revisions to the difficulty algo now. Until we received a huge influx of hashing power yesterday, it was not an issue!

The forknote client has some kind of issues with persistent RPC requests. It's been restarted and is working properly now. We'll look into resolving the bug.

Normally, you would have a pending balance by now, but because blocks became so slow over the last several hours, your pending balance is empty. It takes 60 blocks for the pending balance to 'catch up'. As long as your number of hashes submitted is increasing, it's working properly.


Your coins are in limbo because of the size until block 65,000. We should reach that block in the next several hours depending on hash rate and luck.


 

It's on our immediate agenda to revise the difficulty algorithm in the next major update. We are already looking into options and will likely follow zawy's algorithm, similar to Bitcoin Cash. It's a great revision to the classic difficulty approach, and should really equalize things for big/small miners.


No mechanism to do that now, sorry


Blocks are slow due to a massive influx of hashing power earlier today, that has since left the pool. See above.


Latest version should automatically sync up to main chain. If you're having issues, just close the wallet, clear the blockchain data from %userprofile%\appdata\roaming\intensecoin - delete everything EXCEPT .wallet files, and then restart the wallet.

Hi eat, as noted in our monthly update post, unfortunately it will be stuck in mempool territory until block 65k at which point large TXs will go into the block. As it stands now, TXs using mixins are very large, and the smoothly scaling block size algo defaulting in CryptoNote doesn't support large TXs early on. We have adjusted the code to allow for these blocks. It will take effect soon. Make sure you're on 1.3.0 wallet or later.


EXCELLENT!

Network hash rate is calculated over time based upon the last X blocks. It won't "catch up" to small surges of increased hashing power until that hashing power remains consistent.


Alex already took care of it!

The official pool server's power was just QUADRUPLED to help manage this massive influx of hashing power! Server is no longer sad and hashing is now awesome once again 

Now that is an original post in this thread. Are you in nursing school? Or is this a bad translation?

For anyone having issues with private or public pool mining not properly synthesizing blocks, please checkout branch pre65kminingfix: https://github.com/valiant1x/intensecoin/tree/pre65kminingfix

This should no longer be needed after block 65k. The issue of fusion TX size was originally addressed many patches ago by disabling fusion TXs, but someone is using old software on the network that is again pushing fusion transactions into the mempool. This update will force the daemon to refuse including those txns into the block. The sheer size of fusion TXs pushes them over what cumulative block size should be at that time. The 65k block upgrade will resolve issues with cumulative TX size.

Great! Please make sure you are running the latest git commit (1.3.0 daemon) to support the block 65,000 network upgrade.

Yes, the GUI wallet contains an embedded version of the daemon and does act as a node.


Thanks, we will look into it.

Thanks very much for your quick correspondence. This may be a caching issue on your machine. Please try the following instructions to resolve.

EDIT; saw the above post about the issue ALSO occurring on Windows 7 after I made this suggestion. Try it anyway and let me know!

On Windows 10 I see the icon properly in the tray. Which OS are you using and what are you seeing? Can you provide a screenshot?


Just download the latest version.  


We are very excited for alex to share information about ITNS, making connections and hopefully partnerships!  

angeloal you have raised a valid point which is that the versioning system is defunct! I'll fix it in the next commit - in the meantime make sure you have at least 1.2.2 from this page: https://github.com/valiant1x/intensecoin/releases

Hey Crate, the client from 1.2.2 was designed to be compliant with the 50k block upgrade but we couldn't update certain configuration parameters in it until the upgrade was actually live. For a current network compliant version that should allow you to send those TXs, please see 1.2.4: https://github.com/valiant1x/intensecoinwallet/releases/latest

We will add the Whitepaper link to the first post in a couple days after our graphic designer gets back to us with some stylizing of the content

What other information are you looking for?

Welcome Slowgrowth!!! We are very happy to have him on board!  


Hi Priest, the VPN network data does not proceed over the blockchain but rather the Intense network acts as the backbone to facilitate the VPN. The transactions supporting use of the VPN will occur over the Intense blockchain, which is untraceable via Ring signatures. Due to the decentralized nature of the VPN it will be largely untraceable as well. Previously, when a counterparty or state agency was interested in gleaning VPN data, they would hack or view the data of the datacenter utilized by the VPN provider. In the context of Intense, every day end users are offering their private connections for VPN usage - this makes it much, much harder to track and monitor.