headers-first 如何防止填充磁碟攻擊？
檢查點阻止了一個節點可以從區塊鏈的早期點探勘許多低難度塊並將這些塊提供給同步節點的攻擊，這些節點會看到他們的磁碟已滿。這在<https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Checkpoints>中有描述。
現在，由於檢查點被刪除，我們將容易受到這種攻擊。但是（<https://bitcoin.stackexchange.com/a/75735/69518>）中指出，新的標頭優先同步機制可以防止這種情況。
headers-first 同步如何防止填充磁碟攻擊？
同步節點從單個對等點下載所有標頭。如果該對等點僅從其惡意低難度分支發送標頭，同步節點是否會嘗試下載所有這些塊並填滿它的磁碟？
由於檢查點被刪除，我們將容易受到這種攻擊
你在哪裡看到檢查點被刪除了？他們仍然在
src/chainparams.cpp目前的主人（送出f8bcef38f）中。headers-first 同步如何防止填充磁碟攻擊？
Headers-first 防止了相關的攻擊，客戶端將接受“孤立”塊——沒有已知父塊的塊——並儲存它們直到收到它們的父塊。這可以防止浪費頻寬並在正常情況下加快驗證速度，但在病態情況下使磁碟填充攻擊更容易。
標頭首先允許比特幣核心在下載任何塊之前發現其對等方知道的最多工作量證明區塊鏈（標頭鏈），這允許它確保它收到的任何塊都在該鏈上。反過來，這意味著它永遠不需要下載或儲存孤立塊。
同步節點從單個對等點下載所有標頭。如果該對等點僅從其惡意低難度分支發送標頭，同步節點是否會嘗試下載所有這些塊並填滿它的磁碟？
這是正確的，這就是據我所知，程式碼中仍然使用檢查點的原因。我的理解是，為了最終取消檢查點，需要三件事：
- 最小鏈：編碼到節點中的功能告訴它合法鏈必須至少有 X 數量的鏈，X 設置為軟體發佈時間附近的最近塊的值。這取代了最初使用檢查點來防止網路級攻擊者向客戶端提供包含有效區塊但不是共識最佳區塊鏈的長、低 PoW 鏈。這部署在 Bicoin Core 0.13.2 中。
- 假定有效塊：該功能旨在通過跳過舊塊中的簽名驗證來替代檢查點的二次使用，以（可選地）加速初始塊下載（IBD）。這是在比特幣核心 0.14 中部署的
- 最低難度軟分叉：通過提高區塊鏈中各個時期的最低難度以與實際觀察到的難度增加大致對應來直接解決您描述的塊填充（或頭部填充）攻擊的更改。這將使攻擊者向節點提供虛假塊的成本更高。據我所知，這還沒有達到 BIP 階段，我不確定它目前是否得到積極支持。
作為參考，這個話題在 2017-03-02 比特幣核心開發者會議上討論過：https ://bitcoincore.org/en/meetings/2017/03/02/#discussion
