Whats wrong with current test networks in latest git build? It cannot sync after

Code: [Select]

{
  "blockchain_head_block_num": 10252,
  "blockchain_head_block_time": "20140616T161845",
  "blockchain_head_block_time_rel": "2 minutes old",
  "blockchain_confirmation_requirement": 291,
  "blockchain_average_delegate_participation": 28.429073856975382,

Seems we have 2 major forks =\

Looks fine with me:

"blockchain_head_block_num": 10263,
"blockchain_head_block_time": "20140616T171645",

Quote from: emski on June 16, 2014, 07:05:54 am

I'll just report - everything seems to work flawlessly. No crashes, no diminishing amount of connections. Log size is about 6.5GB since I restarted the client 32 hours ago. Restart was due to extremely large logfile filling up the assigned VM HDD size.

In your data folder run:

Code: [Select]

$ rm default.log ; ln -s /dev/null default.logThen all log entries will be 'deleted' by default No log-bloating .. but also no log file-content

Further,

Quote

network_set_advanced_node_parameters {"desired_number_of_connections":25}

should increase you number of connections... however, there seems to be a bug currently, because I am stuck with 8 connections

I just updated to recent revision that apparently fixes the large logs. And increased the size of VM HDD - we need the logs if something goes wrong after all. If the log file grows large again I'll archive it.

I've set desired_number_of_connections to 30 when I started the node and max connections to 50. Sometimes I get 30 connections but not always. I believe this is normal, isnt it ?

In order to increase your connections you should increase both desired_number_of_connections and max_number_of_connections (at least this makes sense to me).

Just an update:
emski (unlocked) >>> get_info
{
  "blockchain_head_block_num": 6002,
  "blockchain_head_block_time": "20140615T054600",
  "blockchain_confirmation_requirement": 286,
  "blockchain_average_delegate_participation": 60.89139987445072,
  "network_num_connections": 26,
  "wallet_unlocked_seconds_remaining": 99913328,
  "wallet_next_block_production_time": "20140615T054700",
  "wallet_seconds_until_next_block_production": 61,
  "wallet_local_time": "20140615T054559",
  "blockchain_random_seed": "c1286419a26cc7b0402fb40d3537f30a53c0837d",
  "blockchain_shares": 10000094357869,
  "network_num_connections_max": 50,
  "network_protocol_version": 101,
  "wallet_open": true,
  "wallet_unlocked_until": "20170814T152807",
  "wallet_version": 100
}
--- there are now 27 active connections to the p2p network
--- in sync with p2p network

I've increased network_num_connections_max and desired_number_of_connections just to see what happens.

I think you'd just have to crawl the chain and find all unspent outputs of transactions that voted for you.  You could filter out recent transactions depending on your vote duration requirement, and the voters can verify their loyalty by signing with the same keys that signed the voting transactions.

Thank you! I was thinking about this but as I'm not familiar with the design/code I wasnt sure if it is suitable.
I might be able to implement this provided I find enough spare time.

I would like to create delegate that enables everyone who upvoted that delegate to vote on how the taxes should be spent.

Is it possible to obtain a list of all shareholders who voted for a particular delegate?
Is it possible for a shareholder to prove he voted for a particular delegate?

* possible is defined as "takes maximum a few days to implement by someone with technical background"

Just syncrhonized (took less than a minute with clean data dir).

Am I on the right chain?
"blockchain_head_block_num": 2870,
"blockchain_head_block_time": "20140614T054445",

Because I have its private keys.
It will no longer be anonymous - I'll be behind it. (Site and other info is WIP, I just have to pick up a name)
It was just assigned to me by luck. (or the fact that I saw the thread asking for delegates early enough... or by other unknown to me reasons)
Anyway I was just thinking about a new delegate name and one of the options was to go a bit "lazy" - sticking with "init-delegate-1".
That seems like a good idea but I need some more opinions on this.

init-delegate-1 seems like a rather good name.
I was wondering If I should use it.