Denying the Delivery of Transactions
To minimize information spread in the network, transactions are propagated in the Bitcoin network using an advertisement-based request management system (see Chapter 3). Namely, if a peer receives information about a new transaction from another node, then the node will advertise this transaction to its other connections by sending them an inv message (see Figure 4.3). This message is much smaller in size than the actual transaction, because it only contains the hash and the type of object that is advertised.
If the neighbor has not previously received the transaction advertised by the inv message, he or she will request the transaction using a getdata request. Note that
Bitcoin clients keep track of the order of the received transaction advertisements. If a request for a given transaction is not delivered within 2 minutes, the next peer in the list is queried .
By doing so, inventory messages limit the amount of data broadcast in the network. However, this process also opens the door for an adversary to considerably delay the delivery of transactions in the network, and therefore to severely affect the ability of the network to verify transactions on time.
This is achieved as follows . The adversary simply sends n back to back inv messages for the same transaction T. Note that it is important that the adversary is the first to announce T to the victim, otherwise the latter will request it from another peer. When the victim sends a getdata request, the adversary does not reply. After 2 minutes, the time-out will trigger, and the victim will request T from the next node on the list—which also corresponds to the adversary’s. Note that the victim will not request T from any other advertiser in the meantime. By doing so, the adversary effectively increases the time-out specific to the advertised transaction by 2n minutes, as shown in .
This attack has considerable impact on the security of Bitcoin, since it deprives peers from the benefit of immediately receiving and verifying transactions. As we show in Section 4.2.1, this attack can considerably facilitate double-spending in the network.