In this guide, we take a look at some of the features that can improve Bitcoin’s privacy and scalability.
In addition, we’ll discuss how adding smaller blocks could in turn attract more miners, making transaction fees smaller and the network more decentralised.
Signature aggregation and coin mixers
A key advancement in the Bitcoin protocol is Schnorr Signatures. Speaking to Vortex, who Coin Rivet interviewed in 2019, he describes Schnorr Signatures as very important because “Schnorr (and Taproot) is extremely powerful for the privacy in Bitcoin because we can make complex multi-sig transactions and even complex coinjoin transactions look like everyday normal transactions. This makes it difficult for chain analysis companies to analyse the inbound/outbound flows of coins in said transactions.”
Another major improvement that helps Bitcoin scale its privacy features are scriptless scripts, an improvement over the base layer for signature aggregation.
If you weren’t aware, transaction signatures can identify participants and the type of transaction. With Schnorr Signatures, for example, it becomes impossible to identify the participants of a transaction or what type of transaction it is.
Another important feature is coin mixers, which can give users additional privacy. In a sense, mixers simply grab all sender and receiver addresses and mix them up so that someone else cannot identify both the sender and recipient of a given transaction.
Block size: reduce or increase?
I agree with @LukeDashjr that the block size should be smaller. I feel more confidence to say it now that we have LN making strides. I'll run the soft fork.
— John Carvalho (@BitcoinErrorLog) February 10, 2019
One of the most interesting approaches to scaling Bitcoin I’ve seen has been suggested unsurprisingly by some core Bitcoin developers – like Luke Dash Jr – who believe we could have smaller block sizes as that would facilitate the entrance of more full nodes, which could potentially have a scaling effect on the number of network participants.
On the other hand, other developers like Pieter Wuille are proponents of increasing the block weight, perhaps by 10 or 100 times, as that would allow miners to accommodate an increasing number of transactions.
Personally, I believe there are pros and cons on both sides. Given smaller block weight would mean less storage requirements per block, more participants could join the network. However, there could be a massive problem with transactions not getting posted for a longer period, causing long transaction delays.
If we look at SegWit, which indeed increased the block weight, it still hasn’t been fully adopted by the community – even though the upgrade happened over a year ago.
Does this mean miners and full nodes don’t trust SegWit?
Is there an ultimate solution?
Personally speaking, I don’t think there is a definitive solution to the scalability issue. If managed through a soft fork, I would attempt to try both increasing and decreasing the block size, as miners, users, and developers could experience both options and signal their preferences.
From a security standpoint, it’s hard at this point to say smaller blocks would be better. Looking at the Bitcoin Cash vs Bitcoin comparison, we can already see some of the issues bigger blocks can cause. However, the network keeps running and miners keep supporting it, even if almost no fees are paid in comparison to Bitcoin.
Bigger blocks mean little if they remain empty. There’s also a risk miners will flock to another version of Bitcoin with smaller blocks, destroying the network’s attractiveness.
Nevertheless, we should aim at having more versions of Bitcoin – compatible or not – simply because if one gets shut down or gets an irreversible bug, miners can shift onto another.
Additionally, other P2P layer-two solutions like statechains and payment channels (like the Lightning Network and Liquid) can also make huge contributions to Bitcoin’s scaling, although users must forego a small amount of decentralisation.
Safe trades!
Disclaimer: The views and opinions expressed by the author should not be considered as financial advice. We do not give advice on financial products.