Block sizes, processing capacity, and handling spam on a permission-less network
It’s an interesting topic: Spam
I’m not talking about canned pork meats, or even emails, but more specifically spam on a blockchain.
What can you do about it? How do you prevent it? What constitutes spam? Who decides what constitutes spam?
It’s something that the developers of DigiByte have been talking about for a VERY long time, but even more-so lately: How do we minimize any spam on DigiAssets?
There’s a myriad of questions, and it’s not something I’ll profess to have all the answers to, but I’ll walk you through some of the history for DigiByte and other blockchains, then we can take a bit of a look at the future.
Spam on the blockchain
Is it really that common?
Surprisingly, yes.
You see, as a permission-less & censorship resistant network, there’s nothing stopping you from making a transaction on DigiByte.
Same goes for if you want to send yourself some DigiByte back and forth, nobody can stop you.
Likewise if you want to make that same transaction back and forth a few hundred thousand times, you’re only going to be paying the minimal network tx-fees.
So this is where low transaction fees become a double-edged sword.
In fact, you only have to look over at the likes of EOS where spam-tx’s have become a pretty major problem, and all block-explorers are implementing spam-filtering.
This also affects the likes of Ravencoin, where assets are being sent to wallets by somebody crawling the blockchain, then sending an asset to every UTXO address. Once it’s in your Ravencoin wallet you have to burn it to remove it. This spam can be things like including an image with “Check out this website with big penises” or “Buy performance enhancing drugs” etc and it’ll just show up in your wallet.
Naturally, this is not something we want to encourage on DigiByte.
But again it comes back to the problem:
How do you stop this on a permissionless / decentralized network?
This isn’t just limited to DigiByte either.
It’s something that the Litecoin community have recently discussed:
Half of the transactions ever made on the Litecoin network are spam, that contribute to increased RAM usage in the Litecoin Core client.
They looked at the possibility of removing these spam-transactions. More people voted to remove them, compared to those who voted to keep their network as-is, censorship-resistant. This in and of itself is concerning to say the least but not the focus.
But it’s something worth discussing: Should spam also be censorship resistant?
If not, who determines what is / is not spam?
Is it the miners who determine this? The users of the wallet? Charlie Lee, the founder of Litecoin himself?
This isn’t something that I myself have an answer for, except to say that as a user of a decentralized / permissionless network, I’d like to be in control of something like this, myself.
I don’t want to rely on somebody else accidentally presuming something is spam, which isn’t, possibly missing or having an asset burned which shouldn’t be. That would be disastrous.
So there are going to have to be measures put in-place to ensure that the scalability of DigiByte isn’t abused for spamming purposes, and that’s something we’re looking in to prior to making the DigiAssets mobile wallets publicly available.
Revisiting the TPS (Transactions Per Second)
Speaking of DigiByte scaling, often times we’ve seen touted that Bitcoin can do 4–7 TPS, Litecoin 56, and DigiByte can do 280 / 560 TPS.
This isn’t entirely accurate, and I want to clarify why.
WARNING: Simple math ahead, involving multiplication and division
This statistic is based off Bitcoin, having 10 minute 1MB blocks.
Bitcoin, when it has a full block, will get around 2500–2750 transactions per-block. At 600 seconds per-block, if we conservatively go with 2500 transactions per-MB, that’s 4.2 per-block at an average of 400 bytes per-transaction. We’ll round this down to 4 as a nice easy-to-work with number.
So, Bitcoin can, and is, doing 4 TPS, mostly due to individual transaction size growing in spite of the SegWit adoption that’s occurring. This means an exchange might take 10 inputs and send the outputs to half a dozen people, while returning it all to a single change-address, utilizing a process known as “batching”.
Comparatively, many transactions on the likes of Litecoin / DigiByte have significantly less inputs and less outputs, making a 400 byte transaction is probably a pretty good “real world” average.
This means that Litecoin will get 16TPS because they have 2.5 minute blocks (4x faster than Bitcoin).
DigiByte subsequently will have 160TPS because of the 15 second block timings (40x faster than Bitcoin).
Now this is where you need to know a little about SegWit and block weighting.
You see the “block size” is no longer 1MB in Bitcoin, but rather it’s weighted at 4,000,000 bytes, with non-SegWit transactions “counting” for 4x their size. This is where the “4–7 TPS” comes from. If you’re interested, you can read further about SegWit in this fantastic explanation from Jimmy Song.
Now, DigiByte originally had code to double the maximum block-size every 2 years as part of the DigiSpeed upgrade in 2015. You will note in this announcement there is also mention of:
- Minimum TX & Relay Fee set to 1 DGB to prevent attacks
So even back in 2015 when DigiByte was trading USD$0.00015 the developers were aware they didn’t want to encourage spam on the blockchain.
But back to DigiSpeed. When SegWit was implemented in to DigiByte, this DigiSpeed block-size-doubling code was intentionally removed by the developers to be later revisited, and the blockchain intentionally left at 1MB blocks for the then-foreseeable future. The reason for this is that even though the price was 10X more in $USD as of SegWit activation in April 2017, the tx-fees per-byte were also lowered at that time. This still meant that if a user were to fill a block with 2500 Txn’s, they could do-so for cents in the dollar.
This is naturally less than ideal if a transaction fee is “too low”, given the permanent nature of a blockchain.
You’ll never see somebody doing 10,000 spam-transactions on the Bitcoin network, at USD$5 per-tx right? But 12 million Litecoin transactions for a couple of dollars all up? Well, somebody already has.
For this reason, the block-size for DigiByte has currently remained at 1MB (4MB SegWit weighting), in a bid to avoid the possibility of excess spam, while retaining a lower satoshi-level fee for the transactions.
So in the future, there is no doubt that DigiSpeeds block-size (block-weighting) increases will be revisited, possibly even later in 2019, or 2020. It’s worth being aware that the other improvements from the DigiSpeed upgrade such as block propagation streamlining based on Microsoft Research still remain active in DigiByte. In fact I’ve been talking with some of the devs, and they’ve got some other ideas on better ways to handle this block-size growth.
Coupled with the fact we are wanting to use SegWit as a base for mobile wallets with Bech32, we’ll no doubt be able to squeeze far more than 180TPS out anyway. With 100% SegWit adoption being the “7” in “4–7” that BTC was expecting, that figure would take us to ~280TPS.
At 180-280TPS we can still handle a LOT of DigiAssets transactions.
If DigiAssets were used tomorrow, for a concert, with 100K attendees all ‘checking in’ to the event in the space of 30 minutes, that’s not even 1/5th of current capacity.
However, at the same time, you obviously don’t want people to be spamming transactions that a Core Wallet user must keep on their computer / server for all eternity.
It’s a delicate balance.
How will DigiByte mobile / DigiAssets handle spam then?
There are a couple of things we’re looking at to begin with.
Firstly, when assets are issued using a 3rd-party server, the issuer will pay an additional fee that goes to the miners. This acts as a disincentive to just create “shitcoins” for no reason.
Secondly, issuing from mobile won’t occur to begin with. As we’ve mentioned a number of times, we want the DigiAssets MVP (Minimum Viable Product) to focus around purely sending and receiving. Burning assets may not even make the cut to start with. When asset creation is eventually implemented, it too will have a default fee that goes to miners for the creation of an asset.
Third, we’ve been looking at some underlying protocol-level changes that could be done to further mitigate it, I’ll go in to these later in another post if they end up going somewhere.
Additionally we’re looking in to ways we can hide some assets by default. For example, only showing assets that have gone to an address that have no other assets associated with them. This means that mass-spammed assets to existing addresses won’t show up.
We’re also going to look at ways users can showcase their assets, prioritizing some over others etc, having a trophy-case like display for prized assets.
There are other things that are being discussed, and as always the Developer Channel in Telegram is open to input.
Is there a silver bullet solution?
Definitely not.
It’s sadly an even more incredibly complex task compared to traditional spam (such as emails) due to the permanent nature of the blockchain.
It’s for this reason we are going to tread lightly with the mobile wallets to begin with, rapidly iterating and improving the codebase, the look / feel, and the functionality.
I hope you’re as excited for this as I am for DigiAssets coming to mobile.
We’ve got DigiByte Go updates in the works at the moment that are shaping up well. Also, keep an eye out for the Android mobile version first, followed by iOS soon after.
I trust this gives you a little insight in to why this isn’t being rushed, and some of the many different things that the developers must contemplate and resolve on a daily basis.
