The issue of scalability compromise of Bitcoin is in constant iteration and development since the protocol was started in 2009. Two main schools of thought have divided the users, that of increasing the size of the blocks and that of the optimization of block space and scalability across second layers , such as the Lightning network .
The most heated debates take place during the scalability wars from 2015 to 2017, which eased with the creation of Bitcoin Cash and the implementation of Segwit in the Bitcoin protocol on August 23, 2017 . This last method allows the increase in the size of the blocks while following the principle of backward compatibility , therefore considered as a compromise between the two camps. Through this principle, the nodes of the Bitcoin network are not obliged to opt for the new Bitcoin Core client in order to remain compatible with the network.
In addition, Segwit enabled the advent of the Lightning Network , a second layer of Bitcoin micropayments, by solving the problem of transaction malleability .
Feedback on the optimization of the block space (on-chain)
The major scalability technology, the Lightning Network , is an efficient method to increase the transactional capacity of Bitcoin without the original rules of the protocol having to be changed.
On the other hand, this technique is very complex and still requires a lot of development before being completely ready. Many other scalability techniques have been explored to some extent, right from the implementation of Bitcoin.
The transactional capability (transactions per second) is not only dependent on the frequency and size of blocks , but also directly correlated to the size of the transactions . It is therefore sufficient to make the transactions lighter in size (bytes) and not in Bitcoin volume in order to be able to insert a larger number of them in each block.
One of the most widely used and known techniques for this effect is transaction batching .
To understand what Batching is , it is very useful to first understand the transactional model of Bitcoin which is based on UTXO (Unspent transaction outputs).
Each Bitcoin transaction is made up of at least two input fields , an input ( sender ) and an output ( recipient ).
In order for an input to be spent by its sender, it must be signed with the corresponding private key . The same process prevails at the level of the transaction recipient, which can only spend the output if it also holds the private key corresponding to it.
A typical transaction will often hold against at least two outputs, one of which will be destined to the sender of the transaction for the exchange remainder of the input used in it (as shown below).
You can see that in this transaction, the input (on the left) contains 0.6066744 BTC and that the two outputs are 0.08281911 BTC and 0.52380329 BTC
The input must therefore be deconstructed into two outputs for the transaction to be carried out.
On the other hand, it is also possible that a transaction is composed of several inputs which will assemble to form the desired output.
That said, a Bitcoin transaction can be made up of multiple inputs and outputs at the desire of the creator thereof. Most users don’t bother building a deal, because their wallet will do it for them. It is also possible to do this manually for transactional optimization purposes.
Coming back to Batching , there is no official definition for the Batching process, however it is commonly accepted that a transaction with more than 3 outputs is a “batch” transaction .
And yes, it is that easy. The goal is to batch individual transactions in order to optimize the space they would have taken up if built separately.
Let’s say a sender wants to send Bitcoin to three different addresses. It could send three separate transactions, but that certainly wouldn’t be the optimal way to go. Knowing that a regular transaction takes 346 bytes by default, it could simply graft the two additional outputs to the first transaction which only add 34 bytes of space each to the transaction.