BitShares Forum
Main => General Discussion => Topic started by: vikram on December 12, 2014, 03:58:47 pm
-
https://bitsharestalk.org/index.php?topic=7067.msg161312#msg161312
https://bitsharestalk.org/index.php?topic=7067.msg161432#msg161432
All community members please help spread the word.
-
Downgrading now ..
-
Downgrading now ..
Same here...
-
I have a backup of the old chain, just need to start it up.
Anyway, I'm totally confused.
-
Downgrading...
-
What version are acceptable?
I have a 0.4.24 backup and a 0.4.25-RC1 backup
building 0.4.25-RC2
-
I get this error if I now try to open the downgraded client:
------------ error --------------
10 assert_exception: Assert Exception
_map->is_open(): Database is not open!
{}
th_a level_map.hpp:305 commit
error applying batch
{}
th_a level_map.hpp:314 commit
{}
th_a cached_level_map.hpp:52 flush
{}
th_a cached_level_map.hpp:28 close
{}
th_a chain_database.cpp:1370 close
{"data_dir":"/home/l/.BitShares/chain"}
th_a chain_database.cpp:1321 open
{"data_dir":"/home/l/.BitShares"}
th_a client.cpp:1303 open
-
Bumpety bump.
Downgrading now.
-
I get this error if I now try to open the downgraded client:
------------ error --------------
10 assert_exception: Assert Exception
_map->is_open(): Database is not open!
{}
th_a level_map.hpp:305 commit
error applying batch
{}
th_a level_map.hpp:314 commit
{}
th_a cached_level_map.hpp:52 flush
{}
th_a cached_level_map.hpp:28 close
{}
th_a chain_database.cpp:1370 close
{"data_dir":"/home/l/.BitShares/chain"}
th_a chain_database.cpp:1321 open
{"data_dir":"/home/l/.BitShares"}
th_a client.cpp:1303 open
Are you running the wrong version - you need to be on 0.4.25-RC2 if you previously upgraded to 0.4.25
-
Are you running the wrong version - you need to be on 0.4.25-RC2 if you previously upgraded to 0.4.25
Ok thanks I'll try
-
--- syncing with p2p network, our last block is 20 weeks old
--- currently syncing at 270 blocks/sec, 75 minutes remaining
Gonna take a while...
-
--- syncing with p2p network, our last block is 20 weeks old
--- currently syncing at 270 blocks/sec, 75 minutes remaining
Gonna take a while...
same here ... give me 60 minutes or so .. will sign blocks again then .. have shut down all delegates temporarily to not sign on any fork until downgrade ..
-
https://bitsharestalk.org/index.php?topic=7067.msg161312#msg161312
All community members please help spread the word.
Any chance of delaying the full and proper fix for all of this until monday?
-
Syncing....
--- syncing with p2p network, our last block is 20 weeks old
--- currently syncing at 952 blocks/sec, 22 minutes remaining
-
Downgraded to v0.4.25-RC2
delegate1-galt
delegate1.john-galt
-
--- syncing with p2p network, 395712 blocks left to fetch
Ouch...
-
is their an easy way to tell if you are on the right chain/fork?
-
I keep getting this repeated (with slightly different numbers):
--- syncing with p2p network, 325689 blocks left to fetch
--- in sync with p2p network
--- syncing with p2p network, 111 blocks left to fetch
--- in sync with p2p network
Is the fork resolution having a bad time?
-
Please lock delegates still on 0.4.25 to help people switch forks faster
-
...downgrading to v0.4.25-RC2
it will take a while...
-
I keep getting this repeated (with slightly different numbers):
--- syncing with p2p network, 325689 blocks left to fetch
--- in sync with p2p network
--- syncing with p2p network, 111 blocks left to fetch
--- in sync with p2p network
Is the fork resolution having a bad time?
I am also getting similar....
-
Please lock delegates still on 0.4.25 to help people switch forks faster
Done. I was all happy having made it through the morning's chaos without missing a single block, bye bye 100% reliability!
-
Please lock delegates still on 0.4.25 to help people switch forks faster
roger
-
Please lock delegates still on 0.4.25 to help people switch forks faster
Done. I was all happy having made it through the morning's chaos without missing a single block, bye bye 100% reliability!
There wont be a single 100% reliability delegate left now
-
Please lock delegates still on 0.4.25 to help people switch forks faster
Done. I was all happy having made it through the morning's chaos without missing a single block, bye bye 100% reliability!
You can't tell war stories without a few scars :).
-
Please lock delegates still on 0.4.25 to help people switch forks faster
Done. I was all happy having made it through the morning's chaos without missing a single block, bye bye 100% reliability!
There wont be a single 100% reliability delegate left now
For sure, I was the only one left on the v25 chain though, haha.
-
Please lock delegates still on 0.4.25 to help people switch forks faster
Done. I was all happy having made it through the morning's chaos without missing a single block, bye bye 100% reliability!
There wont be a single 100% reliability delegate left now
It'll be like a badge. "Oh, you have 100% reliability? Well, you weren't here for forkfest 2014 noob"
-
Please lock delegates still on 0.4.25 to help people switch forks faster
Done. I was all happy having made it through the morning's chaos without missing a single block, bye bye 100% reliability!
lol
have you ever seen a top soldier without scars ?
(http://mobiusonline.web.fc2.com/gallary/repo/rambo/13.jpg)
-
is their an easy way to tell if you are on the right chain/fork?
You can check block hashes like this:
>>> get_block 1246470
{
"previous": "68b7e003ca08d50843faaddcf696cfff1954ede3",
>>> get_block 1246901
{
"previous": "b5214c1bc914ea5da6c1bb8f774d07f12b85dbe2",
-
Downgraded spartako,spartako1,spartako2 to v0.4.25-RC2
default (unlocked) >>> getinfo
{
"blockchain_head_block_num": 1246950,
"blockchain_head_block_age": "50 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T17:36:00",
"blockchain_average_delegate_participation": "5.96 %",
"blockchain_confirmation_requirement": 303,
"blockchain_share_supply": "2,498,307,571.05240 BTS",
"blockchain_blocks_left_in_round": 97,
"blockchain_next_round_time": "at least 16 minutes in the future",
"blockchain_next_round_timestamp": "2014-12-12T17:53:00",
"blockchain_random_seed": "a393f9536da50480dd66e66fe04fe44cdcc1a572",
"client_data_dir": "/home/spartako/.BitShares",
"client_version": "v0.4.25-RC2",
"network_num_connections": 17,
"network_num_connections_max": 200,
"network_chain_downloader_running": false,
"network_chain_downloader_blocks_remaining": null,
"ntp_time": "2014-12-12T17:36:50",
"ntp_time_error": 0.001722,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "17 weeks in the future",
"wallet_unlocked_until_timestamp": "2015-04-07T11:16:55",
"wallet_last_scanned_block_timestamp": "2014-07-24T09:23:30",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "80 seconds in the future",
"wallet_next_block_production_timestamp": "2014-12-12T17:38:10"
}
default (unlocked) >>> get_block 1246470
{
"previous": "68b7e003ca08d50843faaddcf696cfff1954ede3",
...}
default (unlocked) >>> get_block 1246901
{
"previous": "b5214c1bc914ea5da6c1bb8f774d07f12b85dbe2",
...}
-
Signing on RC2 again now
-
Signing on RC2 again now
Looking good here too. Now I need some lunch. And maybe a beer lol.
-
Signing on RC2 again now
Looking good here too. Now I need some lunch. And maybe a beer lol.
make it quick, maybe we need you again... :D
-
Updating to 0.4.26 now
-
Signing on RC2 again now
Looking good here too. Now I need some lunch. And maybe a beer lol.
make it quick, maybe we need you again... :D
False alarm, it got to six hours and then stopped syncing. Looks like I get to resync again. 4th time the charm I hope. Strange thing is my hash matched what drltc posted.
-
My delegate server finished syncing but was on a minority fork with 7% delegate participation, rebuilding the index now to see if that fixes it..
-
My delegate server finished syncing but was on a minority fork with 7% delegate participation, rebuilding the index now to see if that fixes it..
Im guessing that is the correct one. Its currently up to 9.66% now
-
I've stopped my seed node and delegates until I'm able to upgrade.
All this unplanned stuff happened during my worktime...
-
I've stopped my seed node and delegates until I'm able to upgrade.
All this unplanned stuff happened during my worktime...
Luckily I am on vacation today. Wasn't exactly how I planned to spend it but shit happens.
-
https://github.com/BitShares/bitshares/releases
0.4.26 is out. I assume that is where we should be now??
-
https://github.com/BitShares/bitshares/releases (https://github.com/BitShares/bitshares/releases)
0.4.26 is out. I assume that is where we should be now??
They are still doing internal testing according to Vikram. However I'm building it and will sync it so I can switch over when it's official.
-
My (standby) delegate a.delegate.abit running on v0.4.25-RC1 now..
blockchain_average_delegate_participation 16.64%
is it okay?
-
My (standby) delegate a.delegate.abit running on v0.4.25-RC1 now..
blockchain_average_delegate_participation 16.64%
is it okay?
Ya. People are slowly switching over.
-
My (standby) delegate a.delegate.abit running on v0.4.25-RC1 now..
blockchain_average_delegate_participation 16.64%
is it okay?
Ya. People are slowly switching over.
0.4.26 is out for delegates and seed nodes. It has checkpoints to resolve the fork and should be compatible with 0.4.24.1 and 0.4.25-RC2 forks of the chain.
-
My (standby) delegate a.delegate.abit running on v0.4.25-RC1 now..
blockchain_average_delegate_participation 16.64%
is it okay?
Ya. People are slowly switching over.
0.4.26 is out for delegates and seed nodes. It has checkpoints to resolve the fork and should be compatible with 0.4.24.1 and 0.4.25-RC2 forks of the chain.
Downloading.
-
"blockchain_head_block_num": 1247043,
"blockchain_head_block_age": "2 minutes old",
"blockchain_head_block_timestamp": "2014-12-12T18:38:20",
"blockchain_average_delegate_participation": "23.11 %"
-
Currently building v0.4.26 @ 43%
Currently producing with v0.4.25-RC-2
-
v0.4.26 has been released with a checkpoint to address the blockchain fork: https://bitsharestalk.org/index.php?topic=7067.msg161432#msg161432
Delegates and seed nodes should upgrade ASAP.
-
My (standby) delegate a.delegate.abit running on v0.4.25-RC1 now..
blockchain_average_delegate_participation 16.64%
is it okay?
Ya. People are slowly switching over.
riverhead-del-server-1 is v0.4.25?
-
I've upgraded delegates to 0.4.26 (resync blockchain).
I've updated the seed to 0.4.26 (reindexed).
Everything seems OK.
-
"blockchain_head_block_num": 1247043,
"blockchain_head_block_age": "2 minutes old",
"blockchain_head_block_timestamp": "2014-12-12T18:38:20",
"blockchain_average_delegate_participation": "23.11 %"
very helpful to have updates like this every 15 minutes for example to avoid confusion about which chain is the right one.
-
"blockchain_head_block_num": 1247075,
"blockchain_head_block_age": "42 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T18:52:50",
"blockchain_average_delegate_participation": "28.29 %",
"client_version": "v0.4.26",
-
Is there any way devs could implement 'naming' of the forks? Something more recognizable than a hash, and something that stays consistent for majority forks. Once a minority fork pops up, it gets a new name.
We could use the names that ElasticSearch uses for naming its run instances:
https://github.com/elasticsearch/elasticsearch/blob/master/src/main/resources/config/names.txt
-
"blockchain_head_block_num": 1247075,
"blockchain_head_block_age": "42 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T18:52:50",
"blockchain_average_delegate_participation": "28.29 %",
"client_version": "v0.4.26",
when we reach 51% participation I think I open a champaign :P
-
v0.4.26 has been released with a checkpoint to address the blockchain fork: https://bitsharestalk.org/index.php?topic=7067.msg161432#msg161432
Delegates and seed nodes should upgrade ASAP.
Unable to download the linux binary. Working now.
The windows binary works.
-
when we reach 51% participation I think I open a champaign :P
"blockchain_head_block_num": 1247086,
"blockchain_head_block_age": "4 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T18:58:10",
"blockchain_average_delegate_participation": "30.15 %",
"client_version": "v0.4.26",
PS: I think I have something better that I was longing to open for a long time...
-
"blockchain_head_block_num": 1247102,
"blockchain_head_block_age": "15 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:03:50",
"blockchain_average_delegate_participation": "33.01 %",
-
Upgraded to 0.4.26
-
"blockchain_head_block_num": 1247131,
"blockchain_head_block_age": "5 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:15:50",
"blockchain_average_delegate_participation": "37.27 %"
-
"blockchain_head_block_num": 1247140,
"blockchain_head_block_age": "3 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:17:50",
"blockchain_average_delegate_participation": "41.06 %"
-
looks like svk gives the right data...
http://bitsharesblocks.com/home
-
"blockchain_head_block_num": 1247158,
"blockchain_head_block_age": "2 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:24:10",
"blockchain_average_delegate_participation": "42.62 %",
-
"blockchain_head_block_num": 1247161,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:25:40",
"blockchain_average_delegate_participation": "43.16 %"
-
0.4.26
-
"blockchain_head_block_num": 1247167,
"blockchain_head_block_age": "8 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:28:00",
"blockchain_average_delegate_participation": "43.91 %"
-
"blockchain_head_block_num": 1247161,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:25:40",
"blockchain_average_delegate_participation": "43.16 %"
it's not the bitshares team...
It's the DREAM TEAM !!!
-
"blockchain_head_block_num": 1247188,
"blockchain_head_block_age": "22 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T19:35:40",
"blockchain_average_delegate_participation": "44.89 %",
-
Grr. Was producing blocks and then it froze and now says my chain database is inconsistent state :( . It's using 2.5GB of RAM and 100% of CPU. Maybe I'll let it spin for a bit. I really don't want to resync.
-
Grr. Was producing blocks and then it froze and now says my chain database is inconsistent state :( . It's using 2.5GB of RAM and 100% of CPU. Maybe I'll let it spin for a bit. I really don't want to resync.
Yuck.
-
Upgraded spartako, spartako1, spartako2 to v0.4.26 (on the road from my car :)
-
"blockchain_head_block_num": 1247314,
"blockchain_head_block_age": "10 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:18:10",
"blockchain_average_delegate_participation": "52.06 %",
-
"blockchain_head_block_num": 1247328,
"blockchain_head_block_age": "6 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:20:40",
"blockchain_average_delegate_participation": "55.19 %",
-
"blockchain_head_block_num": 1247336,
"blockchain_head_block_age": "5 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:22:40",
"blockchain_average_delegate_participation": "58.05 %",
-
upgraded to 0.4.26. I assume the data on bitsharesblocks.com is correct. It seems we finally survived in this crisis. +5%
-
Seems my systems finally got their shit together lol.
-
a.delegate.abit upgraded to 0.4.26.
-
Delegates Upgraded to 0.4.26:
delegate1-galt
delegate1.john-galt
-
{
"blockchain_head_block_num": 1247432,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:45:20",
[b] "blockchain_average_delegate_participation": "70.63 %",
[/b]
-
{
"blockchain_head_block_num": 1247432,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:45:20",
[b] "blockchain_average_delegate_participation": "70.63 %",
[/b]
It is pleasing to see how fast delegates act in order to restore the network security, isn't it ?
-
{
"blockchain_head_block_num": 1247432,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:45:20",
[b] "blockchain_average_delegate_participation": "70.63 %",
[/b]
It is pleasing to see how fast delegates act in order to restore the network security, isn't it ?
Much more responsive than miners.
-
{
"blockchain_head_block_num": 1247432,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:45:20",
[b] "blockchain_average_delegate_participation": "70.63 %",
[/b]
It is pleasing to see how fast delegates act in order to restore the network security, isn't it ?
Much more responsive than miners.
Especially true for 100% pay delegates which are losing pay every minute the network is down.
-
{
"blockchain_head_block_num": 1247432,
"blockchain_head_block_age": "7 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T20:45:20",
[b] "blockchain_average_delegate_participation": "70.63 %",
[/b]
It is pleasing to see how fast delegates act in order to restore the network security, isn't it ?
+1
-
Now producing blocks with v0.4.26
-
upgraded seed node and delegate to 0.4.26, and producing blocks. There is something weird, though:
I am pretty sure I just produced a block with wackou-delegate, it even came up on bitsharesblocks: http://bitsharesblocks.com/blocks/block?id=1247596
However, when I run blockchain_get_delegate_slot_records wackou-delegate it shows that my last block was from 2014-12-12T13:38:10
What's even weirder, is that this list keeps being updated, but seems to lag ~8h behind the current time. I would have thought that this is a sync issue, or some background indexing, however both my delegate node and my seed node show the exact same list, and they are on different machines. I did follow the same upgrade pattern for both though (0.4.25-RC1 -> 0.4.25 -> 0.4.25-RC2 (resync blockchain) -> 0.4.26), so maybe that's the cause? I'm a bit confused as to what this could be given that my delegate is signing blocks correctly now... ???
-
I am at Austin Airport an just realize that I cannot connect to any other port than 80 and 443 .. my machines are still compiling and redownloading the chain .. though I have no chance to switch over to 0.4.26 from 0.4.25-RC2 for quite some hours ...
I hope I will have access to my ssh sessions in LA ..
Anyone can offer a temporary port 80 proxy ssh machine?
-
I am at Austin Airport an just realize that I cannot connect to any other port than 80 and 443 .. my machines are still compiling and redownloading the chain .. though I have no chance to switch over to 0.4.26 from 0.4.25-RC2 for quite some hours ...
I hope I will have access to my ssh sessions in LA ..
Anyone can offer a temporary port 80 proxy ssh machine?
0.4.25-RC2 should be fine assuming it is properly connected.
-
I am at Austin Airport an just realize that I cannot connect to any other port than 80 and 443 .. my machines are still compiling and redownloading the chain .. though I have no chance to switch over to 0.4.26 from 0.4.25-RC2 for quite some hours ...
I hope I will have access to my ssh sessions in LA ..
Anyone can offer a temporary port 80 proxy ssh machine?
0.4.25-RC2 should be fine assuming it is properly connected.
it seems so as I am on the main chain (AFAIK) produce block and have the same participation rate as you have posted earlier .. gonna update to 26 though .. once I am in LA ... hope they have port 22 open via WIFI
-
I am at Austin Airport an just realize that I cannot connect to any other port than 80 and 443 .. my machines are still compiling and redownloading the chain .. though I have no chance to switch over to 0.4.26 from 0.4.25-RC2 for quite some hours ...
I hope I will have access to my ssh sessions in LA ..
Anyone can offer a temporary port 80 proxy ssh machine?
I can give you a ssh connection on 443 port, if send in PM your a ssh public key I give you the details how to connect.
-
However, when I run blockchain_get_delegate_slot_records wackou-delegate it shows that my last block was from 2014-12-12T13:38:10
Sorry, my bad, that's because the default values are
blockchain_get_delegate_slot_records wackou-delegate -1000 10and as there were lots of missed blocks, -1000 went way past beyond the usual 10 blocks per delegate to show blocks until "now", so running
blockchain_get_delegate_slot_records wackou-delegate -1000 100does the trick. Sorry for the noise :-[
-
v0.4.26 has been released with a checkpoint to address the blockchain fork: https://bitsharestalk.org/index.php?topic=7067.msg161432#msg161432
Delegates and seed nodes should upgrade ASAP.
Really? The third update in 24 hours?
-
I am at Austin Airport an just realize that I cannot connect to any other port than 80 and 443 .. my machines are still compiling and redownloading the chain .. though I have no chance to switch over to 0.4.26 from 0.4.25-RC2 for quite some hours ...
I hope I will have access to my ssh sessions in LA ..
Anyone can offer a temporary port 80 proxy ssh machine?
0.4.25-RC2 should be fine assuming it is properly connected.
it seems so as I am on the main chain (AFAIK) produce block and have the same participation rate as you have posted earlier .. gonna update to 26 though .. once I am in LA ... hope they have port 22 open via WIFI
yhea .. found an at&t hotstpot that let me connect through 22 .. opened up 80 for ssh and am now again working on the upgrade to 0.4.26 ..
delegate is currently running 26 .. will move it back to the VPS when synced .. backup delegate upgrading atm ..
btw.
{
"blockchain_head_block_num": 1247883,
"blockchain_head_block_age": "6 seconds old",
"blockchain_head_block_timestamp": "2014-12-12T22:29:10",
"blockchain_average_delegate_participation": "75.37 %",
"blockchain_confirmation_requirement": 162,
-
v0.4.26 has been released with a checkpoint to address the blockchain fork: https://bitsharestalk.org/index.php?topic=7067.msg161432#msg161432
Delegates and seed nodes should upgrade ASAP.
Really? The third update in 24 hours?
yhea .. woke up 6 hours ago .. compiling three versions every since :)
0.4.25 has a fork flaw :)
-
For sure, I was the only one left on the v25 chain though, haha.
How are you likein your reliability now, eh? :p
-
It's like July in December 8)
-
delegate.liondani producing blocks again with client version v0.4.26
...seed node also updated ;)
-
For sure, I was the only one left on the v25 chain though, haha.
How are you likein your reliability now, eh? :p
:'( :'(
-
Delegate participation rate is over 95% now. Beautiful update speed (considering re-indexing time)
-
(considering re-indexing time)
Speaking of which, is re-indexing something that is inherently single-threaded or that could be made multi-threaded in the future? Because that could help speed upgrades a lot, even more so than just the gain from the speedup itself on the computer, eg: sometimes in the past I had only 20-30 minutes of "contiguous time" to upgrade and decided to postpone the upgrade until a bit later when I would have more time, because otherwise I wouldn't have been available to unlock my wallet after re-indexing.
-
(considering re-indexing time)
Speaking of which, is re-indexing something that is inherently single-threaded or that could be made multi-threaded in the future? Because that could help speed upgrades a lot, even more so than just the gain from the speedup itself on the computer, eg: sometimes in the past I had only 20-30 minutes of "contiguous time" to upgrade and decided to postpone the upgrade until a bit later when I would have more time, because otherwise I wouldn't have been available to unlock my wallet after re-indexing.
Inherently sequential.
-
Delegate participation rate is over 95% now. Beautiful update speed (considering re-indexing time)
Yes, it is impressive considering not all delegates are running it as a full-timer.
-
Delegate participation rate is over 95% now. Beautiful update speed (considering re-indexing time)
Yes, it is impressive considering not all delegates are running it as a full-timer.
i'm one of the 5%, somehow it got on a fork last night while I was asleep and was producing blocks on a chain with by itself. I have 3 machines and can't get any of them to connect to the network. I've deleted and downloaded the chain 3 times, let's see if 4 is the charm...
EDIT: by can't connect i mean they seem to get on a fork and peg the CPU at 100% while downloading blocks. Different block each time
up and running!
-
I had a similar issue. What I ended up doing was stating 0.4.26 in a completely new directory and then creating a new wallet and importing the private keys. Until then I was getting databases that be OK for a bit and then corrupt or stall.
-
Delegate participation rate is over 95% now. Beautiful update speed (considering re-indexing time)
Yes, it is impressive considering not all delegates are running it as a full-timer.
i'm one of the 5%, somehow it got on a fork last night while I was asleep and was producing blocks on a chain with by itself. I have 3 machines and can't get any of them to connect to the network. I've deleted and downloaded the chain 3 times, let's see if 4 is the charm...
EDIT: by can't connect i mean they seem to get on a fork and peg the CPU at 100% while downloading blocks. Different block each time
Try deleting your peer db and manually reindex.
-
I have 3 client, in 3 different forks.....both v0.4.26
from block 1253547, the random seed is different, but the block is same
5%
delegate (unlocked) >>> blockchain_get_block 1253547
{
"previous": "1eb0869d7fba7402ba5017e3778d04bb2496406d",
"block_num": 1253547,
"timestamp": "2014-12-13T15:48:50",
"transaction_digest": "c8cf12fe3180ed901a58a0697a522f1217de72d04529bd255627a4ad6164f0f0",
"next_secret_hash": "af817547d1c6c287c7c3c4388fc6e0839001d44a",
"previous_secret": "ae525bf66ce8e114a5d23827ea24fbfc6c50174f",
"delegate_signature": "2040ee212addc5a6503b7997009afa4ffd733be14a3afaa0c74b130843a6bf952c4bac02ae48c819f223b0ecf9fdd8cf410ba4edc93fc96660379bf9674af92ee1",
"user_transaction_ids": [],
"signee_shares_issued": 150000,
"signee_fees_collected": 0,
"signee_fees_destroyed": 0,
"random_seed": "8b9d9afdd18d92ee0ecef0997e81562620d1d5a6",
"block_size": 166,
"latency": 0,
"processing_time": 2834
}
95%
delegate (unlocked) >>> blockchain_get_block 1253547
{
"previous": "1eb0869d7fba7402ba5017e3778d04bb2496406d",
"block_num": 1253547,
"timestamp": "2014-12-13T15:48:50",
"transaction_digest": "c8cf12fe3180ed901a58a0697a522f1217de72d04529bd255627a4ad6164f0f0",
"next_secret_hash": "af817547d1c6c287c7c3c4388fc6e0839001d44a",
"previous_secret": "ae525bf66ce8e114a5d23827ea24fbfc6c50174f",
"delegate_signature": "2040ee212addc5a6503b7997009afa4ffd733be14a3afaa0c74b130843a6bf952c4bac02ae48c819f223b0ecf9fdd8cf410ba4edc93fc96660379bf9674af92ee1",
"user_transaction_ids": [],
"signee_shares_issued": 150000,
"signee_fees_collected": 0,
"signee_fees_destroyed": 0,
"random_seed": "9ba0e03ae99795a91f73c233b999efdc5f68a663",
"block_size": 166,
"latency": 0,
"processing_time": 29190
}
from 1253613, the block is different
5%
delegate (unlocked) >>> blockchain_get_block 1253613
{
"previous": "98527eea839fbfe7974ba0795e8e61805a2e6b7a",
"block_num": 1253613,
"timestamp": "2014-12-13T16:02:40",
"transaction_digest": "c8cf12fe3180ed901a58a0697a522f1217de72d04529bd255627a4ad6164f0f0",
"next_secret_hash": "4166c54ab052c38509ee126773b9be62ccd786f5",
"previous_secret": "cba4a7e4709b6053a47960265c2c7c9a19255f76",
"delegate_signature": "206150cb7badd373d189863e1b5d01eeaeeac2493e9e4d51d025ae3de043010b7b49d0c573e8145547aa68190d407cf366bc405b3d752a07d9f2d130ef237f0d30",
"user_transaction_ids": [
"b850db16dcb49b6e98e0790a40159e9eb3ec8156",
"12a4b67ccbfdf9950df96f48240853e9df955a18",
"37c997cb63b065253f41bbebb83d3428c5a75aeb",
"7954c4d8db3d5ee63fa90334830e657970c9623f",
"865c748a7f81dc0444e676120dea7b4bdbc0d8b6",
"b322b06f9fe9208e21d5541119152bc30a52cc3d",
"f55dd51a1610aff079ac1b59cede113bf959920b"
],
"signee_shares_issued": 150000,
"signee_fees_collected": 0,
"signee_fees_destroyed": 20000,
"random_seed": "4c15a30b598899cbbcfc1ee30b6dfd463d54bc03",
"block_size": 7330,
"latency": 0,
"processing_time": 56642
}
95%
delegate (unlocked) >>> blockchain_get_block 1253613
{
"previous": "98527eea839fbfe7974ba0795e8e61805a2e6b7a",
"block_num": 1253613,
"timestamp": "2014-12-13T16:00:10",
"transaction_digest": "c8cf12fe3180ed901a58a0697a522f1217de72d04529bd255627a4ad6164f0f0",
"next_secret_hash": "b293cae7599d6a74e8c1f415e482767a01a3c4f6",
"previous_secret": "37279fa9266808a91eb09ab4c75b3b428b01c1ea",
"delegate_signature": "1f38bafda9c039414cb2b85bb0d73389c4ad4463a39899cabb2b0a92c8543a08a643c19dc7e8d05519e7be741d12e0f5935eba01413e6fe34973effc741c1a5ff8",
"user_transaction_ids": [],
"signee_shares_issued": 150000,
"signee_fees_collected": 0,
"signee_fees_destroyed": 20000,
"random_seed": "df612d4ab5f43d0c8c4f066f315480c1145a4b85",
"block_size": 166,
"latency": 0,
"processing_time": 37179
}
-
and the fork is create from my delegate, because of sync problem
delegate (unlocked) >>> blockchain_list_blocks 1253612 2
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE LATENCY PROCESSING TIME RAND
====================================================================================================================
1253612 2014-12-13T16:00:00 init43 2 1577 0 0.037797 26b59b8a3d46a6b1682b013783e601a1fa7e384a
MISSED 2014-12-13T16:00:10 mrs.agsexplorer N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:00:20 moon.delegate.service N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:00:30 delegate1-galt N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:00:40 bm.payroll.riverhead N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:00:50 delegate.nathanhourt.com N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:01:00 delegate.charity N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:01:10 very.strong N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:01:20 future.dacwin N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:01:30 delegate2.xeldal N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:01:40 boombastic N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:01:50 now.dacwin N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:02:00 testz N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:02:10 emski.bitdelegate N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:02:20 riverhead-del-server-1 N/A N/A N/A N/A N/A
MISSED 2014-12-13T16:02:30 crazybit N/A N/A N/A N/A N/A
1253613 2014-12-13T16:02:40 delegate.baozi 7 7330 0 0.056642 4c15a30b598899cbbcfc1ee30b6dfd463d54bc03
-
the other client is in the main chain, but just refuse to sync continue,
here is the message from p2p.log
2014-12-14T02:12:47 th_a:invoke handle_message evaluate_transaction ] Transaction 921f8f9e253253994ac068e5b2824be7ee8bd079 needed relay fee 90000 but only had 10000
chain_database.cpp:1548
2014-12-14T02:12:47 th_a:invoke handle_message store ] storing error in database: {"code":36005,"name":"insufficient_relay_fee","message":"insufficient r
elay fee","stack":[{"context":{"level":"error","file":"chain_database.cpp","line":1549,"method":"evaluate_transaction","hostname":"","thread_name":"th_a","timestamp":"2
014-12-14T02:12:47"},"format":"","data":{"fees":10000,"required_fees":90000}},{"context":{"level":"warn","file":"chain_database.cpp","line":1555,"method":"evaluate_tran
saction","hostname":"","thread_name":"th_a","timestamp":"2014-12-14T02:12:47"},"format":"","data":{"trx":{"expiration":"2014-12-14T03:20:06","delegate_slate_id":null,"o
perations":[{"type":"ask_op_type","data":{"amount":25002540,"ask_index":{"order_price":{"ratio":"1.8907165815844","quote_asset_id":3,"base_asset_id":0},"owner":"BTSFTpA
1iwRTLjpzy97pJP5StB4vFRiRU6a6"}}},{"type":"withdraw_op_type","data":{"balance_id":"BTSH5rE3GwXQCcVUENejXdf2QehqFSh1UCbj","amount":25012540,"claim_input_data":""}}],"sig
natures":["200a2f8807a6f74471f1db5d966d0259b8a277079728d15a3d62d2b1898b358e3b5161f74fef73cbe7913a724354c63885c5c2eb1a5fc529d63225fef54467856e","1f0efb2bdb393d65181cd984
1b87698a1dae48dc060dba469bff116e778b41827653996aceeb8e535d2e196362e99d9588f72dfb760fbc9a1c2a4acf4ae2536cc4"]}}},{"context":{"level":"warn","file":"chain_database.cpp","
line":2218,"method":"store_pending_transaction","hostname":"","thread_name":"th_a","timestamp":"2014-12-14T02:12:47"},"format":"","data":{"trx":{"expiration":"2014-12-1
4T03:20:06","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":25002540,"ask_index":{"order_price":{"ratio":"1.8907165815844","quote_asset_id
":3,"base_asset_id":0},"owner":"BTSFTpA1iwRTLjpzy97pJP5StB4vFRiRU6a6"}}},{"type":"withdraw_op_type","data":{"balance_id":"BTSH5rE3GwXQCcVUENejXdf2QehqFSh1UCbj","amount"
:25012540,"claim_input_data":""}}],"signatures":["200a2f8807a6f74471f1db5d966d0259b8a277079728d15a3d62d2b1898b358e3b5161f74fef73cbe7913a724354c63885c5c2eb1a5fc529d63225fef54467856e","1f0efb2bdb393d65181cd9841b87698a1dae48dc060dba469bff116e778b41827653996aceeb8e535d2e196362e99d9588f72dfb760fbc9a1c2a4acf4ae2536cc4"]}}}]} client_impl.hpp:47
2014-12-14T02:12:47 th_a:invoke handle_messa