Qtum Mainnet Results Dec 4–10

Luna Park, Active Transactions Peaking, North Sydney Olympic Pool

This week we have the usual charts and graphs showing Mainnet performance. The educational feature considers the memory pool (mempool) and how unconfirmed transactions work with the mempool.

I am an independent researcher, not affiliated with the Qtum Team, but appreciate their advice and the robust technical discussions in the community.

Charts and Graphs

Data sources for this review of the Qtum mainnet performance come from the Qtum Explorer, the blockchain, and logging from the qtumd server application.

Unique Reward Addresses

This week unique addresses winning block rewards per day dropped to 236 on December 6. For the entire week, there were 885 unique addresses, vs. 899 last week, showing the continued growth of large wallets.

Wallets winning multiple blocks per day increased slightly from last week:

Active Transactions per Day

Active transactions per day jumped up to 8,363 on December 8, almost surpassing the previous high on October 20th. Active transactions reports transactions for coins and contracts above the baseline two for each block (the coinbase and coinstake transactions).

You can also see the transaction chart at QTUM Explorer.io. This week the Qtum Explorer was updated to remove most charts (and bitcoin references). The Qtum Explorer now has a Rich List which shows a breakdown of coins by address (but these are not necessarily staking addresses — and there are some display problems: it says there are 16 addresses with over 10 million coins but there are only slightly over 100 million coins total).

December 8 had a big peak of transactions, and block 59,572 had 245 transactions, the high number of transactions per block for the week. Let’s take a closer look at block 59,572. It was a busy time for transactions, but the reason block 59,572 had so many transactions is that it’s spacing from the previous block was 18 minutes 40 seconds, and as a preview of the educational topic, unconfirmed transactions were building up in the memory pools of all the nodes, just waiting for block 59,572 to be published.

You might (correctly) think that there were some nice transaction fees for this block:

Block 59,572 — part of the coinstake transaction

Here we see the top of the coinstake transaction (the transaction that conveys the block reward) for block 59,572. The amount being staked by KG9o is shown on the left as 1644.67142596 QTUM. The stake will be split (if above 200 coins) and we see transactions on the right as two outputs going back to KG9o of approximately 822.55 each. These amounts will include the initial 0.4 QTUM block reward payment, plus one-tenth of the total fees for this block. The coinstake transaction equally shares the transaction fees with ten addresses: 1/10th to the current block reward winner, and 1/10th (along with 0.4 QTUM) to 9 previous block reward winners for 502 to 510 blocks earlier. You can see the fee amount in the payment to Vtvp (the red arrow above) as 0.4 + 0.03569275. The total fees for this block were ten times the fees sent to Vtvp, or 0.3569275. For a refresher on the block reward payment mechanics, see my previous story.

Block Spacing Variation

From December 4 to December 10 there were 2 blocks with more than 20-minute spacing (vs. 3 last week), with the greatest spacing for block 60,957 at 22:26. Average block time dropped a little to 142 seconds:

Network Weight

Another big wallet began putting on some serious weight this week, h8ND bulking up to a healthy 1.018 million coins. This wallet should join the big five next week for the Big Five Network Weight calculation. Some of the other biggest wallets shifted coins around this week, increasing or decreasing their balance, so my calculation for BFNW did not produce a good result. Based on last week’s number of 21 million, plus h8ND, network weight is probably in the 22 million range.

Diving into the Memory Pool

This week the educational feature covers the mempool (memory pool), which holds unconfirmed transactions before they are published to the blockchain. These unconfirmed transactions will accumulate in the mempool (and they are shown on the home page of the Qtum Explorer) until the next block, when most of them are swept up and published to the blockchain.

Here is a transaction in progress from December 8. Wallet address XLqH was sending 203.8 QTUM to someone. They hit the SEND button shortly after block 59662 was published and generated an unconfirmed transaction with hash


This transaction would be sent peer-to-peer to the Qtum network and would be relayed by all the nodes, probably within seconds through the whole network.

Someone who understands the network better than your correspondent could fully explain this, but let’s just say the nodes form up in small-world network graphs (each wallet will connect to from 8 to 125 other nodes — but don’t worry, the number of connections has no bearing on your block reward probability) and given the current wallet population I’m guessing it is probably a few hops to propagate new transactions through the entire network. I’m assuming that the well-connected wallets and those operating in cloud data centers are connecting to 120–125 other nodes.

Back to our transaction example. At 7:55:37 PM UTC the transaction from XLqH is unconfirmed, and would be sitting in the mempool of all the nodes (but not those slacker Ledger wallets which are unable to stake and publish blocks):

Unconfirmed Transaction!

About 2 1/2 minutes later, a lucky wallet (maybe not so lucky — with a balance of 700k coins) solves the SHA-256 hash algo and publishes block 59,663. This transaction goes to one confirmation:

Note that, prior to block 59,663 being published, the blockchain knows nothing about this transaction hash. The transaction is now included in block 59,663 and will remain there until, you know, that Red Giant thing.

I thought it would be interesting to see what is really happening with the memory pool, and by running qtumd with the command line switch

qtumd -debug=mempool

the debug log will be filled with juicy mempool details. Let’s look at the mempool transactions for this block (I’m going to snip the center part of the transaction hash so the debug lines will fit below). The log sequence starts at 19:53:40 with block 59,662 being ACCEPTED:

Our transaction 336e for 203.8 coins shows up as the 3rd transaction in the debug log at 19:55:03. You can see my node received several transactions also relayed from peer 7, which has a low latency connection to the ISP “Google Fiber” in Kansas, USA, probably running their node (wallet) in Google Cloud. In all, there were 27 transactions waiting in my wallet’s mempool for block 59,663.

However, when wallet KhCw published block 59,663, it had only 24 transactions, including the coinbase transaction, the first transaction which is always left blank as a shrine to Satoshi (I love that joke) and the coinstake transaction (the 2nd transaction which conveys the block reward). What happened to the other transactions? Actually, the bottom 6 transactions above starting with 4aac did not make it into block 59,663. But fear not, they were published in block 59,664. It is as if a software genius came up with a clever way using the mempool for distributed peer-to-peer nodes to process these asynchronous transactions arriving at random times.

There is much more interesting behavior for the mempool, but I haven’t read through the code, and if I described all that stuff, Medium would complain about the reading time for this story. I’ll end with a mempool trivia question: is the mempool always in the main CPU memory for your node? No, when you exit the wallet, the mempool is written to disk for a faster restart. For my wallet, the mempool.dat file on disk was 12,816 bytes, and this file size will depend on how busy the network is, and how long since the last block was published.

Herding Cats

so cute

This week the Ethereum blockchain had its first viral DAPP: Crypto Kitties, and oh my. Your correspondent has seen pending transactions (in the mempool, right?) on Ethereum in the 5,000–7,000 range during the worst of the ICO craze earlier this year, and it might take several hours to half a day for the Ethereum blockchain to clean out the mempool for those amounts.

Take take a look at this chart of ETH pending transactions from earlier this week:

December 3–7

I tried to grab a picture showing the pending transactions at normal levels (< 5,000). This chart starts on December 3 and runs for 4 days. You can see the uptake of transactions from all those cute kitties: buying, selling and procreating. The Kitties’ smart contract has more than 1.2 million transactions this week and is generating about 15% of all Ethereum transactions. Thanks to Crypto Kitties, Ethereum has about 700k transactions a day, more than all other crypto currencies combined. The Ethereum unconfirmed transactions are starting to drop a little today. See the references below for more links to charts of the bitcoin and Ethereum mempools.

We finish the report this week in Sydney Australia. All this talk of mempools reminds me of my favourite lap pool, the North Sydney Olympic Pool (videos: 수영장 투어Lovely Swimmer, time lapse), in a beautiful, iconic setting between Sydney Harbor Bridge and Luna Park. Only 10 laps for a 1k swim:

North Sydney Olympic Pool

Hoping your block rewards are going swimmingly,


# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #


Realtime mempool chart for bitcoin showing bands of transactions by fees offered.

More bitcoin mempool charts.

Realtime count of unconfirmed transactions in the bitcoin mempool.

Myetherwallet behind the scenes.

8 beautiful rock swimming pools in Sydney.

Drone views of Luna Park with North Sydney Olympic Pool in the background.

Video of North Sydney Olympic Pool from two weeks ago — Summer in Sydney.