An Overview of Batching 1,263 Outputs With litecoind
Over the weekend, the Litecoin Foundation funded 1,263 LTC addresses with 0.1 LTC to encourage conference attendees to #paywithlitecoin at the Summit. The following will be an exploration of how this was achieved, the stats behind the transactions, and what we can learn from it.
Loshan, a litecoin developer, was able to fund these addresses with two transactions using a script:
The second transaction contained 504 outputs:
Rather than using individual transactions to send LTC to each address, Loshan used a technique called “batching.” If you don’t know what batching is, I highly recommend this article by David Harding.
The great thing about this technique is that anyone can use it as it is available through popular wallets such as Electrum-LTC with the “pay to many” feature:
Litecoind also has this feature, which is what Loshan used for these transactions.
At first, Loshan had intended to send 0.1 LTC to all the addresses in one transaction. However litecoind started to fail when the json, which has the output addresses and transactions, started to get too big. This is why he ended up splitting it into two batched transactions.
A look at the same transactions but from a different explorer.
1. Transaction sizes were 25.989 kB and 17.32 kB respectively.
In contrast, a typical transaction size is around 0.2 kB.
2. Transaction fee rates were 0.00099979 LTC/kB and 0.0000998171478 LTC/kB.
At first I was surprised by this because the minimum transaction fee rate in Litecoin Core is set to 0.001 LTC/kB. However, Loshan clarified that Litecoin Core uses a fee estimator, which would account for the miniscule difference that we see.
3. Transaction fees were approximately 0.026 LTC and 0.017 LTC.
Typical transaction fees are around 0.0002 LTC. If he had sent an individual transaction to each address, the total cumulative fees would have amounted to about 0.2526 LTC. Therefore Loshan was able to save a total of 0.2096 LTC, or $11 USD, through batching.
4. According to Loshan, it took less than 0.5 seconds to create and broadcast a batched a transaction to 759 addresses.
That means the total time to fund 1,263 addresses through two transactions was under 1 second.
The Take Aways
There are several things we can learn from this “stress test”:
It took less than 0.5 seconds to create and sign 759 outputs.
Transaction creation was limited by software, not protocol. This was evidenced by litecoind failing at over 800 outputs. However, it would eventually be limited by the blocksize. Let’s assume a batched transaction size of 26kB is equivalent to 760 outputs. That means that the maximum # of outputs a 1 MB block could contain through a single non-segwit batched transaction would be about 29,231 addresses. This is nowhere near the amount needed to meet the 24,000 transactions per second demand of a global payment system that Visa is currently doing. If a block is 2.5 minutes, then the single non-SegWit batched transaction would have to fit 3.6 million outputs just to match Visa. This would mean each block would have to be at least 123 MB. In one day, this would take up to 70.8 GB on your computer.
This clearly exposes the limitations of on-chain scaling as it is unrealistic to expect a block to be filled with just a single batched transaction. Also the fact that it would just take 14 days for a 1 TB hard-drive to get filled highlights the need for off-chain solutions such as the Lightning Network.
Businesses and exchanges should enable “withdrawal rounds” in order to collect and batch transactions to save money on transaction fees.
These batched transactions were successfully created under the 0.001 LTC/kB fee that is set by default in Litecoin Core due to fee estimation. Let’s apply this idea of fee estimation to Litecoin Core’s minimum relay fees. As it stands now, this transaction would have no problem getting relayed because the minimum relay fee is set at 0.0001 LTC/kB. But what would happen if the minimum relay fee was still set at 0.001 LTC/kB?
It would be logical to conclude that nodes in the network would not relay this transaction as it would be under the 0.001 LTC/kB threshold. However in reality, the transaction would still go through because most of the nodes in the LTC network use Litecoin Core and they would use the same minimum relay fee estimation algorithm. If it worked on Loshan’s litecoind, you can rest assured that the other Litecoin Core nodes in the network would calculate, accept, and relay the transaction as well.
One of the advantages of having a single dominant implementation is a consistent relay feerate because it is set by default. This allows for more reliable transaction relays when users try to spend Litecoin with the lowest fees. Otherwise, inconsistent relay fees throughout the network could cause some transactions to drop out and never reach miners to be processed.