Network issues

[xeroc]

But this is only one way to update if you wan't to keep/add other fields like managedby for example:

Here it works just fine .. all other attributes are kept after publish_version ..

[cn-members]

  even though the superhero voice inside my head tells me that downgrading to v0.4.25-RC2 might solve the issue (for now, with the potential security issue open again), the reasonable voice inside my head (which usually ends up being right) says to not do anything until we have bytemaster or vikram pitch on the issue...

The delegates are certainly waiting for their superheroes to appear. BM, Vikram - Help! Help!

Surely, somebody has their number?

If not can BM give me his number for future? I will ring him up.

I doubt a sleepy head can do us much good ....
It's a 24/7 shift that's most needed in the future .

[testz]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

Two are on v0.4.25, three are on a mysteriously named 0.4.26 (with missing v) and the other 96 are on v0.4.26

0.4.26 without v it's fine - they update version field manually.

They shouldn't do that though, it means we can't tell if they've compiled the incorrect version for example.

But this is only one way to update if you wan't to keep/add other fields like managedby for example:

>> blockchain_get_account delegate.adarin

Name: delegate.adarin
Registered: 2014-10-06T21:15:50
Last Updated: 63 hours ago
Owner Key: BTS6N9quM9WvjqmkkQ46h8dVVk6Utwbvcb4v2KdDRAPL6oR4s1Bz5
Active Key History:
- BTS6N9quM9WvjqmkkQ46h8dVVk6Utwbvcb4v2KdDRAPL6oR4s1Bz5, last used 70 days ago

ID    NAME (* next in line)           APPROVAL       PRODUCED MISSED   RELIABILITY   PAY RATE PAY BALANCE         LAST BLOCK  VERSION     
==========================================================================================================================================
29313 delegate.adarin                 0.25874637 %   0        0        N/A           3 %      0.00000 BTS         NONE        v0.4.26     

Block Signing Key: BTS6N9quM9WvjqmkkQ46h8dVVk6Utwbvcb4v2KdDRAPL6oR4s1Bz5
Public Data:
{
  "version": "v0.4.26",
  "managedby": "testz"
}

[wackou]

Does somebody know whether bter/btc38/... are reading these forums? Or if someone knows how to contact them? Because I believe that they should either:
 - make sure they are on 0.4.26 as all the delegates (on a frozen network, granted)
 - freeze deposits/withdrawals if they are still on 0.4.25 as people could do a double-spend then

Reverting back to 0.4.25 for delegates on friday was the best solution as most, if not all users, were still on 0.4.25, but 0.4.26 has now been published on bitshares.org so it's hard to estimate which fork it's better to move on to...

[sumantso]

  even though the superhero voice inside my head tells me that downgrading to v0.4.25-RC2 might solve the issue (for now, with the potential security issue open again), the reasonable voice inside my head (which usually ends up being right) says to not do anything until we have bytemaster or vikram pitch on the issue...

The delegates are certainly waiting for their superheroes to appear. BM, Vikram - Help! Help!

Surely, somebody has their number?

If not can BM give me his number for future? I will ring him up.

[svk]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

Two are on v0.4.25, three are on a mysteriously named 0.4.26 (with missing v) and the other 96 are on v0.4.26

0.4.26 without v it's fine - they update version field manually.

They shouldn't do that though, it means we can't tell if they've compiled the incorrect version for example.

It shouldn't be allowed to publish version manually...

It uses the public_data field unfortunately so no way of stopping it unless another way of publishing the version is implemented.

[cube]

  even though the superhero voice inside my head tells me that downgrading to v0.4.25-RC2 might solve the issue (for now, with the potential security issue open again), the reasonable voice inside my head (which usually ends up being right) says to not do anything until we have bytemaster or vikram pitch on the issue...

The delegates are certainly waiting for their superheroes to appear. BM, Vikram - Help! Help!

[chsln]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

Two are on v0.4.25, three are on a mysteriously named 0.4.26 (with missing v) and the other 96 are on v0.4.26

0.4.26 without v it's fine - they update version field manually.

They shouldn't do that though, it means we can't tell if they've compiled the incorrect version for example.

It shouldn't be allowed to publish version manually...

[svk]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

Two are on v0.4.25, three are on a mysteriously named 0.4.26 (with missing v) and the other 96 are on v0.4.26

0.4.26 without v it's fine - they update version field manually.

They shouldn't do that though, it means we can't tell if they've compiled the incorrect version for example.

[testz]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

Two are on v0.4.25, three are on a mysteriously named 0.4.26 (with missing v) and the other 96 are on v0.4.26

0.4.26 without v it's fine - they update version field manually.

[wackou]

hree are on a mysteriously named 0.4.26 (with missing v)

that's probably because those delegates publish version manually instead of using the wallet_publish_version command (I used to do it this way too before realizing it's much easier to call wallet_publish_version)

[wackou]

what about downgrading to v 0.4.25-RC2 again?

I strongly recommend no one take any action until we have official word on the matter.

edit: you might make it worse by downgrading

  even though the superhero voice inside my head tells me that downgrading to v0.4.25-RC2 might solve the issue (for now, with the potential security issue open again), the reasonable voice inside my head (which usually ends up being right) says to not do anything until we have bytemaster or vikram pitch on the issue...

[monsterer]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

Two are on v0.4.25, three are on a mysteriously named 0.4.26 (with missing v) and the other 96 are on v0.4.26

[liondani]

what about downgrading to v 0.4.25-RC2 again?

I strongly recommend no one take any action until we have official word on the matter.

edit: you might make it worse by downgrading

 

[wackou]

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).