Whippet is an experimental blockchain forked from Dogecoin, designed to test faster block emisssion consensus without affecting the mainnet. It is not a real coin.

Why create an experimental blockchain?

To answer three questions: what would a six-second blocktime look like, will orphan chains be a problem with the lower difficulty required for these speeds, and how would this work with merge mining?

How is Whippet different from Dogecoin?

Dogecoin is real. Whippet is not. Also, Whippet implements experimental consensus rules (faster blocks, smaller subsidies, a different difficulty adjustment mechanism).

Can I run Whippet locally?

Yes. You can build from source (Ubuntu 25.04 worked fine) or use Docker (builds for Ubuntu 24.04).

Is this safe for testing?

Yes. Whippet is an isolated experimental chain with no real-world value. It's designed specifically for sandbox testing of blockchain mechanics. The server may go up and down, chain may get reset, you may lose your work.

How do I mine blocks on Whippet?

Use the included contrib/mine-blocks.py script with a JSON configuration file specifying target addresses. The script supports optional transaction injection and configurable block intervals.

A Throwaway Blockchain Speed Experiment

Whippet: A Throwaway Experimental Blockchain

Cryptocurrency should be currency; you should be able to use it like money. I believe this, and that’s why I work on Dogecoin.

Over the holiday break I thought about electronic payments. In a previous job I worked on a payment rewards system where, when you tap your payment card, you’d get rewards in your inbox, app, even back on your card within a couple of heartbeats of the network accepting your payment.

Scaling that project (and working with payment networks) taught me a lot. That user experience of swiping or tapping a card and getting real-time feedback was exciting! I’ve never had the same feeling from waiting 10 minutes for a Bitcoin transaction to be mined (or an hour for confirmation). Imagine waiting even one minute for your pinball machine payment to register.

I want instant feedback.

What if Dogecoin blocks mined 10x faster? That’s, on average, every 6 seconds instead of every 60. What would that look like? How would that work? Given network hash rates in 2026 compared to 2011, would that create a huge mess? Would that bloat the chain?

I decided to figure out. Hey, these winter nights are long in the frozen north! So I created Whippet, a forked experimental blockchain based on Dogecoin with a handful of changes.

This taught me a lot. The idea may go nowhere, and I’m not sure if I want to take the code any further (but I have ideas). So far I’m learning things.

Why Build This?

Three concrete problems:

Blocks could be faster. Sure, there are L2 protocols and mechanisms and that’s probably smart, but I wanted to see what a faster L1 would look like.
Historical baggage in the code. Dogecoin’s original commits are old, and the code has a lot of assumptions on blockchain maturity that a new chain has to abandon.
Difficulty adjustments. I don’t want to rent a datacenter’s worth of ASICs to test mining blocks. I’ll throw Python or Perl or JavaScript or C++ at it on my laptop. But I also want other people to play with the chain so we can simulate chain forks.

Hacking around rules and disrupting the Dogecoin test net wouldn’t be polite or help. Fortunately, it’s possible to fork the Dogecoin code. Unfortunately (or maybe not), it’s a painful experience.

What I Changed

Even getting to the point where I had code running was an effort. In theory you can run a find-and-replace on the string “Dogecoin” in its various forms to a new name, but that’s a lot of churn in code, and possibly illegal (certainly immoral) to change copyright text. This is the easy part.

Other guides and tutorials explain how each new blockchain needs its own special magic constants, port numbers, and genesis block. This is all true, and it’s not the easy part. If you care about the test suite passing, as I do, every change to one of these values runs you right into 15+ years of assumptions hard-coded into test files and data.

As I understand from Zordiak, developer of Pepecoin, this could be hours or months of work. (To my credit, I warned him about that when he first started. To his credit, he did it anyway.)

The hardest part was rewriting consensus rules. These are the immutable agreements between nodes about what makes a transaction valid, what makes a block valid, et cetera.

I knew I wanted blocks to be fast, so I worked on ideas to set the difficulty level of blocks such that they average about 6 seconds between them. I also added code to reject blocks mined too quickly. This is a controversial idea and may prove terrible, in fact. This is my second biggest worry, that the blockchain will fork because of time differences between nodes and quickly spiral into incompatibilities. Given that time is an external resource which could be different between computers (and given propagation times between nodes), this is the biggest technical risk of the project.

Obviously it’s important to dive right into understanding that big technical risk, so here we go.

(What’s my first biggest worry? That this gets away from me and people take it seriously, so again with the disclaimer: this is a throwaway experiment. If you’re a writer for a crypto news site, please read this disclaimer out loud ten times, then get a big glass of water and take ten deep breaths.)

In practice, enforcing this rule means rejecting block candidates. Here’s output from the mining script showing that rejection in action. Miners need to catch this error and resubmit blocks with better timestamps:

4775     2026-01-04 10:09:27  4.161        0.0          0.000001       
  [Retry 1/5] RPC error: CreateNewBlock: TestBlockValidity failed: bad-time-too-early (code 16) (-1)
  [Retry 2/5] RPC error: CreateNewBlock: TestBlockValidity failed: bad-time-too-early (code 16) (-1)
  [Retry 3/5] RPC error: CreateNewBlock: TestBlockValidity failed: bad-time-too-early (code 16) (-1)

If this were real and not a throwaway experiment, would this need hardening? Likely!

Silly Mistakes

I did make a few silly mistakes, as you’d expect.

First, I didn’t change the version number from 1.14.99 to something new like 0.1.0. This meant my first few blocks mined in wallets were invalid because the wallet refused to downgrade when I fixed the version number. Either I could redo a night’s worth of mining (remember, I want instant gratification) or find a way to hack the wallet and/or validation code so that I could migrate the wallet version.

I opted for wallet migration so I’d have more time to lose Mario Kart World Knockout Tour races.

Second, I realized that compiling the binaries on my laptop and deploying them to my VPS was a mess of library version mismatches. There’s a reason release builds go though a complex Gitian process! I ended up checking in a Dockerfile that builds a binary suitable for Ubuntu 24.04, which works on my server.

Finally, I ended up regenerating the Genesis block (the first block mined; the “Nintondo” block in Dogecoin) more times than I can remember. I let the LLM talk me into generating it with a dedicated C++ program, and it had endiannness problems. I stared at test failures for a while before realizing the problems.

Mining Tools

For my ease of testing, I decided to use CPU mining. The distribution includes a file contrib/mine-blocks.py which mines blocks via RPC calls to a running node. I left this running overnight a couple of times to generate enough blocks to sync between my two nodes. See the file and its documentation for more information.

If you’re a developer or technically savvy, you can use this script to mine blocks too. I’d like feedback if you do. Even if I take down this whole thing by mid-January 2026, the data we can generate will provide interesting.

Try It Locally

Here’s what the LLM summarized from my build process.

Prerequisites

Linux (Ubuntu 24.04 tested) or Docker.
Build toolchain: Boost, Qt, BerkeleyDB, autotools.

Build with Docker

docker build -f Dockerfile.ubuntu24.04 -t whippet-build:ubuntu24 .
mkdir -p build && docker run --rm \
  -v "$PWD":/src \
  -v "$PWD"/build:/build \
  whippet-build:ubuntu24

Result: whippetd and whippet-cli in build/.

Run a Node (Regtest Example)

Create whippet.conf:

server=1
rpcuser=user
rpcpassword=pass
rpcport=33665

Start the node:

./build/whippetd -datadir=/tmp/whipptest -regtest

Mine Blocks with Transactions

Prepare addresses.json with your target addresses.

Run the mining script:

python3 mine-blocks.py -n 50 -c addresses.json --enable-transactions --interval 30

Verify

./build/whippet-cli -rpcuser=rpcuser -rpcpassword=rpcpass -rpcport=33665 getblockcount

Inspect transactions and balances via RPC commands.

Release and Repository

I pushed the cleaned main branch to the GitHub Whippet do not use for production blockchain repository. I’m not releasing binaries. You’re on your own either shaking your head at my silliness or figuring this out for yourself with what I’ve written so far.

Next Steps for Experimentation

If I do anything with this again, I might experiment with:

garbage-collecting old blocks no longer reachable from the mempool
trying to violate the block time minimum age rule
consolidating mempool transactions
rejecting transactions under a specific size

Alternately, I might shut this all down in a couple of weeks. Either way, I learned a few things, achieved a few things, and enjoyed myself more than if I’d cleaned out my garage. I hope you had a good 2025 holiday season!

A Throwaway Blockchain Speed Experiment.