I should have one setup for you to use at 0 pay:

delegate-free-galt

unless I messed something up. 

Yes it is

Sent from my SCH-I535 using Tapatalk

wow, that was fast.  Are you looking for people to register as potential delegates?

We plan to make one last change to the market engine prior to locking it in stone for many months ...

Glad to hear this.  i think we are near (past?) the point of diminishing returns with respect to the time spent on this for the return.  Maybe that will free up more time to focus on marketing, partnering and networking to facilitate further BitSharesX/BitUSD utility in all the ways discussed. 

Edit: I have this re-occurring nightmare that someone else is going to come along with less tech but better marketing/partnering and eat our lunch.

Average confirmation time is 5 secs.  That's good.

Quote from: GaltReport on October 02, 2014, 01:07:32 pm

Quote from: emski on October 02, 2014, 01:06:20 pm

Quote from: GaltReport on October 02, 2014, 01:02:27 pm

Quote from: wackou on October 02, 2014, 12:59:50 pm

Quote from: bytemaster on October 02, 2014, 12:44:03 pm

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

All delegates should be on the same version. Unless we want forks.

Can't they delay planned forks ?  Not sure if that is what you are referring to or not.  I only notice that when we do upgrades their are days when people are on different versions.

Forks are hardcoded in the code for block number. Current v0.4.19 fork is scheduled for block 640000. All v0.4.19 will fork at that block. Any previous versions might not accept blocks produced by v0.4.19. That is why either all (most) of the delegates upgrade by block 640000 or none (very few) of them upgrade. Note that v0.4.19-RC1 is different version  -> it should not accept blocks by both v0.4.19 and v0.4.18.

ugh, looks like we're "f--ked"... Seems like approx. 68 active delegates are on 0.4.19.

Quote from: bytemaster on October 02, 2014, 12:44:03 pm

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

I'm running under this setting:

network_set_advanced_node_parameters { "peer_connection_retry_timeout": 10, "desired_number_of_connections": 10, "maximum_number_of_connections": 10 }
if that helps anyone.