One of the tools I maintain is Tin Toy. It's a docker image for running a tiny Hive testnet on your local computer. With it, you can point your application and test new functionality, without having to broadcast to the mainnet. I just did a refresh on the `develop` branch so you can try out the next hardfork, HF25. It's also a tool that comes in handy for me, when I'm doing [documentation](, because it helps me find new functionality and create tutorials. You'll find that anytime the devportal mentions a testnet, it's going to recommend tintoy. And so for this reason, I feel like this is time well spent when researching and improving the devportal. To try out the hived 1.26.0, right now: ```bash docker run -d -p 8090:8090 inertia/tintoy:develop ``` Then point your app API endpoint at `` --- Tin Toy - A tiny Hive testnet based on [tinman]( # Quickstart ```bash docker run -d -p 8090:8090 inertia/tintoy:latest ``` Using `-p 8090:8090` will expose json-rpc. ... or ... ```bash docker run -d -P inertia/tintoy:latest ``` Using `-P` will expose all of the ports, ephemerally (see below). If you want to modify the scripts before deploying: ```bash git clone tintoy cd tintoy docker build -t myname/tintoy:mybranch . docker run -d -P myname/tintoy:mybranch ``` For example, you can modify the first line of `Dockerfile` to switch versions of `hived`. Tin Toy uses: ```Dockerfile FROM hiveio/hive:latest ``` But you can switch to any branch and try it out. Suggested branches to try can be found in [hive/activity]( Say we want to take a look at a branch like `develop`. Change the first line of the `Dockerfile` to: ```Dockerfile FROM hiveio/hive:develop ``` Then build and run. # Shell In * Use `docker ps` to get the name of the existing container. * Use the command `docker exec -it /bin/bash` to get a bash shell in the container. # How to Use Once the docker container has fully deployed, you'll have access to various port. Internally, the docker container responds to: | Port | Purpose | |------|-----------| | 2001 | p2p | | 8090 | jussi json-rpc | | 8091 | hived json-rpc | | 8092 | hivemind json-rpc | | 5000 | tinman server (if enabled) | If you launched with `-P` (ephemeral ports enabled), you can get a list of ports: ```bash docker ps ``` Which might return something like: ``` CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 290810dba18e inertia/tintoy:latest "/bin/sh -c /app/boo…" 5 minutes ago Up 5 minutes>2001/tcp,>8080/tcp,>8090/tcp,>8091/tcp tintoy ``` ## Default Secret Key Normally, the secret key for a testnet is kept secret. But for a local testnet, there's no reason to keep it a secret. For tintoy, the default secret key is set in the `Dockerfile`: ```bash ENV SHARED_SECRET tintoy ``` Which means, if you want to derive the private keys for `tnman`, you could use the following command: ```bash get_dev_key tintoy owner-tnman active-tnman posting-tnman memo-tnman | jq ``` ```json [ { "private_key": "5K5kjWq8pY23YptZaiEkiiaKi1wafufj63nzAtaDu1epVXw9fvz", "public_key": "TST7uubH7SpknapasQTzW1rFho3LUn1pFmdR7X4f1cHmK22aTJYm3", "account_name": "owner-tnman" }, { "private_key": "5K3NwkFwCnsSfJNACw1qm3zzojWBtP8k4rTb2kbLQ4DDR6TgGnw", "public_key": "TST4w9GXogQtqPprzPhp7WKZPPKWXv4KvqqMMgd5agJQCDtYLBJwA", "account_name": "active-tnman" }, { "private_key": "5Jrdrbt5xfjVeHfHd5JMiJy1FfrGtuieRvzr9WFYhcdHpjgfwPY", "public_key": "TST883nSqJL5KbVgfdV44snPPDTStQQxfR7vj8XttsZo25sXvHAnQ", "account_name": "posting-tnman" }, { "private_key": "5KB3ddeh5o3WghSM3qQaUthxVt7QZWfNYCoiAW3XYfeDki1oH9z", "public_key": "TST56jtUgZrajuBUgdECYaew6cebjSbKWVdtCKkc4xxLAFZQ9f8A9", "account_name": "memo-tnman" } ] ``` Every account on the testnet uses `tnman` as their account authority. Using this account, you can sign any transaction for any account. ## Snapshot Refresh Occasionally, it's a good idea to refresh the `sample-snapshot.json` file. This process is usually only required to be performed by the repo maintainer, but if you want to do it yourself, here are the steps: 1. Install `tinman` by following that product's []( 2. Next, [generate a new snapshot]( * Example: `tinman snapshot -s -o - | pv > snapshot.json` 3. Once we have our new snapshot, create a sample, overwriting the previous one. * Example: `tinman sample -i snapshot.json -o sample-snapshot.json` 4. Delete (or move) `snapshot.json` (we don't need it anymore now that we have `sample-snapshot.json`). </div>

See: Tin Toy - HF25 on a Local Testnet by @inertia