TestNet Update Released (December 13)

#1

The latest release is now available as of 10:30am EST. We’re waiting for the network to start now that enough stake has updated.
With this release, we’ve generated 20 additional genesis wallets with .1% stake. If you don’t have a wallet and would like one (they survive, but reset, when new genesis blocks are generated), email testnet@algorand.com (provide your node’s host name - from ‘goal logging’).

The relevant updates in this release are:

  • Added more testnet wallets, with .1% stake; changed allocations across the board
  • stdout and stderr output from algod now captured to algod-out.log and algod-err.log
  • Fix network stalling bug introduced in last testnet release
  • Fixed resource leak when disconnecting peers
  • REST API calls now return http status code for failed auth
  • Allow /debug REST API to be called with Header-based token
  • Adding Swagger Support (curl localhost:8080/swagger.yaml) returns swagger.yaml file for current REST API
  • Rewards/incentives are now disabled so transferring large amounts of stake will no longer stall the network (we are fixing rewards and re-enable when ready)
  • Add -d option to carpenter (carpenter -d <datadir>) is short for carpenter -file <datadir>/latest.log
  • Fixed bug causing non-controlled shutdown when stopping the node – resulted in algod-* files to not get cleaned up
  • Changed clerk send’s default -n / --note behavior to expect plaintext (new --noteb64 should be used to pass encoded bytes)
  • Fixed bug in telemetry - we were filtering log history for some errors
  • Added support for Time- and Participation-based account locks
  • Consolidated REST API code that outputs account lists so they use the same format
  • Rationalized our message encoding strategy with msgpack and go-codec (standardized on standard base64 encoding in our REST APIs)
  • Fixed goal account --name panic, and fixed implementation
#2

Hi David, Can you pls explain this problem and how it is getting fixed.

Cheers

#3

Hi Rajesh - Sorry for the delay. I thought I had replied, but just noticed that I didn’t.

The problem was a design flaw around balances used for computing rewards for claiming them, and balances used for computing rewards when awarding them. There was a mismatch in balances used which caused us to treat a block as invalid because the claimed didn’t match the expected earned rewards.

I can’t detail how it’s being fixed yet. We’ll release those details at a later time.