delegate-clayop is updated.

Quote from: lafona on September 24, 2015, 02:45:07 PM

On a side note, the delegate seems to be out of the list of active witnesses,  but has enough votes to be middle of the pack. Any thoughts?

Code Select Expand

{
  "id": "1.6.1531",
  "witness_account": "1.2.22396",
  "last_aslot": 138787,
  "signing_key": "GPH5DCL5nbhL13sXBh1mwQp5pUBSw7rmwjWeiiy5b2Z2UxuYf8spU",
  "pay_vb": "1.13.57",
  "vote_id": "1:1530",
  "total_votes": "9524676529409",
  "url": ""
}


Every hour, only votes of  (new) active witnesses will be updated.

delegate-1.lafona updated.

On a side note, the delegate seems to be out of the list of active witnesses,  but has enough votes to be middle of the pack. Any thoughts?

{
  "id": "1.6.1531",
  "witness_account": "1.2.22396",
  "last_aslot": 138787,
  "signing_key": "GPH5DCL5nbhL13sXBh1mwQp5pUBSw7rmwjWeiiy5b2Z2UxuYf8spU",
  "pay_vb": "1.13.57",
  "vote_id": "1:1530",
  "total_votes": "9524676529409",
  "url": ""
}


I was just testing claiming of genesis collateral positions (those who were short at the time of the snapshot) and discovered a bug that prevented the authority checks from passing.   

I have fixed the bug, but it will require all testing witnesses to upgrade or the test network will fork as soon as someone does something with a usd-collateral-holder-# account. 

Please upgrade your test node as soon possible so I can continue testing this feature without disruption.

Quote from: wuyanren on September 24, 2015, 12:27:39 PM

Quote from: jakub on September 24, 2015, 11:12:13 AM
For the last 12 hours I've been unable to access the GUI on https://graphene.bitshares.org
The browser constantly shows the message  "waiting for graphene.bitshares.org".

mee  too

I just told Valentine, he'll look into it.

Quote from: jakub on September 24, 2015, 11:12:13 AM
For the last 12 hours I've been unable to access the GUI on https://graphene.bitshares.org
The browser constantly shows the message  "waiting for graphene.bitshares.org".

mee  too

For the last 12 hours I've been unable to access the GUI on https://graphene.bitshares.org
The browser constantly shows the message  "waiting for graphene.bitshares.org".

Quote from: abit on September 23, 2015, 07:08:59 PM
For those brave witnesses, I made a patch based on xeroc's price feed script. Enjoy it!

https://github.com/abitmore/python-graphenelib
https://github.com/abitmore/python-graphenelib/blob/master/scripts/pricefeeds.py

Script updated. Fixed BTC precision issue.

Quote from: jakub on September 23, 2015, 08:20:34 PM
Where is the best place to report bugs in the GUI?

https://github.com/cryptonomex/graphene-ui/issues

Create "New Issue"

Where is the best place to report bugs in the GUI?

Quote from: wackou on September 23, 2015, 08:04:09 PM

Quote from: wackou on September 23, 2015, 12:05:44 PM

Quote from: spartako on September 22, 2015, 09:14:11 AM

Quote from: theoretical on September 22, 2015, 05:19:45 AM

Quote from: spartako on September 21, 2015, 11:10:52 PM
What is the best practice for not missing any block during an update?

The update_witness command in CLI wallet allows you to change your witness's block signing key.  This architecture allows several different downtime-free update procedures according to your specific hosting situation:
...

Thanks theoretical! Great work!

+5% indeed, very useful and sounds like a fool-proof way to do it with no risk of signing double blocks.

One question: how long does it take for the signing key to be updated after you call the update_witness command? As soon as the transaction is processed by the network? After the next maintenance interval? Sth else?

I seem to recall that in BitShares 0.9.x changing the signing key did take a bit of time to go into effect, so that set_block_production true/false was the preferred way. If in graphene the call to changing the signing key takes effect immediately, then that's really nice as it's a much better way of doing it.

bump question @theoretical @bytemaster

Instantly

Quote from: wackou on September 23, 2015, 12:05:44 PM

Quote from: spartako on September 22, 2015, 09:14:11 AM

Quote from: theoretical on September 22, 2015, 05:19:45 AM

Quote from: spartako on September 21, 2015, 11:10:52 PM
What is the best practice for not missing any block during an update?

The update_witness command in CLI wallet allows you to change your witness's block signing key.  This architecture allows several different downtime-free update procedures according to your specific hosting situation:
...

Thanks theoretical! Great work!

+5% indeed, very useful and sounds like a fool-proof way to do it with no risk of signing double blocks.

One question: how long does it take for the signing key to be updated after you call the update_witness command? As soon as the transaction is processed by the network? After the next maintenance interval? Sth else?

I seem to recall that in BitShares 0.9.x changing the signing key did take a bit of time to go into effect, so that set_block_production true/false was the preferred way. If in graphene the call to changing the signing key takes effect immediately, then that's really nice as it's a much better way of doing it.

bump question @theoretical @bytemaster

Quote from: puppies on September 23, 2015, 07:02:28 PM
For redundancy I think I will run multiple nodes with different signing keys.  I will then set up a single node to switch signing keys when my witness misses a block.

I feel like that's the way to go in order to have a backup node ready to pop up in case the main witness goes down for some reason. I will do the same, and encourage other witnesses to get familiarized with this way of doing it.

Quote from: bytemaster on September 23, 2015, 12:41:02 PM
jtml - what kind of difficulties are you having at the moment, you have missed quite a few blocks recently.

witness crashed


witness_node: /mon/g/graphene/libraries/fc/src/thread/thread_d.hpp:370: bool fc::thread_d::start_next_fiber(bool): Assertion `std::current_exception() == std::exception_ptr()' failed.


auto start did not work , there was an error when replaying blockchain


Unable to create directories object_database/0
    {"path":"object_database/0","inner":"Dynamic exception type: boost::filesystem::filesystem_error\nstd::exception::what: boost::filesystem::create_directories: Permission denied: \"object_database\"\n"}


After some investigation, I've realized that the problem was in using an absolute path
for --data-dir.  All is written under the given absolute path except object_database, which
is written relative to the current dir (and the proccess did not have write access to that dir)
And it seems that the object_database is not needed and writen during the initial sync,
so the witness was running fine without the need to write to object_database for a while.

Not sure if this could cause the initial crash

The witness is now up and running again.

For those brave witnesses, I made a patch based on xeroc's price feed script. Enjoy it!

https://github.com/abitmore/python-graphenelib
https://github.com/abitmore/python-graphenelib/blob/master/scripts/pricefeeds.py