The concern revolves around how these nodes, which do not retain full historical blockchain data, would handle the transition to a new rule set that requires access to past block information the nodes have pruned.

The scenario described involves a user named Alice who runs an older node without FDT-aware code and prunes blocks after a certain time or block number, denoted as t. When Alice later updates her node to a version that is aware of FDTs, she faces a validation challenge because the node lacks the old blocks needed to enforce the FDT rules. This presents a risk around the activation time of the soft fork as not all nodes might be able to enforce the new consensus rules immediately after the update, even if they nominally support them.

To address this issue, it is suggested that nodes upgraded post-activation should begin collecting median feerate information for new blocks moving forward and only enforce FDTs when they have the necessary data. This approach implies that reliance on FDTs should be handled with caution near the activation period due to potential enforcement discrepancies.

An alternative solution proposed involves having the upgraded pruned nodes redownload the entire missing blocks or perhaps just the relevant segments, such as coinbase transactions. With protocol modifications, it could even be limited to just the commitments within the coinbase transactions. To facilitate this process efficiently, Dave highlights a technique involving the merkle root OP_RETURN in the coinbase transaction. By using a SHA midstate compression for the earlier parts of the coinbase transaction, only the OP_RETURN commitment and a few hundred bytes are required to verify trailing commitments. This method was considered during the development of segregated witness (segwit) but was not adopted due to certain ASIC miners' hardware constraints at the time, which mandated the placement of mining reward payouts in the final output position of the coinbase transaction.