Bitcoin Core

2018-11-01 IRC 會議摘要

Thu, 01 Nov 2018 00:00:00 +0000

概覽

高優先級審查
非 HD 錢包測試
錢包重構
AppVeyor 失敗
大家在做什麼？
參與者
免責聲明

在 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週貢獻者會議涵蓋的主題包括提名高優先級審查的拉取請求、非 HD 錢包程式碼路徑缺少測試、錢包重構進度審查以及 AppVeyor CI 執行的測試產生的偽造失敗。在會議結束時，鼓勵貢獻者分享他們正在積極參與的專案。

高優先級審查

背景： 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的當前高優先級 PR 列表。

討論（日誌）： 討論了以下 PR：

#14532 - 預設情況下永不綁定 INADDR_ANY，明確執行時發出警告，作者 luke-jr
#14350 - 新增 WalletLocation 類別，作者 promag
#14046 - net：重構訊息解析（CNetMessage），作者 jonasschnelli
#14477 - 新增將可解性資訊轉換為描述符的能力，作者 sipa
#13932 - PSBT 的額外實用 RPC，作者 achow101
#14437 - 重構：開始將錢包與節點分離，作者 ryanofsky
#14336 - net：實作 poll，作者 pstratem

非 HD 錢包測試

背景： Bitcoin Core 在 0.13.0 中引入了對 BIP32 階層確定性錢包的支援，大大簡化了錢包備份和恢復過程。使用者可以對錢包的擴展私鑰主金鑰（錢包中的所有金鑰都從中確定性生成）進行一次備份，而不是定期備份無定形的金鑰池。在 0.16.0 版本之前，使用者可以透過指定 -usehd=0 來選擇停用此功能。當刪除此選項時，非 HD 錢包程式碼路徑的測試也被刪除了。雖然較新版本的 Bitcoin Core 無法再建立非 HD 錢包，但仍然可以匯入它們。

討論（日誌）： 此主題由 luke-jr 建議。由於 Bitcoin Core 不再建立非 HD 錢包，provoostenator、achow101 和 jfnewbery 提到，非 HD 版本的錢包必須打包到測試框架中。Sipa 指出了測試錢包升級場景的重要性（在 Bitcoin Core 升級和/或降級時正在備份和恢復的錢包的失敗模式可能導致資金無法恢復的損失）。

結論： 應在 issue #14536 中繼續討論各種方法。

錢包重構

背景： Bitcoin Core 錢包正在積極重構。這項工作有多個目標，其中包括：改進 Bitcoin Core 的架構模組化、簡化錢包的程式碼庫和引入新功能。這一更廣泛目標集中的一個專案是輸出描述符語言。此語言在 0.17.0 中引入，旨在將金鑰集的支出要求編碼為單個字串；這種分類未花費輸出的方法改進了先前存在的 isMine 邏輯，其複雜性和效率低下阻礙了更高級錢包功能的開發（例如，支援與 PSBT 相容的金鑰簽名協定的硬體錢包整合）。

討論（日誌）： 在 #14565 中，Sipa 繼續他的工作，改進 importmulti RPC 的邏輯，以限制多餘的金鑰或腳本資料被匯入；這對於支援「舊式」描述符匯入是必要的，這些匯入會隱式地將描述符轉換為現有的錢包結構（#14491）。Sipa 還將處理使用描述符而不是金鑰池所需的一些公鑰快取準備工作。為了支援原生描述符匯入，現有的金鑰池/isMine 邏輯必須重構為可以由舊錢包邏輯或描述符實例化的抽象層之後。

結論： Meshcollider 將在 #14565 完成後重新基底 #14491。Achow101 將在此之後在 #14491 之上重新基底 #14075。#14705 使設定了 –disable-private-keys 的錢包能夠從金鑰池匯入和提取公鑰。這有助於將僅監視錢包與儲存私鑰的錢包「分離」。沒有此 PR，停用私鑰的錢包將不會從金鑰池提取公鑰。這對於與 Bitcoin Core 作為外部簽署者互動的硬體錢包很有用；為了支援此用例，金鑰池必須接受硬體錢包生成的僅監視公鑰的匯入和檢索。討論的結論是建議將 ryanofsky 關於其程式碼分離 PR 的狀態更新保留到第二次 Bitcoin Core 錢包貢獻者會議。

注意： 在東京 CoreDev 會議的「錢包內容」會議期間，提議組織一個單獨的專注於錢包的會議。在 10 月 19 日星期五，舉行了第一次 Bitcoin Core 錢包會議。它安排在每隔一個星期五 19:00:00 UTC 舉行。第二次會議於 11 月 2 日舉行。

AppVeyor 失敗

背景： AppVeyor 是一個託管的持續整合服務，為 Bitcoin Core 提供 Microsoft Visual C++ (MSVC) 建置環境。在這些環境中產生的二進位檔案僅用於跨平台測試目的。

討論（日誌）： 在 AppVeyor 上執行的功能測試偶爾失敗。這讓一些貢獻者感到沮喪。Sipa 要求解決此問題。

結論： 有一個開放的 issue #14446，詳細說明了失敗類型。PR #13501 可能會緩解這些失敗的一個類別。

大家在做什麼？

日誌

jarthur：RPC API 的 UNIX 網域通訊端。先前的討論。開放的 issue。
luke-jr：重新基底他的 PR
achow101：PSBT 和硬體錢包整合
jnewbery：年底前花更多時間審查錢包 PR
instagibbs：審查錢包 PR 和硬體錢包整合
sipa：P2P 網路的私有驗證協定。先前的討論。更多閱讀（注意：提議的協定存在已知漏洞）。
meshcollider：錢包重構和審查

參與者

IRC 暱稱	姓名/匿名
sipa	Pieter Wuille
provoostenator	Sjors Provoost
luke-jr	Luke Dashjr
achow101	Andrew Chow
MarcoFalke	Marco Falke
meshcollider	Samuel Dobson
jnewbery	John Newbery
instagibbs	Gregory Sanders
phantomcircuit	Patrick Strateman
jarthur	Justin Arthur
kanzure	Bryan Bishop
gwillen	Glenn Willen
ryanofsky	Russell Yanofsky

免責聲明

本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請開啟 issue，我們將更正錯誤。

2018-08-02 IRC 會議摘要

Thu, 02 Aug 2018 00:00:00 +0000

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括如何處理特定邊緣情況下衝突的編譯器標誌、延續上週關於修復 Windows 使用者檔案名中 Unicode 問題的討論，以及更改程式（特別是其資料庫元件）在某些系統上開啟檔案的方式。

在主題開始前，Wladimir van der Laan 簡要連結了 Bitcoin Core 0.17 的待處理 PR、待處理 issue 和計劃的發布時間表。鼓勵潛在貢獻者審查這些頁面並尋找幫助推進發布的方法。

CXXFLAGS 相關事項

背景： 用於建置 Bitcoin Core 的腳本將參數（標誌）傳遞給編譯器，告訴它 Bitcoin Core 需要什麼資源以及使用或避免哪些優化。最近，這包括新增 -mavx2 標誌（Mode AVX2）以在支援的 CPU 上啟用 SHA256 雜湊的硬體加速。除了 Bitcoin Core 傳遞的標誌外，使用者可以使用 CXXFLAGS 變數傳遞額外的參數，包括標誌 -mno-avx2（Mode No AVX2）。如果同時傳遞這兩個標誌，則僅使用最後出現的標誌。

討論（日誌）： Luke Dashjr 請求並介紹了該主題，「Autotools 在我們自己的標誌之後強制使用者 CXXFLAGS，因此當使用者使用 -mno-avx2 建置時，建置只會失敗。」

Wladimir van der Laan 說，「在我看來，這看起來是一個非常人為設計的場景——至少不值得用各種編譯器特定的 pragma 污染程式碼。」

Cory Fields 補充說，「我假設問題是由於編譯器損壞導致的一些編譯失敗，因此希望能夠完全避免它們。」

結論： Dashjr 認為該問題對於 Bitcoin Core 0.17 是必須修復的，但 van der Laan、Marco Falke 和 Gregory Maxwell 不同意。似乎很可能會徵求報告使用者的額外資訊，以了解他們為什麼需要傳遞 -mno-avx2。

Windows 檔案名中的 Unicode 問題

背景： 如上次會議所討論，Microsoft Windows 內建的介面在某些情況下阻止 Bitcoin Core 輕鬆開啟包含非拉丁字元的檔案。

討論（日誌）： Sjors Proovost 請求並介紹了該主題：「鑑於 [Bitcoin Core 0.17 的最終開發] 還剩兩週，我們是否想修復 Windows Unicode 問題？我認為工單中的意見是否定的。」

Cory Fields 指出，「由於問題的性質，我認為許多會報告它的人可能不會說英語，因此重要性可能有點被低估了。」

該問題的一個特殊困難是，如果沒有訪問以特定方式配置的 Windows 系統，似乎無法重現該問題，因此不使用 Windows 的開發人員（大多數活躍貢獻者）無法直接處理它，即使錯誤得到修復，Bitcoin Core 的自動化測試也無法用於防止未來的退化。

結論： Marco Falke 指出，修復該問題「需要 leveldb [升級] 和重大變更。」他建議在 0.18 中解決該問題，幾位會議參與者似乎同意。他進一步建議「如果符合錯誤修復的條件，我們可以將其向後移植到 0.17.1」，會議參與者明確同意。

x86_64 上的 LevelDB FD 使用

背景： Bitcoin Core 使用鍵值儲存資料庫（DB）LevelDB 來追蹤未花費交易輸出（UTXO）集——所有可花費的比特幣組——以及 Bitcoin Core 支援的可選交易索引。LevelDB 使用大量相對較小的檔案（約 2 MB）來儲存其資料。當它從這些檔案讀取時，它更喜歡使用記憶體映射（mmap）以特定的高效方式讀取，但如果不可能，它會退回到使用帶有檔案描述符（FD）的 select 系統呼叫（syscall）直接從磁碟機讀取。然而，select syscall 在可以開啟的 FD 數量上嚴重受限。

討論（日誌）： Gregory Maxwell 請求並介紹了該主題：「最近有一個使用者報告在他的 x86_64 Linux 主機上達到 select 限制。使用 lsof [列出開啟檔案] 檢查顯示，在我們期望它主要使用 mmap 的節點上，leveldb 正在使用大量 FD。顯然 leveldb 有一個 mmap 數量限制。據我所知，我們沒有任何理由不應該增加它。另外，我們應該轉向使用 poll，但增加 mmap 限制應該是約 1 行變更，除非有人知道不這樣做的理由。」

討論了 mmap 限制，沒有參與者知道不增加它的理由。會議結束後不久，Suhas Daftuar 為 leveldb 找到了一個 issue，可能表明為什麼最初設置了該限制，這似乎支援在 x86_64 系統上增加限制。

穿插在 leveldb 討論中的主題是將 Bitcoin Core 從較舊的 select syscall 切換到較新的 poll syscall 以開啟檔案描述符（FD），這不僅包括資料檔案，還包括網路埠。這個低階變更將消除 select 只能處理較低最大 FD 數量的問題，因此 Bitcoin Core 在各個方面受到限制（例如，即使您增加預設最大連接數，它也無法處理更多連接）。此變更的一個問題是 Windows 未實作等效的 poll syscall，因此需要編寫一些相容性程式碼。

結論： 從討論來看，LevelDB mmap 限制很可能會從目前的 1,000 增加到約 4,000，用於 0.17 Bitcoin Core 版本。select 不太可能在該版本中更改為 poll，因為沒有足夠的測試時間，但沒有人反對在後續計劃的主要版本（暫定 0.18）中更改它。

注意： 此主題的討論在會議正式結束後持續了約二十分鐘。

幽默

背景：IRC 頻道最近遭受垃圾訊息攻擊，因此頻道模式設定為安靜（+q）沒有註冊帳戶的使用者。

        wumpus  topics?
       luke-jr  crickets
        wumpus  crickets are... good I guess
      gmaxwell  can someone please drop the registed users
                +q for now? sdaftuar is muted.
provoostenator  (I guess it was crickets and the muffled voice
                of sdaftuar in the distance)

參與者

IRC 暱稱	姓名/匿名
wumpus	Wladimir van der Laan
gmaxwell	Gregory Maxwell
cfields	Cory Fields
luke-jr	Luke Dashjr
provoostenator	Sjors Provoost
MarcoFalke	Marco Falke
meshcollider	Samuel Dobson
ken2812221	Chun Kuan Lee
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
ossifrage	Clem Taylor
sdaftuar	Suhas Daftuar
instagibbs	Gregory Sanders
jnewbery	John Newbery
phantomcircuit	Patrick Strateman
kanzure	Bryan Bishop
midnightmagic	Midnight Magic
promag	Joao Barbosa
achow101	Andrew Chow

免責聲明

2018-07-26 IRC 會議摘要

Thu, 26 Jul 2018 00:00:00 +0000

概覽

P2SH redeemScript 的見證版本命名
會議時間
0.16.2 最終版
Windows 上的編碼問題
次要主題
幽默
參與者
免責聲明

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括花費 segwit P2WSH 輸出的交易中元素的命名、每週會議的時間、是否為即將發布的 0.16.2 Bitcoin Core 版本建立最終 Git 標籤，以及 Windows 上編碼文字字串的問題。

P2SH redeemScript 的見證版本命名

背景： BIP16 P2SH 提供了一種機制，您可以接收對腳本雜湊的支付。當您去花費這些比特幣時，您在支出中包含完整的腳本，在那裡它被稱為 redeemScript。BIP141 segwit P2WSH 使用幾乎相同的機制，但在 BIP141 中稱其為 witnessScript。不幸的是，對於最終不同的事物有幾個類似的術語，聽起來很相似。

討論（日誌）： Matt Corallo 請求該主題並介紹了它：「我們必須為 BitcoinCore.org 選擇[一個術語] […]我知道有些人稱它為見證 redeem 腳本之類的，這也令人困惑，因為 P2SH 包裝的 segwit，但 witnessScript 令人困惑，因為 [Bitcoin Core 內部變數名稱] scriptWitness 指的是整個見證。」

Pieter Wuille 建議，「也許它應該被稱為 P2WSH redeemScript，因為它可以說是特定於 P2WSH 的（P2WPKH 沒有它，未來的見證版本也可能沒有）。」

結論： 沒有明確的結論。Jonas Schnelli 和 Gregory Maxwell 認為討論並不那麼重要，主題很快就被更改了。BitcoinCore.org issue #581 正在追蹤該主題。

會議時間

背景： 如 7 月 5 日會議中所述，會議參與者擔心可能許多 Bitcoin Core 貢獻者，特別是東亞和大洋洲的貢獻者，由於時區差異而無法參加會議。Cory Fields 進行了一項民意調查以找到最佳會議時間。

討論（日誌）： Bryan Bishop 請求該主題的更新，由 Cory Fields 提供：「[民意調查] 在上週會議結束時關閉。獲勝者：[當前] 時間。民意調查結果。」

當前計劃時間是星期四 19:00 UTC。第二受歡迎的時間是提前一小時。關於結果是否偏向於目前參加會議的人進行了一些快速討論，但有人指出，已努力吸引所有活躍的 Bitcoin Core 貢獻者，包括那些生活在當前會議在清晨舉行的時區的貢獻者。

結論： 沒有明確的結論。目前似乎不會更改會議時間。

0.16.2 最終版

背景： 貢獻者一直在開發編號為 0.16.2 的次要版本發布，其中包含向後移植的錯誤修復和次要功能。

討論（日誌）： Wladimir van der Laan 開啟了討論，「發布候選（RC）2 在[大約] 一週前被標記。我認為沒有任何問題出現，所以我認為是時候標記最終版了。」

Matt Corallo、Gregory Maxwell、Jonas Schnelli、Cory Fields 和 João Barbossa 支援該決定。

結論： 會議結束後，0.16.2 被標記。

Windows 上的編碼問題

背景： Windows 應用程式介面（API）對文字字串的要求與 Linux、MacOS 和 *BSD API 不同。正如 Pieter Wuille 在討論中解釋的那樣，「[Windows] 很早就採用了 Unicode，[所以] 他們選擇了與世界其他地方最終選擇的不同的編碼。」當 Bitcoin Core 需要開啟檔案名或目錄名中包含非拉丁字元的檔案時，這目前會產生問題。

討論（日誌）： Chun Kuan Lee 連結到 PR #13426，請求該主題並介紹了它，「是否可以新增 [一個] wmain 函式？」這將為 Windows 使用者在 Bitcoin Core 中新增一個不同的 main 函式，可以解決 Windows 特定的平台問題。

Wladimir van der Laan 回覆說，「我寧願不要。我認為我們在某個時候有多個進入點，Windows 有一個[特殊的]進入點，但這被清理為只有 main() […]我認為 #13426 是一個太大的變更。」

結論： 經過一些討論和關於 Windows 到底支援什麼的快速網路搜尋後，幾位貢獻者表示他們應該更仔細地查看 PR #13426，以便可能提出具體的改進建議。

次要主題

高優先級審查： 不是通常的列表，而是鼓勵審查者專注於為即將發布的 Bitcoin Core 版本 0.17 標記的 PR 和 issue。

幽默

<gmaxwell>  i hate strings
  <wumpus>  so do I, but unfortunately they're needed for path names
 <cfields>  windows strings cause 2x developer hate :(
 <luke-jr>  they string us along?
 <cfields>  luke-jr: i would characterize it that way, yes

參與者

IRC 暱稱	姓名/匿名
wumpus	Wladimir van der Laan
gmaxwell	Gregory Maxwell
sipa	Pieter Wuille
cfields	Cory Fields
BlueMatt	Matt Corallo
ken2812221	Chun Kuan Lee
jonasschnelli	Jonas Schnelli
promag	Joao Barbosa
achow101	Andrew Chow
kanzure	Bryan Bishop
provoostenator	Sjors Provoost
jamesob	James O’Beirne
luke-jr	Luke Dashjr
jtimon	Jorge Timón
jnewbery	John Newbery
nmnkgl	Gleb Naumenko

免責聲明

2018-07-19 IRC 會議摘要

Thu, 19 Jul 2018 00:00:00 +0000

概覽

高優先級審查
在 RPC 上公開幣選擇
#13697 更改 scantxoutset 的 API
Bitcoin-seeder 納入 bitcoin-core GitHub 組織
脫離 Bitcoin.org
下次 CoreDev 技術會議
幽默
參與者
免責聲明

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括在星期一 Bitcoin Core 0.17 功能凍結前需要審查的拉取請求、是否應將 Bitcoin Core 的輸入（幣）選擇演算法作為 RPC 提供、描述錢包應監視哪些輸出的新方法以及此方法在新 scantxoutset RPC 中的實作、Pieter Wuille 的 bitcoin-seeder 程式是否應成為 Bitcoin Core GitHub 組織的一部分、Bitcoin Core 專案是否應停止在 Bitcoin.org 上發布版本說明和二進位檔案，以及關於下次 CoreDev Tech 會議的資訊。

在討論開始之前，Wladimir van der Laan 提到 Bitcoin Core 0.16.2 候選版本（RC）2 的可執行檔可供測試人員使用。

高優先級審查

本次會議的特別關注點是如果要將其功能包含在即將發布的 Bitcoin Core 0.17 版本中，需要在未來幾天內合併的 PR，因此也鼓勵審查者檢查 0.17 里程碑中的 PR 列表。

討論（日誌）： 討論了以下 PR：

#9662 - 新增建立錢包「停用私鑰」選項：純監視錢包的合理模式。由 Jonas Schnelli 請求；Wladimir van der Laan 表示可能很快就可以合併。
#9502 - [Qt] 新增暫停/恢復區塊下載的選項。由 Schnelli 請求。
#13697 - 在 scantxoutset 中支援輸出描述符。由 Pieter Wuille 請求，Schnelli 支援。在會議後面更詳細地討論。
#13666 - 始終使用低 R 值建立簽名。由 Wuille 請求。
#13426 - [錯誤修復] 新增 u8path 和 u8string 以修復 Windows 的編碼問題。由 Chun Kuan Lee 請求。
#13712 - 錢包：修復 ParseHDKeypath 中的非確定性；避免在路徑計算中使用未初始化的變數。由 Andrew Chow 請求。
#8469 - [POC] 向 Core 引入基於屬性的測試。由 Schnelli 請求從 0.17 列表中移除，因為它還沒準備好。
#13617 - 要求 MacOS 10.10+。最初請求從列表中移除，但在 Cory Fields 評論後又加回來。

結論： 在本次會議的這個部分結束時，有超過十幾個 PR 被標記為 0.17，審查截止日期為星期一。

在 RPC 上公開幣選擇

背景： 幣選擇是用於描述錢包如何在特定交易中選擇花費使用者的哪些比特幣的名稱。所選的未花費交易輸出（UTXO），通常簡稱為幣，成為交易中的輸入。開發人員在過去一年中花費了大量時間改進 Bitcoin Core 的幣選擇，以便有時能夠為使用 Bitcoin Core 內建錢包的使用者改善隱私並降低交易大小（從而降低費用），並且還有更多改進正在進行中。

討論（日誌）： Andrew Chow 請求該主題並介紹了它：「這是在與一些公司討論幣選擇時提出的。基本上，有些公司對使用 Core 的幣選擇（或其他人的）感興趣，而不是必須實作/自行設計。目前，如果他們想使用 Core 的幣選擇，UTXO 需要在錢包中——也就是說，地址和可能的金鑰需要在錢包中。」

Wladimir van der Laan 和 Gregory Maxwell 建議他們可以使用 fundrawtransaction RPC 來使用 Bitcoin Core 的幣選擇。Jonas Schnelli 補充說，「使用停用私鑰的動態錢包與 fundraw 結合使用似乎非常有效」，部分是指 PR #9662。

Chow 說，「這對他們來說並不理想」，Pieter Wuille 接著說，「他們不想使用錢包；他們只想能夠執行幣選擇。」

幾位會議參與者建議可以作為程式庫來做，但 Maxwell 反對在專案中將其作為 RPC 或程式庫來做：「我懷疑這是否值得我們為這樣的事情維護一個穩定的介面。例如，[Kalle Alm] 最近的分組 PR 會完全破壞幣選擇的介面 […] 維護穩定的 [幣選擇] 介面的壓力將對專案有害。[…] 我不想聽到『我們不能實作隱私功能 X，因為它會破壞 [幣選擇] 介面』。」

Wladimir van der Laan 說，「我認為這不是我們專案的關注點。有些其他人想要一個幣選擇演算法用於他們自己的目的。[那]很好，他們可以自己從中製作一個程式庫，程式碼是開放原始碼的。」Maxwell 建議，「也許他們應該貢獻使錢包程式碼變得更好，這樣他們就不必編寫自己的（吐舌頭笑臉）。」

結論： 儘管 RPC 方法的想法普遍遭到反對，Wuille 確實建議了一條前進的道路：「我認為這方面的第一步是我們無論如何都在做的事情：使程式碼本身更加封裝。也許一旦程式碼被充分封裝，其他人就可以將其程式庫化並維護它。」

#13697 更改 scantxoutset 的 API

背景： 最近合併的 PR #12196 新增了一個 scantxoutset RPC，允許使用者在目前可花費比特幣（UTXO 集）的集合中搜尋對應於一個或多個指定地址、公鑰、私鑰或 HD 金鑰集的任何輸出。如 6 月 28 日會議中所討論，Pieter Wuille 正在研究一種新方法來指定錢包應尋找哪些輸出（scriptPubKey），稱為輸出腳本描述符，他有 PR #13697 開放，以新增對此的支援到 scantxoutset，而不是目前向錢包描述金鑰和腳本的方式。

討論（日誌）： Wuille 請求並介紹了該主題，「首先，這是一個更大努力的一部分，將金鑰和腳本以及 [HD 錢包] 鏈組合成一個概念。有一種迷你語言可以指定（集合）scriptPubKey，所以我非常希望首先聽到對該語言的評論。另一個問題是 scantxoutset [是否] 實驗性的，[是否在] 0.17 中支援描述符？」

Wladimir van der Laan 和 Jonas Schnelli 都表示他們喜歡輸出腳本描述符的想法，他們也都支援將 scantxoutset 標記為 0.17 版本的實驗性功能，這將允許專案在後續版本中自由更改其 API，並輕鬆納入新 RPC 和新輸出腳本描述符語言使用者的回饋。

Luke Dashjr 問，「[輸出腳本描述符] 應該是 BIP 嗎？似乎在 Core 之外可能有用。」Wuille 回答，「可能是的，但不是第一時間。我預計這將發展得相當快。」

結論： 沒有人對將 scantxoutset 標記為 0.17 版本的實驗性功能的想法提出反對，也沒有人反對如果 #13697 通過審查則使用輸出腳本描述符。

Bitcoin-seeder 納入 bitcoin-core GitHub 組織

背景： 儘管 Bitcoin 使用點對點協定，但首次啟動的節點不知道要連接的任何對等節點的 IP 地址（除了一些用於最後手段使用的備用地址），因此它們從稱為 Bitcoin seeder 的程式請求最近活躍節點的 IP 地址列表。然後節點連接到這些對等節點，這些對等節點可以告訴新節點其他對等節點，因此所有未來的連接通常都可以完全去中心化地進行——但如果去中心化對等節點查找對它不起作用，節點可以再次使用 seeder。

有幾個由不同作者編寫的 seeder 程式。其中一個由 Pieter Wuille 維護，簡稱為 bitcoin-seeder。

討論（日誌）： Lucas Betschart 請求並介紹了該主題：「我認為因為 bitcoin-seeder 有一些開放的 issue 和簡單的 PR，[所以]可能有幾個 Bitcoin 維護者擁有合併權限是有意義的。」

Wuille 回答，「就我而言沒問題，但我不確定這是否是正確的訊息。」Luke Dashjr 呼應了這種情緒。

結論： Sjors Provoost 建議，「另一種方法可能是 [Wuille] 給更多人訪問該儲存庫的權限？」Wuille 回答，「我同意！」Betschart 說，「我也同意。」

脫離 Bitcoin.org

背景： 自 2009 年發布原始 Bitcoin 軟體以來，Bitcoin（後來的 Bitcoin Core）資源一直託管在 Bitcoin.org 上。隨著時間的推移，這增加了關於日益多樣化的 Bitcoin 網路的額外資源。

2015 年 12 月，Bitcoin Core 開始使用自己的網域來託管其資源，後來也用於託管其軟體版本。版本公告和軟體繼續鏡像到 Bitcoin.org。

討論： Andrew Chow 透過建議「脫離 Bitcoin.org」來介紹該主題。他補充說，「我們仍然連結到 bitcoin.org 以獲取下載等資訊。[我們]可能應該更改這些。」完整討論請參見日誌。一些討論也發生在會議之後。

結論： 沒有明確的結論。會議後的討論似乎表明目前的流程不會有重大變化。

下次 CoreDev 技術會議

背景： Bitcoin Core 團隊的一些成員定期舉辦一個主要針對 Bitcoin Core 貢獻者的僅限邀請活動，讓每個人都能親自審查和討論各種專案。有關更多資訊，請參見 CoreDev.Tech 網站。

討論（日誌）： Steve Lee 請求並介紹了該主題，「我自願組織下次 Core Dev Tech 聚會。目前的想法是在 10 月的 Scaling Bitcoin 之後在東京舉行，10 月 8-10 日，並以類似於上次在紐約的方式組織。」

幾個人感謝 Lee。

結論： Lee 說，「我計劃發送一份調查來收集一些回饋。如果有人有具體的想法或建議，請隨時與我聯繫。」

幽默

          <sipa> what about #13666 ?
<provoostenator> What's in a number?
          <sipa> 13 and 666, can't beat those odds
        <wumpus> niice
      <achow101> it was completely planned, obviously
          <sipa> in some timezones it was also opened on
                 friday the 13th
                 oh, no
 <jonasschnelli> I hope no black cat was sitting on the
                 keyboard during coding

參與者

IRC 暱稱	姓名/匿名
wumpus	Wladimir van der Laan
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
achow101	Andrew Chow
luke-jr	Luke Dashjr
gmaxwell	Gregory Maxwell
moneyball	Steve Lee
provoostenator	Sjors Provoost
jnewbery	John Newbery
cfields	Cory Fields
lclc	Lucas Betschart
ken2812221	Chun Kuan Lee
kanzure	Bryan Bishop

免責聲明

2018-07-12 IRC 會議摘要

Thu, 12 Jul 2018 00:00:00 +0000

概覽

會議時間民意調查
推遲功能凍結日期？
0.16.2
Gitian 建置到 18.04 Ubuntu Bionic
PR #12257 的狀態：幣選擇目標群組
小主題
參與者
免責聲明

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括宣布一項民意調查以幫助尋找未來每週會議的普遍可接受時間、是否推遲 Bitcoin Core 0.17 的計劃功能凍結日期、是否產生 0.16.2 維護版本（以及何時進行）、將確定性建置環境升級到新版本 Ubuntu 的狀態，以及與錢包自動選擇花費哪些幣（輸入）相關的 PR 的狀態。

通常的第一個主題高優先級審查拉取請求被跳過了。Wladimir var der Laan 說，「我這次有意跳過了高優先級審查。[似乎]非常清楚[我們]只需要盡快將 0.17 的功能加入。」

會議時間民意調查

背景： 如上次會議所述，專案正在嘗試確定舉行每週會議的最佳時間。

討論（日誌）： Cory Fields 說，「記得投票選擇會議時間。如果您沒有收到關於它的郵件，現在是告訴我的時候！[民意調查]下週此時結束。」

結論： 如果您是常規貢獻者，請檢查您的電子郵件以獲取相關民意調查或聯繫 Fields。

推遲功能凍結日期？

背景： Bitcoin Core 嘗試每六個月發布一個新的主要版本。發布流程的第一步是凍結當前功能集，以便可以將重點轉移到即將發布的版本的成熟、測試和文件編寫上。

討論（日誌）： Wladimir van der Laan 介紹了該主題，「所以目前的功能凍結是 7 月 16 日，也就是幾天後 […] 我的問題是，我們應該推遲它嗎，[或者]是否有重要的事情[我們]否則會錯過但[哪些]幾乎準備好了？」

幾位會議參與者列出了他們希望加入但擔心在凍結前無法完成的事情：

新的 scantxout RPC，由 Jonas Schnelli 提到
用於純監視錢包的新 disableprivatekey 設定，由 Schnelli 提到
部分簽名比特幣交易支援，由 Andrew Chow 提到
機器可寫配置檔案（rwconf），由 Luke Dashjr 提到

結論： 功能凍結日期推遲一週至星期一，7 月 23 日。

0.16.2

背景： Bitcoin Core 偶爾會產生維護版本，將錯誤修復和次要改進向後移植到現有版本的 Bitcoin Core。最近的一次是 Bitcoin Core 0.16.1，大約一個月前發布。

討論（日誌）： 該主題在會議前被建議。Wladimir van der Laan 說，「很快做一個 0.16.2 版本是有意義的，這樣它就不會在 0.17 之前太短。[是否有]除了 #13644 中已經向後移植的內容之外，還有什麼真正需要加入的？」會議中沒有人建議任何進一步的向後移植。

關於發布時間有一些討論。Luke Dashjr 建議可以在 0.17.0 的第一個候選版本（RC）開始建置之前不久發布 0.16.2。其他會議參與者主張將它們分開，Cory Fields 說，「但這樣如果向後移植出錯，可能兩個新版本都會出問題。我寧願[將發布]錯開一點，一般來說。」

結論： Van der Laan 說，「確保您審查 [#13644]。」之後，專案將產生 0.16.2 RC1。如果在其發布後大約一週內沒有關於 RC1 的錯誤報告，將標記 0.16.2 最終版。

Gitian 建置到 18.04 Ubuntu Bionic

背景： Gitian 是 Bitcoin Core 用來允許多人編譯相同程式碼以建立相同可執行程式的系統，這個過程稱為確定性建置。這允許每個建置者對程式進行加密認證，證明它是同行評審原始碼的結果。要產生相同的程式，每個人都需要使用完全相同的建置軟體，包括在虛擬環境中執行的相同作業系統。目前該作業系統是舊版本的 Ubuntu；對於下一個版本，計劃是使用最新的長期支援（LTS）版本的 Ubuntu，18.04（代號 Bionic Beaver）。

討論（日誌）： Wladimir van der Laan 開始了討論，「請注意，我們必須升級，否則 Qt 建置將失敗（或[我們]必須再次降級 Qt，這是一團糟）。」

一直在研究建置系統工具鏈重大更新的 Cory Fields 說，「我一直否認我會及時為 0.17 完成工具鏈工作。遺憾的是，這不會發生。[我]剛開始查看目前的 PR。」

Andrew Chow 提到他研究了基於 Docker 的建置系統，其他人提到了各種其他系統。

作為一個子主題，Fields 提到，「在某個時候，我們將不得不使用 Gitian（或類似的）來建置全確定性工具鏈。所有工具鏈的工作還沒有完成，但我確實有一些可用的東西可以讓我們獲得一個原生的。我建議我們繼續建置那個，以便它以後可以用來建置其餘的 […] 由於以確定性方式完成，我們根本不必依賴發行版工具鏈來建置 0.18。」

結論： 工作將繼續進行，以確保專案更新的 Gitian 配置在候選版本準備好建置時準備就緒。Fields 將「嘗試收集足夠的內容來 PR 一些東西」，與他的初始全確定性工具鏈工作相關。

PR #12257 的狀態：幣選擇目標群組

不是標記的主題，而是在上一個主題之後開始的單獨討論。

背景： 過去六個月中大量工作的重點是 Bitcoin Core 的幣選擇——其錢包如何決定在特定交易中花費哪些輸入。PR #12257 向 Bitcoin Core 的錢包新增了一個選項，使其在花費任何這些輸出時花費接收到同一地址的每個輸出。這防止了同一地址的兩個輸出在單獨的交易中被花費，這是錢包降低隱私的常見方式。缺點是它可能使交易比它們需要的最小值更大。

討論（日誌）： Gregory Maxwell 問，「我猜 [PR #12257 的作者 Kalle Alm] 不在這裡（時區[衝突]），但我想知道 #12257 的狀態如何？」

Pieter Wuille 回答，「我推遲了[審查]它，預期其他更具侵入性的幣選擇變更會先進入，但如果這不會在 0.17 中發生，也許我們可以先進行目標群組。」

Andrew Chow 建議模擬其行為以及他的單次隨機抽取幣選擇程式碼，如先前會議中所述。

結論： Maxwell 說，「我忘記了 [PR #12257]，聽起來我們其他一些人也忘記了 […] 請將自己視為已被提醒。」

小主題

獨角獸： 幾位會議參與者注意到 GitHub 頁面再次無法載入，如至少六次先前會議（1、2、3、4、5、6）中所述，而是顯示一個生氣的獨角獸插圖。這阻止了對 Bitcoin Core PR 的審查，或至少在審查者嘗試解決方法時減慢了它們。

參與者

IRC 暱稱	姓名/匿名
wumpus	Wladimir van der Laan
luke-jr	Luke Dashjr
cfields	Cory Fields
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
achow101	Andrew Chow
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
meshcollider	Samuel Dobson
BlueMatt	Matt Corallo
kanzure	Bryan Bishop
MarcoFalke	Marco Falke
ken2812221	Chun Kuan Lee
jamesob	James O’Beirne
jnewbery	John Newbery
nmnkgl	Gleb Naumenko

免責聲明

2018-07-05 IRC 會議摘要

Thu, 05 Jul 2018 00:00:00 +0000

概覽

高優先級審查
交替會議時間
[降低預設]最低中繼費用
幽默
參與者
免責聲明

在 BotBot.me 或 MeetBot (第 1 部分) 和 MeetBot (第 2 部分) 上查看本週的日誌
MeetBot 的會議記錄第 1 部分和第 2 部分

本週 MeetBot 記錄和日誌分為兩部分，因為最初的會議主持人不得不在會議中途離開。

本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求（特別是鑒於即將到來的 Bitcoin Core 0.17 功能凍結）、交替每週會議的時間，以及降低預設最低中繼費用。

高優先級審查

討論（日誌）： Wladimir van der Laan 開始討論時說，「看起來只剩下一件事：#12196」，它新增了一個 scantxoutset RPC 方法。然後他補充說，「提醒 0.17 功能凍結是 2018-07-16，大約一週後。」在該日期之後，不鼓勵貢獻者為即將發布的 0.17 版本提議包含新功能的 PR，以便每個人都可以專注於在發布前尋找和消除任何錯誤或其他不當行為。

隨著該截止日期的臨近，會議參與者建議將以下 PR 新增到高優先級列表：

#13547： 使 signrawtransaction 在需要但缺少金額時給出錯誤。由 AJ Towns 建議，Pieter Wuille 支援。
#12458： 強制為 signrawtransaction prevtxs 提供金額。由 Towns 建議，Wuille 支援。
#13072： 更新 createmultisig RPC 以支援 segwit。由 Towns 建議，Wuille 支援。
#11658： 在 IBD 期間進行修剪時，額外修剪 10% 以避免不久後再次修剪。由 Sjors Provoost 建議。
#13557： BIP174 PSBT 序列化和 RPC。由 Van der Laan、Wuille、Andrew Chow 和 Gregory Maxwell 請求或支援。
#13298： Net：每個網路群組的隨機延遲以混淆交易時間。由 Gleb Naumenko 建議，Maxwell 明確支援，Wuille 可能支援。
#13414： 在 github-merge.py 中支援 Gitlab API。由 r-f 請求，但 Van der Laan 提到可能與 Bitcoin Core 0.17 不相關。

結論： 除了最後一個 #13414 之外，上述所有 PR 都被新增到高優先級列表。

交替會議時間

背景： 每週的 Bitcoin Core 會議在每週的同一時間舉行，星期四 19:00 UTC。由 AJ Towns 轉換為當地時間（使用北半球夏令時間），這對應於當地時間：

UTC	NYC	LAX	Sydney	Tokyo	Delhi	Paris
19:00	15:00	12:00	05:00	04:00	00:30	21:00

對於位於大洋洲和東亞的 Bitcoin Core 貢獻者來說，這些時間特別不方便。

討論（日誌）： Sjors Provoost 請求該主題並以一個建議介紹它，「我的建議是一些簡單的事情，例如每週交替 12 小時。」

一些會議參與者對該時間或交替會議時間導致的混亂表示擔憂，儘管 Wladimir van der Laan 指出，「問題是支援[不同]時間的人現在可能不在這裡，[所以]這是不公平的。」

Towns 建議「8 小時的三階段循環應該使每個人都能參加 3 次會議中的 2 次 :-/」。會議結束後，Towns 將提供此類潛在時間表的以下地圖：

UTC	NYC	LAX	Sydney	Tokyo	Delhi	Paris
03:00	23:00	20:00	13:00	12:00	08:30	05:00
11:00	07:00	04:00	21:00	20:00	16:30	13:00
19:00	15:00	12:00	05:00	04:00	00:30	21:00

結論： 最終建議有人建立一個民意調查以幫助找到哪些會議時間對不同貢獻者是可接受的，Cory Fields 同意管理該民意調查。

[降低預設]最低中繼費用

背景： Bitcoin Core 不會接受交易進入其記憶池（mempool），除非它們每虛擬千位元組（vKB）支付至少 0.00001000 BTC 的費用，有時寫為每位元組 1 聰（1 sat/B）。這個最低費用水準是幾年前設定的，當時每比特幣的價格（以美元計）約為現在的 1/10，因此它可能太高了——特別是因為節點最近很少在其記憶池中看到超過幾個區塊價值的交易。

Bitcoin Core 還有一個單獨的最低增量中繼費用設定，有助於防止濫用手續費替換機制，但它與最低中繼費用相互作用。

討論（日誌）： 引用了 Twitter 上的討論，建議應降低或理想情況下消除最低中繼費用。Gregory Maxwell 說，「我們的基礎設施設定為有最低費用。隨著費用趨近於零，每美元的中繼垃圾郵件數量趨向於無窮大。」

Pieter Wuille 指出，「最低中繼費用的影響有限，因為如果交易速率因[低費用]而上升，動態費率就會啟動。」這會將費率提高到新接收的交易只有在支付與目前記憶池中最便宜交易競爭的費率時才被接受的水準。

然而，Wuille 提到相關的增量中繼費用必須設定為合理的數量，以防止節點頻寬被濫用。

IRC 使用者 Booyah 提到，「有一些錢包，如 Mycelium，有時會計算錯誤，當準備 1 sat/B 交易時，最終得到 0.97.. sat/B 的實際交易，目前無法廣播。」AJ Towns 確認 Xapo 有類似的錯誤，並描述了發生的原因：「簽名比[錢包]估計的稍大，[所以] 1 sat/B 目標最終為 0.9 多 sat/B 並且不會傳播。」

會議參與者一致認為沒有什麼可以修復的。正如 Luke Dashjr 所說，「如果[最低中繼費用]是 0.5 sat/B，他們最終會[支付] 0.49。」

Dashjr 建議開發人員不要進行任何更改，而是讓使用者在他們之間開展活動以鼓勵更改該值。但 Wuille 指出，將值設定得較低與 BIP152 相關存在缺點：「不過，它降低了緊湊區塊中繼效率。節點營運者通常有動機選擇與礦工相同的值。」

與嘗試開發一個沒有最低中繼費用的設計相關，Maxwell 說，「嘗試使事情在沒有最低中繼費用的情況下工作可能不值得努力。有一堆愚蠢的行為，擁有一個低但非零的最低值可以避免。」

結論： Maxwell 說，「我會 PR 一些關於將其減半的東西。」

幽默

<gmaxwell> probably rather than discussing this here
           someone should go make some proposals (including
           times in common timezones).
<cfields> those annoying doodle availability polls handle
          this really well.
<sipa> cfields just volunteered? :)

參與者

IRC 暱稱	姓名/匿名
achow101	Andrew Chow
aj	Anthony Towns
booyah	booyah
cfields	Cory Fields
clarkmoody	Clark Moody
gmaxwell	Gregory Maxwell
luke-jr	Luke Dashjr
nmnkgl	Gleb Naumenko
phantomcircuit	Patrick Strateman
promag	Joao Barbosa
provoostenator	Sjors Provoost
Randolf	Randolf Richardson
r-f	r-f
sipa	Pieter Wuille
Varunram	Varunram Ganesh
wumpus	Wladimir van der Laan

免責聲明

2018-06-28 IRC 會議摘要

Thu, 28 Jun 2018 00:00:00 +0000

概覽

高優先級審查
Cipherseed
Core 的 BIP32 衍生「標準」
P2P 連結臨時加密
輸出腳本描述符
參與者
免責聲明

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、類似 BIP39 的新種子格式的草案規範、記錄 Bitcoin Core 如何使用 BIP32 HD 錢包標準、實作 BIP151 加密點對點連接的進度更新，以及圍繞向錢包軟體描述它們應將哪些輸出腳本視為使用者錢包一部分的新方法的討論。

高優先級審查

討論（日誌）： 唯一專門討論的 PR 是 #12196，它新增了一個 scantxoutset RPC，允許應用程式在所有目前的未花費交易輸出（UTXO）中搜尋與特定地址、公鑰、私鑰或 HD 錢包擴展公鑰（xpub）相符的輸出。

Pieter Wuille 建議 PR 的作者 Jonas Schnelli 暫時從 scantxoutset 中移除 xpub 支援，Wuille 稍後會 PR 一個更新到 scantxoutset，新增對本會議記錄後面描述的輸出腳本描述符的支援。如果 Wuille 延遲這樣做，Schnelli 可以在 Bitcoin Core 0.17 功能凍結前重新新增之前編寫的 xpub 支援。Schnelli 同意。

注意：會議這部分期間對輸出腳本描述符的擴展討論已移至單獨的部分。

Cipherseed

背景：（討論的一部分。）

討論（日誌）： Jonas Schnelli 請求並介紹了該主題，「我有一個規範草案用於一種新的種子格式，類似於 BIP39，具有一些巧妙的屬性，並且——在將[它]發送到郵件列表之前——將感激回饋。」

結論： Schnelli 說這「更像是一個公告而不是一個主題」，因此討論被推遲，直到人們有機會閱讀草案。

Core 的 BIP32 衍生「標準」

背景： HD 錢包規範 BIP32 定義了一組私鑰和公鑰（因此也包括地址）如何從 128 位元到 512 位元的隨機種子衍生。

討論（日誌）： Jonas Schnelli 請求並介紹了該主題，「今天在討論中提出 [Core 的] BIP32 衍生方案未在 BIP 中指定。有些人認為它是純粹/原生的 BIP32，但它不是，而其他[錢包]則使用原生 BIP32。」

Wladimir van der Laan 同意「如果差異記錄在某處會很好。」Luke Dashjr 反對它成為 BIP，Pieter Wuille 同意，Andrew Chow 建議「只需在文件儲存庫中記錄衍生就足夠了。」

注意：會議這部分期間對輸出腳本描述符的擴展討論已移至單獨的部分。

P2P 連結臨時加密

背景： BIP151 指定了一種方法，允許 Bitcoin 節點和客戶端通過加密連接發送其資料，以防止竊聽者直接監視正在傳輸哪些特定交易和區塊。這可以增強隱私的某些方面，例如使某人更難確定哪個 IP 地址首次傳輸特定交易（可能表明該 IP 地址的某人建立了該交易）。在 BIP151 規範中，連接的雙方僅為該連接和該會話生成金鑰——在連接關閉後銷毀金鑰；這些金鑰被描述為「臨時的」。由於臨時金鑰不被重複使用，因此無法使用它們來識別在不同網路（例如 Tor）上執行或在節點更改 IP 地址後執行的相同節點。

討論（日誌）： Gregory Maxwell 請求該主題並以一個問題開始討論，「最近在實作 P2P 連結臨時加密方面是否有任何進展？我知道我們有點在等待一些其他網路重構。」

Jonas Schnelli 說，「Armory 已經實作了它，並計劃將其 PR 到 Core（不確定多快以及什麼質量）。」

Cory Fields 說，「我不得不暫時將網路[重構]工作放在一邊，所以肯定不要等待它。我很樂意幫助[BIP151 的]實作。我以為我們在等待認證的東西。」

Schnelli、Maxwell 和 Pieter Wuille 都同意 BIP151 實作不應等待認證提案。

進一步的討論集中在加密的設定協定（初始握手）是否應該更難檢測，因此也更難阻止。然而，Maxwell 說，「我認為我們認為[所考慮方法的]好處太可疑了，特別是因為流量模式將非常清楚地識別 Bitcoin 點對點連結。[…] 所以我認為我們可以實作，唯一可能提出的變更將是作為實作和基準測試的副作用而產生的變更。」

結論： Schnelli 說，「如果沒有其他人想要研究實作，那麼我將繼續[我的] BIP151 實作。」

輸出腳本描述符

注意：這不是標記的主題，但在會議的其他兩個主題期間進行了討論。為了更容易閱讀，這些單獨的討論已從發生的位置提取出來並統一到這裡的一個主題中。

背景： Pieter Wuille 一直在研究 Bitcoin Core 錢包如何識別哪些交易屬於特定使用者錢包的重新設計。

討論（日誌第 1 部分、日誌第 2 部分）： 作為他錢包重新設計的一部分，Pieter Wuille 說他一直在研究相關的 scriptPubKey 集合的人類可讀描述的設計，它提供了「一種通用語言，將有關如何花費整組金鑰以及相關地址/腳本/私鑰/…的所有資訊編碼到一個字串中，包括對多重簽名等的支援…」

這透過允許「匯入/匯出[在]這些描述符的層級操作，而不是單個金鑰/腳本/公鑰/HD [錢包金鑰]鏈」來支援提議的錢包重新設計。[importmulti RPC] 在很大程度上已經與該設計相容。整個想法肯定不適用於[下一個主要 Bitcoin Core 版本，] 0.17，但這並不意味著它不能已經在相對小範圍的事情中使用[像] scantxoutset。」

這導致 Wuille 建議 PR #12196 暫時移除其擴展公鑰支援，以便 Wuille 可以允許新的 scantxoutset RPC 使用輸出腳本描述符。

Jonas Schnelli 問，「[輸出腳本描述符]將如何與金鑰池、靈活金鑰路徑和擴展公鑰互動？」金鑰池是屬於使用者錢包的一組金鑰；Bitcoin Core 尋找影響這些金鑰的交易並將它們新增到使用者的錢包中。靈活金鑰路徑指的是 HD 錢包的 BIP32 金鑰衍生路徑。

Wuille 說「金鑰池消失了 […] 實際上，[描述符]包含擴展的公鑰。[對於]靈活金鑰路徑，描述符只包含路徑；您可以將其更改為您喜歡的任何內容（但預設錢包當然會選擇一些標準方案）。」

結論： Wuille 將繼續研究輸出腳本描述符，包括計劃開啟一個 PR 將它們新增到 scantxoutset RPC。

參與者

IRC 暱稱	姓名/匿名
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
gmaxwell	Gregory Maxwell
cfields	Cory Fields
promag	Joao Barbosa
luke-jr	Luke Dashjr
achow101	Andrew Chow
meshcollider	Samuel Dobson
instagibbs	Gregory Sanders
kanzure	Bryan Bishop
jnewbery	John Newbery

免責聲明

2018-06-21 IRC 會議摘要

Thu, 21 Jun 2018 00:00:00 +0000

概覽

審查阻礙者[高優先級審查]
警報金鑰[公開揭露]
Bitcoin-dev 郵件列表
幣選擇
多錢包會話持久性
Bech32x
RWConf [可寫 Bitcoin 配置檔案]
幽默
參與者
免責聲明

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、何時揭露與簽名警報系統相關的 Bitcoin Core 0.12.0 及更早版本的已知 DoS 漏洞以及啟動 DoS 攻擊的機制（中本聰的警報簽名金鑰）、bitcoin-dev 郵件列表的託管變更、預設情況下如何選擇要包含在新交易中的輸入、處理多錢包模式下新錢包的載入、改進的私鑰備份和恢復，以及繼續致力於建立機器可寫配置檔案。

審查阻礙者[高優先級審查]

討論（日誌）： Pieter Wuille 列出了目前列表中的三個 PR（#13062、#12196 和 #13425），並詢問是否有人想提名其他 PR。João Barbosa 建議 #13100，它新增了一個開啟錢包的選單項目，但它還沒有完全準備好，所以 Wuille 將等到準備好再新增它。

警報金鑰[公開揭露]

背景： 2010 年，有人建立了一個協定有效的區塊，建立了超過 1840 億比特幣。中本聰鼓勵使用者停止挖礦，並很快發布了 Bitcoin 的更新版本，在追溯軟分叉中更正了該行為，但他隨後向 Bitcoin 軟體新增了一種機制，允許他簽署「警報」訊息，可以直接通知節點營運者問題，甚至預設情況下關閉可能導致金錢損失的某些節點功能。在中本聰對 BitcoinTalk.org 論壇的最後一篇文章中，他寫道：

「安全模式」警報是 0.3.9 溢位錯誤後的臨時措施。我們可以說使用者可以使用「-disablesafemode」執行，但為了外觀起見，最好不要使用它。它從來沒有打算作為長期功能。安全模式仍然可以透過看到更長（更大的總 PoW）無效區塊鏈來觸發。

隨著時間的推移，後續的 Bitcoin Core 開發人員穩步棄用、停用和移除警報功能，在 0.12.1 版本中預設關閉它，在 0.13.0 版本中完全移除它，在 0.14.0 版本中硬編碼最終警報，並（2016 年 11 月）宣布即將公開揭露中本聰建立的警報簽名金鑰。在 Bitcoin Core 0.12.1 以下版本中發現與警報機制相關的拒絕服務（DoS）漏洞後，揭露被無限期延遲，如 2017 年 3 月 9 日每週會議中所討論，當時影響了大約 2,600 個節點。

討論（日誌）： Bryan Bishop 請求並介紹了該主題，「我正在考慮釋出私有[警報簽名]金鑰。[這]會很好地讓它公開並消除該責任。我特別有興趣聽到其他有充分理由不揭露金鑰的人的意見。在宣布[計劃公開揭露]以來的一年多時間裡，我認為沒有提出太多。」

Gregory Maxwell 說，「所有受支援的 [Bitcoin Core] 版本都完全[移除了簽名警報系統]，所以現在釋出聽起來相當不錯——除非 0.12 之前的節點仍然很受歡迎，我不相信它們是。」

Luke Dashjr 引用他的節點掃描系統說，3% 的節點執行 0.12 版本，「0.61%『其他』版本，其中包括 0.12 之前的所有版本。」Pieter Wuille 使用 Bitnodes 掃描系統發現了類似的統計資料，該系統使用不同的掃描方法。

關於舊版本 Bitcoin Core 中與簽名警報訊息相關的漏洞，Maxwell 說，「我懷疑我們不知道所有漏洞。我知道至少兩個，但我停止尋找了。」Andrew Chow 說他知道三個。

DoS 漏洞不僅影響 Bitcoin，還影響複製了 Bitcoin Core 程式碼並目前使用舊版本的山寨幣。當揭露漏洞時，任何擁有山寨幣警報簽名金鑰的人都將能夠執行這些 DoS 攻擊。在討論這個問題時，Chow 說，「[但]如果山寨幣更好地控制了它們的警報金鑰，發布 Bitcoin 的金鑰和相關漏洞應該不是問題。」

結論： 沒有明確的結論。Bishop 似乎可能會繼續努力負責任地揭露警報金鑰和（可能）與其相關的漏洞。沒有人反對這一點，儘管 Matt Corallo 確實說他認為「釋出警報金鑰的實用性有限。」

Bitcoin-dev 郵件列表

背景： bitcoin-dev（Bitcoin 開發）郵件列表在過去幾年中一直託管在 lists.linuxfoundation.org。

討論（日誌）： Bryan Bishop 請求並介紹了該主題：「Linux Foundation 正在從電子郵件協定遷移，將不再託管 bitcoin-dev 郵件列表。有一個遷移計劃，但它仍在調查中。」

關於列表目前的傳遞問題進行了一些簡短的討論，表達了希望現有舊文章的 URL 保持有效，以及其他遷移問題。

結論： Bishop 將向郵件列表發送一封電子郵件，希望在遷移到新主機網域之前，一旦他有更多細節就會提供。

幣選擇

背景： 幾位開發人員一直在努力改進 Bitcoin Core 的幣選擇——它如何選擇要花費哪些比特幣（輸入）——以同時改善隱私、減少交易大小和降低費用。目前的選擇協定從分支定界（BnB）演算法開始，該演算法嘗試在可用輸入和發送金額之間找到匹配。如果這不起作用，則需要一個備用演算法。單次隨機抽取（SRD）演算法隨機將額外輸入新增到部分交易中，直到輸入的總和等於或大於正在花費的金額（包括費用）。

本週的討論是上週討論的延續，關於同一主題。

討論（日誌）： Andrew Chow 請求並介紹了該主題，「我對[單次隨機抽取]備用內容進行了大量模擬（連結）。我看到這個策略有兩個問題：找零可能非常小，錢包中 UTXO 的平均數量相當高。問題是我們是否可以接受這些權衡，或者我們是否需要找到更好的演算法。」

Gregory Maxwell 說，「[如果我沒記錯的話]，[單次隨機抽取]沒有什麼根本性的東西使它對使[分支定界]更好地工作有好處，而是它是 [Mark Erhardt] 在那裡嘗試的第一個替代方案。」

Chow 補充說，「嗯，在 [Erhardt] 的模擬中，[單次隨機抽取]表現得相當好，而且非常簡單。儘管我想我們現在可能看到不同的結果。」

討論了各種額外的策略及其權衡，但該主題開始變得對一個有時間限制的純文字會議的簡短部分來說變得複雜。

結論： Chow 建議，「也許這個幣選擇討論最好親自用白板進行，」結束會議討論，儘管 Maxwell 指出，「這會排除無法參加的人。」推測討論將在 PR #13307 和可能的其他地方繼續。

多錢包會話持久性

背景： Bitcoin Core 的開發分支（「master」分支）包含允許使用者在多錢包模式下動態載入和卸載單個錢包的程式碼。例如，您可以擁有一個「個人」錢包和一個「商業」錢包，每個都可以單獨開啟或關閉。

討論（日誌）： Jonas Schnelli 請求並介紹了該主題，「我想在 Bitcoin Core 重新啟動後需要重新載入已載入的錢包不是理想的——特別是在修剪模式下。」也就是說，建立或載入錢包然後重新啟動 Bitcoin Core 而不更改配置檔案的使用者將不得不在下次載入該錢包時重新掃描區塊鏈的最新部分。更糟糕的是，如果重新掃描需要的某些區塊已被修剪，使用者將無法使用錢包。

幾位會議參與者建議這就是正在開發可寫 Bitcoin 配置檔案（rwconf）的原因。有關背景，請參見 PR #11082 和 2018 年 5 月 24 日和 2018 年 6 月 7 日的每週會議記錄。

結論： 「好吧，我猜 rw/config 解決了這個問題，所以 /topic，」Schnelli 說。

Bech32x

背景： 幾位 Bitcoin Core 貢獻者一直在努力建立一種新的序列化格式，用於備份和恢復 Bitcoin 私鑰、HD 錢包種子、HD 錢包擴展私鑰和 HD 錢包擴展公鑰。主要目標是用一個新標準取代目前流行的 base58check 和 BIP39 標準，該標準不僅檢測錯誤，還可以為使用者自動更正其中幾個錯誤。該提議格式的當前想法重複使用為建立 bech32 原生 segwit 地址格式而執行的一些工作，因此工作在名稱「bech32x」下進行（但這可能稍後會改變）。

討論（日誌）： Jonas Schnelli 請求並介紹了該主題，「Bech32x 目前具有距離 27 BCH，可更正到 7 個字元，感謝 [Pieter Wuille]。現在的想法是有三個『級別』的更正。[…] 對於 512 位元金鑰材料，七個字元不超過 5% 的更正[所以至少對於該情況需要更多]。」

Wuille 提出提供三個使用者可以選擇的程式碼。Gregory Maxwell 說，「我認為使其普遍可由使用者選擇不好。使用者通常無法做出有用的決定——但使格式支援多個程式碼在我看來似乎沒問題，儘管它可能會降低編寫精緻解碼器的可能性，因為這將是更多的工作。」

Wuille 說，「我們可以確保它們使用相同的欄位和擴展，以便大部分恢復程式碼可以共享。」Wuille 和 Maxwell 繼續談論為此目的選擇最佳 BCH 程式碼的細節。

結論： 會議結束的時間在討論期間發生，Maxwell 說，「稍後繼續。」

RWConf [可寫 Bitcoin 配置檔案]

此主題在會議期間被請求，但沒有足夠的時間。儘管如此，一些參與者在會議結束後立即留下來討論它。

背景： 如 2018 年 5 月 24 日會議中所討論，幾位貢獻者正在努力建立一個機器可寫配置檔案，該檔案將在 Bitcoin Core 的守護程式和 GUI 之間共享，以便當使用者在一個程式中更改設定時，它將在另一個程式中以相同的方式設定。在 2018 年 6 月 7 日會議中提出了建立新配置檔案的特定問題，但最熟悉該主題的人不在場；他在這次會議後討論中在場。

討論（日誌 rwconf）： Luke Dashjr 請求了該主題，並在會議後透過詢問 AJ Towns 是否反對 Dashjr 回復 Towns 的一個提交（該提交更改了 Bitcoin Core 啟動時如何處理命令列和配置檔案參數）來介紹它。這將解決 Dashjr 在建立可寫配置檔案時遇到的問題。

Pieter Wuille 建議了一個額外的機制，Towns 指出了 Dashjr 提案與網路配置相關的潛在問題。然而，Towns 說，「無論如何，我不反對更改地圖內容，[它]只是我能看到的獲得相對理智行為的最簡單方法。」

結論： 沒有明確的結論。推測 Dashjr 將繼續致力於建立機器可寫配置檔案。

幽默

<gmaxwell>  I doubt we know all the vulnerabilities.
            I know of at least two but I stopped looking.
<achow101>  gmaxwell: I believe I know of three
<gmaxwell>  Also depends on how you count. :)
<achow101>  that too
    <sipa>  i tend to count using the ring of integers

參與者

IRC 暱稱	姓名/匿名
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
kanzure	Bryan Bishop
achow101	Andrew Chow
luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
Murch	Mark Erhardt
BlueMatt	Matt Corallo
meshcollider	Samuel Dobson
promag	Joao Barbosa
aj	Anthony Towns
jnewbery	John Newbery
instagibbs	Gregory Sanders
jtimon	Jorge Timón

免責聲明

2018-06-14 IRC 會議摘要

Thu, 14 Jun 2018 00:00:00 +0000

概覽

高優先級審查
SRD [單次隨機抽取] 備用幣選擇
小主題
幽默
參與者
免責聲明

在 BotBot.me 或 MeetBot 上查看本週的日誌
MeetBot 的會議記錄

本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、Bitcoin Core 是否應該基於生成沒有找零的交易（更好的隱私和費用）或僅花費經過充分確認的輸入的交易（較少可能導致支付失敗）來優化選擇花費哪些輸入，以及一些小主題，主要集中在為各種電腦處理器架構優化 SHA256d 功能。

高優先級審查

討論（日誌）： 本週提到了以下待處理的 PR：

#12136： 實作 BIP174 部分簽名比特幣交易序列化和 RPC。根據其作者 Andrew Chow 的請求從列表中移除，他說「它依賴於 #13425。」
#13425： 將最終 scriptSig 構造從 CombineSignatures 移至 ProduceSignatures。Pieter Wuille 評論，「#13425 幾乎是所需的所有[部分簽名比特幣交易]內部變更，不包括序列化和 RPC。」
#13111： 新增 unloadwallet RPC。會議評論表明這在解決最後一個問題後接近合併。
#13160： 解鎖已花費的輸出。建議加入高優先級列表，但被拒絕，因為其作者已經在列表上有一個條目。儘管如此，Wladimir van der Laan 建議它應該得到更多關注。
#13439： RPC：避免無效 submitblock 的「重複」回傳值。

SRD [單次隨機抽取] 備用幣選擇

討論（日誌）： Andrew Chow 請求並介紹了該主題，「我認為我們應該討論 [Gregory Sanders 的] 觀點這裡。」引用的評論說，「這個新邏輯意味著非 BnB 將更頻繁地被嘗試。我們似乎[切換到]嘗試 6 次確認的 BnB，然後 6 次確認的非 BnB，而不是嘗試 BnB 的所有變體（6 次確認、1 次確認、小鏈等）。[…] 由於無找零交易的隱私原因，我更喜歡 master 中的[先前]行為。」

Pieter Wuille 問，「所以這有點是關於我們的幣選擇演算法應該優先考慮什麼的問題：已確認的幣還是（即時）費用[減少]？」

Sanders 同意並補充說，「還有隱私。[…] 無找零輸出在很大程度上干擾了幣分析。」

Chow，也許還有其他人，已經對新行為、早期版本 Bitcoin Core 的行為以及各種替代方案進行了模擬。然後對話簡要討論了這些結果及其含義，至少有兩位參與者表示他們希望看到進行更多模擬。

結論： 沒有明確的結論。Chow 正在執行更多模擬，他、Wuille 和 Sanders 提到當它們可用時在 PR 上討論它們。

小主題

Pieter Wuille 說，「我有 4 個與優化硬體 SHA256 相關的 PR。我應該將它們合併為 1 個 [PR]，還是保持這樣？#13471、#13386、#13442、#13438」Wladimir van der Laan 反對合併 #13438，並建議它可能很快合併，但 Van der Laan 或其他任何人都沒有對其餘 PR 是否應該合併發表評論。
關於 #13442，此 PR 引入的優化程式碼最初執行速度比優化之前慢。其作者 Wuille 此後已改進它以使其更快，但他指出它「非常依賴於編譯器：重新排列兩行可能對速度有 5% 的影響，或使常數靜態化，[…] 或使用特定的 GCC 版本。」Van der Laan 說，「如果它隨著新編譯器變得更快，那很好；如果更慢，則不好。:)」
關於管理 Bitcoin Core 0.16.1 的發布簽名進行了一些簡短的討論。

幽默

<ryanofsky> cd
  <cfields> ~$

參與者

IRC 暱稱	姓名/匿名
wumpus	Wladimir van der Laan
sipa	Pieter Wuille
instagibbs	Gregory Sanders
achow101	Andrew Chow
cfields	Cory Fields
promag	Joao Barbosa
meshcollider	Samuel Dobson
luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
MarcoFalke	Marco Falke
jnewbery	John Newbery
kanzure	Bryan Bishop
ryanofsky	Russell Yanofsky

免責聲明

IRC meeting summary for 2018-06-07

Thu, 07 Jun 2018 00:00:00 +0000

概覽

0.16.1 發行進度
高優先級審查
命令列參數對應
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：下一個維護版本進度的快速更新、專案成員希望審查者在下週重點關注的拉取請求，以及為 Bitcoin Core 內部追蹤命令列參數找到更好的方法。還有一些關於為各種電腦處理器架構最佳化程式碼的旁話討論。

0.16.1 發行進度

這不是宣布的主題，但在其他主題之前簡要討論了。

Wladimir van der Laan 宣布標記版本 0.16.1 的第二個候選版本，要求 Gitian 建置者產生簽署的校驗和，並說：「我希望這能很快成為最終[版本]。」

高優先級審查

背景： 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的目前高優先級 PR 列表。

討論（記錄）： 本週提到的待處理 PR 如下：

#12196： 新增 scantxoutset RPC 方法。先前在列表上。
#13062： 使腳本直譯器獨立於儲存類型。先前在列表上。
#11082： 新增軟體本身用於修改的設定所使用的新 bitcoin_rw.conf 檔案。先前在列表上。此 PR 的作者 Luke Dashjr 有一些擔憂，在會議稍後作為單獨的主題進行了討論。
#12136： 實作 BIP 174 部分簽署的比特幣交易。先前在列表上。Wladimir van der Laan 指出，這在上週有大量活躍的討論。此 PR 的作者 Andrew Chow 說，它和其相關的 BIP 仍然需要更多審查。Pieter Wuille 補充說：「我也一直在討論將其中的部分拆分的一些想法。」
#13111： 新增 unloadwallet RPC。先前在列表上。Van der Laan 說它「應該非常接近[可合併]。」

還有一些關於處理器特定最佳化和測試的討論，主要由 Pieter Wuille 和 Cory Fields 撰寫和執行，其他幾位開發者協助在特定硬體平台上進行測試。這些與 SSE4、SSSE3、SIMD 和 AVX 有關。

命令列參數對應

背景： 如先前會議中所討論的，幾位貢獻者正在努力建立一個機器可寫入的設定檔，該檔案將在 Bitcoin Core 的守護程序和 GUI 之間共享，以便當使用者在一個程式中變更設定時，它將在另一個程式中以相同的方式設定。

討論（記錄）： Luke Dashjr 提出了這個主題，並透過描述 Bitcoin Core 如何處理啟動參數的最近變更來介紹它。「該變更使如何實作[機器可寫入的設定檔]變得複雜。」

幾位開發者表示他們對互動的理解不夠好，無法對此事發表評論，Pieter Wuille 說：「我覺得合適的人不在這裡討論這個。」

John Newbery 說，有問題的變更「新增了非常好的程式碼覆蓋率 […]，所以應該相當直接地遵循。」

結論： 建議 Dashjr 聯繫一位不在會議中但具有更多知識的開發者，檢查目前可用的測試，並理想情況下在進行任何重大變更之前編寫更多測試以確保正確的行為。Dashjr 同意：「聽起來無論哪種方式，我都應該從測試開始。」

幽默時刻

<wumpus> I do not have the capacity to pay attention to
         all PRs in parallel
<promag> really? :P
<sipa> we need to have an AVX2 wumpus
<wumpus> sipa: +1
<sipa> +8

參與者

IRC 暱稱	姓名/化名
wumpus	Wladimir van der Laan
sipa	Pieter Wuille
luke-jr	Luke Dashjr
gmaxwell	Gregory Maxwell
promag	Joao Barbosa
cfields	Cory Fields
achow101	Andrew Chow
jonasschnelli	Jonas Schnelli
jnewbery	John Newbery
jimpo	Jim Posen

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請開啟一個議題，我們將更正錯誤。

IRC meeting summary for 2018-05-31

Thu, 31 May 2018 00:00:00 +0000

概覽

高優先級審查
C++14
支援 256 位元 IP 位址的新「addr」P2P 訊息
種子器加固
小主題
參與者
免責聲明

本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、專案何時應該升級程式碼庫和建置系統以使用 C++14 標準、在點對點網路協定的擴充 addr 訊息中要考慮哪些設計因素，以及如何為託管 Bitcoin DNS 種子器的人過濾掉聲稱是 Bitcoin 節點的競爭幣節點。

高優先級審查

討論（記錄）： 以下 PR 被提名加入高優先級列表。全部被新增。

#13062： 使腳本直譯器獨立於儲存類型 CScript（由 Pieter Wuille 請求）
#13111： 新增 unloadwallet RPC（由 Joao Barbosa 請求）
#11082： 新增軟體本身修改的設定所使用的新 bitcoin_rw.conf 檔案（由 Luke Dashjr 請求）
#13058： [wallet] createwallet RPC - 在執行時建立新錢包（由 Jonas Schnelli 請求，但可能已經在列表上）

C++14

背景： Bitcoin Core 編寫的 C++ 程式語言是由規範定義並由多個不同的編譯器和標準函式庫實作。定期會發布新規範，編譯器和標準函式庫會更新，像 Bitcoin Core 這樣的專案需要決定何時從使用舊編譯器和標準函式庫升級到較新的版本。Bitcoin Core 目前使用的 C++ 規範稱為 C++11；更新的規範是 C++14。

討論（記錄）： Pieter Wuille 提出了這個主題並介紹說：「鑑於[測試和建置基礎設施]將建立在 [Ubuntu] Bionic 上，這可能為使用支援 C++14 的更現代編譯器打開了大門。」

Wladimir van der Laan 參考了專案的追蹤議題，#13356。

討論圍繞著哪些作業系統支援哪些版本的 C++，但也討論了專案上次變更主要 C++ 版本的時間，其中至少有一個大型礦工很長時間沒有升級，因為他們執行的舊作業系統不支援新的 C++ 版本，並且正在編譯他們的舊二進位檔案。

結論： 目前沒有進行變更。Wuille 建議：「在[版本] 0.17 分支後，或甚至在 0.18 週期的後期，我們看看如何。我們現在無法在這裡決定任何事情——只是提前提出潛在問題是好的。」

支援 256 位元 IP 位址的新「addr」P2P 訊息

背景： Bitcoin 的點對點網路協定使用 addr 訊息允許節點告訴其對等點任何可能接受傳入連線的節點；這允許節點在沒有集中協調的情況下找到新的對等點。目前的 addr 訊息僅支援最多 128 位元的位址，這足以用於傳統 IP 位址（IPv4）、現代 IP 位址（IPv6）和舊式 Tor .onion 隱藏服務——但它不支援需要 256 位元的較新式 Tor 隱藏服務，也不支援 I2P 匿名網路上的對等點。

討論（記錄）： Wladimir van der Laan 提出了這個主題並說：「我想做這個。首先是 BIP，當然。[有]什麼特別的我應該考慮的嗎？我的想法是引入一個新的 addr 訊息，為網路位址提供更多空間，[…] 以支援 I2P 和新的 TorV3 隱藏服務。」

Luke Dashjr 建議新增「8 位元來選擇網路架構。」Van der Laan 同意。Dashjr 也建議新增多位元服務旗標，但 Van der Laan 反對：「我不想有太多的範圍蔓延。」

Olaluwa Osuntokun、Pieter Wuille 和其他人討論了在新的 addr 訊息中與其 IP 位址一起分發節點的公鑰。Osuntokun 贊成這個想法，但其他人反對，說它「洩漏了身份」，並且「大多數連線不需要[中間人]保護，因為他們連線的對等點沒有身份。[…] 問題是能夠關聯屬於同一節點的多個 IP 位址。」

Suhas Daftuar 詢問新訊息是否可以宣傳節點願意為其對等點和客戶端提供哪些區塊。這在沒有解決的情況下進行了討論。

結論： Van der Laan 將撰寫並傳播一個討論提案。在會議之後，他發布了文件並從追蹤議題 #2091 連結到它。

種子器加固

背景： 對於首次連線到網路的節點和使用點對點協定的輕量客戶端，幾位知名社群成員託管 DNS 種子器，分發他們知道的節點的 IP 位址列表。會議中有三位託管種子器的人：Pieter Wuille、Jonas Schnelli 和 Matt Corallo。Wuille 和 Corallo 也分別是用於種子的軟體的作者。

討論（記錄）： Jonas Schnelli 提出了這個主題並介紹說：「似乎大多數活躍的 DNS 種子傳遞 ABC/BCash 對等點。這是一場貓捉老鼠的遊戲，但我們可以透過在爬取期間檢查最近的區塊（昂貴）或避免協定版本 >80000 來收緊螺絲。」

Pieter Wuille 檢查了他的種子器，發現「我似乎沒有很多 ABC 節點：我的前 100,000 個 IP 中有 30 個；我的前 10,000 個中有 13 個，我的前 1,000 個中有 1 個。」Schnelli 在他的前 1,000 個中有 58 個，但他建議也許他看到的問題是設定差異的結果，並討論了幾個可能的設定設定。

結論： Schnelli 將繼續調整他的設定，試圖消除不提供目前 Bitcoin 區塊的對等點。其他種子器可能希望比平常更密切地監控他們提供的對等點。

小主題

Cory Fields 問：「GitHub 獨角獸[頁面在 GitHub 上無法載入，而是顯示獨角獸插圖]有什麼更新嗎？我不記得這週看到任何，雖然我的瀏覽器的某些東西一定使它們對我來說很罕見。」幾位會議參與者回答說未載入的頁面已經修復，Fields 回答說：「太好了！」

參與者

IRC 暱稱	姓名/化名
wumpus	Wladimir van der Laan
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
BlueMatt	Matt Corallo
luke-jr	Luke Dashjr
cfields	Cory Fields
gmaxwell	Gregory Maxwell
roasbeef	Olaoluwa Osuntokun
promag	Joao Barbosa
jimpo	Jim Posen
sdaftuar	Suhas Daftuar
MarcoFalke	Marco Falke
ajtowns[m]	Anthony Towns
kanzure	Bryan Bishop
morcos	Alex Morcos

免責聲明

IRC meeting summary for 2018-05-24

Thu, 24 May 2018 00:00:00 +0000

概覽

[需要為] 0.16.1 [做什麼]
每個網路群組的隨機延遲以混淆交易時間
GUI 修剪設定和可寫入的設定檔
ScanTxOutSet RPC 命令
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：在產生版本 0.16.1 的第一個候選版本之前需要解決的問題、是否應該稍微延遲交易轉發以潛在地增加支付者隱私、如何儲存 Bitcoin Core GUI 和守護程序內部設定的設定，以便兩個程式都可以存取它們，以及 Bitcoin Core 是否應該新增掃描 UTXO 集的功能，即使它（假設性地）在未來可能不會以可掃描的形式儲存 UTXO 集。

[需要為] 0.16.1 [做什麼]

背景： Bitcoin Core 貢獻者正在努力發布 Bitcoin Core 0.16.1，這是一個維護版本，將包含錯誤修復和小改進。

討論（記錄）： Wladimir van der Laan 提出了主題，並直接討論了需要做的事情，這似乎是獲取拉取請求（PR）#13317 的審查。關於與 0.16.1 無關的 PR 是否應該獲得高優先級，有一些討論，Van der Laan 反對「我認為我們現在應該專注於 0.16.1；我們下週會再回到其他高優先級的東西。」

提出了兩個 PR 用於向後移植，#12172 和 #12431，但都被反對為有問題或不必要。

結論： 鼓勵審查者查看 #13317。

每個網路群組的隨機延遲以混淆交易時間

背景： 很多年前，當 Bitcoin 軟體收到一筆交易時，它很快就會嘗試將其轉發給其他對等點。這允許交易分析組織連線到大量節點，並假設他們從中接收交易公告的第一個節點可能是建立它的節點（或至少是最早轉發它的節點之一）。在 Bitcoin 版本 0.2.10 中，新增了一個功能，導致節點在將新交易轉發給不同群組的對等點之前等待不同的時間；這導致交易在網路中以較不可預測的方式傳播，以增加支付者隱私。後續版本改進了這個基本功能。

PR #13298 描述了上述方法的可能對策：交易分析組織多次連線到每個節點，增加他們更早而不是更晚聽到交易的機會，因此增加他們從中接收交易的第一個節點是其原始發送者的機會。同一個 PR 還提供了一種方法，透過使隨機延遲基於網路群組（大塊 IP 位址）而不是個別節點，來使多個連線對分析組織來說更昂貴，因此分析組織需要存取特定的 IP 位址範圍才能獲得成為早期接收者的相同機會

討論（記錄）： Pieter Wuille 提出了這個主題並描述了他想看到的：「我想簡要提出 #13298 […] 這對 P2P 交易轉發可能產生重大影響，它需要超越『程式碼是否運作』的審查。但它也只是本地政策，而不是需要 BIP 的東西[我認為]。也許沒有更多要說的了，[我]只是希望讓人們考慮一下。」

P2P 交易轉發上可能的重大影響是延長交易（但不是區塊）從其發起對等點傳播到 90% 或更多其他節點所需的時間。

結論： 沒有討論，只是建議審查者訪問 PR，考慮其影響，並提供任何建議的評論。

GUI 修剪設定和可寫入的設定檔

背景： Bitcoin Core 提供命令列選項和使用者可編輯的設定檔（bitcoin.conf），但它也允許使用者在圖形使用者介面（GUI）中變更一些相同的設定。目前這兩組設定儲存在不同的位置，因為 GUI 無法變更設定檔（在某些系統上，它是唯讀的，並且在所有情況下它可能包含使用者評論和格式，自動設定編輯器可能會破壞）。但是，這會產生幾個問題，其中使用者在一個地方變更設定，它意外地在另一個地方套用或不套用。共享設定的最新案例是 PR #13043，它為 GUI 新增了控制先前可從命令列和設定檔使用的修剪的能力。

討論（記錄）： Sjors Provoost 提出了這個主題，並建議了三個解決在不同 Bitcoin Core 程式之間共享設定的儲存位置問題的解決方案：

「忽略這個問題。」繼續使用目前的系統。
「走可寫入設定檔的路線。」（稍後討論會進入更多細節。）
「以不同的方式解釋缺少 prune= 設定。」給設定檔中指定的選項優先於 GUI 中配置的選項。

Provoost 補充說：「如果我們選擇[選項] 2，那麼我想提名 PR[] 進行優先審查。」該 PR 新增了一個新的 bitcoin_rw.conf 檔案，用於軟體修改的設定。與 Qt 設定不同，該檔案可以在 Bitcoin Core 的守護程序和 GUI 之間共享，並且該檔案將被明確標記為不打算支援評論、基於空白的格式和其他人工編輯的便利性。

Jonas Schnelli 抱怨說：「我們想要四(!)層設定嗎？設定[檔] <-> 啟動[命令列介面參數] <-> Qt 設定 <-> 第 4 層 [bitcoin_rw.conf]。」

Provoost 解釋說：「我也想完全擺脫 Qt 設定 […] 我在 PR[] 中編寫了從 QTSettings 遷移的程式碼。」Schnelli 對此選項感到滿意並說：「感謝 [Provoost] 為此工作！」

Gregory Sanders 建議「使用者可以在很大程度上遷移到 [bitcoin_rw.conf]，除非他們需要唯讀。」Wladimir van der Laan 反對這一點：「嗯，bitcoin.conf 是用於人工編輯的；[bitcoin_rw.conf] 是機器可寫入的，所有評論都將被丟棄，等等…」

結論： 沒有明確的結論；會議參與者似乎贊成繼續建立 bitcoin_rw.conf 來儲存軟體修改的設定。關於目前開放的修改設定的 PR 是否應該等待 bitcoin_rw.conf 可用後才合併，或者應該使用現有的次佳 Qt 設定機制，有一些未解決的討論。

ScanTxOutSet RPC 命令

背景： Bitcoin Core 軟體維護著每個未花費交易輸出（UTXO）的鍵值資料庫——即每個可花費的比特幣群組以及為了花費它們需要滿足的條件。該資料庫不是為一次由多個程式存取而設計的，並且不是 API 穩定的，這意味著其他程式無法輕鬆地從中讀取，因此目前沒有便捷的方法讓其他程式從 UTXO 集中檢索資訊。

討論（記錄）： Jonas Schnelli 提出了這個主題並介紹說：「Pieter Wuille 對在 PR #12196 中提議的 scantxoutset 命令提出了擔憂。在繼續 PR[] 之前，我們可能想討論它是否有意義[…]。掃描功能允許無需掃描區塊的 UTXO 掃掠（rawsweeptransaction）。你可以傳入 n 個公鑰/位址，甚至 [HD 錢包擴充公鑰]和查找視窗，它會給你回傳所有未花費的[輸出]（甚至還有一個 rawsweeptransaction 到單一位址）。」

Wuille 描述了他的擔憂：「我只是提到我們最好不要承諾具有在未來難以維護的功能。[例如，在可能的未來使用] UHF 模型，在沒有索引的情況下實作 UTXO 集的掃描需要瀏覽區塊鏈。」[注意：討論中標記為「UHF」的在其他地方稱為「UHS」；請參閱連結。]

Johnathan Corgan 建議：「如果我們想鼓勵人們將 bitcoind 視為『真實來源』，而不是建立他們自己的東西，給他們更容易存取『資料庫』會有所幫助。」

Wuille 承認這個問題「不那麼令人擔憂[因為更容易]現在透過 [Jim Posen 的]背景索引工作新增選用索引。之前，新索引總是需要在驗證程式碼中到處進行醜陋的修改。」

結論： 「這正在變成一場哲學討論，」Wuille 在討論接近尾聲時評論道。沒有明確的結論，但似乎如果新增了 scantxoutset RPC 或類似的 RPC，可能會在發行說明中新增警告，指出它可能需要在未來啟用選用索引。

幽默時刻

[...Things start to break...]
     <mquin> [Global Notice] [...] There are ongoing issues with
             services that are being looked into - please bear
             with us
      <sipa> fun.
<instagibbs> err what
    <wumpus> services massacre
   <cfields> irc unicorns...
             let's move to slack!
             (/s)
    <wumpus> :-(

參與者

IRC 暱稱	姓名/化名
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
provoostenator	Sjors Provoost
jcorgan	Johnathan Corgan
jimpo	Jim Posen
achow101	Andrew Chow
MarcoFalke	Marco Falke
instagibbs	Gregory Sanders
cfields	Cory Fields
jamesob	James O’Beirne
jtimon	Jorge Timón
echeveria	Echeveria
jnewbery	John Newbery
promag	Joao Barbosa
kanzure	Bryan Bishop
Murch	Mark Erhardt

免責聲明

IRC meeting summary for 2018-05-17

Thu, 17 May 2018 00:00:00 +0000

概覽

高優先級審查
0.16.1
放棄 GitHub
將錢包從節點分離
未驗證區塊訊息
其他主題
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：會議參與者最希望看到審查的拉取請求、在產生版本 0.16.1 的第一個候選版本之前需要解決的問題、專案是否應該離開 GitHub、一個為將節點程式碼與錢包程式碼分離鋪平道路的 PR 的審查請求，以及一個潛在的新 P2P 協定訊息以更好地處理未驗證區塊的轉發。

高優先級審查

討論（記錄）： 具體討論的 PR 包括：

#12254： BIP 158：輕量客戶端的緊湊區塊過濾器
#12196： 新增 scantxoutset RPC 方法
#13142： 將 IsMine 與可解決性分離
#12979： 為輔助索引建立可重複使用的基類

此外，Wladimir van der Laan 表示擔心列表變得相當長。

0.16.1

背景： Bitcoin Core 開發者已開始準備一個新的 0.16.1 維護版本，其中包含錯誤修復和重要功能的向後移植。

討論（記錄）： Wladimir van der Laan 提出了這個主題，並簡要概述了仍需完成的工作：

[0.16] 進一步向後移植（#13253）。 需要更多審查。
0.16.0 bitcoin-qt：啟動期間「斷言 `copyFrom 失敗」（#13110）。 Van der Laan 說他「為[此]提出了修復方案，顯然有效。」
重新掃描期間的斷言失敗（#12646）。 Jonas Schnelli 建議推遲，Van der Laan 同意。它被重新定向到 0.16.2。
0.16 關閉斷言（#12337）。 Schnelli 正在調查此問題。

結論： 「我們只需要完成向後移植並為 0.16.1RC1 標記，」Matt Corallo 說。

放棄 GitHub

背景： 超過 6 週以來，經過高度審查的 Bitcoin Core PR 在 GitHub 上的網頁經常無法載入，審查者看到的是一隻憤怒的獨角獸插圖。不同的人已經多次向 GitHub 支援報告了這個問題，但尚未解決。

討論（記錄）： Matt Corallo 提出了這個主題並介紹說：「它一直沒有正常工作 […]，我有點想要自行託管並擁有更好的審查工具，我知道很多人都想要。」

Pieter Wuille 和 Wladimir van der Laan 建議 GitLab 是一個替代方案，Corallo 接受但指出：「儘管 GitLab 似乎沒有比 GitHub 更好的審查工具。」

Suhas Daftuar 擔心「在我看來，自己託管更難做到正確。」Van der Laan 也有同樣的擔憂，「誰來照顧這個、監控它並應用安全修補程式等…？」

Cory Fields 補充說：「一般反對：撇開自行託管的問題不談，GitHub 的網路效應太強[我認為]。我不可能是唯一一個當我想要玩的程式碼在 BitBucket 上時會感到不理性沮喪的人。」Van der Laan 同意：「是的，只有[大型]玩家如 FreeDesktop 才能真正負擔得起在獨立基礎設施上託管；對於較小的專案，缺乏網路效應（並且必須單獨註冊）是不好的。」John Newbery 也同意。

談到他希望在 GitHub 替代品中看到的功能，Corallo 希望有一種命令列方式來「驗證，例如，對評論的 PGP 簽章。」這樣，如果有人入侵儲存庫網路服務以在 PR 上偽造 ACK，可以在合併之前檢測到。

Jim Posen 和 Steve Lee 提供幫助從 GitHub 獲取有關該問題的更多資訊。Bitcoin Core 專案不是唯一遭受此問題的專案，Corallo 說「一些其他專案正在發布他們收到的回應，其中 [GitHub 支援說]『我們實際上不知道我們做了什麼變更觸發了這些問題，稍等。』但那是三週前的事了。」

結論： Corallo 決定目前對這個想法的反對太多，所以「我不會花時間調查它。」Van der Laan 總結說：「我認為在有人建立可行的替代方案並向我們展示它更好之前，實際上沒有任何機會有任何東西取代 GitHub。」

會議後： 會議結束後大約一天，Jonas Schnelli 收到了 GitHub 產品經理 Ben Balter 的訊息，說 GitHub「已經確定了根本原因，並正在進行修復。」

將錢包從節點分離

背景： Bitcoin Core 的全節點實作、錢包和圖形使用者介面（GUI）目前都作為單一程序執行（儘管錢包和 GUI 可以停用）。這意味著，例如，如果你關閉 GUI，你也會停止節點。將這些不同部分拆分為獨立程序以便它們可以彼此獨立運作一直是幾位貢獻者的長期目標。

討論（記錄）： John Newbery 提出了這個主題並介紹說：「#10973 是一個大的 PR，但我認為它非常值得，[…] 但它需要持續的重新基底。[…] 我認為在這個問題上取得一些進展會很棒。」

Wladimir van der Laan 擔心高優先級審查佇列太大：「哦，不，不要更多高優先級審查。它阻礙了什麼嗎？對 0.17 重要嗎？無論如何，程序分離不是我們 0.17 會有的東西。」

此 PR 的作者 Russell Yanofsky 提議將前六個提交拆分到單獨的 PR 中，以便可以獨立於後面的提交進行審查，從而縮小 PR 的大小，並希望使其更容易審查。

結論： 隨著 Yanofsky 提議拆分 PR 以及幾位貢獻者提供在下週審查它，Newbery 結束了主題。

未驗證區塊訊息

背景： BIP152 緊湑區塊轉發引入了高頻寬模式，節點可以在完成驗證該區塊之前向其對等點發送關於新區塊的資訊。如果節點確實完成了驗證區塊並發現區塊無效，但對等點無論如何都請求整個區塊，目前沒有辦法讓節點告訴其對等點它沒有有效的區塊可以發送給它們。目前，在這種情況下，對等點最終會因為未能發送請求的區塊而與節點斷開連線。

討論（記錄）： Matt Corallo 提出了這個主題，並透過描述問題的兩個潛在解決方案來介紹它：

節點告訴請求的對等點它拒絕轉發區塊。
節點向對等點提供請求的區塊，證明它具有有效的區塊標頭（如 BIP152 所要求），但也將其標記為可能無效。

Pieter Wuille 建議現有的 notfound 訊息可能可以重複使用，作為實作第一個提議解決方案的一部分。

Suhas Daftuar 反對重複使用 notfound 訊息，贊成第二個提議的解決方案：「我認為 notfound 更糟，因為在區塊可能尚未驗證的情況下。」Wladimir van der Laan 同意應該使用新訊息「如果沒有特定原因重複使用 notfound，新訊息要好得多。」

結論： Corallo 仍在考慮選項，但認為「問我很好。顯然[實際解決方案]需要一個 BIP 和其他東西。」

其他主題

會議僅剩幾分鐘時，Matt Corallo 提出了一個標題為「佇列排空鎖定斷言以避免死鎖」的主題，但沒有足夠的時間討論該主題，Corallo 說：「我現在意識到我應該只開一個 PR，人們會看到它，[因為]描述起來有點複雜。」

幽默時刻

<BlueMatt> trashing github
<BlueMatt> or we could switch to gitlab
    <sipa> let's move back to sourceforge

<sdaftuar> i think we could just add a new BLOKC response type
           BLOCK_COULDBEBAD
    <sipa> 0xDEADB10C
  <wumpus> hehe

參與者

IRC 暱稱	姓名/化名
BlueMatt	Matt Corallo
wumpus	Wladimir van der Laan
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
jnewbery	John Newbery
jtimon	Jorge Timón
jimpo	Jim Posen
sdaftuar	Suhas Daftuar
cfields	Cory Fields
MarcoFalke	Marco Falke
jamesob	James O’Beirne
promag	Joao Barbosa
moneyball	Steve Lee
ryanofsky	Russell Yanofsky
kanzure	Bryan Bishop

免責聲明

IRC meeting summary for 2018-05-10

Thu, 10 May 2018 00:00:00 +0000

概覽

高優先級審查
在 CTransaction 中快取見證雜湊
一個大的 malloc
審查協調
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：會議參與者最希望看到審查的拉取請求、如果頁面繼續無法可靠載入是否可能離開 GitHub、如何修復效能退化、在記憶體中儲存交易腳本資料的未來設計，以及是否建立額外的審查佇列。

高優先級審查

討論（記錄）： 具體討論的 PR 包括：

[wallet] loadwallet RPC - 在執行時載入錢包（#10740）。 這是一組 PR 之一，如果被接受，將允許 Bitcoin Core 在 Bitcoin Core 0.15.0 中新增的多錢包模式的背景下，在執行時建立、載入和卸載錢包。在會議中，Joao Barbosa 建議此 PR「已經可以了」，Wladimir van der Laan 說它「應該非常接近可合併。」
BIP 158：輕量客戶端的緊湊區塊過濾器（#12254）。 此 PR 允許 Bitcoin Core 為區塊中包含的一些資訊產生緊湊索引。然後可以與輕量客戶端共享這些索引，以允許它們確定區塊是否包含與客戶端錢包相關的資訊，此時客戶端可以請求下載整個區塊（可能來自不同的對等點）。

在討論具體 PR 時，第 n 次提到了 GitHub 頁面無法載入（顯示獨角獸主題錯誤）的問題。Matt Corallo 說：「如果這個獨角獸問題持續存在，我們將不得不離開 GitHub。大多數情況下，如果你重新整理足夠多次或登出，它就會工作，但當重新整理次數約為 10 次時，這兩個都不是解決方案，[並且]我們不能使用一個一半的貢獻者無法載入 PR 的平台。」

Wladimir van der Laan 回答說：「同意。GitHub 這樣基本上是無用的。」其他參與者分享了他們有時解決問題的技巧。

結論： 鼓勵審查者訪問專案的目前高優先級 PR 列表。沒有討論離開 GitHub 的具體計劃；會議參與者似乎希望 GitHub 會修復他們的系統。

在 CTransaction 中快取見證雜湊

背景： 當 Bitcoin Core 需要將交易儲存在記憶體中時，它使用 CTransaction 資料類型。這包含足夠的資訊來為交易建構見證交易識別碼（wtxid 或見證雜湊）。CTransaction 資料類型可以擴充為包含見證雜湊的預先計算（快取）副本。

討論（記錄）： Marco Falke 提出了這個主題，引用了 PR #13011，並介紹了主題：「見證雜湊用於所有鬆散交易，因此快取它會加速驗證（例如 [AcceptToMemoryPool] 和緊湊區塊轉發）。此外，對於沒有見證的交易，見證雜湊等於『正常雜湊』[txid]，因此重新掃描/重新索引存在開銷，[但它]目前是最小的（因為沒有很多具有見證的交易）。快取見證雜湊的收益遠遠超過重新掃描/重新索引期間的任何開銷，[我認為]。當然，我們可以在未來的 PR 中重新設計重新掃描。」

Pieter Wuille 提供了相反的觀點：「[缺點]是它使交易[在記憶體中]變大，並將一些驗證特定邏輯硬編碼到交易資料結構中（例如，它也會影響從磁碟提供區塊等）。」

Matt Corallo 贊成該提議，「[優點]是我們糾正了顯著的效能退化。」

Wuille 建議分離用於交易的資料類型，以便在不需要時不需要產生和儲存見證雜湊。Wladimir van der Laan 似乎同意，說「讓我們不要為了急於前進而把程式碼搞得一團糟。」

還討論了提議的變更是否應該向後移植到 Bitcoin Core 的下一個小版本。Corallo 贊成向後移植，但 Van der Laan、Cory Fields 和 Alex Morcos 反對（儘管可能不是強烈反對）。

結論： 沒有明確的結論。PR #13011 在討論期間被新增到目前高優先級 PR 列表中。

一個大的 malloc

背景： 在 Bitcoin Core 編寫的 C++ 程式語言中，記憶體配置（Memory ALLOCation）的主要函式稱為 malloc()。目前，如 PR #13062 中所述，交易中腳本的記憶體配置方式是最佳化快取 scriptPubKeys，但在其他情況下效能次佳。該 PR 致力於將記憶體中腳本的儲存與它們在程式中的存取方式分開，以便儲存和存取（表示）都可以最佳化。

討論（記錄）： Cory Fields 提出了這個主題並介紹說：「[Pieter Wuille] 和我簡短討論過這個：[…] 每個區塊的腳本資料一個 malloc。[那]讓我想知道是否值得變更 P2P [網路協定訊息]格式以更適合配置（下次我們變更某些東西時，不是單獨為此）。」

Jonas Schnelli 提供了一個範例，Fields 確認了：「像 inv 大小在實際 inv 資料之前。」

隨後的討論不是集中在 Fields 的原始觀點上，而是集中在 PR #13062 用於在記憶體中儲存腳本的方法（稱為 span）的優點和缺點上。反對 span 的是 Matt Corallo，至少「除非有證明的用途」。

贊成 span 的是 Fields 和 Wuille。Fields 說：「[它]對我來說似乎絕對必要，如果我們要解開我們的子系統。」Wuille 同意，說：「完全正確：它將表示與處理抽象化。」

Corallo 反駁說：「為什麼？如果它只是在 CScript 上操作，它應該只在 CScript 上操作。」經過更多討論後，Corallo 說他理解潛在的優勢，但仍然希望在進行變更之前看到它在可合併的 PR 中使用，「是的，我明白了，我喜歡這個選項…當我們有使用者時。」

結論： 沒有明確的結論。Wuille 和 Fields 可能需要投入更多努力來證明他們方法的優勢，然後才能接受與其相關的 PR。

審查協調

背景： Bitcoin Core 專案目前有超過 250 個開放的 PR，幾乎所有 PR 都需要審查（或額外審查）才能考慮合併。多年來，貢獻者一直在說，他們希望專案有更多人花更多時間審查 PR。

討論： Jim Posen 提出並介紹了這個主題，「[除了高優先級 PR 列表外]，我認為還有空間建立另一個已被概念 ACK 的事物列表，供人們審查，以便每個人審查不同的東西，並且有一些實際的協調。」

Pieter Wuille 建議相對較新的網站 BitcoinACKS.com，Posen 同意「很棒」。Wuille 支援 Posen 的想法，「對什麼是概念 ACK（以及類似地，鼓勵人們快速概念 ACK/NACK）有更好的概述會很好。」

Wladimir van der Laan 反對這個想法，說「現在每個人都可以在[目前高優先級列表]上有一個阻礙他們的 PR，這應該促進合作。」Matt Corallo 同意，「百萬小 PR 審查方法不會讓我們作為專案取得任何進展，[但]審查高優先級列表上的事物確實會（至少對我來說）。」

結論： 沒有明確的結論。Corallo 個人總結說：「我認為我們這週不會比過去 10 次討論這個問題時取得更多進展。」

幽默時刻

<morcos> i'm back
<wumpus> welcome back!
  <sipa> hi back, i'm pieter
<morcos> oh man...

 <cfields> well another option is std::allocator magic,
           without having to switch to Span
  <wumpus> noooo
  <wumpus> no magic
 <cfields> wumpus: i can't argue with that, it looks like voodoo
    <sipa> damn cool voodoo.
    <sipa> but voodoo.
  <wumpus> c++ is already too much voodoo
    <sipa> let's switch to BASIC

    <sipa> bitcoinacks.com ? :)
<BlueMatt> apparently it doesnt distinguish between nacks and acks
    <sipa> ha.
  <wumpus> lol that's an interesting bug
    <sipa> "nack" "nack" "nack" "merged!"

參與者

IRC 暱稱	姓名/化名
wumpus	Wladimir van der Laan
BlueMatt	Matt Corallo
sipa	Pieter Wuille
jimpo	Jim Posen
cfields	Cory Fields
jonasschnelli	Jonas Schnelli
MarcoFalke	Marco Falke
promag	Joao Barbosa
luke-jr	Luke Dashjr
jamesob	James O’Beirne
morcos	Alex Morcos
achow101	Andrew Chow
jcorgan	Johnathan Corgan
kanzure	Bryan Bishop
provoostenator	Sjors Provoost

免責聲明

IRC meeting summary for 2018-05-03

Thu, 03 May 2018 00:00:00 +0000

概覽

高優先級審查
刪除 0.8、0.9 和 0.10 git 分支
將記錄移到單獨的執行緒
0.16.1
非同步呼叫 ProcessNewBlock
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、是否應將除錯記錄移到單獨的執行緒以便它不會減慢某些使用案例、是否要產生包含一些錯誤修復和標準交易政策變更的 0.16.1 小版本，以及如何允許平行處理從網路上其他對等點接收的訊息。

高優先級審查

討論（記錄）： 會議期間討論的具體 PR 包括：

BIP 158：輕量客戶端的緊湊區塊過濾器（#12254），由 Jim Posen 提名加入列表。此 PR 允許 Bitcoin Core 為區塊中包含的一些資訊產生緊湊索引。然後可以與輕量客戶端共享這些索引，以允許它們確定區塊是否包含與客戶端錢包相關的資訊，此時客戶端可以請求下載整個區塊（可能來自不同的對等點）。
[wallet] loadwallet RPC - 在執行時載入錢包（#10740），由 John Newbery 提名加入列表。這是一組 PR 之一，如果被接受，將允許 Bitcoin Core 在 Bitcoin Core 0.15.0 中新增的多錢包模式的背景下，在執行時建立、載入和卸載錢包。
UI：支援動態載入的錢包（#13097），由 Joao Barbosa 提名加入列表。建立在前面提到的 PR #10740 之上，這在 Bitcoin Core 圖形使用者介面（GUI）中為動態載入錢包提供支援。

本次會議再次至少第四週提到了一些 GitHub 頁面無法載入（「獨角獸」）的問題。

刪除 0.8、0.9 和 0.10 git 分支

背景： Bitcoin Core 的新開發通常在 Git 儲存庫的 master 分支上進行。要建立穩定版本，主分支會被 git 分叉到一個穩定分支，分支名稱為預期發行版本的名稱，例如對於版本 0.8，分支是 0.8。該分支上的程式碼會被測試、成熟和發布——並且小版本發行版本（例如 0.8.1）的後續錯誤修復也會在該分支上進行。

討論（記錄）： Marco Falke 在會議前不久提出了這個主題，並介紹說：「這些分支上最後標記的版本已經終止生命週期超過一年了。標籤可以保留以用於歸檔原因，但不再需要分支。參見 https://bitcoincore.org/en/lifecycle/#schedule。」

所有在會議上對此事發表評論的人都表示同意。Luke Dashjr 建議，如果每個分支上的最終提交沒有附加到發行標籤（表示確切哪些程式碼用於特定發行版本），則應新增標籤以確保需要該特定程式碼的任何人仍然可以獲得它。其他會議參與者表示同意。

結論： 會議結束後不久，這些分支被刪除。

將記錄移到單獨的執行緒

背景： 預設情況下，Bitcoin Core 會將有關其正在執行的操作的某些資訊寫入記錄檔，以防出現問題並且使用者需要找出觸發問題的原因。目前，記錄是作為程式執行中的順序步驟完成的，因此記錄之後的下一步不會執行，直到記錄完成，這被描述為記錄步驟「阻塞」後續步驟。執行緒是一種讓程式告訴作業系統可以平行執行多個步驟的方法，這可以允許程式中的下一步在記錄完成之前開始（描述為「非阻塞」）。

討論（記錄）： James O’Beirne 建議並介紹了這個主題，說：「我認為將記錄移到單獨的執行緒可能是值得的。」他參考了兩個最近與記錄相關的 PR，#13099 和 #12970。

Matt Corallo 對這個想法非常熱情，說「ACKACKACKACKACKACKACKACKACKACK」並指出「對於礦工來說，這是一個令人驚訝的高延遲創造者，至少對於那些使用旋轉磁碟支援或雲端託管機器的人來說。」他還連結到了他的專案 Bitcoin FIBRE（不用於共識執行的 Bitcoin Core 軟體分支）的一個提交，該提交為記錄實作了基本執行緒。

其他幾位開發者支援這個想法，討論集中在實作行為的最佳方式，特別是如何確保如果確實出現問題，盡可能多的資訊仍然寫入記錄檔。

一些參與者還討論了如果將記錄移到單獨的執行緒，Bitcoin Core 會快多少。一般意見似乎是它可以在一些時間關鍵的應用程式中提供幫助，例如礦工宣布新發現的區塊，並且在使用者啟用選用的詳細記錄進行除錯時也會有所幫助。後者是開發者經常做的事情，也被 Bitcoin Core 測試套件的部分自動使用。但是，對於其他使用案例，預計不會提供顯著的改進。

結論： James O’Beirne 透過說「除非有人有任何異議，否則我將在不久的將來開始進行執行緒從環形緩衝區消費的實作」來結束討論。

0.16.1

背景： Bitcoin Core 最新的主要版本 0.16.0 版本是在大約兩個月前發布的。通常在發布後，會修復影響該版本的錯誤，並且某些新功能被認為足夠重要以向後移植到該版本，從而產生新的小版本。

討論（記錄）： Matt Corallo 提出了這個主題並介紹說：「對於那些沒有注意的人，[Jesse Cohen] 在 #13092 中發現了區塊處理中一些特別新穎的競態條件。因為它們是執行緒問題，它們幾乎肯定不會影響除 submitblock 使用者（即礦工）以外的任何人，並且只會在罕見的競態[情況？]下，但是，我認為鑑於這一點以及我們擁有的其他各種修復，可能值得向後移植。」

引用的問題 #13092 是 Suhas Daftuar 對 Cohen 在 PR #13023 中編寫的整合測試發現的問題的分析。在最壞的情況下，礦工可能認為他們使用 submitblock RPC 向網路發送了新發現的區塊，卻發現 Bitcoin Core 由於競態條件而默默忽略了該區塊，這是程式以與程式設計師預期不同的順序執行步驟的情況。Cohen 的測試發現了這個問題，因為它們在很短的時間內建立了幾個測試區塊（沒有工作量證明）。主網路上的區塊之間幾乎總是有更大的間隔，因此希望到目前為止沒有礦工受到此錯誤的影響。

儘管有 PR 來修復該問題，但 Daftuar 認為需要額外的討論以「確定正確的修復方法」。Cohen 建議 #12988 是「類似類型的錯誤」，也可能應該在小版本中修復。

Corallo 還建議 0.16.1 應包括 Johnson Lau 的 PR #11423，使 CodeSeparator 操作碼在傳統（非 segwit）輸入的花費中成為非標準的。非標準意味著節點不會接受具有這些輸入的交易進入記憶池；如果它們出現在區塊中，它們仍然會接受它們。這應該消除對稱為 FindAndDelete() 的函式的使用，該函式有問題的歷史（參見 1、2）。Segwit 的實作不需要 FindAndDelete，但仍然提供 CodeSeparator 操作碼，NBitcoin 開發者 Nicholas Dorier 一直在使用它作為 Tumblebit 實作的一部分——因此尚未正式提議在 segwit 花費中使 CodeSeparator 成為非標準的。

關於 Lau 的 PR 是否已準備好合併，有一些討論。Corallo 相信 Lau「想要向 [Lau 的 PR] 新增一個更多的政策規則。」Corallo 說他會就此聯繫 Lau。

結論： 所有參與者似乎都贊成組合 0.16.1 版本以修復競態條件並包含額外的標準性規則。在會議期間和之後，討論的各種 PR 被新增到專案的 0.16.1 里程碑中。

非同步呼叫 ProcessNewBlock

背景： Bitcoin Core 目前在單一執行緒中處理它從點對點網路上的對等點接收的訊息。如果可以重寫為使用多執行緒，它可以平行處理一些訊息，這可以提供效能改進。但是，由於它經常從多個對等點接收相同的基本訊息，因此這提出了如何避免重複工作的挑戰。

討論（記錄）： Matt Corallo 提出了這個主題並介紹說：「PR #12934 [肯定]還沒有準備好審查，但我們應該討論一下跨對等點的並發性會是什麼樣子。有兩種主要方法，但兩者最終都需要對其大部分工作進行類似的重構。過去我曾研究過平行執行 ProcessMessages()；在[先前連結的 PR 中，Jesse Cohen] 將[交易和區塊]的驗證處理移到佇列中，並在單獨的執行緒中執行。在這兩種情況下，我們最終都會建立邏輯來『暫停』處理對等點，直到它剛剛產生的任何訊息都被處理完畢。」

Gregory Maxwell 和 Corallo 簡短討論了系統的哪些部分會發現並發性特別有益。對於 Maxwell 來說，是初始區塊下載（IBD），其中新區塊的下載被延遲「當同時連線多個區塊時（由於 IBD 中的無序獲取）」。對於 Corallo 來說，是在使用 CompactBlocks（BIP152）接收新區塊期間連線期間轉發 gettxn（獲取交易）請求，「對於區塊轉發延遲[改進]來說，剩下的一個大便宜勝利。」

Corallo 接著指出，並發性將允許在具有多個 CPU 核心的系統上同時將來自多個對等點的新接收資料反序列化為可用的資料結構，Maxwell 同意這可能是一個不錯的收穫。他們還同意，過去一年對程式碼所做的許多改進使得實作這種類型的變更變得更簡單和更容易。

結論： Cohen 寫道：「酷——所以，如果沒有強烈的反對或對該方法的擔憂，我將繼續這樣做，並在它更準備好審查時回來。」

幽默時刻

       <wumpus>  #10740 given me an unicorn though
<jonasschnelli>  has also a unicorn, reload solved
       <wumpus>  yes
       <LukeJr>  unicorns probably have a high street value
     <jnewbery>  not any more. The market's been flooded
       <LukeJr>  shows what I know of unicorn markets
       <wumpus>  LukeJr: yes, I"m trying to farm them and sell them,
                 but I have more now than atoms in the knows universe
                 so you could say the supply is more than the demand...

參與者

IRC 暱稱	姓名/化名
BlueMatt	Matt Corallo
wumpus	Wladimir van der Laan
gmaxwell	Gregory Maxwell
LukeJr	Luke Dashjr
skeees	Jesse Cohen
jamesob	James O’Beirne
jnewbery	John Newbery
sipa	Pieter Wuille
cfields	Cory Fields
MarcoFalke	Marco Falke
jonasschnelli	Jonas Schnelli
sdaftuar	Suhas Daftuar
jimpo	Jim Posen
promag	Joao Barbosa
jtimon	Jorge Timón
achow101	Andrew Chow
jcorgan	Johnathan Corgan
kanzure	Bryan Bishop

免責聲明

IRC meeting summary for 2018-04-26

Thu, 26 Apr 2018 00:00:00 +0000

概覽

高優先級審查
bumpfee 的「totalFee」參數的必要性
刪除安全模式
小主題
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：「高優先級審查」拉取請求是否獲得足夠的審查、專案成員希望審查者在下週重點關注的拉取請求、在升級 bumpfee RPC 時如何處理該 RPC 的特定參數，以及是否刪除 Bitcoin Core 預設停用的「安全模式」。

高優先級審查

討論（記錄）： 在討論特定議題之前，Matt Corallo 提出了一個擔憂，「我們在『高優先級』列表上並沒有真正獲得任何審查，所以[我]不確定每週提出它的用處。」其他貢獻者同意列表上的項目在過去幾週內沒有收到太多審查，但許多評論似乎贊成保留該列表。這個主題沒有明確解決，但似乎該列表將至少再使用一週。

如前兩週會議摘要中所述，本次會議再次簡短提到了一些 GitHub 頁面無法載入（「獨角獸」）的問題。

會議期間討論的具體 PR 包括：

將 validationinterface 拆分為平行的 validation/mempool 介面（#12979），先前已新增到列表中。此 PR 將與驗證進入記憶池的交易相關的邏輯拆分為單獨的驗證和記憶池介面，使獲取有關記憶池的某些資訊變得更容易，並為 Bitcoin Core 費用估算器的潛在改進奠定基礎。

Pieter Wuille 指出他「開始審查 #12979，但難以理解[它]。」此 PR 的作者 Corallo 說「這是一個純重構。它所做的只是移動東西。」Corallo 還提到它在高優先級列表上是因為它「阻礙了大約 10 件其他事情。」
引入 getblockstats RPC 來[提供可用於]繪製圖表的資料（#10757），先前由 Jorge Timón 提名。此 PR 新增了一個新的 RPC，回傳關於指定區塊的各種詳細資訊和統計資料。

Anthony Towns 指出，此 PR 在上週收到了一些審查，但仍有一些小的未解決問題。

bumpfee 的「totalFee」參數的必要性

背景： Bitcoin Core 提供了一個 bumpfee RPC，允許增加（「提升」）在使用者任何未確認交易上支付的交易費用，這些交易發出 BIP125 選擇性取代費用（RBF）交易可替換性的訊號。預設情況下，此 RPC 會自行計算增加的金額，但它也允許使用者使用 totalFee 參數選擇性地指定要支付的新費用。

討論（記錄）： Gregory Sanders 提出了這個主題並詢問：「[totalFee 參數]需要嗎？[…] 我希望在不久的將來升級 RBF/CPFP [子為父付]，但它使[邏輯]複雜化以支援[此參數]。」

Anthony Towns 建議該參數（或替代品）可以改為用作使用者願意支付的費用上限，如果自動確定的增加值超過該上限，RPC 可能會出錯。

Sanders 進一步描述了他想要放棄該參數的動機：「我重做了 [bumpfee] 以使用 CreateTransaction，所以它會選擇更多的幣，這會改變大小。」換句話說，向替換交易新增更多輸入（幣）會使替換比原始交易更大，並需要支付額外的費用來覆蓋增加的大小——但使用者在使用特定 totalFee 參數呼叫 bumpfee 時不會知道這一點。

Luke Dashjr、Suhas Daftuar 和 Pieter Wuille 似乎都同意，在變更交易大小時，totalFee 似乎沒有意義。

結論： 沒有明確的結論。Sanders 透過建議他可以設計升級的 bumpfee 來結束主題，預設使用允許額外輸入的新行為，但在使用 totalFee 時選擇性地支援舊行為，其中不會新增額外的輸入，當目前的輸入不足以支付所需的費用增加時，RPC 將失敗。那將是「向後相容而沒有額外的累贅。」

刪除安全模式

背景： Bitcoin Core 軟體的早期版本（當時稱為「Bitcoin」）引入了「安全模式」，該模式在網路中斷期間停用某些 RPC，以嘗試防止使用者損失金錢。觸發安全模式的標準多年來已經改變，新的 RPC 很少新增到在安全模式下停用的列表中，最終 Bitcoin Core 0.16 預設停用了安全模式。

討論（記錄）： Wladimir van der Laan 提出了這個主題，參考了 Andrew Chow 的 PR #10563，Van der Laan 將其重新基底為 PR #13090，並詢問：「自 0.16 以來安全模式已被停用；我們應該為 0.17 完全刪除它嗎？」

幾位貢獻者表示他們不知道有人在使用它，並且認為它目前並不有用。Pieter Wuille 說：「無論如何，停用 RPC 不是 Bitcoin 生態系統處理緊急情況的方式——許多基礎設施甚至不會注意到。」

Van der Laan 指出，Bitcoin Core 將繼續提供 -alertnotify 啟動參數，可用於在安全模式本來會啟動時執行任意指令碼。Luke Dashjr 建議 -alertnotify 可以與提議的即將推出的 RPC walletunload 一起使用，以在緊急情況下停用錢包；這將類似於（並且可能優於）目前的安全模式設計。

結論： 儘管一些參與者希望 Bitcoin Core 能夠更好地檢測破壞性網路條件，並能自動做一些事情來幫助使用者避免損失金錢，但所有參與者似乎都贊成刪除目前不支援的安全模式系統。會議結束後，#13090 被合併以從開發分支中刪除安全模式。

注意，在討論刪除安全模式期間，將 -alertnotify 與提議的新 RPC walletunload 結合使用的建議被誤解為討論目前正在進行的 walletunload 工作的請求。這就是為什麼「walletunload」在 MeetBot 會議摘要中顯示為主題，儘管它沒有被直接討論。

小主題

一個簡短討論的主題是自 Cory Fields 於一月向郵件列表發送電子郵件以來，Bitcoin Core 二進位檔案簽署憑證的更新。在該電子郵件中，Fields 說 Gregory Maxwell 正在致力於「建立一個新的門檻簽署方案，這將允許我們處理程式碼簽署而沒有任何單點故障。」由於 Maxwell 未出席會議，因此沒有可用的更新。

幽默時刻

<wumpus>  #topic walletunload (Lukejr)
<LukeJr>  wumpus: I wasn't suggesting it as a topic
<wumpus>  LukeJr: oh...
  <sipa>  #unload walletunload
<wumpus>  #untopic

參與者

IRC 暱稱	姓名/化名
wumpus	Wladimir van der Laan
instagibbs	Gregory Sanders
BlueMatt	Matt Corallo
luke-jr	Luke Dashjr
sipa	Pieter Wuille
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
achow101	Andrew Chow
aj	Anthony Towns
promag	Joao Barbosa
fanquake	Michael Ford
jamesob	James O’Beirne
jtimon	Jorge Timón
cfields	Cory Fields
kanzure	Bryan Bishop

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。

IRC meeting summary for 2018-04-19

Thu, 19 Apr 2018 00:00:00 +0000

概覽

高優先級審查
循環相依性
輕量客戶端模式設計
私密身份驗證協定的更新
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：GitHub 頁面載入的週期性問題、專案成員希望審查者在下週重點關注的拉取請求、某些原始碼檔案之間的不良相依性分離、輕量客戶端模式的設計，以及後 BIP150 身份驗證協定的更新（具有改進的隱私性）。

高優先級審查

討論： 在討論特定議題之前，幾位團隊成員提到他們在載入 GitHub 上的某些頁面時遇到慢性問題，特別是如上週會議記錄中所報告的，有大量討論的拉取請求。其中一些拉取請求被列為高優先級審查。GitHub 支援團隊先前已被幾位會議參與者告知此問題，並在會議期間發送了更多通知。

作為潛在的解決方法，有人建議可能應該關閉並重新開啟有大量討論的拉取請求作為新的拉取請求，以便審查可以繼續。也討論了其他解決方法，例如使用具有無痕/私密模式或行動檢視的網頁瀏覽器。

本次會議具體討論的唯一 PR 是：

除非被監視，否則不要將裸多重簽章輸出視為 IsMine（#13002），由 Pieter Wuille 提名。此 PR 刪除了 Bitcoin Core 錢包中對罕見（且相當奇怪）的多重簽章使用的預設支援，簡化了錢包，為未來可能的升級做準備。此功能的使用者仍然可以手動使用這種類型的多重簽章，並將在發行說明中提供遷移說明。

循環相依性

背景： Bitcoin Core 是用 C++ 程式語言編寫的，它允許將如何使用函式的資訊與實際使函式運作的邏輯分開。將定義分離到標頭檔（.h）和邏輯分離到 C++ 檔案（.cpp）可以使將專案劃分為一組較小的獨立模組變得更容易，這些模組可以更容易地審查和推理。

討論： Pieter Wuille 提出了這個主題，「我想知道我們是否應該針對 .cpp 檔案相互引入彼此的 .h 檔案（但不是 .h 檔案相互引入）這種類型的循環相依性制定政策。對於編譯器來說，這不是循環相依性，但它確實意味著這兩個模組不能真正獨立使用，並且通常是分離不良的跡象。[…] 有幾個開放的 PR 引入了它們，所以我想在這裡提出來，看看這是否應該成為 PR 合併的阻礙，還是只是『如果引入了就試著在之後修復它』。我對兩者都可以接受。」

Cory Fields 回答說「確實聽起來像是可能的不良設計，至少應該在 PR 中證明其合理性。」幾位會議參與者表示同意。

結論： 普遍同意在 PR 中發現問題時發表評論，但不要求在合併之前總是解決問題，特別是在理想的 PR 的情況下，解決問題可能會使已經很大的程式碼變更集變得更大且更難審查。

輕量客戶端模式設計

背景： Bitcoin Core 作為全節點運作，這意味著它遵循具有最多工作量證明的有效區塊鏈。有人提議 Bitcoin Core 也提供一種降低能力的模式，在該模式下，它遵循具有最多工作量證明的區塊鏈，而無需檢查鏈上的每個區塊是否有效。全節點模式需要下載每個區塊，但輕量模式只需要下載每個區塊的標頭以及與支付給使用者的交易相關的一些資料，這將大大減少頻寬需求。

討論： Jonas Schnelli 提出了這個主題，並參考了他的 PR #10794，該 PR 提議引入輕量客戶端模式，而不將其整合到錢包中。提議的程式碼允許使用者停用區塊的自動下載，並使用 requestblock RPC 手動請求他們想要的特定區塊。這可以在稍後透過未來的 PR 擴充，以允許錢包請求下載運作所需的特定資訊。

Schnelli 問道：「我想獲得一些關於輕量客戶端模式的回饋，[特別是]『requestblock』設計，[那]是我們應該遵循還是放棄的東西。」經過一番討論後，他澄清說：「我只想知道這個概念是否有意義 […] 擁有一個輕量客戶端模式。」

Pieter Wuille 說：「擁有客戶端模式的想法——對我來說[絕對]有意義——但這在很大程度上取決於如何以及是什麼。」Samuel Dobson 也贊同這個概念。

Luke Dashjr 只支援輕量客戶端模式的概念，作為「在背景建置到全節點」過程中的一個步驟。基本想法是 Bitcoin Core 可以作為輕量客戶端啟動，讓使用者幾乎立即開始接收和花費比特幣，然後悄悄下載和驗證成為全節點所需的歷史區塊。

Wuille 不同意：「擁有一個你自己執行的全節點，然後擁有多個專門連線到它的客戶端節點，這是一個完全有效的使用案例。但輕量[客戶端]在背景升級到全[節點]也是一個非常好的使用案例。」

持續的討論集中在啟用輕量客戶端模式和在 Bitcoin Core 中分離節點和錢包程序之間的差異和相似性，這是另一個正在進行的工作。

Wuille 解釋說：「我不認為目標應該是將錢包與節點分離到不同的程序中，然後在兩者之間發明一個協定，而不是讓錢包作為輕量客戶端執行。使用[點對點網路協定]作為節點和錢包之間的通訊的優勢（這是當你將錢包視為輕量節點時所得到的）是它實際上[是]模組化的：你可以執行任何錢包軟體或任何節點軟體。」（原文強調。）

Wuille 還解釋說，將輕量客戶端模式完全實作到 Bitcoin Core 中可能不像某些人預期的那樣是一項大工作，因為它可以「重複使用所有現有的全節點程式碼和 P2P [網路協定]實作，[並]只是[不]進行驗證。」

關於這個主題的最後評論指出，需要在 P2P 網路協定中實作 BIP150/BIP151/BIP158，以便輕量客戶端節點擁有開發者希望的所有功能。Schnelli 計劃繼續他對 BIP151 的工作，並且（會議中未提及）其他開發者正在為 Bitcoin Core 中的 BIP158 支援奠定基礎。

與其他討論交織在一起，Cory Fields 提到阻礙他能夠審查的一個因素是 Bitcoin Core 目前的下載邏輯。「在我看來，[這個邏輯]應該在堆積更多之前進行一些清理/封裝。」Suhas Daftuar 表示同意，Wuille 也是（他幫助編寫了一些目前的程式碼）。

結論： 幾位參與者同意審查並評論 #10794。可能需要更多討論來說服所有人輕量客戶端模式是一個好主意，但幾位參與者確實對基本想法表示熱情。

私密身份驗證協定的更新

背景： BIP150 提出了一個協定，允許兩個節點相互驗證它們的連線。如 BIP 所述，這有助於檢測中間人攻擊，並允許經過身份驗證的對等點存取受限操作。

討論： Pieter Wuille 提出了這個主題，「如一些人所知，[Gregory Maxwell] 和我一直在思考比 BIP150 具有更好隱私性的身份驗證協定。目標是設計一個協定，其中一個節點有一個或多個私鑰，另一個節點有一個或多個公鑰。第二個節點了解[第一個]節點的私鑰之一是否與[其]公鑰之一匹配，但沒有其他資訊。擁有私鑰的節點甚至不知道身份驗證是否成功，或者不知道它被查詢的是哪些金鑰。」

在簡短回答了一些問題後，他繼續說：「想法是我們的大多數連線無論如何都是未經身份驗證的（並且應該[是，因為它們是與點對點網路上的隨機對等點]）所以，無論你給經過身份驗證的節點什麼特權，如果身份驗證失敗，你就不會給予。這有一個非常酷的特性，即使你不關心對方是誰，你也可以總是執行此身份驗證協定。[…] 如果你總是執行身份驗證協定（但如果你對身份驗證不感興趣，則使用隨機產生的公鑰[保證不匹配]）[中間人攻擊者]無法找出你在做什麼——他們必須假設你正在嘗試身份驗證。」

先前嘗試的描述設計這樣一個協定是可用的。Wuille 指出，該文件中描述的協定已損壞，但該文件包含的設計理由仍然有用。

「無論如何，事實證明這很困難，」Wuille 說。「我們有一個協定可以使用一個[私鑰]和一個[公鑰]——這意味著你有時需要執行[它]很多次，這不會帶來很好的指紋屬性。我正在與一些人交談以擴充它。」

Cory Fields 對協定的目的表示了一些困惑。Wuille 澄清說：「[新協定]的全部意義在於避免為應該是無身份的東西擁有可發現的身份，但有時你有一個已經信任的節點（由於外部原因，例如你自己執行它），在這種情況下，你會為[它]配置一個帶有已知公鑰的 addnode。」Bitcoin Core 的 addnode RPC 目前允許你根據其 IP 位址連線到特定節點。

Mark Erhardt 提供了額外的解釋：「例如，如果你想用輕量客戶端連線到你自己的節點，你查詢的唯一有效金鑰是你家用節點的。如果你想防禦女巫攻擊，你可以查詢已知朋友的列表並接受其中任何一個。如果你只想嚇跑[中間人]，你會查詢隨機金鑰。」

Jonas Schnelli 問道：「我猜這個協定需要比[現有的] BIP150 更多的密碼分析？」Wuille 回答說：「我正在與 Dan Boneh 討論它。」Boneh 是一位著名的密碼學家和史丹佛大學的電腦科學教授，他先前曾幫助研究和開發與比特幣相關的密碼協定。

Wladimir van der Laan 指出：「作為 BIP150 的未來繼任者，這會很好——儘管我認為這項研究不應該阻止任何人在[更]短期[基礎上]實作 BIP150 並擁有可運作的東西。」Wuille 表示同意。

結論： 據推測，Wuille 和 Maxwell 將繼續進行該協定的工作，可能會得到 Boneh 和其他人的幫助。鼓勵在此期間繼續實作 BIP150 的工作。

幽默時刻

<jonasschnelli>  I guess this protocol would require more cryptoanalysis
                 then the exiting BIP150
         <sipa>  jonasschnelli: that's ok, i'm talking to dan boneh about it
<jonasschnelli>  Good!
 <meshcollider>  Dan is the solution to all crypto problems

參與者

IRC 暱稱	姓名/化名
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
wumpus	Wladimir van der Laan
cfields	Cory Fields
luke-jr	Luke Dashjr
instagibbs	Gregory Sanders
jnewbery	John Newbery
meshcollider	Samuel Dobson
jamesob	James O’Beirne
kanzure	Bryan Bishop
achow101	Andrew Chow
sdaftuar	Suhas Daftuar
promag	Joao Barbosa
aj	Anthony Towns
Murch	Mark Erhardt
jtimon	Jorge Timón
ryanofsky	Russell Yanofsky
phantomcircuit	Patrick Strateman

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。

IRC meeting summary for 2018-04-12

Thu, 12 Apr 2018 00:00:00 +0000

概覽

高優先級審查
如何處理裸多重簽章上的 IsMine
動態錢包載入/卸載
Gitian 更新
幽默時刻
參與者
免責聲明

本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、是否要取消錢包中一個奇怪且很少使用的功能（IsMine 裸多重簽章）的相容性、如何安全地改進多錢包支援，以及在升級 Bitcoin Core 可重現二進位發行版的建置環境時，如何處理一些不再支援的軟體。

高優先級審查

討論： 本週建議關注的 PR 如下：

在驗證的同時平行建置交易索引（#11857），由 Jim Posen 和 Wladimir van der Laan 提名。此 PR 將選用的交易索引（允許使用者透過 txid 查詢歷史交易）移到單獨的資料庫中。這將允許使用者在節點執行時啟用或停用交易索引，而不必等待數小時（即使在快速硬體上也是如此）。此 PR 也為 Bitcoin Core 新增額外的獨立索引奠定了基礎，這些索引可以啟用諸如 BIP 157 和 158 中描述的輕量客戶端改進隱私區塊過濾等功能。

在會議之前，此 PR 已經收到一些正面的審查，但要求了一些變更，現在已經完成，因此會議中的討論集中在讓這些變更本身得到審查。
非 HD 錢包升級到 HD 的路徑（#12560），由 Van der Laan 提名。此 PR 新增了一個新的 sethdseed（設定 HD 種子）RPC，允許使用者為 BIP32 階層式確定性（HD）錢包設定種子值。這可用於請求 Bitcoin Core 自行產生新種子，或將種子變更為從目前執行的 Bitcoin Core 外部獲得的值（例如從備份中）。此外，此 PR 允許舊版非 HD Bitcoin Core 錢包的使用者使用 -upgradewallet 命令列參數升級到 HD 錢包。

會議中的討論指出，此 PR 可能有一個尚未解決的問題，但主要需要來自其他貢獻者的審查。
將費用估算器移到 validationinterface/cscheduler 執行緒（#11775），由 Van der Laan 提名。此 PR 對 Bitcoin Core 程式碼中的一些內部介面進行後端變更，然後變更 Bitcoin Core 的費用估算器以使用其中一個介面，使其能夠存取對費用估算有用的其他資訊。此 PR 還對費用估算器在處理邊緣情況的方式上進行了一些小改進。

在會議之前，此 PR 的作者（Matt Corallo）提議將此 PR 拆分為針對不同部分變更的獨立較小 PR。會議期間的討論指出，審查者正在等待這件事發生後才進一步審查。
引入 getblockstats RPC 來[提供可用於]繪製圖表的資料（#10757），由 Jorge Timón 提名。此 PR 新增了一個新的 RPC，回傳關於指定區塊的各種詳細資訊和統計資料。

會議中的討論看到一位貢獻者同意審查此 PR。

討論期間提到的一個問題是 GitHub 最近頁面載入失敗的問題，持續時間相當長。這個問題已經變得足夠頻繁，以至於會議參與者透過引用 GitHub 在錯誤頁面上顯示的圖畫——一隻獨角獸——來提及這個問題。

如何處理裸多重簽章上的 IsMine

背景： 裸多重簽章是指支付給多個公鑰而不使用更常用的 P2SH 或 segwit 位址。Bitcoin Core 的錢包目前會掃描任何裸多重簽章付款，以查看是否使用的每個公鑰都是使用者錢包的一部分，如果是，則將付款分類為 IsMine，表示使用者可以花費它。

討論： Pieter Wuille 提出了這個主題。他將目前的行為描述為「愚蠢、惱人、毫無意義且難以維護」。對於愚蠢和毫無意義，問題可能是當所有公鑰都屬於同一個錢包時，多重簽章並不比單一簽章提供任何額外的安全性，但使用多重簽章確實比單一簽章花費更多。對於惱人和難以維護，問題是這種行為需要額外的程式碼，並且使開發者更難以朝著 Wuille 先前描述的改進錢包設計邁進。

Wuille 接著描述了他的擔憂：「可能已經有現有的輸出給它。我不知道是否是這樣，但僅僅停止支援它聽起來很可怕。」經過一番討論，Wuille 澄清他並不是提議刪除允許這些付款的擁有者花費它們的程式碼；相反，Bitcoin Core 將不再自動看到這些付款。

Corallo 和 Wuille 之間的進一步討論提供了對問題的生動描述：要在所需的新錢包模型中支援這種舊行為，需要產生 N³ 個組合，其中 N 是使用者擁有的私鑰數量。預設情況下，Bitcoin Core 產生 2,000 個私鑰，因此錢包需要產生難以管理的 80 億個組合。

持續的討論圍繞著 Wuille 的 PR #12874，該 PR 停用目前的行為並為需要它的使用者提供一個解決方法。Corallo 提到現有的 RPC importaddress 已經為解決方法提供了必要的重要功能。

結論： 儘管會議參與者贊成在有合理方法的情況下保留現有功能，但討論似乎傾向於刪除裸多重簽章上的 IsMine，並在發行說明中提及解決方法。

動態錢包載入/卸載

背景： 舊版本的 Bitcoin Core 只能在特定節點上使用單一內建錢包實例。這在版本 0.15.0 中擴充為允許多個錢包實例，但 Bitcoin Core 的舊部分（例如啟動時讀取的命令列選項）假設使用者只有一個錢包實例，因此它們會同時對所有載入的錢包進行操作。John Newbery 的拉取請求 #10740 透過允許使用者在執行時使用新提議的 RPC 載入、卸載甚至可能建立錢包來為此提供解決方法。

討論： Joao Barbosa 提出了這個主題，建議「…錢包管理應該使用共享指標」。這將有助於確保如果使用者在執行時請求卸載錢包，則可以在卸載錢包之前處理涉及該錢包的待處理請求。另一種情況可能是錢包在操作過程中意外消失，這可能會導致意外和有害的影響。Barbosa 已開啟 PR #11402 來進行此提議的變更。

此提議似乎沒有爭議，討論轉向其他改進以及應該實作這些改進的順序。Jonas Schnelli 建議 Bitcoin Core 首先需要一個 createwallet RPC，以便可以在執行時建立錢包，並且可以停用命令列錢包選項（或可能僅限於單錢包使用）。Pieter Wuille 指出，如果沒有執行時載入錢包的方法，執行時的 createwallet 會很奇怪，因為你必須重新啟動 Bitcoin Core 才能使用剛建立的錢包。

Luke Dashjr 建議順序為「載入 -> 建立 -> 卸載」，因為「卸載是複雜的部分」，可能是因為同時處理多個程序在載入的錢包上工作的潛在問題。Newbery 同意並對 Schnelli 的建議「將卸載從現有 PR 中拆分出來」做出了正面回應。

Wladimir van der Laan 建議「卸載可能應該分兩個階段：請求後，RPC 和 GUI 失去對它的存取權。然後它等待目前的操作完成。然後真正[卸載]該東西。」

結論： Newbery 同意他將修改他的 PR，在 PR 本身上說他將「將此 PR 的範圍縮小到只有一個 loadwallet RPC。接下來應該是 createwallet RPC，然後是 unloadwallet。（unloadwallet 是大部分困難所在）。」

Gitian 更新

背景： Bitcoin Core 使用一個稱為 Gitian 的系統，以一種任何擁有電腦和網際網路連線的人都可以完全重現的方式建置其發行二進位檔案，允許任何人驗證發行二進位檔案是經過同行審查的原始碼的產物。隨著 Bitcoin Core 的變更、建置目標作業系統的變更以及其他軟體可用性的變更，Gitian 建置環境需要更新以處理這些變更。

討論： Luke Dashjr 提出了這個主題，似乎與專案希望將 Gitian 使用的作業系統切換到即將推出的 Ubuntu 18.04 LTS 有關。Dashjr 的擔憂是「我們需要 vmbuilder 的替代品或其他東西，因為 Canonical 尚未更新它以支援任何最新版本。」Vmbuilder 是一個工具，允許在常規作業系統下建立和執行子作業系統，以便在其中建置軟體。vmbuilder 的一個理想功能是它可以在虛擬機器中建立子作業系統，將其與主要作業系統完全隔離，有助於防止你正在建置的程式碼中的任何問題影響實際的作業系統。

Wladimir van der Laan 建議使用 debbootstrap（Debian bootstrap），這是一個早於 vmbuilder 的工具，它使用 chroot 而不是虛擬機器，允許它欺騙正常軟體認為它正在單獨的作業系統中建置，但它並沒有做任何重要的事情來防止惡意軟體攻擊主要作業系統。儘管其他開發者（如 Cory Fields）贊成遷移到 debootstrap，Dashjr 仍然擔心並說：「我想修復 vmbuilder 可能不是太不合理的努力，也許我會嘗試一下。」

Andrew Chow 補充說，他「正在考慮為 Gitian 新增 Docker 支援，這樣我們將使用預設的 Ubuntu docker 映像，然後從那裡建置。」Docker 可能比 chroot 更安全，但通常不如虛擬機器安全。Dashjr 指出，Docker 也僅限於大多數桌上型電腦和伺服器使用的 x86_64 平台，而一些專案貢獻者認為在其他平台上建立一些可重現的建置是有利的，這些平台可能沒有 x86_64 上發現的問題，例如與 Intel Management Engine 相關的問題。

結論： 切換到 debootstrap，同時 Dashjr 可能致力於讓 vmbuilder 再次運作。長期而言，Fields 正在努力全面改革系統。

幽默時刻

<wumpus>      #topic dynamic wallet load/unload (promag)
<instagibbs_> what's the controversy in this topic :)
<sipa>        it should happen, duh
<sipa>        how and when is another :)

參與者

IRC 暱稱	姓名/化名
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
luke-jr	Luke Dashjr
BlueMatt	Matt Corallo
promag	Joao Barbosa
jnewbery	John Newbery
jtimon	Jorge Timón
jimpo	Jim Posen
achow101	Andrew Chow
randolf	Randolf Richardson
instagibbs	Gregory Sanders
cfields	Cory Fields
sdaftuar	Suhas Daftuar
meshcollider	Samuel Dobson
jcorgan	Johnathan Corgan
kanzure	Bryan Bishop

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。

IRC meeting summary for 2017-11-09

Thu, 09 Nov 2017 00:00:00 +0000

概覽

主要議題
Bitcoin Core 0.15.1
- 背景
- 會議意見
幽默時刻
參與者
免責聲明

主要議題

Bitcoin Core 0.15.1

Bitcoin Core 0.15.1

背景

Bitcoin 版本 0.15.1 已經完成 RC 週期，將會發布。

會議意見

Segwit 錢包將包含在 0.16 版本中。
- Segwit 錢包 PR 可以在這裡找到 #11403
高優先級審查中的新 Pull request。
- Pull request #10286
MarcoFalke 提出 Apple 簽名金鑰將在明年初到期，Windows 簽名金鑰將在 2019 年到期。這些簽名金鑰用於驗證在網際網路上發布的應用程式，如 Core。目前這些金鑰與 Bitcoin Foundation 相關聯。這使得看起來像是 Foundation 在創建軟體，而實際上他們與軟體的創建沒有任何關係。計劃是創建一個控股公司，其唯一功能是作為用於獲得 apple 和 microsoft 簽署憑證的名稱。將會有一個 MPC RSA 方案，允許 Core 在簽署軟體時使用多重簽名。這個公鑰將允許人們驗證軟體來自 Bitcoin Core。

幽默時刻

<luke-jr> "We Just Codesign Stuff We Want, LLC" XD
<cfields> luke-jr: that's my end goal, actually
<jonasschnelli> Indeed
<jonasschnelli> It's one entity luke-jr
<wumpus> well adversarial versus consensus-compatible is easy to draw
<gmaxwell> there is another issue, I'm pretty sure that apple will not grant a key to "I sign random shit LLC"
<jonasschnelli> You can found a "Knots Code Signing Assoc"

參與者

IRC nick	Name/Nym
cfields	Cory Fields
luke-jr	Luke Dashjr
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
achow101	Andrew Chow
jnewbery	John Newbery
meshcollider	Samuel Dobson
karelb	Karel Bilek
MarcoFalke	Marco Falke
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
promag	Joao Barbosa
kanzure	Bryan Bishop
instagibbs	Gregory Sanders

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-11-02

Thu, 02 Nov 2017 00:00:00 +0000

概覽

主要議題
Bitcoin Core 0.15.1
- 背景
- 會議意見
幽默時刻
參與者
免責聲明

主要議題

Bitcoin Core 0.15.1

Bitcoin Core 0.15.1

背景

開始發布最新版本的 Bitcoin Core，以及需要加入到向後移植的 PR。

會議意見

此版本的版本號從 0.15.0.2 更改為 0.15.1。
討論要加入到向後移植的 PR。向後移植討論可以在 #11592 中找到。
討論最終從程式碼庫中移除 OpenSSL。由於 BIP 70 無法移除，因為它用於驗證 https 的憑證。
此會議合併的 PR
- 向後移植 PR #11592
- 合併 PR #11593
- 合併 PR #11560
- 合併 PR #11100
審查向後移植並開始 RC 程序

幽默時刻

<jtimon> chaincode conspiracies coming...
<instagibbs> Eastern US powerhouse too :)
<MarcoFalke> instagibbs: It's not retroactive ;)
<morcos> instagibbs: which ones, the ones we do ourselves or the ones under our blockstream contract?
<jonasschnelli> ChainCodeLabs marketing departure must confront now with new ChainCode Core conspiracy
<instagibbs> morcos, one and the same, right?
<jtimon> BlueMatt: lol
<achow101> chaincore
<jonasschnelli> heh
<cfields> BlockChain
wait...
<sdaftuar> lol
<gmaxwell> lol
<morcos> took you long enough
<jonasschnelli> lol
<sipa> ChainStream

參與者

IRC nick	Name/Nym
cfields	Cory Fields
luke-jr	Luke Dashjr
Sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
achow101	Andrew Chow
meshcollider	Samuel Dobson
jonasschnelli	Jonas Schnelli
jtimon	Jorge Timón
MarcoFalke	Marco Falke
instagibbs	Gregory Sanders

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

Authored by: Ivan Quiles

IRC meeting summary for 2017-10-26

Thu, 26 Oct 2017 00:00:00 +0000

概覽

主要議題
Bitcoin Core 0.15.0.2
- 背景
- 會議意見
幽默時刻
參與者
免責聲明

主要議題

Bitcoin Core 0.15.0.2

Bitcoin Core 0.15.0.2

背景

隨著即將到來的 Segwit 2x 分叉，Bitcoin Core 0.15.0.2 將在分叉前發布，更好地處理無效區塊和轉發它們的對等節點。

會議意見

討論需要合併的 Pull Request。審查者應該最好在接下來的兩天內審查這些 Pull request。
- 移除 PR #10593
- 合併 PR #11490
- 審查 PR #11560
- 用 #11568 替換 PR #11446 並審查它
- 審查 PR #11531
Morcos 提出在同一 IP 地址上同時執行 Bitcoin Core 和 Segwit 2x 節點的可能問題。gmaxwell 指出這已經是網路的一個屬性。
gmaxwell 建議也應該為那些在分叉後從 Segwit 2x 切換到 Bitcoin Core 的人實作鏈狀態資料庫的警告機制。

幽默時刻

<achow101> In other news, I got someone to write meeting notes for the website. we'll try to get through all of the meetings missed too
<wumpus> achow101: that's great news!
<meshcollider> \o/
<gmaxwell> bad news is that the someone is roger ver.
<gmaxwell> :P
<achow101> lol. no
<wumpus> hahahaha
<luke-jr> XD
<luke-jr> achow101: you've checked?
<meshcollider> Comic relief would be the whole meeting notes
<achow101> luke-jr: unless I am blind, I am pretty sure the person writing the notes next to me is roger ver
<achow101> *is not
<gmaxwell> uh oh.
<luke-jr> achow101: maybe on his payroll :P
* gmaxwell imagines the delayed correction coming after a sharp poke to the ribs

註：這些註記的作者對上述交流感到受侮辱。

參與者

IRC nick	Name/Nym
cfields	Cory Fields
luke-jr	Luke Dashjr
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
achow101	Andrew Chow
jnewbery	John Newbery
meshcollider	Samuel Dobson
karelb	Karel Bilek

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-06-08

Thu, 08 Jun 2017 00:00:00 +0000

概覽

主要議題
優化：減少計算區塊雜湊的次數
- 背景
- 意見
- 結論
UI 與 pertxout 升級的互動
- 背景
- 意見
- 結論
crc32 leveldb 1.20
- 背景
- 意見
- 結論
高優先級審查
幽默時刻
參與者
免責聲明

主要議題

優化：減少計算區塊雜湊的次數
UI 與 pertxout 升級的互動
crc32 leveldb 1.20

優化：減少計算區塊雜湊的次數

背景

目前在頂端接受區塊會對標頭進行約 6 次雜湊。Jtimon 製作了 PR #10339 來改善這種情況。Wumpus 進行了一些基準測試，結果減少了 26% 的雜湊操作。

意見

Gmaxwell 建議在區塊物件中快取雜湊，但 Sipa 更喜歡這個解決方案。他認為向驗證特定函數加入更多參數比改變原始資料結構侵入性更小。Wumpus 認為傳遞額外的參數比擴展原始資料結構更容易理解，但快取總是有些風險和容易出錯。Wumpus 認為如果在效能方面不值得，我們不應該做任何一個。

Morcos 想知道速度提升是否值得使程式碼變得更複雜/涉及的權衡。Gmaxwell 提出這個問題是因為重複雜湊在區塊傳播的延遲關鍵路徑上，可能達到一毫秒。Codeshark 更願意為更好的架構犧牲一點效能。

Jtimon 認為不同意這個概念的人應該早點說清楚。

結論

在會議後和 PR #10339 上進一步討論。

UI 與 pertxout 升級的互動

背景

PR #10195 將鏈狀態資料庫及其快取從每交易模型切換到每 txoutput 模型，需要在資料庫中進行升級程序，在正常硬體上可能需要幾分鐘或在其他地方更長時間。Sipa 認為這需要一些 GUI 互動，以向使用者明確發生了什麼。

意見

Jonasschnelli 建議使用 uiInterface.Progress，但這不允許你中斷程序。使用者可能希望將升級程序延遲到另一個時間。

Luke-jr 想知道如果你崩潰，執行舊版本，然後再執行新版本會發生什麼。Gmaxwell 認為舊版本會告訴你資料庫損壞並停止，但他沒有測試過。他確實認為這是應該處理的情況。

回到舊版本需要重新索引，這是修剪節點無法做到的。發行說明中應該有明確的警告。

Sipa 注意到可以進行一個微不足道的變更來保證舊版本會將其視為空資料庫。一種方法是創建一個新資料庫，但在升級期間需要兩倍的磁碟儲存。微不足道的方法是將最佳區塊雜湊的記錄設定為無效的東西。

結論

Jonasschnelli 將進行記錄程序的工作，類似於 VerifyDB。
監控升級期間的磁碟使用情況並進行更多測試。根據這些結果繼續討論。

crc32 leveldb 1.20

背景

最新版本的 levelDB 為 intel 實作了硬體加速的 crc32，用於計算校驗和。

意見

Sipa 非常不喜歡 levelDB 開發者使用的方法，它需要使用不同旗標編譯的單獨物件，並且他們在不知道 CPU 是否支援它的情況下呼叫新物件。Wumpus 和 Gmaxwell 注意到使用特殊旗標編譯單獨物件是標準且正確的，但在不知道 CPU 是否支援它的情況下呼叫它則不是。

Jtimon 建議在 levelDB github 上開啟一個議題。Gmaxwell 認為最好直接提交修復，因為開啟議題不會有太大幫助。

稍後加入會議的 Cfields 已經準備好修復。

結論

修復 levelDB

高優先級審查

Sipa 想加入 #10148（使用非原子刷新進行區塊重放），它將使有效可用的 dbcache 加倍。
Luke-jr 已經 rebase 了多錢包。
Gmaxwell 提醒大家 BlueMatt 的快取變更在 #10192 上是 31% 的區塊連接速度提升，它需要審查。

幽默時刻

9:45   cfields_         here!
9:47   BlueMatt         oh, i was supposed to mention cfields_ would be late
9:47   cfields_         heh, thanks
9:47   BlueMatt         you're welcome :)

9:48   gmaxwell         we should submit a fix, it should be trivial.
9:48   cfields_         that's done already: https://github.com/theuni/bitcoin/commit/2cb7dda13884e44105f33c16e7e2c1a9aed46295
9:48   sipa             cfields_: oh!
9:48   cfields_         or are you guys talking about something else?
9:48   sipa             probably not
9:49   wumpus           lol <long discussion> oh, cfields did it already

參與者

IRC nick	Name/Nym
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
jtimon	Jorge Timón
BlueMatt	Matt Corallo
instagibbs	Gregory Sanders
achow101	Andrew Chow
CodeShark	Eric Lombrozo

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-06-01

Thu, 01 Jun 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
0.15 的高優先級功能
- 背景
- 會議意見
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

Luke-jr 提出了一個擔憂，即區塊因無效的 prev-blocks 和發送「不」連線的標頭（因為我們拒絕了較早的無效標頭）而導致 DoS 懲罰，這可能是軟分叉的問題。之前在 DoS 保護方面提出了一個不同的議題，可能有類似的解決方案。因此 Sdaftuar 建議在 #9530 中繼續討論。
0.14.2 的所有內容都已向後移植並合併，因此可以標記 0.14.2 進行發布，並可以創建 RC1。

主要議題

0.15 的高優先級功能

0.15 的高優先級功能

背景

Bitcoin Core 0.15 計劃在 2017-09-01 左右發布。Sdaftuar 想談論哪些功能應該在 0.15 版本中獲得高優先級。

會議意見

Jtimon 希望將他的 PR #8994（testchains）納入。
Sdaftuar 希望看到 BlueMatt 的 #10192（腳本快取）進入，因為這是一個巨大的驗證勝利。Luke-jr 注意到對於他建議的未來軟分叉可能會有問題，其中腳本功能需要鏈上下文，如 CHECKBLOCKVERSION 和可能的 CHECKBLOCKATHEIGHT。Sipa 認為通過將上下文相關的腳本驗證旗標與快取中的條目一起儲存可以解決。
Cfields 想知道為 0.15 移除 openSSL 是否仍然是一個目標。Sipa 認為它不應該是優先事項，但最終應該發生。一旦偽隨機數生成器進行了更多改進，它可能會自然而然地發生

高優先級審查

Jonasschnelli 希望將 PR #10240（HD 錢包自動恢復）放入 Bitcoin Core 0.15。
Jtimon 仍然要求審查 PR #10339（減少計算區塊雜湊的次數）。
Sipa 目前正在壓縮 PR #10195（將鏈狀態資料庫和快取切換到每 txout 模型），並希望在那之後請求審查 PR #10321（對所有測試使用 FastRandomContext）。
Ryanofsky 想加入 #10244，但應該在多錢包基礎進入後完成。
Jtimon 注意到 #7729（錢包的標籤 API）需要 rebase。Gmaxwell 擔心稍後擴展 API 以支援每個交易的多個標籤可能會很困難。Jonasschnelli 澄清它可以完美擴展，但我們應該完成它，因為我們已經談論棄用帳戶系統很長時間了。

幽默時刻

jtimon            other super fast topic?
jonasschnelli     Bitcoin Core ICO?
jonasschnelli     *duck*
wumpus            jonasschnelli: lol
jtimon            testnet 4 ico at most
luke-jr           jonasschnelli: IHO instead?
luke-jr           (Initial Hat Offering)
sipa  commits the Bitcoin Core.ico file
gmaxwell          We could sell international reply coupons... it would have a lot more substance than most ICOs. :)

參與者

IRC nick	Name/Nym
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
jtimon	Jorge Timón
BlueMatt	Matt Corallo
instagibbs	Gregory Sanders
ryanofsky	Russell Yanofsky
achow101	Andrew Chow

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-05-25

Thu, 25 May 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
多錢包概念
變數命名風格
BIP 148
幽默時刻
參與者
免責聲明

註記 / 短議題

Bitcoin Core 0.14.2 應該發布，其中包含手動啟用 UPnP 選項的使用者的安全修復，以及其他較小的錯誤修復。

主要議題

多錢包概念
變數命名風格
BIP 148

多錢包概念

背景

Bitcoin Core 0.15 的一個新功能是同時處理多個獨立錢包的能力。Github 上有一個專案頁面用於所有與多錢包支援相關的 PR 和議題。

會議意見

Jonasschnelli 有一些問題需要思考，即我們是否希望錢包創建/載入在軟體執行時進行，還是每次啟動時進行。長期來看我們應該兩者都要，但作為 0.15 的第一步，後者更現實。

另一個問題是 -rescan/-zapwallettxes/-salvagewallet/-upgradewallet 命令應該怎麼處理。Sipa 最初只會在配置了多個錢包時禁用 -rescan。理想情況下，我們將其移動到通過 RPC 的執行時，這樣命令將變成錢包特定的。Gmaxwell 認為 -zapwallettxes 和 -salvagewallet 最終應該消失，或者移動到另一個工具。Sipa 建議移除 -zapwallettxes 以支援 abandontransaction，用獨立工具替換 -salvagewallet，並讓 -upgradewallet 應用於所有錢包。Jonasschnelli 過去開始進行獨立錢包工具的工作，但遇到了循環依賴問題。Cfields 認為我們可以解決這個問題。

我們還應該考慮錢包旗標與新錢包資料庫的結合，Jonasschnelli 已經在這裡實作了錢包旗標。旗標可以用來指示 HD 的使用、鏈分離等。由於 HD 鏈分離在 0.15 中不向後相容，理想情況下我們會放入我們進一步需要的所有東西，以避免在 0.16 中破壞向後相容性。

會議結論

確保在 0.15 中至少獲得基本的多錢包支援

變數命名風格

背景

在 Bitcoin Core 程式碼庫的歷史中使用了各種編碼風格，結果並不是很一致。已經努力使其更加統一，有一些開發者指南，因此編碼風格將慢慢收斂到單一風格。

會議意見

Sipa 注意到幾個人編寫的補丁中的變數名稱看起來像匈牙利表示法，但實際上不是。目前開發者註記中沒有指定任何約定，所以人們複製程式碼周圍的風格。為了讓人們停止模仿這種風格，應該在開發者註記中規定一種風格。Luke-jr 喜歡只在有新程式碼時進行風格變更的想法，避免大量只是重新命名變數的 PR。一個要做的選擇是使用 camelCase 還是 under_score。camelCase 的缺點是很容易與匈牙利表示法混淆。

大多數開發者希望有一些東西來識別全域和局部變數。Sipa 建議對局部變數使用小寫和底線，對成員使用 ‘m_‘，對全域變數使用 ‘g_‘。Wumpus 注意到方法名稱應該堅持 camelCase。

會議結論

Sipa 將撰寫一個 PR 加入到開發者註記中，解釋變數名稱的新風格指南。
應該在註記中明確提到「不要試圖匹配附近的程式碼」。

BIP 148

背景

BIP148 是一個提案，通過在 2017 年 8 月 1 日設定一個標誌日來啟動 segwit，該日將拒絕不發出 segwit 信號的區塊，從而通過 BIP9 機制強制啟動 segwit。這個提案是對礦工阻止 segwit 啟動的不作為的回應，儘管技術社群、產業和使用者的廣泛支援。

會議意見

Sipa 認為將 BIP148 合併到 Core 中會違背 Core 專案的原則，因為它鼓勵網路中的分叉，而且推動共識變更不是我們的職責。在相關 PR 中已經進行了很多關於 BIP148 的討論，即 #10417、#10428 和 #10442 以及郵件列表。Luke-Jr 認為不包含它會使使用者面臨風險，因為將會由替代客戶端創建分叉，如果成功可能最終替換鏈。Gmaxwell 認為沒有廣泛的支援來證明這種立場。

Wumpus、BlueMatt、Jtimon、Gmaxwell 和 Morcos 更傾向於 BIP149 而不是 BIP148。

Sipa 希望會有足夠的經濟支援，但預計每個經濟相關的完整節點都會在算力未能採用後幾小時內從 bip148 程式碼中撤回。

會議結論

只有在有足夠的經濟支援時才合併 BIP148。

幽默時刻

wumpus           #topic variable naming style
cfields  would kill for m_ == member
luke-jr          pls don't kill


sipa             i'll write up a PR, and we discuss there further?
morcos           sounds good
gmaxwell         sipa to do all the work, agreed.

參與者

IRC nick	Name/Nym
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
jtimon	Jorge Timón
BlueMatt	Matt Corallo
petertodd	Peter Todd
jcorgan	Johnathan Corgan
paveljanik	Pavel Janik

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-05-18

Thu, 18 May 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
客戶端過濾
修剪節點服務
bytes_serialized
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

新的手續費估算器已經合併。現在執行 master 將清除你的舊手續費估算。Morcos 將嘗試進行改進，使其對 0.15 更無縫。

主要議題

客戶端過濾
修剪節點服務
bytes_serialized

客戶端過濾

背景

為了讓輕量級 SPV 客戶端不必下載整個區塊鏈內容，創建了 BIP37。此 BIP 通過對等網路協定使用布隆過濾器，讓完整節點向 SPV 客戶端發送一小部分交易，其中包括 SPV 客戶端錢包所需的所有相關交易。

隨著時間推移，這種方法似乎沒有最初想像的那麼強大。

BIP37 中預期的隱私作為布隆過濾器概率性質的結果最終不存在。
隨著區塊鏈變得更大，完整節點上有顯著的處理負載，因為它們必須處理整個區塊鏈以服務同步的 SPV 客戶端。這也使其容易受到 DoS 攻擊。
SPV 客戶端不能有強大的安全性期望，因為默克爾路徑允許它們驗證輸出是可花費的，但它不能證明輸出稍後未被花費。

已經提出了許多改進這種情況的想法，都有各自的權衡。最近 Roasbeef 一直在進行基於 golomb 編碼集的想法，它比布隆過濾器小，但需要更多 CPU 時間。

會議意見

首先，這將是節點預先計算和儲存的東西。讓區塊承諾這個可以稍後完成。

Gmaxwell 對 golomb 編碼的效能持懷疑態度，但他有興趣看到它。

Roasbeef 建議兩個過濾器，一個用於包括輸出點和腳本資料推送的超輕量級客戶端，另一個用於包括見證堆疊、sig 腳本資料推送和交易 ID 的更複雜查詢。Gmaxwell 評論加入見證資料具有長期影響，因為從現在起幾年後，我們可以期望大多數節點不會儲存超過一年前的見證資料。Roasbeef 澄清包含見證資料的理由是允許輕客戶端有效地掃描隱形地址之類的東西。然而，在實踐中沒有人這樣使用它，任何實作它的人都通過中心化伺服器進行掃描。Sipa 的偏好是只有輸出點和完整的 scriptPubKeys。資料推送相對於完整 scriptPubKey 的唯一優勢是對於裸多重簽名，但那些在實踐中並不真正使用。

Jonasschnelli 補充 Kallewoof 對通過 p2p 網路通過布隆過濾提供過濾器有一個草案實作

會議結論

Roasbeef 將製作一個包含會議反饋的 BIP（郵件列表文章）

修剪節點服務

背景

目前修剪節點不會宣告自己擁有任何區塊，因此它們不向其他對等節點提供任何區塊。隨著區塊鏈大小的持續增長，修剪節點的數量在未來可能會增加。

非修剪的完整節點通過 NODE_NETWORK 宣告自己，Jonasschnelli 在 2017-05-27 會議中建議製作一個訊息來宣告轉發並能夠提供最後 144 個區塊（1 天的區塊）的修剪節點，即 NODE_NETWORK_LIMITED。

會議意見

Sipa 有一些可用資料，顯示從他的節點下載的每個區塊的相對深度，排除緊湊區塊。它確認 144 個區塊太小，修剪最小值 288 更好。Gmaxwell 認為 BIP 不應該有任何餘地/緩衝，只需宣告它們實際儲存的內容。如果結果證明節點沒有你需要的所有區塊，你可以連線到其他人。它也應該只說明需要儲存的區塊數量，而不要與時間有任何聯繫，因為輕客戶端在標頭同步後知道它們落後多少區塊，與時間無關。Gmaxwell 補充 BIP 還應該提到你可以為整個鏈提供標頭。

會議結論

Jonasschnelli 將把反饋納入 BIP。

bytes_serialized

背景

目前 gettxoutsetinfo 有一個稱為 bytes_serialized 的欄位，它基於 UTXO 集資料的某種理論序列化，以顯示資料庫以位元組為單位的大小。然而，在實踐中，這不是 UTXO 集在磁碟上佔用多少空間的好指標。

會議意見

Wumpus 認為應該有一種中立的方式來表示 UTXO 大小，不依賴於特定資料庫格式的估算。他可以接受它只是以中立格式的鍵和值的大小，不考慮 levelDB 前綴壓縮。

更改 bytes_serialized 的格式允許更改定義。

我們也應該在 gettxoutsetinfo 中報告實際磁碟使用量。

Wumpus 認為重新命名該欄位也是有意義的。

會議結論

PR #10195 將移除 bytes_serialized，Sipa 將創建一個單獨的 PR 來加入新的 disk_size 和 bogosize 來取代它。

高優先級審查

Ryanofsky 希望對 #10295（將一些 WalletModel 函數移動到 CWallet）進行更多審查，因為它阻礙了他的 IPC PR。
Jonasschnelli 加入了 #10240（加入 HD 錢包自動恢復功能）

幽默時刻

wumpus        time to close the meeting I think
instagibbs    2 minutes
luke-jr       defer BIP148 to next week?
wumpus        luke-jr: oh forgot about that one
luke-jr       it's okay, a week might be good anyway
gmaxwell      I'm sure you can discuss it in one minute.
gmaxwell      :p
kanzure       we need a meeting extension block
luke-jr       gmaxwell: well, to be fair, we've never had a formal time limit for meetings..
luke-jr       :p
instagibbs    it's a standardness rule...
kanzure       it was to prevent spam
gmaxwell      I like that they're limited. even though I always spend another half hour in resulting discussions.
gmaxwell      kanzure: that limit was temporary!
sipa          we should revert to the original limit of 24 hours
luke-jr       sipa: IMO the original limit was 5 hours
luke-jr       sipa: since that's how long until the day changes in UTC
gmaxwell      luke-jr: That isn't consistent with Craig Wright^W^WSatoshi's vision!
luke-jr       gmaxwell: it's consistent with tonal though
cfields       sipa: nah, let's just use an accounting trick and have meetings on a plane zooming through timezones.
cfields       I'm pretty sure we can cram 2 days into 1 that way :p
gmaxwell      too bad they stopped flying the concord.
sipa          you just need a plane circeling the arctic

參與者

IRC nick	Name/Nym
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
instagibbs	Gregory Sanders
wumpus	Wladimir van der Laan
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
CodeShark	Eric Lombrozo
roasbeef	Olaoluwa Osuntokun
jtimon	Jorge Timón
ryanofsky	Russell Yanofsky

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-05-11

Thu, 11 May 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
每 txo utxo 資料庫
手續費目標/硬幣選擇檢修
高優先級審查
參與者
免責聲明

註記 / 短議題

Sipa 和 Gmaxwell 一直在進行一項提案，以一種每個輸入和輸出只需幾微秒成本的方式始終維護 UTXO 承諾雜湊。這對於使 gettxoutsetinfo 即時化，或從其他人的 UTXO 集同步，或作為稍後軟分叉的基礎都很有用。有 3 種實作方式，都有不同的效能和安全性權衡。會議後幾天，郵件列表發布了一篇文章，解釋了不同的方法和選項。

主要議題

每 txo utxo 資料庫
手續費目標/硬幣選擇檢修

每 txo utxo 資料庫

背景

自 Bitcoin Core v0.8 以來，我們對鏈狀態資料庫及其快取使用了每交易模型。這意味著資料庫實際上是從 txid 到該交易未花費輸出列表的對應。PR #10195 將其更改為從輸出點（（txid，index）對）到該輸出點的單獨未花費輸出的對應。

聚合每個交易的輸出的原始原因是為了節省空間：這樣，我們可以避免在多個輸出中重複 txid 和交易元資料。然而，LevelDB 在內部使用一種編碼，省略鍵中重複的前綴位元組，因此，重複 txid 並不是很重要。

使用每 txout 模型有許多優點：

更簡單的程式碼。
避免反序列化和序列化未使用輸出的 CPU 開銷。
更可預測的記憶體使用。
更容易適應各種快取刷新策略。

缺點：

磁碟上的表示略大，有時記憶體中的表示更大（當快取中有同一 txid 的多個輸出時，這變成可選的）。

會議意見

測試結果非常有希望，如這張圖所示。Sipa 注意到在測試中鏈狀態從 2.2GB 增加到 2.7GB。

Gmaxwell 認為它應該很快合併以在 master 中進行更多測試，但它需要更多的測試/審查。BlueMatt 正在進行一半的審查，cfields 通過了審查，但不夠自信以 ACK 它。

仍需要進行一些程式碼清理，並為升級程序提供更好的使用者介面，因為啟動時會有一次性從舊資料庫升級到新資料庫，需要幾分鐘。

會議結論

審查 PR #10195（將鏈狀態資料庫和快取切換到每 txout 模型）

手續費目標/硬幣選擇檢修

背景

硬幣選擇是一種演算法，它找出如何花費你錢包中的硬幣。應該使用哪些來資助交易。這是在不創建非標準交易（通過超過某些大小，或創建粉塵輸出），試圖找到低手續費配置，給使用者盡可能多的隱私和縮小整體 UTXO 集大小之間的平衡。

多年來已經進行了許多改進，但仍然有偶爾出現的問題。Instagibbs 正在進行更改手續費目標演算法的工作，以考慮考慮的輸入的「有效價值」，而不是簡單地嘗試達到絕對手續費，看看它是否失敗，然後在迴圈結束時使用估算的總手續費再次嘗試。

會議意見

Gmaxwell 對在沒有清掃粉塵策略的情況下進行變更感到有點不安，他擔心可能會有意外的 UTXO 計數爆炸。

隨著對話更深入到手續費目標和硬幣選擇的一般方法，Morcos 提到了「手續費智慧」的想法，即當手續費低時可以包含更多輸入。

Wumpus 喜歡在低手續費率期間清理具有負值的 UTXO 的想法，但補充說如果一開始就不創建那些會更好。Morcos 提到他的 PR #9343，它試圖做到這一點。

Bitcoin Core 的設計目標是永遠不要創建小於 0.01BTC 的找零輸出，除非錢包幾乎被交易耗盡，但這個目標根本沒有實現。

向前邁出的一個好步驟也是將硬幣選擇從 wallet.cpp 中解剖和模組化。

會議結論

已經提出了許多關於手續費目標和硬幣選擇方法的想法，將在會議外進一步討論。

高優先級審查

Instagibbs 想加入 PR #10333，它修復了使用者報告的一些手續費問題，但不像硬幣選擇檢修那麼極端。

多錢包有一些審查意見，但是 PR 取決於上週加入到高優先級審查的 PR #9494。

Jonasschnelli 想加入 PR #10240（HD 錢包自動恢復功能），應該包含在 0.15 中。

參與者

IRC nick	Name/Nym
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
BlueMatt	Matt Corallo
instagibbs	Gregory Sanders
wumpus	Wladimir van der Laan
murchandamus	Mark Erhardt
morcos	Alex Morcos
sdaftuar	Suhas Daftuar

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-05-04

Thu, 04 May 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
HD 錢包自動恢復
高優先級審查
參與者
免責聲明

註記 / 短議題

BlueMatt 對他最近的議題提出一些關注，該議題質疑目前硬幣控制分組對手動隱私保護的有用性。

主要議題

HD 錢包自動恢復

HD 錢包自動恢復

背景

Bitcoin Core 自 0.13 版以來擁有階層式確定性錢包（HD wallet/BIP32）。HD 錢包是一個系統，它從一個稱為「種子」的單一起點派生所有金鑰。這允許使用者只需備份一次錢包，所有未來生成的金鑰都可以從種子重新生成。

為了加快審查和部署，Bitcoin Core 中 HD 錢包的第一個版本被做得很簡單，沒有太多花俏的功能。現在正在向錢包加入新功能，例如這個 HD 錢包自動恢復，它確保在與節點同步時始終檢查金鑰池，並且它搜尋的未使用金鑰數量足夠大。

會議意見

Jonasschnelli 根據上週會議的結論制定了一個適用於加密（和修剪）錢包的解決方案，但他不確定間隙限制和預設金鑰池大小應該是多少。BlueMatt 建議預設金鑰池為 10k，間隙限制為 1000。Jonasschnelli 注意到非加密錢包可以保持在 100，但這只會使其更複雜，而金鑰生成很便宜。

會議結論

將所有錢包的間隙限制提高到 1000，預設金鑰池大小提高到 10000。

高優先級審查

BlueMatt 要求從高優先級列表中移除 #8694（基本多錢包支援），因為它需要一些修復和 rebase。多錢包仍應該是 0.15 的優先事項。其中一個修復是重構所有使用 mapMultiArgs 的東西，這在 PR #9494 中完成，應該加入到列表中。

Sdaftuar 想加入 #9208（改進 DisconnectTip 效能）

Jtimon 的 #8855（使用適當的工廠創建 chainparams）仍在列表上，很容易審查。

Gmaxwell 希望儘快合併 per-txout + atomic，以便有更多時間測試程式碼。Sipa 將進行一些基準測試並在 PR 上報告數字。

參與者

IRC nick	Name/Nym
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
BlueMatt	Matt Corallo
instagibbs	Gregory Sanders
jtimon	Jorge Timón
Chris_Stewart_5	Chris Stewart

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-04-27

Thu, 27 Apr 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
HD 錢包自動恢復
NODE_NETWORK_LIMITED
bitcoind 過期
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

BlueMatt 有一個PR準備好了,這是邁向 libconsensus 的另一步。它將 CChainState 類別加入到 validation.cpp,它將持有像 mapBlockIndex chainActive 等東西

主要議題

HD 錢包自動恢復
NODE_NETWORK_LIMITED
bitcoind 過期

HD 錢包自動恢復

背景

會議意見

PR 的作者 Jonasschnelli 有幾個問題需要討論。他想知道我們應該嘗試始終恢復資金，還是檢查錢包的最佳已見區塊並與節點的最新區塊進行比較，然後才恢復。他認為我們應該只在最佳已見區塊落後時恢復，因為加密錢包可能需要解鎖以生成新金鑰，並且出於效能原因。Achow101 認為如果需要生成更多金鑰，可以在 GUI 彈出時提示使用者。然而，它也應該在命令列介面中工作，這樣解決起來更難。BlueMatt 建議在金鑰池足夠小時停止更新最佳已見區塊，並在錢包解鎖且金鑰池擴展時從該高度重新掃描。Sipa 注意到修剪節點也需要停止修剪。

另一個問題是金鑰池中的間隙限制應該是多少。目前這是 100，但這似乎太低了。目前的瓶頸是派生時間，這是 Berkeley DB 刷新的問題。修復 Berkeley DB 問題將導致巨大的改進，並允許將金鑰池提高到 1000 或 10000 之類的東西。

會議結論

始終掃描金鑰池並檢查金鑰池是否足夠大
將金鑰池和間隙限制擴展到 500+
對於加密錢包：暫停錢包的同步，直到它解鎖
對於加密的修剪節點：也暫停完整節點

NODE_NETWORK_LIMITED

背景

非修剪的完整節點通過 NODE_NETWORK 宣告自己，Jonasschnelli 建議製作一個訊息來宣告轉發並能夠提供最後 144 個區塊（1 天的區塊）的修剪節點，即 NODE_NETWORK_LIMITED。

會議意見

先前關於此主題的討論得出結論，使用兩個服務位元，用於 144 個區塊和約 1000 個區塊。

唯一需要討論的是我們需要將截止設置得多高，因為由於重組/邊界，它應該至少高幾個區塊。Gmaxwell 建議使用現有的修剪最小值 288 個區塊。

Jonasschnelli 認為我們應該允許目前設定 prune=550（550MB，這是最小值）的修剪對等節點發出轉發信號和圍繞最新區塊的有限數量的區塊（10），因為這將通過不必提供歷史區塊來降低頻寬要求。Gmaxwell 注意到還有其他限制頻寬的方法，我們沒有信號空間來發送每種區塊轉發的變體。還有過超過 10 個區塊深度的重組（如 BIP50），所以如果你所有的對等節點只提供 10 個區塊，這會造成許多問題。

會議結論

Jonasschnelli 將開始為兩個位元 NODE_NETWORK_LIMITED 編寫草案規範

bitcoind 過期

背景

Luke-jr 建議讓 bitcoind 和 bitcoin-qt 在 7-8 年沒有更新後過期。假設在 7 年內軟體將變得過時，因為軟分叉和可能的硬分叉將使其不安全，以及在此期間的漏洞利用。

它還會提供某種確定性，舊節點將在截止日期前結束，使任何硬分叉變成軟分叉，前提是它在 8 年前計劃。

會議意見

Luke-jr 澄清它允許明確覆蓋，所以如果人們願意，他們可以在過期日期之後使用軟體。

Petertodd 認為任何足夠短以真正有用的時間範圍可能都足夠短以引發政治風險。

BlueMatt 和 Wumpus 認為讓節點拒絕啟動並顯示錯誤訊息提及覆蓋旗標會更合理，儘管在那個時間尺度上沒有太大區別。然而，它會更簡單地實作，也不太容易出錯。

會議結論

會議後討論繼續，但沒有達成共識

高優先級審查

BlueMatt 建議為無法參加會議的 Morcos 加入 #10199（更好的手續費估算）。
Sipa 喜歡將需要更多測試的 #10148（使用區塊重放的非原子刷新）與 #10195（將鏈狀態資料庫和快取切換到每 txout 模型）交換
CFields 希望看到不緊急但是朝向 Libevent 的長線中的第一個的 #10285（重構）進入。

幽默時刻

wumpus           #topic libconsensus (BlueMatt)
BlueMatt         yes, so obviously this is all based on #771
jonasschnelli    (19 Jan 2012)
wumpus           archeology?

gmaxwell         I think in the future we'll change it to a limited set of options.
gmaxwell         Maybe all of them named after words for big in different languages, like starbucks. :P
sipa             gmaxwell: "For me a venti depruned node, please"
BlueMatt         sipa: I'm sorry, I dont speak starbucks
sipa             BlueMatt: venti is italian for 20. easy. that's obviously more than "grande" or "tall"
BlueMatt         sipa: ehh, I'll stick with my *good* coffee, thanks

wumpus           heck my nodes do nothing imporant and even I have a one-liner script that sends me a mail on crash or unexpected exit
sipa             my node does something important, and i have a 0-line script that sends me an mail on crash (= people mail me that my website stopped updating)
sipa hides
BlueMatt has a feeling sipa's approach is more common

參與者

IRC nick	Name/Nym
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
luke-jr	Luke Dashjr
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
BlueMatt	Matt Corallo
instagibbs	Gregory Sanders
jtimon	Jorge Timón
petertodd	Peter Todd
achow101	Andrew Chow

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-04-20

Thu, 20 Apr 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
手續費估算
地址重複使用
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

沒有報告 RC2 的問題，0.14.1 應該發布。（0.14.1 在會議後 2 天發布）
在 github 中有一些關於錢包處理地址重複使用和粉塵的有趣討論。任何對該主題感興趣的人可能想查看 PR #10233 上的討論以及從那裡連結的 PR。

主要議題

手續費估算
地址重複使用
高優先級審查

手續費估算

背景

在 Bitcoin Core 錢包中，你可以選擇希望看到交易確認的區塊數量，錢包將根據節點記憶池中交易的手續費率估算適當的手續費率。網路上的交易數量每日和每週都有很大變化，這使得這成為一個困難的平衡練習，既要確保交易在定義的時間範圍內得到確認，又要試圖讓使用者支付最小的手續費。

Morcos 一直在改進手續費估算演算法，並且根據上週會議的要求，撰寫了新手續費估算演算法的高層次描述。

會議意見

Morcos 在 #10199 中寫了一堆改進，但也有一些他想要反饋的開放問題。將改進的另一部分加入到更高層次的描述中是有意義的。手續費估算器足夠複雜，我們應該維護一個單獨的描述，甚至可能像許多主要協定功能一樣有一個實際的規範。

Gmaxwell 注意到該文件可能需要更多關於可靠性估算以及它如何合併桶的細節。總的來說，他補充說，我們應該嘗試使其足夠詳細，以便如果學術界出現並僅根據描述撰寫論文（他們會這樣做），結果對我們有用。

Morcos 也有一個計劃將估算器從記憶池中解耦，這建立在 BlueMatt 的 CValidationInterface 之上。

Gmaxwell 認為我們應該嘗試在未來保存更多的狀態，例如他有些節點每月停機時間不超過幾分鐘，但無法達到進行最準確手續費估算所需的兩週運行時間。

Jonasschnelli 想知道啟動後估算的可用速度有多快，以及它是否適用於修剪節點。Morcos 澄清修剪是無關的，對於 N 個區塊的目標，它需要至少 2*N 個區塊才能給你一個估算。之後它會保存資料，所以你可以重新啟動節點並立即獲得手續費估算。

會議結論

Morcos 將向 gist 文件加入新的變更和澄清。

地址重複使用

背景

由於會議還有時間，開發者開始談論地址重複使用問題和可能的解決方案。

一個已經被積極利用了很長時間的隱私問題是，人們向已經花費過的地址進行接近粉塵的支付，這樣你再次從它們花費，在新交易中創建一個雪球效應，將你的所有交易連結在一起。

會議意見

Gmaxwell 注意到最新的討論是由一個經營賭博網站的使用者推動的，他關心這個，因為他的客戶收到了連結回他的交易。然而，這對每個人來說都是一個隱私問題。

Gmaxwell 修復這個問題的建議是創建一個單獨的隔離餘額，其中任何地址或特定 TXO 可以手動隔離。然後調整硬幣選擇演算法以始終一次性花費對特定地址的所有支付。一旦地址被花費過，自動將其加入到隔離餘額中。

Wumpus 和 BlueMatt 喜歡這個想法，但不確定是否將其作為預設策略。BlueMatt 舉了一個可能的問題的例子，商家收到一半的付款，從該地址花費，收到另一半，但沒有意識到他得到了付款，因為資金會被隔離。Morcos 喜歡自動隔離的想法，但不太認同預設花費所有輸入的想法。

Gmaxwell 認為如果最終目標不是將其作為預設，資源投資是不值得的。Wumpus 認為如果我們認為無論如何都有用，這是值得的。

會議結論

作為第一步，在硬幣選擇演算法中引入從給定地址自動花費所有資金。

高優先級審查

PR #10148（使用非原子刷新進行區塊重放）在其目前的形式下，沒有多頭，只需要更多審查，也許還需要更多測試。
Luke-jr 注意到 multiwallet 已經 rebase，nits 已經修復。CWalletDB 仍然需要一些認真的重構，但這應該在不同的 PR 中完成。

幽默時刻

jcorgan       clearly this calls for Deep Fee Estimation
gmaxwell      die
jcorgan       tell me what you *really* think
luke-jr       no no, Xtreme Deep Fee Estimation!
gmaxwell      I have a lovely algorithim for an efficient limited memory 2D exponentially weighed moving average somewhere...
sipa          Xthin fees

morcos        ok, so this sounds like general agreement that this is a good idea and has degenerated into arguing about defaults. all development discussion in a nutshell!

參與者

IRC nick	Name/Nym
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
sdaftuar	Suhas Daftuar
morcos	Alex Morcos
luke-jr	Luke Dashjr
jcorgan	Johnathan Corgan
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
BlueMatt	Matt Corallo
instagibbs	Gregory Sanders
jtimon	Jorge Timón
Chris_Stewart_5	Chris Stewart

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-04-13

Thu, 13 Apr 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
0.14.1
scripted-diffs
0.15 的目標
- 背景
- 會議意見
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

Ryanofsky 的多程序變更被簡要討論，它將 QT 從 bitcoind 分離。雖然將錢包從網路中分離更重要，但 GUI 有更緊迫的問題，因為在 GUI 迴圈中與核心發生了太多同步。相關的 PR #10102 尚未完成，但可以對已經存在的程式碼進行一些審查。

主要議題

0.14.1
scripted-diffs
0.15 的目標
高優先級審查

0.14.1

背景

Bitcoin Core 0.14.1 包括錯誤修復和優化。候選版本 1（RC1）已於 4 月 8 日發布。RC2 已於 4 月 17 日（會議後幾天）發布。

會議意見

沒有關於 RC1 的錯誤報告。Cfields 和 BlueMatt 仍然希望將 PR #10176（優雅地處理 NodeId 包裝）放入 0.14.1，Gmaxwell 和 Wumpus 更傾向於不延遲發布，並且認為它不值得另一個 RC。

會議結論

會議後決定，但 0.14.1 被延遲，RC2 已經發布。

scripted-diffs

背景

CFields 提議在提交訊息中加入一個驗證腳本，可以由 Travis 驗證。這個驗證腳本可以用於簡單的事情，如搜尋和替換，這會創建大量的差異但很容易編寫腳本。如果腳本沒有將舊提交完全轉換為新提交，它會被 Travis 拒絕。這將使這些具有大量差異的簡單變更更容易審查。

Pull request #10193 是腳本差異提交應該如何看起來的一個例子。

會議意見

Luke-jr 認為我們不應該信任 Travis，它給人一種虛假的審查感。Gmaxwell 注意到審查者可以在審查腳本後測試它，Travis 的目的只是為了提供你已正確格式化它並且它在每台電腦上執行的反饋，而不是作為審查步驟。

Gmaxwell 認為只要我們不期望提交者執行它就可以。

Wumpus 認為這有點危險，因為它基本上會執行任意腳本。Cfields 注意到這一點是 BlueMatt 之前提出的，並認為可能值得討論將腳本限制為「sed」，它只是替換/取代。Cfields 也澄清腳本只在 Travis 上自動執行，其他地方都不執行。

Jtimon 建議它們只應在提交標題中有腳本前綴時執行，以使腳本將被執行變得更加明顯，因為大多數審查者審查程式碼，而不是提交訊息。

會議結論

審查 PR #10189（為可腳本化的變更加入驗證器）

0.15 的目標

背景

Bitcoin Core 0.15.0 計劃在 2017 年 9 月左右發布。針對 0.15 的 Pull request 都標記為 0.15.0 標籤。

Sdaftuar 想知道每個人對 0.15 的目標是什麼，這樣其他人就知道什麼應該有審查優先級。

會議意見

Gmaxwell 希望看到每 TXO dbcache 和非原子刷新。Cfields 想知道當從 0.15 降級到 0.14 時每 TXO 的預期結果是什麼。Gmaxwell 澄清它不能降級，需要重新索引。在嘗試降級時，可能值得在 0.14.2 中加入一些東西，優雅地說明格式已經改變，這比通用損壞訊息要好。

Jonasschnelli 的目標是：HD 自動恢復、QT 手續費提升、多錢包和 HD 僅觀察錢包。

Sdaftuar 希望將新的手續費估算放在適當的位置。Gmaxwell 認為我們需要一個演算法的高層次描述，我們可以給非開發者（學術界）審查，這也有助於一般審查，因為很容易失去對估算器整體設計的追蹤。Morcos 意識到這對審查來說是一個巨大的痛苦，收益甚微，但他確實認為這是值得的。BlueMatt 補充說，他不認為收益甚微，因為在錢包開發會議中討論的一個議題是整個生態系統中手續費估算有多糟糕，而 Bitcoin Core 是其中很大一部分。新估算器大大改善了週末期間的手續費估算。

BlueMatt 將致力於多執行緒 net_processing（和錢包），使用 CValidationInterface 生成回呼到其中。

Sipa 希望看到每 TXO dbcache、移除刷新時的記憶體峰值和更好的 dbcache 驅逐策略。

高優先級審查

BlueMatt 想加入 PR #10179（為 CValidationInterface 提供在 CScheduler 執行緒上呼叫通知的支援），因為它和 #10178 為他將錢包回呼移動到背景執行緒的 0.15 目標鋪平了道路。

Sipa 想加入 PR #9792（FastRandomContext 改進和切換到 ChaCha20）

Morcos 認為 #9942（重構 CBlockPolicyEstimator）可以合併，並會使手續費估算變更的其餘部分更小以便審查。

Jnewbery 希望對 #10044（在 ‘make check’ 中執行功能測試）進行一些審查

幽默時刻

BlueMatt       because its free, we're already doing 0.14.1 and delaying 1 week isnt gonna kill us
BlueMatt_      But delaying 1 week isn't too bad
BlueMatt       wait, who is BlueMatt_ ?
wumpus  confused
BlueMatt_  confused
BlueMatt  has no idea who BlueMatt_ is
BlueMatt_ has no idea who BlueMatt is
kanzure        different timeline, carry on.
luke-jr        whois says it's Matt Corallo
BlueMatt       not me
gmaxwell       wumpus: shoot the T1000 (BlueMatt_) and lets move on.
sipa           BlueMatt_: this statement is false

spudowiar      You could create format like '*.cpp *.h | s/boost::filesystem/fs/g'
sipa           spudowiar: little bobby tables will haunt you

sipa           I want pertxoutcache, remove memory peak at flushing, better dbcache eviction policy, ...
sipa           oh, and segwit activated? pretty please?
BlueMatt       sipa: lol
cfields_       sipa: let's activate segwit after the meeting. We only have 20 min left :p
gmaxwell       cfields_: ack
wumpus         #action activate segwit
gmaxwell       jinx

參與者

IRC nick	Name/Nym
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
cfields	Cory Fields
sdaftuar	Suhas Daftuar
morcos	Alex Morcos
luke-jr	Luke Dashjr
jcorgan	Johnathan Corgan
CodeShark	Eric Lombrozo
kanzure	Bryan Bishop
gmaxwell	Gregory Maxwell
BlueMatt	Matt Corallo
BlueMatt_	T-1000 先進原型（擬態聚合金屬）
spudowiar	Saleem Rashid
petertodd	Peter Todd
jnewbery	John Newbery
ryanofsky	Russell Yanofsky
instagibbs	Gregory Sanders
phantomcircuit	Patrick Strateman
MarcoFalke	Marco Falke
achow101	Andrew Chow

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-04-06

Thu, 06 Apr 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
進行中的工作
- 背景
- 會議意見
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

許多開發者參加了金融密碼學會議，因此這是一個簡短的會議。
0.14.1 RC1 已被標記，gitian 建置正在進行中
Jtimon 在待辦事項列表中新增了更多想法，旨在讓 Bitcoin Core 專案的新開發者熟悉為 Bitcoin Core 貢獻。

主要議題

進行中的工作
高優先級審查

進行中的工作

背景

由於許多開發者由於金融密碼學會議而缺席或未專注於會議，Sdaftuar 詢問是否有人想提供他們正在進行的工作的更新，以獲得一些概覽並開始對話。

會議意見

Luke-jr 正在進行一個按 scriptPubKey 的 UTXO 索引以用於清掃目的。Wumpus 指出 PR #9806 正在嘗試做同樣的事情。
Jonasschnelli 正在進行一個 Bloom Filter Digest，他希望在 2016-11-10 會議中談到的混合全區塊 SPV 模式中使用它。
Sipa 一直在進行與資料庫/快取/刷新/記憶體使用相關的工作。
Morcos 數月來一直在編碼和重新編碼手續費估算，但它要複雜得多，而且會很難審查。
Sdaftuar 一直在進行 CreateNewBlock 的工作，引入一種方法，如果這樣做的區塊收入低於某個閾值，則跳過最近新增的交易。
Jtimon 進行了一些重構 PR，如 #9494、#10119 和 #10118

高優先級審查

Github 上的高優先級審查專案。

Jtimon 認為 PR #7729（為錢包引入 ‘label’ API）應該加入到優先級列表，因為它阻礙了帳戶系統的移除。Wumpus 同意，但注意到人們應該審查 API，而不是程式碼，因為現在已經過時了。

幽默時刻

sipa               it seems we boosted the speed of the meeting significantly
warren             overt boost even
jonasschnelli      boost(ed),.. I can't read that word anymore
jeremyrubin        A [sic] efficiency gain
jcorgan            ima go patent it
wumpus             isn't meeting speed boost patented?

參與者

IRC nick	Name/Nym
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
jtimon	Jorge Timón
cfields	Cory Fields
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
morcos	Alex Morcos
luke-jr	Luke Dashjr
warren	Warren Togami
jcorgan	Johnathan Corgan
btcdrak	BtcDrak
CodeShark	Eric Lombrozo
kanzure	Bryan Bishop

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-03-30

Thu, 30 Mar 2017 00:00:00 +0000

概覽

註記 / 短議題
主要議題
緩慢的單元測試
處理 abortnode / ConnectTip / DisconnectTip 失敗
高優先級審查
幽默時刻
參與者
免責聲明

註記 / 短議題

BlueMatt 注意到上週被封鎖和需要審查的 PR 中 6 個有 2 個被合併，可以做得更好。Wumpus 為會議中提到具有優先級的 PR 創建了一個高優先級審查 github 專案頁面。
已有 11 個合併標記為 0.14.1 和 3 個開放的 PR。一旦這些進入，0.14.1 應該就可以發布了。

主要議題

緩慢的單元測試
處理 abortnode / ConnectTip / DisconnectTip 失敗
高優先級審查

緩慢的單元測試

背景

Bitcoin Core 提供了一個 makefile 目標 check 來執行專案的單元測試。該專案隨著時間推移編寫了越來越多通過 RPC 介面執行的整合測試，這些測試由 Travis 持續整合（CI）伺服器自動執行，該伺服器測試每個 Bitcoin Core pull request，可以通過執行 qa/pull-tester/rpc-tests.py 手動執行

如先前在 2017-03-16 會議中討論的，這些測試作為整體目前可能需要太長時間。

會議意見

Wumpus 製作了一個最慢單元測試的概覽。其中一些已經被處理或有 PR 使它們更快。

我們也可以為單元測試引入一個 -extended 模式，它會進行額外徹底的測試，不應該每次都執行。擴展模式應該是發布程序的一部分（並由 gitian 執行）和/或在 master 上每天執行一次。

Jonasschnelli 有一個具有良好網頁 UI 的建置伺服器，每天在 https://bitcoin.jonasschnelli.ch/ 進行 gitian 建置。

Jnewbery 注意到 Travis CI 服務目前失敗，因為我們將其設定為每天執行一次擴展測試，所以我們正在清除所有一直在 Travis 上失敗的擴展測試。一旦 PR #10114 和 #10072 被合併，這些每日執行應該會通過 Travis。

會議結論

對於標準 make check，每個測試案例的準則是最多約 1 秒，對於具有更廣泛測試的單元測試有一個擴展模式。

處理 abortnode / ConnectTip / DisconnectTip 失敗

背景

Sdaftuar 有一個開放的 PR（#9208），它改進了鏈重組後的效能，其中節點發現一個新的最長有效鏈，排除了先前被認為是最長有效鏈的區塊（將被孤立）。目前我們試圖將每個孤立區塊的交易加回到記憶池，即使這些交易中的許多可能會在新發現的區塊中重新出現。#9208 將這些交易儲存在單獨的「斷開連接池」中以供稍後處理。

會議意見

BlueMatt 提出了當 ConnectTip 或 DisconnectTip 回傳 false 時的一些邊緣情況，我們現在 assert() 而不是 AbortNode()。對於何時使用 AbortNode() 以及何時使用 Abort()/assert()，以及通知使用者發生錯誤的最佳方式，進行了一些更廣泛的討論。AbortNode() 允許我們以訊息退出以通知使用者，所以理想情況下只有關鍵錯誤才應導致 Abort()/Assert()。

會議結論

將 AbortNode() 重新命名為 ShutdownSoon()，並確保磁碟損壞使用不同的東西。

高優先級審查

所有標記為 0.14.1 的 PR 應該有優先級

Sipa 補充說，他希望看到 #9792（FastRandomContext 改進和切換到 ChaCha20）在某個時候進入，以進一步移除對 OpenSSL 的依賴。

Gmaxwell 提議重新開啟他的 PR #9424，它將記錄類別更改為布林旗標而不是字串。這將使像 #10123 這樣的 PR 更容易使用，它允許你從除錯記錄中排除某些元件。Cfields 補充說，他想為網路訊息做類似的事情。

幽默時刻

wumpus             if BlueMatt can make it work faster that's great, but don't silently kill the program on every error
gmaxwell           wumpus: how about every other error?

9:48  BlueMatt     so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
...
9:53  BlueMatt     <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
...
9:57  BlueMatt     ok, soooo, acks on:<BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
9:58  jeremyrubin  BlueMatt: maybe if you paste it again
9:58  BlueMatt     jeremyrubin: ok, <BlueMatt> ok, soooo, acks on:<BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?

jtimon             it seems it's time to abort the meeting
wumpus             #endmeeting
BlueMatt           wumpus: we need to change that to #abort()
gmaxwell           But I wanted to cleanly flush!

參與者

IRC nick	Name/Nym
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
BlueMatt	Matt Corallo
jtimon	Jorge Timón
cfields	Cory Fields
achow101	Andrew Chow
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
MarcoFalke	Marco Falke
jnewbery	John Newbery
morcos	Alex Morcos
instagibbs	Gregory Sanders
Chris_Stewart_5	Chris Stewart

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-03-23

Thu, 23 Mar 2017 00:00:00 +0000

概覽

主要議題

Segwit 地址提案
錢包中的 DER 私鑰
反對二進位發布的聲明
被封鎖和需要審查的 PR

Segwit 地址提案

背景

Pieter Wuille 和 Gregory Maxwell 最近提出了一個用於原生隔離見證（segwit）scriptPubKey 的地址格式。

對話

Gregory Maxwell 開始對話：「我們可能在從太多人那裡獲得 1:1 評論方面犯了策略錯誤，導致郵件列表上的評論缺乏。郵件列表上的評論會很好，即使它們只是『我之前審查過這個，LGTM [Looks Good To Me]』。」

Peter Todd 建議：「沿著這些思路，我認為公開其中一些 1:1 評論可能對有興趣了解這些流程如何運作的新開發者有幫助。」

在討論優化 QR 碼編碼時，Jonas Schnelli 提到：「為 QR 碼設計額外的二進位地址標準可能不值得。也許它們只是暫時的？3-4 年後就沒有了？」

Maxwell 回答：「我認為為此可能不值得，但產業反饋會很好。」

Wuille 補充：「[QR 碼的]字母數字模式相當有效；與二進位相比只多 10%。它每個字元使用 5.5 位元，所以每 5 位元資料 5.5 位元相當不錯。」

Schnelli 然後問：「Bech32 編碼也可以用於私鑰（== 32 位元種子）嗎？」

Wuille 回答：「好問題！我們一直在考慮為私鑰使用更強的校驗和，可能是 12 個校驗和字元（這是 64 位元算術可以做到的最大值）。對於地址，你真的只關心[錯誤]檢測，但對於私鑰，你想要[錯誤]更正。使用 12 字元校驗和，更正 3 個錯誤是微不足道的，但也許我們可以找到一個可以更正 4 個的。」

Maxwell 補充：「找到一個更正 4 的 12 位數程式碼可能需要比我們這裡一百個核心更多的計算能力，儘管 [Wuille] 已經做了很多工作，將這個搜尋從完全難以處理變為合理。:) 我認為這項工作的優先級比我們可以進行的其他工作（如 utxo 資料庫重構和交易壓縮）要低得多」

在討論接近尾聲時，Maxwell 簡要談到了 bech32 編碼在防止資金被發送到錯誤地址方面的有效性：「如果使用者的錯誤率低於每個輸入地址 3.53 個錯誤，此程式碼的保護比 32 位元雜湊（如 base58 check 使用的）更好。由於大小寫調變，使用者使用此格式犯錯的可能性要小得多。如果使用者不太可能犯錯，那麼此方案的有效保護趨於無限。例如，每個字元 0.1% 的錯誤機率，錯誤字串未被檢測到的機率是 1:2⁶⁰ [0.0000000000000000867%]。

結論

會議中幾位尚未審查（或完成審查）提案的人將審查它，所有已經審查過的人都被鼓勵在郵件列表上分享他們的評估。

任何閱讀這些會議記錄的錢包作者或其他 Bitcoin 開發者都被鼓勵審查提案，讓社群知道他們是否暫時支援它，或提出他們對它的任何問題。

錢包中的 DER 私鑰

背景

Gregory Maxwell 描述了目前的情況：「DER 私鑰格式包括公鑰，以及所有 ECC 群組參數，和其他開銷，所有這些都打包在數百位元組的 ASN1 解析地獄中。」這對 Bitcoin 錢包中的每個私鑰都這樣做，即使所有 Bitcoin 私鑰使用相同的參數，並且這些參數已經為 Bitcoin Core 所知。

自 Bitcoin Core 0.13.0 以來，由 Bitcoin Core 預設設定創建的所有新錢包都使用 BIP32 階層式確定性（HD）錢包。使用單獨隨機生成金鑰的舊式錢包，以及使用 importprivkey RPC 匯入金鑰的錢包仍然受支援。

討論

沒有人反對更改錢包格式以在不使用 DER 的情況下儲存金鑰或 HD 種子。大多數討論涉及應如何管理此變更和其他類似的錢包變更，特別是確保它們易於測試，但錢包格式每個版本最多只變更一次。

結論

沒有明確的結論。在對話接近尾聲時，討論集中在使用待定功能的特殊旗標上；例如，Maxwell 寫道：「我不在乎我們是否為某人通過執行 bitcoind 加上 --force-wallet-screw-me-over-now-now-now 創建的錢包保留相容性」。

這種類型的旗標將允許測試和合併單獨的功能，但在所有針對特定版本的功能都已合併之前，預設情況下不會啟動。

反對二進位發布的聲明

背景

在會議開始前幾天，Bitcoin Core 專案的一個分叉僅發布了二進位版本，他們聲稱是出於安全原因。

討論

Gregory Maxwell 詢問開發者是否願意簽署一份關於 Bitcoin Core 承諾永遠不會在沒有原始碼的情況下發布二進位檔案的聲明。聲明開始：

Bitcoin 專案永遠不會要求使用者在不提供原始碼的情況下執行二進位檔案。如果它這樣做，你可以安全地假設該專案的實際貢獻者被鎖在某處的地下室。在這種情況下，請派遣救援。

Bryan Bishop 建議人們不僅派遣救援，還要派遣食物。

還有其他幾個建議來完善聲明，但沒有人反對該聲明。

結論

沒有明確的結論。可能 Maxwell 將繼續完善聲明並為其收集簽名。

被封鎖和需要審查的 PR

背景

Matt Corallo 建議：「每週呼籲『你被封鎖在哪個 [Pull Request (PR)] 上並想要審查』，儘管我之前這樣做時結果好壞參半。」

討論

Corallo 請求 #9725：CValidationInterface 清理
Wladimir van der Laan 和 Jonas Schnelli 請求 #9294：對找零輸出使用內部 HD 鏈（hd split）
Gregory Maxwell 請求 #9959：Mining: 防止大型記憶池上的 CreateNewBlock 減速

還有關於使用 GitHub 專案看板或使用標籤追蹤審查請求的討論。

結論

鼓勵審查者專注於上述 PR。會議中沒有就使用專案看板或標籤進行請求的審查做出決定。

幽默時刻

<wumpus> proposed topics?

<btcdrak> holiday at the beach?

<petertodd> btcdrak: that's what the financial crypto conference is for

<kanzure> rationale section was good, although i think it would be worthwhile to
          describe the 'exhaustive search'

<gmaxwell> kanzure: we left out a lot of technical minutia about the construction
           which is interesting but not really relevant to the spec.

<sipa> earlier version explained finite field arithmetic and generator polynomials :)

參與者

IRC nick	Name/Nym
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
jonasschnelli	Jonas Schnelli
sipa	Pieter Wuille
BlueMatt	Matt Corallo
luke-jr	Luke Dashjr
petertodd	Peter Todd
kanzure	Bryan Bishop
jtimon	Jorge Timón
cfields	Cory Fields
btcdrak	BtcDrak
achow101	Andrew Chow
Anduck	Antti Majakivi
phantomcircuit	Patrick Strateman

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-03-16

Thu, 16 Mar 2017 00:00:00 +0000

概覽

主要議題
錢包應如何處理長鏈未確認交易
- 背景
- 意見
- 結論
移除帳戶系統的狀態
- 背景
- 討論
- 結論
修訂 make check 測試
- 背景
- 討論
結論
幽默時刻
參與者
免責聲明

主要議題

錢包應如何處理長鏈未確認交易
移除帳戶系統的狀態
修訂 make check 測試

錢包應如何處理長鏈未確認交易

背景

Bitcoin Core 允許其錢包使用者創建未確認交易鏈。例如，交易 C 花費來自交易 B 的找零，而交易 B 本身花費來自交易 A 的找零。

如果你以這種方式創建超過 20 個未確認交易的鏈，Bitcoin Core 0.14.0（預設）會拒絕你在該鏈上創建的任何新交易。這是因為 Bitcoin Core 中的其他邏輯不允許超過 20 個交易的鏈進入其記憶池，以防止其他人濫用你節點的資源。

在會議時，至少有兩個獨立的人開啟了關於此問題的議題，想知道為什麼他們不能創建交易。

或者，Bitcoin Core 以前允許使用者創建超過 20 個未確認交易的鏈，但只是不轉發深度超過 20 的交易或將它們加入記憶池，直到它們的一些祖先被確認。這意味著當你創建第 21 個交易時，你的錢包會扣除你花費的金額（你的輸入），但不會立即貸記你任何找零輸出。

例如，如果你將 10 BTC 輸入花費到 0.1 BTC 輸出，你會期望你的餘額下降 0.1 BTC——但相反地，它會下降 10 BTC，直到至少前 20 個交易之一被確認。

作為折衷，Bitcoin Core 0.14.0 提供了一個命令列選項，允許使用者選擇他們想要的行為：預設限制 20 個鏈式交易或無限鏈式交易但延遲餘額更新。

這個議題已經在開發者之間討論過很多，在會議中談論它的開發者都不滿意目前的行為——但到目前為止，沒有人提出一個能夠提供良好使用者體驗而不需要大量程式碼變更來處理這種相當罕見情況的解決方案。

此外，整個情況因網路上常規錢包交易持續存在的交易延展性而加劇。如果祖先交易被修改，其所有後代都將在同一區塊鏈上無效。在這種情況下不會損失金錢，但錢包需要一種方法來了解這些後代交易現在無效，並相應地更新錢包餘額。

意見

在試圖描述問題時，Alex Morcos 說：「在 PR 上進行這種討論有點困難」。根據聊天期間的混亂程度，在 IRC 中討論似乎也很困難。

Gregory Maxwell 建議：「這是我們目前定義只是被破壞的跡象。它不應該與記憶池如此緊密耦合（例如，對於沒有記憶池的人，軟體應該如何使用？——這是一個支援的配置！）。」

Pieter Wuille 回答：「如果你不依賴記憶池，我認為讓錢包重複計數並不難」，Wladimir van der Laan 擴展說：「所以如果它發送一個交易，有人修改它，它會收到被修改的版本，它會重複計數。」

Wuille 也補充：「不花費未確認找零的錢包沒有這個問題」。

討論偏離了手續費提升的話題一段時間，然後回到主要議題，Maxwell 指出：「沒有延展性，基本上所有這些找零處理議題都不會存在，我認為，因為你永遠不會有可能重複計數你自己資金的情況。」

結論

在討論這個議題超過半小時後，Morcos 建議：「好吧，我們偏離了軌道。現在——也許下一個議題，我們在思考這兩條路徑後一週後重新訪問這個」，這得到了所有會議參與者的熱烈贊同。

移除帳戶系統的狀態

背景

到 2010 年末，幾個網站提供的網路錢包和交易所基本上是 Bitcoin 軟體之上的一個薄層（它還沒有被稱為 Bitcoin Core）。在那段時間，Bitcoin 引入了一個帳戶系統，允許單個 Bitcoin 實例追蹤多個帳戶中的餘額。

後來，網路錢包和交易所實作了自己的會計後端，從那時起，Bitcoin Core 的帳戶系統大多未被使用——然而它使許多 RPC 呼叫複雜化，除了執行多使用者網路錢包之外，對任何事情都不是特別有用。（即將推出的功能，多錢包，將為想要分割不同比特幣集合的使用者提供真正的錢包分離。）

因此，在過去幾個版本中，與帳戶系統相關的所有功能都被標記為已棄用，並且正在被移除或轉換回帳戶起源的標籤系統。

討論

Wladimir van der Laan 總結了狀態：「可以很簡短：自上次討論以來沒有進展，因為我們需要先有一個標籤 API，然後才能考慮棄用帳戶。」

Matt Corallo 說：「這絕對應該在 0.15 中發生，IMO [in my opinion]」，Wladimir 同意但補充：「我同意，儘管 multiwallet 對我來說有更高的優先級。」

然後討論轉移到關於多錢包的議題，主要是哪些 pull request 對本週審查開發者有用，包括 PR#9294 和 PR#8694。

結論

審查上述 pull request 以在 multiwallet 上取得進展，並在標籤 API 上工作以移除帳戶系統。

修訂 make check 測試

背景

討論

Jonas Schnelli 問：「將 rpc 加入到 make check 有什麼好處？」

Wladimir van der Laan 回答：「make check 理想上應該進行相當快速的檢查，一些 RPC 測試符合這個條件，但整個套件可能需要太長時間。」

討論繼續確保 make check 執行速度合理快，包括增加在多個 CPU 核心上執行它的能力。

結論

John Newberry 總結：「好的，聽起來至少在 make check 中進行一些 RPC 測試沒有根本性的反對。我會開啟一個 PR，我們可以在那裡繼續討論。」

幽默時刻

<wumpus> gmaxwell: yup. don't know if you saw the clang fsafe-stack
         issue that messes up deterministic signing

<gmaxwell> wumpus: I didn't.

<wumpus> gmaxwell: let me dig it up
         gmaxwell: https://github.com/bitcoin-core/secp256k1/issues/445

<gmaxwell> wumpus: holy fuck!

（上述內容的背景：Bitcoin Core 和 libsecp256k1 的測試發現了編譯器中引入的錯誤，可能會造成嚴重問題。）

<gmaxwell> without malleablity basically none of these change handling issues
           would exist, I think.
           as you'd never have a case where you might double count your
           own funds.

<wumpus> unfortunately we're stuck with malleability

<morcos> not if we use flextrans
         (sorry)

<gmaxwell> hah

<jonasschnelli> heh

<wumpus> flextrans, lol

<BlueMatt> trolol

參與者

IRC nick	Name/Nym
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
sipa	Pieter Wuille
morcos	Alex Morcos
jonasschnelli	Jonas Schnelli
jnewbery	John Newbery
jtimon	Jorge Timón
BlueMatt	Matt Corallo
luke-jr	Luke Dashjr
cfields	Cory Fields
instagibbs	Gregory Sanders
achow101	Andrew Chow
bsm117532	Bob McElrath
kanzure	Bryan Bishop

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-03-09

Thu, 09 Mar 2017 00:00:00 +0000

概覽

主要議題
0.14.0 版本發布
警報金鑰披露時間表
- 背景
- 意見
- 結論
下一個版本（0.14.1 和 0.15）
- 背景
- 意見
結論
幽默時刻
參與者
免責聲明

主要議題

0.14.0 版本發布
警報金鑰披露時間表
下一個版本

0.14.0 版本發布

Bitcoin Core 0.14.0 在會議前一天發布。大家分享了對成功發布的歡呼和祝賀。

警報金鑰披露時間表

背景

在 Bitcoin 0.3.11 中引入的 Bitcoin 警報系統已在過去幾個 Bitcoin Core 版本中逐步淘汰。更多資訊，請參見公開資訊聲明。

在較早的 Bitcoin Core 版本中，警報系統被重新設計為包含一個硬編碼的「最終」警報，可以在警報系統的私鑰被洩露的情況下觸發。作為 Bitcoin Core 0.14.0 發布程序的一部分，這個最終警報被觸發了——這應該為按計劃公開發布警報金鑰鋪平了道路。

意見

Gregory Maxwell 開始說：「在舊版本中有 DOS 漏洞是最終警報無法阻擋的。:( 所有版本。在較舊的版本中更糟糕。（顯然只有啟用警報的版本）。沒有 RCE [遠端程式碼執行]，只是 OOM [記憶體不足]。」

根據 Luke Dashjr，2,606 個節點（4.54%）執行低於 0.12.1 的 Bitcoin Core 版本。正是這些版本被 Maxwell 識別為容易受到與濫用警報金鑰相關的問題的影響。

結論

似乎達成了粗略的共識，即會對 Maxwell 發現的阻斷服務漏洞進行通用漏洞和暴露（CVE）披露，以進一步提醒舊版本 Bitcoin Core 使用者他們需要升級。在分發 CVE 並重新評估情況後，可以決定是否屆時披露警報金鑰。

下一個版本（0.14.1 和 0.15）

背景

隨著 0.14.0 的發布，開發者已經開始標記議題和 Pull Request（PR）以向後移植到 0.14.1 小版本。此外，已提出了 0.15 版本發布時間表。

意見

Matt Corallo 建議將 #9959 和 #9955 用於 0.14.1 小版本。沒有人反對 Alex Morcos 的建議：「我們應該為這些標記 0.14 或向後移植或我們說的任何東西，但不是加速小版本發布的原因」。這意味著開發者可能會等待其他幾個錯誤修復或特別有用的向後移植可用後再製作 0.14.1 版本，保持時間表空閒以進行 0.15 及以後的長期改進工作。

Wladimir van der Laan 在 #9961 中提出了 0.15 版本發布時間表。截至本文撰寫時，時間表為：

2017-07-02
-----------
- 開放 0.15 的 Transifex 翻譯
- 軟性翻譯字串凍結（在發布前不做大的或不必要的字串變更）
- 完成並關閉 0.13 的翻譯

2017-07-16
-----------
- 功能凍結（在發布前僅修復錯誤）
- 翻譯字串凍結（在發布前不再變更原始語言）

2017-08-06
-----------
- 從 `master` 分出 `0.15` 分支
- 開始 RC 週期，標記並發布 `0.15.0rc1`
- 開始在 master 分支上合併 0.16

2017-09-01
-----------
- 發布 0.15.0 最終版（目標）

結論

會議中沒有人反對提出的時間表。議題和 PR 將繼續標記為向後移植到 0.14.1。

幽默時刻

<gmaxwell> There are also funds paid to the alert key in the network, I believe
           0.01 BTC or so. :P

<wumpus> surprised no one ever swiped that

參與者

IRC nick	Name/Nym
wumpus	Wladimir van der Laan
gmaxwell	Gregory Maxwell
luke-jr	Luke Dashjr
achow101	Andrew Chow
sipa	Pieter Wuille
btcdrak	BtcDrak
morcos	Alex Morcos
BlueMatt	Matt Corallo
cfields	Cory Fields
jtimon	Jorge Timón
paveljanik	Pavel Janik
jonasschnelli	Jonas Schnelli

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-03-02

Thu, 02 Mar 2017 00:00:00 +0000

概覽

主要議題

0.14.0 版本發布
優先審查和合併請求
0.15 版本的主要功能
Segwit 啟動後的 GetBlockTemplate 行為
CreateNewBlock 呼叫 TestBlockValidity 與否，以及 CreateNewBlock 快取
（空白）

0.14.0 版本發布

背景

Bitcoin Core 0.14.0 的第二和第三個候選版本（RC2 和 RC3）在上週會議後發布。

0.14.0 的許多主要升級都是效能改進。

意見

簡短討論了已發布一週的 RC2 和最近發布的 RC3 的狀態。沒有開發者知道任何問題，有一人回報看到 RC 測試者的一些正面評論。

結論

兩位會議參與者建議如果 RC3 沒有發現問題，將在 3 月 7 日星期二發布 Bitcoin Core 0.14.0 的最終版本。

優先審查和合併請求

背景

當多個不同的程式碼庫變更建議各自以不同方式編輯相同的程式碼行時，就會產生無法由自動化版本控制軟體解決的衝突。相反地，開發者需要手動審查每個衝突的變更，並找出要保留哪個變更，或是否需要將變更組合在一起。

解決這些衝突耗時且大多數開發者認為相當煩人，特別是因為如果第一個開發者的建議變更在任何後續開發者開始工作之前合併到程式碼庫中，通常可以避免這種情況。

此外，由於程式碼在解決衝突時經常變更，變更後的程式碼通常需要由 Bitcoin Core 有限的經驗豐富的程式碼審查者重新審查。

基於這些原因，開發團隊試圖優先審查和合併可能導致許多衝突變更的 Pull Request（PR）。

意見

Alex Morcos 開啟話題：「我想簡短討論合併 #9602 的時機。因為，假設我們要這樣做，最好盡快處理，這樣就不會變成 rebase/審查的惡夢。我還有大量建立在其之上的手續費估算變更。」

Matt Corallo 回覆：「很快會完成審查，但到目前為止看起來不錯。我同意它應該快速合併。」

Suhas Daftuar 補充：「我也在進行一些挖礦調整，我寧願直接建立在 9602 之上。」

Corallo 提出另一個優先審查請求：「我想 Luke 的 dont-use-pwalletMin 的東西重新 rebase 也是個麻煩。那是 #8775。」

結論

Wladimir van der Laan 表示：「盡快審查和合併 #8775 和 #9602，它們容易變成 rebase/合併的惡夢。」

0.15.0 的主要功能

註：這是在前面的 rebase 議題期間討論的。

背景

Gregory Maxwell 開始討論：「可能不是在這次會議中，但人們思考他們希望 0.15 的主要功能是什麼，並確保我們足夠早地在這些事情上取得進展，以便它們實際上能夠在那裡，這可能是有用的。:) 我覺得至少我個人想要在 0.14 中有些東西，但直到太晚才給予足夠的關注。」

Wladimir van der Laan 進行調查，看是否有人有「大型即將到來的軟分叉專案會壟斷所有人」，但 Maxwell 回答：「所有類似的東西都因 segwit 而暫停！」因此 Wladimir 建議「這意味著對於 0.15，我們可以專注於軟體功能而不是網路/共識功能。」

討論

Alex Morcos 問：「我們沒有任何不基於 segwit 的軟分叉建議在佇列中嗎？讓我們利用 BIP 9！」Pieter Wuille 回答：「提高最低難度，可選的 UTXO 承諾，…」

提高最低難度有望成為從共識相容的完整節點（如 Bitcoin Core）中移除區塊鏈檢查點的最後一步。檢查點在 Bitcoin 0.3.2 中加入以「鎖定到此點的區塊鏈」，這降低了某些攻擊的有效性，但也提供了一種可以覆蓋 Bitcoin 基本規則之一的機制：網路帳本是具有最多工作量證明（PoW）的有效區塊鏈。

提高最低難度會使攻擊更昂貴（因為它們必須包含比現在相同攻擊多得多的 PoW），而不會妨礙 Bitcoin 正常使用 PoW 在有效鏈之間進行選擇。

更多背景資訊，請參見 2016 年 10 月 27 日會議期間的討論，以及 IBD using chainwork（在 Bitcoin Core 0.13.2 中發布）和 assumed valid blocks（在 Bitcoin Core 0.14.0 中發布）。
可選的未花費交易輸出（UTXO）承諾可以幫助提高輕量級錢包的安全性。這是多位貢獻者主要獨立工作但共享想法，已經兼職研究數年的主題。本摘要的作者不知道任何具體的提案，甚至在技術社群中獲得初步的廣泛接受。

Morcos 也建議：「我腦海中的一個主要功能，但有點複雜，所以可能需要一些討論是否要它（以及何時），那就是自動化手續費提升。」Maxwell 建議不同的名稱：「我會用『預先計算手續費提升』取代『自動化手續費提升』」。

預先計算手續費提升由 Maxwell 在會議中簡要描述：「當你簽名時，預先簽署所有提升，使用 locktime…這樣它們不會干擾錢包加密…甚至可以在你離線時交給其他人。」

例如，Alice 會告訴 Bitcoin Core 她想在接下來的 10 個區塊內支付給 Bob，並指示她願意支付的最高手續費是多少。

Bitcoin Core 會使用其現有的手續費估算功能，以及 Bitcoin Core 0.14.0 中引入的可選手續費提升功能，創建一個初始版本的交易給 Bob，支付預期在 10 個區塊內確認的交易的最低手續費。同時，Bitcoin Core 也會創建可能另外 9 個版本的交易，第一個使用 nLockTime 確保它直到從現在起兩個區塊才能被加入；第二個時間鎖定直到從現在起三個區塊；等等…

這些後續交易中的每一個都會支付比原始交易稍高的手續費（最高到 Alice 指示的最高手續費），以增加礦工挖掘該交易的激勵。

因為交易的所有版本都會在 Alice 發送初始交易時簽署，她只需要解鎖她的錢包一次。此外，因為交易的所有後續版本都會使用 nLockTime，Alice 可以無需信任地將這些交易的副本分發給其他人，以便在她離線的情況下稍後廣播。

簡而言之，如果必須的話，軟體會自動提供 Alice 的最高手續費，但如果可以的話會支付較低的手續費——確保 Alice 在不需要額外努力的情況下獲得盡可能接近最佳價格的費用。

結論

沒有明確的結論。據推測，開發者將專注於在即將到來的一週發布 0.14.0，然後將花更多時間討論 0.15 的目標。

Segwit 啟動後的 GetBlockTemplate 行為

註：這也是在前面的 rebase 議題期間討論的。

背景

Segwit 被設計為在 segwit 啟動後給予礦工一個選擇：

礦工可以像現在一樣生產舊式區塊，但這些區塊不能包含任何 segwit 交易（因此礦工可能會收到較少的交易手續費）。
礦工可以生產 segwit 式區塊並挖掘 segwit 交易，獲取任何額外的可用手續費。要做到這一點，單獨礦工和礦池營運商需要將他們的軟體更新到支援 segwit 的版本。

單獨礦工和礦池的軟體從 Bitcoin Core 的 GetBlockTemplate（GBT）遠端程序呼叫（RPC）獲取未確認交易列表和其他挖礦資訊。

Bitcoin Core 預設目前只允許礦工使用 BIP9 versionbits 發出支援 segwit 的信號，如果他們已經使用 GBT 對 segwit 相容的挖礦軟體進行了升級（或偽造）。然而，Bitcoin Core 預設也會在 segwit 啟動時停止為任何尚未升級到 segwit 相容軟體的礦工提供 GBT 結果；下面引用的會議評論解釋了為什麼做出這個選擇。

意見

Gregory Maxwell 開始討論：「我認為我們應該重新考慮 segwit 工作方式的一些事情：在 segwit 啟動後我們不會在沒有設定旗標的情況下進行挖礦，並且我們在沒有旗標的情況下不設定 versionbit。」

Suhas Daftuar 解釋：「我們這樣做是為了 segwit 不能在礦工實際上沒有挖掘 segwit 交易的情況下啟動。我的擔憂（在我們到達現在這個點之前）是 segwit 可能在 0 個礦工挖掘的情況下啟動，然後記憶池可能會被不會確認的交易攻擊。」

Maxwell 的回答是：「是的，但我認為那是個錯誤。所以如果他們不這樣做會怎樣？那麼最初 segwit 交易的容量就會較少，直到他們升級，他們會在手續費上損失。」

Alex Morcos 同意並補充：「只要我們知道有些礦工在挖掘它們，這似乎我們現在處於這個點。」Daftuar 也同意現在放寬安全條件，Matt Corallo 似乎也同意。

結論

沒有明確的結論，但會議參與者之間似乎普遍同意將 Bitcoin Core 更改為在 segwit 啟動時繼續挖掘有效的舊式區塊，對於那些不使用 segwit 旗標呼叫 GBT 的礦工。

CreateNewBlock 呼叫 TestBlockValidity 與否，以及 CreateNewBlock 快取

背景

Bitcoin Core 中為礦工組裝新區塊的主要函數稱為 CreateNewBlock（CNB）。作為向礦工提供創建區塊之前的最後一步，會呼叫一個 TestBlockValidity（TBV）函數，確保創建的區塊如果礦工找到所需的工作量證明，將是有效的——被其他節點接受。

Bitcoin 礦工 James Hilliard（Lightsword）已經開啟了一個 Pull Request（PR），從 CNB 中移除 TBV（#9858）和一個使其可選的替代 PR（#9859），解釋：「在這裡獲得無效模板永遠不應該發生，除非 bitcoind 內部有錯誤，所以這個 TestBlockValidity 呼叫只是一個內部健全性檢查」。

更多關於 TBV 的背景，請參見上面連結的議題中的討論。

意見

Pieter Wuille 建議這個議題，Gregory Maxwell 開始討論：「我們需要讓 TBV 脫離關鍵路徑。我不是很同意 Lightsword 對它的看法——我認為我們有一些程序測試我們正在交給礦工的區塊是很重要的。它不需要在關鍵路徑中。」

Alex Morcos 進一步解釋：「將它留在關鍵路徑中的缺點是額外 150 毫秒的空區塊挖礦。」

Pieter Wuille 列舉了選項：「一個簡單的（只是擺脫測試）；或一個困難的（後台驗證、快取、…）」

關於後台和快取的技術討論隨之而來，參與者贊成兩者，但還沒有明確的設計，因此可能需要更多討論。

Morcos 建議：「老實說，我認為更重要的方向應該是開始用更好的框架替換 GBT [GetBlockTemplate]。」Wuille 和 Maxwell 回答說，改變 TBV 的使用方式和 GBT 替換似乎是兩個獨立（正交）的議題；Morcos 同意但補充：「也許我的意思是我們應該設計更好的東西，這樣它就會告訴我們我們想要從 CNB/TBV 中得到什麼。並記錄設計，這樣我們就不會忘記…即使我們還沒有做到。」

沒有人反對實驗性設計，但似乎也沒有人對此熱衷。

討論轉向在接收到新區塊和驗證該區塊之間的短時間內進行無驗證挖礦的可能性。Morcos 描述了這如何工作：「從網路獲取新區塊 -> 假設有效 -> 標記記憶池中所有其交易為可能已使用 -> 從剩餘的 CNB -> 尚未驗證新頂端或 TBV 新模板，如果我們找到一個區塊，那就這樣吧。」

Maxwell 指出：「在那種情況下，你會延長一個無效區塊，這很糟糕（延長無效區塊非常糟糕，即使是相對短暫的間隔，因為它會大幅放大輕客戶端的風險——特別是因為挖礦設備可能會在舊工作上停留數十秒）。」

Matt Corallo 在想類似 Morcos 的東西：「我更傾向於不依賴驗證很快——在獲取區塊模板所需的 100 毫秒內挖掘空區塊，並在驗證期間轉發區塊。」

Maxwell 提到他寫的一個草案 BIP，以減少無驗證挖礦對輕客戶端安全的損害。Corallo 贊成：「我認為當我們回傳空區塊時，我們應該實作那個 :) 我很樂意在輕客戶端中實作它。」

此時討論回到技術細節，專注於挖礦軟體如何處理 Bitcoin Core 回傳的空區塊以及礦池軟體回傳的空區塊。

結論

沒有明確的結論。所有在場的開發者似乎都致力於改善情況，但沒有人直接贊成 #9858 或 #9859 中的解決方案。會議後約 10 分鐘，這些 PR 的作者在 IRC 上變得可用，並開始與開發者討論可以進行的潛在短期優化，同時進行更重要（但長期）的工作。

議題：（空白）

在前面關於在急需結果時生成空區塊模板的對話期間，Pieter Wuille 提醒大家會議只剩 5 分鐘用於其他議題，導致 Gregory Maxwell 匆忙建議「空訊息」的議題。關於這個議題的整個討論在下面的幽默時刻部分轉述。

幽默時刻

<sipa> we're running out of time
       any other topics?

<gmaxwell> quick, empty messages

<sipa>

<luke-jr>

<wumpus>

<gmaxwell>

<luke-jr> inb4 trolls use this as proof we obey gmaxwell

<gwillen>

<BlueMatt> lulwut

<wumpus> #topic

<sipa> it's "lolwut", BlueMatt.

<BlueMatt> lulzwutz

<wumpus> cleared the topic, too, now we can cleanly exit the meeting

<gmaxwell> We should appoint a subcommittee to investigate the spelling of lolwut/lulwut.

<wumpus> #endmeeting

參與者

IRC nick	Name/Nym
gmaxwell	Gregory Maxwell
sipa	Pieter Wuille
BlueMatt	Matt Corallo
morcos	Alex Morcos
wumpus	Wladimir van der Laan
sdaftuar	Suhas Daftuar
luke-jr	Luke Dashjr
MarcoFalke	Marco Falke
gwillen	Glenn Willen
kanzure	Bryan Bishop

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。

IRC meeting summary for 2017-02-23

Thu, 23 Feb 2017 00:00:00 +0000

概覽

主要議題

Git 和 SHA1 碰撞
Bitcoin Core 0.14.0 發布
Travis CI 問題
程式碼重組

Git 和 SHA1 碰撞

背景

在會議開始前幾個小時，幾位研究人員宣布他們首次產生了兩個不同檔案在使用 SHA1 雜湊函數時具有相同雜湊的案例（這種情況稱為雜湊碰撞）。

Bitcoin Core 和許多其他專案使用的 Git 版本控制系統使用 SHA1 雜湊來允許人們確保他們都擁有完全相同的程式碼。產生 SHA1 碰撞的能力破壞了這種保證。

多年來，安全社群的許多成員一直要求 Git 從 SHA1 更改為 SHA256 或另一個更安全的雜湊函數，但 Git 開發者強烈抵制這種變更（可能是因為它不向後相容，這意味著所有 Git 使用者可能需要在大致相同的時間升級）。

「我想知道建立一個回溯歷史的覆蓋層有多困難，為每個樹和提交計算 sha256，然後包含對這些的 gpg 簽名？」（Pieter Wuille）
「我們可以更新我們的開發腳本，對所有提交的檔案執行 sha256sum 並對其進行簽名 […] 例如，合併腳本可以在提交訊息中包含 sha256sum * 的雜湊」（Matt Corallo）。Gregory Maxwell 在大約同一時間提出了非常類似的建議。
「我有一個 git 的修補程式，使用 [sha1collissiondetect] 作為雜湊函數，如果它檢測到可能不良的雜湊就 abort()。」（Matt Corallo）

結論

沒有達成明確的結論，但推測開發者將調查上述提出的部分或所有解決方案，同時 Git 開發者也在努力升級他們的程式。

Bitcoin Core 0.14.0 發布

注意，這個標題涵蓋了會議中的兩個相關主題，(1)「幫助 cfields 新增效能相關的發布說明」和 (2)「RC2 狀態」。

背景

Bitcoin Core 0.14.0 的第一個候選版本（RC1）在上週會議後發布。沒有發現重大問題，但仍有一些小修復和功能需要合併。

0.14.0 中的許多主要升級都是效能改進。

會議評論

Wladimir van der Laan 要求在場的人建議量化效能改進的方法，以便 Cory Fields 可以執行任何建議的測量並將結果新增到 PR#9787 的發布說明中。

Gregory Maxwell 建議：「使用上一個版本同步需要 N 小時，使用新版本同步需要 Y 小時。」

Fields 同意：「好的，我會新增一個模糊的 0.13 與 0.14 同步時間。不過 0.13 需要時間，我還沒有耐心完成一次。」

Jeremy Rubin 建議使用 Amazon EC2 作為測試環境，但 Wladimir van der Laan 警告：「EC 不是一個好的比較環境：I/O 非常慢」。Fields 回答說：「我使用 EC 進行同步基準測試，因為我認為它代表了一個非常典型的使用案例。」

討論轉向第二個候選版本（RC2），除了次要翻譯更新和 PR#9829 之外，似乎已準備好在 Git 中標記，後者已準備好合併但 Travis 持續整合（Travis CI）測試失敗。

結論

Cory Fields 將在 EC2 上執行初始同步測試（此後已完成，Bitcoin Core 0.14.0 在初始同步時的效能比 Bitcoin Core 0.13.2 快 5.7 倍）。PR#9829 的測試在其作者 Russell Yanofsky 表示他認為測試失敗是由於間歇性的 Travis CI 問題後重新啟動。

會議結束後，RC2 被標記。

Travis CI 問題

背景

Bitcoin Core 開發使用 Travis CI 測試平台對每個 Pull Request (PR) 執行專案的測試。測試僅在 PR 中的程式碼有問題時才會失敗，但有時測試會因與 Travis CI 相關的原因而失敗。過去這些問題包括 Travis 上的錯誤以及 Bitcoin Core 達到 Travis 的資源限制。

結論

繼續調查失敗，隔離問題並努力修復它。

程式碼重組

背景

許多經濟全節點使用 Bitcoin Core 來強制執行共識規則。其他程式將受益於重用 Bitcoin Core 用於確保它們符合共識規則的相同程式碼，因此幾位開發者一直在努力使 Bitcoin Core 程式碼庫更加模組化，以便其部分可以在其他程式中使用。

儘管使程式碼庫更加模組化的目標得到了專案貢獻者的充分支援，但實際移動程式碼往往會破壞其他開發者的待處理變更，並消耗專家審查 Bitcoin Core 變更的有限時間—同時不提供新功能或效能改進。這使得程式碼移動成為團隊討論的好主題，以便可以提前商定變更，以盡量減少干擾。

結論

會議期間沒有明確的結論（會議在這個主題上沒時間了）。會議結束後討論繼續進行，Maxwell 和 Wladimir van der Laan 擴展了他們的觀點。

趣聞

<jonasschnelli> or syncs are roughly XYZ% faster...
<jonasschnelli> use the ~ and nobody will blame you afterwards. :)

<jeremyrubin> use two ~~ to be extra approximate

<wumpus> it's marketing not science :p hehe

<gmaxwell> but ~~ will just give you the same number you put in!

<jeremyrubin> The is-approximately operator is non-involutive ;)

<gmaxwell> Well people just have no general idea of the impact. Marketing would be saying that it's 2x faster rather than 3x faster because 2x is more plausible. :P

<gmaxwell> sipa: e.g. someday libstdc++ could get something that generalizes prevector, if it did, we'd drop prevector and use that.

<sipa> c++23

<gmaxwell> sipa: C++23 will just integrate libconsensus of course. template cryprocurrency.

參與者

IRC nick	Name/Nym
achow101	Andrew Chow
BlueMatt	Matt Corallo
btcdrak	BtcDrak
cfields	Cory Fields
gmaxwell	Gregory Maxwell
jeremyrubin	Jeremy Rubin
jnewbery	John Newbery
jonasschnelli	Jonas Schnelli
jtimon	Jorge Timón
kallewoof	Karl-Johan Alm
kanzure	Bryan Bishop
luke-jr	Luke Dashjr
MarcoFalke	Marco Falke
morcos	Alex Morcos
petertodd	Peter Todd
ryanofsky	Russell Yanofsky
sdaftuar	Suhas Daftuar
sipa	Pieter Wuille
wumpus	Wladimir van der Laan

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-02-16

Thu, 16 Feb 2017 00:00:00 +0000

概覽

主要議題

0.14.0RC1 發布
隨機性
時鐘

0.14.0RC1 發布

背景

Bitcoin Core 0.14.0 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

會議評論

普遍認為發布準備度在過去兩週內顯著改善，第一個候選版本（RC1）可以在今天或未來幾天內發布。然而，仍有一些 Pull Request (PR) 即將完成審查，許多會議參與者希望在最終 0.14.0 版本中看到這些內容，因此在這個版本的發布流程中肯定會有至少第二個候選版本。

Andrew Chow 問道：「如果我們無論如何都需要 RC2，那麼發布 RC1 的意義是什麼？」幾個人回答了諸如「曝光」、「開始讓人們使用它」和「讓程式碼實際測試」等答案。Gregory Maxwell 對這些回覆進行了擴展：「我們通常不想做的是發布一個有嚴重問題的 RC1，這會嚴重傷害測試者，或者會以神秘方式失敗，讓我們無法從中學習。例如，如果我們有一個已知的崩潰修復，我們會保留 rc1，這樣我們就不會擔心每個使用者崩潰報告可能是一個未知問題。」

討論繼續進行，關於一個尚未完成的候選版本是否需要特殊標籤，但沒有人強烈推動這樣做，這個想法被放棄了。

暫定時程表是：「Wladimir van der Laan 將在明天早上釋出 RC1。如果今晚我們能說服人們合併其中一些東西，那將為 RC2 留下更少的工作。」

提議在審查後合併到 RC1 程式碼庫或 RC2 程式碼庫的 PR 包括：

#9760 - [wallet] 由 ryanofsky 移除 importmulti 始終為真的檢查（由 Alex Morcos 提議，Jonas Schnelli 和 Gregory Maxwell 附議）
#9761 - 由 ryanofsky 在 importmulti 重新掃描中使用 2 小時寬限期處理金鑰時間戳（由 Alex Morcos 提議，Jonas Schnelli 和 Gregory Maxwell 附議）
#9773 - WIP：如果完整重新掃描不成功，從 importmulti 返回錯誤（在 #9761 之上）由 ryanofsky
#9619 - 錯誤修復：RPC/挖礦：在隔離見證啟動之前，GBT 應返回 1 MB 大小限制，由 luke-jr（由 Jorge Timón 提議，在會議結束時討論更多）

結論

在未來幾天內發布 RC1，並將任何剩餘的修補程式納入 RC2。

隨機性

背景

Pieter Wuille 提議並透過描述當前狀態開啟了主題：「我們目前有 3 個『等級』的隨機性：fastrandomcontext、getrandbytes、getsecurerandbytes。我希望只有 2 個。」

FastRandomContext：目前需要 1.5 奈秒，但不是密碼學安全的偽隨機數生成器（CSPRNG）。
GetRandBytes：一個 CSPRNG。
GetStrongRandBytes：「用於私鑰。如果一切順利，它與 getrandbytes 一樣安全，但它更偏執，」Wuille 解釋道。

GetStrongRandBytes 可以繼續用於「像長期金鑰這樣的事情，我們不經常做，基本上沒有成本太高，並且 [它] 必須滿足我們能想像到的基本上每個安全特性，」Greg Maxwell 說。例如，它可以混合來自多個來源的熵（隨機性），即使是相當慢的來源，因為它相對慢是可以的。

結論

問題主要集中在理解 Wuille 的計劃上，沒有人反對 Wuille 嘗試計劃的第一部分，即更新 GetRandBytes 以使用 ChaCha20。

時鐘：不可轉換的時間

這是在「時鐘」主題下討論的兩個不同時間相關主題中的第一個。

背景

Pieter Wuille 解釋了問題：「我想解決的是 int 或 int64 現在可以表示微秒、毫秒或秒，以及系統時間、單調時間或網路調整時間的事實。它們是類似 int 的是可以的，但它們不應該可以從一個轉換為另一個。」

Gregory Maxwell 描述了為什麼這很重要：「我們多次因隱式轉換的一般問題而出現潛在嚴重的錯誤。（或者在 sighash single 的情況下，實際的共識行為缺陷。）所有資料都在編譯中以防止這些錯誤，我們只是沒有正確地公開它。:)」

Cory Fields 提議並開啟了主題：「我有一些本地變更，實作了不同時鐘/時間點/持續時間的概念。目標是讓它們彼此不相容。目標是停止將時間儲存為 int，而是儲存為 time_value—這樣它可以在需要時以秒/毫秒/任何形式表示，它還強制執行不能在錯誤的時鐘上使用的時間戳。」

似乎沒有人不同意這個目標，討論集中在實作細節上。

結論

Cory Fields 和 Pieter Wuille 將在會議之外更深入地討論細節。（如果您感興趣，討論在會議之後立即繼續。）

時鐘：單調時間戳

這是在「時鐘」主題下討論的兩個不同時間相關主題中的第二個。

背景

單調時鐘是時間永不減少的時鐘。基於本地電腦時間（系統時間）的時鐘不是單調的，因為系統時間偶爾會向後調整。

比特幣的共識要求每個區塊必須具有大於區塊鏈上前 11 個區塊的中位時間戳的時間戳，從而提供單調時鐘（注意：有此處未討論的限制）。

結論

沒有結論。

小主題

重新排列與測試相關的事項

描述了對測試的次要變更願望清單：

Jonas Schnelli 提議重新命名一些目錄，以幫助 GitHub 使用者新進專案的人找到最有用的測試。
Pieter Wuille 建議進行一些額外的重新排列，透過分解出為不再使用的測試工具新增的目錄來提高生產力。
Gregory Maxwell 建議將一些更耗時的測試作為標準編譯序列的一部分執行。
Wladimir van der Laan 抱怨 RPC 測試的命名錯誤，因為它們今天測試的不僅僅是 RPC 介面（許多測試使用 RPC 介面來測試系統的其餘部分是否按預期運作）。

Schnelli 自願在 0.14 分割到單獨的 git 分支後建立一個 pull request 到主分支。

趣聞

<morcos> i think it is a mistake to call it experimental
<morcos> we don't want to devalue the meaning of that word

<wumpus> ok...

<morcos> sometimes we may want to have things that are actually experimental and we don't want people to think we just always say that

<wumpus> "this feature is experimental level 4"

<morcos> this is known to the state of CA to be experimental

<sipa> i'd briefly like to talk about randomness

<luke-jr> that's random.

<sipa> we currently have 3 "levels" of randomness

<wumpus> we need a random number of levels of randomness

參與者

IRC nick	Name/Nym
achow101	Andrew Chow
cfields	Cory Fields
CodeShark	Eric Lombrozo
gmaxwell	Gregory Maxwell
instagibbs	Gregory Sanders
jonasschnelli	Jonas Schnelli
jtimon	Jorge Timón
kanzure	Bryan Bishop
luke-jr	Luke Dashjr
morcos	Alex Morcos
paveljanik	Pavel Janik
petertodd	Peter Todd
sipa	Pieter Wuille
wumpus	Wladimir van der Laan

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-02-09

Thu, 09 Feb 2017 00:00:00 +0000

概覽

主要議題
0.14 RC1 發布
趣聞
參與者
免責聲明

主要議題

0.14 RC1 發布

0.14 RC1 發布

背景

Bitcoin Core 0.14 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

RC1 預計於 2017 年 2 月 6 日發布。

會議評論

有一些網路相關問題延遲了 RC1 發布。包含修復的開放 PR 有 #9698（修復 socket 關閉競爭條件）、#9715（斷開我們在 60 秒內未收到 VERACK 的對等節點）、#9720（修復封禁並禁止在收到 verack 之前發送訊息）和 #9708（清理所有已知的競爭條件/平台特定的未定義行為）。後者並非嚴格必要，但使測試其他修復變得更容易。透過解決網路程式碼中所有已知的競爭條件，即使是無害的，它允許我們開始使用 CI 工具來避免引入新的競爭條件。

Sipa 注意到靜態種子 IP 列表尚未針對 0.14 更新，這通常在每個主要版本之前完成。

release-process.md 中目前沒有提到更新 chainTxData（用於進度估算）以獲得更準確的交易計數估算。這些常數在最近的 #9472（將進度估算與檢查點分離）中更新，對於 0.14 仍然準確。Sipa 將編寫一個腳本來計算未來版本的新 chainTxData 常數。

Issue #9392（錢包祖先完整性檢查忽略 sigops）仍然標記為 0.14，但不是高優先順序。所有其他 issue 都有針對它的開放 PR。

Achow101 在發布說明中增加了很多內容，現在只有 2 件事需要勾選。

發布說明目前建議希望保留挖礦「優先順序」排序的礦工執行 Bitcoin Knots。推薦未經本專案開發者審查的其他分支沒有太大意義。Gmaxwell 認為推薦相容的分支來支援我們不關心支援的功能是可以的，但他認為我們不應該推薦使用優先順序。

會議結論

更新靜態種子 IP 列表
更新 release-process.md 以包含 chainTxData 更新
取消 issue #9392 的 0.14 標記
完成發布說明
從發布說明中移除 Bitcoin Knots 推薦

趣聞

wumpus           if it's manual work, it's probably going to be skipped for most minor releases
wumpus           heck, we forget to update the version numbers half the time :-)

jtimon           maybe just a question in a faq or something? "we don't recommend using prioirty, but if you miss it, there's knots at..."
gmaxwell         jtimon: infrequently asked questions
gmaxwell         never asked questions

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
cfields	Cory Fields
wumpus	Wladimir van der Laan
jtimon	Jorge Timón
MarcoFalke	Marco Falke
achow101	Andrew Chow
gmaxwell	Gregory Maxwell
sdaftuar	Suhas Daftuar

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-02-02

Thu, 02 Feb 2017 00:00:00 +0000

概覽

主要議題
0.14 RC1 發布
程式碼風格
趣聞
參與者
免責聲明

主要議題

0.14 RC1 發布
程式碼風格

0.14 RC1 發布

背景

Bitcoin Core 0.14 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

RC1 預計於 2017 年 2 月 6 日發布。

會議評論

BlueMatt 認為 #9671（修復極不可能的競爭條件）將是發布所必需的。

Issue #9027（無限制的重組記憶體使用）應該推到 0.15，因為它不是退化。它比以前稍微差一點，但還不足以我們絕對需要立即修復它。

importmulti 變更可以在 0.14 之後完成，或者如果不夠安全及時，可以在發布時停用。它也可以不記錄，但這需要修復 issue #9491（Importmulti API 令人困惑，可能導致資金損失）。

會議結論

在 issue 本身討論 importmulti 問題（#9491）

程式碼風格

背景

程式碼的風格一致性有一些好處：

它有助於新來者的貢獻，因為這讓他們更容易確保他們的工作在風格方面是可以的。
它簡化了審查，因為統一性創造了更好的期望，然而重新格式化會使查看歷史記錄更加困難，這損害了審查。
良好的風格選擇有時已被證明可以降低軟體的缺陷率，但對於哪些選擇是好的並沒有普遍的意見。

自 C++11 以來，可以使用「auto」指定符。它指定正在聲明的變數的型別將從其初始化器自動推導。

會議評論

BlueMatt 認為使用「auto」使某些審查更加困難，因為他經常搜尋「X 被使用的所有地方」。Sipa 提出了一個解決方法，透過對型別進行不相容的變更並重新編譯，以便使用它的所有地方都變得可見。討論從這裡開始。

Wumpus 建議記錄使用「auto」不好或危險的特定情況。

使用 auto 的優點，除了它取代了大量要輸入的文字之外，是當你將元組變成結構或新增包裝器時，你不需要到處更改東西。

Gmaxwell 補充說另一個負面方面是 auto 使你能夠在對型別毫不知情的情況下編寫對型別起作用的程式碼，這在 99% 的情況下是安全的，其餘情況則是致命的，因為在 C++ 中，並非所有在型別上分類不安全的操作實際上都被型別檢查阻止。儘管這是一個邊緣情況，但這是需要記住的。

當你有一些可怕的複雜簽名時，Auto 很有趣，但這些也是更成問題的情況。Sipa 指出，這些使用案例的最佳實踐是為其引入 typedef，這也缺少 BlueMatt 的審查擔憂。

會議結論

逐案考慮「auto」的使用。

趣聞

wumpus         #startmeeting
BlueMatt       oh thats today?
luke-jr        BlueMatt: no, it's fake news.
wumpus         BlueMatt: it's thursday I hope?
sipa           luke-jr: alternative news
BlueMatt       wumpus: alternative facts

wumpus         foremost topic would be what to still include in 0.14, as rc1 release is planned for monday
gmaxwell       I propose not including any bugs.

wumpus         no other topics?
wumpus         I had expected heated debates on what to include last-minute in 0.14 and why to delay the rc, what a disappointment! </s>
BlueMatt       wumpus: I vote we push it back a month so we can do all the things we wanted to a month ago :p

BlueMatt       wait, i had something to talk about re: cde style
gmaxwell       BlueMatt: die
sdaftuar       i'll get the baseball bat

wumpus         gmaxwell: it's *easy* but the point is to avoid unnecessary verbosity/typing, not so you can forget the type
BlueMatt       wumpus: I'm generally 100% in favor of extra verbosity
gmaxwell       fking java programmers. :P
wumpus         BlueMatt: go use java
BlueMatt       lol, i expected that....

wumpus         #endmeeting
gmaxwell       wumpus: your request is a little explicit, you could have just said... for auto meetingstep.

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
BlueMatt	Matt Corallo
cfields	Cory Fields
wumpus	Wladimir van der Laan
jtimon	Jorge Timón
MarcoFalke	Marco Falke
achow101	Andrew Chow
gmaxwell	Gregory Maxwell
luke-jr	Luke Dashjr
sdaftuar	Suhas Daftuar

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-01-26

Thu, 26 Jan 2017 00:00:00 +0000

概覽

主要議題
程式碼風格
0.14 的錯誤修復
我們對中繼收費是否足夠？
參與者
免責聲明

主要議題

程式碼風格
0.14 的錯誤修復
我們對中繼收費是否足夠？

程式碼風格

背景

程式碼的風格一致性有一些好處：

它有助於新來者的貢獻，因為這讓他們更容易確保他們的工作在風格方面是可以的。
它簡化了審查，因為統一性創造了更好的期望，然而重新格式化會使查看歷史記錄更加困難，這損害了審查。
良好的風格選擇有時已被證明可以降低軟體的缺陷率，但對於哪些選擇是好的並沒有普遍的意見。

會議評論

我們目前不要求人們堅持特定的程式碼風格，這導致人們想知道在哪裡使用哪種風格。目前模仿周圍程式碼的建議實際上無助於使程式碼庫收斂。

如果我們都在每個修補程式上使用 clang-format，最終我們會收斂。Clang-format-diff.py 是一個自動執行此操作的工具。

Jonasschnelli 曾經提議在 Travis 之外進行 CI 檢查，以檢查 clang 風格，但每個人都反對。BlueMatt 反對 CI 檢查，但贊成使用機器人自動開啟 PR，修復最近損壞的 PR 的 clang 風格。Wumpus 不希望僅僅因為風格問題而延遲 PR。

僅移動的提交可能不應該更改風格，否則將更難審查它是否真的只是移動。

Gmaxwell 的經驗是，像程式碼風格挑剔這樣的小事會改善開發團隊的士氣。這是一個互相幫助的機會，非常簡單明確，而不是「請完全重新設計你的修補程式」。

會議結論

能夠在 PR 中指出與風格指南衝突的風格問題。
盡可能在提交修補程式之前使用 Clang-format-diff.py。
不要在僅移動的提交中更改風格

0.14 的錯誤修復

背景

Bitcoin Core 0.14 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

會議評論

Morcos 指出他的 #9615（錢包增量手續費）需要 0.14 標籤，sdaftuar 有一兩個小修復即將到來。#9615 分離了錢包的預設增量值和中繼預設增量手續費，這是防止如果 incrementalRelayFee 增加時 bumpfee 出現問題所必需的。

目前 0.14 的開放 PR 有：#9638 #9626 #9622 #9609 #9589 #9108

在 0.14 中將發布 bumpfee。Gmaxwell 提議查看 GreenAddress 和 Electrum 正在做什麼，因為他們都在生產環境中有 bumpfee，看看他們是否發現了我們遺漏的任何東西。他自願檢查 GreenAddress。

會議結論

標記 #9615（錢包增量手續費）

我們對中繼收費是否足夠？

背景

目前「incrementalRelayFee」，它設定記憶體池限制或選擇性手續費替換替換的最低費率增加，設定為每位元組 1 聰。

Morcos 認為這太低了，網路中繼交易的「成本」高於每位元組 1 聰，並且對 bumpfee 和記憶體池限制有那麼高的精度沒有足夠的好處。

會議評論

當聽到 petertodd 談論他如何循環按 bumpfee 時，Morcos 意識到我們允許對 1 個被挖掘的交易進行太多中繼。有兩種方法可以改進：提高「incrementalRelayFee」，並使我們自己的程式碼的行為在預設情況下不會導致這種荒謬的中繼迭代，如果人們想要進行定期增量。

Gmaxwell 認為提高限制會切斷在不太瘋狂的時間內確認的交易，因此中繼成本不會太高。BlueMatt 補充說，他上週末很容易確認了每位元組 0.1 聰的交易，並認為現在討論提高它為時過早。

Gmaxwell 還指出，在有記憶體池限制之前和 createNewBlock 快速之前，礦工提高 minRelayTxFee 的一些遺留問題。因此，在得出每位元組 1 聰不會確認的結論之前，首先重新命名參數以使人們重新考慮或返回預設值可能是明智的。此外，隔離見證可能會使手續費行為回到功能失調的狀態。

會議結論

在發布說明中宣布 minRelayTxFee 將被重新命名，並鼓勵人們移除它。

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
kanzure	Bryan Bishop
BlueMatt	Matt Corallo
cfields	Cory Fields
wumpus	Wladimir van der Laan
morcos	Alex Morcos
jtimon	Jorge Timón
MarcoFalke	Marco Falke
achow101	Andrew Chow
gmaxwell	Gregory Maxwell
paveljanik	Pavel Janik

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-01-19

Thu, 19 Jan 2017 00:00:00 +0000

概覽

主要議題
功能凍結 0.14 前的最後合併
錢包同步問題
0.14 的最終警報
趣聞
參與者
免責聲明

主要議題

功能凍結 0.14 前的最後合併
錢包同步問題
0.14 的最終警報

功能凍結 0.14 前的最後合併

背景

Bitcoin Core 0.14 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

會議評論

#9535（分割 CNode::cs_vSend：訊息處理和訊息發送）得到了一些徹底的審查，將是一個巨大的勝利。

#9461（改進進度顯示）已準備好，#9294（HD 分割）需要另一次審查。它有字串變更，因此需要在功能凍結之前完成以便進行翻譯。

Gmaxwell 認為 #9526（-blocksonly 應停用與 dbcache 共享記憶體池）應該取消 0.14 標記。BlueMatt 和 Sipa 認為這是錯誤修復，因此可以在功能凍結後合併。

0.14 的優先事項是解決剩餘的棘手問題，例如錢包同步問題。

BlueMatt 注意到 #9108（匯入僅觀察金鑰時使用 importmulti 時間戳）需要 0.14 標籤，因為它修復了標記為 0.14 的 issue #9034。

BlueMatt 可以接受取消 #9027（無限制的重組記憶體使用）的 0.14 標記。有人指出我們可以做一個簡單的修復來解決這個問題，但還有其他問題使得完全修復它並不簡單。

會議結論

審查 #9294（使用內部 HD 鏈進行找零輸出（hd 分割））

錢包同步問題

背景

自 #7946 以來，Bitcoin Core 在將區塊中連接的交易與錢包同步時不持有 cs_main。已經有幾個問題，其中至少有 2 個仍然存在，總結在 issue #9584 中。

會議評論

BlueMatt 嘗試修復 issue #9148，但結果比預期更複雜。他建議 0.14 採用 #9583（將錢包回呼移入 cs_main（這有效地還原了 #7946）），並在 0.15 進行一系列更大的變更。他對 0.15 的意圖是將這些回呼移到背景執行緒中。

會議結論

審查 #9583 作為 0.14 的解決方案

0.14 的最終警報

背景

比特幣警報系統是受信任方向所有 Core 客戶端廣播有關關鍵網路問題的訊息的一種方式。自 Bitcoin Core 0.13.0 以來已被移除，並且已停用一段時間。

警報系統退役的最後一步是將節點硬編碼為向對等節點發送最終警報，以克服缺乏傳播的問題。

會議評論

現在是發送最終警報的好時機。鑑於之前的警報，不需要延遲或公告。

會議結論

發送最終警報訊息（PR #9594）

趣聞

luke-jr         there's a pre-MW PR that's probably ready, but not a prioirty
sipa            pre-mimblewimble?
luke-jr         multiwallet ;)

wumpus          let's just do it
petertodd       wumpus: <insert meme here>

sipa            https://cdn.meme.am/cache/instances/folder963/500x/74859963.jpg

wumpus          ok, any other topics?
sipa            i propose lunch

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
kanzure	Bryan Bishop
BlueMatt	Matt Corallo
cfields	Cory Fields
luke-jr	Luke Dashjr
wumpus	Wladimir van der Laan
morcos	Alex Morcos
jtimon	Jorge Timón
petertodd	Peter Todd
MarcoFalke	Marco Falke
CodeShark	Eric Lombrozo
btcdrak	BtcDrak
achow101	Andrew Chow
gmaxwell	Gregory Maxwell

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-01-12

Thu, 12 Jan 2017 00:00:00 +0000

概覽

主要議題
0.14 功能凍結
趣聞
參與者
免責聲明

主要議題

0.14 功能凍結

0.14 功能凍結

背景

Bitcoin Core 0.14 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

會議評論

0.14 的功能凍結預定於 2017 年 1 月 16 日星期一。

PR #9499（使用 recent-rejects、orphans 和 recently-replaced txn 進行緊湊區塊重建）、#9375（在完整區塊連接之前中繼緊湊區塊訊息）和 #9441（大幅加速。網路鎖重構）可能足夠接近可以趕上。

多錢包至少還需要 2 個 PR，並且不是可以在最後一刻安全合併並讓人們在候選版本中測試的東西。

錯誤修復仍然可以在星期一之後加入。BlueMatt 認為 #9519（從手續費估算中排除 RBF 替換交易）和 #9512（修復 -fsanitize 投訴的各種問題）是應該加入的錯誤修復。Wumpus 擔心後者的這些變更在雜湊上會造成 +/- 1.5% 的效能損失。Sipa 認為他有一個版本可以修復問題而不會降低效能（甚至有非常輕微的效能提升）。

#9484（引入 assumevalid 設定）是一種無需使用檢查點即可跳過腳本驗證的方法，也很希望能加入。

Morcos 認為也應該考慮在 0.14 中加入 #9380（分離最低手續費的不同用途），因為目前如果礦工更改 -minrelaytxfee，它會自動更改他們對粉塵的定義，這偶爾會導致具有高費率的交易無法被部分礦工挖掘。這也損害了手續費估算，這可能更嚴重。

BlueMatt 想知道是否應該取消某些 PR 的 0.14 標記，例如 #8456、#8501、#8654、#8723 或 #8755。

Jonasschnelli 希望看到 #9294（使用內部 HD 鏈進行找零輸出）以及 #9377（fundrawtransaction：預設保留找零輸出金鑰），但後者是錯誤修復，可以稍後加入。前者可以避免建立更多單鏈 HD 錢包，因此越早加入越有價值。缺點是新建立的錢包無法在 0.13、0.14 版本的舊軟體上使用，可能包括將引入彈性金鑰路徑的 0.15。只要新版本接觸過的錢包不會自動使其不相容，每個人都可以接受。

Jonasschnelli 認為 #9461（改進進度顯示）是一個簡單的變更，可以加入 0.14。

BlueMatt 意識到他忘記了 cs_vSend split，它包含在 #9419（停止使用 cs_main 處理 CNodeState/State()）中，但本身就是一個巨大的勝利。

會議結論

0.14 不做多錢包
審查 #9484、#9380、網路相關：#9499、#9375、#9441 和錢包相關：#9294、#8456
取消標記 #8501、#8654、#8723 和 #8755

趣聞

jonasschnelli    The sad thing is, it will be another feature that is not downward compatible.
sipa             breaking backward compatibility in major releases is fine
wumpus           don't you mean forwards compatible? backwards compatible means that it can use old wallets, which should always be possible
jonasschnelli    wumpus: right. My fault.
sipa             backward compatible means that old software can use new wallets
jonasschnelli    perspective thing. :)
wumpus           huh? I thought the other way around.
sipa             forward compatible is what you normally always have
wumpus           I don't understand it anymore then
sipa             oopz
sipa             maybe i am wrong too
sipa             i will shut up
jtimon           all these backwards and forwards compatibility is confusing, softfork and hardforks are much more clear :p

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
kanzure	Bryan Bishop
BlueMatt	Matt Corallo
cfields	Cory Fields
jl2012	Johnson Lau
luke-jr	Luke Dashjr
wumpus	Wladimir van der Laan
morcos	Alex Morcos
jtimon	Jorge Timón
petertodd	Peter Todd
MarcoFalke	Marco Falke
sdaftuar	Suhas Daftuar
CodeShark	Eric Lombrozo
btcdrak	BtcDrak
Michagogo	Michagogo
achow101	Andrew Chow

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2017-01-05

Thu, 05 Jan 2017 00:00:00 +0000

概覽

筆記／短主題
主要議題
分叉警告系統修復
0.14 審查優先順序
趣聞
參與者
免責聲明

筆記／短主題

Jonasschnelli 建立了 2016 年 Git 視覺化的草稿影片。

主要議題

分叉警告系統修復
0.14 審查優先順序

分叉警告系統修復

背景

大工作量分叉警告系統（應該在具有足夠工作量證明的分叉持續被挖掘時警告使用者）目前在 header first 驗證下已損壞。

Jl2012 正在研究此問題的修復方案。

會議評論

Jl2012 詳細說明這不僅僅是修復，它會儲存無效區塊下的有效標頭，只要有有效的工作量證明和有效的 nTime。

Gmaxwell 對警告系統的實用性表示懷疑：已經有太多誤報，而且大多數人一開始就沒有有效使用它。BlueMatt 指出，擁有可靠的警告系統是修復系統信任度的第一步。

Sipa 想知道我們是否需要檢測內部共識錯誤，例如資料庫損壞、CPU 過熱等，因為實際上看到的 99.99% 分叉警告只是節點故障。

沒有人認為此變更對 0.14 來說很重要。

會議結論

更專注於 0.14 的關鍵變更

0.14 審查優先順序

背景

Bitcoin Core 0.14 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

會議評論

如果審查工作不是瓶頸，人們希望在 0.14 中看到的內容：

Wumpus 希望看到具名參數。

BlueMatt 認為平行 ProcessMessages 對某些使用案例來說是巨大的改進，但如果沒有足夠的時間審查，他會跳過 0.14。

Jtimon 希望加入自訂區塊鏈，但懷疑這是否現實。為了效率，此最佳化可能有幫助，但沒有人有時間進行基準測試。

Luke-jr 指出有人希望看到多錢包 PR（#8775 和 #8694），以及忽略/覆寫拒絕，但它們沒有標記 0.14 里程碑。

Morcos 希望看到區塊中繼改進（#9375、#9441 和 #9447），並可能加入平行 ProcessMessages。#9441 有很多提交，但大多數都很小，以便於審查。

Gmaxwell 希望看到多錢包支援（PR #8775 和 #8694）和 UTXO scriptpubkey 索引，儘管後者似乎已被請求者放棄。此外，Morcos 的 CreateTransaction 變更可以修復一些令人擔憂的手續費超額支付邊緣情況，這也很好。

Jonasschnelli 認為 HD chain split 也應該進入 0.14，加上某種形式的 HD 重新掃描。

已經有很多工作要做，並且至少有 4 個阻礙 0.14 的退化問題（issues #9479、#9027、#9148 和 #9212）。Morcos 指出，如果 #9371（修復 issue #9479）無法進入 0.14，我們需要還原 #9240。

會議結論

專注於手續費修復（#9404）、網路鎖重構（#9441）、具名參數（#8811）、早期緊湊區塊中繼（#9375、#9441 和 #9447），以及較低優先順序的多錢包變更（#8775 和 #8694）。

趣聞

jonasschnelli       Fun topic: 2016 Git Visualisation: I'd created a draft video, need feedback to overhaul it and place it on the bitcoincore.org website.
jonasschnelli       https://vimeo.com/198242328
jonasschnelli       Password coredev
jonasschnelli       (will be there for a couple of mins)
luke-jr             jonasschnelli: why password protect it and post the password in public? :P
jonasschnelli       Security by obscurity.
petertodd           luke-jr: MILITARY LEVEL BLOCKCHAIN SECURITY

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
kanzure	Bryan Bishop
BlueMatt	Matt Corallo
cfields	Cory Fields
phantomcircuit	Patrick Strateman
jl2012	Johnson Lau
luke-jr	Luke Dashjr
wumpus	Wladimir van der Laan
morcos	Alex Morcos
jtimon	Jorge Timón
petertodd	Peter Todd

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。

2016-12-22 IRC 會議摘要

Thu, 22 Dec 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
0.14 功能
WitnessMerkleBlocks
幽默時刻
參與者
免責聲明

本週會議記錄連結
meetbot 會議紀錄不可用

備註 / 簡短議題

Bitcoin Core 0.13.2 候選版本 1 可供測試。
Jl2012 請大家閱讀並可能回應他的 BIP 提案。
現在 BIP2 已經啟用，發布一些 BIP 評論會很好。背後的想法是為使用者提供一個中心位置來區分不建議和推薦的 BIP。有關格式和程序的更多資訊可以在「BIP 評論」部分找到。
sipa 自從上週會議以來，對每交易輸出 UTXO 快取方法進行了更多測試。結果顯示，在早期的基準測試中留下了一些除錯程式碼，導致每個 txin 都進行資料庫讀取，這嚴重影響了性能。現在初始區塊下載大約快 30%。未來還預期會有進一步的加速，所以這可能是值得的，這意味著我們需要弄清楚如何進行遷移，因為這個變更需要重新索引。

主要議題

0.14 功能
WitnessMerkleBlocks

0.14 功能

背景

Bitcoin Core 0.14 預計在 2017 年 3 月左右發布。針對 0.14 的開放拉取請求被標記為 0.14 標籤。

會議討論

Luke-jr 和 jonasschnelli 正在進行多錢包專案，該專案允許執行多個錢包。由於這是一個影響重大的變更，對於 0.14 來說可能太晚了。一個重要的變更是 #9294（使用內部 HD 鏈進行找零輸出），這將使新錢包使用 2 條金鑰鏈，一條用於內部金鑰（找零輸出），一條用於外部金鑰（getnewaddress）。由於這個變更不向下相容，將其與其他錢包變更批次處理是有意義的。Jonasschnelli 建議將其與 #9298（使用 CHDPubKey，不在資料庫中儲存子私鑰，即時衍生）批次處理，後者不儲存 HD 子項的私鑰，而是在需要時衍生它們。如果我們想支援像 GPG 代理或硬體錢包這樣處理金鑰的程序，就需要這樣的東西。

Jl2012 希望在 0.14 中看到 #8755（實作具有嚴格簽章雜湊估算的過度簽章雜湊保護政策）和 #8654（在評估中重複使用簽章雜湊計算）。

BlueMatt 希望看到 cfields 的重構工作（#9289（net：放棄 boost::thread_group））和他自己的 #9375（在完整區塊連線之前中繼緊湊區塊訊息）進入，這大大改善了網路傳播速度。

Luke-jr 希望看到 #7533（sendrawtransaction：允許使用者忽略/覆蓋特定拒絕）進入 0.14，因為它很難重新基礎，也許還有 #8776（通往多錢包的錢包重構）。

Gmaxwell 希望看到對 #9138（改進手續費估算）的一些審查，因為錢包和手續費估算沒有足夠的測試基礎設施，所以我們依賴於人工審查。

會議結論

審查 #9294（使用內部 HD 鏈進行找零輸出）和 #9298（使用 CHDPubKey，不在資料庫中儲存子私鑰，即時衍生）
審查人們為可能進入 0.14 而正在進行的 PR

WitnessMerkleBlocks

背景

Codeshark 開始進行新訊息類型的工作，用於過濾區塊，其中包括到 coinbase 的路徑和見證的部分默克爾樹。此外，它不是將所有交易作為單獨的訊息發送，而是將它們包含在相同的結構中。他開始在這裡進行這些程式碼的工作。

會議討論

CodeShark 並不真的喜歡 BIP37，但目前沒有另一個查詢機制不需要你下載完整區塊。Gmaxwell 想知道像 BIP152 ‘getblocktxn’ 訊息這樣的按索引查詢是否能涵蓋 CodeShark 的使用情境。人們更願意進行按索引查詢的工作，而不是投資已知有問題的 BIP37 方法。

會議結論

CodeShark 將更深入研究 BIP152

幽默時刻

gmaxwell          #startmeeting
jonasschnelli     gmaxwell: 我想是 meetingstart
gmaxwell          #meetingstart
jonasschnelli     嗯...
gmaxwell          哈，機器人不在這裡。
gmaxwell          好吧，我們不需要它。我們可以假裝它在這裡。

gmaxwell          #action 測試 0.13.1rc1 或 0.13 分支
gmaxwell          （我們假裝機器人在這裡，記得嗎。）

gmaxwell          我有點擔心 0.14 中使用者可見功能較少，這會使採用速度變慢，最終導致測試和回饋變慢——就是這樣。
CodeShark         添加一些動畫 gif :p
jonasschnelli     我們可以變更啟動畫面...
gmaxwell          將標誌替換為刻有 B 的月球，以慶祝最近的價格活動。:P

sipa              嗨！
sipa              我忘記了
sipa              早安
CodeShark         歡迎！
gmaxwell          sipa：我們已經把所有工作分配給你了，所以不用擔心。

gmaxwell          好的。我想我們可以提前結束。祝大家節日快樂！如果你要旅行，請安全旅行。
gmaxwell          #endmeetingItDoesntMatterHowWeSpellItBecauseTheBotIsntHere

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
kanzure	Bryan Bishop
btcdrak	BtcDrak
BlueMatt	Matt Corallo
cfields	Cory Fields
phantomcircuit	Patrick Strateman
jl2012	Johnson Lau
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
jcorgan	Johnathan Corgan

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-12-15 IRC 會議摘要

Thu, 15 Dec 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
PR 積壓/0.13.2 的緊急 PR
幽默時刻
參與者
免責聲明

備註 / 簡短議題

Sipa 和 gmaxwell 一直在試驗每交易輸出 UTXO 快取方法，而不是按交易分組 UTXO，但到目前為止結果看起來不太樂觀。當它完全在記憶體中運作時，速度快 15%，但是當 levelDB 參與時，它會更慢。真正的收益應該來自於使快取更智慧，但需要進一步測試。想要每交易輸出快取的原因是目前的行為可能在平均情況下很好，但對於大型交易來說很糟糕。

主要議題

PR 積壓/0.13.2 的緊急 PR

PR 積壓/0.13.2 的緊急 PR

背景

Bitcoin Core 0.13.2 帶來了各種錯誤修復和性能改進。RC1 預計在本月底或下個月初發布。

會議討論

PR #9322（不設置未知的 rpcserialversion），如果你請求的序列化版本高於你的軟體支援的版本，它會返回錯誤，Luke-jr 有一條評論，他希望允許設置超出預設的未來序列化版本。但假設預設值始終是最新版本。Wumpus 指出這可以在稍後的拉取請求中完成，這個可以合併。

PR #9352（嘗試從所有緊湊區塊公告重建）需要快速推進，以解決 FIBRE/一些目前的網路問題。Gmaxwell 解釋說，目前，如果有人向我們發送標頭，我們請求一個區塊並標記該區塊正在傳輸中。如果在我們等待時出現一個緊湊區塊（例如，來自高頻寬模式發送者，該發送者發送未經請求的區塊），我們就會忽略它，而不是嘗試重建區塊。這意味著，如果一個節點出現故障且緩慢傳輸或無法回應，高頻寬模式將無法解決這個問題。我們可以深入探討以實現最佳行為，但目前提出的是一個非常小的變更，即使區塊正在傳輸中，我們仍然會看看是否可以僅從緊湊區塊中恢復整個區塊。如果可以，我們接受它，並將區塊標記為完成。

PR #9289（net：放棄 boost::thread_group）阻礙了網路重構的下一輪變更。

PR #9262（偏好祖先較少的幣，在 ATMP 之前進行合理性檢查）已準備好，但對於預設值存在一些分歧。Gmaxwell 和 instagibbs 認為它應該預設為「關閉」。這些交易將在錢包中排隊，定期重新廣播，並在不再超限時發出。可以在 0.14 中變更預設值，如果需要的話。PR 最重要的變更是盡可能避免那些傳播不良的交易，這不是可選的。由於這會造成實際問題，應該回移到 0.13.2

MarcoFalke 想知道是否有人對他在 PR #9347 中關於 fLimitFree 旗標的評論有強烈意見。他認為這並不重要，但希望得到第二意見。

會議結論

合併 #9322（不設置未知的 rpcserialversion）
審查 #9262（偏好祖先較少的幣，在 ATMP 之前進行合理性檢查）預設停用並回移到 0.13.2
審查 #9352（嘗試從所有緊湊區塊公告重建）並回移到 0.13.2

幽默時刻

instagibbs      更好就是更好
gmaxwell        有時更好就是更糟，肯定有一篇關於這個的文章。:P

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
Chris_Stewart_5	Chris Stewart
jonasschnelli	Jonas Schnelli
instagibbs	Gregory Sanders
sdaftuar	Suhas Daftuar
kanzure	Bryan Bishop
btcdrak	BtcDrak
MarcoFalke	Marco Falke
BlueMatt	Matt Corallo
cfields	Cory Fields
jtimon	Jorge Timón
phantomcircuit	Patrick Strateman
achow101	Andrew Chow

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-12-08 IRC 會議摘要

Thu, 08 Dec 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
使 RelayWalletTransaction 嘗試 AcceptToMemoryPool
記憶池過期時間增加
幽默時刻
參與者
免責聲明

備註 / 簡短議題

Github 現在支援為你的 PR 列出審查者
隔離見證支援 getblocktemplate 實作需要一些緊急審查，因為一些下游礦工需要它來支援 segwit

主要議題

使 RelayWalletTransaction 嘗試 AcceptToMemoryPool
記憶池過期時間增加

使 RelayWalletTransaction 嘗試 AcceptToMemoryPool

背景

拉取請求 #9290（使 RelayWalletTransaction 嘗試 AcceptToMemoryPool）修復了一個問題，即先前因無法進入記憶池而未能中繼的錢包交易，在重新啟動之前不會再次嘗試，即使記憶池條件可能已經改變。連同拉取請求 #9262（偏好祖先較少的幣，在 ATMP 之前進行合理性檢查）一起，它們修復了一些使用者正常使用錢包可能導致無法解釋的失敗的情況，原因是在記憶池中建立長交易鏈。這些長交易鏈會使發送看起來失敗，但它仍然會進入錢包並可能稍後廣播（重新啟動後）。使用者失去對其資金的存取權，並可能錯誤地認為錢包是空的。導致可能的重複支付。

會議討論

拉取請求描述中表達的擔憂來自 morcos，但他被 sdaftuar 說服並同意該 PR。他對回移它仍有一些疑慮，對於 #9262 肯定也是。他擔心，由於這些是行為上相當大的變更，它們不會得到足夠的測試以確保它們不會引發新問題。

這種行為已經存在好幾個版本了，然而最近由於偶爾的記憶池積壓，這已經成為一個更大的問題。

Gmaxwell 希望看到 #9262 或 #9290 被回移，但如果只有一個，更偏好 #9290。Morcos 對 #9290 也感覺更輕鬆，因為它相當簡單。

Morcos 和 Wumpus 希望專注於 0.14 的良好解決方案，而不是急於在 0.13.2 中實現。0.13.2 的 RC1 應該可能在 12 月發布，以避免與 0.14 重疊。

Sipa 想知道是否有處理 createTransaction 中 AcceptToMemoryPool（ATMP）失敗的修補程式。#9262 會使你到達 ATMP 失敗的可能性大大降低。#9262 使它更不可能遇到 ATMP 失敗，但 sipa 會更放心有一些正確處理偶爾失敗的東西，而不是盡力避免失敗。這樣你就會知道你的交易沒有立即廣播。Gmaxwell 認為我們從來不真正知道這一點，因為我們沒有監控來告訴廣播是否成功。

Sdaftuar 提出一個簡單的回移，將失敗 ATMP 的交易的交易 ID 返回給 RPC 呼叫者，一旦它被添加到錢包。Sipa 在會議期間進行了一個拉取請求。

Luke-jr 指出，也可以通過將 -spendzeroconfchange 的預設值設置為 0 來解決這個問題，但這將是一個破壞性的變更，只有在真正嚴重的問題時才應該考慮。

會議結論

審查主分支和回移的 #9290（使 RelayWalletTransaction 嘗試 AcceptToMemoryPool）、#9302（即使新交易的 ATMP 失敗也返回 txid）以及可選的回移 #9262（偏好祖先較少的幣，在 ATMP 之前進行合理性檢查）

記憶池過期時間增加

背景

目前在記憶池中停留超過 3 天的交易會從記憶池中移除。Morcos 提議將此過期時間增加到 2 週。

會議討論

Morcos 認為，如果我們想充分利用交易量的每週週期，我們需要有停留一週或更長時間的交易來測量它們需要多長時間才能得到確認。

Gmaxwell 指出，過期會移除被軟分叉出去但佔用你的記憶池的高手續費交易。然而，3 天的過期時間無論如何都會搞亂手續費估算。

Sdaftuar 指出，3 天與一週的另一個優勢是能夠雙重花費手續費太低的交易，但在引入手續費提升後，這個問題在很大程度上消失了。Gmaxwell 認為，即使在一天之後，非可替換交易的替換現在也能工作，這是由於重新啟動和全 rbf 礦工。

會議結論

提出一個 PR 來增加過期時間並獲得更多想法和問題。

幽默時刻

8:45  MarcoFalke      #action 建立報告 txid 修補程式
8:45  sipa            MarcoFalke_: 已經在做了
8:45 jonasschnelli    sipa: 棒！
...
8:50 bitcoin-git      sipa 開啟了拉取請求 #9302：即使新交易的 ATMP 失敗也返回 txid https://github.com/bitcoin/bitcoin/pull/9302
8:52 morcos           謝謝 sipa
8:52 jonasschnelli    是的。謝謝 sipa。
8:53 jonasschnelli    下次請更快一點

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
Chris_Stewart_5	Chris Stewart
jonasschnelli	Jonas Schnelli
Michagogo	Michagogo
instagibbs	Gregory Sanders
sdaftuar	Suhas Daftuar
kanzure	Bryan Bishop
luke-jr	Luke Dashjr
btcdrak	BtcDrak
MarcoFalke	Marco Falke
CodeShark	Eric Lombrozo

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-12-01 IRC 會議摘要

Thu, 01 Dec 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
Main.cpp 拆分
錢包中的 vchDefaultKey
HD 復原
幽默時刻
參與者
免責聲明

備註 / 簡短議題

由於 segwit 變更了來自 JSON-RPC API 的資料格式，已提出一個拉取請求，添加一個選項以返回非 segwit 序列化，以便未及時升級其函式庫的使用者仍然可以使用 RPC 介面。
JeremyRubin 的更好的 SigCache 實作已準備好進入，但缺少一些審查。

主要議題

Main.cpp 拆分
錢包中的 vchDefaultKey
HD 復原

Main.cpp 拆分

背景

TheBlueMatt 正在進行重構 main.cpp 的工作。這應該使程式碼對新開發者更容易接觸，並改進程式碼審查和測試。

會議討論

PR #9183（main.cpp 拆分的最終準備）已準備好合併，已經有很多 ACK。

在主要拆分之後，回移可能會變得更複雜。仍需回移到 0.13.2 的 PR 有：

#9253（修復計算要使用的綁定通訊端數量）
#9229（移除對 getaddrinfo_a 的呼叫）
#9194（添加選項以透過 rpc 返回非 segwit 序列化）
#9188（使孤兒父取得要求見證）
#9239（停用 1 個區塊目標的手續費估算）
#9252（在呼叫 ProcessNewBlock 或處理標頭（cmpctblock 處理）之前釋放 cs_main）

會議結論

合併 #9183（main.cpp 拆分的最終準備）
專注審查「需要回移」標籤
回移完成後拆分 main

錢包中的 vchDefaultKey

背景

vchDefaultKey 是「預設位址」概念的遺留物，該概念在古老的 0.4.0 版本中被移除。Wumpus 開啟了一個問題討論這個行為。

它目前除了用於確定是否剛建立新錢包之外未被使用。

會議討論

Sipa 希望擺脫這個，但是如果我們這樣做，降級到較舊的錢包版本將導致重新掃描失敗。

鑑於這並不是很緊急，所以不需要虛擬金鑰等駭客手法。0.14 可以停止依賴 vchDefaultKey，但仍然寫入它，然後在 0.15 中刪除 vchDefaultKey 並將最低版本提高到 0.14，這樣 0.15 錢包將永遠無法在 0.13 中開啟。

會議結論

使用版本控制在 0.15 之前擺脫 vchDefaultKey

HD 復原

背景

自 0.13 以來，新建立的錢包將根據 BIP32 使用階層式確定性金鑰生成。錢包轉儲將包含 HD 種子，但尚無法匯入此種子。

會議討論

Jonasschnelli 認為復原 HD 種子應該是一個單獨的工具。該工具將建立一個新的 wallet.dat 並在之後執行重新掃描。該工具可以與 RPC 和 UTXO 集互動以檢測間隙限制。

Wumpus 建議在進行額外工作之前，先審查並合併目前的錢包 PR。PR #9143（重構 ZapWalletTxes 以避免層違規）、#9256（修復更多 CWallet/CWalletDB 層違規）和 #8723（添加對靈活 BIP32/HD 金鑰路徑方案的支援）需要一些審查。

Gmaxwell 認為在修復路徑拆分問題之前，我們應該避免在 HD 支援中添加更多複雜性。問題在於找零輸出與接收金鑰在同一鏈上，因此你最終可能會將找零金鑰作為位址分發出去讓人們付款（對你隱藏他們的付款），或者如果你從 hd 資料復原錢包，找零可能會顯示為付款。

低懸果實可能是在金鑰池中添加「已使用」標記，並將 HD 錢包的預設金鑰池增加到 1000，因為目前的 100 真的很小。

會議結論

審查 #9143（重構 ZapWalletTxes 以避免層違規）、#9256（修復更多 CWallet/CWalletDB 層違規）和 #8723（添加對靈活 BIP32/HD 金鑰路徑方案的支援）
專注於拆分金鑰路徑

幽默時刻

gmaxwell      我剛注意到 #9188 還沒合併。
gmaxwell 看看自己是不是延遲的原因
gmaxwell 不是延遲的原因

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
jtimon	Jorge Timón
BlueMatt	Matt Corallo
Chris_Stewart_5	Chris Stewart
jonasschnelli	Jonas Schnelli
Michagogo	Michagogo
achow101	Andrew Chow
cfields	Cory Fields
jcorgan	Johnathan Corgan
petertodd	Peter Todd
instagibbs	Gregory Sanders
sdaftuar	Suhas Daftuar
paveljanik	Pavel Janik
kanzure	Bryan Bishop
luke-jr	Luke Dashjr
btcdrak	BtcDrak

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-11-17 IRC 會議摘要

Thu, 17 Nov 2016 00:00:00 +0000

概覽

主要議題
Shared_ptr
移除優先級
移除帳戶
輔助區塊請求
- 背景
- 會議討論
幽默時刻
參與者
免責聲明

主要議題

Shared_ptr
移除優先級
移除帳戶
輔助區塊請求

Shared_ptr

背景

在許多地方，我們已經開始使用 ‘shared_ptr’ 而不是物件本身，這樣它可以在許多資料結構之間共享，而無需製作副本。

會議討論

Sipa 有一系列 3 個拉取請求，在更多地方引入 shared_ptr，即 #9125（使 CBlock 成為 CTransactions 的 shared_ptr 的向量）、#8580（使 CTransaction 真正不可變）和 #8589（在 CTxIn 中內嵌 CTxInWitness（在 #8580 之上））。第一個是後續請求的必要重構，性能提升 3-4%。第二個可能更具爭議性，因為它顯著影響錢包程式碼。Wumpus 認為 CwalletTx 繼承自 CTransaction 的舊行為是濫用繼承的一個很好的例子。

會議結論

審查 #9125

移除優先級

背景

優先級系統過去根據年齡、大小和輸入數量為交易分配優先級，使得一些交易免費。這有大量程式碼基礎，已經努力移除該系統，因為不能期望礦工繼續包含 0 手續費交易。

會議討論

Morcos 指出，優先級程式碼不再提供任何功能，也許可以設定一個目標，在 0.15 中移除所有優先級程式碼。Luke-Jr 可能不同意這一點，儘管他沒有出席會議。已經合併了很多朝向優先級的東西。

Gmaxwell 同意，並認為保留優先級的任何願望都可以通過明智地使用手續費差異來回答。

「移除優先級」有 4 個組成部分：rpc、估算、挖礦和中繼。估算已經被移除。Gmaxwell 希望看到中繼被移除，因為它目前造成頻寬浪費，因為它正在中繼不會被挖出的交易。

會議結論

變更預設值以停用優先級中繼。
與 Luke-Jr 重新討論，因為他是保留優先級的主要支持者，但未出席會議

移除帳戶

背景

目前 bitcoin-core 使用帳戶系統。使用此功能的第三方可能會遇到多個問題，很久以前就已達成共識，應該移除該系統並由「標籤」系統取代。

會議討論

今年早些時候，Wumpus 開啟了一個拉取請求，為錢包引入「標籤」API（在 2016-07-14 會議中曾提到）。它仍然沒有得到太多審查。

應該首先引入標籤一兩個版本，然後再移除帳戶，因為有些人仍然依賴帳戶系統，但將其用作標籤。

Wumpus 提到應該有保護措施，防止使用者同時使用帳戶和標籤 API，因為這可能會造成問題。

Instagibbs 想知道是否有人與仍然使用帳戶的開發者交談。MarcoFalke 認為 Dooglus 使用它，但他的使用情境會被新的標籤 API 涵蓋。

會議結論

審查 #7729（rpc：為錢包引入「標籤」API）
向 dooglus 詢問使用者回饋

輔助區塊請求

背景

Jonasschnelli 開啟了一個拉取請求，引入輔助區塊請求（先前稱為「帶外區塊請求」）。此功能允許請求區塊，如果在磁碟上可用，則會被下載並優先於正常 IBD 下載。此變更是執行 SPV 錢包所需的，在上週會議中討論過。

會議討論

多位開發者發現很難理解，並想知道是否有對高層設計及其如何運作的更一般描述。Jonasschnelli 解釋：你問你的節點，給我區塊 “D, F, G”，節點下載區塊 “D, F, G” 並通過 validate=false 的訊號傳遞它

Sipa 喜歡整體概念，但認為實作需要隨著正在進行的網路重構而改變。

BlueMatt 想知道區塊是否真的應該被儲存，或者我們是否可以直接傳遞給錢包。如果它不儲存區塊，在混合模式下將需要下載兩次，所以它至少應該有機會儲存它。BlueMatt 希望看到 p2p 邏輯決定是否將區塊發送到 ProcessNewBlock。

幽默時刻

morcos          讓我們談談帳戶或優先級移除的潛力（2 個單獨的議題）
jonasschnelli   #topic 帳戶或優先級移除

jonasschnelli   #topic "移除帳戶"
gmaxwell        「比特幣開發者反對問責制。」

jtimon          我們不能一次性用標籤替換帳戶嗎？
jtimon          我們不是已經警告不要使用帳戶很久了嗎
instagibbs      jtimon，在某個時候我認為人們不相信棄用警告
instagibbs      我們應該放上可怕的 ASCII 藝術 :)

gmaxwell        好的，我認為我們應該採取建議的行動，讓每個人閱讀並評論 7729，然後轉到另一個主題。
gmaxwell        否則，我們可以從事古老的完全無知的戰鬥藝術。
gmaxwell        「我沒有讀過 7729，但我反對任何會導致小孩失明的變更！」
petertodd       gmaxwell：我沒有讀你的上一條評論，但 ACK
jonasschnelli   如果沒有其他議題，我們可以談談「輔助區塊請求」，如果有些人感興趣的話？
jtimon          那是什麼？
gmaxwell        jonasschnelli：那會導致小孩失明嗎？

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
morcos	Alex Morcos
jtimon	Jorge Timón
BlueMatt	Matt Corallo
Chris_Stewart_5	Chris Stewart
jonasschnelli	Jonas Schnelli
Michagogo	Michagogo
achow101	Andrew Chow
cfields	Cory Fields
MarcoFalke	Marco Falke
CodeShark	Eric Lombrozo
jcorgan	Johnathan Corgan
petertodd	Peter Todd
instagibbs	Gregory Sanders

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-11-10 IRC 會議摘要

Thu, 10 Nov 2016 00:00:00 +0000

概覽

主要議題
混合 SPV
多執行緒 ProcessMessages
0.14
幽默時刻
參與者
免責聲明

主要議題

混合 SPV
多執行緒 ProcessMessages
0.14

混合 SPV

背景

Jonasschnelli 正在進行一個拉取請求，為錢包添加全區塊 SPV 模式。

它會有 2 個選項：-spv 和 -spvonly，-spv 用於啟用使用者在區塊鏈仍在下載/驗證時發送和接收交易。-spvonly 則完全不驗證區塊。

PR 目前的限制：

沒有 SPV 0 確認交易
SPV 交易的備用手續費（因為沒有記憶池/手續費估算器）
它只有簡單的 spv 重組處理
目前與修剪不相容

會議討論

Jonasschnelli 想知道這個想法是否值得追求，因為他還沒有收到任何概念性的 ACK。

每個人都認為這是一個很好的功能。BlueMatt 認為包含 spv-only 模式可能不值得，但是沒有額外成本，因為混合模式需要這些程式碼。它也將是唯一使用完整區塊的 SPV 客戶端。

會議結論

繼續進行混合全區塊 SPV 模式

多執行緒 ProcessMessages

背景

目前 Bitcoin Core 在單執行緒中進行訊息處理。BlueMatt 請求對多訊息處理執行緒的一些回饋和一般關注。

會議討論

BlueMatt 詳細說明，目前它不是很有用，因為大多數訊息使用 cs_main，但他希望能儘早而不是稍後看到它的管道。例如：添加多執行緒訊息傳遞將允許節點在處理區塊時回應 getblocktxn，這是他真正想要用於基於 FIBRE 的中繼網路的功能。Wumpus 補充說，能夠同時服務多個節點也會非常有用，應該可以減少區塊中繼延遲。

Morcos 指出，首先徹底審查同步問題很重要，因為現在可能無法檢測到問題，因為它們只從單執行緒存取。

Gmaxwell 認為讓 process message 並發可能會為 nodestats 周圍的資料競爭帶來更大的風險，所以他建議使用 valgrind DRD 執行測試，並嘗試消除資料競爭。

會議結論

進行添加多執行緒訊息處理的工作

0.14

背景

Bitcoin Core 0.14 預計在 2017 年 3 月左右發布。

會議討論

MarcoFalke 想知道進入 0.14 的優先事項是什麼。

拆分 main.cpp 幾乎可以肯定會在此時進入。

Sdaftuar 希望看到 JeremyRubin 的驗證加速進入。

Jonasschnelli 認為多錢包支援剩下的工作不多，儘管他不確定是否能趕上 0.14。為多錢包支援開設了一個 github 專案。

對於網路重構，Cfields 的目標是下週完成 net.h/cpp 拆分。

Bumpfee 應該得到一些審查。

記憶池統計的基礎工作在 #8501 中完成，但到目前為止沒有審查。

會議結論

優先審查錢包變更

幽默時刻

gmaxwell      我們應該向所有錯過時區變更的美國人打招呼。
gmaxwell      並且現在剛到。:P
gmaxwell      嗨，各位。
achow101      嗨
petertodd     gmaxwell: 加拿大人也是 :)
btcdrak       petertodd: 你是說雪地墨西哥人對吧？
gmaxwell      歡迎來到會議結束。
wumpus        是的，歡迎
sipa          kthxbye
wumpus        #endmeeting
MarcoFalk_    也許川普會廢除日光節約時間

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
NicolasDorier	Nicolas Dorier
morcos	Alex Morcos
jtimon	Jorge Timón
BlueMatt	Matt Corallo
kanzure	Bryan Bishop
jonasschnelli	Jonas Schnelli
sdaftuar	Suhas Daftuar
achow101	Andrew Chow
cfields	Cory Fields
MarcoFalke	Marco Falke
CodeShark	Eric Lombrozo
paveljanik	Pavel Janik
petertodd	Peter Todd

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-11-03 IRC 會議摘要

Thu, 03 Nov 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
區塊標頭/取得邏輯
BIP152 變更
幽默時刻
參與者
免責聲明

備註 / 簡短議題

最終警報已成功發出。
Wumpus 想知道 PR #9053（使用鏈工作量而非高度進行 IBD，且不使用標頭時間戳記）是否應該回移到 0.13.2。回移是無害的，它確實修復了測試網問題，即非 segwit 鏈無意中觸發測試網節點進入停止挖礦的狀態。到底要回移什麼總是可以稍後決定。

主要議題

區塊標頭/取得邏輯
BIP152 變更

區塊標頭/取得邏輯

背景

在初始區塊下載（IBD）期間，會發送一個 ‘getheaders’ 訊息，該訊息請求一個 ‘headers’ 訊息，該訊息提供來自區塊鏈中特定點的區塊標頭。這樣可以一次下載許多區塊標頭。

會議討論

Sipa 解釋了幾個相關的要點：

標頭請求沒有逾時
我們在 IBD 中不回應標頭請求，如果節點錯誤地認為它們在 IBD 中，這可能會導致停滯
區塊取得邏輯只會斷開那些減慢進程的節點，我們可能有一個節點完全沒有我們可以取得的區塊，我們永遠不會嘗試，也永遠不會斷開它們

他提議在 IBD 時斷開你沒有從中下載的外向連線，但移除在 IBD 中不回應 ‘getheaders’ 的設定。

Gmaxwell 提出了更強的建議，即當你有最大外向連線數時，在 IBD 期間每分鐘斷開給你提供區塊最慢的節點。

會議結論

首先為標頭取得添加逾時
會後進一步討論

BIP152 變更

背景

BIP152 緊湊區塊中繼自 0.13.0 以來一直在 Core 中。為了減少區塊中繼期間使用的頻寬和延遲。

會議討論

已經進行了一些小的錯誤修復和改進，需要變更 BIP 文字，例如 sdaftuar 的修復無效緊湊區塊的處理。Luke-jr 想知道何時以及是否應該停止 BIP 變更，因為現在 BIP 似乎對其他實作來說是一個移動目標。

在發布實作後，認為我們不會想對複雜的 BIP 進行小調整可能不切實際，在未來讓原始 BIP 反映最終設計會更清楚。

Gmaxwell 認為這更像是郵件列表的議題，而不是會議議題。

會議結論

等到一段時間沒有變更後再將 BIP 設為「最終」。

幽默時刻

gmaxwell          總之，我仍然認為 BIP 討論應該放在別處。:)
morcos            好吧，那你想出別的東西來討論剩下的 11 分鐘！

gmaxwell          wumpus: sipa: 感謝合併這麼多東西！
BlueMatt          <3
sdaftuar          +1
BlueMatt          讓 0.14 再次偉大！

wumpus            所以我想在實務上它只修復了 0.13.2 上的測試網問題，所以問題是這是否值得潛在的倒退？
gmaxwell          <有名的遺言>我看不出它會造成倒退。</有名的遺言>

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
Chris_St_1	Chris Stewart
morcos	Alex Morcos
jtimon	Jorge Timón
BlueMatt	Matt Corallo
kanzure	Bryan Bishop
jonasschnelli	Jonas Schnelli
luke-jr	Luke Dashjr
sdaftuar	Suhas Daftuar
achow101	Andrew Chow

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-10-27 IRC 會議摘要

Thu, 27 Oct 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
測試鏈
移除檢查點
參與者
免責聲明

備註 / 簡短議題

0.13.1 已發布。（二進制檔案、磁力連結、郵件列表公告、部落格文章）
Gmaxwell 將與 Achow101 和 Cobra 協調發出最終警報，如郵件列表和 2016-09-22 會議所討論的。

主要議題

測試鏈
移除檢查點

測試鏈

背景

Jtimon 正在進行一項工作，使在主測試網之外建立新測試網變得更容易（PR #8994）。為了測試某些功能或不同的邊緣情況，普通測試網可能不夠用。目前測試網的不穩定性導致一些人根本不在上面測試。

會議討論

進一步的開發將著重於簽名區塊選項，這是在 Elements Alpha 中用於建立區塊的機制。Jtimon 正在自己的分支上進行這項工作。

在受信任的群組內使用 regtest 與簽名區塊一樣有用，然而當公開時，就需要像區塊簽名這樣的東西。Jtimon 指出，他的 PR 使得可以選擇 “-chain=custom -chainpetname=mysharedsecret”，而沒有存取 mysharedsecret 的人將無法在本地建立創世區塊，因為創世區塊的雜湊值取決於 -chainpetname。

會議結論

查看 PR#8994（測試鏈：引入自訂鏈，其建構子…）

移除檢查點

背景

每隔一段時間，舊的區塊雜湊值就會被硬編碼到比特幣軟體中。不同的實作選擇不同的檢查點位置。這些檢查點目前用於 3 個使用情境：

防止使用低難度標頭進行標頭洪水攻擊
跳過早期區塊中的簽章
估算進度

會議討論

Gmaxwell 有一個分支移除了檢查點。他還沒有完全移除，因為他仍然需要替換進度估算。

有 3 個組成部分：

移除初始區塊下載的檢查點，這是理所當然的。
移除腳本檢查的檢查點，這取決於基準測試結果，如 2016-09-09 會議所討論的。
避免標頭洪水。Gmaxwell 確實想出了一個簡潔的方法來做到這一點，但這需要一個非常瑣碎且顯然沒問題的隱式共識變更，但可能會延遲進度。他提議在鏈參數中引入一個常數，這是發布時最佳鏈中已知的工作量。初始區塊下載檢查已經使用了這個。一旦我們有任何標頭鏈至少有那麼多的工作量，我們就不再接受任何難度低於 1600 萬的區塊，這大約等於約 10 台商用採礦設備。

難度可能在軟分叉到不同的工作量證明下降到如此之低，然而在這種情況下，舊客戶端非常不安全，這不是軟分叉的特性。接下來進行了一些關於 PoW 變更的軟分叉不安全性的討論。

會議結論

會後進一步討論

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
cfields	Cory Fields
Chris_Stewart_5	Chris Stewart
CodeShark	Eric Lombrozo
morcos	Alex Morcos
harding	David Harding
jtimon	Jorge Timón
BlueMatt	Matt Corallo
kanzure	Bryan Bishop
jonasschnelli	Jonas Schnelli
jeremyrubin	Jeremy Rubin
petertodd	Peter Todd
luke-jr	Luke Dashjr

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

2016-10-20 IRC 會議摘要

Thu, 20 Oct 2016 00:00:00 +0000

概覽

備註 / 簡短議題
主要議題
libconsensus
參與者
免責聲明

備註 / 簡短議題

Bitcoin Core 0.13.1 候選版本 2 已發布，目前沒有回報任何問題。
Wumpus 一直在詢問有關終止 Windows 32 位元版本的問題，可能在 0.15 版本。他收到了 2 個仍在使用 Windows 32 位元的回應，兩者預期只會再使用 6 個月。
Jonasschnelli 注意到 GUI 預設確認目標是 25 個區塊，這真的很高，而預設 RPC 目標只有 2 個區塊。這些應該是相同的值。由於改進手續費估算方面進展甚微，bumpfee PR 應該獲得更多審查。

主要議題

libconsensus

libconsensus

背景

理想情況下，共識層應該與比特幣軟體的其他部分解耦。長期目標是提取出一個獨立的 “libconsensus” 函式庫。這樣人們就可以更容易地對非共識部分進行變更，而不必擔心共識不相容。然而，這是一個緩慢而危險的專案，需要移動大量程式碼。在過去幾個主要版本中，一直在努力朝著這個共識函式庫的方向前進。

最近，Jorge Timón 在郵件列表上發表了一篇文章，提出了更詳細的推進計劃。他有自己的分支，正在進行所有變更。

會議討論

目前可以將非共識旗標傳遞到 libconsensus 中。PR #8976 試圖修復這個問題。Sipa 認為應該有一個轉換層。

Jtimon 希望在 libconsensus 中公開一個 “GetConsensusFlags” 呼叫，以隱藏 BIP9 和先前開發的類似內容，類似於“公開 VerifyHeader”。Sipa 不喜歡將標頭的內部表示轉換為介面，而只是有一個 API，你可以在其中建立 blockindexstore，並向其提供標頭。這意味著 libconsensus 將與 Bitcoin Core 的儲存保持耦合，這是 sipa 的偏好。Wumpus 指出，先前的結論是 libconsensus 應該與當前的快取層保持耦合，但不與 levelDB 耦合，因此記憶體儲存是 libconsensus 的一部分，但磁碟儲存不是。Jtimon 可以接受包含儲存和不包含儲存的兩個版本，例如 libbitcoin 可能永遠不會使用與 bitcoin 儲存耦合的 libconsensus 及其並發性。其他人可能只想使用 core 目前的儲存實作來減少工作。Sipa 認為不抽象出資料結構為未來的最佳化留下了更多機會。

會議結論

專注於單元的分離和移除依賴，進一步的最佳化可以稍後進行。
會後進一步討論

參與者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
instagibbs	Gregory Sanders
cfields	Cory Fields
Chris_Stewart_5	Chris Stewart
jl2012	Johnson Lau
CodeShark	Eric Lombrozo
Michagogo	Michagogo
paveljanik	Pavel Janik
achow101	Andrew Chow
morcos	Alex Morcos
MarcoFalke	Marco Falke
jtimon	Jorge Timón
BlueMatt	Matt Corallo
kanzure	Bryan Bishop
jonasschnelli	Jonas Schnelli
jeremyrubin	Jeremy Rubin

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-10-13

Thu, 13 Oct 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.1
sybil 攻擊
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Jtimon 在郵件列表上發布了 libconsensus 完成計劃。
有人抱怨測試網不可靠，因為它沒有持續被挖掘。一些人希望看到簽名測試網，類似於 elements alpha 執行的方式，這樣它將具有完全可預測的區塊和重組。
為下游開發者提供了 segwit 開發指南。還應該有一個 segwit 部署指南，其中包含更多詳細資訊，例如如何設定周邊節點。
Achow101 將為 bitcoin.org 撰寫關於警報系統的文章，這在之前的 2016-09-22 會議中討論過。

主要議題

0.13.1 與 BIP 9 參數
sybil 攻擊

0.13.1

背景

Bitcoin Core 0.13.0 於 2016/08/23 發布。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。

BIP9 是使用比特幣區塊中「版本」欄位的各個位元來部署軟分叉的機制。BIP68、BIP112 和 BIP113 已使用此機制同時部署。

會議討論

0.13.1 僅剩一個 PR（#8499），它添加策略限制並為 segwit 腳本停用未壓縮金鑰。Jl2012 一直在為它編寫測試，因為有很多邊緣情況，但它們現在都已被識別並可修復。

BIP 9 建議將開始日期設定為軟體發布後大約一個月。BlueMatt 提議在第一個發布候選版本中不設定日期，而是在最終版本上設定。由於這會使事情複雜化，最好在 RC1 中設定一個足夠遠的未來日期。BIP9 實際上需要 4-8 週才能啟動的事實使日期變得不那麼重要。

會議結論

在郵件列表上發布關於 segwit 軟分叉的文章，以決定啟動時間，提議為 RC1 之後 1 個月。

sybil 攻擊

背景

目前正在進行一次攻擊，大量並行連接到所有可達節點，偽裝成混合的不同 spv 客戶端。

會議討論

Gmaxwell 指出他在啟動節點後的幾秒鐘內就看到 60 多個連線。已經向亞馬遜提出了關於此使用者的濫用投訴，但他們沒有回應。

由於幾個版本前實施的連線管理，這次攻擊不會對網路造成太大破壞，但假設他們的動機是透過觀察破壞使用者的隱私，否則這將是一個非常無效的 DoS 攻擊。

這種隱私洩漏可以透過實施已計劃的中繼改進來減少，由於其他優先事項，這還沒有完成。如果我們減少隱私洩漏，他們很可能會停止攻擊。

Btcdrak 想知道我們是否可以封禁來自同一 IP 的多個連線，但這會損害許多使用相同 IP 的機構。他們也已經使用了多個 IP，一旦人們開始傳播封禁列表，他們就會變更這些 IP。

BlueMatt 指出現在有幾個人封禁 AWS（Amazon Web Services）節點，這很遺憾，因為它們由於內建的 DoS 保護而很有用。

會議結論

努力減少隱私洩漏。

趣味環節

(selective quoting for comic effect)

morcos               so use 2 months after the time you issue the first RC for instance?
BlueMatt             so set parameters to 1.5 months for rc1? or 2?
wumpus               just estimate 2 months for the RC process
btcdrak              most releases take 3 or 4 rcs, so if we set the date for 5 weeks on rc1 that would cover it I am sure.
morcos               is wumpus saying 3 months?
wumpus               no, two months is fine
BlueMatt             i mean I'm ok with 1.5 months, too
achow101             I think two months after rc1 is fine
gmaxwell             I think it would be fine to set start date 1 month after RC1.
BlueMatt             for now lets recommend 1.25 months from rc1
michagogo            BlueMatt: perhaps 50 days for roundness
michagogo            Or 55
sipa                 nov 15.
michagogo            That's good too
btcdrak              this is like an auction.
achow101             nov 15th sounds good (at 00:00 AM?)

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
instagibbs	Gregory Sanders
cfields	Cory Fields
Chris_Stewart_5	Chris Stewart
jcorgan	Johnathan Corgan
CodeShark	Eric Lombrozo
Michagogo	Michagogo
sdaftuar	Suhas Daftuar
achow101	Andrew Chow
morcos	Alex Morcos
MarcoFalke	Marco Falke
jtimon	Jorge Timón
BlueMatt	Matt Corallo

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-09-29

Thu, 29 Sep 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
修剪和區塊中繼
移除檢查點
Segwit 對抗未壓縮金鑰？
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Gmaxwell 提到了為守護程式設定 cron 模式的想法，它只是同步然後關閉，以便更輕鬆地保持區塊鏈副本的最新狀態。
下週的會議不太可能舉行（或參與者很少），因為大多數開發者都在前往米蘭 Scaling Bitcoin的途中。

主要議題

修剪和區塊中繼
移除檢查點
Segwit 對抗未壓縮金鑰？

修剪和區塊中繼

背景

隨著 segwit 的引入，預期區塊會更大，從而對完整節點磁碟空間增加更大的壓力。有幾個想法圍繞添加服務標誌來表示區塊鏈已修剪，不會中繼歷史區塊。

會議討論

最簡單的解決方案是只添加一個標誌，表示你中繼有效的區塊和交易，但不中繼歷史區塊。當你想要多個範圍時會變得更困難，這樣節點就可以只託管一部分舊區塊。當你想以有效的方式支援分片時，它變得更加困難。

Sipa 一直在執行一些統計資料，關於從節點請求哪些區塊深度。他注意到 4 個有意義的範圍：

最上面的 2 個區塊（只是中繼，700 萬個請求中的 100,000 個）
深度達到 +/- 2500 個區塊（請求非常頻繁，每個區塊約 200-2000 個請求）
深度達到 +/- 10000 個區塊（比下一個範圍多請求幾次）
其餘的（每個區塊約 20 個請求）

Sipa 指出 4 個範圍可以用 2 個服務位元標誌完成。Wumpus 認為應該有一個服務標誌，並透過查詢表示範圍，這樣範圍的數量可以是可變的。

在「addr」訊息中添加節點範圍更加困難，gmaxwell 指出「addr」無論如何都需要相對快速地重做，因為這些訊息與 Tor 的新隱藏服務標準不相容。

Gmaxwell 之前正在開發一個提案，節點可以發出一個小種子，從中每個人都會知道它們將儲存歷史的哪些部分，但到目前為止，他無法使其既具有計算效率，又使對等節點永遠不會擷取它之前刪除的區塊。

Petertodd 指出區塊是線性下載的，所以我們可以利用這一點，確保具有一個範圍的節點追蹤具有相鄰範圍的節點。

如果服務位元用於表示服務最後 X 個區塊，它應該與最大修剪一致。Sipa 的資料表明深度達到 2000 個區塊的請求很多，而修剪節點的最小歷史記錄為 288 個區塊。

Morcos 建議當你落後少於 288 個區塊時，優先從修剪的對等節點下載，從而減輕完整歷史對等節點的負擔。

會議結論

從表示僅中繼深度 288 個區塊的服務位元開始，稍後可能添加另一個來表示更大的範圍。

移除檢查點

背景

每隔一段時間，舊的區塊雜湊就會硬編碼到 Bitcoin 軟體中。不同的實作選擇不同的檢查點位置。這些檢查點目前用於 3 種使用案例：

防止使用低難度 header 進行 header 洪水攻擊
跳過早期區塊中的簽名
估計進度

會議討論

Gmaxwell 提議完全移除檢查點。由於只有非常小比例的交易低於檢查點，並且自從 libsecp256k1 以來，簽名檢查只為同步時間增加了 15-20 分鐘。

為了防止 header 洪水攻擊，gmaxwell 提議永久增加最小難度（如果現有區塊破壞最小規則，則使用類似檢查點的規則繞過該規則）。

估計進度可以透過許多不同的方式完成。

Sipa 不相信，希望看到簽名跳過的替代方案，這可能會顯著改善事情。Gmaxwell 希望它是好的東西，因為否則可能會採用不謹慎的嘗試，例如 bitcoin classic 目前透過本地時鐘忽略超過 24 小時的簽名，這很容易被利用。

會議結論

制定提案以移除檢查點並用其他解決方案取代它

Segwit 對抗未壓縮金鑰？

背景

公鑰可以用兩種方式序列化：壓縮（33 位元組）或未壓縮（65 位元組）。自 Bitcoin QT 0.6 以來，使用壓縮版本。

會議討論

提案是在 segwit 交易中將未壓縮金鑰設為非標準。Sipa 指出在過去 2 小時內，未壓縮金鑰佔網路上使用金鑰的 0.7%。

Armory 仍然使用未壓縮金鑰。如果 segwit 強制壓縮金鑰，它將延遲 Armory 使用者採用 segwit。他們計劃無論如何都要有新的錢包結構，使用 BIP32 和壓縮金鑰以及 segwit 支援。Gmaxwell 認為壓縮金鑰支援可以完全在序列化 segwit scriptpubkey 的程序內部完成。

我們應該鼓勵所有錢包使用壓縮金鑰，並在需要時提供協助。

會議結論

在 segwit 中將未壓縮金鑰設為非標準
鼓勵錢包轉向壓縮金鑰

趣味環節

wumpus          otoh bittorrent has a fixed block size :)
sipa            wumpus: so do we *ducks*
btcdrak         inb4 Bittorrent XT
petertodd       btcdrak: I use Bittorrent Unlimited myself

gmaxwell        Might as well fit a cubic spline to the height vs txn count... and store the parameters.
sipa now remembers a song our student organization wrote to the melody of staying alive, called 'cubic spline'

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
petertodd	Peter Todd
jonasschnelli	Jonas Schnelli
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
Michagogo	Michagogo
sdaftuar	Suhas Daftuar
achow101	Andrew Chow
morcos	Alex Morcos
MarcoFalke	Marco Falke
jl2012	Johnson Lau

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-09-22

Thu, 22 Sep 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.1 發布
警報系統退役
與會者
免責聲明

筆記 / 簡短議題

Wumpus 已經開始使用 github 上的新功能來追蹤較長期的專案。

主要議題

0.13.1 發布
警報系統退役

0.13.1 發布

背景

Bitcoin Core 0.13.0 於 2016/08/23 發布。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。

在上週會議中，開發者決定從 0.13.1 里程碑標籤中移除 PR #8635（Enforce mandatory softfork flags for segwit block/tx）。

會議討論

Jl2012 建議不要在 0.13.1 中執行 PR #8654（Reuse sighash computations across evaluation）。每個人似乎都同意。關於 PR #8757（Fix issue with conflicted mempool tx in listsinceblock）中的 RPC 行為變更存在一些分歧。由於人們可能在「奇怪」行為上建構了應用程式，在主要發布版本中執行此操作會更有意義，在發布說明中完整記錄它。

標記為 0.13.1 的剩餘 pull request 的更新：

PR #8634（Add policy: null signature for failed CHECK(MULTI)SIG）有很多 ACK，似乎已準備好合併。
#8499（Check bad witness and implement several policy limits for segwit scripts）仍在進行中。
#8526（Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH）需要更多 ACK。
Sipa 將解決 PR #8393（Support for compact blocks together with segwit）中的最新細節。Roasbeef 的腳本現在正在執行並在測試網上發送 segwit 交易垃圾訊息，如果有任何礦工將算力指向測試網，他們能否設定「-blockmaxweight=4000000」，省略任何其他相關參數，這樣我們就能獲得更多更大的區塊。

Sdaftuar 認為 #8279 議題（Mempool DoS risk in segwit due to malleated transactions）對於 0.13.1 已充分解決。

Btcd，Go 語言的替代比特幣實作，將很快最終確定 segwit 相關事項。Petertodd 的 python bitcoin library 也有一個很好的 segwit PR。Gmaxwell 指出挖礦軟體最近在 segwit 方面有很大改進。Achow101 指出 armory 目標是在下一個版本之後的版本中完全支援 segwit。

會議結論

從 0.13.1 里程碑中移除 PR #8654 和 #8757，以及議題 #8279
壓縮第一個和最後一個提交後合併 #8634
審查/ACK PR #8393、#8499 和 #8526

警報系統退役

背景

比特幣警報系統是受信任方向所有 Core 客戶端廣播有關關鍵網路問題的訊息的一種方式。自 Bitcoin Core 0.13.0 以來它已被移除，並且已經停用一段時間了。

本月早些時候，Gmaxwell 在郵件列表上發布了完成警報系統退役的願望，這得到了很好的回應。

會議討論

Gmaxwell 提議了以下步驟：

建立 bitcoincore.org 或 bitcoin.org 公告訊息。
發送帶有比 COMPROMISED 訊息更禮貌文字的倒數第二個警報，引導人們查看它。
很久之後，發送最終警報。
硬編碼節點向對等節點發送最終警報以克服缺乏傳播的問題。

Wumpus 提議在 0.14 發布版本中發送最終警報。

會議結論

在 0.14 發布版本中發送最終警報

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
petertodd	Peter Todd
jonasschnelli	Jonas Schnelli
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
Michagogo	Michagogo
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
achow101	Andrew Chow
instagibbs	Gregory Sanders
jtimon	Jorge Timón
roasbeef	Olaoluwa Osuntokun
paveljanik	Pavel Janik

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-09-15

Thu, 15 Sep 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.1 發布
與會者
免責聲明

筆記 / 簡短議題

生命週期頁面上版本 0.11 的「終止支援」EOL 日期應該設定。維護日期不反映現實，因為對先前版本的反向移植沒有使用和沒有審查，因此開發者專注於當前版本。Sipa 拋出在發布 X 個月後自動顯示警告訊息的想法，以警告使用者該版本不再維護。
在 Scaling Bitcoin 會議之後的 10 月 10 日和 11 日星期一和星期二，有兩個駭客日，供那些想要對 Bitcoin Core 和高度相關專案做出生產性貢獻的人參加。
Wumpus 提議了 0.14 的發布時程表。每個人似乎都同意。

主要議題

0.13.1 發布

0.13.1 發布

背景

Bitcoin Core 0.13.0 於 2016/08/23 發布。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。

會議討論

由於仍有相當多的 PR 標記為 0.13.1，sdaftuar 提議從里程碑中移除其中一些，例如 #8654（Reuse sighash computations across evaluation）。PR #8635 對於 0.13.1 也不是必需的。Luke-jr 對一些已合併的修復發表評論，表示它們應該被反向移植。PR #8636（NULLDUMMY softfork BIP147）已準備好合併。再次進行了一些討論，關於 NULDUMMY 軟分叉是否應該與 segwit 軟分叉綁定。

Sdaftuar 正在為帶有 segwit 的 compact blocks 重寫測試。測試網上更多的 segwit 流量將使實際測試更有用。Roasbeef 正在努力產生一堆 segwit 交易，會議後他說如果我們能在測試網上獲得更多啟用 segwit 的算力並讓目前正在挖礦的人按最大權重而不是去除後大小進行限制，將會有所幫助。

會議結論

從 0.13.1 里程碑中移除 PR #8635
審查/ACK PR #8634（Add policy: null signature for failed CHECK(MULTI)SIG）、#8499（Check bad witness and implement several policy limits for segwit scripts）、#8526（Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH）和 #8393（Support for compact blocks together with segwit）

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
petertodd	Peter Todd
jonasschnelli	Jonas Schnelli
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
Michagogo	Michagogo
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
achow101	Andrew Chow
morcos	Alex Morcos
jl2012	Johnson Lau
MarcoFalke	Marco Falke

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-09-08

Thu, 08 Sep 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
segwit-compact blocks BIP
選擇 segwit 推出日期
rpc 同步假設
趣味環節
與會者
免責聲明

筆記 / 簡短議題

在米蘭 scaling bitcoin 會議之後，10 月 10 日星期一和 11 日星期二將舉行 2 天的駭客日，更多資訊和註冊將隨後發布。
有一個 0.13.1 的 PR 隊列，鼓勵審查。

主要議題

segwit-compact blocks BIP
選擇 segwit 推出日期
rpc 同步假設

segwit-compact blocks BIP

背景

BIP152：「Compact block relay」是 0.13.0 中引入的功能，用於透過使用應該在節點記憶體池中的交易的短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也導致減少區塊傳輸延遲。

開發者現在正在開發 compact blocks 的版本 2，它與版本 1 幾乎相同，但支援隔離見證交易。對 BIP 文件的變更提案在這裡。

會議討論

Gmaxwell 一直在進行一些測試。一旦他獲得更大的測試設定，他將呼籲人們在測試網上建立更多 segwit 交易，因為目前沒有很多。

對提議的 BIP 文件的最新提交將「cmpctack」訊息添加到協定中。這的優點是你可以在不實施發送該編碼的情況下實施接收某個版本的 compactblocks，並且稍微簡化協定。這是以稍微複雜化實施為代價的。如果我們不預期添加超過一個或更多版本，這絕對不值得，但是如果我們預期在某個時候推出 compact blocks 版本 4、5、6，這可能值得。

Gmaxwell 指出雖然清理是可以的，但在某些時候更好的升級是引入一個單獨的機制並放棄舊的機制，而不是永遠擴展它，因為那會產生大量技術債務。

會議結論

會議後進一步討論所有選項

選擇 segwit 推出日期

背景

隔離見證（segwit）允許將交易簽名資料儲存在用於產生交易識別碼的雜湊資料之外，移除所有已知形式的第三方延展性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，使輕量級（SPV）客戶端能夠協助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替代 1 位元組的區塊空間，為使用 segwit 的錢包增加交易容量。隔離見證 BIP：BIP141、BIP142、BIP143、BIP144 和 BIP145

隔離見證程式碼已在 0.13.0 中引入，並在測試網上啟用。

會議討論

Gmaxwell 一直在詢問一些分叉關於它們圍繞 segwit 的實施時程表，回應基本上是「在網路中部署之後」。

鑑於 0.13.1 有相當多的工作要做，很難提出推出日期。

Achow101 想知道 segwit 是否會反向移植到 0.12。如 2016/07/14 會議中討論的，不會有 0.12 反向移植，因為它沒有收到要求反向移植的回饋。

會議結論

除非我們有信心，否則不要引入時程表
不要將 segwit 反向移植到 0.12

rpc 同步假設

背景

如 2016/09/01 會議中簡要討論的，當錢包尚未完成處理交易時，存在競爭條件，在 getblockcount/getbestblockhash 回傳新值之前，因此餘額可能不代表該區塊的準確狀態。

會議討論

一些開發者不認為這是錯誤，因為未確認的交易可以隨時出現，與任何區塊無關。如果在錢包處理交易時變更餘額被視為錯誤，它也應該適用於所有其他狀態，例如交易列表。

其他開發者認為這是 API 的變更，將破壞一些 RPC 客戶端，而使錢包餘額呼叫等待它們自己的時間，直到錢包報告的高度與 chainactive 高度匹配，不需要所有使用者審核他們的程式碼庫。

未來錢包區塊處理應該移到背景執行緒。

會議結論

建立關於問題的議題（會議後完成）。
合併快速修復（#8680）以解決 travis 失敗
在會議外進一步討論

趣味環節

BlueMatt          topic: sing morcos happy birthday
luke-jr           morcos: happy birthday https://www.youtube.com/watch?v=dQw4w9WgXcQ

wumpus            happy birthday morcos
kanzure           wumpus: no doxxing :)
petertodd         kanzure: happy birthday to anyone who considers themselves born on this date
kanzure           much better.

btcdrak           unless you are happy with bigger blocks being relayed without it...
btcdrak           anyway. weeds.
sipa              yes, weeds
wumpus            weeds?
sipa              wumpus: "we're getting into the weeds"
wumpus            ohh
CodeShark         in the Netherlands that might have a different meaning ;)

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
petertodd	Peter Todd
jonasschnelli	Jonas Schnelli
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
instagibbs	Gregory Sanders
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
achow101	Andrew Chow
morcos	Alex Morcos
jl2012	Johnson Lau

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-09-01

Thu, 01 Sep 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
剩餘的 0.13.1 議題
nulldummy 和 low_s 軟分叉提案
趣味環節
與會者
免責聲明

筆記 / 簡短議題

0.13 部署似乎沒有遇到問題
Travis 報告了一些議題（8532、8425、8429）。似乎是 Travis 基礎設施造成了一些失敗。fields 還解釋了一個競爭條件：「那裡的問題是節點高度是同步的，但錢包不一定已經更新它們的交易。所以 sync_all() 後跟餘額檢查是有競爭條件的。」

主要議題

剩餘的 0.13.1 議題
nulldummy 和 low_s 軟分叉提案

剩餘的 0.13.1 議題

背景

Bitcoin Core 0.13.0 於 2016/08/23 發布。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。

會議討論

有很多標記為 0.13.1 的 pull request。Wumpus 想知道是否有任何應該優先審查的，因為其中一些有衝突。PR#8393（Support for compact blocks together with segwit）是阻礙項，以及在 2016/08/04 和 2016/08/25 會議中討論的 DoS 議題的解決方案。Sipa 對之前建議的完全驗證所有內容感到不舒服。Luke-jr 和 sdaftuar 喜歡拒絕快取使用見證雜湊而不是 txid 的方法，但這需要重做交易中繼，這是一個很大的變更，並且有一些複雜性，例如複製幾個索引。大多數人喜歡強制使用 feefilter 的想法，儘管它不像其他一些解決方案那樣是萬靈丹。Sipa 想知道是否每個人都同意僅對非見證進行拒絕快取，以及對最常見交易類型檢測無效見證膨脹的啟發式，例如檢查見證程式的嵌入式腳本雜湊是否與見證腳本的雜湊匹配。Luke-jr 認為強制 feefilter 可能會因為費用策略和祖先費率（子付父）的分歧而引起問題，gmaxwell 指出 CPFP 中繼在當前形式的 feefilter 下已經被抑制到最大程度；強制 feefilter 不會使其變得更糟。

BlueMatt 想知道 feefilter 是否不會去匿名化，以及我們是否應該對數量進行一些舍入/隨機化。Gmaxwell 解釋它已經在這樣做了，但我們無法保證具有多個介面的單個節點不能被區分為同一節點，因為有其他幾種方法可以做到這一點。

Jeremyrubin 提到他的 Checkqueue Lockfree 正在通過測試，並希望聽聽人們希望看到什麼才能合併。BlueMatt 指出這為 checkqueue 帶來了 10-20% 的效能改進。

Gmaxwell 希望看到 PR #8594（Do not add random inbound peers to addrman）反向移植到 0.13.1。

會議結論

審查 PR #8499（Check bad witness）和 #8525（Do not store witness txn in rejection cache）

nulldummy 和 low_s 軟分叉提案

背景

延展性的一個來源是 ECDSA 簽名中的 ‘S’ 值，它可以有兩個值，一個高值和一個低值。去年引入了一項策略，要求節點使用 low-s 值（在 2015-10-08 會議中討論）。Sipa 現在提議將其作為共識規則，而不僅僅是策略。

這在 2016/08/11 會議中討論過。

會議討論

這個議題需要重新討論，因為 jl2012 發現 low_s 有一個非常奇怪的實施議題洩漏到語義中，這對於標準性不是問題，但對於共識我們應該更喜歡乾淨的語義。這可以透過執行「only-empty-signature-in-invalid-checksig」軟分叉來實現。Sipa 提議稍後使用空簽名規則執行 low_s 軟分叉，並僅將 nulldummy 與 segwit 綁定。

BlueMatt 詢問是否曾經在鏈中出現過使用 OP_NOT 的非零長度無效簽名。至少有一個案例。BlueMatt 提議在 0.13.1 中將非零長度無效簽名設為非標準。

會議結論

將非零長度無效簽名設為非標準

趣味環節

BlueMatt      but can be OP_NOT'd, no?
sipa          yes, but nobody sane does that
BlueMatt      sure, but /has/ anyone ever done so?
jtimon        BlueMatt: good question, petertodd has anybody done that? :p
sipa          petertodd: have you done that?
petertodd     sipa: me personally, probably not - I'm a fine arts grad :P

BlueMatt      I was informed that non-0-length invalid sigs is not nonstd
gmaxwell      It is non-standard for segwit. (unless I am on drugs.)
sipa          gmaxwell: you're on drugs

cfields       well, as a nasty short-term fix, we can just throw some sleeps in after sync. that should at least shut travis up while we work on a fix
gmaxwell      sleeps for now sound fine to me. We could all use more sleep.

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
petertodd	Peter Todd
jonasschnelli	Jonas Schnelli
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
paveljanik	Pavel Janik
instagibbs	Gregory Sanders
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
BlueMatt	Matt Corallo
jtimon	Jorge Timón

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-08-25

Thu, 25 Aug 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
segwit DoS 保護提案
程式碼簽名
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Paveljanik 要求對他的 Wshadow PR 進行更多審查/ACK：PR#8191、PR#8449、PR#8466、PR#8468 和 PR#8472
Bitcoin Core 0.13.0 已發布。
有一個提案為硬體錢包執行分離簽名制定標準，這將允許將金鑰與錢包解耦。這是為了結束目前由錢包和硬體錢包供應商實施的 API/介面的混亂局面。

主要議題

segwit DoS 保護提案
程式碼簽名

segwit DoS 保護提案

背景

在審查 segwit 時，petertodd 注意到攻擊者可能能夠透過發送具有延展見證資料的交易來使節點對交易視而不見。在議題 #8279 中進一步討論。

會議討論

已經提出了幾種解決方案，包括：驗證所有輸入（即使交易太大或低於費率），不將失敗的見證交易輸入拒絕表，強制使用 feefilter 等。

Gmaxwell 認為所有這些變更都是有益的，驗證所有輸入甚至是在 segwit 被構想之前的提案，我們沒有進行該變更的主要原因是因為即使從合作的對等節點也有很多被拒絕的內容。這應該透過 feefilter 解決。

作為驗證所有內容的替代方案，jl2012 建議隨機驗證某個百分比，因為它允許你拒絕向你發送垃圾訊息的對等節點，但你只承擔一小部分成本。

會議結論

PR#8525：Do not store witness txn in rejection cache
PR#8593：Verify all incoming txs unless too big or too much hashing

程式碼簽名

背景

上週會議討論了簽名和驗證 Bitcoin Core 二進位檔的多種安全增強功能。

會議討論

Cfields 一直在開發一個從 linux 執行的 OSX 程式碼簽名工具，因此發布流程不再需要 OSX 機器。他想知道在像以前一樣實施之前，是否有人對更複雜/分散式的簽名方案有建議。Gmaxwell 希望看看是否容易將多方簽名整合到其中。

Codeshark 想知道 4096 位元 RSA 而不是 2048 位元是否過度。2048 位元大約相當於 128 位元 ECDSA。4096 會更好，因為大小和效能基本上無關緊要，但金鑰的參數由 Apple 選擇。

會議結論

Gmaxwell 和 sipa 將研究 2048 位元 RSA 的閾值簽名，看看我們是否能做到沒有單一方持有該金鑰。
Cfields 將嘗試找出是否可能使用 2048 位元 RSA 以外的其他簽名類型（如 4096 位元金鑰）。

趣味環節

paveljanik         I'd like to ask for more ACKs on Wshadow PRs
gmaxwell           too bad, we haven't started so you can't ask for that yet.
gmaxwell           :P
wumpus             #startmeeting
paveljanik         I'd like to ask for more ACKs on Wshadow PRs
paveljanik         ;-)

wumpus             anything that really needs to be discussed at the meeting?
CodeShark          no, we've already accomplished everything - there's nothing more to do ever

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
petertodd	Peter Todd
jonasschnelli	Jonas Schnelli
CodeShark	Eric Lombrozo
luke-jr	Luke Dashjr
paveljanik	Pavel Janik
instagibbs	Gregory Sanders
MarcoFalke	Marco Falke
jeremyrubin	Jeremy Rubin

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-08-18

Thu, 18 Aug 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
core 內部二進位簽名和驗證工具
0.13.0 正式版
BIP146
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Bitcoin Core 的二進位發布版本仍然以「The Bitcoin Foundation」的名義簽名。Jonasschnelli 想知道我們是否應該嘗試以「Bitcoin Core」的名義獲得新證書。Cfields 正在調查此事，但沒有任何進展。他最好的建議是看看 MIT 是否有興趣協助獲得證書。

主要議題

core 內部二進位簽名和驗證工具
0.13.0 正式版

core 內部二進位簽名和驗證工具

背景

在 Cobra-Bitcoin 在 bitcoin.org 網站上發布安全警告後，更多人詢問如何安全驗證 Bitcoin Core 二進位檔。

會議討論

Jonasschnelli 提議在 Bitcoin Core 套件中添加命令列介面工具來驗證 Bitcoin Core。Btcdrak 認為 GUI 會帶來更廣泛的採用。它將是 Bitcoin Core 發行版中的一個獨立可執行檔。橢圓曲線簽名應該放在 bitcoin/bitcoin 中，否則需要託管在其他地方，這是發布流程的變更。Wumpus 指出 GPG 金鑰已經在儲存庫中。

Kanzure 認為在名稱中包含「next」很重要，以明確驗證工具是為了驗證下一個發布版本。使其成為一旦你有一個好的發布版本，你將永遠擁有好的發布版本。

這將是一個 N-out-of-M 方案，因此有一些空間來容忍被撤銷或被洩露的金鑰。

Jonasschnelli 指出該工具將允許硬體錢包簽署二進位檔，儘管你已經可以透過 GPG 智慧卡執行此操作。許多人透過 yubikey3 使用 GPG。Btcdrak 指出 Ledger Nano S 可以被程式設計來執行簽名，它也有一個即將推出的 GPG 模組，他認為每個人都應該使用某種智慧卡/硬體設備進行 GPG 簽名。

Btcdrak 建議在其他地方鏡像下載，如 Github 和 bitcoincore.org。Wumpus 指出我們已經為不想從 bitcoin.org 下載的人提供 torrent，額外的鏡像不能解決驗證問題。在 Github 上託管二進位檔也會給洩露我們的 Github 提供另一個動機。

Zooko 解釋了一個稱為「二進位透明度」的專案，它允許你將你的雜湊提交到僅附加伺服器。（google-group）Wumpus 指出這不能解決使用者根本不驗證二進位檔的問題，除非作業系統內建對它的支援。

會議結論

Jonasschnelli 將制定一個簡短的設計並將其發布到 bitcoin-core-dev 郵件列表。
開始在發布公告中添加 sha256 雜湊，因為這將確保雜湊的更廣泛分發。

0.13.0 正式版

背景

Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（完整時程表），RC3 自 2016-08-13 起可用。

會議討論

RC3 沒有報告嚴重問題，所以現在可以隨時標記為正式版。

MarcoFalke 在測試網上遇到了問題，這可能是發布阻礙。（會議後檢測到問題，並認為不是發布阻礙）

Gitian 建構可以在週末開始。

鑑於 0.13.0 延遲，Wumpus 想知道我們是否應該延遲設定 0.14 發布時程表。每個人都同意目前的 6 個月時程表很好，0.14 應該在 0.13.0 發布後立即安排。

會議結論

審查 bitcoincore.org 上的 0.13.0 部落格文章
開始 gitian 建構

BIP146

背景

BIP146：處理簽名延展性。LOW_S 和 NULLDUMMY 長期以來在網路上一直不符合標準，並且不出現在鏈上。由於它們都很簡單，BIP146 提議與 segwit 一起執行此軟分叉。Low_S 在上週會議中討論過。

會議討論

BIP 提案已發送至郵件列表（正式會議時間後：）Bluematt 仍然執行一個節點，該節點自動將 high-s 交易延展為 low-s，他仍然收到很多 high-s 交易（約每小時 1 筆）。不過這也可能是有人將原本的 low-s 交易延展的。

會議結論

將 BIP146 與 segwit 一起執行

趣味環節

gmaxwell         If it does https I will nak it so hard keys will fall of the keyboard.

*discussion about different hosting for binaries*
sipa             let's use sourceforge *ducks*

wumpus           however the announcement of cobra this morning felt like someone dropped a bomb on the release process, and 'infected' 0.13.0 in people's minds before it is even released
cfields          wumpus: tag it as 0.13.0.1 :)

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
warren	Warren Togami
jonasschnelli	Jonas Schnelli
jl2012	Johnson Lau
luke-jr	Luke Dashjr
achow101	Andrew Chow
instagibbs	Gregory Sanders
MarcoFalke	Marco Falke
zooko	Zooko Wilcox
BlueMatt	Matt Corallo
kadoban	Joshua Simmons
sdaftuar	Suhas Daftuar
adam3us	Adam Back

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-08-11

Thu, 11 Aug 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
軟分叉以要求 low-s
0.13.0 RC3
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Jtimon 要求對 PR #8493（Untested: libconsensus: Expose VerifyHeader）進行一些程式碼審查。
Jl2012 建議進行一些變更以防止 segwit 的 DoS 攻擊（PR #8499），sipa 詢問關於添加每個 txin 見證大小限制策略的意見。Luke-jr 指出匹配 P2SH 共識限制對於 N-of-15 多簽來說太小，所以可能需要稍微大一點的限制。Sipa 將在下次會議前提出提案。
Sipa 提醒注意不同的標誌集，即強制標誌、共識標誌和標準性。發送違反強制規則的交易的節點將被封禁，如果有節點中繼這些交易，這會導致網路分區。

主要議題

軟分叉以要求 low-s
0.13.0 RC3

軟分叉以要求 low-s

背景

會議討論

High-s 交易已經長期不符合標準，並且超過一年沒有出現在網路上。由於這不具爭議性且易於實施（一行程式碼），主要問題是與 segwit 同時部署還是分開部署。Sipa 認為作為單獨的軟分叉可能很難做到這一點，因為它的收益很低，而礦工仍需要更新他們的軟體。GreenIsMyPepper 和 sipa 指出在 segwit 中永遠不要有 high-s 值會更乾淨。

會議結論

將 low-s 規則的執行與 segwit 結合在一起。

0.13.0 RC3

背景

Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（完整時程表），RC3 自 2016-08-13 起可用。

會議討論

Wumpus 想知道是否還有任何需要合併/反向移植到 0.13.0 的內容。

Luke-jr 想要做一個 PR 來在 segwit 未啟動時將 blockmaxsize 對應到 blockmaxweight，以使 PR #8459 不具爭議性。

有一個關於 0.13.0 的部落格文章 PR，可以使用審查。

Cfields 想知道是否應該在 0.13.0 中將 default_witness_commitment 添加到帶有見證資料的 GBT 中。Sipa 認為 0.13.0 上的礦工永遠不應該產生 segwit 承諾，這樣我們就不會在遠離更新軟體的時間點出現突然的行為變更，這可能會破壞下游挖礦基礎設施，gmaxwell 補充說。

會議結論

審查部落格文章

趣味環節

wumpus          can anyone do the giant highlight list?
cfields         gmaxwell: paging bot
gmaxwell        #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
michagogo       cfields: I think last time he said it's not a bot...
wumpus          michagogo: all bots say that!

jtimon          yay 0.13.0!
gmaxwell        jtimon: careful, you're going to trigger some confused reddit posts.
jtimon          oops, sorry, yay ack rc3

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
GreenIsMyPepper	Joseph Poon
jonasschnelli	Jonas Schnelli
jl2012	Johnson Lau
luke-jr	Luke Dashjr
jtimon	Jorge Timón
instagibbs	Gregory Sanders

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-08-04

Thu, 04 Aug 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.0
segwit 記憶體池延展性 DoS
與會者
免責聲明

筆記 / 簡短議題

幾位開發者和礦工在舊金山見面，他們前往史丹佛大學會見應用密碼學和電腦安全研究員 Dan Boneh。雖然與短期開發無關，但由 kanzure 製作的文字記錄具有非常高的訊噪比。
NicolasDorier 建立了一個 IRC ##libconsensus bikeshedding 聊天室，討論如何處理 libconsensus。設計將呈現給更大的群體以獲得回饋。

主要議題

0.13.0
segwit 記憶體池延展性 DoS

0.13.0

背景

Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（完整時程表），RC2 自 2016-07-31 起可用。

會議討論

Sipa 注意到我們忘記反向移植 PR #8438/#8365（Treat high-sigop transactions as larger rather than rejecting them）。#8438 可以等到 0.13.1。

Luke-jr 指出發布說明在 blockmaxsize/blockmaxweight 方面仍然不恰當，wumpus 回覆他應該調整他的 PR 以僅變更發布說明。Gmaxwell 和 sipa 仍需要在發布說明中添加一些內容。

Luke-jr 想知道從 0.13.1 降級的失敗模式應該是什麼，以及是否需要為此進行變更。它應該給出硬錯誤或重新索引。如果它還沒有這樣做，可能值得再做一個 RC，包括修復此問題和 #8438。

會議結論

檢查是否真的需要降級保護

segwit 記憶體池延展性 DoS

背景

在審查 segwit 時，petertodd 注意到攻擊者可能能夠透過發送具有延展見證資料的交易來使節點對交易視而不見。在議題 #8279 中進一步討論。

會議討論

Sipa 更傾向移除「無效見證不會導致插入拒絕快取」規則，理由是它所做的只是防止攻擊者向你隱藏有效交易，但它並不能完全防止，因為他們可以宣布但永遠不發送交易。

Bluematt 想知道對於 segwit 節點使用 txid 而不是 wtxid 進行 inv’ing 的理由是什麼。Sipa 澄清這會複製很多邏輯（記憶體池、孤立、快取等），並且至少會造成潛在的加倍，因為你可能會從 pre-segwit 和 post-segwit 節點收到相同交易的 inv，一次使用 txid，一次使用 wtxid，而無法判斷它們是相同的。使用 txid 和 wtxid 進行 inv’ing 是一個解決方案，但如果我們採用這種方式，我們也應該將資源資訊添加到所有 inv（費用、大小、sigops 等），sipa 補充說。

Morcos 提議強制使用 feefilter，完全驗證交易，這樣我們就可以懲罰向我們發送無效內容的對等節點。不要將任何見證交易放入拒絕快取，然後評估拒絕快取繼續有用的程度，或者是否有違反策略的 segwit 交易在彈跳。Sipa 喜歡這個想法，但認為這對 0.13.1 來說是一個很大的變更。

對此沒有明確的解決方案。

會議結論

從「不要將任何見證交易放入拒絕快取」開始

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
jeremyrubin	Jeremy Rubin
luke-jr	Luke Dashjr
jtimon	Jorge Timón
morcos	Alex Morcos
instagibbs	Gregory Sanders
NicolasDorier	Nicolas Dorier
BlueMatt	Matt Corallo
MarcoFalke	Marco Falke

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-07-28

Thu, 28 Jul 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.0
為 master 替換 boost threads/sync
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Jtimon 希望看到上週會議中討論的 ISM 移除能快速合併，因為它對其他 libconsensus 重構很重要。
NicolasDorier 要求審查/測試 PR #8422（Cache hashes），該 PR 需要在 segwit 發布之前合併並反向移植到 0.13。

主要議題

0.13.0
為 master 替換 boost threads/sync

0.13.0

背景

Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（完整時程表），RC2 自 2016-07-31（會議後 3 天）起可用。

會議討論

PR #8408，修復 compactblocks 中的錯誤，是唯一剩下的標記為 0.13 的事項。

Jtimon 做了 PR #8412，他認為應該包含在 0.13 中。所有人都同意。

Luke-jr 重申發布說明有一個不良策略，鼓勵將 blockmaxsize 變更為 blockmaxweight，他為此有一個 pull request，包括一些程式碼變更。Wumpus 指出並非所有人都同意什麼是「不良策略」。Luke-jr 認為如果是這樣的話，發布說明不應該推薦任何東西。Gmaxwell 認為我們仍然使用不反映近乎普遍網路使用情況的預設設定來發布是愚蠢的，因為實際上幾乎每個礦工都會將 blockmaxsize 和 blockmaxweight 設定為允許的最大值。預設值一直是 750k，但看不到 750k 的區塊。（在討論的這一點，luke-jr 必須趕飛機）

Wumpus 認為這些設定的一個積極後果是它迫使礦工不使用預設設定。Gmaxwell 還指出變更 blockmaxweight 的值更為複雜，因為它需要是所需 blockmaxsize 的 4 倍，在發布說明中解釋如何將其設定為最大值可能被視為一種推薦。Eliel_ 建議使挖礦部分拒絕在使用者未手動設定所需配置值的情況下運作，從而避免設定預設值，這是 luke-jr 多年來主張的。

會議結論

審查 PR #8408（Prevent fingerprinting, disk-DoS with compact blocks）

為 master 替換 boost threads/sync

背景

Bitcoin Core 正在努力移除對 boost 函式庫的依賴。Cfields 有一個準備好的 pull request 來擺脫 boost threads。

會議討論

Cfields 詢問他應該一次做一個替換，還是一次全部完成。Wumpus 表示一次全部完成最有意義，使其成為一次性的痛苦。

#8023 有一個先決條件，他將在會議後為此做一個 pull request。

Cfields 也仍在進行網路重構，審查/ACK PR #8128 和 #8085 將有所幫助。

會議結論

審查 PR #8128 和 #8085（”Net: Turn net structures into dumb storage classes” & “p2p: Begin encapsulation”）

趣味環節

lightningbot      Meeting ended Thu Jul 28 20:00:26 2016 UTC.
jonasschnelli     sipa: time for your Pokemon walk. :P

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
achow101	Andrew Chow
luke-jr	Luke Dashjr
jtimon	Jorge Timón
morcos	Alex Morcos
instagibbs	Gregory Sanders
NicolasDorier	Nicolas Dorier
Eliel_	Eliel_

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-07-21

Thu, 21 Jul 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.0
移除 ISM
sigops 最大大小和每位元組 sigops 限制
趣味環節
與會者
免責聲明

筆記 / 簡短議題

0.13 已在幾天前從 master 分支出來。
Jeremyrubin 一直在進行 checkqueue.h 的重構，包括一些不錯的改進。Cfields 一直在優化 sigcache，並提議一起合作提出一個良好的代表性基準來測試改進。
目前錢包程式碼透過使用 txminRelayFee 來防止建立低於粉塵的輸出。去年在 PR#6793 中提升此值時，一些交易無法再中繼，對使用者造成了一些壓力。NicolasDorier 正在 PR#8356 中努力避免未來出現此類問題。

主要議題

0.13.0
移除 ISM
sigops 最大大小和每位元組 sigops 限制

0.13.0

背景

Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（完整時程表），RC1 自 2016-07-20 起可用。

會議討論

RC1 收到了一些回饋，注意到在加密錢包時，它使用相同的 HD 種子，這意味著在建立錢包時 HD 種子已經未加密地存在磁碟上。Jonasschnelli 正在進行修復，在加密錢包後建立新的 HD 種子。

一個常見的抱怨是缺乏匯出 HD 種子的方法。Jonasschnelli 有一個pull request，易於審查且影響較低，將種子匯出到 dumpwallet。匯入是一個不同的問題，影響更大，因為錢包目前不支援多個種子。這是 0.14 的功能。

Luke-jr 指出新的預設策略使用 blockmaxweight 在當前環境中的表現不如使用 blockmaxsize。他做了一個 pull request 來改變這一點。這是一個相當大的變更，需要更多討論。

會議結論

審查 PR #8206

移除 ISM

背景

在 BIP9 之前，軟分叉是透過 isSuperMajority（ISM）機制完成的，意思是當最後 1000 個區塊中的 95% 的版本號高於 X 時，分叉就會部署。BIP68、BIP112 和 BIP113 同時使用 BIP9 部署。

會議討論

NicolasDorier 做了一個 pull request 來移除 ISM 並在 regtest 中硬編碼由 ISM 產生的軟分叉。

Gmaxwell 想在 0.13 中移除 ISM，但不想引入與 segwit 合併的衝突，所以他擱置了它。

討論很快偏離到與重構相關的議題。

會議結論

審查 PR#8391
在重構其程式碼之前移除 ISM

sigops 最大大小和每位元組 sigops 限制

背景

為了防止簽名操作（SIGOPS）攻擊，開發者引入了 bytespersigop 選項來限制我們中繼和挖掘的交易中的 sigops 數量。這在 2015-11-05 會議中討論過。

有人抱怨這個限制使得一些裸多簽輸出難以花費。

會議討論

對此有兩個提議的解決方案：一個由 sipa 提出，一個由 f139975 提出。Sipa 認為後者使其變得不必要地複雜，但除此之外並不強烈反對。

Luke-jr 認為引入限制的原因是為了過濾垃圾訊息，允許高 sigops 交易但收取高額費用等於隱含地認可不必要地使用大量 sigops。Gmaxwell 不同意，並表示他不會支援為了過濾目的而設定的限制。目前為了繞過限制，他們膨脹交易以獲得更多 sigops，PR #8365 將修復這一點，sdaftuar 認為我們可以在長遠考慮更好的策略。

隨後進行了一些討論，關於這些交易是否應該被視為垃圾訊息。

會議結論

查看 PR #8364 和 #8365

趣味環節

19:59	lightningbot    Meeting ended Thu Jul 21 19:59:17 2016 UTC
20:03	sipa            ok, i'm going to catch some pokemon
20:03	sipa            i mean
20:03	sipa            i'm going for a walk

與會者

IRC nick	Name/Nym
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
kanzure	Bryan Bishop
cfields	Cory Fields
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
MarcoFalke	Marco Falke
luke-jr	Luke Dashjr
jtimon	Jorge Timón
morcos	Alex Morcos
instagibbs	Gregory Sanders
jeremyrubin	Jeremy Rubin
CodeShark	Eric Lombrozo
NicolasDorier	Nicolas Dorier
BlueMatt	Matt Corallo

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-07-14

Thu, 14 Jul 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.0 rc1
Segwit 反向移植
趣味環節
與會者
免責聲明

筆記 / 簡短議題

需要更好的 -blockmaxcost 選項文件，但有人指出這是一個糟糕的名稱，因為使用者認為「最大成本」是關於貨幣成本。翻譯人員也以這種方式翻譯它。「區塊成本」一詞也用於 segwit BIP 中，sdaftuar 提議變更 BIP 中的描述。與會者同意將 blockmaxcost 重新命名為 blockmaxweight。
Gmaxwell 指出他在 reddit 上收到一些回覆，指出 bitcoin core 的錢包對商業用途無法使用，大多數人使用集中式 API 提供商。不幸的是，商業使用者通常不會報告他們遇到的問題，他不知道如何改善這一點。
Bsm117532 詢問是否有人正在進行移除「帳戶」的工作。Wumpus 嘗試為 0.13 引入標籤 API 來取代它，但沒有獲得足夠的審查。

主要議題

0.13.0 rc1
Segwit 反向移植

0.13.0 rc1

背景

Bitcoin Core 團隊正在朝 0.13.0 RC1 努力。（完整時程表）

會議討論

大多數剩餘的 pull request 已合併，但仍有一些需要為 0.13.0 修復的開放 PR。Jonasschnelli 開啟了 PR #8323，他建議將其納入 0.13.0 以避免識別 HD/非 HD 金鑰的問題。

發布說明並不緊急，因為它們需要在最終版本完成，而不是 RC1。

會議結論

審查 #8323（Add HD keypath to CKeyMetadata, report metadata in validateaddress）
審查 #8305（Improve handling of unconnecting headers）
審查 #8295（Mining-related fixups for 0.13.0）

Segwit 反向移植

背景

開發者正在開發軟分叉以將隔離見證引入比特幣主網。隔離見證（segwit）允許將交易簽名資料儲存在用於產生交易識別碼的雜湊資料之外，移除所有已知形式的第三方延展性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，使輕量級（SPV）客戶端能夠協助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替代 1 位元組的區塊空間，為使用 segwit 的錢包增加交易容量。隔離見證 BIP：BIP141、BIP142、BIP143、BIP144 和 BIP145

會議討論

一些人對將 segwit 反向移植到 0.12 表示擔憂。Morcos、jl2012 和 btcdrak 認為收益不值得開發者時間成本以及反向移植中增加的錯誤風險。如果反向移植沒有獲得足夠的審查和測試，就不會有發布版本，但是如果反向移植和審查無法通過標準，對某些人來說犧牲時間將是一種遺憾。

擔憂在於我們不想強迫人們快速採用 0.13 衍生程式碼只是為了趕上 segwit。

現在的優先事項是 0.13 發布版本，幾乎沒有人使用反向移植。

Petertodd 建議在 0.13.0 的發布說明中詢問人們讓開發者知道是否想要包含 segwit 的 0.12.2 發布版本。他還指出人們可以在 0.13+segwit 節點後面執行 0.12 節點，但是礦工無法用該設定挖掘任何 segwit 交易。Gmaxwell 指出擁有部署指南可能會很有用，顯示諸如這種分層和測試基礎設施的內容，因為擁有雙層設定是一種良好的做法，作為一種不將生產節點暴露在網際網路上的方式。

會議結論

在進行 segwit 0.12 反向移植發布之前等待使用者回饋。

趣味環節

<sipa>        well, any reason not use vsize?
<petertodd>   sipa: vsize is fine
<wumpus>      yes vsize is fine
<gmaxwell>    V means validation?
<sipa>        virtual
<btcdrak>     v for vendetta

與會者

IRC nick	Name/Nym
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
achow101	Andrew Chow
cfields	Cory Fields
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
MarcoFalke	Marco Falke
luke-jr	Luke Dashjr
jtimon	Jorge Timón
morcos	Alex Morcos
instagibbs	Gregory Sanders
maaku	Mark Friedenbach
jeremyrubin	Jeremy Rubin
CodeShark	Eric Lombrozo
jl2012	Johnson Lau
bsm117532	Bob McElrath

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-07-07

Thu, 07 Jul 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.0 rc1
FIBRE 公告
- 背景
- 會議討論
趣味環節
與會者
免責聲明

筆記 / 簡短議題

Gmaxwell 指出他仍希望在 RC 期間看到獨立的測試網預設二進位檔。Wumpus 指向他錯過的一個 PR，該 PR 使安裝測試網客戶端變得非常容易。

主要議題

0.13.0 rc1 與 HD 錢包議題
FIBRE 公告

0.13.0 rc1

背景

Bitcoin Core 團隊正在朝 0.13.0 RC1 努力。（完整時程表）

會議討論

有幾個議題需要為 0.13.0 修復。Wumpus 無法建構發布版本，因為 gitian lxc 建構已損壞，如此議題所述（會議後一天找到了解決方法）。對於 0.14，我們可以切換到 ubuntu 16.04，該版本已修復此問題。

Sdaftuar 有一些針對 0.13.0 的 PR 開放，缺乏一些審查，即 #8305（headers 同步議題）、#8312（segwit 合併後的記憶體池 DoS）和 #8295（segwit 合併後的挖礦程式碼修復）。

在測試新的階層式確定性（HD）錢包時，MarcoFalke 遇到了問題。要麼是他的測試程式碼中的錯誤，要麼是 IsMine() 的問題。如果沒有明確的答案解釋為什麼會發生這個問題，最好在 0.13 中停用 HD 錢包。

在會議結束前，Jonasschnelli 已經在 MarcoFalke 的測試程式碼中找到了錯誤。修復的測試將包含在 0.13.0 中。

會議結論

審查 0.13.0 的開放議題
為 sdaftuar 的 PR 加上 0.13.0 里程碑標籤

FIBRE 公告

背景

Matt Corrallo 宣布了他的新中繼網路工作，使用 UDP 和 FEC，目前尚未完全成熟的軟體在 99% 的時間內能在光纖路徑距離上實現不到 100 毫秒的全球區塊傳播。

更多資訊可以在網站 http://bitcoinfibre.org/ 上找到。

會議討論

在他的部署中，他只使用便宜的 VPS。他正試圖讓其他人建立平行網路並提供詳盡的指南，包括獲得亞洲和歐洲之間低延遲連線的途徑。

連結：github 專案和中繼網路統計

趣味環節

9:30 pm   wumpus          any other topics?
9:31 pm   gmaxwell        Sure, an announcement:
9:31 pm   sipa            *crickets*
9:31 pm   jonasschnelli   oO
9:32 pm   petertodd braces for an incoming text wall

petertodd     wumpus: happy halving day :)
wumpus        hah, same to you
gmaxwell      I wonder if there is some sci-fi where halving day is where half the people die? it seems right.
petertodd     I'll be hiding in a cave most of that day fyi - so if the world ends don't call me :P
petertodd     gmaxwell: Satoshi should have made it a 10% thing, so we could call it DECIMATION DAY
wumpus        petertodd: that sounds like a wise thing to do, hide in a cave until it blows over
sipa          I wish i had a cave here
sipa          I'm in the middle of Paris
sipa          and there is some football thing
petertodd     sipa: you've got the most awesome sewer system, and the catacombs!

與會者

IRC nick	Name/Nym
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
achow101	Andrew Chow
cfields	Cory Fields
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
MarcoFalke	Marco Falke

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-06-30

Thu, 30 Jun 2016 00:00:00 +0000

概覽

筆記 / 簡短議題
主要議題
0.13.0 的挖礦相關變更
Segwit
Dbcache
趣味環節
與會者
免責聲明

筆記 / 簡短議題

許多人正在測試網上測試 segwit + BIP152。目前還沒有相關的 PR，因為這允許測試與非 segwit-BIP152 的互動，並且需要一些 BIP 變更（在 BIP144、BIP152 或單獨的 BIP 中）。最好在 segwit 啟動之前就準備好，否則 compact blocks 會突然停用。

主要議題

0.13.0 的挖礦相關變更
Segwit
Dbcache

0.13.0 的挖礦相關變更

背景

Sdaftuar 在一個議題中提到了一些他認為應該在 0.13.0 中解決的挖礦相關事項。PR #8295 被建立來解決這些問題。

會議討論

Blockminsize（設定最小區塊大小）不受 segwit 的封包選擇程式碼支援。由於這個功能對任何人都不再相關，移除它是合理的。目前保留 blockminsize 和 blockmaxsize 的原因是新演算法因缺少會計而無法運作。Sdaftuar 指出這在 #8295 的第一個提交中已解決。當給定 blockminsize 參數時，不應導致失敗，而應給出警告。

AddScoreTxs，舊的交易選擇演算法，可以被移除，因為新的封包選擇演算法絕對優越。Sdaftuar 指出如果我們這樣做，mining_score 可以從記憶體池 multiIndex 中移除，這將在記憶體池中節省一些記憶體。然而這不是優先事項，可以等到 0.14。

發布說明需要為所有挖礦變更撰寫大量內容。

會議結論

移除 -blockminsize 並在給定該參數時發出警告
更新發布說明中的挖礦變更

Segwit

背景

會議討論

在他的審查期間，petertodd 發現了由於延展交易造成的潛在記憶體池 DoS 風險（議題 8279）。

Gmaxwell 提議在驅逐保護邏輯中將低 dos 分數作為排名標準，這將使以非常高的 DoS 閾值執行更加合理。Sipa 指出如果進行這些變更，DoS 分數也應該隨時間衰減，否則較長時間的連線將累積它們不應得的分數。

Petertodd 希望看到某些節點有不同的閾值期間，這樣雖然不會在所有人身上浪費頻寬，但仍然保持與少數對等節點的連線。Gmaxwell 指出這樣的事情可以將這些對等節點轉變為僅區塊模式，因為這是我們關心的反分區所需的全部，並且幾乎完全消除了 DoS 的擔憂。

Sipa 認為可能有理由引入類似「資源使用分數」的東西，它與「不當行為」不同，用於決定斷開哪些對等節點以支持其他節點，但永遠不會導致封禁。

Gmaxwell 指出 bitcoinXT 最近開始僅與其他 XT 節點建立出站連線，這與 segwit 結合將使它們分區。已在 XT 儲存庫中為此建立了議題。

會議結論

腦力激盪連線管理相關事項

Dbcache

背景

Gmaxwell 在使用預設 dbcache 進行測試時注意到重新索引非常緩慢，sipa 也確認了這點，他看到了類似的行為。這在上週的會議中提出。

會議討論

Wumpus 建立了 PR #8273 將預設 dbcache 提升至 300 MiB，並將 leveldb 特定快取的配置上限設為 32 MiB，這是目前 100 MiB 的預設值。Gmaxwell 的測試確認 leveldb 快取大小沒有太大影響，但在啟用 txindex 時它們有更多影響。他還注意到即使是 300 MiB 的 dbcache 實際上也不夠大以提供良好的重新索引效能，並提議在 0.14 中考慮在重新索引/初始區塊下載期間將記憶體池記憶體分配給 dbcache。

Jonasschnelli 的測試顯示，master 的重新索引幾乎是從頭開始正常初始區塊下載的兩倍長。他在啟用 -debug 的情況下執行測試，所以可能扭曲了基準測試。他還注意到錯誤 potential_deadlock_detected 每隔幾分鐘就會停止他的節點。他為此建立了一個議題。

會議結論

進一步的基準測試

趣味環節

gmaxwell       <meme text="Delete all the code."/>

wumpus         sipa: attenuating theDoS score over time makes sense, a very slow DoS attack isn't really a DoS attack
sipa           theDos? sister of [GLaDoS](https://en.wikipedia.org/wiki/GLaDOS)?
wumpus         the cake is a lie

gmaxwell       Hurrah we ended early. :p
jonasschnelli  1min! :)
gmaxwell       May your usage of the remaining minute be productive.

與會者

IRC nick	Name/Nym
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
btcdrak	BtcDrak
jtimon	Jorge Timon
CodeShark	Eric Lombrozo
sdaftuar	Suhas Daftuar
jonasschnelli	Jonas Schnelli
kanzure	Bryan Bishop
jl2012	Johnson Lau

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-06-23

Thu, 23 Jun 2016 00:00:00 +0000

概覽

主要議題
感知到的驗證速度減緩
Segwit
趣味環節
與會者
免責聲明

主要議題

感知到的驗證速度減緩
Segwit

感知到的驗證速度減緩

背景

Gmaxwell 在使用預設 dbcache 進行測試時注意到重新索引非常緩慢，sipa 也確認了這點，他看到了類似的行為。

會議討論

Sipa 注意到鏈狀態寫入非常緩慢，但這可能是因為他的磁碟設定。我們仍需要找出這背後的確切原因，但提高 dbcache 的預設值並改變其配置方式是個好主意，因為目前很大一部分分配給了 leveldb 快取，但需要進一步的基準測試來找出最佳值。

Gmaxwell 將針對修補版的 0.12.1 進行測試，該版本跳過區塊 295000 之前的簽名檢查，以查看是否有任何退步或這是正常行為。

這些測試是在合併 compact blocks 之前完成的，所以不會受到影響。Leveldb 最近沒有任何變更，所以 leveldb 成為問題的唯一方式是它跨越了某個效能懸崖。

Sipa 指出測試是在啟用 txindex（維護完整交易索引）的情況下完成的，效能可能受到影響。

會議結論

Gmaxwell 將對不同配置進行基準測試：0.12.1 vs master、txindex 啟用/停用、dbcache 預設/較高以及不同的快取分配。

Segwit

背景

會議討論

Segwit 在合併 compact blocks 後已重新基底。

Sipa 一直在執行 compact blocks + segwit，沒有看到對記憶體使用的影響。

所有人都贊成合併 segwit。（會議後已合併）

Gmaxwell 建議我們應該立即發布「測試網二進位檔」，預設啟用測試網，以讓更多人進行測試。到目前為止，segwit 測試主要由技術人員完成，他們不太可能被 UI 狀態變更等問題困擾。

在測試網上啟動 segwit 是一個非常有用的測試演練，因為它是在大多數節點未升級的環境中進行的。

會議結論

合併 segwit
發布預設/僅限測試網的二進位檔

趣味環節

wumpus      meeting time?
sipa        present
gmaxwell    past?

petertodd   sipa: re: segwit, has it been rebased?
sipa        petertodd: 12 times by now
CodeShark   lol
CodeShark   poor sipa
wumpus      sipa is getting carpal tunnel syndrome from rebasing

lightningbot   Meeting ended Thu Jun 23 19:49:58 2016 UTC.
jtimon      oh, I think we forgot to make a joke, that's bad for the summaries :p

與會者

IRC nick	Name/Nym
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
instagibbs	Gregory Sanders
btcdrak	BtcDrak
jtimon	Jorge Timon
CodeShark	Eric Lombrozo

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-06-16

Thu, 16 Jun 2016 00:00:00 +0000

概覽

主要議題
緊湊區塊和功能凍結
Segwit 更新
0.13 中的 RBF 替換
GetBlockTemplate (GBT)
參與者
免責聲明

主要議題

緊湊區塊和功能凍結
Segwit 更新
0.13 中的 RBF 替換
GetBlockTemplate (GBT)

緊湊區塊和功能凍結

背景

BIP152：「緊湊區塊中繼」是一個提議的想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。閱讀緊湊區塊常見問題解答以獲取更多資訊。

會議評論

Sipa 提議將功能凍結推遲一週，以穩定緊湊區塊和 segwit。Wumpus 不喜歡這個想法，因為功能凍結已經推遲了一個月。Sdaftuar 認為緊湊區塊現在還沒有準備好，因為它仍然有未解決的問題。Wumpus 指出合併後仍然可以修復錯誤，因為候選版本 1 是在 7 月 7 日。

沒有人希望看到沒有緊湊區塊的 segwit，因為區塊將變得實際上更大。

會議結論

再有一週時間修復錯誤，並在下週四重新評估。

Segwit 更新

背景

開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：BIP141、BIP142、BIP143、BIP144 和 BIP145

會議評論

Sipa 認為除了使其與緊湊區塊合作之外，不會有任何進一步的變更。問題是在緊湊區塊之前還是之後合併 segwit。緊湊區塊審查起來較小，審查也比 segwit 少，但另一方面，segwit 不受功能凍結的約束，因為它只需要在 master 中，而不是在 0.13.0 中。但是在 0.13.0 之前合併它會使事情更可測試/更經過測試。

Sipa 指向 PR #8149，其中提交按 BIP 組織，對某些人來說審查它並只 ACK 其中某些部分可能是有意義的。他在評論中有一個按部分組織的提交列表，他會保持更新。

會議結論

對緊湊區塊和 segwit 進行更多審查

0.13 中的 RBF 替換

背景

BIP125 選擇性 replace-by-fee (RBF) 是 0.12 以來的新功能，它使錢包能夠在交易仍在記憶體池中時將其標記為可替換。這允許錢包提高費用、新增接收者等。更多資訊可以在 RBF 常見問題解答頁面上找到。目前 bitcoin-core 錢包不提供任何使用這些功能的功能。

會議評論

Jonasschnelli 認為我們應該在 0.13 中為錢包提供替換選項。他希望對 PR #8182 進行審查，這是一個 GUI bumpfee 命令。每個人都希望看到費用提升選項，但現在已經很晚了，將緊湊區塊和 segwit 合併可能已經足夠擔心下週了。

Petertodd 建議至少將他的全域選擇性設定合併，這樣需要 RBF 的人可以輕鬆使用外部腳本來實現。

會議結論

審查 PR #7132

GetBlockTemplate (GBT)

背景

Getblocktemplate 是新的去中心化比特幣挖礦協議，由比特幣社群在 2012 年中期公開開發。它取代了舊的 getwork 挖礦協議。（Wiki-連結）

會議評論

Luke-jr 詢問一旦 segwit 啟動，GBT 應該如何對 pre-segwit 礦工做出反應。目前它會出錯，這會導致礦工故障轉移或停止。或者，您可以挖掘沒有任何見證交易的區塊或返回空區塊。空區塊總體上不太理想，但更有可能被注意到和升級，並且不會帶來太多程式碼複雜性。

Sdaftuar 指出如果故障轉移到舊守護程式，這些區塊將被孤立，這也會被注意到。這是因為 segwit 節點將嘗試從見證對等節點下載區塊，因此非見證區塊不會被中繼。然而 Petertodd 指出，網路中只有一個節點橋接非見證和見證對等節點之間的差距，就會使它中繼。

會議結論

保持目前行為，如果礦工抱怨則重新考慮。

參與者

IRC nick	Name/Nym
Luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
instagibbs	Gregory Sanders
btcdrak	BtcDrak
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
BakSAj	BakSAj
phantomcircuit	Patrick Strateman
achow101	Andrew Chow

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-06-09

Thu, 09 Jun 2016 00:00:00 +0000

概覽

主要議題
註記 / 簡短議題
編譯時間 / 記憶體使用量
Segwit 更新
緊湊區塊測試
娛樂時刻
參與者
免責聲明

主要議題

編譯時間 / 記憶體使用量
segwit 更新
緊湊區塊測試

註記 / 簡短議題

Bitcoin Core 的功能凍結預定在下週，所有需要合併的功能都應該在那之前合併。Cfields 有 2 個 p2p 重構 PR 他希望合併，這些可以在凍結後完成，因為那些不是新功能。
在上次會議的評論關於軟體生命週期頁面之後，Btcdrak 和 David Harding 一直在努力更新該頁面，使其更清晰和更具代表性，在這裡以及進一步在這裡，這需要審查。

編譯時間 / 記憶體使用量

背景

問題 6658（建置需要 >1GB 記憶體）和 7471（用 512 MB RAM 建置沒有太多空間）討論了編譯時對 RAM 的需求不斷增加。

會議評論

Gmaxwell 指出我們不能再使用預設設定在僅有 2GB RAM 的主機上編譯，而我們的文件說 1.5GB。

TheBlueMatt 準備了一個補丁，將所有記憶體池內容移出，顯然可以將其恢復到 1.5GB。但他還沒有提出 pull request。

Wumpus 指出使用 Clang 建置通常在相同編譯設定下使用的記憶體要少得多。

編譯時間可能與記憶體使用量相關，因為磁碟尋找/讀取存取可以忽略不計。

為 ARM 和 AARCH64 新增二進位建置將減少關於記憶體問題的抱怨。Cfields 正在致力於此。使用者目前可以使用交叉編譯，但是 gmaxwell 指出許多使用類似 raspberry pi 系統的人沒有另一個 linux 主機。

會議結論

Cfields 計劃為 0.13 新增不帶 GUI 的 ARM 二進位檔案（會議後在 PR #8188 中完成）

Segwit 更新

背景

會議評論

在程式碼減去軟分叉可以進入 0.13 之前，仍有一些錯誤需要修復。Sipa 指出下一批補丁將解決所有問題。

Luke-jr 希望最大見證程式長度為 75 位元組，而不是現在的 40 位元組。他認為沒有必要限制（低於 75，因為高於 75 將需要更多變更和額外測試），較小的限制很可能會阻止未來的軟分叉。稍後擴充限制將需要硬分叉。Sipa 認為應該不需要超過 256 位元雜湊 + 一些版本控制中繼資料，設定更多會給人一種印象，或者正如 petertodd 所闡述的：會給人一種印象，比特幣比那更破碎。Gmaxwell 加入並認為他看到的最大危害是允許更大的大小可能會限制未來使 UTXO 條目大小受限的能力。但是進一步限制可以稍後發生。他還指出將來可以透過使用不同的版本類型信號來擴充這一點，但這將需要除了當前承諾之外的新承諾。

會議結論

討論繼續，並被推遲到會議外。

緊湊區塊測試

背景

BIP152：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。

會議評論

公共網路上有許多節點執行緊湊區塊，一切似乎運作良好。Instagibbs 製作了一個圖表。Gmaxwell 一直在執行修改版本的測試，將雜湊大小減少到 16 位元，透過使碰撞更常見來測試圍繞碰撞的罕見邊緣情況。兩個大型礦池一直在執行它，其中一個位於中國的防火長城後面。

Cfields 想知道是否討論過緊湊區塊的服務位元。之前提出的論點是服務位元應該僅用於關鍵所需的服務。由於它可能會足夠快地變得普遍，所以不需要。只有礦工才真正需要它，但他們無論如何都應該手動管理他們的連接。

會議結論

與區塊擷取邏輯的互動需要更多審查。
審查者應該停止使用 sipa 的分支，因為 PR #8068 已在 shared_ptr 工作之上重新建立。
審查 PR #8084（將最近接受的區塊和交易新增到 AttemptToEvictConnection）

娛樂時刻

wumpus       #link https://github.com/bitcoin/bitcoin/issues/7471
cfields_     wumpus: thanks
wumpus       eeh that's the wrong one
gmaxwell     wumpus: unthanks

Lightsword   maybe we should just have a service bit for flagging fast relay nodes/miners in general for preferential peering rather than making it flag compact blocks specifically
sipa         Lightsword: we should also have an evil bit that abusive nodes should set

參與者

IRC nick	Name/Nym
Luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
instagibbs	Gregory Sanders
cfields	Cory Fields
btcdrak	BtcDrak
jeremyrubin	Jeremy Rubin
sdaftuar	Suhas Daftuar
BakSAj	BakSAj
CodeShark	Eric Lombrozo
MarcoFalke	Marco Falke
Lightsword	Lightsword

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-06-02

Thu, 02 Jun 2016 00:00:00 +0000

概覽

主要議題
註記 / 簡短議題
Segwit 審查
緊湊區塊測試
CPFP 狀態和其他待處理的 pull request
娛樂時刻
參與者
免責聲明

主要議題

Segwit 審查
緊湊區塊測試
CPFP 狀態和其他待處理的 pull request

註記 / 簡短議題

沒有很多人對 0.11 的軟分叉反向移植感興趣，使用者對此也沒有太大興趣。BIP68 的反向移植特別複雜，可能比根本不發布更危險。軟體生命週期頁面仍然承諾維護以前的版本，但 0.13 也很近，所以可能不是什麼大問題。

Segwit 審查

背景

會議評論

Sipa 計劃進行 BIP9/GBT 變更，移除 segnet 和正面見證標誌，然後建立一個具有清晰歷史記錄但導致相同樹的平行重新建立。正面見證標誌是一個標誌，表示您想要序列化見證。由於除了少數例外情況外，您幾乎總是想要序列化見證，所以最好有一個負面見證標誌。另一個原因是設定正面標誌的失敗通常不會被檢測到，但設定負面標誌的失敗會被檢測到。同時擁有兩個標誌也是一個選項，但會導致更多程式碼變更分散在各處。

由於您不希望使用者在推出之前擁有 segwit 地址，因此新的錢包程式碼可以在測試可以使用的隱藏設定選項後面引入。

jl2012 提出了我們的見證程式定義僅限於 16 個版本的問題，如果不引入新的見證儲存就不容易擴充。允許見證程式稍大一點的簡單解決方案與目前程式碼相比是硬分叉變更，這將導致測試網分叉，因為 segwit 已經在那裡啟動。由於可能發生的最糟糕的事情是測試網節點的重新索引，而 16 太少，sipa 將變更版本限制。

會議結論

審查 #7749（執行預期的出站服務）和 #8083（新增支援具有按服務位元過濾選項的 dnsseeds）
擴充最大見證程式長度

緊湊區塊測試

背景

BIP152：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少 p2p 網路的區塊傳輸延遲。

會議評論

BlueMatt 建立了一個使用緊湊區塊和 UDP 網路區塊編碼內容的平行中繼網路，sipa 在 shared_ptr 記憶體池變更之上重新建立了 TheblueMatt 的 PR（可在這裡取得）。包括一些大型礦工在內的許多人正在公共節點上執行這兩者。一切似乎都按預期工作，收集到的資料也是如此。

Gmaxwell 指出他應該採取行動設定一些已發布的地址，讓人們無需詢問即可連接。

會議結論

審查 PR #8126（記憶體池中基於 std:shared_ptr 的 CTransaction 儲存）。

CPFP 狀態和其他待處理的 pull request

背景

Suhas Daftuar 有一個 pull request (#7600)，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child Pays For Parent (CPFP)。

會議評論

重構 CreateNewBlock 的 PR #7598 是 CPFP 所需的

佇列中有很多 PR 是不錯的，但還沒有完全完成。這使得很難維持良好的概覽，也很難測試多個 PR，因為許多 PR 觸及相同的部分。Wumpus 詢問是否有任何 PR 接近能夠合併。

Jonasschnelli 認為 #7957（RPC：新增對序列號的支援）可以合併，並要求對 #7946（減少 ConnectTip/SyncWithWallets 期間的 cs_main 鎖定）進行一些審查。他還要求允許合併 [docs] 和 [tools] PR。他將嘗試專注於更瑣碎的文件 PR。

Sipa 要求審查 #7948（RPC：增強 getblockchaininfo bip9_softforks 資料）、#7967（RPC：為 fundrawtransaction 新增 feerate 選項）和 #7997（用更精簡的 setSpends 替換 mapNextTx）

Luke-jr 認為 #7935（Versionbits：GBT 支援）已準備好。

會議結論

審查 PR #7598（重構 CreateNewBlock 成為 BlockAssembler 類別的方法）

娛樂時刻

sipa         i have another question
gmaxwell     sipa: what is the meaning of life?
sipa         42
gmaxwell     thats an answer, not a question!
luke-jr      he has both the answer and a question
gmaxwell     we're going to need to build a bigger computer...

gmaxwell     Yes, though they may get DDOS attacked, which is harmless but would waste time sorting out the issue. :)
wumpus       gmaxwell: you mean thoroughly stress-tested :)

參與者

IRC nick	Name/Nym
Luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
sipa	Pieter Wuille
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
instagibbs	Gregory Sanders
cfields	Cory Fields
btcdrak	BtcDrak
jtimon	Jorge Timon

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-05-26

Thu, 26 May 2016 00:00:00 +0000

概覽

主要議題
註記 / 簡短議題
Segwit 優先順序
BIP 151
Child-Pays-For-Parent
娛樂時刻
參與者
免責聲明

主要議題

Segwit 優先順序

註記 / 簡短議題

上週 coredev 駭客活動的記錄可以在這裡找到，這些註記的摘要在這裡。
BIP 151
Child-Pays-For-Parent

Segwit 優先順序

背景

會議評論

網路堆疊重構和 libconsensus 重構都是長期重要的，但與隔離見證的程式碼衝突。儘管網路重構對緊湊區塊的影響比對 segwit 的影響更大，因為 segwit 的網路變更處於比網路重構更高的層級。

Libconsensus 重構在 0.10 中運作良好，因為有一個明確的目標和明確的做法，而進一步的努力大多是一個人的表演，如果我們希望這些變更發生，同意一個計劃是有意義的。

0.13 的功能凍結是在 2016-06-16，緊湊區塊最好能在 0.13 中以減輕額外的重播延遲。我們可以在沒有定義軟分叉的情況下合併 segwit，只是擁有程式碼，這使得在測試網上的測試更容易，並讓進一步的開發在其上進行，這樣其他工作就不會被 segwit 阻礙。

由於 segwit 已在測試網上啟動，segnet 將被放棄。

會議結論

僅合併 segwit 程式碼

BIP 151

背景

比特幣網路今天不加密對等節點之間的通訊。這會帶來安全問題，並允許對比特幣使用者進行大規模監控/分析。對於 SPV 節點，這可能會產生重大的隱私影響，並可能降低對等節點的抗審查性。

加密對等節點流量將使分析和特定使用者定位比目前困難得多。今天，網路提供商或任何其他中間人識別比特幣使用者及其控制的地址/金鑰是微不足道的，因為新廣播的交易將向網路提供商揭示金額和收款人。

此 BIP 還描述了一種方式，可以讓通訊對等節點識別資料操縱（攔截 TCP/IP 節點阻止命令）。

由於加密訊息的特徵，分析 p2p 通訊的類型仍然是可能的。

會議評論

Petertodd 從密碼學家那裡獲得了一些回饋，他們擔心 BIP 151 不是現成的標準。BIP151 完全使用 openssh 的 chacha20-poly1305，因此可能需要在 BIP 中更加突出。

會議結論

在 BIP 文字中更清楚地說明 BIP151 使用 chacha20-poly1305 標準。

Child-Pays-For-Parent

背景

Suhas Daftuar 有一個 pull request，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child Pays For Parent (CPFP)。

會議評論

CreateNewBlock 所需的重構與 segwit 衝突，因此可能錯過 0.13。儘管每個人都希望盡快擁有它，因為這是一個長期討論的功能，但還沒有太多審查/測試。

會議結論

審查 PR #7600

娛樂時刻

sipa       !beginmeeting
sipa       !meetingbegin
sipa       !meetingstart
sdaftuar   startmeeting i think?
sipa       !startmeeting
btcdrak    # startmeeting without the space
sipa       #startmeeting
lightningbot   Meeting started Thu May 26 19:06:07 2016 UTC. The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.

參與者

IRC nick	Name/Nym
Luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
sipa	Pieter Wuille
sdaftuar	Suhas Daftuar
gmaxwell	Gregory Maxwell
wumpus	Wladimir van der Laan
kanzure	Bryan Bishop
CodeShark	Eric Lombrozo
instagibbs	Gregory Sanders
cfields	Cory Fields
jcorgan	Johnathan Corgan
btcdrak	BtcDrak
achow101	Andrew Chow

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

2016-05-20 非 IRC 會議摘要

Fri, 20 May 2016 00:00:00 +0000

概覽

連結至會議記錄 (文字)。
連結至會議記錄 (html)。

主要議題

隔離見證程式碼審查
未來位址類型的錯誤更正碼
點對點網路協定的加密
緊湊區塊中繼協定
Schnorr 簽章與聚合
新的網路函式庫

備註 / 簡短議題

本次會議在瑞士蘇黎世舉行實體會議，而非一般的 IRC 頻道。詳情請見 http://coredev.tech/。
一些參與者藉此機會驗證 PGP 指紋並簽署彼此的金鑰，以擴大圍繞比特幣的 PGP 信任網，提升安全性。
Bitcoin Core 使用的特殊 travis 快取功能現在應該對所有 GitHub 使用者開放，所以 CI 測試應該可以在任意儲存庫上執行，而不僅限於 Bitcoin Core。
Greg Maxwell 注意到一些開發者似乎正在收到大量的 PDF 惡意軟體。

隔離見證程式碼審查

背景

隔離見證是一項從標準交易 ID 中省略簽章的變更，以消除非故意的可塑性。作為副作用，它也趁機改進了可擴展性並增加最大區塊大小。

會議討論

Jonas Nick 將 segnet（一個專門用於隔離見證測試的自訂測試網）回移到 0.9，並檢查 segwit 向下相容性以及啟用後升級到 segwit 版本的情況。Suhas 收集了一份剩餘測試清單。進行了大量程式碼審查，修復了一些小錯誤。討論了 fund-raw-transaction 的不尋常需求所帶來的不確定性。

會議結論

Fund-raw-transaction 應該不需要變更共識層的 segwit 程式碼。
sdaftuar 擬定了一份應該編寫的額外測試清單。
挖礦：研究 GBT 如何運作（非 segwit 感知的軟體不應該能夠發出 segwit 的版本位元訊號）；請參閱 #7935 了解我們可能如何實作的一些背景資訊
Segwit 的種子節點 - jonasschnelli 正在進行
在發行說明中添加文件。
審查我們如何處理異常行為的節點。

未來位址類型的錯誤更正碼

背景

在比特幣歷史的大部分時間裡，比特幣位址一直使用自訂的 base-58 編碼。遷移到支付協定的努力並未成功，因此未來可能需要新的位址類型。Base-58 普遍被認為是一種不良編碼，因此人們希望為未來的位址類型提出一種改進的編碼方式。

會議討論

Pieter 針對未來位址類型定義的高性能 base-32 BCH 碼，提供了工作進度更新。Pieter 在尋找易於實作且具有良好性能的代碼方面取得了良好進展（例如，30 個更正位元可以確保檢測到最多 4 個換位錯誤或 4 個替換錯誤）。

會議結論

使用錯誤更正邏輯進行可靠的錯誤檢測是個好主意，但基於安全原因，應明確不嘗試更正使用者錯誤。

點對點網路協定的加密

背景

比特幣網路目前不對節點之間的通訊進行加密。這會帶來安全問題（例如：被他人操縱流量），並允許對比特幣使用者進行大規模監控/分析。主要是因為比特幣的信任模型特性，這大多數情況下是可以忽略的，然而對於 SPV 節點來說，這可能對隱私有重大影響，並可能降低節點的抗審查能力。

加密節點流量將使分析和特定使用者目標鎖定比目前困難得多。今天，網路提供商或任何其他中間人都可以輕易識別比特幣使用者及其控制的位址/金鑰（並與他的 Google 個人檔案等連結）。剛建立和廣播的交易將向網路提供商揭露金額和收款人。

比特幣節點之間用於通訊的協定一直都是未加密的，因為通訊被視為公開的。然而，有些使用者希望為他們的錢包執行輕型客戶端，但又想使用自己的私有節點以獲得安全性，因此需要選擇性的安全性。

會議討論

Jonas Schnelli 更新了 BIP151，現在看起來已經可以進行試驗性實作。除了改善隱私之外，這項變更還應該讓 p2p 協定的 CPU 開銷更少。

會議結論

草案 BIP151 現已在 BIPs 儲存庫中發布，Jonas 將進行實作。

緊湊區塊中繼協定

背景

頻寬是在點對點網路中中繼區塊的主要瓶頸。除非能減少這個瓶頸，否則更大的區塊大小可能會對比特幣的去中心化特性造成極大損害。

從歷史上看，比特幣 P2P 協定在區塊中繼方面的頻寬效率不高。中繼時會包含區塊中的每筆交易，即使在中繼區塊之前，節點已經獲得了給定區塊中的大量交易。這對於接收區塊的節點會造成適度的入站頻寬峰值，但對於某些在其節點之前接收到區塊的節點，可能會造成非常顯著的出站頻寬峰值。當這種峰值發生時，緩衝區膨脹可能會使消費級網路連線暫時無法使用，並可能延遲將區塊中繼到遠端節點，這些節點可能選擇等待，而不是從其他較不擁塞的節點重複請求相同的區塊。

背景

BIP114，默克爾抽象語法樹（MAST），是利用 segwit 腳本版本控制的比特幣腳本語言增強。它提高了條件交易的效率和隱私性。這個 BIP114 也安全地啟用了許多在比特幣早期版本中被停用的運算碼。MAST 腳本提高了隱私性，因為需要公開的資料較少，也可以使交易變小，從而節省空間。

會議討論

MAST 提案相當直接。它與目前的 P2WSH 方案非常相似。當你花費幣時，需要提供腳本、默克爾分支以及位置。你使用 ECDSA 驗證來計算根，並與 scriptpubkey 進行比較。它建立一個樹，其中葉子是腳本。然後你說，這是我正在執行的腳本，這是證明它已被承諾的默克爾分支。

討論了 MAST 的許多優點以及實作細節。

會議結論

MAST 依賴於 segwit 啟用。

子為父付費

子為父付費是一種透過建立另一個依賴於第一個交易的交易來為交易添加手續費的方法。

會議討論

拉取請求已經完成，可以進行審查。

會議結論

審查以下拉取請求 #7600 和 #7598。

參與者

IRC nick	Name/Nym
adam3us	Adam Back
kanzure	Bryan Bishop
jcorgan	Johnathan Corgan
sdaftuar	Suhas Daftuar
luke-jr	Luke Dashjr
Adiabat	Tadge Dryja
MarcoFalke	Marco Falke
cfields	Cory Fields
maaku	Mark Friedenbach
wumpus	Wladimir van der Laan
jl2012	Johnson Lau
CodeShark	Eric Lombrozo
gmaxwell	Gregory Maxwell
nickler	Jonas Nick
instagibbs	Gregory Sanders
jonasschnelli	Jonas Schnelli
jtimon	Jorge Timón
petertodd	Peter Todd
sipa	Pieter Wuille

免責聲明

本摘要編寫時未徵詢部分討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。

IRC meeting summary for 2016-05-19

Thu, 19 May 2016 00:00:00 +0000

概覽

主要議題
註記 / 簡短議題
Versionbits GetBlockTemplate 和 CSV 啟動
參與者
免責聲明

主要議題

Versionbits GetBlockTemplate 和 CSV 啟動

註記 / 簡短議題

這是一個簡短的會議，出席率很低，因為許多開發者正在前往 coredev 駭客活動。
Luke-jr 想知道是否有人研究了最新的 OpenSSL 漏洞。在發布 0.12.2 時，將 OpenSSL 一起提升可能是有意義的。

Versionbits GetBlockTemplate 和 CSV 啟動

背景

Getblocktemplate 是新的去中心化比特幣挖礦協議，由比特幣社群在 2012 年中期公開開發。它取代了舊的 getwork 挖礦協議。（Wiki-連結）

CheckSequenceVerify 或 BIP112 是 0.12.1 中發布的與時間鎖定相關的 BIP 之一，這是第一個應該使用 BIP9 versionbits 啟動的軟分叉。

會議評論

Luke-jr 提到他需要為 Eligius 礦池提供 GBT 支援。有一些應用程式需要 CSV，並且最好不要同時啟動 CSV 和 segwit，所以雖然不是關鍵的，但如果能在合理的時間範圍內啟動會很好。反向移植到 0.11 或 0.12 CPFP 測試/審查將使 Eligius 支援 CSV。

會議結論

審查實作「Child-Pays-For-Parent」的 PR #7600。

參與者

IRC nick	Name/Nym
Luke-jr	Luke Dashjr
jonasschnelli	Jonas Schnelli
Morcos	Alex Morcos
sipa	Pieter Wuille
BlueMatt	Matt Corallo

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-05-12

Thu, 12 May 2016 00:00:00 +0000

概覽

主要議題
緊湊區塊中繼 BIP 和一般 BIP 流程
RPC 長輪詢通知
娛樂時刻
參與者
免責聲明

主要議題

一般 BIP 流程和問題
RPC 長輪詢通知

緊湊區塊中繼 BIP 和一般 BIP 流程

背景

BIP 152：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。

會議評論

在上週會議中討論的 BIP9 部署文件已經建立。

BIP 編輯 Luke-jr 說，如果他們不是該 BIP 的列出作者，他希望人們不要 ACK/NACK BIP，因為 BIP 是作者的文件。

Jonasschnelli 提議定義一個規則，說明如何處理已實作 BIP 的實作連結。在 BIP32 中，不斷有 pull request 來新增連結，這些連結更多地作為廣告而不是其他任何東西。如果我們不監控它，也會帶來惡意軟體的風險。參考實作以及其他語言的實作可能很有用，因此最好連結到實作。Jcorgan 提議連結到 URL 和提交雜湊，以確保連結的程式碼反映實作。

會議結論

新增 BIP 實作連結取決於 BIP 作者，通常應該連結到實際的程式碼，而不是產品。

RPC 長輪詢通知

背景

長輪詢或類似協議將啟用一種簡單且安全的方式，透過網際網路向 Core 新增遠端 GUI 和遠端錢包。

會議評論

jonasschnelli 的 PR #7949 正在實作 RPC 長輪詢通知。

目前 ZeroMQ 用於通知，但實際上僅對本地系統有用，不適用於透過網際網路的通知。Jcorgan 指出這可以透過 CurveZMQ 實現。 ZeroMQ 可能太複雜而無法進一步擴充，並且對於編寫遠端 GUI 來說是次優的，因為您無法僅過濾錢包交易，而長輪詢只需要很少的程式碼變更且沒有相依性。儘管可能有價值將 Core 限制為一個介面。

RPC 長輪詢的另一個優勢是能夠擁有在身份驗證後面保護的私人通知。Wumpus 想知道我們是否需要私人通知。對於遠端錢包 GUI，您會需要，但是他解釋說，這個想法是附加錢包，而不是錢包 GUI，因為錢包需要從核心分離。理想情況下，節點、錢包和 GUI 應該分離。Sipa 不確定 Core 錢包現在是否應該提供通訊通道。

另一個解決方案是提供一個小的守護程式，在核心和遠端 GUI/錢包之間互動。

會議結論

有許多可能性：多種通知協議、僅 ZeroMQ、僅 RPC。意見分歧很大，討論在會議後繼續。大多數人似乎同意焦點應該放在節點 <-> 錢包連接上。

Jonasschnelli 將為 RPC 長輪詢新增一些簡單的範例。

娛樂時刻

kanzure    have we received an overview from sipa yet about areas of segwit that he feels should be most thoroughly reviewed
sipa       kanzure: no, sorry
kanzure    can we get 10 volunteers to heckle sipa about this?

參與者

IRC nick	Name/Nym
Luke-jr	Luke Dashjr
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
kanzure	Bryan Bishop
jtimon	Jorge Timon
petertodd	Peter Todd
instagibbs	Gregory Sanders
paveljanik	Pavel Janik
jcorgan	Johnathan Corgan
btcdrak	BtcDrak
BlueMatt	Matt Corallo

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-05-05

Thu, 05 May 2016 00:00:00 +0000

概覽

主要議題
簡短議題
segwit versionbit、testnet 開始日期、GBT 變更
娛樂時刻
參與者
免責聲明

主要議題

segwit versionbit、testnet 開始日期、GBT 變更

簡短議題

NicolasDorier 提議致力於這個問題。Morcos 評論說我們應該將錢包功能分開，為「塵埃」使用一些更聰明的較高值，塵埃的下限應該是一個單獨的變數，而不是像現在這樣是最小中繼的倍數。進一步討論被導向問題本身。
BlueMatt 為他的緊湊區塊中繼提案準備了一份 BIP 文件。該文件已發送到 bitcoin-dev 郵件列表以獲得進一步回饋。

segwit versionbit、testnet 開始日期、GBT 變更

背景

開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：BIP141、BIP142、BIP143、BIP144 和 BIP145

會議評論

隔離見證需要一個 BIP9 versionbit 來啟動。選擇任何特定位元沒有特殊理由，因此選擇下一個位元是有意義的，因為這可能會減少意外重複分配的機會。需要在 BIP 文件之外有一個文件來追蹤當前的位元分配。

Testnet 需要隔離見證的開始日期。由於不需要提前設定，啟動可以設定在 5 月 1 日，以讓人們在合併之前互相測試他們的 segwit 版本。主網的日期應該在軟體準備好發布時設定，並且理想情況下應該與其他實作協調。

Cfields 指出 getblocktemplate(GBT) 變更需要快速就位，以便測試網是礦工將要執行的有效表示。有一個提議的修正案對 BIP9 進行修正，要求礦工設定一個標誌，表示對 segwit 的認識（實作）。如果採用這個，不支援 segwit 的 GBT 客戶端將不會建立包含 segwit 交易的區塊。這個討論被延遲到會議後。

會議結論

在 bips 儲存庫中新增 bip-0009/assignments.md 以追蹤當前的位元分配。
將 testnet 啟動設定在 5 月 1 日，到期時間為 1 年後。

娛樂時刻

btcdrak       ok so (1<<1) with activation may 1st for testnet, and (1<<1) and date TDB for mainnet
morcos        btcdrak: ack
morcos        but what does TDB stand for? :)
btcdrak  palms face
gmaxwell      Totally delicious burger.

參與者

IRC nick	Name/Nym
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
phantomcircuit	Patrick Strateman
sdaftuar	Suhas Daftuar
jl2012	Johnson Lau
cfields	Cory Fields
Nickler	Jonas Nick
instagibbs	Gregory Sanders
paveljanik	Pavel Janik
achow101	Andrew Chow
NicolasDorier	Nicolas Dorier
BlueMatt	Matt Corallo

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-04-28

Thu, 28 Apr 2016 00:00:00 +0000

概覽

主要議題
簡短議題
Segwit 審查和 BIP 的狀態更新
娛樂時刻
參與者
免責聲明

主要議題

Segwit 審查和 BIP 的狀態更新

簡短議題

過渡到 travis trusty 和 C++11 已成功
在 2016-03-24 會議中討論的固定時間 AES 函式庫的獨立審查已完成，他正式證明了某些部分是正確的並分析了固定時間性。
對於他的 replace-by-fee (RBF) 錢包實作，jonasschnelli 想知道他應該將 RBF 交易屬性為「可替換」還是將非 RBF 交易屬性為「不可替換」。開發者似乎同意前者最有意義，因為非 RBF 只是較不可替換。在許多提議之後，jonasschnelli 決定採用「已發出可替換性信號」作為確切的措辭。
有人聯絡 jonasschnelli，要求為 Bitcoin Core 標誌和傳播材料建立一個儲存庫。bitcoin core 沒有清晰的標誌或視覺識別。開發者並不真正關心這個，但使用者群可能關心。在某個地方提供「新聞資料包」可能是有意義的。開源專案的新聞資料包並不常見，而且幾乎總是附帶許可政策。因此，除非人們想要監管這樣的許可政策，否則新聞資料包更像是我們也使用的推薦圖像/文字的集合。

Segwit 審查和 BIP 的狀態更新

背景

會議評論

Cfields 已開始與礦池合作，以確保他們的設定可以處理隔離見證。他的目標是讓每個礦池至少挖掘一個 segnet 區塊。

考慮到 segwit PR #7910 涉及的許多不同部分，很少有開發者有信心能夠完全 utACK 它，因為他們可能對程式碼的特定部分不夠熟悉。開發者將專注於他們最有信心的部分並 ACK 這些部分。

一些人對 BIP 文字提供了回饋，並因此頻繁地進行了小的澄清。Instagibbs 驗證了 BIP141 和 BIP143 與其實作相符。

會議結論

Sipa 將列出他認為需要額外審查的一些中等棘手的領域
BIP 144 需要包含服務位元的內容

娛樂時刻

（編輯後只留下自行車棚評論）

19:35:30 <jonasschnelli> RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"?
19:35:59 <petertodd>     jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something...
19:37:16 <instagibbs>    'mempool-replaceable' ?
19:38:13 <jtimon>        "standard-policy-0.12-replaceable"?
19:38:40 <jonasschnelli> "standard-policy-0.12-BIP125-replaceable"
19:40:21 <jtimon>        ack bip125-replaceable
19:42:24 <petertodd>     jonasschnelli: "easily replacable"
19:42:27 <jtimon>        opt-in-repleaceable ?
19:42:38 <petertodd>     jonasschnelli: or heck, "trivially replacable"
19:42:45 <paveljanik>    "updatable"?
19:43:03 <luke-jr>       "replacement-requested"
19:43:04 <jonasschnelli> of "signs replicability"?
19:43:39 <paveljanik>    replacability signalled ;-)
19:44:38 <jtimon>        "replace explicitly allowed"?
19:44:41 <sdaftuar>      fee-replaceable ?
19:45:58 <jonasschnelli> "fee-replacability signalled"?
19:48:21 <jtimon>        what was wrong about "Opted in to replacement" or something along those lines?

參與者

IRC nick	Name/Nym
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
kanzure	Bryan Bishop
sdaftuar	Suhas Daftuar
jl2012	Johnson Lau
cfields	Cory Fields
jtimon	Jorge Timon
petertodd	Peter Todd
instagibbs	Gregory Sanders
warren	Warren Togami
paveljanik	Pavel Janik
achow101	Andrew Chow
Luke-jr	Luke Dashjr

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-04-21

Thu, 21 Apr 2016 00:00:00 +0000

概覽

主要議題
Segwit 審查
Travis 切換到 trusty
娛樂時刻
參與者
免責聲明

主要議題

Segwit 審查
Travis 切換到 trusty

Segwit 審查

背景

會議評論

上週提出的 segwit 實作 PR #7910 已經收到了很多輸入。Morcos 和 sdaftuar 提議大家努力審查 segwit，並盡可能延遲其他合併。Gmaxwell 和 wumpus 指出這將對合併 segwit 造成人為壓力，並且有太多其他事情正在進行，無法延遲所有事情。Wumpus 確實同意我們應該延遲可能與 segwit 衝突的 PR，例如共識和中繼政策重構。Sipa 指出他對目前正在進行的任何事情都不太擔心。

有一些安全的準備提交/PR 應該首先進入，這些應該是優先事項。許多開發者希望獲得更多關於哪些領域正在進行大量測試、哪些沒有、哪些領域是關鍵的並需要額外關注、哪些領域需要優先處理等資訊，以便順利進行審查流程。

會議結論

更多 segwit 的程式碼審查
Luke-jr 需要更新 PR #7935 getblocktemplate 對 versionbits 的支援。

Travis 切換到 trusty

背景

Travis 是一個開源持續整合 (CI) 服務，用於建置和測試託管在 GitHub 上的軟體專案。Bitcoin Core 計劃在 0.13 中開始使用 C++11，因此需要更新版本的 Travis 來建置和測試 pull request。這個稱為「trusty」的版本目前處於 beta 階段。Bitcoin Core 已經從 Travis 團隊獲得了使用快取功能的標記，該功能預設尚不可用。

會議評論

正在致力於 C++11 更新的 Cfields 指出，切換到 trusty 時可能會有幾個小時的不穩定，因為該標記帶有使所有當前快取失效的警告。

一些開發者無法為自己的儲存庫啟用 travis 或讓它失敗。

有一個選項可以新增另一個與 github 相容的 CI 服務來加速測試，但這意味著更多維護，這可能不值得。

會議結論

當 cfields 給出綠燈時合併 PR #7920。

娛樂時刻

<wumpus>   ok, any other topics to be discussed?
<btcdrak>  the segwit afterparty!

參與者

IRC nick	Name/Nym
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
kanzure	Bryan Bishop
sdaftuar	Suhas Daftuar
CodeShark	Eric Lombrozo
cfields	Cory Fields
Luke-jr	Luke Dashjr
jtimon	Jorge Timon

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-04-14

Thu, 14 Apr 2016 00:00:00 +0000

概覽

主要議題
簡短議題
Segwit 和反向移植
C++11 狀態
娛樂時刻
參與者
免責聲明

主要議題

Segwit 和反向移植
C++11 狀態

簡短議題

0.12.1 的狀態：RC2 已發布。同時上週已挖掘了一個 0.12.1 RC 區塊。通常我們在 RC 發布後等待一週才將其標記為最終版本，但許多人希望盡快發布它。0.12.1 功能包括 BIP68、BIP112、BIP113，這些將透過 BIP9 軟分叉機制部署。（0.12.1 於 2016-04-15，即會議後第二天發布）
在 2016-03-24 會議中討論的固定時間 AES 函式庫正在進行獨立審查，由 Matthew Green 的一位研究生進行，希望在幾週內可用。
考慮到 0.13 計劃的新功能數量以及在蘇黎世舉行會議的時間，0.13 的功能凍結和 RC 發布週期推遲了一個月。修訂後的時程表可以在這裡找到。
BlueMatt 已實作了高效的區塊中繼；與 gmaxwell 長期以來一直在傳播的設計相關。他已經有程式碼，並獲得了約 96% 的區塊頻寬減少。協議需要一些調整，但一旦進入，它應該能夠在 0.5 個往返時間內傳送絕大多數區塊（加上 TCP 新增的任何可怕開銷），其餘的將需要 1.5 個往返時間。他還一直在致力於更進一步的其他事情，儘管這項工作主要與礦工相關。第一部分應該很快就會進入 pull-request。

Segwit 和反向移植

背景

幾位開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。

會議評論

Sipa 報告 segwit 分支目前在 0.12.1 之上，接近向 bitcoin 提出 PR。Morcos 提議非常快速地向 master 和 0.12 提出 PR，並共同努力在大致相同的時間審查它們。Btcdrak 同意並指出已經從下游消費者那裡獲得了很多幫助、測試和審查。

Gmaxwell 指出 btcd，一個用 Go 編寫的替代比特幣完整節點實作，已經實作了 segwit 的共識變更，並且正在與 segnet4 互操作。

會議結論

Sipa 將很快提出 pull request。

C++11 狀態

背景

C++11 是 C++ 語言的更新。它提供新功能、擴充的標準函式庫等。 Zerocash 必須用一些 c++11 函式庫編寫，一些 IBLT 模擬程式碼用 c++11 編寫，他們希望為最終的核心提交回收利用。計劃是在 0.13 中開始使用 c++11。

會議評論

travis 團隊已啟用快取，但僅針對標記的專案，因為它處於測試階段，所以 cfields 已發送郵件請求標記。他還一直在他的個人分支上駭客 C++11，並說很明顯需要一個關於我們允許哪些現代化的政策。人們似乎圍繞著僅新的 C++11 程式碼的想法，然後是 boost 替換，然後是重構。

Wumpus 在一段時間前做了一個 PR #7165，它啟用了 C++11 建置並需要 C++11 編譯器，這樣我們將獲得使用者報告。

會議結論

一週後開啟 C++11。新的東西可以使用它，但重構可以等到 0.14。

娛樂時刻

19:00	cfields	     meeting?
19:00	wumpus	     I guess?
19:00	wumpus	     #startmeeting
19:00	morcos	     confidence inspiring wumpus
19:01	gmaxwell	 "If I have to."

19:01	btcdrak	     gavel wont be attending due to last week's beating.

19:03	Luke-Jr	     we should release 0.12.1 when 0.12.1 is observed to be released.
19:04	sipa	     Luke-Jr is the first member of the club containing Luke-Jr as first member
19:04	Luke-Jr	     that sounds lonely.

19:30	wumpus	     may work better with cfields' holiday too
19:30	cfields	     stupid inconvenient honeymoon...
19:30	sipa	     cfields: priorities!
19:37	BlueMatt	 when does cfields get back?
19:38	cfields	     BlueMatt: july4ish
19:39	cfields	     BlueMatt: if it turns out to be too problematic, i can revisit the dates.
19:39	BlueMatt	 cfields: lol, dont change honeymoon for us
19:39	wumpus	     cfields: no
19:39	morcos	     cfields: you better hope your fiance doesnt read these logs

19:58	sipa         #shutdown -h now meeting
19:59	jonasschnelli   sudo!
19:59	paveljanik   jonasschnelli, no need for sudo once you have # ;-)
19:59	jonasschnelli   nerds! oO

19:59	jtimon       meeting?
20:00	gmaxwell     jtimon: an hour ago.
20:00	jtimon       oh...
20:00	phantomcircuit   timezones strike again
20:00	jtimon       well, read the logs I guess

參與者

IRC nick	Name/Nym
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
kanzure	Bryan Bishop
sdaftuar	Suhas Daftuar
instagibbs	Gregory Sanders
phantomcircuit	Patrick Strateman
paveljanik	Pavel Janik
cfields	Cory Fields
Lukejr	Luke Dashjr
BlueMatt	Matt Corallo

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-04-07

Thu, 07 Apr 2016 00:00:00 +0000

概覽

主要議題
簡短議題
如何處理 Bitcoin Core 錢包
處理 RBF RPC/UI
娛樂時刻
參與者
免責聲明

主要議題

如何處理 Bitcoin Core 錢包
處理 RBF RPC/UI

簡短議題

0.12.1 Release candidate 1 已標記（撰寫時 0.12.1 RC2 已標記）
中位時間過去違規檢查更新：gmaxwell 產生了許多違規，但沒有被挖掘。他仍在努力，因為他懷疑他需要更努力地中繼這些交易。
5 月 20-22 日將在瑞士蘇黎世舉行 Bitcoin Core 駭客大會 http://coredev.tech 感興趣的核心開發者應在 4 月 15 日之前通知 jonasschnelli。
Jtimon 希望對 PR #7829 中的實驗獲得一些回饋，該實驗旨在幫助新人熟悉 git、審查流程等，並合併他們的第一個 PR。

如何處理 Bitcoin Core 錢包

背景

多年來，Bitcoin Core 錢包幾乎沒有變化。然而，錢包的長期可持續性需要許多功能。長期目標是讓錢包獨立於核心。

會議評論

Jonasschnelli 提議擴充 PR #7830，將當前錢包複製到第二個目前實驗性的錢包中，然後可以透過 –enable-lightwallet 啟用。這樣就不需要向後相容性，因此需要考慮的限制更少。新錢包應該移除帳戶，用 LogDB 替換 BerkeleyDB，新增 BIP32 和 SPV。

Jonasschnelli 做了一個非常粗略的時間估計：「沒有帳戶和沒有 BDB 的新錢包可能在 0.13 中，穩定的 API 在 0.15 中，…非 beta 在 0.16 中」。

許多非錢包功能的單元測試依賴於擁有錢包。更長期來看，這些測試應該減少對錢包的依賴。

新錢包也可能會有一個全新的介面。

會議結論

功能主要應該最終出現在新錢包中，舊錢包仍應接受錯誤修復。
Jonasschnelli 將撰寫一份提案，更清楚地記錄他將要做什麼以及人們如何最好地支援他。

處理 RBF RPC/UI

背景

BIP125 選擇性 replace-by-fee (RBF) 是 0.12 以來的新功能，它使錢包能夠在交易仍在記憶體池中時將其標記為可替換。這允許錢包提高費用、新增接收者等。reddit 上有一篇關於它的很棒的常見問題解答文章 reddit。目前 Bitcoin Core 錢包不提供任何使用這些功能的功能。

會議評論

Petertodd：「所以，我認為您從 RPC 的角度實際上需要做的是考慮使用者想要支付的地址，以及已知（已確認）交易是否成功做到了這一點 - 這不是錢包現在的工作方式」

雖然新增輸出可能更有用，但第一步應該是支援費用提高。Petertodd 編寫了一個用 python 提高費用的工具。

Gmaxwell 希望看到一種不同的方法，即「自適應費用」，它預先建立具有鎖定時間的提升並將它們排隊。雖然更好，但人們希望從簡單的費用提升開始，因為鎖定時間版本將重複使用該程式碼。我們應該小心自動費用提升，因為使用者需要意識到它並期待這種行為。

降低找零有一些隱私影響，然而隱私將更昂貴且難以成功。Gmaxwell 指出：「主要要做的是首先正確估算，儘管現在找零是如此徹底地可識別，以至於您是在馬跑了之後關閉穀倉門。:)」

費用提升可以新增到目前的錢包中，更先進的解決方案如自動費用提升可以在新錢包上完成。

會議結論

致力於 BumpFee

娛樂時刻

19:14:37 * gmaxwell bangs gavel
19:14:43 <sipa> who is gavel?

19:24:40 <petertodd> I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10

19:31:26 <jonasschnelli> petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future?
19:32:10 <petertodd> jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean?
19:32:51 <sipa> jonasschnelli: it shall be called BeeFump

參與者

IRC nick	Name/Nym
MarcoFalke	Marco Falke
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
kanzure	Bryan Bishop
sdaftuar	Suhas Daftuar
jtimon	Jorge Timon
phantomcircuit	Patrick Strateman
paveljanik	Pavel Janik

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-03-31

Thu, 31 Mar 2016 00:00:00 +0000

概覽

主要議題

隔離見證更新
軟分叉反向移植
壞鏈警報
child-Pays-For-parent 挖礦

簡短議題

上週討論的中位時間過去違規檢查更新：目前沒有違規被挖掘。Gmaxwell 將開始產生 MTP 違規交易以再次檢查。

網路堆疊重構更新：cfields 將最新版本推送到他的 net-refactor10 分支，已準備好進行測試和審查。它仍然需要一堆單元測試，cfields 正在為此建置框架，以及文件。

Jonasschnelli 詢問人們是否仍然對他一直在研究的 p2p 加密和身份驗證 BIP 感興趣。我們是需要自己的解決方案還是調整已有的解決方案。Sipa 提議從 openssh 複製加密程式碼，這是 300 行的 chacha20 - poly1305。每個人似乎都贊成繼續編寫 BIP，因為它允許錢包 (spv) 的簡單設定以增加隱私。

隔離見證更新

背景

會議評論

Sipa，segwit 程式碼的主要貢獻者/維護者，指出：

segwit 程式碼在過去幾天取得了很大進展；它現在通過了所有預先存在的 rpc 測試和單元測試，並在此過程中修復了許多錯誤
它在 bip68/112/113 反向移植之上重新建立，並且新的 segnet (segnet4) 已啟動並執行 bip9 啟動邏輯
我已經顯著重組了分支中的提交以 1) 定義 segnet 2) 新增共識/節點邏輯 3) 新增錢包邏輯 4) 新增測試。這樣就可以測試分叉後從 pre-segwit 程式碼升級，並且可以單獨審查共識關鍵部分。
我將編寫腳本單元測試，因為我們沒有測試所有可能的見證驗證失敗
程式碼變更可以在這裡查看

會議結論

Sipa 將列出他希望其他人致力於的事情清單，以推進 segwit。

軟分叉反向移植

背景

如軟體生命週期文件所述，Bitcoin Core 開發者旨在維護最新和以前的主要版本，目前是 0.12 和 0.11。

會議評論

相關的反向移植是 #7716(0.11) 和 #7543(0.12)。#7543 得到了 5 個經過測試的 ACK，應該準備好合併了。

Morcos 表達了多位開發者共有的一些擔憂：「我知道這可能有爭議，但我認為為 0.11 提供反向移植比不提供更糟。很難提供足夠的審查。如果您不知道需要同時變更兩者，您可能已經以通過現有單元測試但已損壞的方式將這些軟分叉反向移植到 0.11。我認為我們不對我們無法提供同樣高程度安全性的東西蓋章批准，對我們的『客戶』提供更好的服務。只是一個想法，考慮到 segwit 也可能很難在 0.11 中正確測試…我們似乎為自己設定了一個要求，即我們將反向移植 2 個主要版本，因此我們浪費了大量開發資源來做這件事，以獲得一個質量可疑的產品。」

Gmaxwell 也指出，0.11 的使用者沒有任何回饋或反向移植請求，考慮到 0.11 和 0.12 之間的效能差異，有很多理由不執行 0.11。

會議結論

想要反向移植到 0.11 的人應該審查 #7716
0.11 反向移植不應延遲 0.12.1

壞鏈警報

背景

服務正在使用 -alertnotify 來通知關鍵問題。有些人連接了呼叫器，甚至自動關閉服務。

一些基於啟發式的訊息，例如「異常高數量的區塊」似乎經常出現，儘管沒有真正的問題：https://www.reddit.com/r/Bitcoin/comments/3ydwg2/warning_abnormally_high_number_of_blocks/

除了浪費時間和資源之外，在第無數次之後，使用者開始完全忽略訊息，從而錯過嚴重問題。

另一個問題是，當（臨時）問題消失時，某些警告不會消失，關閉它們的唯一方法是重新啟動 bitcoind。

會議評論

似乎沒有關於什麼導致誤報的最終結論，應該對此進行更多研究。 dgenr8 的 pull #7568 修復了一些問題，但可能不是所有問題。

會議結論

暫時停用警告，嘗試在 master 中修復它，如果成功則反向移植到 0.12.2/0.13。

child-Pays-For-parent 挖礦

背景

Suhas Daftuar 有一個進行中的 (WIP) pull request，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child Pays For Parent (CPFP)。

會議評論

第一步是讓人們為 #7598 提供概念回饋，重構 CreateNewBlock。設計的最初目標是將優先順序填充與費率填充分開，但我認為整體目標應該是使其更模組化以弄清楚如何組裝區塊。

考慮到 0.13 的功能凍結不是那麼遙遠（2016/05/15），而且需要在 segwit 之上進行一些變更，Morcos 想知道是否要平行繼續還是先專注於 segwit。

娛樂時刻

<gmaxwell> is that bad "chain alerts" or "bad chain" alerts? :)
<jonasschnelli> second.
<wumpus> hehe both
<sipa> (bad ((bad chain) alerts))
<gmaxwell> I think it's actually more the first.

參與者

IRC nick	Name/Nym
cfields	Cory Fields
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
Morcos	Alex Morcos
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
Luke-Jr	Luke Dashjr
dgenr8	Tom Harding
sdaftuar	Suhas Daftuar
jtimon	Jorge Timon
phantomcircuit	Patrick Strateman
paveljanik	Pavel Janik
warren	Warren Togami

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-03-24

Thu, 24 Mar 2016 00:00:00 +0000

概覽

主要議題
簡短議題
BIP9 的軟分叉狀態
v0.12.1、v0.11.3 和 v0.10.5 反向移植
固定時間 AES 函式庫
娛樂時刻
參與者
免責聲明

主要議題

BIP9 的軟分叉狀態
v0.12.1、v0.11.3 和 v0.10.5 反向移植
固定時間 AES 函式庫

簡短議題

Cfields 正在對 bitcoin core 的網路堆疊進行全面改革。這意味著大量程式碼的移動，但它會使新增額外功能變得更容易。他有一個功能完整的分支，他預計下週將尋求概念審查。Wumpus 和 sipa 指出他在波士頓會議上得到了他們的概念 ACK。
MarcoFalke 提議將 python RPC 測試切換到 python 3。Wumpus 也指出下一個 Ubuntu 版本將不再附帶 python 2。似乎沒有任何僅限 python 2 的建置環境，因此開發者同意最好直接切換到 python 3。

BIP9 的軟分叉狀態

背景

VersionBits BIP9 允許使用區塊標頭版本欄位作為位元陣列，以便礦工可以同時表示對多達 29 個軟分叉的準備就緒。根據目前的程式碼和提案，未表示對任何軟分叉準備就緒的礦工將建立「版本 4 區塊」，即與用於觸發和執行 BIP65 CLTV 軟分叉相同版本的區塊。

會議評論

#7648 收到了一些經過測試的 ACK，但仍然需要更多審查，因為軟分叉的標準比隨機 pull request 的標準要高一些。Jonasschnelli、MarcoFalke、cfields 和 wumpus 表示打算審查它。

Gmaxwell 想知道是否還有人在挖掘中位時間過去違規 (BIP113)。

會議結論

審查 #7648
Gmaxwell 將嘗試尋找仍在挖掘中位時間過去違規的礦工。

v0.12.1、v0.11.3 和 v0.10.5 反向移植

背景

如軟體生命週期文件所述，Bitcoin Core 開發者旨在維護最新和以前的主要版本，目前是 0.12 和 0.11。個別開發者可能選擇更新以前的版本，但這不是政策規則。

會議評論

Luke-Jr 正在檢查他的 pull request #7047 對 0.11.3 反向移植是否準確。Wumpus 指出對於軟分叉版本來說太多了，應該等待軟分叉版本之後的次要版本。Luke-Jr 也可能停止更新 0.10，這取決於 BIP68/112/113 反向移植到 0.10 有多困難。

pull-request #7543 將 BIP68、BIP112、BIP9 和軟分叉邏輯反向移植到 0.12，也需要審查。Pull-request #7716 對 0.11 做同樣的事情，也需要審查。

會議結論

審查 #7543 和 #7716
將 Gentoo stable 從 0.10 提升到 0.11

固定時間 AES 函式庫

背景

OpenSSL 在過去造成了許多問題和擔憂，開發者努力最小化對 openSSL 的依賴，例如引入他們自己的函式庫 (libsecp256k1) 用於 ECDSA 簽署/驗證。Sipa 編寫了一個 AES 實作，應該取代 OpenSSL 的 AES 版本（PR #7689）。

會議評論

很多開發者希望將 sipa 的程式碼提取到一個單獨的函式庫中。Sipa 和 gmaxwell 指出這是一個單一檔案，沒有意圖也不會超出這個範圍。Gmaxwell 還表示「一個構造良好的函式庫本身就是大量的工作」。

Petertodd 對審查程式碼提出了一些擔憂。雖然程式碼很小，但它仍然是獨立編寫的低級加密，他認為應該努力進行外部審查。Btcdrak 指出他要求 Tor 的 @isislovecruft 在付費基礎上看一下它。

會議結論

大多數人似乎想為它建立一個函式庫，儘管 gmaxwell 和 sipa 仍然不同意。

娛樂時刻

sipa:           cfields: just PR it! i want to see the code :)
jonasschnelli   sipa: code: https://github.com/theuni/bitcoin/tree/net-refactor8
cfields         sipa: i'm still frantically coding it :)
cfields         jonasschnelli: nooooooo. everyone shield your eyes from that :)
jonasschnelli   cfields: We all know how code during implementation can look. No shame for it!

參與者

IRC nick	Name/Nym
cfields	Cory Fields
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
petertodd	Peter Todd
MarcoFalke	Marco Falke
sipa	Pieter Wuille
wumpus	Wladimir van der Laan
Luke-Jr	Luke Dashjr

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-03-17

Thu, 17 Mar 2016 00:00:00 +0000

概覽

主要議題
為 BIP 68、112、113 安排第一個 BIP 9 軟分叉
除了 BIP 9 之外 0.12.1 的功能
- 會議評論
- 會議結論
隔離見證的狀態
- 背景
- 會議評論
娛樂時刻
參與者
免責聲明

主要議題

為 BIP 68、112、113 安排第一個 BIP 9 軟分叉
除了 BIP 9 之外 0.12.1 的功能
隔離見證的狀態

為 BIP 68、112、113 安排第一個 BIP 9 軟分叉

背景

會議評論

每個人似乎都對 PR #7575（會議後不久合併）感到滿意。一旦決定了開始日期和位元編號，就應該在郵件列表上宣布，以便其他實作也可以實作它。 Btcdrak 和 Morcos 將為 0.12 和 0.11 準備好反向移植。 BIP9 BIP 文字是最新的，更新 BIP 68、112 和 113 的軟分叉資訊也是個好主意。

會議結論

合併 #7575
審查 #7648
基於 BIP9 的部署開始日期是 5 月 1 日，位元編號為 0。
btcdrak 將使用新的軟分叉資訊更新 BIP 文字 68、112 和 113 的部署部分。

除了 BIP 9 之外 0.12.1 的功能

會議評論

Jonasschnelli 一直在開發 GUI 警告功能（PR #7579），人們同意將其推遲到 12.2，以便專注於 12.1 的軟分叉。Morcos 希望新增他和 jonasschnelli 的 PR #7715（「修復餘額和可用幣的計算」）和 #7707（「放棄交易的 UI 支援」），它們支援和處理放棄的交易，以便重新花費費用太低的輸出。

Wumpus 指出他希望避免在軟分叉旁邊帶來大量新功能。現在用於檢查您是否在壞鏈上的警報系統有很多誤報，有緊迫感要麼修復它，要麼停用它們，因為維護目前狀態會讓人們忽略警告。 dgenr8 做了一個修復（PR #7568）

會議結論

審查 #7568（「對壞鏈警報觸發的修正」）和 #7715
#7707 僅限 RPC（提交 42e945d79fd54ab11ad48978910b42d10c1c7cf8），這是 1 行程式碼。

隔離見證的狀態

背景

幾位開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。

會議評論

Sipa 正在處理目前 segnet 程式碼中的分叉後升級問題，之後他將建立一個包含 versionbit 邏輯的新 segnet。他的目標是在 0.13 版本發布之前準備好。

娛樂時刻

sipa:       I'm glad bip9 seems final
btcdrak:    sipa: party at your house. we'll bring the beers.
jonasschnelli:    btcdrak finally de-anonymizes at the party.
btcdrak:    haha
sipa:       jonasschnelli: that's why you bring a drink mixer

參與者

IRC nick	Name/Nym
jtimon	Jorge Timon
btcdrak	BtcDrak
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
sipa	Pieter Wuille
wumpus	Wladimir van der Laan

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-03-10

Thu, 10 Mar 2016 00:00:00 +0000

概覽

Segregated witness (segwit) 協調
- 標準性政策
- Segwit 地址類型
使用預生成簽署的 UTXO 進行初始區塊下載 (IBD)
Bitcoin Core 0.11 的反向移植
VersionBits 預設區塊版本
是否應該要求新的 VersionBits 預設版本
結論
娛樂時刻
參與者
免責聲明

Segregated witness (segwit) 協調

背景：幾位開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。

Pieter Wuille 開始說：「我的計劃是將 segwit 重新建立在 BIP9 [versionbits] 之上，新增 BIP9 倒帶邏輯以在軟分叉後升級後繼續，並建立一個新的 segnet [segwit 測試網]。」

從這裡開始的對話討論了標準性政策和新的比特幣地址類型：

標準性政策

[編輯註：BIP9 使用「active」一詞表示「對所有新建立的區塊強制執行」。舊的軟分叉使用具有不同含義的「active」，但為了一致性，下面的文字在所有情況下都使用 BIP9 的含義。]

Suhas Daftuar 要求討論標準性政策，這是節點預設遵循的可選政策，用於決定要中繼或挖掘哪些交易類型。segwit 軟分叉將建立一種新型交易，就像 BIP16 軟分叉建立 P2SH 交易類型一樣，正如在 P2SH 軟分叉啟動之前花費 P2SH 輸出的任何人（有人這樣做了）可能會被盜取該輸出中的比特幣一樣，在 segwit 軟分叉啟動之前花費 segwit 輸出的任何人也可能會被盜取該輸出中的比特幣，如果花費交易在區塊外傳送，或者包含它的區塊從最佳區塊鏈分叉出去。

「我相信我們決定建議錢包作者在 segwit 啟動後等待一段時間再使用[它]」，Daftuar 在 Alex Morcos 的同意下說，描述了一項將決定權留給錢包作者及其使用者的政策。Pieter Wuille 描述了將使用標準性規則的替代方案，「一種可能性是在啟動後 2 個[重新定位期]後才啟用 segwit 交易的中繼/記憶體池邏輯。」這是啟動後約一個月。「另一種可能性是謹慎行事，在軟分叉後版本發布之前不啟用錢包中的功能。」Wuille 既不認可也不拒絕這些替代方案；他只是將它們描述為選項。

Gregory Maxwell 沒有評論是否應該使用標準性政策，但對於 Bitcoin Core 自己的錢包，他建議：「我建議我們在軟分叉啟動後的後續版本中將使用 segwit 作為預設值。我建議使用[後續]版本[因為]這裡不需要自動行為。此外——使用它是一個相當大的行為變化，例如您將回應發出其他地址樣式。讓[使用者介面變更]由對使用者不可見的網路行為觸發並不好。」

行動項目： 討論似乎圍繞著將決定權留給錢包作者而不是建立臨時標準性政策，但沒有達成具體決定，Eric Lombrozo 建議討論轉移到其他主題，「這是可以在 segwit 已經部署並正在等待啟動後決定的事情」。

Segwit 地址類型

背景：segwit 的初始公告要求支援 segwit 的錢包可以透過兩種方式請求付款，一種方式使用完善的 P2SH 地址樣式；另一種將提供完全針對 segwit 最佳化的新地址樣式。BIP142 是該新地址樣式的提案，但由於專案內外的擔憂，對它的支援已從初始 segwit 實作計劃中刪除。

Wuille 開始討論：「我希望我們有一個 segwit 地址樣式作為標準的一部分。」Morcos 同意：「我認為我們應該這樣做，否則每個人都會將 [segwit] 嵌入 P2SH 中，這有點愚蠢。」

Lombrozo 解釋了為什麼它不是初始標準的一部分，「我們沒有推動 BIP142，因為擔心可怕的『新地址』。在[專案]內部，有些人討厭 base58；在外部，有些人仍然以『segwit 太難了』的廢話嘩眾取寵。我認為這是一場不值得現在打的戰鬥。」BtcDrak 表示同意最後一句話。

Maxwell 解釋了他為什麼反對 BIP142 的地址樣式：「[繼續]使用 base58 是糟糕的。」不太認真地（如表情符號所示），他繼續說：「我將拒絕與任何沒有透過電話向我讀過地址的人討論地址編碼。」

Matt Corallo 補充說：「在這裡為 segwit 找出地址不是我們的工作——這是錢包需要參與的事情——真正具有一些使用者體驗經驗的人，這裡不存在。」（原文強調。）Maxwell 同意：「是的，確實如此，但這也是為什麼在[發布 segwit 的]同時採用新地址類型不是一個好主意，它會妨礙這種協作。」

Wuille 仍然不相信：「我認為恰恰相反。」Maxwell 指出還有另一個理由暫時推遲建立新地址樣式，「[Wuille] 提出了擔憂，如果不盡快做某事，我們將永遠被[當前地址的] 80 位元安全性所困；我提醒他 […] 我們即將進行 checksig 改進，以將交易大小減少 30%，這也是建立新地址類型的好時機。」他所暗示的 OP_CHECKSIG 改進是允許使用 Schnorr 數位簽章演算法，這在 Bitcoin Core 的簽名和驗證函式庫 libsecp256k1 中已經支援。

行動項目： 無。[編輯註：正如 Corallo 和 Maxwell 所建議的，我認為如果閱讀此內容的錢包作者開始討論他們希望在新地址樣式中看到什麼以及他們認為應該如何（以及何時）部署它會很好。]

使用預生成簽署的 UTXO 進行初始區塊下載 (IBD)

背景：每個 Bitcoin Core 完整節點下載並處理最佳區塊鏈上的每個區塊，以建立當前未花費交易輸出 (UTXO) 的資料庫。這是可花費比特幣的清單以及它們可能被花費的條件（例如花費簽名必須符合什麼公鑰）。處理所有這些區塊是讓 Bitcoin Core 在第一次啟動時需要兩個小時或更長時間才能完全準備好的原因。Jonas Schnelli 提議為使用者提供某個相當近期區塊高度的預生成 UTXO 集副本，該集由備受推崇的社群成員簽署，以允許使用者跳過下載和處理除最近區塊之外的所有區塊。

Jonas Schnelli 開始說：「你們對我[使用預生成簽署的 UTXO 集執行初始區塊下載 (IBD)] 的方法有什麼看法？」

回饋完全是負面的：

Luke Dashjr：「坦率地說，聽起來充其量是浪費時間。[我]更希望看到 [Bitcoin Core 以] SPV 模式啟動，直到 IBD 完成。」
Morcos：「我認為這是個壞主意。核心開發者（或任何人）不應該在任何時候授權帳本的狀態。」
Wladimir van der Laan：「這是有風險的，它給系統帶來了信任。你會信任誰來簽署這樣的東西？」
Wuille：「這不是減少區塊服務；而是改變信任模型。」

行動項目： Schnelli 優雅地接受了回饋，提供了一個積極的表情符號，並說：「好吧…那麼讓我不要實作它。」

Bitcoin Core 0.11 的反向移植

背景：Bitcoin Core 的軟體生命週期文件說：「我們維護主要版本直到它們的『維護結束』。我們通常維護當前和以前的主要版本。所以如果當前版本是 0.12，那麼 0.11 也被認為是維護中的。一旦 0.13 發布，那麼 0.11 將被認為已達到『維護結束』。」

Morcos 開始說：「我們還需要將所有這些軟分叉 [BIP 9、68、112、113] 反向移植到 0.11；對嗎？」

Maxwell、van der Laan 和 Wuille 同意，van der Laan 說：「我認為反向移植到 0.11 是相當必要的；那只是往回一個版本」。

Dashjr 希望看到反向移植到 0.10，如果它們不太困難的話：「0.11 是必要的；0.10 是理想的；但我想我稍後會處理 0.10。」

Morcos 回答：「0.10？我希望你們願意跳過 0.11。我擔心這些主要的[反向移植的軟分叉]測試得有多好。」BtcDrak 似乎同意：「我會跳過 0.11」。

行動項目： Morcos 和 BtcDrak 討論了分工，每個人似乎都同意將所有 BIP 反向移植到 Bitcoin Core 0.11 系列。Wuille 總結：「我認為我們可以很快完成 [BIP] 9/68/112/113」。Morcos、van der Laan 和 BtcDrak 都同意，BtcDrak 說「68/112/113 從我這邊完成了；Morcos 想要新增更多 RPC 測試，這很好。」

VersionBits 預設區塊版本

背景：VersionBits BIP9 允許使用區塊標頭版本欄位作為位元陣列，以便礦工可以同時表示對多達 29 個軟分叉的準備就緒。根據目前的程式碼和提案，未表示對任何軟分叉準備就緒的礦工將建立「版本 4 區塊」，即與用於觸發和執行 BIP65 CLTV 軟分叉相同版本的區塊。

Daftuar 開始說：「現在 [pull request] #7575 將在第一個軟分叉啟動後恢復到版本 4 區塊，如果佇列中沒有其他軟分叉；我假設這是無意的？」

Wuille 回答說這實際上是有意的，「這[行為]對我來說似乎是正確的；舊版本 [4] 用於表示『沒有 versionbits』。」

Morcos 不確定這是正確的做法，「所有先前的軟分叉都要求礦工升級。我想做的是，在這第一個軟分叉中，要求[區塊標頭]版本大於 4。然後我們可以對不是[頂部位元為] 001 的位元欄位發出警告，除非它小於或等於 4，我們知道這些是無效的。」

頂部位元為 001000 的位元欄位被提議為一個好選項，Maxwell 說：「我喜歡 001000，因為它會鼓勵視覺化工具解析位元欄位而不僅僅是顯示整數。」這是因為將前三個位元設定為 001 在原始系統中相當於版本號 536,870,912，這在任何以這種方式顯示它的區塊鏈瀏覽器中看起來都非常奇怪。

行動項目： 沒有明確提及，但似乎預設版本位元欄位可能會將其頂部位元設定為 001000。

是否應該要求新的 VersionBits 預設版本

在前面的討論似乎以將預設版本位元欄位頂部位元設定為 001000 結束後，Pieter Wuille 想知道使預設版本大於或等於 5 是否應該是「共識[規則]？我更喜歡不引入新的共識邏輯，特別是當支援它的唯一論據是更好的警告保證時。」

Morcos 回答：「我想它不必是共識規則，但我認為如果它是共識規則，對我來說更清楚它沒有問題，因為這就是[以前的版本增加軟分叉]的工作方式。如果它不是共識規則，你不能確定舊節點會被警告規則已經改變[但]也許這不值得擔心。」（原文強調。）

Wuille 問：「我們擔心[礦工]可以繞過警告機制嗎？」軟分叉與硬分叉不同，因為大多數算力可以隨時開始執行軟分叉，而不會造成持久的鏈分裂。versionbits 和舊的軟分叉管理方法都允許礦工使用他們的算力向其他礦工表示他們準備好執行軟分叉，以便他們可以同時執行它，但沒有任何東西直接阻止礦工私下同意軟分叉。這意味著軟分叉警告機制取決於礦工的合作，試圖設計它以防止某種形式的繞過可能是浪費精力。

Morcos 似乎同意不將其作為共識規則，儘管它「對我來說似乎很奇怪：我覺得我們正在從舊系統過渡到新系統，過渡應該符合舊系統——但只要我們將預設值設為 00100，那麼我認為這只是理論上的擔憂。」

行動項目： 無。

結論

會議在預定結束時間結束，繼續討論如何為 versionbits 管理的軟分叉變更警告和警報。

娛樂時刻

wumpus: it's risky, it brings trust into the system
wumpus: who would you trust to sign something like that?
sipa:   Bob.
wumpus: yes, definitely Bob
Luke-Jr: XD
CodeShark: :p

參與者

IRC nick	Name/Nym
BlueMatt	Matt Corallo
btcdrak	BtcDrak
CodeShark	Eric Lombrozo
evoskuil	Eric Voskuil
gmaxwell	Gregory Maxwell
jonasschnelli	Jonas Schnelli
Luke-Jr	Luke Dashjr
morcos	Alex Morcos
sdaftuar	Suhas Daftuar
sipa	Pieter Wuille
warren	Warren Togami
wumpus	Wladimir van der Laan

免責聲明

引用的討論內容經過修改，調整了大小寫、標點符號和拼寫以產生一致的句子。括號內的詞語和片段以及背景敘述和解釋性說明是由本摘要作者新增的，可能會意外改變某些句子的含義；如果您認為任何引用脫離了上下文，請聯絡我們，我們將糾正錯誤。

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

IRC meeting summary for 2016-03-03

Thu, 03 Mar 2016 00:00:00 +0000

概覽

VersionBits (BIP9) 軟分叉邏輯
交易積壓
- 選擇性 Replace-by-Fee (RBF) 使用
- -paytxfee 語意變更
FeeFilter
Child Pays For Parent (CPFP) 挖礦
Segregated Witness (segwit) 狀態
結論
娛樂時刻
參與者
免責聲明

VersionBits (BIP9) 軟分叉邏輯

背景：BIP9 是一種部署軟分叉的機制，取代了用於部署 BIP 34、66 和 65 的 IsSuperMajority() 機制。舊方法要求軟分叉按順序進行，因為礦工表示他們準備好執行軟分叉 3 號時，也必須表示他們願意執行軟分叉 2 號和 1 號。因此，我們目前會等待軟分叉 1 號完全執行後再嘗試軟分叉 2 號，並等待 2 號完全執行後再嘗試軟分叉 3 號。這可能造成延遲，並對下一個執行哪個軟分叉產生爭議。VersionBits 允許礦工表示準備執行最多 29 個不同的軟分叉，並提供一些其他優良功能，例如更好的執行時間可預測性。

今天的討論集中在 Pull Request (PR) #7575 和 BIP 最近的一些變更上，「只要（軟分叉）部署的開始/結束時間不重疊，（區塊標頭版本，即礦工用來表示準備執行的）位元就永遠不會模糊。（這意味著）不需要追蹤不同部署之間的相依性，（它們）只（需要）明智地選擇開始/結束時間」(Pieter Wuille)。幾位參與者對此表示滿意。

關於不同的 BIP9 議題，Gregory Maxwell 說：「考慮到低變異數觸發機制和啟動延遲，我仍然有點擔心啟動門檻可能太高。但我認為除了嘗試看看我們的第一個 versionbits 分叉是否無法在合理時間內啟動之外，別無他法。」VersionBits 的啟動門檻為 95%，與 IsSuperMajority() 使用的相同，但 VersionBits 是在 2,016 個區塊上測量，而不是 1,000 個區塊，並且每 2,016 個區塊僅測量一次，而不是像 IsSuperMajority() 那樣每個區塊都測量。這意味著即使其他所有礦工都發出準備信號，產生少於 5% 區塊的小型礦工仍然可能阻止分叉觸發，只是因為該小型礦工在該期間「幸運」地產生了超過 5% 的區塊。

Pieter Wuille 回應 Maxwell 的擔憂說：「如果需要，我們可以降低門檻；提高[它]更困難，因為這可能導致警告不會觸發。」

對話繼續討論如何優化 Bitcoin Core 的迴歸測試 (regtest) 模式，以測試 4,032 個區塊的長鏈，例如 versionbits 測量的那些。

本次討論的最終行動項目：

Pieter Wuille 將對 PR #7575 進行一些變更
鼓勵所有共識協議開發者審查 #7575 和 BIP9，因為這些很可能很快就會用於一個或多個待處理的軟分叉。

交易積壓

背景：在會議前的幾天內，廣泛報導許多節點的記憶體池包含高於正常數量的未確認交易。雖然系統狀態的重大變化在任何情況下都值得調查，但最近發布的 Bitcoin Core 0.12.0 及其對記憶體池政策的重大變更可能使調查這一點比平常更重要。

[編輯註：這次討論有點漫無邊際，即使會議主持人說「好吧，我們正在離題」，也沒有任何正式的主題變更。我將其分為幾個小節以希望提高清晰度，但這使某些元素明顯脫離了線性順序。]

關於目前狀況，Maxwell 說：「現在每位元組超過 1 satoshi 的交易費用有所增加。低於該[每位元組費用]水平約一千兆位元組的長期背景垃圾負載對我來說似乎基本上沒有變化。」

Luke Dashjr 問：「有人調查過這些新交易是真實的還是垃圾訊息嗎？」Maxwell 回答：「有些人調查過；Peter Todd 在推特上發布了一些分析，強烈支持後者。」

Peter Todd 補充說：「是的，它們看起來像長鏈，最終一切都回到發送者那裡。但還沒有正式的書面報告[關於這項分析]。」

Alex Morcos 說「在我看來，積壓正在減少」。

選擇性 Replace-by-Fee (RBF) 使用

Peter Todd 指出 GreenAddress.it (GA.it) 錢包「在他們的 GitHub 儲存庫中有 RBF 程式碼」。Maxwell 同意：「GA.it 一直在致力於此；我認為他關於如何最好地支援使用額外輸出更新[交易]的設計陷入了困境。順便說一下，有了新的 Schnorr 聚合簽名提案，更新更多輸出將更具吸引力。」

Schnorr 聚合簽名提案將允許同一交易的多個輸入共享簽名欄位，如果它們都使用足夠相似的腳本（如果它們都由同一個錢包花費，這是預期的）。由於簽名是典型交易中最大的單一部分，能夠將多個簽名組合在一起而不損失安全性，可以顯著壓縮交易。由於 Replace By Fee (RBF) 交易中支付的費用基於交易大小，這種壓縮將使 RBF 在省錢方面比今天傳送單獨交易更有效率。

-paytxfee 語意變更

背景：在會議前大約 24 小時，開發者 Mike Gogulski 在 Bitcoin Core 儲存庫中開啟了一個問題，報告 -paytxfee 設定選項的行為隨著 Bitcoin Core 0.12.0 的發布而改變

「所以我認為發生了什麼，」Pieter Wuille 寫道，「是在某個時候我們將挖礦程式碼切換為每位元組而不是每千位元組。後來引入了[一個]全域[變數]，即使程式碼的其餘部分已更新為每位元組，它隱式地保留了『四捨五入到 1,000 位元組進行費用計算』的行為，只是現在，隨著全域[變數]的消失，我們實際上得到了準確的變更。」

由於使用此設定選項時交易大小以前會四捨五入，但現在正在精確計算，因此現在每位元組支付的費用低於使用 -paytxfee 旗標的使用者的預期。請注意，此語意變更僅影響手動設定此選項的使用者。

Alex Morcos 提到 -maxsigcachesize 基本單位也已變更；現在是以兆位元組為單位。他建議：「在變更任何選項或 RPC 呼叫的行為時有一個檢查清單 […] 我不確定有多少人會在兩英尺厚的發布說明中發現所有這些警告，但擁有它們仍然很好。」

FeeFilter

背景：Alex Morcos 最近提出的 draft BIP133 建議在 P2P 協議中新增一條新訊息，允許節點告訴其對等節點，它只想接收關於新交易的通知，如果這些交易支付的每位元組交易費用超過某個水平。請求過濾掉低費用交易的節點可以選擇它想要的任何每位元組費用水平。由於今天的節點無法告訴其對等節點它們不會處理低費用交易，因此相信引入此訊息將減少網路上浪費的流量。

討論極為簡短。Morcos 說：「它減少了約 40% 以上的交易傳送和接收頻寬」。Maxwell 回答：「太棒了」，還說「feefilter 很棒」。

Dashjr 建議 feefilter「需要某種『模式』來處理『我們如何測量大小』等問題，但[那]不是什麼大問題。」Morcos 有不同的看法：「我基本上認為我們在需要之前不引入複雜性。」Maxwell 同意：「我們不會用完訊息類型，所以我們可以稍後引入 modefilter」。

從長遠來看，Maxwell 補充說：「我預計中繼工作方式會在未來幾年發生重大變化；所以我們可能不應該在這裡過度設計。」

feefilter 的行動項目是更多審查和測試。

Child Pays For Parent (CPFP) 挖礦

背景：Suhas Daftuar 有一個進行中的 (WIP) pull request，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child [transaction] Pays For Parent [transaction] (CPFP)。

Daftuar 報告：「我在過去兩天一直在執行[該程式碼]。[我一直在]大約每 128 筆交易比較現有的挖礦演算法和新演算法。[當]查看找到區塊之前對 CreateNewBlock() [函數]的最後一次呼叫時，我看到最後 144 個資料點的費用/區塊有[顯著]增加。」

Maxwell 解釋了為什麼預期會有非微不足道的獲利能力增加：「我相信它應該會從我所看到的情況中對選擇產生一些相當大的差異。許多 OTHERBRAND [原文如此] 錢包的使用者沒有費用估算，總是花費未確認的找零，似乎經常產生非常低費用、非常高費用的鏈（在意識到他們需要從第一筆交易中支付更多費用之後）。」

關於用於測試獲利能力增加的方法的討論解釋說，該測試可能多次計算了一些交易，因此每個區塊捕獲的費用的確切增加可能少於測試所指示的。儘管如此，在其他條件相同的情況下，人們可以安全地假設礦工會樂於執行增加其潛在獲利能力的程式碼。

然後 Daftuar 報告了新程式碼在效能方面的成本。「所以有三個效能方面需要考慮：

「記憶體池保持[相關交易及其費用的]索引的額外工作
「在呼叫 TestBlockValidity() 之前 CreateNewBlock() 的部分
「TestBlockValidity 花費的時間（[這]比 CreateNewBlock() 的其餘部分大得多，這就是為什麼我認為將它分開是有意義的）」

技術討論繼續，Daftuar 提供了他測試的數字。結果和測試方法可以在 PR #7594 和 #7600 中找到。在一種情況下，這個新程式碼似乎加快了與挖礦相關的過程，而在至少另一種情況下，減速似乎微不足道。

行動項目：「[讓]人們開始審查 CPFP [PR] #7594、#7598 和 #7600。」

後記：在會議後的討論中，Maxwell 向 Daftuar 建議「如果 CPFP 似乎相當穩定，我們可能會考慮要求一個中等規模的礦工執行它（與其他東西平行）；如果只有一個中等規模的礦工正在執行它，它將對網路具有大部分的可用性優勢。[…] 我建議這樣做的唯一原因是，至少有一些使用者的延遲可以透過[執行]它來避免。」Daftuar 似乎同意，並表示他將與 Maxwell 合作尋找礦工進行現場測試。

Segregated Witness (segwit) 狀態

背景：幾位開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。

Eric Lombrozo 首先說：「幾天前我們有一個[鏈]分叉」。Wuille 回答：「我沒有時間調查；我希望這是由執行舊版本 [segwit] 程式碼的礦工造成的，而不是其他原因」。Lombrozo 承認「這是最有可能的 - 但我們還沒有縮小實際導致它的條件。」

Wuille 說：「我計劃很快做一個 segnet4，但我們需要先了解是什麼導致了這個問題。」

Morcos 問：「有人卡在短分叉上嗎」，Lombrozo 回答：「我認為可能還有一些」。Cory Fields 說「我有興趣看看那裡」。

Maxwell 建議一個除錯工具：「[如果] regtest 網路將其 git 構建資訊放在版本號中可能會很有用。[這]對隱私來說很糟糕，但[它]在這裡會很有用。」

行動項目是幾個人將致力於確定分叉的原因。

結論

會議在預定結束時間結束，議程上仍有一些項目。一些會後立即討論已被整合到本摘要中。

娛樂時刻

gmaxwell:  okay, we're going on a tangent.
sipa:      going on a tangent is a sin
morcos:    oh no
CodeShark: no trig puns
sipa:      I co-sign that

參與者

IRC nick	Name/Nym
btcdrak	BtcDrak
cfields	Cory Fields
CodeShark	Eric Lombrozo
gmaxwell	Gregory Maxwell
Luke-Jr	Luke Dashjr
morcos	Alex Morcos
paveljanik	Pavel Janik
petertodd	Peter Todd
sdaftuar	Suhas Daftuar
sipa	Pieter Wuille

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。

2016-02-25 IRC 會議摘要

Thu, 25 Feb 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題
BIP 68/112/113 推出
即將發布的 OpenSSL 版本
與會者
趣味橋段

會議記錄

主要議題

BIP 68/112/113 推出
即將發布的 OpenSSL 版本

簡短議題

PR #7542 實作 “feefilter” P2P 訊息尚未被審查。

BIP 68/112/113 推出

背景

BIP 68 透過序列號訊號發送的共識強制交易替換。 BIP 112 CHECKSEQUENCEVERIFY。 BIP 113 使用中位時間過去作為鎖定時間計算的端點。

簡而言之：BIP 68 將序列號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供 bitcoin 腳本系統存取。 BIP 113 在鎖定時間交易中啟用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）的使用。

BIP 9 具有超時和延遲的版本位元。

目前軟分叉是透過 IsSuperMajority 機制完成的，意思是當最近 1000 個區塊中有 95% 的版本號高於 X 時，分叉就會部署。目前正在開發一種新方法，使用版本號的所有位元，適當地稱為 versionbits。因此，不是在版本大於（例如）00000000011（3）時發生分叉，而是在（例如）第 3 位元被設定時發生分叉（即 00100000011）。這樣軟分叉就可以同時且獨立地部署。

會議討論

相當多的算力正在使用區塊版本號為 BIP 109 投票，這使得使用 IsSuperMajority 的部署變得複雜。這也可能延遲隔離見證的部署。因此可能會使用 versionbits。

BIP 68 需要 v2 交易，目前不會被中繼。

相當一部分算力在任何發布的軟體支援 CLTV（BIP 65）之前就已經訊號發送準備好強制執行它。

會議結論

PR #7561 需要轉換為 versionbits。

審查 PR #7575。

中繼政策可能會在軟分叉部署之前變更。

與 btcd 開發人員討論 BIP 9/68/112/113 以獲得回饋。

向郵件列表發送關於 BIP 68/112/113 部署的電子郵件，徵求任何反對意見。

為了防止過早啟動，將為 BIP 9 軟分叉定義「開始時間」。建議在預期發布日期後 1-2 個月的開始時間。

即將發布的 OpenSSL 版本

背景

有一個新的 OpenSSL 發布修復了一些安全問題。

從 0.12 開始，Bitcoin Core 使用他們自己的 libsecp256k1 進行 ECDSA 簽章驗證，而不是 OpenSSL。

會議討論

OpenSSL 應該盡可能從軟體中移除。

OpenSSL 實際上只在付款協定中需要，而該協定幾乎未被使用。建議預設停用它並聆聽回饋。

會議結論

暫時需要推出嚴重 OpenSSL 漏洞的緊急更新。

與會者

petertodd         Peter Todd
gmaxwell          Gregory Maxwell
btcdrak           btcdrak
morcos            Alex Morcos
sipa              Pieter Wuille
CodeShark         Eric Lombrozo
jonasschnelli     Jonas Schnelli
sdaftuar          Suhas Daftuar
warren            Warren Togami

趣味橋段

25:30 <btcdrak> wumpus: 我會謹慎合併任何共識重構 PR，直到我們合併 sf 程式碼。這將使回溯到 0.12 更容易且更容易驗證（基本上是簡單的 cherrypick）。
26:28 <petertodd> btcdrak: 我建議我們買一台時光機給 jtimom，這樣他就可以在過去進行重構了 :)
26:40 <petertodd> *jtimon

2016-02-18 IRC 會議摘要

Thu, 18 Feb 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題/備註
feefilter P2P 訊息
SequenceLocks 檢查的重組效能
與會者
趣味橋段

會議記錄

主要議題

feefilter P2P 訊息
SequenceLocks 檢查的重組效能

簡短議題/備註

注意：這次會議很短，因為一些開發人員正在參加 Bitcoin Roundtable。

Btcdrak 建議安排 C++ 和 Python 的 Jetbrains IDE 的開源授權。維護者（wumpus）需要申請。

`feefilter` P2P 訊息

背景

Bitcoin Core 0.12 中引入了有限記憶池的概念，以提供對低費用且未被挖掘的攻擊或垃圾交易的保護。目前有一個拒絕訊息允許通知對等節點關於費用不足的情況，但只是針對每個交易。feefilter 訊息允許節點通知其對等節點它願意接受的最低交易費用率，以便其對等節點可以跳過中繼不符合的交易。

會議討論

Wumpus 還沒有查看費用過濾器，所以將在下次會議上討論。

會議結論

審查實作 “feefilter” P2P 訊息 #7542

SequenceLocks 檢查的重組效能

背景

BIP 68 透過序列號訊號發送的共識強制交易替換。

BIP 68 將先前未使用的序列號欄位的意義改為相對鎖定時間。

SequenceLocks 函式用於根據 BIP 68 評估序列鎖定時間或高度。

檢查序列鎖定以確定交易是否有效需要查詢其所有輸入的高度。在重組中，按照目前的情況，這將需要重新評估記憶池中每個交易的輸入。 PR #7187 嘗試為每個交易快取包含具有序列鎖定的輸入的最新區塊的區塊雜湊。在發生重組時，如果該雜湊仍在鏈上，你知道先前計算的高度和時間（也已快取）仍然有效。這意味著理想情況下大多數輸入不需要重新評估。

會議討論

有討論是否應該將此回溯到 0.12 和 0.11。由於 0.12 中對記憶池的所有變更，將該最佳化回溯到已經慢得多的 0.11 可能會非常困難。

會議結論

審查/測試為 SequenceLocks 檢查保持重組快速 #7187

與會者

wumpus            Wladimir J. van der Laan
morcos            Alex Morcos
btcdrak           btcdrak
paveljanik        Pavel Janik
sdaftuar          Suhas Daftuar
shea256           Ryan Shea

趣味橋段

08:51 <morcos> 現在的主題是 7187 嗎？
09:22 <wumpus> 我們還沒有主題 :)
09:32 * btcdrak 為 wumpus 泡咖啡

2016-02-11 IRC 會議摘要

Thu, 11 Feb 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題
BIP68 審查
軟分叉邏輯（BIP9）
squash/rebase 建議
與會者

會議記錄

主要議題

BIP68 審查
軟分叉邏輯（BIP9）
squash/rebase 建議

簡短議題

會議結論

一般規則是：做任何更容易閱讀和審查的事情。

與會者

wumpus            Wladimir J. van der Laan
sipa              Pieter Wuille
morcos            Alex Morcos
maaku             Mark Friedenbach
jtimon            Jorge Timón
petertodd         Peter Todd
gmaxwell          Gregory Maxwell
paveljanik        Pavel Janik
cfields           Cory Fields
sdaftuar          Suhas Daftuar

2016-02-04 IRC 會議摘要

Thu, 04 Feb 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題
Segwit 提議的變更
Sequence locks
與會者
趣味橋段

會議記錄

主要議題

Segwit 提議的變更
Sequence locks

簡短議題

Bitcoin core 0.12 已到候選發布版本 3 https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

在先前會議中討論的生命週期結束政策已發布。

Segwit 提議的變更

背景

隔離見證改變了交易的結構，使得簽章可以與交易的其他部分分離。這允許在中繼時節省頻寬、修剪舊簽章、透過引入腳本版本來軟分叉所有未來的腳本變更，並解決所有非故意形式的可延展性。在上次 scaling bitcoin 會議期間，Pieter Wuille 展示了一種透過軟分叉實現這一點的方法，並提議透過將簽章資料對總區塊大小進行折扣來增加區塊中的最大交易量。隔離見證是 bitcoin-core 容量增加路線圖的一部分。更詳細的說明：

Pieter Wuille 在舊金山 bitcoin 開發者聚會的演講（更技術性）
Andreas Antonopoulos 在 let’s talk bitcoin 播客的演講（較不技術性）

Peter Todd 為隔離見證提出了兩個想法：

未驗證的區塊擴充資料，這將使未來新增共識資料的軟分叉更容易部署。
礦工應該證明他們或可信的第三方有前一個區塊資料的副本才能建立新區塊，作為一種不進一步激勵無驗證挖礦的方式。

會議討論

關於未驗證區塊擴充資料的討論正在進行中。 Petertodd 正在處理 prev-block-proof，他可能會在幾天內準備好供審查。這個想法可以用來完全阻止 SPV 挖礦，我們是否這樣做是一個實作決定。也可以強制區塊必須是空的才能進行無驗證挖礦。 SPV 挖礦的問題在於它破壞了 SPV 錢包的安全模型。

會議結論

由於討論轉向 bitcoin 應該成為什麼的更長期想法，它被重新導向會議外，因為會議是針對短期開發的。

Sequence locks

背景

BIP 68 透過序列號訊號發送的共識強制交易替換。 BIP 112 CHECKSEQUENCEVERIFY。簡而言之：BIP 68 將序列號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供 bitcoin 腳本系統存取。

會議討論

BIP68 實作已完成並正在收集 ACK，BIP112 實作也是如此 Ajtowns 編寫了一些測試腳本，為此你需要將兩個 PR 合併在一起。btcdrak 在 https://github.com/btcdrak/bitcoin/tree/sequenceandcsv 這樣做了下游使用者已進行了廣泛的測試，發現程式碼對他們的案例很有用。所有 BIP 文字都已合併且最終確定。 Petertodd 指出他認為我們仍然缺少實際軟分叉的交易級單元測試。

會議結論

審查並 ACK #7184 和 #6564

與會者

petertodd          Peter Todd
wumpus             Wladimir J. van der Laan
btcdrak            btcdrak
jtimon             Jorge Timón
sipa               Pieter Wuille
Tasoshi            Tasoshi
phantomcircuit     Patrick Strateman
cfields            Cory Fields
gmaxwell           Gregory Maxwell
shea256            Ryan Shea

趣味橋段

29 petertodd        注意我認為我們仍然缺少交易級單元測試，我會基於此 NACK 實際的軟分叉
29 wumpus           petertodd: 我認為提前 NACK 是沒有建設性的
30 btcdrak          wumpus: 他是首席反對者，他必須這樣做！
30 btcdrak          呃甚至是 Chief
30 petertodd        btcdrak: 我 Naysay 你的拼寫 :P

2016-01-28 IRC 會議摘要

Thu, 28 Jan 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題
重構時段
0.12.0 的未解決問題
新的「關鍵」OpenSSL 發布如何影響我們
與會者
趣味橋段

會議記錄

主要議題

重構時段
0.12.0 的未解決問題
新的「關鍵」OpenSSL 發布如何影響我們

會議結論

長期目標是只在 BIP70 中保留 openSSL。

與會者

wumpus           Wladimir J. van der Laan
jonasschnelli    Jonas Schnelli
gmaxwell         Gregory Maxwell
petertodd        Peter Todd
jtimon           Jorge Timón
cfields          Cory Fields
btcdrak          btcdrak
Luke-Jr          Luke Dashjr
paveljanik       Pavel Janik
maaku            Mark Friedenbach

趣味橋段

47    wumpus           也要注意 bitcoin 從不分叉

48    wumpus           gmaxwell: 只要加上免責聲明「不適用於分叉」
48    jonasschnelli    「不適用於分叉」？HF 還是 SF....
48    jonasschnelli    </funmode>

2016-01-21 IRC 會議摘要

Thu, 21 Jan 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題
chainstate 混淆的 0.11 回溯發布版本
C++11 更新
EOL 政策 / 發布週期
與會者
趣味橋段

會議記錄

主要議題

chainstate 混淆的 0.11 回溯發布版本
C++11 更新
EOL 政策 / 發布週期

簡短議題

最近合併了一個設定選項「-permitrbf」，允許節點選擇是否替換 opt-in RBF 交易。有些討論希望變更 0.12.0 的預設行為並將其設定為 false。由於大多數與會者在相關的 pull request（#7386 和 #7388）上表達了他們的意見，因此在會議中沒有進一步討論。
有一些關於 bitcoin core 中資料庫損壞的問題被提出。雖然問題還沒有確定是 LevelDB，但長期計劃仍然是切換到一個新的、維護良好的資料庫。

chainstate 混淆的 0.11 回溯發布版本

背景

正如一些 Windows 使用者過去可能經歷的，防毒軟體經常偵測到 bitcoin 資料庫檔案中的值，這些是誤報。因此刪除這些檔案並損壞資料庫。為了防止這種情況發生，開發人員去年討論了一種混淆資料庫檔案的方法並實作了它。雖然升級後可以降級，但如果你從新的 0.12 安裝開始，或者你在 0.12 上執行了 -reindex，就不可能降級到 0.11（除非從頭開始）。

會議討論

提議的 pull request 在 0.11 中偵測混淆，因此它會拋出相關的錯誤訊息。為了避免將來出現這種情況，為 chainstate 設定版本號會是好的。

會議結論

在 0.12 最終發布版本之後立即發布 0.11 回溯發布版本，以避免混淆。

C++11 更新

背景

C++11 是 C++ 語言的更新。它提供了新功能、擴充的標準函式庫等。 Zerocash 必須使用一些 c++11 函式庫編寫，一些 IBLT 模擬程式碼是用 c++11 編寫的，他們希望將其回收用於最終的 core 提交。

會議討論

C++11 所需的所有變更都已完成，準備好切換了。 Cfields 與 travis 團隊交談，所有需要的功能（trusty、快取）將在月底前準備好，因此他建議等到那時再切換。 f2pool 的 Wangchun 表示他不會執行需要 C++11 編譯器的程式碼。沒有人知道他確切的疑慮是什麼。Wumpus 指出 gitian 建構的執行檔在 C++11 切換後不需要任何特殊的作業系統支援。

會議結論

等待 Travis 更新以切換到 C++11。與 wangchun 談談他的疑慮。

EOL 政策 / 發布週期

背景

一般來說，錯誤修復、翻譯和軟分叉會維護 2 個主要發布版本。btcdrak 提議將此正式制定為 bitcoin core 的軟體生命週期文件，以便告知使用者可以期待什麼，以及開發人員應該為什麼編碼。此文件的 Pull request。鑑於龐大的 0.12 變更日誌，jonasschnelli 詢問較短的發布週期是否是個好主意。目前大約是 6 個月的發布週期。

會議討論

Gmaxwell 指出他不知道回溯有多有用，因為沒有關於它們的回饋，但認為目前的政策還不錯。「我觀察到回溯似乎是浪費時間。從原則上來說，我認為它們很重要，但業界似乎不同意。」如果沒有人使用回溯，可能不會得到足夠的測試。人們普遍同意 2 個主要發布版本的方法。

週期長度也會導致挫折和壓力，以使功能納入，因為如果沒有納入新發布版本，6 個月內都不會看到它。對使用者來說，更頻繁的主要發布版本並不一定更好，因為升級可能並不總是一個簡單的過程。發布版本也需要大量工作。如果 GUI 和錢包分離，該部分可以有更頻繁的發布版本。

會議結論

政策將是：0.X 的最終發布意味著 0.(X-2) 的生命週期結束，這意味著在 6 個月週期上提供 1 年的支援。

與會者

wumpus          Wladimir J. van der Laan
gmaxwell        Gregory Maxwell
jonasshnelli    Jonas Schnelli
cfields         Cory Fields
btcdrak         btcdrak
sipa            Pieter Wuille
jtimon          Jorge Timón
maaku           Mark Friedenbach
kangx_          Kang Zhang
sdaftuar        Suhas Daftuar
phantomcircuit  Patrick Strateman
CodeShark       Eric Lombrozo
bsm117532       Bob McElrath
dkog            dkog
jeremias        Jeremias Kangas

趣味橋段

jonasschnelli   maaku: 重構？我們有一個 main.cpp。我們不需要重構。:)
gmaxwell        jonasschnelli: 我們能把所有東西都移回 main.cpp 嗎？我會節省很多搜尋時間。:P

wumpus          #endmeeting
lightningbot`   Meeting ended Thu Jan 21 19:55:48 2016 UTC.
btcdrak         wumpus: 一桿進洞
maaku           這次做對了！
gmaxwell        萬歲！

2016-01-14 IRC 會議摘要

Thu, 14 Jan 2016 00:00:00 +0000

概覽

會議記錄

主要議題

Versionbits
隔離見證的狀態
0.12 bitcoin-core 發布狀態
共識程式碼封裝（libconsensus）
Locktime PR

Versionbits

會議結論

關閉 PR #7142，因為它現在是 #7148 的一部分每個人都可以自由改進發布說明，只需提交 PR。

共識程式碼封裝（libconsensus）

背景

Satoshi 並不是最好的程式設計師，這留下了相當混亂的程式碼。理想情況下，你會將影響網路共識的程式碼部分分離出來，但在 bitcoin 中它們都交織在一起。 Libconsensus 最終應該成為這個部分。這樣人們可以更容易地在非共識部分進行變更，而不用擔心造成網路分叉。然而，這是一個緩慢且危險的專案，需要移動大量程式碼。

會議討論

jtimon 有 4 個與 libconsensus 相關的 PR 待審，分別是 #7091、#7287、#7311 和 #7310 他認為如果不先合併類似 #7310 的東西，任何「大圖分支」都將高度不可讀。他目前擁有的最長的「大圖分支」是 https://github.com/jtimon/bitcoin/commits/libconsensus-f2 他將分階段記錄計劃和「大圖」：

有東西稱為 libconsensus：公開 verifyScript。（完成）
將其餘的共識關鍵程式碼（不包括儲存）放在同一個建構套件中（見 #7091）
討論 libconsensus 的完整 C API
將其分離到子儲存庫 Wumpus 指出他希望盡快開始 3，因為 API 可以很好地引導這項工作。

會議結論

審查 #7091、#7287、#7311 和 #7310

Locktime PR

背景

BIP 68 透過序列號訊號發送的共識強制交易替換。 BIP 112 CHECKSEQUENCEVERIFY。 BIP 113 使用中位時間過去作為鎖定時間計算的端點。簡而言之：BIP 68 將序列號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供 bitcoin 腳本系統存取。BIP 113 在鎖定時間交易中啟用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）的使用。

會議討論

我們需要在 2 種實作之間做出選擇，即 #6312 和 #7184。 PR #7184 是 CreateNewBlock 最佳化與 #6312 不相容的結果。 jtimon 認為可以相對快速地合併，因為 #7184 基於 #6312，後者有大量的測試和審查。

會議結論

關閉 #6312，採用 #7184。 Morcos 將修復 #7184 上未解決的問題 btcdrak 將更新 BIP 文字

與會者

wumpus			Wladimir J. van der Laan
btcdrak			btcdrak
morcos			Alex Morcos
jtimon			Jorge Timón
Luke-Jr			Luke Dashjr
MarcoFalke		Marco Falke
jonasshnelli	Jonas Schnelli
cfields			Cory Fields
sipa			Pieter Wuille
kanzure     	Bryan Bishop
droark			Douglas Roark
sdaftuar		Suhas Daftuar
Diablo-D3   	Patrick McFarland

趣味橋段

54	wumpus			#meetingstop
54	wumpus			#stopmeeting
54	btcdrak			haha
54	MarcoFalke		#closemeeting
54	wumpus			#endmeeting
54	lightningbot`	Meeting ended Thu Jan 14 19:54:26 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)

致謝

本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 bitcoin-discuss 郵件列表，附帶免責聲明「請記住我不是開發人員，所以有些內容可能不正確或完全錯誤。」並將版權置於公有領域。

2016-01-07 IRC 會議摘要

Thu, 07 Jan 2016 00:00:00 +0000

概覽

會議記錄
主要議題
簡短議題/備註
0.12 候選發布版本
下一階段專案的詳細路線圖
與會者
趣味橋段
致謝

會議記錄

主要議題

0.12 候選發布版本
下一階段專案的詳細路線圖

簡短議題/備註

Gmaxwell 已請 Luke-Jr 接任 BIP 編輯。他將處理積壓的工作。他已寄信到郵件列表徵求資訊。

所有平台現在似乎都使用 C++11 編譯 bitcoin 了。Travis 仍需要 C++11 編譯器，cfields 將會啟用它。

Segnet 將很快進行向後不相容的變更，以改變承諾結構。

0.12 候選發布版本

背景

Bitcoin Core 0.12 計劃於二月左右發布，引入了許多修復和改進。

會議討論

發布說明仍需要更多資訊。 PR #7151 和 #7149 被提到可能仍會納入 0.12，以及 #7098 的快速修復（待撰寫）。 Morcos 強烈認為照現狀發布 0.12 是相當糟糕的。由於 smartfee 的變更，卡住的交易應該會非常罕見，但如果發生了，會比 0.11 更糟，因為網路更容易「遺忘」交易。 Morcos 提出 PR #7312「新增 RPC 呼叫 abandontransaction」作為快速修復方案，讓使用者能夠使他們的錢包遺忘不在記憶池中的交易的輸入。應該為 0.12.1 建立更好的解決方案。

會議結論

檢視 PR #7151、#7149 和 #7312 Cfields 將處理 #7098 的修復

下一階段專案的詳細路線圖

背景

Morcos 請求提供專案時間軸的一些方向，以及實作順序大致應該是什麼。這樣才能集中精力和焦點。更清晰的計劃可以促使資源投入到正確的部分。

會議討論

Jonasschnelli 將處理錢包的 RBF 功能。
Cfields 計劃下週發布網路堆疊改造的徵求意見。
BIP 9 versionbits 的優先順序稍微往後移。
Libconsensus 重構需要排定時間來進行，C++11 也是。
Clang format 可能不值得，如果是這樣我們需要溝通它不會發生。

會議結論

每個正在處理計劃於 0.13 完成的事項的人都應該向 wumpus 提交他們的提案，以便他可以將其合併到計劃中。

與會者

Luke-Jr         Luke Dashjr
wumpus          Wladimir J. van der Laan
sipa	        Pieter Wuille
morcos	        Alex Morcos
jonasshnelli    Jonas Schnelli
cfields         Cory Fields
petertodd       Peter Todd
MarcoFalke      Marco Falke
sdaftuar        Suhas Daftuar
jgarzik	        Jeff Garzik
btcdrak	        btcdrak
CodeShark       Eric Lombrozo
droark	        Douglas Roark
jtimon	        Jorge Timón

趣味橋段

19:40 sipa    道德上有義務提供 VB 或類似功能的東西 （指的是 versionbits）
19:41 Luke-Jr "Pieter Wuille 提議有道德要求用 Visual Basic 重寫 Bitcoin。"

致謝

IRC 會議摘要 2015-12-17

Thu, 17 Dec 2015 00:00:00 +0000

概覽

記錄
主要議題
錢包中的手續費替換 (RBF) 處理
0.13 的 C++11
幽默時刻
致謝

記錄

主要議題

錢包中的手續費替換處理
0.13 的 C++11

錢包中的手續費替換 (RBF) 處理

背景

目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用 RBF，如果新交易有更高的手續費，它會替換記憶池中的當前交易。這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。

由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。發送者可以通過改變所有輸入的 nSequence 欄位來選擇使用 RBF。這是即將推出的 0.12 版本的記憶池策略。在 reddit 上有一篇很好的 FAQ 式貼文關於它。

會議意見

0.12 的功能凍結自 12 月 1 日起生效，除了錯誤修復外，現在 0.12 分支中的內容將被發布。 #7219 使 RBF 策略成為可選的（0 = 從不，1 = 總是，2 = 選擇性加入）可能不會進入 0.12。 jonasschnelli 和 harding 要求為 RBF 錢包策略提供好的想法以及處理這個問題的方法。 Android 錢包透過點擊提升 UI 來提升手續費（透過 CPFP）。添加提升手續費相當簡單，做更多如添加輸入和輸出可能會使當前錢包變得非常複雜。對於包含輸入和輸出，你會想要準備一個包含 A+B 的已簽署交易和另一個只包含 B 的已簽署交易，該交易花費 A 中建立的找零輸出。對於 0.13，我們希望至少看到一個手續費提升選項和一些原始交易指令來修改錢包交易。

會議結論

查看 #7062 為 0.12 修復記憶池限制和 PrioritiseTransaction 的手續費替換
查看 #7132 添加在發送資金時選擇完整 RBF 的選項

0.13 的 C++11

背景

C++11 是 C++ 語言的更新。它提供新的功能、擴展的標準函式庫等。 Zerocash 必須用一些 c++11 函式庫編寫，一些 IBLT 模擬程式碼是用 c++11 編寫的，他們希望將其回收用於最終的 core 提交。

會議意見

未解決的建置問題是相依性相容性和 Travis 的編譯器。對 boost 函式庫有一些擔憂，因為它是共識關鍵的。在 0.13 之前移除 boost 的使用（在共識中）消除了這種擔憂。風險是我們不可逆地陷入 C++11 並在 0.13 發布時發現大部分使用者群無法處理它。如果程式碼開始差異太大，回移也更困難。更多的測試會很好，但 travis 拉取測試器已經很慢了，所以添加更多設定可能不好。可能有第二個免費的替代方案可以並行建置更多設定。 zero-cash 和 bitcoin core 團隊都希望在許多平台上對這些東西進行自動化測試，這可以由 buildbot 完成。我們也可以向發行版尋求協助。 Wumpus 準備好在 travis 建置/通過後立即將建置切換到 std=c++11。

會議結論

每個人都希望 0.13 有 C++11
將一些建置切換到 C++11

##參與者

wumpus          Wladimir J. van der Laan
cfields         Cory Fields
sipa            Pieter Wuille
jonasshnelli    Jonas Schnelli
petertodd       Peter Todd
Luke-Jr         Luke Dashjr
nwilcox         Nathan Wilcox
zookolaptop     Zooko Wilcox-O'Hearn
sdaftuar        Suhas Daftuar
harding         David A. Harding
jgarzik         Jeff Garzik
btcdrak         btcdrak

幽默時刻

03  petertodd    wumpus：v0.12 分支中的 RBF 處理是將要發布的嗎？也就是說，我們已經功能凍結了嗎？
04  wumpus       是的，我們在 12 月 1 日已經功能凍結了
04  petertodd    酷
04  petertodd    或者我應該說，冰凍

( ••) ( ••)>⌐■-■ (⌐■_■) YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH

致謝

本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 bitcoin-discuss 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。

IRC 會議摘要 2015-12-10

Thu, 10 Dec 2015 00:00:00 +0000

概覽

記錄
議題
BIP 68 語義變更
參與者
致謝

記錄

議題

BIP 68 語義變更

BIP 68 語義變更

背景

BIP 68 透過序號發出信號的共識強制交易替換，以及目前的實作。 BIP 68 將先前未使用的序號欄位的意義改為相對鎖定時間。當建立區塊時，礦工會包含一個時間戳記。這個時間戳記必須在前 11 個區塊的中位數和網路調整時間 +2 小時之間。所以這個時間戳記可以與實際時間有相當大的差異。隨著鎖定時間交易的引入，這些交易只有在特定時間之後才有效，礦工被激勵對時間撒謊，以便包含原本無效的鎖定時間交易（及其手續費）。 BIP113 在鎖定時間交易中啟用使用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）來對抗這種行為。使用者可以透過在他們的鎖定時間上加 1 小時（6 個區塊）來彌補這一點。

會議意見

無論 BIP113 如何，對 BIP68 總是使用 MedianTimePast 是有道理的，儘管仍然需要 BIP 113 來改變 nLockTime 的語義。Morcos 的實作。 BIP 68 會使最近在 #6898 中進行的 CreateNewBlock 效能提升無效，關於修復的討論在 #7176 中進行，新方法（總是使用 MedianTimePast）的修復討論和提交在 #7187 上。 GUI 顯示當前鎖定的交易可能存在一些問題。如果一個區塊被孤立，一個已確認的輸入變成未確認的，這可能會使先前可接受的交易被記憶池驅逐，你可能想通知使用者它已被鎖定（相對於不可見）。 Morcos 提議留下這個問題，並在軟分叉後清理它，因為它似乎不夠重要到需要回移。UI/錢包變更通常也與軟分叉變更分開。在這個思路上，morcos 提出了一個問題，即是否有一些想法和/或反對放寬記憶池目前只包含對下一個區塊有效的交易的行為。 btcdrak 提到 ajtowns 為 BIP68+CSV 寫了一些 python 示範，這對測試者會很有用。

會議結論

查看 #7184 的 BIP68 方法查看上述方法的 CreateNewBlock 效能修復 #7187

參與者

morcos          Alex Morcos
btcdrak         btcdrak
wumpus          Wladimir J. van der Laan
BlueMatt        Matt Corallo
gmaxwell        Gregory Maxwell
jonasschnelli   Jonas Schnelli
sdaftuar        Suhas Daftuar
gavinandresen   Gavin Andresen
Lightsword      Lightsword

致謝

IRC 會議摘要 2015-12-03

Thu, 03 Dec 2015 00:00:00 +0000

概覽

記錄
主要議題
簡短議題/筆記
BIP68 相關拉取請求
驅逐和洋蔥網路
選擇性 RBF 的 BIP
參與者
幽默時刻
致謝

記錄

本週記錄連結
Meetbot 會議記錄（記錄有些錯誤，如您所見）

主要議題

BIP68 相關拉取請求
驅逐和洋蔥網路
選擇性 RBF 的 BIP

簡短議題/筆記

許多開發者正在前往擴容比特幣會議（影片），所以這次會議又比較短，而且下週可能也一樣（因為許多開發者在會議後留在香港參加開發者聚會）。

同時提醒執行完整節點的任何人將他們的節點更新到 core 11.2 或 10.4，或任何其他支援 BIP65 CLTV 的節點，以配合即將到來的軟分叉。不更新意味著你將信任礦工生產有效的區塊。85% 的礦工宣傳他們支援 CLTV 交易，當達到 95% 時軟分叉將啟動，目前（撰寫時）約 30% 的節點已更新。

BIP68 相關拉取請求

背景

BIP 68 透過序號發出信號的共識強制交易替換，以及目前的實作。 BIP 68 將先前未使用的序號欄位的意義改為相對鎖定時間。

會議意見

有一個拉取請求對程式碼註解進行小修正。在優化 CreateNewBlock（它的作用如其名）方面已經有一些工作。Morcos 和 sdaftuar 正在研究兩種方法，其中一種將顯著重構 BIP68 實作。由於重構最好在 BIP68 合併之前完成，因此了解哪種方法更好會很有幫助。

會議結論

研究 CreateNewBlock 優化方法。

驅逐和洋蔥網路

背景

從 Tor 版本 0.2.7.1 開始，可以以程式化方式建立隱藏服務。如果 Tor 正在執行，Bitcoin 現在會自動建立一個隱藏服務來監聽。

會議意見

本地主機對等節點永遠不會被驅逐；所以只要你出現在隱藏服務上，有人就可以輕易地防止其他人連接到你。拉取請求 #7082 透過使用延遲來偵測實際的本地對等節點來解決這個問題。你也可以使用白名單來區分真正的本地主機連接和 tor 本地主機連接，但這可能會破壞現有的軟體。 wumpus 指出我們應該在長期鼓勵對特殊對等節點使用白名單。

會議結論

查看拉取請求 #7082

選擇性 RBF 的 BIP

背景

目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用手續費替換，如果新交易有更高的手續費，它會替換記憶池中的當前交易。這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。

由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。發送者可以通過改變所有輸入的 nSequence 欄位來選擇使用手續費替換。這是即將推出的 0.12 版本的記憶池策略。在 reddit 上有一篇很好的 FAQ 式貼文關於它。

會議意見

問題是選擇性 RBF 是否應該有 BIP。這只是策略程式碼，但是標準性之前已經在 BIP 中涵蓋過。 sdaftuar 指出不幸的是，錢包編寫者應該做什麼的唯一文件是在一篇郵件列表貼文中。 harding 自願寫 BIP。

會議結論

harding 將與 petertodd 協調撰寫 BIP。

參與者

wumpus          Wladimir J. van der Laan
morcos          Alex Morcos
btcdrak         btcdrak
sipa  	        Pieter Wuille
gmaxwell        Gregory Maxwell
cfields         Cory Fields
jonasschnelli  	Jonas Schnelli
Diablo-D3  	    Patrick McFarland
sdaftuar        Suhas Daftuar
harding         David A. Harding
jcorgan         Johnathan Corgan

幽默時刻

26	cfields	等等，我會喜歡郵件討論串
26	sipa	cfields：你會「喜歡」它，它在 facebook 上嗎？
27	wumpus	twitter 現在也有「喜歡」了 :')

致謝

IRC 會議摘要 2015-11-26

Thu, 26 Nov 2015 00:00:00 +0000

概覽

記錄
主要議題
CLTV 啟動
BIP68/BIP112 實作
手續費替換
參與者
幽默時刻
致謝

記錄

主要議題

CLTV 啟動
BIP68/BIP112 實作
手續費替換

btcdrak         btcdrak
petertodd       Peter Todd
Luke-Jr         Luke Dashjr
CodeShark       Eric Lombrozo
sipa            Pieter Wuille
jtimon          Jorge Timón

幽默時刻

17	btcdrak		wumpus：那今天沒有會議了？
17	CodeShark	btcdrak：那今天沒有 wumpus 了？:)
17	petertodd	btcdrak：你什麼時候聽權威的話了？:P

22	CodeShark	有法定人數嗎？還是我們可以照樣開會？:)
22	petertodd	CodeShark：我現在在麥當勞，正在努力增加我的影響力，以質量衡量的話...
22	petertodd	CodeShark：所以是的

49	btcdrak		### 剩下 10 分鐘。還有其他議題建議嗎？
50	petertodd	btcdrak：rbf
50	btcdrak		#topic RBF
51	CodeShark	有人有支付更高手續費的議題嗎？:)
51	Luke-Jr		這個手續費太低了，我要提早離開！

24	btcdrak		#meetingstart
24	btcdrak		#startmeeting
24	lightningbot	Meeting started Thu Nov 26 19:24:40 2015 UTC. The chair is btcdrak. Information about MeetBot at http://wiki.debian.org/MeetBot.

00	btcdrak		#endmeeting
00	btcdrak		#meetingend
00	btcdrak		噢該死，又是這個問題
00	lightningbot	Meeting ended Thu Nov 26 20:00:24 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)

致謝

IRC 會議摘要 2015-11-19

Thu, 19 Nov 2015 00:00:00 +0000

概覽

記錄
主要議題
- 簡短議題/筆記
交易優先級
處理記憶池驅逐
序號**
- 背景
- 會議意見
會議結論
參與者
致謝

記錄

主要議題

交易優先級
處理記憶池驅逐
序號

簡短議題/筆記

選擇性手續費替換需要一些額外的測試，但其他方面似乎已經準備好了。一些錢包開發者已經加入並積極參與，例如 GreenAddress。

交易優先級

背景

每筆交易都會被指派一個優先級，由年齡、大小和輸入數量決定。這目前使某些交易可以免費。這目前有大量的程式碼，使其更難維護，而且不太理想,因為你不能期望礦工包含零手續費交易。

會議意見

如果我們不停止支援在交易建立中使用優先級，我們也需要一個記憶池區域用於優先級，否則這些交易總是會被驅逐。如果我們開發一個更好的框架來支援這類指標，我們可以將它加回來。計劃是從錢包中移除優先級交易建立，而不是挖礦部分。

會議結論

應該從錢包中移除優先級交易的建立。

處理記憶池驅逐

背景

當交易在網路上中繼時，它會被節點保存在記憶體中，直到進入區塊。所有這些位於記憶體中的交易被稱為記憶池（memorypool）或簡稱 mempool。就像我們在垃圾攻擊期間看到的那樣，如果有大量無法進入區塊鏈的交易積壓，這個記憶池可能會變得非常大，導致節點崩潰。

為了防止這種情況發生，開發者創建了一個機制來拒絕和/或從記憶池中移除交易。

會議意見

目前的問題：當錢包交易被記憶池拒絕時，錢包會將產生的交易視為「衝突」並會愉快地重新花費輸入。 sipa 提議讓錢包只在交易有不存在的輸入時將其視為衝突。但是，它應該在稍後某個時間考慮將其設為可重新花費。你可以添加一種手動移除交易的方式，或將其標記為已移除，或將其歸檔。你也可以做一些單獨的事情，將交易標記為可重新花費，因為移除給人的印象是交易未來無法被挖掘。想要的選項：一個「以更高手續費重新花費」選項和一個完全忘記交易的選項，不過我們需要一個 0.12 的最小可行想法。

會議結論

鑑於 0.12 的緊迫期限，我們偵測實際衝突而不是記憶池驅逐，並讓幣立即可重新花費。

序號**

背景

BIP 68 將一些未使用的 nSequence 欄位重新用於相對鎖定時間，意思是鎖定輸入直到經過某個時間或區塊高度。

會議意見

我們需要等待 BIP113 作為標準性部署，這樣 BIP 68、112 和 113 可以進入軟分叉。有即將到來的專案已經使用序號。合併 BIP68 會讓 BIP112 更容易審查，並且會停止一直需要 rebase 的需求。如果我們覺得 68/112 已經經過充分審查並且成熟，它們可以作為標準性規則加入。 BIP 文字似乎沒有反映程式碼中所寫的內容。

會議結論

檢查 BIP68 以符合實作

參與者

sipa               Pieter Wuille
gmaxwell           Gregory Maxwell
morcos             Alex Morcos
jtimon             Jorge Timón
wumpus             Wladimir J. van der Laan
btcdrak            btcdrak
jgarzik            Jeff Garzik
petertodd          Peter Todd
Luke-Jr            Luke Dashjr
BlueMatt           Matt Corallo
jonasschnelli      Jonas Schnelli
CodeShark          Eric Lombrozo
sdaftuar           Suhas Daftuar
gavinand1esen      Gavin Andresen

致謝

IRC 會議摘要 2015-11-12

Thu, 12 Nov 2015 00:00:00 +0000

概覽

記錄
主要議題
0.12 的交易優先級
選擇性手續費替換
參與者
幽默時刻
致謝

記錄

本週記錄連結 -Meetbot 會議記錄

主要議題

0.12 的交易優先級
選擇性手續費替換
版本位元
鏈限制

0.12 的交易優先級

背景

會議意見

大多數人似乎都同意移除記憶池中的優先級，但應該提前通知人們這個變更即將到來。 sdaftuar 提出了一個分階段的方法，將優先級的預設值設為 0，並在下一個版本中完全移除它。 petertodd 指出會有一個自然的分階段過程，因為不是每個人都會立即升級到 0.12，而且有些實作可能根本不會移除優先級。 bitcoin-core 之外的大多數錢包軟體都沒有實作優先級計算。隨著手續費估算變得更加重要，許多錢包提供者使用 bitcoin-core 的手續費估算，對此的改進是受歡迎的。 Luke-Jr 不同意移除優先級，特別是改變挖礦程式碼以使用交易進入記憶池時的優先級。 Sipa 有一個想法，在手續費中加入一小部分的比特幣天數銷毀除以平均 UTXO 年齡，這樣非垃圾攻擊交易就會被視為具有更高的手續費。

雖然大多數人同意移除目前的優先級的提議，但關於是否需要為 0.13 替換它，以及如果需要的話，如何替換，仍有很多爭論。

會議結論

審查「改善手續費估算程式碼的使用」 BlueMatt 將向開發者郵件列表發送郵件宣布這些變更。( https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02790.html )

選擇性手續費替換

BlueMatt        Matt Corallo
petertodd       Peter Todd
morcos          Alex Morcos
jgarzik         Jeff Garzik
gmaxwell        Gregory Maxwell
wumpus          Wladimir J. van der Laan
Luke-Jr         Luke Dashjr
jtimon          Jorge Timón
btcdrak         btcdrak
phantomcircuit  Patrick Strateman
sipa            Pieter Wuille
CodeShark       Eric Lombrozo
sdaftuar        Suhas Daftuar
jg_taxi         jg_taxi
gavinandresen   Gavin Andresen
cfields         Cory Fields
bsm1175321      Bob McElrath

幽默時刻

53	sipa	新議題？
53	wumpus	還有其他議題嗎？
53	petertodd	<蟋蟀叫聲>
53	jgarzik	我在計程車上時我們有討論 jonas 嗎？
54	sdaftuar	？
54	jtimon	？
54	CodeShark	不確定我想知道
54	jgarzik  	提議新的 GUI 維護者
54	CodeShark	雖然聽起來有點怪
54	petertodd	CodeShark：GUI 確實很怪

56	BlueMatt	好，結束會議？
56	btcdrak	如果我們這週能記得指令的話 :-)
56	wumpus	#meetingend
56	gmaxwell	#destroymeeting
56	wumpus	#endmeeting
56	Luke-Jr	#endmeeting
56	lightningbot	Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
56	BlueMatt	#magicmeetbotincantation
57	petertodd	#DoWhatIMean

致謝

2015-11-05 IRC 會議摘要

Thu, 05 Nov 2015 00:00:00 +0000

概覽

日誌

主要議題

Sigcache 效能
0.12 的效能目標
交易優先度
sigops 洪水攻擊
鏈限制

簡短議題/備註

注意：cfields、mcelrath 和 BlueMatt（可能還有更多）因為日光節約時間而錯過了會議。

Scaling Bitcoin 工作坊的提案截止日期是 9 日。

sdaftuar 的分析顯示 40% 的區塊包含超過提議限制的鏈。即使是小幅增加也無法解決問題。這些鏈的可能來源：為其他交易支付手續費的服務（子付父）、一個樂意花費未確認找零的 iOS 錢包。一家企業確認他們在收到來自未花費鏈的比特幣時使用子付父。這些長鏈可能直接傳送給礦工，在這種情況下，它們不會受到提議的傳播限制（以及延展性）的影響。由於這是一個需要解決的問題，人們似乎對無論如何都要合併它感到滿意，提前溝通讓企業考慮這如何影響他們。

會議結論

合併「政策：降低交易鏈的預設限制」 Morcos 將在合併後寄信給開發者郵件列表。

參與者

morcos          Alex Morcos
gmaxwell        Gregory Maxwell
wumpus          Wladimir J. van der Laan
sipa            Pieter Wuille
jgarzik         Jeff Garzik
Luke-Jr         Luke Dashjr
phantomcircuit  Patrick Strateman
sdaftuar        Suhas Daftuar
btcdrak         btcdrak
jouke           ??Jouke Hofman??
jtimon          Jorge Timón
jonasschnelli   Jonas Schnelli

幽默時刻

01	wumpus		#meetingend
01	wumpus		#meetingstop
01	gmaxwell   Thanks all.
01	btcdrak		#exitmeeting
01	gmaxwell	   #nomeetingnonono
01	btcdrak		#meedingexit
01	wumpus		#endmeeting
01	lightningbot  Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot .
01	btcdrak		#rekt

致謝

本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-discuss 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。

2015-10-29 IRC 會議摘要

Thu, 29 Oct 2015 00:00:00 +0000

概覽

日誌

主要議題

即將到來的軟分叉
鏈限制
Clang format
BIP68 和 BIP112 實作

簡短議題/備註

LevelDB 議題已經開始，但推遲到會議後，因為目前沒有移動到另一個資料庫的計畫。然而，鼓勵進行研究和測試。mcelrath 自願製作一個 LMDB 分支，jgarzik 已經有一個 sqlite 分支。

即將到來的軟分叉

背景

CheckLockTimeVerify（CLTV）又稱「在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的」是一個計畫在十月底發布的軟分叉（結果是十一月初）。

會議評論

檢查是否有任何需要包含在此版本中但尚未包含的內容。Luke-jr 有一個拉取請求開放以添加錯誤修復。檢查關於其他客戶端的軟分叉是否有任何協調。btcd 已經準備好了，bitcoinj 歷史上沒有實作任何軟分叉。

會議結論

僅以 CLTV 作為軟分叉發布。

鏈限制

背景

會議評論

25 作為限制仍然非常高，可以更低。關於哪些統計資料和測量對這個提案有用和相關的討論。

會議結論

Morcos 將進行一些額外的測量來支持該提案。

Clang format

背景

就像 libconsensus 一樣，這是為了整理程式碼，但更多的是關於程式碼本身的樣式和格式。引用 gmaxwell 在 github 評論中的部分內容：「樣式一致性有實際的好處；它幫助新手貢獻，因為他們更容易確保他們的工作在樣式上是可以的；儘管這可能被他們在開始之前必須安裝某個特定版本的 clang-format 所抵消。它簡化了審查，因為統一性創造了更好的期望；但重新格式化使查看歷史記錄變得更困難，這妨礙了審查。良好的樣式選擇（與僅僅一致相對）有時已經被證明可以降低軟體中的缺陷率——但對於什麼選擇是好的並沒有普遍的意見。」

會議評論

之前的提議是 clang-format file set <a b c …> 一旦完成，通過自動化維護這些檔案的格式。意見分歧很大。從不要為現有檔案更改任何內容到讓我們更改整個比特幣儲存庫。某些行為從一個 Clang 版本到另一個版本會改變，這將要求每個人使用相同版本的 clang format，這很繁瑣。

會議結論

沒有結論。

BIP68 和 BIP112 實作

背景

BIP 68 通過序號發出信號的共識強制交易替換，以及當前實作。
BIP 112 CHECKSEQUENCEVERIFY，以及當前實作。

簡而言之：BIP 68 將序號欄位的含義更改為相對鎖定時間。BIP 112 使該欄位可以被比特幣腳本系統存取。

會議評論

關於 LockTime 函數跳過不存在的輸入的擔憂。為了審查目的，btcdrak 結合了兩個拉取請求（https://github.com/bitcoin/bitcoin/compare/master…btcdrak:sequenceandcsv）

會議結論

兩個實作應該保持單獨的拉取請求。在 BIP 68 之前部署 BIP 112 沒有用處。

參與者

gmaxwell        Gregory Maxwell
dcousens        Daniel Cousens
sipa            Pieter Wuille
jgarzik         Jeff Garzik
morcos          Alex Morcos
Luke-Jr         Luke Dashjr
wumpus          Wladimir J. van der Laan
mcelrath        Bob McElrath
jtimon          Jorge Timón
jonasshnelli    Jonas Schnelli
btcdrak         btcdrak
petertodd       Peter Todd
dstadulis       Daniel Stadulis
dgenr8          Tom Harding
jeremyrubin     Jeremy Rubin
warren          Warren Togami
rusty           Rusty Russell
sdaftuar        Suhas Daftuar

致謝

2015-10-22 IRC 會議摘要

Thu, 22 Oct 2015 00:00:00 +0000

概覽

日誌
主要議題
- 簡短議題/備註
記憶體池記憶體使用
LevelDB 替代方案
中位過去鎖定時間與 CLTV
參與者
致謝

日誌

主要議題

記憶體池記憶體使用
LevelDB 替代方案
中位過去鎖定時間與 CLTV

簡短議題/備註

BIP 9 Versionbits PR #6816 已準備好實作，需要更多審查。

bitcoin-dev 郵件列表已開始為期 3 個月的審核期，以及新列表 bitcoin-discuss。更多詳情：http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html

「bitcoin.org 的 0.11.1 版本發布說明不正確。現在已經更正了。他們發布了初始 RC 的發布說明，而沒有更新它們。從流程上來說，未來最好注意這一點。」

記憶體池記憶體使用

背景

當一筆交易在網路中傳播時，它會被節點保存在記憶體中，直到它進入區塊為止。所有這些存放在記憶體中的交易被稱為記憶體池（memorypool）或簡稱記憶體池（mempool）。正如我們在垃圾攻擊期間所見，如果有大量無法進入區塊鏈的交易積壓，這個記憶體池可能會變得非常大，導致節點崩潰。

為了防止這種情況發生，開發者建立了一個從記憶體池中拒絕和/或移除交易的機制。這個記憶體池限制本週已經合併。

另外相關的：資料庫快取大小已經有一個現有的限制，稱為「dbCache」。該預設值為 100MB。

會議評論

測試顯示配置的記憶體池限制與實際記憶體使用之間存在差異。這是由處理交易時的 UTXO 資料量造成的。這些資料只有在處理區塊後才會清除（因此暫時超過 dbCache 中設置的快取限制）。

對此有 2 個「明顯的」解決方案：

始終強制執行 UTXO 快取限制，就像始終強制執行記憶體池限制一樣。缺點是如果你錯誤配置記憶體池限制，攻擊可以清除你的 UTXO 快取，這會顯著減慢驗證和傳播速度。
在限制記憶體池時考慮 UTXO 快取。缺點是你可以建構需要更多快取空間的交易，從而更容易踢出其他交易。

更理想的解決方案是在快取中優先處理記憶體池中的事物。實現這一點的方法是從記憶體池中被驅逐的交易中踢出 UTXO，以及從從未進入記憶體池的交易中踢出。這是 TheBlueMatt 正在進行的工作

會議結論

繼續研究和優化。

LevelDB 替代方案

背景

LevelDB 是比特幣目前使用的資料庫系統。由於這已經有一段時間沒有維護了，開發者正在尋找替代方案。

會議評論

jgarzik 開發了一個 SQLite 補丁有些人擔心 SQLite 的效能是否足夠好，但還沒有基準測試結果。

會議結論

研究其他選項做大量基準測試並報告結果

中位過去鎖定時間與 CLTV

背景

當建立一個區塊時，礦工會包含一個時間戳記。這個時間戳記必須介於前 11 個區塊的中位數和網路調整時間 +2 小時之間。因此這個時間戳記可以與實際時間有相當大的差異。隨著鎖定時間交易的引入，這些交易只有在特定時間後才有效，礦工被激勵對時間撒謊，以便包含原本無效的鎖定時間交易（及其手續費）。 BIP 113 啟用在鎖定時間交易中使用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）來對抗這種行為。使用者可以通過在他們的鎖定時間中增加 1 小時（6 個區塊）來補償這一點。

CLTV 代表 CheckLockTimeVerify，BIP65 通常簡稱為：在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的。

會議評論

CLTV 已準備好合併（並且在撰寫本文時已經合併）關於是否將中位過去鎖定時間僅作為記憶體池還是作為軟分叉添加的問題總體問題是在 CLTV 部署中包含什麼，什麼僅作為記憶體池包含，什麼作為軟分叉包含。中位過去鎖定時間違反了當前的「標準」行為，因此我們希望在中位過去鎖定時間軟分叉向前推進之前，該違規在網路中消失。

會議結論

審查 BIP-113：僅記憶體池的中位時間過去作為鎖定時間計算的終點審查 CLTV 向後移植（在撰寫本文時已完成並合併）將中位過去鎖定時間向後移植到 0.10 和 0.11

參與者

btcdrak         btcdrak
sipa            Pieter Wuille
gmaxwell        Gregory Maxwell
BlueMatt        Matt Corallo
morcos          Alex Morcos
petertodd       Peter Todd
CodeShark       Eric Lombrozo
jgarzik         Jeff Garzik
maaku           Mark Friedenbach
kanzure         Bryan Bishop
jcorgan         Johnathan Corgan
Luke-Jr         Luke Dashjr
jonasschnelli   Jonas Schnelli
sdaftuar        Suhas Daftuar

致謝

2015-10-15 IRC 會議摘要

Thu, 15 Oct 2015 00:00:00 +0000

概覽

日誌

主要議題

記憶體池限制
sendheaders BIP
versionbits
dev/discuss 列表政策
CHECKSEQUENCEVERIFY

記憶體池限制

背景

為了防止這種情況發生，開發者正在嘗試找到一種方法來限制這個記憶體池，也就是一種從記憶體池中拒絕和/或移除交易的機制。這裡最困難的部分是確保節點不會因為濫用這個機制而受到攻擊。到目前為止，開發者採用 TheBlueMatt 的丟棄最便宜的交易並將最低傳播費用設置為該費用提案。

會議評論

在測試時，sipa 遇到了需要 200ms 才能被接受進入記憶體池的交易。由於這是他第一次對此進行基準測試，而且拉取請求不應該對這些時間產生影響，因此可能與此無關。然而，無論如何，這樣的時間都是不好的。 sipa 測試中的平均時間是 4ms。（會議後 Morcos 做了一些基準測試，確認這不是此 PR 特有的，並指出異常值來自 CheckInputs 和 HaveInputs（正如你所猜測的，與檢查輸入有關）關於為什麼我們應該將最低傳播費用（節點傳播交易的最低費用）恢復到 1000（它已被設置為 5000 以快速修復記憶體池問題）的問題，sipa 認為它也應該浮動，否則灰塵限制會變得無效。

會議結論

審查 PR 6722 透過丟棄最便宜的交易並將最低傳播費用設置為該費用來限制記憶體池 Morcos/sipa 將做更多基準測試並對 PR 發表評論（morcos 的基準測試結果）

sendheaders BIP

背景

send headers BIP 從 BIP 複製/貼上：自從在 0.10 中引入「標頭優先」下載區塊以來，除非區塊能夠連接到（有效的）標頭鏈，否則不會被處理。因此，區塊傳播通常的運作方式如下：

節點（N）使用「inv」訊息宣布新的頂端，包含區塊雜湊
對等節點（P）以「getheaders」訊息（請求到新頂端的標頭）和「getdata」訊息請求新頂端本身來回應「inv」
N 以「headers」訊息（包含新區塊的標頭以及 P 未知的任何前面的標頭）和包含新區塊的「block」訊息回應然而，在宣布建立在頂端上的新區塊的情況下，如果節點 N 只是宣布新區塊的區塊標頭，而不僅僅是區塊雜湊，並節省對等節點生成和傳輸 getheaders 訊息（以及所需的區塊定位器）的時間，通常會更有效率。

會議評論

關於如何推進的問題。如何讓節點知道你想要區塊標頭而不是區塊雜湊。選項：

擴展版本訊息。
有一個可以發送標誌的「options」訊息。
在連接時儘早發送「sendheaders」訊息，以便立即知道對等節點希望如何宣布區塊。
在任何時間發送「sendheaders」訊息，將對等節點希望的區塊宣布方式從雜湊更改為標頭。

沒有人喜歡進一步擴展版本訊息。相對於「sendheaders」訊息，「options」訊息沒有強大的優勢。讓訊息在早期發送可能過於限制。morcos 的可能使用案例：「未來的某些優化完全可能會說，我想向這些對等節點發送 sendheaders，因為他們向我宣布了很多新內容，而不是向其他節點發送，因為他們沒有」。大多數人喜歡這只能啟用，所以沒有訊息可以返回接收區塊雜湊。這就是 BIP 的起草方式。

會議結論

sdaftuar 為 BIP 提交拉取請求以獲得分配的編號，並按起草的方式繼續推進 BIP。

versionbits

背景

BIP 9 目前軟分叉是通過 isSuperMajority 機制完成的，意思是當最後 X 個區塊中有 95% 的版本號高於 Y 時，分叉就會被部署。一種新的做法目前正在開發中，它使用版本號的所有位元，被恰當地稱為 versionbits。因此，分叉不是在版本大於（例如）00000000011（3）時發生，而是在（例如）第 3 位元被設置時發生（即 00100000011）。這樣一來，軟分叉可以同時且獨立地部署。

會議評論

從 IRC 複製/貼上，因為我不知道這具體是什麼意思： CodeShark：所以現在它只是一個實作 versionbits 邏輯的單元，但沒有演示其用法我認為最好在單獨的 PR 中實際整合，但我可以添加一個演示 sipa：單獨的提交，同一個 PR - 我認為我們需要一個可以作為整體合併的東西，以便能夠看到整個東西是否容易向後移植

Codeshark（正在實作 versionbits）還有一些其他評論，但似乎沒有人審查過它，所以進一步討論也沒什麼用處。

會議結論

審查 versionbits 實作

dev/discuss 列表政策

背景

bitcoin-dev 郵件列表僅用於技術討論。有些事情不屬於那裡，但無論如何都需要討論。現在這是在 bitcoin-dev 中完成的，但這個數量變得太大了。最近也有大量非常不適當的帖文湧入，程度達幼稚園級別。對於不屬於 bitcoin-dev 但無論如何都需要討論的事情，正在建立一個新列表，即 bitcoin-discuss，以及兩者的明確政策和審核。

會議評論

Bitcoin-discuss 已經建立，但管理員密碼沒有分發給願意指導審核的 jgarzik。同時已經提出了單獨的審核提案。人們只是希望它繼續推進。

會議結論

由於提出審核方案的人都不在場，我們讓他們相互討論並公開發布他們的決定。

CHECKSEQUENCEVERIFY

背景

CheckLockTimeVerify（CLTV）重新利用了 nSequence 欄位（nSequence 是 4 個位元組，用於排序時間鎖定交易，但這從未被使用過）。然而，沒有辦法在比特幣腳本中使用這些值。 CheckSequenceVerify（CSV）使這個欄位可以被比特幣腳本存取。

編輯：結果這不完全正確，因為是相對鎖定時間重新利用了 nSequence 欄位。

會議評論

CLTV 幾乎完成了。檢查 maaku 移動其中一個位元以允許其他實作具有更好的粒度是否有任何異議。只要我們使用盡可能少的位元，確切的語義對大多數人來說就不那麼重要。 sipa 指出了一個可能影響錢包的錯誤。 CSV 不在月底的目標上，儘管已經做了很多工作並取得了進展。

會議結論

審查並 ACK/NACK 6312 BIP-68：僅記憶體池的序號約束驗證
審查並 ACK/NACK 6566 BIP-113：僅記憶體池的中位時間過去作為鎖定時間計算的終點

參與者

wumpus          Wladimir J. van der Laan
sipa            Pieter Wuille
btcdrak         btcdrak
gmaxwell        Gregory Maxwell
morcos          Alex Morcos
maaku           Mark Friedenbach
CodeShark       Eric Lombrozo
BlueMatt        Matt Corallo
sdaftuar        Suhas Daftuar
warren          Warren Togami
GreenIsMyPepper Joseph Poon
davec           Dave Collins
cfields         Cory Fields
jonasschnelli   Jonas Schnelli

幽默時刻

19:21 sdaftuar 聽起來每個人都同意起草的 BIP 了？ 19:21 wumpus 是的 19:21 gmaxwell 我認為是的。 19:22 davec 是的 19:22 sipa 嗯，唯一有疑慮的人是 cfields，他似乎不在這裡 :) 19:22 gmaxwell sipa：他也可以稍後提出疑慮！ 19:22 cfields 該死！ 19:22 sipa cfields：太遲了！ 19:22 gmaxwell 哈 19:23 cfields 我真的連續錯過了第三次這個會議嗎？

致謝

本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-dev 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。

2015-10-08 IRC 會議摘要

Thu, 08 Oct 2015 00:00:00 +0000

將建立 bitcoin-discuss 列表以及一個簡單的網站，列出所有列表和相應的政策。計畫在星期一開會討論上述列表的審核和政策。

參與者

morcos           Alex Morcos
gmaxwell         Gregory Maxwell
wumpus           Wladimir J. van der Laan
sipa             Pieter Wuille
BlueMatt         Matt Corallo
btcdrak          btcdrak
petertodd        Peter Todd
warren           Warren Togami
phantomcircuit   Patrick Strateman
dstadulis        Daniel Stadulis
GreenIsMyPepper  Joseph Poon
bsm117532        Bob McElrath

致謝

2015-10-01 IRC 會議摘要

Thu, 01 Oct 2015 00:00:00 +0000

概覽

日誌

完整的 IRC 日誌可以在這裡找到。

主要議題

記憶體池限制
BIP68 + CHECKSEQUENCEVERIFY
CLTV 軟分叉部署
libconsensus 合併時間窗口

記憶體池限制

參與者

dstadulis       Daniel Stadulis
wumpus          Wladimir J. van der Laan
morcos          Alex Morcos
gmaxwell        Gregory Maxwell
btcdrak         btcdrak
jonasshnelli    Jonas Schnelli
maaku           Mark Friedenbach
sdaftuar        Suhas Daftuar
sipa            Pieter Wuille
BlueMatt        Matt Corallo
CodeShark       Eric Lombrozo
Luke-Jr         Luke Dashjr
bsm117532       Bob McElrath
jgarzik         Jeff Garzik