BitShares Forum
Main => General Discussion => Topic started by: chsln on December 15, 2014, 09:25:17 am
-
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?
-
Also bitsharesblocks seems to have trouble
-
Same here.
Quite unexpected.
Seems like a broken network.
-
Is all the network down then?
it's stuck at block 1268078
-
Same here. What happened?
-
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.
{"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
-
my delegate has stopped producing blocks 40 minutes ago ..
-
Tmd, we also got this problem.
-
:(
-
:(
Looks like my delegate is on a fork:
"blockchain_average_delegate_participation": "27.67 %",
-
{
"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"
}
-
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?
-
:(
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?
-
:(
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).
-
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.... >:( >:( >:(
-
:(
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....
-
:(
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 .
-
I suppose exchanges have stop deposits and withdrawals , can somebody confirm?
-
I'd recommend to shutdown feed publish scripts until further notice .. otherwise you will pay tx fees and fill your tx buffer for nothing :)
-
I suppose exchanges have stop deposits and withdrawals , can somebody confirm?
I confirm Bter has stopped deposits and withdrawals
-
Network alarm~
-
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..
-
I suppose we can do anything about it until a patch release update comes from the devs?
-
I have suspended the Bitshare faucet. Let's hope we can resolve this soon.
-
I suppose we can do anything about it until a patch release update comes from the devs?
Yes, we should wait for patch.
-
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 ....
-
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 !!!
-
what about downgrading to v 0.4.25-RC2 again?
-
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?
-
What damage can be done in the mean time from an attacker? (before the update)
-
what about downgrading to v 0.4.25-RC2 again?
or v0.4.24.1? This is the stable version before the major patches.
-
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
-
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).
-
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
+5%
-
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
-
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
+5% 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...
-
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)
-
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.
-
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.
-
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...
-
+5% 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!
-
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.
-
+5% 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.
-
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...
-
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"
}
-
+5% 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 .
-
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 ..
-
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.
-
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
-
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 ;).
-
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 ..
-
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.
-
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
-
I sent a SMS to Virkam. Not sure if that helps. If possible we need shifts...
-
Maybe there is need a message send to phone of developer automatically,when network is bad
-
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.
-
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.
-
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.
+5%
-
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.
-
It looks like BM is informed about this.
-
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.
-
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
-
I'm am up and working on the issue.
-
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.
+5%
-
I'm am up and working on the issue.
yhea .. seems like i need to stay awake a little longer :)
-
It looks like BM is informed about this.
any thing new ?
-
It looks like BM is informed about this.
any thing new ?
https://bitsharestalk.org/index.php?topic=12300.msg162459#msg162459
:)
-
I'm am up and working on the issue.
+5% +5% +5%
(http://www.thebestbrainpossible.com/wp-content/uploads/2012/09/Ray-of-hope.jpg)
-
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???
-
new commit in github master
-
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?
-
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.
-
new commit in github master
This is an untested commit while we attempt to debug it.
-
@BM .. had the same unconfirmed transactions ..
though .. I tried to do a transaction and it didn't appear in that list .. not sure why
-
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.
-
> 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
-
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
-
Those who feel comfortable helping to debug the issue can you checkout the latest master and see if it enables you to produce blocks.
-
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
-
i recompiled with the patch and started signing again ..
-
though it seems all delegates are signing again ..
-
i recompiled with the patch and started signing again ..
I see blocks!
-
Network has been synced!
-
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?
-
which branch should i syn? master branch?
-
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.
-
which branch should i syn? master branch?
Master
-
spartako,spartako1,spartako2 updated to the master
-
finally .. bed time ..
Being in Australia rocks ... weather-wise .. not when it comes to synchronizing with US and europe .. ;)
-
"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,
-
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.
-
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.