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](https://peakd.com/c/hive-139531/search?q=devportal), 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 `http://127.0.0.1:8080`
---
Tin Toy - A tiny Hive testnet based on [tinman](https://gitlab.syncad.com/hive/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 https://gist.github.com/b88e7bfff8862858e54c59392e2bce20.git 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](https://gitlab.syncad.com/hive/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 0.0.0.0:32832->2001/tcp, 0.0.0.0:32831->8080/tcp, 0.0.0.0:32830->8090/tcp, 0.0.0.0:32829->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 [README.md](https://gitlab.syncad.com/hive/tinman#installation).
2. Next, [generate a new snapshot](https://gitlab.syncad.com/hive/tinman#taking-a-snapshot).
* Example: `tinman snapshot -s https://anyx.io -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
