2018-07-05 IRC 會議摘要

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

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

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

高優先級審查

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

討論（日誌）： 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 轉換為當地時間（使用北半球夏令時間），這對應於當地時間：

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

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

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

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

結論： 最終建議有人建立一個民意調查以幫助找到哪些會議時間對不同貢獻者是可接受的，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? :)

參與者

免責聲明

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