Network issues

[bytemaster]

I think the problem has been fixed for everyone. 

We will release an official update later today after a little bit more review of our patch.   In the mean time as long as a few delegates are running the patch in master it shouldn't happen again.

i syned the latest code, but seems i am still on the fork chain, and unable to download the blocks signed by other delegates.

Delete the full chain and download (not reindex).   

We are preparing some more advanced delegate tools to help resolve issues without the dev team intervention.   

[crazybit]

I think the problem has been fixed for everyone. 

We will release an official update later today after a little bit more review of our patch.   In the mean time as long as a few delegates are running the patch in master it shouldn't happen again.

i syned the latest code, but seems i am still on the fork chain, and unable to download the blocks signed by other delegates.

[bytemaster]

  "blockchain_head_block_num": 1268180,
  "blockchain_head_block_age": "6 seconds old",
  "blockchain_head_block_timestamp": "2014-12-15T12:23:20",
  "blockchain_average_delegate_participation": "87.83 %",
  "blockchain_confirmation_requirement": 230,

[xeroc]

finally .. bed time ..

Being in Australia rocks ... weather-wise .. not when it comes to synchronizing with US and europe ..

[spartako]

spartako,spartako1,spartako2 updated to the master

[bytemaster]

which branch should i syn? master branch?

Master

[bytemaster]

I think the problem has been fixed for everyone. 

We will release an official update later today after a little bit more review of our patch.   In the mean time as long as a few delegates are running the patch in master it shouldn't happen again.

[crazybit]

which branch should i syn? master branch?

[xeroc]

i recompiled with the patch and started signing again ..

I see blocks!

isn't that what we want?

I though I'd go straight forward and compile that patch .. as you don't really have a running delegate to test on your own ..

No good?

[clayop]

Network has been synced!

[bytemaster]

i recompiled with the patch and started signing again ..

I see blocks! 

[xeroc]

though it seems all delegates are signing again ..

[xeroc]

i recompiled with the patch and started signing again ..

[monsterer]

Code: [Select]

blockchain_list_pending_transactions
    TXN ID      SIZE          OPERATION COUNT          SIGNATURE COUNT
----------------------------------------------------------------------
  508c4b08       416                        5                        1
  14c3b1e9       216                        2                        2
  3269c196      1659                       20                        1
  5130293b      1661                       20                        1
  5299508f      1639                       20                        1
  655e7d12      1639                       20                        1
  68812c7b       436                        4                        3
  ab7252ea       451                        6                        1
  f8ee1d05       449                        6                        1


[bytemaster]

Those who feel comfortable helping to debug the issue can you checkout the latest master and see if it enables you to produce blocks.   

[spartako]

Code: [Select]

default (unlocked) >>> blockchain_list_pending_transactions
    TXN ID      SIZE          OPERATION COUNT          SIGNATURE COUNT
----------------------------------------------------------------------
  610e12b1      1741                       20                        2
  162b5967      1639                       20                        1
  3b90ea72      1640                       20                        1
  41c26cf8      1639                       20                        1
  48a6ef6c      1640                       20                        1
  4fe0cf80       157                        2                        1
  523d6f84       240                        2                        2
  5b741af1      1640                       20                        1
  6666aaff       157                        2                        1
  6698b2f4      1639                       20                        1
  8343bcd9      1639                       20                        1
  a6c1b7fe      1656                       20                        1
  a9013eb1      1656                       20                        1
  ac60133e       238                        2                        2
  b17832eb      1639                       20                        1
  b2e0fb13      1635                       20                        1
  b81ebab2      1639                       20                        1
  c140b581      1656                       20                        1
  d116ca79      1656                       20                        1
  e03da130      1656                       20                        1
  e2bb40c1      1635                       20                        1
  e95300bf       155                        2                        1



[davidpbrown]

> blockchain_list_pending_transactions

    TXN ID      SIZE          OPERATION COUNT          SIGNATURE COUNT
----------------------------------------------------------------------
  610e12b1      1741                       20                        2
  4fe0cf80       157                        2                        1
  523d6f84       240                        2                        2
  6666aaff       157                        2                        1
  a6c1b7fe      1656                       20                        1
  a9013eb1      1656                       20                        1
  ac60133e       238                        2                        2
  b2e0fb13      1635                       20                        1
  c140b581      1656                       20                        1
  d116ca79      1656                       20                        1
  e03da130      1656                       20                        1
  e2bb40c1      1635                       20                        1
  e95300bf       155                        2                        1

[svk]

Begs the question whether such forking can trigger some alarm that does have the network freeze itself.. or would that be too much a liability in itself?

We perhaps need to be aware of what bad events can occur when the network does this and look to prevent any future damage. Right now, I wouldn't know what to expect of transactions put to a fork.. how would I know I'm on a fork? I guess those transactions on forks get rebroadcast once its back as one.. but is it possible to undo transactions that haven't taken yet or can that only be done by reverting to an old wallet??.. or do transactions not rebroadcast with manual intervention???

Are there forks or did the network just freeze.   It looks like the network is frozen with 0 forks.

Bitsharesblocks was reporting a fork at the final block I think.

[xeroc]

@BM .. had the same unconfirmed transactions ..

though .. I tried to do a transaction and it didn't appear in that list .. not sure why

[bytemaster]

new commit in github master

This is an untested commit while we attempt to debug it.

[bytemaster]

Begs the question whether such forking can trigger some alarm that does have the network freeze itself.. or would that be too much a liability in itself?

We perhaps need to be aware of what bad events can occur when the network does this and look to prevent any future damage. Right now, I wouldn't know what to expect of transactions put to a fork.. how would I know I'm on a fork? I guess those transactions on forks get rebroadcast once its back as one.. but is it possible to undo transactions that haven't taken yet or can that only be done by reverting to an old wallet??.. or do transactions not rebroadcast with manual intervention???

Are there forks or did the network just freeze.   It looks like the network is frozen with 0 forks. 

[bytemaster]

Code: [Select]

    TXN ID      SIZE          OPERATION COUNT          SIGNATURE COUNT
----------------------------------------------------------------------
  610e12b1      1741                       20                        2
  dd3dd79a      1638                       20                        1
  4fe0cf80       157                        2                        1
  523d6f84       240                        2                        2
  6666aaff       157                        2                        1
  a6c1b7fe      1656                       20                        1
  a9013eb1      1656                       20                        1
  ac60133e       238                        2                        2
  b2e0fb13      1635                       20                        1
  d116ca79      1656                       20                        1
  e03da130      1656                       20                        1
  e2bb40c1      1635                       20                        1
  e95300bf       155                        2                        1
Can anyone else report the output of this command?

[xeroc]

new commit in github master

[davidpbrown]

Begs the question whether such forking can trigger some alarm that does have the network freeze itself.. or would that be too much a liability in itself?

We perhaps need to be aware of what bad events can occur when the network does this and look to prevent any future damage. Right now, I wouldn't know what to expect of transactions put to a fork.. how would I know I'm on a fork? I guess those transactions on forks get rebroadcast once its back as one.. but is it possible to undo transactions that haven't taken yet or can that only be done by reverting to an old wallet??.. or do transactions not rebroadcast with manual intervention???

[liondani]

I'm am up and working on the issue.

 

[liondani]

It looks like BM is informed about this.

any thing new ?

https://bitsharestalk.org/index.php?topic=12300.msg162459#msg162459

 

[BTSdac]

It looks like BM is informed about this.

any thing new ?

[xeroc]

I'm am up and working on the issue.

yhea .. seems like i need to stay awake a little longer

[ebit]

Would be sweet if we had 3 teams of core developers for the 3 major time zones Americas, europe/Africa and Asia. It will probably happen eventually, it's just a matter of hiring enough talented people as delegates that's the issue.

 

[bytemaster]

I'm am up and working on the issue.   

[liondani]

On skype at "Bitshares Delegates Coordination" group


Daniel: anybody is his neigborhood?
[1:13:54 PM] Daniel: calling the fire department, and say them the Larimers house is on fire maybe helps.... imagine... in ten minute from know they will hear the buzzer 
[1:14:10 PM] Daniel:

[1:14:26 PM] James calfee: valentine is .. i'll call and pm now
[1:15:06 PM] James calfee: agent86 should be close by too
[1:16:07 PM] James calfee: talking to dan now
[1:17:09 PM] James calfee: he will be on skype soon ..he is just waking up
[1:17:38 PM] Emil Velichkov: this should have better effect on him than morning coffee
[1:17:50 PM] Daniel: lol

[Rune]

I sent a SMS to Virkam. Not sure if that helps. If possible we need shifts...

Really, you want a core team member in a different timezone, that would do the trick.

If one of them decides to shift base to Mumbai, I can let him bunk for free

Or better still get one locally, supposedly coders are cheaper over here.

Would be sweet if we had 3 teams of core developers for the 3 major time zones Americas, europe/Africa and Asia. It will probably happen eventually, it's just a matter of hiring enough talented people as delegates that's the issue.

[emski]

It looks like BM is informed about this.

[sumantso]

I sent a SMS to Virkam. Not sure if that helps. If possible we need shifts...

Really, you want a core team member in a different timezone, that would do the trick.

If one of them decides to shift base to Mumbai, I can let him bunk for free

Or better still get one locally, supposedly coders are cheaper over here.

[janx]

I sent a SMS to Virkam. Not sure if that helps. If possible we need shifts...

Really, you want a core team member in a different timezone, that would do the trick.

 

[testz]

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

If it's works as you described that's fine and dev can prevent to publishing version field by command wallet_account_update_registration, in this case no one will be able to change version field manually unless he change the source code.

[monsterer]

I sent a SMS to Virkam. Not sure if that helps. If possible we need shifts...

Really, you want a core team member in a different timezone, that would do the trick.

[BTSdac]

Maybe there is need a message send to phone of developer automatically,when network is bad

[santaclause102]

I sent a SMS to Virkam. Not sure if that helps. If possible we need shifts...

[JA]

Could a blockchain rescan do something to the network.

It may sound weird.
But just a minute before the crash i opened my wallet since weeks (v0.4.24.1) and rescaned 50k blocks.
Could that have a effect on the network?
AFAIK it's a local operation so i doubt it...just want to be sure  .

na .. you cannot write anything into blocks ... only delegates can ... and it seems one of the obsolete 0.4.24 delegates screwed it up ..

ah ok
btw the lowest version according to bitsharesblocks are two with 0.4.25

[emski]

Could a blockchain rescan do something to the network.

It may sound weird.
But just a minute before the crash i opened my wallet since weeks (v0.4.24.1) and rescaned 50k blocks.
Could that have a effect on the network?
AFAIK it's a local operation so i doubt it...just want to be sure  .

na .. you cannot write anything into blocks ... only delegates can ... and it seems one of the obsolete 0.4.24 delegates screwed it up ..

It is not the issue of obsolete delegate(s). You shouldn't be able to stop the whole network with specific transaction(s). Regardless of the issuer.

[xeroc]

Could a blockchain rescan do something to the network.

It may sound weird.
But just a minute before the crash i opened my wallet since weeks (v0.4.24.1) and rescaned 50k blocks.
Could that have a effect on the network?
AFAIK it's a local operation so i doubt it...just want to be sure  .

na .. you cannot write anything into blocks ... only delegates can ... and it seems one of the obsolete 0.4.2425 delegates screwed it up ..

[JA]

Could a blockchain rescan do something to the network.

It may sound weird.
But just a minute before the crash i opened my wallet since weeks (v0.4.24.1) and rescaned 50k blocks.
Could that have a effect on the network?
AFAIK it's a local operation so i doubt it...just want to be sure  .

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

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

Publish version command doesn't overwrite the public data. Use this to publish info about your delegate that will show up in the wallet and bitsharesblocks: https://bitsharestalk.org/index.php?topic=11485.0

[cube]

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

bter has frozen bts.

[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).

[monsterer]

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

[cube]

what about downgrading to v 0.4.25-RC2 again?

or v0.4.24.1?  This is the stable version before the major patches.

[liondani]

What damage can be done in the mean time from an attacker? (before the update)

[liondani]

How can we prevent the regular users to stop making transactions?
Would it be a good idea for future implementation when the participation drops below 50% the wallet don't allow any other transactions?

[chsln]

what about downgrading to v 0.4.25-RC2 again?

[liondani]

I suppose we can do anything about it until a patch release update comes from the devs?

At least another 3 hours before BM can wake up ....

is it a coincidence or an attack...?
Every time the devs are sleeping shit happens !!!

[cn-members]

I suppose we can do anything about it until a patch release update comes from the devs?

At least another 3 hours before BM can wake up ....

[testz]

I suppose we can do anything about it until a patch release update comes from the devs?

Yes, we should wait for patch.

[cube]

I have suspended the Bitshare faucet.  Let's hope we can resolve this soon.

[liondani]

I suppose we can do anything about it until a patch release update comes from the devs?

[svk]

Yea looks like we're stuck on a fork again

I had a bad feeling about that fork resolution code that was pushed so quickly, looks like I was right..

[Harvey]

Network alarm~

[chsln]

I suppose exchanges have stop deposits and withdrawals , can somebody confirm?

I confirm Bter has stopped deposits and withdrawals

[xeroc]

I'd recommend to shutdown feed publish scripts until further notice .. otherwise you will pay tx fees and fill your tx buffer for nothing

[liondani]

I suppose exchanges have stop deposits and withdrawals , can somebody confirm?

[cn-members]

Looks like my delegate is on a fork:

"blockchain_average_delegate_participation": "27.67 %",

all delegates are I suppose !!!
Can somebody reach bytemaster or vikram?
NOW?

I doubt it , BM's time zone is 5:00 AM now .
I think it's a sign that they should do 24/7 shift .

[liondani]

Looks like my delegate is on a fork:

"blockchain_average_delegate_participation": "27.67 %",

all delegates are I suppose !!!
Can somebody reach bytemaster or vikram?
NOW?

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

yep you are right... I am just not emotional on a good shape to think logical....

[liondani]

if we continue like this, the only positive result I can think off is...

that we can buy super cheap BTS again the next days.... 

[monsterer]

Looks like my delegate is on a fork:

"blockchain_average_delegate_participation": "27.67 %",

all delegates are I suppose !!!
Can somebody reach bytemaster or vikram?
NOW?

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

[liondani]

Looks like my delegate is on a fork:

"blockchain_average_delegate_participation": "27.67 %",

all delegates are I suppose !!!
Can somebody reach bytemaster or vikram?
NOW?

[matt608]

Did DAC Sun do the previous updates?  Why did we get rid of them?

Not that I know much about the developer setup but they had a proven track record and are bitshares-fluent.  These things didn't happen when they were working on it.  Why not encourage them to create delegate positions and keep working?  Why was a perfectly good developer team disposed of when we are still looking for developers?

[liondani]

{
  "blockchain_head_block_num": 1268078,
  "blockchain_head_block_age": "45 minutes old",
  "blockchain_head_block_timestamp": "2014-12-15T09:14:00",
  "blockchain_average_delegate_participation": "27.30 %",
  "blockchain_confirmation_requirement": 1,
  "blockchain_share_supply": "2,498,408,589.57855 BTS",
  "blockchain_blocks_left_in_round": 78,
  "blockchain_next_round_time": "at least 13 minutes in the future",
  "blockchain_next_round_timestamp": "2014-12-15T10:11:40",
  "blockchain_random_seed": "718e310066d70763ccb61c852dd3f6f2fceb8301",
  "client_data_dir": "/home/liondani/.BitShares",
  "client_version": "v0.4.26",
  "network_num_connections": 19,
  "network_num_connections_max": 200,
  "network_chain_downloader_running": false,
  "network_chain_downloader_blocks_remaining": null,
  "ntp_time": "2014-12-15T09:58:41",
  "ntp_time_error": 0.00064700000000000001,
  "wallet_open": true,
  "wallet_unlocked": true,
  "wallet_unlocked_until": "2 years 10 months in the future",
  "wallet_unlocked_until_timestamp": "2017-10-09T05:08:07",
  "wallet_last_scanned_block_timestamp": "2014-12-13T01:36:40",
  "wallet_scan_progress": "? %",
  "wallet_block_production_enabled": true,
  "wallet_next_block_production_time": "6 minutes in the future",
  "wallet_next_block_production_timestamp": "2014-12-15T10:04:30"
}

[monsterer]

Looks like my delegate is on a fork:

"blockchain_average_delegate_participation": "27.67 %",

[chsln]

 

[fredafrica]

Tmd, we also got this problem.

[xeroc]

my delegate has stopped producing blocks 40 minutes ago ..

[emski]

This seems to be the reason for each ignored block.
How is each block ignored -> I dont know. Why is such duplicate transaction included I dont know.

Code: [Select]

    {"trx_num":10}
    th_a  chain_database.cpp:735 apply_transactions
ff564df8aa75aae05fe653e9da994463ed3de037: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"26e39dec4da5cbf259f6f0fbbb1ec6b851ed3fc0"}
    th_a  transaction_evaluation_state.cpp:208 evaluate

    {"trx":{"expiration":"2014-12-13T05:59:30","delegate_slate_id":null,"operations":[{"type":"update_feed_op_type","data":{"feed":{"feed_id":18,"delegate_id":10879},"value":{"ratio":"0.002063053930077422","quote_asset_id":18,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":4,"delegate_id":10879},"value":{"ratio":"0.048633818654512256","quote_asset_id":4,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":16,"delegate_id":10879},"value":{"ratio":"0.001970295508210492","quote_asset_id":16,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":17,"delegate_id":10879},"value":{"ratio":"0.001639794128077247","quote_asset_id":17,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":14,"delegate_id":10879},"value":{"ratio":"0.010521575043394854","quote_asset_id":14,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":21,"delegate_id":10879},"value":{"ratio":"0.001365108666025929","quote_asset_id":21,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":19,"delegate_id":10879},"value":{"ratio":"0.001082522253551607","quote_asset_id":19,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":7,"delegate_id":10879},"value":{"ratio":"0.000139219808619081","quote_asset_id":7,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":10,"delegate_id":10879},"value":{"ratio":"0.013188236454493424","quote_asset_id":10,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":20,"delegate_id":10879},"value":{"ratio":"0.002019496169557553","quote_asset_id":20,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":3,"delegate_id":10879},"value":{"ratio":"1.878852686320509312","quote_asset_id":3,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":15,"delegate_id":10879},"value":{"ratio":"0.025117152168524356","quote_asset_id":15,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":13,"delegate_id":10879},"value":{"ratio":"0.002187847007422356","quote_asset_id":13,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":11,"delegate_id":10879},"value":{"ratio":"0.09898000981556776","quote_asset_id":11,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":12,"delegate_id":10879},"value":{"ratio":"0.012843719535394108","quote_asset_id":12,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":9,"delegate_id":10879},"value":{"ratio":"0.002235493783919358","quote_asset_id":9,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":6,"delegate_id":10879},"value":{"ratio":"0.000099970973263619","quote_asset_id":6,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":8,"delegate_id":10879},"value":{"ratio":"0.003910639302506914","quote_asset_id":8,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":22,"delegate_id":10879},"value":{"ratio":"0.001701391478694531","quote_asset_id":22,"base_asset_id":0}}},{"type":"withdraw_pay_op_type","data":{"amount":50000,"account_id":10879}}],"signatures":["1f2394fdd8a80f093e5d10864a3cc38e0db3fbdfb6bfdd782e872655b8714ee2ef7f188dd3933393c62108f9fed258841b1cdeb7c9d8731b97f8c9218f5bef9f19"]}}
    th_a  transaction_evaluation_state.cpp:239 evaluate

    {"trx_num":0}
    th_a  chain_database.cpp:735 apply_transactions


[clayop]

Same here. What happened?

[chsln]

Is all the network down then?

it's stuck at block 1268078

[emski]

Same here.
Quite unexpected.
Seems like a broken network.

[chsln]

Also bitsharesblocks seems to have trouble

[chsln]

I see some network issue on both my istances:

  "blockchain_head_block_num": 1268078,
  "blockchain_head_block_age": "11 minutes old",
  "blockchain_head_block_timestamp": "2014-12-15T09:14:00",
  "blockchain_average_delegate_participation": "61.21 %",


Am I the only one?