Author Topic: Test Net for Advanced Users  (Read 263692 times)

0 Members and 1 Guest are viewing this topic.

Offline boombastic

  • Sr. Member
  • ****
  • Posts: 251
    • View Profile
    • AngelShares Explorer
After you update new signing key to witness account, the old witness node won't produce blocks 'cause it doesn't have correct key to sign blocks.
http://bitshares.dacplay.org/r/boombastic
Support My Witness: mr.agsexplorer
BTC: 1Bb6V1UStz45QMAamjaX8rDjsnQnBpHvE8

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
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:

(1) Create new witness on new server with new block signing key (you can use suggest_brain_key in CLI wallet, or the get_dev_key binary, to generate a new key).  When the new witness is synced, run update_witness to change your key, shutdown old witness and delete old server.  Good method if you use a pay-by-the-hour hosting provider that lets you quickly create and destroy servers (e.g. DigitalOcean).

...

I think I'll write this up in a wiki article sometime this week

Thanks for the nice writeup and good planning! 

Between the time the new witness just took over signing block and the old witness is still active, is there something to look out for to prevent double signing (ie both old and new witnesses signing block?)
« Last Edit: September 22, 2015, 09:38:49 am by cube »
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline Riverhead

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% Very useful information.

Offline spartako

  • Sr. Member
  • ****
  • Posts: 401
    • View Profile
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!
wallet_account_set_approval spartako

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
All witnesses please upgrade to the latest master.    We have checked in a few "hard-forking" fixes for publishing price feeds.   This hardfork was required due to a misconfigured genesis state for bitassets preventing us from publishing feeds.   Please do not attempt to publish price feeds for at least 24 hours to give all testers a chance to upgrade to the latest.

Fox I voted you in.    The least approved witness is bitcube which as 13M votes...

My witness node was having problem with negative latency values which I suspect my computer's system clock was not working properly.  I sent my PC for repair and just got it back.  I will get the witness node up soon.  Please give bitcube a chance.

I am compiling the latest master and the node should be up soon.

Edit: bitcube witness is updated with the latest master and fully re-synced.  Please vote for bitcube.

p.s.: Latency values are back to positive.

Code: [Select]

634472ms th_a       application.cpp:388           handle_block         ] Got block #97888 with time 2015-09-22T10:10:33 from network with latency of 25101 ms from init8
636002ms th_a       witness.cpp:182               block_production_loo ] Not producing block because it isn't my turn
636526ms th_a       application.cpp:388           handle_block         ] Got block #97889 with time 2015-09-22T10:10:36 from network with latency of 24155 ms from init6
637996ms th_a       application.cpp:518           get_item             ] Serving up block #97889
639429ms th_a       application.cpp:388           handle_block         ] Got block #97890 with time 2015-09-22T10:10:39 from network with latency of 24059 ms from init3

« Last Edit: September 22, 2015, 10:20:19 am by cube »
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline boombastic

  • Sr. Member
  • ****
  • Posts: 251
    • View Profile
    • AngelShares Explorer
Therefore, in the witness server, I should only use the witness signing key to boot up the witness node, but to publish price feed, still need to import owner key/active key to cli_wallet and keep wallet unlock.  Are there any suggestions to make this more secure in case server is compromised?
http://bitshares.dacplay.org/r/boombastic
Support My Witness: mr.agsexplorer
BTC: 1Bb6V1UStz45QMAamjaX8rDjsnQnBpHvE8

Offline boombastic

  • Sr. Member
  • ****
  • Posts: 251
    • View Profile
    • AngelShares Explorer
thanks @theoretical, it's very useful.
http://bitshares.dacplay.org/r/boombastic
Support My Witness: mr.agsexplorer
BTC: 1Bb6V1UStz45QMAamjaX8rDjsnQnBpHvE8

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
Very very nice work theoretical.  Thank you for explaining.  I really like this method of turning block production on and off. Allows me to run two witness nodes and switch back and forth without having to worry about double signing. 
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline theoretical

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:

(1) Create new witness on new server with new block signing key (you can use suggest_brain_key in CLI wallet, or the get_dev_key binary, to generate a new key).  When the new witness is synced, run update_witness to change your key, shutdown old witness and delete old server.  Good method if you use a pay-by-the-hour hosting provider that lets you quickly create and destroy servers (e.g. DigitalOcean).

(2) Create new witness on the same server with new block signing key in different datadir.  When new witness is synced, update_witness to change your block signing key and shut down old witness.  Good method if you have a large server capable of running two witnesses at once (e.g. dedicated host).

(3) Create temporary witness on your own personal machine.  When it is synced, update_witness to change your block signing key and cause the temporary witness to start producing.  Then shut down the old witness and spin up the new witness on the same server; it is okay if it takes some time, because your temporary witness is still signing blocks.  Then when new witness is ready, run update_witness again to change your block signing key back (or create another new key).  Good method if you have a decent personal machine you can occasionally put on witness duty for a few blocks when you're doing an upgrade, and don't want to mess with multiple VPS's as in (1) or pay for a large server as in (2).

Also note that the block signing key can be different from the active and owner keys which control account funds.  The only key which needs to live unencrypted on a machine with 24/7 internet connectivity is the block signing key; if an attacker compromises the server, the only thing they can do with the block signing key is sign blocks.

I designed this system, and my goal was to give witnesses better options for dealing with the various IT headaches of signing blocks in DPOS.

I just gave update_witness quite a real-world test on this testnet -- I initially ran all of the init witnesses in a single process on the cloud server that I used to create the testnet, then bytemaster and I migrated a bunch of them to different machines within the first day.  In prepping them for the hardfork, I've had to shut down and re-create the witnesses, and also migrated them to better balance them between the multiple machines.  I used the update_witness command for all of this and achieved it with minimal downtime.  In particular for today's hardfork upgrade, I had no downtime on block signing during the upgrade / migration, even though I had to upgrade 8 witnesses on multiple machines, and I also migrated some of those witnesses to better balance them between machines.  The update_witness code and its supporting logic in the block production loop are rock solid!

Some of my init witnesses have been down, but that's mostly due to issues in the p2p layer, the worst of which are resolved in the latest code.

I think I'll write this up in a wiki article sometime this week
« Last Edit: September 22, 2015, 05:26:15 am by theoretical »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline Fox

What is the minimum hardware requirement to participate in the testnet?
Seed node (stable): Shared CPU, 768MB RAM
Witness node (stable): 2 Cores, 3.5GB RAM

I attempted to run the witness node on the lower specs VPS, but the node would not reliably produce blocks, so I returned to Witness node (stable) specs above. 
Witness: fox

Offline roadscape

roadscape is updated, but seems to have been voted out.
http://cryptofresh.com  |  witness: roadscape

Xeldal

  • Guest

Offline Riverhead


riverhead is updated.

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
What is the minimum hardware requirement to participate in the testnet?

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
dele-puppy is updated.  A means of turning block production on and off within the witness node would be really useful for upgrading. 
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads