Is it only me, or consequence of new wallet, that the blockchain is stuck at 17901???
I also see that blokchain stuck at 17901, but in my wallet right now 17943.
Topic: [ANN][NTRN] Neutron - New Nucleus wallets released! - Next developments soon! - page 39. (Read 72958 times)
May 04, 2015, 01:08:24 AM
I also see that blokchain stuck at 17901, but in my wallet right now 17943.
May 04, 2015, 01:05:07 AM
Is it only me, or consequence of new wallet, that the blockchain is stuck at 17901???
May 04, 2015, 12:39:46 AM
We need a new wallet, not the old beautifully packaged.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
The fix to end all forking issues is being developed now - it should be out within 24 hours.
These issues are not being ignored - there is a group of us working hard to get them sorted out. I will say though - once they are fixed - don't try and be cheeky and short on Bittrex. We have two major implementations ready - one of which is something we have all been waiting for - that will cause a large influx of demand.
These are not ideas - these are finished and ready to go as soon as the forking issue is confirmed resolved.
Have you had converations out of the forum with the Dev?? If so, why did he not make those comments here in the forum?? So we could all be aware??
When somethin spookie, like this, happens, the more info, the better. IMHO...
Another stake? Another apparent slowdown from blockchain...
Private conversations are held between the members of the NTRN Investors club and various developers. When they choose to release that info to the general population is their decision. Sometimes I will make announcements on things If I think the dev is asleep or otherwise unable to speak on an issue - particularly where panic is liable to set in.
My information is that a new wallet is an hour or so away and it will be mandatory.
Thanks for letting us all know things "as they happen" BigDaddySherman...
Don't mean to be disrespectfull, but having a lot of coins, compared to us, IMHO, doesn't mean you all can do things without letting the community know. This IS a community...
Again, this is my opinion with all due respect...
BTW, thnxs for the update tho...
May 03, 2015, 11:51:38 PM
We need a new wallet, not the old beautifully packaged.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
The fix to end all forking issues is being developed now - it should be out within 24 hours.
These issues are not being ignored - there is a group of us working hard to get them sorted out. I will say though - once they are fixed - don't try and be cheeky and short on Bittrex. We have two major implementations ready - one of which is something we have all been waiting for - that will cause a large influx of demand.
These are not ideas - these are finished and ready to go as soon as the forking issue is confirmed resolved.
Have you had converations out of the forum with the Dev?? If so, why did he not make those comments here in the forum?? So we could all be aware??
When somethin spookie, like this, happens, the more info, the better. IMHO...
Another stake? Another apparent slowdown from blockchain...
Private conversations are held between the members of the NTRN Investors club and various developers. When they choose to release that info to the general population is their decision. Sometimes I will make announcements on things If I think the dev is asleep or otherwise unable to speak on an issue - particularly where panic is liable to set in.
My information is that a new wallet is an hour or so away and it will be mandatory.
May 03, 2015, 11:44:51 PM
We need a new wallet, not the old beautifully packaged.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
The fix to end all forking issues is being developed now - it should be out within 24 hours.
These issues are not being ignored - there is a group of us working hard to get them sorted out. I will say though - once they are fixed - don't try and be cheeky and short on Bittrex. We have two major implementations ready - one of which is something we have all been waiting for - that will cause a large influx of demand.
These are not ideas - these are finished and ready to go as soon as the forking issue is confirmed resolved.
Have you had converations out of the forum with the Dev?? If so, why did he not make those comments here in the forum?? So we could all be aware??
When somethin spookie, like this, happens, the more info, the better. IMHO...
Another stake? Another apparent slowdown from blockchain...
May 03, 2015, 10:23:42 PM
The coin Neutron have had trouble with synching. This is claimed to be becaused of code taken from this coin Positron. Here is tips to correct the code.
I originally added a parameter to the function to pass the block height, but later found it wasn't needed during my testing.
TRON hasn't had any syncing problems, we had a short fork during the POW phase but I resolved it with ocminer from Suprnova within a few minutes.
The more likely problem for your sync is the outgoing maxconnections variable in net.cpp. The defaults are really low and seednodes and pools should always increase them. Neutron's default outgoing connection # is only 16:
https://github.com/teamneutron/Neutron/blob/master/src/net.cpp#L28
The reason a lot of these high POS coins are having problems connecting or syncing is because so many wallets are staking now and demanding more node connections. That variable needs to be increased to like 1024 for your main seed nodes, then recompile.
I'm glad to see someone took over the failing neutron project and made something of it.
Good luck.
May 03, 2015, 09:35:08 PM
Important to correct the dynamic staking code taken from coin Positron.
it doesn't check obviously.
and a lil easier advice to everybody: always delete peers.dat after you close the wallet.
that way next launch you'll feed it from seednode and not some shitnodes
Actually it does check.
https://github.com/teamneutron/Neutron/blob/master/src/version.h#L39
The problem is that this dynamic staking code that came out of Tron is broken/not implemented correctly. I am surprised Tron has not started having issues yet.
Check it out:
https://github.com/teamneutron/Neutron/blob/master/src/main.cpp#L1036
Do you see the problem in that code? It is checking the block height against pindexBest, which is a pointer to the tip of the chain. But that varies as you sync. If you get a bunch of other block inventory for your node to check, its always going to be trying to assign a reward based on what it thinks the tip of the chain is, not the relative height of a particular block.
The new seed/checkpointing/other nodes will disconnect anyone who is not on protocol 60014.
I wonder if the new wallet has a higher version number and if it checks that nodes have the new wallet.
it doesn't check obviously.
and a lil easier advice to everybody: always delete peers.dat after you close the wallet.
that way next launch you'll feed it from seednode and not some shitnodes
https://github.com/teamneutron/Neutron/blob/master/src/version.h#L39
The problem is that this dynamic staking code that came out of Tron is broken/not implemented correctly. I am surprised Tron has not started having issues yet.
Check it out:
https://github.com/teamneutron/Neutron/blob/master/src/main.cpp#L1036
Do you see the problem in that code? It is checking the block height against pindexBest, which is a pointer to the tip of the chain. But that varies as you sync. If you get a bunch of other block inventory for your node to check, its always going to be trying to assign a reward based on what it thinks the tip of the chain is, not the relative height of a particular block.
i'm not into C at all, simply logically if it connects to any nodes any version
and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
Actually thats completely and totally wrong. The existing wallet respects connect= correctly. The previous version was protocol version 60013 with a min required version of 209 as seen here: https://bitbucket.org/neutroncrypto/neutron/src/880cb18109884e1168e76a3d96fde8987a38c38e/src/version.h?at=master#cl-39.and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
The new seed/checkpointing/other nodes will disconnect anyone who is not on protocol 60014.
Can simply replace the dynamic award at a constant? This will solve the problem?
Don't need to do that, its one of the features of this coin that makes it attractive. Just need to modify the reward methods to accept a height parameter and pass the (previous block index + 1) to it from checkblock etc. May 03, 2015, 05:04:32 PM
We need a new wallet, not the old beautifully packaged.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
The fix to end all forking issues is being developed now - it should be out within 24 hours.
These issues are not being ignored - there is a group of us working hard to get them sorted out. I will say though - once they are fixed - don't try and be cheeky and short on Bittrex. We have two major implementations ready - one of which is something we have all been waiting for - that will cause a large influx of demand.
These are not ideas - these are finished and ready to go as soon as the forking issue is confirmed resolved.
May 03, 2015, 04:54:13 PM
We need a new wallet, not the old beautifully packaged.
http://savepic.org/7256389.png
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
http://savepic.org/7256389.png
Bad blocks all day and in all likelihood need to synchronize units every 10-12 hours. This is ridiculous.
May 03, 2015, 02:25:02 PM
Are there any who have a problem with synchronization? I have now run 3 wallet (new green wallet) on three different computers, and they work for 10 hours without errors and all wallets blocks correspond http://neutron.blockview.space/chains
Maybe the network returned to normal and now there is only one chain of blocks?
Maybe the network returned to normal and now there is only one chain of blocks?
I still have 'invalid checkpoint' although seems fine re block number (17478) and showing synchronised & staking?
Should I worry?
Am using new green wallet. I deleted everything except wallet.dat about 1 hour ago and downloaded and restarted new wallet.
May 03, 2015, 02:22:20 PM
Are there any who have a problem with synchronization? I have now run 3 wallet (new green wallet) on three different computers, and they work for 10 hours without errors and all wallets blocks correspond http://neutron.blockview.space/chains
Maybe the network returned to normal and now there is only one chain of blocks?
Maybe the network returned to normal and now there is only one chain of blocks?
I still have 'invalid checkpoint' although seems fine re block number (17478) and showing synchronised & staking?
Should I worry?
May 03, 2015, 02:17:01 PM
Are there any who have a problem with synchronization? I have now run 3 wallet (new green wallet) on three different computers, and they work for 10 hours without errors and all wallets blocks correspond http://neutron.blockview.space/chains
Maybe the network returned to normal and now there is only one chain of blocks?
Maybe the network returned to normal and now there is only one chain of blocks?
I still have 'invalid checkpoint' although seems fine re block number (17478) and showing synchronised & staking?
Should I worry?
May 03, 2015, 01:53:02 PM
Are there any who have a problem with synchronization? I have now run 3 wallet (new green wallet) on three different computers, and they work for 10 hours without errors and all wallets blocks correspond http://neutron.blockview.space/chains
Maybe the network returned to normal and now there is only one chain of blocks?
Maybe the network returned to normal and now there is only one chain of blocks?
May 03, 2015, 12:49:02 PM
Wait some time and see 
May 03, 2015, 12:44:23 PM
new wallet staking good
and synched o.k
so for now everything working ok
wallet
v1.0.0.0-g32a928e
and synched o.k
so for now everything working ok
wallet
v1.0.0.0-g32a928e
May 03, 2015, 11:29:32 AM
i'm not into C at all, simply logically if it connects to any nodes any version
and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
Actually thats completely and totally wrong. The existing wallet respects connect= correctly. The previous version was protocol version 60013 with a min required version of 209 as seen here: https://bitbucket.org/neutroncrypto/neutron/src/880cb18109884e1168e76a3d96fde8987a38c38e/src/version.h?at=master#cl-39.and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
The new seed/checkpointing/other nodes will disconnect anyone who is not on protocol 60014.
i cannot make my wallet follow connect=ip rule.
at start it takes only this node and it looks good
but in 2-3 minutes there's a myriad, as if no option present
May 03, 2015, 11:19:21 AM
Can simply replace the dynamic award at a constant? This will solve the problem?
Don't need to do that, its one of the features of this coin that makes it attractive. Just need to modify the reward methods to accept a height parameter and pass the (previous block index + 1) to it from checkblock etc. May 03, 2015, 11:16:42 AM
i'm not into C at all, simply logically if it connects to any nodes any version
and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
Actually thats completely and totally wrong. The existing wallet respects connect= correctly. The previous version was protocol version 60013 with a min required version of 209 as seen here: https://bitbucket.org/neutroncrypto/neutron/src/880cb18109884e1168e76a3d96fde8987a38c38e/src/version.h?at=master#cl-39.and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
The new seed/checkpointing/other nodes will disconnect anyone who is not on protocol 60014.
May 03, 2015, 11:05:53 AM
This works:
Exit neutron wallet program.
Delete everything in data directory (search for %appdata%) except wallet.dat and any "conf"-file.
I you have a "conf"-file edit and remove all "addnode=".
Start neutron wallet again but don't unlock it yet.
Let the wallet synch to the latest block.
Compare the block that the wallet have as the latest with the blockexplorer.
http://neutron.blockview.space/
Save everything in data directory to a new backup directory except wallet.dat, peers.dat and any "conf"-file.
Start staking with the wallet by unlocking it.
When the wallet for some reason isn't synchronised with the latest block according to the block explorer. Delete again in the data directory as stated and copy the data from the backup directory to your data directory which gives a fast synching to the latest block.
I wonder if the new wallet has a higher version number and if it checks that nodes have the new wallet.
Exit neutron wallet program.
Delete everything in data directory (search for %appdata%) except wallet.dat and any "conf"-file.
I you have a "conf"-file edit and remove all "addnode=
Start neutron wallet again but don't unlock it yet.
Let the wallet synch to the latest block.
Compare the block that the wallet have as the latest with the blockexplorer.
http://neutron.blockview.space/
Save everything in data directory to a new backup directory except wallet.dat, peers.dat and any "conf"-file.
Start staking with the wallet by unlocking it.
When the wallet for some reason isn't synchronised with the latest block according to the block explorer. Delete again in the data directory as stated and copy the data from the backup directory to your data directory which gives a fast synching to the latest block.
I wonder if the new wallet has a higher version number and if it checks that nodes have the new wallet.
it doesn't check obviously.
and a lil easier advice to everybody: always delete peers.dat after you close the wallet.
that way next launch you'll feed it from seednode and not some shitnodes
https://github.com/teamneutron/Neutron/blob/master/src/version.h#L39
The problem is that this dynamic staking code that came out of Tron is broken/not implemented correctly. I am surprised Tron has not started having issues yet.
Check it out:
https://github.com/teamneutron/Neutron/blob/master/src/main.cpp#L1036
Do you see the problem in that code? It is checking the block height against pindexBest, which is a pointer to the tip of the chain. But that varies as you sync. If you get a bunch of other block inventory for your node to check, its always going to be trying to assign a reward based on what it thinks the tip of the chain is, not the relative height of a particular block.
i'm not into C at all, simply logically if it connects to any nodes any version
and even ignores connect=ip option, that means there is NO check actually,
i see constants in code, but behavior doesn't follow.
and btw, how many version already have the same protocol 60014
as to block height, of course Tron won't bork because reward is not dynamic there for every block
Can simply replace the dynamic award at a constant? This will solve the problem?
May 03, 2015, 10:17:51 AM
This works:
Exit neutron wallet program.
Delete everything in data directory (search for %appdata%) except wallet.dat and any "conf"-file.
I you have a "conf"-file edit and remove all "addnode=".
Start neutron wallet again but don't unlock it yet.
Let the wallet synch to the latest block.
Compare the block that the wallet have as the latest with the blockexplorer.
http://neutron.blockview.space/
Save everything in data directory to a new backup directory except wallet.dat, peers.dat and any "conf"-file.
Start staking with the wallet by unlocking it.
When the wallet for some reason isn't synchronised with the latest block according to the block explorer. Delete again in the data directory as stated and copy the data from the backup directory to your data directory which gives a fast synching to the latest block.
I wonder if the new wallet has a higher version number and if it checks that nodes have the new wallet.
Exit neutron wallet program.
Delete everything in data directory (search for %appdata%) except wallet.dat and any "conf"-file.
I you have a "conf"-file edit and remove all "addnode=
Start neutron wallet again but don't unlock it yet.
Let the wallet synch to the latest block.
Compare the block that the wallet have as the latest with the blockexplorer.
http://neutron.blockview.space/
Save everything in data directory to a new backup directory except wallet.dat, peers.dat and any "conf"-file.
Start staking with the wallet by unlocking it.
When the wallet for some reason isn't synchronised with the latest block according to the block explorer. Delete again in the data directory as stated and copy the data from the backup directory to your data directory which gives a fast synching to the latest block.
I wonder if the new wallet has a higher version number and if it checks that nodes have the new wallet.
it doesn't check obviously.
and a lil easier advice to everybody: always delete peers.dat after you close the wallet.
that way next launch you'll feed it from seednode and not some shitnodes
https://github.com/teamneutron/Neutron/blob/master/src/version.h#L39
The problem is that this dynamic staking code that came out of Tron is broken/not implemented correctly. I am surprised Tron has not started having issues yet.
Check it out:
https://github.com/teamneutron/Neutron/blob/master/src/main.cpp#L1036
Do you see the problem in that code? It is checking the block height against pindexBest, which is a pointer to the tip of the chain. But that varies as you sync. If you get a bunch of other block inventory for your node to check, its always going to be trying to assign a reward based on what it thinks the tip of the chain is, not the relative height of a particular block.
Jump to: