9

There are probably several reasons, but it's mostly historic. There is no inherent problem with just sending transaction id's. There is a disadvantage too, though, namely increased latency, which is not necessarily a problem when doing an initial sync, but it is not wanted when a fresh new block is propagating. In fact, this idea is part of BIP 37, which ...


6

The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it. BIP ...


3

In current versions of Bitcoin Core, most transactions are only relayed once and all transaction are only validated once. New blocks and transactions in Bitcoin are usually advertised to peers by use of inv (inventory) messages. Blocks are thereby identified with the hash of their header, while transactions are identified by a hash over the complete ...


2

While FIBRE has done an incredible job in reducing relay times for blocks which are new, many miners additionally have systems by which they relay their own blocks in a single packet and have them queued up to relay on when they start mining the template, not when they find the block. Ultimately, FIBRE's few milliseconds of delay will lose to a single UDP ...


1

only include transaction hashes Blocks must include transactions. It's the way how transactions are archived. Otherwise, over 100 GB of transactions had to be stored in mempool. However, you're right. Each transaction is broadcast twice: Once when a user makes a transactions, once when a miner creates a block containing it. There have been various ...


1

Transaction should be verifiable (and may be verified) by each full node. If block only contained the transaction hashes, any node who has not been online during the transactions propagation, or simply has not received the transactions, would not be able to verify the correctness of the transactions referred in the block. Furthermore, when new nodes join ...


1

You mention in your comment that They can still put full transactions to the full blockchain. This is exactly what they are doing. The full blockchain is simply a collection of the blocks. Since the blocks contain the full transactions, the transactions are in the blockchain. If the blocks contained only the transaction hashes, the raw transaction data ...


1

Yes, compact blocks are still usually faster even when there is a getblocktxn round trip. The reason for this is because all that needs to be sent in that case is the requests for the missing transactions and the missing transactions themselves. Although the time is increased by another round trip in this case it is only a single round trip and there is ...


Only top voted, non community-wiki answers of a minimum length are eligible