Quote from: xeroc on December 12, 2014, 09:41:55 PM

Quote from: bytemaster on December 12, 2014, 09:40:15 PM

Quote from: xeroc on December 12, 2014, 09:38:47 PM
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,


Quote from: vikram on December 12, 2014, 06:46:39 PM
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?

Quote from: wackou on December 12, 2014, 09:35:21 PM
However, when I run

Code Select Expand

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 10
and 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 100
does the trick. Sorry for the noise  :-[

Quote from: xeroc on December 12, 2014, 09:38:47 PM
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.

Quote from: bytemaster on December 12, 2014, 09:40:15 PM

Quote from: xeroc on December 12, 2014, 09:38:47 PM
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

Quote from: xeroc on December 12, 2014, 09:38:47 PM
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?

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...  ???

Now producing blocks with v0.4.26

Quote from: emski on December 12, 2014, 08:51:48 PM

Quote from: bytemaster on December 12, 2014, 08:46:08 PM

Code Select Expand


{
  "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

Quote from: bytemaster on December 12, 2014, 08:54:08 PM

Quote from: emski on December 12, 2014, 08:51:48 PM

Quote from: bytemaster on December 12, 2014, 08:46:08 PM

Code Select Expand


{
  "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.

Quote from: emski on December 12, 2014, 08:51:48 PM

Quote from: bytemaster on December 12, 2014, 08:46:08 PM

Code Select Expand


{
  "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.   

Quote from: bytemaster on December 12, 2014, 08:46:08 PM

Code Select Expand


{
  "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]

Delegates Upgraded to  0.4.26:

delegate1-galt
delegate1.john-galt