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

0 Members and 1 Guest are viewing this topic.

Offline Riverhead


Stupid question: How do I create an account in the GUI? I've tried importing a .json and creating an account with the "Create Account" button. Does it need to be done via the Javascript CLI? I feel like I'm missing something obvious - hopefully not as bad as my IP address typo but....

Update: Seems this is a Firefox issue (at least my copy). Chrome displayed the two password fields as expected but still returns the same error.

« Last Edit: September 22, 2015, 06:23:18 pm by Riverhead »

Offline bytemaster

do you have to enable stale block production to produce blocks?
Don't enable that

Stale production is only required to bootstrap a dead chain, but should never be used with a live chain.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
do you have to enable stale block production to produce blocks?
Don't enable that
BitShares committee member: abit
BitShares witness: in.abit

clout

  • Guest
do you have to enable stale block production to produce blocks?

Offline betax

  • Hero Member
  • *****
  • Posts: 808
    • View Profile
Very good procedure, one question how do you get the WIF key for the blockchain signing key?

You can create with a command in the cli_wallet: suggest_brain_key

Import that private key and update your config.ini on the new witness. Fire up the new witness and once sync'd update_witness <name> <public key from above> true

I missed the update to the config.ini which is why I was down for a few minutes.

Thanks, @Riverhead all clear now.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
If you're looking for more witnesses
maqifrnswa is online
witness id 1.6.3184
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
This morning I came in to find all 3 of the nodes I run having issues.  I am looking into the cause.   After the successful run yesterday I am confident we are very close to eliminating all of the edge cases.

Will update things soon.

It looks like all of my nodes went down because they got into an inconsistent blockchain state regarding a vesting balance object.  A replay of the blockchain fixed it.

(Anyone notice how much faster replaying the  blockchain is with 1 hour maitenance intervals??!! )
Maybe same issue as my nodes encountered. I did resync. Will try replay next time (if happen again).
BitShares committee member: abit
BitShares witness: in.abit

Offline Riverhead

Very good procedure, one question how do you get the WIF key for the blockchain signing key?

You can create with a command in the cli_wallet: suggest_brain_key

Import that private key and update your config.ini on the new witness. Fire up the new witness and once sync'd update_witness <name> <public key from above> true

I missed the update to the config.ini which is why I was down for a few minutes.

Offline bytemaster

This morning I came in to find all 3 of the nodes I run having issues.  I am looking into the cause.   After the successful run yesterday I am confident we are very close to eliminating all of the edge cases.

Will update things soon.

It looks like all of my nodes went down because they got into an inconsistent blockchain state regarding a vesting balance object.  A replay of the blockchain fixed it.

(Anyone notice how much faster replaying the  blockchain is with 1 hour maitenance intervals??!! )
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

This morning I came in to find all 3 of the nodes I run having issues.  I am looking into the cause.   After the successful run yesterday I am confident we are very close to eliminating all of the edge cases.

Will update things soon.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline betax

  • Hero Member
  • *****
  • Posts: 808
    • 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:

(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

Very good procedure, one question how do you get the WIF key for the blockchain signing key?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Riverhead

Botched an update migrating to a dedicated hosted server. Should be back up in a minute. Producing again.
« Last Edit: September 22, 2015, 12:16:39 pm by Riverhead »

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
My witnesses got out of sync 2 hours ago. Restart didn't fix it. Resyncing.
Will check the logs.

//Update:
1. resync worked.
2. issue submitted https://github.com/cryptonomex/graphene/issues/336
« Last Edit: September 22, 2015, 12:13:23 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline jtme

jtm1 updated to the latest master

Offline cube

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

This is cool! It makes upgrading witness safer to execute.  +5%
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.