BitShares Forum
Main => Stakeholder Proposals => Topic started by: dannotestein on December 17, 2014, 08:21:26 am
-
Update, use client below for best results:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1
Some (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).
Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.
Also, as per msgs further down in this thread, if you fail to get on correct fork, you can force it using this method from testz:
If as delegate you have a problem to sync to right chain, you should move to 0.4.27.1 and add following lines to checkpoints.json at data directory:
Quote
],[
1279500,
"488313d2c1c85bdec117bac0379f7b17f7cfbed3"
],[
1283300,
"cef871ef96c687b4841b02a7643c2a90d6c46bd1"
],[
1283590,
"d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
]
I mark as bold the lines which present in original file.
After this you should re-index the database.
-
on the way !!!
-
upgraded to 0.4.27
-
my seed node 185.25.22.21:1776 is on the right fork....
(wallet closed) >>> info
{
"blockchain_head_block_num": 1283659,
"blockchain_head_block_age": "6 seconds old",
"blockchain_head_block_timestamp": "2014-12-17T09:13:30",
"blockchain_average_delegate_participation": "65.58 %",
"blockchain_confirmation_requirement": 76,
"blockchain_share_supply": "2,498,424,447.19030 BTS",
"blockchain_blocks_left_in_round": 51,
"blockchain_next_round_time": "at least 8 minutes in the future",
"blockchain_next_round_timestamp": "2014-12-17T09:22:00",
"blockchain_random_seed": "03d4d1e27e7d8027c9182138b552da4ccbe733a4",
"client_data_dir": "/root/.BitShares",
"client_version": "v0.4.26",
"network_num_connections": 78,
"network_num_connections_max": 200,
-
Some (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).
Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.
Are you part of the official dev team?
-
just to keep this thread on the first places ...
(wallet closed) >>> info
{
"blockchain_head_block_num": 1283702,
"blockchain_head_block_age": "28 seconds old",
"blockchain_head_block_timestamp": "2014-12-17T09:23:50",
"blockchain_average_delegate_participation": "64.74 %",
"blockchain_confirmation_requirement": 71,
"blockchain_share_supply": "2,498,424,750.89030 BTS",
"blockchain_blocks_left_in_round": 8,
"blockchain_next_round_time": "at least 72 seconds in the future",
"blockchain_next_round_timestamp": "2014-12-17T09:25:30",
"blockchain_random_seed": "0d395d1024ac74ebe6a3725cacc0dfb358b02dfc",
"client_data_dir": "/root/.BitShares",
"client_version": "v0.4.26",
"network_num_connections": 77,
"network_num_connections_max": 200,
-
Some (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).
Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.
Are you part of the official dev team?
yes he is.
http://bitshares.org/team/
-
If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:
],[
1279500,
"488313d2c1c85bdec117bac0379f7b17f7cfbed3"
],[
1283300,
"cef871ef96c687b4841b02a7643c2a90d6c46bd1"
],[
1283590,
"d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
]
I mark as bold the lines which present in original file.
After this you should re-index the database.
-
If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:
],[
1279500,
"488313d2c1c85bdec117bac0379f7b17f7cfbed3"
],[
1283300,
"cef871ef96c687b4841b02a7643c2a90d6c46bd1"
],[
1283590,
"d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
]
I mark as bold the lines which present in original file.
After this you should re-index the database.
good idea, testz, that will make sure the client moves to the proper fork.
-
If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:
I have no file called checkpoints.json
-
If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:
I have no file called checkpoints.json
Oh, it gets created when you run the client... which means you are forced to re-index once and then again if it doesn't work.
-
If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:
I have no file called checkpoints.json
Oh, it gets created when you run the client... which means you are forced to re-index once and then again if it doesn't work.
Yes, first time my 0.4.27 goes to wrong chain then I modify checkpoint.json and re-index.
-
If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:
I have no file called checkpoints.json
Oh, it gets created when you run the client... which means you are forced to re-index once and then again if it doesn't work.
Yes, first time my 0.4.27 goes to wrong chain then I modify checkpoint.json and re-index.
./bitshares_client --rebuild-index
-
Here is the output of my delegate after update to 0.4.27 and --resync-blockchain (and I've deleted everything in data-dir except wallet):
I am disconnecting peer 84.238.140.192:42577 for reason: You offered us a block that we reject as invalid
(wallet closed) >>> info
{
"blockchain_head_block_num": 1283490,
"blockchain_head_block_age": "2 minutes old",
"blockchain_head_block_timestamp": "2014-12-17T11:40:40",
"blockchain_average_delegate_participation": "17.18 %",
"blockchain_confirmation_requirement": 303,
"blockchain_share_supply": "2,498,424,296.59030 BTS",
"blockchain_blocks_left_in_round": 18,
"blockchain_next_round_time": "at least 3 minutes in the future",
"blockchain_next_round_timestamp": "2014-12-17T11:45:50",
"blockchain_random_seed": "9fd5828f7cc87cbf48c62745c4a6181510072306",
"client_data_dir": "/home/emski/bitsharesAltDelegate/bitshares/programs/client/dd",
"client_version": "v0.4.27",
"network_num_connections": 9,
"network_num_connections_max": 200,
"network_chain_downloader_running": false,
"network_chain_downloader_blocks_remaining": null,
"ntp_time": "2014-12-17T11:42:50",
"ntp_time_error": 0.0055840000000000004,
"wallet_open": false,
"wallet_unlocked": null,
"wallet_unlocked_until": null,
"wallet_unlocked_until_timestamp": null,
"wallet_last_scanned_block_timestamp": null,
"wallet_scan_progress": null,
"wallet_block_production_enabled": null,
"wallet_next_block_production_time": null,
"wallet_next_block_production_timestamp": null
}
[13:43:35] Emil Velichkov: this is with the checkpoints
[13:43:50] Emil Velichkov: note that 84.238.140.192:42577 is the seed node which is on the right chain
[13:44:18] Emil Velichkov: so checkpoints and --resync-blockchain does NOT work
-
1283481 2014-12-17T11:33:40 backbone.riverhead 0 166 544 0.002572 d310b14962c87e4a97600e6f6b6d0d72e6039cad
you are signing the wrong chain
[13:49:25] Emil Velichkov: crazibyt, chinesecommunity, bm.payroll.riverhead, rose.ebit, titan.crazybit
[13:49:59] Emil Velichkov: including x.ebit
[13:50:00] Emil Velichkov: fox
[13:50:15] Emil Velichkov: *.helloworld
[13:50:23] Emil Velichkov: del0.cass
[13:50:29] Emil Velichkov: marketing.methodx
[13:50:59] Emil Velichkov: riverhead-del-server-1
[13:51:30] Emil Velichkov: anchor.crazybit
[13:52:00] Emil Velichkov: dc-delegate
[13:52:20] Emil Velichkov: there are still seed nodes on the forked chain and some delegates actively producing blocks there
[13:53:04] Emil Velichkov: if someone can reach out the the above-mentioned delegates that would be cool
-
[13:44:18] Emil Velichkov: so checkpoints and --resync-blockchain does NOT work
Confirmed !
-
when run : ./bitshares_client
------------ error --------------
10 assert_exception: Assert Exception
_map->is_open(): Database is not open!
{}
th_a level_map.hpp:305 commit
error applying batch
{}
th_a level_map.hpp:314 commit
{}
th_a cached_level_map.hpp:52 flush
{}
th_a cached_level_map.hpp:28 close
{}
th_a chain_database.cpp:1485 close
{"data_dir":"/root/.BitShares/chain"}
th_a chain_database.cpp:1434 open
{"data_dir":"/root/.BitShares"}
th_a client.cpp:1365 open
-
if you delete "chain" folder this message will not show again if I am right ;)
PS make a restart and try again before you take my advice (maybe you save the resync time)
-
Thanks,I will try
-
I had a backup server come online after a restart. The situation has been corrected and updated to not repeat.
-
1283481 2014-12-17T11:33:40 backbone.riverhead 0 166 544 0.002572 d310b14962c87e4a97600e6f6b6d0d72e6039cad
you are signing the wrong chain
[13:49:25] Emil Velichkov: crazibyt, chinesecommunity, bm.payroll.riverhead, rose.ebit, titan.crazybit
[13:49:59] Emil Velichkov: including x.ebit
[13:50:00] Emil Velichkov: fox
[13:50:15] Emil Velichkov: *.helloworld
[13:50:23] Emil Velichkov: del0.cass
[13:50:29] Emil Velichkov: marketing.methodx
[13:50:59] Emil Velichkov: riverhead-del-server-1
[13:51:30] Emil Velichkov: anchor.crazybit
[13:52:00] Emil Velichkov: dc-delegate
[13:52:20] Emil Velichkov: there are still seed nodes on the forked chain and some delegates actively producing blocks there
[13:53:04] Emil Velichkov: if someone can reach out the the above-mentioned delegates that would be cool
Aren't they supposed to be fired for this? Lol
-
Aren't they supposed to be fired for this? Lol
The developers that introduced the forking code to make the network more robust or the delegates who are quickly adapting to keep the network running while the kinks are worked out?
Who would you have replace them that you think would do a better job?
-
Aren't they supposed to be fired for this? Lol
The developers that introduced the forking code to make the network more robust or the delegates who are quickly adapting to keep the network running while the kinks are worked out?
Who would you have replace them that you think would do a better job?
Everyone is doing their best to get it working. There is no need to fire anyone. :)
-
Even though these delegates were informed about the dangers of multiple chain block signing
and about the flaws of current public automated delegate backup system implementations they still used it.
Perhaps this should be made a bit more clear.
Anyway it looks like everyone is working to resolve the issues and there is no harm done.
-
Even though these delegates were informed about the dangers of multiple chain block signing
and about the flaws of current public automated delegate backup system implementations they still used it.
I agree. However multiple chain block signing is a real risk now that version updates are longer than round times. In my case today the double signing was due to efforts to have the delegate survive a full machine crash and/or reboot by the vendor. Sadly it worked =/. I have it disabled on the backup VPS and only enabled on the live VPS.
To further prevent this from happening again I have moved the wallets directory out of the data-dir so even if it comes online it won't try to sign blocks.
-
We think we understand what has been causing the network to fork repeatedly over the past 12 hours or so. We're currently working on implementing a fix. We prefer not to publicly explain what's going on until the fix is released.
-
We think we understand what has been causing the network to fork repeatedly over the past 12 hours or so. We're currently working on implementing a fix. We prefer not to publicly explain what's going on until the fix is released.
Sounds juicy!
-
Sounds juicy!
In this case, it's more of an abundance of caution. I personally don't think this bug is exploitable (or at any rate that exploitation will be able to do anything worse than what's already happening naturally). But we're still waiting until the fix is released to discuss details.
-
I have a working fix in place. There is no security issue.
The issue involves false positives on duplicate transactions when switching from a "short fork" to the "long fork" because our cache of "known transaction ids" wasn't properly cleared when unwinding the short fork. When attempting to apply the longer fork it failed due to "duplicate transaction". This means that what use to be a "small issue" of a single missed block could turn into a "large issue" of delegates going down two different paths.
We also have the issue that some delegates have automatic backup nodes that prevent them from missing blocks. These backup nodes would activate after they went down a different fork than the master and thus both forks add a cumulative participation greater than 100%. As a result we produced a few very long (longer than 404 blocks) minority forks. These long minority forks exceeded the undo history which meant that once your client went down that minority fork it was a dead end with no turning back except to attempt a fresh download of the entire chain.
We have put in a fix for the false positive issue and increased the undo history to 1616 blocks. Delegates should upgrade to help reduce forking. This is not a required upgrade for end users, but it will help them get on the right fork.
-
When will we have a stable client where there will not be an update every 24 hours? I may just wait to update my personal wallet until 1.0 is released.
-
When will we have a stable client where there will not be an update every 24 hours? I may just wait to update my personal wallet until 1.0 is released.
Light weight wallet will not require updates. One month or so.
-
I deleted my chain and peer dbs, then redownloaded the chain on 0.4.27:
Machine 1 (0.4.27):
--- in sync with p2p network
(wallet closed) >>> info
{
"blockchain_head_block_num": 1283018,
"blockchain_head_block_age": "13 hours old",
"blockchain_head_block_timestamp": "2014-12-17T06:27:10",
"blockchain_average_delegate_participation": "2.18 %",
"blockchain_confirmation_requirement": 1,
"blockchain_share_supply": "2,498,420,479.09030 BTS",
"blockchain_blocks_left_in_round": 86,
"blockchain_next_round_time": "at least 14 minutes in the future",
"blockchain_next_round_timestamp": "2014-12-17T19:14:50",
"blockchain_random_seed": "9c8436243078d56f4ca9216c8233a7758d084452",
"client_data_dir": "/home/showard/.BitShares",
"client_version": "v0.4.27",
"network_num_connections": 8,
"network_num_connections_max": 200,
"network_chain_downloader_running": false,
"network_chain_downloader_blocks_remaining": null,
"ntp_time": "2014-12-17T19:00:32",
"ntp_time_error": 0.0020690000000000001,
"wallet_open": false,
"wallet_unlocked": null,
"wallet_unlocked_until": null,
"wallet_unlocked_until_timestamp": null,
"wallet_last_scanned_block_timestamp": null,
"wallet_scan_progress": null,
"wallet_block_production_enabled": null,
"wallet_next_block_production_time": null,
"wallet_next_block_production_timestamp": null
(wallet closed) >> blockchain_list_forks
FORKED BLOCK FORKING BLOCK ID SIGNING DELEGATE TXN COUNT SIZE TIMESTAMP LATENCY VALID IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
1283018
11afe1649155b854b5bb3c69021a39151df5ef12 bm.payroll.riverhead 4 1572 2014-12-17T06:27:20 45172 NO NO
ec9e8670a9099bb830fe1275298ca03b1b10c555 emski 2 998 2014-12-17T06:27:40 45153 NO NO
REASONS FOR INVALID BLOCKS
11afe1649155b854b5bb3c69021a39151df5ef12: 30007 duplicate_transaction: duplicate transaction
{"trx_id":"0b37cd2a4dc1c10ae1ecb7bb44b0af30aaf778b6"}
th_a transaction_evaluation_state.cpp:212 evaluate
{"trx":{"expiration":"2014-12-17T07:34:30","delegate_slate_id":null,"operations":[{"type":"update_feed_op_type","data":{"feed":{"feed_id":4,"delegate_id":14872},"value":{"ratio":"0.045095236539076448","quote_asset_id":4,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":14,"delegate_id":14872},"value":{"ratio":"0.00922438485977705","quote_asset_id":14,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":7,"delegate_id":14872},"value":{"ratio":"0.000124300399590475","quote_asset_id":7,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":22,"delegate_id":14872},"value":{"ratio":"0.001489678120825724","quote_asset_id":22,"base_asset_id":0}}},{"type":"withdraw_pay_op_type","data":{"amount":50000,"account_id":14872}}],"signatures":["1f3b48e355cd4086284045565a299fe46e514cdbe69e2b2147b5f16ea3f22fa8ab4832a7bd4d28527f202a0a8fcb47578d8deaeb8bf769955b0bdcd4a504d07214"]}}
th_a transaction_evaluation_state.cpp:244 evaluate
{"trx_num":0}
th_a chain_database.cpp:729 apply_transactions
ec9e8670a9099bb830fe1275298ca03b1b10c555: 30007 duplicate_transaction: duplicate transaction
{"trx_id":"9273cbde64d4edde9103776c723cf59665af4f71"}
th_a transaction_evaluation_state.cpp:212 evaluate
{"trx":{"expiration":"2014-12-17T07:34:43","delegate_slate_id":null,"operations":[{"type":"update_feed_op_type","data":{"feed":{"feed_id":4,"delegate_id":18766},"value":{"ratio":"0.045084141539375624","quote_asset_id":4,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":14,"delegate_id":18766},"value":{"ratio":"0.00922686315058886","quote_asset_id":14,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":7,"delegate_id":18766},"value":{"ratio":"0.000124323783549378","quote_asset_id":7,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":22,"delegate_id":18766},"value":{"ratio":"0.001490020525769598","quote_asset_id":22,"base_asset_id":0}}},{"type":"withdraw_pay_op_type","data":{"amount":50000,"account_id":18766}}],"signatures":["1f6616c9788206f632eae3154714ca09fcf367c8511cd56129f530449f674ac86022bb4cd0b4993fda63b4420f21d7a714626bb7b31f91ba8bbb3196a9ae0b18b6"]}}
th_a transaction_evaluation_state.cpp:244 evaluate
{"trx_num":0}
th_a chain_database.cpp:729 apply_transactions
}
but it seems to still be on the fork (compared to another machine)
Machine 2 (0.4.26):
default (unlocked) >>> info
{
"blockchain_head_block_num": 1286385,
"blockchain_head_block_age": "1 second old",
"blockchain_head_block_timestamp": "2014-12-17T19:03:40",
"blockchain_average_delegate_participation": "72.66 %",
"blockchain_confirmation_requirement": 7,
"blockchain_share_supply": "2,498,439,830.19030 BTS",
"blockchain_blocks_left_in_round": 52,
"blockchain_next_round_time": "at least 9 minutes in the future",
"blockchain_next_round_timestamp": "2014-12-17T19:12:20",
"blockchain_random_seed": "6e6343e36995b304269ba0bf45dfb9078c36c098",
"client_data_dir": "/home/showard/.BitShares",
"client_version": "v0.4.26",
"network_num_connections": 10,
"network_num_connections_max": 10,
"network_chain_downloader_running": false,
"network_chain_downloader_blocks_remaining": null,
"ntp_time": "2014-12-17T19:03:41",
"ntp_time_error": 0.00090200000000000002,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "3 years 2 months in the future",
"wallet_unlocked_until_timestamp": "2018-02-13T03:46:55",
"wallet_last_scanned_block_timestamp": "2014-11-12T00:42:40",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "49 seconds in the future",
"wallet_next_block_production_timestamp": "2014-12-17T19:04:30"
-
@maqifrnswa, Try https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1
-
Updated to v0.4.27. I am fortunate not to have chain issue.
-
Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?
-
FYI, for anyone running a windows delegate (yes, there are some out there), I've added a Windows installer for 0.4.27.1 here:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1
-
FYI, for anyone running a windows delegate (yes, there are some out there), I've added a Windows installer for 0.4.27.1 here:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1
Thanks. Reindexing now, and my standby delegate has been updated.
-
Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?
That is a delegate issue based upon their use of their custom software. It should be a fireable offense to produce on more than one chain.
-
Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?
That is a delegate issue based upon their use of their custom software. It should be a fireable offense to produce on more than one chain.
This was discussed several times before.
Can this be made sticky and/or explicitly stated in a new thread.
-
I have update to 0.4.27.1, but offen stop sync. here is some information
stop at block 1288364
"blockchain_head_block_num": 1288364,
"blockchain_head_block_age": "12 minutes old",
"blockchain_head_block_timestamp": "2014-12-18T01:54:20",
"blockchain_average_delegate_participation": "52.33 %",
there is a fork at here
1288363
1e52304898b7e133a3c5f70e28fc2e98642d98b4 bitsharesx-delegate 4 4042 2014-12-18T01:54:20 0 YES NO
44bd8acf6b7d9f6a11158c8a87652b1e2a29f739 black-widow 3 3798 2014-12-18T01:54:30 0 N/A NO
and from the log file, it can't find block 1288364 at database
2014-12-18T01:54:40 th_a:invoke handle_message switch_to_fork ] pop 1e52304898b7e133a3c5f70e28fc2e98642d98b4 chain_database.cpp:693
2014-12-18T01:54:40 th_a:invoke handle_message push_block ] fork permanently rejected as it has permanently invalid block chain_database.cpp:1745
2014-12-18T01:54:40 p2p:message read_loop process_block_during ] Successfully pushed block 1288365 (id:75bda8624c5b6d389683a549701cccd55762ea2a) node.cpp:3050
2014-12-18T01:54:41 p2p:message read_loop read_loop ] message transmission failed 6 key_not_found_exception: Key Not Found
unable to find key 1288364
{"key":1288364}
th_a level_map.hpp:102 fetch
error fetching key 1288364
{"key":1288364}
th_a level_map.hpp:112 fetch
{"block_num":1288364}
th_a chain_database.cpp:1647 get_block message_oriented_connection.cpp:165
2014-12-18T01:54:41 p2p:message read_loop read_loop ] disconnected 6 key_not_found_exception: Key Not Found
I have to restart client, then it can sync again.
-
Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?
That is a delegate issue based upon their use of their custom software. It should be a fireable offense to produce on more than one chain.
Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.
-
Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?
That is a delegate issue based upon their use of their custom software. It should be a fireable offense to produce on more than one chain.
Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.
Why don't you just try to theoretically explain the delegate backup system first?
-
Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?
That is a delegate issue based upon their use of their custom software. It should be a fireable offense to produce on more than one chain.
Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.
.
Why don't you just try to theoretically explain the delegate backup system first?
Sorry Emski, I didn't see this question until now. What happened with my delegate wasn't an automated backup system. Currently I have no scripts in place that detect one node missing blocks to enable another. I have ideas about that but have been too afraid of signing on two chains (ya, I know :P ). What happened the other night was a setup designed to survive a reboot kicked in when the instance rebooted. The scripts didn't have a check to see if the node was active before reboot. I have since moved the wallet directory to wallet.standby so that the node can still stay in sync without risk of it becoming unlocked.
It was a stupid oversight and I've paid for it; both literally and figuratively.
-
Delegate updated to v0.4.27.1
I had some issues with sending funds to publish feeds but all is well again 8)