2015-10-08 IRC 會議摘要

概覽

日誌

主要議題

記憶體池限制：鏈限制 Low-S 變更 CLTV 與 CSV 審查建立 bitcoin discuss 郵件列表

題外話但重要通知

這個問題已使大多數 JS 比特幣軟體容易生成不正確的公鑰。「這是一個生態系統威脅，可能造成數百萬美元的損失，需要更高的可見度；儘管這不是 bitcoin core / 比特幣網路的問題。常見的關鍵 JS 程式碼被破壞，可能導致生成不正確的公鑰（以及其他問題）。任何關心 JS 實作的人都應該閱讀那個 PR。」

記憶體池限制：鏈限制

背景

（從上週複製/貼上）在這個情境中，鏈是指連接的交易。當你發送一筆依賴於另一筆尚未確認的交易時，我們稱之為交易鏈。理想情況下，礦工會考慮整個交易鏈，而不僅僅是每一筆單獨的交易（雖然據我所知這並未被廣泛實作）。因此，雖然單一交易可能沒有足夠的手續費，但一個依賴的交易可能有足夠高的手續費，使得挖取兩者都值得。這通常被稱為子付父（child-pays-for-parent）。由於你可以讓這些鏈變得非常大，因此可以通過這種方式堵塞記憶體池。第一筆未確認的交易被稱為祖先，依賴於它的交易被稱為子孫。交易的總數量被稱為「套件」。

自上週以來

如上週在「鏈限制」中所述，Morcos 確實撰寫了關於降低交易鏈預設限制的提案。出現了兩個目前正在使用或之前發生過的使用案例：例如：有人從網站購買比特幣，可以在同一網站的市場中花費這些比特幣而無需等待確認，以改善比特幣使用者體驗。這留下了一個順序交易鏈。他們不需要鏈接超過 5 層深度，這在提議的限制內。不在提議限制內的是一家公司在垃圾攻擊期間的 +/- 100 筆交易鏈。這些只是終端使用者增加的活動，而可用的 UTXO 不足（準確地說是 3 個）（UTXO：未花費交易輸出，可以用作新交易輸入的輸出）。值得注意的是，這是在採用優先使用已確認交易的最佳實踐下。從公司方面可以解決這個問題的方法是事先準備更多 UTXO、捆綁交易（這需要延遲客戶的請求）或使用手續費替代（replace-by-fee）來添加收款人（這節省區塊鏈空間、手續費更便宜且交易更快完成，但目前礦工尚未廣泛部署）。請記住，這些提案是記憶體池的預設值，絕不是硬性限制。

會議評論

緊迫感。引用 sipa：「我的記憶體池有 2.5G… 我們最好找到一些解決方案！」目前的攻擊分析假設子付父挖礦，可能應該在沒有這個的情況下再做一次。較高的交易數量限制會增加攻擊向量。提議的交易數量受到一些反對，但總大小限制沒有。混合預設值（例如 50% 為 10/10 限制，50% 為 100/100 限制）會浪費頻寬，而且有太多因素限制了長鏈的效用。 25 筆交易限制對每個人來說應該足夠了（目前）。

會議結論

審查與測試透過丟棄最便宜的交易並將最低傳播費用設置為該費用來限制記憶體池支援降低交易鏈的預設限制，也就是說服人們 25 應該足夠。

Low-S 變更

背景

這是關於最近的延展性攻擊。這是由 ECDSA 簽名中的 ‘S’ 值引起的，該值可以是兩個值，一個高值和一個低值，並且仍然有效。導致不同的交易 ID。更多資訊解決方案是要求節點對簽名使用「low-s」編碼。缺點是它將阻止大多數由足夠過時的軟體（+/- 2014 年 3 月之前）製作的交易。這不能取代對 BIP62 的需求，它只是消除了廉價的 DOS 攻擊。

會議評論

95% 的交易已經符合這一點，並且自那以後已經應用了更多修復。 BlueMatt 有一個節點，幾個人正在運行它，會自動將交易延展為 low-s。問題是我們是否立即發布它，還是等待下一個版本並在此期間將它交給一些礦工（可能帶有自動 lowS 延展）。

會議結論

聯繫礦工關於「在標準性中測試 LowS，移除討厭的延展性向量」發布計畫在本月底，與可能的 check-lock-time-verify 一起，可能還有 check-sequence-verify。

CLTV 與 CSV 向後移植審查

背景

CLTV：checkLockTimeVerify CSV：checkSequenceVerify 兩個新的與時間相關的 OP-code。上週進行了大量討論。

會議評論

擔憂 CSV 是否會在本月底的版本中準備好。當所有 3 個與時間相關的拉取請求合併後，情況如何還不清楚。仍有許多人在審查拉取請求。對於語義是否最終確定存在不確定性和混淆（關於從 nSequence 使用位元）。nSequence 是 4 個位元組，用於排序時間鎖定交易，但這從未被使用過。現在這些位元組被重新用於混合用途。目前的計畫是：「位元 0..15 是相對鎖定時間，位元 30 決定單位（0：高度，1：時間，512 秒粒度），位元 31 切換 BIP 68（0：開啟，1：關閉）。位元 16..29 被遮罩並可以取任何值。」

會議結論

maaku 需要澄清關於 BIP68 的 nSequence。（會議後他解釋說他在等待意見，但似乎沒有足夠的人知道這個問題）繼續審查拉取請求 6312、6564 和 6566

建立 bitcoin discuss 郵件列表

背景

bitcoin-dev 郵件列表僅用於技術討論。有些事情不屬於那裡，但無論如何都需要討論。現在這是在 bitcoin-dev 中完成的，但這個數量變得太大了。最近也有大量非常不適當的帖文湧入，程度達幼稚園級別。

會議評論

不清楚誰是版主。下週將建立一個 bitcoin-discuss 列表。需要決定誰將成為該列表和 bitcoin-dev 的版主。需要決定列表和審核政策是什麼。

會議結論

將建立 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

致謝

本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-dev 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。