Combining big transactions with hash-only blocks to improve tps. [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2014-01-22T22:20:58+00:00


Summary:

On January 22, 2014, Bitcoin developer Jorge Timón proposed two optimizations to improve the transaction processing rate and anonymity of the network. The first optimization involves keeping only hashes of transactions in a block, reducing redundancy and keeping block propagation time from increasing. By keeping only hashes in a block, it allows for 50tps in a 1MiB block. This method also removes redundancy since every transaction has to be transmitted only once. The second optimization is CoinJoin, which allows many people to send coins with one transaction, thus increasing the effective transaction rate. For example, a limit of 50 KiB allows for a CoinJoin transaction between 170 participants, allowing for 50 tps * 170 effective transactions/tx = 8500 tps in a 1MiB block. However, CoinJoin requires collaboration between many users in real-time, which can induce delays that can take some time. By using a bigger CoinJoin user base for online payments (with smaller fees) and a smaller one for POS payments (with larger fees), this issue can be resolved.The author of the article suggests two optimizations that can improve tps while maintaining anonymity of the network. The first optimization is to keep only the transaction hashes in a block, thereby reducing redundancy and keeping the block size small and easy to propagate. The second optimization involves using CoinJoin to merge transactions from many users for online shopping and banking, which increases the effective transaction rate considerably. However, it requires collaboration between many users in real-time, which induces delays that are unsuitable for POS payments. The author proposes a new type of transaction called Jumbo transactions to serve as a fallback where CoinJoin is not applicable. Jumbo transactions remove the CoinJoin-induced delays while keeping transaction sizes big. The author provides a detailed algorithm for implementing Jumbo transactions, which includes a Jumbo pubkey hash to prevent modification of the transaction. Although Jumbo transactions do not mix coins and thus do not increase anonymity of the network, they offer many benefits such as no wait time for every participant to sign the transaction, backward compatibility with the current transaction system, and more suitable for POS payments. Finally, the author cites several references regarding block propagation time, Bitcoin privacy, and electronic cash system.The proposal to improve transaction per second (tps) by combining big transactions with hash-only blocks is presented in a post by bc. The proposal suggests keeping only hashes of transactions included in a block, transferring all tx separately, using CoinJoin to merge transactions from many users for online shopping and banking, and using jumbo transactions as a fallback for applications where CoinJoin is inappropriate. By keeping only hashes in a block, the current 1MB block can contain about 31000tx = 50tps instead of 3300tx = 5.5tps. This method allows achieving more tps without increasing the block propagation time, which is critical for mining decentralization. CoinJoin is used to allow many people to send coins with one transaction, increasing the effective transaction rate considerably. For example, if the transaction size limit is 50KB, it allows for a CoinJoin transaction between 170 participants. So for a block of 1MB, it would allow for 8500tps. There would be an incentive for users to use CoinJoin by default, lower tx fees per effective transaction, which would greatly increase the anonymity of the network.Jumbo transactions type proposed as a backup when CoinJoin is not applicable. It would remove the CoinJoin-induced delays while keeping transaction sizes big. Jumbo pubkey prevents the transaction from being modified. A service that collects transactions from clients and publishes them as a Jumbo transaction joins the transaction. Transaction joiner sends a Jumbo pubkey hash to the client. The client creates a transaction, includes a Jumbo pubkey hash, and signs it. The transaction joiner waits until there are enough transactions and releases a Jumbo transaction to the network. Jumbo transactions do not mix coins, so anonymity of the network is not increased. There would be an incentive to use this transaction type by default compared to CoinJoin. To mitigate this problem, the Jumbo transaction size limit can be lower than CoinJoin, making fees for these transactions higher, thus creating an incentive to use them only when necessary. The proposal suggests using a bigger CoinJoin user base for online payments with smaller fees and a smaller one for POS payments with larger fees.The author proposes a method to combine big transactions with hash-only blocks to improve the transaction per second (tps). This combines two techniques, one is including only hashes in a block to speed up the network, and the other is using CoinJoin to improve privacy. Keeping only transaction hashes in a block removes redundancy and allows for more consistent bandwidth utilization. Assuming a block size of 1MB and a limit of 50KB for transaction size, it allows for a CoinJoin transaction between 170 participants and an effective transaction rate of 8500 tps.


Updated on: 2023-08-01T07:18:50.241680+00:00