Squashing redundant tx data in blocks on the wire [combined summary]



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

Published on: 2014-08-01T01:00:06+00:00


Summary:

In an email exchange, Gregory Maxwell and Kaz Wesley discussed the possibility of developing a rule to avoid false negatives or excessive storage requirements. Kaz is working on a prototype that will provide data on the false-positive-missing-tx rate using a "remember-last-N" approach. They explored various upgrades to this rule, including learning dropped transactions through mempool syncing or specifying the rule explicitly with priority scripts.The idea of mempool synchronization raised concerns about transaction expiration. Gregory also mentioned the benefits of channel memory sparseblocks and FEC-based mempool synchronization. While implementing FEC at block forwarding time can minimize latency with multiple peers, they agreed that starting with a simple approach would be best.The discussion continued as Kaz Wesley questioned the need to solve the problem of missing transactions since the current protocol already exchanges necessary information. However, false positives and false negatives are still concerns when dealing with multiple peers. Kaz suggested that channel memory sparseblocks could achieve most of the possible bandwidth savings, and FEC-based mempool synchronization could reset the channel memory to the mutual mempool state. This would provide similar benefits to FEC-based block forwarding. The suggestion of using part of a cryptographic permutation as the key was also mentioned as a way to transmit new unknown keys without adding overhead.In another email exchange, Kaz Wesley emphasized the communication overhead of transmitting a transaction list. He proposed a method using forward error correcting (FEC) code data to fill in missing transactions without prior knowledge. Kaz acknowledged that sending 100% of the missing amount can save time if the transport is unordered. The suggestion of using part of a cryptographic permutation as the key was again mentioned as a way to avoid overhead for unknown transactions.On July 31, 2014, Gregory Maxwell and Kaz Wesley discussed the communication overhead of transmitting a transaction list. The current approach of sending 32 bits per transaction was deemed inefficient compared to a simpler approach. Gregory explained the use of non-syndromic forward error correcting code data to minimize overhead. However, it was noted that knowing the sizes and orders of the transactions is essential for this approach to be effective.Kaz Wesley suggested a method for retrieving missing transactions using forward error correcting (FEC) code data in an email conversation. This involved sending slightly larger non-syndromic FEC code data based on estimated missing data. The missing blocks could then be recovered using the FEC code. Wesley provided further details on how to implement this method effectively.The discussion touched on the practicality of set reconciliation for condensed block exchange. It was acknowledged that requesting missing transaction keys would require a round trip, making it costly for exchanging transactions not mutually known. Instead, remembering transmitted invs along connections was deemed effective for reducing bytes and CPU cycles. The current protocol already provides mutual knowledge, allowing for efficient block exchange. The implementation of inv-history-tracking and sparseblock messages were mentioned as improvements. Compact descriptions of block tx inclusion and ordering policies could eliminate overhead for known and unknown transactions. Efficient mempool synchronization and mempool exchange were also discussed to enhance channel-memory sparseblocks and prevent sybil attacks.Gavin Andresen expressed his thoughts on incentivizing nodes to propagate transactions in an email thread. He suggested rewarding nodes for propagating transactions since most transaction data has already been propagated. Wladimir proposed starting the set synchronization process when a miner begins working on a specific block. This would prepare peers for the actual block broadcast, which would only consist of the header and coinbase transaction.In a conversation, Emin Gün Sirer and another individual discussed minimizing data transfer in cryptocurrency mining. The round complexity was seen as crucial, with Yaron's non-interactive scheme being praised for its lack of overhead. Forward error correction (FEC) was suggested but acknowledged to still have some overhead. The multithreading of the client was considered the best approach, although the potential applicability of Yaron's work was noted.Emin Gün Sirer discussed a problem similar to set reconciliation and the importance of minimizing data transfer. The round complexity was highlighted, and a previous proposal to use FEC for low data transfer was mentioned. However, it was acknowledged that FEC schemes are complex and add metadata overhead.A new technique for solving the set reconciliation problem was described in a Cornell paper. This approach aimed to reduce communication complexity between peers and eliminate overhead. Set reconciliation was compared to Bloom filters, with the former being more efficient and non-interactive. The author invited interested parties to apply this technique to the Bitcoin p2p protocol.Kaz Wesley proposed an additional proposal involving sparse blocks and ultra-fast block validation (UFBV). This would incentivize ahead-of-block transaction propagation and make the new-block process more efficient for miners. The benefits of these changes were emphasized, but they only applied when transactions were seen in advance.


Updated on: 2023-08-01T09:47:20.622686+00:00