diff --git a/_config.yml b/_config.yml index f7fb510e3..7b1584b87 100644 --- a/_config.yml +++ b/_config.yml @@ -67,6 +67,12 @@ defaults: lang: en values: permalink: /en/:year/:month/:day/:title/ + - scope: + path: "_posts/zh_TW/posts" + type: posts + lang: zh_TW + values: + permalink: /zh_TW/:year/:month/:day/:title/ collections: releases: diff --git a/_data/navigation.yml b/_data/navigation.yml index 6f11c47da..b136bda02 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -98,42 +98,48 @@ zh_TW: url: "/zh_TW/" about: title: "關於我們" - url: "/en/about/" + url: "/zh_TW/about/" + download: + title: "下載" + url: "/zh_TW/download/" blog: title: "網誌" url: "/zh_TW/blog/" releases: - title: "軟件發行" + title: "版本發布" url: "/zh_TW/releases/" security-advisories: - title: "Security Advisories" - url: "/en/security-advisories/" + title: "安全公告" + url: "/zh_TW/security-advisories/" dev: - title: "Development" + title: "開發" submenu: true tree: contribute: title: "貢獻" url: "/zh_TW/contribute/" contribute-code: - title: "contributing code" - url: "/en/faq/contributing-code/" + title: "貢獻程式碼" + url: "/zh_TW/faq/contributing-code/" meetings: - title: "meetings" - url: "/en/meetings/" + title: "會議紀錄" + url: "/zh_TW/meetings/" eol: - title: "Lifecycle" - url: "/en/lifecycle/" + title: "生命週期" + url: "/zh_TW/lifecycle/" contact: - title: "Contact" + title: "聯絡" submenu: true tree: contact_us: - title: "Contact Us" - url: "/en/contact/" + title: "聯絡我們" + url: "/zh_TW/contact/" announcements: - title: "Announcements" - url: "/en/list/announcements/join/" + title: "公告" + url: "/zh_TW/list/announcements/join/" + twitter_impersonation: + title: "X 冒充帳號" + url: "/zh_TW/twitter-impersonation" ja: home: title: "Bitcoin Core" diff --git a/_data/translations.yml b/_data/translations.yml index 1d2ed1937..a25c35d89 100644 --- a/_data/translations.yml +++ b/_data/translations.yml @@ -30,15 +30,15 @@ zh_TW: created: "發表於" author: "作者" description: "Bitcoin Core 網站" - footer: "Bitcoin Core 計劃" - recommended: "推薦閱讀" - viewallposts: "显示所有文章" - not_translated: "注意：本頁未被翻譯" - tocoverview: "Overview" - translation_outdated: "This translation may be out of date compared to the English version" - rss_feed: "Bitcoin Core Blog RSS Feed" - rss_meetings_feed: "Meetings feed" - rss_blog_feed: "Blog posts feed" + footer: "Bitcoin Core 專案" + related: "推薦閱讀" + viewallposts: "顯示所有文章" + not_translated: "注意：本頁尚未翻譯" + tocoverview: "概覽" + translation_outdated: "此翻譯可能與英文版本不同步，請以英文版為準。" + rss_feed: "Bitcoin Core 部落格 RSS 訂閱" + rss_meetings_feed: "會議紀錄訂閱" + rss_blog_feed: "部落格文章訂閱" ja: created: "Published on the" diff --git a/_posts/en/pages/2016-01-01-about.md b/_posts/en/pages/2016-01-01-about.md index 317cb6dfc..0f77dcff2 100755 --- a/_posts/en/pages/2016-01-01-about.md +++ b/_posts/en/pages/2016-01-01-about.md @@ -7,7 +7,6 @@ layout: page lang: en version: 3 redirect_from: - - /zh_TW/about/ - /en/team/ --- diff --git a/_posts/en/pages/2016-01-01-contribute.md b/_posts/en/pages/2016-01-01-contribute.md index 12d09e831..4a7ad1f29 100644 --- a/_posts/en/pages/2016-01-01-contribute.md +++ b/_posts/en/pages/2016-01-01-contribute.md @@ -7,8 +7,6 @@ type: pages layout: page lang: en version: 5 -redirect_from: - - /zh_TW/contribute/ --- You are welcome to contribute to the project! diff --git a/_posts/en/pages/2016-01-13-supported-bips.md b/_posts/en/pages/2016-01-13-supported-bips.md index e10acb7f8..3dd7419e1 100644 --- a/_posts/en/pages/2016-01-13-supported-bips.md +++ b/_posts/en/pages/2016-01-13-supported-bips.md @@ -6,8 +6,6 @@ layout: page lang: en permalink: /en/bips/ version: 2 -redirect_from: - - /zh_TW/bips/ --- Bitcoin Core supports the following [BIPs][BitcoinCoreDocBips]. diff --git a/_posts/zh_TW/meetings/2015-10-01-meeting.md b/_posts/zh_TW/meetings/2015-10-01-meeting.md new file mode 100644 index 000000000..485fcfc90 --- /dev/null +++ b/_posts/zh_TW/meetings/2015-10-01-meeting.md @@ -0,0 +1,140 @@ +--- +title: 2015-10-01 IRC 會議摘要 +permalink: /zh_TW/meetings/2015/10/01/ +name: 2015-10-01-meeting +version: 1 +type: meetings +layout: page +lang: zh_TW +--- +{% include toc.html %} + +## 日誌 + +完整的 IRC 日誌可以在[這裡](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/01#l1443726030.0)找到。 + +## 主要議題 + +- 記憶體池限制 +- BIP68 + CHECKSEQUENCEVERIFY +- CLTV 軟分叉部署 +- libconsensus 合併時間窗口 + + +## 記憶體池限制 + +### 背景 + +當一筆交易在網路中傳播時，它會被節點保存在記憶體中，直到它進入區塊為止。所有這些存放在記憶體中的交易被稱為記憶體池（memorypool）或簡稱記憶體池（mempool）。 +正如我們在垃圾攻擊期間所見，如果有大量無法進入區塊鏈的交易積壓，這個記憶體池可能會變得非常大，導致節點崩潰。 + +為了防止這種情況發生，開發者正在嘗試找到一種方法來限制這個記憶體池，也就是一種從記憶體池中拒絕和/或移除交易的機制。這裡最困難的部分是確保節點不會因為濫用這個機制而受到攻擊。 + +對此有多個已經提出的想法，即： + +- [透過丟棄最便宜的交易並將最低傳播費用設置為該費用來限制記憶體池](https://github.com/bitcoin/bitcoin/pull/6722) +- [使用子孫套件追蹤來限制記憶體池](https://github.com/bitcoin/bitcoin/pull/6557) +- [指數上升的有效最低傳播費率](https://github.com/bitcoin/bitcoin/pull/6673) + +### 會議評論 + +開發者傾向於 6722（丟棄最便宜的交易並將最低傳播費用設置為該費用），因為這是更簡單的方法，可能有更少的邊界情況。 +其背後的想法是擁有一個記憶體池，能夠很好地估算將包含在下一個區塊中的內容，也就是更高費用的交易。 +這種方法也有助於建立費用估算器。 +一些開發者建議也包含基於時間的驅逐。 + + +### 會議結論 + +應該完成 6722，並且其他人應該攻擊 6722、6557 和 6673，試圖找出邊界情況。 +預設記憶體池大小應該為 300MB。 + + +## 鏈限制 + +### 背景 + +在這個情境中，鏈是指連接的交易。當你發送一筆依賴於另一筆尚未確認的交易時，我們稱之為交易鏈。 +理想情況下，礦工會考慮整個交易鏈，而不僅僅是每一筆單獨的交易（雖然據我所知這並未被廣泛實作）。因此，雖然單一交易可能沒有足夠的手續費，但一個依賴的交易可能有足夠高的手續費，使得挖取兩者都值得。 +這通常被稱為子付父（child-pays-for-parent）。 +由於你可以讓這些鏈變得非常大，因此可以通過這種方式堵塞記憶體池。 +第一筆未確認的交易被稱為祖先，依賴於它的交易被稱為子孫。交易的總數量被稱為「套件」。 + +### 會議評論 + +如果你有更大的鏈限制，所有記憶體池限制方法都會更容易受到攻擊。 +擁有更大子孫套件的原因是你無法自己控制這一點，某人付款給你和 bob，而 bob 鏈接了一百萬個子孫，最終他害了你。 +如果你有一個 900kb 的祖先套件限制，那麼即使祖先費率相當高，預設的挖礦程式碼也可能會首先找到 100kb 的非常高費用交易來包含，然後就沒有空間容納你的祖先套件了。 +Morcos 提議祖先為 25/250kb，子孫為 50/500kb，意思是祖先最多 25 筆交易或 250kb 大小。 +大多數人對這些限制都覺得沒問題，甚至更小也可以。 + +### 會議結論 + +morcos 撰寫一個鏈限制提案發布到郵件列表上，以找出大型鏈交易的可能使用案例。 + + + +## CHECKLOCKTIMEVERIFY 軟分叉 + +### 背景 + +通常簡稱為：在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的。 +對此有相當多的需求，程式碼已經被審查並且已經在側鏈 alpha 上運行了 6 個月。 +唯一真正的問題是它如何以及何時被合併。 +目前軟分叉是通過 isSuperMajority 機制完成的，意思是當最後 X 個區塊中有 95% 的版本號高於 X 時，分叉就會被部署。 +一種新的做法目前正在開發中，它使用版本號的所有位元，被恰當地稱為 versionbits。因此，分叉不是在版本大於（例如）00000000011（3）時發生，而是在（例如）第 3 位元被設置時發生（即 00100000011）。 +這樣一來，軟分叉可以同時且獨立地部署。 + +### 會議評論 + +有問題提出我們是否要等待其他與時間相關的 BIP 和/或 versionbits，還是現在使用 isSuperMajority。 +如果稍後部署 versionbits，它需要等待所有超級多數軟分叉結束。 +Vladimir van der Laan 不希望在主要版本（在這種情況下是 0.12）中部署任何軟分叉，這樣人們就是明確為了軟分叉而升級，而不是為了其他東西。 +你可以推出多個超級多數分叉，只要它們是累積的。 +如果在十月底前準備好，談話似乎趨向於使用超級多數來部署 checkLockTimeVerify 和 checkSequenceVerify。 + +### 會議結論 + +需要審查 checkLockTimeVerify 的向後移植（在舊版本中的部署）以及 BIP68、112 和 113（所有與時間相關的 BIP）。 + + +## Libconsensus + +### 背景 + +中本聰不是最好的程式設計師，這留下了相當混亂的程式碼。理想情況下，你應該將影響網路共識的程式碼部分單獨分開，但在比特幣中它們都交織在一起。 +Libconsensus 最終應該成為這一部分。這樣人們可以更容易地在非共識部分進行更改，而不用擔心造成網路分叉。 +然而，這是一個緩慢且危險的專案，涉及移動大量程式碼。 + +### 會議評論 + +關於何時合併現有更改、何時為下一個版本凍結程式碼等，有很多討論。 +在 linux 中，更改會在主要版本發布後立即合併。jtimon 注意到這也是在 0.10 和 0.11 之後計畫的，但什麼都沒有發生。 +似乎缺乏關於什麼應該移到哪裡的規劃和概述。 + +### 會議結論 + +jtimon 將提供一個關於什麼以及事物應該移動到哪裡的高層次理由，以便人們可以根據這個理由進行評論和審查。 + +## 參與者 + + 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 + +## 致謝 + +本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 [bitcoin-dev 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011368.html diff --git a/_posts/zh_TW/meetings/2015-10-08-meeting.md b/_posts/zh_TW/meetings/2015-10-08-meeting.md new file mode 100644 index 000000000..db22da7de --- /dev/null +++ b/_posts/zh_TW/meetings/2015-10-08-meeting.md @@ -0,0 +1,148 @@ +--- +title: 2015-10-08 IRC 會議摘要 +permalink: /zh_TW/meetings/2015/10/08/ +name: 2015-10-08-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 日誌 + +- [本週日誌連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1444330778.0) +- [會議紀錄連結](https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit) + +## 主要議題 + +記憶體池限制：鏈限制 +Low-S 變更 +CLTV 與 CSV 審查 +建立 bitcoin discuss 郵件列表 + + +### 題外話但重要通知 + +[這個問題](https://github.com/feross/buffer/pull/81)已使大多數 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 筆交易限制對每個人來說應該足夠了（目前）。 + +### 會議結論 + +審查與測試[透過丟棄最便宜的交易並將最低傳播費用設置為該費用來限制記憶體池](https://github.com/bitcoin/bitcoin/pull/6722) +支援[降低交易鏈的預設限制](https://github.com/bitcoin/bitcoin/pull/6771)，也就是說服人們 25 應該足夠。 + +## Low-S 變更 {#low-s-change} + +### 背景 + +這是關於最近的延展性攻擊。這是由 ECDSA 簽名中的 'S' 值引起的，該值可以是兩個值，一個高值和一個低值，並且仍然有效。導致不同的交易 ID。[更多資訊](http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high) +解決方案是要求節點對簽名使用「low-s」編碼。 +缺點是它將阻止大多數由足夠過時的軟體（+/- 2014 年 3 月之前）製作的交易。 +這不能取代對 BIP62 的需求，它只是消除了廉價的 DOS 攻擊。 + +### 會議評論 + +95% 的交易已經符合這一點，並且自那以後已經應用了更多修復。 +BlueMatt 有一個節點，幾個人正在運行它，會自動將交易延展為 low-s。 +問題是我們是否立即發布它，還是等待下一個版本並在此期間將它交給一些礦工（可能帶有自動 lowS 延展）。 + +### 會議結論 + +聯繫礦工關於[「在標準性中測試 LowS，移除討厭的延展性向量」](https://github.com/bitcoin/bitcoin/pull/6769) +發布計畫在本月底，與可能的 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](https://github.com/bitcoin/bitcoin/pull/6312)、[6564](https://github.com/bitcoin/bitcoin/pull/6564) 和 [6566](https://github.com/bitcoin/bitcoin/pull/6566) + +## 建立 bitcoin discuss 郵件列表 + +### 背景 + +bitcoin-dev 郵件列表僅用於技術討論。有些事情不屬於那裡，但無論如何都需要討論。 +現在這是在 bitcoin-dev 中完成的，但這個數量變得太大了。 +最近也有大量非常不適當的帖文湧入，程度達[幼稚園](https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02539.html)級別。 + +### 會議評論 + +不清楚誰是版主。 +下週將建立一個 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 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011496.html diff --git a/_posts/zh_TW/meetings/2015-10-15-meeting.md b/_posts/zh_TW/meetings/2015-10-15-meeting.md new file mode 100644 index 000000000..44c7a4d88 --- /dev/null +++ b/_posts/zh_TW/meetings/2015-10-15-meeting.md @@ -0,0 +1,176 @@ +--- +title: 2015-10-15 IRC 會議摘要 +permalink: /zh_TW/meetings/2015/10/15/ +name: 2015-10-15-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 日誌 + +- [本週日誌連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444935660.0) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.html) + +## 主要議題 + +- 記憶體池限制 +- sendheaders BIP +- versionbits +- dev/discuss 列表政策 +- CHECKSEQUENCEVERIFY + +## 記憶體池限制 + +### 背景 + +當一筆交易在網路中傳播時，它會被節點保存在記憶體中，直到它進入區塊為止。所有這些存放在記憶體中的交易被稱為記憶體池（memorypool）或簡稱記憶體池（mempool）。 +正如我們在垃圾攻擊期間所見，如果有大量無法進入區塊鏈的交易積壓，這個記憶體池可能會變得非常大，導致節點崩潰。 + +為了防止這種情況發生，開發者正在嘗試找到一種方法來限制這個記憶體池，也就是一種從記憶體池中拒絕和/或移除交易的機制。這裡最困難的部分是確保節點不會因為濫用這個機制而受到攻擊。 +到目前為止，開發者採用 TheBlueMatt 的[丟棄最便宜的交易並將最低傳播費用設置為該費用](https://github.com/bitcoin/bitcoin/pull/6722)提案。 + +### 會議評論 + +在測試時，sipa 遇到了需要 200ms 才能被接受進入記憶體池的交易。 +由於這是他第一次對此進行基準測試，而且拉取請求不應該對這些時間產生影響，因此可能與此無關。然而，無論如何，這樣的時間都是不好的。 +sipa 測試中的平均時間是 4ms。（會議後 Morcos 做了一些[基準測試](https://github.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040)，確認這不是此 PR 特有的，並指出異常值來自 CheckInputs 和 HaveInputs（正如你所猜測的，與檢查輸入有關） +關於為什麼我們應該將最低傳播費用（節點傳播交易的最低費用）恢復到 1000（它已被設置為 5000 以快速修復記憶體池問題）的問題，sipa 認為它也應該浮動，否則灰塵限制會變得無效。 + +### 會議結論 + +審查 PR 6722 [透過丟棄最便宜的交易並將最低傳播費用設置為該費用來限制記憶體池](https://github.com/bitcoin/bitcoin/pull/6722) +Morcos/sipa 將做更多基準測試並對 PR 發表評論（[morcos 的基準測試結果](https://github.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040)） + +## sendheaders BIP + +### 背景 + +[send headers BIP](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) +從 BIP 複製/貼上： +自從在 0.10 中引入「標頭優先」下載區塊以來，除非區塊能夠連接到（有效的）標頭鏈，否則不會被處理。因此，區塊傳播通常的運作方式如下： + +1. 節點（N）使用「inv」訊息宣布新的頂端，包含區塊雜湊 +2. 對等節點（P）以「getheaders」訊息（請求到新頂端的標頭）和「getdata」訊息請求新頂端本身來回應「inv」 +3. N 以「headers」訊息（包含新區塊的標頭以及 P 未知的任何前面的標頭）和包含新區塊的「block」訊息回應 +然而，在宣布建立在頂端上的新區塊的情況下，如果節點 N 只是宣布新區塊的區塊標頭，而不僅僅是區塊雜湊，並節省對等節點生成和傳輸 getheaders 訊息（以及所需的區塊定位器）的時間，通常會更有效率。 + +### 會議評論 + +關於如何推進的問題。如何讓節點知道你想要區塊標頭而不是區塊雜湊。 +選項： + +1. 擴展[版本訊息](https://en.bitcoin.it/wiki/Protocol_documentation#version)。 +2. 有一個可以發送標誌的「options」訊息。 +3. 在連接時儘早發送「sendheaders」訊息，以便立即知道對等節點希望如何宣布區塊。 +4. 在任何時間發送「sendheaders」訊息，將對等節點希望的區塊宣布方式從雜湊更改為標頭。 + +沒有人喜歡進一步擴展版本訊息。 +相對於「sendheaders」訊息，「options」訊息沒有強大的優勢。 +讓訊息在早期發送可能過於限制。morcos 的可能使用案例：「未來的某些優化完全可能會說，我想向這些對等節點發送 sendheaders，因為他們向我宣布了很多新內容，而不是向其他節點發送，因為他們沒有」。 +大多數人喜歡這只能啟用，所以沒有訊息可以返回接收區塊雜湊。這就是 BIP 的起草方式。 + +### 會議結論 + +sdaftuar 為 BIP 提交拉取請求以獲得分配的編號，並按起草的方式繼續推進 BIP。 + +## versionbits + +### 背景 + +[BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) +目前軟分叉是通過 isSuperMajority 機制完成的，意思是當最後 X 個區塊中有 95% 的版本號高於 Y 時，分叉就會被部署。 +一種新的做法目前正在開發中，它使用版本號的所有位元，被恰當地稱為 versionbits。因此，分叉不是在版本大於（例如）00000000011（3）時發生，而是在（例如）第 3 位元被設置時發生（即 00100000011）。 +這樣一來，軟分叉可以同時且獨立地部署。 + +### 會議評論 + +從 IRC 複製/貼上，因為我不知道這具體是什麼意思： +CodeShark：所以現在它只是一個實作 versionbits 邏輯的單元，但沒有演示其用法 +我認為最好在單獨的 PR 中實際整合，但我可以添加一個演示 +sipa：單獨的提交，同一個 PR - 我認為我們需要一個可以作為整體合併的東西，以便能夠看到整個東西是否容易向後移植 + +Codeshark（正在實作 versionbits）還有一些其他評論，但似乎沒有人審查過它，所以進一步討論也沒什麼用處。 + +### 會議結論 + +審查 [versionbits 實作](https://github.com/bitcoin/bitcoin/pull/6816) + +## dev/discuss 列表政策 + +### 背景 + +bitcoin-dev 郵件列表僅用於技術討論。有些事情不屬於那裡，但無論如何都需要討論。 +現在這是在 bitcoin-dev 中完成的，但這個數量變得太大了。 +最近也有大量非常不適當的帖文湧入，程度達[幼稚園](https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02539.html)級別。 +對於不屬於 bitcoin-dev 但無論如何都需要討論的事情，正在建立一個新列表，即 bitcoin-discuss，以及兩者的明確政策和審核。 + +### 會議評論 + +Bitcoin-discuss 已經建立，但管理員密碼沒有分發給願意指導審核的 jgarzik。 +同時已經提出了單獨的審核提案。 +人們只是希望它繼續推進。 + +### 會議結論 + +由於提出審核方案的人都不在場，我們讓他們相互討論並公開發布他們的決定。 + +## CHECKSEQUENCEVERIFY + +### 背景 + +CheckLockTimeVerify（CLTV）重新利用了 nSequence 欄位（nSequence 是 4 個位元組，用於排序時間鎖定交易，但這從未被使用過）。然而，沒有辦法在比特幣腳本中使用這些值。 +CheckSequenceVerify（CSV）使這個欄位可以被比特幣腳本存取。 + +編輯：[結果這不完全正確](https://www.reddit.com/r/Bitcoin/comments/3pcinz/bitcoin_dev_irc_meeting_in_laymans_terms_20151015/cw55n6q)，因為是[相對鎖定時間](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)重新利用了 nSequence 欄位。 + +### 會議評論 + +CLTV 幾乎完成了。 +檢查 maaku 移動其中一個位元以允許其他實作具有更好的粒度是否有任何異議。 +只要我們使用盡可能少的位元，確切的語義對大多數人來說就不那麼重要。 +sipa 指出了一個可能影響錢包的[錯誤](https://github.com/bitcoin/bitcoin/pull/6312#discussion_r41899674)。 +CSV 不在月底的目標上，儘管已經做了很多工作並取得了進展。 + +### 會議結論 + + - 審查並 ACK/NACK 6312 [BIP-68：僅記憶體池的序號約束驗證](https://github.com/bitcoin/bitcoin/pull/6312) + - 審查並 ACK/NACK 6566 [BIP-113：僅記憶體池的中位時間過去作為鎖定時間計算的終點](https://github.com/bitcoin/bitcoin/pull/6566) + +## 參與者 + + 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 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011562.html diff --git a/_posts/zh_TW/meetings/2015-10-22-meeting.md b/_posts/zh_TW/meetings/2015-10-22-meeting.md new file mode 100644 index 000000000..c4a50c84b --- /dev/null +++ b/_posts/zh_TW/meetings/2015-10-22-meeting.md @@ -0,0 +1,124 @@ +--- +title: 2015-10-22 IRC 會議摘要 +permalink: /zh_TW/meetings/2015/10/22/ +name: 2015-10-22-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 日誌 + +- [本週日誌連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/22#l1445540405.0) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-22-19.05.html) + +## 主要議題 + +- 記憶體池記憶體使用 +- LevelDB 替代方案 +- 中位過去鎖定時間與 CLTV + +### 簡短議題/備註 + +[BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) Versionbits [PR #6816](https://github.com/bitcoin/bitcoin/pull/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）。 +正如我們在垃圾攻擊期間所見，如果有大量無法進入區塊鏈的交易積壓，這個記憶體池可能會變得非常大，導致節點崩潰。 + +為了防止這種情況發生，開發者建立了一個從記憶體池中拒絕和/或移除交易的機制。這個[記憶體池限制](https://github.com/bitcoin/bitcoin/pull/6722)本週已經合併。 + +另外相關的：資料庫快取大小已經有一個現有的限制，稱為「dbCache」。該預設值為 100MB。 + +### 會議評論 + +測試顯示配置的記憶體池限制與實際記憶體使用之間存在差異。這是由處理交易時的 [UTXO](https://bitcoin.org/en/glossary/unspent-transaction-output) 資料量造成的。 +這些資料只有在處理區塊後才會清除（因此暫時超過 dbCache 中設置的快取限制）。 + +對此有 2 個「明顯的」解決方案： + +1. 始終強制執行 UTXO 快取限制，就像始終強制執行記憶體池限制一樣。 +缺點是如果你錯誤配置記憶體池限制，攻擊可以清除你的 UTXO 快取，這會顯著減慢驗證和傳播速度。 + +2. 在限制記憶體池時考慮 UTXO 快取。 +缺點是你可以建構需要更多快取空間的交易，從而更容易踢出其他交易。 + +更理想的解決方案是在快取中優先處理記憶體池中的事物。 +實現這一點的方法是從記憶體池中被驅逐的交易中踢出 UTXO，以及從從未進入記憶體池的交易中踢出。 +這是 TheBlueMatt [正在進行的工作](https://github.com/bitcoin/bitcoin/pull/6872) + +### 會議結論 + +繼續研究和優化。 + +## LevelDB 替代方案 + +### 背景 + +LevelDB 是比特幣目前使用的資料庫系統。由於這已經有一段時間沒有維護了，開發者正在尋找替代方案。 + +### 會議評論 + +jgarzik 開發了一個 [SQLite 補丁](https://github.com/bitcoin/bitcoin/pull/6873) +有些人擔心 SQLite 的效能是否足夠好，但還沒有基準測試結果。 + +### 會議結論 + +研究其他選項 +做大量基準測試並報告結果 + +## 中位過去鎖定時間與 CLTV + +### 背景 + +當建立一個區塊時，礦工會包含一個時間戳記。這個時間戳記必須介於前 11 個區塊的中位數和網路調整時間 +2 小時之間。因此這個時間戳記可以與實際時間有相當大的差異。 +隨著鎖定時間交易的引入，這些交易只有在特定時間後才有效，礦工被激勵對時間撒謊，以便包含原本無效的鎖定時間交易（及其手續費）。 +BIP 113 啟用在鎖定時間交易中使用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）來對抗這種行為。使用者可以通過在他們的鎖定時間中增加 1 小時（6 個區塊）來補償這一點。 + +CLTV 代表 CheckLockTimeVerify，[BIP65](https://github.com/bitcoin/bitcoin/pull/6351) 通常簡稱為：在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的。 + +### 會議評論 + +CLTV 已準備好合併（並且在撰寫本文時已經合併） +關於是否將中位過去鎖定時間僅作為記憶體池還是作為軟分叉添加的問題 +總體問題是在 CLTV 部署中包含什麼，什麼僅作為記憶體池包含，什麼作為軟分叉包含。 +中位過去鎖定時間違反了當前的「標準」行為，因此我們希望在中位過去鎖定時間軟分叉向前推進之前，該違規在網路中消失。 + +### 會議結論 + +審查 [BIP-113：僅記憶體池的中位時間過去作為鎖定時間計算的終點](https://github.com/bitcoin/bitcoin/pull/6566) +審查 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 + +## 致謝 + +本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-October/000003.html diff --git a/_posts/zh_TW/meetings/2015-10-29-meeting.md b/_posts/zh_TW/meetings/2015-10-29-meeting.md new file mode 100644 index 000000000..49f09aafd --- /dev/null +++ b/_posts/zh_TW/meetings/2015-10-29-meeting.md @@ -0,0 +1,125 @@ +--- +title: 2015-10-29 IRC 會議摘要 +permalink: /zh_TW/meetings/2015/10/29/ +name: 2015-10-29-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 日誌 + +- [本週日誌連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/29#l1446145259.0) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-29-19.02.html) +- [會議 google 文件](https://docs.google.com/document/d/1t3kGkAUQ-Yui57P29YhDll5WyJuTiGrUhCW8so-E-iQ/edit) + +## 主要議題 + +- 即將到來的軟分叉 +- 鏈限制 +- Clang format +- BIP68 和 BIP112 實作 + +### 簡短議題/備註 + +LevelDB 議題已經開始，但推遲到會議後，因為目前沒有移動到另一個資料庫的計畫。然而，鼓勵進行研究和測試。mcelrath 自願製作一個 LMDB 分支，jgarzik 已經有一個 sqlite 分支。 + +## 即將到來的軟分叉 + +### 背景 + +CheckLockTimeVerify（CLTV）又稱「在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的」是一個計畫在十月底發布的軟分叉（結果是十一月初）。 + +### 會議評論 + +檢查是否有任何需要包含在此版本中但尚未包含的內容。Luke-jr 有一個[拉取請求](https://github.com/bitcoin/bitcoin/pull/6825)開放以添加錯誤修復。 +檢查關於其他客戶端的軟分叉是否有任何協調。[btcd](https://github.com/btcsuite/btcd) 已經準備好了，[bitcoinj](https://github.com/bitcoinj/bitcoinj) 歷史上沒有實作任何軟分叉。 + +### 會議結論 + +僅以 CLTV 作為軟分叉發布。 + +## 鏈限制 + +### 背景 + +在這個情境中，鏈是指連接的交易。當你發送一筆依賴於另一筆尚未確認的交易時，我們稱之為交易鏈。 +理想情況下，礦工會考慮整個交易鏈，而不僅僅是每一筆單獨的交易（雖然據我所知這並未被廣泛實作）。因此，雖然單一交易可能沒有足夠的手續費，但一個依賴的交易可能有足夠高的手續費，使得挖取兩者都值得。 +這通常被稱為子付父（child-pays-for-parent）。 +由於你可以讓這些鏈變得非常大，因此可以通過這種方式堵塞記憶體池。 +在最近的延展性攻擊中，任何進行多層深度交易的人都會遇到巨大的問題（在 [let's talk bitcoin #258](https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-258-liquidity-and-malleability) 從 13:50 開始有很好的解釋） +[提案](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html)和 [github](https://github.com/bitcoin/bitcoin/pull/6771) 連結。 + +### 會議評論 + +25 作為限制仍然非常高，可以更低。 +關於哪些統計資料和測量對這個提案有用和相關的討論。 + +### 會議結論 + +Morcos 將進行一些額外的測量來支持該提案。 + +## Clang format + +### 背景 + +就像 libconsensus 一樣，這是為了整理程式碼，但更多的是關於程式碼本身的樣式和格式。引用 gmaxwell 在 github 評論中的部分內容： +「樣式一致性有實際的好處；它幫助新手貢獻，因為他們更容易確保他們的工作在樣式上是可以的；儘管這可能被他們在開始之前必須安裝某個特定版本的 clang-format 所抵消。它簡化了審查，因為統一性創造了更好的期望；但重新格式化使查看歷史記錄變得更困難，這妨礙了審查。良好的樣式選擇（與僅僅一致相對）有時已經被證明可以降低軟體中的缺陷率——但對於什麼選擇是好的並沒有普遍的意見。」 + +### 會議評論 + +之前的提議是 clang-format file set 一旦完成，通過自動化維護這些檔案的格式。 +意見分歧很大。從不要為現有檔案更改任何內容到讓我們更改整個比特幣儲存庫。 +某些行為從一個 Clang 版本到另一個版本會改變，這將要求每個人使用相同版本的 clang format，這很繁瑣。 + +### 會議結論 + +沒有結論。 + +## BIP68 和 BIP112 實作 + +### 背景 + +- [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 通過序號發出信號的共識強制交易替換，以及當前[實作](https://github.com/bitcoin/bitcoin/pull/6312)。 +- [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) CHECKSEQUENCEVERIFY，以及當前[實作](https://github.com/bitcoin/bitcoin/pull/6564)。 + +簡而言之：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 + +## 致謝 + +本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000007.html diff --git a/_posts/zh_TW/meetings/2015-11-05-meeting.md b/_posts/zh_TW/meetings/2015-11-05-meeting.md new file mode 100644 index 000000000..8664597ff --- /dev/null +++ b/_posts/zh_TW/meetings/2015-11-05-meeting.md @@ -0,0 +1,168 @@ +--- +title: 2015-11-05 IRC 會議摘要 +permalink: /zh_TW/meetings/2015/11/05/ +name: 2015-11-05-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 日誌 + +- [本週日誌連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/05#l1446750061.0) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-05-19.01.html) + + +## 主要議題 + +- Sigcache 效能 +- 0.12 的效能目標 +- 交易優先度 +- sigops 洪水攻擊 +- 鏈限制 + +### 簡短議題/備註 + +注意：cfields、mcelrath 和 BlueMatt（可能還有更多）因為日光節約時間而錯過了會議。 + +Scaling Bitcoin 工作坊的提案截止日期是 9 日。 + +檢查 0.11.2 RC 是否還有其他提交。一旦 [6948](https://github.com/bitcoin/bitcoin/pull/6948) 和 [6825](https://github.com/bitcoin/bitcoin/pull/6825) 合併，似乎就可以了。 +我們需要相當快速地行動，因為已經有礦工在為 CLTV 投票（F2Pool）。此外，testnet 已經被 CLTV 鎖定，並且不斷分叉。 +0.11.2 RC1 已於今天發布：https://bitcoin.org/bin/bitcoin-core-0.11.2/test/ + +大多數記憶體池限制分析假設了子付父，然而這還沒有為 0.12 準備好，所以我們應該在現有挖礦演算法的背景下考慮可能的濫用。 + +由於時間限制，[選擇性手續費替代](https://github.com/bitcoin/bitcoin/pull/6871)已推遲到下週會議，但大多數人似乎希望它在 0.12 中。sdaftuar 提醒我們需要向使用者明確說明，如果他們不想接受選擇性交易，他們需要做什麼。 + +## Sigcache 效能 + +### 背景 + +簽名快取，用於提高效能（通過不必多次檢查簽名），並減輕一些攻擊，目前的預設限制為 50,000 個簽名。 +Sipa 有一個拉取請求，提議： +將限制從條目數量改為 MB +將預設值更改為 40MB，對應 500,000 個簽名 +儲存加鹽雜湊而不是完整條目 +移除已在區塊中驗證的條目 + +### 會議評論 + +Sipa 對各種簽名快取大小在區塊中的命中率（有多少快取簽名在區塊中）進行了基準測試。 +最大 sigcache 大小為 68MB，導致 3% 的未命中率。然而，有些區塊有極高的未命中率（60%），而其他區塊則沒有。可能是由於礦工運行不同的政策造成的。 +Gmaxwell 提議始終對記憶體池交易運行腳本驗證，即使這些交易因客戶端政策而被拒絕進入記憶體池。 +其結果是即使 300MB 的 sigcache 大小也只能降到 15% 的未命中率。所以有太多垃圾被傳播，無法保持任何合理大小的快取。 +Gmaxwell 指出不檢查任何被拒絕的交易的缺點，即：可能有一些 DOS 攻擊，如果你設置的政策比典型網路更嚴格，你會增加未命中率，這可能導致競爭到底部。 + +### 會議結論 + +Sipa 繼續他的工作並尋找其他策略 + +## 0.12 的效能目標 + +### 背景 + +Bitcoin-core 0.12 計畫於 12 月 1 日發布。 + +### 會議評論 + +每個人都希望儘快包含 [secp256k1](https://github.com/bitcoin/bitcoin/pull/6954)，因為它有非常大的效能提升。 +有些人希望包含 [sigcache 拉取請求](https://github.com/bitcoin/bitcoin/pull/6918)、[BIP30](https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531)、[modifyNewCoins](https://github.com/bitcoin/bitcoin/pull/6932) 和 [createNewBlock 重寫](https://github.com/bitcoin/bitcoin/pull/6898)（如果準備好的話）。 +Wumpus 建議不要為 0.12 合併最後一刻的效能改進。 + +### 會議結論 + +應該審查提到的拉取請求，優先處理 [CreateNewBlock](https://github.com/bitcoin/bitcoin/pull/6898) + +## 交易優先度 + +### 背景 + +每筆交易都被分配一個優先度，由年齡、大小和輸入數量決定。這使得一些交易免費。 + +### 會議評論 + +Sipa 認為我們應該完全擺脫當前的優先度，並用一個修改交易手續費或大小的函數來替換它。 +有一個[拉取請求](https://github.com/bitcoin/bitcoin/pull/6357)可用，它優化了當前的交易優先度，從而避免了改變交易優先度定義所帶來的政治辯論。 +Luke-jr 認為舊政策應該保持可能。 + +### 會議結論 + +檢查 [PR #6357](https://github.com/bitcoin/bitcoin/pull/6357) 是否足夠安全和高效。 + +## sigops 洪水攻擊 {#sigops-flooding-attack} + +### 背景 + +ECDSA 簽名檢查操作或 sigops 的數量目前限制為每個區塊 20,000 個。這是為了防止礦工建立需要很長時間才能驗證的區塊，因為這些操作很耗時。 +然而，你可以建構具有非常高 sigops 計數的交易，由於大多數礦工不考慮 sigops 計數，他們最終得到非常小的區塊，因為達到了 sigop 限制。 +這種攻擊在[這裡](https://bitcointalk.org/index.php?topic=1166928.0)有描述。 + +### 會議評論 + +建議考慮 sigops 數量相對於最大區塊大小與總大小的關係。意思是 10k sigops 交易目前將被視為 500kB 大小（僅對該單一交易，而不是對區塊）。 +該建議在挖礦程式碼中很容易更改，但要將其插入到所有查看費率的地方，則更具侵入性。 +如果這些交易沒有被記憶體池限制驅逐，這也會對記憶體池開放攻擊。 +Luke-jr 有一個每 sigop 位元組限制，可以過濾掉這些攻擊交易。 + +### 會議結論 + +應該進行更多分析，人們似乎對修復它的總體方向感到滿意。 + +## 鏈限制 + +### 背景 + +在這個情境中，鏈是指連接的交易。當你發送一筆依賴於另一筆尚未確認的交易時，我們稱之為交易鏈。 +理想情況下，礦工會考慮整個交易鏈，而不僅僅是每一筆單獨的交易（雖然據我所知這並未被廣泛實作）。因此，雖然單一交易可能沒有足夠的手續費，但一個依賴的交易可能有足夠高的手續費，使得挖取兩者都值得。 +這通常被稱為子付父（child-pays-for-parent）。 +由於你可以讓這些鏈變得非常大，因此可以通過這種方式堵塞記憶體池。 +在最近的延展性攻擊中，任何進行多層深度交易的人都會遇到巨大的問題（在 [let's talk bitcoin #258](https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-258-liquidity-and-malleability) 從 13:50 開始有很好的解釋） +[提案](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html)和 [github](https://github.com/bitcoin/bitcoin/pull/6771) 連結。 + +### 會議評論 + +sdaftuar 的分析顯示 40% 的區塊包含超過提議限制的鏈。即使是小幅增加也無法解決問題。 +這些鏈的可能來源：為其他交易支付手續費的服務（子付父）、一個樂意花費未確認找零的 iOS 錢包。一家企業確認他們在收到來自未花費鏈的比特幣時使用子付父。 +這些長鏈可能直接傳送給礦工，在這種情況下，它們不會受到提議的傳播限制（以及延展性）的影響。 +由於這是一個需要解決的問題，人們似乎對無論如何都要合併它感到滿意，提前溝通讓企業考慮這如何影響他們。 + +### 會議結論 + +合併[「政策：降低交易鏈的預設限制」](https://github.com/bitcoin/bitcoin/pull/6771) +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 + +## 幽默時刻 + + 20:01 wumpus #meetingend + 20:01 wumpus #meetingstop + 20:01 gmaxwell Thanks all. + 20:01 btcdrak #exitmeeting + 20:01 gmaxwell #nomeetingnonono + 20:01 btcdrak #meedingexit + 20:01 wumpus #endmeeting + 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . + 20:01 btcdrak #rekt + +## 致謝 + +本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000008.html diff --git a/_posts/zh_TW/meetings/2015-11-12-meeting.md b/_posts/zh_TW/meetings/2015-11-12-meeting.md new file mode 100644 index 000000000..53a335ee8 --- /dev/null +++ b/_posts/zh_TW/meetings/2015-11-12-meeting.md @@ -0,0 +1,161 @@ +--- +title: IRC 會議摘要 2015-11-12 +permalink: /zh_TW/meetings/2015/11/12/ +name: 2015-11-12-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 記錄 + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/12#l1447354830.0) +-[Meetbot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.html) + +## 主要議題 + +- 0.12 的交易優先級 +- 選擇性手續費替換 +- 版本位元 +- 鏈限制 + +## 0.12 的交易優先級 + +### 背景 + +每筆交易都會被指派一個優先級，由年齡、大小和輸入數量決定。這目前使某些交易可以免費。 +這目前有大量的程式碼，使其更難維護，而且不太理想,因為你不能期望礦工包含零手續費交易。 + +### 會議意見 + +大多數人似乎都同意移除記憶池中的優先級，但應該提前通知人們這個變更即將到來。 +sdaftuar 提出了一個分階段的方法，將優先級的預設值設為 0，並在下一個版本中完全移除它。 +petertodd 指出會有一個自然的分階段過程，因為不是每個人都會立即升級到 0.12，而且有些實作可能根本不會移除優先級。 +bitcoin-core 之外的大多數錢包軟體都沒有實作優先級計算。 +隨著手續費估算變得更加重要，許多錢包提供者使用 bitcoin-core 的手續費估算，對此的改進是受歡迎的。 +Luke-Jr 不同意移除優先級，特別是改變挖礦程式碼以使用交易進入記憶池時的優先級。 +Sipa 有一個想法，在手續費中加入一小部分的比特幣天數銷毀除以平均 [UTXO](https://bitcoin.org/en/glossary/unspent-transaction-output) 年齡，這樣非垃圾攻擊交易就會被視為具有更高的手續費。 + +雖然大多數人同意移除目前的優先級的提議，但關於是否需要為 0.13 替換它，以及如果需要的話，如何替換，仍有很多爭論。 + +### 會議結論 + +審查「[改善手續費估算程式碼的使用](https://github.com/bitcoin/bitcoin/pull/6134)」 +BlueMatt 將向開發者郵件列表發送郵件宣布這些變更。( https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02790.html ) + +## 選擇性手續費替換 + +### 背景 + +目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用手續費替換，如果新交易有更高的手續費，它會替換記憶池中的當前交易。 +這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。 + +由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。 +發送者可以通過改變 nSequence 欄位中的輸入來選擇使用手續費替換。 + +### 會議意見 + +Peter Todd 寫了一些使用手續費替換的工具。[連結](https://github.com/petertodd/replace-by-fee-tools) +如果能夠對每個輸出而不是整個交易進行選擇性設定會很好，但這會非常難以實作，而且會有一些隱私問題。 +Luke-Jr 希望看到一個選項來在首次可見安全/完整 RBF 和從不/選擇性/總是之間切換。由於「總是」切換可能有一些反對意見，它應該是一個單獨的拉取請求。 + +### 會議結論 + +審查並合併 [基於 nSequence 的完整 RBF 選擇性加入](https://github.com/bitcoin/bitcoin/pull/6871) +Peter Todd 將向郵件列表寫一封郵件，解釋它是如何運作的以及人們如何不接受選擇性加入的交易。 + +##版本位元 + +jonasschnelli> 背景 + +[BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) +目前軟分叉是通過 isSuperMajority 機制完成的，意思是當最後 X 個區塊中的 95% 版本號大於 Y 時，分叉就會部署。 +目前正在開發一種新的方式，它使用版本號的所有位元，適當地被稱為版本位元。所以不是在版本大於（例如）00000000011 (3) 時發生分叉，而是在（例如）第 3 位元為 1 時（即 00100000011）發生分叉。 +這樣軟分叉可以同時且獨立地部署。 + +### 會議意見 + +有兩種不同的實作。一種來自 [Codeshark](https://github.com/bitcoin/bitcoin/pull/6816)，另一種來自 [Rusty](https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits) +jtimon 認為這兩種實作都比它們需要的更複雜。 +需要進行一個小修訂，即提案的開始時間。 +一般來說，我們希望盡快實現這一點，但現有的軟分叉需要先完成。 + +### 會議結論 + +CodeShark 為版本位元添加開始時間。 + +##鏈限制 + +### 背景 + +這裡的鏈是指連接的交易。當你發送一個依賴於另一個尚未確認的交易時，我們談論的是一個交易鏈。 +理想情況下，礦工會考慮整個鏈，而不只是每一筆單獨的交易（雖然據我所知這並未廣泛實作）。所以雖然單一交易可能沒有足夠的手續費，但依賴的交易可能有足夠高的手續費，使得挖掘兩者都值得。 +這通常被稱為子為父付費。 +由於你可以使這些鏈非常大，所以有可能以這種方式堵塞記憶池。 +在最近的延展性攻擊中，任何進行多層深度交易的人都會遇到巨大的問題（在 [let's talk bitcoin #258](https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-258-liquidity-and-malleability) 從 13:50 開始有很好的解釋） +[提案](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html)和 [github](https://github.com/bitcoin/bitcoin/pull/6771) 連結。 + +### 會議意見 + +Wumpus 不太放心合併它，因為有些超過限制（或可能/想要）的公司有一些爭議。 +jgarzik 對此感到放心，許多人認為應該合併它，因為如果需要的話很容易還原。 +沒有太多選擇，因為沒有限制就不安全，容易受到攻擊。 +我們應該向長鏈傳達手續費替換 sendmany 替代方案（在現有未確認交易上添加新收款人），儘管它還不會顯示在使用者錢包中，而且區塊瀏覽器可能還沒準備好正確顯示它。 +強調這是預設值的變更，不是共識變更，然而預設值有很大的影響力。 +最終限制是祖先和後代套件的 25 筆交易和 101kb 總大小。 + +### 會議結論 + +jgarzik 將合併拉取請求。 +Morcos 將在合併後向郵件列表發送郵件。 + +## 參與者 + + 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 + +## 幽默時刻 + + 19:53 sipa 新議題？ + 19:53 wumpus 還有其他議題嗎？ + 19:53 petertodd <蟋蟀叫聲> + 19:53 jgarzik 我在計程車上時我們有討論 jonas 嗎？ + 19:54 sdaftuar ？ + 19:54 jtimon ？ + 19:54 CodeShark 不確定我想知道 + 19:54 jgarzik 提議新的 GUI 維護者 + 19:54 CodeShark 雖然聽起來有點怪 + 19:54 petertodd CodeShark：GUI 確實很怪 + + 19:56 BlueMatt 好，結束會議？ + 19:56 btcdrak 如果我們這週能記得指令的話 :-) + 19:56 wumpus #meetingend + 19:56 gmaxwell #destroymeeting + 19:56 wumpus #endmeeting + 19:56 Luke-Jr #endmeeting + 19: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) + 19:56 BlueMatt #magicmeetbotincantation + 19:57 petertodd #DoWhatIMean + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000010.html diff --git a/_posts/zh_TW/meetings/2015-11-19-meeting.md b/_posts/zh_TW/meetings/2015-11-19-meeting.md new file mode 100644 index 000000000..d91162f76 --- /dev/null +++ b/_posts/zh_TW/meetings/2015-11-19-meeting.md @@ -0,0 +1,105 @@ +--- +title: IRC 會議摘要 2015-11-19 +permalink: /zh_TW/meetings/2015/11/19/ +name: 2015-11-19-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 記錄 + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/19#l1447959611.0) +- [Meetbot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-19-19.00.html) + +## 主要議題 + +- 交易優先級 +- 處理記憶池驅逐 +- 序號 + +### 簡短議題/筆記 + +[選擇性手續費替換](https://github.com/bitcoin/bitcoin/pull/6871)需要一些額外的測試，但其他方面似乎已經準備好了。一些錢包開發者已經加入並積極參與，例如 GreenAddress。 + +## 交易優先級 + +### 背景 + +每筆交易都會被指派一個優先級，由年齡、大小和輸入數量決定。這目前使某些交易可以免費。 +這目前有大量的程式碼，使其更難維護，而且不太理想,因為你不能期望礦工包含零手續費交易。 + +### 會議意見 + +如果我們不停止支援在交易建立中使用優先級，我們也需要一個記憶池區域用於優先級，否則這些交易總是會被驅逐。 +如果我們開發一個更好的框架來支援這類指標，我們可以將它加回來。 +計劃是從錢包中移除優先級交易建立，而不是挖礦部分。 + +### 會議結論 + +應該從錢包中移除優先級交易的建立。 + +## 處理記憶池驅逐 + +### 背景 + +當交易在網路上中繼時，它會被節點保存在記憶體中，直到進入區塊。所有這些位於記憶體中的交易被稱為記憶池（memorypool）或簡稱 mempool。 +就像我們在垃圾攻擊期間看到的那樣，如果有大量無法進入區塊鏈的交易積壓，這個記憶池可能會變得非常大，導致節點崩潰。 + +為了防止這種情況發生，開發者創建了一個機制來拒絕和/或從記憶池中移除交易。 + +### 會議意見 + +目前的問題：當錢包交易被記憶池拒絕時，錢包會將產生的交易視為「衝突」並會愉快地重新花費輸入。 +sipa 提議讓錢包只在交易有不存在的輸入時將其視為衝突。 +但是，它應該在稍後某個時間考慮將其設為可重新花費。 +你可以添加一種手動移除交易的方式，或將其標記為已移除，或將其歸檔。 +你也可以做一些單獨的事情，將交易標記為可重新花費，因為移除給人的印象是交易未來無法被挖掘。 +想要的選項：一個「以更高手續費重新花費」選項和一個完全忘記交易的選項，不過我們需要一個 0.12 的最小可行想法。 + +### 會議結論 + +鑑於 0.12 的緊迫期限，我們偵測實際衝突而不是記憶池驅逐，並讓幣立即可重新花費。 + +## 序號** + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 將一些未使用的 nSequence 欄位重新用於相對鎖定時間，意思是鎖定輸入直到經過某個時間或區塊高度。 + +### 會議意見 + +我們需要等待 BIP113 作為標準性部署，這樣 [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)、[112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) 和 [113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) 可以進入軟分叉。 +有即將到來的專案已經使用序號。 +合併 BIP68 會讓 BIP112 更容易審查，並且會停止一直需要 [rebase](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase) 的需求。 +如果我們覺得 68/112 已經經過充分審查並且成熟，它們可以作為標準性規則加入。 +BIP 文字似乎沒有反映程式碼中所寫的內容。 + +## 會議結論 + +檢查 BIP68 以符合[實作](https://github.com/bitcoin/bitcoin/pull/6312) + +## 參與者 + + 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 + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000028.html diff --git a/_posts/zh_TW/meetings/2015-11-26-meeting.md b/_posts/zh_TW/meetings/2015-11-26-meeting.md new file mode 100644 index 000000000..4d7b43d16 --- /dev/null +++ b/_posts/zh_TW/meetings/2015-11-26-meeting.md @@ -0,0 +1,117 @@ +--- +title: IRC 會議摘要 2015-11-26 +permalink: /zh_TW/meetings/2015/11/26/ +name: 2015-11-26-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 記錄 + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/26#l1448565880.0) +- [Meetbot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-26-19.24.html) + +## 主要議題 + +- CLTV 啟動 +- BIP68/BIP112 實作 +- 手續費替換 + +## CLTV 啟動 + +### 背景 + +CheckLockTimeVerify (CLTV) 又名「你在實際嘗試使用 nLockTime 之前以為它是如何運作的」又名 OP_HODL。 + +### 會議意見 + +CLTV 軟分叉很可能在短短幾週內就會啟動，因為除了少數大礦工外，每個人都已經採用它。 +目前約 20% 的節點執行支援 CLTV 的版本。不升級的負面影響是驗證降級（SPV）。 + +### 會議結論 + +在社群媒體上提醒升級節點到 v0.11.2/v0.10.4 + +## BIP68/BIP112 實作 + +### 背景 + +- [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序號發出信號的共識強制交易替換，以及目前的[實作](https://github.com/bitcoin/bitcoin/pull/6312)。 +- [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) CHECKSEQUENCEVERIFY，以及目前的[實作](https://github.com/bitcoin/bitcoin/pull/6564)。 + +簡而言之：BIP 68 將序號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供比特幣腳本系統存取。 + +### 會議意見 + +BIP68 和 BIP112 文字已經更新以符合實作。 +有人呼籲並討論在[郵件列表](https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02876.html)上重新命名 CHECKSEQUENCEVERIFY。 +btcdrak 希望這兩個拉取請求都能盡快合併，其他人則感到更加猶豫，因為人們似乎最近才開始認真研究它。 + +### 會議結論 + +合併更新的 BIP 文字 + +## 手續費替換 + +### 背景 + +目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用手續費替換，如果新交易有更高的手續費，它會替換記憶池中的當前交易。 +這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。 + +由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。 +發送者可以通過改變所有輸入的 nSequence 欄位來選擇使用手續費替換。 +這是即將推出的 0.12 版本的記憶池策略。 + +在 reddit 上有一篇很好的 [FAQ 式貼文](https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/)關於它。 + +### 會議意見 + +petertodd 在將記憶池限制器調低的情況下執行了一些測試，沒有發現問題。 +如果有人想寫的話，在技術上應該很容易首先合併首次可見安全和完全無條件作為選項。 + +### 會議結論 + +測試並 ACK [手續費替換](https://github.com/bitcoin/bitcoin/pull/6871)（同時已經合併）。 + +## 參與者 + + btcdrak btcdrak + petertodd Peter Todd + Luke-Jr Luke Dashjr + CodeShark Eric Lombrozo + sipa Pieter Wuille + jtimon Jorge Timón + +## 幽默時刻 + + 19:17 btcdrak wumpus：那今天沒有會議了？ + 19:17 CodeShark btcdrak：那今天沒有 wumpus 了？:) + 19:17 petertodd btcdrak：你什麼時候聽權威的話了？:P + + 19:22 CodeShark 有法定人數嗎？還是我們可以照樣開會？:) + 19:22 petertodd CodeShark：我現在在麥當勞，正在努力增加我的影響力，以質量衡量的話... + 19:22 petertodd CodeShark：所以是的 + + 19:49 btcdrak ### 剩下 10 分鐘。還有其他議題建議嗎？ + 19:50 petertodd btcdrak：rbf + 19:50 btcdrak #topic RBF + 19:51 CodeShark 有人有支付更高手續費的議題嗎？:) + 19:51 Luke-Jr 這個手續費太低了，我要提早離開！ + + 19:24 btcdrak #meetingstart + 19:24 btcdrak #startmeeting + 19: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. + + 20:00 btcdrak #endmeeting + 20:00 btcdrak #meetingend + 20:00 btcdrak 噢該死，又是這個問題 + 20: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) + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000035.html diff --git a/_posts/zh_TW/meetings/2015-12-03-meeting.md b/_posts/zh_TW/meetings/2015-12-03-meeting.md new file mode 100644 index 000000000..57b5e207c --- /dev/null +++ b/_posts/zh_TW/meetings/2015-12-03-meeting.md @@ -0,0 +1,110 @@ +--- +title: IRC 會議摘要 2015-12-03 +permalink: /zh_TW/meetings/2015/12/03/ +name: 2015-12-03-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 記錄 + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/12/03#l1449169187.0) +- [Meetbot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-03-18.59.html)（記錄有些錯誤，如您所見） + +## 主要議題 + +- BIP68 相關拉取請求 +- 驅逐和洋蔥網路 +- 選擇性 RBF 的 BIP + +## 簡短議題/筆記 + +許多開發者正在前往擴容比特幣會議（[影片](https://www.youtube.com/channel/UCql9h_eXmusjt-f3k8qLwPQ/videos)），所以這次會議又比較短，而且下週可能也一樣（因為許多開發者在會議後留在香港參加[開發者聚會](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011712.html)）。 + +同時提醒執行完整節點的任何人將他們的節點更新到 core 11.2 或 10.4，或任何其他支援 BIP65 CLTV 的節點，以配合即將到來的軟分叉。不更新意味著你將信任礦工生產有效的區塊。85% 的礦工宣傳他們支援 CLTV 交易，當達到 95% 時軟分叉將啟動，目前（撰寫時）約 30% 的節點已更新。 + +## BIP68 相關拉取請求 + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序號發出信號的共識強制交易替換，以及目前的[實作](https://github.com/bitcoin/bitcoin/pull/6312)。 +BIP 68 將先前未使用的序號欄位的意義改為相對鎖定時間。 + +### 會議意見 + +有一個[拉取請求](https://github.com/bitcoin/bips/pull/252)對程式碼註解進行小修正。 +在優化 CreateNewBlock（它的作用如其名）方面已經有一些工作。Morcos 和 sdaftuar 正在研究兩種方法，其中一種將顯著[重構](https://en.wikipedia.org/wiki/Code_refactoring) BIP68 實作。 +由於重構最好在 BIP68 合併之前完成，因此了解哪種方法更好會很有幫助。 + +### 會議結論 + +研究 CreateNewBlock 優化方法。 + +## 驅逐和洋蔥網路 + +### 背景 + +從 Tor 版本 0.2.7.1 開始，可以以程式化方式建立隱藏服務。如果 Tor 正在執行，Bitcoin 現在會自動建立一個隱藏服務來監聽。 + +### 會議意見 + +本地主機對等節點永遠不會被驅逐；所以只要你出現在隱藏服務上，有人就可以輕易地防止其他人連接到你。 +拉取請求 [#7082](https://github.com/bitcoin/bitcoin/pull/7082) 透過使用延遲來偵測實際的本地對等節點來解決這個問題。 +你也可以使用白名單來區分真正的本地主機連接和 tor 本地主機連接，但這可能會破壞現有的軟體。 +wumpus 指出我們應該在長期鼓勵對特殊對等節點使用白名單。 + +### 會議結論 + +查看拉取請求 [#7082](https://github.com/bitcoin/bitcoin/pull/7082) + +## 選擇性 RBF 的 BIP + +### 背景 + +目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用手續費替換，如果新交易有更高的手續費，它會替換記憶池中的當前交易。 +這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。 + +由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。 +發送者可以通過改變所有輸入的 nSequence 欄位來選擇使用手續費替換。 +這是即將推出的 0.12 版本的記憶池策略。 +在 reddit 上有一篇很好的 [FAQ 式貼文](https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/)關於它。 + +### 會議意見 + +問題是選擇性 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 + +## 幽默時刻 + + 19:26 cfields 等等，我會喜歡郵件討論串 + 19:26 sipa cfields：你會「喜歡」它，它在 facebook 上嗎？ + 19:27 wumpus twitter 現在也有「喜歡」了 :') + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-December/000036.html diff --git a/_posts/zh_TW/meetings/2015-12-10-meeting.md b/_posts/zh_TW/meetings/2015-12-10-meeting.md new file mode 100644 index 000000000..7492443e6 --- /dev/null +++ b/_posts/zh_TW/meetings/2015-12-10-meeting.md @@ -0,0 +1,61 @@ +--- +title: IRC 會議摘要 2015-12-10 +permalink: /zh_TW/meetings/2015/12/10/ +name: 2015-12-10-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 記錄 + +- [本週記錄連結](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-10-19.01.log.html) +- [Meetbot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-10-19.01.html) + +## 議題 + +- BIP 68 語義變更 + +## BIP 68 語義變更 + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序號發出信號的共識強制交易替換，以及目前的[實作](https://github.com/bitcoin/bitcoin/pull/6312)。 +BIP 68 將先前未使用的序號欄位的意義改為相對鎖定時間。 +當建立區塊時，礦工會包含一個時間戳記。這個時間戳記必須在前 11 個區塊的中位數和網路調整時間 +2 小時之間。所以這個時間戳記可以與實際時間有相當大的差異。 +隨著鎖定時間交易的引入，這些交易只有在特定時間之後才有效，礦工被激勵對時間撒謊，以便包含原本無效的鎖定時間交易（及其手續費）。 +[BIP113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) 在鎖定時間交易中啟用使用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）來對抗這種行為。使用者可以透過在他們的鎖定時間上加 1 小時（6 個區塊）來彌補這一點。 + +### 會議意見 + +無論 BIP113 如何，對 BIP68 總是使用 MedianTimePast 是有道理的，儘管仍然需要 BIP 113 來改變 nLockTime 的語義。Morcos 的[實作](https://github.com/bitcoin/bitcoin/pull/7184)。 +BIP 68 會使最近在 [#6898](https://github.com/bitcoin/bitcoin/pull/6898) 中進行的 CreateNewBlock 效能提升無效，關於修復的討論在 [#7176](https://github.com/bitcoin/bitcoin/issues/7176) 中進行，新方法（總是使用 MedianTimePast）的修復討論和提交在 [#7187](https://github.com/bitcoin/bitcoin/pull/7187) 上。 +GUI 顯示當前鎖定的交易可能存在一些問題。如果一個區塊被孤立，一個已確認的輸入變成未確認的，這可能會使先前可接受的交易被記憶池驅逐，你可能想通知使用者它已被鎖定（相對於不可見）。 +Morcos 提議留下這個問題，並在軟分叉後清理它，因為它似乎不夠重要到需要回移。UI/錢包變更通常也與軟分叉變更分開。 +在這個思路上，morcos 提出了一個問題，即是否有一些想法和/或反對放寬記憶池目前只包含對下一個區塊有效的交易的行為。 +btcdrak 提到 ajtowns 為 BIP68+CSV 寫了一些 python 示範，這對測試者會很有用。 + +### 會議結論 + +查看 [#7184](https://github.com/bitcoin/bitcoin/pull/7184) 的 BIP68 方法 +查看上述方法的 CreateNewBlock 效能修復 [#7187](https://github.com/bitcoin/bitcoin/pull/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 + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-December/000037.html diff --git a/_posts/zh_TW/meetings/2015-12-17-meeting.md b/_posts/zh_TW/meetings/2015-12-17-meeting.md new file mode 100644 index 000000000..1ce8af00e --- /dev/null +++ b/_posts/zh_TW/meetings/2015-12-17-meeting.md @@ -0,0 +1,104 @@ +--- +title: IRC 會議摘要 2015-12-17 +permalink: /zh_TW/meetings/2015/12/17/ +name: 2015-12-17-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 記錄 + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/12/17#l1450378915.0) +- [Meetbot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-17-19.01.html) + +## 主要議題 + +- 錢包中的手續費替換處理 +- 0.13 的 C++11 + +## 錢包中的手續費替換 (RBF) 處理 + +### 背景 + +目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用 RBF，如果新交易有更高的手續費，它會替換記憶池中的當前交易。 +這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。 + +由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。 +發送者可以通過改變所有輸入的 nSequence 欄位來選擇使用 RBF。 +這是即將推出的 0.12 版本的記憶池策略。 +在 reddit 上有一篇很好的 [FAQ 式貼文](https://np.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/)關於它。 + +### 會議意見 + +0.12 的功能凍結自 12 月 1 日起生效，除了錯誤修復外，現在 0.12 分支中的內容將被發布。 +[#7219](https://github.com/bitcoin/bitcoin/pull/7219) 使 RBF 策略成為可選的（0 = 從不，1 = 總是，2 = 選擇性加入）可能不會進入 0.12。 +jonasschnelli 和 harding 要求為 RBF 錢包策略提供好的想法以及處理這個問題的方法。 +Android 錢包透過點擊提升 UI 來提升手續費（透過 CPFP）。 +添加提升手續費相當簡單，做更多如添加輸入和輸出可能會使當前錢包變得非常複雜。 +對於包含輸入和輸出，你會想要準備一個包含 A+B 的已簽署交易和另一個只包含 B 的已簽署交易，該交易花費 A 中建立的找零輸出。 +對於 0.13，我們希望至少看到一個手續費提升選項和一些原始交易指令來修改錢包交易。 + +### 會議結論 + +- 查看 [#7062](https://github.com/bitcoin/bitcoin/pull/7062) 為 0.12 修復記憶池限制和 PrioritiseTransaction 的手續費替換 +- 查看 [#7132](https://github.com/bitcoin/bitcoin/pull/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 + +## 幽默時刻 + + 19:03 petertodd wumpus：v0.12 分支中的 RBF 處理是將要發布的嗎？也就是說，我們已經功能凍結了嗎？ + 19:04 wumpus 是的，我們在 12 月 1 日已經功能凍結了 + 19:04 petertodd 酷 + 19:04 petertodd 或者我應該說，冰凍 + +( •_•) +( •_•)>⌐■-■ + (⌐■_■) +YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-December/000039.html diff --git a/_posts/zh_TW/meetings/2016-01-07-meeting.md b/_posts/zh_TW/meetings/2016-01-07-meeting.md new file mode 100644 index 000000000..fd26efddc --- /dev/null +++ b/_posts/zh_TW/meetings/2016-01-07-meeting.md @@ -0,0 +1,94 @@ +--- +title: 2016-01-07 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/01/07/ +name: 2016-01-07-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/07#l1452193219.0) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-07-19.00.html) + +## 主要議題 + +- 0.12 候選發布版本 +- 下一階段專案的詳細路線圖 + +## 簡短議題/備註 + +Gmaxwell 已請 Luke-Jr 接任 BIP 編輯。他將處理積壓的工作。他已[寄信到郵件列表](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012197.html)徵求資訊。 + +所有平台現在似乎都使用 C++11 編譯 bitcoin 了。Travis 仍需要 C++11 編譯器，cfields 將會啟用它。 + +Segnet 將很快進行向後不相容的變更，以改變承諾結構。 + +## 0.12 候選發布版本 + +### 背景 + +Bitcoin Core 0.12 計劃於二月左右發布，引入了許多修復和改進。 + +### 會議討論 + +發布說明仍需要更多資訊。 +PR [#7151](https://github.com/bitcoin/bitcoin/pull/7151) 和 [#7149](https://github.com/bitcoin/bitcoin/pull/7149) 被提到可能仍會納入 0.12，以及 [#7098](https://github.com/bitcoin/bitcoin/pull/7098) 的快速修復（待撰寫）。 +Morcos 強烈認為照現狀發布 0.12 是相當糟糕的。由於 smartfee 的變更，卡住的交易應該會非常罕見，但如果發生了，會比 0.11 更糟，因為網路更容易「遺忘」交易。 +Morcos 提出 PR [#7312](https://github.com/bitcoin/bitcoin/pull/7312)「新增 RPC 呼叫 abandontransaction」作為快速修復方案，讓使用者能夠使他們的錢包遺忘不在記憶池中的交易的輸入。應該為 0.12.1 建立更好的解決方案。 + +### 會議結論 + +檢視 PR [#7151](https://github.com/bitcoin/bitcoin/pull/7151)、[#7149](https://github.com/bitcoin/bitcoin/pull/7149) 和 [#7312](https://github.com/bitcoin/bitcoin/pull/7312) +Cfields 將處理 [#7098](https://github.com/bitcoin/bitcoin/pull/7098) 的修復 + +## 下一階段專案的詳細路線圖 + +### 背景 + +Morcos 請求提供專案時間軸的一些方向，以及實作順序大致應該是什麼。這樣才能集中精力和焦點。 +更清晰的計劃可以促使資源投入到正確的部分。 + +### 會議討論 + +- Jonasschnelli 將處理錢包的 RBF 功能。 +- Cfields 計劃下週發布網路堆疊改造的徵求意見。 +- [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) 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。" + +## 致謝 + +本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 [bitcoin-discuss 郵件列表][meetingsource]，附帶免責聲明「請記住我不是開發人員，所以有些內容可能不正確或完全錯誤。」並將版權置於公有領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-January/000040.html diff --git a/_posts/zh_TW/meetings/2016-01-14-meeting.md b/_posts/zh_TW/meetings/2016-01-14-meeting.md new file mode 100644 index 000000000..ec1599793 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-01-14-meeting.md @@ -0,0 +1,157 @@ +--- +title: 2016-01-14 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/01/14/ +name: 2016-01-14-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/14#l1452798004.0) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-14-19.00.html) + +## 主要議題 + +- Versionbits +- 隔離見證的狀態 +- 0.12 bitcoin-core 發布狀態 +- 共識程式碼封裝（libconsensus） +- Locktime PR + +## Versionbits + +### 背景 + +[BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) +目前軟分叉是透過 isSuperMajority 機制完成的，意思是當最近 1000 個區塊中有 95% 的版本號高於 X 時，分叉就會部署。 +目前正在開發一種新方法，使用版本號的所有位元，適當地稱為 versionbits。 +因此，不是在版本大於（例如）00000000011（3）時發生分叉，而是在（例如）第 3 位元被設定時發生分叉（即 00100000011）。 +這樣軟分叉就可以同時且獨立地部署。 + +### 會議討論 + +Morcos 自願接手主導這個提案，因為 CodeShark 和 Rusty 正忙於其他事情。他將審查兩種實作，然後決定以哪種實作為基礎進行工作。 +他指出，如果非核心實作正在嘗試做其他事情（並且正在使用 nVersion 進行訊號發送），當隔離見證正在部署時，不產生衝突將是重要的，這樣其他版本的使用者也可以支援隔離見證。 +如果這種方法達成共識，那麼在隔離見證部署之前，versionbits 必須準備好。 +jtimon 有一些建議，可以讓實作更簡單、更靈活。 + +### 會議結論 + +Morcos 將主導 [BIP9: Versionbits](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) 的新參考實作。 + +## 隔離見證的狀態 + +### 背景 + +隔離見證改變了交易的結構，使得簽章可以與交易的其他部分分離。 +這允許在中繼時節省頻寬、修剪舊簽章、透過引入腳本版本來軟分叉所有未來的腳本變更，並解決所有非故意形式的可延展性。 +在上次 scaling bitcoin 會議期間，Pieter Wuille 展示了一種透過軟分叉實現這一點的方法，並提議透過將簽章資料對總區塊大小進行折扣來增加區塊中的最大交易量。 +隔離見證是 bitcoin-core [容量增加路線圖](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html)的一部分。 +更詳細的說明： +- [Pieter Wuille 在舊金山 bitcoin 開發者聚會的演講](https://www.youtube.com/watch?v=NOYNZB5BCHM)（更技術性） +- [Andreas Antonopoulos 在 let's talk bitcoin 播客的演講](https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-277-separating-signatures-with-segregated-witness)（較不技術性） + +### 會議討論 + +Segnet，隔離交易的測試網路，很快就會推出第 3 版。 +Luke-Jr 已將所有隔離見證 BIP 分配到 14x 範圍。目前有 4 個 BIP：[141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)、[142](https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki)、[143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) 和 [144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki)。 + +## 0.12 bitcoin-core 發布狀態 + +### 背景 + +Bitcoin Core 0.12 計劃於二月左右發布，引入了許多修復和改進。（[發布說明](https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md)） +0.12rc1 候選發布版本可在 https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ 取得 + +### 會議討論 + +Luke-Jr 認為 PR [#7149](https://github.com/bitcoin/bitcoin/pull/7149)、[#7339](https://github.com/bitcoin/bitcoin/pull/7339) 和 [#7340](https://github.com/bitcoin/bitcoin/pull/7340) 應該已經納入 0.12，但現在真的太晚了，可能不切實際納入。 +給 gitian 建構者：0.12rc1 的 osx sig attach descriptor 由於缺少套件（實際上並不需要）而失敗。不要使用程式碼樹中的 descriptor，請使用 [#7342](https://github.com/bitcoin/bitcoin/pull/7342) 中的。這在 rc2 中已修復。 +「fundrawtransaction」和「setban」應該新增到發布說明中。在某個時候，在其他地方記錄這些指令並在發布說明中連結到它會更有意義，因為它們變得非常冗長。 +Wumpus 認為發布說明有太多細節，它們不是要取代文件。 + +### 會議結論 + +關閉 PR [#7142](https://github.com/bitcoin/bitcoin/pull/7142)，因為它現在是 [#7148](https://github.com/bitcoin/bitcoin/pull/7148) 的一部分 +每個人都可以自由改進發布說明，只需提交 PR。 + +## 共識程式碼封裝（libconsensus） + +### 背景 + +Satoshi 並不是最好的程式設計師，這留下了相當混亂的程式碼。理想情況下，你會將影響網路共識的程式碼部分分離出來，但在 bitcoin 中它們都交織在一起。 +Libconsensus 最終應該成為這個部分。這樣人們可以更容易地在非共識部分進行變更，而不用擔心造成網路分叉。 +然而，這是一個緩慢且危險的專案，需要移動大量程式碼。 + +### 會議討論 + +jtimon 有 4 個與 libconsensus 相關的 PR 待審，分別是 [#7091](https://github.com/bitcoin/bitcoin/pull/7091)、[#7287](https://github.com/bitcoin/bitcoin/pull/7287)、[#7311](https://github.com/bitcoin/bitcoin/pull/7311) 和 [#7310](https://github.com/bitcoin/bitcoin/pull/7310) +他認為如果不先合併類似 #7310 的東西，任何「大圖分支」都將高度不可讀。 +他目前擁有的最長的「大圖分支」是 https://github.com/jtimon/bitcoin/commits/libconsensus-f2 +他將分階段記錄計劃和「大圖」： +1. 有東西稱為 libconsensus：公開 verifyScript。（完成） +2. 將其餘的共識關鍵程式碼（不包括儲存）放在同一個建構套件中（見 #7091） +3. 討論 libconsensus 的完整 C API +4. 將其分離到子儲存庫 +Wumpus 指出他希望盡快開始 3，因為 API 可以很好地引導這項工作。 + +### 會議結論 + +審查 [#7091](https://github.com/bitcoin/bitcoin/pull/7091)、[#7287](https://github.com/bitcoin/bitcoin/pull/7287)、[#7311](https://github.com/bitcoin/bitcoin/pull/7311) 和 [#7310](https://github.com/bitcoin/bitcoin/pull/7310) + +## Locktime PR + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序列號訊號發送的共識強制交易替換。 +[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) CHECKSEQUENCEVERIFY。 +[BIP 113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) 使用中位時間過去作為鎖定時間計算的端點。 +簡而言之：BIP 68 將序列號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供 bitcoin 腳本系統存取。BIP 113 在鎖定時間交易中啟用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）的使用。 + +### 會議討論 + +我們需要在 2 種實作之間做出選擇，即 [#6312](https://github.com/bitcoin/bitcoin/pull/6312) 和 [#7184](https://github.com/bitcoin/bitcoin/pull/7184)。 +PR #7184 是 CreateNewBlock 最佳化與 #6312 不相容的結果。 +jtimon 認為可以相對快速地合併，因為 #7184 基於 #6312，後者有大量的測試和審查。 + +### 會議結論 + +關閉 [#6312](https://github.com/bitcoin/bitcoin/pull/6312)，採用 [#7184](https://github.com/bitcoin/bitcoin/pull/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 + +## 趣味橋段 + + 19:54 wumpus #meetingstop + 19:54 wumpus #stopmeeting + 19:54 btcdrak haha + 19:54 MarcoFalke #closemeeting + 19:54 wumpus #endmeeting + 19: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 郵件列表][meetingsource]，附帶免責聲明「請記住我不是開發人員，所以有些內容可能不正確或完全錯誤。」並將版權置於公有領域。 + +[meetingsource]: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-January/000045.html diff --git a/_posts/zh_TW/meetings/2016-01-21-meeting.md b/_posts/zh_TW/meetings/2016-01-21-meeting.md new file mode 100644 index 000000000..c96e20e79 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-01-21-meeting.md @@ -0,0 +1,115 @@ +--- +title: 2016-01-21 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/01/21/ +name: 2016-01-21-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/21#l1453402792.0) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.html) + +## 主要議題 + +- chainstate 混淆的 0.11 回溯發布版本 +- C++11 更新 +- EOL 政策 / 發布週期 + +## 簡短議題 + +- 最近合併了一個設定選項「-permitrbf」，允許節點選擇是否替換 opt-in RBF 交易。 +有些討論希望變更 0.12.0 的預設行為並將其設定為 false。由於大多數與會者在相關的 pull request（[#7386](https://github.com/bitcoin/bitcoin/pull/7386) 和 [#7388](https://github.com/bitcoin/bitcoin/pull/7388)）上表達了他們的意見，因此在會議中沒有進一步討論。 + +- 有一些關於 bitcoin core 中資料庫損壞的問題被提出。雖然問題還沒有確定是 LevelDB，但長期計劃仍然是切換到一個新的、維護良好的資料庫。 + +## chainstate 混淆的 0.11 回溯發布版本 + +### 背景 + +正如一些 Windows 使用者過去可能經歷的，防毒軟體經常偵測到 bitcoin 資料庫檔案中的值，這些是誤報。因此刪除這些檔案並損壞資料庫。 +為了防止這種情況發生，開發人員去年[討論](https://github.com/bitcoin/bitcoin/issues/6613)了一種混淆資料庫檔案的方法並[實作](https://github.com/bitcoin/bitcoin/pull/6650)了它。 +雖然升級後可以降級，但如果你從新的 0.12 安裝開始，或者你在 0.12 上執行了 -reindex，就不可能降級到 0.11（除非從頭開始）。 + +### 會議討論 + +提議的 [pull request](https://github.com/bitcoin/bitcoin/pull/7259) 在 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](https://github.com/bitcoin-core/website/pull/37)。 +鑑於龐大的 [0.12 變更日誌](https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md)，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 萬歲！ diff --git a/_posts/zh_TW/meetings/2016-01-28-meeting.md b/_posts/zh_TW/meetings/2016-01-28-meeting.md new file mode 100644 index 000000000..6279accfa --- /dev/null +++ b/_posts/zh_TW/meetings/2016-01-28-meeting.md @@ -0,0 +1,103 @@ +--- +title: 2016-01-28 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/01/28/ +name: 2016-01-28-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/28#l1454007669.0) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-28-19.01.html) + +## 主要議題 + +- 重構時段 +- 0.12.0 的未解決問題 +- 新的「關鍵」OpenSSL 發布如何影響我們 + +## 簡短議題 + +ajtowns 為 OP_CSV 編寫了一些功能測試腳本，這將有助於測試 [#7184](https://github.com/bitcoin/bitcoin/pull/7184)（[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)）和 [#6564](https://github.com/bitcoin/bitcoin/pull/6564)（[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)） + +## 重構時段 + +### 背景 + +jtimon 詢問這確切是什麼時候以及它包含什麼。重構是將程式碼移動到特定的函式庫或檔案，以使事情更容易閱讀，並能夠安全地變更部分程式碼而不影響其他部分。 +主要這些將是為了促進 libconsensus 的移動，該部分將包含所有共識關鍵程式碼。 + +### 會議討論 + +Wumpus 可以開始合併僅移動的東西。 +重構可能會與隔離見證產生衝突，然而等待它可能會錯過 0.13 的重構時段。 + +### 會議結論 + +重構時段從現在到 -未決定- +審查 [#7091](https://github.com/bitcoin/bitcoin/pull/7091)、[#7287](https://github.com/bitcoin/bitcoin/pull/7287)、[#7310](https://github.com/bitcoin/bitcoin/pull/7310) 和 [#7311](https://github.com/bitcoin/bitcoin/pull/7311) + +## 0.12.0 的未解決問題 + +### 背景 + +Bitcoin Core 0.12 計劃於二月左右發布，引入了許多修復和改進。（[發布說明](https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md)） +0.12rc2 候選發布版本可在 https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ 取得 + +### 會議討論 + +我們需要用新的金鑰簽署 win32 發布版本，用於 win7+，因為目前的金鑰使用已被破解的 sha-1。 +關於優先順序變更應該如何在發布說明中記錄，仍有一些爭議。例如 [#7346](https://github.com/bitcoin/bitcoin/pull/7346) +gmaxwell 指出我們從未對 localhost 被列入白名單的問題做任何處理，這可能會導致新的自動隱藏服務建立出現問題。這個問題在 [2015/12/03 會議](https://bitcoincore.org/en/meetings/2015/12/03/)中提出 + +### 會議結論 + +將會有一個新的金鑰，如果花太長時間取得，這次可以由其他人簽署。 +gmaxwell 將變更 [#7082](https://github.com/bitcoin/bitcoin/pull/7082) 以僅移除 localhost 的特權。PR 的其餘部分可以在 12.1/0.13 中完成 + +## 新的「關鍵」OpenSSL 發布如何影響我們 + +### 背景 + +有一個新的 openSSL 發布修復了一些安全問題。https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html +問題是這是否以及如何影響 bitcoin。 +從 0.12 開始，bitcoin-core 使用他們自己的 libsecp256k1 進行 ECDSA 簽章驗證，而不是 openSSL。 + +### 會議討論 + +[BIP70](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki)（付款協定）可能會受到影響。 +core 中仍然依賴 openSSL 的部分是熵、AES（錢包）和 BIP70。 +有計劃用 [fortuna](https://github.com/bitcoin/bitcoin/pull/5885)（由 sipa 和 gmaxwell 建構）替換 openSSL 的熵，這需要建構到一個單獨的函式庫中。 +製作安全的隨機數產生器有許多複雜性，首先是分叉偵測（分叉 = 一個 unix 操作，它複製整個程序狀態，這將導致重複使用隨機數） +Wumpus 指出 openSSL 有相同的問題，我們只需要比 openSSL 更好，而且 bitcoin 從不分叉，所以問題主要是對使用函式庫的其他應用程式。 +如果這是一個包括非 bitcoin 使用者的工作會很好（例如郵件列表和 tor） + +### 會議結論 + +長期目標是只在 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 + + +## 趣味橋段 + + 19:47 wumpus 也要注意 bitcoin 從不分叉 + + 19:48 wumpus gmaxwell: 只要加上免責聲明「不適用於分叉」 + 19:48 jonasschnelli 「不適用於分叉」？HF 還是 SF.... + 19:48 jonasschnelli diff --git a/_posts/zh_TW/meetings/2016-02-04-meeting.md b/_posts/zh_TW/meetings/2016-02-04-meeting.md new file mode 100644 index 000000000..934630ca1 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-02-04-meeting.md @@ -0,0 +1,95 @@ +--- +title: 2016-02-04 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/02/04/ +name: 2016-02-04-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/02/04#l1454612462.0) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-02-04-19.01.html) + +## 主要議題 + +- Segwit 提議的變更 +- Sequence locks + +## 簡短議題 + +Bitcoin core 0.12 已到候選發布版本 3 https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ + +在先前會議中討論的生命週期結束政策已[發布](https://bitcoincore.org/en/lifecycle/)。 + +## Segwit 提議的變更 + +### 背景 + +隔離見證改變了交易的結構，使得簽章可以與交易的其他部分分離。 +這允許在中繼時節省頻寬、修剪舊簽章、透過引入腳本版本來軟分叉所有未來的腳本變更，並解決所有非故意形式的可延展性。 +在上次 scaling bitcoin 會議期間，Pieter Wuille 展示了一種透過軟分叉實現這一點的方法，並提議透過將簽章資料對總區塊大小進行折扣來增加區塊中的最大交易量。 +隔離見證是 bitcoin-core [容量增加路線圖](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html)的一部分。 +更詳細的說明： +- [Pieter Wuille 在舊金山 bitcoin 開發者聚會的演講](https://www.youtube.com/watch?v=NOYNZB5BCHM)（更技術性） +- [Andreas Antonopoulos 在 let's talk bitcoin 播客的演講](https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-277-separating-signatures-with-segregated-witness)（較不技術性） + +Peter Todd 為隔離見證提出了兩個想法： +- [未驗證的區塊擴充資料](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012301.html)，這將使未來新增共識資料的軟分叉更容易部署。 +- 礦工應該證明他們或可信的第三方有前一個區塊資料的副本才能建立新區塊，作為一種不進一步激勵無驗證挖礦的方式。 + +### 會議討論 + +關於未驗證區塊擴充資料的討論正在進行中。 +Petertodd 正在處理 prev-block-proof，他可能會在幾天內準備好供審查。 +這個想法*可以*用來完全阻止 SPV 挖礦，我們是否這樣做是一個實作決定。 +也可以強制區塊必須是空的才能進行無驗證挖礦。 +SPV 挖礦的問題在於它破壞了 SPV 錢包的安全模型。 + +### 會議結論 + +由於討論轉向 bitcoin 應該成為什麼的更長期想法，它被重新導向會議外，因為會議是針對短期開發的。 + +## Sequence locks + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序列號訊號發送的共識強制交易替換。 +[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) CHECKSEQUENCEVERIFY。 +簡而言之：BIP 68 將序列號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供 bitcoin 腳本系統存取。 + +### 會議討論 + +[BIP68 實作](https://github.com/bitcoin/bitcoin/pull/7184)已完成並正在收集 ACK，[BIP112 實作](https://github.com/bitcoin/bitcoin/pull/6564)也是如此 +Ajtowns 編寫了一些[測試腳本](https://github.com/ajtowns/op_csv-test)，為此你需要將兩個 PR 合併在一起。btcdrak 在 [https://github.com/btcdrak/bitcoin/tree/sequenceandcsv](https://github.com/btcdrak/bitcoin/tree/sequenceandcsv) 這樣做了 +下游使用者已進行了廣泛的測試，發現程式碼對他們的案例很有用。 +所有 BIP 文字都已合併且最終確定。 +Petertodd 指出他認為我們仍然缺少實際軟分叉的交易級單元測試。 + +### 會議結論 + +審查並 ACK [#7184](https://github.com/bitcoin/bitcoin/pull/7184) 和 [#6564](https://github.com/bitcoin/bitcoin/pull/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 + +## 趣味橋段 + + 19:29 petertodd 注意我認為我們仍然缺少交易級單元測試，我會基於此 NACK 實際的軟分叉 + 19:29 wumpus petertodd: 我認為提前 NACK 是沒有建設性的 + 19:30 btcdrak wumpus: 他是首席反對者，他必須這樣做！ + 19:30 btcdrak 呃甚至是 Chief + 19:30 petertodd btcdrak: 我 Naysay 你的拼寫 :P diff --git a/_posts/zh_TW/meetings/2016-02-11-meeting.md b/_posts/zh_TW/meetings/2016-02-11-meeting.md new file mode 100644 index 000000000..921baf0e8 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-02-11-meeting.md @@ -0,0 +1,96 @@ +--- +title: 2016-02-11 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/02/11/ +name: 2016-02-11-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/02/11#l1455217245.0) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-11-19.00.html) + +## 主要議題 + +- BIP68 審查 +- 軟分叉邏輯（BIP9） +- squash/rebase 建議 + +## 簡短議題 + +Cfields 仍在處理網路堆疊的改造，他希望下週準備好。合併這種變更的最佳時機是在發布視窗開始時，所以大約是現在。否則我們將不得不推遲到 0.14 + +Petertodd 正在撰寫關於欺詐證明的文章/論文/部落格文章，以及一些相關的資料結構工作。Maaku 想與他合作處理欺詐證明和 prev-block 證明，因為他自己對此進行了探索。 + +## BIP68 審查 + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序列號訊號發送的共識強制交易替換。 +[BIP68 實作](https://github.com/bitcoin/bitcoin/pull/7184) 僅記憶池 +在會議後合併。 + +### 會議討論 + +BIP68 和 112 在作為軟分叉安全之前不需要記憶池部署，然而我們總是在軟分叉邏輯之前合併僅政策的實作。 +軟分叉需要更多的審查和單元測試。 + +### 會議結論 + +將僅記憶池實作合併到 master，當軟分叉準備好時將記憶池 + 軟分叉回溯到 0.12.x。 +審查/測試 BIP112 [#7524](https://github.com/bitcoin/bitcoin/pull/7524)（重新基底版本） + +## 軟分叉邏輯（BIP9） + +### 背景 + +[BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) +目前軟分叉是透過 isSuperMajority 機制完成的，意思是當最近 1000 個區塊中有 95% 的版本號高於 X 時，分叉就會部署。 +目前正在開發一種新方法，使用版本號的所有位元，適當地稱為 versionbits。 +因此，不是在版本大於（例如）00000000011（3）時發生分叉，而是在（例如）第 3 位元被設定時發生分叉（即 00100000011）。 +這樣軟分叉就可以同時且獨立地部署。 + +### 會議討論 + +需要 BIP 9，因為有太多未完成的軟分叉，可能會延遲所有軟分叉。然而，我們不應該因為 BIP9 開發的延遲而阻止有價值的軟分叉。 +當另一個 isSuperMajority 軟分叉尚未完成時，我們可以透過 BIP9 進行部署。 +目前 BIP9 實作的問題是：Codeshark 的版本有很多程式碼，似乎做了很多不相關的事情，而 Rusty 的版本從未有快取層使其高效。 +Petertodd 指出它需要在資料庫中新增一些東西來儲存旗標，然而 sipa 提供了一個解決方案，為每個區塊計算一次狀態，之後保持不可變，並在啟動時重新計算。這樣你就不必在 chainstate 中儲存任何東西。 +Morcos 退出了 BIP9 的工作。如果沒有其他志願者，jtimon 將會做。 + +### 會議結論 + +在 BIP9 合併之前進行 isSuperMajority 軟分叉。 + +## squash/rebase 建議 + +### 背景 + +pull request 通常由幾個不同的提交（對程式碼的變更）組成。這些提交可以壓縮成一個提交。在先前討論的 BIP68 實作上，對於要壓縮什麼和不壓縮什麼進行了一些[討論](https://github.com/bitcoin/bitcoin/pull/7184#issuecomment-182594295)。 + +### 會議討論 + +提交有邏輯功能，你想講述一個你如何變更程式碼的故事，這很容易審查，不一定是你的時間順序變更。如果你有大量的「修復問題 X」，其中 X 是在同一個 pull 中引入的，那是沒有用的。 +一個擔憂是壓縮對正在審查的人來說很煩人。 +Sipa 指出，有一個本地審查腳本會很好，它儲存你審查過的提交/樹，然後向你顯示與你之前審查的內容的差異。 + +### 會議結論 + +一般規則是：做任何更容易閱讀和審查的事情。 + +## 與會者 + + 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 diff --git a/_posts/zh_TW/meetings/2016-02-18-meeting.md b/_posts/zh_TW/meetings/2016-02-18-meeting.md new file mode 100644 index 000000000..b342c8e0e --- /dev/null +++ b/_posts/zh_TW/meetings/2016-02-18-meeting.md @@ -0,0 +1,77 @@ +--- +lang: zh_TW +name: 2016-02-18-meeting +version: 1 +type: meetings +layout: page +permalink: /zh_TW/meetings/2016/02/18/ +title: 2016-02-18 IRC 會議摘要 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-02-18/?msg=60397355&page=2) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-18-19.04.html) + +## 主要議題 + +- `feefilter` P2P 訊息 +- SequenceLocks 檢查的重組效能 + +## 簡短議題/備註 + +注意：這次會議很短，因為一些開發人員正在參加 +Bitcoin Roundtable。 + +Btcdrak 建議安排 C++ 和 Python 的 Jetbrains IDE 的開源授權。維護者（wumpus）需要申請。 + +## `feefilter` P2P 訊息 + +### 背景 + +Bitcoin Core 0.12 中引入了有限記憶池的概念，以提供對低費用且未被挖掘的攻擊或垃圾交易的保護。目前有一個[拒絕訊息](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki)允許通知對等節點關於費用不足的情況，但只是針對每個交易。`feefilter` 訊息允許節點通知其對等節點它願意接受的最低交易費用率，以便其對等節點可以跳過中繼不符合的交易。 + +### 會議討論 + +Wumpus 還沒有查看費用過濾器，所以將在下次會議上討論。 + +### 會議結論 + +審查*實作 "feefilter" P2P 訊息* [\#7542](https://github.com/bitcoin/bitcoin/pull/7542) + +## SequenceLocks 檢查的重組效能 + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序列號訊號發送的共識強制交易替換。 + +BIP 68 將先前未使用的序列號欄位的意義改為相對鎖定時間。 + +SequenceLocks 函式用於根據 BIP 68 評估序列鎖定時間或高度。 + +檢查序列鎖定以確定交易是否有效需要查詢其所有輸入的高度。在重組中，按照目前的情況，這將需要重新評估記憶池中每個交易的輸入。 +PR [\#7187](https://github.com/bitcoin/bitcoin/pull/7187) 嘗試為每個交易快取包含具有序列鎖定的輸入的最新區塊的區塊雜湊。在發生重組時，如果該雜湊仍在鏈上，你知道先前計算的高度和時間（也已快取）仍然有效。這意味著理想情況下大多數輸入不需要重新評估。 + +### 會議討論 + +有討論是否應該將此回溯到 0.12 和 0.11。由於 0.12 中對記憶池的所有變更，將該最佳化回溯到已經慢得多的 0.11 可能會非常困難。 + +### 會議結論 + +審查/測試*為 SequenceLocks 檢查保持重組快速* [\#7187](https://github.com/bitcoin/bitcoin/pull/7187) + +## 與會者 + + wumpus Wladimir J. van der Laan + morcos Alex Morcos + btcdrak btcdrak + paveljanik Pavel Janik + sdaftuar Suhas Daftuar + shea256 Ryan Shea + +## 趣味橋段 + + 19:08:51 現在的主題是 7187 嗎？ + 19:09:22 我們還沒有主題 :) + 19:09:32 * btcdrak 為 wumpus 泡咖啡 diff --git a/_posts/zh_TW/meetings/2016-02-25-meeting.md b/_posts/zh_TW/meetings/2016-02-25-meeting.md new file mode 100644 index 000000000..cce309a74 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-02-25-meeting.md @@ -0,0 +1,98 @@ +--- +lang: zh_TW +name: 2016-02-25-meeting +version: 1 +type: meetings +layout: page +permalink: /zh_TW/meetings/2016/02/25/ +title: 2016-02-25 IRC 會議摘要 +--- +{% include toc.html %} + +## 會議記錄 + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-02-25/?msg=60913933&page=2) +- [meetbot 產生的會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.html) + +## 主要議題 + +- BIP 68/112/113 推出 +- 即將發布的 OpenSSL 版本 + +## 簡短議題 + +PR [\#7542](https://github.com/bitcoin/bitcoin/pull/7542) *實作 "feefilter" P2P 訊息*尚未被審查。 + +## BIP 68/112/113 推出 + +### 背景 + +[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) 透過序列號訊號發送的共識強制交易替換。 +[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) CHECKSEQUENCEVERIFY。 +[BIP 113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) 使用中位時間過去作為鎖定時間計算的端點。 + +簡而言之：BIP 68 將序列號欄位的意義改為相對鎖定時間。BIP 112 使該欄位可供 bitcoin 腳本系統存取。 +BIP 113 在鎖定時間交易中啟用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）的使用。 + +[BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) +具有超時和延遲的版本位元。 + +目前軟分叉是透過 IsSuperMajority 機制完成的，意思是當最近 1000 個區塊中有 95% 的版本號高於 X 時，分叉就會部署。目前正在開發一種新方法，使用版本號的所有位元，適當地稱為 versionbits。因此，不是在版本大於（例如）00000000011（3）時發生分叉，而是在（例如）第 3 位元被設定時發生分叉（即 00100000011）。這樣軟分叉就可以同時且獨立地部署。 + +### 會議討論 + +相當多的算力正在使用區塊版本號為 [BIP 109](https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki) 投票，這使得使用 IsSuperMajority 的部署變得複雜。這也可能延遲隔離見證的部署。因此可能會使用 versionbits。 + +BIP 68 需要 v2 交易，目前不會被中繼。 + +相當一部分算力在任何發布的軟體支援 CLTV（[BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)）之前就已經訊號發送準備好強制執行它。 + +### 會議結論 + +PR [\#7561](https://github.com/bitcoin/bitcoin/pull/7561) 需要轉換為 versionbits。 + +審查 PR [\#7575](https://github.com/bitcoin/bitcoin/pull/7575)。 + +中繼政策可能會在軟分叉部署之前變更。 + +與 [btcd](https://github.com/btcsuite/btcd) 開發人員討論 BIP 9/68/112/113 以獲得回饋。 + +向郵件列表發送關於 BIP 68/112/113 部署的電子郵件，徵求任何反對意見。 + +為了防止過早啟動，將為 BIP 9 軟分叉定義「開始時間」。建議在預期發布日期後 1-2 個月的開始時間。 + +## 即將發布的 OpenSSL 版本 + +### 背景 + +有一個新的 [OpenSSL 發布](https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html)修復了一些安全問題。 + +從 0.12 開始，Bitcoin Core 使用他們自己的 libsecp256k1 進行 ECDSA 簽章驗證，而不是 OpenSSL。 + +### 會議討論 + +OpenSSL 應該盡可能從軟體中移除。 + +OpenSSL 實際上只在[付款協定](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki)中需要，而該協定幾乎未被使用。建議預設停用它並聆聽回饋。 + +### 會議結論 + +暫時需要推出嚴重 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 + +## 趣味橋段 + + 19:25:30 wumpus: 我會謹慎合併任何共識重構 PR，直到我們合併 sf 程式碼。這將使回溯到 0.12 更容易且更容易驗證（基本上是簡單的 cherrypick）。 + 19:26:28 btcdrak: 我建議我們買一台時光機給 jtimom，這樣他就可以在過去進行重構了 :) + 19:26:40 *jtimon diff --git a/_posts/zh_TW/meetings/2016-03-03-meeting.md b/_posts/zh_TW/meetings/2016-03-03-meeting.md new file mode 100644 index 000000000..469902af4 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-03-03-meeting.md @@ -0,0 +1,156 @@ +--- +title: IRC meeting summary for 2016-03-03 +permalink: /zh_TW/meetings/2016/03/03/ +name: 2016-03-03-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/03/03#l1457031985.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.html) + +--- + +## VersionBits (BIP9) 軟分叉邏輯 + +*背景：[BIP9][] 是一種部署軟分叉的機制，取代了用於部署 BIP [34][BIP34]、[66][BIP66] 和 [65][BIP65] 的 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 儲存庫中開啟了一個[問題](https://github.com/bitcoin/bitcoin/issues/7633)，報告 -paytxfee 設定選項的行為隨著 Bitcoin Core 0.12.0 的發布而改變* + +「所以我認為發生了什麼，」Pieter Wuille 寫道，「是在某個時候我們將挖礦程式碼切換為每位元組而不是每千位元組。後來引入了[一個]全域[變數]，即使程式碼的其餘部分已更新為每位元組，它隱式地保留了『四捨五入到 1,000 位元組進行費用計算』的行為，只是現在，隨著全域[變數]的消失，我們實際上得到了準確的變更。」 + +由於使用此設定選項時交易大小以前會四捨五入，但現在正在精確計算，因此現在每位元組支付的費用低於使用 `-paytxfee` 旗標的使用者的預期。請注意，此語意變更僅影響手動設定此選項的使用者。 + +Alex Morcos 提到 `-maxsigcachesize` 基本單位也已變更；現在是以兆位元組為單位。他建議：「在變更任何選項或 RPC 呼叫的行為時有一個檢查清單 [...] 我不確定有多少人會在兩英尺厚的發布說明中發現所有這些警告，但擁有它們仍然很好。」 + +## FeeFilter + +*背景：Alex Morcos 最近提出的 [draft BIP133][BIP133] 建議在 P2P 協議中新增一條新訊息，允許節點告訴其對等節點，它只想接收關於新交易的通知，如果這些交易支付的每位元組交易費用超過某個水平。請求過濾掉低費用交易的節點可以選擇它想要的任何每位元組費用水平。由於今天的節點無法告訴其對等節點它們不會處理低費用交易，因此相信引入此訊息將減少網路上浪費的流量。* + +討論極為簡短。Morcos 說：「它減少了約 40% 以上的交易傳送和接收頻寬」。Maxwell 回答：「太棒了」，還說「feefilter 很棒」。 + +Dashjr 建議 feefilter「需要某種『模式』來處理『我們如何測量大小』等問題，但[那]不是什麼大問題。」Morcos 有不同的看法：「我基本上認為我們在需要之前不引入複雜性。」Maxwell 同意：「我們不會用完訊息類型，所以我們可以稍後引入 modefilter」。 + +從長遠來看，Maxwell 補充說：「我預計中繼工作方式會在未來幾年發生重大變化；所以我們可能不應該在這裡過度設計。」 + +feefilter 的行動項目是更多審查和測試。 + +## Child Pays For Parent (CPFP) 挖礦 + +*背景：Suhas Daftuar 有一個進行中的 (WIP) [pull request][#7600]，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child [transaction] Pays For Parent [transaction] (CPFP)。* + +Daftuar 報告：「我在過去兩天一直在執行[該程式碼]。[我一直在]大約每 128 筆交易比較現有的挖礦演算法和新演算法。[當]查看找到區塊之前對 CreateNewBlock() [函數]的最後一次呼叫時，我看到最後 144 個資料點的費用/區塊有[顯著]增加。」 + +Maxwell 解釋了為什麼預期會有非微不足道的獲利能力增加：「我相信它應該會從我所看到的情況中對選擇產生一些相當大的差異。許多 OTHERBRAND [原文如此] 錢包的使用者沒有費用估算，總是花費未確認的找零，似乎經常產生非常低費用、非常高費用的鏈（在意識到他們需要從第一筆交易中支付更多費用之後）。」 + +關於用於測試獲利能力增加的方法的討論解釋說，該測試可能多次計算了一些交易，因此每個區塊捕獲的費用的確切增加可能少於測試所指示的。儘管如此，在其他條件相同的情況下，人們可以安全地假設礦工會樂於執行增加其潛在獲利能力的程式碼。 + +然後 Daftuar 報告了新程式碼在效能方面的成本。「所以有三個效能方面需要考慮： + +1. 「記憶體池保持[相關交易及其費用的]索引的額外工作 + +2. 「在呼叫 TestBlockValidity() 之前 CreateNewBlock() 的部分 + +3. 「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 構建資訊放在版本號中可能會很有用。[這]對隱私來說很糟糕，但[它]在這裡會很有用。」 + +行動項目是幾個人將致力於確定分叉的原因。 + +## 結論 + +會議在預定結束時間結束，議程上仍有一些項目。一些會後立即討論已被整合到本摘要中。 + +## 娛樂時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +引用的討論內容經過修改，調整了大小寫、標點符號和拼寫以產生一致的句子。括號內的詞語和片段以及背景敘述和解釋性說明是由本摘要作者新增的，可能會意外改變某些句子的含義；如果您認為任何引用脫離了上下文，請聯絡我們，我們將糾正錯誤。 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + + +{% include references.md %} + +[#7575]: https://github.com/bitcoin/bitcoin/pull/7575 +[#7594]: https://github.com/bitcoin/bitcoin/pull/7594 +[#7598]: https://github.com/bitcoin/bitcoin/pull/7598 +[#7600]: https://github.com/bitcoin/bitcoin/pull/7600 diff --git a/_posts/zh_TW/meetings/2016-03-10-meeting.md b/_posts/zh_TW/meetings/2016-03-10-meeting.md new file mode 100644 index 000000000..4df8ffe33 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-03-10-meeting.md @@ -0,0 +1,158 @@ +--- +title: IRC meeting summary for 2016-03-10 +permalink: /zh_TW/meetings/2016/03/10/ +name: 2016-03-10-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/03/10#l1457636399.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.html) + +--- + +## 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 數位簽章演算法][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][BIP9]、[68][BIP68]、[112][BIP112]、[113][BIP113]] 反向移植到 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][#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 管理的軟分叉變更警告和警報。 + +## 娛樂時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +引用的討論內容經過修改，調整了大小寫、標點符號和拼寫以產生一致的句子。括號內的詞語和片段以及背景敘述和解釋性說明是由本摘要作者新增的，可能會意外改變某些句子的含義；如果您認為任何引用脫離了上下文，請聯絡我們，我們將糾正錯誤。 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + + + +[schnorr]: https://en.wikipedia.org/wiki/Schnorr_signature +[libsecp256k1]: https://github.com/bitcoin/secp256k1 +[軟體生命週期]: /zh_TW/lifecycle/ + +[#7575]: https://github.com/bitcoin/bitcoin/pull/7575 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-03-17-meeting.md b/_posts/zh_TW/meetings/2016-03-17-meeting.md new file mode 100644 index 000000000..e7f08dc40 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-03-17-meeting.md @@ -0,0 +1,105 @@ +--- +title: IRC meeting summary for 2016-03-17 +permalink: /zh_TW/meetings/2016/03/17/ +name: 2016-03-17-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/03/17#l1458241237.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.html) + +--- + +## 主要議題 + +- 為 BIP 68、112、113 安排第一個 BIP 9 軟分叉 +- 除了 BIP 9 之外 0.12.1 的功能 +- 隔離見證的狀態 + +## 為 BIP 68、112、113 安排第一個 BIP 9 軟分叉 + +### 背景 + +VersionBits [BIP9][] 允許使用區塊標頭版本欄位作為位元陣列，以便礦工可以同時表示對多達 29 個軟分叉的準備就緒。根據目前的程式碼和提案，未表示對任何軟分叉準備就緒的礦工將建立「版本 4 區塊」，即與用於觸發和執行 [BIP65][] CLTV 軟分叉相同版本的區塊。 + +### 會議評論 + +每個人似乎都對 PR [#7575][]（會議後不久合併）感到滿意。 +一旦決定了開始日期和位元編號，就應該在郵件列表上宣布，以便其他實作也可以實作它。 +Btcdrak 和 Morcos 將為 0.12 和 0.11 準備好反向移植。 +[BIP9][] BIP 文字是最新的，更新 BIP [68][BIP68]、[112][BIP112] 和 [113][BIP113] 的軟分叉資訊也是個好主意。 + + +### 會議結論 + +- 合併 [#7575][] +- 審查 [#7648][] +- 基於 [BIP9][] 的部署開始日期是 5 月 1 日，位元編號為 0。 +- btcdrak 將使用新的軟分叉資訊更新 BIP 文字 [68][BIP68]、[112][BIP112] 和 [113][BIP113] 的部署部分。 + +## 除了 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 版本發布之前準備好。 + + +## 娛樂時刻 + +{% highlight text %} +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 + +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7575]: https://github.com/bitcoin/bitcoin/pull/7575 +[#7648]: https://github.com/bitcoin/bitcoin/pull/7648 +[#7579]: https://github.com/bitcoin/bitcoin/pull/7579 +[#7715]: https://github.com/bitcoin/bitcoin/pull/7715 +[#7707]: https://github.com/bitcoin/bitcoin/pull/7707 +[#7568]: https://github.com/bitcoin/bitcoin/pull/7568 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-03-24-meeting.md b/_posts/zh_TW/meetings/2016-03-24-meeting.md new file mode 100644 index 000000000..c219d2da3 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-03-24-meeting.md @@ -0,0 +1,114 @@ +--- +title: IRC meeting summary for 2016-03-24 +permalink: /zh_TW/meetings/2016/03/24/ +name: 2016-03-24-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/03/24#l1458846025.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-24-19.00.html) + +--- + +## 主要議題 + +- BIP9 的軟分叉狀態 +- v0.12.1、v0.11.3 和 v0.10.5 反向移植 +- 固定時間 AES 函式庫 + +## 簡短議題 + +- Cfields 正在對 bitcoin core 的網路堆疊進行全面改革。這意味著大量程式碼的移動，但它會使新增額外功能變得更容易。他有一個功能完整的[分支](https://github.com/theuni/bitcoin/tree/net-refactor8)，他預計下週將尋求概念審查。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 仍然不同意。 + +## 娛樂時刻 + +{% highlight text %} +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! +{% endhighlight %} + +## 參與者 + +| 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][] | + + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7047]: https://github.com/bitcoin/bitcoin/pull/7047 +[#7648]: https://github.com/bitcoin/bitcoin/pull/7648 +[#7543]: https://github.com/bitcoin/bitcoin/pull/7543 +[#7716]: https://github.com/bitcoin/bitcoin/pull/7716 +[#7689]: https://github.com/bitcoin/bitcoin/pull/7689 +[軟體生命週期]: /zh_TW/lifecycle/ + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-03-31-meeting.md b/_posts/zh_TW/meetings/2016-03-31-meeting.md new file mode 100644 index 000000000..ae2de9514 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-03-31-meeting.md @@ -0,0 +1,146 @@ +--- +title: IRC meeting summary for 2016-03-31 +permalink: /zh_TW/meetings/2016/03/31/ +name: 2016-03-31-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/03/31#l1459450785.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.html) + +--- + +## 主要議題 + +- 隔離見證更新 +- 軟分叉反向移植 +- 壞鏈警報 +- child-Pays-For-parent 挖礦 + +## 簡短議題 + +上週討論的中位時間過去違規檢查更新：目前沒有違規被挖掘。Gmaxwell 將開始產生 MTP 違規交易以再次檢查。 + +網路堆疊重構更新：cfields 將最新版本推送到他的 [net-refactor10 分支](https://github.com/theuni/bitcoin/tree/net-refactor10)，已準備好進行測試和審查。它仍然需要一堆單元測試，cfields 正在為此建置框架，以及文件。 + +Jonasschnelli 詢問人們是否仍然對他一直在研究的 p2p 加密和身份驗證 BIP 感興趣。我們是需要自己的解決方案還是調整已有的解決方案。Sipa 提議從 openssh 複製加密程式碼，這是 300 行的 [chacha20](https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant) - [poly1305](https://en.wikipedia.org/wiki/Poly1305)。每個人似乎都贊成繼續編寫 BIP，因為它允許錢包 (spv) 的簡單設定以增加隱私。 + +## 隔離見證更新 + +### 背景 + +幾位開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。 + +### 會議評論 + +Sipa，segwit 程式碼的主要貢獻者/維護者，指出： + +- segwit 程式碼在過去幾天取得了很大進展；它現在通過了所有預先存在的 rpc 測試和單元測試，並在此過程中修復了許多錯誤 +- 它在 bip68/112/113 反向移植之上重新建立，並且新的 segnet (segnet4) 已啟動並執行 bip9 啟動邏輯 +- 我已經顯著重組了分支中的提交以 1) 定義 segnet 2) 新增共識/節點邏輯 3) 新增錢包邏輯 4) 新增測試。這樣就可以測試分叉後從 pre-segwit 程式碼升級，並且可以單獨審查共識關鍵部分。 +- 我將編寫腳本單元測試，因為我們沒有測試所有可能的見證驗證失敗 +- 程式碼變更可以在[這裡](https://github.com/sipa/bitcoin/compare/segwit-base...sipa: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][#7600]，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child Pays For Parent (CPFP)。 + +## 會議評論 + +第一步是讓人們為 [#7598][] 提供概念回饋，重構 CreateNewBlock。設計的最初目標是將優先順序填充與費率填充分開，但我認為整體目標應該是使其更模組化以弄清楚如何組裝區塊。 + +考慮到 0.13 的功能凍結不是那麼遙遠（2016/05/15），而且需要在 segwit 之上進行一些變更，Morcos 想知道是否要平行繼續還是先專注於 segwit。 + +## 娛樂時刻 + +{% highlight text %} + is that bad "chain alerts" or "bad chain" alerts? :) + second. + hehe both + (bad ((bad chain) alerts)) + I think it's actually more the first. +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7598]: https://github.com/bitcoin/bitcoin/pull/7598 +[#7600]: https://github.com/bitcoin/bitcoin/pull/7600 +[#7543]: https://github.com/bitcoin/bitcoin/pull/7543 +[#7716]: https://github.com/bitcoin/bitcoin/pull/7716 +[#7568]: https://github.com/bitcoin/bitcoin/pull/7568 +[軟體生命週期]: /zh_TW/lifecycle/ + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-04-07-meeting.md b/_posts/zh_TW/meetings/2016-04-07-meeting.md new file mode 100644 index 000000000..18dfafedf --- /dev/null +++ b/_posts/zh_TW/meetings/2016-04-07-meeting.md @@ -0,0 +1,111 @@ +--- +title: IRC meeting summary for 2016-04-07 +permalink: /zh_TW/meetings/2016/04/07/ +name: 2016-04-07-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/04/07#l1460055658.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.html) + +--- + +## 主要議題 + +- 如何處理 Bitcoin Core 錢包 +- 處理 RBF RPC/UI + +## 簡短議題 + +- 0.12.1 Release candidate 1 已標記（撰寫時 0.12.1 RC2 已標記） +- 中位時間過去違規檢查更新：gmaxwell 產生了許多違規，但沒有被挖掘。他仍在努力，因為他懷疑他需要更努力地中繼這些交易。 +- 5 月 20-22 日將在瑞士蘇黎世舉行 Bitcoin Core 駭客大會 [http://coredev.tech](http://coredev.tech) 感興趣的核心開發者應在 4 月 15 日之前通知 jonasschnelli。 +- Jtimon 希望對 PR [#7829][] 中的實驗獲得一些回饋，該實驗旨在幫助新人熟悉 git、審查流程等，並合併他們的第一個 PR。 + +## 如何處理 Bitcoin Core 錢包 + +### 背景 + +多年來，Bitcoin Core 錢包幾乎沒有變化。然而，錢包的長期可持續性需要許多功能。 +長期目標是讓錢包獨立於核心。 + +### 會議評論 + +Jonasschnelli 提議擴充 PR [#7830][]，將當前錢包複製到第二個目前實驗性的錢包中，然後可以透過 --enable-lightwallet 啟用。這樣就不需要向後相容性，因此需要考慮的限制更少。新錢包應該移除[帳戶](https://en.bitcoin.it/wiki/Help:Accounts_explained)，用 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](https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/)。目前 Bitcoin Core 錢包不提供任何使用這些功能的功能。 + +### 會議評論 + +Petertodd：「所以，我認為您從 RPC 的角度實際上需要做的是考慮使用者想要支付的地址，以及已知（已確認）交易是否成功做到了這一點 - 這不是錢包現在的工作方式」 + +雖然新增輸出可能更有用，但第一步應該是支援費用提高。Petertodd 編寫了一個[用 python](https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py) 提高費用的工具。 + +Gmaxwell 希望看到一種不同的方法，即「自適應費用」，它預先建立具有鎖定時間的提升並將它們排隊。雖然更好，但人們希望從簡單的費用提升開始，因為鎖定時間版本將重複使用該程式碼。我們應該小心自動費用提升，因為使用者需要意識到它並期待這種行為。 + +降低找零有一些隱私影響，然而隱私將更昂貴且難以成功。Gmaxwell 指出：「主要要做的是首先正確估算，儘管現在找零是如此徹底地可識別，以至於您是在馬跑了之後關閉穀倉門。:)」 + +費用提升可以新增到目前的錢包中，更先進的解決方案如自動費用提升可以在新錢包上完成。 + +### 會議結論 + +- 致力於 BumpFee + +## 娛樂時刻 + +{% highlight text %} +19:14:37 * gmaxwell bangs gavel +19:14:43 who is gavel? + +19:24:40 I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10 + +19:31:26 petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future? +19:32:10 jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean? +19:32:51 jonasschnelli: it shall be called BeeFump +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7830]: https://github.com/bitcoin/bitcoin/pull/7830 +[#7829]: https://github.com/bitcoin/bitcoin/pull/7829 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-04-14-meeting.md b/_posts/zh_TW/meetings/2016-04-14-meeting.md new file mode 100644 index 000000000..260eb1e43 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-04-14-meeting.md @@ -0,0 +1,127 @@ +--- +title: IRC meeting summary for 2016-04-14 +permalink: /zh_TW/meetings/2016/04/14/ +name: 2016-04-14-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/04/14#l1460660450.0) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.html) + +--- + +## 主要議題 + +- Segwit 和反向移植 +- C++11 狀態 + + +## 簡短議題 + +- 0.12.1 的狀態：RC2 已發布。同時上週已挖掘了一個 0.12.1 RC 區塊。通常我們在 RC 發布後等待一週才將其標記為最終版本，但許多人希望盡快發布它。0.12.1 功能包括 [BIP68][]、[BIP112][]、[BIP113][]，這些將透過 [BIP9][] 軟分叉機制部署。（[0.12.1](https://bitcoin.org/en/release/v0.12.1) 於 2016-04-15，即會議後第二天發布） +- 在 [2016-03-24 會議](https://bitcoincore.org/en/meetings/2016/03/24/#constant-time-aes-library)中討論的固定時間 AES 函式庫正在進行獨立審查，由 Matthew Green 的一位研究生進行，希望在幾週內可用。 +- 考慮到 0.13 計劃的新功能數量以及在[蘇黎世](http://coredev.tech/)舉行會議的時間，0.13 的功能凍結和 RC 發布週期推遲了一個月。修訂後的時程表可以在[這裡](https://github.com/bitcoin/bitcoin/issues/7679)找到。 +- 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](https://github.com/btcsuite/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。 + +## 娛樂時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7165]: https://github.com/bitcoin/bitcoin/pull/7165 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-04-21-meeting.md b/_posts/zh_TW/meetings/2016-04-21-meeting.md new file mode 100644 index 000000000..40030083b --- /dev/null +++ b/_posts/zh_TW/meetings/2016-04-21-meeting.md @@ -0,0 +1,90 @@ +--- +title: IRC meeting summary for 2016-04-21 +permalink: /zh_TW/meetings/2016/04/21/ +name: 2016-04-21-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-21-19.00.log.html) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-21-19.00.html) + +--- + +## 主要議題 + +- Segwit 審查 +- Travis 切換到 trusty + +## Segwit 審查 + +### 背景 + +開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議評論 + +上週提出的 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][]。 + +## 娛樂時刻 + +{% highlight text %} + ok, any other topics to be discussed? + the segwit afterparty! +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7910]: https://github.com/bitcoin/bitcoin/pull/7910 +[#7935]: https://github.com/bitcoin/bitcoin/pull/7935 +[#7920]: https://github.com/bitcoin/bitcoin/pull/7920 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-04-28-meeting.md b/_posts/zh_TW/meetings/2016-04-28-meeting.md new file mode 100644 index 000000000..a904bd654 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-04-28-meeting.md @@ -0,0 +1,100 @@ +--- +title: IRC meeting summary for 2016-04-28 +permalink: /zh_TW/meetings/2016/04/28/ +name: 2016-04-28-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-04-28/?msg=65090086&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.html) + +--- + +## 主要議題 + +- Segwit 審查和 BIP 的狀態更新 + +## 簡短議題 + +- 過渡到 travis trusty 和 C++11 已成功 +- 在 [2016-03-24 會議](https://bitcoincore.org/en/meetings/2016/03/24/#constant-time-aes-library)中討論的固定時間 AES 函式庫的獨立審查已完成，他正式證明了某些部分是正確的並分析了固定時間性。 +- 對於他的 replace-by-fee (RBF) 錢包實作，jonasschnelli 想知道他應該將 RBF 交易屬性為「可替換」還是將非 RBF 交易屬性為「不可替換」。開發者似乎同意前者最有意義，因為非 RBF 只是較不可替換。在許多提議之後，jonasschnelli 決定採用「已發出可替換性信號」作為確切的措辭。 +- 有人聯絡 jonasschnelli，要求為 Bitcoin Core 標誌和傳播材料建立一個儲存庫。bitcoin core 沒有清晰的標誌或視覺識別。開發者並不真正關心這個，但使用者群可能關心。在某個地方提供「新聞資料包」可能是有意義的。開源專案的新聞資料包並不常見，而且幾乎總是附帶許可政策。因此，除非人們想要監管這樣的許可政策，否則新聞資料包更像是我們也使用的推薦圖像/文字的集合。 + +## Segwit 審查和 BIP 的狀態更新 + +### 背景 + +開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議評論 + +Cfields 已開始與礦池合作，以確保他們的設定可以處理隔離見證。他的目標是讓每個礦池至少挖掘一個 segnet 區塊。 + +考慮到 segwit PR [#7910][] 涉及的許多不同部分，很少有開發者有信心能夠完全 utACK 它，因為他們可能對程式碼的特定部分不夠熟悉。開發者將專注於他們最有信心的部分並 ACK 這些部分。 + +一些人對 BIP 文字提供了回饋，並因此頻繁地進行了小的澄清。Instagibbs 驗證了 [BIP141][] 和 [BIP143][] 與其實作相符。 + +### 會議結論 + +- Sipa 將列出他認為需要額外審查的一些中等棘手的領域 +- BIP 144 需要包含服務位元的內容 + + +## 娛樂時刻 + +（編輯後只留下自行車棚評論） + +{% highlight text %} +19:35:30 RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"? +19:35:59 jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something... +19:37:16 'mempool-replaceable' ? +19:38:13 "standard-policy-0.12-replaceable"? +19:38:40 "standard-policy-0.12-BIP125-replaceable" +19:40:21 ack bip125-replaceable +19:42:24 jonasschnelli: "easily replacable" +19:42:27 opt-in-repleaceable ? +19:42:38 jonasschnelli: or heck, "trivially replacable" +19:42:45 "updatable"? +19:43:03 "replacement-requested" +19:43:04 of "signs replicability"? +19:43:39 replacability signalled ;-) +19:44:38 "replace explicitly allowed"? +19:44:41 fee-replaceable ? +19:45:58 "fee-replacability signalled"? +19:48:21 what was wrong about "Opted in to replacement" or something along those lines? +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7910]: https://github.com/bitcoin/bitcoin/pull/7910 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-05-05-meeting.md b/_posts/zh_TW/meetings/2016-05-05-meeting.md new file mode 100644 index 000000000..431905c22 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-05-05-meeting.md @@ -0,0 +1,83 @@ +--- +title: IRC meeting summary for 2016-05-05 +permalink: /zh_TW/meetings/2016/05/05/ +name: 2016-05-05-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-05-05/?msg=65532310&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-05-19.01.html) + +--- + +## 主要議題 + +- segwit versionbit、testnet 開始日期、GBT 變更 + +## 簡短議題 + +- NicolasDorier 提議致力於這個[問題](https://github.com/bitcoin/bitcoin/issues/7677)。Morcos 評論說我們應該將錢包功能分開，為「塵埃」使用一些更聰明的較高值，塵埃的下限應該是一個單獨的變數，而不是像現在這樣是最小中繼的倍數。進一步討論被導向問題本身。 +- BlueMatt 為他的緊湊區塊中繼提案準備了一份 [BIP 文件](https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki)。該文件已發送到 [bitcoin-dev 郵件列表](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012624.html)以獲得進一步回饋。 + +## 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](https://en.bitcoin.it/wiki/Getblocktemplate)(GBT) 變更需要快速就位，以便測試網是礦工將要執行的有效表示。有一個 [提議的修正案](https://github.com/bitcoin/bips/pull/365)對 BIP9 進行修正，要求礦工設定一個標誌，表示對 segwit 的認識（[實作][#7935]）。如果採用這個，不支援 segwit 的 GBT 客戶端將不會建立包含 segwit 交易的區塊。這個討論被延遲到[會議後](https://botbot.me/freenode/bitcoin-core-dev/2016-05-05/?msg=65535546&page=4)。 + +### 會議結論 + +- 在 bips 儲存庫中新增 bip-0009/assignments.md 以追蹤當前的位元分配。 +- 將 testnet 啟動設定在 5 月 1 日，到期時間為 1 年後。 + +## 娛樂時刻 + +{% highlight text %} +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. +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7935]: https://github.com/bitcoin/bitcoin/pull/7935 +[#6793]: https://github.com/bitcoin/bitcoin/pull/6793 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-05-12-meeting.md b/_posts/zh_TW/meetings/2016-05-12-meeting.md new file mode 100644 index 000000000..c14461462 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-05-12-meeting.md @@ -0,0 +1,98 @@ +--- +title: IRC meeting summary for 2016-05-12 +permalink: /zh_TW/meetings/2016/05/12/ +name: 2016-05-12-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-05-12/?msg=65949110&page=4) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.html) + +--- + +## 主要議題 + +- 一般 BIP 流程和問題 +- RPC 長輪詢通知 + + +## 緊湊區塊中繼 BIP 和一般 BIP 流程 + +### 背景 + +[BIP 152](https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki)：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。 + +### 會議評論 + +在[上週會議](https://bitcoincore.org/en/meetings/2016/05/05/#meeting-comments)中討論的 [BIP9][] 部署文件已經[建立](https://github.com/bitcoin/bips/pull/386)。 + +BIP 編輯 Luke-jr 說，如果他們不是該 BIP 的列出作者，他希望人們不要 ACK/NACK BIP，因為 BIP 是作者的文件。 + +Jonasschnelli 提議定義一個規則，說明如何處理已實作 BIP 的實作連結。在 [BIP32][] 中，不斷有 pull request 來新增連結，這些連結更多地作為廣告而不是其他任何東西。如果我們不監控它，也會帶來惡意軟體的風險。參考實作以及其他語言的實作可能很有用，因此最好連結到實作。Jcorgan 提議連結到 URL 和提交雜湊，以確保連結的程式碼反映實作。 + +### 會議結論 + +新增 BIP 實作連結取決於 BIP 作者，通常應該連結到實際的程式碼，而不是產品。 + +## RPC 長輪詢通知 + +### 背景 + +[長輪詢](https://en.wikipedia.org/wiki/Push_technology#Long_Polling)或類似協議將啟用一種簡單且安全的方式，透過網際網路向 Core 新增遠端 GUI 和遠端錢包。 + +### 會議評論 + +jonasschnelli 的 PR [#7949][] 正在實作 RPC 長輪詢通知。 + +目前 [ZeroMQ](http://zeromq.org/) 用於通知，但實際上僅對本地系統有用，不適用於透過網際網路的通知。Jcorgan 指出這可以透過 [CurveZMQ](http://curvezmq.org/) 實現。 +ZeroMQ 可能太複雜而無法進一步擴充，並且對於編寫遠端 GUI 來說是次優的，因為您無法僅過濾錢包交易，而長輪詢只需要很少的程式碼變更且沒有相依性。儘管可能有價值將 Core 限制為一個介面。 + +RPC 長輪詢的另一個優勢是能夠擁有在身份驗證後面保護的私人通知。Wumpus 想知道我們是否需要私人通知。對於遠端錢包 GUI，您會需要，但是他解釋說，這個想法是附加錢包，而不是錢包 GUI，因為錢包需要從核心分離。理想情況下，節點、錢包和 GUI 應該分離。Sipa 不確定 Core 錢包現在是否應該提供通訊通道。 + +另一個解決方案是提供一個小的守護程式，在核心和遠端 GUI/錢包之間互動。 + + +### 會議結論 + +有許多可能性：多種通知協議、僅 ZeroMQ、僅 RPC。意見分歧很大，討論在會議後繼續。大多數人似乎同意焦點應該放在節點 <-> 錢包連接上。 + +Jonasschnelli 將為 RPC 長輪詢新增一些簡單的範例。 + +## 娛樂時刻 + +{% highlight text %} +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? +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7949]: https://github.com/bitcoin/bitcoin/pull/7949 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-05-19-meeting.md b/_posts/zh_TW/meetings/2016-05-19-meeting.md new file mode 100644 index 000000000..a593c89b6 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-05-19-meeting.md @@ -0,0 +1,59 @@ +--- +title: IRC meeting summary for 2016-05-19 +permalink: /zh_TW/meetings/2016/05/19/ +name: 2016-05-19-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-05-19/?msg=66359385&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-19-19.02.html) + +--- + +## 主要議題 + +- Versionbits GetBlockTemplate 和 CSV 啟動 + +## 註記 / 簡短議題 + +- 這是一個簡短的會議，出席率很低，因為許多開發者正在前往 [coredev 駭客活動](http://coredev.tech/)。 +- Luke-jr 想知道是否有人研究了最新的 OpenSSL 漏洞。在發布 0.12.2 時，將 OpenSSL 一起提升可能是有意義的。 + +## Versionbits GetBlockTemplate 和 CSV 啟動 + +### 背景 + +Getblocktemplate 是新的去中心化比特幣挖礦協議，由比特幣社群在 2012 年中期公開開發。它取代了舊的 getwork 挖礦協議。（[Wiki](https://en.bitcoin.it/wiki/Getblocktemplate)-連結） + +CheckSequenceVerify 或 [BIP112][] 是 0.12.1 中發布的與時間鎖定相關的 BIP 之一，這是第一個應該使用 [BIP9][] versionbits 啟動的軟分叉。 + +### 會議評論 + +Luke-jr 提到他需要為 Eligius 礦池提供 [GBT 支援][#7935]。有一些應用程式需要 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7600]: https://github.com/bitcoin/bitcoin/pull/7600 +[#7935]: https://github.com/bitcoin/bitcoin/pull/7935 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-05-20-meeting.md b/_posts/zh_TW/meetings/2016-05-20-meeting.md new file mode 100644 index 000000000..00571808b --- /dev/null +++ b/_posts/zh_TW/meetings/2016-05-20-meeting.md @@ -0,0 +1,189 @@ +--- +title: 2016-05-20 非 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/05/20/ +name: 2016-05-20-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- 連結至[會議記錄 (文字)](/logs/2016-05-zurich-meeting-notes.txt)。 +- 連結至[會議記錄 (html)](/logs/2016-05-zurich-meeting-notes.html)。 + +--- + +## 主要議題 + +- 隔離見證程式碼審查 +- 未來位址類型的錯誤更正碼 +- 點對點網路協定的加密 +- 緊湊區塊中繼協定 +- Schnorr 簽章與聚合 +- 新的網路函式庫 + +## 備註 / 簡短議題 + +- 本次會議在瑞士蘇黎世舉行實體會議，而非一般的 IRC 頻道。詳情請見 。 +- 一些參與者藉此機會驗證 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 協定在區塊中繼方面的頻寬效率不高。中繼時會包含區塊中的每筆交易，即使在中繼區塊之前，節點已經獲得了給定區塊中的大量交易。這對於接收區塊的節點會造成適度的入站頻寬峰值，但對於某些在其節點之前接收到區塊的節點，可能會造成非常顯著的出站頻寬峰值。當這種峰值發生時，緩衝區膨脹可能會使消費級網路連線暫時無法使用，並可能延遲將區塊中繼到遠端節點，這些節點可能選擇等待，而不是從其他較不擁塞的節點重複請求相同的區塊。 + +因此，減少區塊中繼期間使用的頻寬對許多執行節點的個人非常有用。 + +雖然這項工作的目標明確不是為了減少區塊傳輸延遲，但作為副作用，它確實在某些相當重要的方面減少了區塊傳輸延遲。此外，這項工作為未來明確針對低延遲區塊傳輸的工作奠定了基礎。 + +### 會議討論 + +更多人被要求審查記憶池互動（特別是使用引用計數而非複製）。 + +### 會議結論 + +繼續審查 [BIP152][] 草案和 Core 實作 [\#8068](https://github.com/bitcoin/bitcoin/pull/8068)。 + +## Schnorr 簽章與聚合 + +### 背景 + +目前，比特幣對交易中消費的每個輸出都需要一個簽章，對於多重簽章幣的情況，每一方都需要一個簽章。Schnorr 簽章允許將這些簽章合併為一個可以對整個交易進行檢查的簽章，從而顯著減少驗證時間和資料大小。 + +### 會議討論 + +Pieter 介紹了他對於 schnorr 簽章和簽章聚合的構造想法的狀態。 + +### 會議結論 + +一般預期與 Schnorr 簽章相關的 BIP 將在接下來的 12 個月內提出。 + +## 新的網路函式庫 + +### 背景 + +Bitcoin Core 的網路程式碼非常簡約，不太靈活，也不容易改進。Cory 一直在進行重寫工作。 + +### 會議討論 + +Cory Fields 概述了他最近在新網路函式庫方面的工作。 + +### 會議結論 + +這最終可以用來移除原始碼中對 boost 的依賴。 + +## 默克爾抽象語法樹 + +### 背景 + +[BIP114][]，默克爾抽象語法樹（MAST），是利用 segwit 腳本版本控制的比特幣腳本語言增強。它提高了條件交易的效率和隱私性。這個 [BIP114][] 也安全地啟用了許多在比特幣早期版本中被停用的運算碼。MAST 腳本提高了隱私性，因為需要公開的資料較少，也可以使交易變小，從而節省空間。 + +### 會議討論 + +MAST 提案相當直接。它與目前的 P2WSH 方案非常相似。當你花費幣時，需要提供腳本、默克爾分支以及位置。你使用 ECDSA 驗證來計算根，並與 scriptpubkey 進行比較。它建立一個樹，其中葉子是腳本。然後你說，這是我正在執行的腳本，這是證明它已被承諾的默克爾分支。 + +討論了 MAST 的許多優點以及實作細節。 + +### 會議結論 + +MAST 依賴於 segwit 啟用。 + +## 子為父付費 + +子為父付費是一種透過建立另一個依賴於第一個交易的交易來為交易添加手續費的方法。 + +### 會議討論 + +拉取請求已經完成，可以進行審查。 + +### 會議結論 + +審查以下拉取請求 [\#7600](https://github.com/bitcoin/bitcoin/pull/7600) 和 [\#7598](https://github.com/bitcoin/bitcoin/pull/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][] | + +## 免責聲明 + +本摘要編寫時未徵詢部分討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-05-26-meeting.md b/_posts/zh_TW/meetings/2016-05-26-meeting.md new file mode 100644 index 000000000..b104dabeb --- /dev/null +++ b/_posts/zh_TW/meetings/2016-05-26-meeting.md @@ -0,0 +1,121 @@ +--- +title: IRC meeting summary for 2016-05-26 +permalink: /zh_TW/meetings/2016/05/26/ +name: 2016-05-26-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-05-26/?msg=66782849&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-26-19.06.html) + +--- + +## 主要議題 + +- Segwit 優先順序 + +## 註記 / 簡短議題 + +- 上週 [coredev 駭客活動](http://coredev.tech/)的記錄可以在[這裡](https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html)找到，這些註記的摘要在[這裡](https://bitcoincore.org/en/meetings/2016/05/20/)。 +- BIP 151 +- Child-Pays-For-Parent + + +## Segwit 優先順序 + +### 背景 + +開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議評論 + +網路堆疊重構和 libconsensus 重構都是長期重要的，但與隔離見證的程式碼衝突。儘管網路重構對緊湊區塊的影響比對 segwit 的影響更大，因為 segwit 的網路變更處於比網路重構更高的層級。 + +Libconsensus 重構在 0.10 中運作良好，因為有一個明確的目標和明確的做法，而進一步的努力大多是一個人的表演，如果我們希望這些變更發生，同意一個計劃是有意義的。 + +0.13 的功能凍結是在 2016-06-16，緊湊區塊最好能在 0.13 中以減輕額外的重播延遲。我們可以在沒有定義軟分叉的情況下合併 segwit，只是擁有程式碼，這使得在測試網上的測試更容易，並讓進一步的開發在其上進行，這樣其他工作就不會被 segwit 阻礙。 + +由於 segwit 已在測試網上啟動，segnet 將被放棄。 + +### 會議結論 + +- 僅合併 segwit 程式碼 + +## BIP 151 + +### 背景 + +比特幣網路今天不加密對等節點之間的通訊。這會帶來安全問題，並允許對比特幣使用者進行大規模監控/分析。對於 SPV 節點，這可能會產生[重大的隱私影響](http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf)，並可能降低對等節點的抗審查性。 + +加密對等節點流量將使分析和特定使用者定位比目前困難得多。今天，網路提供商或任何其他中間人識別比特幣使用者及其控制的地址/金鑰是微不足道的，因為新廣播的交易將向網路提供商揭示金額和收款人。 + +此 BIP 還描述了一種方式，可以讓通訊對等節點識別資料操縱（攔截 TCP/IP 節點阻止命令）。 + +由於加密訊息的特徵，分析 p2p 通訊的類型仍然是可能的。 + +### 會議評論 + +Petertodd 從密碼學家那裡獲得了一些回饋，他們擔心 BIP 151 不是現成的標準。[BIP151][] 完全使用 openssh 的 chacha20-poly1305，因此可能需要在 BIP 中更加突出。 + +### 會議結論 + +- 在 BIP 文字中更清楚地說明 [BIP151][] 使用 chacha20-poly1305 標準。 + +## Child-Pays-For-Parent + +### 背景 + +Suhas Daftuar 有一個 [pull request][#7600]，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child Pays For Parent (CPFP)。 + +### 會議評論 + +CreateNewBlock 所需的重構與 segwit 衝突，因此可能錯過 0.13。儘管每個人都希望盡快擁有它，因為這是一個長期討論的功能，但還沒有太多審查/測試。 + +### 會議結論 + +- 審查 PR [#7600][] + +## 娛樂時刻 + +{% highlight text %} +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. +{% endhighlight %} + +## 參與者 + +| 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][] | + + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7600]: https://github.com/bitcoin/bitcoin/pull/7600 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-06-02-meeting.md b/_posts/zh_TW/meetings/2016-06-02-meeting.md new file mode 100644 index 000000000..42bd1a2d3 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-06-02-meeting.md @@ -0,0 +1,131 @@ +--- +title: IRC meeting summary for 2016-06-02 +permalink: /zh_TW/meetings/2016/06/02/ +name: 2016-06-02-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-06-02/?msg=67171812&page=4) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.html) + +--- + +## 主要議題 + +- Segwit 審查 +- 緊湊區塊測試 +- CPFP 狀態和其他待處理的 pull request + +## 註記 / 簡短議題 + +沒有很多人對 0.11 的軟分叉反向移植感興趣，使用者對此也沒有太大興趣。[BIP68][] 的反向移植特別複雜，可能比根本不發布更危險。軟體生命週期頁面仍然承諾維護以前的版本，但 0.13 也很近，所以可能不是什麼大問題。 + +## Segwit 審查 + +### 背景 + +開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議評論 + +Sipa 計劃進行 BIP9/GBT 變更，移除 segnet 和正面見證標誌，然後建立一個具有清晰歷史記錄但導致相同樹的平行重新建立。正面見證標誌是一個標誌，表示您想要序列化見證。由於除了少數例外情況外，您幾乎總是想要序列化見證，所以最好有一個負面見證標誌。另一個原因是設定正面標誌的失敗通常不會被檢測到，但設定負面標誌的失敗會被檢測到。同時擁有兩個標誌也是一個選項，但會導致更多程式碼變更分散在各處。 + +由於您不希望使用者在推出之前擁有 segwit 地址，因此新的錢包程式碼可以在測試可以使用的隱藏設定選項後面引入。 + +jl2012 提出了我們的見證程式定義僅限於 16 個版本的問題，如果不引入新的見證儲存就不容易擴充。允許見證程式稍大一點的簡單解決方案與目前程式碼相比是硬分叉變更，這將導致測試網分叉，因為 segwit 已經在那裡啟動。由於可能發生的最糟糕的事情是測試網節點的重新索引，而 16 太少，sipa 將變更版本限制。 + +### 會議結論 + +- 審查 [#7749][]（執行預期的出站服務）和 [#8083][]（新增支援具有按服務位元過濾選項的 dnsseeds） +- 擴充最大見證程式長度 + +## 緊湊區塊測試 + +### 背景 + +[BIP152][]：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少 p2p 網路的區塊傳輸延遲。 + +### 會議評論 + +BlueMatt 建立了一個使用緊湊區塊和 UDP 網路區塊編碼內容的平行中繼網路，sipa 在 [shared_ptr 記憶體池變更][#8126]之上重新建立了 [TheblueMatt 的 PR][#8068]（可在[這裡](https://github.com/sipa/bitcoin/commits/compactblocks)取得）。包括一些大型礦工在內的許多人正在公共節點上執行這兩者。一切似乎都按預期工作，收集到的資料也是如此。 + +Gmaxwell 指出他應該採取行動設定一些已發布的地址，讓人們無需詢問即可連接。 + +### 會議結論 + +審查 PR [#8126][]（記憶體池中基於 std:shared_ptr 的 CTransaction 儲存）。 + +## CPFP 狀態和其他待處理的 pull request + +### 背景 + +Suhas Daftuar 有一個 pull request ([#7600][])，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child Pays For Parent (CPFP)。 + +### 會議評論 + +重構 CreateNewBlock 的 PR [#7598][] 是 [CPFP][#7600] 所需的 + +佇列中有很多 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 類別的方法） + +## 娛樂時刻 + +{% highlight text %} +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 :) +{% endhighlight %} + +## 參與者 + +| 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][] | + + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#7749]: https://github.com/bitcoin/bitcoin/pull/7749 +[#8083]: https://github.com/bitcoin/bitcoin/pull/8083 +[#8126]: https://github.com/bitcoin/bitcoin/pull/8126 +[#8068]: https://github.com/bitcoin/bitcoin/pull/8068 +[#7600]: https://github.com/bitcoin/bitcoin/pull/7600 +[#7598]: https://github.com/bitcoin/bitcoin/pull/7598 +[#7957]: https://github.com/bitcoin/bitcoin/pull/7957 +[#7948]: https://github.com/bitcoin/bitcoin/pull/7948 +[#7967]: https://github.com/bitcoin/bitcoin/pull/7967 +[#7997]: https://github.com/bitcoin/bitcoin/pull/7997 +[#7935]: https://github.com/bitcoin/bitcoin/pull/7935 +[#7946]: https://github.com/bitcoin/bitcoin/pull/7946 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-06-09-meeting.md b/_posts/zh_TW/meetings/2016-06-09-meeting.md new file mode 100644 index 000000000..6c94e0107 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-06-09-meeting.md @@ -0,0 +1,125 @@ +--- +title: IRC meeting summary for 2016-06-09 +permalink: /zh_TW/meetings/2016/06/09/ +name: 2016-06-09-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-06-09/?msg=67610017&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.html) + +--- + +## 主要議題 + +- 編譯時間 / 記憶體使用量 +- segwit 更新 +- 緊湊區塊測試 + +## 註記 / 簡短議題 + +- Bitcoin Core 的功能凍結[預定](https://github.com/bitcoin/bitcoin/issues/7679)在下週，所有需要合併的功能都應該在那之前合併。Cfields 有 2 個 p2p 重構 PR 他希望合併，這些可以在凍結後完成，因為那些不是新功能。 +- 在[上次會議的評論](https://bitcoincore.org/en/meetings/2016/06/02/#notes--short-topics)關於[軟體生命週期頁面](https://bitcoincore.org/en/lifecycle/)之後，Btcdrak 和 David Harding 一直在努力更新該頁面，使其更清晰和更具代表性，在[這裡](https://github.com/bitcoin-core/bitcoincore.org/pull/179)以及進一步在[這裡](https://github.com/btcdrak/bitcoincore.org/pull/2)，這需要審查。 + +## 編譯時間 / 記憶體使用量 + +### 背景 + +問題 [6658](https://github.com/bitcoin/bitcoin/issues/6658)（建置需要 >1GB 記憶體）和 [7471](https://github.com/bitcoin/bitcoin/issues/7471)（用 512 MB RAM 建置沒有太多空間）討論了編譯時對 RAM 的需求不斷增加。 + +### 會議評論 + +Gmaxwell 指出我們不能再使用預設設定在僅有 2GB RAM 的主機上編譯，而我們的文件說 1.5GB。 + +TheBlueMatt 準備了一個補丁，將所有記憶體池內容移出，顯然可以將其恢復到 1.5GB。但他還沒有提出 pull request。 + +Wumpus 指出使用 [Clang](https://en.wikipedia.org/wiki/Clang) 建置通常在相同編譯設定下使用的記憶體要少得多。 + +編譯時間可能與記憶體使用量相關，因為磁碟尋找/讀取存取可以忽略不計。 + +為 ARM 和 AARCH64 新增二進位建置將減少關於記憶體問題的抱怨。Cfields 正在致力於此。使用者目前可以使用[交叉編譯](https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#arm-cross-compilation)，但是 gmaxwell 指出許多使用類似 raspberry pi 系統的人沒有另一個 linux 主機。 + +### 會議結論 + +Cfields 計劃為 0.13 新增不帶 GUI 的 ARM 二進位檔案（會議後在 PR [#8188][] 中完成） + +## Segwit 更新 + +### 背景 + +開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議評論 + +在程式碼減去軟分叉可以進入 0.13 之前，仍有一些錯誤需要修復。Sipa 指出下一批補丁將解決所有問題。 + +Luke-jr 希望最大見證程式長度為 75 位元組，而不是現在的 40 位元組。他認為沒有必要限制（低於 75，因為高於 75 將需要更多變更和額外測試），較小的限制很可能會阻止未來的軟分叉。稍後擴充限制將需要硬分叉。Sipa 認為應該不需要超過 256 位元雜湊 + 一些版本控制中繼資料，設定更多會給人一種印象，或者正如 petertodd 所闡述的：會給人一種印象，比特幣比那更破碎。Gmaxwell 加入並認為他看到的最大危害是允許更大的大小可能會限制未來使 UTXO 條目大小受限的能力。但是進一步限制可以稍後發生。他還指出將來可以透過使用不同的版本類型信號來擴充這一點，但這將需要除了當前承諾之外的新承諾。 + +### 會議結論 + +討論繼續，並被推遲到會議外。 + +## 緊湊區塊測試 + +### 背景 + +[BIP152][]：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。 + +### 會議評論 + +公共網路上有許多節點執行緊湊區塊，一切似乎運作良好。Instagibbs 製作了一個[圖表](http://imgur.com/iq2lRGl)。Gmaxwell 一直在執行修改版本的測試，將雜湊大小減少到 16 位元，透過使碰撞更常見來測試圍繞碰撞的罕見邊緣情況。兩個大型礦池一直在執行它，其中一個位於中國的防火長城後面。 + +Cfields 想知道是否討論過緊湊區塊的服務位元。之前提出的論點是服務位元應該僅用於關鍵所需的服務。由於它可能會足夠快地變得普遍，所以不需要。只有礦工才真正需要它，但他們無論如何都應該手動管理他們的連接。 + +### 會議結論 + +- 與區塊擷取邏輯的互動需要更多審查。 +- 審查者應該停止使用 sipa 的分支，因為 PR [#8068][] 已在 [shared_ptr 工作][#8126] 之上重新建立。 +- 審查 PR [#8084][]（將最近接受的區塊和交易新增到 AttemptToEvictConnection） + +## 娛樂時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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 | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#8188]: https://github.com/bitcoin/bitcoin/pull/8188 +[#8068]: https://github.com/bitcoin/bitcoin/pull/8068 +[#8126]: https://github.com/bitcoin/bitcoin/pull/8126 +[#8084]: https://github.com/bitcoin/bitcoin/pull/8084 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-06-16-meeting.md b/_posts/zh_TW/meetings/2016-06-16-meeting.md new file mode 100644 index 000000000..6a97f9437 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-06-16-meeting.md @@ -0,0 +1,116 @@ +--- +title: IRC meeting summary for 2016-06-16 +permalink: /zh_TW/meetings/2016/06/16/ +name: 2016-06-16-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-06-16/?msg=68050508&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.html) + +--- + +## 主要議題 + +- 緊湊區塊和功能凍結 +- Segwit 更新 +- 0.13 中的 RBF 替換 +- GetBlockTemplate (GBT) + +## 緊湊區塊和功能凍結 + +### 背景 + +[BIP152][]：「緊湊區塊中繼」是一個提議的想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。閱讀[緊湊區塊常見問題解答](https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/)以獲取更多資訊。 + +### 會議評論 + +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 常見問題解答頁面](https://bitcoincore.org/en/faq/optin_rbf/)上找到。目前 bitcoin-core 錢包不提供任何使用這些功能的功能。 + +### 會議評論 + +Jonasschnelli 認為我們應該在 0.13 中為錢包提供替換選項。他希望對 PR [#8182][] 進行審查，這是一個 GUI bumpfee 命令。每個人都希望看到費用提升選項，但現在已經很晚了，將緊湊區塊和 segwit 合併可能已經足夠擔心下週了。 + +Petertodd 建議至少將他的[全域選擇性設定][#7132]合併，這樣需要 RBF 的人可以輕鬆使用外部腳本來實現。 + +### 會議結論 + +- 審查 PR [#7132][] + +## GetBlockTemplate (GBT) + +### 背景 + +Getblocktemplate 是新的去中心化比特幣挖礦協議，由比特幣社群在 2012 年中期公開開發。它取代了舊的 getwork 挖礦協議。（[Wiki](https://en.bitcoin.it/wiki/Getblocktemplate)-連結） + +### 會議評論 + +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][] | + + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。 + +[#8149]: https://github.com/bitcoin/bitcoin/pull/8149 +[#7132]: https://github.com/bitcoin/bitcoin/pull/7132 +[#8182]: https://github.com/bitcoin/bitcoin/pull/8182 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-06-23-meeting.md b/_posts/zh_TW/meetings/2016-06-23-meeting.md new file mode 100644 index 000000000..d40cb307e --- /dev/null +++ b/_posts/zh_TW/meetings/2016-06-23-meeting.md @@ -0,0 +1,100 @@ +--- +title: IRC meeting summary for 2016-06-23 +permalink: /zh_TW/meetings/2016/06/23/ +name: 2016-06-23-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-06-23/?msg=68482305&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.html) + +--- + +## 主要議題 + +- 感知到的驗證速度減緩 +- 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）允許將交易簽名資料儲存在用於產生交易識別碼的雜湊資料之外，移除所有已知形式的第三方延展性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，使輕量級（SPV）客戶端能夠協助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替代 1 位元組的區塊空間，為使用 segwit 的錢包增加交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議討論 + +Segwit 在合併 compact blocks 後已重新基底。 + +Sipa 一直在執行 compact blocks + segwit，沒有看到對記憶體使用的影響。 + +所有人都贊成合併 segwit。（會議後已合併） + +Gmaxwell 建議我們應該立即發布「測試網二進位檔」，預設啟用測試網，以讓更多人進行測試。到目前為止，segwit 測試主要由技術人員完成，他們不太可能被 UI 狀態變更等問題困擾。 + +在測試網上啟動 segwit 是一個非常有用的測試演練，因為它是在大多數節點未升級的環境中進行的。 + +### 會議結論 + +- 合併 segwit +- 發布預設/僅限測試網的二進位檔 + +## 趣味環節 + +{% highlight text %} +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 +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-06-30-meeting.md b/_posts/zh_TW/meetings/2016-06-30-meeting.md new file mode 100644 index 000000000..58bcfdcd5 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-06-30-meeting.md @@ -0,0 +1,121 @@ +--- +title: IRC meeting summary for 2016-06-30 +permalink: /zh_TW/meetings/2016/06/30/ +name: 2016-06-30-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-06-30/?msg=68899079&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.html) + +--- + +## 筆記 / 簡短議題 + +- 許多人正在測試網上測試 segwit + [BIP152][]。目前還沒有相關的 PR，因為這允許測試與非 segwit-BIP152 的互動，並且需要一些 BIP 變更（在 [BIP144][]、[BIP152][] 或單獨的 BIP 中）。最好在 segwit 啟動之前就準備好，否則 compact blocks 會突然停用。 + +## 主要議題 + +- 0.13.0 的挖礦相關變更 +- Segwit +- Dbcache + +## 0.13.0 的挖礦相關變更 + +### 背景 + +Sdaftuar 在一個[議題](https://github.com/bitcoin/bitcoin/issues/8294)中提到了一些他認為應該在 0.13.0 中解決的挖礦相關事項。PR [#8295][] 被建立來解決這些問題。 + +### 會議討論 + +Blockminsize（設定最小區塊大小）不受 segwit 的封包選擇程式碼支援。由於這個功能對任何人都不再相關，移除它是合理的。目前保留 blockminsize 和 blockmaxsize 的原因是新演算法因缺少會計而無法運作。Sdaftuar 指出這在 [#8295][] 的第一個提交中已解決。當給定 blockminsize 參數時，不應導致失敗，而應給出警告。 + +AddScoreTxs，舊的交易選擇演算法，可以被移除，因為新的封包選擇演算法絕對優越。Sdaftuar 指出如果我們這樣做，mining_score 可以從記憶體池 multiIndex 中移除，這將在記憶體池中節省一些記憶體。然而這不是優先事項，可以等到 0.14。 + +發布說明需要為所有挖礦變更撰寫大量內容。 + +### 會議結論 + +- 移除 -blockminsize 並在給定該參數時發出警告 +- 更新發布說明中的挖礦變更 + +## Segwit + +### 背景 + +開發者正在開發軟分叉以將隔離見證引入比特幣主網。隔離見證（segwit）允許將交易簽名資料儲存在用於產生交易識別碼的雜湊資料之外，移除所有已知形式的第三方延展性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，使輕量級（SPV）客戶端能夠協助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替代 1 位元組的區塊空間，為使用 segwit 的錢包增加交易容量。隔離見證 BIP：[BIP141][]、[BIP142][]、[BIP143][]、[BIP144][] 和 [BIP145][] + +### 會議討論 + +在他的[審查](https://petertodd.org/2016/segwit-consensus-critical-code-review)期間，petertodd 發現了由於延展交易造成的潛在記憶體池 DoS 風險（[議題 8279](https://github.com/bitcoin/bitcoin/issues/8279)）。 + +Gmaxwell 提議在驅逐保護邏輯中將低 dos 分數作為排名標準，這將使以非常高的 DoS 閾值執行更加合理。Sipa 指出如果進行這些變更，DoS 分數也應該隨時間衰減，否則較長時間的連線將累積它們不應得的分數。 + +Petertodd 希望看到某些節點有不同的閾值期間，這樣雖然不會在所有人身上浪費頻寬，但仍然保持與少數對等節點的連線。Gmaxwell 指出這樣的事情可以將這些對等節點轉變為僅區塊模式，因為這是我們關心的反分區所需的全部，並且幾乎完全消除了 DoS 的擔憂。 + +Sipa 認為可能有理由引入類似「資源使用分數」的東西，它與「不當行為」不同，用於決定斷開哪些對等節點以支持其他節點，但永遠不會導致封禁。 + +Gmaxwell 指出 bitcoinXT 最近開始僅與其他 XT 節點建立出站連線，這與 segwit 結合將使它們分區。已在 XT 儲存庫中為此建立了議題。 + +### 會議結論 + +- 腦力激盪連線管理相關事項 + +## Dbcache + +### 背景 + +Gmaxwell 在使用預設 dbcache 進行測試時注意到重新索引非常緩慢，sipa 也確認了這點，他看到了類似的行為。這在[上週的會議](/zh_TW/meetings/2016/06/23/#感知到的驗證速度減緩)中提出。 + +### 會議討論 + +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 每隔幾分鐘就會停止他的節點。他為此建立了一個[議題](https://github.com/bitcoin/bitcoin/issues/8297)。 + +### 會議結論 + +- 進一步的基準測試 + +## 趣味環節 + +{% highlight text %} +gmaxwell + +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. +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8295]: https://github.com/bitcoin/bitcoin/pull/8295 +[#8273]: https://github.com/bitcoin/bitcoin/pull/8273 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-07-07-meeting.md b/_posts/zh_TW/meetings/2016-07-07-meeting.md new file mode 100644 index 000000000..47297b820 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-07-07-meeting.md @@ -0,0 +1,108 @@ +--- +title: IRC meeting summary for 2016-07-07 +permalink: /zh_TW/meetings/2016/07/07/ +name: 2016-07-07-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-07-07/?msg=69273712&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.html) + +--- + +## 筆記 / 簡短議題 + +Gmaxwell 指出他仍希望在 RC 期間看到獨立的測試網預設二進位檔。Wumpus 指向他錯過的一個 [PR][#8285]，該 PR 使安裝測試網客戶端變得非常容易。 + +## 主要議題 + +- 0.13.0 rc1 與 HD 錢包議題 +- FIBRE 公告 + +## 0.13.0 rc1 + +### 背景 + +Bitcoin Core 團隊正在朝 0.13.0 RC1 努力。（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)） + +### 會議討論 + +有幾個[議題](https://github.com/bitcoin/bitcoin/milestone/20)需要為 0.13.0 修復。Wumpus 無法建構發布版本，因為 gitian lxc 建構已損壞，如[此議題](https://github.com/bitcoin/bitcoin/issues/8212)所述（會議後一天找到了[解決方法][#8315]）。對於 0.14，我們可以切換到 ubuntu 16.04，該版本已修復此問題。 + +Sdaftuar 有一些針對 0.13.0 的 PR 開放，缺乏一些審查，即 [#8305][]（headers 同步議題）、[#8312][]（segwit 合併後的記憶體池 DoS）和 [#8295][]（segwit 合併後的挖礦程式碼修復）。 + +在測試新的階層式確定性（HD）錢包時，MarcoFalke 遇到了問題。要麼是他的[測試程式碼][#8309]中的錯誤，要麼是 IsMine() 的問題。如果沒有明確的答案解釋為什麼會發生這個問題，最好在 0.13 中停用 HD 錢包。 + +在會議結束前，Jonasschnelli 已經在 MarcoFalke 的測試程式碼中找到了錯誤。修復的測試將包含在 0.13.0 中。 + +### 會議結論 + +- 審查 0.13.0 的[開放議題](https://github.com/bitcoin/bitcoin/milestone/20) +- 為 sdaftuar 的 PR 加上 0.13.0 里程碑標籤 + +## FIBRE 公告 + +### 背景 + +Matt Corrallo [宣布](http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/)了他的新中繼網路工作，使用 UDP 和 FEC，目前尚未完全成熟的軟體在 99% 的時間內能在光纖路徑距離上實現不到 100 毫秒的全球區塊傳播。 + +更多資訊可以在網站 [http://bitcoinfibre.org/](http://bitcoinfibre.org/) 上找到。 + +### 會議討論 + +在他的部署中，他只使用便宜的 VPS。他正試圖讓其他人建立平行網路並提供詳盡的指南，包括獲得亞洲和歐洲之間低延遲連線的途徑。 + +連結：[github 專案](https://github.com/bitcoinfibre)和[中繼網路統計](http://bitcoinfibre.org/stats_ng.html) + +## 趣味環節 + +{% highlight text %} + +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! +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8315]: https://github.com/bitcoin/bitcoin/pull/8315 +[#8305]: https://github.com/bitcoin/bitcoin/pull/8305 +[#8312]: https://github.com/bitcoin/bitcoin/pull/8312 +[#8295]: https://github.com/bitcoin/bitcoin/pull/8295 +[#8309]: https://github.com/bitcoin/bitcoin/pull/8309 +[#8285]: https://github.com/bitcoin/bitcoin/pull/8285 +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-07-14-meeting.md b/_posts/zh_TW/meetings/2016-07-14-meeting.md new file mode 100644 index 000000000..c350ac518 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-07-14-meeting.md @@ -0,0 +1,110 @@ +--- +title: IRC meeting summary for 2016-07-14 +permalink: /zh_TW/meetings/2016/07/14/ +name: 2016-07-14-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-07-14/?msg=69652623&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.html) + +--- + +## 筆記 / 簡短議題 + +- 需要更好的 -blockmaxcost 選項文件，但有人指出這是一個糟糕的名稱，因為使用者認為「最大成本」是關於貨幣成本。翻譯人員也以這種方式翻譯它。「區塊成本」一詞也用於 [segwit BIP][BIP141] 中，sdaftuar 提議變更 BIP 中的描述。與會者同意將 blockmaxcost 重新命名為 blockmaxweight。 +- Gmaxwell 指出他在 reddit 上收到一些回覆，指出 bitcoin core 的錢包對商業用途無法使用，大多數人使用集中式 API 提供商。不幸的是，商業使用者通常不會報告他們遇到的問題，他不知道如何改善這一點。 +- Bsm117532 詢問是否有人正在進行移除「帳戶」的工作。Wumpus 嘗試為 0.13 [引入][#7729]標籤 API 來取代它，但沒有獲得足夠的審查。 + +## 主要議題 + +- 0.13.0 rc1 +- Segwit 反向移植 + +## 0.13.0 rc1 + +### 背景 + +Bitcoin Core 團隊正在朝 0.13.0 RC1 努力。（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)） + +### 會議討論 + +大多數剩餘的 pull request 已合併，但仍有一些需要為 0.13.0 修復的[開放 PR](https://github.com/bitcoin/bitcoin/milestone/20)。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 反向移植發布之前等待使用者回饋。 + +## 趣味環節 + +{% highlight text %} + well, any reason not use vsize? + sipa: vsize is fine + yes vsize is fine + V means validation? + virtual + v for vendetta +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8323]: https://github.com/bitcoin/bitcoin/pull/8323 +[#8305]: https://github.com/bitcoin/bitcoin/pull/8305 +[#7729]: https://github.com/bitcoin/bitcoin/pull/7729 +[#8295]: https://github.com/bitcoin/bitcoin/pull/8295 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-07-21-meeting.md b/_posts/zh_TW/meetings/2016-07-21-meeting.md new file mode 100644 index 000000000..ca2349bce --- /dev/null +++ b/_posts/zh_TW/meetings/2016-07-21-meeting.md @@ -0,0 +1,131 @@ +--- +title: IRC meeting summary for 2016-07-21 +permalink: /zh_TW/meetings/2016/07/21/ +name: 2016-07-21-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-07-21/?msg=70044352&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.html) + +--- + +## 筆記 / 簡短議題 + +- 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 發布版本努力（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)），RC1 自 2016-07-20 起[可用](https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc1/)。 + +### 會議討論 + +RC1 收到了一些[回饋](https://github.com/bitcoin/bitcoin/issues/8383)，注意到在加密錢包時，它使用相同的 HD 種子，這意味著在建立錢包時 HD 種子已經未加密地存在磁碟上。Jonasschnelli 正在進行[修復][#8389]，在加密錢包後建立新的 HD 種子。 + +一個常見的抱怨是缺乏匯出 HD 種子的方法。Jonasschnelli 有一個[pull request][#8206]，易於審查且影響較低，將種子匯出到 dumpwallet。匯入是一個不同的問題，影響更大，因為錢包目前不支援多個種子。這是 0.14 的功能。 + +Luke-jr 指出新的預設策略使用 blockmaxweight 在當前環境中的表現不如使用 blockmaxsize。他做了一個 [pull request][#8388] 來改變這一點。這是一個相當大的變更，需要更多討論。 + +### 會議結論 + +- 審查 PR [#8206][] + +## 移除 ISM + +### 背景 + +在 [BIP9][] 之前，軟分叉是透過 isSuperMajority（ISM）機制完成的，意思是當最後 1000 個區塊中的 95% 的版本號高於 X 時，分叉就會部署。[BIP68][]、[BIP112][] 和 [BIP113][] 同時使用 [BIP9][] 部署。 + +### 會議討論 + +NicolasDorier 做了一個 [pull request][#8391] 來移除 ISM 並在 regtest 中硬編碼由 ISM 產生的軟分叉。 + +Gmaxwell 想在 0.13 中移除 ISM，但不想引入與 segwit 合併的衝突，所以他擱置了它。 + +討論很快偏離到與重構相關的議題。 + +### 會議結論 + +- 審查 PR[#8391][] +- 在重構其程式碼之前移除 ISM + +## sigops 最大大小和每位元組 sigops 限制 + +### 背景 + +為了防止簽名操作（SIGOPS）[攻擊](https://bitcointalk.org/index.php?topic=1166928.0)，開發者[引入][#7081]了 bytespersigop 選項來限制我們中繼和挖掘的交易中的 sigops 數量。這在 [2015-11-05 會議](/zh_TW/meetings/2015/11/05/#sigops-flooding-attack)中討論過。 + +有人[抱怨](https://github.com/bitcoin/bitcoin/issues/8079)這個限制使得一些裸多簽輸出難以花費。 + +### 會議討論 + +對此有兩個提議的解決方案：一個由 [sipa][#8365] 提出，一個由 [f139975][#8364] 提出。Sipa 認為後者使其變得不必要地複雜，但除此之外並不強烈反對。 + +Luke-jr 認為引入限制的原因是為了過濾垃圾訊息，允許高 sigops 交易但收取高額費用等於隱含地認可不必要地使用大量 sigops。Gmaxwell 不同意，並表示他不會支援為了過濾目的而設定的限制。目前為了繞過限制，他們膨脹交易以獲得更多 sigops，PR [#8365][] 將修復這一點，sdaftuar 認為我們可以在長遠考慮更好的策略。 + +隨後進行了一些討論，關於這些交易是否應該被視為垃圾訊息。 + +### 會議結論 + +查看 PR [#8364][] 和 [#8365][] + +## 趣味環節 + +{% highlight text %} +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 +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8389]: https://github.com/bitcoin/bitcoin/pull/8389 +[#8206]: https://github.com/bitcoin/bitcoin/pull/8206 +[#8391]: https://github.com/bitcoin/bitcoin/pull/8391 +[#6793]: https://github.com/bitcoin/bitcoin/pull/6793 +[#8356]: https://github.com/bitcoin/bitcoin/pull/8356 +[#7081]: https://github.com/bitcoin/bitcoin/pull/7081 +[#8364]: https://github.com/bitcoin/bitcoin/pull/8364 +[#8365]: https://github.com/bitcoin/bitcoin/pull/8365 +[#8388]: https://github.com/bitcoin/bitcoin/pull/8388 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-07-28-meeting.md b/_posts/zh_TW/meetings/2016-07-28-meeting.md new file mode 100644 index 000000000..2a1351a4e --- /dev/null +++ b/_posts/zh_TW/meetings/2016-07-28-meeting.md @@ -0,0 +1,106 @@ +--- +title: IRC meeting summary for 2016-07-28 +permalink: /zh_TW/meetings/2016/07/28/ +name: 2016-07-28-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-07-28/?msg=70411862&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.html) + +--- + +## 筆記 / 簡短議題 + +- Jtimon 希望看到[上週會議](/zh_TW/meetings/2016/07/21/#移除-ism)中討論的 [ISM 移除][#8391]能快速合併，因為它對其他 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 發布版本努力（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)），RC2 自 2016-07-31（會議後 3 天）起[可用](https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc2/)。 + +### 會議討論 + +PR [#8408][]，修復 compactblocks 中的錯誤，是唯一剩下的標記為 0.13 的事項。 + +Jtimon 做了 PR [#8412][]，他認為應該包含在 0.13 中。所有人都同意。 + +Luke-jr 重申發布說明有一個不良策略，鼓勵將 blockmaxsize 變更為 blockmaxweight，他為此有一個 [pull request][#8388]，包括一些程式碼變更。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][#8023] 來擺脫 boost threads。 + +### 會議討論 + +Cfields 詢問他應該一次做一個替換，還是一次全部完成。Wumpus 表示一次全部完成最有意義，使其成為一次性的痛苦。 + +[#8023][] 有一個先決條件，他將在會議後為此做一個 [pull request][#8421]。 + +Cfields 也仍在進行網路重構，審查/ACK PR [#8128][] 和 [#8085][] 將有所幫助。 + +### 會議結論 + +審查 PR [#8128][] 和 [#8085][]（"Net: Turn net structures into dumb storage classes" & "p2p: Begin encapsulation"） + +## 趣味環節 + +{% highlight text %} +lightningbot Meeting ended Thu Jul 28 20:00:26 2016 UTC. +jonasschnelli sipa: time for your Pokemon walk. :P +{% endhighlight %} + +## 與會者 + +| 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_ | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8408]: https://github.com/bitcoin/bitcoin/pull/8408 +[#8412]: https://github.com/bitcoin/bitcoin/pull/8412 +[#8388]: https://github.com/bitcoin/bitcoin/pull/8388 +[#8391]: https://github.com/bitcoin/bitcoin/pull/8391 +[#8023]: https://github.com/bitcoin/bitcoin/pull/8023 +[#8128]: https://github.com/bitcoin/bitcoin/pull/8128 +[#8085]: https://github.com/bitcoin/bitcoin/pull/8085 +[#8422]: https://github.com/bitcoin/bitcoin/pull/8422 +[#8421]: https://github.com/bitcoin/bitcoin/pull/8421 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-08-04-meeting.md b/_posts/zh_TW/meetings/2016-08-04-meeting.md new file mode 100644 index 000000000..3000e3555 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-08-04-meeting.md @@ -0,0 +1,93 @@ +--- +title: IRC meeting summary for 2016-08-04 +permalink: /zh_TW/meetings/2016/08/04/ +name: 2016-08-04-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-08-04/?msg=70789770&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.html) + +--- + +## 筆記 / 簡短議題 + +- 幾位開發者和礦工在舊金山見面，他們前往史丹佛大學會見應用密碼學和電腦安全研究員 Dan Boneh。雖然與短期開發無關，但由 kanzure 製作的[文字記錄](http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/)具有非常高的訊噪比。 +- NicolasDorier 建立了一個 IRC ##libconsensus bikeshedding 聊天室，討論如何處理 libconsensus。設計將呈現給更大的群體以獲得回饋。 + +## 主要議題 + +- 0.13.0 +- segwit 記憶體池延展性 DoS + +## 0.13.0 + +### 背景 + +Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)），RC2 自 2016-07-31 起[可用](https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc2/)。 + +### 會議討論 + +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](https://github.com/bitcoin/bitcoin/issues/8279) 中進一步討論。 + +### 會議討論 + +Sipa 更傾向移除「無效見證不會導致插入拒絕快取」規則，理由是它所做的只是防止攻擊者向你隱藏有效交易，但它並不能完全防止，因為他們可以宣布但永遠不發送交易。 + +Bluematt 想知道對於 segwit 節點使用 txid 而不是 wtxid 進行 [inv'ing](https://en.bitcoin.it/wiki/Protocol_documentation#inv) 的理由是什麼。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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8438]: https://github.com/bitcoin/bitcoin/pull/8438 +[#8365]: https://github.com/bitcoin/bitcoin/pull/8365 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-08-11-meeting.md b/_posts/zh_TW/meetings/2016-08-11-meeting.md new file mode 100644 index 000000000..4ea0d9724 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-08-11-meeting.md @@ -0,0 +1,101 @@ +--- +title: IRC meeting summary for 2016-08-11 +permalink: /zh_TW/meetings/2016/08/11/ +name: 2016-08-11-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-08-11/?msg=71169405&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-11-18.59.html) + +--- + +## 筆記 / 簡短議題 + +- 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 + +### 背景 + +延展性的一個來源是 ECDSA 簽名中的 'S' 值，它可以有兩個值，一個高值和一個低值。去年引入了一項策略，要求節點使用 low-s 值（在 [2015-10-08 會議](/zh_TW/meetings/2015/10/08/#low-s-change)中討論）。Sipa 現在提議將其作為共識規則，而不僅僅是策略。 + +### 會議討論 + +High-s 交易已經長期不符合標準，並且超過一年沒有出現在網路上。由於這不具爭議性且易於實施（一行程式碼），主要問題是與 segwit 同時部署還是分開部署。Sipa 認為作為單獨的軟分叉可能很難做到這一點，因為它的收益很低，而礦工仍需要更新他們的軟體。GreenIsMyPepper 和 sipa 指出在 segwit 中永遠不要有 high-s 值會更乾淨。 + +### 會議結論 + +- 將 low-s 規則的執行與 segwit 結合在一起。 + +## 0.13.0 RC3 + +### 背景 + +Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)），RC3 自 2016-08-13 起[可用](https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc3/)。 + +### 會議討論 + +Wumpus 想知道是否還有任何需要合併/反向移植到 0.13.0 的內容。 + +Luke-jr 想要做一個 PR 來[在 segwit 未啟動時將 blockmaxsize 對應到 blockmaxweight](https://github.com/bitcoin/bitcoin/commit/5a716a3bc6621e4d2e2c1de5b6b5596d6877d589)，以使 PR [#8459][] 不具爭議性。 + +有一個關於 0.13.0 的[部落格文章 PR](https://github.com/bitcoin-core/bitcoincore.org/pull/199)，可以使用審查。 + +Cfields 想知道是否應該在 0.13.0 中將 default_witness_commitment 添加到帶有見證資料的 GBT 中。Sipa 認為 0.13.0 上的礦工永遠不應該產生 segwit 承諾，這樣我們就不會在遠離更新軟體的時間點出現突然的行為變更，這可能會破壞下游挖礦基礎設施，gmaxwell 補充說。 + +### 會議結論 + +- 審查[部落格文章](https://github.com/bitcoin-core/bitcoincore.org/pull/199) + +## 趣味環節 + +{% highlight text %} +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 +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8493]: https://github.com/bitcoin/bitcoin/pull/8493 +[#8499]: https://github.com/bitcoin/bitcoin/pull/8499 +[#8459]: https://github.com/bitcoin/bitcoin/pull/8459 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-08-18-meeting.md b/_posts/zh_TW/meetings/2016-08-18-meeting.md new file mode 100644 index 000000000..0dcea3222 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-08-18-meeting.md @@ -0,0 +1,126 @@ +--- +title: IRC meeting summary for 2016-08-18 +permalink: /zh_TW/meetings/2016/08/18/ +name: 2016-08-18-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-08-18/?msg=71545121&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.html) + +--- + +## 筆記 / 簡短議題 + +- Bitcoin Core 的二進位發布版本仍然以「The Bitcoin Foundation」的名義簽名。Jonasschnelli 想知道我們是否應該嘗試以「Bitcoin Core」的名義獲得新證書。Cfields 正在調查此事，但沒有任何進展。他最好的建議是看看 MIT 是否有興趣協助獲得證書。 + +## 主要議題 + +- core 內部二進位簽名和驗證工具 +- 0.13.0 正式版 + +## core 內部二進位簽名和驗證工具 + +### 背景 + +在 Cobra-Bitcoin 在 bitcoin.org 網站上發布[安全警告](https://bitcoin.org/en/alert/2016-08-17-binary-safety)後，更多人詢問如何安全驗證 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](https://groups.google.com/forum/#!forum/binary-transparency)）Wumpus 指出這不能解決使用者根本不驗證二進位檔的問題，除非作業系統內建對它的支援。 + +### 會議結論 + +- Jonasschnelli 將制定一個簡短的設計並將其發布到 bitcoin-core-dev 郵件列表。 +- 開始在發布公告中添加 sha256 雜湊，因為這將確保雜湊的更廣泛分發。 + +## 0.13.0 正式版 + +### 背景 + +Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（[完整時程表](https://github.com/bitcoin/bitcoin/issues/7679)），RC3 自 2016-08-13 起[可用](https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc3/)。 + +### 會議討論 + +RC3 沒有報告嚴重問題，所以現在可以隨時標記為正式版。 + +MarcoFalke 在測試網上遇到了[問題](https://github.com/bitcoin/bitcoin/issues/8518)，這可能是發布阻礙。（會議後檢測到問題，並認為不是發布阻礙） + +Gitian 建構可以在週末開始。 + +鑑於 0.13.0 延遲，Wumpus 想知道我們是否應該延遲設定 0.14 發布時程表。每個人都同意目前的 6 個月時程表很好，0.14 應該在 0.13.0 發布後立即安排。 + +### 會議結論 + +- 審查 bitcoincore.org 上的 [0.13.0 部落格文章](https://github.com/bitcoin-core/bitcoincore.org/pull/199) +- 開始 gitian 建構 + +## BIP146 + +### 背景 + +[BIP146][]：處理簽名延展性。LOW_S 和 NULLDUMMY 長期以來在網路上一直不符合標準，並且不出現在鏈上。由於它們都很簡單，[BIP146][] 提議與 segwit 一起執行此軟分叉。Low_S 在[上週會議](/zh_TW/meetings/2016/08/11/#軟分叉以要求-low-s)中討論過。 + +### 會議討論 + +BIP 提案已發送至[郵件列表](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013006.html) +（正式會議時間後：）Bluematt 仍然執行一個節點，該節點自動將 high-s 交易延展為 low-s，他仍然收到很多 high-s 交易（約每小時 1 筆）。不過這也可能是有人將原本的 low-s 交易延展的。 + +### 會議結論 + +- 將 [BIP146][] 與 segwit 一起執行 + +## 趣味環節 + +{% highlight text %} +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 :) +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-08-25-meeting.md b/_posts/zh_TW/meetings/2016-08-25-meeting.md new file mode 100644 index 000000000..73810e35c --- /dev/null +++ b/_posts/zh_TW/meetings/2016-08-25-meeting.md @@ -0,0 +1,109 @@ +--- +title: IRC meeting summary for 2016-08-25 +permalink: /zh_TW/meetings/2016/08/25/ +name: 2016-08-25-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-08-25/?msg=71945213&page=5) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.html) + +--- + +## 筆記 / 簡短議題 + +- Paveljanik 要求對他的 Wshadow PR 進行更多審查/ACK：PR[#8191][]、PR[#8449][]、PR[#8466][]、PR[#8468][] 和 PR[#8472][] +- Bitcoin Core 0.13.0 已[發布](/zh_TW/releases/0.13.0/)。 +- 有一個[提案](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html)為硬體錢包執行分離簽名制定標準，這將允許將金鑰與錢包解耦。這是為了結束目前由錢包和硬體錢包供應商實施的 API/介面的混亂局面。 + +## 主要議題 + +- segwit DoS 保護提案 +- 程式碼簽名 + +## segwit DoS 保護提案 + +### 背景 + +在審查 segwit 時，petertodd 注意到攻擊者可能能夠透過發送具有延展見證資料的交易來使節點對交易視而不見。在議題 [#8279](https://github.com/bitcoin/bitcoin/issues/8279) 中進一步討論。 + +### 會議討論 + +已經提出了幾種解決方案，包括：驗證所有輸入（即使交易太大或低於費率），不將失敗的見證交易輸入拒絕表，強制使用 feefilter 等。 + +Gmaxwell 認為所有這些變更都是有益的，驗證所有輸入甚至是在 segwit 被構想之前的提案，我們沒有進行該變更的主要原因是因為即使從合作的對等節點也有很多被拒絕的內容。這應該透過 [feefilter][BIP133] 解決。 + +作為驗證所有內容的替代方案，jl2012 建議隨機驗證某個百分比，因為它允許你拒絕向你發送垃圾訊息的對等節點，但你只承擔一小部分成本。 + +### 會議結論 + +- PR[#8525][]：Do not store witness txn in rejection cache +- PR[#8593][]：Verify all incoming txs unless too big or too much hashing + +## 程式碼簽名 + +### 背景 + +[上週會議](/zh_TW/meetings/2016/08/18/#core-內部二進位簽名和驗證工具)討論了簽名和驗證 Bitcoin Core 二進位檔的多種安全增強功能。 + +### 會議討論 + +Cfields 一直在開發一個從 linux 執行的 [OSX 程式碼簽名工具](https://github.com/theuni/osx-codesign)，因此發布流程不再需要 OSX 機器。他想知道在像以前一樣實施之前，是否有人對更複雜/分散式的簽名方案有建議。Gmaxwell 希望看看是否容易將多方簽名整合到其中。 + +Codeshark 想知道 4096 位元 RSA 而不是 2048 位元是否過度。2048 位元大約相當於 128 位元 ECDSA。4096 會更好，因為大小和效能基本上無關緊要，但金鑰的參數由 Apple 選擇。 + +### 會議結論 + +- Gmaxwell 和 sipa 將研究 2048 位元 RSA 的閾值簽名，看看我們是否能做到沒有單一方持有該金鑰。 +- Cfields 將嘗試找出是否可能使用 2048 位元 RSA 以外的其他簽名類型（如 4096 位元金鑰）。 + +## 趣味環節 + +{% highlight text %} +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 +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8191]: https://github.com/bitcoin/bitcoin/pull/8191 +[#8449]: https://github.com/bitcoin/bitcoin/pull/8449 +[#8466]: https://github.com/bitcoin/bitcoin/pull/8466 +[#8468]: https://github.com/bitcoin/bitcoin/pull/8468 +[#8472]: https://github.com/bitcoin/bitcoin/pull/8472 +[#8593]: https://github.com/bitcoin/bitcoin/pull/8593 +[#8525]: https://github.com/bitcoin/bitcoin/pull/8525 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-09-01-meeting.md b/_posts/zh_TW/meetings/2016-09-01-meeting.md new file mode 100644 index 000000000..92e42cb86 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-09-01-meeting.md @@ -0,0 +1,115 @@ +--- +title: IRC meeting summary for 2016-09-01 +permalink: /zh_TW/meetings/2016/09/01/ +name: 2016-09-01-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-09-01/?msg=72346265&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.html) + +--- + +## 筆記 / 簡短議題 + +- 0.13 部署似乎沒有遇到問題 +- Travis 報告了一些議題（[8532](https://github.com/bitcoin/bitcoin/issues/8532)、[8425](https://github.com/bitcoin/bitcoin/issues/8425)、[8429](https://github.com/bitcoin/bitcoin/issues/8429)）。似乎是 Travis 基礎設施造成了一些失敗。fields 還解釋了一個競爭條件：「那裡的問題是節點高度是同步的，但錢包不一定已經更新它們的交易。所以 sync_all() 後跟餘額檢查是有競爭條件的。」 + +## 主要議題 + +- 剩餘的 0.13.1 議題 +- nulldummy 和 low_s 軟分叉提案 + +## 剩餘的 0.13.1 議題 + +### 背景 + +Bitcoin Core 0.13.0 於 2016/08/23 [發布](/zh_TW/releases/0.13.0/)。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。 + +### 會議討論 + +有很多標記為 0.13.1 的 pull request。Wumpus 想知道是否有任何應該優先審查的，因為其中一些有衝突。PR[#8393][]（Support for compact blocks together with segwit）是阻礙項，以及在 [2016/08/04](/zh_TW/meetings/2016/08/04/#segwit-記憶體池延展性-dos) 和 [2016/08/25](/zh_TW/meetings/2016/08/25/#segwit-dos-保護提案) 會議中討論的 [DoS 議題](https://github.com/bitcoin/bitcoin/issues/8279)的解決方案。Sipa 對之前建議的完全驗證所有內容感到不舒服。Luke-jr 和 sdaftuar 喜歡拒絕快取使用見證雜湊而不是 txid 的方法，但這需要重做交易中繼，這是一個很大的變更，並且有一些複雜性，例如複製幾個索引。大多數人喜歡強制使用 feefilter 的想法，儘管它不像其他一些解決方案那樣是萬靈丹。Sipa 想知道是否每個人都同意僅對非見證進行拒絕快取，以及對最常見交易類型檢測無效見證膨脹的[啟發式][#8499]，例如檢查見證程式的嵌入式腳本雜湊是否與見證腳本的雜湊匹配。Luke-jr 認為強制 feefilter 可能會因為費用策略和祖先費率（子付父）的分歧而引起問題，gmaxwell 指出 CPFP 中繼在當前形式的 feefilter 下已經被抑制到最大程度；強制 feefilter 不會使其變得更糟。 + +BlueMatt 想知道 feefilter 是否不會去匿名化，以及我們是否應該對數量進行一些舍入/隨機化。Gmaxwell 解釋它已經在這樣做了，但我們無法保證具有多個介面的單個節點不能被區分為同一節點，因為有其他幾種方法可以做到這一點。 + +Jeremyrubin 提到他的 [Checkqueue Lockfree][#8464] 正在通過測試，並希望聽聽人們希望看到什麼才能合併。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 會議](/zh_TW/meetings/2015/10/08/#low-s-change)中討論）。Sipa 現在提議將其作為共識規則，而不僅僅是策略。 + +這在 2016/08/11 [會議](/zh_TW/meetings/2016/08/11/#軟分叉以要求-low-s)中討論過。 + +### 會議討論 + +這個議題需要重新討論，因為 jl2012 [發現](https://github.com/bitcoin/bitcoin/pull/8533#issuecomment-243973512) low_s 有一個非常奇怪的實施議題洩漏到語義中，這對於標準性不是問題，但對於共識我們應該更喜歡乾淨的語義。這可以透過執行「[only-empty-signature-in-invalid-checksig][#8634]」軟分叉來實現。Sipa 提議稍後使用空簽名規則執行 low_s 軟分叉，並僅將 nulldummy 與 segwit 綁定。 + +BlueMatt 詢問是否曾經在鏈中出現過使用 OP_NOT 的非零長度無效簽名。至少有一個案例。BlueMatt 提議在 0.13.1 中將非零長度無效簽名設為非標準。 + +### 會議結論 + +- 將非零長度無效簽名設為非標準 + +## 趣味環節 + +{% highlight text %} +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. +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8393]: https://github.com/bitcoin/bitcoin/pull/8393 +[#8499]: https://github.com/bitcoin/bitcoin/pull/8499 +[#8464]: https://github.com/bitcoin/bitcoin/pull/8464 +[#8594]: https://github.com/bitcoin/bitcoin/pull/8594 +[#8634]: https://github.com/bitcoin/bitcoin/pull/8634 +[#8525]: https://github.com/bitcoin/bitcoin/pull/8525 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-09-08-meeting.md b/_posts/zh_TW/meetings/2016-09-08-meeting.md new file mode 100644 index 000000000..314c72f19 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-09-08-meeting.md @@ -0,0 +1,137 @@ +--- +title: IRC meeting summary for 2016-09-08 +permalink: /zh_TW/meetings/2016/09/08/ +name: 2016-09-08-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-09-08/?msg=72705189&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-08-18.59.html) + +--- + +## 筆記 / 簡短議題 + +- 在米蘭 [scaling bitcoin 會議](https://scalingbitcoin.org/milan2016/)之後，10 月 10 日星期一和 11 日星期二將舉行 2 天的駭客日，更多資訊和註冊將隨後發布。 +- 有一個 [0.13.1 的 PR 隊列](https://github.com/bitcoin/bitcoin/milestones/0.13.1)，鼓勵審查。 + +## 主要議題 + +- segwit-compact blocks BIP +- 選擇 segwit 推出日期 +- rpc 同步假設 + +## segwit-compact blocks BIP + +### 背景 + +[BIP152][]：「Compact block relay」是 0.13.0 中引入的功能，用於透過使用應該在節點記憶體池中的交易的短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也導致減少區塊傳輸延遲。 + +開發者現在正在開發 compact blocks 的版本 2，它與版本 1 幾乎相同，但支援隔離見證交易。對 BIP 文件的變更提案在[這裡](https://github.com/bitcoin/bips/pull/423)。 + +### 會議討論 + +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 會議](/zh_TW/meetings/2016/07/14/#segwit-反向移植)中討論的，不會有 0.12 反向移植，因為它沒有收到要求反向移植的回饋。 + +### 會議結論 + +- 除非我們有信心，否則不要引入時程表 +- 不要將 segwit 反向移植到 0.12 + +## rpc 同步假設 + +### 背景 + +如 [2016/09/01 會議](/zh_TW/meetings/2016/09/01/#筆記--簡短議題)中簡要討論的，當錢包尚未完成處理交易時，存在競爭條件，在 getblockcount/getbestblockhash 回傳新值之前，因此餘額可能不代表該區塊的準確狀態。 + +### 會議討論 + +一些開發者不認為這是錯誤，因為未確認的交易可以隨時出現，與任何區塊無關。如果在錢包處理交易時變更餘額被視為錯誤，它也應該適用於所有其他狀態，例如交易列表。 + +其他開發者認為這是 API 的變更，將破壞一些 RPC 客戶端，而使錢包餘額呼叫等待它們自己的時間，直到錢包報告的高度與 chainactive 高度匹配，不需要所有使用者審核他們的程式碼庫。 + +未來錢包區塊處理應該移到背景執行緒。 + +### 會議結論 + +- 建立關於問題的議題（[會議後完成](https://github.com/bitcoin/bitcoin/issues/8692)）。 +- 合併快速修復（[#8680][]）以解決 travis 失敗 +- 在會議外進一步討論 + +## 趣味環節 + +{% highlight text %} +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 ;) +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8680]: https://github.com/bitcoin/bitcoin/pull/8680 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-09-15-meeting.md b/_posts/zh_TW/meetings/2016-09-15-meeting.md new file mode 100644 index 000000000..57f9585a2 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-09-15-meeting.md @@ -0,0 +1,79 @@ +--- +title: IRC meeting summary for 2016-09-15 +permalink: /zh_TW/meetings/2016/09/15/ +name: 2016-09-15-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-09-15/?msg=73087604&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.html) + +--- + +## 筆記 / 簡短議題 + +- [生命週期](/zh_TW/lifecycle/)頁面上版本 0.11 的「終止支援」EOL 日期應該設定。維護日期不反映現實，因為對先前版本的反向移植沒有使用和沒有審查，因此開發者專注於當前版本。Sipa 拋出在發布 X 個月後自動顯示警告訊息的想法，以警告使用者該版本不再維護。 +- 在 Scaling Bitcoin 會議之後的 10 月 10 日和 11 日星期一和星期二，有兩個[駭客日](http://coredev.tech/nextmeeting_tmp.html)，供那些想要對 Bitcoin Core 和高度相關專案做出生產性貢獻的人參加。 +- Wumpus 提議了 [0.14 的發布時程表](https://github.com/bitcoin/bitcoin/issues/8719)。每個人似乎都同意。 + +## 主要議題 + +- 0.13.1 發布 + +## 0.13.1 發布 {#release} + +### 背景 + +Bitcoin Core 0.13.0 於 2016/08/23 [發布](/zh_TW/releases/0.13.0/)。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。 + +### 會議討論 + +由於仍有相當多的 PR [標記為 0.13.1](https://github.com/bitcoin/bitcoin/milestone/22)，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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8654]: https://github.com/bitcoin/bitcoin/pull/8654 +[#8635]: https://github.com/bitcoin/bitcoin/pull/8635 +[#8636]: https://github.com/bitcoin/bitcoin/pull/8636 +[#8634]: https://github.com/bitcoin/bitcoin/pull/8634 +[#8499]: https://github.com/bitcoin/bitcoin/pull/8699 +[#8526]: https://github.com/bitcoin/bitcoin/pull/8526 +[#8393]: https://github.com/bitcoin/bitcoin/pull/8393 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-09-22-meeting.md b/_posts/zh_TW/meetings/2016-09-22-meeting.md new file mode 100644 index 000000000..cb70cc676 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-09-22-meeting.md @@ -0,0 +1,114 @@ +--- +title: IRC meeting summary for 2016-09-22 +permalink: /zh_TW/meetings/2016/09/22/ +name: 2016-09-22-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-09-22/?msg=73443433&page=4) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.html) + +--- + +## 筆記 / 簡短議題 + +- Wumpus 已經開始使用 github 上的新功能來追蹤較長期的[專案](https://github.com/bitcoin/bitcoin/projects)。 + +## 主要議題 + +- 0.13.1 發布 +- 警報系統退役 + +## 0.13.1 發布 + +### 背景 + +Bitcoin Core 0.13.0 於 2016/08/23 [發布](/zh_TW/releases/0.13.0/)。下一個點發布版本 0.13.1 可能會包含隔離見證軟分叉啟動邏輯，以及其他錯誤修復和優化。 + +在[上週會議](/zh_TW/meetings/2016/09/15/#release)中，開發者決定從 [0.13.1 里程碑](https://github.com/bitcoin/bitcoin/milestone/22)標籤中移除 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](https://github.com/bitcoin/bitcoin/issues/8279) 議題（Mempool DoS risk in segwit due to malleated transactions）對於 0.13.1 已充分解決。 + +[Btcd](https://github.com/btcsuite/btcd)，Go 語言的替代比特幣實作，將很快最終確定 segwit 相關事項。Petertodd 的 [python bitcoin library](https://github.com/petertodd/python-bitcoinlib) 也有一個很好的 [segwit PR](https://github.com/petertodd/python-bitcoinlib/pull/112)。Gmaxwell 指出挖礦軟體最近在 segwit 方面有很大改進。Achow101 指出 armory 目標是在下一個版本之後的版本中完全支援 segwit。 + +### 會議結論 + +- 從 0.13.1 里程碑中移除 PR [#8654][] 和 [#8757][]，以及議題 [#8279](https://github.com/bitcoin/bitcoin/issues/8279) +- 壓縮第一個和最後一個提交後合併 [#8634][] +- 審查/ACK PR [#8393][]、[#8499][] 和 [#8526][] + +## 警報系統退役 + +### 背景 + +比特幣警報系統是受信任方向所有 Core 客戶端廣播有關關鍵網路問題的訊息的一種方式。自 Bitcoin Core 0.13.0 以來它已被移除，並且已經停用一段時間了。 + +本月早些時候，Gmaxwell 在郵件列表上[發布](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html)了完成警報系統退役的願望，這得到了很好的回應。 + +### 會議討論 + +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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8654]: https://github.com/bitcoin/bitcoin/pull/8654 +[#8635]: https://github.com/bitcoin/bitcoin/pull/8635 +[#8634]: https://github.com/bitcoin/bitcoin/pull/8634 +[#8499]: https://github.com/bitcoin/bitcoin/pull/8499 +[#8526]: https://github.com/bitcoin/bitcoin/pull/8526 +[#8393]: https://github.com/bitcoin/bitcoin/pull/8393 +[#8757]: https://github.com/bitcoin/bitcoin/pull/8757 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-09-29-meeting.md b/_posts/zh_TW/meetings/2016-09-29-meeting.md new file mode 100644 index 000000000..9da138cbf --- /dev/null +++ b/_posts/zh_TW/meetings/2016-09-29-meeting.md @@ -0,0 +1,142 @@ +--- +title: IRC meeting summary for 2016-09-29 +permalink: /zh_TW/meetings/2016/09/29/ +name: 2016-09-29-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-09-29/?msg=73958802&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-29-19.01.html) + +--- + +## 筆記 / 簡短議題 + +- Gmaxwell 提到了為守護程式設定 cron 模式的想法，它只是同步然後關閉，以便更輕鬆地保持區塊鏈副本的最新狀態。 +- 下週的會議不太可能舉行（或參與者很少），因為大多數開發者都在前往[米蘭 Scaling Bitcoin](https://scalingbitcoin.org/milan2016/)的途中。 + +## 主要議題 + +- 修剪和區塊中繼 +- 移除檢查點 +- 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 中將未壓縮金鑰設為非標準 +- 鼓勵錢包轉向壓縮金鑰 + +## 趣味環節 + +{% highlight text %} +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' +{% endhighlight %} + + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-10-13-meeting.md b/_posts/zh_TW/meetings/2016-10-13-meeting.md new file mode 100644 index 000000000..0030cb12a --- /dev/null +++ b/_posts/zh_TW/meetings/2016-10-13-meeting.md @@ -0,0 +1,119 @@ +--- +title: IRC meeting summary for 2016-10-13 +permalink: /zh_TW/meetings/2016/10/13/ +name: 2016-10-13-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-10-13/?msg=74777126&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.html) + +--- + +## 筆記 / 簡短議題 + +- Jtimon 在郵件列表上發布了 [libconsensus 完成計劃](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013204.html)。 +- 有人抱怨測試網不可靠，因為它沒有持續被挖掘。一些人希望看到簽名測試網，類似於 elements alpha 執行的方式，這樣它將具有完全可預測的區塊和重組。 +- 為下游開發者提供了 [segwit 開發指南](/zh_TW/segwit_wallet_dev/)。還應該有一個 segwit 部署指南，其中包含更多詳細資訊，例如如何設定周邊節點。 +- Achow101 將為 bitcoin.org 撰寫關於警報系統的文章，這在之前的 [2016-09-22](/zh_TW/meetings/2016/09/22/#警報系統退役) 會議中討論過。 + +## 主要議題 + +- 0.13.1 與 BIP 9 參數 +- sybil 攻擊 + +## 0.13.1 + +### 背景 + +Bitcoin Core 0.13.0 於 2016/08/23 [發布](/zh_TW/releases/0.13.0/)。下一個點發布版本 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 保護而很有用。 + +### 會議結論 + +- 努力減少隱私洩漏。 + +## 趣味環節 + +{% highlight text %} +(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?) +{% endhighlight %} + +## 與會者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8499]: https://github.com/bitcoin/bitcoin/pull/8499 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-10-20-meeting.md b/_posts/zh_TW/meetings/2016-10-20-meeting.md new file mode 100644 index 000000000..e4d035113 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-10-20-meeting.md @@ -0,0 +1,81 @@ +--- +title: 2016-10-20 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/10/20/ +name: 2016-10-20-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-10-20/?msg=75168477&page=6) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.html) + +--- + +## 備註 / 簡短議題 + +- Bitcoin Core 0.13.1 [候選版本 2](https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/) 已發布，目前沒有回報任何問題。 +- Wumpus 一直在詢問有關終止 Windows 32 位元版本的問題，可能在 0.15 版本。他收到了 2 個仍在使用 Windows 32 位元的回應，兩者預期只會再使用 6 個月。 +- Jonasschnelli 注意到 GUI 預設確認目標是 25 個區塊，這真的很高，而預設 RPC 目標只有 2 個區塊。這些應該是相同的值。由於改進手續費估算方面進展甚微，[bumpfee PR][#8456] 應該獲得更多審查。 + +## 主要議題 + +- libconsensus + +## libconsensus + +### 背景 + +理想情況下，共識層應該與比特幣軟體的其他部分解耦。長期目標是提取出一個獨立的 "libconsensus" 函式庫。 +這樣人們就可以更容易地對非共識部分進行變更，而不必擔心共識不相容。 +然而，這是一個緩慢而危險的專案，需要移動大量程式碼。在過去幾個主要版本中，一直在努力朝著這個共識函式庫的方向前進。 + +最近，Jorge Timón 在[郵件列表](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013204.html)上發表了一篇文章，提出了更詳細的推進計劃。他有自己的[分支](https://github.com/jtimon/bitcoin/commits/0.13-consensus-flags)，正在進行所有變更。 + +### 會議討論 + +目前可以將非共識旗標傳遞到 libconsensus 中。PR [#8976][] 試圖修復這個問題。Sipa 認為應該有一個轉換層。 + +Jtimon 希望在 libconsensus 中公開一個 "GetConsensusFlags" 呼叫，以隱藏 [BIP9][] 和先前開發的類似內容，類似於["公開 VerifyHeader"][#8493]。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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8976]: https://github.com/bitcoin/bitcoin/pull/8976 +[#8493]: https://github.com/bitcoin/bitcoin/pull/8493 +[#8456]: https://github.com/bitcoin/bitcoin/pull/8456 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-10-27-meeting.md b/_posts/zh_TW/meetings/2016-10-27-meeting.md new file mode 100644 index 000000000..50856ba92 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-10-27-meeting.md @@ -0,0 +1,95 @@ +--- +title: 2016-10-27 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/10/27/ +name: 2016-10-27-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-10-27/?msg=75583089&page=4) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.html) + +--- + +## 備註 / 簡短議題 + +- 0.13.1 已發布。（[二進制檔案](https://bitcoin.org/bin/bitcoin-core-0.13.1/)、[磁力連結](magnet:?xt=urn:btih:dbe48c446b1113890644bbef03e361269f69c49a&dn=bitcoin-core-0.13.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F)、[郵件列表公告](https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-October/000023.html)、[部落格文章](https://bitcoincore.org/en/2016/10/27/release-0.13.1/)） +- Gmaxwell 將與 Achow101 和 Cobra 協調發出最終警報，如[郵件列表](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html)和 [2016-09-22 會議](https://bitcoincore.org/en/meetings/2016/09/22/#alert-system-retirement)所討論的。 + +## 主要議題 + +- 測試鏈 +- 移除檢查點 + +## 測試鏈 + +### 背景 + +Jtimon 正在進行一項工作，使在主測試網之外建立新測試網變得更容易（PR [#8994][]）。為了測試某些功能或不同的邊緣情況，普通測試網可能不夠用。目前測試網的不穩定性導致一些人根本不在上面測試。 + +### 會議討論 + +進一步的開發將著重於簽名區塊選項，這是在 [Elements Alpha](https://www.elementsproject.org/sidechains/alpha/) 中用於建立區塊的機制。Jtimon 正在自己的[分支](https://github.com/jtimon/bitcoin/compare/0.13-new-testchain...jtimon:0.13-blocksign)上進行這項工作。 + +在受信任的群組內使用 regtest 與簽名區塊一樣有用，然而當公開時，就需要像區塊簽名這樣的東西。Jtimon 指出，他的 PR 使得可以選擇 "-chain=custom -chainpetname=mysharedsecret"，而沒有存取 mysharedsecret 的人將無法在本地建立創世區塊，因為創世區塊的雜湊值取決於 -chainpetname。 + +### 會議結論 + +- 查看 PR[#8994][]（測試鏈：引入自訂鏈，其建構子...） + +## 移除檢查點 + +### 背景 + +每隔一段時間，舊的區塊雜湊值就會被硬編碼到比特幣軟體中。不同的實作選擇不同的檢查點位置。這些檢查點目前用於 3 個使用情境： + +- 防止使用低難度標頭進行標頭洪水攻擊 +- 跳過早期區塊中的簽章 +- 估算進度 + +### 會議討論 + +Gmaxwell 有一個[分支](https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints)移除了檢查點。他還沒有完全移除，因為他仍然需要替換進度估算。 + +有 3 個組成部分： +- 移除初始區塊下載的檢查點，這是理所當然的。 +- 移除腳本檢查的檢查點，這取決於基準測試結果，如 [2016-09-09 會議](/en/meetings/2016/09/29/#removing-checkpoints)所討論的。 +- 避免標頭洪水。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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#8994]: https://github.com/bitcoin/bitcoin/pull/8994 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-11-03-meeting.md b/_posts/zh_TW/meetings/2016-11-03-meeting.md new file mode 100644 index 000000000..bacb9b304 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-11-03-meeting.md @@ -0,0 +1,109 @@ +--- +title: 2016-11-03 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/11/03/ +name: 2016-11-03-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-11-03/?msg=75932564&page=2) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.html) + +--- + +## 備註 / 簡短議題 + +- [最終警報](https://bitcoin.org/en/alert/2016-11-01-alert-retirement)已成功發出。 +- 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 的[修復無效緊湊區塊的處理][#9026]。Luke-jr 想知道何時以及是否應該停止 BIP 變更，因為現在 BIP 似乎對其他實作來說是一個移動目標。 + +在發布實作後，認為我們不會想對複雜的 BIP 進行小調整可能不切實際，在未來讓原始 BIP 反映最終設計會更清楚。 + +Gmaxwell 認為這更像是郵件列表的議題，而不是會議議題。 + +### 會議結論 + +- 等到一段時間沒有變更後再將 BIP 設為「最終」。 + +## 幽默時刻 + +{% highlight text %} +gmaxwell 總之，我仍然認為 BIP 討論應該放在別處。:) +morcos 好吧，那你想出別的東西來討論剩下的 11 分鐘！ + +gmaxwell wumpus: sipa: 感謝合併這麼多東西！ +BlueMatt <3 +sdaftuar +1 +BlueMatt 讓 0.14 再次偉大！ + +wumpus 所以我想在實務上它只修復了 0.13.2 上的測試網問題，所以問題是這是否值得潛在的倒退？ +gmaxwell <有名的遺言>我看不出它會造成倒退。 +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9026]: https://github.com/bitcoin/bitcoin/pull/9026 +[#9053]: https://github.com/bitcoin/bitcoin/pull/9053 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-11-10-meeting.md b/_posts/zh_TW/meetings/2016-11-10-meeting.md new file mode 100644 index 000000000..fa77e0da1 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-11-10-meeting.md @@ -0,0 +1,139 @@ +--- +title: 2016-11-10 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/11/10/ +name: 2016-11-10-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-11-10/?msg=76281623&page=2) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-10-19.03.html) + +--- + +## 主要議題 + +- 混合 SPV +- 多執行緒 ProcessMessages +- 0.14 + +## 混合 SPV + +### 背景 + +Jonasschnelli 正在進行一個[拉取請求][#9076]，為錢包添加全區塊 SPV 模式。 + +它會有 2 個選項：-spv 和 -spvonly，-spv 用於啟用使用者在區塊鏈仍在下載/驗證時發送和接收交易。-spvonly 則完全不驗證區塊。 + +PR 目前的限制： +- 沒有 SPV 0 確認交易 +- SPV 交易的備用手續費（因為沒有記憶池/手續費估算器） +- 它只有簡單的 spv 重組處理 +- 目前與修剪不相容 + +### 會議討論 + +Jonasschnelli 想知道這個想法是否值得追求，因為他還沒有收到任何概念性的 ACK。 + +每個人都認為這是一個很好的功能。BlueMatt 認為包含 spv-only 模式可能不值得，但是沒有額外成本，因為混合模式需要這些程式碼。它也將是唯一使用完整區塊的 SPV 客戶端。 + +### 會議結論 + +- 繼續進行[混合全區塊 SPV 模式][#9076] + +## 多執行緒 ProcessMessages + +### 背景 + +目前 Bitcoin Core 在單執行緒中進行訊息處理。BlueMatt 請求對多訊息處理執行緒的一些回饋和一般關注。 + +### 會議討論 + +BlueMatt 詳細說明，目前它不是很有用，因為大多數訊息使用 cs_main，但他希望能儘早而不是稍後看到它的管道。例如：添加多執行緒訊息傳遞將允許節點在處理區塊時回應 getblocktxn，這是他真正想要用於基於 FIBRE 的中繼網路的功能。Wumpus 補充說，能夠同時服務多個節點也會非常有用，應該可以減少區塊中繼延遲。 + +Morcos 指出，首先徹底審查同步問題很重要，因為現在可能無法檢測到問題，因為它們只從單執行緒存取。 + +Gmaxwell 認為讓 process message 並發可能會為 nodestats 周圍的資料競爭帶來更大的風險，所以他建議使用 valgrind DRD 執行測試，並嘗試消除資料競爭。 + +### 會議結論 + +- 進行添加多執行緒訊息處理的工作 + +## 0.14 + +### 背景 + +Bitcoin Core 0.14 [預計](https://github.com/bitcoin/bitcoin/issues/8719)在 2017 年 3 月左右發布。 + +### 會議討論 + +MarcoFalke 想知道進入 0.14 的優先事項是什麼。 + +拆分 main.cpp 幾乎可以肯定會在此時進入。 + +Sdaftuar 希望看到 [JeremyRubin 的驗證加速][#8895]進入。 + +Jonasschnelli 認為多錢包支援剩下的工作不多，儘管他不確定是否能趕上 0.14。為多錢包支援開設了一個 [github 專案](https://github.com/bitcoin/bitcoin/projects/2)。 + +對於網路重構，Cfields 的目標是下週完成 net.h/cpp 拆分。 + +[Bumpfee][#8456] 應該得到一些審查。 + +記憶池統計的基礎工作在 [#8501][] 中完成，但到目前為止沒有審查。 + +### 會議結論 + +- 優先審查錢包變更 + +## 幽默時刻 + +{% highlight text %} +gmaxwell 我們應該向所有錯過時區變更的美國人打招呼。 +gmaxwell 並且現在剛到。:P +gmaxwell 嗨，各位。 +achow101 嗨 +petertodd gmaxwell: 加拿大人也是 :) +btcdrak petertodd: 你是說雪地墨西哥人對吧？ +gmaxwell 歡迎來到會議結束。 +wumpus 是的，歡迎 +sipa kthxbye +wumpus #endmeeting +MarcoFalk_ 也許川普會廢除日光節約時間 +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9076]: https://github.com/bitcoin/bitcoin/pull/9076 +[#8895]: https://github.com/bitcoin/bitcoin/pull/8895 +[#8456]: https://github.com/bitcoin/bitcoin/pull/8456 +[#8501]: https://github.com/bitcoin/bitcoin/pull/8501 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-11-17-meeting.md b/_posts/zh_TW/meetings/2016-11-17-meeting.md new file mode 100644 index 000000000..cfd050960 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-11-17-meeting.md @@ -0,0 +1,146 @@ +--- +title: 2016-11-17 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/11/17/ +name: 2016-11-17-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-11-17/?msg=76630924&page=2) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.html) + +--- + +## 主要議題 + +- 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 使用帳戶系統。使用此功能的第三方可能會遇到多個問題，[很久以前](https://github.com/bitcoin/bitcoin/issues/3816)就已達成共識，應該移除該系統並由「標籤」系統取代。 + +### 會議討論 + +今年早些時候，Wumpus 開啟了一個[拉取請求][#7729]，為錢包引入「標籤」API（在 [2016-07-14 會議](/en/meetings/2016/07/14/#notes--short-topics)中曾提到）。它仍然沒有得到太多審查。 + +應該首先引入標籤一兩個版本，然後再移除帳戶，因為有些人仍然依賴帳戶系統，但將其用作標籤。 + +Wumpus 提到應該有保護措施，防止使用者同時使用帳戶和標籤 API，因為這可能會造成問題。 + +Instagibbs 想知道是否有人與仍然使用帳戶的開發者交談。MarcoFalke 認為 Dooglus 使用它，但他的使用情境會被新的標籤 API 涵蓋。 + +### 會議結論 + +- 審查 [#7729][]（rpc：為錢包引入「標籤」API） +- 向 dooglus 詢問使用者回饋 + +## 輔助區塊請求 + +### 背景 + +Jonasschnelli 開啟了一個[拉取請求][#9171]，引入輔助區塊請求（先前稱為「帶外區塊請求」）。此功能允許請求區塊，如果在磁碟上可用，則會被下載並優先於正常 IBD 下載。此變更是執行 SPV 錢包所需的，在[上週會議](/en/meetings/2016/11/10/#hybrid-spv)中討論過。 + +### 會議討論 + +多位開發者發現很難理解，並想知道是否有對高層設計及其如何運作的更一般描述。Jonasschnelli 解釋：你問你的節點，給我區塊 "D, F, G"，節點下載區塊 "D, F, G" 並通過 validate=false 的訊號傳遞它 + +Sipa 喜歡整體概念，但認為實作需要隨著正在進行的網路重構而改變。 + +BlueMatt 想知道區塊是否真的應該被儲存，或者我們是否可以直接傳遞給錢包。如果它不儲存區塊，在混合模式下將需要下載兩次，所以它至少應該有機會儲存它。BlueMatt 希望看到 p2p 邏輯決定是否將區塊發送到 ProcessNewBlock。 + +## 幽默時刻 + +{% highlight text %} +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：那會導致小孩失明嗎？ +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9125]: https://github.com/bitcoin/bitcoin/pull/9125 +[#8580]: https://github.com/bitcoin/bitcoin/pull/8580 +[#8589]: https://github.com/bitcoin/bitcoin/pull/8589 +[#7729]: https://github.com/bitcoin/bitcoin/pull/7729 +[#9171]: https://github.com/bitcoin/bitcoin/pull/9171 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-12-01-meeting.md b/_posts/zh_TW/meetings/2016-12-01-meeting.md new file mode 100644 index 000000000..625fec760 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-12-01-meeting.md @@ -0,0 +1,140 @@ +--- +title: 2016-12-01 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/12/01/ +name: 2016-12-01-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-12-01/?msg=77318530&page=4) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-01-19.00.html) + +--- + +## 備註 / 簡短議題 + +- 由於 segwit 變更了來自 JSON-RPC API 的資料格式，已提出一個[拉取請求][#9194]，添加一個選項以返回非 segwit 序列化，以便未及時升級其函式庫的使用者仍然可以使用 RPC 介面。 +- JeremyRubin 的[更好的 SigCache 實作][#8895]已準備好進入，但缺少一些審查。 + +## 主要議題 + +- 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 開啟了一個[問題](https://github.com/bitcoin/bitcoin/issues/8416)討論這個行為。 + +它目前除了用於確定是否剛建立新錢包之外未被使用。 + +### 會議討論 + +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 金鑰路徑方案的支援） +- 專注於拆分金鑰路徑 + +## 幽默時刻 + +{% highlight text %} +gmaxwell 我剛注意到 #9188 還沒合併。 +gmaxwell 看看自己是不是延遲的原因 +gmaxwell 不是延遲的原因 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9194]: https://github.com/bitcoin/bitcoin/pull/9194 +[#8895]: https://github.com/bitcoin/bitcoin/pull/8895 +[#9183]: https://github.com/bitcoin/bitcoin/pull/9183 +[#9229]: https://github.com/bitcoin/bitcoin/pull/9229 +[#9194]: https://github.com/bitcoin/bitcoin/pull/9194 +[#9188]: https://github.com/bitcoin/bitcoin/pull/9188 +[#9239]: https://github.com/bitcoin/bitcoin/pull/9239 +[#9252]: https://github.com/bitcoin/bitcoin/pull/9252 +[#9253]: https://github.com/bitcoin/bitcoin/pull/9253 +[#9143]: https://github.com/bitcoin/bitcoin/pull/9143 +[#9256]: https://github.com/bitcoin/bitcoin/pull/9256 +[#8723]: https://github.com/bitcoin/bitcoin/pull/8723 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-12-08-meeting.md b/_posts/zh_TW/meetings/2016-12-08-meeting.md new file mode 100644 index 000000000..074eb2e16 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-12-08-meeting.md @@ -0,0 +1,112 @@ +--- +title: 2016-12-08 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/12/08/ +name: 2016-12-08-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-12-08/?msg=77680236&page=2) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-08-19.00.html) + +--- + +## 備註 / 簡短議題 + +- Github 現在支援為你的 PR 列出審查者 +- 隔離見證支援 [getblocktemplate][BIP23] 實作需要一些緊急[審查](https://github.com/bitcoin/libblkmaker/pull/6)，因為一些下游礦工需要它來支援 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 在會議期間進行了一個[拉取請求][#9302]。 + +Luke-jr 指出，也可以通過將 -spendzeroconfchange 的預設值設置為 0 來解決這個問題，但這將是一個破壞性的變更，只有在真正嚴重的問題時才應該考慮。 + +### 會議結論 + +- 審查主分支和回移的 [#9290][]（使 RelayWalletTransaction 嘗試 AcceptToMemoryPool）、[#9302][]（即使新交易的 ATMP 失敗也返回 txid）以及可選的回移 [#9262][]（偏好祖先較少的幣，在 ATMP 之前進行合理性檢查） + +## 記憶池過期時間增加 + +### 背景 + +目前在記憶池中停留超過 3 天的交易會從記憶池中移除。Morcos 提議將此過期時間增加到 2 週。 + +### 會議討論 + +Morcos 認為，如果我們想充分利用交易量的每週週期，我們需要有停留一週或更長時間的交易來測量它們需要多長時間才能得到確認。 + +Gmaxwell 指出，過期會移除被軟分叉出去但佔用你的記憶池的高手續費交易。然而，3 天的過期時間無論如何都會搞亂手續費估算。 + +Sdaftuar 指出，3 天與一週的另一個優勢是能夠雙重花費手續費太低的交易，但在引入手續費提升後，這個問題在很大程度上消失了。Gmaxwell 認為，即使在一天之後，非可替換交易的替換現在也能工作，這是由於重新啟動和全 rbf 礦工。 + +### 會議結論 + +- 提出一個 [PR][#9312] 來增加過期時間並獲得更多想法和問題。 + +## 幽默時刻 + +{% highlight text %} +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 下次請更快一點 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9290]: https://github.com/bitcoin/bitcoin/pull/9290 +[#9262]: https://github.com/bitcoin/bitcoin/pull/9262 +[#9302]: https://github.com/bitcoin/bitcoin/pull/9302 +[#9312]: https://github.com/bitcoin/bitcoin/pull/9312 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-12-15-meeting.md b/_posts/zh_TW/meetings/2016-12-15-meeting.md new file mode 100644 index 000000000..9ab2e876a --- /dev/null +++ b/_posts/zh_TW/meetings/2016-12-15-meeting.md @@ -0,0 +1,88 @@ +--- +title: 2016-12-15 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/12/15/ +name: 2016-12-15-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-12-15/?msg=78038850&page=2) +- [meetbot 會議紀錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.html) + +--- + +## 備註 / 簡短議題 + +- Sipa 和 gmaxwell 一直在試驗[每交易輸出 UTXO 快取](https://github.com/bitcoin/bitcoin/compare/master...sipa:pertxoutcache)方法，而不是按交易分組 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 旗標的[評論](https://github.com/bitcoin/bitcoin/pull/9347#discussion_r92503011)有強烈意見。他認為這並不重要，但希望得到第二意見。 + +### 會議結論 + +- 合併 [#9322][]（不設置未知的 rpcserialversion） +- 審查 [#9262][]（偏好祖先較少的幣，在 ATMP 之前進行合理性檢查）預設停用並回移到 0.13.2 +- 審查 [#9352][]（嘗試從所有緊湊區塊公告重建）並回移到 0.13.2 + +## 幽默時刻 + +{% highlight text %} +instagibbs 更好就是更好 +gmaxwell 有時更好就是更糟，肯定有一篇關於這個的文章。:P +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9322]: https://github.com/bitcoin/bitcoin/pull/9322 +[#9352]: https://github.com/bitcoin/bitcoin/pull/9352 +[#9262]: https://github.com/bitcoin/bitcoin/pull/9262 +[#9289]: https://github.com/bitcoin/bitcoin/pull/9289 +[#9347]: https://github.com/bitcoin/bitcoin/pull/9347 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2016-12-22-meeting.md b/_posts/zh_TW/meetings/2016-12-22-meeting.md new file mode 100644 index 000000000..9e890e7d9 --- /dev/null +++ b/_posts/zh_TW/meetings/2016-12-22-meeting.md @@ -0,0 +1,126 @@ +--- +title: 2016-12-22 IRC 會議摘要 +permalink: /zh_TW/meetings/2016/12/22/ +name: 2016-12-22-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2016-12-22/?msg=78334610&page=2) +- meetbot 會議紀錄不可用 + +--- + +## 備註 / 簡短議題 + +- Bitcoin Core 0.13.2 候選版本 1 [可供](https://bitcoin.org/bin/bitcoin-core-0.13.2/test.rc1/)測試。 +- Jl2012 請大家閱讀並可能回應他的 [BIP 提案](https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki)。 +- 現在 [BIP2][] 已經啟用，發布一些 BIP 評論會很好。背後的想法是為使用者提供一個中心位置來區分不建議和推薦的 BIP。有關格式和程序的更多資訊可以在[「BIP 評論」部分](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments)找到。 +- sipa 自從[上週會議](/en/meetings/2016/12/15/#notes--short-topics)以來，對每交易輸出 UTXO 快取方法進行了更多測試。結果顯示，在早期的基準測試中留下了一些除錯程式碼，導致每個 txin 都進行資料庫讀取，這嚴重影響了性能。現在初始區塊下載大約快 30%。未來還預期會有進一步的加速，所以這可能是值得的，這意味著我們需要弄清楚如何進行遷移，因為這個變更需要重新索引。 + +## 主要議題 + +- 0.14 功能 +- WitnessMerkleBlocks + +## 0.14 功能 + +### 背景 + +Bitcoin Core 0.14 [預計](https://github.com/bitcoin/bitcoin/issues/8719)在 2017 年 3 月左右發布。針對 0.14 的開放拉取請求被[標記為 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +### 會議討論 + +Luke-jr 和 jonasschnelli 正在進行[多錢包專案](https://github.com/bitcoin/bitcoin/projects/2)，該專案允許執行多個錢包。由於這是一個影響重大的變更，對於 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 的路徑和見證的部分默克爾樹。此外，它不是將所有交易作為單獨的訊息發送，而是將它們包含在相同的結構中。他開始在[這裡](https://github.com/bitcoin/bitcoin/compare/master...CodeShark:WitnessMerkleBlock2)進行這些程式碼的工作。 + +### 會議討論 + +CodeShark 並不真的喜歡 [BIP37][]，但目前沒有另一個查詢機制不需要你下載完整區塊。Gmaxwell 想知道像 [BIP152][] 'getblocktxn' 訊息這樣的按索引查詢是否能涵蓋 CodeShark 的使用情境。人們更願意進行按索引查詢的工作，而不是投資已知有問題的 [BIP37][] 方法。 + +### 會議結論 + +- CodeShark 將更深入研究 [BIP152][] + +## 幽默時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。 + +[#9294]: https://github.com/bitcoin/bitcoin/pull/9294 +[#9298]: https://github.com/bitcoin/bitcoin/pull/9298 +[#8755]: https://github.com/bitcoin/bitcoin/pull/8755 +[#8654]: https://github.com/bitcoin/bitcoin/pull/8654 +[#9289]: https://github.com/bitcoin/bitcoin/pull/9289 +[#9375]: https://github.com/bitcoin/bitcoin/pull/9375 +[#7533]: https://github.com/bitcoin/bitcoin/pull/7533 +[#9138]: https://github.com/bitcoin/bitcoin/pull/9138 +[#8776]: https://github.com/bitcoin/bitcoin/pull/8776 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-01-05-meeting.md b/_posts/zh_TW/meetings/2017-01-05-meeting.md new file mode 100644 index 000000000..e2848fb83 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-01-05-meeting.md @@ -0,0 +1,137 @@ +--- +title: IRC meeting summary for 2017-01-05 +permalink: /zh_TW/meetings/2017/01/05/ +name: 2017-01-05-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-01-05/?msg=78899987&page=2) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.html) + +--- + +## 筆記／短主題 + +- Jonasschnelli 建立了 2016 年 Git 視覺化的草稿影片。 + +## 主要議題 + +- 分叉警告系統修復 +- 0.14 審查優先順序 + +## 分叉警告系統修復 + +### 背景 + +大工作量分叉警告系統（應該在具有足夠工作量證明的分叉持續被挖掘時警告使用者）目前在 header first 驗證下已損壞。 + +Jl2012 正在[研究][#9443]此問題的修復方案。 + +### 會議評論 + +Jl2012 詳細說明這不僅僅是修復，它會儲存無效區塊下的有效標頭，只要有有效的工作量證明和有效的 nTime。 + +Gmaxwell 對警告系統的實用性表示懷疑：已經有太多誤報，而且大多數人一開始就沒有有效使用它。BlueMatt 指出，擁有可靠的警告系統是修復系統信任度的第一步。 + +Sipa 想知道我們是否需要檢測內部共識錯誤，例如資料庫損壞、CPU 過熱等，因為實際上看到的 99.99% 分叉警告只是節點故障。 + +沒有人認為此變更對 0.14 來說很重要。 + +### 會議結論 + +- 更專注於 0.14 的關鍵變更 + +## 0.14 審查優先順序 + +### 背景 + +Bitcoin Core 0.14 [預定](https://github.com/bitcoin/bitcoin/issues/8719)於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +### 會議評論 + +如果審查工作不是瓶頸，人們希望在 0.14 中看到的內容： + +Wumpus 希望看到[具名參數][#8811]。 + +BlueMatt 認為[平行 ProcessMessages][#9488] 對某些使用案例來說是巨大的改進，但如果沒有足夠的時間審查，他會跳過 0.14。 + +Jtimon 希望加入[自訂區塊鏈][#8994]，但懷疑這是否現實。為了效率，[此最佳化][#8498]可能有幫助，但沒有人有時間進行基準測試。 + +Luke-jr 指出有人希望看到多錢包 PR（[#8775][] 和 [#8694][]），以及[忽略/覆寫拒絕][#7533]，但它們沒有標記 0.14 里程碑。 + +Morcos 希望看到區塊中繼改進（[#9375][]、[#9441][] 和 [#9447][]），並可能加入[平行 ProcessMessages][#9488]。[#9441][] 有很多提交，但大多數都很小，以便於審查。 + +Gmaxwell 希望看到多錢包支援（PR [#8775][] 和 [#8694][]）和 [UTXO scriptpubkey 索引][#8660]，儘管後者似乎已被請求者放棄。此外，Morcos 的 [CreateTransaction 變更][#9404]可以修復一些令人擔憂的手續費超額支付邊緣情況，這也很好。 + +Jonasschnelli 認為 [HD chain split][#9294] 也應該進入 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][]）。 + +## 趣聞 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[#9443]: https://github.com/bitcoin/bitcoin/pull/9443 +[#9488]: https://github.com/bitcoin/bitcoin/pull/9488 +[#8994]: https://github.com/bitcoin/bitcoin/pull/8994 +[#8775]: https://github.com/bitcoin/bitcoin/pull/8775 +[#8694]: https://github.com/bitcoin/bitcoin/pull/8694 +[#7533]: https://github.com/bitcoin/bitcoin/pull/7533 +[#8811]: https://github.com/bitcoin/bitcoin/pull/8811 +[#9375]: https://github.com/bitcoin/bitcoin/pull/9375 +[#9441]: https://github.com/bitcoin/bitcoin/pull/9441 +[#9447]: https://github.com/bitcoin/bitcoin/pull/9447 +[#8775]: https://github.com/bitcoin/bitcoin/pull/8775 +[#8694]: https://github.com/bitcoin/bitcoin/pull/8694 +[#8660]: https://github.com/bitcoin/bitcoin/pull/8660 +[#8498]: https://github.com/bitcoin/bitcoin/pull/8498 +[#9404]: https://github.com/bitcoin/bitcoin/pull/9404 +[#9465]: https://github.com/bitcoin/bitcoin/pull/9465 +[#9294]: https://github.com/bitcoin/bitcoin/pull/9294 +[#9371]: https://github.com/bitcoin/bitcoin/pull/9371 +[#9240]: https://github.com/bitcoin/bitcoin/pull/9240 +[#9479]: https://github.com/bitcoin/bitcoin/issues/9479 +[#9027]: https://github.com/bitcoin/bitcoin/issues/9027 +[#9148]: https://github.com/bitcoin/bitcoin/issues/9148 +[#9212]: https://github.com/bitcoin/bitcoin/issues/9212 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-01-12-meeting.md b/_posts/zh_TW/meetings/2017-01-12-meeting.md new file mode 100644 index 000000000..b97ec5ed4 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-01-12-meeting.md @@ -0,0 +1,118 @@ +--- +title: IRC meeting summary for 2017-01-12 +permalink: /zh_TW/meetings/2017/01/12/ +name: 2017-01-12-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-01-12/?msg=79272904&page=4) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.html) + +--- + +## 主要議題 + +- 0.14 功能凍結 + +## 0.14 功能凍結 + +### 背景 + +Bitcoin Core 0.14 [預定](https://github.com/bitcoin/bitcoin/issues/8719)於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +### 會議評論 + +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 版本的舊軟體上使用，可能包括將引入[彈性金鑰路徑][#8723]的 0.15。只要新版本接觸過的錢包不會自動使其不相容，每個人都可以接受。 + +Jonasschnelli 認為 [#9461][]（改進進度顯示）是一個簡單的變更，可以加入 0.14。 + +BlueMatt 意識到他忘記了 [cs_vSend split][#9535]，它包含在 [#9419][]（停止使用 cs_main 處理 CNodeState/State()）中，但本身就是一個巨大的勝利。 + +### 會議結論 + +- 0.14 不做多錢包 +- 審查 [#9484][]、[#9380][]、網路相關：[#9499][]、[#9375][]、[#9441][] 和錢包相關：[#9294][]、[#8456][] +- 取消標記 [#8501][]、[#8654][]、[#8723][] 和 [#8755][] + +## 趣聞 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[#9519]: https://github.com/bitcoin/bitcoin/pull/9519 +[#9512]: https://github.com/bitcoin/bitcoin/pull/9512 +[#9484]: https://github.com/bitcoin/bitcoin/pull/9484 +[#9380]: https://github.com/bitcoin/bitcoin/pull/9380 +[#8456]: https://github.com/bitcoin/bitcoin/pull/8456 +[#8501]: https://github.com/bitcoin/bitcoin/pull/8501 +[#8654]: https://github.com/bitcoin/bitcoin/pull/8654 +[#9375]: https://github.com/bitcoin/bitcoin/pull/9375 +[#9441]: https://github.com/bitcoin/bitcoin/pull/9441 +[#8723]: https://github.com/bitcoin/bitcoin/pull/8723 +[#8755]: https://github.com/bitcoin/bitcoin/pull/8755 +[#9294]: https://github.com/bitcoin/bitcoin/pull/9294 +[#9377]: https://github.com/bitcoin/bitcoin/pull/9377 +[#9419]: https://github.com/bitcoin/bitcoin/pull/9419 +[#9461]: https://github.com/bitcoin/bitcoin/pull/9461 +[#9535]: https://github.com/bitcoin/bitcoin/pull/9535 +[#9499]: https://github.com/bitcoin/bitcoin/pull/9499 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-01-19-meeting.md b/_posts/zh_TW/meetings/2017-01-19-meeting.md new file mode 100644 index 000000000..9d8bcf2c9 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-01-19-meeting.md @@ -0,0 +1,132 @@ +--- +title: IRC meeting summary for 2017-01-19 +permalink: /zh_TW/meetings/2017/01/19/ +name: 2017-01-19-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-01-19/?msg=79637992&page=2) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-19-19.00.html) + +--- + +## 主要議題 + +- 功能凍結 0.14 前的最後合併 +- 錢包同步問題 +- 0.14 的最終警報 + +## 功能凍結 0.14 前的最後合併 + +### 背景 + +Bitcoin Core 0.14 [預定][#8719]於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +### 會議評論 + +[#9535][]（分割 CNode::cs_vSend：訊息處理和訊息發送）得到了一些徹底的審查，將是一個巨大的勝利。 + +[#9461][]（改進進度顯示）已準備好，[#9294][]（HD 分割）需要另一次審查。它有字串變更，因此需要在功能凍結之前完成以便進行翻譯。 + +Gmaxwell 認為 [#9526][]（-blocksonly 應停用與 dbcache 共享記憶體池）應該取消 0.14 標記。BlueMatt 和 Sipa 認為這是錯誤修復，因此可以在功能凍結後合併。 + +0.14 的優先事項是解決剩餘的棘手問題，例如[錢包同步問題][#9584]。 + +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 嘗試[修復][#9570] issue [#9148][]，但結果比預期更複雜。他建議 0.14 採用 [#9583][]（將錢包回呼移入 cs_main（這有效地還原了 [#7946][]）），並在 0.15 進行一系列更大的變更。他對 0.15 的意圖是將這些回呼移到背景執行緒中。 + +### 會議結論 + +- 審查 [#9583][] 作為 0.14 的解決方案 + +## 0.14 的最終警報 + +### 背景 + +比特幣警報系統是受信任方向所有 Core 客戶端廣播有關關鍵網路問題的訊息的一種方式。自 Bitcoin Core 0.13.0 以來已被移除，並且已停用一段時間。 + +警報系統退役的最後一步是將節點硬編碼為向對等節點發送[最終警報](https://bitcoin.org/en/alert/2016-11-01-alert-retirement)，以克服缺乏傳播的問題。 + +### 會議評論 + +現在是發送最終警報的好時機。鑑於之前的警報，不需要延遲或公告。 + +### 會議結論 + +- 發送最終警報訊息（PR [#9594][]） + +## 趣聞 + +{% highlight text %} +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: + +sipa https://cdn.meme.am/cache/instances/folder963/500x/74859963.jpg + +wumpus ok, any other topics? +sipa i propose lunch +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[#9526]: https://github.com/bitcoin/bitcoin/pull/9526 +[#7946]: https://github.com/bitcoin/bitcoin/pull/7946 +[#9570]: https://github.com/bitcoin/bitcoin/pull/9570 +[#9583]: https://github.com/bitcoin/bitcoin/pull/9583 +[#9594]: https://github.com/bitcoin/bitcoin/pull/9594 +[#9108]: https://github.com/bitcoin/bitcoin/pull/9108 +[#9027]: https://github.com/bitcoin/bitcoin/pull/9027 +[#9294]: https://github.com/bitcoin/bitcoin/pull/9294 +[#9461]: https://github.com/bitcoin/bitcoin/pull/9461 +[#9535]: https://github.com/bitcoin/bitcoin/pull/9535 +[#9584]: https://github.com/bitcoin/bitcoin/issues/9584 +[#8719]: https://github.com/bitcoin/bitcoin/issues/8719 +[#9148]: https://github.com/bitcoin/bitcoin/issues/9148 +[#9034]: https://github.com/bitcoin/bitcoin/issues/9034 +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-01-26-meeting.md b/_posts/zh_TW/meetings/2017-01-26-meeting.md new file mode 100644 index 000000000..21191cd97 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-01-26-meeting.md @@ -0,0 +1,119 @@ +--- +title: IRC meeting summary for 2017-01-26 +permalink: /zh_TW/meetings/2017/01/26/ +name: 2017-01-26-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-01-26/?msg=79993062&page=2) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.html) + +--- + +## 主要議題 + +- 程式碼風格 +- 0.14 的錯誤修復 +- 我們對中繼收費是否足夠？ + +## 程式碼風格 + +### 背景 + +程式碼的風格一致性有一些好處： +- 它有助於新來者的貢獻，因為這讓他們更容易確保他們的工作在風格方面是可以的。 +- 它簡化了審查，因為統一性創造了更好的期望，然而重新格式化會使查看歷史記錄更加困難，這損害了審查。 +- 良好的風格選擇有時已被證明可以降低軟體的缺陷率，但對於哪些選擇是好的並沒有普遍的意見。 + +### 會議評論 + +我們目前不要求人們堅持特定的程式碼風格，這導致人們想知道在哪裡使用哪種風格。目前模仿周圍程式碼的建議實際上無助於使程式碼庫收斂。 + +如果我們都在每個修補程式上使用 [clang-format](https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format)，最終我們會收斂。[Clang-format-diff.py](https://github.com/bitcoin/bitcoin/blob/5cf3c60fccb198c16819fcf8a0c5635b5b630496/contrib/devtools/clang-format-diff.py) 是一個自動執行此操作的工具。 + +Jonasschnelli 曾經提議在 Travis 之外進行 CI 檢查，以檢查 clang 風格，但每個人都反對。BlueMatt 反對 CI 檢查，但贊成使用機器人自動開啟 PR，修復最近損壞的 PR 的 clang 風格。Wumpus 不希望僅僅因為風格問題而延遲 PR。 + +僅移動的提交可能不應該更改風格，否則將更難審查它是否真的只是移動。 + +Gmaxwell 的經驗是，像程式碼風格挑剔這樣的小事會改善開發團隊的士氣。這是一個互相幫助的機會，非常簡單明確，而不是「請完全重新設計你的修補程式」。 + +### 會議結論 + +- 能夠在 PR 中指出與[風格指南](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md)衝突的風格問題。 +- 盡可能在提交修補程式之前使用 [Clang-format-diff.py](https://github.com/bitcoin/bitcoin/blob/5cf3c60fccb198c16819fcf8a0c5635b5b630496/contrib/devtools/clang-format-diff.py)。 +- 不要在僅移動的提交中更改風格 + +## 0.14 的錯誤修復 + +### 背景 + +Bitcoin Core 0.14 [預定][#8719]於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +### 會議評論 + +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」，它設定記憶體池限制或[選擇性手續費替換](/en/faq/optin_rbf/)替換的最低費率增加，設定為每位元組 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[#9615]: https://github.com/bitcoin/bitcoin/pull/9615 +[#9638]: https://github.com/bitcoin/bitcoin/pull/9638 +[#9626]: https://github.com/bitcoin/bitcoin/pull/9626 +[#9622]: https://github.com/bitcoin/bitcoin/pull/9622 +[#9609]: https://github.com/bitcoin/bitcoin/pull/9609 +[#9108]: https://github.com/bitcoin/bitcoin/pull/9108 +[#9589]: https://github.com/bitcoin/bitcoin/pull/9589 +[#8719]: https://github.com/bitcoin/bitcoin/issues/8719 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-02-02-meeting.md b/_posts/zh_TW/meetings/2017-02-02-meeting.md new file mode 100644 index 000000000..c0dc3fd29 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-02-02-meeting.md @@ -0,0 +1,126 @@ +--- +title: IRC meeting summary for 2017-02-02 +permalink: /zh_TW/meetings/2017/02/02/ +name: 2017-02-02-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-02-02/?msg=80352895&page=2) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.html) + +--- + +## 主要議題 + +- 0.14 RC1 發布 +- 程式碼風格 + +## 0.14 RC1 發布 + +### 背景 + +Bitcoin Core 0.14 [預定][#8719]於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +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 提出了一個解決方法，透過對型別進行不相容的變更並重新編譯，以便使用它的所有地方都變得可見。討論從[這裡](https://github.com/bitcoin/bitcoin/pull/9609#discussion_r98335218)開始。 + +Wumpus 建議記錄使用「auto」不好或危險的特定情況。 + +使用 auto 的優點，除了它取代了大量要輸入的文字之外，是當你將元組變成結構或新增包裝器時，你不需要到處更改東西。 + +Gmaxwell 補充說另一個負面方面是 auto 使你能夠在對型別毫不知情的情況下編寫對型別起作用的程式碼，這在 99% 的情況下是安全的，其餘情況則是致命的，因為在 C++ 中，並非所有在型別上分類不安全的操作實際上都被型別檢查阻止。儘管這是一個邊緣情況，但這是需要記住的。 + +當你有一些可怕的複雜簽名時，Auto 很有趣，但這些也是更成問題的情況。Sipa 指出，這些使用案例的最佳實踐是為其引入 typedef，這也缺少 BlueMatt 的審查擔憂。 + +### 會議結論 + +- 逐案考慮「auto」的使用。 + +## 趣聞 + +{% highlight text %} +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! +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. +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[#9671]: https://github.com/bitcoin/bitcoin/pull/9671 +[#8719]: https://github.com/bitcoin/bitcoin/issues/8719 +[#9027]: https://github.com/bitcoin/bitcoin/issues/9027 +[#9491]: https://github.com/bitcoin/bitcoin/issues/9491 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-02-09-meeting.md b/_posts/zh_TW/meetings/2017-02-09-meeting.md new file mode 100644 index 000000000..edb41e34a --- /dev/null +++ b/_posts/zh_TW/meetings/2017-02-09-meeting.md @@ -0,0 +1,89 @@ +--- +title: IRC meeting summary for 2017-02-09 +permalink: /zh_TW/meetings/2017/02/09/ +name: 2017-02-09-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-02-09/?msg=80720449&page=2) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-09-19.01.html) + +--- + +## 主要議題 + +- 0.14 RC1 發布 + +## 0.14 RC1 發布 + +### 背景 + +Bitcoin Core 0.14 [預定][#8719]於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +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 件事需要[勾選][#8455]。 + +發布說明目前建議希望保留挖礦「優先順序」排序的礦工執行 Bitcoin Knots。推薦未經本專案開發者審查的其他分支沒有太大意義。Gmaxwell 認為推薦相容的分支來支援我們不關心支援的功能是可以的，但他認為我們不應該推薦使用優先順序。 + +### 會議結論 + +- 更新靜態種子 IP 列表 +- 更新 release-process.md 以包含 chainTxData 更新 +- 取消 issue [#9392][] 的 0.14 標記 +- 完成[發布說明][#8455] +- 從發布說明中移除 Bitcoin Knots 推薦 + +## 趣聞 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[#9698]: https://github.com/bitcoin/bitcoin/pull/9698 +[#9715]: https://github.com/bitcoin/bitcoin/pull/9715 +[#9720]: https://github.com/bitcoin/bitcoin/pull/9720 +[#9708]: https://github.com/bitcoin/bitcoin/pull/9708 +[#9472]: https://github.com/bitcoin/bitcoin/pull/9472 +[#8719]: https://github.com/bitcoin/bitcoin/issues/8719 +[#9392]: https://github.com/bitcoin/bitcoin/issues/9392 +[#8455]: https://github.com/bitcoin/bitcoin/issues/8455 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-02-16-meeting.md b/_posts/zh_TW/meetings/2017-02-16-meeting.md new file mode 100644 index 000000000..c6d61772d --- /dev/null +++ b/_posts/zh_TW/meetings/2017-02-16-meeting.md @@ -0,0 +1,190 @@ +--- +title: IRC meeting summary for 2017-02-16 +permalink: /zh_TW/meetings/2017/02/16/ +name: 2017-02-16-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-02-16/?msg=81092667&page=3) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-16-19.02.html) + +--- + +## 主要議題 + +- 0.14.0RC1 發布 +- 隨機性 +- 時鐘 + +## 0.14.0RC1 發布 + +### 背景 + +Bitcoin Core 0.14.0 [預定][#8719]於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已[標記 0.14 標籤](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0)。 + +### 會議評論 + +普遍認為發布準備度在過去兩週內顯著改善，第一個候選版本（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 個。」 + +1. FastRandomContext：目前需要 1.5 奈秒，但不是密碼學安全的偽隨機數生成器（[CSPRNG][]）。 + +1. GetRandBytes：一個 CSPRNG。 + +1. GetStrongRandBytes：「用於私鑰。如果一切順利，它與 getrandbytes 一樣安全，但它更偏執，」Wuille 解釋道。 + +### 評論 + +Wuille 提議使用 [ChaCha20][] 加密演算法使 GetRandBytes 非常快速，Linux 4.8 切換到在其 `/dev/urandom` 中使用它。一旦 GetRandBytes 快速，它也可以用來取代 FastRandomContext。 + +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 個區塊的中位時間戳的時間戳，從而提供單調時鐘（注意：有此處未討論的限制）。 + +### 評論 + +與使用不可轉換時間的主題相關，Wladimir van der Laan 建議「最重要的是，我們應該開始在網路程式碼中盡可能使用單調時間戳」。 + +Gregory Maxwell 說：「我過去曾建議我們考慮建構一個單調的本地時鐘，但 [Wladimir] 似乎不喜歡這個想法。我認為這與型別安全性問題是正交的，但它可能會使程式碼庫中的時間更加合理。」 + +Wladimir 回答：「嗯，我完全贊成在可能的情況下使用單調時鐘，它們只是不適合所有情況。」 + +使用單調時鐘的討論就此結束。本摘要的作者懷疑，當關於時間單位型別安全的其他工作取得進展時，將再次討論它。 + +### 結論 + +沒有結論。 + +## 小主題 + +### 重新排列與測試相關的事項 + +描述了對測試的次要變更願望清單： + +- Jonas Schnelli 提議重新命名一些目錄，以幫助 GitHub 使用者新進專案的人找到最有用的測試。 + +- Pieter Wuille 建議進行一些額外的重新排列，透過分解出為不再使用的測試工具新增的目錄來提高生產力。 + +- Gregory Maxwell 建議將一些更耗時的測試作為標準編譯序列的一部分執行。 + +- Wladimir van der Laan 抱怨 RPC 測試的命名錯誤，因為它們今天測試的不僅僅是 RPC 介面（許多測試使用 RPC 介面來測試系統的其餘部分是否按預期運作）。 + +Schnelli 自願在 0.14 分割到單獨的 git 分支後建立一個 pull request 到主分支。 + +## 趣聞 + +{% highlight text %} + i think it is a mistake to call it experimental + we don't want to devalue the meaning of that word + + ok... + + sometimes we may want to have things that are actually experimental and we don't want people to think we just always say that + + "this feature is experimental level 4" + + this is known to the state of CA to be experimental +{% endhighlight %} + +{% highlight text %} + i'd briefly like to talk about randomness + + that's random. + + we currently have 3 "levels" of randomness + + we need a random number of levels of randomness +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[ChaCha20]: https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant +[CSPRNG]: https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator +[#8719]: https://github.com/bitcoin/bitcoin/issues/8719 +[#9760]: https://github.com/bitcoin/bitcoin/issues/9760 +[#9761]: https://github.com/bitcoin/bitcoin/issues/9761 +[#9773]: https://github.com/bitcoin/bitcoin/issues/9773 +[#9619]: https://github.com/bitcoin/bitcoin/issues/9619 diff --git a/_posts/zh_TW/meetings/2017-02-23-meeting.md b/_posts/zh_TW/meetings/2017-02-23-meeting.md new file mode 100644 index 000000000..2d5628586 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-02-23-meeting.md @@ -0,0 +1,173 @@ +--- +title: IRC meeting summary for 2017-02-23 +permalink: /zh_TW/meetings/2017/02/23/ +name: 2017-02-23-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 + +--- +{% include toc.html %} +{% include references.md %} + +- [本週日誌連結](https://botbot.me/freenode/bitcoin-core-dev/2017-02-23/?msg=81448642&page=3) +- [會議紀錄（meetbot 版本）](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-23-19.00.html) + +--- + +## 主要議題 + +- Git 和 SHA1 碰撞 +- Bitcoin Core 0.14.0 發布 +- Travis CI 問題 +- 程式碼重組 + +## Git 和 SHA1 碰撞 + +### 背景 + +在會議開始前幾個小時，幾位研究人員[宣布](http://shattered.io/)他們首次產生了兩個不同檔案在使用 SHA1 雜湊函數時具有相同雜湊的案例（這種情況稱為雜湊碰撞）。 + +Bitcoin Core 和許多其他專案使用的 Git 版本控制系統使用 SHA1 雜湊來允許人們確保他們都擁有完全相同的程式碼。產生 SHA1 碰撞的能力破壞了這種保證。 + +多年來，安全社群的許多成員一直要求 Git 從 SHA1 更改為 SHA256 或另一個更安全的雜湊函數，但 Git 開發者強烈抵制這種變更（可能是因為它不向後相容，這意味著所有 Git 使用者可能需要在大致相同的時間升級）。 + +### 評論 + +討論最初集中在澄清情況的嚴重性，然後轉向描述 Bitcoin Core 專案在等待 Git 開發者發布更安全的程式時可以處理問題的潛在方法。提出的解決方案包括： + +- 「我想知道建立一個回溯歷史的覆蓋層有多困難，為每個樹和提交計算 sha256，然後包含對這些的 gpg 簽名？」（Pieter Wuille） + +- 「我們可以更新我們的開發腳本，對所有提交的檔案執行 sha256sum 並對其進行簽名 [...] 例如，合併腳本可以在提交訊息中包含 sha256sum \* 的雜湊」（Matt Corallo）。Gregory Maxwell 在大約同一時間提出了非常類似的建議。 + +- 「我有一個 git 的修補程式，使用 [[sha1collissiondetect](https://github.com/cr-marcstevens/sha1collisiondetection)] 作為雜湊函數，如果它檢測到可能不良的雜湊就 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][] 的發布說明中。 + +[PR#9787]: https://github.com/bitcoin/bitcoin/pull/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 的資源限制。 + +### 評論 + +在會議前約一週，測試執行檔 `test_bitcoin` 在 Travis CI 測試期間開始間歇性失敗。開啟了 [Issue 9825][] 來診斷問題並研究解決方案。 + +會議評論集中在測試程式碼如何為建置日誌建立堆疊追蹤，以及如何變更測試以從 Travis 獲取可執行檔、核心傾印和其他建置和測試工件以供開發者分析。 + +### 結論 + +繼續調查失敗，隔離問題並努力修復它。 + +## 程式碼重組 + +### 背景 + +許多經濟全節點使用 Bitcoin Core 來強制執行共識規則。其他程式將受益於重用 Bitcoin Core 用於確保它們符合共識規則的相同程式碼，因此幾位開發者一直在努力使 Bitcoin Core 程式碼庫更加模組化，以便其部分可以在其他程式中使用。 + +儘管使程式碼庫更加模組化的目標得到了專案貢獻者的充分支援，但實際移動程式碼往往會破壞其他開發者的待處理變更，並消耗專家審查 Bitcoin Core 變更的有限時間---同時不提供新功能或效能改進。這使得程式碼移動成為團隊討論的好主題，以便可以提前商定變更，以盡量減少干擾。 + +### 評論 + +Jeremy Rubin 開始：「我有一個[概念驗證]分支，它將大部分純資料結構移動到資料結構目錄。」他補充說：「非比特幣特定的[資料結構]。例如，prevector。」 + +Gregory Maxwell 回答：「我認為我們都不關心為其他用途維護像 prevector 這樣的東西。製作一個好的函式庫需要大量的工作。」 + +Wladimir van der Laan 同意：「我不認為 bitcoin-datastructures 函式庫有意義。如果我們提供函式庫，它應該是對比特幣使用者有用的東西。」 + +### 結論 + +會議期間沒有明確的結論（會議在這個主題上沒時間了）。會議結束後討論繼續進行，Maxwell 和 Wladimir van der Laan 擴展了他們的觀點。 + +## 趣聞 + +{% highlight text %} + or syncs are roughly XYZ% faster... + use the ~ and nobody will blame you afterwards. :) + + use two ~~ to be extra approximate + + it's marketing not science :p hehe + + but ~~ will just give you the same number you put in! + + The is-approximately operator is non-involutive ;) + + 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 +{% endhighlight %} + +--- + +{% highlight text %} + sipa: e.g. someday libstdc++ could get something that generalizes prevector, if it did, we'd drop prevector and use that. + + c++23 + + sipa: C++23 will just integrate libconsensus of course. template cryprocurrency. +{% endhighlight %} + +## 參與者 + +| 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][] | + + +## 免責聲明 + +本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。 + +[Issue 9825]: https://github.com/bitcoin/bitcoin/issues/9825 +[PR#9829]: https://github.com/bitcoin/bitcoin/issues/9829 diff --git a/_posts/zh_TW/meetings/2017-03-02-meeting.md b/_posts/zh_TW/meetings/2017-03-02-meeting.md new file mode 100644 index 000000000..323090710 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-03-02-meeting.md @@ -0,0 +1,247 @@ +--- +title: IRC meeting summary for 2017-03-02 +permalink: /zh_TW/meetings/2017/03/02/ +name: 2017-03-02-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-03-02/?msg=81834029&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.html) + +--- + +## 主要議題 + +- 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 日會議期間的[討論][removing checkpoints]，以及 [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 啟動後給予礦工一個選擇： + +1. 礦工可以像現在一樣生產舊式區塊，但這些區塊不能包含任何 segwit 交易（因此礦工可能會收到較少的交易手續費）。 + +2. 礦工可以生產 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][draft BIP]，以減少無驗證挖礦對輕客戶端安全的損害。Corallo 贊成：「我認為當我們回傳空區塊時，我們應該實作那個 :) 我很樂意在輕客戶端中實作它。」 + +此時討論回到技術細節，專注於挖礦軟體如何處理 Bitcoin Core 回傳的空區塊以及礦池軟體回傳的空區塊。 + +### 結論 + +沒有明確的結論。所有在場的開發者似乎都致力於改善情況，但沒有人直接贊成 #9858 或 #9859 中的解決方案。會議後約 10 分鐘，這些 PR 的作者在 IRC 上變得可用，並開始與開發者討論可以進行的潛在短期優化，同時進行更重要（但長期）的工作。 + +## 議題：（空白） + +在前面關於在急需結果時生成空區塊模板的對話期間，Pieter Wuille 提醒大家會議只剩 5 分鐘用於其他議題，導致 Gregory Maxwell 匆忙建議「空訊息」的議題。關於這個議題的整個討論在下面的幽默時刻部分轉述。 + +## 幽默時刻 + +{% highlight text %} + we're running out of time + any other topics? + + quick, empty messages + + + + + + + + + + inb4 trolls use this as proof we obey gmaxwell + + + + lulwut + + #topic + + it's "lolwut", BlueMatt. + + lulzwutz + + cleared the topic, too, now we can cleanly exit the meeting + + We should appoint a subcommittee to investigate the spelling of lolwut/lulwut. + + #endmeeting +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#9602]: https://github.com/bitcoin/bitcoin/pull/9602 +[#8775]: https://github.com/bitcoin/bitcoin/pull/8775 +[#9858]: https://github.com/bitcoin/bitcoin/pull/9858 +[#9859]: https://github.com/bitcoin/bitcoin/pull/9859 +[draft BIP]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011853.html +[critical path]: https://en.wikipedia.org/wiki/Critical_path_method +[nLockTime]: https://bitcoin.org/en/glossary/locktime +[Bitcoin 0.3.2]: https://bitcointalk.org/index.php?topic=437 +[removing checkpoints]: https://botbot.me/freenode/bitcoin-core-dev/2016-10-27/?msg=75584824&page=5 +[IBD using chainwork]: https://github.com/bitcoin/bitcoin/pull/9053 +[assumed valid blocks]: /en/2017/03/08/release-0.14.0/#assumed-valid-blocks diff --git a/_posts/zh_TW/meetings/2017-03-09-meeting.md b/_posts/zh_TW/meetings/2017-03-09-meeting.md new file mode 100644 index 000000000..35e39b5a8 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-03-09-meeting.md @@ -0,0 +1,117 @@ +--- +title: IRC meeting summary for 2017-03-09 +permalink: /zh_TW/meetings/2017/03/09/ +name: 2017-03-09-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-03-09/?msg=82192588&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.html) + +--- + +## 主要議題 + +- 0.14.0 版本發布 +- 警報金鑰披露時間表 +- 下一個版本 + +## 0.14.0 版本發布 + +Bitcoin Core 0.14.0 在會議前一天發布。大家分享了對成功發布的歡呼和祝賀。 + +## 警報金鑰披露時間表 + +### 背景 + +在 Bitcoin 0.3.11 中引入的 Bitcoin 警報系統已在過去幾個 Bitcoin Core 版本中逐步淘汰。更多資訊，請參見[公開資訊聲明][alert retirement]。 + +在較早的 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。 + +## 幽默時刻 + +{% highlight text %} + There are also funds paid to the alert key in the network, I believe + 0.01 BTC or so. :P + + surprised no one ever swiped that +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[alert retirement]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement +[#9959]: https://github.com/bitcoin/bitcoin/issues/9959 +[#9955]: https://github.com/bitcoin/bitcoin/issues/9955 +[#9961]: https://github.com/bitcoin/bitcoin/issues/9961 diff --git a/_posts/zh_TW/meetings/2017-03-16-meeting.md b/_posts/zh_TW/meetings/2017-03-16-meeting.md new file mode 100644 index 000000000..13a6c0679 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-03-16-meeting.md @@ -0,0 +1,161 @@ +--- +title: IRC meeting summary for 2017-03-16 +permalink: /zh_TW/meetings/2017/03/16/ +name: 2017-03-16-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-03-16/?msg=82545921&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-16-19.01.html) + +--- + +## 主要議題 + +- 錢包應如何處理長鏈未確認交易 +- 移除帳戶系統的狀態 +- 修訂 `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 [引入][accounts intro]了一個帳戶系統，允許單個 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 測試 + +### 背景 + +Bitcoin Core 提供了一個 makefile 目標 `check` 來執行專案的單元測試。該專案隨著時間推移編寫了越來越多通過 RPC 介面執行的整合測試，這些測試由 Travis 持續整合（CI）伺服器自動執行，該伺服器測試每個 Bitcoin Core pull request，可以通過執行 `qa/pull-tester/rpc-tests.py` 手動執行 + +### 討論 + +Jonas Schnelli 問：「將 rpc 加入到 `make check` 有什麼好處？」 + +Wladimir van der Laan 回答：「`make check` 理想上應該進行相當快速的檢查，一些 RPC 測試符合這個條件，但整個套件可能需要太長時間。」 + +討論繼續確保 `make check` 執行速度合理快，包括增加在多個 CPU 核心上執行它的能力。 + +## 結論 + +John Newberry 總結：「好的，聽起來至少在 make check 中進行一些 RPC 測試沒有根本性的反對。我會開啟一個 PR，我們可以在那裡繼續討論。」 + +## 幽默時刻 + +{% highlight text %} + gmaxwell: yup. don't know if you saw the clang fsafe-stack + issue that messes up deterministic signing + + wumpus: I didn't. + + gmaxwell: let me dig it up + gmaxwell: https://github.com/bitcoin-core/secp256k1/issues/445 + + wumpus: holy fuck! +{% endhighlight %} + +（上述內容的背景：Bitcoin Core 和 libsecp256k1 的測試發現了編譯器中引入的錯誤，可能會造成嚴重問題。） + +{% highlight text %} + 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. + + unfortunately we're stuck with malleability + + not if we use flextrans + (sorry) + + hah + + heh + + flextrans, lol + + trolol +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[accounts intro]: https://github.com/bitcoin/bitcoin/commit/e4ff4e6898d378b1a3e83791034a7af455fde3ab +[PR#9294]: https://github.com/bitcoin/bitcoin/issues/9294 +[PR#8694]: https://github.com/bitcoin/bitcoin/issues/8694 diff --git a/_posts/zh_TW/meetings/2017-03-23-meeting.md b/_posts/zh_TW/meetings/2017-03-23-meeting.md new file mode 100644 index 000000000..76b466696 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-03-23-meeting.md @@ -0,0 +1,162 @@ +--- +title: IRC meeting summary for 2017-03-23 +permalink: /zh_TW/meetings/2017/03/23/ +name: 2017-03-23-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-03-23/?msg=82894270&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.html) + +--- + +## 主要議題 + +- Segwit 地址提案 +- 錢包中的 DER 私鑰 +- 反對二進位發布的聲明 +- 被封鎖和需要審查的 PR + +## Segwit 地址提案 + +### 背景 + +Pieter Wuille 和 Gregory Maxwell 最近[提出][sw addr bip]了一個用於原生隔離見證（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:260 [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。會議中沒有就使用專案看板或標籤進行請求的審查做出決定。 + +## 幽默時刻 + +{% highlight text %} + proposed topics? + + holiday at the beach? + + btcdrak: that's what the financial crypto conference is for +{% endhighlight %} + + +{% highlight text %} + rationale section was good, although i think it would be worthwhile to + describe the 'exhaustive search' + + kanzure: we left out a lot of technical minutia about the construction + which is interesting but not really relevant to the spec. + + earlier version explained finite field arithmetic and generator polynomials :) +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#9725]: https://github.com/bitcoin/bitcoin/pull/9725 +[#9294]: https://github.com/bitcoin/bitcoin/pull/9294 +[#9959]: https://github.com/bitcoin/bitcoin/pull/9959 +[sw addr bip]: https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki diff --git a/_posts/zh_TW/meetings/2017-03-30-meeting.md b/_posts/zh_TW/meetings/2017-03-30-meeting.md new file mode 100644 index 000000000..072953b4e --- /dev/null +++ b/_posts/zh_TW/meetings/2017-03-30-meeting.md @@ -0,0 +1,124 @@ +--- +title: IRC meeting summary for 2017-03-30 +permalink: /zh_TW/meetings/2017/03/30/ +name: 2017-03-30-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-03-30/?msg=83238145&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.html) + +--- + +## 註記 / 短議題 + +- BlueMatt 注意到上週[被封鎖和需要審查的 PR](/en/meetings/2017/03/23/#blocked-and-review-needed-prs) 中 6 個有 2 個被合併，可以做得更好。Wumpus 為會議中提到具有優先級的 PR 創建了一個[高優先級審查](https://github.com/bitcoin/bitcoin/projects/8) github 專案頁面。 +- 已有 11 個合併標記為 [0.14.1](https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.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](/en/meetings/2017/03/16/#revising-make-check-tests) 會議中討論的，這些測試作為整體目前可能需要太長時間。 + +### 會議意見 + +Wumpus 製作了一個最慢單元測試的[概覽][#10026]。其中一些已經被處理或有 PR 使它們更快。 + +我們也可以為單元測試引入一個 -extended 模式，它會進行額外徹底的測試，不應該每次都執行。擴展模式應該是發布程序的一部分（並由 gitian 執行）和/或在 master 上每天執行一次。 + +Jonasschnelli 有一個具有良好網頁 UI 的建置伺服器，每天在 [https://bitcoin.jonasschnelli.ch/](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 補充說，他想為網路訊息做類似的事情。 + +## 幽默時刻 + +{% highlight text %} +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 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: 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, ok, soooo, acks on: 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! +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10026]: https://github.com/bitcoin/bitcoin/issues/10026 +[#10114]: https://github.com/bitcoin/bitcoin/pull/10114 +[#10072]: https://github.com/bitcoin/bitcoin/pull/10072 +[#9792]: https://github.com/bitcoin/bitcoin/pull/9792 +[#9424]: https://github.com/bitcoin/bitcoin/pull/9424 +[#10123]: https://github.com/bitcoin/bitcoin/pull/10123 +[#9208]: https://github.com/bitcoin/bitcoin/pull/9208 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-04-06-meeting.md b/_posts/zh_TW/meetings/2017-04-06-meeting.md new file mode 100644 index 000000000..eda926782 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-04-06-meeting.md @@ -0,0 +1,90 @@ +--- +title: IRC meeting summary for 2017-04-06 +permalink: /zh_TW/meetings/2017/04/06/ +name: 2017-04-06-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-04-06/?msg=83564974&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-06-19.02.html) + +--- + +## 註記 / 短議題 + +- 許多開發者參加了金融密碼學會議，因此這是一個簡短的會議。 +- 0.14.1 RC1 已被標記，gitian 建置正在進行中 +- Jtimon 在[待辦事項列表][#7829]中新增了更多想法，旨在讓 Bitcoin Core 專案的新開發者熟悉為 Bitcoin Core 貢獻。 + +## 主要議題 + +- 進行中的工作 +- 高優先級審查 + +## 進行中的工作 + +### 背景 + +由於許多開發者由於金融密碼學會議而缺席或未專注於會議，Sdaftuar 詢問是否有人想提供他們正在進行的工作的更新，以獲得一些概覽並開始對話。 + +### 會議意見 + +- Luke-jr 正在進行一個按 scriptPubKey 的 UTXO 索引以用於清掃目的。Wumpus 指出 PR [#9806][] 正在嘗試做同樣的事情。 +- Jonasschnelli 正在進行一個 Bloom Filter Digest，他希望在 [2016-11-10 會議](/en/meetings/2016/11/10/#hybrid-spv)中談到的混合全區塊 SPV 模式中使用它。 +- Sipa 一直在進行與資料庫/快取/刷新/記憶體使用相關的工作。 +- Morcos 數月來一直在編碼和重新編碼手續費估算，但它要複雜得多，而且會很難審查。 +- Sdaftuar 一直在進行 CreateNewBlock 的工作，引入一種方法，如果這樣做的區塊收入低於某個閾值，則跳過最近新增的交易。 +- Jtimon 進行了一些重構 PR，如 [#9494][]、[#10119][] 和 [#10118][] + +## 高優先級審查 + +Github 上的[高優先級審查專案](https://github.com/bitcoin/bitcoin/projects/8)。 + +Jtimon 認為 PR [#7729][]（為錢包引入 'label' API）應該加入到優先級列表，因為它阻礙了帳戶系統的移除。Wumpus 同意，但注意到人們應該審查 API，而不是程式碼，因為現在已經過時了。 + +## 幽默時刻 + +{% highlight text %} +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? +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#7829]: https://github.com/bitcoin/bitcoin/issues/7829 +[#10118]: https://github.com/bitcoin/bitcoin/pull/10118 +[#10119]: https://github.com/bitcoin/bitcoin/pull/10119 +[#7729]: https://github.com/bitcoin/bitcoin/pull/7729 +[#9806]: https://github.com/bitcoin/bitcoin/pull/9806 +[#9494]: https://github.com/bitcoin/bitcoin/pull/9494 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-04-13-meeting.md b/_posts/zh_TW/meetings/2017-04-13-meeting.md new file mode 100644 index 000000000..4dbadd995 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-04-13-meeting.md @@ -0,0 +1,163 @@ +--- +title: IRC meeting summary for 2017-04-13 +permalink: /zh_TW/meetings/2017/04/13/ +name: 2017-04-13-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-04-13/?msg=83979451&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.html) + +--- + +## 註記 / 短議題 + +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](https://bitcoin.org/bin/bitcoin-core-0.14.1/test.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 [計劃][#9961]在 2017 年 9 月左右發布。針對 0.15 的 Pull request 都[標記為 0.15.0 標籤](https://github.com/bitcoin/bitcoin/milestone/25)。 + +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' 中執行功能測試）進行一些審查 + +## 幽默時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10176]: https://github.com/bitcoin/bitcoin/pull/10176 +[#10193]: https://github.com/bitcoin/bitcoin/pull/10193 +[#10189]: https://github.com/bitcoin/bitcoin/pull/10189 +[#10179]: https://github.com/bitcoin/bitcoin/pull/10179 +[#10178]: https://github.com/bitcoin/bitcoin/pull/10178 +[#10102]: https://github.com/bitcoin/bitcoin/pull/10102 +[#9792]: https://github.com/bitcoin/bitcoin/pull/9792 +[#9942]: https://github.com/bitcoin/bitcoin/pull/9942 +[#10044]: https://github.com/bitcoin/bitcoin/pull/10044 +[#9961]: https://github.com/bitcoin/bitcoin/issues/9961 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-04-20-meeting.md b/_posts/zh_TW/meetings/2017-04-20-meeting.md new file mode 100644 index 000000000..469e80122 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-04-20-meeting.md @@ -0,0 +1,122 @@ +--- +title: IRC meeting summary for 2017-04-20 +permalink: /zh_TW/meetings/2017/04/20/ +name: 2017-04-20-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-04-20/?msg=84291532&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-20-19.02.html) + +--- + +## 註記 / 短議題 + +- 沒有報告 RC2 的問題，0.14.1 應該發布。（0.14.1 在會議後 2 天[發布](/en/2017/04/22/release-0.14.1/)） + +- 在 github 中有一些關於錢包處理地址重複使用和粉塵的有趣討論。任何對該主題感興趣的人可能想查看 PR [#10233][] 上的討論以及從那裡連結的 PR。 + +## 主要議題 + +- 手續費估算 +- 地址重複使用 +- 高優先級審查 + +## 手續費估算 + +### 背景 + +在 Bitcoin Core 錢包中，你可以選擇希望看到交易確認的區塊數量，錢包將根據節點記憶池中交易的手續費率估算適當的手續費率。網路上的交易數量每日和每週都有很大變化，這使得這成為一個困難的平衡練習，既要確保交易在定義的時間範圍內得到確認，又要試圖讓使用者支付最小的手續費。 + +Morcos 一直在改進手續費估算演算法，並且根據[上週會議](/en/meetings/2017/04/13/#meeting-comments-2)的要求，撰寫了新手續費估算演算法的[高層次描述](https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41)。 + +### 會議意見 + +Morcos 在 [#10199][] 中寫了一堆改進，但也有一些他想要反饋的開放問題。將改進的另一部分加入到更高層次的描述中是有意義的。手續費估算器足夠複雜，我們應該維護一個單獨的描述，甚至可能像許多主要協定功能一樣有一個實際的規範。 + +Gmaxwell 注意到該文件可能需要更多關於可靠性估算以及它如何合併桶的細節。總的來說，他補充說，我們應該嘗試使其足夠詳細，以便如果學術界出現並僅根據描述撰寫論文（他們會這樣做），結果對我們有用。 + +Morcos 也有一個計劃將估算器從記憶池中解耦，這建立在 BlueMatt 的 [CValidationInterface][#10179] 之上。 + +Gmaxwell 認為我們應該嘗試在未來保存更多的狀態，例如他有些節點每月停機時間不超過幾分鐘，但無法達到進行最準確手續費估算所需的兩週運行時間。 + +Jonasschnelli 想知道啟動後估算的可用速度有多快，以及它是否適用於修剪節點。Morcos 澄清修剪是無關的，對於 N 個區塊的目標，它需要至少 2*N 個區塊才能給你一個估算。之後它會保存資料，所以你可以重新啟動節點並立即獲得手續費估算。 + +### 會議結論 + +- Morcos 將向 [gist 文件](https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41)加入新的變更和澄清。 + +## 地址重複使用 + +### 背景 + +由於會議還有時間，開發者開始談論地址重複使用問題和可能的解決方案。 + +一個已經被積極利用了很長時間的隱私問題是，人們向已經花費過的地址進行接近粉塵的支付，這樣你再次從它們花費，在新交易中創建一個雪球效應，將你的所有交易連結在一起。 + +### 會議意見 + +Gmaxwell 注意到最新的討論是由一個經營賭博網站的使用者推動的，他關心這個，因為他的客戶收到了連結回他的交易。然而，這對每個人來說都是一個隱私問題。 + +Gmaxwell 修復這個問題的建議是創建一個單獨的隔離餘額，其中任何地址或特定 TXO 可以手動隔離。然後調整硬幣選擇演算法以始終一次性花費對特定地址的所有支付。一旦地址被花費過，自動將其加入到隔離餘額中。 + +Wumpus 和 BlueMatt 喜歡這個想法，但不確定是否將其作為預設策略。BlueMatt 舉了一個可能的問題的例子，商家收到一半的付款，從該地址花費，收到另一半，但沒有意識到他得到了付款，因為資金會被隔離。Morcos 喜歡自動隔離的想法，但不太認同預設花費所有輸入的想法。 + +Gmaxwell 認為如果最終目標不是將其作為預設，資源投資是不值得的。Wumpus 認為如果我們認為無論如何都有用，這是值得的。 + +### 會議結論 + +- 作為第一步，在硬幣選擇演算法中引入從給定地址自動花費所有資金。 + +## 高優先級審查 + +- PR [#10148][]（使用非原子刷新進行區塊重放）在其目前的形式下，沒有多頭，只需要更多審查，也許還需要更多測試。 +- Luke-jr 注意到 [multiwallet][#8694] 已經 rebase，nits 已經修復。CWalletDB 仍然需要一些認真的重構，但這應該在不同的 PR 中完成。 + +## 幽默時刻 + +{% highlight text %} +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! +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10233]: https://github.com/bitcoin/bitcoin/pull/10233 +[#10148]: https://github.com/bitcoin/bitcoin/pull/10148 +[#8694]: https://github.com/bitcoin/bitcoin/pull/8694 +[#10199]: https://github.com/bitcoin/bitcoin/pull/10199 +[#10179]: https://github.com/bitcoin/bitcoin/pull/10179 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-04-27-meeting.md b/_posts/zh_TW/meetings/2017-04-27-meeting.md new file mode 100644 index 000000000..3dd945e68 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-04-27-meeting.md @@ -0,0 +1,144 @@ +--- +title: IRC meeting summary for 2017-04-27 +permalink: /zh_TW/meetings/2017/04/27/ +name: 2017-04-27-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-04-27/?msg=84825928&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.html) + +--- + +## 註記 / 短議題 + +- BlueMatt 有一個[PR][#10279]準備好了,這是邁向 libconsensus 的另一步。它將 CChainState 類別加入到 validation.cpp,它將持有像 mapBlockIndex chainActive 等東西 + +## 主要議題 + +- HD 錢包自動恢復 +- NODE_NETWORK_LIMITED +- bitcoind 過期 + +## HD 錢包自動恢復 + +### 背景 + +Bitcoin Core 自 0.13 版以來擁有階層式確定性錢包（HD wallet/[BIP32][]）。HD 錢包是一個系統，它從一個稱為「種子」的單一起點派生所有金鑰。這允許使用者只需備份一次錢包，所有未來生成的金鑰都可以從種子重新生成。 + +為了加快審查和部署，Bitcoin Core 中 HD 錢包的第一個版本被做得很簡單，沒有太多花俏的功能。現在正在向錢包加入新功能，例如這個 [HD 錢包自動恢復][#10240]，它確保在與節點同步時始終檢查金鑰池，並且它搜尋的未使用金鑰數量足夠大。 + +### 會議意見 + +[PR][#10240] 的作者 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 [建議][#10282]讓 bitcoind 和 bitcoin-qt 在 7-8 年沒有更新後過期。假設在 7 年內軟體將變得過時，因為軟分叉和可能的硬分叉將使其不安全，以及在此期間的漏洞利用。 + +它還會提供某種確定性，舊節點將在截止日期前結束，使任何硬分叉變成軟分叉，前提是它在 8 年前計劃。 + +### 會議意見 + +Luke-jr 澄清它允許明確覆蓋，所以如果人們願意，他們可以在過期日期之後使用軟體。 + +Petertodd 認為任何足夠短以真正有用的時間範圍可能都足夠短以引發政治風險。 + +BlueMatt 和 Wumpus 認為讓節點拒絕啟動並顯示錯誤訊息提及覆蓋旗標會更合理，儘管在那個時間尺度上沒有太大區別。然而，它會更簡單地實作，也不太容易出錯。 + +### 會議結論 + +- 會議後討論繼續，但沒有達成共識 + +## 高優先級審查 + +- BlueMatt 建議為無法參加會議的 Morcos 加入 [#10199][]（更好的手續費估算）。 +- Sipa 喜歡將需要更多測試的 [#10148][]（使用區塊重放的非原子刷新）與 [#10195][]（將鏈狀態資料庫和快取切換到每 txout 模型）交換 +- CFields 希望看到不緊急但是朝向 Libevent 的長線中的第一個的 [#10285][]（重構）進入。 + +## 幽默時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10240]: https://github.com/bitcoin/bitcoin/pull/10240 +[#10279]: https://github.com/bitcoin/bitcoin/pull/10279 +[#10199]: https://github.com/bitcoin/bitcoin/pull/10199 +[#10148]: https://github.com/bitcoin/bitcoin/pull/10148 +[#10195]: https://github.com/bitcoin/bitcoin/pull/10195 +[#10285]: https://github.com/bitcoin/bitcoin/pull/10285 +[#10282]: https://github.com/bitcoin/bitcoin/pull/10282 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-05-04-meeting.md b/_posts/zh_TW/meetings/2017-05-04-meeting.md new file mode 100644 index 000000000..ad1b7d733 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-05-04-meeting.md @@ -0,0 +1,78 @@ +--- +title: IRC meeting summary for 2017-05-04 +permalink: /zh_TW/meetings/2017/05/04/ +name: 2017-05-04-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-05-04/?msg=85162138&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-04-19.01.html) + +--- + +## 註記 / 短議題 + +- BlueMatt 對他最近的[議題][#10337]提出一些關注，該議題質疑目前硬幣控制分組對手動隱私保護的有用性。 + +## 主要議題 + +- HD 錢包自動恢復 + +## HD 錢包自動恢復 + +### 背景 + +Bitcoin Core 自 0.13 版以來擁有階層式確定性錢包（HD wallet/[BIP32][]）。HD 錢包是一個系統，它從一個稱為「種子」的單一起點派生所有金鑰。這允許使用者只需備份一次錢包，所有未來生成的金鑰都可以從種子重新生成。 + +為了加快審查和部署，Bitcoin Core 中 HD 錢包的第一個版本被做得很簡單，沒有太多花俏的功能。現在正在向錢包加入新功能，例如這個 [HD 錢包自動恢復][#10240]，它確保在與節點同步時始終檢查金鑰池，並且它搜尋的未使用金鑰數量足夠大。 + +### 會議意見 + +Jonasschnelli 根據[上週會議](/en/meetings/2017/04/27/#hd-wallet-auto-restore)的結論制定了一個適用於加密（和修剪）錢包的解決方案，但他不確定間隙限制和預設金鑰池大小應該是多少。BlueMatt 建議預設金鑰池為 10k，間隙限制為 1000。Jonasschnelli 注意到非加密錢包可以保持在 100，但這只會使其更複雜，而金鑰生成很便宜。 + +### 會議結論 + +- 將所有錢包的間隙限制提高到 1000，預設金鑰池大小提高到 10000。 + +## 高優先級審查 + +BlueMatt 要求從[高優先級列表](https://github.com/bitcoin/bitcoin/projects/8)中移除 [#8694][]（基本多錢包支援），因為它需要一些修復和 rebase。多錢包仍應該是 0.15 的優先事項。其中一個修復是重構所有使用 `mapMultiArgs` 的東西，這在 PR [#9494][] 中完成，應該加入到列表中。 + +Sdaftuar 想加入 [#9208][]（改進 DisconnectTip 效能） + +Jtimon 的 [#8855][]（使用適當的工廠創建 chainparams）仍在列表上，很容易審查。 + +Gmaxwell 希望儘快合併 [per-txout + atomic][#10195]，以便有更多時間測試程式碼。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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#8694]: https://github.com/bitcoin/bitcoin/pull/8694 +[#10240]: https://github.com/bitcoin/bitcoin/pull/10240 +[#9208]: https://github.com/bitcoin/bitcoin/pull/9208 +[#8855]: https://github.com/bitcoin/bitcoin/pull/8855 +[#9494]: https://github.com/bitcoin/bitcoin/pull/9494 +[#10195]: https://github.com/bitcoin/bitcoin/pull/10195 +[#10337]: https://github.com/bitcoin/bitcoin/issues/10337 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-05-11-meeting.md b/_posts/zh_TW/meetings/2017-05-11-meeting.md new file mode 100644 index 000000000..fdf9c225a --- /dev/null +++ b/_posts/zh_TW/meetings/2017-05-11-meeting.md @@ -0,0 +1,119 @@ +--- +title: IRC meeting summary for 2017-05-11 +permalink: /zh_TW/meetings/2017/05/11/ +name: 2017-05-11-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-05-11/?msg=85494365&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.html) + +--- + +## 註記 / 短議題 + +- Sipa 和 Gmaxwell 一直在進行一項提案，以一種每個輸入和輸出只需幾微秒成本的方式始終維護 UTXO 承諾雜湊。這對於使 `gettxoutsetinfo` 即時化，或從其他人的 UTXO 集同步，或作為稍後軟分叉的基礎都很有用。有 3 種實作方式，都有不同的效能和安全性權衡。會議後幾天，郵件列表發布了一篇[文章](https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg05396.html)，解釋了不同的方法和選項。 + +## 主要議題 + +- 每 txo utxo 資料庫 +- 手續費目標/硬幣選擇檢修 + +## 每 txo utxo 資料庫 + +### 背景 + +自 Bitcoin Core v0.8 以來，我們對鏈狀態資料庫及其快取使用了每交易模型。這意味著資料庫實際上是從 txid 到該交易未花費輸出列表的對應。PR [#10195][] 將其更改為從輸出點（（txid，index）對）到該輸出點的單獨未花費輸出的對應。 + +聚合每個交易的輸出的原始原因是為了節省空間：這樣，我們可以避免在多個輸出中重複 txid 和交易元資料。然而，LevelDB 在內部使用一種編碼，省略鍵中重複的前綴位元組，因此，重複 txid 並不是很重要。 + +使用每 txout 模型有許多優點： + +- 更簡單的程式碼。 +- 避免反序列化和序列化未使用輸出的 CPU 開銷。 +- 更可預測的記憶體使用。 +- 更容易適應各種快取刷新策略。 + +缺點： + +- 磁碟上的表示略大，有時記憶體中的表示更大（當快取中有同一 txid 的多個輸出時，這變成可選的）。 + +### 會議意見 + +測試結果非常有希望，如[這張圖](https://cloud.githubusercontent.com/assets/548488/25769030/c84fe65e-31c4-11e7-8819-264c44e50ddf.png)所示。Sipa 注意到在測試中鏈狀態從 2.2GB 增加到 2.7GB。 + +Gmaxwell 認為它應該很快合併以在 master 中進行更多測試，但它需要更多的測試/審查。BlueMatt 正在進行一半的審查，cfields 通過了審查，但不夠自信以 ACK 它。 + +仍需要進行一些程式碼清理，並為升級程序提供更好的使用者介面，因為啟動時會有一次性從舊資料庫升級到新資料庫，需要幾分鐘。 + +### 會議結論 + +- 審查 PR [#10195][]（將鏈狀態資料庫和快取切換到每 txout 模型） + + +## 手續費目標/硬幣選擇檢修 + +### 背景 + +硬幣選擇是一種演算法，它找出如何花費你錢包中的硬幣。應該使用哪些來資助交易。這是在不創建非標準交易（通過超過某些大小，或創建粉塵輸出），試圖找到低手續費配置，給使用者盡可能多的隱私和縮小整體 UTXO 集大小之間的平衡。 + +多年來已經進行了許多改進，但仍然有偶爾出現的[問題][#10247]。Instagibbs 正在進行更改手續費目標演算法的工作，以考慮考慮的輸入的「有效價值」，而不是簡單地嘗試達到絕對手續費，看看它是否失敗，然後在迴圈結束時使用估算的總手續費再次嘗試。 + +### 會議意見 + +Gmaxwell 對在沒有清掃粉塵策略的情況下進行變更感到有點不安，他擔心可能會有意外的 UTXO 計數爆炸。 + +隨著對話更深入到手續費目標和硬幣選擇的一般方法，Morcos 提到了「手續費智慧」的想法，即當手續費低時可以包含更多輸入。 + +Wumpus 喜歡在低手續費率期間清理具有負值的 UTXO 的想法，但補充說如果一開始就不創建那些會更好。Morcos 提到他的 PR [#9343][]，它試圖做到這一點。 + +Bitcoin Core 的設計目標是永遠不要創建小於 0.01BTC 的找零輸出，除非錢包幾乎被交易耗盡，但這個目標根本沒有實現。 + +向前邁出的一個好步驟也是將硬幣選擇從 wallet.cpp 中解剖和模組化。 + +### 會議結論 + +- 已經提出了許多關於手續費目標和硬幣選擇方法的想法，將在會議外進一步討論。 + +## 高優先級審查 + +Instagibbs 想加入 PR [#10333][]，它修復了使用者報告的一些[手續費問題][#10247]，但不像硬幣選擇檢修那麼極端。 + +[多錢包][#8694]有一些審查意見，但是 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#9343]: https://github.com/bitcoin/bitcoin/pull/9343 +[#10333]: https://github.com/bitcoin/bitcoin/pull/10333 +[#8694]: https://github.com/bitcoin/bitcoin/pull/8694 +[#10240]: https://github.com/bitcoin/bitcoin/pull/10240 +[#9494]: https://github.com/bitcoin/bitcoin/pull/9494 +[#10195]: https://github.com/bitcoin/bitcoin/pull/10195 +[#10247]: https://github.com/bitcoin/bitcoin/issues/10247 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-05-18-meeting.md b/_posts/zh_TW/meetings/2017-05-18-meeting.md new file mode 100644 index 000000000..32f89907d --- /dev/null +++ b/_posts/zh_TW/meetings/2017-05-18-meeting.md @@ -0,0 +1,151 @@ +--- +title: IRC meeting summary for 2017-05-18 +permalink: /zh_TW/meetings/2017/05/18/ +name: 2017-05-18-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-05-18/?msg=85822053&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.html) + +--- + +## 註記 / 短議題 + +- 新的手續費估算器已經合併。現在執行 master 將清除你的舊手續費估算。Morcos 將嘗試進行改進，使其對 0.15 更無縫。 + +## 主要議題 + +- 客戶端過濾 +- 修剪節點服務 +- bytes_serialized + +## 客戶端過濾 + +### 背景 + +為了讓輕量級 SPV 客戶端不必下載整個區塊鏈內容，創建了 [BIP37][]。此 BIP 通過對等網路協定使用[布隆過濾器](https://en.wikipedia.org/wiki/Bloom_filter)，讓完整節點向 SPV 客戶端發送一小部分交易，其中包括 SPV 客戶端錢包所需的所有相關交易。 + +隨著時間推移，這種方法似乎沒有最初想像的那麼強大。 +- [BIP37][] 中預期的隱私作為布隆過濾器概率性質的結果最終[不存在](https://eprint.iacr.org/2014/763.pdf)。 +- 隨著區塊鏈變得更大，完整節點上有顯著的處理負載，因為它們必須處理整個區塊鏈以服務同步的 SPV 客戶端。這也使其容易受到 DoS 攻擊。 +- SPV 客戶端不能有強大的安全性期望，因為默克爾路徑允許它們驗證輸出是可花費的，但它不能證明輸出稍後未被花費。 + +已經提出了許多改進這種情況的想法，都有各自的權衡。最近 Roasbeef 一直在進行基於 [golomb 編碼集](https://en.wikipedia.org/wiki/Golomb_coding)的想法，它比布隆過濾器小，但需要更多 CPU 時間。 + +### 會議意見 + +首先，這將是節點預先計算和儲存的東西。讓區塊承諾這個可以稍後完成。 + +Gmaxwell 對 golomb 編碼的效能持懷疑態度，但他有興趣看到它。 + +Roasbeef 建議兩個過濾器，一個用於包括輸出點和腳本資料推送的超輕量級客戶端，另一個用於包括見證堆疊、sig 腳本資料推送和交易 ID 的更複雜查詢。Gmaxwell 評論加入見證資料具有長期影響，因為從現在起幾年後，我們可以期望大多數節點不會儲存超過一年前的見證資料。Roasbeef 澄清包含見證資料的理由是允許輕客戶端有效地掃描隱形地址之類的東西。然而，在實踐中沒有人這樣使用它，任何實作它的人都通過中心化伺服器進行掃描。Sipa 的偏好是只有輸出點和完整的 scriptPubKeys。資料推送相對於完整 scriptPubKey 的唯一優勢是對於裸多重簽名，但那些在實踐中並不真正使用。 + +Jonasschnelli 補充 Kallewoof 對通過 p2p 網路通過布隆過濾提供過濾器有一個[草案實作](https://github.com/kallewoof/bitcoin/pull/1/files) + +### 會議結論 + +- Roasbeef 將製作一個包含會議反饋的 BIP（[郵件列表文章](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014474.html)） + +## 修剪節點服務 + +### 背景 + +目前修剪節點不會宣告自己擁有任何區塊，因此它們不向其他對等節點提供任何區塊。隨著區塊鏈大小的持續增長，修剪節點的數量在未來可能會增加。 + +非修剪的完整節點通過 `NODE_NETWORK` 宣告自己，Jonasschnelli 在 [2017-05-27 會議](https://bitcoincore.org/en/meetings/2017/04/27/#node_network_limited)中建議製作一個訊息來宣告轉發並能夠提供最後 144 個區塊（1 天的區塊）的修剪節點，即 `NODE_NETWORK_LIMITED`。 + + +### 會議意見 + +Sipa 有一些[可用資料](http://bitcoin.sipa.be/depths.png)，顯示從他的節點下載的每個區塊的相對深度，排除緊湊區塊。它確認 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 錢包自動恢復功能） + +## 幽默時刻 + +{% highlight text %} +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 +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10295]: https://github.com/bitcoin/bitcoin/pull/10295 +[#10240]: https://github.com/bitcoin/bitcoin/pull/10240 +[#10195]: https://github.com/bitcoin/bitcoin/pull/10195 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-05-25-meeting.md b/_posts/zh_TW/meetings/2017-05-25-meeting.md new file mode 100644 index 000000000..c1a018e93 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-05-25-meeting.md @@ -0,0 +1,121 @@ +--- +title: IRC meeting summary for 2017-05-25 +permalink: /zh_TW/meetings/2017/05/25/ +name: 2017-05-25-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-05-25/?msg=86142878&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.html) + +--- + +## 註記 / 短議題 + +- Bitcoin Core 0.14.2 應該發布，其中包含手動啟用 UPnP 選項的使用者的安全修復，以及其他較小的錯誤修復。 + +## 主要議題 + +- 多錢包概念 +- 變數命名風格 +- BIP 148 + +## 多錢包概念 + +### 背景 + +Bitcoin Core 0.15 的一個新功能是同時處理多個獨立錢包的能力。Github 上有一個[專案頁面](https://github.com/bitcoin/bitcoin/projects/2)用於所有與多錢包支援相關的 PR 和議題。 + +### 會議意見 + +Jonasschnelli 有一些問題需要思考，即我們是否希望錢包創建/載入在軟體執行時進行，還是每次啟動時進行。長期來看我們應該兩者都要，但作為 0.15 的第一步，後者更現實。 + +另一個問題是 `-rescan`/`-zapwallettxes`/`-salvagewallet`/`-upgradewallet` 命令應該怎麼處理。Sipa 最初只會在配置了多個錢包時禁用 `-rescan`。理想情況下，我們將其移動到通過 RPC 的執行時，這樣命令將變成錢包特定的。Gmaxwell 認為 `-zapwallettxes` 和 `-salvagewallet` 最終應該消失，或者移動到另一個工具。Sipa 建議移除 `-zapwallettxes` 以支援 `abandontransaction`，用獨立工具替換 `-salvagewallet`，並讓 `-upgradewallet` 應用於所有錢包。Jonasschnelli 過去[開始進行][#8745]獨立錢包工具的工作，但遇到了循環依賴問題。Cfields 認為我們可以解決這個問題。 + +我們還應該考慮錢包旗標與新錢包資料庫的結合，Jonasschnelli 已經在[這裡](https://github.com/bitcoin/bitcoin/pull/9662/files#diff-b2bb174788c7409b671c46ccc86034bdR1357)實作了錢包旗標。旗標可以用來指示 HD 的使用、鏈分離等。由於 HD 鏈分離在 0.15 中不向後相容，理想情況下我們會放入我們進一步需要的所有東西，以避免在 0.16 中破壞向後相容性。 + +### 會議結論 + +- 確保在 0.15 中至少獲得基本的多錢包支援 + +## 變數命名風格 + +### 背景 + +在 Bitcoin Core 程式碼庫的歷史中使用了各種編碼風格，結果並不是很一致。已經努力使其更加統一，有一些[開發者指南](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md)，因此編碼風格將慢慢收斂到單一風格。 + +### 會議意見 + +Sipa 注意到幾個人編寫的補丁中的變數名稱看起來像[匈牙利](https://en.wikipedia.org/wiki/Hungarian_notation)表示法，但實際上不是。目前開發者註記中沒有指定任何約定，所以人們複製程式碼周圍的風格。為了讓人們停止模仿這種風格，應該在開發者註記中規定一種風格。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][] 以及[郵件列表](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html)。Luke-Jr 認為不包含它會使使用者面臨風險，因為將會由替代客戶端創建分叉，如果成功可能最終替換鏈。Gmaxwell 認為沒有廣泛的支援來證明這種立場。 + +Wumpus、BlueMatt、Jtimon、Gmaxwell 和 Morcos 更傾向於 [BIP149][] 而不是 BIP148。 + +Sipa 希望會有足夠的經濟支援，但預計每個經濟相關的完整節點都會在算力未能採用後幾小時內從 bip148 程式碼中撤回。 + +### 會議結論 + +- 只有在有足夠的經濟支援時才合併 BIP148。 + +## 幽默時刻 + +{% highlight text %} +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. +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#8745]: https://github.com/bitcoin/bitcoin/pull/8745 +[#10417]: https://github.com/bitcoin/bitcoin/pull/10417 +[#10428]: https://github.com/bitcoin/bitcoin/pull/10428 +[#10442]: https://github.com/bitcoin/bitcoin/pull/10442 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-06-01-meeting.md b/_posts/zh_TW/meetings/2017-06-01-meeting.md new file mode 100644 index 000000000..c73d67ea4 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-06-01-meeting.md @@ -0,0 +1,93 @@ +--- +title: IRC meeting summary for 2017-06-01 +permalink: /zh_TW/meetings/2017/06/01/ +name: 2017-06-01-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-06-01/?msg=86677749&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-01-19.00.html) + +--- + +## 註記 / 短議題 + +- Luke-jr 提出了一個擔憂，即區塊因無效的 prev-blocks 和發送「不」連線的標頭（因為我們拒絕了較早的無效標頭）而導致 DoS 懲罰，這可能是軟分叉的問題。之前在 DoS 保護方面提出了一個不同的[議題][#9530]，可能有類似的解決方案。因此 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](https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki) 和可能的 [CHECKBLOCKATHEIGHT](https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)。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 澄清它可以完美擴展，但我們應該完成它，因為我們已經談論棄用帳戶系統很長時間了。 + +## 幽默時刻 + +{% highlight text %} +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. :) +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10240]: https://github.com/bitcoin/bitcoin/pull/10240 +[#10339]: https://github.com/bitcoin/bitcoin/pull/10339 +[#10195]: https://github.com/bitcoin/bitcoin/pull/10195 +[#10321]: https://github.com/bitcoin/bitcoin/pull/10321 +[#10244]: https://github.com/bitcoin/bitcoin/pull/10244 +[#7729]: https://github.com/bitcoin/bitcoin/pull/7729 +[#8994]: https://github.com/bitcoin/bitcoin/pull/8994 +[#10192]: https://github.com/bitcoin/bitcoin/pull/10192 +[#9530]: https://github.com/bitcoin/bitcoin/issues/9530 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-06-08-meeting.md b/_posts/zh_TW/meetings/2017-06-08-meeting.md new file mode 100644 index 000000000..e66b4a8a3 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-06-08-meeting.md @@ -0,0 +1,131 @@ +--- +title: IRC meeting summary for 2017-06-08 +permalink: /zh_TW/meetings/2017/06/08/ +name: 2017-06-08-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-06-08/?msg=86999215&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-08-19.00.html) + +--- + +## 主要議題 + +- 優化：減少計算區塊雜湊的次數 +- 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 已經[準備好修復](https://github.com/theuni/bitcoin/commit/2cb7dda13884e44105f33c16e7e2c1a9aed46295)。 + +### 結論 + +- 修復 levelDB + +## 高優先級審查 + +- Sipa 想加入 [#10148][]（使用非原子刷新進行區塊重放），它將使有效可用的 dbcache 加倍。 +- Luke-jr 已經 rebase 了[多錢包][#8694]。 +- Gmaxwell 提醒大家 BlueMatt 的快取變更在 [#10192][] 上是 31% 的區塊連接速度提升，它需要審查。 + +## 幽默時刻 + +{% highlight text %} +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 oh, cfields did it already +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#10148]: https://github.com/bitcoin/bitcoin/pull/10148 +[#10339]: https://github.com/bitcoin/bitcoin/pull/10339 +[#10195]: https://github.com/bitcoin/bitcoin/pull/10195 +[#8694]: https://github.com/bitcoin/bitcoin/pull/8694 +[#10192]: https://github.com/bitcoin/bitcoin/pull/10192 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-10-26-meeting.md b/_posts/zh_TW/meetings/2017-10-26-meeting.md new file mode 100644 index 000000000..634862af2 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-10-26-meeting.md @@ -0,0 +1,89 @@ +--- +title: IRC meeting summary for 2017-10-26 +permalink: /zh_TW/meetings/2017/10/26/ +name: 2017-10-26-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-10-26/?msg=92779323&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-26-19.00.html) + +--- + +## 主要議題 + +- 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 的人實作鏈狀態資料庫的警告機制。 + + +## 幽默時刻 + +{% highlight text %} + 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 + achow101: that's great news! + \o/ + bad news is that the someone is roger ver. + :P + lol. no + hahahaha + XD + achow101: you've checked? + Comic relief would be the whole meeting notes + luke-jr: unless I am blind, I am pretty sure the person writing the notes next to me is roger ver + *is not + uh oh. + achow101: maybe on his payroll :P +* gmaxwell imagines the delayed correction coming after a sharp poke to the ribs +{% endhighlight %} + +註：這些註記的作者對上述交流感到受侮辱。 + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#11490]: https://github.com/bitcoin/bitcoin/issues/11490 +[#11446]: https://github.com/bitcoin/bitcoin/issues/11446 +[#11560]: https://github.com/bitcoin/bitcoin/issues/11560 +[#11446]: https://github.com/bitcoin/bitcoin/issues/11446 +[#10593]: https://github.com/bitcoin/bitcoin/issues/10593 +[#11531]: https://github.com/bitcoin/bitcoin/issues/11531 +[#11568]: https://github.com/bitcoin/bitcoin/issues/11568 + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2017-11-02-meeting.md b/_posts/zh_TW/meetings/2017-11-02-meeting.md new file mode 100644 index 000000000..823add513 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-11-02-meeting.md @@ -0,0 +1,91 @@ +--- +title: IRC meeting summary for 2017-11-02 +permalink: /zh_TW/meetings/2017/11/02/ +name: 2017-11-02-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-11-02/?msg=93048278&page=2) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-02-19.01.html) + +--- + +## 主要議題 + +- 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 程序 + +## 幽默時刻 + +{% highlight text %} + chaincode conspiracies coming... + Eastern US powerhouse too :) + instagibbs: It's not retroactive ;) + instagibbs: which ones, the ones we do ourselves or the ones under our blockstream contract? + ChainCodeLabs marketing departure must confront now with new ChainCode Core conspiracy + morcos, one and the same, right? + BlueMatt: lol + chaincore + heh + BlockChain +wait... + lol + lol + took you long enough + lol + ChainStream + +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#11592]: https://github.com/bitcoin/bitcoin/issues/11592 +[#11593]: https://github.com/bitcoin/bitcoin/issues/11593 +[#11560]: https://github.com/bitcoin/bitcoin/issues/11560 +[#11100]: https://github.com/bitcoin/bitcoin/issues/11000 + +{% include references.md %} + +Authored by: Ivan Quiles diff --git a/_posts/zh_TW/meetings/2017-11-09-meeting.md b/_posts/zh_TW/meetings/2017-11-09-meeting.md new file mode 100644 index 000000000..e149804e7 --- /dev/null +++ b/_posts/zh_TW/meetings/2017-11-09-meeting.md @@ -0,0 +1,77 @@ +--- +title: IRC meeting summary for 2017-11-09 +permalink: /zh_TW/meetings/2017/11/09/ +name: 2017-11-09-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +- [本週會議記錄](https://botbot.me/freenode/bitcoin-core-dev/2017-11-09/?msg=93346267&page=3) +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-09-19.02.log.html) + +--- + +## 主要議題 + +- 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。 + +## 幽默時刻 + +{% highlight text %} + "We Just Codesign Stuff We Want, LLC" XD + luke-jr: that's my end goal, actually + Indeed + It's one entity luke-jr + well adversarial versus consensus-compatible is easy to draw + there is another issue, I'm pretty sure that apple will not grant a key to "I sign random shit LLC" + You can found a "Knots Code Signing Assoc" +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。 + +[#11403]: https://github.com/bitcoin/bitcoin/issues/11403 +[#10286]: https://github.com/bitcoin/bitcoin/issues/10286 + + +{% include references.md %} diff --git a/_posts/zh_TW/meetings/2018-04-12-meeting.md b/_posts/zh_TW/meetings/2018-04-12-meeting.md new file mode 100644 index 000000000..6beda3f7f --- /dev/null +++ b/_posts/zh_TW/meetings/2018-04-12-meeting.md @@ -0,0 +1,127 @@ +--- +title: IRC meeting summary for 2018-04-12 +permalink: /zh_TW/meetings/2018/04/12/ +name: 2018-04-12-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/2018-04-12/?msg=98918663&page=4) +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-12-19.01.html) + +--- + +本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、是否要取消錢包中一個奇怪且很少使用的功能（IsMine 裸多重簽章）的相容性、如何安全地改進多錢包支援，以及在升級 Bitcoin Core 可重現二進位發行版的建置環境時，如何處理一些不再支援的軟體。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表](https://github.com/bitcoin/bitcoin/projects/8)。 + +**討論：** 本週建議關注的 PR 如下： + +1. **在驗證的同時平行建置交易索引（[#11857][]）**，由 Jim Posen 和 Wladimir van der Laan 提名。此 PR 將選用的交易索引（允許使用者透過 txid 查詢歷史交易）移到單獨的資料庫中。這將允許使用者在節點執行時啟用或停用交易索引，而不必等待數小時（即使在快速硬體上也是如此）。此 PR 也為 Bitcoin Core 新增額外的獨立索引奠定了基礎，這些索引可以啟用諸如 BIP [157][BIP157] 和 [158][BIP158] 中描述的輕量客戶端改進隱私區塊過濾等功能。 + + 在會議之前，此 PR 已經收到一些正面的審查，但要求了一些變更，現在已經完成，因此會議中的討論集中在讓這些變更本身得到審查。 + +2. **非 HD 錢包升級到 HD 的路徑（[#12560][]）**，由 Van der Laan 提名。此 PR 新增了一個新的 `sethdseed`（設定 HD 種子）RPC，允許使用者為 [BIP32][] 階層式確定性（HD）錢包設定種子值。這可用於請求 Bitcoin Core 自行產生新種子，或將種子變更為從目前執行的 Bitcoin Core 外部獲得的值（例如從備份中）。此外，此 PR 允許舊版非 HD Bitcoin Core 錢包的使用者使用 `-upgradewallet` 命令列參數升級到 HD 錢包。 + + 會議中的討論指出，此 PR 可能有一個尚未解決的問題，但主要需要來自其他貢獻者的審查。 + +3. **將費用估算器移到 validationinterface/cscheduler 執行緒（[#11775][]）**，由 Van der Laan 提名。此 PR 對 Bitcoin Core 程式碼中的一些內部介面進行後端變更，然後變更 Bitcoin Core 的費用估算器以使用其中一個介面，使其能夠存取對費用估算有用的其他資訊。此 PR 還對費用估算器在處理邊緣情況的方式上進行了一些小改進。 + + 在會議之前，此 PR 的作者（Matt Corallo）提議將此 PR 拆分為針對不同部分變更的獨立較小 PR。會議期間的討論指出，審查者正在等待這件事發生後才進一步審查。 + +4. **引入 `getblockstats` RPC 來[提供可用於]繪製圖表的資料（[#10757][]）**，由 Jorge Timón 提名。此 PR 新增了一個新的 RPC，回傳關於指定區塊的各種詳細資訊和統計資料。 + + 會議中的討論看到一位貢獻者同意審查此 PR。 + +討論期間提到的一個問題是 GitHub 最近頁面載入失敗的問題，持續時間相當長。這個問題已經變得足夠頻繁，以至於會議參與者透過引用 GitHub 在錯誤頁面上顯示的圖畫——一隻獨角獸——來提及這個問題。 + +## 如何處理裸多重簽章上的 IsMine + +**背景：** 裸多重簽章是指支付給多個公鑰而不使用更常用的 P2SH 或 segwit 位址。Bitcoin Core 的錢包目前會掃描任何裸多重簽章付款，以查看是否使用的每個公鑰都是使用者錢包的一部分，如果是，則將付款分類為 *IsMine*，表示使用者可以花費它。 + +**討論：** Pieter Wuille 提出了這個主題。他將目前的行為描述為「愚蠢、惱人、毫無意義且難以維護」。對於*愚蠢*和*毫無意義*，問題可能是當所有公鑰都屬於同一個錢包時，多重簽章並不比單一簽章提供任何額外的安全性，但使用多重簽章確實比單一簽章花費更多。對於*惱人*和*難以維護*，問題是這種行為需要額外的程式碼，並且使開發者更難以朝著 Wuille 先前描述的[改進錢包設計](https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2)邁進。 + +Wuille 接著描述了他的擔憂：「可能已經有現有的輸出給它。我不知道是否是這樣，但僅僅停止支援它聽起來很可怕。」經過一番討論，Wuille 澄清他並不是提議刪除允許這些付款的擁有者花費它們的程式碼；相反，Bitcoin Core 將不再自動看到這些付款。 + +Corallo 和 Wuille 之間的進一步討論提供了對問題的生動描述：要在所需的新錢包模型中支援這種舊行為，需要產生 N3 個組合，其中 *N* 是使用者擁有的私鑰數量。預設情況下，Bitcoin Core 產生 2,000 個私鑰，因此錢包需要產生難以管理的 80 億個組合。 + +持續的討論圍繞著 Wuille 的 PR [#12874][]，該 PR 停用目前的行為並為需要它的使用者提供一個解決方法。Corallo 提到現有的 RPC `importaddress` 已經為解決方法提供了必要的重要功能。 + +**結論：** 儘管會議參與者贊成在有合理方法的情況下保留現有功能，但討論似乎傾向於刪除裸多重簽章上的 IsMine，並在發行說明中提及解決方法。 + +## 動態錢包載入/卸載 + +**背景：** 舊版本的 Bitcoin Core 只能在特定節點上使用單一內建錢包實例。這在[版本 0.15.0](/zh_TW/releases/0.15.0/#multi-wallet-support) 中擴充為允許多個錢包實例，但 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](https://en.wikipedia.org/wiki/Intel_Management_Engine) 相關的問題。 + +**結論：** 切換到 debootstrap，同時 Dashjr 可能致力於讓 vmbuilder 再次運作。長期而言，Fields 正在努力全面改革系統。 + +## 幽默時刻 + +{% highlight text %} + #topic dynamic wallet load/unload (promag) + what's the controversy in this topic :) + it should happen, duh + how and when is another :) +{% endhighlight %} + +## 參與者 + + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。 + +[#11857]: https://github.com/bitcoin/bitcoin/issues/11857 +[#12560]: https://github.com/bitcoin/bitcoin/issues/12560 +[#11775]: https://github.com/bitcoin/bitcoin/issues/11775 +[#10757]: https://github.com/bitcoin/bitcoin/issues/10757 +[#12874]: https://github.com/bitcoin/bitcoin/issues/12874 +[#10740]: https://github.com/bitcoin/bitcoin/issues/10740 +[#11402]: https://github.com/bitcoin/bitcoin/issues/11402 +[Gitian]: https://github.com/bitcoin-core/docs/blob/master/gitian-building.md diff --git a/_posts/zh_TW/meetings/2018-04-19-meeting.md b/_posts/zh_TW/meetings/2018-04-19-meeting.md new file mode 100644 index 000000000..6e0fe3fd4 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-04-19-meeting.md @@ -0,0 +1,130 @@ +--- +title: IRC meeting summary for 2018-04-19 +permalink: /zh_TW/meetings/2018/04/19/ +name: 2018-04-19-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/99172001/) +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.html) + +--- + +本週會議討論的主題包括：GitHub 頁面載入的週期性問題、專案成員希望審查者在下週重點關注的拉取請求、某些原始碼檔案之間的不良相依性分離、輕量客戶端模式的設計，以及後 BIP150 身份驗證協定的更新（具有改進的隱私性）。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論：** 在討論特定議題之前，幾位團隊成員提到他們在載入 GitHub 上的某些頁面時遇到慢性問題，特別是如上週會議記錄中所報告的，有大量討論的拉取請求。其中一些拉取請求被列為高優先級審查。GitHub 支援團隊先前已被幾位會議參與者告知此問題，並在會議期間發送了更多通知。 + +作為潛在的解決方法，有人建議可能應該關閉並重新開啟有大量討論的拉取請求作為新的拉取請求，以便審查可以繼續。也討論了其他解決方法，例如使用具有無痕/私密模式或行動檢視的網頁瀏覽器。 + +本次會議具體討論的唯一 PR 是： + +1. **除非被監視，否則不要將裸多重簽章輸出視為 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][] 具有更好隱私性的身份驗證協定。目標是設計一個協定，其中一個節點有一個或多個私鑰，另一個節點有一個或多個公鑰。第二個節點了解[第一個]節點的私鑰之一是否與[其]公鑰之一匹配，但*沒有*其他資訊。擁有私鑰的節點甚至不知道身份驗證是否成功，或者不知道它被查詢的是哪些金鑰。」 + +在簡短回答了一些問題後，他繼續說：「想法是我們的大多數連線無論如何都是未經身份驗證的（並且應該[是，因為它們是與點對點網路上的隨機對等點]）所以，無論你給經過身份驗證的節點什麼特權，如果身份驗證失敗，你就不會給予。這有一個非常酷的特性，即使你不關心對方是誰，你也可以*總是*執行此身份驗證協定。[...] 如果你總是執行身份驗證協定（但如果你對身份驗證不感興趣，則使用隨機產生的公鑰[保證不匹配]）[中間人攻擊者]無法找出你在做什麼——他們必須假設你正在嘗試身份驗證。」 + +[先前嘗試的描述](https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b)設計這樣一個協定是可用的。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 的工作。 + +## 幽默時刻 + +{% highlight text %} + I guess this protocol would require more cryptoanalysis + then the exiting BIP150 + jonasschnelli: that's ok, i'm talking to dan boneh about it + Good! + Dan is the solution to all crypto problems +{% endhighlight %} + +## 參與者 + +| 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][] | + + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。 + +[#10794]: https://github.com/bitcoin/bitcoin/issues/10794 +[#13002]: https://github.com/bitcoin/bitcoin/issues/13002 +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 diff --git a/_posts/zh_TW/meetings/2018-04-26-meeting.md b/_posts/zh_TW/meetings/2018-04-26-meeting.md new file mode 100644 index 000000000..3c76a2e67 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-04-26-meeting.md @@ -0,0 +1,108 @@ +--- +title: IRC meeting summary for 2018-04-26 +permalink: /zh_TW/meetings/2018/04/26/ +name: 2018-04-26-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/99439716/)或 [MeetBot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-26-19.00.log.html) +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.html) + +--- + +本週會議討論的主題包括：「高優先級審查」拉取請求是否獲得足夠的審查、專案成員希望審查者在下週重點關注的拉取請求、在升級 `bumpfee` RPC 時如何處理該 RPC 的特定參數，以及是否刪除 Bitcoin Core 預設停用的「安全模式」。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-26-19.00.log.html#l-16)）：** 在討論特定議題之前，Matt Corallo 提出了一個擔憂，「我們在『高優先級』列表上並沒有真正獲得任何審查，所以[我]不確定每週提出它的用處。」其他貢獻者同意列表上的項目在過去幾週內沒有收到太多審查，但許多評論似乎贊成保留該列表。這個主題沒有明確解決，但似乎該列表將至少再使用一週。 + +如前兩週會議摘要中所述，本次會議再次簡短提到了一些 GitHub 頁面無法載入（「獨角獸」）的問題。 + +會議期間討論的具體 PR 包括： + +1. **將 validationinterface 拆分為平行的 validation/mempool 介面（[#12979][]）**，先前已新增到列表中。此 PR 將與驗證進入記憶池的交易相關的邏輯拆分為單獨的驗證和記憶池介面，使獲取有關記憶池的某些資訊變得更容易，並為 Bitcoin Core 費用估算器的潛在改進奠定基礎。 + + Pieter Wuille 指出他「開始審查 #12979，但難以理解[它]。」此 PR 的作者 Corallo 說「這是一個純重構。它所做的只是移動東西。」Corallo 還提到它在高優先級列表上是因為它「阻礙了大約 10 件其他事情。」 + +1. **引入 `getblockstats` RPC 來[提供可用於]繪製圖表的資料（[#10757][]）**，先前由 Jorge Timón 提名。此 PR 新增了一個新的 RPC，回傳關於指定區塊的各種詳細資訊和統計資料。 + + Anthony Towns 指出，此 PR 在上週收到了一些審查，但仍有一些小的未解決問題。 + +## bumpfee 的「totalFee」參數的必要性 + +**背景：** Bitcoin Core 提供了一個 `bumpfee` RPC，允許增加（「提升」）在使用者任何未確認交易上支付的交易費用，這些交易發出 [BIP125][] 選擇性取代費用（RBF）交易可替換性的訊號。預設情況下，此 RPC 會自行計算增加的金額，但它也允許使用者使用 `totalFee` 參數選擇性地指定要支付的新費用。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-26-19.00.log.html#l-87)）：** 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 預設停用了安全模式。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-26-19.00.log.html#l-129)）：** 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 於一月向郵件列表發送[電子郵件](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015542.html)以來，Bitcoin Core 二進位檔案簽署憑證的更新。在該電子郵件中，Fields 說 Gregory Maxwell 正在致力於「建立一個新的門檻簽署方案，這將允許我們處理程式碼簽署而沒有任何單點故障。」由於 Maxwell 未出席會議，因此沒有可用的更新。 + +## 幽默時刻 + +{% highlight text %} + #topic walletunload (Lukejr) + wumpus: I wasn't suggesting it as a topic + LukeJr: oh... + #unload walletunload + #untopic +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。 + +[#12979]: https://github.com/bitcoin/bitcoin/issues/12979 +[#10757]: https://github.com/bitcoin/bitcoin/issues/10757 +[#10563]: https://github.com/bitcoin/bitcoin/issues/10563 +[#13090]: https://github.com/bitcoin/bitcoin/issues/13090 +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 diff --git a/_posts/zh_TW/meetings/2018-05-03-meeting.md b/_posts/zh_TW/meetings/2018-05-03-meeting.md new file mode 100644 index 000000000..3fb18751f --- /dev/null +++ b/_posts/zh_TW/meetings/2018-05-03-meeting.md @@ -0,0 +1,145 @@ +--- +title: IRC meeting summary for 2018-05-03 +permalink: /zh_TW/meetings/2018/05/03/ +name: 2018-05-03-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/99670696/)或 [MeetBot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html) +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.html) + +--- + +本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、是否應將除錯記錄移到單獨的執行緒以便它不會減慢某些使用案例、是否要產生包含一些錯誤修復和標準交易政策變更的 0.16.1 小版本，以及如何允許平行處理從網路上其他對等點接收的訊息。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html#l-24)）：** 會議期間討論的具體 PR 包括： + +1. **BIP 158：輕量客戶端的緊湊區塊過濾器（[#12254][]）**，由 Jim Posen 提名加入列表。此 PR 允許 Bitcoin Core 為區塊中包含的一些資訊產生緊湊索引。然後可以與輕量客戶端共享這些索引，以允許它們確定區塊是否包含與客戶端錢包相關的資訊，此時客戶端可以請求下載整個區塊（可能來自不同的對等點）。 + +2. **[wallet] `loadwallet` RPC - 在執行時載入錢包（[#10740][]）**，由 John Newbery 提名加入列表。這是一組 PR 之一，如果被接受，將允許 Bitcoin Core 在 Bitcoin Core 0.15.0 中新增的多錢包模式的背景下，在執行時建立、載入和卸載錢包。 + +3. **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）的後續錯誤修復也會在該分支上進行。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html#l-61)）：** Marco Falke 在會議前不久提出了這個主題，並介紹說：「這些分支上最後標記的版本已經終止生命週期超過一年了。標籤可以保留以用於歸檔原因，但不再需要分支。參見 。」 + +所有在會議上對此事發表評論的人都表示同意。Luke Dashjr 建議，如果每個分支上的最終提交沒有附加到發行標籤（表示確切哪些程式碼用於特定發行版本），則應新增標籤以確保需要該特定程式碼的任何人仍然可以獲得它。其他會議參與者表示同意。 + +**結論：** 會議結束後不久，這些分支被刪除。 + +## 將記錄移到單獨的執行緒 + +**背景：** 預設情況下，Bitcoin Core 會將有關其正在執行的操作的某些資訊寫入記錄檔，以防出現問題並且使用者需要找出觸發問題的原因。目前，記錄是作為程式執行中的順序步驟完成的，因此記錄之後的下一步不會執行，直到記錄完成，這被描述為記錄步驟「阻塞」後續步驟。執行緒是一種讓程式告訴作業系統可以平行執行多個步驟的方法，這可以允許程式中的下一步在記錄完成之前開始（描述為「非阻塞」）。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html#l-84)）：** James O'Beirne 建議並介紹了這個主題，說：「我認為將記錄移到單獨的執行緒可能是值得的。」他參考了兩個最近與記錄相關的 PR，[#13099][] 和 [#12970][]。 + +Matt Corallo 對這個想法非常熱情，說「ACKACKACKACKACKACKACKACKACKACK」並指出「對於礦工來說，這是一個令人驚訝的高延遲創造者，至少對於那些使用旋轉磁碟支援或雲端託管機器的人來說。」他還連結到了他的專案 Bitcoin FIBRE（不用於共識執行的 Bitcoin Core 軟體分支）的一個[提交](https://github.com/bitcoinfibre/bitcoinfibre/commit/6b6a3aef0663775b63bac7d0aa07ec5fc4eb9fc9)，該提交為記錄實作了基本執行緒。 + +其他幾位開發者支援這個想法，討論集中在實作行為的最佳方式，特別是如何確保如果確實出現問題，盡可能多的資訊仍然寫入記錄檔。 + +一些參與者還討論了如果將記錄移到單獨的執行緒，Bitcoin Core 會快多少。一般意見似乎是它可以在一些時間關鍵的應用程式中提供幫助，例如礦工宣布新發現的區塊，並且在使用者啟用選用的詳細記錄進行除錯時也會有所幫助。後者是開發者經常做的事情，也被 Bitcoin Core 測試套件的部分自動使用。但是，對於其他使用案例，預計不會提供顯著的改進。 + +**結論：** James O'Beirne 透過說「除非有人有任何異議，否則我將在不久的將來開始進行執行緒從環形緩衝區消費的實作」來結束討論。 + +## 0.16.1 + +**背景：** Bitcoin Core 最新的主要版本 0.16.0 版本是在大約兩個月前發布的。通常在發布後，會修復影響該版本的錯誤，並且某些新功能被認為足夠重要以[向後移植][backport]到該版本，從而產生新的小版本。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html#l-188)）：** Matt Corallo 提出了這個主題並介紹說：「對於那些沒有注意的人，\[Jesse Cohen] 在 [#13092][] 中發現了區塊處理中一些特別新穎的競態條件。因為它們是執行緒問題，它們幾乎肯定不會影響除 submitblock 使用者（即礦工）以外的任何人，並且只會在罕見的競態[情況？]下，但是，我認為鑑於這一點以及我們擁有的其他各種修復，可能值得向後移植。」 + +引用的問題 #13092 是 Suhas Daftuar 對 Cohen 在 PR [#13023][] 中編寫的整合測試發現的問題的分析。在最壞的情況下，礦工可能認為他們使用 `submitblock` RPC 向網路發送了新發現的區塊，卻發現 Bitcoin Core 由於[競態條件][race condition]而默默忽略了該區塊，這是程式以與程式設計師預期不同的順序執行步驟的情況。Cohen 的測試發現了這個問題，因為它們在很短的時間內建立了幾個測試區塊（沒有工作量證明）。主網路上的區塊之間幾乎總是有更大的間隔，因此希望到目前為止沒有礦工受到此錯誤的影響。 + +儘管有 PR 來修復該問題，但 Daftuar 認為需要額外的討論以「確定正確的修復方法」。Cohen 建議 [#12988][] 是「類似類型的錯誤」，也可能應該在小版本中修復。 + +Corallo 還建議 0.16.1 應包括 Johnson Lau 的 PR [#11423][]，使 `CodeSeparator` 操作碼在傳統（非 segwit）輸入的花費中成為非標準的。非標準意味著節點不會接受具有這些輸入的交易進入記憶池；如果它們出現在區塊中，它們仍然會接受它們。這應該消除對稱為 `FindAndDelete()` 的函式的使用，該函式有問題的歷史（參見 [1][todd-sighash-single]、[2][lerner-findandreplace]）。Segwit 的實作[不需要 FindAndDelete](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#No_FindAndDelete)，但仍然提供 `CodeSeparator` 操作碼，NBitcoin 開發者 Nicholas Dorier 一直在[使用][using codeseparator]它作為 [Tumblebit][] 實作的一部分——因此尚未正式提議在 segwit 花費中使 `CodeSeparator` 成為非標準的。 + +[using codeseparator]: https://github.com/bitcoin/bitcoin/pull/11423#issuecomment-333439463 + +關於 Lau 的 PR 是否已準備好合併，有一些討論。Corallo 相信 Lau「想要向 [Lau 的 PR] 新增一個更多的政策規則。」Corallo 說他會就此聯繫 Lau。 + +**結論：** 所有參與者似乎都贊成組合 0.16.1 版本以修復競態條件並包含額外的標準性規則。在會議期間和之後，討論的各種 PR 被新增到專案的 [0.16.1 里程碑][0.16.1 milestone]中。 + +## 非同步呼叫 ProcessNewBlock + +**背景：** Bitcoin Core 目前在單一執行緒中處理它從點對點網路上的對等點接收的訊息。如果可以重寫為使用多執行緒，它可以平行處理一些訊息，這可以提供效能改進。但是，由於它經常從多個對等點接收相同的基本訊息，因此這提出了如何避免重複工作的挑戰。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html#l-234)）：** Matt Corallo 提出了這個主題並介紹說：「PR [#12934][] [肯定]還沒有準備好審查，但我們應該討論一下跨對等點的並發性會是什麼樣子。有兩種主要方法，但兩者最終都需要對其大部分工作進行類似的重構。過去我曾研究過平行執行 ProcessMessages()；在[先前連結的 PR 中，Jesse Cohen] 將[交易和區塊]的驗證處理移到佇列中，並在單獨的執行緒中執行。在這兩種情況下，我們最終都會建立邏輯來『暫停』處理對等點，直到它剛剛產生的任何訊息都被處理完畢。」 + +Gregory Maxwell 和 Corallo 簡短討論了系統的哪些部分會發現並發性特別有益。對於 Maxwell 來說，是初始區塊下載（IBD），其中新區塊的下載被延遲「當同時連線多個區塊時（由於 IBD 中的無序獲取）」。對於 Corallo 來說，是在使用 CompactBlocks（[BIP152][]）接收新區塊期間連線期間轉發 `gettxn`（獲取交易）請求，「對於區塊轉發延遲[改進]來說，剩下的一個大便宜勝利。」 + +Corallo 接著指出，並發性將允許在具有多個 CPU 核心的系統上同時將來自多個對等點的新接收資料反序列化為可用的資料結構，Maxwell 同意這可能是一個不錯的收穫。他們還同意，過去一年對程式碼所做的許多改進使得實作這種類型的變更變得更簡單和更容易。 + +**結論：** Cohen 寫道：「酷——所以，如果沒有強烈的反對或對該方法的擔憂，我將繼續這樣做，並在它更準備好審查時回來。」 + +## 幽默時刻 + +{% highlight text %} + #10740 given me an unicorn though + has also a unicorn, reload solved + yes + unicorns probably have a high street value + not any more. The market's been flooded + shows what I know of unicorn markets + 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... +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請聯繫我們，我們將更正錯誤。 + +[0.16.1 milestone]: https://github.com/bitcoin/bitcoin/milestone/34 +[#10740]: https://github.com/bitcoin/bitcoin/issues/10740 +[#11423]: https://github.com/bitcoin/bitcoin/issues/11423 +[#12254]: https://github.com/bitcoin/bitcoin/issues/12254 +[#12934]: https://github.com/bitcoin/bitcoin/issues/12934 +[#12970]: https://github.com/bitcoin/bitcoin/issues/12970 +[#12988]: https://github.com/bitcoin/bitcoin/issues/12988 +[#13023]: https://github.com/bitcoin/bitcoin/issues/13023 +[#13092]: https://github.com/bitcoin/bitcoin/issues/13092 +[#13097]: https://github.com/bitcoin/bitcoin/issues/13097 +[#13099]: https://github.com/bitcoin/bitcoin/issues/13099 +[backport]: https://en.wikipedia.org/wiki/Backporting +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[lerner-findandreplace]: https://bitslog.wordpress.com/2017/01/08/a-bitcoin-transaction-that-takes-5-hours-to-verify/ +[race condition]: https://en.wikipedia.org/wiki/Race_condition +[todd-sighash-single]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-November/006878.html +[tumblebit]: http://cs-people.bu.edu/heilman/tumblebit/ diff --git a/_posts/zh_TW/meetings/2018-05-10-meeting.md b/_posts/zh_TW/meetings/2018-05-10-meeting.md new file mode 100644 index 000000000..b10cb92ae --- /dev/null +++ b/_posts/zh_TW/meetings/2018-05-10-meeting.md @@ -0,0 +1,140 @@ +--- +title: IRC meeting summary for 2018-05-10 +permalink: /zh_TW/meetings/2018/05/10/ +name: 2018-05-10-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/99928845/)或 [MeetBot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-10-19.00.log.html) +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-10-19.00.html) + +--- + +本週會議討論的主題包括：會議參與者最希望看到審查的拉取請求、如果頁面繼續無法可靠載入是否可能離開 GitHub、如何修復效能退化、在記憶體中儲存交易腳本資料的未來設計，以及是否建立額外的審查佇列。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-10-19.00.log.html#l-16)）：** 具體討論的 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 列表][current high-priority PRs]。沒有討論離開 GitHub 的具體計劃；會議參與者似乎希望 GitHub 會修復他們的系統。 + +## 在 CTransaction 中快取見證雜湊 + +**背景：** 當 Bitcoin Core 需要將交易儲存在記憶體中時，它使用 `CTransaction` 資料類型。這包含足夠的資訊來為交易建構見證交易識別碼（*wtxid* 或*見證雜湊*）。CTransaction 資料類型可以擴充為包含見證雜湊的預先計算（快取）副本。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-10-19.00.log.html#l-51)）：** 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 列表][current high-priority PRs]中。 + +## 一個大的 malloc + +**背景：** 在 Bitcoin Core 編寫的 C++ 程式語言中，記憶體配置（Memory ALLOCation）的主要函式稱為 `malloc()`。目前，如 PR [#13062][] 中所述，交易中腳本的記憶體配置方式是最佳化快取 scriptPubKeys，但在其他情況下效能次佳。該 PR 致力於將記憶體中腳本的儲存與它們在程式中的存取方式分開，以便儲存和存取（表示）都可以最佳化。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-10-19.00.log.html#l-109)）：** 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](https://bitcoinacks.com/)，Posen 同意「很棒」。Wuille 支援 Posen 的想法，「對什麼是概念 ACK（以及類似地，鼓勵人們快速概念 ACK/NACK）有更好的概述會很好。」 + +Wladimir van der Laan 反對這個想法，說「現在每個人都可以在[目前高優先級列表]上有一個阻礙他們的 PR，這應該促進合作。」Matt Corallo 同意，「百萬小 PR 審查方法不會讓我們作為專案取得任何進展，[但]審查高優先級列表上的事物確實會（至少對我來說）。」 + +**結論：** 沒有明確的結論。Corallo 個人總結說：「我認為我們這週不會比過去 10 次討論這個問題時取得更多進展。」 + +## 幽默時刻 + +{% highlight text %} + i'm back + welcome back! + hi back, i'm pieter + oh man... +{% endhighlight %} + +{% highlight text %} + well another option is std::allocator magic, + without having to switch to Span + noooo + no magic + wumpus: i can't argue with that, it looks like voodoo + damn cool voodoo. + but voodoo. + c++ is already too much voodoo + let's switch to BASIC +{% endhighlight %} + +{% highlight text %} + bitcoinacks.com ? :) + apparently it doesnt distinguish between nacks and acks + ha. + lol that's an interesting bug + "nack" "nack" "nack" "merged!" +{% endhighlight %} + +## 參與者 + +| 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][] | + + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請[開啟一個議題](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + + + +[#10740]: https://github.com/bitcoin/bitcoin/issues/10740 +[#12254]: https://github.com/bitcoin/bitcoin/issues/12254 +[#13011]: https://github.com/bitcoin/bitcoin/issues/13011 +[#13062]: https://github.com/bitcoin/bitcoin/issues/13062 +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 diff --git a/_posts/zh_TW/meetings/2018-05-17-meeting.md b/_posts/zh_TW/meetings/2018-05-17-meeting.md new file mode 100644 index 000000000..f5a56c485 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-05-17-meeting.md @@ -0,0 +1,154 @@ +--- +title: IRC meeting summary for 2018-05-17 +permalink: /zh_TW/meetings/2018/05/17/ +name: 2018-05-17-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/100174747/)或 [MeetBot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html) +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.html) + +--- + +本週會議討論的主題包括：會議參與者最希望看到審查的拉取請求、在產生版本 0.16.1 的第一個候選版本之前需要解決的問題、專案是否應該離開 GitHub、一個為將節點程式碼與錢包程式碼分離鋪平道路的 PR 的審查請求，以及一個潛在的新 P2P 協定訊息以更好地處理未驗證區塊的轉發。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html#l-13)）：** 具體討論的 PR 包括： + +- **[#12254][]：** BIP 158：輕量客戶端的緊湊區塊過濾器 + +- **[#12196][]：** 新增 scantxoutset RPC 方法 + +- **[#13142][]：** 將 IsMine 與可解決性分離 + +- **[#12979][]：** 為輔助索引建立可重複使用的基類 + +此外，Wladimir van der Laan 表示擔心列表變得相當長。 + +## 0.16.1 + +**背景：** Bitcoin Core 開發者已開始準備一個新的 0.16.1 [維護版本](/zh_TW/lifecycle/#maintenance-releases)，其中包含錯誤修復和重要功能的向後移植。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html#l-65)）：** Wladimir van der Laan 提出了這個主題，並簡要概述了仍需完成的工作： + +1. **[0.16] 進一步向後移植（[#13253][]）。** 需要更多審查。 + +2. **0.16.0 bitcoin-qt：啟動期間「斷言 `copyFrom 失敗」（[#13110][]）。** Van der Laan 說他「為[此]提出了修復方案，顯然有效。」 + +3. **重新掃描期間的斷言失敗（[#12646][]）。** Jonas Schnelli 建議推遲，Van der Laan 同意。它被重新定向到 0.16.2。 + +4. **0.16 關閉斷言（[#12337][]）。** Schnelli 正在調查此問題。 + +**結論：** 「我們只需要完成向後移植並為 0.16.1RC1 標記，」Matt Corallo 說。 + +## 放棄 GitHub + +**背景：** 超過 6 週以來，經過高度審查的 Bitcoin Core PR 在 GitHub 上的網頁經常無法載入，審查者看到的是一隻憤怒的獨角獸插圖。不同的人已經多次向 GitHub 支援報告了這個問題，但尚未解決。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html#l-97)）：** 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 的[訊息](https://0bin.net/paste/ViHtKCgPIfW0TMYt#j30mFske0y1EVoVRZCsQqMoYCpoPc3axAV29jkKkznB)，說 GitHub「已經確定了根本原因，並正在進行修復。」 + +## 將錢包從節點分離 + +**背景：** Bitcoin Core 的全節點實作、錢包和圖形使用者介面（GUI）目前都作為單一程序執行（儘管錢包和 GUI 可以停用）。這意味著，例如，如果你關閉 GUI，你也會停止節點。將這些不同部分拆分為獨立程序以便它們可以彼此獨立運作一直是幾位貢獻者的長期目標。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html#l-234)）：** John Newbery 提出了這個主題並介紹說：「[#10973][] 是一個大的 PR，但我認為它非常值得，[...] 但它需要持續的重新基底。[...] 我認為在這個問題上取得一些進展會很棒。」 + +Wladimir van der Laan 擔心高優先級審查佇列太大：「哦，不，不要更多高優先級審查。它阻礙了什麼嗎？對 0.17 重要嗎？無論如何，程序分離不是我們 0.17 會有的東西。」 + +此 PR 的作者 Russell Yanofsky 提議將前六個提交拆分到單獨的 PR 中，以便可以獨立於後面的提交進行審查，從而縮小 PR 的大小，並希望使其更容易審查。 + +**結論：** 隨著 Yanofsky 提議拆分 PR 以及幾位貢獻者提供在下週審查它，Newbery 結束了主題。 + +## 未驗證區塊訊息 + +**背景：** [BIP152][] 緊湑區塊轉發引入了高頻寬模式，節點可以在完成驗證該區塊之前向其對等點發送關於新區塊的資訊。如果節點確實完成了驗證區塊並發現區塊無效，但對等點無論如何都請求整個區塊，目前沒有辦法讓節點告訴其對等點它沒有有效的區塊可以發送給它們。目前，在這種情況下，對等點最終會因為未能發送請求的區塊而與節點斷開連線。 + +**討論（[記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html#l-268)）：** Matt Corallo 提出了這個主題，並透過描述問題的兩個潛在解決方案來介紹它： + +1. 節點告訴請求的對等點它拒絕轉發區塊。 + +2. 節點向對等點提供請求的區塊，證明它具有有效的區塊標頭（如 BIP152 所要求），但也將其標記為可能無效。 + +Pieter Wuille 建議現有的 [`notfound`][p2p notfound] 訊息可能可以重複使用，作為實作第一個提議解決方案的一部分。 + +Suhas Daftuar 反對重複使用 `notfound` 訊息，贊成第二個提議的解決方案：「我認為 notfound 更糟，因為在區塊可能尚未驗證的情況下。」Wladimir van der Laan 同意應該使用新訊息「如果沒有特定原因重複使用 `notfound`，新訊息要好得多。」 + +**結論：** Corallo 仍在考慮選項，但認為「問我很好。顯然[實際解決方案]需要一個 BIP 和其他東西。」 + +## 其他主題 + +會議僅剩幾分鐘時，Matt Corallo 提出了一個標題為「佇列排空鎖定斷言以避免死鎖」的主題，但沒有足夠的時間討論該主題，Corallo 說：「我現在意識到我應該只開一個 PR，人們會看到它，[因為]描述起來有點複雜。」 + +## 幽默時刻 + +{% highlight text %} + trashing github + or we could switch to gitlab + let's move back to sourceforge +{% endhighlight %} + +{% highlight text %} + i think we could just add a new BLOKC response type + BLOCK_COULDBEBAD + 0xDEADB10C + hehe +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請[開啟一個議題](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[#10973]: https://github.com/bitcoin/bitcoin/issues/10973 +[#12196]: https://github.com/bitcoin/bitcoin/issues/12196 +[#12254]: https://github.com/bitcoin/bitcoin/issues/12254 +[#12337]: https://github.com/bitcoin/bitcoin/issues/12337 +[#12646]: https://github.com/bitcoin/bitcoin/issues/12646 +[#12979]: https://github.com/bitcoin/bitcoin/issues/12979 +[#13110]: https://github.com/bitcoin/bitcoin/issues/13110 +[#13142]: https://github.com/bitcoin/bitcoin/issues/13142 +[#13253]: https://github.com/bitcoin/bitcoin/issues/13253 +[p2p notfound]: https://bitcoin.org/en/developer-reference#notfound +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 diff --git a/_posts/zh_TW/meetings/2018-05-24-meeting.md b/_posts/zh_TW/meetings/2018-05-24-meeting.md new file mode 100644 index 000000000..c388f264d --- /dev/null +++ b/_posts/zh_TW/meetings/2018-05-24-meeting.md @@ -0,0 +1,133 @@ +--- +title: IRC meeting summary for 2018-05-24 +permalink: /zh_TW/meetings/2018/05/24/ +name: 2018-05-24-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/100407600/)或 [MeetBot][mb log] +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-24-19.00.html) + +--- + +本週會議討論的主題包括：在產生版本 0.16.1 的第一個候選版本之前需要解決的問題、是否應該稍微延遲交易轉發以潛在地增加支付者隱私、如何儲存 Bitcoin Core GUI 和守護程序內部設定的設定，以便兩個程式都可以存取它們，以及 Bitcoin Core 是否應該新增掃描 UTXO 集的功能，即使它（假設性地）在未來可能不會以可掃描的形式儲存 UTXO 集。 + +## [需要為] 0.16.1 [做什麼] + +**背景：** Bitcoin Core 貢獻者正在努力發布 Bitcoin Core 0.16.1，這是一個[維護版本][maintenance release]，將包含錯誤修復和小改進。 + +**討論（[記錄][log 0.16.1 todo]）：** 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 位址範圍才能獲得成為早期接收者的相同機會 + +**討論（[記錄][log random relay delays]）：** Pieter Wuille 提出了這個主題並描述了他想看到的：「我想簡要提出 [#13298][] [...] 這對 P2P 交易轉發可能產生重大影響，它需要超越『程式碼是否運作』的審查。但它也只是本地政策，而不是需要 BIP 的東西[我認為]。也許沒有更多要說的了，[我]只是希望讓人們考慮一下。」 + +P2P 交易轉發上可能的重大影響是延長交易（但不是區塊）從其發起對等點傳播到 90% 或更多其他節點所需的時間。 + +**結論：** 沒有討論，只是建議審查者訪問 PR，考慮其影響，並提供任何建議的評論。 + +## GUI 修剪設定和可寫入的設定檔 {#gui-prune-setting-and-writable-config-files} + +**背景：** Bitcoin Core 提供命令列選項和使用者可編輯的設定檔（`bitcoin.conf`），但它也允許使用者在圖形使用者介面（GUI）中變更一些相同的設定。目前這兩組設定儲存在不同的位置，因為 GUI 無法變更設定檔（在某些系統上，它是唯讀的，並且在所有情況下它可能包含使用者評論和格式，自動設定編輯器可能會破壞）。但是，這會產生幾個問題，其中使用者在一個地方變更設定，它意外地在另一個地方套用或不套用。共享設定的最新案例是 PR [#13043][]，它為 GUI 新增了控制先前可從命令列和設定檔使用的修剪的能力。 + +**討論（[記錄][log gui prune]）：** Sjors Provoost 提出了這個主題，並建議了三個解決在不同 Bitcoin Core 程式之間共享設定的儲存位置問題的解決方案： + +1. 「忽略這個問題。」繼續使用目前的系統。 + +2. 「走可寫入設定檔的路線。」（稍後討論會進入更多細節。） + +3. 「以不同的方式解釋缺少 `prune=` 設定。」給設定檔中指定的選項優先於 GUI 中配置的選項。 + +Provoost 補充說：「如果我們選擇[選項] 2，那麼我想提名 [PR] [#11082][] 進行優先審查。」該 PR 新增了一個新的 `bitcoin_rw.conf` 檔案，用於軟體修改的設定。與 Qt 設定不同，該檔案可以在 Bitcoin Core 的守護程序和 GUI 之間共享，並且該檔案將被明確標記為不打算支援評論、基於空白的格式和其他人工編輯的便利性。 + +Jonas Schnelli 抱怨說：「我們想要四(!)層設定嗎？設定[檔] <-> 啟動[命令列介面參數] <-> Qt 設定 <-> 第 4 層 [`bitcoin_rw.conf`]。」 + +Provoost 解釋說：「我也想完全擺脫 Qt 設定 [...] 我在 [PR] [#12833][] 中編寫了從 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）的[鍵值資料庫][key-value database]——即每個可花費的比特幣群組以及為了花費它們需要滿足的條件。該資料庫不是為一次由多個程式存取而設計的，並且不是 API 穩定的，這意味著其他程式無法輕鬆地從中讀取，因此目前沒有便捷的方法讓其他程式從 UTXO 集中檢索資訊。 + +**討論（[記錄][log scantxoutset]）：** Jonas Schnelli 提出了這個主題並介紹說：「[Pieter Wuille] 對在 PR #12196 中提議的 `scantxoutset` 命令提出了擔憂。在繼續 [PR] [#12196][] 之前，我們可能想討論它是否有意義[...]。掃描功能允許無需掃描區塊的 UTXO 掃掠（`rawsweeptransaction`）。你可以傳入 *n* 個公鑰/位址，甚至 [HD 錢包擴充公鑰]和查找視窗，它會給你回傳所有未花費的[輸出]（甚至還有一個 rawsweeptransaction 到單一位址）。」 + +Wuille 描述了他的擔憂：「我只是提到我們最好不要承諾具有在未來難以維護的功能。[例如，在可能的未來使用] [UHF 模型][UHF model]，在沒有索引的情況下實作 UTXO 集的掃描需要瀏覽區塊鏈。」*[注意：討論中標記為「UHF」的在其他地方稱為「UHS」；請參閱[連結][UHF model]。]* + +Johnathan Corgan 建議：「如果我們想鼓勵人們將 bitcoind 視為『真實來源』，而不是建立他們自己的東西，給他們更容易存取『資料庫』會有所幫助。」 + +Wuille 承認這個問題「不那麼令人擔憂[因為更容易]現在透過 [Jim Posen 的]背景索引工作新增選用索引。之前，新索引總是需要在驗證程式碼中到處進行醜陋的修改。」 + +**結論：** 「這正在變成一場哲學討論，」Wuille 在討論接近尾聲時評論道。沒有明確的結論，但似乎如果新增了 `scantxoutset` RPC 或類似的 RPC，可能會在發行說明中新增警告，指出它可能需要在未來啟用選用索引。 + +## 幽默時刻 + +{% highlight text %} +[...Things start to break...] + [Global Notice] [...] There are ongoing issues with + services that are being looked into - please bear + with us + fun. + err what + services massacre + irc unicorns... + let's move to slack! + (/s) + :-( +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請[開啟一個議題](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[maintenance release]: /zh_TW/lifecycle/#maintenance-releases +[key-value database]: https://en.wikipedia.org/wiki/Key-value_database +[UHF model]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015967.html + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-24-19.00.log.html" %} +[mb log]: {{log}} +[log 0.16.1 todo]: {{log}}#l-14 +[log random relay delays]: {{log}}#l-51 +[log gui prune]: {{log}}#l-66 +[log scantxoutset]: {{log}}#l-136 + +{% include link-to-issues.md issues="13317,12172,12431,13298,13043,11082,12833,12196" %} diff --git a/_posts/zh_TW/meetings/2018-05-31-meeting.md b/_posts/zh_TW/meetings/2018-05-31-meeting.md new file mode 100644 index 000000000..71f83f6f6 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-05-31-meeting.md @@ -0,0 +1,111 @@ +--- +title: IRC meeting summary for 2018-05-31 +permalink: /zh_TW/meetings/2018/05/31/ +name: 2018-05-31-meeting +type: meetings +layout: page +lang: zh_TW +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [本週會議記錄連結](https://botbot.me/freenode/bitcoin-core-dev/msg/100659376/)或 [MeetBot][mb log] +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.html) + +--- + +本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、專案何時應該升級程式碼庫和建置系統以使用 C++14 標準、在點對點網路協定的擴充 `addr` 訊息中要考慮哪些設計因素，以及如何為託管 Bitcoin DNS 種子器的人過濾掉聲稱是 Bitcoin 節點的競爭幣節點。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論（[記錄][log hipri]）：** 以下 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][]。 + +**討論（[記錄][log c14]）：** 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` message]允許節點告訴其對等點任何可能接受傳入連線的節點；這允許節點在沒有集中協調的情況下找到新的對等點。目前的 `addr` 訊息僅支援最多 128 位元的位址，這足以用於傳統 IP 位址（IPv4）、現代 IP 位址（IPv6）和舊式 Tor .onion 隱藏服務——但它不支援需要 256 位元的較新式 Tor 隱藏服務，也不支援 I2P 匿名網路上的對等點。 + +**討論（[記錄][log 256-bit addr]）：** 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 將撰寫並傳播一個討論提案。在會議之後，他發布了[文件][addrv2 pre-bip]並從追蹤議題 [#2091][] 連結到它。 + +## 種子器加固 + +**背景：** 對於首次連線到網路的節點和使用點對點協定的輕量客戶端，幾位知名社群成員託管 DNS 種子器，分發他們知道的節點的 IP 位址列表。會議中有三位託管種子器的人：Pieter Wuille、Jonas Schnelli 和 Matt Corallo。Wuille 和 Corallo 也分別是用於種子的軟體的作者。 + +**討論（[記錄][log seeder]）：** 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請[開啟一個議題](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[`addr` message]: https://bitcoin.org/en/developer-reference#addr +[addrv2 pre-bip]: https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1 +[c++11]: https://en.wikipedia.org/wiki/C%2B%2B11 +[c++14]: https://en.wikipedia.org/wiki/C%2B%2B14 + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-17 +[log c14]: {{log}}#l-14 +[log 256-bit addr]: {{log}}#l-175 +[log seeder]: {{log}}#l-274 + +{% include link-to-issues.md issues="13062,13111,11082,13058,13356,2091" %} diff --git a/_posts/zh_TW/meetings/2018-06-07-meeting.md b/_posts/zh_TW/meetings/2018-06-07-meeting.md new file mode 100644 index 000000000..b06706c05 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-06-07-meeting.md @@ -0,0 +1,96 @@ +--- +title: IRC meeting summary for 2018-06-07 +lang: zh_TW +permalink: /zh_TW/meetings/2018/06/07/ +name: 2016-06-07-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- [在 BotBot.me 查看本週記錄](https://botbot.me/freenode/bitcoin-core-dev/msg/100892716/)或 [MeetBot][mb log] +- [MeetBot 會議記錄](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-07-19.00.html) + +--- + +本週會議討論的主題包括：下一個維護版本進度的快速更新、專案成員希望審查者在下週重點關注的拉取請求，以及為 Bitcoin Core 內部追蹤命令列參數找到更好的方法。還有一些關於為各種電腦處理器架構最佳化程式碼的旁話討論。 + +## 0.16.1 發行進度 + +*這不是宣布的主題，但在其他主題之前簡要討論了。* + +Wladimir van der Laan 宣布標記版本 0.16.1 的第二個候選版本，要求 [Gitian][] 建置者產生簽署的校驗和，並說：「我希望這能很快成為最終[版本]。」 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的[目前高優先級 PR 列表][current high-priority PRs]。 + +**討論（[記錄][log hipri]）：** 本週提到的待處理 PR 如下： + +- **[#12196][]：** 新增 `scantxoutset` RPC 方法。先前在列表上。 + +- **[#13062][]：** 使腳本直譯器獨立於儲存類型。先前在列表上。 + +- **[#11082][]：** 新增軟體本身用於修改的設定所使用的新 bitcoin_rw.conf 檔案。先前在列表上。此 PR 的作者 Luke Dashjr 有一些擔憂，在會議稍後作為單獨的主題進行了討論。 + +- **[#12136][]：** 實作 BIP 174 部分簽署的比特幣交易。先前在列表上。Wladimir van der Laan 指出，這在上週有大量活躍的討論。此 PR 的作者 Andrew Chow 說，它和其[相關的 BIP][BIP174] 仍然需要更多審查。Pieter Wuille 補充說：「我也一直在討論將其中的部分拆分的一些想法。」 + +- **[#13111][]：** 新增 `unloadwallet` RPC。先前在列表上。Van der Laan 說它「應該非常接近[可合併]。」 + +還有一些關於處理器特定最佳化和測試的討論，主要由 Pieter Wuille 和 Cory Fields 撰寫和執行，其他幾位開發者協助在特定硬體平台上進行測試。這些與 SSE4、SSSE3、SIMD 和 AVX 有關。 + +## 命令列參數對應 + +**背景：** 如[先前會議][rw conf meet notes]中所討論的，幾位貢獻者正在努力建立一個機器可寫入的設定檔，該檔案將在 Bitcoin Core 的守護程序和 GUI 之間共享，以便當使用者在一個程式中變更設定時，它將在另一個程式中以相同的方式設定。 + +**討論（[記錄][log cli args]）：** Luke Dashjr 提出了這個主題，並透過描述 Bitcoin Core 如何處理啟動參數的[最近變更][#11862]來介紹它。「該變更使如何實作[機器可寫入的設定檔]變得複雜。」 + +幾位開發者表示他們對互動的理解不夠好，無法對此事發表評論，Pieter Wuille 說：「我覺得合適的人不在這裡討論這個。」 + +John Newbery 說，有問題的變更「新增了非常好的程式碼覆蓋率 [...]，所以應該相當直接地遵循。」 + +**結論：** 建議 Dashjr 聯繫一位不在會議中但具有更多知識的開發者，檢查目前可用的測試，並理想情況下在進行任何重大變更之前編寫更多測試以確保正確的行為。Dashjr 同意：「聽起來無論哪種方式，我都應該從測試開始。」 + +## 幽默時刻 + +{% highlight text %} + I do not have the capacity to pay attention to + all PRs in parallel + really? :P + we need to have an AVX2 wumpus + sipa: +1 + +8 +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請[開啟一個議題](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[gitian]: https://github.com/bitcoin-core/gitian.sigs +[rw conf meet notes]: /zh_TW/meetings/2018/05/24/#gui-prune-setting-and-writable-config-files + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-07-19.00.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-15 +[log cli args]: {{log}}#l-102 + +{% include link-to-issues.md issues="12196,13062,11082,12136,13111,11862" %} diff --git a/_posts/zh_TW/meetings/2018-06-14-meeting.md b/_posts/zh_TW/meetings/2018-06-14-meeting.md new file mode 100644 index 000000000..aa948ce8a --- /dev/null +++ b/_posts/zh_TW/meetings/2018-06-14-meeting.md @@ -0,0 +1,99 @@ +--- +title: 2018-06-14 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/06/14/ +name: 2016-06-14-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、Bitcoin Core 是否應該基於生成沒有找零的交易（更好的隱私和費用）或僅花費經過充分確認的輸入的交易（較少可能導致支付失敗）來優化選擇花費哪些輸入，以及一些小主題，主要集中在為各種電腦處理器架構優化 SHA256d 功能。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的[當前高優先級 PR][current high-priority PRs] 列表。 + +**討論（[日誌][log hipri]）：** 本週提到了以下待處理的 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 [單次隨機抽取] 備用幣選擇 + +**背景：** 幾位開發人員一直在努力改進 Bitcoin Core 的幣選擇——它如何選擇要花費哪些比特幣（輸入）——以同時改善隱私、減少交易大小和降低費用。目前的選擇協定從分支定界（BnB）演算法開始，該演算法嘗試在可用輸入和發送金額之間找到匹配。如果這不起作用，則需要一個備用演算法。單次隨機抽取（SRD）演算法隨機將額外輸入新增到部分交易中，直到輸入的總和等於或大於正在花費的金額（包括費用）。 + +**討論（[日誌][log srd]）：** Andrew Chow 請求並介紹了該主題，「我認為我們應該討論 [Gregory Sanders 的] 觀點[這裡][instagibbs comment]。」引用的評論說，「這個新邏輯意味著非 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 的發布簽名進行了一些簡短的討論。 + +## 幽默 + +{% highlight text %} + cd + ~$ +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/101130091/ + +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-07-19.00.html +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[instagibbs comment]: https://github.com/bitcoin/bitcoin/pull/13307#discussion_r192899180 + + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-14-19.00.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-15 +[log srd]: {{log}}#l-58 + +{% include link-to-issues.md issues="12136,13425,13111,13160,13439,13471,13386,13442,13438" %} diff --git a/_posts/zh_TW/meetings/2018-06-21-meeting.md b/_posts/zh_TW/meetings/2018-06-21-meeting.md new file mode 100644 index 000000000..c3c04cfa3 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-06-21-meeting.md @@ -0,0 +1,172 @@ +--- +title: 2018-06-21 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/06/21/ +name: 2016-06-21-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、何時揭露與簽名警報系統相關的 Bitcoin Core 0.12.0 及更早版本的已知 DoS 漏洞以及啟動 DoS 攻擊的機制（中本聰的警報簽名金鑰）、bitcoin-dev 郵件列表的託管變更、預設情況下如何選擇要包含在新交易中的輸入、處理多錢包模式下新錢包的載入、改進的私鑰備份和恢復，以及繼續致力於建立機器可寫配置檔案。 + +## 審查阻礙者[高優先級審查] + +**背景：** 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的[當前高優先級 PR][current high-priority PRs] 列表。 + +**討論（[日誌][log hipri]）：** Pieter Wuille 列出了目前列表中的三個 PR（[#13062][]、[#12196][] 和 [#13425][]），並詢問是否有人想提名其他 PR。João Barbosa 建議 [#13100][]，它新增了一個開啟錢包的選單項目，但它還沒有完全準備好，所以 Wuille 將等到準備好再新增它。 + +## 警報金鑰[公開揭露] + +**背景：** 2010 年，有人建立了一個協定有效的區塊，[建立了超過 1840 億比特幣][value overflow incident]。中本聰鼓勵使用者停止挖礦，並很快發布了 Bitcoin 的更新版本，在追溯軟分叉中更正了該行為，但他隨後向 Bitcoin 軟體新增了一種機制，允許他簽署「警報」訊息，可以直接通知節點營運者問題，甚至預設情況下關閉可能導致金錢損失的某些節點功能。在中本聰對 BitcoinTalk.org 論壇的[最後一篇文章][nakamoto last post]中，他寫道： + +> 「安全模式」警報是 0.3.9 溢位錯誤後的臨時措施。我們可以說使用者可以使用「-disablesafemode」執行，但為了外觀起見，最好不要使用它。它從來沒有打算作為長期功能。安全模式仍然可以透過看到更長（更大的總 PoW）無效區塊鏈來觸發。 + +隨著時間的推移，後續的 Bitcoin Core 開發人員穩步棄用、停用和移除警報功能，在 0.12.1 版本中[預設關閉][alerts off]它，在 0.13.0 版本中[完全移除][alerts removed]它，在 0.14.0 版本中硬編碼[最終警報][final alert]，並（2016 年 11 月）宣布[即將公開揭露][alert key disclosure]中本聰建立的警報簽名金鑰。在 Bitcoin Core 0.12.1 以下版本中發現與警報機制相關的拒絕服務（DoS）漏洞後，揭露被無限期延遲，如 [2017 年 3 月 9 日每週會議][9 March 2017 weekly meeting]中所討論，當時影響了大約 2,600 個節點。 + +**討論（[日誌][log alert]）：** Bryan Bishop 請求並介紹了該主題，「我正在考慮釋出私有[警報簽名]金鑰。[這]會很好地讓它公開並消除該責任。我特別有興趣聽到其他有充分理由不揭露金鑰的人的意見。在宣布[計劃公開揭露]以來的一年多時間裡，我認為沒有提出太多。」 + +Gregory Maxwell 說，「所有受支援的 [Bitcoin Core] 版本都完全[移除了簽名警報系統]，所以現在釋出聽起來相當不錯——除非 0.12 之前的節點仍然很受歡迎，我不相信它們是。」 + +Luke Dashjr 引用他的[節點掃描系統][dashjr addr scanner]說，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。 + +**討論（[日誌][log dev ml]）：** Bryan Bishop 請求並介紹了該主題：「Linux Foundation 正在從電子郵件協定遷移，將不再託管 bitcoin-dev 郵件列表。有一個遷移計劃，但它仍在調查中。」 + +關於列表目前的傳遞問題進行了一些簡短的討論，表達了希望現有舊文章的 URL 保持有效，以及其他遷移問題。 + +**結論：** Bishop 將向郵件列表發送一封電子郵件，希望在遷移到新主機網域之前，一旦他有更多細節就會提供。 + +## 幣選擇 + +**背景：** 幾位開發人員一直在努力改進 Bitcoin Core 的幣選擇——它如何選擇要花費哪些比特幣（輸入）——以同時改善隱私、減少交易大小和降低費用。目前的選擇協定從分支定界（BnB）演算法開始，該演算法嘗試在可用輸入和發送金額之間找到匹配。如果這不起作用，則需要一個備用演算法。單次隨機抽取（SRD）演算法隨機將額外輸入新增到部分交易中，直到輸入的總和等於或大於正在花費的金額（包括費用）。 + +本週的討論是[上週討論][srd 2018-06-14]的延續，關於同一主題。 + +**討論（[日誌][log coin selection]）：** Andrew Chow 請求並介紹了該主題，「我對[單次隨機抽取]備用內容進行了大量模擬（[連結](https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c)）。我看到這個策略有兩個問題：找零可能非常小，錢包中 UTXO 的平均數量相當高。問題是我們是否可以接受這些權衡，或者我們是否需要找到更好的演算法。」 + +Gregory Maxwell 說，「[如果我沒記錯的話]，[單次隨機抽取]沒有什麼根本性的東西使它對使[分支定界]更好地工作有好處，而是它是 \[Mark Erhardt] 在那裡嘗試的第一個替代方案。」 + +Chow 補充說，「嗯，在 [Erhardt] 的模擬中，[單次隨機抽取]表現得相當好，而且非常簡單。儘管我想我們現在可能看到不同的結果。」 + +討論了各種額外的策略及其權衡，但該主題開始變得對一個有時間限制的純文字會議的簡短部分來說變得複雜。 + +**結論：** Chow 建議，「也許這個幣選擇討論最好親自用白板進行，」結束會議討論，儘管 Maxwell 指出，「這會排除無法參加的人。」推測討論將在 PR [#13307][] 和可能的其他地方繼續。 + +## 多錢包會話持久性 + +**背景：** Bitcoin Core 的開發分支（「master」分支）包含允許使用者在多錢包模式下動態載入和卸載單個錢包的程式碼。例如，您可以擁有一個「個人」錢包和一個「商業」錢包，每個都可以單獨開啟或關閉。 + +**討論（[日誌][log multiwallet persistence]）：** Jonas Schnelli 請求並介紹了該主題，「我想在 Bitcoin Core 重新啟動後需要重新載入已載入的錢包不是理想的——特別是在修剪模式下。」也就是說，建立或載入錢包然後重新啟動 Bitcoin Core 而不更改配置檔案的使用者將不得不在下次載入該錢包時重新掃描區塊鏈的最新部分。更糟糕的是，如果重新掃描需要的某些區塊已被修剪，使用者將無法使用錢包。 + +幾位會議參與者建議這就是正在開發可寫 Bitcoin 配置檔案（rwconf）的原因。有關背景，請參見 PR [#11082][] 和 [2018 年 5 月 24 日][rwconf meeting 2018-05-24]和 [2018 年 6 月 7 日][rwconf meeting 2018-06-07]的每週會議記錄。 + +[rwconf meeting 2018-05-24]: /en/meetings/2018/05/24/#gui-prune-setting-and-writable-config-files +[rwconf meeting 2018-06-07]: /en/meetings/2018/06/07/#command-line-argument-mapping + +**結論：** 「好吧，我猜 rw/config 解決了這個問題，所以 /topic，」Schnelli 說。 + +## Bech32x + +**背景：** 幾位 Bitcoin Core 貢獻者一直在努力建立一種新的序列化格式，用於備份和恢復 Bitcoin 私鑰、HD 錢包種子、HD 錢包擴展私鑰和 HD 錢包擴展公鑰。主要目標是用一個新標準取代目前流行的 base58check 和 BIP39 標準，該標準不僅檢測錯誤，還可以為使用者自動更正其中幾個錯誤。該提議格式的當前想法重複使用為建立 [bech32][bip173] 原生 segwit 地址格式而執行的一些工作，因此工作在名稱「bech32x」下進行（但這可能稍後會改變）。 + +**討論（[日誌][log bech32x]）：** Jonas Schnelli 請求並介紹了該主題，「Bech32x 目前具有距離 27 [BCH][wikipedia BCH]，可更正到 7 個字元，感謝 \[Pieter Wuille]。現在的想法是有三個『級別』的更正。[...] 對於 512 位元金鑰材料，七個字元不超過 5% 的更正[所以至少對於該情況需要更多]。」 + +Wuille 提出提供三個使用者可以選擇的程式碼。Gregory Maxwell 說，「我認為使其普遍可由使用者選擇不好。使用者*通常*無法做出有用的決定——但使格式支援多個程式碼在我看來似乎沒問題，儘管它可能會降低編寫精緻解碼器的可能性，因為這將是更多的工作。」 + +Wuille 說，「我們可以確保它們使用相同的欄位和擴展，以便大部分恢復程式碼可以共享。」Wuille 和 Maxwell 繼續談論為此目的選擇最佳 BCH 程式碼的細節。 + +**結論：** 會議結束的時間在討論期間發生，Maxwell 說，「稍後繼續。」 + +## RWConf [可寫 Bitcoin 配置檔案] + +*此主題在會議期間被請求，但沒有足夠的時間。儘管如此，一些參與者在會議結束後立即留下來討論它。* + +**背景：** 如 [2018 年 5 月 24 日會議][rwconf meeting 2018-05-24]中所討論，幾位貢獻者正在努力建立一個機器可寫配置檔案，該檔案將在 Bitcoin Core 的守護程式和 GUI 之間共享，以便當使用者在一個程式中更改設定時，它將在另一個程式中以相同的方式設定。在 [2018 年 6 月 7 日會議][rwconf meeting 2018-06-07]中提出了建立新配置檔案的特定問題，但最熟悉該主題的人不在場；他在這次會議後討論中在場。 + +**討論（[日誌 rwconf][]）：** Luke Dashjr 請求了該主題，並在會議後透過詢問 AJ Towns 是否反對 Dashjr 回復 Towns 的一個提交（該提交更改了 Bitcoin Core 啟動時如何處理命令列和配置檔案參數）來介紹它。這將解決 Dashjr 在建立可寫配置檔案時遇到的問題。 + +Pieter Wuille 建議了一個額外的機制，Towns 指出了 Dashjr 提案與網路配置相關的潛在問題。然而，Towns 說，「無論如何，我不反對更改地圖內容，[它]只是我能看到的獲得相對理智行為的最簡單方法。」 + +**結論：** 沒有明確的結論。推測 Dashjr 將繼續致力於建立機器可寫配置檔案。 + +## 幽默 + +{% highlight text %} + I doubt we know all the vulnerabilities. + I know of at least two but I stopped looking. + gmaxwell: I believe I know of three + Also depends on how you count. :) + that too + i tend to count using the ring of integers +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/101362379/ +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.html +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 + + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-14 +[log alert]: {{log}}#l-30 +[log dev ml]: {{log}}#l-120 +[log coin selection]: {{log}}#l-155 +[log multiwallet persistence]: {{log}}#l-219 +[log bech32x]: {{log}}#l-239 +[log rwconf]: https://botbot.me/freenode/bitcoin-core-dev/msg/101364609/ +[日誌 rwconf]: https://botbot.me/freenode/bitcoin-core-dev/msg/101364609/ + +[dashjr addr scanner]: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html +[value overflow incident]: https://en.bitcoin.it/wiki/Value_overflow_incident +[nakamoto last post]: https://bitcointalk.org/index.php?topic=2228.msg29479#msg29479 +[alerts off]: /en/releases/0.12.1/#miscellaneous +[alerts removed]: /en/releases/0.13.0/#low-level-p2p-changes +[final alert]: /en/releases/0.14.0/#final-alert +[alert key disclosure]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement +[9 march 2017 weekly meeting]: /en/meetings/2017/03/09/#alert-key-disclosure-timeline +[bitnodes scanning system]: https://bitnodes.earn.com/ +[Bitnodes 掃描系統]: https://bitnodes.earn.com/ +[srd 2018-06-14]: /en/meetings/2018/06/14/#srd-single-random-draw-fallback-coin-selection +[wikipedia bch]: https://en.wikipedia.org/wiki/BCH_code + +{% include link-to-issues.md issues="13062,12196,13425,13100,13307,11082" %} diff --git a/_posts/zh_TW/meetings/2018-06-28-meeting.md b/_posts/zh_TW/meetings/2018-06-28-meeting.md new file mode 100644 index 000000000..a47c3dd1e --- /dev/null +++ b/_posts/zh_TW/meetings/2018-06-28-meeting.md @@ -0,0 +1,124 @@ +--- +title: 2018-06-28 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/06/28/ +name: 2016-06-28-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、類似 [BIP39][] 的新種子格式的草案規範、記錄 Bitcoin Core 如何使用 [BIP32][] HD 錢包標準、實作 [BIP151][] 加密點對點連接的進度更新，以及圍繞向錢包軟體描述它們應將哪些輸出腳本視為使用者錢包一部分的新方法的討論。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的[當前高優先級 PR][current high-priority PRs] 列表。 + +**討論（[日誌][log hipri]）：** 唯一專門討論的 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 同意。 + +*注意：會議這部分期間對輸出腳本描述符的擴展討論已移至[單獨的部分](#output-script-descriptors)。* + +## Cipherseed + +**背景：**（討論的一部分。） + +**討論（[日誌][log cipherseed]）：** Jonas Schnelli 請求並介紹了該主題，「我有一個[規範草案][draft bip cipherseed]用於一種新的種子格式，類似於 BIP39，具有一些巧妙的屬性，並且——在將[它]發送到郵件列表之前——將感激回饋。」 + +**結論：** Schnelli 說這「更像是一個公告而不是一個主題」，因此討論被推遲，直到人們有機會閱讀草案。 + +## Core 的 BIP32 衍生「標準」 + +**背景：** HD 錢包規範 [BIP32][] 定義了一組私鑰和公鑰（因此也包括地址）如何從 128 位元到 512 位元的隨機種子衍生。 + +**討論（[日誌][log core hd]）：** Jonas Schnelli 請求並介紹了該主題，「今天在討論中提出 [Core 的] BIP32 衍生方案未在 BIP 中指定。有些人認為它是純粹/原生的 BIP32，但它不是，而其他[錢包]則使用原生 BIP32。」 + +Wladimir van der Laan 同意「如果差異記錄在某處會很好。」Luke Dashjr 反對它成為 BIP，Pieter Wuille 同意，Andrew Chow 建議「只需在[文件儲存庫][docs repo]中記錄衍生就足夠了。」 + +*注意：會議這部分期間對輸出腳本描述符的擴展討論已移至[單獨的部分](#output-script-descriptors)。* + +## P2P 連結臨時加密 + +**背景：** [BIP151][] 指定了一種方法，允許 Bitcoin 節點和客戶端通過加密連接發送其資料，以防止竊聽者直接監視正在傳輸哪些特定交易和區塊。這可以增強隱私的某些方面，例如使某人更難確定哪個 IP 地址首次傳輸特定交易（可能表明該 IP 地址的某人建立了該交易）。在 BIP151 規範中，連接的雙方僅為該連接和該會話生成金鑰——在連接關閉後銷毀金鑰；這些金鑰被描述為「臨時的」。由於臨時金鑰不被重複使用，因此無法使用它們來識別在不同網路（例如 Tor）上執行或在節點更改 IP 地址後執行的相同節點。 + +**討論（[日誌][log link encryption]）：** Gregory Maxwell 請求該主題並以一個問題開始討論，「最近在實作 P2P 連結臨時加密方面是否有任何進展？我知道我們有點在等待一些其他網路重構。」 + +Jonas Schnelli 說，「Armory 已經實作了它，並計劃將其 PR 到 Core（不確定多快以及什麼質量）。」 + +Cory Fields 說，「我不得不暫時將網路[重構]工作放在一邊，所以肯定不要等待它。我很樂意幫助[BIP151 的]實作。我以為我們在等待認證的東西。」 + +Schnelli、Maxwell 和 Pieter Wuille 都同意 BIP151 實作不應等待認證提案。 + +進一步的討論集中在加密的設定協定（初始握手）是否應該更難檢測，因此也更難阻止。然而，Maxwell 說，「我認為我們認為[所考慮方法的]好處太可疑了，特別是因為流量模式將非常清楚地識別 Bitcoin 點對點連結。[...] 所以我認為我們可以實作，唯一可能提出的變更將是作為實作和基準測試的副作用而產生的變更。」 + +**結論：** Schnelli 說，「如果沒有其他人想要研究實作，那麼我將繼續[我的] BIP151 實作。」 + +[draft bip cipherseed]: https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991 + +## 輸出腳本描述符 {#output-script-descriptors} + +*注意：這不是標記的主題，但在會議的其他兩個主題期間進行了討論。為了更容易閱讀，這些單獨的討論已從發生的位置提取出來並統一到這裡的一個主題中。* + +**背景：** Pieter Wuille 一直在研究 Bitcoin Core 錢包如何識別哪些交易屬於特定使用者錢包的[重新設計][gist wallet redesign]。 + +**討論（[日誌第 1 部分][log out desc scantxoutset]、[日誌第 2 部分][log out desc bip32]）：** 作為他錢包重新設計的一部分，Pieter Wuille 說他一直在研究相關的 scriptPubKey 集合的人類可讀描述的[設計][gist output script descriptors]，它提供了「一種通用語言，將有關如何花費整組金鑰以及相關地址/腳本/私鑰/...的所有資訊編碼到一個字串中，包括對多重簽名等的支援...」 + +這透過允許「匯入/匯出[在]這些描述符的層級操作，而不是單個金鑰/腳本/公鑰/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。 + +[gist wallet redesign]: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2 +[gist output script descriptors]: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82 + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/101580174/ +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.html +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 + + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-15 +[log cipherseed]: {{log}}#l-85 +[log core hd]: {{log}}#l-92 +[log link encryption]: {{log}}#l-149 +[log out desc scantxoutset]: {{log}}#l-33 +[log out desc bip32]: {{log}}#l-124 + +[docs repo]: https://github.com/bitcoin-core/docs + +{% include link-to-issues.md issues="12196" %} diff --git a/_posts/zh_TW/meetings/2018-07-05-meeting.md b/_posts/zh_TW/meetings/2018-07-05-meeting.md new file mode 100644 index 000000000..8077d3ec6 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-07-05-meeting.md @@ -0,0 +1,146 @@ +--- +title: 2018-07-05 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/07/05/ +name: 2018-07-05-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot (第 1 部分)][mb log1] 和 [MeetBot (第 2 部分)][mb log2] 上查看本週的日誌 +- MeetBot 的會議記錄[第 1 部分][mb minutes1]和[第 2 部分][mb minutes2] + +*本週 MeetBot 記錄和日誌分為兩部分，因為最初的會議主持人不得不在會議中途離開。* + +--- + +本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求（特別是鑒於即將到來的 Bitcoin Core 0.17 功能凍結）、交替每週會議的時間，以及降低預設最低中繼費用。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的[當前高優先級 PR][current high-priority PRs] 列表。 + +**討論（[日誌][log hipri]）：** Wladimir van der Laan 開始討論時說，「看起來只剩下一件事：[#12196][]」，它新增了一個 `scantxoutset` RPC 方法。然後他補充說，「提醒 [0.17 功能凍結][#12624]是 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 貢獻者來說，這些時間特別不方便。 + +**討論（[日誌][log time]）：** 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 還有一個單獨的最低增量中繼費用設定，有助於防止濫用手續費替換機制，但它與最低中繼費用相互作用。 + +**討論（[日誌][log min relay fee]）：** 引用了 [Twitter 上的討論][min relay 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 一些關於將其減半的東西。」 + +## 幽默 + +{% highlight text %} + probably rather than discussing this here + someone should go make some proposals (including + times in common timezones). + those annoying doodle availability polls handle + this really well. + cfields just volunteered? :) +{% endhighlight %} + +## 參與者 + + +| 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](https://github.com/rfree-d) | +| sipa | [Pieter Wuille][] | +| Varunram | [Varunram Ganesh][] | +| wumpus | [Wladimir van der Laan][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/101804501/ + +[mb minutes1]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-05-19.00.html +[mb minutes2]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-05-19.22.html +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 + + +{% assign log1 = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-05-19.00.log.html" %} +{% assign log2 = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-05-19.22.log.html" %} +[mb log1]: {{log1}} +[mb log2]: {{log2}} +[log hipri]: {{log1}}#l-9 +[log time]: {{log1}}#l-70 +[log min relay fee]: {{log2}}#l-24 + +[min relay twitter]: https://twitter.com/orionwl/status/1014829318986436608 + +{% include link-to-issues.md issues="12196,12624,13547,12458,13072,11658,13557,13298,13414" %} diff --git a/_posts/zh_TW/meetings/2018-07-12-meeting.md b/_posts/zh_TW/meetings/2018-07-12-meeting.md new file mode 100644 index 000000000..7135ae4e5 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-07-12-meeting.md @@ -0,0 +1,137 @@ +--- +title: 2018-07-12 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/07/12/ +name: 2018-07-12-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括宣布一項民意調查以幫助尋找未來每週會議的普遍可接受時間、是否推遲 Bitcoin Core 0.17 的計劃功能凍結日期、是否產生 0.16.2 維護版本（以及何時進行）、將確定性建置環境升級到新版本 Ubuntu 的狀態，以及與錢包自動選擇花費哪些幣（輸入）相關的 PR 的狀態。 + +通常的第一個主題*高優先級審查拉取請求*被跳過了。Wladimir var der Laan 說，「我這次有意跳過了高優先級審查。[似乎]非常清楚[我們]只需要盡快將 0.17 的功能加入。」 + +## 會議時間民意調查 + +**背景：** 如[上次會議][last meeting]所述，專案正在嘗試確定舉行每週會議的最佳時間。 + +**討論（[日誌][log meeting time]）：** Cory Fields 說，「記得投票選擇會議時間。如果您沒有收到關於它的郵件，現在是告訴我的時候！[民意調查]下週此時結束。」 + +**結論：** 如果您是常規貢獻者，請檢查您的電子郵件以獲取相關民意調查或聯繫 Fields。 + +## 推遲功能凍結日期？ + +**背景：** Bitcoin Core 嘗試每六個月發布一個新的主要版本。發布流程的第一步是凍結當前功能集，以便可以將重點轉移到即將發布的版本的成熟、測試和文件編寫上。 + +**討論（[日誌][log feature freeze]）：** Wladimir van der Laan 介紹了該主題，「所以目前的功能凍結是 7 月 16 日，也就是幾天後 [...] 我的問題是，我們應該推遲它嗎，[或者]是否有重要的事情[我們]否則會錯過但[哪些]*幾乎*準備好了？」 + +幾位會議參與者列出了他們希望加入但擔心在凍結前無法完成的事情： + +- [新的 scantxout RPC][#12196]，由 Jonas Schnelli 提到 +- 用於純監視錢包的[新 disableprivatekey 設定][#9662]，由 Schnelli 提到 +- [部分簽名比特幣交易支援][#13557]，由 Andrew Chow 提到 +- [機器可寫配置檔案][#11082]（rwconf），由 Luke Dashjr 提到 + +**結論：** 功能凍結日期推遲一週至星期一，7 月 23 日。 + +## 0.16.2 + +**背景：** Bitcoin Core 偶爾會產生[維護版本][maintenance releases]，將錯誤修復和次要改進[向後移植][backport]到現有版本的 Bitcoin Core。最近的一次是 Bitcoin Core 0.16.1，大約一個月前發布。 + +**討論（[日誌][log 0.16.2]）：** 該主題在會議前被建議。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）。 + +**討論（[日誌][log gitian]）：** 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 的錢包新增了一個選項，使其在花費任何這些輸出時花費接收到同一地址的每個輸出。這防止了同一地址的兩個輸出在單獨的交易中被花費，這是錢包降低隱私的常見方式。缺點是它可能使交易比它們需要的最小值更大。 + +**討論（[日誌][log coin selection]）：** Gregory Maxwell 問，「我猜 [PR #12257 的作者 Kalle Alm] 不在這裡（時區[衝突]），但我想知道 #12257 的狀態如何？」 + +Pieter Wuille 回答，「我推遲了[審查]它，預期其他更具侵入性的幣選擇變更會先進入，但如果這不會在 0.17 中發生，也許我們可以先進行目標群組。」 + +Andrew Chow 建議模擬其行為以及他的單次隨機抽取幣選擇程式碼，如[先前會議][srd]中所述。 + +**結論：** Maxwell 說，「我忘記了 [PR #12257]，聽起來我們其他一些人也忘記了 [...] 請將自己視為已被提醒。」 + +## 小主題 + +- **獨角獸：** 幾位會議參與者注意到 GitHub 頁面再次無法載入，如至少六次先前會議（[1][m1]、[2][m2]、[3][m3]、[4][m4]、[5][m6]、[6][m6]）中所述，而是顯示一個生氣的獨角獸插圖。這阻止了對 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/102030043/ +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-12-19.00.html +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-12-19.00.log.html" %} +[mb log]: {{log}} +[log meeting time]: {{log}}#l-15 +[log feature freeze]: {{log}}#l-28 +[log 0.16.2]: {{log}}#l-77 +[log gitian]: {{log}}#l-104 +[log coin selection]: {{log}}#l-194 + +[last meeting]: /en/meetings/2018/07/05/ +[maintenance releases]: /en/lifecycle/#maintenance-releases +[backport]: https://en.wikipedia.org/wiki/Backporting +[docs repo]: https://github.com/bitcoin-core/docs +[srd]: /en/meetings/2018/06/21/#coin-selection + +[m1]: /en/meetings/2018/04/12/ +[m2]: /en/meetings/2018/04/19/ +[m3]: /en/meetings/2018/04/26/ +[m4]: /en/meetings/2018/05/03/ +[m5]: /en/meetings/2018/05/10/ +[m6]: /en/meetings/2018/05/17/ + +{% include link-to-issues.md issues="13644,12257,12196,9662,13557,11082" %} diff --git a/_posts/zh_TW/meetings/2018-07-19-meeting.md b/_posts/zh_TW/meetings/2018-07-19-meeting.md new file mode 100644 index 000000000..571e7a145 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-07-19-meeting.md @@ -0,0 +1,172 @@ +--- +title: 2018-07-19 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/07/19/ +name: 2018-07-19-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括在星期一 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 的可執行檔[可供測試人員使用][0.16.2rc2 bin]。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的[當前高優先級 PR][current high-priority PRs] 列表。 + +本次會議的特別關注點是如果要將其功能包含在即將發布的 Bitcoin Core 0.17 版本中，需要在未來幾天內合併的 PR，因此也鼓勵審查者檢查 [0.17 里程碑][0.17 milestone]中的 PR 列表。 + +**討論（[日誌][log hipri]）：** 討論了以下 PR： + +- [#9662][] - 新增建立錢包「停用私鑰」選項：純監視錢包的合理模式。由 Jonas Schnelli 請求；Wladimir van der Laan 表示可能很快就可以合併。 + +- [#9502][] - [Qt] 新增暫停/恢復區塊下載的選項。由 Schnelli 請求。 + +- [#13697][] - 在 scantxoutset 中支援輸出描述符。由 Pieter Wuille 請求，Schnelli 支援。在會議[後面](#osd)更詳細地討論。 + + +- [#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 內建錢包的使用者改善隱私並降低交易大小（從而降低費用），並且還有更多改進正在進行中。 + +**討論（[日誌][log rpc coin selection]）：** Andrew Chow 請求該主題並介紹了它：「這是在與一些公司討論幣選擇時提出的。基本上，有些公司對使用 Core 的幣選擇（或其他人的）感興趣，而不是必須實作/自行設計。目前，如果他們想使用 Core 的幣選擇，UTXO 需要在錢包中——也就是說，地址和可能的金鑰需要在錢包中。」 + +Wladimir van der Laan 和 Gregory Maxwell 建議他們可以使用 [`fundrawtransaction`][rpc fundrawtransaction] RPC 來使用 Bitcoin Core 的幣選擇。Jonas Schnelli 補充說，「使用停用私鑰的動態錢包與 fundraw 結合使用似乎非常有效」，部分是指 PR [#9662][]。 + +Chow 說，「這對他們來說並不理想」，Pieter Wuille 接著說，「他們不想使用錢包；他們只想能夠執行幣選擇。」 + +幾位會議參與者建議可以作為程式庫來做，但 Maxwell 反對在專案中將其作為 RPC 或程式庫來做：「我懷疑這是否值得我們為這樣的事情維護一個穩定的介面。例如，[Kalle Alm] 最近的[分組 PR][#12257] 會完全破壞幣選擇的介面 [...] 維護穩定的 [幣選擇] 介面的壓力將對專案有害。[...] 我不想聽到『我們不能實作隱私功能 X，因為它會破壞 [幣選擇] 介面』。」 + +Wladimir van der Laan 說，「我認為這不是我們專案的關注點。有些其他人想要一個幣選擇演算法用於他們自己的目的。[那]很好，他們可以自己從中製作一個程式庫，程式碼是開放原始碼的。」Maxwell 建議，「也許他們應該貢獻使錢包程式碼變得更好，這樣他們就不必編寫自己的（吐舌頭笑臉）。」 + +**結論：** 儘管 RPC 方法的想法普遍遭到反對，Wuille 確實建議了一條前進的道路：「我認為這方面的第一步是我們無論如何都在做的事情：使程式碼本身更加封裝。也許一旦程式碼被充分封裝，其他人就可以將其程式庫化並維護它。」 + +## #13697 更改 scantxoutset 的 API {#osd} + +**背景：** 最近合併的 PR [#12196][] 新增了一個 `scantxoutset` RPC，允許使用者在目前可花費比特幣（UTXO 集）的集合中搜尋對應於一個或多個指定地址、公鑰、私鑰或 HD 金鑰集的任何輸出。如 [6 月 28 日][meet osd]會議中所討論，Pieter Wuille 正在研究一種[新方法][osd gist]來指定錢包應尋找哪些輸出（scriptPubKey），稱為輸出腳本描述符，他有 PR [#13697][] 開放，以新增對此的支援到 `scantxoutset`，而不是目前向錢包描述金鑰和腳本的方式。 + +**討論（[日誌][log scantxoutset api]）：** 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][]。 + +**討論（[日誌][log 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 以獲取下載等資訊。[我們]可能應該更改這些。」完整討論請參見[日誌][log bco]。一些討論也發生在[會議之後][post-meeting bco]。 + +**結論：** 沒有明確的結論。會議後的討論似乎表明目前的流程不會有重大變化。 + +## 下次 CoreDev 技術會議 + +**背景：** Bitcoin Core 團隊的一些成員定期舉辦一個主要針對 Bitcoin Core 貢獻者的僅限邀請活動，讓每個人都能親自審查和討論各種專案。有關更多資訊，請參見 [CoreDev.Tech][] 網站。 + +**討論（[日誌][log coredev meet]）：** Steve Lee 請求並介紹了該主題，「我自願組織下次 Core Dev Tech 聚會。目前的想法是在 10 月的 Scaling Bitcoin 之後在東京舉行，10 月 8-10 日，並以類似於上次在紐約的方式組織。」 + +幾個人感謝 Lee。 + +**結論：** Lee 說，「我計劃發送一份調查來收集一些回饋。如果有人有具體的想法或建議，請隨時與我聯繫。」 + +## 幽默 + +{% highlight text %} + what about #13666 ? + What's in a number? + 13 and 666, can't beat those odds + niice + it was completely planned, obviously + in some timezones it was also opened on + friday the 13th + oh, no + I hope no black cat was sitting on the + keyboard during coding +{% endhighlight %} + + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/102255898/ +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.html + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-13 +[log rpc coin selection]: {{log}}#l-77 +[log scantxoutset api]: {{log}}#l-173 +[log seeder]: {{log}}#l-207 +[log bco]: {{log}}#l-231 +[log coredev meet]: {{log}}#l-279 +[post-meeting bco]: https://botbot.me/freenode/bitcoin-core-dev/msg/102258762/ + + +[meet osd]: /en/meetings/2018/06/28/#output-script-descriptors +[osd gist]: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82 +[coredev.tech]: https://coredev.tech/ + +[0.16.2rc2 bin]: https://bitcoincore.org/bin/bitcoin-core-0.16.2/test.rc2/ +[0.17 milestone]: https://github.com/bitcoin/bitcoin/milestone/33 +[bitcoin-seeder]: https://github.com/sipa/bitcoin-seeder + + +{% include link-to-issues.md issues="9662,9502,13697,13666,13426,13712,8469,13617,12196,12257" %} diff --git a/_posts/zh_TW/meetings/2018-07-26-meeting.md b/_posts/zh_TW/meetings/2018-07-26-meeting.md new file mode 100644 index 000000000..1d71d442b --- /dev/null +++ b/_posts/zh_TW/meetings/2018-07-26-meeting.md @@ -0,0 +1,117 @@ +--- +title: 2018-07-26 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/07/26/ +name: 2018-07-26-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括花費 segwit P2WSH 輸出的交易中元素的命名、每週會議的時間、是否為即將發布的 0.16.2 Bitcoin Core 版本建立最終 Git 標籤，以及 Windows 上編碼文字字串的問題。 + +## P2SH redeemScript 的見證版本命名 + +**背景：** [BIP16][] P2SH 提供了一種機制，您可以接收對腳本雜湊的支付。當您去花費這些比特幣時，您在支出中包含完整的腳本，在那裡它被稱為 redeemScript。[BIP141][] segwit P2WSH 使用幾乎相同的機制，但在 BIP141 中稱其為 witnessScript。不幸的是，對於最終不同的事物有幾個類似的術語，聽起來很相似。 + +**討論（[日誌][log P2WSH redeemScript]）：** 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][bcco #581] 正在追蹤該主題。 + +## 會議時間 + +**背景：** 如 [7 月 5 日會議][alt meet time]中所述，會議參與者擔心可能許多 Bitcoin Core 貢獻者，特別是東亞和大洋洲的貢獻者，由於時區差異而無法參加會議。Cory Fields 進行了一項民意調查以找到最佳會議時間。 + +**討論（[日誌][log time]）：** Bryan Bishop 請求該主題的更新，由 Cory Fields 提供：「[民意調查] 在上週會議結束時關閉。獲勝者：[當前] 時間。[民意調查結果。][time poll results]」 + +當前計劃時間是星期四 19:00 UTC。第二受歡迎的時間是提前一小時。關於結果是否偏向於目前參加會議的人進行了一些快速討論，但有人指出，已努力吸引所有活躍的 Bitcoin Core 貢獻者，包括那些生活在當前會議在清晨舉行的時區的貢獻者。 + +**結論：** 沒有明確的結論。目前似乎不會更改會議時間。 + +## 0.16.2 最終版 + +**背景：** 貢獻者一直在開發編號為 0.16.2 的[次要版本發布][maintenance release]，其中包含向後移植的錯誤修復和次要功能。 + +**討論（[日誌][log 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 需要開啟檔案名或目錄名中包含非拉丁字元的檔案時，這目前會產生問題。 + +**討論（[日誌][log win encoding]）：** Chun Kuan Lee 連結到 PR [#13426][]，請求該主題並介紹了它，「是否可以新增 [一個] `wmain` 函式？」這將為 Windows 使用者在 Bitcoin Core 中新增一個不同的 `main` 函式，可以解決 Windows 特定的平台問題。 + +Wladimir van der Laan 回覆說，「我寧願不要。我認為我們在某個時候有多個進入點，Windows 有一個[特殊的]進入點，但這被清理為只有 `main()` [...]我認為 #13426 是一個太大的變更。」 + +**結論：** 經過一些討論和關於 Windows 到底支援什麼的快速網路搜尋後，幾位貢獻者表示他們應該更仔細地查看 PR #13426，以便可能提出具體的改進建議。 + +## 次要主題 + +- **高優先級審查：** 不是[通常的列表][current high-priority PRs]，而是鼓勵審查者專注於為即將發布的 Bitcoin Core 版本 0.17 [標記][tag 0.17]的 PR 和 issue。 + +## 幽默 + +{% highlight text %} + i hate strings + so do I, but unfortunately they're needed for path names + windows strings cause 2x developer hate :( + they string us along? + luke-jr: i would characterize it that way, yes +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)，我們將更正錯誤。 + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/102496404/ +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-26-19.01.html + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 + +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-26-19.01.log.html" %} +[mb log]: {{log}} +[log p2wsh redeemscript]: {{log}}#l-16 +[log time]: {{log}}#l-46 +[log 0.16.2]: {{log}}#l-69 +[log win encoding]: {{log}}#l-120 + +[bcco #581]: https://github.com/bitcoin-core/bitcoincore.org/issues/581 +[alt meet time]: /en/meetings/2018/07/05/#alternating-meeting-time +[time poll results]: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_a80f9a69d20aab2a +[maintenance release]: /en/lifecycle/#maintenance-releases +[tag 0.17]: https://github.com/bitcoin/bitcoin/milestone/33 + +{% include link-to-issues.md issues="13426" %} diff --git a/_posts/zh_TW/meetings/2018-08-02-meeting.md b/_posts/zh_TW/meetings/2018-08-02-meeting.md new file mode 100644 index 000000000..537ae9c9d --- /dev/null +++ b/_posts/zh_TW/meetings/2018-08-02-meeting.md @@ -0,0 +1,119 @@ +--- +title: 2018-08-02 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/08/02/ +name: 2018-08-02-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [BotBot.me][bbm log] 或 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot 的會議記錄][mb minutes] + +--- + +本週會議討論的主題包括如何處理特定邊緣情況下衝突的編譯器標誌、延續上週關於修復 Windows 使用者檔案名中 Unicode 問題的討論，以及更改程式（特別是其資料庫元件）在某些系統上開啟檔案的方式。 + +在主題開始前，Wladimir van der Laan 簡要連結了 Bitcoin Core 0.17 的[待處理 PR][0.17 prs]、[待處理 issue][0.17 issues] 和計劃的[發布時間表][0.17 schedule]。鼓勵潛在貢獻者審查這些頁面並尋找幫助推進發布的方法。 + +## CXXFLAGS 相關事項 + +**背景：** 用於建置 Bitcoin Core 的腳本將參數（標誌）傳遞給編譯器，告訴它 Bitcoin Core 需要什麼資源以及使用或避免哪些優化。最近，這包括新增 `-mavx2` 標誌（Mode AVX2）以在支援的 CPU 上啟用 SHA256 雜湊的硬體加速。除了 Bitcoin Core 傳遞的標誌外，使用者可以使用 CXXFLAGS 變數傳遞額外的參數，包括標誌 `-mno-avx2`（Mode No AVX2）。如果同時傳遞這兩個標誌，則僅使用最後出現的標誌。 + +**討論（[日誌][log cxxflags]）：** 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 問題 + +**背景：** 如[上次會議][last meeting]所討論，Microsoft Windows 內建的介面在某些情況下阻止 Bitcoin Core 輕鬆開啟包含非拉丁字元的檔案。 + +**討論（[日誌][log broken windows]）：** 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 數量上嚴重受限。 + +**討論（[日誌][log ldb]）：** Gregory Maxwell 請求並介紹了該主題：「最近有一個使用者報告在他的 x86_64 Linux 主機上達到 `select` 限制。使用 `lsof` [列出開啟檔案] 檢查顯示，在我們期望它主要使用 `mmap` 的節點上，leveldb 正在使用大量 FD。顯然 leveldb 有一個 mmap 數量限制。據我所知，我們沒有任何理由不應該增加它。另外，我們應該轉向使用 `poll`，但增加 `mmap` 限制應該是約 1 行變更，除非有人知道不這樣做的理由。」 + +討論了 `mmap` 限制，沒有參與者知道不增加它的理由。會議結束後不久，Suhas Daftuar 為 leveldb 找到了[一個 issue][ldb 128]，可能表明為什麼最初設置了該限制，這似乎支援在 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）沒有註冊帳戶的使用者。 + +{% highlight text %} + 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) +{% endhighlight %} + +## 參與者 + +| 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][] | + +## 免責聲明 + +本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請[開啟 issue][open an issue]，我們將更正錯誤。 + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[open an issue]: https://github.com/bitcoin-core/bitcoincore.org/issues/new + +[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/102785470/ +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-02-19.01.html +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-02-19.01.log.html" %} +[mb log]: {{log}} +[log cxxflags]: {{log}}#l-24 +[log broken windows]: {{log}}#l-87 +[log ldb]: {{log}}#l-202 + +[0.17 prs]: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.17.0 +[0.17 issues]: https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.17.0 +[0.17 schedule]: https://github.com/bitcoin/bitcoin/issues/12624 +[last meeting]: /en/meetings/2018/07/26/ +[ldb 128]: https://github.com/google/leveldb/issues/128 + +{% include link-to-issues.md issues="" %} diff --git a/_posts/zh_TW/meetings/2018-11-01-meeting.md b/_posts/zh_TW/meetings/2018-11-01-meeting.md new file mode 100644 index 000000000..4c2fdab27 --- /dev/null +++ b/_posts/zh_TW/meetings/2018-11-01-meeting.md @@ -0,0 +1,126 @@ +--- +title: 2018-11-01 IRC 會議摘要 +lang: zh_TW +permalink: /zh_TW/meetings/2018/11/01/ +name: 2018-11-01-meeting +layout: page +type: meetings +version: 1 +--- +{% include toc.html %} +{% include references.md %} + +- 在 [MeetBot][mb log] 上查看本週的日誌 +- [MeetBot][mb minutes] 的會議記錄 + +--- + +本週貢獻者會議涵蓋的主題包括提名高優先級審查的拉取請求、非 HD 錢包程式碼路徑缺少測試、錢包重構進度審查以及 AppVeyor CI 執行的測試產生的偽造失敗。在會議結束時，鼓勵貢獻者分享他們正在積極參與的專案。 + +## 高優先級審查 + +**背景：** 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的[當前高優先級 PR][current high-priority PRs] 列表。 + +**討論（[日誌][log hipri]）：** 討論了以下 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 中[引入了對][bitcoin core bip32] [BIP32][] 階層確定性錢包的支援，大大簡化了錢包備份和恢復過程。使用者可以對錢包的擴展私鑰主金鑰（錢包中的所有金鑰都從中確定性生成）進行一次備份，而不是定期備份無定形的金鑰池。在 0.16.0 版本之前，使用者可以透過指定 `-usehd=0` 來選擇停用此功能。當刪除此選項時，非 HD 錢包程式碼路徑的測試也被刪除了。雖然較新版本的 Bitcoin Core 無法再建立非 HD 錢包，但仍然可以匯入它們。 + +**討論（[日誌][log nonhdwallets]）：** 此主題由 luke-jr 建議。由於 Bitcoin Core 不再建立非 HD 錢包，provoostenator、achow101 和 jfnewbery 提到，非 HD 版本的錢包必須打包到測試框架中。Sipa 指出了測試錢包升級場景的重要性（在 Bitcoin Core 升級和/或降級時正在備份和恢復的錢包的[失敗模式][wallet failure modes]可能導致資金無法恢復的損失）。 + +**結論：** 應在 issue [#14536][] 中繼續討論各種方法。 + +## 錢包重構 + +**背景：** Bitcoin Core 錢包正在積極重構。這項工作有多個目標，其中包括：改進 Bitcoin Core 的架構模組化、簡化錢包的程式碼庫和引入新功能。這一更廣泛目標集中的一個專案是[輸出描述符][output descriptors]語言。此語言在 0.17.0 中引入，旨在將金鑰集的支出要求編碼為單個字串；這種分類未花費輸出的方法改進了先前存在的 [isMine][] 邏輯，其複雜性和效率低下阻礙了更高級錢包功能的開發（例如，支援與 [PSBT][] 相容的金鑰簽名協定的硬體錢包整合）。 + +**討論（[日誌][log walletrefactor]）：** 在 [#14565][] 中，Sipa 繼續他的工作，改進 importmulti RPC 的邏輯，以限制多餘的金鑰或腳本資料被匯入；這對於支援「舊式」描述符匯入是必要的，這些匯入會隱式地將描述符轉換為現有的錢包結構（[#14491][]）。Sipa 還將處理使用描述符而不是金鑰池所需的一些公鑰快取準備工作。為了支援原生描述符匯入，現有的金鑰池/isMine 邏輯必須重構為可以由舊錢包邏輯或描述符實例化的抽象層之後。 + +**結論：** Meshcollider 將在 #14565 完成後重新基底 #14491。Achow101 將在此之後在 #14491 之上重新基底 [#14075][]。#14705 使設定了 --disable-private-keys 的錢包能夠從金鑰池匯入和提取公鑰。這有助於將僅監視錢包與儲存私鑰的錢包「[分離][wallet stuff]」。沒有此 PR，停用私鑰的錢包將不會從金鑰池提取公鑰。這對於與 Bitcoin Core 作為外部簽署者互動的硬體錢包很有用；為了支援此用例，金鑰池必須接受硬體錢包生成的僅監視公鑰的匯入和檢索。討論的結論是建議將 ryanofsky 關於其[程式碼][#10973][分離][#14437] PR 的狀態更新保留到第二次 Bitcoin Core 錢包貢獻者會議。 + +**注意：** 在東京 [CoreDev][coredev] 會議的「[錢包內容][wallet stuff]」會議期間，提議組織一個單獨的專注於錢包的會議。在 [10 月 19 日][walletmeeting1]星期五，舉行了第一次 Bitcoin Core 錢包會議。它安排在每隔一個星期五 19:00:00 UTC 舉行。第二次會議於 [11 月 2 日][walletmeeting2]舉行。 + +## AppVeyor 失敗 + +**背景：** AppVeyor 是一個託管的持續整合服務，為 Bitcoin Core 提供 Microsoft Visual C++ (MSVC) 建置環境。在這些環境中產生的二進位檔案僅用於跨平台測試目的。 + +**討論（[日誌][log appveyor]）：** 在 AppVeyor 上執行的功能測試偶爾失敗。這讓一些貢獻者感到沮喪。Sipa 要求解決此問題。 + +**結論：** 有一個開放的 issue [#14446][]，詳細說明了失敗類型。PR [#13501][] 可能會緩解這些失敗的一個類別。 + +## 大家在做什麼？ + +**[日誌][log workingon]** + +- jarthur：RPC API 的 UNIX 網域通訊端。[先前的討論][unixsocketsdiscussion]。[開放的 issue][unixsocketissue]。 +- luke-jr：重新基底他的 PR +- achow101：PSBT 和硬體錢包整合 +- jnewbery：年底前花更多時間審查錢包 PR +- instagibbs：審查錢包 PR 和硬體錢包整合 +- sipa：P2P 網路的私有驗證協定。[先前的討論][countersigndiscussion]。[更多閱讀][countersigngist]（注意：提議的協定存在已知漏洞）。 +- 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][open an issue]，我們將更正錯誤。 + +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 +[open an issue]: https://github.com/bitcoin-core/bitcoincore.org/issues/new + +[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-11-01-19.04.html +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-11-01-19.04.log.html" %} +[mb log]: {{log}} +[log hipri]: {{log}}#l-16 +[log nonhdwallets]: {{log}}#l-56 +[log walletrefactor]: {{log}}#l-86 +[log appveyor]: {{log}}#l-131 +[log workingon]: {{log}}#l-151 + +[bitcoin core bip32]: https://bitcoincore.org/en/2016/08/23/release-0.13.0/#bip32-hd-wallet-support +[wallet failure modes]: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2#segwit-wallet-support +[output descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md +[isMine]: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2#current-design +[PSBT]: https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md +[wallet stuff]: http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-10-09-wallet-stuff/ +[coredev]: https://coredev.tech/ +[walletmeeting1]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-19-19.04.log.html +[walletmeeting2]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-11-02-19.01.log.html +[unixsocketsdiscussion]: http://www.erisian.com.au/bitcoin-core-dev/log-2018-10-25.html#l-939 +[unixsocketissue]: https://github.com/bitcoin/bitcoin/issues/9919 +[countersigndiscussion]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.log.html#l-200 +[countersigngist]: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b + +{% include link-to-issues.md issues="10973,13501,13932,14046,14075,14336,14350,14437,14446,14477,14491,14532,14536,14565" %} diff --git a/_posts/zh_TW/pages/2016-01-01-about.md b/_posts/zh_TW/pages/2016-01-01-about.md new file mode 100644 index 000000000..41df43291 --- /dev/null +++ b/_posts/zh_TW/pages/2016-01-01-about.md @@ -0,0 +1,38 @@ +--- +title: 關於我們 +name: about +id: zh_tw-about +permalink: /zh_TW/about/ +type: pages +layout: page +lang: zh_TW +version: 3 +--- + +## 關於我們 + +Bitcoin Core 是一個[開源](https://opensource.org/)專案，負責維護和發布名為「Bitcoin Core」的比特幣客戶端軟體。 + +它是中本聰發表著名的 [Bitcoin 白皮書](/bitcoin.pdf)後所發布的原始比特幣軟體客戶端的直接後繼版本。 + +[Bitcoin Core](https://github.com/bitcoin/bitcoin) 包含用於完整驗證區塊鏈的「全節點」軟體以及比特幣錢包。該專案目前也維護相關軟體，例如密碼學函式庫 [libsecp256k1](https://github.com/bitcoin-core/secp256k1) 以及其他位於 [GitHub](https://github.com/bitcoin-core) 的專案。 + +任何人都可以[為 Bitcoin Core 做出貢獻](/zh_TW/contribute/)。 + +## 團隊 + +Bitcoin Core 專案擁有龐大的開源開發者社群，有許多不定期為程式碼庫做出貢獻的參與者。 +還有更多人貢獻研究、同儕審查、測試、文件撰寫和翻譯。 + +### 維護者 + +專案維護者擁有提交權限，負責合併來自貢獻者的修補程式。他們執行整理工作，合併團隊認為應該合併的修補程式。他們也作為最後檢查，確保修補程式安全且符合專案目標。維護者的角色由專案貢獻者共同協議決定。 + +### 貢獻者 + +每個人都可以自由提議程式碼變更，以及測試、審查和評論開放的 Pull Requests。 +任何為 Bitcoin Core 專案貢獻程式碼、審查、測試、翻譯或文件的人都被視為貢獻者。 +每個 Bitcoin Core 軟體版本的發行說明都包含致謝章節，以表彰所有在前一個發行週期中為專案做出貢獻的人。 +程式碼貢獻者名單可在 [Github][github-contributors] 上找到。 + +{% include references.md %} diff --git a/_posts/zh_TW/pages/2016-01-01-blog.md b/_posts/zh_TW/pages/2016-01-01-blog.md index 607f7e2d4..cc6bbc3c7 100755 --- a/_posts/zh_TW/pages/2016-01-01-blog.md +++ b/_posts/zh_TW/pages/2016-01-01-blog.md @@ -2,7 +2,7 @@ layout: post-index type: pages lang: zh_TW -title: Blog +title: 部落格 name: blog permalink: /zh_TW/blog/ version: 0 diff --git a/_posts/zh_TW/pages/2016-01-01-contribute.md b/_posts/zh_TW/pages/2016-01-01-contribute.md new file mode 100644 index 000000000..100fbe446 --- /dev/null +++ b/_posts/zh_TW/pages/2016-01-01-contribute.md @@ -0,0 +1,43 @@ +--- +title: 我能如何貢獻？ +name: contribute +id: zh_tw-contribute +permalink: /zh_TW/contribute/ +type: pages +layout: page +lang: zh_TW +version: 5 +--- + +歡迎您為本專案做出貢獻！ +我們的主要原始碼儲存庫[託管在 GitHub 上](https://github.com/bitcoin/bitcoin/)，您可以在以下幾個方面提供協助： + + - 改善我們的文件（請參閱 [README.md][README.md] 和 [doc 資料夾][doc]） + - [翻譯][translation_process.md] + - 測試程式碼、測試發布版本 + - 參與郵件列表討論 + - 改善我們的使用者介面 + - 撰寫程式碼（修復開放問題或實作新功能） + +歡迎回報[問題][issues]和開啟 [Pull Requests][pulls]，但請查看[貢獻指南](/zh_TW/faq/contributing-code)以了解我們的工作流程。 + +**討論** + +大多數 Bitcoin Core 相關討論發生在 irc.libera.chat 上的以下 IRC 頻道： + +- [#bitcoin-core-dev] - 主要討論 +- [#bitcoin-core-builds] - 建置系統和發布討論 +- [#bitcoin-core-gui] - 圖形使用者介面討論 + +也有一個關於 Bitcoin 協議討論的郵件列表 [bitcoin-dev][]。 + +**為本網站做出貢獻** + +您也可以為本[網站][website-contrib]進行翻譯或做出貢獻。 + +[README.md]: https://github.com/bitcoin/bitcoin/blob/master/README.md +[doc]: https://github.com/bitcoin/bitcoin/tree/master/doc +[translation_process.md]: https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md +[website-contrib]: https://github.com/bitcoin-core/bitcoincore.org/blob/master/CONTRIBUTING.md + +{% include references.md %} diff --git a/_posts/zh_TW/pages/2016-01-01-index.md b/_posts/zh_TW/pages/2016-01-01-index.md index 4d35e61ba..62dfc0749 100755 --- a/_posts/zh_TW/pages/2016-01-01-index.md +++ b/_posts/zh_TW/pages/2016-01-01-index.md @@ -2,10 +2,10 @@ layout: home type: pages lang: zh_TW -title: Home +title: 首頁 name: index permalink: /zh_TW/ version: 0 --- -Home page +首頁 diff --git a/_posts/zh_TW/pages/2016-01-01-meetings.md b/_posts/zh_TW/pages/2016-01-01-meetings.md index 6813d1e25..3b2864745 100755 --- a/_posts/zh_TW/pages/2016-01-01-meetings.md +++ b/_posts/zh_TW/pages/2016-01-01-meetings.md @@ -2,12 +2,12 @@ layout: page type: pages lang: zh_TW -title: IRC Meetings +title: IRC 會議 name: meetings permalink: /zh_TW/meetings/ version: 0 --- -The project usually holds IRC meetings every Thursday at 19:00 UTC in `#bitcoin-core-dev` on irc.freenode.net. -Everyone is welcome to attend. +本專案通常於每週四 UTC 時間 19:00 在 irc.libera.chat 的 `#bitcoin-core-dev` 頻道舉行 IRC 會議。 +歡迎所有人參加。 {% include meetings.html %} diff --git a/_posts/zh_TW/pages/2016-01-01-releases.md b/_posts/zh_TW/pages/2016-01-01-releases.md index db195e04b..36edbd538 100755 --- a/_posts/zh_TW/pages/2016-01-01-releases.md +++ b/_posts/zh_TW/pages/2016-01-01-releases.md @@ -2,7 +2,7 @@ layout: page type: pages lang: zh_TW -title: Releases +title: 版本發布 name: releases permalink: /zh_TW/releases/ version: 0 diff --git a/_posts/zh_TW/pages/2016-01-13-supported-bips.md b/_posts/zh_TW/pages/2016-01-13-supported-bips.md new file mode 100644 index 000000000..218cdaaed --- /dev/null +++ b/_posts/zh_TW/pages/2016-01-13-supported-bips.md @@ -0,0 +1,14 @@ +--- +title: Bitcoin Core 支援的 BIP +name: supported-bips +type: pages +layout: page +lang: zh_TW +permalink: /zh_TW/bips/ +version: 2 +redirect_from: + - /zh_TW/bips/ +--- +Bitcoin Core 支援以下 [BIP][BitcoinCoreDocBips]。 + +{% include references.md %} diff --git a/_posts/zh_TW/pages/2016-01-15-lifecycle.md b/_posts/zh_TW/pages/2016-01-15-lifecycle.md new file mode 100644 index 000000000..554bb7369 --- /dev/null +++ b/_posts/zh_TW/pages/2016-01-15-lifecycle.md @@ -0,0 +1,84 @@ +--- +title: 軟體生命週期 +name: software-life-cycle +id: zh_tw-software-life-cycle +permalink: /zh_TW/lifecycle/ +layout: page +type: pages +lang: zh_TW +version: 2 +--- +{% include toc.html %} + +本文件描述了由 Bitcoin Core 專案發布的 Bitcoin Core 軟體套件的生命週期。這符合商業軟體的標準維護政策。 + +## 版本編號 + +Bitcoin Core 發布版本按以下方式編號：主版本號.次版本號（MAJOR.MINOR），候選版本則加上 rc1、rc2 等後綴。 + +## 主要版本 + +我們的目標是每 6-7 個月發布一個主要版本。 + +這些版本將編號為 22.0、23.0 等。 + +## 維護版本 {#maintenance-releases} + +我們將提供維護「次要版本」來修復主要版本中的錯誤。一般來說，我們不會在維護版本中引入主要的新功能（共識規則除外）。但是，在必要時我們可能會新增次要功能，並且我們會向後移植共識規則變更，例如軟分叉。 + +次要版本將編號為 22.1、22.2、23.1、23.2 等。 + +## 共識規則 + +變更共識規則的提案總是首先在維護版本（例如 22.2、23.1 等）中發布。這使企業使用者更容易評估和測試該提案，因為與主要版本相比，其變更集較小。這也允許遵循更保守升級路徑的使用者能夠更及時地採用共識規則變更。 + +## 維護期 + +我們維護主要版本直到其「維護終止」（Maintenance End）日期。我們通常維護當前和前一個主要版本。 +例如，如果當前版本是 23.0，則 22.0 也被視為正在維護中。 +一旦發布 24.0，則 22.0 將被視為「維護終止」。 +隨著主要版本逐漸老化，只有越來越重大的問題才會被向後移植，並且需要越來越多或越來越嚴重的問題才能保證發布新的次要版本。 +一旦軟體到達「維護終止」期間，它將僅接收重大安全修復，直到生命週期終止（End-of-Life, EOL）日期。 +在 EOL 之後，使用者必須升級到更新版本才能接收安全更新，儘管社群可能會盡力為重大問題提供修復。 +通常建議執行當前或前一個主要版本的最新維護版本（點版本）。 + +請注意，次要版本會獲得錯誤修復、翻譯更新和軟分叉。[Transifex][bitcoin-transifex-link] 上的翻譯僅對最後兩個主要版本開放。 + +例如，主要版本 22.0 於 2021-09-13 發布，我們提供維護修復（點版本）直到 2022-12-14。 +重大安全問題仍將繼續修復，直到 2023-04-01 的 EOL 日期。 +但是，要利用錯誤修復，您必須升級到更新的主要版本。 + +## 時程表 + +一旦達到 EOL，您將需要升級到更新的版本。 + +| 版本 | 發布日期 | 維護終止 | 生命週期終止 | +|---------|--------------|-----------------|-------------| +{% include posts/maintenance-table.md %} + +\* _我們的目標是每 6-7 個月發布一個主要版本_ + +_TBA：待公告_ + +## 協議版本編號 + +上述描述僅描述 Bitcoin Core 軟體版本。Bitcoin 系統的許多其他部分包含自己的版本號。幾個範例： + +- 每個**交易**都包含一個版本號。 +- **P2P 網路協議**使用版本號來讓節點宣告它們支援的功能。 +- Bitcoin Core 的**內建錢包**有自己的內部版本號。 + +這些版本號刻意與 Bitcoin Core 的版本號分離，因為 Bitcoin Core 專案要麼沒有直接控制它們（如區塊和交易的情況），要麼試圖與其他專案保持相容性（如網路協議的情況），或者允許在某些版本中可能不會進行重大變更（如內建錢包有時的情況）。 + +共識協議本身沒有版本號。 + +## 與 SemVer 的關係 + +Bitcoin Core 軟體版本編號不遵循 [SemVer][] 可選版本編號標準，但其發布版本編號在表面上是相似的。SemVer 是為一般軟體函式庫設計的，個人可以選擇按照自己的步調升級函式庫，甚至如果不喜歡變更，可以停留在較舊的版本上。 + +Bitcoin 的某些部分，最顯著的是共識規則，不是這樣運作的。為了使新的共識規則生效，它必須由一定數量的礦工、全節點或兩者來執行；一旦它生效，不知道新規則的軟體可能會產生或接受無效的交易（儘管升級的設計是為了盡可能防止這種情況發生）。 + +因此，對於共識規則的變更以及其他需要或希望全網路採用的更新，Bitcoin Core 偏離了 SemVer。Bitcoin Core 將這些變更作為維護版本（`x.y`）而不是主要版本（`x.0`）發布；這最小化了修補程式的大小，以便讓盡可能多的人更容易檢查、測試和部署它。這也使得可以將相同的修補程式向後移植到多個先前的主要版本，進一步增加可以輕鬆升級的使用者數量，儘管並不總是有足夠的志願者來管理這個過程。 + +[SemVer]: https://semver.org/ +[bitcoin-transifex-link]: https://explore.transifex.com/bitcoin/bitcoin/ diff --git a/_posts/zh_TW/pages/2016-01-18-segwit-wallet-dev.md b/_posts/zh_TW/pages/2016-01-18-segwit-wallet-dev.md new file mode 100644 index 000000000..e35df1d44 --- /dev/null +++ b/_posts/zh_TW/pages/2016-01-18-segwit-wallet-dev.md @@ -0,0 +1,174 @@ +--- +version: 4 +title: 隔離見證錢包開發指南 +name: segwit-wallet-dev +id: zh_tw-segwit-wallet-dev +type: pages +layout: page +lang: zh_TW +permalink: /zh_TW/segwit_wallet_dev/ +--- +{% include toc.html %} +{% include references.md %} + +本文件的大部分內容可在與隔離見證相關的 BIP 中找到，包括 [BIP141][]、[BIP143][]、[BIP144][] 和 [BIP145][]。請將此視為其他相關文件的首要參考點，以及應該做和不應該做的檢查清單。 + +### 基本隔離見證支援 + +為了被視為基本層級的 segwit 相容，錢包必須實作本節中的所有功能： + +#### 發送至 P2SH + +* segwit 相容錢包必須支援 pay-to-script-hash（[BIP16][]）及其位址格式（[BIP13][]）。 +* 對於進行支付，錢包必須能夠正確地將給定的 P2SH 位址轉換為 scriptPubKey，並建立交易。 +* 對於接收支付，錢包必須能夠基於 P2WPKH 腳本（如下定義）建立 P2SH 位址，並能夠識別支付至此類位址的款項。 +* 這是強制性要求，即使錢包僅接受單一簽名支付。 + +#### 建立 P2SH-P2WPKH 位址 + +* P2SH-P2WPKH 位址可與 Bitcoin 原始的單一簽名 P2PKH 位址（前綴為 1 的位址）相比較。 +* 與任何其他 P2SH 位址一樣，P2SH-P2WPKH 位址的前綴為 3。 +* 在 P2SH-P2WPKH UTXO 被花費且 redeemScript 被揭露之前，P2SH-P2WPKH 位址與非 segwit P2SH 位址（例如非 segwit 多重簽名位址）無法區分。 +* 當僅使用 1 個公鑰接收支付時（類似 P2PKH），應使用 P2SH-P2WPKH 位址。 +* P2SH-P2WPKH 使用與 P2PKH 相同的公鑰格式，但有一個非常重要的例外：P2SH-P2WPKH 中使用的公鑰必須是壓縮的，即大小為 33 位元組，並以 0x02 或 0x03 開頭。使用任何其他格式（如未壓縮的公鑰）可能導致資金永久損失。 +* 建立 P2SH-P2WPKH 位址： + 1. 計算公鑰的 SHA256 的 RIPEMD160（keyhash）。儘管 keyhash 公式與 P2PKH 相同，但為了更好的隱私和防止意外使用未壓縮金鑰，應避免重複使用 keyhash。 + 2. P2SH redeemScript 總是 22 位元組。它以 OP_0 開頭，後接 keyhash 的標準推送（即 0x0014{20-byte keyhash}）。 + 3. 與任何其他 P2SH 相同，scriptPubKey 是 OP_HASH160 hash160(redeemScript) OP_EQUAL，位址是對應的前綴為 3 的 P2SH 位址。 + +#### 交易序列化 + +* segwit 相容錢包必須支援原始交易格式，即 nVersion|txins|txouts|nLockTime。 +* segwit 相容錢包也必須支援新的序列化格式，即 nVersion|marker|flag|txins|txouts|witness|nLockTime。 + * nVersion、txins、txouts 和 nLockTime 的格式與原始格式相同。 + * marker 必須為 0x00。 + * flag 必須為 0x01。 + * witness 是交易所有見證資料的序列化。 + * 每個 txin 都關聯一個見證欄位。因此，沒有見證欄位數量的指示，因為它由 txins 的數量暗示。 + * 每個見證欄位以一個 compactSize [整數](https://bitcoin.org/en/developer-reference#compactsize-unsigned-integers)開頭，以指示對應 txin 的堆疊項目數量。然後是對應 txin 的見證堆疊項目（如果有）。 + * 每個見證堆疊項目以一個 compactSize 整數開頭，以指示項目的位元組數。 + * 如果 txin 未與任何見證資料關聯，則其對應的見證欄位是確切的 0x00，表示見證堆疊項目數量為零。 +* 如果交易中的所有 txins 都未與任何見證資料關聯，則交易必須以原始交易格式序列化，不包含 marker、flag 和 witness。例如，如果沒有任何 txins 來自 segwit UTXO，則必須以原始交易格式序列化。（例外：coinbase 交易） +* 交易序列化的範例可在 BIP143 的範例章節中找到。錢包開發者可使用這些範例來測試其實作是否正確解析新的序列化格式。 + +#### 交易 ID + +* 在 segwit 下，每個交易將有 2 個 ID。 +* txid 的定義保持不變：原始序列化格式的雙 SHA256。 +* 定義了一個新的 wtxid，它是包含見證資料的新序列化格式的雙 SHA256。 +* 如果交易沒有任何見證資料，則其 wtxid 與 txid 相同。 +* txid 仍然是交易的主要識別碼： + * 在引用先前輸出時，它必須在 txin 中使用。 + * 如果錢包或服務目前使用 txid 識別交易，預期在 segwit 中繼續使用。 + +#### P2SH-P2WPKH 的簽名產生和驗證 + +* 對於花費非 segwit UTXO，簽名產生演算法保持不變。 +* 對於花費 P2SH-P2WPKH： + * scriptSig 必須僅包含 redeemScript 的推送。 + * 對應的見證欄位必須恰好包含 2 個項目：簽名後接公鑰。 + * [BIP143][] 中描述了 segwit 腳本的新簽名產生演算法。開發者應仔細遵循說明，並利用 [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#P2SHP2WPKH) 中的 P2SH-P2WPKH 範例來確保能夠重現 sighash。 + * [BIP143][] 簽名產生演算法涵蓋了被花費輸入的值，這簡化了氣隙輕量級錢包和硬體錢包的設計。 + * 請注意，對於 P2SH-P2WPKH，scriptCode 總是 26 位元組（包括前導大小位元組），即 0x1976a914{20-byte keyhash}88ac，而不是 redeemScript 或 scriptPubKey。 + * [範例](https://blockchainprogramming.azurewebsites.net/checktx?txid=8139979112e894a14f8370438a471d23984061ff83a9eba0bc7a34433327ec21) + +#### 網路服務（可選） + +* 如果錢包將透過點對點網路發送和接收交易，則需要網路服務。 +* 具有 segwit 能力的節點將透過服務位元廣告它們可以提供見證：NODE_WITNESS = (1 << 3)。 +* 沒有任何見證資料（因此以原始格式序列化）的交易可以發送到具有或不具有 NODE_WITNESS 支援的節點。 +* 花費 segwit UTXO 的交易（因此以新格式序列化）只能發送到具有 NODE_WITNESS 支援的節點。 +* 花費 segwit UTXO 但見證資料被剝離（因此以原始格式序列化）的交易可以發送到不具有 NODE_WITNESS 支援的節點。但是，此類交易在 segwit 啟動後無效，不會被區塊接受。 +* 網路服務的詳細資訊可在 [BIP144][] 中找到。 + +#### 使用者隱私 + +* 在 segwit 交易變得普遍之前，此交易類型可能使 Bitcoin 追蹤更容易。 +* 使用 P2SH-P2WPKH 作為預設找零輸出也可能對隱私產生影響。 + +#### 交易手續費估算 + +* 不使用交易大小，而是定義了一個新的指標，稱為「虛擬大小」（vsize）。 +* 交易的 vsize 等於原始序列化大小的 3 倍，加上新序列化的大小，將結果除以 4 並向上取整到下一個整數。例如，如果交易使用新序列化為 200 位元組，並在移除 marker、flag 和 witness 後變為 99 位元組，則 vsize 為 (99 * 3 + 200) / 4 = 125（向上取整）。 +* 非 segwit 交易的 vsize 就是其大小。 +* 交易手續費應透過將 vsize 與其他交易比較來估算，而不是大小。 +* 開發者應小心避免在手續費估算中出現 4 倍的錯誤。 + +#### 啟動 {#upgrade-safety} + +* 從區塊高度 481824 開始，所有 SegWit 就緒節點開始強制執行新的 SegWit 共識規則。 + +#### 向後相容性 + +* 應繼續支援發送和接收舊版 P2PKH 支付（前綴為 1 的位址）。 + +### 複雜腳本支援 + +如果錢包支援單一簽名以外的腳本類型（例如多重簽名），則必須滿足基本要求以外的更多要求： + +#### 建立 P2SH-P2WSH 位址 + +* P2SH-P2WSH 位址可與 Bitcoin 原始的 P2SH 位址相比較，它允許用固定大小的位址表示任意複雜的腳本。 +* 與任何其他 P2SH 和 P2SH-P2WPKH 位址一樣，P2SH-P2WSH 位址的前綴為 3。在 UTXO 被花費之前，它們無法區分。 +* 建立 P2SH-P2WSH 位址： + 1. 定義一個腳本，稱為（witnessScript）。 + 2. 計算 witnessScript 的 SHA256（scripthash）。請注意使用單一 SHA256，而不是雙 SHA256 或 RIPEMD160(SHA256)。 + 3. P2SH redeemScript 總是 34 位元組。它以 OP_0 開頭，後接 scripthash 的標準推送（即 0x0020{32-byte scripthash}）。 + 4. 與任何其他 P2SH 相同，scriptPubKey 是 OP_HASH160 hash160(redeemScript) OP_EQUAL，位址是對應的前綴為 3 的 P2SH 位址。 +* 腳本限制 + * 腳本評估不得失敗，並且必須在評估後僅留下一個且僅一個 TRUE 堆疊項目。否則，評估失敗。 + * P2SH-P2WSH 腳本內的任何公鑰必須是壓縮金鑰，否則資金可能永久損失。 + * 如果使用 OP_IF 或 OP_NOTIF，其參數必須是空向量（表示 false）或 0x01（表示 true）。使用其他值可能導致資金永久損失。（[BIP 草案](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html)） + * 如果 OP_CHECKSIG 或 OP_CHECKMULTISIG 返回失敗，則所有簽名必須是空向量。否則，資金可能永久損失。（[BIP146][]） + * witnessScript 有 3600 位元組的預設政策限制。除了 witnessScript，最多可以有 100 個見證堆疊項目，每個最多 80 位元組。超過這些限制的交易可能不會被中繼或包含在區塊中。 + * 許多原始腳本共識限制，例如 10000 位元組腳本大小、201 nOpCount，仍然適用於 P2SH-P2WSH。 + * P2SH 的 520 位元組腳本大小限制不適用於 P2SH-P2WSH。它被 3600 位元組政策限制和 10000 位元組共識限制取代。 + +#### P2SH-P2WSH 的簽名產生和驗證 + +* 對於花費 P2SH-P2WSH： + * scriptSig 必須僅包含 redeemScript 的推送。 + * 對應見證欄位的最後一個見證項目必須是 witnessScript。 + * 應用新的 [BIP143][] 簽名產生演算法： + * 在不使用任何 OP_CODESEPARATOR 的情況下，scriptCode 是前面帶有 witnessScript 大小的 compactSize 整數的 witnessScript。例如，如果腳本是 OP_1（0x51），則序列化的 scriptCode 是（0x0151）。 + * 對於任何包含 OP_CODESEPARATOR 的不尋常腳本，請參閱 [BIP143][] 以了解確切的語義。 + * witnessScript 之前的任何見證堆疊項目都用作腳本評估的輸入堆疊。輸入堆疊不會被解釋為腳本。例如，不需要使用 0x4c（OP_PUSHDATA1）來「推送」大項目。 + * 要驗證簽名產生和堆疊序列化的正確性，請始終針對 [BIP143][] 中的範例進行測試。 + * [範例](https://blockchainprogramming.azurewebsites.net/checktx?txid=954f43dbb30ad8024981c07d1f5eb6c9fd461e2cf1760dd1283f052af746fc88) + +### Segwit 原生位址（可選）{#advanced-designs} + +以下功能對於初始 segwit 支援不是必需的。 + +#### 原生 Pay-to-Witness-Public-Key-Hash (P2WPKH) + +* 原生 P2WPKH 是 22 位元組的 scriptPubKey。它以 OP_0 開頭，後接 keyhash 的標準推送（即 0x0014{20-byte keyhash}）。 +* 與 P2SH-P2WPKH 相同，keyhash 是壓縮公鑰的 RIPEMD160(SHA256)。 +* 花費原生 P2WPKH 時，scriptSig 必須為空，見證堆疊格式和簽名產生規則與 P2SH-P2WPKH 相同（包括使用壓縮公鑰的要求）。 +* [範例](https://blockchainprogramming.azurewebsites.net/checktx?txid=d869f854e1f8788bcff294cc83b280942a8c728de71eb709a2c29d10bfe21b7c) + +#### 原生 Pay-to-Witness-Script-Hash (P2WSH) + +* 原生 P2WSH 是 34 位元組的 scriptPubKey。它以 OP_0 開頭，後接 scripthash 的標準推送（即 0x0020{32-byte scripthash}）。 +* 與 P2SH-P2WSH 相同，scripthash 是 witnessScript 的 SHA256。 +* 花費原生 P2WSH 時，scriptSig 必須為空，見證堆疊格式和簽名產生規則與 P2SH-P2WSH 相同（包括使用壓縮公鑰的要求）。 +* [範例](https://blockchainprogramming.azurewebsites.net/checktx?txid=78457666f82c28aa37b74b506745a7c7684dc7842a52a457b09f09446721e11c) + +#### 為什麼以及如何使用原生（Bech32）P2WPKH 和 P2WSH？ + +* [BIP173][] 為原生 P2WPKH 和 P2WSH 位址提出了一個帶校驗和的 base32 格式（Bech32）。 +* Bitcoin Core v0.16.0 中包含了對 Bech32 位址的支援。 +* 與 P2SH 版本相比，原生版本的交易 vsize 在大多數情況下較小，因此可能需要較少的手續費。 +* 原生 P2WPKH 和 P2WSH 可與原始 scriptPubKey 協議一起使用，例如支付協議（BIP70）。但是，這可能影響付款人和收款人的隱私（見下文）。 +* 原生 P2WPKH 和 P2WSH 可用作預設找零位址，但這可能讓其他人輕易識別找零（見下文）。 +* 在原生 P2WPKH 和 P2WSH 廣泛使用之前，這些位址類型可能在使用者中引起隱私問題。 + +### 腳本和交易範例 + +* [不同見證交易類型的範例和交易有效性檢查工具](https://blockchainprogramming.azurewebsites.net/checktx) +* [BIP141][] +* [BIP143][] +* [BIP173][] +* [腳本測試](https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json) +* [有效交易測試](https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_valid.json) +* [無效交易測試](https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_invalid.json) diff --git a/_posts/zh_TW/pages/2016-03-12-contact.md b/_posts/zh_TW/pages/2016-03-12-contact.md new file mode 100644 index 000000000..46567fcda --- /dev/null +++ b/_posts/zh_TW/pages/2016-03-12-contact.md @@ -0,0 +1,35 @@ +--- +title: 聯繫我們 +name: contact +id: zh_tw-contact +permalink: /zh_TW/contact/ +type: pages +layout: page +lang: zh_TW +version: 2 +--- + +
+
+Bitcoin Core 不提供技術支援。 + +
社群支援可於 bitcoin.stackexchange.com 找到 +
+
+ +X: @bitcoincoreorg + +您可以使用 [問題追蹤器][issues]回報我們軟體中的錯誤。 + +您可以在 [IRC][#bitcoin-core-dev] 上找到 Bitcoin Core 開發者。 + +## GPG 金鑰 + +以下金鑰可用於向開發者傳達敏感資訊： +{% include dev-keys.md %} +若要回報本網站的問題，請使用[網站][website-issues]問題追蹤器。 +
負責任的披露 +
+若要回報安全問題： security@bitcoincore.org（非技術支援）。 +
+{% include references.md %} diff --git a/_posts/zh_TW/pages/2016-03-21-rss.md b/_posts/zh_TW/pages/2016-03-21-rss.md index c0624c071..c5ee8cbfa 100755 --- a/_posts/zh_TW/pages/2016-03-21-rss.md +++ b/_posts/zh_TW/pages/2016-03-21-rss.md @@ -1,5 +1,5 @@ --- -title: RSS Feeds +title: RSS 訂閱 name: rss permalink: /zh_TW/rss/ type: pages diff --git a/_posts/zh_TW/pages/2016-10-26-segwit-upgrade-guide.md b/_posts/zh_TW/pages/2016-10-26-segwit-upgrade-guide.md new file mode 100644 index 000000000..869a9f79e --- /dev/null +++ b/_posts/zh_TW/pages/2016-10-26-segwit-upgrade-guide.md @@ -0,0 +1,214 @@ +--- +title: 隔離見證升級指南 +name: segwit-upgrade-guide +id: zh_tw-segwit-upgrade-guide +type: posts +layout: post +lang: zh_TW +permalink: /zh_TW/2016/10/27/segwit-upgrade-guide/ +version: 1 +excerpt: 在 Bitcoin Core 0.13.1 中發布的 segwit 版本經歷了近兩年的迭代設計、開發和測試，過去一年的大部分精力都集中在讓現有的 Bitcoin 使用者、企業、開發者和礦工盡可能輕鬆地升級到 segwit。 +--- +{% include toc.html %} +{% include references.md %} + +在 Bitcoin Core 0.13.1 中發布的 segwit 版本經歷了近兩年的迭代設計、開發和測試，過去一年的大部分精力都集中在讓現有的 Bitcoin 使用者、企業、開發者和礦工盡可能輕鬆地升級到 segwit。 + +初始 segwit 採用需要兩個群體的參與： + +- **[礦工][miners guide]**代表 95% 或更多的 Bitcoin 網路總算力必須發出支援 segwit 的信號，以便鎖定 segwit 的啟動。 + +- **[全節點][node guide]**由合理數量的使用者和企業執行以驗證其接收的支付，需要升級到 Bitcoin Core 0.13.1 或更高版本，或另一個 segwit 相容實作，以便在 segwit 啟動後激勵礦工遵循 segwit 的規則。（這是 Bitcoin 的正常激勵機制，礦工只有在遵循所有共識規則時才能獲得區塊收入，一旦 segwit 啟動，這將包括新的 segwit 共識規則。） + +segwit 軟分叉的設計允許這兩個群體的個人自願決定是否要採用 segwit，下面為想要採用 segwit 和不想採用的人提供了指南。 + +如果足夠多的礦工確實決定採用 segwit，它最終將啟動，錢包使用者將能夠開始建立帶有隔離見證的交易。segwit 軟分叉也被設計為與所有常用錢包向後和向前相容，因此錢包開發者和使用者也可以獨立決定是否要採用 segwit 或繼續進行不帶隔離見證的交易。下面為採用和不採用的[開發者][dev guide]和[使用者][user guide]提供了指南。 + +除了說明之外，以下每個指南章節的末尾還提供了一個簡短的推薦列表，列出了您可能遇到的任何 segwit 相關問題的詢問地點。 + +## 礦工 {#miners} + +*本節是為獨立礦工和礦池營運商撰寫的。礦池礦工應聯繫其礦池營運商，以了解他們需要做什麼（如果有的話）才能升級或不升級到 segwit。* + +BIP9 軟分叉部署機制被用於 segwit——與 2016 年 7 月 4 日啟動的 BIP 68/112/113 軟分叉相同的機制。無論您是否希望升級，您都應該了解升級過程的重要階段： + +- **已開始：** Segwit 將在 2016 年 11 月 15 日或之後的第一個重定目標期開始時處於*已開始*階段，直到它啟動或被認為失敗（根據 BIP9 的政策），在一年內未達到鎖定後。在此期間，願意並能夠強制執行 segwit 新共識規則的礦工將透過在區塊標頭 versionbits 欄位中放置位元 1 來發出他們這樣做的意圖信號。 + +- **已鎖定：** 如果在 2,016 個區塊的重定目標期間，95% 的區塊發出支援 segwit 的信號，segwit 軟分叉將被*鎖定*，並計劃在 2,016 個區塊後（約兩週）*啟動*。 + +- **已啟動：** 在*已鎖定*期間結束後，發出準備強制執行 segwit 信號的礦工將開始產生包含帶有隔離見證的交易的 segwit 樣式區塊。 + +### 升級 + +segwit 軟分叉的 BIP9 參數允許礦工在 2016 年 11 月 15 日或之後的第一個重定目標期開始時開始發出支援信號。要發出支援信號，您需要執行以下操作： + +- 將您用於交易選擇和區塊建構的全節點升級到 Bitcoin Core 0.13.1+ 或另一個 segwit 相容的全節點。 + +- 將您的挖礦軟體、礦池軟體或兩者都升級到 segwit 相容版本。 + +- 開始產生包含 segwit 的 BIP9 versionbit（即位元 1）的區塊。 + +當 segwit 啟動時，您將希望能夠挖掘和中繼 segwit 樣式區塊。以下挖礦軟體已升級以支援 segwit。 + +- 全節點： + - [Bitcoin Core](https://bitcoin.org/en/download) 0.13.1 或更高版本 + - [Bitcoin Knots](http://bitcoinknots.org/) 0.13.1 或更高版本 + - [Btcd](https://github.com/btcsuite/btcd/pull/656)\* + +- 挖礦軟體： + - [BFGMiner](https://github.com/luke-jr/bfgminer)\* + - [CGMiner](https://github.com/ckolivas/cgminer) + - [libblkmaker](https://github.com/bitcoin/libblkmaker/pull/6)\* + +- 礦池軟體： + - [ckpool](https://bitbucket.org/ckolivas/ckpool) + - [Eloipool](https://github.com/luke-jr/eloipool) + - [Stratum-Mining](https://github.com/slush0/stratum-mining/pull/16)\* + +- 中繼軟體： + - [Bitcoin FIBRE](http://bitcoinfibre.org/) + +請注意，支援 GetBlockTemplate (GBT) RPC 的軟體必須升級以支援對 GBT 的 BIP9 和 BIP145 變更。上面連結的所有支援 GBT 的程式都已升級。 + +Segwit 已經在測試網上啟動並強制執行，因此您可能會發現在測試網上使用少量算力進行挖礦來測試您的基礎設施升級很有用。或者，Bitcoin Core 0.13.1 的回歸測試模式（regtest）預設也支援 segwit。 + +**有疑問？** 歡迎獨立礦工和礦池營運商在 irc.freenode.net 的 #bitcoin-mining 中尋求幫助。礦池礦工應聯繫其礦池營運商以了解有關礦池關於 segwit 的政策的任何問題。 + +### 不升級 + +本節描述了如果您不想強制執行 segwit，作為礦工可以做什麼。 + +在*已開始*階段，如果您不想採用 segwit，您可以簡單地拒絕升級到 segwit 相容的全節點（例如 Bitcoin Core 0.13.1 或更高版本），以及避免使用任何假設您想要設定 segwit 的 versionbit 位元 1 的挖礦軟體。 + +如果 segwit 達到*已鎖定*，您仍然不需要升級，但強烈建議升級。segwit 軟分叉不要求您產生 segwit 樣式區塊，因此您可以無限期地繼續產生非 segwit 區塊。但是，一旦 segwit 啟動，其他礦工可能會產生您認為有效但每個強制執行 segwit 的節點都拒絕的區塊；如果您在這些無效區塊上建立任何區塊，您的區塊也將被視為無效。 + +因此，在 segwit 達到*已鎖定*後，建議您升級您的全節點到 Bitcoin Core 0.13.1 或更高版本（或相容的全節點），或者您遵循下面全節點章節中的「不升級」說明，使用 Bitcoin Core 0.13.1 或更高版本作為您 pre-segwit 軟體的過濾器。 + +## 全節點使用者 {#full-node-users} + +*本節是為任何操作全節點的人撰寫的，包括企業和個人。* + +全節點防止其使用者接受違反任何 Bitcoin 共識規則的任何區塊。在像 segwit 這樣的軟分叉升級中，會新增新規則，任何不升級的節點都不會知道這些新規則。這不是問題：segwit 軟分叉的設計允許未升級的使用者像軟分叉之前一樣繼續使用 Bitcoin。 + +但是，任何想要使用 segwit 軟分叉啟用的功能的人都會希望知道，足夠數量的全節點使用者已經升級了他們的節點以拒絕違反 segwit 規則的區塊和交易，從而為礦工遵循 segwit 的更新共識規則提供強烈的激勵。 + +這個系統在過去運作良好，在之前幾個軟分叉啟動之前，至少有 25% 的可達節點（通常為 50% 或更多）已升級（不計算 BIP50 緊急和臨時軟分叉）。沒有理由期望 segwit 軟分叉會有任何不同，升級是支援 segwit 的人幫助鼓勵其採用的簡單方法。當然，對 segwit 不感興趣的人可以簡單地不升級。以下描述了兩種情況的詳細資訊。 + +### 升級 + +要升級到 segwit 相容版本，請下載您的全節點軟體的 segwit 相容版本（例如 [Bitcoin Core 0.13.1 版本](https://bitcoin.org/en/download)），確保您下載的檔案是合法的（使用 PGP 或其他方法），停止舊版本的節點軟體，然後啟動新版本的軟體。請注意，如果您在 segwit 啟動後升級，您的節點將需要從啟動點向前下載和重新同步區塊，因為舊版本沒有完全下載它們。 + +您可以使用 Bitcoin Core RPC `getblockchaininfo` 來追蹤 segwit 軟分叉的狀態（在 BIP9 樣式軟分叉清單中標記為 `segwit`）。此資訊包括有多少近期區塊是由發出打算強制執行 segwit 新共識規則的礦工產生的。`getblockchaininfo` RPC 的結果還將讓您確定 segwit 的軟分叉何時被鎖定（意味著它將在接下來的 2,016 個區塊內啟動）和啟動（意味著它現在由礦工強制執行）。 + +Bitcoin Core 0.13.1 提供的錢包預設將繼續僅產生非 segwit P2PKH 位址以接收支付。預計後續版本將允許使用者選擇接收支付到 segwit 位址。 + +如果您是想要產生位址進行測試的開發者或專家使用者，請參閱 [segwit dev guide][]。 + +**有疑問？** 如果您使用 Bitcoin Core 作為您的全節點，請參閱 Bitcoin.org 上的 [取得幫助](https://bitcoin.org/en/bitcoin-core/help) 頁面以獲取各種支援選項。如果您使用另一個全節點，最好的詢問地點是您的全節點軟體使用者尋求支援的地方。您的軟體維護者至少會熟悉 segwit 背後的想法，他們將能夠告訴您何時會實作它以及它將如何影響您。 + +### 不升級 + +如果您不想升級到 segwit 並且您不是礦工，您可以簡單地繼續使用您當前的全節點軟體。Segwit 實作為軟分叉，因此您不需要升級。您也不需要升級連接到您全節點的任何錢包；它們將像以前一樣繼續工作（有關詳細資訊，請參閱下面的[錢包章節][user guide]）。 + +但是，如果您接受確認區塊較少的交易（例如一個或兩個區塊），請注意，在軟分叉啟動後，未升級的全節點暫時接受無效區塊的風險會略微增加。隨著升級的礦工繼續強制執行新的 segwit 共識規則，情況將在幾個區塊內自行解決，但不能保證在無效區塊中顯示為已確認的交易將繼續在有效區塊中得到確認。 + +防止此問題的最簡單方法是升級到 Bitcoin Core 0.13.1 或更高版本，或另一個與 segwit 軟分叉相容的全節點版本。如果您仍然不想升級，可以使用較新的 Bitcoin Core 版本作為較舊 Bitcoin Core 版本的過濾器。 + +![Filtering by an upgraded node](/assets/images/filtering-by-upgraded-node.svg) + +在此配置中，您將當前的 Bitcoin Core 節點（我們稱之為「較舊節點」）設定為僅連接到執行 Bitcoin Core 0.13.1 或更高版本的節點（我們稱之為「較新節點」）。較新節點像往常一樣連接到 Bitcoin P2P 網路。因為較新節點知道 segwit 對共識規則的變更，它不會將無效區塊或交易中繼到較舊節點——但它會中繼其他所有內容。 + +使用此配置時，請注意，如果較舊節點使用 Bitcoin Core 預設值，它將不會看到使用 segwit 功能的交易，直到這些交易被包含在區塊中。 + +配置： + +對於較新節點，正常啟動它並讓它同步區塊鏈。目前，您不能將修剪節點用於此目的，因為修剪節點不會作為中繼節點。您可以選擇使用以下一個或兩個命令列參數啟動較新節點，以便它將較舊節點視為特殊（這些選項也可以放在 Bitcoin Core 的配置檔案中）： + +~~~ + -whitebind= + 綁定到給定位址並將連接到它的對等點列入白名單。使用 + [host]:port 表示法表示 IPv6 + + -whitelist= + 將從給定網路遮罩或 IP 位址連接的對等點列入白名單。可以 + 多次指定。列入白名單的對等點不能被 DoS 封禁 + 並且它們的交易總是被中繼，即使它們已經 + 在記憶池中，例如對閘道很有用 +~~~ + +對於較舊節點，首先等待較新節點完成同步區塊鏈，然後使用以下命令列參數重新啟動較舊節點（這也可以放在 Bitcoin Core 配置檔案中）： + + -connect=<較新節點的 IP 位址或 DNS 名稱> + +例如， + + -connect=192.168.8.8 + +這將導致較舊節點僅連接到較新節點，以便所有區塊和交易都由較新節點過濾。 + +## 錢包使用者 {#wallet-users} + +*本節是為使用輕量級錢包、網頁錢包、連接到個人全節點的錢包或任何其他錢包的任何人撰寫的。* + +### 升級 + +如果您確實想升級到 segwit，您首先需要等待礦工啟動 segwit，然後您需要一個支援接收和花費 segwit 樣式支付的錢包。這適用於 Bitcoin Core 的錢包、輕量級錢包，以及第三方代表您發送和接收比特幣的錢包（有時稱為網頁錢包）。Bitcoin Core 或其他全節點的使用者也應該閱讀上面有關全節點的章節。 + +在您的錢包升級以支援 segwit 後，它將產生以「3」開頭的接收位址（P2SH 位址）。有些錢包多年來一直在產生 P2SH 位址，因此這對您來說可能不是變化。 + +所有常用錢包都能夠支付 P2SH 位址，因此您將能夠從任何常見錢包接收支付，無論它們是否已升級到 segwit。升級到 segwit 後花費您的比特幣時，您仍然能夠支付以「1」開頭的原始類型 Bitcoin 位址（P2PKH 位址），以及能夠支付其他 P2SH 位址的使用者。 + +使用 segwit 錢包花費您的比特幣時，您會注意到以下情況： + +- 當僅花費您在升級前收到的比特幣時，您應該注意到與升級前建立的交易沒有差異。 + +- 當將升級到 segwit 後收到的比特幣花費給尚未升級到 segwit 的人時，他們可能要等到交易被包含在區塊中後才能看到您的交易。這是一個安全功能，可避免向他們顯示他們的錢包不完全理解的交易，直到這些交易得到確認。交易確認後，他們將能夠像正常一樣看到和花費您發送給他們的比特幣。 + +- 當花費您升級後收到的新 P2SH 位址的比特幣時，您可能會注意到您支付的交易手續費略低於花費您之前收到的非 segwit 支付時。這是因為包含您簽名的交易部分（「見證」）不需要被 Bitcoin 全節點快速存取，所以 segwit 允許礦工在區塊中儲存最多 4 倍的見證位元組，而不是非見證位元組。這更好地將建立區塊的成本（因此其交易手續費）與操作全節點的實際成本相一致。 + +**有疑問？** 如果您有任何問題，最好的詢問地點是您的錢包使用者尋求支援的地方。您的錢包維護者將熟悉 segwit 背後的想法，他們將能夠告訴您是否會為您的錢包實作 segwit、何時可能發生以及它將如何影響您對錢包的使用。 + +### 不升級 + +如果您不想升級到 segwit，您可以簡單地繼續使用任何尚未新增 segwit 支援的錢包。即使您沒有升級，您也將能夠與已升級到 segwit 的使用者以及像您一樣尚未升級到 segwit 的使用者進行交易。 + +如果您不升級，您可能會遇到一個差異：如果已升級到 segwit 的人向您付款，您的錢包可能要等到支付被包含在區塊中後才會向您顯示。這是一個安全功能，可防止您的錢包看到它不完全理解的交易，直到它們被礦工確認。 + +## Bitcoin 軟體開發者 {#bitcoin-software-developers} + +*本節是為處理交易或區塊的任何 Bitcoin 軟體開發者撰寫的。* + +所有 Bitcoin 軟體（包括挖礦軟體，前提是它僅選擇遵循預設中繼政策的交易）都應該像以前一樣繼續工作，並且只有在您想要利用 segwit 的新功能時才需要升級您的軟體。 + +Segwit 在以下文件中為開發者進行了描述： + +- **[Segwit 錢包開發者指南][segwit dev guide]：** 您需要了解的所有內容的摘要描述，以升級您的錢包以支援 segwit。 + +- **[BIP141][] 隔離見證（共識層）：** 尋求實作 segwit 任何方面的開發者應閱讀本文件的規範章節。挖礦和全節點軟體的開發者將在部署章節中找到 segwit 的 BIP9 參數。 + +- **[BIP143][] 版本 0 見證程式的交易簽名驗證：** 希望建立或驗證 segwit 簽名的任何軟體開發者應閱讀本文件的規範章節，並建議使用範例章節進行測試。 + +- **[BIP144][] 隔離見證（對等服務）：** 尋求透過 Bitcoin P2P 網路發送或接收隔離見證的開發者應閱讀本文件的規範章節。 + +- **[BIP145][] 隔離見證的 getblocktemplate 更新：** 挖礦和其他產生或使用 GetBlockTemplate RPC 的軟體開發者應閱讀 BIP145 和 [BIP9][] 中的相關 GBT 變更。 + +- **[BIP147][] 處理虛擬堆疊元素可塑性：** 錢包開發者，尤其是新交易腳本開發者，應該了解這個新的共識規則，它反映了一個長期存在的預設網路中繼政策，禁止將除 `OP_0`「null」操作碼以外的任何內容作為「虛擬」參數傳遞給 checkmultisig 樣式操作碼。在 segwit 啟動後，這個新的共識規則將適用於使用 segwit 和不使用 segwit 的交易。 + +- **[VersionBits FAQ][]：** 礦工和挖礦軟體開發者應閱讀此常見問題以獲取有關設定其 versionbits 以發出支援軟分叉的信號的資訊。Segwit 使用位元 1 作為 versionbits。 + +請注意，[BIP142][]（隔離見證的位址格式）處於*延期*狀態（如 BIP1 所定義），並未作為標準提出。相反，邀請錢包開發者在 [bitcoin-dev 郵件列表][bitcoin-dev]上討論建立一個新的 Bitcoin 位址格式，該格式將比當前的 base58check 編碼位址更易於使用。 + +BIP 141、143、144 和 145 的大多數實作詳細資訊可在 [Bitcoin Core PR#8149](https://github.com/bitcoin/bitcoin/pull/8149) 中找到。BIP147 的實作可在 [Bitcoin Core PR#8636](https://github.com/bitcoin/bitcoin/pull/8636) 中找到。 + +為了在啟用 segwit 的網路上測試變更，測試網（testnet3）已經支援 segwit 數月，並包括大量 segwit 區塊，包括幾乎達到 segwit 允許的最大區塊大小的區塊。Bitcoin Core 的回歸測試（regtest）模式在 Bitcoin Core 0.13.0 和 0.13.1 中預設也支援 segwit。 + +除了 Bitcoin Core 之外，許多自由和開源軟體 Bitcoin 錢包和套件也已經新增了 segwit 相容性或準備好部署 segwit 相容程式碼，因此，如果它們的著作權授權與您的程式碼相容，您可以使用它們的程式碼變更作為更新您軟體的範例。 + +**有疑問？** Bitcoin 開發問題可以在 irc.freenode.net 的 #bitcoin-dev IRC 聊天室中詢問。問題也可以在 Bitcoin.StackExchange.com 和 BitcoinTalk.org [技術討論板](https://bitcointalk.org/index.php?board=6.0)上詢問。 + +[miners guide]: #miners +[node guide]: #full-node-users +[dev guide]: #bitcoin-software-developers +[user guide]: #wallet-users +[segwit dev guide]: /zh_TW/segwit_wallet_dev/ +[versionbits faq]: /en/2016/06/08/version-bits-miners-faq/ diff --git a/_posts/zh_TW/pages/2017-01-01-download.md b/_posts/zh_TW/pages/2017-01-01-download.md new file mode 100644 index 000000000..6150d5290 --- /dev/null +++ b/_posts/zh_TW/pages/2017-01-01-download.md @@ -0,0 +1,162 @@ +--- +name: download +id: zh_tw-download +permalink: /zh_TW/download/ +type: pages +layout: page +lang: zh_TW +version: 6 + +## These strings need to be localized. In the listing below, the +## comment above each entry contains the English text. The key before the +## colon must not be changed; the value after the colon should be the +## translation. For example (Spanish): +## +## ## title: Download - Bitcoin +## title: Descargar - Bitcoin +# title: Download - Bitcoin +title: 下載 - Bitcoin +# latestversion: "Latest version:" +latestversion: "最新版本：" +# download: "Download Bitcoin Core" +download: "下載 Bitcoin Core" +# downloados: "Or choose your operating system" +downloados: "或選擇您的作業系統" +# download_sha: "SHA256 binary hashes" +download_sha: "SHA256 二進位雜湊值" +# download_sig: "SHA256 hash signatures" +download_sig: "SHA256 雜湊簽名" +# downloadtorrent: "Download torrent" +downloadtorrent: "下載種子檔案" +# source: "Source code" +source: "原始碼" +# versionhistory: "Show version history" +versionhistory: "顯示版本歷史" +# notelicense: "Bitcoin Core is a community-driven free software project, released under the open source MIT license." +notelicense: "Bitcoin Core 是一個由社群驅動的自由軟體專案，以開源 MIT 授權發布。" +# notesync: > +# Bitcoin Core requires a one-time download of about $(DATADIR_SIZE)GB +# of data plus a further $(MONTHLY_RANGE_GB)GB per month. By default, +# you will need to store all of that data, but if you enable +# pruning, you can store as little as $(PRUNED_SIZE)GB total without +# sacrificing any security. +notesync: > + Bitcoin Core 需要一次性下載約 $(DATADIR_SIZE)GB 的資料， + 之後每月額外增加約 $(MONTHLY_RANGE_GB)GB。預設情況下， + 您需要儲存所有這些資料，但如果您啟用修剪功能， + 在不犧牲任何安全性的情況下，總共只需儲存少至 $(PRUNED_SIZE)GB。 + +# full_node_guide: "For more information about setting up Bitcoin Core, please read the full node guide." +full_node_guide: "關於設定 Bitcoin Core 的更多資訊，請閱讀全節點指南。" +# patient: "Check your bandwidth and space" +patient: "檢查您的頻寬和儲存空間" + +pgp_key_fingerprint: "PGP 金鑰指紋" +verify_download: "驗證您的下載" + +verification_recommended: > +

下載驗證是可選的，但強烈建議執行。執行此處的驗證步驟可確保您下載的不是 + 意外或被竄改的 Bitcoin 版本，這可能導致資金損失。

+ +

點擊下方其中一行以查看該平台的驗證說明。

+ +windows_instructions: "Windows 驗證說明" +macos_instructions: "MacOS 驗證說明" +linux_instructions: "Linux 驗證說明" +snap_instructions: "Snap 套件驗證說明" +download_release: "點擊上方清單中的連結以下載適用於您平台的版本，並等待檔案下載完成。" +download_checksums: "下載加密雜湊值清單：" +download_checksums_sigs: "下載證明雜湊值有效性的簽名：" +cd_to_downloads: "開啟終端機（命令列提示字元）並切換目錄（cd）到您用於下載的資料夾。例如：" +cd_example_linux: "cd Downloads/" +cd_example_windows: > + cd %UserProfile%\Downloads + +verify_download_checksum: "使用以下命令驗證版本檔案的雜湊值是否列在雜湊值檔案中：" +checksum_warning_and_ok: '在上述命令產生的輸出中，確保輸出在您下載的版本檔案名稱後列出「$(SHASUMS_OK)」。例如：' + +example_builders_line: "E777299FC265DD04793070EB944D35F9AC3DB76A Michael Ford (fanquake)" +builder_keys_url: "https://github.com/bitcoin-core/guix.sigs/tree/main/builder-keys" +example_builder_key_file: "fanquake.gpg" + +obtain_release_key: > +

Bitcoin 版本由多位人員簽名，每位都有獨特的公鑰。為了識別簽名的有效性， + 您必須使用 GPG 在本地載入這些公鑰。您可以在 bitcoin-core/guix.sigs 儲存庫中找到許多開發者的金鑰， + 然後可以將它們載入到您的 GPG 金鑰資料庫中。

+ +

例如，您可以下載 + builder-keys/$(EXAMPLE_BUILDER_KEY_FILE) 檔案並使用此命令載入金鑰：

+ +choosing_builders: > + 建議您從此清單中選擇幾位您認為值得信任的人並如上所述匯入他們的金鑰。 + 稍後您將使用他們的金鑰來檢查證明雜湊值有效性的簽名，而這些雜湊值用於檢查二進位檔案。 + 您可以透過複製儲存庫並匯入目錄來一次匯入所有金鑰： + +release_key_obtained: "上述命令的輸出應顯示已匯入、更新、具有新簽名或保持不變的一個金鑰。" + +verify_checksums_file: "驗證雜湊值檔案已由足夠數量您信任且已匯入到您金鑰鏈中的金鑰進行 PGP 簽名：" + +check_gpg_output: > + 上述命令將為每個簽署雜湊值的公鑰輸出一系列簽名檢查。每個有效的簽名將顯示以下文字： + +line_starts_with: "開頭為：" +complete_line_saying: "完整行顯示：" + +gpg_trust_warning: > + 驗證命令的輸出可能包含公鑰不可用的警告。只要您擁有所有您信任的簽署者的公鑰， + 此警告即可忽略。可能還會有額外的警告，指出「金鑰未經可信簽名認證」。 + 這意味著要完全驗證您的下載，您需要確認簽署金鑰的指紋（例如 + $(SHORT_BUILDER_KEY)）與您對簽署者公鑰的預期相符。 + +verify_keys: "有關金鑰管理的更多詳細資訊，請參閱 GNU 手冊的相關章節。" + +localized_checksum_ok: "OK" +localized_gpg_good_sig: "Good signature" +localized_gpg_primary_fingerprint: "Primary key fingerprint:" + +install_gpg: "如果您之前未在系統上安裝 GNU Privacy Guard (GPG)，" +gpg_download_page: "請立即安裝" +gpg_download_other: "或查看其他安裝" +gpg_download_options: "選項。" + +snap_warning: > + 雖然 Snap 套件使用確定性產生的可執行檔，但 Snap 工具本身並未提供 + 簡化的方式來顯示 Snap 套件的內容。因此，Bitcoin Core 專案沒有 + 必要的資訊來協助您驗證 Bitcoin Core Snap 套件。 + +ensure_checksum_matches: > + 確保上述命令產生的雜湊值與您先前下載的雜湊值檔案中列出的其中一個雜湊值相符。 + 我們建議您檢查兩個雜湊值的每個字元以確保它們相符。 + 您可以透過執行以下命令來查看您下載的雜湊值： + +generate_checksum: "執行以下命令以產生您下載的版本檔案的雜湊值。將 '$(FILE)' 替換為您實際下載的檔案名稱。" + +build_reproduction: "透過可重現建置進行額外驗證" +additional_steps: > + 不介意執行額外步驟的有經驗使用者可以利用 Bitcoin Core 的可重現建置 + 以及執行這些建置的貢獻者所產生的已簽名雜湊值。 + +reproducible_builds: "可重現建置" +build_identical_binaries: > + 允許任何擁有 Bitcoin Core MIT 授權原始碼副本的人建置與本網站 + 分發的二進位檔案相同的檔案（意味著二進位檔案將具有與本網站 + 提供的相同加密雜湊值）。 + +verified_reproduction: "已驗證的重現" +independently_reproducing: > + 是多位 Bitcoin Core 貢獻者各自獨立重現如上所述的相同二進位檔案的結果。 + 這些貢獻者以密碼學方式簽署並發布他們產生的二進位檔案的雜湊值。 +verifying_and_reproducing: > + 前述的驗證說明將驗證您信任的幾位貢獻者都簽署了版本雜湊值檔案中 + 分發的相同雜湊值。此外，自行重現二進位檔案將為您提供目前可用的 + 最高等級保證。有關更多資訊，請造訪專案的 +guix_repository: "可信建置流程簽名" +key_refresh: "使用以下命令更新過期的金鑰：" + +--- + +{% include templates/download.html %} diff --git a/_posts/zh_TW/pages/2017-01-01-twitter-impersonation.md b/_posts/zh_TW/pages/2017-01-01-twitter-impersonation.md new file mode 100644 index 000000000..8d7a8c19b --- /dev/null +++ b/_posts/zh_TW/pages/2017-01-01-twitter-impersonation.md @@ -0,0 +1,42 @@ +--- +title: X 詐騙警告 +name: twitter-impersonation +id: zh_tw-twitter-impersonation +permalink: /zh_TW/twitter-impersonation/ +type: pages +layout: page +lang: zh_TW +version: 1 +--- +我們注意到 X（前身為 Twitter）上有幾個帳號違反了 [X 的冒充政策][X's Impersonation Policy]， +假裝是 Bitcoin Core 專案或與 Bitcoin Core 相關的知名人士。這些帳號一直在傳播關於 + Bitcoin Core 及其貢獻者的虛假和誤導性資訊。 + +如果您看到這些帳號之一，可以[向 X 舉報][report it to X]。如果您要舉報有關 Bitcoin Core 專案的問題， +而 X 要求您輸入該專案的官方電子郵件地址，請使用： +contact@bitcoincore.org + +這在 X 上似乎是一個不幸但常見的問題，也影響了許多其他專案和個人，因此我們敦促您仔細評估 +您在 X 上看到的任何貼文——以及其他地方的貼文——以確定它們是否真的來自所標示的發送者。 + +特別重要的是要小心那些建議您採取可能危及您的比特幣或電腦的行動的貼文，例如建議您下載更新版本的 + Bitcoin 軟體。最新版本的 Bitcoin Core 始終可以從[下載頁面][download page]取得，為了更高的安全性， +建議您使用 PGP 驗證二進位完整性（請參閱[全節點指南][full node guide]以獲取說明）。 + +Bitcoin Core 專案絕不會聯繫您要求您披露來自您的 Bitcoin 錢包的資訊，包括您的餘額、位址、 +交易或私鑰。如果您收到安全公告但不確定它是否合法，您可以安全地關閉您的 Bitcoin Core 程式 +以消除任何立即的問題，並給自己時間進行調查。 + +雖然 Bitcoin Core 確實有一個官方 X 帳號 [@bitcoincoreorg][]，但任何關於該專案的重要公告 +也會發送到我們流量較低的[公告郵件列表][announcements mailing list]或發布在[本網站的首頁][front page of this website] +（該網站也有 [RSS 訂閱][RSS feed]）。如果您知道如何使用 PGP 安全軟體，特別建議訂閱郵件列表， +因為所有公告都將由開發者進行密碼學簽名。 + +[X's Impersonation Policy]: https://help.x.com/en/rules-and-policies/authenticity +[report it to X]: https://help.x.com/en/forms/authenticity/impersonation +[@bitcoincoreorg]: https://x.com/bitcoincoreorg +[announcements mailing list]: /zh_TW/list/announcements/join/ +[front page of this website]: / +[RSS feed]: /zh_TW/rss.xml +[download page]: /zh_TW/download +[full node guide]: https://bitcoin.org/en/full-node diff --git a/_posts/zh_TW/pages/2020-08-01-meeting-summaries.md b/_posts/zh_TW/pages/2020-08-01-meeting-summaries.md new file mode 100644 index 000000000..f882e5118 --- /dev/null +++ b/_posts/zh_TW/pages/2020-08-01-meeting-summaries.md @@ -0,0 +1,15 @@ +--- +type: pages +layout: page +lang: zh_TW +title: IRC 會議摘要 +name: meeting-summaries +id: zh_tw-meeting-summaries +permalink: /zh_TW/meeting-summaries/ +version: 1 +--- +從 2015 年到 2018 年，幾位志願者撰寫了 Bitcoin Core 開發會議的摘要。本頁面連結到這些摘要。有關近期會議的資訊，請參閱[會議頁面][meetings page]。 + +{% include meetings.html %} + +[meetings page]: /zh_TW/meetings/ diff --git a/_posts/zh_TW/pages/2024-06-26-security-advisories.md b/_posts/zh_TW/pages/2024-06-26-security-advisories.md new file mode 100644 index 000000000..7dc2ec38d --- /dev/null +++ b/_posts/zh_TW/pages/2024-06-26-security-advisories.md @@ -0,0 +1,111 @@ +--- +title: 安全公告 +name: Security Advisories +id: zh_tw-security-advisories +permalink: /zh_TW/security-advisories/ +layout: page +type: pages +lang: zh_TW +version: 1 +--- +{% include toc.html %} + +本頁面概述了與 Bitcoin Core 中漏洞披露相關的政策， +以及歷史安全公告的摘要。 + +## 政策 + +所有漏洞都應報告至 security@bitcoincore.org（詳情請參閱 +[SECURITY.md](https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md)）。 +報告後，漏洞將被分配一個嚴重性類別。 +我們區分 4 類漏洞： + +* **嚴重（Critical）**：威脅整個 Bitcoin 網路的基本安全性和完整性的錯誤。 + 這些錯誤允許在協議層面上竊取幣、在指定發行時程之外創造幣，或造成永久性、 + 全網路範圍的鏈分裂。 +
+ + + 範例 + + + * 允許在區塊內兩次花費同一交易輸出以增加貨幣供應的錯誤 + ([CVE-2018-17144](/en/2018/09/20/notice/))。 + * 一個共識失敗，其中執行較舊軟體的節點拒絕了較新軟體接受的區塊， + 原因是底層資料庫限制，導致全網路範圍的鏈分裂 + ([BIP 50](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki))。 + +
+ +* **高（High）**：對受影響節點或網路有重大影響的錯誤。這些錯誤通常可以在預設配置下 + 遠端利用，並可能造成廣泛的中斷。 +
+ + + 範例 + + + * 可遠端觸發的當機，可能使許多節點離線 + ([CVE-2024-35202](/en/2024/10/08/disclose-blocktxn-crash/))。 + * 阻斷服務攻擊，導致節點長時間停滯，無法處理新的交易和區塊 + ([CVE-2024-52914](/en/2024/07/03/disclose-orphan-dos/))。 + * 記憶體耗盡漏洞，可透過使節點儲存過量的區塊標頭來遠端觸發當機 + ([CVE-2019-25220](/en/2024/09/18/disclose-headers-oom/))。 + +
+ +* **中（Medium）**：可能明顯降低網路或節點性能或功能的錯誤，但其範圍或可利用性有限。 + 這些錯誤可能需要特殊條件才能觸發，例如非預設設定，或導致服務降級而非完全節點故障。 +
+ + + 範例 + + + * 本地網路上的潛在遠端程式碼執行（RCE）漏洞，僅在啟用 UPnP 等非預設功能時才能利用 + ([CVE-2015-20111](/en/2024/07/03/disclose_upnp_rce/))。 + * 對等節點可透過發送變異區塊來阻礙區塊傳播，延遲節點接收新區塊的時間 + ([CVE-2024-52921](/en/2024/10/08/disclose-mutated-blocks-hindering-propagation/))。 + * 攻擊者向節點宣告區塊，然後無法提供該區塊，導致受害節點在能夠從其他對等節點獲取之前等待最多 10 分鐘 + ([CVE-2024-52922](/en/2024/11/05/cb-stall-hindering-propagation/))。 + +
+ +* **低（Low）**：難以利用或對節點運作影響輕微的錯誤。這些錯誤可能僅在非預設配置下 + 或從本地網路才能觸發，且不會構成立即或廣泛的威脅。 +
+ + + 範例 + + + * 格式錯誤的 `getdata` 訊息可能導致對等連接進入無限迴圈，消耗 CPU + 但不影響節點處理區塊或處理其他對等連接的能力 + ([CVE-2024-52920](/en/2024/07/03/disclose-getdata-cpu/))。 + * 依賴套件中的錯誤可能導致節點當機，但僅在啟用 UPnP 等非預設功能時 + ([CVE-2024-52917](/en/2024/07/31/disclose-upnp-oom/))。 + * 可能導致節點當機的錯誤，但極難利用 + ([CVE-2024-52919](/en/2025/04/28/disclose-cve-2024-52919/))。 + +
+ +**低**嚴重性漏洞將在包含修復的主要版本發布後 2 週內披露。**中**和**高**嚴重性漏洞 +將在最後一個受影響版本[終止生命週期](/zh_TW/lifecycle/)（包含修復的主要版本首次發布後 +約一年）後 2 週內披露。 + +在發布漏洞詳情的兩週前將進行預告。此預告將與新主要版本的發布同時進行， +並包含已修復漏洞的數量及其嚴重性等級。 + +**嚴重**錯誤不在標準政策考慮範圍內，因為它們很可能需要臨時程序。 +此外，錯誤可能根本不被視為漏洞。任何報告的問題也可能被認為是嚴重的，但不需要禁運。 + +## 過往安全公告 + +{% assign advisories=site.posts | where:"lang", 'en' | where:"type", 'advisory' | sort: "date" | reverse %} +{% for advisory in advisories %} +{% assign post=advisory %} +
+

{{ post.title }}

+

{{ post.excerpt | markdownify | strip_html | truncate: 200 }}

+
+{% endfor %} diff --git a/_posts/zh_TW/pages/faq/2016-01-21-rbf-faq.md b/_posts/zh_TW/pages/faq/2016-01-21-rbf-faq.md new file mode 100644 index 000000000..a50159697 --- /dev/null +++ b/_posts/zh_TW/pages/faq/2016-01-21-rbf-faq.md @@ -0,0 +1,199 @@ +--- +### 原始來源自 https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ +title: 選擇性 RBF 常見問題 +name: optin-rbf-faq +type: pages +layout: page +lang: zh_TW +permalink: /zh_TW/faq/optin_rbf/ +version: 1 +--- +{% include toc.html %} + +## 什麼是選擇性 RBF? + +選擇性手續費替換 (RBF) 允許交易被標記為可替換,直到它們在區塊中被確認。 + +## 這是一個新功能嗎? + +交易替換是由 Satoshi 在 Bitcoin 軟體的第一個版本中引入的,但後來由於阻斷服務問題而被移除。選擇性 RBF 透過要求替換交易支付更高的手續費來解決這個問題。 + +## 它用於什麼? + +在交易等待確認的期間,一些錢包希望能夠更新這些交易,以增加其手續費(這可能有助於它們更快得到確認)、將多個交易壓縮為一個、創建背景 coinjoin(以提高隱私)或執行許多其他有用的操作。 + +## 它是如何運作的? + +選擇性 RBF 是對記憶體池和網路中繼程式碼的變更,允許這些錢包可選擇性地向其交易添加一個信號,告訴完整節點這些特定交易可能會被更新(替換),直到它們在新區塊中得到確認為止。 + +## 選擇性 RBF 實作是否改變了「非 RBF」交易被雙重支付的可能性? + +不會。交易必須被標記為可替換(序列號*低於* MAX*-1*)才能讓選擇性 RBF 實作將其視為可替換。 + +## 選擇性 RBF 是否使欺詐性支付顯著更成功? + +選擇性 RBF 對未使用它的交易沒有影響,也沒有人被強制使用它。一旦交易被確認,它就沒有效果。這意味著關心未確認交易的使用者可以繼續不使用 RBF。 + +## 選擇性交易本身是否是專門欺詐者更有用的工具,假設人們在沒有確認的情況下接受它們? + +我們目前沒有理由相信它們是,至少對於使用已知最有效工具和做法的欺詐者來說不是顯著的。但如果是(或在更清楚它們不是之前),接收者可以透過繼續將具有非最大序列號的交易視為不安全來保護自己,直到它們得到確認為止。 + +因為使用選擇性 RBF 的支付者有能力增加他們的手續費,並可能減少他們的確認時間,即使有許多交易等待確認,要求他們的交易在為他們提供服務之前得到確認並不是不體貼的。 + +## 為什麼未確認的交易不安全? + +Bitcoin 交易在異步分散式系統中中繼,在該系統中不存在全域一致的「第一」。Alice 首先看到的,Bob 可能第二個看到。Bitcoin 設計沒有提供機制讓 Alice 和 Bob 就這些交易中哪一個真正先到達成協議;他們所能做的就是等待看到這些交易中哪一個在最佳區塊鏈上的有效區塊中得到確認。 + +今天複雜的雙重支付攻擊者使用工具透過進行無害的衝突支付並查看哪些版本出現在哪些商家和哪些區塊中來映射網路連接性。這允許他們製作同一交易的兩個版本,一個發送給受害者,一個發送給礦工進行確認。 + +不可替換支付給商家的存在阻止了他的節點了解雙重支付,直到它出現在礦工開採的區塊中,而該礦工只是開採了他們首先看到的東西。這種簡單、常見的模式有時會被其他技術進一步放大,例如使用未確認的交易鏈、低手續費或非標準交易。 + +因此,未確認交易的絕大部分安全性不是來自 Bitcoin 系統內部,而是來自外部因素,例如永遠不會試圖欺騙其供應商的大量誠實 Bitcoin 使用者、供應商對少量欺詐的容忍度、供應商訴諸法律系統或其他類型追索權的能力(或威脅),以及與 Bitcoin 協定設計無關的其他因素。 + +所有這些對於選擇性 RBF 同樣適用(它們與美國的信用卡支付情況並不不同,這些支付在交換後數月內很容易被撤銷,但欺詐率足夠低,幾乎所有重要商家都接受它們)。此外,因為 RBF 有時可以消除長時間的確認延遲,一些以前被迫接受未確認交易以防止不幸延遲的商家將不再需要這樣做,這減少了他們面臨欺詐的風險。 + +然而,沒有使用選擇性 RBF 的人堅持您同意上述關於未確認交易安全性的觀點。選擇性 RBF 是*選擇性的*,如果它不符合您的需求,您不需要使用它。 + +## 誰發明了未確認交易替換?這是否違背了 Bitcoin 的「願景」? + +未確認交易的交易替換是 [Bitcoin 第一個版本中的一個功能](https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434)。交易可以透過設定非最大序列號將自己標記為可替換。後來這被停用,因為攻擊者可以以很小的成本耗盡完整節點之間的所有頻寬,從而造成阻斷服務漏洞。 + +此外,礦工沒有動機遵循慣例並接受替換,如果交易的早期版本支付了更高的手續費,甚至可能有動機違反慣例。 + +這兩個因素使替換在幾年內無法恢復,但在 2013 年 Peter Todd [提議](https://bitcointalk.org/index.php?topic=199947.0)要求替換支付嚴格更高的手續費率,並要求替換至少增加中繼新交易所需的最低手續費率。這消除了阻斷服務和激勵相容性問題。 + +Peter 的原始工作更進一步,將激勵相容性推向其邏輯結論,推論出對於匿名、短暫、自我選擇的礦工,您真正可以依賴的唯一行為是以更高手續費替換。更高的手續費偏好也可以使節點能夠根據手續費率在記憶體池中收斂到一組交易,而這對於只接受他們看到的第一個版本交易的節點來說是不可能的。 + +由於這些原因,以及因為系統以預期方式運作比系統以「不可預測但平均更好的方式」運作更安全和保護,他提議對所有交易進行替換。他還提議了一個以強烈激勵相容的方式消除雙重支付經濟收益的協定,稱為替換焦土,如果有人試圖對您進行雙重支付,您將所有資金用於手續費,這樣攻擊者就得不到它們。(但這是只有博弈論者才會真正喜歡的那種提議。) + +在 Peter 的提議之後,我們收到了來自 [Greenaddress](https://blog.greenaddress.it/2015/12/09/why-replace-by-fee-is-good-for-bitcoin/) 等錢包的請求,他們非常強烈地要求選擇性 RBF,因為他們真的需要一個合理的方式來處理手續費,並將選擇性 RBF 視為一個很好的方法,這就是為什麼提議被更改為符合 Satoshi 的原始選擇性行為。 + +## 選擇性 RBF 拉取請求有爭議嗎? + +一點也不。經過幾個月前的廣泛非正式討論,[PR][RBF PR] 於 10 月 22 日開放。隨後在至少四次 Bitcoin 開發每週會議中進行了討論([2015-11-05][]、[2015-11-12][]、[2015-11-19][] 和 [2015-11-26][])。 + +[RBF PR]: https://github.com/bitcoin/bitcoin/pull/6871 +[2015-11-05]: /zh_TW/meetings/2015/11/05/ +[2015-11-12]: /zh_TW/meetings/2015/11/12/ +[2015-11-19]: /zh_TW/meetings/2015/11/19/ +[2015-11-26]: /zh_TW/meetings/2015/11/26/ + +在 PR 討論中,19 人發表了評論(包括至少三個不同錢包品牌的工作人員),14 人明確 ACK 了這項變更,包括至少一位過去曾對完整 RBF 非常直言不諱反對的人。在 PR 開放期間,PR 中(或我們所知的其他地方)沒有提供明確的負面反饋。 + +## 這項變更何時以及如何啟動? + +選擇性 RBF 並沒有真正的「啟動」,因為它不是 Bitcoin 共識的一部分。這是一種本地政策行為,因此隨著人們採用行為不同的軟體,變更會一次一個節點地發生。網路上已經有一些節點以各種方式執行 RBF,而且已經有一段時間了,可能有數年之久。 + +Bitcoin Core 0.12 將於 2016 年 2 月左右發布,並將包含選擇性 RBF,之後可能還需要幾個月的時間,這種行為才會變得普遍。這可能會因開發使用它的有趣應用程式而加速。 + +## 選擇性 RBF 僅對調整手續費有用嗎? + +不,錢包可以使用選擇性 RBF 做的另一件有用的事情是,當第一筆付款尚未確認時,將兩筆或更多筆付款合併為一筆付款。即使替換必須支付比原始交易更高的手續費,這也可以節省大量位元組和交易手續費。 + +選擇性 RBF 還可以用於實作更高級的合作穩定性方案,例如 [交易切割](https://bitcointalk.org/index.php?topic=281848.0)。 + +各種[智慧合約](https://bitcointalk.org/index.php?topic=321228.0)案例也需要替換,但它們通常使用 locktime 來創建更強的排序並解決歷史上替換不可用的問題;這些可能是在其原始設計中支援替換的 Bitcoin 協定的動機。 + +雖然除了調整手續費之外還有更多有趣的原因,但調整手續費的能力不應被低估。這意味著初始手續費可以使用較低的「最可能」估計,而不必「以防萬一」而多付;這導致即使很少進行替換時手續費也更低。 + +## 錢包是否需要保持線上以發出更高手續費的替換? + +不需要。替換可以預先計算、時間鎖定,並提供給始終線上的遠端伺服器以供稍後廣播,而沒有伺服器可以竊取任何使用者資金的風險(最壞的情況是它未能廣播)。 + +例如。在區塊 100 時,錢包想要進行一筆設定為在 3 個區塊內確認的交易。錢包使用其對三區塊確認手續費的最佳估計,製作了一筆鎖定在 101 的交易,同時它還製作了鎖定在高度 104、105、106、107... 的替換交易,每筆支付(比如)上一筆手續費的 1.5 倍。這些可以交給接受高級 locktime 交易的節點。 + +即使礦工知道將來會支付更高的手續費,理性地他們仍然更喜歡現在可以包含的那個---因為如果他們等待,另一個礦工可能會拿走手續費。上述建議的乘法增加意味著,在最壞的情況下,交易會多付 50%,但仍然可以在少數交易中達到任意高的手續費。 + +## 選擇性 RBF 是否增加了「懶惰」交易處理器被詐騙的風險? + +似乎不是這樣,至少不是顯著的,而且這是設計使然。選擇性 RBF 使用 nSequence 欄位發出信號,該欄位專門用於涵蓋可替換性。許多一般信任未確認交易的程式和平台已經將低序列號的交易視為可疑,並忽略它們直到它們確認為止。 + +還有數十種其他方式可以改變交易的確認速度或可靠性,並增加成功進行欺詐性雙重支付的機率: + +- 支付低手續費 +- 使用非標準標誌或版本 +- 花費未確認的輸入 +- 表現得像任何數量的阻斷服務攻擊模式 +- 創建塵埃 txout +- 等等。 + +這些標準經常變化,並取決於使用者可配置的節點特定政策。試圖估計未確認付款風險的各方必須追蹤所有這些事情以及更多,並且他們必須主動回應變化。選擇性 RBF 是一個提前數月已知的高度溝通的添加,它覆蓋在已經檢測到的行為上。如果未確認交易警惕所需的努力有任何變化,它可能只是噪音。 + +除此之外,尚不清楚選擇性 RBF 交易實際上是否比非 RBF 交易對欺詐性雙重支付顯著更有用,至少對於使用複雜工具的攻擊者而言。 + +一些執行未確認置信度分析的各方已明確表示[他們已經準備好了][blockcypher ready],如果有人知道仍需要幫助適應的軟體,請告訴我們,我們很樂意提供幫助。 + +[blockcypher ready]: https://twitter.com/BlockCypher/status/670334879565922304 + +## 如果我認為 RBF 很糟糕怎麼辦? + +那就不要使用它:不要在您自己的交易上設定它,並將您收到的所有序列號小於 MAX_INT-1 的交易視為不存在(或已經被雙重支付),直到它們確認為止。選擇性 RBF 是選擇性的。 + +我們所知道的沒有常用軟體將其序列號設定為低於 MAX_INT-1,許多程式(包括「交易置信度」儀表)已經將低序列號視為可能被雙重支付。畢竟,交易已經被明確標記為可替換,即使沒有 RBF,nLocktime 也可能導致衝突首先得到確認。 + +如果有人向您發送可替換交易,而您不會零確認記入它,他們的替換可以使它以他們想要的速度得到確認。已經存在類似的情況,發送者使用非標準交易功能或花費未確認的輸出,這使得交易客觀上更容易被雙重支付---但在這些情況下,沒有修復方法可以快速完成交易。 + +RBF 是一個同意成年人的功能。如果您不想參與其中,您不需要。您對它的不喜歡不是阻止其他人在不涉及您的交易中使用它的理由。 + +## 為什麼實作「選擇性」而不是讓礦工替換任何交易? + +現在沒有什麼可以阻止礦工替換甚至非選擇性交易,一些礦工以前曾自己嘗試過 RBF。透過提供可以滿足使用者對此功能需求的標準實作,礦工開始用更高手續費率變體替換任何交易的動機可能會減少。 + +## 我聽說選擇性 RBF 的添加幾乎沒有討論 + +最近的 RBF 討論可以追溯到 2015 年 5 月。 + +Github: + +- 向記憶體池添加首次看到安全的手續費替換邏輯 [#6176](https://github.com/bitcoin/bitcoin/pull/6176) +- 預定的完整 RBF 部署 [#6352](https://github.com/bitcoin/bitcoin/pull/6352) +- 基於 nSequence 的完整 RBF 選擇性 [#6871](https://github.com/bitcoin/bitcoin/pull/6871) + +IRC 會議: + +- [2015-11-05][] +- [2015-11-12][] +- [2015-11-19][] +- [2015-11-26][] + +還有許多其他 [#bitcoin-dev](http://bitcoinstats.com/) 和 [#bitcoin-core-dev](https://botbot.me/freenode/bitcoin-core-dev/) 的日誌。 + +郵件列表討論,沒有特定順序: + +- [[bitcoin-dev] 選擇性完整手續費替換 (Full-RBF)](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011783.html) +- [[Bitcoin-development] 首次看到安全的手續費替換](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html) +- [[Bitcoin-development] 使用手續費替換節省成本,30-90%](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008232.html) +- [[bitcoin-dev] 雙重支付未確認交易造成的重大損失](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009420.html) +- [[bitcoin-dev] BIP: 完整手續費替換部署時間表](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009253.html) +- [[Bitcoin-development] 手續費替換 v0.10.0rc4](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007404.html) +- [[bitcoin-dev] 錢包如何處理真實的交易手續費](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011685.html) + +Satoshi 最初引入了[未確認交易替換](https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434),但由於 DOS 攻擊而被停用(Peter Todd 透過要求每次替換都有更高的手續費來修復)。 + +## 這可以用來對未準備好的(舊)錢包進行雙重支付嗎?所有錢包都必須更新嗎? + +未確認的交易始終可以被雙重支付,無論有沒有 RBF。欺詐目前很容易,RBF 不會改變這一點。 + +錢包只有在想要使用選擇性 RBF 時才需要更新。這為錢包提供了一個新的維度,讓他們可以創新並為使用者提供有益的功能。 + +## 為什麼不使用首次看到安全的手續費替換 (FSS-RBF) + +FSS-RBF 意味著只有在完全花費所有先前輸出時才能修改交易。這可以防止雙重支付,但在實際使用時有三個問題: + +1. 它會導致交易大小增加,因為您必須為每次替換添加新的輸入。 + +2. 許多錢包沒有備用輸入可以花費,因此他們根本無法使用 FSS-RBF。 + +2. 它會降低隱私,因為它幾乎總是增加找零輸出的價值,公開將該輸出標記為找零。 + +## 什麼是「子為父付」(CPFP)? + +子為父付是一種透過建立另一個依賴於第一個交易的交易來為交易添加手續費的方法。 + +## 為什麼不使用 CPFP 來實作 RBF? + +子為父付 (CPFP) 不能解決同樣的問題。RBF 允許*支付者*增加手續費; CPFP 很有用,因為它允許*接收者*增加手續費。 + +RBF 優於 CPFP 的優勢在於它不一定需要使用任何額外的區塊空間,因此效率提高了約 [30% 到 90%](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008232.html)。 + +計劃同時支援 CPFP 和選擇性 RBF。 diff --git a/_posts/zh_TW/pages/faq/2016-02-15-contributing-core-guidelines.md b/_posts/zh_TW/pages/faq/2016-02-15-contributing-core-guidelines.md new file mode 100644 index 000000000..14e49368d --- /dev/null +++ b/_posts/zh_TW/pages/faq/2016-02-15-contributing-core-guidelines.md @@ -0,0 +1,14 @@ +--- +title: 如何為 Bitcoin Core 貢獻程式碼 +name: contributing-guidelines +id: zh_TW-contributing-guidelines +permalink: /zh_TW/faq/contributing-code/ +layout: page +type: pages +lang: zh_TW +category: faqs +version: 3 +--- +Bitcoin Core 專案採用開放貢獻者模式，歡迎任何人以同儕審查、測試和修補程式的形式為開發做出貢獻。 + +請參閱 Git 儲存庫中的[貢獻指南](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md)以獲取更多詳細資訊。 diff --git a/_posts/zh_TW/pages/legal/2016-01-15-cookie-policy.md b/_posts/zh_TW/pages/legal/2016-01-15-cookie-policy.md new file mode 100644 index 000000000..866238fa8 --- /dev/null +++ b/_posts/zh_TW/pages/legal/2016-01-15-cookie-policy.md @@ -0,0 +1,24 @@ +--- +title: Cookie 政策 +name: legal-cookie +permalink: /zh_TW/legal/cookie/ +type: pages +layout: page +lang: zh_TW +version: 1 +--- +## 簡介 + +Cookie 是一個小型文字檔案,當您請求頁面時,網頁伺服器可以將其發送到您的網頁瀏覽器。此檔案儲存在您的電腦上,當您發出另一個頁面請求時,它會被發送回網站。只有發送網站才能存取其 cookie。 + +當您關閉瀏覽器視窗或分頁時,會話 cookie 會從您的瀏覽器中刪除。持久性 cookie 會在到期日期到達時由您的瀏覽器自動刪除。 + +第三方 cookie 是由本網站使用的第三方服務發送和檢索的 cookie。 + +## 同意 + +使用者可以配置其網頁瀏覽器接受或拒絕 cookie。透過使用本網站並將瀏覽器設定為接受 cookie,您同意在您的電腦上設定 cookie。如果您不同意,請不要使用本網站,或停用 cookie,這可能會降低或破壞您的網站體驗。 + +本網站使用 cookie 來提供基本功能。第三方 DDOS 保護服務也可能設定 cookie 以提供受保護的頁面。 + +最後更新於 2015-01-15。 diff --git a/_posts/zh_TW/pages/legal/2016-01-15-legal-home.md b/_posts/zh_TW/pages/legal/2016-01-15-legal-home.md new file mode 100644 index 000000000..222a91fc4 --- /dev/null +++ b/_posts/zh_TW/pages/legal/2016-01-15-legal-home.md @@ -0,0 +1,15 @@ +--- +title: 法律條款 +name: legal-home +permalink: /zh_TW/legal/ +type: pages +layout: page +lang: zh_TW +version: 1 +--- + + - [隱私權政策] + - [Cookie 政策] + +[隱私權政策]: /zh_TW/legal/privacy +[Cookie 政策]: /zh_TW/legal/cookie diff --git a/_posts/zh_TW/pages/legal/2016-01-15-privacy-policy.md b/_posts/zh_TW/pages/legal/2016-01-15-privacy-policy.md new file mode 100644 index 000000000..0894b497d --- /dev/null +++ b/_posts/zh_TW/pages/legal/2016-01-15-privacy-policy.md @@ -0,0 +1,45 @@ +--- +title: 隱私權政策 +name: legal-privacy +permalink: /zh_TW/legal/privacy/ +type: pages +layout: page +lang: zh_TW +version: 1 +--- +## 簡介 + +透過造訪本網站或以任何其他方式向我們提供您的個人資訊,您接受並同意本政策中描述的做法。除非另有說明,否則「訪客」一詞包括所有人,無論您是將資訊上傳到我們的網站、下載資訊,還是僅僅造訪。 + +本隱私權政策將管理我們對您資訊的使用,無論我們收集哪些資訊。 + +## 我們收集哪些資訊? + +我們以日誌的形式從所有訪客收集基本使用資訊。當您造訪我們的網站時,我們的伺服器會記錄您的 IP 位址、您造訪的時間和持續時間,以及您查看我們網站頁面的時間和持續時間。我們也可能捕獲有關您電腦系統的資訊,例如您的瀏覽器類型和作業系統。 + +我們可能會在網頁造訪期間在您的硬碟上放置一個 cookie。如果您不希望在您的電腦上放置 cookie,則可以在您的網頁瀏覽器中停用它們。但是,請注意,在您的瀏覽器中停用 cookie 可能會阻止本網站正常運作。我們可能會使用第三方 DDOS 保護服務,他們也可能使用 cookie 來提供其服務。 + +## 我們如何使用這些資訊? + +基本使用資訊。我們使用基本使用資訊來監控和改善本網站的可用性、效能和內容。 + +個人識別資訊。我們可能會使用我們收集的資訊來改善網站內容。我們可能會使用此資訊來防止或偵測欺詐或濫用我們的網站,並使第三方能夠代表我們執行技術、後勤或其他功能。 + +## 個人資訊揭露 + +除非符合以下情況,否則我們不會將我們收集的任何資訊揭露給任何第三方: + +- 得到您的特別授權;或 +- 執行您請求的功能所必需(且僅在執行功能絕對必要的範圍內);或 +- 檢查欺詐或其他資源濫用所必需;或 +- 法律要求。 + +特別是,當我們認為適當遵守法律、執行我們的法律權利、保護他人的權利和安全,或協助行業努力控制欺詐、垃圾郵件或其他不良行為時,我們可能會將我們收集的資訊發布給第三方。 + +如果我們與第三方簽約提供特定服務,我們可能會將我們收集的資訊發布給該第三方,前提是該第三方已同意使用至少與本隱私權政策中描述的相同級別的隱私保護,並且僅被允許使用該資訊為我們提供服務。 + +## 變更 + +我們的隱私權政策可能會不時變更,新政策將顯著發布在本網站上。未經您事先同意,我們絕不會實質性地改變我們的政策和做法,使其對過去收集的個人資訊的保護程度降低。 + +最後更新於 2015-01-15。 diff --git a/_posts/zh_TW/pages/list/2016-03-10-announcements-join.md b/_posts/zh_TW/pages/list/2016-03-10-announcements-join.md new file mode 100644 index 000000000..26915a398 --- /dev/null +++ b/_posts/zh_TW/pages/list/2016-03-10-announcements-join.md @@ -0,0 +1,18 @@ +--- +title: 訂閱 Bitcoin Core 公告 +name: announcements +permalink: /zh_TW/list/announcements/join/ +type: pages +layout: page +lang: zh_TW +version: 3 +--- +接收 Bitcoin Core 重要安全公告和發布版本的通知。 + +訂閱下方的 RSS feed 或查看 [bitcoin core blog][] 區塊。 + +公告列表目前無法使用。 + +{% include pages/list/announcement.html %} + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2015-09-01-open-letter.md b/_posts/zh_TW/posts/2015-09-01-open-letter.md new file mode 100644 index 000000000..c19c68d5d --- /dev/null +++ b/_posts/zh_TW/posts/2015-09-01-open-letter.md @@ -0,0 +1,112 @@ +--- +title: 給 Bitcoin 社群的公開信 +permalink: /zh_TW/2015/09/01/open-letter/ +lang: zh_TW +id: zh_TW-open-letter +name: open-letter +type: posts +layout: post +canonical: https://bitcoinmagazine.com/articles/open-letter-bitcoin-community-developers-1441146317 +version: 1 +--- +作為 Bitcoin 的積極貢獻者,我們分享這封信來傳達我們關於技術共識和 Bitcoin 可擴展性的行動計劃。 + +Bitcoin 對不同的人有不同的意義。然而,Bitcoin 的開發和維護是一項人類的努力。Satoshi 尋求審查和合作,而 Bitcoin 開發者隨後的工作使系統更加安全,速度提高了幾個數量級。Bitcoin 開發者社群致力於 Bitcoin 的未來,關注網路的健康,追求最高的效能標準,並代表每個人努力保持 Bitcoin 的安全。 + +我們致力於 Bitcoin,並回應社群的需求。在過去五年中,我們編寫了程式碼並管理了超過 [50 個 Bitcoin 版本][1],並審查了超過 [45 個正式提案][2] 以改善 Bitcoin 的效能、安全性和可擴展性。技術討論雖然有時激烈,但始終專注於改善 Bitcoin。 + +在這個領域已經完成了大量工作,從 CPU 瓶頸、記憶體使用、網路效率和初始區塊下載時間的實質性改進,到一般的演算法擴展。然而,仍然存在許多關鍵挑戰,每個挑戰都有許多重要的考慮因素和權衡需要評估。我們多年來一直致力於 Bitcoin 擴展,同時保護網路的去中心化、安全性和無需許可的創新等核心特性。我們致力於確保盡可能多的使用者從 Bitcoin 中受益,而不侵蝕這些基本價值。 + +不時會有爭議,但 Bitcoin 是一個安全關鍵系統,擁有數十億美元的使用者資產,一個錯誤可能會危及這些資產。為了減輕潛在的存在風險,我們所有人都應該花時間評估已經提出的提案,並透過共識建立過程就最佳解決方案達成一致。 + +在未來幾個月,兩個開放研討會將把社群聚集在一起探討這些問題。第一個 [Scaling Bitcoin 研討會][3] 將於 9 月 12-13 日在蒙特婁舉行。第二個研討會計劃於 12 月 6-7 日舉行,並將在香港舉辦,以更包容 Bitcoin 的全球使用者群體。 + +我們請求社群不要預先判斷,而是透過現有流程和支援研討會協作達成最佳結果。很高興看到對活動的廣泛興奮和參加的技術參與者的高度集中。 + +我們相信透過共同努力,我們可以就最佳行動方案達成一致。我們相信這是前進的方向,並加強了迄今為止很好地服務於 Bitcoin 開發社群(以及一般的 Bitcoin)的現有審查流程。 + +我們歡迎您的參與,因為我們繼續努力將 Bitcoin 帶入未來。 + +簽署: + +(支持這封信的技術貢獻者名單) + +Wladimir J. van der Laan + +Pieter Wuille + +Cory Fields + +Luke Dashjr + +Jonas Schnelli + +Jorge Timón + +Greg Maxwell + +Eric Voskuil + +Amir Taaki + +Dave Collins + +Michael Ford + +Peter Todd + +Phillip Mienk + +Suhas Daftuar + +R E Broadley + +Eric Lombrozo + +Daniel Kraft + +Chris Moore + +Alex Morcos + +dexX7 + +Warren Togami + +Mark Friedenbach + +Ross Nicoll + +Pavel Janík + +Josh Lehan + +Andrew Poelstra + +Christian Decker + +Bryan Bishop + +Benedict Chan + +฿tcDrak + +William Swanson + +Charlie Lee + +Jeremy Rubin + +Esteban Ordano + +Manuel Araoz + +Ruben de Vries + +**更多簽名可以在 [change.org](https://www.change.org/p/the-community-an-open-letter-to-the-bitcoin-community) 找到。** + +_這封信最初於 2015 年 9 月 1 日發表在 Bitcoin Magazine 上,網址為 。_ + +[1]: https://github.com/bitcoin/bitcoin/tree/master/doc/release-notes +[2]: https://github.com/bitcoin/bips +[3]: https://scalingbitcoin.org/montreal2015/ diff --git a/_posts/zh_TW/posts/2015-12-07-ml-capacity-roadmap.md b/_posts/zh_TW/posts/2015-12-07-ml-capacity-roadmap.md new file mode 100644 index 000000000..b9b613071 --- /dev/null +++ b/_posts/zh_TW/posts/2015-12-07-ml-capacity-roadmap.md @@ -0,0 +1,93 @@ +--- +title: Bitcoin 系統容量增加路線圖 +permalink: /zh_TW/2015/12/07/roadmap/ +lang: zh_TW +id: zh_TW-ml-roadmap-2015-12-07 +name: ml-roadmap-2015-12-07 +type: posts +layout: post +canonical: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +version: 1 +--- +_以下路線圖最初由 Gregory Maxwell 於 2015 年 12 月 7 日發布到 [bitcoin-dev 郵件列表](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html)。_ + +香港的 Scaling Bitcoin 研討會剛剛結束。許多令人著迷的提案被展示出來。 +我認為這是分享我對 Bitcoin 系統容量增加近期發展方向看法的好時機。 +我相信我們現在處於一個絕佳的位置,社群已經準備好提供一個清晰的前進路徑,並有一個共同的願景來解決系統的需求,同時維護其價值。 + +我認為首先清楚表達我認為應該指導 Bitcoin 系統持續發展的一些相關原則很重要。 + +Bitcoin 是點對點電子現金,由於透過去中心化為使用者帶來貨幣自主權,因此相對於傳統系統具有價值。Bitcoin 試圖解決傳統貨幣的根本問題:使其運作所需的所有信任-- + +-- 並不是說正當的信任是壞事,但信任使系統變得脆弱、不透明且運營成本高昂。 +信任失敗導致系統性崩潰,信任管理創造不平等和壟斷鎖定,自然產生的信任阻塞點可能被濫用以拒絕正當程序的存取。 +透過使用加密證明和去中心化網路,Bitcoin 最小化並取代了這些信任成本。 + +使用現有技術,規模和去中心化之間存在基本的權衡。 +如果系統成本太高,人們將被迫信任第三方,而不是獨立執行系統規則。 +如果 Bitcoin 區塊鏈的資源使用量相對於可用技術來說太大,Bitcoin 將失去相對於傳統系統的競爭優勢,因為驗證成本太高(將許多使用者定價排除在外),迫使信任重新進入系統。 +如果容量太低,我們的交易方法效率太低,存取鏈進行爭議解決的成本將太高,再次將信任推回系統。 + +由於 Bitcoin 是電子現金,它_不是_一個通用資料庫;對廉價高度複製永久儲存的需求是無限的,Bitcoin 不能也不會滿足非電子現金(非 Bitcoin)使用的需求,這並不可恥。 +幸運的是,Bitcoin 可以與解決其他應用程式的其他系統互操作,而且--憑藉運氣和努力--Bitcoin 系統可以並且將會滿足世界對電子現金的需求。 + +幸運的是,許多偉大的技術正在開發中,使得導航權衡變得更容易。 + +首先:經過幾年的開發,Bitcoin Core 最近合併了 libsecp256k1,這導致簽名驗證效能大幅提高。 +結合其他最近的工作,我們現在在 0.12 中獲得的 ConnectTip 效能比以前的版本高 7 倍。這 +已經醞釀了很長時間,如果沒有對它的預期和早期工作(如 headers-first),我可能會在去年主張減少區塊大小。 +這種廣泛可用的生產 Bitcoin 軟體技術水平的改進為一些容量增加奠定了基礎,同時仍在彌補我們的去中心化赤字。這將瓶頸從 CPU 轉移到更強烈地轉移到傳播延遲和頻寬上。 + +Versionbits (BIP9) 正在接近成熟,將允許 Bitcoin 網路擁有多個進行中的軟分叉。到目前為止,我們必須完全序列化軟分叉工作,而且也沒有真正的方法來處理在核心中合併但被網路拒絕的軟分叉。 +所有這些都在 BIP9 中得到解決,這應該允許我們加快網路改進的步伐。看起來 versionbits 將準備好在網路上執行的下一個軟分叉中使用。 + +接下來是,在香港的 Scaling Bitcoin 上,Pieter Wuille 介紹了將隔離見證帶到 Bitcoin。 +提議的是一個_軟分叉_,透過重組區塊中的資料以單獨處理簽名,從而增加 Bitcoin 的可擴展性和容量,並在此過程中將它們從當前區塊大小限制的範圍中移除。 + +該特定提案最多相當於 4MB 區塊大小增加。這種分離允許新的安全模型,例如跳過下載您不打算檢查的資料以及改善輕客戶端的效能(尤其是具有高隱私性的客戶端)。 +該提案還包括欺詐證明,這使得違反 Bitcoin 系統的行為可以用緊湊的證明來證明。 +這完成了 Bitcoin 白皮書「簡化支付驗證」部分中描述的「警報」願景,並將使輕客戶端能夠執行系統的所有規則(在他們不會與會產生證明的人分離的新強假設下)。 +該設計具有許多其他功能,例如使進一步的增強更安全並消除簽名可塑性 +問題。如果廣泛使用,該提案將提供 2 倍的容量增加(如果廣泛使用多重簽名則更多),但最重要的是,它透過提高效率和允許更多權衡(特別是,您可以使用更少的頻寬來換取強大的非分區假設)使該額外容量--以及未來更多的容量--更安全。 + +在 有一個工作實作(儘管它還沒有欺詐證明)。 + +(Pieter 的演講在: [文字記錄](http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/)、[幻燈片](https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/)、[影片](https://www.youtube.com/watch?v=fst1IK_mrng#t=36m))。 + +我在 Elements Alpha 側鏈中成功部署了早期(硬分叉)版本的 segwit;現在提議的軟分叉 segwit 是第二代設計。我認為在相對較短的時間內部署它是相當合理的。 +segwit 設計要求未來進行與 bitcoinj 相容的硬分叉以進一步提高其效率--但這不是獲得大部分好處所必需的,這意味著它可以按照自己的時間表並以非爭議的方式發生。 + +超越 segwit,圍繞更高效的區塊中繼一直有相當大的活動在醞釀。有一系列提案,有些源於我受 p2pool 啟發的非正式草圖,有些是獨立發明的,稱為「弱區塊」、「瘦區塊」或「軟區塊」。 +這些提案建立在高效中繼技術(如中繼網路協定或 IBLT)之上,並在找到區塊之前將區塊的幾乎所有傳輸時間移至之前,從孤塊競賽計算中消除大小。我們在當前區塊大小下已經迫切需要這個。這些尚未實作,但幸運的是路徑似乎很清晰。 +我至少看到了一個或多或少完整的規範,我預計在幾個月內會看到使用它的東西執行。這個工具將在礦工沒有策略行為的情況下消除傳播延遲成為問題。當礦工策略性地行為時更好地理解他們的行為是一個開放的問題。 + +同時,有很多關於「非頻寬」擴展機制的活動正在進行。 +非頻寬擴展機制是像交易切割和雙向支付通道這樣的工具,它們使用聰明的智慧合約而不是增加頻寬來增加 Bitcoin 的容量和速度。 +關鍵的是,這些方法直接針對容量與自主性權衡的核心,並可能允許我們實現非常高的容量和非常高的去中心化。CLTV (BIP65) 於一個月前部署,現在在網路上活躍,對這些技術非常有用(對於使保留退款工作至關重要);CSV (BIP68 / BIP112) 正在核心中合併的管道中並取得良好進展(並且可能會在 segwit 之前準備好)。 +正在開發用於非頻寬擴展的進一步 Bitcoin 協定改進:許多這些提案確實需要反可塑性修復(將由 segwit 提供),並且已經提供了 checksig 標誌改進,還有更多正在開發中,使用 segwit 部署會容易得多。 +我預計在六個月內,我們可以有更多功能準備好部署以啟用這些技術。即使沒有它們,我相信我們在近期容量方面的位置也是可以接受的,但為未來啟用它們很重要。 + + 是關於 Lightning 所需的一些網路功能的相關演講,Lightning 是一個雙向支付通道提案,許多方現在正在研究;過去討論的其他非頻寬改進包括交易切割,我認為這是理解交易容量如何大於區塊鏈容量的基本直覺的必讀: ,儘管還有許多其他的。) + +更遠一點,有幾個與彈性上限或基於允許礦工以某種成本生產更大區塊的激勵對齊動態區塊大小控制相關的提案。 +這些提案有助於保持礦工和一般節點運營商之間的激勵一致,並防止礦工之間的背叛破壞最終將為安全提供資金的手續費市場行為。 +我認為現在容量足夠高,所需容量足夠低,我們不會立即需要這些提案,但它們長期來說將是至關重要的。 +我計劃在接下來的幾個月裡幫助並推動這些提案朝著更具體的方向發展。 + +(相關演講包括 。 + +最後--在某個時候,上述的容量增加可能還不夠。 +在中繼改進、segwit 欺詐證明、動態區塊大小控制和其他技術進步上的交付將降低風險,因此降低圍繞適度區塊大小增加提案的爭議(例如 2/4/8 重新調整以尊重 segwit 的增加)。 +當改進和理解使其風險相對於不部署它們的風險而言被廣泛接受時,Bitcoin 將能夠推進這些增加。 +在 Bitcoin Core 中,我們應該準備好補丁來實作它們,當需要和意願出現時,以防止基本軟體工程成為限制因素。 + +我們最近和當前的進展很好地定位了 Bitcoin 生態系統來處理其當前的容量需求。 +我認為上述內容提出了一些明確可實現的里程碑,以繼續推進 Bitcoin 容量的技術,同時使我們處於進一步改進和演進的良好位置。 + +TL;DR: 我建議我們立即致力於 segwit 4MB 區塊軟分叉,它增加了容量和可擴展性,最近的加速和即將到來的中繼改進使 segwit 成為合理的風險。BIP9 和 segwit 也將使進一步的改進更容易和更快地部署。 +我們將繼續為基於非頻寬增加的擴展奠定基礎,同時構建額外的工具,使頻寬增加長期更安全。 +進一步的工作將為 Bitcoin 準備進一步的增加,當有理由時這將成為可能,同時也提供使它們合理的基礎。 + +感謝您的時間, + +_最初由 Gregory Maxwell 於 2015 年 12 月 7 日發布到 bitcoin-dev 郵件列表 _ diff --git a/_posts/zh_TW/posts/2015-12-14-segregated-witness.md b/_posts/zh_TW/posts/2015-12-14-segregated-witness.md new file mode 100644 index 000000000..c2af38aa1 --- /dev/null +++ b/_posts/zh_TW/posts/2015-12-14-segregated-witness.md @@ -0,0 +1,17 @@ +--- +type: posts +layout: post +lang: zh_TW +id: zh_TW-segregated-witness +name: segregated-witness +title: 隔離見證影片演示 +permalink: /zh_TW/2015/12/14/segregated-witness/ +related: false +tags: [scalability] +version: 1 +excerpt: 這是 Pieter Wuille 關於隔離見證的擴展演示。 +--- + +這是 Pieter Wuille 關於隔離見證的擴展演示。 + +https://www.youtube.com/embed/NOYNZB5BCHM diff --git a/_posts/zh_TW/posts/2015-12-23-capacity-increases-faq-zh_tw.md b/_posts/zh_TW/posts/2015-12-23-capacity-increases-faq-zh_tw.md index 84a5d9557..6e5e3192a 100644 --- a/_posts/zh_TW/posts/2015-12-23-capacity-increases-faq-zh_tw.md +++ b/_posts/zh_TW/posts/2015-12-23-capacity-increases-faq-zh_tw.md @@ -21,11 +21,11 @@ version: 1 | 2016年4月\* | 0.12.x | 完成隔離見證 | | 2016年 | | 弱區塊, IBLTs, 或者二者都實現 | -\* 有星號的日期是預計完成代碼的時間。代碼只會在充分審核後才會發表，而軟分叉完成也需要時間。([BIP66][]經歷數月時間在2015年7月生效，[BIP65][]則只用了五周時間在2015年12月生效) +\* 有星號的日期是預計完成程式碼的時間。程式碼只會在充分審核後才會發表，而軟分叉完成也需要時間。([BIP66][]經歷數月時間在2015年7月生效，[BIP65][]則只用了五周時間在2015年12月生效) - **隔離見證測試網:** 一個獨立的測試網，並非平常測試網的一部分。讓 Bitcoin Core 開發員及錢包開發員測試隔離見證功能。 -- **Libsecp256k1驗證:** 在x86\_64硬件上提升交易驗證速度五至七倍。幫助新節點加入網絡並減輕現有節點的負擔。 +- **Libsecp256k1驗證:** 在x86\_64硬體上提升交易驗證速度五至七倍。幫助新節點加入網路並減輕現有節點的負擔。 - **OP\_CHECKSEQUENCEVERIFY:** 讓雙向[支付通道][payment channel efficiency]可以無限期使用，提升效率達25倍。 @@ -33,11 +33,11 @@ version: 1 - **隔離見證:** 允許交易容量上升到1.75至4倍，解決第三方延展性讓智能合約更安全，雙向支付通道效率提升66%，提供欺詐證明讓輕量節點也可以執行系統規則，更容易對腳本系統升級以允許更強大的合約功能。 -- **IBLT及弱區塊:** 只需要把[總帶寬增加少許][increase in total bandwidth]，就可以把區塊傳播所必須的帶寬減低90%以上，讓礦工可以在最短時間內把區塊傳播出去，把[比特幣廣播網絡][Bitcoin Relay Network]的好處帶給所有全節點。IBLT及弱區塊可以把全節點所需的帶寬變得更平均，讓將來可以更安全地增加最大區塊容量。 +- **IBLT及弱區塊:** 只需要把[總頻寬增加少許][increase in total bandwidth]，就可以把區塊傳播所必須的頻寬減低90%以上，讓礦工可以在最短時間內把區塊傳播出去，把[比特幣廣播網路][Bitcoin Relay Network]的好處帶給所有全節點。IBLT及弱區塊可以把全節點所需的頻寬變得更平均，讓將來可以更安全地增加最大區塊容量。 ## 隔離見證軟分叉究竟相當於多少的區塊大小增加？我聽過不同講法，如4MB、2MB、1.75MB。 {#segwit-size} -[現在的方案][current proposal]是以軟分叉來實現隔離見證，並把每字節的見證內容算為0.25字節，因此最大的區塊體積會是稍低於4MB。 +[現在的方案][current proposal]是以軟分叉來實現隔離見證，並把每位元組的見證內容算為0.25位元組，因此最大的區塊體積會是稍低於4MB。 然而，區塊並不應該只有見證內容，而計算非見證內容的體積時不會有折扣，因此並不可能有4MB的體積。 @@ -50,15 +50,15 @@ version: 1 有些想法是容易解釋但執行很難，有些卻是解釋很難但執行容易，隔離見證似乎是後者。 -由於隔離見證可以逐步實行而不會破壞兼容性，因此生態內各環節無需特別準備。開發員可以在2015年12月推出的測試網得到實際的使用經驗並同時測試他們的軟件。 +由於隔離見證可以逐步實行而不會破壞兼容性，因此生態內各環節無需特別準備。開發員可以在2015年12月推出的測試網得到實際的使用經驗並同時測試他們的軟體。 -最初，只有希望支持隔離見證的礦工需要升級，讓新規則可以在主網實行。現有的應用程序只有需要使用新功能才需要改變。 +最初，只有希望支持隔離見證的礦工需要升級，讓新規則可以在主網實行。現有的應用程式只有需要使用新功能才需要改變。 隔離見證交易收取較低交易費，有更佳的性能，而且支持多重簽名智能合約，如雙向支付通道，可以作大量交易卻無需在區塊鏈作額外紀錄。我們強烈建議錢包升級，但即使不升級，現有錢包仍然可以繼續正常使用。 ## 我還是覺得隔離見證很複雜，為什麼不簡單地提高區塊體積？ {#size-bump} -在Bitcoin Core有[一句代碼][max_block_size]指定區塊最大是 1,000,000 字節 (1MB)。最簡單的方法是用硬分叉改變這句代碼，例如變為 2,000,000 字節 (2MB)。 +在Bitcoin Core有[一行程式碼][max_block_size]指定區塊最大是 1,000,000 位元組 (1MB)。最簡單的方法是用硬分叉改變這行程式碼，例如變為 2,000,000 位元組 (2MB)。 但硬分叉本身絕不簡單: @@ -66,13 +66,13 @@ version: 1 軟分叉則不同。軟分叉最初由中本聰管理，然後我們又從實行[BIP16][]所遇到的問題中得到經驗，讓我們以改良了的方法實行[BIP34][]，以及後來的BIP[66][BIP66] 和 [65][BIP65]。在將來的軟分叉，我們正準備使用[BIP9][] version bits，讓多個軟分叉方案可以同時進行。 -- **強制升級:** 硬分叉要求所有全節點升級，而任何使用舊版本節點的人都可能會損失金錢，這不但包括全節點錢包的運行者本身，還包括依靠該全節點提供數據的輕量錢包。 +- **強制升級:** 硬分叉要求所有全節點升級，而任何使用舊版本節點的人都可能會損失金錢，這不但包括全節點錢包的營運者本身，還包括依靠該全節點提供資料的輕量錢包。 -- **需要其它的改動:** 即使只是改一行代碼來增加最大區塊容量，也會影響到系統內其它代碼，有些更是不良的影響。例如現在可以制造一個接近1MB的交易，而現代的電腦驗證該交易需時超過30秒 (這樣的交易已存在於區塊鏈上)。在2MB的區塊下，驗證一個2MB的交易需時10分鐘，將成為一個很危險的攻擊方法。為了避免這種攻擊，就有必要改動其它代碼。 +- **需要其它的改動:** 即使只是改一行程式碼來增加最大區塊容量，也會影響到系統內其它程式碼，有些更是不良的影響。例如現在可以制造一個接近1MB的交易，而現代的電腦驗證該交易需時超過30秒 (這樣的交易已存在於區塊鏈上)。在2MB的區塊下，驗證一個2MB的交易需時10分鐘，將成為一個很危險的攻擊方法。為了避免這種攻擊，就有必要改動其它程式碼。 雖然有以上的問題，但只要有充足的準備，硬分叉並不會出現致命問題，而我們也預計將來會有硬分叉。但隔離見證可以用我們更熟悉的軟分叉完成，而且帶來增加交易量以外更多的好處。 -和簡單提升區塊體積相比，隔離見證需要在不同的軟件層面作更多改動。但如果我們真的希望比特幣可以擴展，我們無論如何也需要根本性的改動，而隔離見證可以逐漸地鼓勵人們升級至更具擴展性的方案，卻無需強逼他們這樣做。 +和簡單提升區塊體積相比，隔離見證需要在不同的軟體層面作更多改動。但如果我們真的希望比特幣可以擴展，我們無論如何也需要根本性的改動，而隔離見證可以逐漸地鼓勵人們升級至更具擴展性的方案，卻無需強逼他們這樣做。 開發員，礦工，以及社群已對軟分叉有充分經驗，我們相信實行隔離見證所需時間並不比提升容量的硬分叉為多，而且會更安全。 @@ -86,7 +86,7 @@ version: 1 利用有廣泛共識的軟分叉，我們能夠把系統擴展而沒有硬分叉的[副作用][q simple raise]，因此即使預期會有硬分叉，這並不是現在就要做的充分理由。 -在路線圖提到的改進，除提供額外的交易容量以外，配合其它技術如雙向支付通道，可以讓用戶減少使用區塊鏈，變相提高了比特幣系統的容量，卻不用增加全節點使用的帶寬。例如： +在路線圖提到的改進，除提供額外的交易容量以外，配合其它技術如雙向支付通道，可以讓用戶減少使用區塊鏈，變相提高了比特幣系統的容量，卻不用增加全節點使用的頻寬。例如： - [BIP68][] 及 [BIP112][] 允許無限期的雙向支付通道，可以大為減少紀錄在區塊鏈的交易。 @@ -94,25 +94,25 @@ version: 1 - 隔離見證允許將來更容易以軟分叉改變比特幣的腳本語言，例如從簽名提取公鑰，或使用Schnorr聯合簽名算法，從而減少交易的平均大小。 -- 實行隔離見證後，當無效區塊出現時就可以產生很簡潔的欺詐證明，這會讓進行簡單交易驗證 (SPV) 的輕量節點的安全性更接近全節點，可以讓整個網絡在較少的全節點下仍能運作。 +- 實行隔離見證後，當無效區塊出現時就可以產生很簡潔的欺詐證明，這會讓進行簡單交易驗證 (SPV) 的輕量節點的安全性更接近全節點，可以讓整個網路在較少的全節點下仍能運作。 -這些技術的實際效果仍然未知，但實行一個具廣泛共識的軟分叉可讓我們立即得益並且測試和評估中期的可能性，以及用這些數據作長期的規劃。 +這些技術的實際效果仍然未知，但實行一個具廣泛共識的軟分叉可讓我們立即得益並且測試和評估中期的可能性，以及用這些資料作長期的規劃。 ## 錢包會如何使用隔離見證？ {#segwit-in-wallets} 現在支持 P2SH 的錢包可以分兩階段轉移至完整的隔離見證： -- 第一階段：腳本需要經過兩次雜湊運算，首先是變成256字節，然後再變成160字節。這個160字節的雜湊和現有的P2SH地址兼容，因此已升級的錢包和現有的錢包之間可以互相收付款項。 +- 第一階段：腳本需要經過兩次雜湊運算，首先是變成256位元組，然後再變成160位元組。這個160位元組的雜湊和現有的P2SH地址兼容，因此已升級的錢包和現有的錢包之間可以互相收付款項。 -- 第二階段：腳本只需一次雜湊運算變為256字節。這格式和現有錢包不相容，但允許更有效率地使用區塊空間，及提供更強的防碰撞攻擊性能。 +- 第二階段：腳本只需一次雜湊運算變為256位元組。這格式和現有錢包不相容，但允許更有效率地使用區塊空間，及提供更強的防碰撞攻擊性能。 ## 如果沒有人被逼升級，為何會有人升級？聽說P2SH用了差不多兩年時間才得到廣泛應用。 {#why-upgrade} -在隔離見證交易中，見證部分的每字節只算為0.25字節，也就是說這部分的交易費有75%的折扣，但只限於隔離見證的用戶。 +在隔離見證交易中，見證部分的每位元組只算為0.25位元組，也就是說這部分的交易費有75%的折扣，但只限於隔離見證的用戶。 -David Harding 提供了下表以[估計][estimated savings]在不同費用和交易類型下可以節省的費用。例如如果一個常見的250字節交易收費是0.01美元，用隔離見證花費一個P2PK-in-P2SH輸出就可以節省約0.003美元。 +David Harding 提供了下表以[估計][estimated savings]在不同費用和交易類型下可以節省的費用。例如如果一個常見的250位元組交易收費是0.01美元，用隔離見證花費一個P2PK-in-P2SH輸出就可以節省約0.003美元。 -| 交易 | 節省字節 | $0.01/250B | $0.05/250B | $0.25/250B | $1.00/250B | +| 交易 | 節省位元組 | $0.01/250B | $0.05/250B | $0.25/250B | $1.00/250B | |-------------|-------------|------------|------------|------------|------------| | P2PK-in-P2SH | 79/107 | $0.003 | $0.015 | $0.079 | $0.316 | | 1-of-1 P2SH 多簽 | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 | @@ -125,9 +125,9 @@ David Harding 提供了下表以[估計][estimated savings]在不同費用和交 ## 聽說你們會讓零確認不能再用，這是路線圖內哪一項技術？ {#rbf} -這並不是路線圖的一部分。作為現在 Bitcoin Core 版本的默認設置，在收到一個未確認交易後，就不會再接受其它有相同輸入的交易。有些人認為這表示他們首個見到的交易就是安全的，但其實不是；如果真的是這樣，我們根本不需要區塊鏈。 +這並不是路線圖的一部分。作為現在 Bitcoin Core 版本的預設設定，在收到一個未確認交易後，就不會再接受其它有相同輸入的交易。有些人認為這表示他們首個見到的交易就是安全的，但其實不是；如果真的是這樣，我們根本不需要區塊鏈。 -在現時的默認設置下，人們並不能更新他們未確認的交易。在最初的 Bitcoin 版本，其實是有方法讓使用者表明他希望交易可被更新，但為了防止拒絕服務攻擊，中本聰在2010年關閉了這功能。 +在現時的預設設定下，人們並不能更新他們未確認的交易。在最初的 Bitcoin 版本，其實是有方法讓使用者表明他希望交易可被更新，但為了防止拒絕服務攻擊，中本聰在2010年關閉了這功能。 最近 Bitcoin Core 的開發員發現只要要求更新交易的同時要求使用者要付出更多的交易費，就可以防止上述的拒絕服務攻擊，因此他們重開了中本聰那個允許交易被替換的機制。這功能會在預計2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聰原本的設計一樣，只有希望可以替換交易的使用者才需要選擇使用支持該功能的錢包。 @@ -137,19 +137,19 @@ David Harding 提供了下表以[估計][estimated savings]在不同費用和交 弱區塊和IBLT是兩種仍在研究的技術，需要選擇適當的參數，但因為參與的開發員有限，我們難以估計在什麼時候才能推出。 -弱區塊和IBLT都只涉及網絡改善而不是軟分叉或硬分叉，因此只需要較短的測試時間就可以推出讓節點升級，我們希望可以在2016年內完成。 +弱區塊和IBLT都只涉及網路改善而不是軟分叉或硬分叉，因此只需要較短的測試時間就可以推出讓節點升級，我們希望可以在2016年內完成。 在推出弱區塊和IBLT後，我們可以利用一個簡單而無爭議的軟分叉來[規範交易次序][canonical transaction ordering]讓它們更有效率，這軟分叉可以透過BIP9 versionBits 推出。 [canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions -## 「如果隔離見證不能減少礦工所用的帶寬，儲存空間，和處理時間，為什麼他們要支持？」 {#why-mine-segwit} +## 「如果隔離見證不能減少礦工所用的頻寬，儲存空間，和處理時間，為什麼他們要支持？」 {#why-mine-segwit} 其實大部分[以前的軟分叉][previous soft forks]都沒有為礦工帶來這些好處，例如： | BIP16 (P2SH) | 新交易種類 | | BIP30 (重覆交易ID) | 要求檢查重覆交易ID | -| BIP34 (Coinbase 內記錄區塊高度) | 讓礦工可用的coinbase空間減少 4 字節 | +| BIP34 (Coinbase 內記錄區塊高度) | 讓礦工可用的coinbase空間減少 4 位元組 | | BIP65 (OP_CLTV) | 新腳本命令 | 在2015年7月正式執行的 BIP66 (嚴格 DER 簽名) 軟分叉讓我們可以轉用libsecp256k1作交易驗證，讓驗證時間大減，讓礦工得益。 @@ -165,7 +165,7 @@ David Harding 提供了下表以[估計][estimated savings]在不同費用和交 ## 我可以怎樣幫忙？ 首先閱讀在 Bitcoin.org 上的 [Bitcoin Core貢獻者][Bitcoin Core contributor]網頁。 -其中[代碼審閱][code review]是實行軟分叉極重要的一部分。 +其中[程式碼審閱][code review]是實行軟分叉極重要的一部分。 如果你想得到更多有關如何貢獻的建議，請加入[#bitcoin-dev][] IRC 頻道討論。 diff --git a/_posts/zh_TW/posts/2016-01-07-statement.md b/_posts/zh_TW/posts/2016-01-07-statement.md index 95562b067..0d7d52615 100644 --- a/_posts/zh_TW/posts/2016-01-07-statement.md +++ b/_posts/zh_TW/posts/2016-01-07-statement.md @@ -13,15 +13,15 @@ version: 1 我們相信比特幣要達到這目標，就要在其之上建立多個層次的服務，並與其它系統接合。除此以外，我們的長遠目標還包括保護及增加比特幣用戶的隱私。 -「Bitcoin Core」是一個開源軟體計劃，直接承接了原本的比特幣軟件設定。作為計劃的貢獻者，我們為比特幣社群維護並發行軟件，讓用戶考慮使用。我們致力改進比特幣的共識協定，提出的升級方案，都是按我們所認知的比特幣目標所提出，在技術上可行，而且有合理機會被廣泛支持並應用。 +「Bitcoin Core」是一個開源軟體計劃，直接承接了原本的比特幣軟體設定。作為計劃的貢獻者，我們為比特幣社群維護並發行軟體，讓用戶考慮使用。我們致力改進比特幣的共識協定，提出的升級方案，都是按我們所認知的比特幣目標所提出，在技術上可行，而且有合理機會被廣泛支持並應用。 -比特幣的共識協定可以透過軟分叉或硬分叉改動 (參與附件A)。軟分叉容許具兼容性的改動，新舊軟件可以在網絡上同時存在。通過軟分叉來實現新功能不會造成擾亂，因為只有希望使用新功能的用戶才需要升級，其它用戶可以繼續正常使用原有軟件。 +比特幣的共識協定可以透過軟分叉或硬分叉改動 (參與附件A)。軟分叉容許具兼容性的改動，新舊軟體可以在網路上同時存在。通過軟分叉來實現新功能不會造成擾亂，因為只有希望使用新功能的用戶才需要升級，其它用戶可以繼續正常使用原有軟體。 -硬分叉則會破壞對所有現有比特幣軟件的兼容性，所有用戶必須在指定期限前升級，否則會有損失金錢的風險。這情況可能逼使不升級的用戶離開網絡，並可能令各種下游軟件及應用不能運作，對比特幣的網絡效應造成損害。 +硬分叉則會破壞對所有現有比特幣軟體的兼容性，所有用戶必須在指定期限前升級，否則會有損失金錢的風險。這情況可能逼使不升級的用戶離開網路，並可能令各種下游軟體及應用不能運作，對比特幣的網路效應造成損害。 -由於以上原因，Bitcoin Core 強烈地傾向保持兼容性，並相信應該由每個用戶決定是否升級他們正在使用的比特幣軟件。事實上利用軟分叉可以加入幾乎任何新功能。在某些情況下，硬分叉可能有些好處，如果能得到幾乎一致的同意，這些好處或可以勝過其缺點。但除了這些罕有情況，軟分叉仍然是首選。我們相信這是最合乎系統內現在和未來用戶的利益。 +由於以上原因，Bitcoin Core 強烈地傾向保持兼容性，並相信應該由每個用戶決定是否升級他們正在使用的比特幣軟體。事實上利用軟分叉可以加入幾乎任何新功能。在某些情況下，硬分叉可能有些好處，如果能得到幾乎一致的同意，這些好處或可以勝過其缺點。但除了這些罕有情況，軟分叉仍然是首選。我們相信這是最合乎系統內現在和未來用戶的利益。 -隨著比特幣的生態系統的成長，我們亦預計會有更多其它運行比特幣協定的軟件設定，且無可避免地這些軟件計劃可能會提出徹底不同的方案，讓比特幣的生態系統作考慮。最終而言，Bitcoin Core的開發團隊並不決定比特幣的共識規則；相對地，是由比特幣用戶選擇他們自己運行什麼比特幣軟件。因此 Bitcoin Core 刻意地沒有自動升級功能，這確保每次升級都是用戶自願進行，令用戶可以保持選擇運行什麼軟件的權力。 +隨著比特幣的生態系統的成長，我們亦預計會有更多其它執行比特幣協定的軟體設定，且無可避免地這些軟體計劃可能會提出徹底不同的方案，讓比特幣的生態系統作考慮。最終而言，Bitcoin Core的開發團隊並不決定比特幣的共識規則；相對地，是由比特幣用戶選擇他們自己執行什麼比特幣軟體。因此 Bitcoin Core 刻意地沒有自動升級功能，這確保每次升級都是用戶自願進行，令用戶可以保持選擇執行什麼軟體的權力。 ### 附件 A diff --git a/_posts/zh_TW/posts/2016-01-13-developer-visualisation-2015.md b/_posts/zh_TW/posts/2016-01-13-developer-visualisation-2015.md new file mode 100644 index 000000000..219a40022 --- /dev/null +++ b/_posts/zh_TW/posts/2016-01-13-developer-visualisation-2015.md @@ -0,0 +1,30 @@ +--- +type: posts +layout: post +lang: zh_TW +id: zh_TW-development-visualisation-2015 +name: development-visualisation-2015 +title: 2015 年核心開發視覺化 +permalink: /zh_TW/2016/01/13/development-visualisation-2015/ +version: 1 +excerpt: 以下影片顯示了 2015 年期間 Bitcoin Core 儲存庫中的提交活動。 +--- +以下影片顯示了 2015 年期間 [Bitcoin Core 儲存庫][repository]中的提交活動。此期間程式碼貢獻者的完整列表可在[此處][activity]找到。 + +https://www.youtube.com/embed/FIt7GLxxIpY + +2015 年，Bitcoin Core 專案發布了 2 個主要版本的軟體以及 5 個進一步的維護版本。此外，部署並成功啟動了兩個軟分叉升級。第一個 [BIP66] 修復了 openssl 引入的潛在嚴重安全漏洞；第二個 [BIP65] 向 Bitcoin 指令碼語言新增了一個新的操作碼 CHECKLOCKTIMEVERIFY。 + +該專案還完成了下一個主要版本 [0.12] 的大部分工作，計劃於 2 月發布。[0.12] 將包含 [libsecp256k1]，該程式庫已開發了[兩年半][secp_contributors]，並將簽章驗證速度提高了 7 倍，這對於未來提高可擴展性至關重要。 + +請注意，提交活動僅代表整體開發者活動的一部分，並未記錄同行審查者、程式碼審查者、整合測試人員和翻譯人員的活動。它也沒有準確反映在被接受到程式庫之前進行研究、討論和開發所花費的時間。 + +我們也想藉此機會感謝迄今為止參與貢獻 Bitcoin Core 並幫助讓 Bitcoin 為每個人變得更好的每一個人。 + +[repository]: https://github.com/bitcoin/bitcoin +[activity]: https://github.com/bitcoin/bitcoin/graphs/contributors?from=2015-01-01&to=2016-01-01&type=c +[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki +[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki +[0.12]: https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md +[libsecp256k1]: https://github.com/bitcoin/secp256k1 +[secp_contributors]: https://github.com/bitcoin/secp256k1/graphs/contributors?from=2013-03-04&to=2015-12-01&type=c diff --git a/_posts/zh_TW/posts/2016-01-21-segwit-testnet.md b/_posts/zh_TW/posts/2016-01-21-segwit-testnet.md new file mode 100644 index 000000000..6f19bc32c --- /dev/null +++ b/_posts/zh_TW/posts/2016-01-21-segwit-testnet.md @@ -0,0 +1,69 @@ +--- +type: posts +layout: post +lang: zh_TW +id: zh_TW-segwit-testnet +name: segwit-testnet +title: 隔離見證測試網啟動 +permalink: /zh_TW/2016/01/21/launch_segwit_testnet/ +version: 1 +excerpt: 我們非常高興和興奮地宣布隔離見證測試網的發布 +--- + +我們非常高興和興奮地宣布[隔離見證測試網](https://github.com/sipa/bitcoin/commits/segwit)的發布！我們鼓勵所有開發者立即開始協助測試和整合工作。 + +這代表了迄今為止最受期待和令人興奮的發展之一，是許多未來改進和創新的重要基礎。隔離見證透過將交易簽名資料安全地移至交易區塊外的特別指定「隔離見證」資料結構中，釋放了 Bitcoin 區塊鏈上的空間。 + +這項重大創新使 Bitcoin 區塊鏈的使用效率大幅提升，同時為更廣泛的 Bitcoin 生態系統開啟了令人興奮的新可能性和機會，特別是在智慧合約應用和更快速的交易方面，同時也為未來更進階的功能和可能性奠定了基礎。 + +這項開發始於 Bitcoin Core 開發者 Dr. Pieter Wuille 的研究工作，最初專注於解決交易可塑性問題，這是一個長期存在且廣為人知的關注點和優先事項。然而，在研究過程中以及在縮小解決方案範圍時，發現了該解決方案的其他特性，這些特性不僅允許增加區塊大小，同時還開啟了一些令人難以置信的次要好處。 + +這項工作由 Dr. Pieter Wuille 發起，但也包含了許多其他人的貢獻，特別感謝 Eric Lombrozo、Johnson Lau、Alex Morcos、Nicolas Dorier、Bryan Bishop、Gregory Maxwell、Peter Todd、Cory Fields、Suhas Daftuar 和 Luke-Jr。 + +## Bitcoin Core 生態系統 + +提供者和其他交易所營運者將使用此版本中包含的基礎開發和創新來創造什麼，存在著廣泛的興奮和期待。到目前為止，最受歡迎的錢包和支援程式庫已表示將支援 segwit，包括 Ledger、Trezor、Electrum 和 Bitgo。此外，許多其他程式庫如 bitcoinj、bitcoinjs、pycoin 和 bitcore 的工作已經開始。 + +「segnet」代幣的水龍頭可在[這裡](https://segwit.greenaddress.it/faucet/)取得。 + +第三方錢包支援的早期預覽可在以下位置取得： + +- [mSIGNA](https://github.com/ciphrex/mSIGNA/tree/segwit)（錢包原始碼） +- [Green Address](https://segwit.greenaddress.it/)（網頁錢包） + +## 如何參與 + +請加入 irc.freenode.net 上的 `segwit-dev` IRC 頻道。 + +錢包提供者應閱讀[遷移指南](/zh_TW/segwit_wallet_dev)。 + +## 測試 + +最後也是最重要的，請協助測試隔離見證測試網！ + +原始碼可以在[這裡](https://github.com/sipa/bitcoin/tree/segwit)找到，請 checkout `segwit` 分支。 + +編譯完成後，在標準的 `bitcoind` 和 `bitcoin-cli` 命令列中加入 `-segnet`。 + +## 其他背景和歷史 + +- [Scaling Bitcoins 香港演講](https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/) +- [擴展影片](https://bitcoincore.org/zh_TW/2015/12/14/segregated-witness) +- [逐字稿](http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/) + +## 技術參考 + +### SegWit BIP + +- [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)：隔離見證軟分叉的概述，以及對其好處、向後相容性、共識限制和部署的討論。 +- [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)：隔離見證交易中用於簽名驗證的新摘要演算法定義。 +- [BIP144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki)：隔離見證交易的新訊息類型和序列化格式。 + +### 參考資料 + +- [隔離見證好處分析](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012248.html) +- [硬分叉與軟分叉](https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks) +- [「非爭議性」硬分叉研究的早期探索](https://scalingbitcoin.org/hongkong2015/presentations/DAY1/1_overview_1_timon.pdf) + +[FAQ]: https://bitcoincore.org/zh_TW/2015/12/23/capacity-increases-faq +[roadmap]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html diff --git a/_posts/zh_TW/posts/2016-01-26-segwit-benefits.md b/_posts/zh_TW/posts/2016-01-26-segwit-benefits.md new file mode 100644 index 000000000..8daf1672e --- /dev/null +++ b/_posts/zh_TW/posts/2016-01-26-segwit-benefits.md @@ -0,0 +1,205 @@ +--- +type: posts +layout: post +lang: zh_TW +name: segwit-benefits +id: zh_TW-segwit-benefits +title: 隔離見證的好處 +permalink: /zh_TW/2016/01/26/segwit-benefits/ +version: 1 +excerpt: 本頁總結了隔離見證的一些好處。 +--- +{% include toc.html %} + +隔離見證軟分叉（segwit）包含了廣泛的功能，其中許多功能具有高度技術性。本頁總結了這些功能的一些好處。 + +## 可塑性修復 + +Bitcoin 交易透過一個 64 位十六進位雜湊來識別，稱為交易識別碼（txid），該識別碼基於正在花費的代幣和誰將能夠花費交易的結果。 + +不幸的是，txid 的計算方式允許任何人對交易進行小幅修改，這不會改變其含義，但會改變 txid。這稱為第三方可塑性。BIP 62（「處理可塑性」）試圖以零碎的方式解決這些問題，但實作起來過於複雜而無法作為共識檢查，已被撤回。 + +例如，您可以向網路提交一個 txid 為 ef74...c309 的交易，但發現第三方（例如網路上中繼您交易的節點，或將您的交易包含在區塊中的礦工）稍微修改了交易，導致您的交易仍然花費相同的代幣並支付相同的地址，但在完全不同的 txid 683f...8bfa 下確認。 + +更一般地說，如果交易的一個或多個簽名者修改他們的簽名，則交易仍然有效並向相同地址支付相同金額，但 txid 會完全改變，因為它包含了簽名。簽名資料（但不是輸出或輸入選擇）的變更修改交易的一般情況稱為 scriptSig 可塑性。 + +Segwit 透過允許 Bitcoin 使用者將交易的可塑部分移至*交易見證*中，並隔離該見證，使見證的變更不影響 txid 的計算，從而防止第三方和 scriptSig 可塑性。 + +### 誰受益？ + +- **追蹤已花費 bitcoin 的錢包作者**：最簡單的監控自己傳出交易狀態的方法是透過 txid 查詢它們。但在具有第三方可塑性的系統中，錢包必須實作額外的程式碼才能處理變更的 txid。 + +- **任何花費未確認交易的人**：如果 Alice 在交易 1 中向 Bob 付款，Bob 在交易 2 中使用該付款向 Charlie 付款，然後 Alice 的付款被可塑化並以不同的 txid 確認，那麼交易 2 現在無效，Charlie 沒有收到付款。如果 Bob 值得信任，他將重新發出向 Charlie 的付款；但如果他不值得信任，他可以簡單地為自己保留這些 bitcoin。 + +- **閃電網路**：隨著第三方和 scriptSig 可塑性被修復，閃電網路的實作變得不那麼複雜，並且在區塊鏈上的空間使用上顯著更有效率。移除 scriptSig 可塑性後，也可以執行輕量級閃電客戶端，將監控區塊鏈的工作外包出去，而不是每個閃電客戶端都需要成為完整的 Bitcoin 節點。 + +- **任何使用區塊鏈的人**：今天的智慧合約（例如微支付通道）和預期的新智慧合約，變得不那麼複雜設計、理解和監控。 + +注意：只有當隔離見證交易的所有輸入都是 segwit 花費（直接或透過向後相容的 segwit P2SH 地址）時，segwit 交易才能避免可塑性。 + +### 進一步資訊 + + * [Bitcoin Wiki 上的可塑性](https://en.bitcoin.it/wiki/Transaction_Malleability) + * [Coin Telegraph 關於 2015 年可塑性攻擊的文章](http://cointelegraph.com/news/115374/the-ongoing-bitcoin-malleability-attack) + * [Bitcoin Magazine 關於 2015 年可塑性攻擊的文章](https://bitcoinmagazine.com/articles/the-who-what-why-and-how-of-the-ongoing-transaction-malleability-attack-1444253640) + * [「閃電網路所需的 BIP 概述」逐字稿](http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/) + * [BIP 62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) + * [BIP 140 -- 可塑性修復的替代方法](https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki) + * [關於 683f...8bfa 交易的 Stack exchange 回答](http://bitcoin.stackexchange.com/questions/22051/transaction-malleability-in-the-blockchain/22058#22058) + +## 簽章操作的線性擴展 + +增加 Bitcoin 區塊大小的簡單方法的一個主要問題是，對於某些交易，簽名雜湊的擴展是二次方的而不是線性的。 + +![線性與二次方](/assets/images/linear-quad-scale.png) + +本質上，將交易的大小加倍可以使簽名操作的數量加倍，以及為了驗證每個簽名而必須雜湊的資料量加倍。這在實際環境中已經出現，其中單個區塊需要 25 秒來驗證，惡意設計的交易可能需要超過 3 分鐘。 + +Segwit 透過變更簽名的交易雜湊計算來解決這個問題，使得交易的每個位元組最多只需要雜湊兩次。這更有效地提供了相同的功能，因此即使惡意生成或支援更大的區塊（因此更大的交易），也可以生成大型交易而不會遇到簽名雜湊問題。 + +### 誰受益？ + +移除驗證簽名的雜湊資料的二次方擴展使增加區塊大小更安全。在不限制交易大小的情況下執行此操作，允許 Bitcoin 繼續支援向大型群組付款或來自大型群組的付款，例如礦池獎勵的付款或群眾募資服務。 + +修改後的雜湊僅適用於從見證資料發起的簽名操作，因此來自基礎區塊的簽名操作將繼續需要較低的限制。 + +### 進一步資訊 + + * [BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) + * [Rusty Russell 關於 25 秒交易的部落格文章](http://rusty.ozlabs.org/?p=522) + * [Bitcoin wiki 上的 CVE 2013-2292](https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2013-2292) + * [將交易限制為 100kB 的提案](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009494.html) + * [Bitcoin Classic 在 0.11.2 分支上的提交，新增了對 sighash 位元組的額外共識限制](https://github.com/bitcoinclassic/bitcoinclassic/commit/842dc24b23ad9551c67672660c4cba882c4c840a) + +## 透過 pay-to-script-hash (P2SH) 增加多重簽名的安全性 + +多重簽名付款目前使用 P2SH，它由 160 位元 HASH160 演算法（SHA256 的 RIPEMD）保護。然而，如果其中一個簽名者希望竊取所有資金，他們可以在作為多重簽名腳本一部分的有效地址與只向他們支付所有資金的腳本之間找到碰撞，只需 80 位元（280）的工作量，這對於資源極其豐富的攻擊者來說已經在可能的範圍內。（作為比較，在持續 1 exahash/秒的情況下，Bitcoin 挖礦網路每兩週完成 80 位元的工作量） + +Segwit 透過僅對直接向單個公鑰的付款使用 HASH160（在這種情況下這種攻擊是無用的），同時對向腳本雜湊的付款使用 256 位元 SHA256 雜湊來解決這個問題。 + +### 誰受益？ + +透過 segwit 向多重簽名或智慧合約付款的每個人都受益於為腳本提供的額外安全性。 + +### 進一步資訊 + + * [Gavin Andresen 詢問 80 位元攻擊是否值得擔心](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html) + * [Ethan Heilman 描述循環查找演算法](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012202.html) + * [Rusty Russell 計算執行攻擊的成本](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012227.html) + * [Anthony Towns 應用循環查找演算法來利用交易](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012218.html) + * [Gavin Andresen 總結討論串](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012234.html) + +## 腳本版本控制 + +對 Bitcoin 腳本的變更允許改進安全性和功能。然而，腳本的設計僅允許透過用新的操作碼替換十個額外的 OP\_NOP 操作碼之一來實作向後相容（軟分叉）的變更，該新操作碼可以有條件地使腳本失敗，但在其他情況下什麼都不做。這對於許多變更來說是足夠的 -- 例如引入新的簽名方法或像 OP\_CLTV 這樣的功能，但它既有點 hacky（例如，OP\_CLTV 通常必須伴隨 OP\_DROP），也無法用於啟用甚至像連接兩個字串這樣簡單的功能。 + +Segwit 透過為腳本包含版本號來解決這個問題，因此在非 segwit 交易中需要硬分叉才能使用的額外操作碼，可以透過簡單地增加腳本版本來支援。 + +### 誰受益？ + +更容易變更腳本操作碼將使 Bitcoin 中的進階腳本更容易。這包括引入 Schnorr 簽名、使用金鑰恢復來縮小簽名大小、支援側鏈，或使用 Merklized Abstract Syntax Trees (MAST) 和其他研究級想法來建立更智慧的合約等變更。 + +## 減少 UTXO 增長 + +每個驗證的 Bitcoin 節點都維護未花費交易輸出（UTXO）資料庫，以確定新交易是有效還是欺詐。為了網路的有效運作，此資料庫需要非常快速地查詢和修改，並且理想情況下應該能夠放入主記憶體（RAM），因此將資料庫的大小（以位元組為單位）保持在盡可能小的範圍內是有價值的。 + +隨著 Bitcoin 的成長，這變得更加困難，因為每個新使用者必須至少有一個自己的 UTXO 條目，並且將偏好擁有多個條目以幫助改善他們的隱私和靈活性，或提供作為支付通道或其他智慧合約的支援。 + +Segwit 透過使不影響 UTXO 集大小的簽名資料成本比影響 UTXO 集大小的資料低 75% 來改善這種情況。預期這將鼓勵使用者偏好使用對 UTXO 集影響最小的交易以最小化費用，並鼓勵開發者以同樣最小化對 UTXO 集影響的方式設計智慧合約和新功能。 + +因為 segwit 是軟分叉變更並且不增加基礎區塊大小，所以 UTXO 集的最壞情況增長率保持不變。 + +### 誰受益？ + +減少的 UTXO 增長將使礦工、企業和執行完整節點的使用者受益，這反過來又有助於在更多使用者進入系統時維持 Bitcoin 網路的當前安全性。幫助最小化 UTXO 集增長的使用者和開發者將受益於較低的費用，相對於那些忽視其交易對 UTXO 增長影響的人。 + +### 進一步資訊 + + * [Statoshi UTXO 儀表板](http://statoshi.info/dashboard/db/unspent-transaction-output-set) + +## 不驗證簽名時的效率提升 + +歷史交易的簽名可能不如未來交易的簽名有趣 -- 例如，Bitcoin Core 預設不檢查最近檢查點之前的交易簽名，而某些 SPV 客戶端根本不檢查簽名本身，信任這已經由礦工或其他節點完成。然而，目前簽名資料是交易的組成部分，必須存在才能計算交易雜湊。 + +隔離簽名資料允許對簽名資料不感興趣的節點將其從磁碟中剪除，或避免首先下載它，從而節省資源。 + +### 誰受益？ + +隨著更多交易使用 segwit 地址，執行剪除或 SPV 節點的人將能夠以更少的頻寬和磁碟空間運作。 + +## 區塊容量/大小增加 + +由於舊節點只會下載去除見證的區塊，它們只對該資料強制執行 1 MB 區塊大小限制規則。 +因此，理解包含見證資料的完整區塊的新節點可以用新的限制取代這個限制，允許更大的區塊大小。隔離見證因此利用這個機會將區塊大小限制提高到接近 4 MB，並新增了新的成本限制以確保區塊在其資源使用上保持平衡（這有效地導致有效限制接近 1.6 到 2 MB）。 + +### 誰受益？ + +執行升級錢包的人將能夠透過將簽名移至交易的見證部分來利用增加的區塊大小。 + +## 邁向單一組合區塊限制 + +目前對區塊大小有兩個共識強制執行的限制：區塊不能大於 1MB，並且獨立地，不能在區塊中的交易之間執行超過 20,000 次簽名檢查。 + +在給定單一限制的情況下，找到要包含在區塊中的最有利可圖的交易集是背包問題的一個實例，可以用簡單的貪婪演算法輕鬆地幾乎完美地解決。然而，新增第二個約束使得在某些情況下找到好的解決方案變得非常困難，而且這個理論問題已在實踐中被利用，迫使區塊以遠低於容量的大小進行挖礦。 + +在不進行硬分叉或大幅減少區塊大小的情況下，無法解決這個問題。由於 segwit 無法修復這個問題，它選擇不使其惡化：特別是，與其為隔離見證資料引入獨立限制，不如將單一限制應用於 UTXO 資料和見證資料的加權總和，允許兩者作為組合實體同時受到限制。 + +### 誰受益？ + +如果未來的硬分叉將區塊容量限制變更為參數的單一加權總和，最終礦工將受益。例如： + + 50*sigops + 4*basedata + 1*witnessdata < 10M + +這讓礦工輕鬆準確地填充區塊，同時最大化費用收入，這將透過允許使用者更可靠地計算其交易被挖掘所需的適當費用來使使用者受益。 + +### 進一步資訊 + + * [背包問題](https://en.wikipedia.org/wiki/Knapsack_problem) + * [2015 年 8 月 bitcointalk 上的 Sigop 攻擊討論](https://bitcointalk.org/index.php?topic=1166928.0;all) + * [Gregory Maxwell 在 bitcoin-dev 上關於見證限制](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011870.html) + * [「驗證成本指標」逐字稿](http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/validation-cost-metric/) + +## 2016-10-19 更新 + +本頁的早期版本將「緊湊欺詐證明」列為 segwit 的好處。然而，如實作的那樣，segwit 並沒有使這變得更容易：無論有沒有 segwit，啟用緊湊欺詐證明及其帶來的好處的未來軟分叉都需要包含自己的承諾（例如，在 coinbase 交易中），而不是能夠擴展 segwit 使用的承諾資料。 + +先前的文字是： + +> **緊湊欺詐證明** +> +> 隨著 Bitcoin 使用者群的擴大，驗證整個區塊鏈自然變得更加昂貴。為了維持 Bitcoin 的去中心化、無需信任的特性，重要的是允許那些無法負擔驗證整個區塊鏈的人至少能夠以低成本驗證他們能夠負擔的範圍。 +> +> Segwit 透過允許未來的軟分叉擴展見證結構以包含承諾資料來改善這種情況，這將允許輕量級（SPV）客戶端強制執行共識規則，例如區塊中引入的 bitcoin 數量、區塊的大小以及區塊中使用的 sigops 數量。 +> +> **誰受益？** +> +> 欺詐證明允許 SPV 使用者幫助強制執行 Bitcoin 的共識規則，這將潛在地大大增加整個 Bitcoin 網路的安全性，並減少個別使用者可能受到攻擊的方式。 +> +> 這些欺詐證明可以作為未來軟分叉的一部分新增到見證資料結構中，它們將幫助 SPV 客戶端強制執行規則，即使是那些不使用 segwit 功能的交易。 + +## 2020-06-23 更新 + +本頁的早期版本將「輸入值的簽名」列為 segwit 的好處。 +然而，如實作的那樣，segwit 並沒有使這變得安全： +無論有沒有 segwit，都需要未來的軟分叉才能依賴簽名的輸入值。 + +由於每個輸入的值都是單獨簽名的，因此可以以欺騙性的方式操縱表面費用。 +(CVE-2020-14199) + +先前的文字是： + +> **輸入值的簽名** +> +> 當硬體錢包簽署交易時，它可以輕鬆驗證總花費金額，但只能透過擁有所有正在花費的輸入交易的完整副本來安全地確定費用，並且必須雜湊每個交易以確保它沒有被餵以虛假資料。由於單個交易的大小最大可達 1MB，因此即使被簽署的交易本身很小，這也不一定是便宜的操作。 +> +> Segwit 透過明確雜湊輸入值來解決這個問題。這意味著硬體錢包可以簡單地被給予交易雜湊、索引和值（並被告知使用了什麼公鑰），並且可以安全地簽署花費交易，無論被花費的交易有多大或多複雜。 +> +> **誰受益？** +> +> 硬體錢包的製造商和使用者是明顯的受益者；然而，這也可能使在小型嵌入式裝置中安全使用 Bitcoin 進行「物聯網」應用變得更加容易。 +> +> 此好處僅在花費發送到 segwit 啟用地址（或 segwit-via-P2SH 地址）的交易時可用。 +> +> **進一步資訊** +> +> * [BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) diff --git a/_posts/zh_TW/posts/2016-01-28-clarification.md b/_posts/zh_TW/posts/2016-01-28-clarification.md index 359b48ea7..cbec597f9 100644 --- a/_posts/zh_TW/posts/2016-01-28-clarification.md +++ b/_posts/zh_TW/posts/2016-01-28-clarification.md @@ -7,11 +7,11 @@ type: posts lang: zh_TW permalink: /zh_TW/2016/01/28/clarification/ --- -最初，bitcoin.org是用作放置[比特幣白皮書](https://bitcoin.org/bitcoin.pdf)，並成為[比特幣軟件](https://bitcoin.org/en/download)的主頁。後來，這網站提供了比特幣教育資訊，但這與現時的Bitcoin Core計劃[並無關係](https://bitcoin.org/en/bitcoin-core/about-site)。Bitcoin Core的正式網站是bitcoincore.org，而雖然其它網站仍會提供有關Bitcoin Core的資訊，他們的觀點並不代表Bitcoin Core。我們明白這可能令人感到混淆，因此我們正在努力地清楚說明這些關係。 +最初，bitcoin.org是用作放置[比特幣白皮書](https://bitcoin.org/bitcoin.pdf)，並成為[比特幣軟體](https://bitcoin.org/en/download)的主頁。後來，這網站提供了比特幣教育資訊，但這與現時的Bitcoin Core計劃[並無關係](https://bitcoin.org/en/bitcoin-core/about-site)。Bitcoin Core的正式網站是bitcoincore.org，而雖然其它網站仍會提供有關Bitcoin Core的資訊，他們的觀點並不代表Bitcoin Core。我們明白這可能令人感到混淆，因此我們正在努力地清楚說明這些關係。 在開發方面，Bitcoin Core主要使用Freenode IRC上的#bitcoin-core-dev，[Github](https://github.com/bitcoin/bitcoin)，以及[bitcoin-dev 電郵列表](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/)。 -另一方面，在網絡上有很多和比特幣有關的論壇，當中可能有Bitcoin Core的貢獻者參與，但Bitcoin Core對這些論壇的政策並不負責，並對比特幣社群應使用哪些論壇沒有正式立場。然而，我們堅信比特幣社群應該可以自由地討論和批評與比特幣相關的所有事情。 +另一方面，在網路上有很多和比特幣有關的論壇，當中可能有Bitcoin Core的貢獻者參與，但Bitcoin Core對這些論壇的政策並不負責，並對比特幣社群應使用哪些論壇沒有正式立場。然而，我們堅信比特幣社群應該可以自由地討論和批評與比特幣相關的所有事情。 -當比特幣社群在討論的時候，雖然可能會非常興奮和激烈，但我們必須保持文明的態度。社群不應該採取網絡打手，拒絕服務攻擊，以及其它會妨礙正當討論的手段。除非有其它理由，我們應該盡量假設參與討論的人都是懷著善意而來的。 +當比特幣社群在討論的時候，雖然可能會非常興奮和激烈，但我們必須保持文明的態度。社群不應該採取網路打手，拒絕服務攻擊，以及其它會妨礙正當討論的手段。除非有其它理由，我們應該盡量假設參與討論的人都是懷著善意而來的。 diff --git a/_posts/zh_TW/posts/2016-02-26-zkcp.md b/_posts/zh_TW/posts/2016-02-26-zkcp.md new file mode 100644 index 000000000..954b68486 --- /dev/null +++ b/_posts/zh_TW/posts/2016-02-26-zkcp.md @@ -0,0 +1,116 @@ +--- +type: posts +layout: post +lang: zh_TW +id: zh_TW-zkcp-announce +name: zkcp-announce +title: 首次成功的零知識或有支付 +permalink: /zh_TW/2016/02/26/zero-knowledge-contingent-payments-announcement/ +tags: [privacy, cryptography, zero-knowledge, verifiability] +version: 1 +excerpt: 在 Bitcoin 網路上首次成功的零知識或有支付公告。 +--- +我很高興宣布在 Bitcoin 網路上首次成功的零知識或有支付（ZKCP）。 + +ZKCP 是一種交易協定，允許買方使用 Bitcoin 以私密、可擴展、安全且不需要信任任何人的方式從賣方購買資訊：當且 _僅當_ 付款完成時，預期的資訊才會被轉移。買方和賣方不需要相互信任或依賴第三方的仲裁。 + +想像一下電影風格的「公事包交換」（一方拿著裝滿現金的公事包，另一方拿著裝有機密文件的公事包），但沒有其中一個箱子裝滿碎報紙以及隨之而來的精彩追逐場景的潛在情況。 + +一個示例應用是特定品牌電子書閱讀器的所有者合作從倒閉的製造商購買 DRM 主金鑰，以便在供應商的伺服器離線後可以在其閱讀器上載入自己的文件。這種類型的銷售本質上是不可逆的，可能跨越多個司法管轄區，並涉及財務穩定性不確定的各方──這意味著雙方要麼承擔很大的風險，要麼必須做出艱難的安排。使用 ZKCP 可以避免在否則容易出錯的銷售中涉及的重大交易成本。 + +在今天的交易中，我從 Zcash 團隊成員 Sean Bowe 以 0.10 BTC 的價格購買了一個 16x16 數獨謎題的解決方案，作為在巴貝多舉行的 [Financial Cryptography 2016](http://fc16.ifca.ai/) 上現場演示的一部分。我在加州遠端參與了交易。 + +轉移涉及兩筆交易： + +- [8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e][0] +- [200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae][1] + +此 ZKCP 實作背後的幾乎所有工程工作都由 Sean Bowe 完成，並得到 Pieter Wuille、我本人和 Madars Virza 的支援。 + +請參閱[現場演示](https://z.cash/zkcp3.pdf)的投影片。 + +## 背景 + +我於 2011 年在 [Bitcoin Wiki 上的一篇文章](https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment)中首次提出 ZKCP 協定，作為 Bitcoin Script 中現有基本運算已經非常強大的示例。 + +### 零知識證明 + +我的 ZKCP 協定需要一個用於任意程式的零知識證明作為構建模組。存在許多類型的專門零知識證明：常見的數位簽章就是一個例子，[機密交易][2]中的範圍證明也是如此。 + +用於 _一般計算_ 的零知識證明是一種密碼系統，它允許人們使用公共和秘密輸入的混合執行任意程式，並向其他人證明此特定程式接受了輸入，而不透露有關其操作或秘密輸入的更多資訊。 + +如果這看起來像是不可能的魔法，出於教育目的，我提出了[一個非常簡單但效率低下的 ZKP 系統][3]，它只使用布林電路和密碼雜湊，或者參見 Matthew Green 的[圖著色 ZKP 示例](http://blog.cryptographyengineering.com/2014/11/zero-knowledge-proofs-illustrated-primer.html)。 + +正如我最初關於 ZKCP 的文章所指出的，2011 年沒有這樣的系統可用，但人們相信它們是可能的，特別是在特定約束下，這些約束對 ZKCP 有效。 + +2012 年，Gennaro、Gentry、Parno 和 Raykova 發表了一篇論文（「[Quadratic Span Programs and Succinct NIZKs without PCPs](https://eprint.iacr.org/2012/215)」），描述了一種特別有效的構造。從那時起，幾個團隊繼續推進這項工作，創建編譯器、效能改進，最重要的是像 libsnark 這樣的實用工具。GGPR'12 密碼系統需要可信設定，但對於 ZKCP 應用來說，這不是真正的限制，因為買方可以執行它。由於這項工作，ZKCP 現在可以成為一個實用的工具。 + +進一步閱讀： + +- [GGPR'12 論文](https://eprint.iacr.org/2012/215) +- [Microsoft 可驗證計算小組](http://research.microsoft.com/en-us/projects/verifcomp/) +- [SCIPR Lab](http://www.scipr-lab.org/) +- [Libsnark](https://github.com/scipr-lab/libsnark) + +因為這些高效的 ZKP 是尖端技術，依賴於新的強密碼假設，它們的安全性尚未確定。但在像 ZKCP 這樣的應用中，我們唯一的替代方案是第三方信任，它們可以以比沒有它們時更嚴格改進的方式使用。 + +## ZKCP 如何運作 + +如果您接受零知識證明系統作為一個黑盒，ZKCP 協定的其餘部分相當簡單。 + +買方首先建立一個程式，可以決定給它的輸入是否是買方想要購買的資料。此程式僅驗證資訊，它不產生資訊──買方甚至不必知道如何產生它。（例如，編寫程式來驗證數獨解決方案是否正確很容易，但編寫數獨求解器更困難，數獨是 NP 完全的。這裡的買方只需要編寫解決方案驗證器。） + +買方為證明系統執行可信設定，並將產生的設定資訊傳送給賣方。 + +賣方選擇一個隨機加密金鑰並加密買方希望購買的資訊。 + +使用 ZKP 系統，賣方證明一個複合陳述： + +* Ex 是滿足買方程式的輸入的加密。 +* Y 是 Ex 的解密金鑰的 sha256 雜湊。 + +賣方將 Ex、Y、證明和他的公鑰傳送給買方。一旦買方的電腦驗證了證明，買方就知道，如果他得知產生雜湊 Y 的 SHA256 輸入，他就可以解密他的答案。 + +因此，買方最初想購買他程式的輸入，但現在他同樣樂意購買雜湊的原像。事實證明，Bitcoin 已經提供了一種以安全方式出售雜湊原像的方法。 + +買方將他的付款支付給以下 ScriptPubkey： + + OP_SHA256 + OP_EQUAL + OP_IF + + OP_ELSE + OP_CHECKLOCKTIMEVERIFY OP_DROP + + OP_ENDIF + OP_CHECKSIG + +這筆付款的效果是，賣方如果提供 Y 的雜湊原像和他的金鑰簽章，就可以收取它。為了避免永遠鎖定買方的資金，如果賣方在（例如）一天內不收取他的付款，買方可以收回付款。 + +因此，當賣方收取他的付款時，他被迫透露買方需要的資訊以解密答案。如果他不這樣做，買方會取回他的資金。 + +此 ScriptPubkey 也與用於跨鏈原子交換或閃電支付通道的相同。 + +這些交易的錢包支援已在 [PR#7601](https://github.com/bitcoin/bitcoin/pull/7601) 中為 Bitcoin Core 實作。此錢包支援由數獨 ZKCP 客戶端和伺服器使用，可在 取得。 + +買方的程式可以任意長且複雜，而不會給 Bitcoin 的區塊鏈增加任何額外負擔──唯一的影響是設定和證明所需的時間增加，這一切都發生在 Bitcoin 外部。除了買方或賣方之外，沒有人了解買方的程式（也就是說，他們不了解正在出售的資訊的性質）。 + +## 限制和替代方案 + +這種方法比在區塊鏈內執行智慧合約更具可擴展性和私密性，並且不受 Bitcoin 智慧合約中的任何效能或功能限制的阻礙。 + +這種方法有兩個主要限制。首先，它是互動式的：買方不能簡單地發出廣播報價，讓任何感興趣的賣方在沒有來回溝通的情況下接受付款。其次，ZKP 系統雖然足夠快以實用，但仍然不是很快。例如，在我們的演示中，ZKP 系統證明了 5 次 SHA256 執行和數獨約束，並且在筆記型電腦上執行大約需要 20 秒。（證明的驗證只需要幾毫秒。） + +ZKCP 的一種替代方案是 Peter Todd 2014 年的 [「paypub」協定](https://github.com/unsystem/paypub)。在 Paypub 中，買方不使用零知識證明，而是被展示他們試圖購買的資料的隨機子集，當他們收取付款時，賣方被迫解鎖其餘部分。Paypub 避免了處理零知識證明的複雜性──並且還允許交換只有人類才能驗證的資訊──但代價是對作弊的某些脆弱性，並且只能用於相對較大的隨機可驗證資訊集。 + +一般來說，我認為像這樣的「無信任」智慧合約在以下情況下最有價值：頻繁的自動化非常低價值的交易──以至於傳統衝突解決方法的開銷剝奪了參與者獲得有意義正義的機會──或對於非常高價值的交換，傳統衝突解決的速度、不可靠性（特別是跨司法管轄區）或缺乏私密性將是不可接受的。 + +隨著技術變得越來越實用，我期待人們為它們找到令人興奮的應用。 + +_Gregory Maxwell_ + + +[0]: https://mempool.space/tx/8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e +[1]: https://mempool.space/tx/200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae +[2]: https://web.archive.org/web/20191122230510/https://people.xiph.org/~greg/confidential_values.txt +[3]: https://web.archive.org/web/20190203034901/https://people.xiph.org/~greg/simple_verifyable_execution.txt diff --git a/_posts/zh_TW/posts/2016-03-15-announcelist.md b/_posts/zh_TW/posts/2016-03-15-announcelist.md new file mode 100644 index 000000000..48dd659ec --- /dev/null +++ b/_posts/zh_TW/posts/2016-03-15-announcelist.md @@ -0,0 +1,20 @@ +--- +title: 保持更新！ +permalink: /zh_TW/2016/03/15/announcement-list/ +lang: zh_TW +id: zh_TW-announce-list +name: announce-list +tags: [bitcoin, bitcoin core, announcement list, updates] +version: 2 +redirect_from: + - /zh_CN/2016/03/15/announcement-list/ +--- +為了加強溝通，我們現在為 Bitcoin Core 的使用者提供選擇性加入、_僅公告_ 資訊，以接收安全問題和新版本的通知。 + +雖然 Bitcoin Core 專案有多種溝通管道，但已有許多請求要求提供僅接收重要公告的方法。這個新來源旨在極低容量，專注於關鍵通知以及宣布新版本。 + +如果您使用 Bitcoin Core，請考慮[訂閱][subscribe]。 + +[subscribe]: /zh_TW/list/announcements/join + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2016-04-14-maintainer-appointed-marcofalke.md b/_posts/zh_TW/posts/2016-04-14-maintainer-appointed-marcofalke.md new file mode 100644 index 000000000..5efc0c1d2 --- /dev/null +++ b/_posts/zh_TW/posts/2016-04-14-maintainer-appointed-marcofalke.md @@ -0,0 +1,26 @@ +--- +title: 任命新儲存庫維護者 +name: blog-maintainer-appointed-marcofalke +id: blog-maintainer-appointed-marcofalke +lang: zh_TW +permalink: /zh_TW/blog/2016/04/14/maintainer/ +type: posts +layout: post +tags: [bitcoin, maintainer] +category: [announcements] +canonical: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-April/000003.html +version: 1 +--- +特此宣布 Marco Falke 為 Bitcoin Core 的新測試與 QA 維護者。 + +測試和 QA 一直對這個專案至關重要，隨著開發速度的加快，它變得比以往任何時候都更加關鍵。 + +Marco 在過去一年中為專案做出了出色的貢獻，特別是在測試框架和單元測試、提高覆蓋率方面，還透過檢查錢包手續費功能以及審查其他拉取請求。所以這幾乎是他一直在做的事情，考慮讓他擔任這個職位是很自然的。 + +他將監督並合併 QA 和測試框架的拉取請求，並關注測試的整體品質。 + +歡迎加入團隊，Marco！ + +此致， + +Wladimir van der Laan diff --git a/_posts/zh_TW/posts/2016-06-07-compact-blocks-faq.md b/_posts/zh_TW/posts/2016-06-07-compact-blocks-faq.md new file mode 100644 index 000000000..56637d17d --- /dev/null +++ b/_posts/zh_TW/posts/2016-06-07-compact-blocks-faq.md @@ -0,0 +1,147 @@ +--- +type: posts +layout: post +lang: zh_TW +name: compact-blocks-faq +id: zh_TW-compact-blocks-faq +title: 緊湊區塊常見問題 +permalink: /zh_TW/2016/06/07/compact-blocks-faq/ +version: 1 +categories: + - FAQ + - BIPS +tags: [compact blocks, compact block relay] +excerpt: 緊湊區塊中繼（BIP152）是一種減少傳播新區塊至全節點所需頻寬的方法。 +--- +{% include toc.html %} + +*緊湊區塊中繼*，[BIP152][]，是一種減少傳播新區塊至全節點所需頻寬的方法。 + +## 摘要 + +當全節點之間共享許多相同的記憶池內容時，可以使用簡單的技術來減少傳播新區塊所需的頻寬。對等節點向接收對等節點傳送緊湊區塊「草圖」。這些草圖包含以下資訊： + +- 新區塊的 80 位元組標頭 +- 縮短的交易識別碼（txids），其設計目的是防止阻斷服務（DoS）攻擊 +- 一些傳送對等節點預測接收對等節點尚未擁有的完整交易 + +接收對等節點接著嘗試使用收到的資訊和記憶體池中已有的交易來重建整個區塊。如果仍然缺少任何交易，它將從傳送對等節點請求這些交易。 + +這種方法的優點是，在最佳情況下，交易只需要傳送一次──即在它們最初廣播時──從而大幅減少整體頻寬。 + +此外，緊湊區塊中繼提議還提供了第二種營運模式（稱為*高頻寬模式*），接收節點要求其幾個對等節點直接傳送新區塊而不先請求許可，這可能會增加頻寬（因為兩個對等節點可能同時嘗試傳送同一個區塊），但進一步減少區塊到達高頻寬連線所需的時間（延遲）。 + +下圖顯示了節點目前傳送區塊的方式與緊湊區塊中繼的兩種營運模式的比較。節點 A 時間軸上的灰色方塊表示它正在執行驗證的期間。 + +![Compact Blocks diagram](https://raw.githubusercontent.com/bitcoin/bips/master/bip-0152/protocol-flow.png) + +- 在**傳統中繼**中，區塊經過節點 A 的驗證（灰色長條），然後向節點 B 傳送 `inv` 訊息請求傳送區塊的許可。節點 B 回覆一個對區塊的請求（`getdata`），節點 A 傳送區塊。 + +- 在**高頻寬中繼**中，節點 B 使用 `sendcmpt(1)`（傳送緊湊）告訴節點 A 它希望盡快接收區塊。當新區塊到達時，節點 A 執行一些基本驗證（例如驗證區塊標頭），然後自動開始向節點 B 傳送標頭、縮短的 txids 和預測缺失的交易（如上所述）。節點 B 嘗試重建區塊並請求它仍然缺失的任何交易（`getblocktxn`），節點 A 傳送這些交易（`blocktxn`）。在背景中，兩個節點在將區塊新增到其本機區塊鏈副本之前完成對區塊的完整驗證，保持與之前相同的全節點安全性。 + +- 在**低頻寬中繼**中，節點 B 使用 `sendcmpt(0)` 告訴節點 A 它希望盡可能減少頻寬使用。當新區塊到達時，節點 A 完全驗證它（因此它不會中繼任何無效區塊）。然後它詢問節點 B 是否想要該區塊（`inv`），這樣如果節點 B 已經從另一個對等節點接收到該區塊，它可以避免再次下載。如果節點 B 確實想要該區塊，它以緊湊模式請求它（`getdata(CMPCT)`），節點 A 傳送標頭、短 txids 和預測缺失的交易。節點 B 嘗試重建區塊，請求它仍然缺失的任何交易，節點 A 傳送這些交易。然後節點 B 正常完全驗證區塊。 + +## 一些有用的基準測試資料是什麼？ + +平均完整的 1MB 區塊公告可以由接收節點使用 9KB 的區塊草圖重建，加上接收節點記憶池中沒有的區塊中每個交易的額外開銷。見到的最大區塊草圖最高達到 20KB 以北的幾個位元組。 + +在「高頻寬」模式下執行即時實驗並讓節點預先填充最多 6 筆交易時，我們可以預期看到超過 90% 的區塊立即傳播而不需要請求任何缺失的交易。即使除了 coinbase 之外不預先填充任何交易，實驗顯示我們可以看到超過 60% 的區塊立即傳播，其餘需要完整的額外網路往返。 + +由於預熱節點的記憶池和區塊之間的差異很少超過 6 筆交易，這意味著緊湊區塊中繼實現了所需峰值頻寬的顯著減少。 + +## 如何選擇預期缺失的交易立即轉發？ + +為了減少初始實作中需要審查的內容，僅會預先傳送 coinbase 交易。 + +然而，在所描述的實驗中，傳送節點使用簡單的公式來選擇要傳送的交易：當節點 A 收到一個區塊時，它檢查哪些交易在區塊中但不在其記憶池中；這些是它預測其對等節點沒有的交易。理由是（在沒有額外資訊的情況下）你不知道的交易可能也是你的對等節點不知道的交易。使用這種基本啟發式方法，看到了很大的改進，說明許多時候最簡單的解決方案是最好的。 + +## 快速中繼網路如何與此相關？ + +[快速中繼網路](http://bitcoinrelaynetwork.org/)（FRN）由兩部分組成： + +* 目前在快速中繼網路中精選的節點集合 + +* 快速區塊中繼協定（FBRP） + +FRN 中精選的節點集合經過精心選擇，以全球最小中繼為首要優先事項。這些節點的故障將導致浪費算力的顯著增加和挖礦潛在的進一步集中化。今天絕大多數挖礦算力連線到這個網路。 + +原始的 FBRP 是參與節點如何相互通訊區塊資訊的方式。節點追蹤它們相互傳送的交易，並根據這些知識中繼區塊差異。對於一對一的伺服器-客戶端新區塊通訊，這個協定幾乎是最佳的。最近，一個基於 UDP 和前向錯誤更正（FEC）的協定，名為 RN-NextGeneration，已被部署供礦工測試和使用。然而，這些協定需要一個連線不良的中繼拓撲，並且比更通用的 p2p 網路更脆弱。使用緊湊區塊的協定層級改進將縮小精選節點網路和一般 p2p 網路之間的效能差距。p2p 網路的強韌性提升和整體區塊傳播速度將在網路未來發展中發揮作用。 + +## 這會擴展 Bitcoin 嗎？ + +此功能旨在節省節點的峰值區塊頻寬，減少可能降低終端使用者網際網路體驗的頻寬尖峰。然而，如以下影片所述，挖礦的集中化壓力在很大程度上是由於區塊傳播的延遲。緊湊區塊版本 1 主要不是為了解決該問題而設計的。 + +https://www.youtube.com/embed/Y6kibPzbrIc + +預期礦工將繼續使用[快速中繼網路](http://bitcoinrelaynetwork.org/)，直到開發出更低延遲或更強韌的解決方案。然而，對基礎 p2p 協定的改進將在 FRN 故障的情況下增加強韌性，並且可能減少私有中繼網路的優勢，使它們不值得營運。 + +此外，使用第一版緊湊區塊進行的實驗和收集的資料將為我們預期與 FRN 更具競爭力的未來改進的設計提供資訊。 + +## 誰從緊湊區塊中受益？ + +* 想要中繼交易但網際網路頻寬有限的全節點使用者。如果您只是想在仍然向對等節點中繼區塊的同時節省最多頻寬，從 Bitcoin Core v0.12 開始已經有一個 `blocksonly` 模式可用。僅區塊模式僅在交易包含在區塊中時接收交易，因此沒有額外的交易開銷。 + +* 整體網路。減少 p2p 網路上的區塊傳播時間可以創建一個更健康的網路，具有更好的基準中繼安全邊際。 + +## 編碼、測試、審查和部署緊湊區塊傳播的時程是什麼？ + +緊湊區塊的第一版已被分配 [BIP152][]，有一個工作實作，並正在由開發者社群積極測試。 + +- BIP152: +- 參考實作: + +## 如何調整這個以實現更快的 p2p 中繼？ + +可以對緊湊區塊方案進行額外的改進。這些與 RN-NG 相關，包含兩個方面： + +- 首先，用 UDP 傳輸取代區塊資訊的 TCP 傳輸。 + +- 其次，使用前向錯誤更正（FEC）代碼處理丟失的封包並預先傳送缺失的交易資料。 + +UDP 傳輸允許伺服器傳送資料並由客戶端以路徑允許的速度消化，而不用擔心間歇性丟失的封包。客戶端寧願無序接收封包以盡快構建區塊，但 TCP 不允許這樣做。 + +為了處理丟失的封包和從多個伺服器接收非冗餘區塊資料，將採用 FEC 代碼。FEC 代碼是一種將原始資料轉換為冗餘代碼的方法，只要一定百分比的封包到達其目的地就允許無損傳輸，其中所需資料僅略大於資料的原始大小。 + +這將允許節點在接收到區塊時立即開始傳送區塊，並允許接收者重建同時從多個對等節點串流的區塊。所有這些工作都繼續建立在已經完成的緊湊區塊工作之上。這是一個中期擴展，開發正在進行中。 + +## 這個想法是新的嗎？ + +使用布隆過濾器（例如 [BIP37][] filteredblocks 中使用的）來更有效地傳輸區塊的想法在幾年前就被提出了。它也由 Pieter Wuille（sipa）在 2013 年實作，但他發現開銷使傳輸速度變慢。 + +{% highlight text %} +[#bitcoin-dev, public log (excerpts)] + +[2013-12-27] +09:12 < sipa> TD: i'm working on bip37-based block propagation +[...] +10:27 < BlueMatt> sipa: bip37 doesnt really make sense for block download, no? why do you want the filtered merkle tree instead of just the hash list (since you know you want all txn anyway) +[...] +15:14 < sipa> BlueMatt: the overhead of bip37 for full match is something like 1 bit per transaction, plus maybe 20 bytes per block or so +15:14 < sipa> over just sending the txid list + +[2013-12-28] +00:11 < sipa> BlueMatt: i have a ~working bip37 block download branch, but it's buggy and seems to miss blocks and is very slow +00:15 < sipa> BlueMatt: haven't investigated, but my guess is transactions that a peer assumes we have and doesn't send again +00:15 < sipa> while they already have expired from our relay pool +[...] +00:17 < sipa> if we need to ask for missing transactions, there is an extra roundtrip, which makes it likely slower than full block download for many connections +00:18 < BlueMatt> you also cant request missing txn since they are no longer in mempool [...] +00:21 < gmaxwell> sounds like we really do need a protocol extension for this. +[...] 00:23 < sipa> gmaxwell: i don't see how to do it without extra roundtrip +00:23 < BlueMatt> send a list of txn in your mempool (or bloom filter over them or whatever)! +{% endhighlight %} + +如摘錄中所述，簡單地擴展協定以支援請求交易的個別交易雜湊以及區塊中的個別交易，最終允許緊湊區塊方案更簡單、抗 DoS 且更高效。 + +## 進一步閱讀資源 + +- +- +- +- +- +- +- +- + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2016-06-08-version-bits-miners.md b/_posts/zh_TW/posts/2016-06-08-version-bits-miners.md new file mode 100644 index 000000000..728747d66 --- /dev/null +++ b/_posts/zh_TW/posts/2016-06-08-version-bits-miners.md @@ -0,0 +1,100 @@ +--- +type: posts +layout: post +lang: zh_TW +name: version-bits-faq-miners +id: zh_TW-version-bits-faq-miners +title: 礦工版本位元常見問題 +permalink: /zh_TW/2016/06/08/version-bits-miners-faq/ +categories: [FAQ, mining] +tags: [soft fork, soft forks, bip9, version bits, mining] +version: 1 +excerpt: 「版本位元」BIP9 系統是一種向 Bitcoin 共識規則引入向後相容規則變更的方法，稱為軟分叉。 +--- +{% include toc.html %} + +## 什麼是 _版本位元_ BIP9？ + +_版本位元_ [BIP9][] 系統是一種向 Bitcoin 共識規則引入向後相容規則變更的方法，稱為軟分叉。 + +_版本位元_ 允許礦工發出訊號表示他們可以驗證軟分叉規則。它還允許同時提出最多 29 個軟分叉。 + +## _版本位元_ 如何啟動？ + +_版本位元_ 不需要啟動，它只是礦工透過在區塊標頭 nVersion 欄位中設定位元來發出對軟分叉準備就緒訊號的一種方式。 + +## 什麼是軟分叉超時？ + +軟分叉有一個開始時間和一個 _超時時間_，在此期間提案是活躍的。軟分叉只能在 _開始時間_ 和 _超時時間_ 之間啟動。如果軟分叉在 _超時時間_ 之前未被啟動，軟分叉提案失敗，即使發出訊號也不會啟動。 + +## 啟動工作流程是什麼？ + +在 _版本位元_ 下，軟分叉提案經歷一個工作流程： + +- `[DEFINED]` -> `[STARTED]` -> `[LOCKED_IN]` -> `[ACTIVE]` + +或 + +- `[DEFINED]` -> `[STARTED]` -> `[FAILED]` + +![version bits state diagram](https://raw.githubusercontent.com/bitcoin/bips/master/bip-0009/states.png) + +Bitcoin 網路每 2016 個區塊重新定向挖礦難度；此時 _版本位元_ 將查看前 2016 個區塊的視窗，以查看有多少區塊為給定的軟分叉發出訊號。如果 95% 的區塊發出軟分叉準備就緒的訊號，狀態將從 `[STARTED]` 變更為 `[LOCKED_IN]`。 + +在 `[LOCKED_IN]` 之後，規則將在再一次難度重新定向後啟動，即再 2016 個區塊。節點軟體將警告升級正在等待中。 + +## 什麼是版本位元？ + +當沒有軟分叉發出訊號時，礦工應將區塊版本欄位設定為 `0x20000000`。 + +## 礦工何時應該設定位元？ + +要為軟分叉發出準備就緒訊號，礦工應將相關版本位元與 `0x20000000` 一起設定。這應該只在軟分叉的 _開始時間_ 之後執行。 + +如果軟分叉啟動或達到 `[FAILED]` 狀態，應取消設定位元。 + +例如： + +「alice」軟分叉使用位元 0，即 `0x1` + `0x20000000` + +|0|0|1|0|0| ... |0|0|0|0|0|0|0|0|0|1| + +「bob」軟分叉使用位元 1，即 `0x2` + `0x20000000` + +|0|0|1|0|0| ... |0|0|0|0|0|0|0|0|1|0| + +要同時為兩個軟分叉發出訊號，使用 `0x20000003`（即 `0x1` + `0x2` + `0x20000000`*） + +|0|0|1|0|0| ... |0|0|0|0|0|0|0|0|1|1| + +* 注意，如果其中一個在另一個之前啟動，您必須取消設定相關位元並繼續為另一個發出訊號。如果一個未能啟動且超時到期，您也應該取消設定該位元。 + +## 它與 ISM 軟分叉有何不同？ + +IsSuperMajority() 或簡稱 ISM，是一種傳統的軟分叉觸發器，一旦 1000 個區塊中有 950 個挖出發出新區塊版本訊號的區塊，就會啟動新規則。 + +1. IsSuperMajority() 軟分叉將在啟動後孤立所有具有先前版本的區塊。例如，如果當前版本是 4，而下一個軟分叉引入版本 5 區塊，那麼在達到啟動（950/1000 個區塊）後，節點將拒絕所有版本 4 區塊。 + +2. 一旦 _版本位元_ 軟分叉達到啟動，節點將簡單地開始強制執行新規則，並且不會孤立非發出訊號的區塊，_除非_ 它違反新規則。 + +3. ISM() 在滾動基礎上查看前 1000 個區塊；_版本位元_ 在每次挖礦難度重新定向時查看前 2016 個區塊一次。 + +4. ISM() 軟分叉不會過期。_版本位元_ 軟分叉只能在 _開始時間_ 和 _超時時間_ 之間啟動。 + +## 礦工必須升級嗎？ + +不。[BIP9][] 軟分叉不會啟動，除非 95% 的礦工發出準備就緒訊號。如果軟分叉達到 `[LOCKED_IN]` 狀態，絕大多數礦工已準備好進行變更，剩餘的礦工應該在下一次難度重新定向（大約 2 週）_之前_ 升級。 + +未升級的礦工如果無法驗證新啟動的規則，則有產生無效區塊的風險，這些區塊將被孤立。 + +## 誰為不同的升級提案分配版本位元？ + +軟分叉透過 [BIPs 流程][BIP1] 提出。活躍的 [BIP9][] 軟分叉提案列在[分配頁面](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#deployments)上。 + +## 進一步閱讀 + +- +- +- + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2016-06-21-csv-softfork-instructions.md b/_posts/zh_TW/posts/2016-06-21-csv-softfork-instructions.md index 959bfeae5..44bf80d2d 100644 --- a/_posts/zh_TW/posts/2016-06-21-csv-softfork-instructions.md +++ b/_posts/zh_TW/posts/2016-06-21-csv-softfork-instructions.md @@ -19,7 +19,7 @@ excerpt: 比特幣的共識規則現正有一項軟分叉進行中，雖然一 摘要 -1. 你必須在區塊419328號產出以前，檢查你的所有節點，確保皆已升級至 Bitcoin Core 0.12.1 或相容軟件。 +1. 你必須在區塊419328號產出以前，檢查你的所有節點，確保皆已升級至 Bitcoin Core 0.12.1 或相容軟體。 2. 如果你正在手動設定區塊版本號，你必在區塊419328號產出以前把版本號的0號位元去除。最好的做法是由 bitcoind 自動設定。 @@ -33,15 +33,15 @@ excerpt: 比特幣的共識規則現正有一項軟分叉進行中，雖然一 ## 所有礦工請留意 -在寬限期內，所有礦工必須升級至 Bitcoin Core 0.12.1 或任何支持 CSV 軟分叉的相容軟件。實際上，在編寫本文的時間，Bitcoin Core 0.12.1 是唯一支持 CSV 軟分叉的版本。礦工必須再三確認所有負責挖礦的節點以及備用節點皆已升級。 +在寬限期內，所有礦工必須升級至 Bitcoin Core 0.12.1 或任何支持 CSV 軟分叉的相容軟體。實際上，在編寫本文的時間，Bitcoin Core 0.12.1 是唯一支持 CSV 軟分叉的版本。礦工必須再三確認所有負責挖礦的節點以及備用節點皆已升級。 不依從以上指引者可能會產出無效區塊，或會延長無效的區塊鏈，造成區塊鏈分叉，令有關礦工和廣大比特幣使用者蒙受經濟損失。 ## 手動設定區塊版本號的礦工請注意 -Bitcoin Core 的默認設定會自動按 BIP9 的要求設定區塊版本，然而我們留意到有些礦工會手動設定區塊版本號，我們強烈建議不要手動設定區塊版本號，因為這會對比特幣系統帶來風險。 +Bitcoin Core 的預設設定會自動按 BIP9 的要求設定區塊版本，然而我們留意到有些礦工會手動設定區塊版本號，我們強烈建議不要手動設定區塊版本號，因為這會對比特幣系統帶來風險。 -如果有礦工設定了一個版本編號，卻沒有實施對應的規則，便可能會產出無效區塊，並會延長無效的區塊鏈。簡單而言，不使用由 bitcoind 提供的默認版本值，可能會令版本編號與實際運作的規則不相符。 +如果有礦工設定了一個版本編號，卻沒有實施對應的規則，便可能會產出無效區塊，並會延長無效的區塊鏈。簡單而言，不使用由 bitcoind 提供的預設版本值，可能會令版本編號與實際運作的規則不相符。 和 BIP33/66/65 所使用的 IsSuperMajority 軟分叉不同，在 BIP9 的設計中，沒有區塊會因為不當版本號而被視作無效（根據 BIP65，最低有效版本號為4）。因此，礦工並無誘因去手動設定區塊版本號，因為這只會帶來不必要的維護工作與人為出錯的風險。 @@ -61,7 +61,7 @@ Bitcoin Core 的默認設定會自動按 BIP9 的要求設定區塊版本，然 不依從以上指引者可能會產出無效區塊，造成區塊鏈分叉，令有關礦工和廣大比特幣使用者蒙受經濟損失。 -使用 bitcoind 提供的默認 Coinbase 交易 nSequence 和 nVersion 值的礦工無需採取任何行動。 +使用 bitcoind 提供的預設 Coinbase 交易 nSequence 和 nVersion 值的礦工無需採取任何行動。 ## 使用或手動設定 Coinbase 交易內 nLockTime 參數的礦工請注意 @@ -73,7 +73,7 @@ Bitcoin Core 的默認設定會自動按 BIP9 的要求設定區塊版本，然 不依從以上指引者可能會產出無效區塊，造成區塊鏈分叉，令有關礦工和廣大比特幣使用者蒙受經濟損失。 -使用 bitcoind 提供的默認 Coinbase 交易 nLockTime 值的礦工無需採取任何行動。 +使用 bitcoind 提供的預設 Coinbase 交易 nLockTime 值的礦工無需採取任何行動。 [1]: /en/contact/ [2]: /en/2016/06/08/version-bits-miners-faq/#when-should-miners-set-bits diff --git a/_posts/zh_TW/posts/2016-06-24-segwit-next-steps.md b/_posts/zh_TW/posts/2016-06-24-segwit-next-steps.md new file mode 100644 index 000000000..52981483b --- /dev/null +++ b/_posts/zh_TW/posts/2016-06-24-segwit-next-steps.md @@ -0,0 +1,166 @@ +--- +type: posts +layout: post +lang: zh_TW +name: segwit-next-steps +id: zh_TW-segwit-next-steps +title: "隔離見證：下一步" +permalink: /zh_TW/2016/06/24/segwit-next-steps/ +categories: [mining] +tags: [soft fork, soft forks, bip9, version bits, mining, segwit] +version: 1 +excerpt: 隔離見證（segwit）即將發布。本文提供一些背景資訊、關於如何測試 segwit 的詳細資訊、關於升級預期如何進行的資訊，以及 segwit 使實作變得更容易的一些未來功能的描述。 +--- +{% include toc.html %} +{% include references.md %} + +{{page.excerpt}} + +## 背景 + +[Segwit][segwit faq] 是一個提案，允許生產交易的軟體將交易簽名（見證）與交易中的其餘資料分離（隔離），並允許礦工將這些見證放置在傳統區塊結構之外。這提供了兩個直接好處： + +1. **消除可塑性**：隔離見證允許接收交易的現有軟體和升級軟體在不參照見證的情況下計算使用 segwit 的交易的交易識別碼（txid）。這解決了所有已知的不需要的第三方交易可塑性情況，這是一個使 Bitcoin 錢包軟體程式設計更加困難的問題，並嚴重複雜化了 Bitcoin 智慧合約的設計。 + +2. **容量增加**：將見證資料移至傳統區塊結構之外（但仍在新式區塊結構內）意味著新式區塊可以容納比舊式區塊更多的資料，允許交易資料量的適度增加。 + +Segwit 還簡化了向 Bitcoin 新增新功能的能力，並提高了完整節點的效率，這提供了長期好處，將在本文件後面更詳細地描述。 + +有關 segwit 的更多資訊，請參閱[我們的 FAQ][segwit faq] 或 BIP [141][BIP141]、[143][BIP143] 和 [144][BIP144]。 + +[segwit faq]: /zh_TW/2016/01/26/segwit-benefits/ + +## 如何測試 segwit + +Segwit 變更了 Bitcoin 系統的幾個部分，最值得注意的是完整驗證節點用來就 Bitcoin 帳本狀態達成一致的共識規則。如果節點停止就帳本狀態達成一致，那麼接收新的 Bitcoin 交易就變得不安全，因此 Bitcoin 開發者應該謹慎進行任何此類變更，並對任何此類提議的變更進行廣泛的測試。 + +同樣重要的是用於中繼區塊和交易的點對點網路程式碼的變更。由於 segwit 交易和區塊的組織方式與早期交易和區塊版本不同，因此確保網路實作既可以向 segwit 節點中繼 segwit 資料，也可以向舊節點中繼舊式資料很重要。 + +這些對共識規則和 P2P 網路程式碼的組合變更包含 1,486 行新增或修改的程式碼。segwit 補丁還包括單元和整合測試中的額外 3,338 行新增或修改的程式碼，這些測試有助於確保 segwit 在 Bitcoin Core 程式的每次完整建置時都能按預期運作。 + +除了超過 3,000 行新增的自動化測試程式碼外，segwit 還經過 Bitcoin 開發者的廣泛測試。本節僅描述他們在過去一年對不同版本的 segwit 進行的一些嚴格測試。 + +- Segwit 最初由 Pieter Wuille 和其他幾位 Blockstream 開發者在 2015 年 4 月至 6 月在 [Elements Project][] 側鏈上實作，作為不打算與先前 Bitcoin 軟體相容的「從頭開始」版本。這個版本已用於基於 Elements 的側鏈上的每一筆交易。 + +- 2015 年 10 月下旬，Luke Dashjr [描述了][luke-jr sfsw]一種允許在 Bitcoin 中將 segwit 作為軟分叉實作的方法，Wuille 利用他在 Elements 版本方面的經驗開始開發這個新的實作，該實作與所有現有 Bitcoin 軟體向後相容（儘管程式確實需要升級才能完全理解 segwit）。 + +- 程式碼在 2015 年 12 月下旬在特殊的 segwit 專用測試網（稱為 segnet）上完全運作，允許實作者和測試者在多使用者環境中執行程式碼，也允許錢包作者測試他們生成 segwit 交易的程式碼。Segnet 經歷了幾次迭代，因為發現並修復了問題，並發現和實作了改進。 + +- 2016 年 4 月，經過四個月的積極開發和測試後，Wuille 向 Bitcoin Core 專案提交了一個[拉取請求][PR#7910]以供審查。 + +- 2016 年 5 月，Segwit 在 Bitcoin 的常規測試網上啟用，在那裡它不僅針對預期與 segwit 互動的其他軟體進行測試，還針對在 Bitcoin 測試網上定期測試且尚未為 segwit 升級的所有其他程式進行測試。 + +- 同樣在 2016 年 5 月，二十位 Bitcoin Core 開發者[在瑞士會面][may2016 core meetup]進行（除其他事項外）segwit 程式碼的面對面審查，並確保測試覆蓋率足夠。 + +- 2016 年 6 月，在對原始拉取請求進行了近兩個月的非常積極的審查以及在 segnet 和測試網上的擴展運作後，Wuille 建立了一個[第二個拉取請求][PR#8149]，其中包含對原始拉取請求進行的所有改進，重新基於 Bitcoin Core 開發分支的最新版本，並專門格式化以使最終審查變得容易，並確保對原始拉取請求進行的所有審查保持有效。 + +隨著 segwit 的原始側鏈實作在過去一年中被許多審查者使用，Bitcoin 軟分叉實作在六個月內獲得嚴格的測試和審查，Bitcoin Core 開發者相信它現在已準備好投入生產。 + +[PR#8149]: https://github.com/bitcoin/bitcoin/pull/8149 +[PR#7910]: https://github.com/bitcoin/bitcoin/pull/7910 +[may2016 core meetup]: /logs/2016-05-zurich-meeting-notes.html +[luke-jr sfsw]: https://botbot.me/freenode/bitcoin-core-dev/2015-10-21/ +[elements project]: http://elementsproject.org/ + +## 緊湊區塊 + +Segwit 將允許 Bitcoin 礦工在他們建立的區塊中包含比現在更多的交易資料。這將增加中繼所有這些資料的 Bitcoin 完整節點的頻寬需求，並增加新區塊發布和節點接收之間的延遲（因為較大的資料量通常需要更長的時間來傳播）。為了幫助減少這些負面副作用，Bitcoin Core 開發者計劃為 Bitcoin Core 0.13 及更高版本提供[緊湊區塊中繼](/zh_TW/2016/06/07/compact-blocks-faq/)。 + +Bitcoin 完整節點目前下載許多交易兩次：一次是當它們單獨接收交易時，第二次是當交易作為區塊的一部分接收時。緊湊區塊中繼可以透過僅向節點發送它們使用已接收的交易重建區塊所需的資訊來消除大部分（有時是全部）這種重複。 + +在樂觀情況下，這將節點使用的頻寬減少了近一半。由於 segwit 預期將最大容量增加到大約兩倍，這兩個改進大致相互平衡，使節點頻寬使用保持在大致與現在相同的水平。 + +更重要的是，緊湊區塊中繼有助於減少峰值頻寬負載。目前，必須一次下載大約 1 兆位元組的新接收區塊；當部署 segwit 時，這意味著可能需要下載 2 兆位元組或更大的區塊。在除最快的連接之外的所有連接上，這些頻寬峰值會損害使用者同時執行的其他服務的效能，例如遊戲或影片串流。使用緊湊區塊，使用者可以以穩定的流接收交易，然後使用區塊的小描述重建每個區塊，消除了給許多使用者帶來不便的頻寬峰值。 + +最後，透過減少宣布新區塊時需要發送的資料量，緊湊區塊中繼還實現了更好的區塊傳播速度。緊湊區塊中繼透過支援兩種運作模式來特別利用這一點，一種低頻寬模式針對減少頻寬進行了最佳化（儘管在大多數情況下它也提高了速度），一種高頻寬模式顯著提高了速度，並且仍然設法透過僅需要比低頻寬模式平均多 20 千位元組來大大減少峰值頻寬使用。 + +高頻寬模式被用作點對點區塊中繼最佳化的進一步開發的基礎。它特別適用於需要盡快接收區塊的礦工（特別是如果其他非點對點區塊中繼方法失敗），但具有額外頻寬的使用者也可以啟用此模式，以幫助更快地向礦工中繼區塊，並透過使哪些高頻寬節點由礦工執行和哪些由普通對等方執行變得不那麼明顯來幫助阻止拒絕服務攻擊。 + +## 部署計劃 + +以下計劃描述了 segwit 預期的部署方式。 + +**合併到 master（不含主網啟動程式碼）**：在 Bitcoin Core 開發者「ACK」（批准）最終 segwit 拉取請求後，它將被合併到 Bitcoin Core master Git 儲存庫分支中。正在合併的程式碼將包含 segwit 中的所有內容，除了啟動程式碼。這將使開發者可以輕鬆地在 segwit 之上測試其他功能，例如緊湊區塊。**測試網上的啟動**已經發生，因此使用者和開發者可以在測試網上實驗和測試 segwit。 + +**回移到 0.12 分支**：未啟動的程式碼將回移到 0.12 維護分支，回移將獲得自己的測試。 + +**選擇 BIP9 參數**：[BIP9][] 是一種軟分叉部署機制，允許礦工發出他們準備好強制執行新共識規則的訊號。使用 BIP9 進行的每個軟分叉選擇礦工何時可以開始為軟分叉發出訊號，如果沒有足夠的礦工為其發出訊號則何時認為軟分叉不成功，以及區塊標頭版本欄位中的哪個位元將由礦工用於發出他們的準備訊號。這些參數將在此時選擇並與在 master 和 0.12 分支上啟動 segwit 的程式碼一起實作。 + +**候選版本階段**：在所有開發者測試成功完成後，將向願意測試程式碼的任何人公開提供候選版本（可能命名為 0.12.2RC1）。特別鼓勵礦工、商家和錢包供應商進行測試。如果發現任何問題，將進行修復並發布新的候選版本。這將根據需要重複，直到找到沒有已知問題的候選版本。 + +**二進位發布**：最終候選版本將其版本變更為最終發布版本（預期為 0.12.2），並將發布供所有使用者閒暇下載和開始執行（segwit 是軟分叉，因此僅當他們計劃使用 segwit 功能時才需要升級）。 + +**礦工升級**：選擇升級到 0.12.2 的礦工將能夠在達到定義為 segwit 的 BIP9 開始日期後開始生成發出準備強制執行 segwit 訊號的區塊。 + +**鎖定**：一旦在 2,016 個區塊長的重新定向期間中有 95% 的區塊發出其礦工準備好強制執行 segwit 的訊號，segwit 將鎖定 -- 這意味著除非此時區塊鏈回滾，否則 segwit 將變為活躍（見下一點）。 + +**啟動**：segwit 鎖定後 2,016 個區塊（約兩週）後，它將啟動。這意味著所有執行 segwit 感知程式碼的完整節點將開始要求礦工強制執行新的 segwit 共識規則。 + +**錢包升級**：與 2012 年的 P2SH 軟分叉類似，在 segwit 啟動後，錢包立即升級以支援 segwit 並不安全。那是因為來自 segwit 交易的花費對舊節點來說看起來像不安全的交易，所以如果 segwit 啟動後不久區塊鏈被分叉，這些花費可能會被放置在不受 segwit 規則約束的較早區塊中。因此，建議錢包在 segwit 啟動後幾週內避免升級。允許額外時間過去為錢包使用者提供了額外的安全性，儘管任何想要用他們可以承受損失的少量錢進行測試的人都可以在 segwit 啟動後立即開始花費。使用者也可以使用測試網或 regtest 立即開始測試提議的 segwit 程式碼或（可用時）任何包含 segwit 的版本。 + +## segwit 將如何影響您 + +- **礦工**選擇執行 segwit 將有責任確保他們準備好透過將其完整驗證節點升級到 segwit 強制執行程式碼來強制執行它。當他們完成此操作並執行他們認為謹慎的任何測試時，他們可以開始發出支援 segwit 的訊號。 + +- **完整節點運營商**可以繼續使用他們現有的節點，但建議他們升級到 segwit 強制執行版本。如果任何礦工最終在 segwit 啟動後根據 segwit 規則生成無效的區塊，升級的完整節點將自動拒絕這些區塊，確保這些升級的完整節點使用者看到準確的確認計數。 + + 對於任何接受低確認數交易的人（例如企業）來說，此升級特別重要。 + +- **Bitcoin Core 錢包使用者**可以繼續使用他們現有的節點。即使您升級，除了上述變更外，您也不會看到任何變更。預期在 0.12.2 中發布的程式碼預設不會開始生成 segwit 接收地址。 + +- **其他錢包的使用者**可以繼續使用他們現有的錢包。建議輕量級錢包使用者在接收大量金錢時總是等待幾次確認，因此這裡不預期需要額外的等待。 + + 當您有機會升級到支援 segwit 的錢包版本時，您可能會發現當您花費升級到 segwit 後收到的 bitcoin 時，您必須支付的交易費用稍低，因為見證是外部的，因此交易大小被計為較小。 + +## segwit 使未來升級更容易 + +Segwit 是改善 Bitcoin 系統運作的重要一步。除了上述第三方可塑性修復和容量增加外，它還提供了一種機制，允許更輕鬆地升級 Bitcoin 的腳本語言。 + +自 Bitcoin 0.3.6 以來，腳本語言一直支援十個特殊的 NOP 操作碼，其行為可以在以後的版本中以某些方式重新定義。這十個特殊 NOP 操作碼中的兩個已經用於向系統新增新功能：NOP2 根據 [BIP65][] 變更為 `OP_CHECKLOCKTIMEVERIFY` (CLTV)，NOP3 根據 [BIP112][] 變更為 `OP_CHECKSEQUENCEVERIFY` (CSV)。 + +這些操作需要非常仔細地實作以保留舊節點使用的 NOP 語義，這限制了軟分叉可以做什麼，並可能使以這種方式新增功能變得有點混亂。例如，因為 CLTV 和 CSV 都接受參數，所以每次使用它們時，還必須使用 `OP_DROP` 操作碼以保持與它們原始 NOP 行為的相容性。這使得使用它們編寫和閱讀腳本都變得更加困難。 + +Segwit 透過允許 segwit 使用者指定要使用的 Bitcoin 腳本語言的版本來消除所有這些問題。每個版本可以是早期版本的小改進，也可以是完全新的語言 -- 而且多個版本可以共存在一起，允許個別使用者指定他們想要用於保護其交易的版本。 + +例如，segwit 隨附了對 `OP_CHECKSIG`、`OP_CHECKMULTISIG` 和相關簽名檢查操作碼的改進，消除了可以透過這些操作碼利用的已知拒絕服務漏洞向量。這不是對該問題的完整解決方案，因為 CHECKSIG 操作碼的先前版本仍可用於非 segwit 交易，但它確實有助於使 segwit 交易比非 segwit 交易更難以濫用。 + +以下描述了使用此機制進行未來升級的一些想法： + +### Schnorr 簽名 + +Bitcoin 使用橢圓曲線數位簽名演算法（ECDSA）。有一種更簡單的數位簽名演算法也使用橢圓曲線，但在 Bitcoin 最初發布前不久之前一直受專利保護。這種演算法稱為 [Schnorr][]，它支援 Bitcoin 使用的 ECDSA 中的所有功能，包括建立安全簽名的能力以及建立 HD 錢包的能力。 + +Schnorr 簽名已經在 Bitcoin 之外使用。例如，著名的 [Ed25519 簽名方案][] 基於 Schnorr。 + +Schnorr 簽名的驗證比 ECDSA 簽名稍快（這使得執行完整節點更方便），並且簽名可以做得更小，因為目前用於 ECDSA 簽名的 DER 編碼不需要用於 Schnorr（提供適度的容量增加）。 + +Schnorr 還允許在所有參與者需要簽名的情況下（例如 2-of-2、3-of-3 或任何 n-of-n）進行「原生多重簽名」，允許將所有 *n* 個公鑰組合成單個總體公鑰，並將所有 *n* 個簽名組合成單個總體簽名。總體公鑰和簽名的大小與單個原始公鑰和簽名的大小相同，因此可以建立與 1-of-1 交易大小相同的 100-of-100 多重簽名交易。這將非常有用，因為預期網路將看到 n-of-n 多重簽名交易的使用增加（例如，2-of-2 用於許多支付通道交易）。 + +Schnorr 支援已經在 Bitcoin Core 用於建立和驗證簽名的 [libsecp256k1][] 程式庫中可用，儘管 Bitcoin 目前不以任何方式使用 Schnorr，並且開發者希望在開始使用它之前對程式庫的 Schnorr 部分進行一些變更。這與 segwit 對 Bitcoin 腳本版本控制的支援相結合，應該使新增上述功能變得相當容易。 + +Schnorr 支援的一個更難新增的功能是[簽名聚合][]。這將變更簽名驗證的工作方式，並允許需要 1-of-2、2-of-3 或任何 m-of-n 簽名的多重簽名交易僅為每個交易建立一個簽名，前提是所有簽名者同時線上。這還允許為每個交易建立一個簽名，無論它有多少輸入（同樣，如果所有簽名者同時線上）。 + +由於簽名通常是交易的最大單個部分，並且許多交易有兩個或更多輸入，每個輸入至少需要一個簽名，這將顯著減少許多交易的大小，並加快驗證速度（因為總共只需要驗證一個簽名，而不是每個輸入一個簽名）。 + +一旦實作，簽名聚合可以與 coinjoin 隱私增強技術結合，為使用 coinjoin 花費您的 bitcoin 建立顯著的財務激勵。目前，使用 coinjoin 有輕微的財務激勵，因為將來自不同人的多個個別交易組合在一起的 coinjoin 交易比所有這些個別交易的總大小稍小。使用簽名聚合，組合交易將顯著更小，因為它只需要一個簽名而不是許多簽名。 + +儘管簽名聚合仍在設計中，但使用 segwit 對不同版本的 Bitcoin 腳本評估語言的支援將很容易為協定新增對它的支援。 + +[schnorr]: https://en.wikipedia.org/wiki/Schnorr_signature +[ed25519 簽名方案]: http://ed25519.cr.yp.to/ +[libsecp256k1]: https://github.com/bitcoin-core/secp256k1 +[簽名聚合]: https://bitcointalk.org/index.php?topic=1377298.0 + +### MAST + +[Merkelized Abstract Syntax Trees][BIP114] (MAST) 允許[建立 Bitcoin 腳本][todd mast]具有許多不同的條件，但可能只允許將相對少量的資料放入交易中。 + +它們的工作方式是取一個程式並將其每個條件部分拆分為單獨的片段，然後將這些片段中的每一個放入默克爾樹中。Bitcoin 被花費（encumbered）到默克爾樹的默克爾根。 + +需要用於最終驗證的最小條件集可以透露給所有完整驗證節點，但不執行的程式碼可以由簡單的雜湊替換，作為部分默克爾分支的一部分，允許腳本的所有部分連接到 encumbrance 中使用的默克爾根，以便可以完成驗證。 + +這不僅節省空間，而且還可能有助於改善隱私。例如，如果 Alice 希望能夠每天正常花費她的 bitcoin，但也希望她的遺產律師 Bob 能夠在它們閒置一年後花費她的 bitcoin，她可以將這兩個條件放在不同的分支中。當 Alice 進行正常花費時，沒有人可以僅透過查看交易來看到第二個條件是什麼。 + +可以使用 segwit 啟用的 Bitcoin 腳本版本控制來啟用 MAST。 + +[todd mast]: https://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327 diff --git a/_posts/zh_TW/posts/2016-10-28-segwit-costs.md b/_posts/zh_TW/posts/2016-10-28-segwit-costs.md new file mode 100644 index 000000000..57b41ddf3 --- /dev/null +++ b/_posts/zh_TW/posts/2016-10-28-segwit-costs.md @@ -0,0 +1,307 @@ +--- +title: 隔離見證的成本與風險 +name: segwit-costs +id: zh_TW-segwit-costs +lang: zh_TW +permalink: /zh_TW/2016/10/28/segwit-costs/ +type: posts +layout: post +version: 1 +excerpt: 總結部署隔離見證可能產生的一些成本和預期風險。 +--- +{% include toc.html %} +{% include references.md %} + +## 簡介 + +本文是先前關於[隔離見證好處](/zh_TW/2016/01/26/segwit-benefits/)文章的補充，概述了透過 [BIP141][] 啟動隔離見證可能產生的技術成本和風險。 + +### 目的 + +在本文中，我們將使用*成本*來描述如果部署和啟動 segwit 一定會發生的負面結果，使用*風險*來描述可能不會發生的負面影響，或並非每個人都認為是負面的變更。 + +在分析風險時，我們考慮為*避免*風險而採取的步驟（即最小化其發生的機會），以及為*減輕*風險而採取的步驟（即如果確實發生，如何最小化負面影響）。 + +本文不嘗試就好處是否超過成本或是否應該部署或啟動 segwit 得出結論，而是透過提供背景資訊來協助利害關係人做出明智的決策。 + +## 序列化成本 + +交易和區塊資訊序列化有三個主要目的： + + 1. 跨點對點網路傳輸； + + 2. 將區塊鏈儲存在磁碟上；以及 + + 3. 評估區塊限制。 + +Segwit 以兩種方式影響序列化： + + * 見證承諾包含在 coinbase 交易中，新增 38 到 47 位元組，約為區塊的 0.005%。（參見 [BIP 141 - 承諾結構](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure)） + + * 定義了一個包含隔離見證資料的新交易序列化（參見 [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_ID) 或 [BIP 144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#Serialization)）。這為每個交易新增了 2 位元組的額外負擔，以允許輕鬆區分序列化格式，並為每個輸入的見證項目計數新增了 1 位元組的額外負擔。這些結合起來約為每個交易的 1%。 + +segwit 交易格式（參見 [BIP 141 - 見證程式](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program)）在序列化時有以下影響： + + * 與 P2PKH 相比，P2WPKH 在 scriptPubKey 中使用*更少* 3 位元組（-1%），見證位元組數量與 P2PKH scriptSig 相同。 + + * 與 P2SH 相比，P2WSH 在 scriptPubKey 中使用額外 11 位元組（6%），見證位元組數量與 P2SH scriptSig 相同。 + + * 與 P2PKH 相比，P2WPKH/P2SH 使用額外 21 位元組（11%），因為在 scriptPubKey 中使用 24 位元組，在 scriptSig 中比 P2PKH scriptPubKey 少 3 位元組，見證位元組數量與 P2PKH scriptSig 相同。 + + * 與 P2SH 相比，P2WSH/P2SH 使用額外 35 位元組（19%），因為在 scriptPubKey 中使用 24 位元組，在 scriptSig 中比 P2SH scriptPubKey 多 11 位元組，見證位元組數量與 P2SH scriptSig 相同。 + +上述百分比基於具有一個輸入和一個輸出的 180 位元組交易。隨著輸入/輸出數量的增加，這些比例大致保持不變，但如果使用更複雜的交易腳本（例如多重簽名），則會減少。 + +### 理由 + +交易大小額外負擔是由於兩個因素： + + 1. P2WSH 使用 256 位元雜湊而不是 P2SH 的 160 位元雜湊；以及 + 2. 透過 P2SH 編碼，以便不支援 segwit 的舊錢包可以發送可以使用 segwit 花費的資金，允許接收者獲得 segwit 的好處。 + +沒有這兩個因素，額外負擔在 P2WPKH 的 -3 位元組和 P2WSH 的 +1 位元組時可以忽略不計。 + +第一個因素背後的動機在[透過 pay-to-script-hash (P2SH) 增加多重簽名的安全性](/zh_TW/2016/01/26/segwit-benefits/#透過-pay-to-script-hash-p2sh-增加多重簽名的安全性)下討論。 + +第二個因素是個別使用者在發布接收地址時可以做出的權衡，選擇 P2WPKH/P2SH 或 P2WSH/P2SH 的使用者將按額外負擔的比例支付更高的費用。這應該會在長期內自然限制這種額外負擔的影響。 + +### 未來減少 + +透過變更網路和儲存序列化格式，可以使這種額外負擔的大部分消失：完整序列化可以從指示正在使用哪種格式的簡單標誌（P2PKH、P2WPKH、P2WPKH/P2SH 等）以及實際資料（公鑰和簽名）中恢復。（例如，[compacted_txn.txt](https://people.xiph.org/~greg/compacted_txn.txt)） + +## 區塊驗證成本 + +使用 segwit，在驗證區塊時引入了額外的處理，以檢查見證默克爾樹和處理 P2SH 編碼的見證交易。這需要每個交易大約五個額外的 SHA256 雜湊，每個 P2SH 編碼的 P2WSH 輸入一個額外的 SHA256，每個 P2SH 編碼的 P2WPKH 輸出一個額外的 HASH160。然而，這僅相當於對最多 4MB 資料進行大約六次 SHA256 執行，或總共大約 24MB 的 SHA256 資料，這在 Raspberry Pi v1 上應該轉化為每個區塊最多額外 15 秒，或在更強大的硬體上不到 1/10 秒。 + +## 引入錯誤的風險 + +segwit 補丁集是對 Bitcoin 的重大變更，並在 Bitcoin Core 0.13.0 中推出，儘管未在主 Bitcoin 網路上啟動。任何這樣的重大變更都會帶來各種風險，包括： + + * 徹底的錯誤：設計或實作中可能犯錯誤，產生意外或有害的結果。例如 [PR#8525](https://github.com/bitcoin/bitcoin/pull/8525)。 + + * 使用者錯誤：對系統的變更可能導致使用者混淆，導致系統的不正確使用，這反過來可能導致有害的結果。 + + * 生態系統互動：Bitcoin 生態系統的不同部分可能有硬編碼的假設，這些假設將隨著更新而被違反。例如，解析 bitcoind 的區塊儲存的應用程式將需要更新以理解新的序列化。 + +### 避免 + +為了減少 segwit 啟動時這些風險發生的機會，已採取以下步驟： + + * 同儕審查：segwit 中的所有變更，包括設計和實作，都已公開展示並由多位獨立專家審查；通常會導致建議的改進被採納。 + + 公開展示包括： + + - [Elements Project](https://www.elementsproject.org/elements/segregated-witness/) + - [Scaling Bitcoin 香港](http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/) + - [SF Bitcoin Devs](https://www.youtube.com/watch?v=NOYNZB5BCHM) + - [Scaling Bitcoin 米蘭](http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/segwit-lessons-learned/) + - [BIP141][]、 + [BIP142][]、 + [BIP143][]、 + [BIP144][] 和 + [BIP145][] + + 技術審查包括： + + - [PR#7910](https://github.com/bitcoin/bitcoin/pull/7910) + - [PR#8149](https://github.com/bitcoin/bitcoin/pull/8149) + - [開發分支拉取請求](https://github.com/sipa/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr%20) + - [Bitcoin Core 蘇黎世會議](/logs/2016-05-zurich-meeting-notes.html) + - [Peter Todd 的審查](https://petertodd.org/2016/segwit-consensus-critical-code-review) + + * 測試案例：如[下一步](/zh_TW/2016/06/24/segwit-next-steps/#如何測試-segwit)文章中所述，「對共識規則和 P2P 網路程式碼的組合變更包含 1,486 行新增或修改的程式碼。segwit 補丁還包括單元和整合測試中的額外 3,338 行新增或修改的程式碼，這些測試有助於確保 segwit 在 Bitcoin Core 程式的每次完整建置時都能按預期運作。」 + + * 測試網路：在開發期間，隔離見證已部署在多個測試網路上，允許程式碼被審查，並且來自更廣泛生態系統的開發者（例如區塊瀏覽器和錢包）確保他們的軟體與隔離見證正確互操作。這些測試網路包括： + - Elements Project -- 測試了作為硬分叉實作的隔離見證概念，以及許多其他變更 + - segnet1 到 segnet4 -- 在 2016 年 1 月至 5 月期間測試了 segwit 作為軟分叉的實作 + - testnet3 -- segwit 於 2016 年 5 月在標準測試網上啟動 + + * 替代實作：segwit BIP 已在 [btcd](https://github.com/btcsuite/btcd/pull/656)（Go）和 [Bcoin](https://medium.com/purse-essays/introducing-bcoin-fdfcb22dfa34)（Javascript）中重新實作，以及在各種錢包和程式庫中。獨立重新實作有助於消除設計中未明確的假設和模糊性，並避免可能由此產生的錯誤。 + +### 減輕 + +減輕任何錯誤影響的一個主要因素是 segwit 作為軟分叉實作。這意味著： + + * Bitcoin 的使用者可以簡單地避免使用新引入的功能，直到他們個人確信它們被正確實作，而不會失去任何功能。 + + * 所有有效的 segwit 區塊對於 pre-segwit 軟體也是有效的區塊，因此可以使用不包含 segwit 變更的早期版本 Bitcoin（因此不包含這些變更中引入的任何錯誤）來驗證區塊，以提供針對共識回歸可能性的第二級保證。 + +此外，「腳本」語言版本控制的可能性引入了修復 Bitcoin 腳本語言中錯誤的可能性，包括預先存在的錯誤以及 segwit 可能引入的任何潛在新錯誤。 + +## 與複雜性和技術債務相關的風險 + +*技術債務*的概念是，現在的簡單修復可能會在長期內造成足夠的困難和問題，以至於現在花更多的時間和精力將證明更經濟。 + +在 Bitcoin 的背景下，有兩種類型的技術債務： + + * 醜陋或複雜的程式碼，可以在不影響使用者或共識的情況下重構；以及 + * 不良的設計決策，其中許多必須無限期保留，否則 Bitcoin 使用者將失去對其現有代幣的存取權。 + +### 避免 + +如上所述，segwit 程式碼已經過大量審查，這有助於抵制在程式碼和設計層面引入技術債務。 + +同樣如上所述，segwit 有多個獨立的重新實作，這有助於在仍可避免的時候發現任何不必要的複雜性和技術債務。 + +為了支援現有的透過重構和改進 Bitcoin 程式碼庫來償還技術債務的努力，segwit 作為僅程式碼更新合併，作為[0.13.0 版本工作的一部分](/zh_TW/meetings/2016/05/26/)。 + +### 減輕 + +Bitcoin 已經遭受了一些重大的設計債務，segwit 專門設計用於減少這些債務的影響（特別是交易可塑性、簽名雜湊的二次方擴展和未簽名的輸入值）。 + +segwit 提供的腳本版本控制方法提供了一種優雅的方式，允許未來的軟分叉更新進一步減少設計債務，包括透過修復現有操作碼中的錯誤（例如 CHECKMULTISIG）、重新啟用停用的操作碼（例如 CAT），或切換到優越的驗證方法（例如 Schnorr 簽名或聚合簽名）。 + +一般來說，Bitcoin 腳本中的設計債務無法完全償還，因為總是有可能存在一些未花費的交易支付到利用「醜陋」功能的 P2SH 地址。停用這些功能將使這些交易無法花費，實際上從使用者那裡竊取資金。腳本版本控制允許減少這種設計債務的「成本」，透過將這種「醜陋」功能劃分為僅適用於「舊」腳本版本，從而允許新的開發工作在很大程度上忽略舊程式碼。 + +## 與軟分叉部署相關的風險 + +軟分叉是對 Bitcoin 共識規則的任何變更，使先前有效的某些交易集無效。處理不當的軟分叉可能在 Bitcoin 生態系統中造成許多問題，並且，因為 segwit 使額外的見證資料對於建立 Bitcoin 的分散式共識至關重要，處理不當的升級可能導致系統以額外的方式失敗。主要的潛在失敗模式包括： + + 1. 使某些 Bitcoin 持有者無法花費他們的錢 + 2. 導致舊節點和升級節點對哪些未確認交易有效且可能被挖掘有不同的看法 + 3. 礦工錯誤地挖掘在新規則下無效的區塊 + 4. 被啟動，有一些實際使用，然後被撤回 + 5. 由於 p2p 網路實際上被斷開連接，導致大型區塊鏈分叉，因為透過無法轉發見證資料的舊節點的連接 + +### 避免 + +Bitcoin 中已經啟動了許多軟分叉（包括 BIP [16][BIP16]、[34][BIP34]、[65][BIP65]、[66][BIP66]、[68][BIP68]、[112][BIP112] 和 [113][BIP113]），這種經驗已被編纂在啟動軟分叉的 [BIP9][] 流程中。BIP9 流程用於部署 CSV 軟分叉（BIP 68、112 和 113），並導致該變更的共識規則快速且無問題的升級。 + +segwit 設計和 BIP9 部署透過以下方式避免了上述問題： + + 1. segwit 施加的新限制僅影響目前沒有人會使用的交易，因為： + + - 受影響的交易將是非標準的，因此不會被絕大多數節點中繼或被大多數礦工挖掘。 + + - 任何受影響的交易目前都會被視為明顯的「任何人都可以花費」付款，並且可以立即被任何監控區塊鏈的人領取，因此應該預期會「丟失」。 + + 2. 舊節點將認為花費 segwit 輸出的交易是非標準的，因為明顯違反了 [BIP62][] CLEANSTACK 規則，因此不會被包含在舊節點的 mempool 中。同樣，具有 P2WPKH 或 P2WSH 輸出（但不是透過 P2SH 編碼的 P2WPKH/P2WSH）的交易也將被視為非標準，因為它是新的輸出類型。 + + 這使得透過舊節點中繼一個交易並透過 segwit 節點中繼不同的交易來實現 segwit 輸出的雙花變得不可能。 + + 然而，這些差異仍然可能被用於嘗試雙花，例如透過在單個交易中組合非 segwit 輸出和 segwit 輸出（該交易將僅透過升級的 segwit 節點中繼），然後嘗試透過僅使用非 segwit 輸出的更高費用交易進行雙花，該交易可能透過舊節點成功中繼。 + + 這些擔憂僅影響 mempool 中的未確認交易；一旦交易被確認並挖掘到區塊中，雙花仍然不可能。現有的監控雙花的方法應該保持同樣有效，前提是監控工具能夠完全追蹤 segwit 花費。 + + 3. 確保礦工挖掘有效區塊顯然是每個人的高度優先事項，並且已經投入了大量工作來保證 segwit 的情況如此。這包括 [BIP145][] 下的直接工作，以及間接工作，例如緊湊區塊（[BIP152][]）。 + + 4. 如果 segwit 軟分叉在啟動後被撤回，這可能允許任何進行 segwit 交易的人損失資金 -- 例如，惡意礦工可以在沒有啟用 segwit 的鏈上重播交易，此時它將是任何人都可以花費的，然後礦工可以透過將其花費給自己來竊取資金。segwit 軟分叉在啟動後可以透過兩種方式撤回，同時允許竊取啟用 segwit 的交易： + + - 礦工可以放棄啟用 segwit 的鏈，並從 segwit 啟動之前開始挖掘。基於 [BIP9][] 啟動規則，這將需要放棄超過 2016 個區塊（LOCKED IN 期間，加上足夠的區塊以確保未達到 95% 的閾值）。這將要求礦工放棄超過 25,200 BTC 的區塊獎勵，按當前價格計算超過 15,000,000 美元。 + + - 礦工可以簡單地使用不識別 segwit 規則的軟體（例如 Bitcoin Core 的早期版本）在啟動了 segwit 的鏈頂部挖掘區塊。就 segwit 感知軟體而言，這將是硬分叉，因此使用 segwit 感知驗證節點的 Bitcoin 使用者將忽略這些區塊。如果有足夠多的使用者使用 segwit 節點，這樣的硬分叉將不會比引入新的 alt coin 更有效。 + + 因此，這兩種方法似乎都不太可能。 + + 5. 已經投入了大量工作以確保啟用 segwit 的對等方將形成 Bitcoin P2P 網路的強連接子圖。這包括為啟用見證的節點提供專用的服務位元，並優先連接到這些節點。 + +## 由於更大的區塊而產生的風險 + +Segwit 將 1MB 區塊大小限制更新為 4M 單位區塊權重限制，將序列化的見證資料計為一個單位，將核心區塊資料計為四個單位。隨著使用 segwit 功能的交易開始被使用，此變更將允許每個區塊包含更多資料（如果 100% 的交易使用 segwit 功能，預計每個區塊約 2MB 資料，但在最壞的情況下可能高達每個區塊 4MB 資料）。就其允許更大的交易量而言，可以預期它將更快地增加 UTXO 資料庫（如果 100% 的交易使用 segwit 功能，增長率可能預期大約翻倍；但是因為 segwit 是軟分叉，最壞情況的 UTXO 增長是不變的）。 + +這些結果可能有積極的屬性（例如更多的交易量允許更多的使用者採用），但也有可能顯著的負面影響： + + * 更大的區塊可能導致更慢的區塊傳輸，導致礦工的孤塊率更高 -- 這反過來可能導致更低的安全性（控制網路所需的雜湊算力更少），或更高的中心化（較大的礦工更能夠降低其孤塊率）。 + + * 更大的區塊將導致完整節點的資源需求更高，可能導致使用者關閉他們的節點，這將導致更高的中心化。 + + * 更大的 UTXO 集將導致礦工的資源需求更高，可能導致礦工共享驗證資源，這將導致更高的中心化。 + +### 避免 + +更大區塊的負面影響以多種方式受到限制： + + * 由於部署 libsecp256k1，區塊的驗證時間已顯著減少。 + + * 透過 [BIP152][] 部署緊湊區塊有助於限制更大區塊對區塊傳輸的影響，因此對孤塊率的影響，也減少了完整節點的頻寬使用。 + + * 剪除支援允許使用者執行完整節點而無需儲存整個區塊鏈歷史，這允許資源受限儲存的使用者繼續執行完整節點，即使區塊大小更大。 + + * segwit 簽名使用的簽名雜湊演算法的變更以避免二次方擴展，為某些大型交易提供了成本的顯著降低。 + +增加的 UTXO 增長的負面影響受到以下限制： + + * 將 segwit 部署為軟分叉，以確保最壞情況的 UTXO 增長不會變得更糟。 + + * 見證資料的權重降低以重新平衡 UTXO 的生命週期成本，降低引入花費 segwit 輸出的額外輸入的成本，因此（相對地）增加引入建立新 UTXO 的額外輸出的成本，將建立/花費成本比率從約 1:4.5 變更為約 1:2。這應該透過阻止 UTXO 建立和鼓勵 UTXO 花費來適度減少增加 UTXO 集的激勵。 + +### 減輕 + + * 由於每個區塊的最大資料量上限為不超過當前速率的四倍，因此解決大型區塊引起的問題的減輕工作應該在相對直接的工程工作範圍內。此外，由於預期每個區塊的資料量僅約為當前速率的兩倍，這意味著任何必要的減輕努力應該進一步簡化。 + + * 正在進行的工作是改進交易和區塊的磁碟和網路序列化，進一步減少執行完整節點的儲存和頻寬需求。 + +## 由於較低費用而產生的風險 + +Bitcoin 區塊鏈的安全性由雜湊算力提供，該算力由固定的區塊獎勵和來自個別交易的費用獎勵。因此，費用收入的減少有可能減少用於挖掘 Bitcoin 的雜湊算力，這反過來可能降低 Bitcoin 區塊鏈的安全性。 + +就個別交易費用由市場力量和供需決定而言，segwit 引入的變更可能透過增加供應（假設需求不會也上升，無論是因為還是至少與 segwit 部署同時）來降低價格的風險，較低的個別價格可能導致較低的整體挖礦收入（如果需求的價格彈性在非彈性範圍內）。 + +此外，segwit 中所做的變更可能使「第二層」解決方案（例如閃電網路）更具吸引力。如果這導致使用者將第二層解決方案視為鏈上交易的替代品，這可能會顯著降低對鏈上交易的需求，這將對交易費用水平施加額外的下行壓力。 + +### 避免 + +費用目前約為每個區塊 0.5 BTC，而區塊補貼為每個區塊 12.5 BTC，約為礦工收入的 4%，因此對礦工收入的潛在影響以及網路安全性在短期內可能很小。 + +此外，在過去十二個月中，費用在 BTC 計價值（從一年前的每個區塊不到 0.2 BTC）和實際價值（從一年前的每 BTC 不到 300 美元到今天的每 BTC 超過 600 美元）方面都在上漲，因此費用水平的適度下降只會相當於回到最多十二個月前的費用收入，這應該不會是重大影響。 + +### 減輕 + +礦工能夠個別和集體限制供應，無論是透過個別設定他們生產的區塊的最大權重的軟限制（「blockmaxweight」設定，預設為 3M），還是透過集體使用軟分叉透過孤立超過特定權重的區塊來有效降低共識限制。這種方法有可能防止由於供應增加而導致的任何費用減少（或者確實透過減少供應來增加個別費用，儘管這可能不會增加整體收入），但無法防止由於替代效應（例如採用第二層網路）而導致的費用收入減少。 + +雖然第二層網路可能充當鏈上交易的替代品，但它們無法完全避免鏈上交易，在某些情況下，即使來自第二層網路的這些相對較少的鏈上交易也可以輕易地在啟用 segwit 的情況下飽和鏈上容量。即使只有這些網路價值的非常小的一部分透過鏈上交易費用捕獲，這也可能大大高於當前的費用價值。 + +## 與長期擴展相關的風險 + +如上所述，所有交易完全採用 segwit 預計將容量大約翻倍。這在短期或中期提供了顯著的一次性容量增加，取決於採用速度。此外，透過新增功能以啟用第二層網路，可能實現一些額外的中期和長期擴展。透過修復二次方 sighash 擴展錯誤，segwit 還減少了由於未來容量增加而產生負面影響的風險。 + +然而，segwit 並沒有提供任何直接機制來進一步擴展鏈上交易量，除了那一次性的翻倍。 + +這存在長期擴展方法可能被阻止或延遲的風險：利害關係人可能認為 segwit 是「足夠的」擴展並拒絕進行或支援進一步的擴展努力。 + +### 避免 + +避免這種風險的努力包括： + + * 在 [2015-12-07 容量增加路線圖](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html)中納入「適度區塊大小增加提案」 + * 在同一路線圖中納入「彈性上限或激勵一致的動態區塊大小控制」。 + * 在 segwit 中包含功能以使後期擴展風險更低，特別是[簽章操作的線性擴展](/zh_TW/2016/01/26/segwit-benefits/#簽章操作的線性擴展)和[邁向單一組合區塊限制](/zh_TW/2016/01/26/segwit-benefits/#邁向單一組合區塊限制)。 + * 研究更有效地使用區塊空間的技術，例如使用 [Schnorr 簽名和簽名聚合](http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/) + * 研究區塊鏈的替代模型，維持去中心化和安全性，但具有更好的可擴展性屬性，例如 [Mimblewimble](http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/mimblewimble/)、[Braiding](http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/breaking-the-chain/) 和 [Jute Braiding](http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/jute-braiding/)。 + +此外，使 segwit 允許的規模增加可實現的工作（例如 libsecp256k1 和緊湊區塊）顯然也使進一步的潛在規模增加更可實現。 + +### 減輕 + +Segwit 在任何技術層面上都沒有使進一步的擴展更加困難 -- 這裡的風險完全是社會性的。因此，最有效的減輕努力也可能是社會性質的：例如透過讓支援長期擴展的公司投入開發資源來實現這一點。 + +segwit 使交易量增加到大約當前水平的兩倍也提供了展示擴展的實際影響的機會，例如對節點效能、去中心化和交易需求的影響，以及生態系統升級可以進行的速度。這些資料可以合理地收集並用於支援未來的擴展努力，無論是透過顯示某些擔心的結果不太可能發生，還是透過確認有效的擔憂並允許工作集中於解決這些擔憂。 + +## 替代方法 + +本節提供與實現 segwit 的部分或全部好處的一些替代方法的簡要比較，以及這些不同方法如何可能改變所涉及的成本和風險。 + +### 硬分叉的 segwit + +任何 segwit 的硬分叉實作都會增加顯著的新成本和風險，因為需要所有節點在啟動之前升級以理解新規則，並有可能分叉成「舊 Bitcoin」和「新 Bitcoin」，從而導致混淆和價值損失。由於 Bitcoin 社群對硬分叉的經驗相對缺乏，可能還會出現意外的風險和成本，儘管這顯然很難分析。 + +segwit 的硬分叉實作實際上可以以兩種方式進行： + + 1. SPV 不可見：如果見證承諾從 coinbase 移至區塊交易默克爾樹，大多數非驗證客戶端和錢包將繼續工作而無需升級。這將節省 coinbase 交易中的 38-47 位元組，但不提供任何其他優勢。 + + 2. SPV 可見：如果變更交易雜湊的計算以排除 scriptSig，這可能允許更簡單的實作，並減少每個交易的額外負擔；然而，它將使所有現有的 Bitcoin 軟體在更新之前無法處理這些交易。此外，需要保留管理舊式交易的單獨程式碼路徑，增加程式碼複雜性和錯誤的可能性。[BIP 134，彈性交易][BIP134] 提出了一種替代方法，透過 SPV 可見的硬分叉獲得 segwit 的一些好處。 + +任何一種硬分叉方法都可能同時大幅改變區塊的共識限制。 + +### 更簡單的 segwit + +segwit 的許多好處在邏輯上可以分為獨立的變更，並單獨評估和部署。然而，各種功能的實作需求密切相關： + + * 簽章操作的線性擴展：CHECKSIG 和 CHECKMULTISIG 操作碼需要替換。 + * 輸入值的簽名：CHECKSIG 和 CHECKMULTISIG 操作碼需要替換。 + * 透過 P2SH 增加多重簽名的安全性：P2SH 支付格式需要替換。 + * 腳本版本控制：P2SH 支付格式需要替換。 + +獨立進行這些修復將增加 Bitcoin 程式碼庫的複雜性，因為需要處理在區塊鏈上的不同時間啟動不同功能；而同時部署它們則消除了這種複雜性。 + +因為由於現有 CHECKSIG 和 CHECKMULTISIG 操作碼的簽章操作的二次方擴展，增加容量是危險的，因此需要對這些操作施加一些限制。由於 segwit 僅允許透過更新的操作碼增加簽名操作，舊操作碼自然保持受限。相反，如果獨立應用容量增加，則需要實作額外的限制以確保增加是安全的，可能會增加挖礦和費用計算的複雜性。 diff --git a/_posts/zh_TW/posts/2017-03-13-performance-optimizations-1.md b/_posts/zh_TW/posts/2017-03-13-performance-optimizations-1.md new file mode 100644 index 000000000..c0d3a360e --- /dev/null +++ b/_posts/zh_TW/posts/2017-03-13-performance-optimizations-1.md @@ -0,0 +1,118 @@ +--- +type: posts +layout: post +lang: zh_TW +name: performance-optimizations-1 +id: zh_TW-performance-optimizations-1 +title: 鏈上擴容 - Bitcoin 參考軟體歷史性能優化回顧。第 1 部分 +permalink: /zh_TW/2017/03/13/performance-optimizations-1/ +version: 1 +excerpt: 多年來幫助 Bitcoin 軟體客戶端使用者保持可靠體驗的開發里程碑。 +--- + +以下文章旨在強調多年來幫助 Bitcoin 軟體客戶端使用者保持可靠體驗的開發里程碑。我們展示了幾個關鍵升級，這些升級對於維護網路的去中心化特性和減輕參與者的資源負擔至關重要。我們描述了如何進行數個數量級的優化，使 Bitcoin 網路能夠支援交易活動的增長，而不會大幅增加新使用者和現有使用者的參與成本。最後，我們注意到這些改進都屬於更大的、系統性的協定開發方法的一部分，該方法使用來自 Big-O 複雜度概念的見解，並利用更智慧的演算法來更有效地利用網路資源。 + +## 簽名快取 +發布版本：Bitcoin-Qt 0.7.0 + +ECSDA 簽名驗證是在對等節點層級完成的計算量最大的操作之一。因為它們需要對每個交易進行驗證，任何多餘的驗證都會給終端使用者帶來顯著的資源開銷。早期版本的軟體就是這種情況，它們會在交易進入節點記憶池之前和接收到區塊後都驗證簽名。 + +為了提高效率，開發人員建立了一個快取，允許節點儲存先前驗證過的簽名，並在交易進入已接受區塊後跳過冗餘工作。 + +此外，簽名快取還減輕了由特別製作的交易可能導致 Bitcoin 客戶端停滯所引入的 DoS 向量。 + +### 進一步資訊 + + * [Bitcoin-Qt 0.7.0 發布說明](https://bitcoin.org/en/release/v0.7.0#core-bitcoin-handling-and-blockchain-database) + * [已修復的漏洞解釋：為什麼簽名快取是 DoS 保護](https://bitcointalk.org/index.php?topic=136422.0) + +## Ultraprune + LevelDB +發布版本：Bitcoin-Qt 0.8.0 + +Ultraprune 是 Bitcoin 軟體的首批主要升級之一，旨在解決與驗證區塊鏈交易資料相關的開銷。Bitcoin 參考客戶端的早期版本維護了所有交易輸出（已花費或未花費）的索引。Ultraprune 透過洞察到您只需要追蹤未花費的輸出，並且輸出一旦被花費就可以完全從索引中刪除，從而顯著減少了該索引的大小。 + +為了實現這一點，實作了一種新的資料庫佈局，該佈局將未花費交易輸出分配到緊湊的自訂格式，以減少驗證工作所需的資訊大小。 + +為了進一步優化系統的性能，Ultraprune 與 LevelDB 同時引入，後者取代了舊的 BDB 資料庫技術。總體而言，影響是顯著的：根據其硬體，使用者在驗證區塊鏈資料時可以體驗到至少一個數量級的改進。這種新的資料庫結構也為未來關於修剪和更輕量級的 Bitcoin 全節點實作的工作鋪平了道路。 + +### 進一步資訊 + + * [Bitcoin-Qt 0.8.0 發布說明](https://bitcoin.org/en/release/v0.8.0#improvements) + * [用簡單英語解釋 Ultraprune](https://archive.is/bUocJ) + * [Ultraprune 合併到主線](https://bitcointalk.org/index.php?topic=119525.0) + * [參考客戶端中的修剪：ultraprune 模式](https://bitcointalk.org/index.php?topic=91954.0) + +## 平行腳本驗證 +發布版本：Bitcoin-Qt 0.8 + +雖然是一個更微妙的變化，但將腳本驗證轉變為更平行化的過程消除了區塊驗證時間的顯著開銷。早期版本的軟體會在每次 UTXO 提取之間驗證輸入的腳本資料，由於所有操作的線性處理而產生性能問題。這違反了設計高效計算過程的基本原則，該原則規定計算應盡可能與 I/O 作業同時發生。 + +考慮到這一點，區塊驗證機制被重新設計，以便能夠將腳本檢查分配給平行執行緒，以便即使在客戶端完成從區塊提取所有 UTXO 之前，它們的驗證也可以進行。為了實現這一點，腳本檢查操作在處理交易後儲存在佇列中，並與其他輸入驗證作業分開處理。 + +因此，透過更有效地利用對等節點的資源，同步到鏈的頂端發生得更快。在實作的測試期間，開發人員注意到與軟體早期版本相比，速度提升了 35% 到 100%。 + +### 進一步資訊 + + * [平行腳本驗證 #2060](https://github.com/bitcoin/bitcoin/pull/2060) + +## 標頭優先同步 +發布版本：Bitcoin Core 0.10 + +為了進一步改善初始區塊下載時間，Core 專案在 2014 年底引入了節點用於與最多工作量有效鏈同步的機制的重要重新架構。 + +最初，引導新 Bitcoin 客戶端的過程涉及使用者從單個對等節點提取區塊資料，其結果是任何中斷或連接品質下降都會顯著停滯該過程。隨著區塊鏈大小的不斷增加，這將導致同步完成的等待時間有時會很長，很大比例的使用者報告根據其硬體最多需要數天時間。 + +標頭優先同步使用一種新方法完全緩解了這個問題，該方法涉及節點首先從單個對等節點下載和驗證區塊標頭，然後從眾多其他對等節點平行提取區塊資料。 + +自 Bitcoin 早期以來，關於初始區塊下載時間的抱怨一直很普遍。透過標頭優先同步，軟體在新使用者的可用性方面邁出了重要一步。節點現在可以利用其整個對等節點網路，而不是在不可靠的同步上浪費許多小時，並顯著縮短引導時間。透過使用更智慧的演算法，對 Bitcoin 長期永續性的這個關鍵方面進行了另一個漸近改進。 + +### 進一步資訊 + + * [Bitcoin-Qt 0.10.0 發布說明](https://bitcoin.org/en/release/v0.10.0#faster-synchronization) + * [Bitcoin.org 開發者指南](https://bitcoin.org/en/developer-guide#headers-first) + * [Pieter Wuille 在 Bitcoin-dev 郵件列表上的文章](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-October/006724.html) + +## 區塊檔案修剪 +發布版本：Bitcoin Core 0.11 + +舊資料修剪是中本聰在其白皮書中首次描述的概念，作為磁碟空間稀缺的潛在解決方案。不幸的是，原始設計不充分，無法按照其創建者的想像實作。七年後，隨著區塊鏈達到超過一百 GB，我們今天所知的區塊檔案修剪的引入為資源有限的使用者帶來了重大福音。 + +區塊檔案修剪利用了 ultraprune 的先前工作；最初下載並驗證區塊鏈的使用者現在可以丟棄早於 288 個區塊的原始資料。因為這些節點仍然保留完整的 UTXO 集，它們仍然能夠驗證未花費的資料，這足以完全驗證新區塊並防止潛在的雙重花費。 + +當然，修剪意味著仍然需要足夠數量的存檔節點來提供完整的區塊鏈資料。另一方面，這項創新透過使保持驗證者身份更具成本效益來擴大了驗證者的範圍。總體而言，該解決方案是我們增強網路多樣性可用選項的受歡迎補充。 + +### 進一步資訊 + + * [Bitcoin-Qt 0.11.0 發布說明](https://bitcoin.org/en/release/v0.11.0#block-file-pruning) + +## libsecp256k1 +發布版本：Bitcoin Core 0.12 + +經過測量，確定解決區塊鏈下載效率低下問題後的下一步是解決交易驗證及其大量計算負載的瓶頸。Core 專案著手透過使用為 ECDSA 操作的優化性能而設計的新程式庫來做到這一點。ECDSA（橢圓曲線數位簽章演算法）是 Bitcoin 公鑰基礎設施的骨幹，每當使用者透過使用其私鑰簽署訊息來移動幣時都會使用它。這些簽名需要由網路中的每個對等節點驗證，以保持帳本的完整性。 + +早期開發人員長期以來一直考慮從原始 OpenSSL 程式庫轉換，經過 5 年的設計考慮、測試和同行評審，Pieter Wuille 的 libsecp256k1 程式庫被引入作為其替代品。正如預期的那樣，該實作導致每個 Bitcoin 交易背後的簽名驗證過程的重大加速。基準測試報告比 OpenSSL 實作改進了 5-7 倍。對於使用者來說，這將轉化為節省多達一半通常用於 ECSDA 操作的引導時間，這是從頭開始同步新節點最費力的步驟之一。 + +考慮到 Bitcoin 交易活動的增長，此升級對於為網路對等節點保持合理的使用者體驗至關重要。再一次，演算法複雜度的降低為使用者提供了更有效的資源使用，並大幅降低了新參與者的進入門檻。 + +### 進一步資訊 + + * [Bitcoin-Qt 0.12.0 發布說明](https://bitcoin.org/en/release/v0.12.0#signature-validation-using-libsecp256k1) + * [Andrew Poelstra (andytoshi) 關於 libsecp256k1 的安全性和測試](https://bitcointalk.org/index.php?action=profile;u=80376) + * [Greg Maxwell 關於 libsecp256k1 測試揭示 OpenSSL 中的錯誤](https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/) + * [Greg Maxwell 在 DevCore 的演講](https://www.youtube.com/watch?v=RguZ0_nmSPw&t=1297) + * [Hal Finney 關於 libsecp256k1 的文章](https://bitcointalk.org/index.php?topic=3238.0) + +## 記憶池限制 +發布版本：Bitcoin Core 0.12 + +Bitcoin 軟體長期存在的漏洞是無法正確處理對等節點記憶池的氾濫。實際上，攻擊者可以傳送大量低價值、低費用的交易，這些交易會在記憶池中累積，直到它會使可用記憶體過載。這將導致具有相對較低 RAM 資源的節點在異常活動期間崩潰。對此唯一有效的措施是增加軟體的最低中繼費用，但這仍然沒有對記憶池的潛在大小設定上限。 + +為了補救這一點，Core 專案的開發人員實作了嚴格的記憶池最大大小，並具有特定的驅逐策略，按費用對交易進行排序，並首先驅逐支付最低的交易。為了防止具有相同費用的交易重新進入記憶池，節點將增加其有效的最低中繼費率，以匹配最後一個被驅逐交易的費率加上初始最低中繼費率。 + +最大大小的配置留給使用者，預設大小為 300 MB。此更新為資源有限的節點使用者提供了更強大的體驗，並且總體上使整個網路更加可靠。 + +### 進一步資訊 + +* [Bitcoin-Qt 0.12.0 發布說明](https://bitcoin.org/en/release/v0.12.0#memory-pool-limiting) + +在第 2 部分中，我們將討論基於上述技術的最新改進，並進一步提高網路的穩健性和擴展潛力。 diff --git a/_posts/zh_TW/posts/2017-03-23-schnorr-sigagg.md b/_posts/zh_TW/posts/2017-03-23-schnorr-sigagg.md new file mode 100644 index 000000000..609319075 --- /dev/null +++ b/_posts/zh_TW/posts/2017-03-23-schnorr-sigagg.md @@ -0,0 +1,83 @@ +--- +type: posts +layout: post +lang: zh_TW +name: schnorr-sigagg +id: zh_TW-schnorr-sigagg +title: 技術路線圖 - Schnorr 簽章和簽章聚合 +permalink: /zh_TW/2017/03/23/schnorr-signature-aggregation/ +version: 1 +excerpt: Schnorr 簽章和簽章聚合的狀態和說明 +--- + +## Schnorr 簽章 + +用更有效的 Schnorr 演算法替代 Bitcoin 的數位簽章演算法（ECDSA）長期以來一直位於許多 Bitcoin 開發者願望清單的首位。Schnorr 是一種利用橢圓曲線密碼學的簡單演算法，在保留其所有功能和安全假設的同時，實現了對現有方案的多項改進。 + +值得注意的是，Schnorr 簽章支援「原生多重簽章」，可將多個簽章聚合為一個對其各自輸入的金鑰總和有效的簽章。此功能提供三個重要好處： + +* 無論多重簽章設定中的參與者數量如何，簽章大小都是恆定的。50-of-50 交易的大小實際上與使用單個公鑰和簽章的交易相同。因此，此類方案的效能透過消除單獨驗證每個簽章的原始要求而顯著提高。此外，Schnorr 簽章的驗證比 ECDSA 稍快。 + + +* 要驗證和透過網路傳輸的資料大小減少也轉化為有趣的容量增益。考慮到下面顯示的多重簽章交易數量的歷史增長，減少這些交易大小的潛力是對現有擴展工作的誘人補充。我們應該預期隨著支付通道的出現和進一步採用，這一趨勢將繼續。 + + +* 從私密性的角度來看，Schnorr 允許將多重簽章的整個策略隱藏起來，並且與傳統的單個公鑰無法區分。在閾值設定中，參與者也變得不可能透露他們中的哪些人授權或未授權交易。 + + +

+ UTXO repartition +

+

+ 根據多重簽章設定分佈未花費 P2SH 輸出。來源：p2sh.info +

+ +不幸的是，與 ECDSA 不同，Schnorr 演算法自發明以來尚未被標準化，可能是因為對其強制執行的原始專利（現已到期）。雖然系統的一般輪廓在數學上是健全的，但缺乏文件和規範使其實作更具挑戰性。具體來說，它對 Bitcoin 的臨時金鑰對設計的應用涉及需要進一步最佳化的安全考慮。 + +Pieter Wuille 在他的 Scaling Bitcoin Milan 上關於 Schnorr 簽章的演講中將主要挑戰定義為「抵消」問題。一組使用者建立對其金鑰總和有效的簽章的可能性為對抗性參與者從整體中減去另一個使用者的金鑰開啟了大門。它本質上是這樣運作的： + +假設使用輸入公鑰 Q1 和 Q2 的 2-of-2 多重簽章方案。惡意參與者在互動階段期間，不是宣布他們的金鑰為 Q2 以與 Q1 組合，而是可以提供 Q2-Q1 並有效地抵消其他使用者的金鑰。傳送到聯合公鑰的任何資金現在只能由 Q2 金鑰的所有者花費，而 Q1 的所有者甚至不知道發生了什麼。 + +幸運的是，現在有一個解決方案可用，它涉及在簽章之前將設定期間使用的每個金鑰與基於其自身和所有其他相關金鑰的雜湊相乘。此過程稱為去線性化。此方案的安全性證明目前正在進行同行評審，並將在即將發布的白皮書中正式描述。 + +在短期內，Schnorr 簽章被認為是 Bitcoin 協定兩個重要功能的可行替代品：OP_CHECKSIG 和 OP_CHECKMULTISIG。 + +前者目前用於根據交易中的訊息檢查 ECDSA 簽章與其各自的公鑰。透過切換到檢查 Schnorr 簽章而不是 ECDSA 的等效物，該操作碼可用於授權需要多個簽章的支出，這通常需要呼叫 OP_CHECKMULTISIG。使用網路無法觀察到的先驗互動，簽署者集合計算組合的公鑰以及共同簽章，由新的 OP_CHECKSIG 驗證，具有增加私密性和降低成本的好處。 + +後者涉及閾值情況，其中只需要 n-of-m 簽章來授權交易。OP_CHECKMULTISIG 的當前實作驗證閾值策略所需的所有公鑰和相關簽章。因為計算隨著參與者數量線性擴展，Schnorr 提出了一個更有效的方案，它用單個組合簽章以及所需公鑰的子集替換簽章列表。 + +在對保護簽署者免受惡意行為者攻擊的去線性化方案進行更多評估之前，Schnorr 簽章的進一步應用可能為時過早，但上述功能的實作有望為在生產中更好地理解該方案鋪平道路。取決於額外的同行評審，Schnorr 簽章實作的 BIP 可以在年底前提出。 + +## 簽章聚合 + +Schnorr 允許在單個輸入上組合多個簽章的屬性也適用於所有交易的多個輸入的聚合。Bitcoin 開發者 Gregory Maxwell 是第一個使用基於 BLS 簽章的先前提案的見解引入這個想法的人。 + +要正確理解此應用與上述應用之間的差異，有必要考慮在每個各自情況下如何聚合簽章。在原生多重簽章設定中，簽署者彼此合作以計算共同公鑰及其相關簽章。這種互動發生在協定之外，只涉及相關各方。簽章聚合背後的想法是讓系統驗證者（即 Bitcoin 節點）在協定層級為所有交易的每個輸入計算單個金鑰和簽章。 + +因為此方案將聚合範圍擴展到確定性參與者集合之外，它引入了惡意行為者利用「抵消」錯誤的新攻擊向量。因此，前一節中強調的去線性化修正對於此方法的健全性至關重要。 + +在實作方面，該提案相當直接：修改 OP_CHECKSIG 和 OP_CHECKMULTISIG，使它們可以堆疊公鑰，對它們進行去線性化，一旦驗證了所有相關輸入，就為它們各自的交易產生組合簽章。 + +評估如果自創世區塊以來實作簽章聚合可能節省的資源類型相當簡單。假設每個歷史簽章減少到 1 位元組，除了每筆交易一個，分析表明該方法將導致儲存和頻寬至少減少 25%。增加使用 n-of-n 閾值可能會轉化為更多節省，儘管它們未在此分析中考慮。 + +

+ Schnorr signature addregation savings chart +

+ +### 關於 Schnorr 簽章的更多資訊 + * [Pieter Wuille 在 Scaling Bitcoin Milan 上關於 Schnorr 簽章的演講逐字稿](https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/) + * [Pieter Wuille 的演講影片](https://youtu.be/_Z0ID-0DOnc?t=2297) + * [2016 年 7 月 Bitcoin 開發者和礦工會議關於 Schnorr 簽章的討論](http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/) + * [Schnorr 文件](https://github.com/sipa/secp256k1/blob/968e2f415a5e764d159ee03e95815ea11460854e/src/modules/schnorr/schnorr.md) + * [StackExchange - Schnorr 的含義是什麼？](http://bitcoin.stackexchange.com/questions/34288/what-are-the-implications-of-schnorr-signatures/35351#35351) + * [Elements 專案：Schnorr 簽章驗證](https://elementsproject.org/features/schnorr-signatures) + * [SF Bitcoin Devs 研討會：Gregory Maxwell 談 Schnorr 多重簽章](https://www.youtube.com/watch?v=TYQ-3VvNCHE) + * [Bitcoin Core 開發者關於 Schnorr 簽章的會議記錄](https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html) + +### 關於簽章聚合的更多資訊 + * [Gregory Maxwell 在 Bitcointalk.org 論壇上關於簽章聚合的貼文](https://bitcointalk.org/index.php?topic=1377298.0) + * [Bitcoin Core 開發者關於 Schnorr 簽章的會議記錄](https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html) + * [Pieter Wuille 在 Scaling Bitcoin Milan 上關於 Schnorr 簽章的演講逐字稿](https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/) + * [Pieter Wuille 的演講影片](https://youtu.be/_Z0ID-0DOnc?t=2297) + + diff --git a/_posts/zh_TW/posts/2017-03-31-hybrid-spv.md b/_posts/zh_TW/posts/2017-03-31-hybrid-spv.md new file mode 100644 index 000000000..b37ba14cc --- /dev/null +++ b/_posts/zh_TW/posts/2017-03-31-hybrid-spv.md @@ -0,0 +1,24 @@ +--- +type: posts +layout: post +lang: zh_TW +name: hybrid-spv +id: zh_TW-hybrid-spv +title: 技術路線圖 - 使用完整區塊 SPV 模式的優先區塊下載 +permalink: /zh_TW/2017/03/31//prioritized-block-download-using-hybrid-spv/ +version: 1 +excerpt: 使用完整區塊 SPV 模式的優先區塊下載 +--- + +## 混合式完整區塊 SPV 模式 + +阻礙一般使用者進一步採用完全驗證軟體的主要障礙之一是，在完全同步整個區塊鏈之前無法使用客戶端的錢包功能。對於引導新節點的使用者來說，這意味著他們無法接收或傳送交易，直到每個區塊都已下載並驗證到鏈的當前尖端。這種行為並非錯誤：Bitcoin Core 參考軟體預設構建為提供 Bitcoin 使用者可以期望的最強安全性和私密性保證，這必然意味著完全驗證以確認歷史區塊鏈資料的完整性。 + +另一方面，軟體的現有功能（例如標頭優先驗證）提供了改進錢包可用性的機會，前提是使用者願意做出臨時的安全權衡。使用混合式完整區塊 SPV 模式，軟體將根據使用者錢包中最舊的金鑰優先下載區塊。與先前下載的區塊標頭鏈一起，它應該滿足預期的工作量證明難度檢查，客戶端可以立即開始處理相關交易。整個區塊鏈仍然並行下載並最終驗證，但此功能使使用者能夠在背景中進行同步時查看和花費與其錢包相關的 UTXO。 + +與 SPV 錢包的典型實作相反，此模型不會遭受依賴布隆過濾器和公鑰公開披露的方案所施加的[私密性降級](http://bitcoin.stackexchange.com/questions/37756/are-public-keys-and-their-corresponding-hash-values-both-added-to-a-bitcoinj-blo)。這種好處帶來的權衡是它消耗更多頻寬。另一個警告：在 SPV 模式下收到的確認本質上不如在完全驗證下收到的確認安全。利用混合式 SPV 模式的使用者應該等待多次確認（6+），直到他的付款可以被認為是安全的。 + +### 更多資訊 + * [完整修補程式集 PR](https://github.com/bitcoin/bitcoin/pull/9483) + * [接收交易的完美私密性](https://bitcoin.org/en/bitcoin-core/features/privacy#perfect-privacy-for-received-transactions) + diff --git a/_posts/zh_TW/posts/2017-08-18-btc1-misleading-statements.md b/_posts/zh_TW/posts/2017-08-18-btc1-misleading-statements.md new file mode 100644 index 000000000..188a54118 --- /dev/null +++ b/_posts/zh_TW/posts/2017-08-18-btc1-misleading-statements.md @@ -0,0 +1,29 @@ +--- +type: posts +layout: post +lang: zh_TW +name: btc1-misleading-statements +id: zh_TW-btc1-misleading-statements +title: 更正關於 Segwit2x 和 btc1 的錯誤資訊 +permalink: /zh_TW/2017/08/18/btc1-misleading-statements/ +version: 1 +excerpt: 更正關於 Segwit2x 和 btc1 的錯誤資訊 +--- + +「Segwit2x」，一項對 Bitcoin 網路共識規則進行不相容變更的提案，最近受到越來越多的關注。有人試圖誤導人們相信 btc1 專案（Segwit2x 提案的實作）是現有軟體的必要更新──事實並非如此。相反，它是對現有網路規則的爭議性偏離，其使用者將很快發現自己與網路其他部分在區塊和交易的有效性方面存在分歧。 + +請注意： + + * 隔離見證（或 Segwit，一種將在未來幾天內啟動的軟分叉）與 Segwit2x 硬分叉無關。隔離見證與所有先前的 Bitcoin 軟體向後相容。對於絕大多數 Bitcoin 使用者來說，不需要採取任何行動。 + + * [bitcoincore.org](https://bitcoincore.org) 是官方網站，[@bitcoincoreorg](https://twitter.com/bitcoincoreorg) 是 Bitcoin Core 專案的官方 Twitter 帳戶。任何其他聲稱代表該專案的網站或 Twitter 帳戶都是欺詐性的。Bitcoin Core 是一個開源專案，歡迎任何人透過其 GitHub 專案貢獻和審查。Bitcoin Core 二進位檔案可以從 [bitcoincore.org](/zh_TW/download) 取得，並且始終由發布經理的簽署金鑰進行數位簽章。撰寫本文時，Bitcoin Core 的最新版本是 0.14.2。 + + * btc1 與 Bitcoin Core *沒有任何* 關聯。沒有常規的 Bitcoin Core 貢獻者支援 btc1 或與該專案有任何聯繫，也沒有參與其提議的硬分叉的設計。 + + * 我們強烈建議使用者不要下載任何聲稱是對 Bitcoin 共識規則「升級」的 Bitcoin 全節點軟體，除非仔細考慮提議的變更對 Bitcoin 系統的影響以及社群對它的支援程度。這包括 Bitcoin Core 新版本中提議的共識變更。 + + * 雖然很難確定更廣泛的 Bitcoin 社群支援什麼，但要警惕聲稱龐大而多樣化的 Bitcoin 社群在沒有獨立驗證的情況下完全轉向一個分叉或另一個分叉的說法。簽署信已被公司用來聲稱代表其客戶/使用者而未經其同意，並且經常使用不精確和誤導性的語言。過去，Bitcoin XT、Bitcoin Classic 和 Bitcoin Unlimited 以及其他的信件已被傳閱以表明對一個想法的普遍支援，同時被宣傳為不考慮社群考慮而執行軟體的承諾，只會在幾個月後被放棄。 + + * Bitcoin Core 貢獻者和 Bitcoin 社群成員提出的關於 Segwit2x 提案的擔憂尚未得到其支持者的充分解決。該提案的細節是在 Bitcoin 的隔離見證啟動之前以及最近建立 BCH 貨幣之前確定的。在規劃未來時忽略這些事件的結果是不負責任的。例如，我們已經看到了當單個地址在兩條鏈上都有效時產生的混亂，但 Segwit2x 提案打算重複同樣的錯誤。此外，BCH 對強重放保護的實作為 BCH 和 Bitcoin 的使用者提供了顯著的保護，而 Segwit2x 不打算提供這種保護。 + + * Bitcoin 的共識規則應該只在謹慎的情況下並在整個社群的廣泛同意下變更。Segwit2x 在其流程和實作中都受到了許多人的反對。Bitcoin Core 將繼續支援 Segwit 軟分叉，我們期待在未來幾年幫助 Bitcoin 擴展到新的高度。 diff --git a/_posts/zh_TW/posts/2018-09-20-notice.md b/_posts/zh_TW/posts/2018-09-20-notice.md new file mode 100644 index 000000000..b3df053ce --- /dev/null +++ b/_posts/zh_TW/posts/2018-09-20-notice.md @@ -0,0 +1,75 @@ +--- +title: CVE-2018-17144 披露 +name: cve-2018-17144-full-disclosure +id: zh_TW-cve-2018-17144-full-disclosure +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + Bitcoin Core 容易受到 DoS 和通膨攻擊。修復程式於 2018 年 9 月 18 日在 Bitcoin Core 版本 0.16.3 和 0.17.0rc4 中發布。 + +--- + +完整披露 +=============== +CVE-2018-17144 的修復程式於 9 月 18 日在 Bitcoin Core 版本 0.16.3 和 0.17.0rc4 中發布，包括阻斷服務元件和關鍵的通膨漏洞。它最初於 9 月 17 日僅作為阻斷服務錯誤報告給多位從事 Bitcoin Core 工作的開發者，以及支援其他加密貨幣的專案，包括 ABC 和 Unlimited，但我們很快確定該問題也是一個通膨漏洞，具有相同的根本原因和修復方法。 + +為了鼓勵快速升級，決定立即修補並披露較不嚴重的阻斷服務漏洞，同時聯繫礦工、企業和其他受影響的系統，同時延遲發布完整問題以給系統時間升級。9 月 20 日，一個公共論壇中的貼文報告了完整影響，儘管它很快被撤回，但該聲稱被進一步傳播。 + +目前我們相信超過一半的 Bitcoin 算力已升級到已修補的節點。我們不知道有任何試圖利用此漏洞的嘗試。 + +然而，受影響的使用者升級並應用最新的修補程式仍然至關重要，以確保不會發生大規模重組、挖掘無效區塊或接受無效交易的可能性。 + +技術細節 +================= + +在 Bitcoin Core 0.14 中，新增了一個最佳化（Bitcoin Core PR #9049），它避免了在初始預中繼區塊驗證期間進行昂貴的檢查，該檢查是在 2012 年新增的（PR #443），用於檢查單個交易中的多個輸入沒有花費相同的輸入兩次。雖然 UTXO 更新邏輯有足夠的知識來檢查在 0.14 中沒有違反這種情況，但它僅在完整性檢查斷言中這樣做，而不是使用完整的錯誤處理（然而，它確實在 0.8 之前完全處理了這種情況兩次）。 + +因此，在 Bitcoin Core 0.14.X 中，任何在區塊內的單個交易中重複花費交易輸出的嘗試都將導致斷言失敗和崩潰，正如最初報告的那樣。 + +在 Bitcoin Core 0.15 中，作為更大的重新設計的一部分，以簡化未花費交易輸出追蹤並更正資源耗盡攻擊，斷言被巧妙地更改了。它不是斷言被標記為已花費的輸出先前是未花費的，而是僅斷言它存在。 + +因此，在 Bitcoin Core 0.15.X、0.16.0、0.16.1 和 0.16.2 中，任何在區塊內的單個交易中重複花費交易輸出的嘗試，其中被花費的輸出是在同一區塊中建立的，將發生相同的斷言失敗（如 0.16.3 修補程式中包含的測試案例所示）。然而，如果被重複花費的輸出是在前一個區塊中建立的，CCoin 映射中仍將保留一個條目，設定了 DIRTY 標誌並被標記為已花費，不會導致這樣的斷言。這可能允許礦工增加 Bitcoin 的供應量，因為他們將能夠聲稱被花費的價值兩次。 + +時間表 +======== + +2018 年 9 月 17 日的時間表：（所有時間均為 UTC） + +- 14:57 匿名報告者向以下人員報告崩潰錯誤：Bitcoin Core 的 Pieter Wuille、Greg Maxwell、Wladimir Van Der Laan，Bitcoin ABC 的 deadalnix 和 Bitcoin Unlimited 的 sickpig。 +- 15:15 Greg Maxwell 與 Cory Fields、Suhas Daftuar、Alex Morcos 和 Matt Corallo 分享原始報告 +- 17:47 Matt Corallo 識別通膨錯誤 +- 19:15 Matt Corallo 首次嘗試聯繫 slushpool CEO 以建立溝通線路快速應用修補程式 +- 19:29 Greg Maxwell 為展示通膨漏洞的測試案例的雜湊加上時間戳記（a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350） +- 20:15 John Newbery 和 James O'Beirne 被告知該漏洞，以便他們可以協助警告公司即將發布的 DoS 漏洞修補程式 +- 20:30 Matt Corallo 與 slushpool CTO 和 CEO 交談，並分享修補程式並披露阻斷服務 +- 20:48 slushpool 確認已升級 +- 21:08 向 Bitcoin ABC 傳送警告，修補程式將在 22:00 前公開發布 +- 21:30（大約）回覆原始報告者並確認 +- 21:57 Bitcoin Core PR 14247 發布，包含修補程式和展示阻斷服務錯誤的測試 +- 21:58 Bitcoin ABC 發布其修補程式 +- 22:07 諮詢電子郵件與 Bitcoin Core PR 和修補程式的連結傳送給 Optech 成員等 +- 23:21 Bitcoin Core 版本 0.17.0rc4 標記 + +2018 年 9 月 18 日： + +- 00:24 Bitcoin Core 版本 0.16.3 標記 +- 20:44 Bitcoin Core 發布二進位檔案和發布公告可用 +- 21:47 Bitcointalk 和 reddit 有公開橫幅敦促人們升級 + +2018 年 9 月 19 日： + +- 14:06 郵件列表由 Pieter Wuille 分發額外訊息敦促人們升級 + +2018 年 9 月 20 日： + +- 19:50 David Jaenson 獨立發現該漏洞，並向 Bitcoin Core 安全聯絡電子郵件報告。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2019-11-08-CVE-2017-18350.md b/_posts/zh_TW/posts/2019-11-08-CVE-2017-18350.md new file mode 100644 index 000000000..764909a2a --- /dev/null +++ b/_posts/zh_TW/posts/2019-11-08-CVE-2017-18350.md @@ -0,0 +1,54 @@ +--- +title: CVE-2017-18350 披露 +name: cve-2017-18350-disclosure +id: zh_TW-2017-18350-disclosure +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點可能容易受到惡意 SOCKS 伺服器的緩衝區溢位攻擊。修復程式於 2017 年 11 月 6 日在 Bitcoin Core 版本 0.15.1 中發布。 +--- +{{page.excerpt}} + +技術細節 +========== +CVE-2017-18350 是一個緩衝區溢位漏洞，它允許惡意 SOCKS 代理伺服器在具有有號 `char` 型態的系統（包括常見的 32 位元和 64 位元 x86 PC）上覆寫程式堆疊。 + +該漏洞在 [60a87bce873 (SOCKS5 support)](https://github.com/bitcoin/bitcoin/commit/60a87bce873ce1f76a80b7b8546e83a0cd4e07a5) 中引入，並於 2012 年 8 月 27 日首次在 Bitcoin Core v0.7.0rc1 中發布。修復程式隱藏在 [d90a00eabed ("Improve and document SOCKS code")](https://github.com/bitcoin/bitcoin/commit/d90a00eabed0f3f1acea4834ad489484d0012372) 中，於 2017 年 11 月 6 日在 v0.15.1 中發布。 + +要受到影響，節點必須首先被設定為使用這樣的惡意代理。請注意，在不安全的網路（例如網際網路）上使用*任何*代理都可能是一個漏洞，因為連線可能被攔截用於此類目的。 + +在節點的連線請求後，惡意代理將回應一個與請求不同的目標網域名稱的確認。通常這個確認完全被忽略，但如果長度使用高位元（即，長度 128-255（含）），它將被易受影響的版本解釋為負數。當負數傳遞給 recv() 系統呼叫以讀取網域名稱時，它會轉換回無號/正數，但以更寬的大小（通常是 32 位元），導致實際上無限讀取到 256 位元組虛擬堆疊緩衝區內及之外。 + +為了修復此漏洞，虛擬緩衝區被更改為明確的無號資料型態，避免與負數之間的轉換。 + +歸屬 +=========== +感謝 [practicalswift](https://twitter.com/practicalswift) 發現並提供漏洞的初始修復程式，以及 Wladimir J. van der Laan 提供修復程式的偽裝版本以及對風險程式碼的一般清理。 + +時間表 +======== + +- 2012-04-01：在 PR #1141 中引入漏洞。 +- 2012-05-08：漏洞合併到 master git 儲存庫。 +- 2012-08-27：漏洞在 v0.7.0rc1 中發布。 +- 2012-09-17：漏洞在 v0.7.0 中發布。 +- ... +- 2017-09-21：practicalswift 向安全團隊披露漏洞。 +- 2017-09-23：Wladimir 開啟 PR #11397 以悄悄修復漏洞。 +- 2017-09-27：修復程式合併到 master git 儲存庫。 +- 2017-10-18：修復程式合併到 0.15 git 儲存庫。 +- 2017-11-04：修復程式在 v0.15.1rc1 中發布。 +- 2017-11-09：修復程式在 v0.15.1 中發布。 +- ... +- 2019-06-22：向 bitcoin-dev ML 披露漏洞存在。 +- 2019-11-08：向 bitcoin-dev ML 披露漏洞細節。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2020-03-27-hidden-service.md b/_posts/zh_TW/posts/2020-03-27-hidden-service.md new file mode 100644 index 000000000..8515887b7 --- /dev/null +++ b/_posts/zh_TW/posts/2020-03-27-hidden-service.md @@ -0,0 +1,22 @@ +--- +title: bitcoincore.org 隱藏服務 +name: hidden-service +id: zh_TW-hidden-service +lang: zh_TW +type: posts +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 0 + +excerpt: > + 在多次請求後，本站現在可作為 Tor 隱藏服務訪問 +--- +在多次請求後，本站現在可透過 onion 地址作為 Tor 隱藏服務訪問： + + + +除了新增另一種抗審查手段外，隱藏服務提供了不依賴憑證授權單位或 DNS 基礎設施的替代信任路徑。 diff --git a/_posts/zh_TW/posts/2021-09-13-release-22.0.md b/_posts/zh_TW/posts/2021-09-13-release-22.0.md new file mode 100644 index 000000000..48d10277f --- /dev/null +++ b/_posts/zh_TW/posts/2021-09-13-release-22.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 22.0 版本發布 +name: blog-release-22.0 +id: zh_tw-blog-release-22.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 22.0 現已發布。 +--- +Bitcoin Core 22.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/22.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2022-04-25-release-23.0.md b/_posts/zh_TW/posts/2022-04-25-release-23.0.md new file mode 100644 index 000000000..27bac9dce --- /dev/null +++ b/_posts/zh_TW/posts/2022-04-25-release-23.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 23.0 版本發布 +name: blog-release-23.0 +id: zh_tw-blog-release-23.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 23.0 現已發布。 +--- +Bitcoin Core 23.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/23.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2022-12-12-release-24.0.1.md b/_posts/zh_TW/posts/2022-12-12-release-24.0.1.md new file mode 100644 index 000000000..424ceaaa5 --- /dev/null +++ b/_posts/zh_TW/posts/2022-12-12-release-24.0.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 24.0.1 版本發布 +name: blog-release-24.0.1 +id: zh_tw-blog-release-24.0.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 24.0.1 現已發布。 +--- +Bitcoin Core 24.0.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/24.0.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2022-12-15-release-22.1.md b/_posts/zh_TW/posts/2022-12-15-release-22.1.md new file mode 100644 index 000000000..3f2e414e1 --- /dev/null +++ b/_posts/zh_TW/posts/2022-12-15-release-22.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 22.1 版本發布 +name: blog-release-22.1 +id: zh_tw-blog-release-22.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 22.1 現已發布。 +--- +Bitcoin Core 22.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/22.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2022-12-21-release-23.1.md b/_posts/zh_TW/posts/2022-12-21-release-23.1.md new file mode 100644 index 000000000..9b6de66b8 --- /dev/null +++ b/_posts/zh_TW/posts/2022-12-21-release-23.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 23.1 版本發布 +name: blog-release-23.1 +id: zh_tw-blog-release-23.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 23.1 現已發布。 +--- +Bitcoin Core 23.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/23.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2023-05-18-release-23.2.md b/_posts/zh_TW/posts/2023-05-18-release-23.2.md new file mode 100644 index 000000000..20f29f737 --- /dev/null +++ b/_posts/zh_TW/posts/2023-05-18-release-23.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 23.2 版本發布 +name: blog-release-23.2 +id: zh_tw-blog-release-23.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 23.2 現已發布。 +--- +Bitcoin Core 23.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/23.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2023-05-18-release-24.1.md b/_posts/zh_TW/posts/2023-05-18-release-24.1.md new file mode 100644 index 000000000..a008de022 --- /dev/null +++ b/_posts/zh_TW/posts/2023-05-18-release-24.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 24.1 版本發布 +name: blog-release-24.1 +id: zh_tw-blog-release-24.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 24.1 現已發布。 +--- +Bitcoin Core 24.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/24.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2023-05-26-release-25.0.md b/_posts/zh_TW/posts/2023-05-26-release-25.0.md new file mode 100644 index 000000000..e0a661d40 --- /dev/null +++ b/_posts/zh_TW/posts/2023-05-26-release-25.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 25.0 版本發布 +name: blog-release-25.0 +id: zh_tw-blog-release-25.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 25.0 現已發布。 +--- +Bitcoin Core 25.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/25.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2023-10-19-release-25.1.md b/_posts/zh_TW/posts/2023-10-19-release-25.1.md new file mode 100644 index 000000000..bb7c9f44d --- /dev/null +++ b/_posts/zh_TW/posts/2023-10-19-release-25.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 25.1 版本發布 +name: blog-release-25.1 +id: zh_tw-blog-release-25.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 25.1 現已發布。 +--- +Bitcoin Core 25.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/25.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2023-10-26-release-24.2.md b/_posts/zh_TW/posts/2023-10-26-release-24.2.md new file mode 100644 index 000000000..a8dcef727 --- /dev/null +++ b/_posts/zh_TW/posts/2023-10-26-release-24.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 24.2 版本發布 +name: blog-release-24.2 +id: zh_tw-blog-release-24.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 24.2 現已發布。 +--- +Bitcoin Core 24.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/24.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2023-12-06-release-26.0.md b/_posts/zh_TW/posts/2023-12-06-release-26.0.md new file mode 100644 index 000000000..68891d733 --- /dev/null +++ b/_posts/zh_TW/posts/2023-12-06-release-26.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 26.0 版本發布 +name: blog-release-26.0 +id: zh_tw-blog-release-26.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 26.0 現已發布。 +--- +Bitcoin Core 26.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/26.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-04-02-release-26.1.md b/_posts/zh_TW/posts/2024-04-02-release-26.1.md new file mode 100644 index 000000000..d0eabae54 --- /dev/null +++ b/_posts/zh_TW/posts/2024-04-02-release-26.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 26.1 版本發布 +name: blog-release-26.1 +id: zh_tw-blog-release-26.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 26.1 現已發布。 +--- +Bitcoin Core 26.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/26.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-04-08-release-25.2.md b/_posts/zh_TW/posts/2024-04-08-release-25.2.md new file mode 100644 index 000000000..6cf68b689 --- /dev/null +++ b/_posts/zh_TW/posts/2024-04-08-release-25.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 25.2 版本發布 +name: blog-release-25.2 +id: zh_tw-blog-release-25.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 25.2 現已發布。 +--- +Bitcoin Core 25.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/25.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-04-16-release-27.0.md b/_posts/zh_TW/posts/2024-04-16-release-27.0.md new file mode 100644 index 000000000..2bcda3410 --- /dev/null +++ b/_posts/zh_TW/posts/2024-04-16-release-27.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 27.0 版本發布 +name: blog-release-27.0 +id: zh_tw-blog-release-27.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 27.0 現已發布。 +--- +Bitcoin Core 27.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/27.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-06-17-release-27.1.md b/_posts/zh_TW/posts/2024-06-17-release-27.1.md new file mode 100644 index 000000000..a017b2d72 --- /dev/null +++ b/_posts/zh_TW/posts/2024-06-17-release-27.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 27.1 版本發布 +name: blog-release-27.1 +id: zh_tw-blog-release-27.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 27.1 現已發布。 +--- +Bitcoin Core 27.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/27.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-bip70-crash.md b/_posts/zh_TW/posts/2024-07-03-disclose-bip70-crash.md new file mode 100644 index 000000000..b3db63603 --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-bip70-crash.md @@ -0,0 +1,42 @@ +--- +title: CVE-2024-52918 - 使用惡意 BIP72 URI 導致崩潰 +name: blog-disclose-bip70-crash +id: zh_TW-blog-disclose-bip70-crash +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 2 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + Bitcoin-Qt 中的 BIP70 實作在開啟 BIP72 URI 時可能會靜默崩潰。修復程式於 2020 年 6 月 3 日在 Bitcoin Core 0.20.0 中發布。 +--- + +Bitcoin-Qt 在開啟 [BIP72](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki) URI 時可能會崩潰。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +[BIP72](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki) 使用 `r` 參數擴展了 BIP21 URI 方案，以從中獲取付款請求。攻擊者可以簡單地將 `r` 參數中包含的 URL 指向一個非常大的檔案，Bitcoin-Qt 會嘗試為其分配足夠的記憶體並崩潰。 + +受害者可能會被誘騙開啟惡意付款請求。大型下載將在背景中進行，在 GUI 中幾乎沒有輸出，直到應用程式記憶體不足。 + +## 歸屬 + +感謝 Michael Ford (Fanquake) 負責任地披露問題並提供 PoC。 + +## 時間表 + +- 2019-08-12 Michael Ford 向 Cory Fields 和 Wladimir Van Der Laan 報告該錯誤 +- 2019-10-16 Michael Ford 開啟 PR [#17165](https://github.com/bitcoin/bitcoin/pull/17165) 以完全移除 BIP70 支援 +- 2019-10-26 Michael 的 PR 被合併到 Bitcoin Core +- 2020-06-03 Bitcoin Core 版本 0.20.0 發布 +- 2021-09-13 最後一個易受影響的 Bitcoin Core 版本（0.19.x）終止支援 +- 2024-07-03 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-getdata-cpu.md b/_posts/zh_TW/posts/2024-07-03-disclose-getdata-cpu.md new file mode 100644 index 000000000..24a14a5a7 --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-getdata-cpu.md @@ -0,0 +1,42 @@ +--- +title: CVE-2024-52920 - 使用巨大 GETDATA 訊息的 DoS +name: blog-disclose-getdata-cpu +id: zh_TW-blog-disclose-getdata-cpu +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 格式錯誤的 `GETDATA` 訊息可能在接收節點上觸發 100% CPU 使用率。修復程式於 2020 年 6 月 3 日在 Bitcoin Core 0.20.0 中發布。 +--- + +格式錯誤的 `GETDATA` 訊息可能在接收節點上觸發無限迴圈，使用分配給此執行緒的 100% CPU，並且不在此連線上取得進一步進展。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +在 Bitcoin Core 0.20.0 之前，攻擊者（甚至是有錯誤的客戶端）可以向我們發送一個 `GETDATA` 訊息，這將導致我們的 net_processing 執行緒開始以 100% 的速度旋轉，並且不再為攻擊者對等節點處理訊息取得進展。它仍然會為其他對等節點處理訊息取得進展，所以除此之外它只是一個 CPU DoS，影響很小（不為攻擊者對等節點取得進展不是問題）。它還將每個攻擊者對等節點的長期記憶體使用量增加了 1.5 MB。 + +John Newbery 開啟 [PR #18808](https://github.com/bitcoin/bitcoin/pull/18808) 以修復此問題，僅披露缺乏進展。 + +## 歸屬 + +感謝 John Newbery 發現此錯誤、負責任地披露它並修復它。 + +## 時間表 + +- 2020-04-29 John Newbery 開啟 #18808 +- 2020-05-08 John Newbery 透過電子郵件報告他的發現 +- 2020-05-12 #18808 被合併 +- 2020-06-03 Bitcoin Core 版本 0.20.0 發布，包含修復程式 +- 2021-09-13 最後一個易受影響的 Bitcoin Core 版本（0.19.x）終止支援 +- 2024-07-03 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-header-spam.md b/_posts/zh_TW/posts/2024-07-03-disclose-header-spam.md new file mode 100644 index 000000000..46aab375c --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-header-spam.md @@ -0,0 +1,42 @@ +--- +title: CVE-2024-52916 - 使用低難度標頭的記憶體 DoS +name: blog-disclose-header-spam-checkpoint-bypass +id: zh_TW-blog-disclose-header-spam-checkpoint-bypass +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點可能被低難度標頭垃圾訊息淹沒，這可能被用來崩潰它。修復程式於 2017 年 9 月 14 日在 Bitcoin Core 0.15.0 中發布。 +--- + +在 Bitcoin Core 0.12.0 之後和 Bitcoin Core 0.15.0 之前，節點可能被最低難度標頭垃圾訊息淹沒，這可能被利用透過 OOM 崩潰它。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +在引入[標頭預同步](https://github.com/bitcoin/bitcoin/pull/25717)之前，節點完全依賴檢查點來避免被低難度標頭垃圾訊息淹沒。 + +在 Bitcoin Core 0.12.0 中，檢查在最後一個檢查點高度之前分叉的標頭的檢查被移動到將標頭儲存在 `mapBlockIndex` 之後。這允許攻擊者透過垃圾訊息發送其父節點是創世區塊（只需要難度 1 來建立）的標頭來無限制地增長映射，因為這些區塊繞過了檢查點邏輯。 + +## 歸屬 + +感謝 Cory Fields 發現並負責任地披露該錯誤。 + +## 時間表 + +- 2017-08-08 Cory Fields 私下報告該錯誤 +- 2017-08-11 Pieter Wuille 開啟 [PR #11028](https://github.com/bitcoin/bitcoin/pull/11028) 以修復它 +- 2017-08-14 PR #11028 被合併 +- 2017-09-14 Bitcoin Core 版本 0.15.0 發布，包含修復程式 +- 2018-10-03 最後一個易受影響的 Bitcoin Core 版本（0.14.3）終止支援 +- 2024-07-03 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-inv-buffer-blowup.md b/_posts/zh_TW/posts/2024-07-03-disclose-inv-buffer-blowup.md new file mode 100644 index 000000000..8ee0cd058 --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-inv-buffer-blowup.md @@ -0,0 +1,42 @@ +--- +title: CVE-2024-52915 - 使用巨大 INV 訊息的記憶體 DoS +name: blog-disclose-inv-buffer-blowup +id: zh_TW-blog-disclose-inv-buffer-blowup +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點會為每個傳送惡意 `INV` 訊息的攻擊者分配最多 50 MB 的記憶體。修復程式於 2020 年 6 月 3 日在 Bitcoin Core 0.20.0 中發布。 +--- + +節點可能被迫在接收到特別建構的 `INV` 訊息時分配大量記憶體。對於可用記憶體很少或連線數量很大的節點來說，這是一個特別的問題。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +填充 50,000 個區塊項目的 `INV` 訊息可能導致在單個 `ProcessMessages()` 呼叫中傳送 50,000 個 `getheaders` 回應。每個回應包含一個定位器，約 1 kB。所有這些都會立即放入傳送緩衝區。攻擊者可以只是拒絕接收資料以防止 50 MB 緩衝區排空。 + +John Newbery 開啟 [PR #18962](https://github.com/bitcoin/bitcoin/pull/18962) 以修復此問題，假託從每個接收的 `INV` 傳送單個 `GETHEADERS` 可以獲得頻寬增益。 + +## 歸屬 + +感謝 John Newbery 發現此錯誤、負責任地披露它並修復它。 + +## 時間表 + +- 2020-05-08 John Newbery 透過電子郵件報告他的發現 +- 2020-05-12 John Newbery 開啟 #18962 +- 2020-05-14 #18962 被合併 +- 2020-06-03 Bitcoin Core 版本 0.20.0 發布，包含修復程式 +- 2021-09-13 最後一個易受影響的 Bitcoin Core 版本（0.19.x）終止支援 +- 2024-07-03 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-orphan-dos.md b/_posts/zh_TW/posts/2024-07-03-disclose-orphan-dos.md new file mode 100644 index 000000000..314f74bc3 --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-orphan-dos.md @@ -0,0 +1,45 @@ +--- +title: CVE-2024-52914 - 由於孤兒處理導致的重大 DoS +name: blog-disclose-orphan-dos +id: zh_TW-blog-disclose-orphan-dos +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點在接收到特別建構的未確認交易時可能會停滯數小時。修復程式於 2019 年 5 月 18 日在 Bitcoin Core 0.18.0 中發布。 +--- + +節點在處理特別建構的未確認交易的孤兒時可能會停滯數小時。 + +此問題被認為是**高**嚴重性。 + +## 細節 + +在將交易接受到其記憶池後，節點將瀏覽其孤兒交易快取，以找出這個新接受的交易是否使接受任何交易成為可能。此搜尋是二次方的：對於新接受的交易中的每個輸出，它將瀏覽所有快取的孤兒交易（限制為 100）。透過特別建構孤兒交易為無效但驗證昂貴，節點可能會停滯數小時。 + +停滯由 Pieter Wuille 在 [PR #15644](https://github.com/bitcoin/bitcoin/pull/15644) 中修復，透過在找到匹配時中斷孤兒解析以處理新訊息（無論孤兒最終是否有效）。 + +## 歸屬 + +感謝 sec.eine 負責任地披露該錯誤並提供關於修復程式的回饋。 + +## 時間表 + +- 2019-03-19 sec.eine 透過電子郵件向 Greg Maxwell 報告問題 +- 2019-03-21 Greg Maxwell 回應有關建議修補程式的資訊 +- 2019-03-22 sec.eine 對修補程式給出回饋（「看起來很穩固且 [..] 不會引起注意」） +- 2019-03-22 Pieter Wuille 開啟 PR #15644 +- 2019-04-01 PR #15644 被合併 +- 2019-05-18 Bitcoin Core 版本 0.18.0 發布，包含修復程式 +- 2020-07-22 在 PR 審查俱樂部期間[部分披露](https://bitcoincore.reviews/15644#l-285)該問題 +- 2020-08-01 最後一個易受影響的 Bitcoin Core 版本（0.17.x）終止支援 +- 2024-07-03 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-timestamp-overflow.md b/_posts/zh_TW/posts/2024-07-03-disclose-timestamp-overflow.md new file mode 100644 index 000000000..7ceaaab5a --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-timestamp-overflow.md @@ -0,0 +1,43 @@ +--- +title: CVE-2024-52912 - 由於時間戳記調整導致的網路分裂 +name: blog-disclose-timestamp-overflow +id: zh_TW-blog-disclose-timestamp-overflow +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點在被其前 200 個對等節點攻擊時可能會與網路分裂。修復程式於 2021 年 1 月 15 日在 Bitcoin Core 版本 0.21.0 中發布。 +--- + +披露一個整數溢位錯誤的細節，該錯誤有引起網路分裂的風險，修復程式於 2021 年 1 月 15 日在 Bitcoin Core 版本 0.21.0 中發布。 + +此問題被認為是**中等**嚴重性。 + +## 技術細節 + +網路分裂漏洞源於 `version` 訊息處理程式碼中的兩個獨立錯誤： +* 計算新連線對等節點的時間偏移時的有號整數溢位。 +* abs64 邏輯錯誤（`abs64(std::numeric_limits::min()) == std::numeric_limits::min()`），導致繞過最大時間調整限制。 + +這兩個錯誤允許攻擊者強制受害者的調整時間（`系統時間 + 網路時間偏移`）被偏斜，使得任何新區塊因時間戳記過於未來而被拒絕。應該注意的是，此攻擊假設攻擊者在連線到受害者的前 200 個對等節點中，因為只有來自這些初始連線的時間偏移才會被納入調整時間。 + +## 歸屬 + +感謝 [practicalswift](https://github.com/practicalswift) 發現並提供漏洞的初始修復程式，以及 Pieter Wuille 提供修復程式以及對風險程式碼的一般清理。 + +## 時間表 + +* 2020-10-10 初始報告傳送到 security@bitcoincore.org +* 2020-10-13 修復程式合併到 Bitcoin Core (https://github.com/bitcoin/bitcoin/pull/20141) +* 2021-01-15 v0.21.0 發布 +* 2022-04-25 最後一個易受影響的 Bitcoin Core 版本（0.20.x）終止支援 +* 2024-07-03 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose-unbounded-banlist.md b/_posts/zh_TW/posts/2024-07-03-disclose-unbounded-banlist.md new file mode 100644 index 000000000..bda4f21d9 --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose-unbounded-banlist.md @@ -0,0 +1,46 @@ +--- +title: CVE-2020-14198 披露 +name: blog-disclose-unbounded-banlist +id: zh_TW-blog-disclose-unbounded-banlist +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點在受到大量不同 IP 攻擊時可能會受到 CPU 和記憶體 DoS 的影響。修復程式於 2020 年 8 月 1 日在 Bitcoin Core 0.20.1 中發布。 +--- + +Bitcoin Core 維護了一個無限制的禁止 IP 地址列表，並對其執行二次方操作。這可能導致 OOM 崩潰和 CPU DoS。 + +此問題被認為是**高**嚴重性。 + +## 細節 + +Bitcoin Core 維護了一個禁止 IP 地址列表。此列表沒有界限，可以被對手操縱。考慮到 IPV6，為攻擊者向此列表新增新條目特別便宜。此外，在接收到 `GETADDR` 訊息時，Bitcoin Core 會掃描整個禁止列表以檢查要返回的每個地址（最多 2500 個）。 + +## 歸屬 + +Calin Culianu 首先負責任地披露它。Calin 後來在 [PR 評論](https://github.com/bitcoin/bitcoin/pull/15617#issuecomment-640898523)中公開披露了該錯誤。 + +同一天，Bitcoin ABC 的 Jason Cox 透過電子郵件與 Bitcoin Core 專案分享了他們也收到的同一報告。 + +## 時間表 + +- 2020-06-08 Calin Culianu 私下向 Bitcoin Core 專案報告該錯誤 +- 2020-06-08 Jason Cox 私下與 Bitcoin Core 分享傳送給 Bitcoin ABC 的（同一）報告 +- 2020-06-08 Calin Culianu 在引入二次方行為的原始 PR 上公開披露該漏洞 +- 2020-06-09 Pieter Wuille 開啟 PR [#19219](https://github.com/bitcoin/bitcoin/pull/19219)，修復了無界記憶體使用和二次方行為 +- 2020-06-16 Luke Dashjr 在他的請求後被分配 CVE-2020-14198 用於此漏洞 +- 2020-07-07 Pieter 的 PR 被合併 +- 2020-08-01 Bitcoin Core 0.20.1 發布，包含修復程式 +- 2021-01-14 Bitcoin Core 0.21.0 發布，包含修復程式 +- 2022-04-25 最後一個易受影響的 Bitcoin Core 版本（0.20.0）終止支援 +- 2024-07-03（官方）公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose_already_asked_for.md b/_posts/zh_TW/posts/2024-07-03-disclose_already_asked_for.md new file mode 100644 index 000000000..6553941da --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose_already_asked_for.md @@ -0,0 +1,51 @@ +--- +title: CVE-2024-52913 - 由於交易重新請求處理導致的審查 +name: blog-disclose-already-asked-for +id: zh_TW-blog-disclose-already-asked-for +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 2 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 惡意對等節點可以阻止節點看到特定的未確認交易。修復程式於 2021 年 1 月 14 日在 Bitcoin Core 0.21.0 中發布。 +--- + +攻擊者可以阻止節點看到特定的未確認交易。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +在 PR 19988 修復此問題之前，「g_already_asked_for」機制用於排程交易的 `GETDATA` 請求。`SendMessages()` 函式會為對等節點最近公告的交易發出 `GETDATA`，記住該請求在 `g_already_asked_for` 中的發送時間。然而，這個 `g_already_asked_for` 是一個「limitedmap」資料結構，具有有界大小，如果達到 50000 個條目，將忘記最舊的條目。這使得以下攻擊成為可能： +* 攻擊者是第一個向受害者公告合法交易 T 的人。 +* 受害者使用 `GETDATA` 從攻擊者請求 T。 +* 攻擊者在接近受害者將從其他對等節點請求 T 的時間（約 60 秒）之前不回應 `GETDATA`。 +* 然後，攻擊者仔細地向受害者發送虛假公告垃圾訊息，導致受害者的 `g_already_asked_for` 驅逐 T。 +* 攻擊者再次向受害者公告 T（由於 `m_tx_process_time` 中的佇列工作方式，這不需要特別精確的時間）。 +* 受害者在 `g_already_asked_for` 中找不到 T，會將其視為新公告，向攻擊者發送新的 `GETDATA`。 +* 攻擊者再次不回應 `GETDATA`。 +* 等等。 + +這樣，攻擊者可以阻止受害者從除攻擊者之外的任何人請求交易。 + +## 歸屬 + +由 John Newbery 負責任地披露，聲稱由 Amiti Uttarwar 和他發現。 + +## 時間表 + +- 2020-04-03 John Newbery 在一封電子郵件中向 Suhas Daftuar 和其他人報告該錯誤 +- 2020-05-08 John Newbery 建議修復該錯誤的方法 +- 2020-09-21 Pieter Wuille 開啟 [PR #19988](https://github.com/bitcoin/bitcoin/pull/19988) 作為修復此錯誤和其他錯誤的綜合方法 +- 2020-10-14 Pieter 的 PR 被合併 +- 2021-01-14 Bitcoin Core 版本 0.21.0 發布，包含修復程式 +- 2022-04-25 最後一個易受影響的 Bitcoin Core 版本（0.20.x）終止支援 +- 2024-07-03 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose_receive_buffer_oom.md b/_posts/zh_TW/posts/2024-07-03-disclose_receive_buffer_oom.md new file mode 100644 index 000000000..4745c368f --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose_receive_buffer_oom.md @@ -0,0 +1,46 @@ +--- +title: CVE-2015-3641 披露 +name: blog-disclose-receive-buffer-oom +id: zh_TW-blog-disclose-receive-buffer-oom +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者傳送大型不完整訊息會導致高記憶體使用量。修復程式於 2015 年 4 月 27 日在 Bitcoin Core 0.10.1 中發布。 +--- + +節點可能被迫在接收訊息時分配大型緩衝區，這可能被利用透過 OOM 遠端崩潰它。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +在沒有更嚴格的界限的情況下，接收訊息的大小受限於最大序列化訊息大小 32 MiB。攻擊者可以強制節點為每個連線分配這麼多 RAM，這可能導致 OOM。 + +[PR #5843](https://github.com/bitcoin/bitcoin/pull/5843) 減少了 P2P 訊息在接收有效載荷之前可以擁有的大小。這減少了惡意對等節點可以導致的每個對等節點接收緩衝區記憶體大小。該 PR 將數字從 32 MiB 減少到 2 MiB，後來作為 Segwit BIP144 變更的一部分增加回 4 MB。 + +## 歸屬 + +由 bitcointalk 使用者 Evil-Knievel 向 Greg Maxwell 報告。由 Pieter Wuille 修復。 + +## 時間表 + +- 2015-02-05 Evil-Knievel 透過 bitcointalk 私人訊息向 Greg Maxwell 報告該漏洞。 +- 2015-??-?? 為其註冊 `CVE-2015-3641`。 +- 2015-03-01 開啟 [PR #5843](https://github.com/bitcoin/bitcoin/pull/5843) 以修復它。 +- 2015-03-06 PR #5843 被合併。 +- 2015-03-09 修復程式被回移植到版本 0.10.1。 +- 2015-04-27 Bitcoin Core 版本 [0.10.1 發布](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007828.html)，包含修復程式。 +- 2015-06-25 披露被[預先宣布](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009135.html)。 +- 2015-07-07 披露被[推遲](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009362.html)。 +- 2016-08-23 最後一個易受影響的 Bitcoin Core 版本（0.10.x）終止支援 +- 2024-07-03 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-03-disclose_upnp_rce.md b/_posts/zh_TW/posts/2024-07-03-disclose_upnp_rce.md new file mode 100644 index 000000000..4f17add1f --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-03-disclose_upnp_rce.md @@ -0,0 +1,47 @@ +--- +title: CVE-2015-20111 - 由於 miniupnpc 中的錯誤導致遠端程式碼執行 +name: blog-disclose-upnp-rce +id: zh_TW-blog-disclose-upnp-rce +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + miniupnpc 程式庫中的錯誤可能導致 Bitcoin Core 中的遠端程式碼執行。修復程式於 2015 年 10 月 15 日在 Bitcoin Core 0.11.1 中發布。 +--- + +在 `miniupnpc` 中發現了一個啟用重大資料洩漏的緩衝區溢位。結合當時最近披露的 CVE-2015-6031，它在 `miniupnpc` 中啟用了 RCE，這可能導致 Bitcoin Core 中的 RCE。這在 2016 年 2 月發布的 [Bitcoin Core 0.12](https://bitcoincore.org/zh_TW/releases/0.12.0/) 中得到修復。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +[CVE-2015-6031](https://nvd.nist.gov/vuln/detail/CVE-2015-6031)，於 2015 年 9 月披露，使惡意 UPnP 伺服器有可能在啟動時遠端崩潰本機網路上的 Bitcoin Core 程序。詳情請參見[此處](https://nvd.nist.gov/vuln/detail/CVE-2015-6031)。該修復程式在 [Bitcoin Core 中拉取](https://github.com/bitcoin/bitcoin/pull/6789)，並在 2015 年 10 月發布的[版本 0.11.1](https://bitcoincore.org/zh_TW/releases/0.11.1/) 中發布。UPnP 隨後[預設關閉](https://github.com/bitcoin/bitcoin/pull/6795)。 + +CVE-2015-6031 披露了一個緩衝區溢位，除了啟用遠端崩潰之外，還可能使遠端在受害者的機器上執行程式碼成為可能。在調查這種可能性時，Wladimir J. Van Der Laan 在 `miniupnpc` 中發現了另一個啟用重大資料洩漏的緩衝區溢位。這在提交 `4c90b87ce3d2517097880279e8c3daa7731100e6` 中由 [Wladimir 在 `miniupnpc` 中修復](https://github.com/miniupnp/miniupnp/pull/157)。該修復程式隨後[拉取到 Bitcoin Core](https://github.com/bitcoin/bitcoin/pull/6980) 中，並作為版本 0.12 的一部分發布。 + +此資料洩漏不會直接披露秘密資訊（例如錢包的私鑰）。但與另一個堆疊溢位（例如 CVE-2015-6031 中披露的那個）結合，這使得觸發遠端程式碼執行成為可能。Wladimir 針對 Ubuntu 的 `miniupnpc` 版本 `1.6-precise` 演示了這一點。然而，此漏洞利用中使用的特定方法並不直接可移植到 Bitcoin Core。 + +## 歸屬 + +感謝 Aleksandar Nikolic 識別 CVE-2015-0035，以及 Wladimir J. Van Der Laan 調查其影響並發現第二個緩衝區溢位。 + +## 時間表 + +- 2015-09-15 CVE-2015-0035 被[修復](https://github.com/miniupnp/miniupnp/commit/79cca974a4c2ab1199786732a67ff6d898051b78)並[披露](https://talosintelligence.com/vulnerability_reports/TALOS-2015-0035/)。 +- 2015-10-09 [PR #6789](https://github.com/bitcoin/bitcoin/pull/6789) 在 Bitcoin Core 中被合併 +- 2015-10-14 Wladimir 透過利用第二個緩衝區溢位的遠端程式碼執行向 Ubuntu 安全和 Bitcoin 開發者披露。 +- 2015-10-15 Bitcoin Core 0.11.1 [發布](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011545.html) +- 2015-10-26 第二個緩衝區溢位的修復程式[被合併](https://github.com/miniupnp/miniupnp/pull/157)到 `miniupnpc` 中。 +- 2015-12-18 該修復程式[被拉取到 Bitcoin Core](https://github.com/bitcoin/bitcoin/pull/6980)。 +- 2016-02-23 Bitcoin Core 版本 0.12 [發布](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012456.html)。 +- 2017-03-08 最後一個易受影響的 Bitcoin Core 版本（0.11.x）終止支援 +- 2024-07-03 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-09-release-26.2.md b/_posts/zh_TW/posts/2024-07-09-release-26.2.md new file mode 100644 index 000000000..15759a40c --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-09-release-26.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 26.2 版本發布 +name: blog-release-26.2 +id: zh_tw-blog-release-26.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 26.2 現已發布。 +--- +Bitcoin Core 26.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/26.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-31-disclose-addrman-int-overflow.md b/_posts/zh_TW/posts/2024-07-31-disclose-addrman-int-overflow.md new file mode 100644 index 000000000..29ce01a70 --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-31-disclose-addrman-int-overflow.md @@ -0,0 +1,38 @@ +--- +title: CVE-2024-52919 - 由於 addr 訊息垃圾導致的遠端崩潰 +name: blog-disclose-addrman-idcount-in-overflow +id: blog-disclose-addrman-idcount-in-overflow +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點可能被 addr 訊息垃圾淹沒，這可能被用來崩潰它們。修復程式於 2021 年 9 月 14 日在 Bitcoin Core v22.0 中發布。 +--- + +披露一個整數溢位錯誤的細節，該錯誤會導致斷言崩潰，修復程式於 2021 年 9 月 14 日在 Bitcoin Core 版本 v22.0 中發布。 + +此問題被認為是**高**嚴重性。 + +## 細節 + +`CAddrMan` 有一個 32 位元 `nIdCount` 欄位，每次插入 addrman 時都會遞增，然後成為新條目的識別碼。透過讓受害者插入 232 個條目（例如透過垃圾訊息發送 addr 訊息），此識別碼會溢位，導致斷言崩潰。 + +## 歸屬 + +感謝 Eugene Siegel 發現並披露該漏洞，以及 Pieter Wuille 在 https://github.com/bitcoin/bitcoin/pull/22387 中修復該問題。 + +## 時間表 + +* 2021-06-21 - Eugene Siegel 向 security@bitcoincore.org 傳送初始報告 +* 2021-07-19 - 修復程式被合併 (https://github.com/bitcoin/bitcoin/pull/22387) +* 2021-09-13 - v22.0 發布 +* 2024-07-31 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-07-31-disclose-upnp-oom.md b/_posts/zh_TW/posts/2024-07-31-disclose-upnp-oom.md new file mode 100644 index 000000000..afc5adfab --- /dev/null +++ b/_posts/zh_TW/posts/2024-07-31-disclose-upnp-oom.md @@ -0,0 +1,41 @@ +--- +title: CVE-2024-52917 - miniupnp 依賴項中的無限迴圈錯誤 +name: blog-disclose-miniupnp-bug-impact +id: zh_TW-blog-disclose-miniupnp-bug-impact +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 節點可能被本機網路上的惡意 UPnP 裝置崩潰。修復程式於 2021 年 9 月 14 日在 Bitcoin Core v22.0 中發布。 +--- + +披露 miniupnp 依賴項中無限迴圈錯誤對 Bitcoin Core 的影響，修復程式於 2021 年 9 月 14 日在 Bitcoin Core 版本 v22.0 中發布。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +Bitcoin Core 使用的 UPnP 程式庫 Miniupnp，只要從網路上的裝置接收到隨機資料，就會在發現時一直等待。此外，它會為每個新裝置資訊分配記憶體。本機網路上的攻擊者可以假裝是 UPnP 裝置，並不斷向 Bitcoin Core 節點傳送膨脹的 M-SEARCH 回覆，直到其記憶體耗盡。 + +只有使用 -miniupnp 選項執行的使用者才會受到此錯誤的影響，因為 Miniupnp 預設是關閉的。 + +## 歸屬 + +感謝 Ronald Huveneers 向 miniupnp 專案報告無限迴圈錯誤，以及 Michael Ford (Fanquake) 向 Bitcoin Core 專案報告並提供 PoC 漏洞利用以觸發 OOM 以及提升依賴項（包含修復程式）的拉取請求。 + +## 時間表 + +* 2020-09-17 - Ronald Huveneers 向 miniupnp 初始報告無限迴圈錯誤 +* 2020-10-13 - Michael Ford 向 security@bitcoincore.org 傳送初始報告 +* 2021-03-23 - 修復程式被合併 (https://github.com/bitcoin/bitcoin/pull/20421) +* 2021-09-13 - v22.0 發布 +* 2024-07-31 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-09-18-disclose-headers-oom.md b/_posts/zh_TW/posts/2024-09-18-disclose-headers-oom.md new file mode 100644 index 000000000..ad3a393cd --- /dev/null +++ b/_posts/zh_TW/posts/2024-09-18-disclose-headers-oom.md @@ -0,0 +1,69 @@ +--- +title: CVE-2019-25220 - 由於標頭垃圾導致的記憶體 DoS +name: blog-disclose-headers-oom +id: zh_TW-blog-disclose-headers-oom +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者可以向 Bitcoin Core 節點垃圾發送低難度標頭鏈，這可以被用來遠端崩潰它。 +--- + +在 Bitcoin Core v24.0.1 之前，攻擊者可以向節點垃圾發送低難度標頭鏈，這可以被用來遠端崩潰對等節點。 + +此問題被認為是**高**嚴重性。 + +## 細節 + +Bitcoin Core 將區塊鏈標頭儲存在記憶體中。這使其容易受到 DoS 攻擊，透過讓它下載和儲存極長的標頭鏈，即使它們是低難度的。重要的是要注意，一旦製作完成，攻擊鏈可以被重複使用來崩潰網路上的任何節點。 + +使用此方法攻擊節點的可能性早已為人所知，這是檢查點系統仍然存在的主要原因：讓攻擊者從最後一個檢查點開始攻擊，使其成本遠高於從創世區塊開始。然而，隨著時間推移，隨著算力成本的降低，即使這種緩解措施也變得不那麼有效。 + +此攻擊於 2019 年 1 月由 David Jaenson 獨立發現並向 Bitcoin Core 專案報告，他建議引入更新的檢查點作為實用的緩解措施。然而： +1. 這仍然使執行 IBD 的節點在收到檢查點區塊之前沒有保護。 +2. 它依賴於生態系統半定期採用包含新檢查點的更新軟體，這是 Bitcoin Core 貢獻者長期以來不太願意接受的做法。 + +當 Braydon Fuller 於 2019 年 10 月在 bitcoin-dev 郵件列表上[發布他的「鏈寬擴展」報告](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017354.html)時，它引起了更多關注。他之前已經負責任地向 Bitcoin Core 安全列表報告過。由於對限制平行鏈數量時網路收斂的擔憂，所建議的方法未被 Bitcoin Core 採用。 + +當時，建立一個巨大的低難度標頭鏈的計算成本約等於在頂端挖掘一個區塊的 32.28%。這是約 4.12 BTC 的成本，因為當時的區塊獎勵約為 12.77 BTC。 + +到 2022 年 2 月，攻擊成本進一步下降到挖掘一個區塊成本的約 14.73%，這促使對替代解決方案的調查。如果不加以解決，今天（2024 年 9 月）的成本將僅為一個區塊的 4.44%。考慮到這些日期的區塊獎勵，這些數字分別轉化為約 1.07 BTC 和 0.14 BTC 的成本。 + +針對此 DoS 的保護措施在 Bitcoin Core PR [#25717](https://github.com/bitcoin/bitcoin/pull/25717) 中實作，節點將首先驗證所呈現的鏈是否有足夠的工作量，然後再承諾儲存它。這樣，Bitcoin Core 不再依賴檢查點來防禦任何已知攻擊。 + +## 歸屬 + +感謝 David Jaenson 和 Braydon Fuller 獨立重新發現該攻擊，估計其成本並建議修改。 + +感謝 Suhas Daftuar 和 Pieter Wuille 研究令人滿意的修復程式並實作它。 + +## 時間表 + +* 2010-07-17 - Bitcoin 0.3.2 發布，引入檢查點。它們保護包括低難度區塊垃圾在內的其他威脅。 +* 2011-11-21 - Bitcoin 0.5.0 發布，跳過最後一個檢查點之前的區塊的腳本驗證。這使得檢查點的作用更加安全關鍵。 +* 2014-04-09 - 區塊 295000 被挖掘，成為最後一個 Bitcoin Core 檢查點。隨著算力成本降低，檢查點對區塊垃圾的保護從這一點開始侵蝕。 +* 2015-02-16 - Bitcoin Core 0.10.0 發布，具有標頭優先同步。這將低難度區塊垃圾攻擊弱化為區塊*標頭*垃圾攻擊。 +* 2017-03-08 - Bitcoin Core 0.14.0 發布，將跳過腳本驗證與檢查點分離，使它們僅與防禦區塊標頭垃圾相關。 +* 2019-01-28 - David Jaenson 向 Bitcoin Core 安全郵件列表報告此問題。 +* 2019-09-18 - Braydon Fuller 向 Bitcoin Core 安全列表傳送電子郵件，標題為「[Bitcoin 鏈寬擴展拒絕服務攻擊](https://bcoin.io/papers/bitcoin-chain-expansion.pdf)」，討論區塊和區塊標頭垃圾的危險、成本分析和建議的解決方案。 +* 2019-09-26 - Suhas Daftuar 回覆 Braydon Fuller 這是一個已知問題，並邀請他將他的報告發布到 bitcoin-dev 郵件列表。 +* 2019-10-04 - Braydon Fuller 將他的論文傳送到 bitcoin-dev 郵件列表。 +* 2019-10-31 - 作為對上述事件的回應，Suhas Daftuar 開啟 PR [#17332](https://github.com/bitcoin/bitcoin/pull/17332)，其中包含他早期但不實用的概念驗證，希望引起更多關於該主題的討論。 +* 2022-02 - Suhas Daftuar 和 Pieter Wuille 討論此問題，並估計此攻擊的成本現在實際上已經變得如此之低，以至於需要立即採取行動，並需要避免公開談論它。 +* 2022-06-22 - Suhas Daftuar 開啟 PR [#25454](https://github.com/bitcoin/bitcoin/pull/25454) 作為實作修復程式的準備工作。 +* 2022-06-22 - Suhas Daftuar 向一群長期貢獻者傳送訊息，詳細說明攻擊、其成本以及 Pieter Wuille 和他一直在研究的修復程式。 +* 2022-07-26 - Suhas Daftuar 開啟 PR [#25717](https://github.com/bitcoin/bitcoin/pull/25717)，與 Pieter Wuille 共同撰寫，實作修復程式。 +* 2022-08-30 - PR #25717 被合併。 +* 2022-10-21 - Niklas Gögge 的 PR [#26355](https://github.com/bitcoin/bitcoin/pull/26355) 被合併，修復了 PR #25717 中引入的標頭預同步步驟中的錯誤。如果沒有這個，仍然可能垃圾發送區塊標頭。發現此錯誤以及可能存在未發現的錯誤的可能性，是舊檢查點尚未完全刪除的原因。 +* 2022-12-12 - Bitcoin Core 24.0.1 發布，包含修復程式。 +* 2023-12-07 - 最後一個易受影響的 Bitcoin Core 版本（23.2）終止支援。 +* 2024-09-18 - 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-10-02-release-28.0.md b/_posts/zh_TW/posts/2024-10-02-release-28.0.md new file mode 100644 index 000000000..6c4d6e714 --- /dev/null +++ b/_posts/zh_TW/posts/2024-10-02-release-28.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 28.0 版本發布 +name: blog-release-28.0 +id: zh_tw-blog-release-28.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 28.0 現已發布。 +--- +Bitcoin Core 28.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/28.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-10-08-disclose-blocktxn-crash.md b/_posts/zh_TW/posts/2024-10-08-disclose-blocktxn-crash.md new file mode 100644 index 000000000..4b6864b31 --- /dev/null +++ b/_posts/zh_TW/posts/2024-10-08-disclose-blocktxn-crash.md @@ -0,0 +1,44 @@ +--- +title: CVE-2024-35202 披露 +name: blog-disclose-blocktxn-crash +id: zh_TW-blog-disclose-blocktxn-crash +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者可以透過觸發 blocktxn 訊息處理邏輯中的斷言來遠端崩潰 Bitcoin Core 節點。 +--- + +在 Bitcoin Core v25.0 之前，攻擊者可以透過觸發 blocktxn 訊息處理邏輯中的斷言來遠端崩潰 Bitcoin Core 節點。 + +此問題被認為是**高**嚴重性。 + +## 細節 + +當透過 cmpctblock 訊息接收到區塊公告時，Bitcoin Core 嘗試使用其自己記憶池中的交易以及其他可用的交易來重建公告的區塊。如果由於缺少交易而重建失敗，它將透過 getblocktxn 訊息從公告對等節點請求它們。作為回應，預期會收到 blocktxn 訊息，其中應包含所請求的交易。 + +緊湊區塊協定採用縮短的交易識別碼來減少頻寬。這些短 ID 大小為 6 位元組，在區塊重建時導致碰撞的小機率（即交易 A 與交易 B 具有相同的短 ID）。碰撞將被檢測到，因為從重建的交易集計算的默克爾根將與區塊公告中的默克爾根不匹配。對等節點不應因碰撞而受到懲罰，因為它們可能偶然發生，因此透過回退到請求完整區塊來處理它們。 + +Bitcoin Core 將在每次收到新的緊湊區塊時建立一個 PartiallyDownloadedBlock 實例。如果請求缺少的交易，該實例將保持到處理相應的 blocktxn 訊息為止。收到 blocktxn 訊息後，將呼叫 PartiallyDownloadedBlock::FillBlock，嘗試重建完整區塊。在上述碰撞情況下，請求完整區塊，但 PartiallyDownloadedBlock 實例以及與底層區塊請求相關的其他狀態保持不變。這為同一區塊的第二個 blocktxn 訊息留下了處理空間，並觸發 FillBlock 再次被呼叫。這違反了 FillBlock 只能被呼叫一次的假設（記錄為 assert 陳述），並導致節點崩潰。 + +攻擊者不需要透過觸發碰撞來獲得幸運，因為碰撞處理邏輯可以透過簡單地在 blocktxn 訊息中包含未提交到區塊默克爾根的交易來輕鬆觸發。 + +## 歸屬 + +感謝 Niklas Gögge 發現和披露該漏洞，以及在 https://github.com/bitcoin/bitcoin/pull/26898 中修復該問題。 + +## 時間表 + +* 2022-10-05 - Niklas Gögge 向 Bitcoin Core 安全郵件列表報告該問題。 +* 2023-01-24 - 包含修復程式的 PR #26898 被合併。 +* 2023-05-25 - Bitcoin Core 25.0 發布，包含修復程式。 +* 2024-10-09 - 公開披露。 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-10-08-disclose-large-inv-to-send.md b/_posts/zh_TW/posts/2024-10-08-disclose-large-inv-to-send.md new file mode 100644 index 000000000..fec8dc0af --- /dev/null +++ b/_posts/zh_TW/posts/2024-10-08-disclose-large-inv-to-send.md @@ -0,0 +1,42 @@ +--- +title: 披露由於 inv-to-send 集合過大導致的 DoS +name: blog-disclose-large-inv-to-send +id: zh_TW-blog-disclose-large-inv-to-send +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security announcement. English posts only +announcement: 1 + +excerpt: > + inv-to-send 集合可能會增長得太大，以至於排序這些集合所花費的時間會影響節點與其對等節點通訊的能力。 +--- + +在 Bitcoin Core v25.0 之前，每個對等節點的 `m_tx_inventory_to_send` 集合可能會增長得太大，以至於在建構庫存訊息時排序這些集合會影響節點與其對等節點通訊的能力。2023 年 5 月初的網路狀況觸發了此 DoS，並影響了區塊和交易傳播。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +作為交易中繼的一部分，Bitcoin Core 維護每個對等節點的 `m_tx_inventory_to_send` 集合，其中包含應向對等節點公告的交易。在為對等節點建構庫存訊息時，該集合按交易依賴關係和費率排序，以優先處理高費率交易並避免洩漏節點了解交易的順序。在 Bitcoin Core v25.0 之前，在建構庫存訊息時，相關的（仍在記憶池中、尚未被對等節點向我們公告、高於費用篩選器）交易以每秒 7 個交易的速率被清空。 + +2023 年 5 月初，網路活動增加導致集合增長速度快於清空速度，導致在 P2P 通訊執行緒中花費大量時間排序集合。此外，只監聽交易公告但從不自己公告任何交易的對等節點（通常稱為「間諜節點」），透過擁有巨大的集合（包含它們已經知道的交易）而放大了這一點，這需要很長時間來排序。觀察到排序幾乎佔用了 P2P 通訊執行緒中花費的全部時間，這顯著影響了區塊和交易傳播以及保持與對等節點的連接。 + +這在 [#27610](https://github.com/bitcoin/bitcoin/pull/27610) 中得到修復，透過 1) 更早地刪除不再在記憶池中的交易，以及 2) 根據集合大小動態增加集合清空速率。 + +## 歸屬 + +感謝 Anthony Towns 修復該問題，以及 b10c 最初報告並將問題縮小到緩慢的 inv-to-send 排序。 + +## 時間表 + +- 2023-05-02 - 問題首次被觀察到並報告 +- 2023-05-11 - 修復程式被合併（[#27610](https://github.com/bitcoin/bitcoin/pull/27610)） +- 2023-05-25 - v25.0 發布 +- 2024-10-09 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-10-08-disclose-mutated-blocks-hindering-propagation.md b/_posts/zh_TW/posts/2024-10-08-disclose-mutated-blocks-hindering-propagation.md new file mode 100644 index 000000000..fbc797ead --- /dev/null +++ b/_posts/zh_TW/posts/2024-10-08-disclose-mutated-blocks-hindering-propagation.md @@ -0,0 +1,42 @@ +--- +title: CVE-2024-52921 - 由於變異區塊導致的區塊傳播受阻 +name: blog-disclose-mutated-blocks-hindering-propagation +id: zh_TW-blog-disclose-mutated-blocks-hindering-propagation +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security announcement. English posts only +announcement: 1 + +excerpt: > + 對等節點可以透過傳送變異區塊來阻礙區塊傳播。 +--- + +在 Bitcoin Core v25.0 之前，傳送變異區塊的對等節點可以清除同樣向我們公告該區塊的其他對等節點的下載狀態，這會阻礙區塊傳播。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +Bitcoin Core 將區塊視為變異，例如，當標頭中的默克爾根或幣基交易中的見證承諾與區塊中的交易不匹配時。 + +在 Bitcoin Core v25.0 之前，對等節點可以透過傳送未請求的變異區塊來清除其他對等節點的區塊下載狀態。例如，這對緊湊區塊中繼是一個問題。在接收到緊湊區塊並在等待 `getblocktxn` 請求的回應以重建完整區塊時，接收變異區塊會讓 Bitcoin Core 忘記緊湊區塊重建狀態。在變異區塊之後到達的 `blocktxn` 回應無法用於重建區塊。這阻礙了區塊傳播。 + +這在 [#27608](https://github.com/bitcoin/bitcoin/pull/27608) 中得到修復，透過確保對等節點只能影響其自己的區塊下載狀態，而不能影響其他對等節點的下載狀態。 + +## 歸屬 + +感謝 Suhas Daftuar 注意到該問題並修復它。 + +## 時間表 + +- 2023-05-08 - 在 [#bitcoin-core-dev IRC 頻道](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-05-08)中首次報告變異區塊問題。 +- 2023-05-10 - 修復程式被合併（[#27608](https://github.com/bitcoin/bitcoin/pull/27608)） +- 2023-05-25 - v25.0 發布 +- 2024-10-09 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-11-04-release-27.2.md b/_posts/zh_TW/posts/2024-11-04-release-27.2.md new file mode 100644 index 000000000..bba27fb1b --- /dev/null +++ b/_posts/zh_TW/posts/2024-11-04-release-27.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 27.2 版本發布 +name: blog-release-27.2 +id: zh_tw-blog-release-27.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 27.2 現已發布。 +--- +Bitcoin Core 27.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/27.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2024-11-05-cb-stall-hindering-propagation.md b/_posts/zh_TW/posts/2024-11-05-cb-stall-hindering-propagation.md new file mode 100644 index 000000000..0409fccad --- /dev/null +++ b/_posts/zh_TW/posts/2024-11-05-cb-stall-hindering-propagation.md @@ -0,0 +1,47 @@ +--- +title: CVE-2024-52922 - 由於停滯對等節點導致的區塊傳播受阻 +name: blog-disclose-stalling-peers-hindering-propagation +id: zh_TW-blog-disclose-stalling-peers-hindering-propagation +lang: zh_TW +type: advisory +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security announcement. English posts only +announcement: 1 + +excerpt: > + 對等節點可以透過首先公告區塊然後簡單地扣留區塊來阻礙區塊傳播。 +--- + +在 Bitcoin Core v25.1 之前，攻擊者可以導致節點不下載最新區塊。 + +此問題被認為是**中等**嚴重性。 + +## 細節 + +當透過標頭或緊湊區塊訊息接收到新的區塊公告時，接收節點會向傳遞的對等節點請求完整區塊或缺少的交易細節。如果公告對等節點隨後未按照對等節點對等節點協定的要求作出回應，受影響的 Bitcoin Core 節點將等待最多 10 分鐘，然後斷開對等節點連接並進行另一次區塊下載嘗試。如果攻擊者能夠建立多個傳入或傳出連接，則可以重複此過程。 + +延遲區塊傳遞可能會透過減慢網路收斂、使挖礦收益不太公平以及導致活性問題而導致網路降級。 + +此問題因最近披露的其他問題（例如[庫存堆積](https://bitcoincore.org/en/2024/10/08/disclose-large-inv-to-send/)）而進一步加劇，當記憶池相對異質時，不允許誠實對等節點機會性地重建緊湊區塊。 + +在 [#27626](https://github.com/bitcoin/bitcoin/pull/27626) 中引入了緩解措施，在 Bitcoin Core v26.0 中引入並向後移植到 v25.1。它確保可以同時從最多 3 個高頻寬緊湊區塊對等節點請求區塊，其中一個必須是傳出連接。 + +## 歸屬 + +由 Greg Sanders 報告和修復。 + +## 時間表 + +- 2023-05-08 - 使用者在 [#bitcoin-core-dev IRC 頻道](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-05-08)中報告區塊逾時 +- 2023-05-09 - 第一個描述該問題的 github issue https://github.com/bitcoin/bitcoin/issues/25258#issuecomment-1540028533 +- 2023-05-11 - 緩解 PR 開啟 https://github.com/bitcoin/bitcoin/pull/27626 +- 2023-05-24 - PR 在 Bitcoin Core v26.0 之前合併 +- 2023-05-25 - 向後移植到 Bitcoin Core v25.1 的 PR 合併 https://github.com/bitcoin/bitcoin/pull/27752 +- 2023-10-19 - Bitcoin Core v25.1 發布 +- 2024-11-05 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-01-09-release-28.1.md b/_posts/zh_TW/posts/2025-01-09-release-28.1.md new file mode 100644 index 000000000..a695ac6da --- /dev/null +++ b/_posts/zh_TW/posts/2025-01-09-release-28.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 28.1 版本發布 +name: blog-release-28.1 +id: zh_tw-blog-release-28.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 28.1 現已發布。 +--- +Bitcoin Core 28.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/28.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-04-14-release-29.0.md b/_posts/zh_TW/posts/2025-04-14-release-29.0.md new file mode 100644 index 000000000..01268760a --- /dev/null +++ b/_posts/zh_TW/posts/2025-04-14-release-29.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 29.0 版本發布 +name: blog-release-29.0 +id: zh_tw-blog-release-29.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 29.0 現已發布。 +--- +Bitcoin Core 29.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/29.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-04-28-disclose-cve-2024-52919.md b/_posts/zh_TW/posts/2025-04-28-disclose-cve-2024-52919.md new file mode 100644 index 000000000..f57c661a7 --- /dev/null +++ b/_posts/zh_TW/posts/2025-04-28-disclose-cve-2024-52919.md @@ -0,0 +1,47 @@ +--- +title: CVE-2024-52919 - 由於 addr 訊息垃圾導致的遠端崩潰（第 2 部分） +name: blog-disclose-cve-2024-52919 +id: zh_TW-blog-disclose-cve-2024-52919 +lang: zh_TW +type: advisory +layout: post +redirect_from: + - /zh_TW/2025/03/31/disclose-cve-2024-52919 + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者可以透過長時間向節點垃圾發送 `addr` 訊息來崩潰節點。修復程式於 2025 年 4 月 14 日在 Bitcoin Core v29.0 中發布。 +--- + +披露一個整數溢位錯誤的細節，如果節點長時間（數年）持續被垃圾發送 `addr` 訊息，該錯誤會導致崩潰。修復程式於 2025 年 4 月 14 日在 Bitcoin Core v29.0 中發布。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +Bitcoin Core 中的地址管理器為每個條目使用 32 位元識別碼，在每次插入時遞增。[早期的安全公告](https://bitcoincore.org/en/2024/07/31/disclose-addrman-int-overflow)解釋了它如何使攻擊者能夠透過向節點垃圾發送 `addr` 訊息直到 32 位元識別碼溢位來遠端觸發斷言失敗。 + +這在 Bitcoin Core v22.0 中透過將地址管理器中的插入速率限制為每個對等節點每 10 秒 1 個地址來部分解決。這使得攻擊的成本大大增加，即使不是不切實際：即使有 1000 個對等節點持續攻擊，仍然需要一年多的時間才能使 32 位元識別碼溢位。 + +剩餘的、成本更高的攻擊向量在 Bitcoin Core 版本 29.0 中透過將識別碼變為 64 位元識別碼來解決。 + +## 歸屬 + +感謝 Eugene Siegel 發現並披露該漏洞，以及 Martin Zumsande 將識別碼更改為 64 位元。 + +## 時間表 + +* 2021-06-21 - Eugene Siegel 向 security@bitcoincore.org 傳送初始報告 +* 2021-07-19 - 速率限制在 PR [#22387](https://github.com/bitcoin/bitcoin/pull/22387) 中合併 +* 2021-09-13 - v22.0 發布，包含速率限制 +* 2024-07-31 - 發布[第一個安全公告](https://bitcoincore.org/en/2024/07/31/disclose-addrman-int-overflow) +* 2024-09-20 - 更改為 64 位元識別碼在 PR [#30568](https://github.com/bitcoin/bitcoin/pull/30568) 中合併 +* 2025-04-14 - Bitcoin Core v29.0 發布，包含 64 位元識別碼 +* 2025-04-28 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-06-06-relay-statement.md b/_posts/zh_TW/posts/2025-06-06-relay-statement.md new file mode 100644 index 000000000..9487cdcbe --- /dev/null +++ b/_posts/zh_TW/posts/2025-06-06-relay-statement.md @@ -0,0 +1,64 @@ +--- +title: Bitcoin Core 開發和交易中繼策略 +permalink: /zh_TW/2025/06/06/relay-statement/ +lang: zh_TW +id: zh_TW-relay-statement +name: relay-statement +type: posts +layout: post +version: 1 +--- + +我們想分享我們對 Bitcoin Core 開發與網路上交易中繼策略之間關係的看法。 + +Bitcoin 是一個由其使用者定義的網路，他們在選擇使用什麼軟體（完全驗證或非完全驗證）和實作他們想要的任何策略方面擁有最終自由。Bitcoin Core 貢獻者無權規定這些策略是什麼。這反映在我們長期以來避免在軟體中自動更新的做法中。這意味著沒有任何實體可以單方面向 Bitcoin Core 使用者推送變更：變更必須由使用者自己選擇採用新的軟體版本，或者如果他們願意，採用不同的軟體。自由執行任何軟體是網路對抗強制的主要保障。 + +作為 Bitcoin Core 開發者，我們也認為我們有責任使我們的軟體盡可能有效和可靠地為其目的服務，即在 Bitcoin 點對點網路中驗證和中繼區塊和交易，以便 Bitcoin 作為去中心化數位貨幣取得成功。關於交易中繼，這可能包括新增阻斷服務（DoS）保護和手續費評估的策略，但不會阻止中繼有持續經濟需求且可靠地進入區塊的交易。交易中繼的目標包括： + +* 預測將被挖掘的交易（例如用於手續費估算或手續費提升，但它也是節點軟體內許多 DoS 保護策略的基礎）； +* 加快我們預期被挖掘的交易的區塊傳播。減少延遲有助於防止大型礦工獲得不公平的優勢； +* 幫助礦工了解付費交易（這樣他們就不需要依賴破壞挖礦去中心化的頻外交易提交方案）。 + +**明知拒絕中繼礦工無論如何都會包含在區塊中的交易會迫使使用者進入替代通訊管道，破壞上述目標。** + +交易接受規則過去曾被有效地用於阻止使用區塊空間效率低下的用例的開發，而這樣做非常便宜。然而，這只有在使用者和礦工都對存在的任何替代方案感到滿意時才能有效。當情況不再如此，並且開發出與策略規則衝突的經濟上可行的用例時，使用者和礦工可以直接合作以避免對其活動施加限制的任何外部嘗試。事實上，能夠做到這一點是 Bitcoin 抗審查性的一個重要方面，具有優先對等的其他節點軟體也表明，規避絕大多數節點的過濾器相對容易。鑑於此，我們認為 Bitcoin 節點軟體最好旨在對下一個區塊中最終會包含什麼有一個現實的想法，而不是試圖在同意的交易建立者和礦工之間進行干預，以阻止在技術層面上基本無害的活動。 + +**這不是認可或容忍非金融資料使用，而是接受作為抗審查系統，Bitcoin 可以而且將被用於不是每個人都同意的用例。** + +雖然我們認識到這一觀點並非所有使用者和開發者普遍持有，但我們真誠地相信這符合 Bitcoin 及其使用者的最佳利益，我們希望我們的使用者同意。我們將繼續作為開發者應用我們的最佳判斷，使交易接受規則與 Bitcoin 的長期健康和礦工的理性自利保持一致，包括特定的技術原因，例如升級安全性、高效的區塊建構和節點 DoS 攻擊。 + +簽署， + +（支援此信的貢獻者列表） + +* Andrew Toth +* Antoine Poinsot +* Anthony Towns +* Ava Chow +* b10c +* Bruno Garcia +* David Gumberg +* fjahr +* Gloria Zhao +* Gregory Sanders +* hodlinator +* ismaelsadeeq +* Josie Baker +* kevkevinpal +* l0rinc +* Marco De Leon +* Martin Zumsande +* Matthew Zipkin +* Michael Ford +* Murch +* Niklas Gögge +* pablomartin4btc +* Pieter Wuille +* Pol Espinasa +* Sebastian Falbesoner +* Sergi Delgado +* Stephan Vuylsteke +* TheCharlatan +* Vasil Dimov +* Will Clark +* w0xlt diff --git a/_posts/zh_TW/posts/2025-06-26-release-28.2.md b/_posts/zh_TW/posts/2025-06-26-release-28.2.md new file mode 100644 index 000000000..29db18359 --- /dev/null +++ b/_posts/zh_TW/posts/2025-06-26-release-28.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 28.2 版本發布 +name: blog-release-28.2 +id: zh_tw-blog-release-28.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 28.2 現已發布。 +--- +Bitcoin Core 28.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/28.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-09-04-release-29.1.md b/_posts/zh_TW/posts/2025-09-04-release-29.1.md new file mode 100644 index 000000000..37fe92f77 --- /dev/null +++ b/_posts/zh_TW/posts/2025-09-04-release-29.1.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 29.1 版本發布 +name: blog-release-29.1 +id: zh_tw-blog-release-29.1 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 29.1 現已發布。 +--- +Bitcoin Core 29.1 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/29.1/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-10-release-30.0.md b/_posts/zh_TW/posts/2025-10-10-release-30.0.md new file mode 100644 index 000000000..183409f06 --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-10-release-30.0.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 30.0 版本發布 +name: blog-release-30.0 +id: zh_tw-blog-release-30.0 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 30.0 現已發布。 +--- +Bitcoin Core 30.0 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本中的新功能和其他變更。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/30.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-14-release-29.2.md b/_posts/zh_TW/posts/2025-10-14-release-29.2.md new file mode 100644 index 000000000..65f684113 --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-14-release-29.2.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 29.2 版本發布 +name: blog-release-29.2 +id: zh_tw-blog-release-29.2 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 29.2 現已發布。 +--- +Bitcoin Core 29.2 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/29.2/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-17-release-28.3.md b/_posts/zh_TW/posts/2025-10-17-release-28.3.md new file mode 100644 index 000000000..803026066 --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-17-release-28.3.md @@ -0,0 +1,23 @@ +--- +title: Bitcoin Core 28.3 版本發布 +name: blog-release-28.3 +id: zh_tw-blog-release-28.3 +lang: zh_TW +type: posts +layout: post + +version: 1 + +excerpt: > + Bitcoin Core 28.3 現已發布。 +--- +Bitcoin Core 28.3 版本現已可供[下載][download page]。請參閱[版本說明][release notes]以了解此版本的錯誤修復詳情。 + +如有任何問題，請前往 #bitcoin IRC 聊天室（[IRC][irc]、[網頁版][web irc]），我們會盡力為您提供協助。 + +[release notes]: /zh_TW/releases/28.3/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /zh_TW/download + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-46597.md b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-46597.md new file mode 100644 index 000000000..b35201149 --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-46597.md @@ -0,0 +1,46 @@ +--- +title: CVE-2025-46597 - 32 位元系統上極不可能的遠端崩潰 +name: blog-disclose-cve-2025-46597 +id: zh_TW-blog-disclose-cve-2025-46597 +lang: zh_TW +type: advisory +layout: post +redirect_from: + - /zh_TW/2025/10/24/disclose-cve-2025-46597 + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者可以產生一個在罕見邊緣情況下崩潰在 32 位元系統上執行的節點的區塊。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 +--- + +披露 32 位元系統上一個錯誤的細節，該錯誤在罕見邊緣情況下可能導致節點在接收到病理區塊時崩潰。此錯誤將極難利用。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +在將區塊寫入磁碟之前，Bitcoin Core 會檢查其大小是否在正常範圍內。對於超過 1GB 的區塊，此檢查將在 32 位元系統上溢位，並在將其寫入磁碟時使節點崩潰。這樣的區塊無法使用 `BLOCK` 訊息傳送，但理論上如果受害者節點具有非預設的大記憶池，該記憶池已經包含 1GB 的交易，則可以作為緊湊區塊傳送。這需要受害者將其 `-maxmempool` 選項設定為大於 3GB 的值，而 32 位元系統最多可能有 4GiB 的記憶體。 + +此問題透過限制 32 位元系統上 `-maxmempool` 設定的最大值來間接防止。 + +## 歸屬 + +Pieter Wuille 發現此錯誤並負責任地披露它。 + +Antoine Poinsot 提出並實作了隱蔽緩解措施。 + +## 時間表 + +- 2025-04-24 - Pieter Wuille 報告該問題 +- 2025-05-16 - Antoine Poinsot 開啟 PR [#32530](https://github.com/bitcoin/bitcoin/pull/32530)，包含隱蔽修復程式 +- 2025-06-26 - PR #32530 合併到 master +- 2025-09-04 - 版本 29.1 發布，包含修復程式 +- 2025-10-10 - 版本 30.0 發布，包含修復程式 +- 2025-10-24 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-46598.md b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-46598.md new file mode 100644 index 000000000..245b98844 --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-46598.md @@ -0,0 +1,49 @@ +--- +title: CVE-2025-46598 - 未確認交易處理導致的 CPU DoS +name: blog-disclose-cve-2025-46598 +id: zh_TW-blog-disclose-cve-2025-46598 +lang: zh_TW +type: advisory +layout: post +redirect_from: + - /zh_TW/2025/10/24/disclose-cve-2025-46598 + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 特別製作的無效未確認交易可能導致不必要的資源使用。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 +--- + +披露處理未確認交易時的資源耗盡問題的細節。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +攻擊者可以傳送特別製作的未確認交易，受害者節點需要幾秒鐘來驗證每個交易。非標準交易將被拒絕，但不會導致斷開連接，並且可以重複該過程。這可以被利用來延遲區塊傳播。 + +該問題透過減少不同 Script 上下文中的驗證時間而在多個步驟中得到緩解。 + +## 歸屬 + +Antoine Poinsot 向 Bitcoin Core 安全郵件列表報告此問題。 + +Pieter Wuille、Anthony Towns 和 Antoine Poinsot 實作了緩解措施，以減少未確認交易的最壞情況驗證時間。 + +## 時間表 + +- 2025-04-25 - Antoine Poinsot 報告該問題 +- 2025-05-12 - Pieter Wuille 開啟 PR [#32473](https://github.com/bitcoin/bitcoin/pull/32473) 以緩解傳統 Script 上下文中最壞情況的二次方簽章雜湊 +- 2025-07-24 - Anthony Towns 開啟 PR [#33050](https://github.com/bitcoin/bitcoin/pull/33050) 以緩解 Tapscript 上下文中最壞情況的雜湊 +- 2025-07-30 - Antoine Poinsot 開啟 PR [#33105](https://github.com/bitcoin/bitcoin/pull/33105) 以進一步緩解傳統 Script 上下文中的最壞情況 +- 2025-08-08 - PR #33105 合併到 master +- 2025-08-11 - PR #32473 合併到 master +- 2025-08-12 - PR #33050 合併到 master +- 2025-10-10 - 版本 30.0 發布，包含緩解措施 +- 2025-10-24 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-54604.md b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-54604.md new file mode 100644 index 000000000..5d1f219ee --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-54604.md @@ -0,0 +1,48 @@ +--- +title: CVE-2025-54604 - 偽造的自連接導致的磁碟填滿 +name: blog-disclose-cve-2025-54604 +id: zh_TW-blog-disclose-cve-2025-54604 +lang: zh_TW +type: advisory +layout: post +redirect_from: + - /zh_TW/2025/10/24/disclose-cve-2025-54604 + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者可以透過長時間重複偽造自連接來導致受害者節點填滿其磁碟空間。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 +--- + +披露一個日誌填充錯誤的細節，該錯誤允許攻擊者透過偽造自連接來填滿受害者節點的磁碟空間。此錯誤的可利用性有限，並且需要很長時間才能導致受害者耗盡磁碟空間。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +Bitcoin Core 會在自連接情況下無條件記錄。攻擊者可以利用這一點，等待受害者連接到它，並重複使用版本訊息隨機數來建立許多到受害者的連接，導致它將這些嘗試檢測為自連接。然而，可利用性是有限的，因為來自受害者的初始連接預設會在 60 秒後逾時。 + +此問題透過在整個系統中實作日誌速率限制來修復，也防止未來發生相同類型的問題。 + +## 歸屬 + +Niklas Goegge 發現此錯誤並負責任地披露它。 + +Eugene Siegel 和 Niklas Goegge 致力於修復所有類型的日誌填充攻擊。 + +也感謝貢獻者「practicalswift」，他之前提出了對 Bitcoin Core 中磁碟填充向量的擔憂並致力於解決它們。 + +## 時間表 + +- 2022-03-16 - Niklas Goegge 向 Bitcoin Core 安全郵件列表報告此問題 +- 2025-05-23 - Eugene Siegel 開啟 PR [#32604](https://github.com/bitcoin/bitcoin/pull/32604) 以引入日誌速率限制，基於 Niklas Goegge 的早期工作 +- 2025-07-09 - PR #32604 合併到 master +- 2025-09-04 - 版本 29.1 發布，包含修復程式 +- 2025-10-10 - 版本 30.0 發布，包含修復程式 +- 2025-10-24 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-54605.md b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-54605.md new file mode 100644 index 000000000..554f4c6eb --- /dev/null +++ b/_posts/zh_TW/posts/2025-10-24-disclose-cve-2025-54605.md @@ -0,0 +1,50 @@ +--- +title: CVE-2025-54605 - 無效區塊導致的磁碟填滿 +name: blog-disclose-cve-2025-54605 +id: zh_TW-blog-disclose-cve-2025-54605 +lang: zh_TW +type: advisory +layout: post +redirect_from: + - /zh_TW/2025/10/24/disclose-cve-2025-54605 + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 1 + +excerpt: > + 攻擊者可以透過重複傳送無效區塊來導致受害者節點填滿其磁碟空間。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 +--- + +披露一個日誌填充錯誤的細節，該錯誤允許攻擊者透過重複傳送無效區塊來導致受害者節點填滿其磁碟空間。此錯誤的可利用性有限，因為需要很長時間才能導致受害者耗盡磁碟空間。修復程式於 2025 年 10 月 10 日在 Bitcoin Core v30.0 中發布。 + +此問題被認為是**低**嚴重性。 + +## 細節 + +節點在接收到未通過基本完整性檢查的區塊時，或在接收到從最後一個檢查點之前分叉的區塊時，會無條件記錄。透過重複向受害者節點傳送這樣的無效區塊，攻擊者可以導致受害者耗盡磁碟空間。 + +此問題透過在整個系統中實作日誌速率限制來修復，也防止未來發生相同類型的問題。 + +## 歸屬 + +Niklas Goegge 發現此錯誤並負責任地披露它。Eugene Siegel 獨立重新發現此錯誤並負責任地披露它。 + +Eugene Siegel 和 Niklas Goegge 致力於修復所有類型的日誌填充攻擊。 + +也感謝貢獻者「practicalswift」，他之前提出了對 Bitcoin Core 中磁碟填充向量的擔憂並致力於解決它們。 + +## 時間表 + +- 2022-05-16 - Niklas Goegge 向 Bitcoin Core 安全郵件列表報告此問題 +- 2025-03-13 - Eugene Siegel 向 Bitcoin Core 安全郵件列表報告此問題 +- 2025-04-24 - Eugene Siegel 向安全郵件列表報告他對最壞情況磁碟填充速率的研究 +- 2025-05-23 - Eugene Siegel 開啟 PR [#32604](https://github.com/bitcoin/bitcoin/pull/32604) 以引入日誌速率限制，基於 Niklas Goegge 的早期工作 +- 2025-07-09 - PR #32604 合併到 master +- 2025-09-04 - 版本 29.1 發布，包含修復程式 +- 2025-10-10 - 版本 30.0 發布，包含修復程式 +- 2025-10-24 - 公開披露 + +{% include references.md %} diff --git a/_posts/zh_TW/releases/2015-07-12-release-0.11.0.md b/_posts/zh_TW/releases/2015-07-12-release-0.11.0.md new file mode 100644 index 000000000..5477ac057 --- /dev/null +++ b/_posts/zh_TW/releases/2015-07-12-release-0.11.0.md @@ -0,0 +1,146 @@ +--- +title: Bitcoin Core 0.11.0 +id: zh_tw-release-0.11.0 +name: release-0.11.0 +permalink: /zh_TW/releases/0.11.0/ +excerpt: Bitcoin Core 0.11.0 版本現已發布 +date: 2015-07-12 +type: releases +layout: page +lang: zh_TW + +release: [0, 11, 0, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.11.0 版本現已發布，可從以下位置下載： + + + +此主要版本帶來了新功能和錯誤修正。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +升級和降級 +========================= + +降級警告 +------------------ + +由於 0.10.0 及更高版本使用標頭優先同步和平行區塊下載，區塊檔案和資料庫與 0.10 之前版本的 Bitcoin Core 或其他軟體不向後相容。 + +從 0.11.x 降級到 0.10.x 時沒有已知問題。 + +重要資訊 +====================== + +交易洪水 +--------------------- + +在此版本發布時，P2P 網路正在遭受低費用交易的洪水攻擊。這導致 mempool 大小膨脹。 + +如果 mempool 的增長在您的節點上導致記憶體使用問題，可以更改一些配置選項來解決此問題。可以使用 RPC 命令 `getmempoolinfo` 監控 mempool 的增長。 + +一個是增加最低交易中繼費用 `minrelaytxfee`，預設為 0.00001。這將導致拒絕每 kB 費用較少的交易，從而減少進入 mempool 的交易。 + +另一個是限制免費交易的中繼，使用 `limitfreerelay`。此選項設定接受免費交易（具有足夠優先級）的 kB/分鐘速率。預設為 15。減少此數字可減少由於免費交易而導致的 mempool 增長速度。 + +例如，將以下內容新增到 `bitcoin.conf`： + + minrelaytxfee=0.00005 + limitfreerelay=5 + +正在為後續版本開發更強大的解決方案。 + +重要變更 +=============== + +區塊檔案修剪 +---------------------- + +此版本支援在不維護磁碟上原始區塊和還原資料副本的情況下執行完全驗證節點。 + +區塊修剪允許 Bitcoin Core 在原始資料經過驗證並用於建置資料庫後刪除原始區塊和還原資料。此時，原始資料僅用於向其他節點中繼區塊、處理重組、查找舊交易（如果啟用了 -txindex 或透過 RPC/REST 介面），或重新掃描錢包。 + +使用者指定為區塊和還原檔案分配多少空間。允許的最小值為 550MB。請注意，這是除了區塊索引和 UTXO 資料庫所需的任何空間之外的。選擇最小值是為了使 Bitcoin Core 能夠在磁碟上維護至少 288 個區塊（以每個區塊 10 分鐘計算，兩天的區塊）。 + +區塊修剪在初始同步期間的工作方式與穩定狀態相同，透過在分配磁碟空間時「隨時」刪除區塊檔案。 + +現在，區塊修剪會停用區塊中繼。未來，具有區塊修剪的節點至少會中繼「新」區塊，即擴展其活動鏈的區塊。 + +區塊修剪目前與執行錢包不相容，因為區塊資料用於重新掃描錢包和匯入金鑰或位址（需要重新掃描）。然而，在不久的將來，將支援使用區塊修剪執行錢包，但受到這些限制。 + +區塊修剪也與 -txindex 不相容，並會自動停用它。 + +一旦您修剪了區塊，回到未修剪狀態需要重新下載整個區塊鏈。要執行此操作，請使用 -reindex 重新啟動節點。 + +要在命令列上啟用區塊修剪： + +- `-prune=N`：其中 N 是為原始區塊和還原資料分配的 MB 數。 + +修改的 RPC 呼叫： + +- `getblockchaininfo` 現在包括我們是否處於修剪模式。 +- `getblock` 將檢查區塊的資料是否已被修剪，如果是，則返回錯誤。 +- `getrawtransaction` 將無法再找到具有 UTXO 但其區塊檔案已被修剪的交易。 + +預設情況下停用修剪。 + +Big endian 支援 +-------------------- + +在此版本中新增了對 big-endian CPU 架構的實驗性支援。所有 little-endian 特定的程式碼都已替換為 endian 中性的建構。這已在至少 MIPS 和 PPC 主機上測試過。建置系統將自動檢測目標的 endianness。 + +記憶體使用最佳化 +-------------------------- + +此版本中進行了許多變更以減少節點的預設記憶體使用，其中包括： + +- 準確的 UTXO 快取大小計算（#6102）；這使得選項 `-dbcache` 精確，而以前這嚴重低估了記憶體使用量 +- 減少每個對等節點資料結構的大小（#6064 等）；這增加了可以在相同記憶體量下支援的連線數 +- 減少執行緒數（#5964、#5679）；降低（尤其是虛擬）記憶體需求 + +費用估算變更 +---------------------- + +此版本改進了用於費用估算的演算法。以前，當沒有足夠的資料給出估算時，返回 -1。現在，當所需確認目標沒有足夠高的費用或優先級時，也將返回 -1。在這些情況下，要求更高目標區塊數的估算可能會有所幫助。沒有足夠高的費用或優先級可靠地（85%）包含在下一個區塊中並不罕見，因此 `-txconfirmtarget=n` 的預設值已從 1 更改為 2。 + +隱私：停用錢包交易廣播 +---------------------------------------------- + +此版本新增了一個選項 `-walletbroadcast=0` 以防止自動交易廣播和重新廣播（#5951）。此選項允許將交易提交與節點功能分離。 + +利用此功能，可以編寫第三方腳本來處理交易（重新）廣播： + +- 透過 RPC 或 GUI 正常發送交易 +- 透過 RPC 使用 `gettransaction`（不是 `getrawtransaction`）檢索交易資料。結果的 `hex` 欄位將包含交易的原始十六進位表示 +- 然後可以透過腳本支援的任意機制廣播交易 + +一個這樣的應用是選擇性 Tor 使用，其中節點在普通網際網路上執行，但交易透過 Tor 廣播。 + +有關範例腳本，請參閱 [bitcoin-submittx](https://github.com/laanwj/bitcoin-submittx)。 + +隱私：Tor 的串流隔離 +---------------------------------- + +此版本新增了為每個對等節點連線建立新電路的功能，當軟體與 Tor 一起使用時。新選項 `-proxyrandomize` 預設開啟。 + +啟用後，每個出站連線都將（可能）透過不同的出口節點。這顯著減少了不幸選擇單個惡意或被 P2P 網路廣泛禁止的出口節點的機會。這提高了連線可靠性和隱私，特別是對於初始連線。 + +**重要注意事項：**如果配置了支援認證但不需要認證的非 Tor SOCKS5 代理，此變更可能導致該代理拒絕連線。在這種情況下，可以傳遞 `-proxyrandomize=0` 以停用該行為。 + +0.11.0 變更日誌 +================= + +完整的變更日誌包含數百個 PR，涵蓋 RPC 和 REST、配置和命令列選項、區塊和交易處理、P2P 協定和網路程式碼、驗證、建置系統、錢包、GUI、測試等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 80 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2015-10-15-release-0.11.1.md b/_posts/zh_TW/releases/2015-10-15-release-0.11.1.md new file mode 100644 index 000000000..fc4a67824 --- /dev/null +++ b/_posts/zh_TW/releases/2015-10-15-release-0.11.1.md @@ -0,0 +1,133 @@ +--- +title: Bitcoin Core 0.11.1 +id: zh_tw-release-0.11.1 +name: release-0.11.1 +permalink: /zh_TW/releases/0.11.1/ +excerpt: Bitcoin Core 0.11.1 版本現已發布 +date: 2015-10-15 +type: releases +layout: page +lang: zh_TW + +release: [0, 11, 1, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.11.1 版本現已發布，可從以下位置下載： + + + +此小版本帶來了安全性修正。建議盡快升級到此版本。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +升級和降級 +========================= + +如何升級 +-------------- + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +降級警告 +------------------ + +由於 0.10.0 及更高版本使用標頭優先同步和平行區塊下載（請參閱下文），區塊檔案和資料庫與 0.10 之前版本的 Bitcoin Core 或其他軟體不向後相容。 + +從 0.11.x 降級到 0.10.x 時沒有已知問題。 + +重要變更 +=============== + +修復綁定的 upnp 中的緩衝區溢位 +------------------------------------ + +綁定的 miniupnpc 已更新至 1.9.20151008。這修復了初始網路發現期間 XML 解析器中的緩衝區溢位。 + +詳細資訊可以在這裡找到：http://talosintel.com/reports/TALOS-2015-0035/ + +這僅適用於分發的可執行檔，在從原始碼建置或使用發行版提供的套件時不適用。 + +此外，upnp 已預設停用。這可能導致 IPv4 上可達節點數量減少，但這可以防止未來的 libupnpc 漏洞成為網路的結構性風險（請參閱 https://github.com/bitcoin/bitcoin/pull/6795）。 + +在中繼前測試 LowS 簽名 +----------------------------------------- + +使節點在中繼或挖掘時要求 ECDSA 簽名的規範「low-s」編碼。這消除了一個麻煩的可塑性向量。 + +共識行為不變。 + +如果廣泛部署，此變更將消除 SIGHASH_ALL P2PKH 交易的最後一個已知麻煩可塑性向量。缺點是它將阻止大多數由足夠過時的軟體建立的交易。 + +與變更交易 txid 的其他途徑不同，這一個在被發現之前被所有部署的 bitcoin 軟體隨機違反。因此，雖然其他可塑性向量一經發現就成為非標準，但這一個仍然被允許。即使 BIP62 也沒有提議將此規則應用於舊版本交易，但自 BIP62 最初編寫以來，符合的實作已變得更加普遍。 + +Bitcoin Core 自 2013 年 9 月的 a28fb70e 以來就產生相容的簽名，但這直到 2014 年 3 月的 0.9 才進入發布版本；Bitcoinj 在類似的時間範圍內也是如此。Bitcoinjs 和 electrum 最近才更新。 + +這不能替代 BIP62 或類似的，因為礦工仍然可以合作破壞交易。它也不能替代錢包軟體以理智的方式處理可塑性。這只是消除了便宜且令人惱火的 DOS 攻擊。 + +最低中繼費用預設增加 +----------------------------------- + +`-minrelaytxfee` 設定的預設值已從 `0.00001` 增加到 `0.00005`。 + +這是由於當前的交易洪水造成的，由於 mempool 膨脹導致節點上的記憶體使用量過高。這是一個臨時措施，直到確定此費用的動態方法合併（將在 0.12 中）。 + +（請參閱 https://github.com/bitcoin/bitcoin/pull/6793，以及 0.11 版本說明，其中建議了此值） + +0.11.1 變更日誌 +================= + +- #6438 `2531438` openssl: avoid config file load/race +- #6439 `980f820` Updated URL location of netinstall for Debian +- #6384 `8e5a969` qt: Force TLS1.0+ for SSL connections +- #6471 `92401c2` Depends: bump to qt 5.5 +- #6224 `93b606a` Be even stricter in processing unrequested blocks +- #6571 `100ac4e` libbitcoinconsensus: avoid a crash in multi-threaded environments +- #6545 `649f5d9` Do not store more than 200 timedata samples +- #6694 `834e299` [QT] fix thin space word wrap line break issue +- #6703 `1cd7952` Backport bugfixes to 0.11 +- #6750 `5ed8d0b` Recent rejects backport to v0.11 +- #6769 `71cc9d9` Test LowS in standardness, removes nuisance malleability vector +- #6789 `b4ad73f` Update miniupnpc to 1.9.20151008 +- #6785 `b4dc33e` Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave() +- #6412 `0095b9a` Test whether created sockets are select()able +- #6795 `4dbcec0` net: Disable upnp by default +- #6793 `e7bcc4a` Bump minrelaytxfee default + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Adam Weiss +- Alex Morcos +- Casey Rodarmor +- Cory Fields +- fanquake +- Gregory Maxwell +- Jonas Schnelli +- J Ross Nicoll +- Luke Dashjr +- Pavel Janík +- Pavel Vasin +- Peter Todd +- Pieter Wuille +- randy-waterhouse +- Ross Nicoll +- Suhas Daftuar +- tailsjoin +- ฿tcDrak +- Tom Harding +- Veres Lajos +- Wladimir J. van der Laan + +以及那些貢獻額外程式碼審查和/或安全研究的人： + +- timothy on IRC for reporting the issue +- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2015-11-13-release-0.11.2.md b/_posts/zh_TW/releases/2015-11-13-release-0.11.2.md new file mode 100644 index 000000000..737d607a7 --- /dev/null +++ b/_posts/zh_TW/releases/2015-11-13-release-0.11.2.md @@ -0,0 +1,134 @@ +--- +title: Bitcoin Core 0.11.2 +id: zh_tw-release-0.11.2 +name: release-0.11.2 +permalink: /zh_TW/releases/0.11.2/ +excerpt: Bitcoin Core 0.11.2 版本現已發布 +date: 2015-11-13 +type: releases +layout: page +lang: zh_TW + +release: [0, 11, 2, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.11.2 版本現已發布，可從以下位置下載： + + + +此小版本帶來了錯誤修正、BIP65 (CLTV) 共識變更以及 BIP113 的中繼政策準備。建議盡快升級到此版本。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +升級和降級 +========================= + +如何升級 +-------------- + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +降級警告 +------------------ + +由於 0.10.0 及更高版本使用標頭優先同步和平行區塊下載（請參閱下文），區塊檔案和資料庫與 0.10 之前版本的 Bitcoin Core 或其他軟體不向後相容。 + +從 0.11.x 降級到 0.10.x 時沒有已知問題。 + +自 0.11.1 以來的重要變更 +============================ + +BIP65 軟分叉以強制執行 OP_CHECKLOCKTIMEVERIFY 操作碼 +-------------------------------------------------------- + +此版本包含與 [BIP65][] 軟分叉相關的幾個變更，該軟分叉將現有的 OP_NOP2 操作碼重新定義為 OP_CHECKLOCKTIMEVERIFY (CLTV)，以便交易輸出可以在指定的未來時間點之前無法被花費。 + +1. 此版本只會中繼和挖掘花費 CLTV 輸出的交易，如果它們符合程式碼中提供的 BIP65 規則。 + +2. 此版本預設將產生版本 4 區塊。請參閱下面的*礦工注意事項*。 + +3. 一旦本地節點最佳區塊鏈上的 1,001 個區塊序列中有 951 個包含版本 4（或更高）區塊，此版本將不再接受新的版本 3 區塊，並且只有在符合 CLTV 的 BIP65 規則時才會接受版本 4 區塊。 + +有關軟分叉變更的更多資訊，請參閱 + +**礦工注意事項：**Bitcoin Core 的區塊模板現在僅適用於版本 4 區塊，任何依賴其 getblocktemplate 的挖礦軟體必須並行更新以使用 libblkmaker 0.4.3 版或 0.5.2 及更高版本。 + +[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki + +BIP113 mempool-only 鎖定時間強制執行使用 GetMedianTimePast() +---------------------------------------------------------------- + +[BIP113][] 指定了一個軟分叉（**在此版本中未強制執行**），透過要求有效區塊的計算 GetMedianTimePast() 大於該區塊中任何交易指定的鎖定時間，來削弱個別礦工使用未來時間的不當激勵。 + +Mempool 包含規則目前要求交易對於立即包含在區塊中有效才能被接受到 mempool 中。此版本開始將 BIP113 規則應用於接收的交易，因此其時間大於 GetMedianTimePast() 的交易將不再被接受到 mempool 中。 + +**對礦工的影響：**您將開始拒絕在 BIP113 下無效的交易，這將防止您在網路上強制執行 BIP113 時產生無效區塊。 + +**對使用者的影響：**GetMedianTimePast() 總是落後於當前時間，因此鎖定時間設定為當前時間的交易將被執行此版本的節點拒絕，直到中位數時間向前移動。為了補償，從您的鎖定時間中減去一小時（3,600 秒）。 + +[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki + +Windows 不乾淨關閉時 UTXO 資料庫損壞的錯誤修復 +---------------------------------------------------------------- + +幾個 Windows 使用者回報，在 Windows 上不乾淨關閉 Bitcoin Core（或 Windows 本身不乾淨關閉）後，他們經常需要重新索引整個區塊鏈。儘管不乾淨的關閉仍然不安全，但此版本不再依賴 UTXO 資料庫的記憶體映射檔案，這顯著減少了測試期間不乾淨關閉導致需要重新索引的頻率。 + +有關更多資訊，請參閱： + +預計下一個主要版本中將對 Windows 上的資料庫損壞進行其他修復。 + +0.11.2 變更日誌 +================= + +- #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument +- #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65) +- #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify flag +- #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic +- #6353 `ba1da90` Show softfork status in getblockchaininfo +- #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list +- #6688 `01878c9` Fix locking in GetTransaction +- #6653 `b3eaa30` [Qt] Raise debug window when requested +- #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary +- #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package +- #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for testnet +- #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack +- #6846 `af6edac` alias `-h` for `--help` +- #6867 `95a5039` Set TCP_NODELAY on P2P sockets +- #6856 `dfe55bd` Do not allow blockfile pruning during reindex +- #6566 `a1d3c6f` Add rules--presently disabled--for using GetMedianTimePast as end point for lock-time calculations +- #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints +- #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping +- #6948 `4e895b0` Always flush block and undo when switching to new file + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Alex Morcos +- ฿tcDrak +- Chris Kleeschulte +- Daniel Cousens +- Diego Viola +- Eric Lombrozo +- Esteban Ordano +- Gregory Maxwell +- Luke Dashjr +- Marco Falke +- Mark Friedenbach +- Matt Corallo +- Micha +- Mitchell Cash +- Peter Todd +- Pieter Wuille +- Wladimir J. van der Laan +- Zak Wilcox + +以及那些貢獻額外程式碼審查和/或安全研究的人。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2016-02-23-release-0.12.0.md b/_posts/zh_TW/releases/2016-02-23-release-0.12.0.md new file mode 100644 index 000000000..3e9e37811 --- /dev/null +++ b/_posts/zh_TW/releases/2016-02-23-release-0.12.0.md @@ -0,0 +1,215 @@ +--- +title: Bitcoin Core 0.12.0 +id: zh_tw-release-0.12.0 +name: release-0.12.0 +permalink: /zh_TW/releases/0.12.0/ +excerpt: Bitcoin Core 0.12.0 版本現已發布 +date: 2016-02-23 +type: releases +layout: page +lang: zh_TW + +release: [0, 12, 0, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.12.0 版本現已發布，可從以下位置下載： + + + +此主要版本帶來了新功能和其他改進。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +升級和降級 +========================= + +降級警告 +----------------- + +### 降級到版本 < 0.12.0 + +由於 0.12.0 及更高版本將在每次新同步或重新索引時混淆 chainstate，因此 chainstate 與 0.12 之前版本的 Bitcoin Core 或其他軟體不向後相容。 + +如果您想在使用 0.12.0 或更高版本進行重新索引後降級，當您首次啟動 Bitcoin Core 0.11 或更早版本時，您將需要重新索引。 + +重要變更 +=============== + +使用 libsecp256k1 進行簽名驗證 +--------------------------------------- + +Bitcoin 交易中的 ECDSA 簽名現在使用 [libsecp256k1](https://github.com/bitcoin/secp256k1) 進行驗證，而不是 OpenSSL。 + +根據平台的不同，這意味著原始簽名驗證速度的顯著加速。在 x86_64 上優勢最大，驗證速度提高了五倍以上。在實際應用中，這轉化為原始重新索引和新區塊驗證時間不到以前的一半。 + +Libsecp256k1 經過了非常廣泛的測試和驗證。 + +此變更的副作用是 libconsensus 不再依賴 OpenSSL。 + +減少上傳流量 +--------------------- + +出站流量的主要部分是由於在初始區塊下載狀態下向其他節點提供歷史區塊。 + +現在可以透過 `-maxuploadtarget` 參數減少總上傳流量。這*不是*硬限制，而是最小化出站流量的閾值。當即將達到限制時，透過不提供歷史區塊（超過一週的區塊）來削減上傳的資料。此外，當請求過濾區塊時，任何 SPV 對等節點都會被斷開連線。 + +此選項可以以每天 MiB 為單位指定，預設關閉（`-maxuploadtarget=0`）。建議的最小值是每天 144 * MAX_BLOCK_SIZE（目前為 144MB）。 + +白名單對等節點永遠不會被斷開連線，儘管它們的流量會計入目標計算。 + +有關保持流量低的更詳細文件可以在 [/doc/reduce-traffic.md](https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/reduce-traffic.md) 中找到。 + +直接標頭公告（BIP 130） +------------------------------------- + +在相容對等節點之間，使用 [BIP 130](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) 直接標頭公告。這意味著透過直接公告標頭來廣告區塊，而不僅僅是公告雜湊。在重組中，發送所有新標頭，而不僅僅是新提示。這通常可以防止在下載實際區塊之前的額外往返。 + +隨著此變更，修剪節點現在能夠向相容對等節點中繼新區塊。 + +記憶體池限制 +-------------------- + +先前版本的 Bitcoin Core 透過檢查交易費用是否符合節點的最低中繼費用來限制其 mempool。mempool 的大小沒有上限，攻擊者可以發送大量支付略高於預設最低中繼費用的交易，以使相對低 RAM 的節點崩潰。先前版本的 Bitcoin Core 的臨時解決方法是提高預設最低中繼費用。 + +Bitcoin Core 0.12 將對 mempool 有嚴格的最大大小。預設值為 300 MB，可以使用 `-maxmempool` 參數配置。每當交易會導致 mempool 超過其最大大小時，具有最低總費率（作為套件）的交易（連同記憶體內後代）將被驅逐，節點的有效最低中繼費率將增加以匹配此費率加上初始最低中繼費率。初始最低中繼費率設定為每 kB 1000 satoshi。 + +Bitcoin Core 0.12 還引入了新的預設政策限制，限制 mempool 中允許的未確認交易鏈的長度和大小（通常將未確認鏈的長度限制為 25 個交易，總大小為 101 KB）。 + +選擇加入的 Replace-by-fee 交易 +---------------------------------- + +現在可以替換 Bitcoin Core 0.12 節點的交易記憶體池中的交易。Bitcoin Core 只允許替換其任何輸入的 `nSequence` 號設定為小於 `0xffffffff - 1` 的交易。此外，只有當替換交易支付足夠的費用時，才能接受替換交易，如 [BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) 中所述。 + +可以使用新的命令列選項 `-mempoolreplacement=0` 停用交易替換。在 BIP125 下發送替換訊號的交易仍將在此配置中被允許進入 mempool，但替換將被拒絕。此選項適用於希望繼續先前版本的交易選擇行為的礦工。 + +請注意，Bitcoin Core 0.12 中的錢包尚不支援建立在 BIP 125 下可替換的交易。 + +RPC：Random-cookie RPC 認證 +------------------------------------- + +當未指定 `-rpcpassword` 時，守護程式現在使用特殊的「cookie」檔案進行認證。此檔案在守護程式啟動時使用隨機內容生成，並在退出時刪除。其內容用作認證令牌。對此檔案的讀取存取控制誰可以透過 RPC 存取。預設情況下，它儲存在資料目錄中，但可以使用 `-rpccookiefile` 選項覆蓋其位置。 + +這類似於 Tor 的 CookieAuthentication：請參閱 + +這允許在不進行任何手動配置的情況下執行 bitcoind。 + +中繼：OP_RETURN 輸出中的任何 pushdata 序列現在允許 +----------------------------------------------------------------- + +以前，只有當 OP_RETURN 輸出具有單個 pushdata 時，才會中繼和挖掘具有有效負載的 OP_RETURN 輸出。此限制已解除，以允許在 OP_RETURN 之後使用任何資料推送和數字常數操作碼（OP_1 到 OP_16）的組合。OP_RETURN 輸出大小的限制現在應用於整個序列化的 scriptPubKey，預設為 83 位元組。（先前的 80 位元組預設值加上三個位元組開銷） + +中繼和挖礦：優先級交易 +--------------------------------------- + +Bitcoin Core 有基於幣值和年齡的啟發式「優先級」。此計算用於中繼不支付最低中繼費用的交易，並可用作為挖掘區塊排序交易的替代方法。 + +在 Bitcoin Core 0.12 中，當達到 mempool 限制時，更高的最低中繼費用生效以限制記憶體使用。即使根據優先級啟發式排名很高，不符合此更高有效最低中繼費用的交易也不會被中繼或挖掘。 + +基於優先級的交易挖掘現在預設也已停用。要重新啟用它，只需設定 `-blockprioritysize=`，其中 n 是為這些交易保留的區塊大小（以位元組為單位）。舊的預設值為 50k，因此要保留大致相同的政策，您需要設定 `-blockprioritysize=50000`。 + +自動使用 Tor 隱藏服務 +------------------------------------- + +從 Tor 版本 0.2.7.1 開始，透過 Tor 的控制套接字 API，可以程式化地建立和銷毀「臨時」隱藏服務。Bitcoin Core 已更新以使用此功能。 + +這意味著如果 Tor 正在執行（並且可用適當的授權），Bitcoin Core 會自動建立一個隱藏服務來監聽，無需手動配置。如果可以成功開啟控制套接字，Bitcoin Core 也將自動使用 Tor 連線到其他 .onion 節點。 + +如果 Bitcoin Core 正在監聽，並且可以與 Tor 建立連線，則此新功能預設啟用。可以使用 `-listenonion`、`-torcontrol` 和 `-torpassword` 設定進行配置。要顯示詳細除錯資訊，請傳遞 `-debug=tor`。 + +透過 ZMQ 的通知 +------------------------- + +Bitcoind 現在可以（可選）透過基於 ZMQ 的 PUB 套接字異步通知客戶端新交易和區塊的到達。此功能需要安裝 ZMQ C API 程式庫 4.x，並透過命令列或配置檔配置其使用。請參閱 [docs/zmq.md](https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/zmq.md) 以獲取操作詳細資訊。 + +錢包：交易費用 +------------------------ + +對錢包如何計算交易費用進行了各種改進。 + +使用者可以透過設定 `-paytxfee=`（或在執行時執行 `settxfee ` rpc）來決定支付預定義的費率。`n=0` 的值表示 Bitcoin Core 使用浮動費用。預設情況下，Bitcoin Core 將使用浮動費用。 + +基於過去的交易資料，浮動費用近似從現在起進入第 `m` 個區塊所需的費用。這可以使用 `-txconfirmtarget=`（預設值：`2`）配置。 + +有時，無法給出良好的估算，或根本無法給出估算。因此，可以使用 `-fallbackfee=`（預設值：`0.0002` BTC/kB）設定回退值。 + +在任何時候，Bitcoin Core 都會將費用限制在 `-maxtxfee=`（預設值：0.10）BTC。此外，Bitcoin Core 永遠不會建立支付少於當前最低中繼費用的交易。最後，使用者可以使用 `-mintxfee=` 為所有交易設定最低費率，預設為每 kB 1000 satoshi。 + +錢包：負確認和衝突檢測 +----------------------------------------------------- + +錢包現在將報告負確認數，指示衝突在區塊鏈中的深度。例如，如果交易 A 有 5 次確認並花費與錢包交易 B 相同的輸入，B 將被報告為具有 -5 次確認。如果另一個錢包交易 C 花費來自 B 的輸出，它也將被報告為具有 -5 次確認。 + +與早期版本不同，未確認但不衝突的交易永遠不會獲得負確認計數。除非它們來自我們自己（找零）並被接受到我們的本地 mempool 中，否則它們不會被視為可花費。`listtransactions` RPC 輸出中的新「trusted」欄位指示未確認交易的輸出是否被視為可花費。 + +錢包：移除 Merkle 分支 +------------------------------- + +以前，每個錢包交易都儲存一個 Merkle 分支來證明其在區塊中的存在。這只是用於昂貴的健全性檢查。從 0.12 開始，不再儲存這些。當將 0.12 錢包載入到較舊版本時，它將自動重新掃描以避免檢查失敗。 + +錢包：修剪 +--------------- + +從 0.12 開始，可以在修剪模式下使用錢包功能。這可以將磁碟使用量從目前的約 60 GB 減少到約 2 GB。 + +然而，重新掃描以及 RPC `importwallet`、`importaddress`、`importprivkey` 被停用。 + +要啟用區塊修剪，請在命令列或 `bitcoin.conf` 中設定 `prune=`，其中 `N` 是為原始區塊和還原資料分配的 MiB 數。值 0 停用修剪。0 以上的最小值為 550。 + +`NODE_BLOOM` 服務位元 +------------------------ + +已將對 `NODE_BLOOM` 服務位元的支援新增到 P2P 協定程式碼中，如 [BIP 111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki) 中所述。 + +BIP 111 定義了一個服務位元，允許對等節點明確廣告它們支援 bloom 過濾器（如 SPV 客戶端使用的）。它還提升協定版本，以允許對等節點識別儘管缺少新服務位元但仍允許連線的 bloom 過濾的舊節點。 + +選項解析行為 +----------------------- + +命令列選項現在嚴格按照指定的順序解析。過去的情況是 `-X -noX` 最終不直觀地設定 X，因為 `-X` 優先於 `-noX`。這不再是這種情況。與其他軟體一樣，選項的最後指定值將保留。 + +RPC：低階 API 變更 +-------------------------- + +- 可以以字串形式提供貨幣金額。這意味著例如 sendtoaddress 的參數可以是「0.0001」而不是 0.0001。如果 JSON 程式庫堅持對數字使用有損浮點類型，這可能是一個優勢，這對於貨幣金額來說是危險的。 + +- 每個 scriptSig 的 `asm` 屬性現在包含每個提供有效定義雜湊類型的簽名的解碼簽名雜湊類型。 + +- OP_NOP2 已被 [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) 重新命名為 OP_CHECKLOCKTIMEVERIFY + +RPC：SSL 支援移除 +------------------------ + +先前透過選項 `rpcssl` 啟用的 RPC 的 SSL 支援已從客戶端和伺服器中移除。這是為了準備完全移除守護程式對 OpenSSL 的依賴。 + +嘗試使用 `rpcssl` 將導致錯誤： + + Error: SSL mode for RPC (-rpcssl) is no longer supported. + +如果您是少數依賴此功能的人之一，靈活的遷移路徑是使用 `stunnel`。這是一個可以在 SSL 內隧道任意 TCP 連線的實用程式。 + +挖礦程式碼變更 +------------------- + +0.12 中的挖礦程式碼已最佳化，速度明顯更快且使用更少的記憶體。作為這些變更的一部分，共識關鍵計算在交易被接受到 mempool 時快取，挖礦程式碼現在依賴 mempool 的一致性來組裝區塊。然而，所有區塊在組裝後仍然進行有效性測試。 + +其他 P2P 變更 +----------------- + +被禁止對等節點的清單現在儲存在磁碟上而不是記憶體中。重新啟動 bitcoind 將不再清除被禁止對等節點的清單；相反，可以使用新的 RPC 呼叫（`clearbanned`）手動清除清單。新的 `setban` RPC 呼叫也可用於手動禁止或解禁對等節點。 + +0.12.0 變更日誌 +================= + +完整的變更日誌包含數百個 PR，涵蓋 RPC 和 REST、配置和命令列選項、區塊和交易處理、P2P 協定和網路程式碼、驗證、建置系統、錢包、GUI、測試和 QA 等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 100 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2016-04-15-release-0.12.1.md b/_posts/zh_TW/releases/2016-04-15-release-0.12.1.md new file mode 100644 index 000000000..2471a7bc6 --- /dev/null +++ b/_posts/zh_TW/releases/2016-04-15-release-0.12.1.md @@ -0,0 +1,151 @@ +--- +title: Bitcoin Core 0.12.1 +id: zh_tw-release-0.12.1 +name: release-0.12.1 +permalink: /zh_TW/releases/0.12.1/ +excerpt: Bitcoin Core 0.12.1 版本現已發布 +date: 2016-04-15 +type: releases +layout: page +lang: zh_TW + +release: [0, 12, 1, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.12.1 版本現已發布，可從以下位置下載： + + + +此小版本包含 BIP9、BIP68 和 BIP112 軟分叉、各種錯誤修正和更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +升級和降級 +========================= + +如何升級 +-------------- + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +降級警告 +----------------- + +### 降級到版本 < 0.12.0 + +由於 0.12.0 及更高版本將在每次新同步或重新索引時混淆 chainstate，因此 chainstate 與 0.12 之前版本的 Bitcoin Core 或其他軟體不向後相容。 + +如果您想在使用 0.12.0 或更高版本進行重新索引後降級，當您首次啟動 Bitcoin Core 0.11 或更早版本時，您將需要重新索引。 + +重要變更 +=============== + +首個使用 BIP9 的 version bits 軟分叉部署 +------------------------------------------- + +此版本包含使用 [BIP9][] 部署機制強制執行 [BIP68][]、[BIP112][] 和 [BIP113][] 的軟分叉部署。 + +部署將區塊版本號設定為 0x20000001，在 2016 年 5 月 1 日午夜到 2017 年 5 月 1 日午夜之間發送就緒部署訊號。版本號由 0x20000000 組成以指示 version bits，並設定位元 0 以指示對此組合部署的支援，在 `getblockchaininfo` RPC 呼叫中顯示為「csv」。 + +有關軟分叉變更的更多資訊，請參閱 + +此特定回移 pull-request 可在 查看 + +[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki +[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki +[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki +[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki + +BIP68 軟分叉以強制執行相對鎖定時間的序列鎖 +--------------------------------------------------------------- + +[BIP68][] 引入了序列號欄位的相對鎖定時間共識強制執行語義，以使簽名的交易輸入在其對應輸出點確認後的定義時間內保持無效。 + +有關實作的更多資訊，請參閱 + +BIP112 軟分叉以強制執行 OP_CHECKSEQUENCEVERIFY +-------------------------------------------------- + +[BIP112][] 將現有的 OP_NOP3 重新定義為 OP_CHECKSEQUENCEVERIFY (CSV)，作為 Bitcoin 腳本系統中的新操作碼，結合 [BIP68][] 允許根據被花費輸出的年齡限制腳本的執行路徑。 + +有關實作的更多資訊，請參閱 + +BIP113 鎖定時間強制執行軟分叉 +------------------------------------- + +Bitcoin Core 0.11.2 先前引入了僅 mempool 的鎖定時間強制執行，使用 GetMedianTimePast()。此版本尋求共識強制執行該規則。 + +Bitcoin 交易目前可以指定鎖定時間，指示何時可以將它們新增到有效區塊。當前共識規則要求區塊的區塊標頭時間大於該區塊中任何交易指定的鎖定時間。 + +礦工可以選擇用於其標頭時間的時間，共識規則是沒有節點會接受其時間比未來時間超過兩個小時的區塊。這為礦工創造了一個激勵，讓他們將標頭時間設定為未來值，以便包含原本不應該在未來兩個小時內包含的鎖定時間交易。 + +共識規則還指定有效區塊的標頭時間可以大於前 11 個區塊的中位數時間。此 GetMedianTimePast() 時間具有我們通常與時間相關的關鍵特徵：它不能倒退。 + +[BIP113][] 指定在此版本中強制執行的軟分叉，透過要求有效區塊的計算 GetMedianTimePast() 大於該區塊中任何交易指定的鎖定時間，來削弱個別礦工使用未來時間的這種不當激勵。 + +**對礦工的影響：**您將開始拒絕在 BIP113 下無效的交易，這將防止您在網路上強制執行 BIP113 時產生無效區塊。在當前規則下有效但在 BIP113 規則下尚未有效的任何交易將由其他礦工挖掘或延遲，直到它們在 BIP113 下有效為止。 + +**對使用者的影響：**GetMedianTimePast() 總是落後於當前時間，因此鎖定時間設定為當前時間的交易將被執行此版本的節點拒絕，直到中位數時間向前移動。為了補償，從您的鎖定時間中減去一小時（3,600 秒），以允許這些交易在大約預期的時間被包含在 mempool 中。 + +有關實作的更多資訊，請參閱 + +雜項 +------------- + +p2p 警報系統預設關閉。要開啟，請在啟動配置中使用 `-alert`。 + +0.12.1 變更日誌 +================= + +### RPC 和其他 API +- #7739 `7ffc2bd` Add abandoned status to listtransactions (jonasschnelli) + +### 區塊和交易處理 +- #7543 `834aaef` Backport BIP9, BIP68 and BIP112 with softfork (btcdrak) + +### P2P 協定和網路程式碼 +- #7804 `90f1d24` Track block download times per individual block (sipa) +- #7832 `4c3a00d` Reduce block timeout to 10 minutes (laanwj) + +### 驗證 +- #7821 `4226aac` init: allow shutdown during 'Activating best chain...' (laanwj) +- #7835 `46898e7` Version 2 transactions remain non-standard until CSV activates (sdaftuar) + +### 建置系統 +- #7487 `00d57b4` Workaround Travis-side CI issues (luke-jr) +- #7606 `a10da9a` No need to set -L and --location for curl (MarcoFalke) +- #7614 `ca8f160` Add curl to packages (now needed for depends) (luke-jr) +- #7776 `a784675` Remove unnecessary executables from gitian release (laanwj) + +### 錢包 +- #7715 `19866c1` Fix calculation of balances and available coins (morcos) + +### 雜項 +- #7617 `f04f4fd` Fix markdown syntax and line terminate LogPrint (MarcoFalke) +- #7747 `4d035bc` added depends cross compile info (accraze) +- #7741 `a0cea89` Mark p2p alert system as deprecated (btcdrak) +- #7780 `c5f94f6` Disable bad-chain alert (btcdrak) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- accraze +- Alex Morcos +- BtcDrak +- Jonas Schnelli +- Luke Dashjr +- MarcoFalke +- Mark Friedenbach +- NicolasDorier +- Pieter Wuille +- Suhas Daftuar +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2016-08-23-release-0.13.0.md b/_posts/zh_TW/releases/2016-08-23-release-0.13.0.md new file mode 100644 index 000000000..810037337 --- /dev/null +++ b/_posts/zh_TW/releases/2016-08-23-release-0.13.0.md @@ -0,0 +1,190 @@ +--- +title: Bitcoin Core 0.13.0 +id: zh_tw-release-0.13.0 +name: release-0.13.0 +permalink: /zh_TW/releases/0.13.0/ +excerpt: Bitcoin Core 0.13.0 版本現已發布 +date: 2016-08-23 +type: releases +layout: page +lang: zh_TW + +release: [0, 13, 0, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.13.0 版本現已發布，可從以下位置下載： + + + +此主要版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +從 0.13.0 開始，不再支援 Windows XP。建議使用者升級到較新版本的 Windows，或安裝支援的替代作業系統。我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但不要期望它能正常工作：請不要向問題追蹤器回報關於 Windows XP 的問題。 + +重要變更 +=============== + +資料庫快取記憶體增加 +-------------------------------- + +由於 UTXO 集合的增長，使用先前預設的 100 MiB 資料庫快取的效能已經下降。因此，此版本中的預設值已更改為 300 MiB。 + +對於低記憶體系統上的節點，可以透過以下方式將資料庫快取更改回 100 MiB（或其他值）： + +- 在 bitcoin.conf 中新增 `dbcache=100` +- 在 GUI 中的 `選項 → 資料庫快取大小` 下更改 + +請注意，資料庫快取設定在節點的初始同步期間和停機後追趕時對效能影響最大。 + +bitcoin-cli：參數隱私 +------------------------------ + +RPC 命令列客戶端獲得了一個新參數 `-stdin`，用於從標準輸入讀取額外參數，每行一個，直到 EOF/Ctrl-D。例如： + + $ src/bitcoin-cli -stdin walletpassphrase + mysecretcode + 120 + ..... 在此處按 Ctrl-D 結束輸入 + $ + +建議將此用於敏感資訊（如錢包密碼），因為命令列參數通常可以被系統上的任何使用者從處理程序表中讀取。 + +C++11 和 Python 3 +------------------ + +已進行各種程式碼現代化。Bitcoin Core 程式碼庫已開始使用 C++11。這意味著現在建置需要支援 C++11 的編譯器。實際上這意味著 GCC 4.7 或更高版本，或 Clang 3.3 或更高版本。 + +對於在 `qa/rpc-tests` 中執行功能測試，現在需要 Python3.4 或更高版本。 + +Linux ARM 建置 +---------------- + +由於普遍的要求，Linux ARM 建置已新增到上傳的可執行檔中。 + +下載目錄或 torrent 中可以找到以下額外檔案： + +- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`：針對最常見的 32 位元 ARM 架構的 Linux 二進位檔。 +- `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`：針對最常見的 64 位元 ARM 架構的 Linux 二進位檔。 + +ARM 建置仍然是實驗性的。請注意，Android 在此上下文中不被視為 ARM Linux。 + +緊湊區塊支援（BIP 152） +------------------------------- + +已在 PR 8068 中實作使用緊湊區塊協定進行區塊中繼的支援。 + +主要目標是減少中繼時的頻寬尖峰，儘管在許多情況下它也減少了傳播延遲。它在相容對等節點之間自動啟用。 +[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) + +階層式確定性金鑰生成 +----------------------------------------- +新建立的錢包將根據 BIP32 使用階層式確定性金鑰生成（keypath m/0'/0'/k'）。現有錢包仍將使用傳統金鑰生成。 + +無論何時建立，HD 錢包的備份都可用於重新生成所有可能的私鑰，即使是在備份時尚未生成的私鑰。 +**注意：**加密錢包將建立新的 seed，這需要新的備份！ + +使用 `dumpwallet` RPC 建立的錢包轉儲將包含確定性 seed。這預計將允許未來版本匯入 seed 和所有相關資金，但這尚未實作。 + +可以透過 `-usehd=0` 為新錢包停用 HD 金鑰生成。請記住，此標記只對新建立的錢包有效。一旦建立了 HD 錢包，就無法停用 HD 金鑰生成。 + +內部和外部金鑰之間沒有區別。 + +HD 錢包與舊版本的 Bitcoin Core 不相容。 + +[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files)、[BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) + +Segregated Witness +------------------ + +Segregated Witness (「segwit」) 的程式碼準備工作（如 [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)、[BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)、[BIP 144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) 和 [BIP 145](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) 中所述）已完成並包含在此版本中。然而，BIP 141 尚未指定 mainnet 上的啟動參數，因此此版本不支援在 mainnet 上使用 segwit。支援在 testnet 上使用。 + +在 BIP 141 更新為建議參數後，預計將發布實作這些 mainnet 參數的 Bitcoin Core 未來版本。 + +挖礦交易選擇（「Child Pays For Parent」） +------------------------------------------------------ + +挖礦交易選擇演算法已被替換為基於未確認祖先交易的費率選擇交易的演算法。這意味著，如果中繼支出其輸出的高費用交易，低費用交易可能更有可能被選中。 + +隨著此變更，`-blockminsize` 命令列選項已被移除。 + +命令列選項 `-blockmaxsize` 仍然是指定生成區塊中最大序列化位元組數的選項。此外，已新增新的命令列選項 `-blockmaxweight`，它指定生成區塊的最大「區塊權重」，如 [BIP 141 (Segregated Witness)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) 所定義。 + +重新索引變更 +------------------ + +在早期版本中，重新索引在讀取磁碟上的區塊檔案時進行驗證。這兩者現在已被分開，因此在驗證開始之前所有區塊都是已知的。這對於使正常同步期間可用的某些最佳化在重新索引期間也可用是必要的。 + +在 Bitcoin-Qt GUI 中，這兩個階段是不同的。在第一階段期間，顯示「在磁碟上重新索引區塊」。在第二階段（較慢）期間，顯示「在磁碟上處理區塊」。 + +現在可以只重做驗證，而不重建區塊索引，使用命令列選項 `-reindex-chainstate`（除了執行兩者的 `-reindex`）。當假設磁碟上的區塊正常，但 chainstate 仍然損壞時，此新選項很有用。它對基準測試也很有用。 + +移除內部礦工 +-------------------------- + +由於 CPU 挖礦已經無用很長時間，內部礦工已在此版本中移除，並替換為測試框架的更簡單實作。 + +這的整體結果是 `setgenerate` RPC 呼叫已被移除，以及 `-gen` 和 `-genproclimit` 命令列選項。 + +對於測試，`generate` 呼叫仍可用於挖掘區塊，並已新增新的 RPC 呼叫 `generatetoaddress` 以挖掘到特定位址。這在停用錢包的情況下有效。 + +低階 P2P 變更 +---------------------- + +- 實作了可選的新 p2p 訊息「feefilter」，協定版本提升到 70013。在從對等節點接收到 feefilter 訊息後，節點不會為不符合過濾器費率的任何交易發送 inv。[BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki) + +- P2P 警報系統已在 PR #7692 中移除，不再支援 `alert` P2P 訊息。 + +- 交易中繼機制曾經立即中繼四分之一的所有交易，同時將其餘交易排隊並分批發送出去。由於這導致依賴交易鏈被重新排序，它系統性地損害了交易中繼。中繼程式碼在 PR #7840 和 #8082 中被重新設計，現在總是批次處理交易公告，同時也根據依賴順序對它們進行排序。這顯著減少了孤立交易。 + +- 自 PR #7840 以來，BIP35 `mempool` 命令也受批次處理的影響。當透過 `-peerbloomfilters=0` 停用 `NODE_BLOOM` 時，非白名單對等節點的 `mempool` 訊息不再被處理。 + +- 保留在記憶體中直到其祖先到達的孤立交易的最大大小在 PR #8179 中從 5000 提高到 99999 位元組。當它們被包含在區塊中、與區塊衝突以及在 20 分鐘後超時時，它們現在也會從記憶體中移除。 + +低階 RPC 變更 +---------------------- + +- 已新增 RPC 呼叫以輸出單個 mempool 條目的詳細統計資訊，以及計算交易的記憶體內祖先或後代：請參閱 `getmempoolentry`、`getmempoolancestors`、`getmempooldescendants`。 + +- `gettxoutsetinfo` UTXO 雜湊（`hash_serialized`）已變更。32 位元和 64 位元平台之間存在差異，雜湊資料中缺少 txid。這已被修復，但這意味著輸出將與先前版本不同。 + +- RPC API 中的完整 UTF-8 支援。例如，錢包標籤中的非 ASCII 字元總是格式錯誤的，因為在 JSON RPC 處理中沒有正確考慮它們。這不再是問題。這也影響 GUI 除錯控制台。 + +- Asm 腳本輸出替換 OP_NOP2 和 OP_NOP3 + - OP_NOP2 已被 [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) 重新命名為 OP_CHECKLOCKTIMEVERIFY + - OP_NOP3 已被 [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) 重新命名為 OP_CHECKSEQUENCEVERIFY + +- 新的 RPC 命令：`generatetoaddress`、`importprunedfunds`、`removeprunedfunds`、`signmessagewithprivkey`、`getmempoolancestors`、`getmempooldescendants`、`getmempoolentry`、`createwitnessaddress`、`addwitnessaddress`。 + +- 移除的 RPC 命令：`setgenerate`、`getgenerate`。 + +- 已為 `fundrawtransaction` 新增選項：`includeWatching`、`changeAddress`、`changePosition` 和 `feeRate`。 + +低階 ZMQ 變更 +---------------------- + +- 每個 ZMQ 通知現在都包含一個遞增序號，允許監聽器檢測丟失的通知。序號始終是多部分 ZMQ 通知中的最後一個元素，因此向後相容。每種訊息類型都有自己的計數器。PR #7762。 + +0.13.0 變更日誌 +================= + +完整的變更日誌包含數百個 PR，涵蓋 RPC 和其他 API、區塊和交易處理、P2P 協定和網路程式碼、驗證、建置系統、GUI、錢包、挖礦、測試和 QA、文件等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 100 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2016-10-27-release-0.13.1.md b/_posts/zh_TW/releases/2016-10-27-release-0.13.1.md new file mode 100644 index 000000000..7c526309f --- /dev/null +++ b/_posts/zh_TW/releases/2016-10-27-release-0.13.1.md @@ -0,0 +1,146 @@ +--- +title: Bitcoin Core 0.13.1 +id: zh_tw-release-0.13.1 +name: release-0.13.1 +permalink: /zh_TW/releases/0.13.1/ +excerpt: Bitcoin Core 0.13.1 版本現已發布 +date: 2016-10-27 +type: releases +layout: page +lang: zh_TW + +release: [0, 13, 1, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.13.1 版本現已發布，可從以下位置下載： + + + +此小版本包含 segwit 軟分叉的啟動參數、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +從 0.13.0 開始，不再支援 Windows XP。建議使用者升級到較新版本的 Windows，或安裝支援的替代作業系統。我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但不要期望它能正常工作：請不要向問題追蹤器回報關於 Windows XP 的問題。 + +從 0.13.1 開始，不再支援 OS X 10.7。0.13.0 原本打算在 10.7+ 上運作，但 10.7.x 上的 libc++ 版本存在嚴重問題，使其無法可靠執行。0.13.1 現在需要 10.8+，並會將此訊息傳達給 10.7 使用者，而不是意外崩潰。 + +重要變更 +=============== + +Segregated Witness 軟分叉 +---------------------------- + +Segregated witness (segwit) 是一種軟分叉，如果啟動，將允許產生交易的軟體將交易簽名（見證）與交易中由 txid 覆蓋的部分資料分離（隔離）。這提供了幾個即時好處： + +- **消除不需要的交易可塑性**：隔離見證允許現有和升級的軟體在不引用見證的情況下計算交易識別符（txid），見證有時可能被第三方（如礦工）或多重簽名支出中的共同簽名者更改。這解決了所有已知的不需要的交易可塑性案例，這使得編寫 Bitcoin 錢包軟體更加困難，並嚴重複雜化了 Bitcoin 智慧合約的設計。 + +- **容量增加**：Segwit 交易包含新欄位，這些欄位不是目前用於計算區塊大小的資料的一部分，這允許包含 segwit 交易的區塊容納比當前最大區塊大小允許的更多資料。基於目前在區塊中發現的交易的估算表明，如果所有錢包都切換到使用 segwit，網路將能夠支援大約 70% 更多的交易。 + +- **基於對節點效能影響的資料加權**：在 segwit 啟動後，隔離見證的每個位元組被賦予權重 1，區塊中的每個其他位元組被賦予權重 4，區塊的最大允許權重為 400 萬。以這種方式加權資料更好地將建立區塊的最有利可圖的策略與區塊驗證的長期成本對齊。 + +- **簽名覆蓋價值**：Segwit 中簽名生成方式的簡單改進簡化了安全簽名產生器（如硬體錢包）的設計，減少了簽名產生器需要下載的資料量，並允許簽名產生器更快地操作。 + +- **Sighash 操作的線性擴展**：在 2015 年，由於交易簽名雜湊的執行方式，產生了一個在現代硬體上需要大約 25 秒驗證的區塊。可以選擇加入使用 segwit 的交易現在將使用不同的簽名方法，不會遭受此問題且沒有任何不需要的副作用。 + +- **提高多重簽名的安全性**：Segwit 允許進階交易使用 SHA256 雜湊函數，提供約 128 位元的安全性（相當於 ECDSA 提供的最大安全位元數）。 + +- **腳本版本控制**：Segwit 使得未來的軟分叉可以輕鬆允許 Bitcoin 使用者在收到新交易時單獨選擇加入 Bitcoin Script 語言的幾乎任何變更。目前由 Bitcoin Core 貢獻者研究的功能包括 Schnorr 簽名和 Merklized Abstract Syntax Trees (MAST) 支援。 + +Segwit 軟分叉的啟動使用 BIP9 versionbits 進行管理。Segwit 的版本位元是位元 1，節點將在 segwit 開始日期 2016 年 11 月 15 日後的第一個重新目標期間開始追蹤哪些區塊發送 segwit 支援訊號。如果 2,016 個區塊的重新目標期間（約兩週）內 95% 的區塊發送 segwit 支援訊號，軟分叉將被鎖定。再經過 2,016 個區塊後，segwit 將啟動。 + +有關 segwit 的更多資訊，請參閱 [segwit FAQ][]、[segwit wallet developers guide][] 或 BIP [141][BIP141]、[143][BIP143]、[144][BIP144] 和 [145][BIP145]。如果您是礦工或礦池營運商，請參閱 [versionbits FAQ][] 以獲取有關為軟分叉發送支援訊號的資訊。 + +[Segwit FAQ]: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ +[segwit wallet developers guide]: https://bitcoincore.org/en/segwit_wallet_dev/ +[BIP141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki +[BIP143]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki +[BIP144]: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki +[BIP145]: https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki +[versionbits FAQ]: https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/ + +Null dummy 軟分叉 +------------------- + +與 segwit 軟分叉結合的是一個額外變更，將長期存在的網路中繼政策轉變為共識規則。`OP_CHECKMULTISIG` 和 `OP_CHECKMULTISIGVERIFY` 操作碼在簽名驗證後消耗額外的堆疊元素（「dummy element」）。Dummy element 不會以任何方式檢查，可以被任何值替換而不會使腳本無效。 + +由於任何值都可以用於此 dummy element，第三方可以將資料插入其他人的交易中，更改交易的 txid（稱為交易可塑性）並可能造成其他問題。 + +自 Bitcoin Core 0.10.0 以來，節點預設只中繼和挖掘其 dummy element 為 null 值（0x00，也稱為 OP_0）的交易。Null dummy 軟分叉將此中繼規則轉變為共識規則，適用於非 segwit 交易和 segwit 交易，因此這種變異交易的方法從網路中永久消除。 + +Null dummy 軟分叉的訊號是透過為 segwit 發送支援訊號來完成的，null dummy 軟分叉將與 segwit 同時啟動。 + +有關更多資訊，請參閱 [BIP147][]。 + +[BIP147]: https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki + +低階 RPC 變更 +--------------------- + +- `importprunedfunds` 只接受兩個必需參數。某些版本接受可選的第三個參數，但總是被忽略。請確保永遠不要傳遞超過兩個參數。 + +Linux ARM 建置 +---------------- + +從 0.13.0 版本開始，預建構的 Linux ARM 二進位檔已新增到上傳的可執行檔集合中。以下提供每個目標 ARM 架構的其他詳細資訊。 + +下載目錄或 torrent 中可以找到以下額外檔案： + +- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`：針對 32 位元 ARMv7-A 架構的 Linux 二進位檔。 +- `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`：針對 64 位元 ARMv8-A 架構的 Linux 二進位檔。 + +ARM 建置仍然是實驗性的。如果您在某個裝置或 Linux 發行版組合上遇到問題，請在錯誤追蹤器上回報，可能可以解決。請注意，您使用的裝置必須（向後）相容您使用的二進位檔所針對的架構。 + +請注意，在此上下文中，Android 不被視為 ARM Linux。這些可執行檔預計不會在 Android 上開箱即用。 + +0.13.1 變更日誌 +================= + +完整的變更日誌包含數百個 PR。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +### 主要變更包括： + +**共識** +- 實作 NULLDUMMY 軟分叉（BIP147） +- 定義 segwit 部署的開始和結束時間 + +**RPC 和其他 API** +- 移除 importprunedfunds 中的誤導性選項 +- 移除 createwitnessaddress RPC 命令 +- 棄用 getinfo +- 在十六進位而非 base64 中生成認證 cookie + +**P2P 協定和網路程式碼** +- 不再在 addrMe 中發送本地位址 +- 忽略 notfound P2P 訊息 +- 支援緊湊區塊與 segwit 一起使用 +- Feeler 連線以增加 tried table 中的線上位址 + +**GUI** +- 修復最小化和關閉錯誤 +- 在選項重設後持久化 datadir +- 修復可能導致支付意外費用的 UI 錯誤 +- 在隱藏服務執行時顯示網路/鏈錯誤 + +**錢包** +- 修復 segwit 相關的錢包錯誤 +- 將見證位址新增到位址簿 +- 從 removeprunedfunds 移除「未使用的」ThreadFlushWalletDB + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 60 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-01-03-release-0.13.2.md b/_posts/zh_TW/releases/2017-01-03-release-0.13.2.md new file mode 100644 index 000000000..e7398c764 --- /dev/null +++ b/_posts/zh_TW/releases/2017-01-03-release-0.13.2.md @@ -0,0 +1,167 @@ +--- +title: Bitcoin Core 0.13.2 +id: zh_tw-release-0.13.2 +name: release-0.13.2 +permalink: /zh_TW/releases/0.13.2/ +excerpt: Bitcoin Core 0.13.2 版本現已發布 +date: 2017-01-03 +type: releases +layout: page +lang: zh_TW + +release: [0, 13, 2, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.13.2 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +Microsoft 已於 [2014 年 4 月 8 日](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support)終止對 Windows XP（最初於 2001 年發布的作業系統）的支援。這意味著甚至不會再發布關鍵的安全性更新。在沒有安全性更新的情況下，在 XP 機器上使用 bitcoin 錢包至少是不負責任的。 + +此外，在 0.12.x 中有各種關於 Bitcoin Core 在 Windows XP 上隨機崩潰的報告。尚[不清楚](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)這些崩潰的來源是什麼，但很可能是上游程式庫（如 Qt）不再在 XP 上測試。 + +我們沒有時間或資源為生命週期結束的作業系統提供支援。從 0.13.0 開始，不再支援 Windows XP。建議使用者升級到較新版本的 Windows，或安裝支援的替代作業系統。 + +我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但不要期望它能正常工作：請不要向問題追蹤器回報關於 Windows XP 的問題。 + +從 0.13.1 開始，不再支援 OS X 10.7。0.13.0 原本打算在 10.7+ 上運作，但 10.7.x 上的 libc++ 版本存在嚴重問題，使其無法可靠執行。0.13.1 現在需要 10.8+，並會將此訊息傳達給 10.7 使用者，而不是意外崩潰。 + +重要變更 +=============== + +錢包處理 mempool 拒絕的變更 +----------------------------------------------- + +當新建立的交易由於未確認交易鏈的限制而無法進入 mempool 時，發送 RPC 呼叫會返回錯誤。交易仍會在錢包中排隊，一旦某些父交易被確認，在軟體重新啟動後會廣播。 + +此行為已更改為返回成功，並在嘗試交易重新廣播的同時重新嘗試 mempool 插入，避免需要重新啟動。 + +無法被 mempool 接受的錢包中的交易可以使用先前存在的 abandontransaction RPC（或在 GUI 中透過交易的上下文選單）放棄。 + +0.13.2 變更日誌 +================= + +### 共識 +- #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell) +- #9053 `5b93eee` IBD using chainwork instead of height and not using header timestamps (gmaxwell) + +### RPC 和其他 API +- #8845 `1d048b9` Don't return the address of a P2SH of a P2SH (jnewbery) +- #9041 `87fbced` keypoololdest denote Unix epoch, not GMT (s-matthew-english) +- #9122 `f82c81b` fix getnettotals RPC description about timemillis (visvirial) +- #9042 `5bcb05d` [rpc] ParseHash: Fail when length is not 64 (MarcoFalke) +- #9194 `f26dab7` Add option to return non-segwit serialization via rpc (instagibbs) +- #9347 `b711390` [0.13.2] wallet/rpc backports (MarcoFalke) +- #9292 `c365556` Complain when unknown rpcserialversion is specified (sipa) +- #9322 `49a612f` [qa] Don't set unknown rpcserialversion (MarcoFalke) + +### 區塊和交易處理 +- #8357 `ce0d817` [mempool] Fix relaypriority calculation error (maiiz) +- #9267 `0a4aa87` [0.13 backport #9239] Disable fee estimates for a confirm target of 1 block (morcos) +- #9196 `0c09d9f` Send tip change notification from invalidateblock (ryanofsky) + +### P2P 協定和網路程式碼 +- #8995 `9ef3875` Add missing cs_main lock to ::GETBLOCKTXN processing (TheBlueMatt) +- #9234 `94531b5` torcontrol: Explicitly request RSA1024 private key (laanwj) +- #8637 `2cad5db` Compact Block Tweaks (rebase of #8235) (sipa) +- #9058 `286e548` Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (ryanofsky) +- #8865 `4c71fc4` Decouple peer-processing-logic from block-connection-logic (TheBlueMatt) +- #9117 `6fe3981` net: don't send feefilter messages before the version handshake is complete (theuni) +- #9188 `ca1fd75` Make orphan parent fetching ask for witnesses (gmaxwell) +- #9052 `3a3bcbf` Use RelevantServices instead of node_network in AttemptToEvict (gmaxwell) +- #9048 `9460771` [0.13 backport #9026] Fix handling of invalid compact blocks (sdaftuar) +- #9357 `03b6f62` [0.13 backport #9352] Attempt reconstruction from all compact block announcements (sdaftuar) +- #9189 `b96a8f7` Always add default_witness_commitment with GBT client support (sipa) +- #9253 `28d0f22` Fix calculation of number of bound sockets to use (TheBlueMatt) +- #9199 `da5a16b` Always drop the least preferred HB peer when adding a new one (gmaxwell) + +### 建置系統 +- #9169 `d1b4da9` build: fix qt5.7 build under macOS (theuni) +- #9326 `a0f7ece` Update for OpenSSL 1.1 API (gmaxwell) +- #9224 `396c405` Prevent FD_SETSIZE error building on OpenBSD (ivdsangen) + +### GUI +- #8972 `6f86b53` Make warnings label selectable (jonasschnelli) (MarcoFalke) +- #9185 `6d70a73` Fix coincontrol sort issue (jonasschnelli) +- #9094 `5f3a12c` Use correct conversion function for boost::path datadir (laanwj) +- #8908 `4a974b2` Update bitcoin-qt.desktop (s-matthew-english) +- #9190 `dc46b10` Plug many memory leaks (laanwj) + +### 錢包 +- #9290 `35174a0` Make RelayWalletTransaction attempt to AcceptToMemoryPool (gmaxwell) +- #9295 `43bcfca` Bugfix: Fundrawtransaction: don't terminate when keypool is empty (jonasschnelli) +- #9302 `f5d606e` Return txid even if ATMP fails for new transaction (sipa) +- #9262 `fe39f26` Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs) + +### 測試和 QA +- #9159 `eca9b46` Wait for specific block announcement in p2p-compactblocks (ryanofsky) +- #9186 `dccdc3a` Fix use-after-free in scheduler tests (laanwj) +- #9168 `3107280` Add assert_raises_message to check specific error message (mrbandrews) +- #9191 `29435db` 0.13.2 Backports (MarcoFalke) +- #9077 `1d4c884` Increase wallet-dump RPC timeout (ryanofsky) +- #9098 `ecd7db5` Handle zombies and cluttered tmpdirs (MarcoFalke) +- #8927 `387ec9d` Add script tests for FindAndDelete in pre-segwit and segwit scripts (jl2012) +- #9200 `eebc699` bench: Fix subtle counting issue when rescaling iteration count (laanwj) + +### 雜項 +- #8838 `094848b` Calculate size and weight of block correctly in CreateNewBlock() (jnewbery) +- #8920 `40169dc` Set minimum required Boost to 1.47.0 (fanquake) +- #9251 `a710a43` Improvement of documentation of command line parameter 'whitelist' (wodry) +- #8932 `106da69` Allow bitcoin-tx to create v2 transactions (btcdrak) +- #8929 `12428b4` add software-properties-common (sigwo) +- #9120 `08d1c90` bug: Missed one "return false" in recent refactoring in #9067 (UdjinM6) +- #9067 `f85ee01` Fix exit codes (UdjinM6) +- #9340 `fb987b3` [0.13] Update secp256k1 subtree (MarcoFalke) +- #9229 `b172377` Remove calls to getaddrinfo_a (TheBlueMatt) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Alex Morcos +- BtcDrak +- Cory Fields +- fanquake +- Gregory Maxwell +- Gregory Sanders +- instagibbs +- Ivo van der Sangen +- jnewbery +- Johnson Lau +- Jonas Schnelli +- Luke Dashjr +- maiiz +- MarcoFalke +- Masahiko Hyuga +- Matt Corallo +- matthias +- mrbandrews +- Pavel Janík +- Pieter Wuille +- randy-waterhouse +- Russell Yanofsky +- S. Matthew English +- Steven +- Suhas Daftuar +- UdjinM6 +- Wladimir J. van der Laan +- wodry + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-03-08-release-0.14.0.md b/_posts/zh_TW/releases/2017-03-08-release-0.14.0.md new file mode 100644 index 000000000..2a01114c7 --- /dev/null +++ b/_posts/zh_TW/releases/2017-03-08-release-0.14.0.md @@ -0,0 +1,231 @@ +--- +title: Bitcoin Core 0.14.0 +id: zh_tw-release-0.14.0 +name: release-0.14.0 +permalink: /zh_TW/releases/0.14.0/ +excerpt: Bitcoin Core 0.14.0 版本現已發布 +date: 2017-03-08 +type: releases +layout: page +lang: zh_TW + +release: [0, 14, 0, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.14.0 版本現已發布，可從以下位置下載： + + + +此主要版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。 + +Microsoft 已於 [2014 年 4 月 8 日](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support)終止對 Windows XP 的支援，我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但請注意存在已知的不穩定性和問題。請不要向問題追蹤器回報關於 Windows XP 的問題。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +效能改進 +-------------- + +版本 0.14 包含許多重大的效能改進，大幅縮短初始區塊下載、啟動、交易和區塊驗證時間： + +- 腳本簽名快取已重新實作為「cuckoo cache」，允許快取更多簽名並加快查找速度。 +- 引入了 assumed-valid 區塊，允許跳過已知良好區塊的祖先的腳本驗證，而不改變安全模型。詳情請見下文。 +- 在某些情況下，緊湊區塊現在在完全驗證之前就被中繼，符合 BIP152 規範。 +- P2P 網路已重構，專注於並發性和吞吐量。網路操作不再受驗證瓶頸限制。因此，在許多情況下，區塊獲取比先前版本快數倍。 +- UTXO 快取現在聲明未使用的 mempool 記憶體。這加快了初始區塊下載，因為 UTXO 查找是主要瓶頸，在該階段 mempool 沒有用處。 + +手動修剪 +-------------- + +Bitcoin Core 自 0.11 以來就支援自動修剪區塊鏈。修剪區塊鏈可以顯著節省儲存空間，因為在處理後可以丟棄絕大多數下載的資料，因此磁碟上只保留很少的資料。 + +現在可以透過設定 `-prune=1` 啟用手動區塊修剪。設定後，RPC 命令 `pruneblockchain` 可用於將區塊鏈修剪到指定的高度或時間戳記。 + +`getinfo` 已棄用 +-------------------- + +`getinfo` RPC 命令已被棄用。RPC 呼叫中的每個欄位都已移至另一個命令的輸出，該命令還提供 `getinfo` 未提供的其他資訊。下表顯示每個欄位已移至何處： + +|`getinfo` 欄位 | 移至 | +|------------------|-------------------------------------------| +`"version"` | `getnetworkinfo()["version"]` +`"protocolversion"`| `getnetworkinfo()["protocolversion"]` +`"walletversion"` | `getwalletinfo()["walletversion"]` +`"balance"` | `getwalletinfo()["balance"]` +`"blocks"` | `getblockchaininfo()["blocks"]` +`"timeoffset"` | `getnetworkinfo()["timeoffset"]` +`"connections"` | `getnetworkinfo()["connections"]` +`"proxy"` | `getnetworkinfo()["networks"][0]["proxy"]` +`"difficulty"` | `getblockchaininfo()["difficulty"]` +`"testnet"` | `getblockchaininfo()["chain"] == "test"` +`"keypoololdest"` | `getwalletinfo()["keypoololdest"]` +`"keypoolsize"` | `getwalletinfo()["keypoolsize"]` +`"unlocked_until"` | `getwalletinfo()["unlocked_until"]` +`"paytxfee"` | `getwalletinfo()["paytxfee"]` +`"relayfee"` | `getnetworkinfo()["relayfee"]` +`"errors"` | `getnetworkinfo()["warnings"]` + +Windows 上的 ZMQ +-------------- + +由於 ZMQ 的各種問題，先前 ZeroMQ 通知系統在 Windows 上不可用。這些問題已在上游修復，現在 Windows 上可以使用 ZMQ。請參閱[此文件](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md)以獲得使用 ZMQ 的一般幫助。 + +除錯控制台中的巢狀 RPC 命令 +------------------------------------ + +除錯控制台已新增巢狀 RPC 命令的功能。這允許使用者讓一個命令的輸出成為另一個命令的輸入，而無需單獨執行命令。 + +巢狀 RPC 命令使用括號語法（即 `getwalletinfo()`），並且可以巢狀（即 `getblock(getblockhash(1))`）。可以使用方括號進行簡單查詢，使用陣列索引或非引號字串存取物件值（即 `listunspent()[0][txid]`）。括號語法和正常 RPC 命令語法中都可以使用逗號和空格來分隔參數。 + +網路活動切換 +----------------------- + +已新增 RPC 命令和 GUI 切換以啟用或停用所有 p2p 網路活動。右下角的網路狀態圖示現在是 GUI 切換。點擊圖示將啟用或停用所有 p2p 網路活動。如果停用網路活動，圖示將變灰並在上面顯示 X。 + +此外，已新增 `setnetworkactive` RPC 命令，其功能與 GUI 圖示相同。該命令採用一個布林參數，`true` 啟用網路，`false` 停用網路。 + +非同步模態資訊層 +---------------------------- + +當 Bitcoin Core 在啟動時不同步時，將在正常顯示上方顯示半透明的資訊層。此層包含有關當前同步進度的詳細資訊，並估計完成同步所需的剩餘時間。此層也可以透過點擊視窗底部的進度條來隱藏和隨後取消隱藏。 + +支援 JSON-RPC 具名參數 +------------------------------------ + +透過 JSON-RPC 介面和透過 `bitcoin-cli` 二進位檔發送的命令現在可以使用具名參數。這遵循 [JSON-RPC 規範](http://www.jsonrpc.org/specification)以物件按名稱傳遞參數。 + +`bitcoin-cli` 已更新為在給定 `-named` 選項時透過解析 `name=value` 參數來支援此功能。 + +一些範例： + + src/bitcoin-cli -named help command="help" + src/bitcoin-cli -named getblockhash height=0 + src/bitcoin-cli -named getblock blockhash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f + src/bitcoin-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true + +在這種情況下參數的順序無關緊要。具名參數對於省略應保持預設值的參數也很有用。很少使用的參數 `comment` 和 `comment_to` 到 `sendtoaddress` 例如可以省略。然而，這尚未為許多 RPC 呼叫實作，預計將在未來版本中實現。 + +RPC 伺服器仍然完全向後相容位置參數。 + +發送時選擇加入 RBF +------------------------- + +已新增新的啟動選項 `-walletrbf`，允許使用者讓所有發送的交易選擇加入 RBF 支援。此選項的預設值目前為 `false`，因此交易預設不會選擇加入 RBF。新的 `bumpfee` RPC 可用於替換選擇加入 RBF 的交易。 + +除錯控制台歷史中不再儲存敏感資料 +----------------------------------------------------------- + +除錯控制台維護先前輸入命令的歷史記錄，可以透過按上箭頭鍵存取，以便使用者可以輕鬆重複使用先前輸入的命令。當透過歷史記錄存取時，具有敏感資訊（如密碼和私鑰）的命令現在將在參數位置顯示 `(...)`。 + +跨重啟保留 Mempool +------------------------------------- + +在關閉之前，mempool 將儲存到資料目錄中的 `mempool.dat` 檔案。此檔案保留 mempool，以便在節點重新啟動時，可以在不等待建立新交易的情況下填充 mempool 中的交易。這也保留透過 `prioritisetransaction` 等命令對交易所做的任何變更，因此這些變更不會丟失。 + +最終警報 +----------- + +警報系統在 Bitcoin Core 0.12.1 中[被停用和棄用](https://bitcoin.org/en/alert/2016-11-01-alert-retirement)，並在 0.13.0 中移除。警報系統以最大序列最終警報退役，該警報導致支援警報系統的任何節點顯示靜態硬編碼的「Alert Key Compromised」訊息，這也阻止任何其他警報覆蓋它。此最終警報已硬編碼到此版本中，以便所有舊節點都收到最終警報。 + +GUI 變更 +----------- + +- 在選項對話框中點擊 `Reset Options` 按鈕或使用 `-resetguioptions` 啟動選項重設選項後，將提示使用者再次選擇資料目錄。這是為了確保在清除透過選擇資料目錄對話框設定的自訂資料目錄的選項重設後保留自訂資料目錄。 + +- 現在可以在除錯視窗的對等節點清單中選擇多個對等節點。這允許使用者同時禁止或中斷多個對等節點的連線，而不是一次禁止一個。 + +- 已在主視窗的右下角新增一個指示器，以指示正在使用的錢包是否為 HD 錢包。如果錢包不是 HD 錢包，此圖示將變灰並在上面顯示 X。 + +低階 RPC 變更 +---------------------- + +- `importprunedfunds` 只接受兩個必需參數。某些版本接受可選的第三個參數，但總是被忽略。請確保永遠不要傳遞超過兩個參數。 + +- `getaddednodeinfo` 的第一個布林參數已被移除。這是一個不相容的變更。 + +- RPC 命令 `getmininginfo` 失去了「testnet」欄位，改用更通用的「chain」（已存在多年）。 + +- 已新增新的 RPC 命令 `preciousblock`，它將區塊標記為珍貴。珍貴區塊將被視為比競爭區塊更早接收。 + +- 已新增新的 RPC 命令 `importmulti`，它接收一個 JSON 物件陣列，表示匯入公鑰、私鑰、地址和腳本/p2sh 的意圖。 + +- 使用 `getrawtransaction` 檢索具有未花費輸出的已確認交易已被棄用。目前這仍然有效，但在未來可能會變更為只能檢索 mempool 中的交易資訊，或者如果啟用了 `txindex`。 + +- 已新增新的 RPC 命令 `getmemoryinfo`，它將返回有關 Bitcoin Core 記憶體使用情況的資訊。這是與記憶體管理最佳化一起新增的。詳見 Pull #8753。 + +- 已新增新的 RPC 命令 `bumpfee`，允許用支付更高費用的新交易替換發送 RBF 訊號的未確認錢包交易（參見上面的 `-walletrbf` 啟動選項），並且應該更有可能快速確認。 + +引入 assumed-valid 區塊 +------------------------------------- + +- 初始區塊下載時間的很大一部分用於驗證腳本/簽名。儘管驗證必須通過以確保系統的安全性，但不需要來自此驗證的其他結果：如果節點知道給定區塊的歷史有效，它可以跳過檢查其祖先的腳本。 + +- 提供了新的配置選項 'assumevalid' 來向軟體表達這種知識。與過去的「checkpoints」不同，此設定不會強制使用特定的鏈：與其一致的鏈處理更快，但如果其他鏈被選為最佳鏈，仍然會被接受。與「checkpoints」不同，使用者可以配置假設為真的區塊歷史，這意味著即使過時的軟體在使用者更新設定後也可以更快地同步。 + +- 由於鏈歷史的有效性是一個簡單的客觀事實，因此審查此設定要容易得多。因此，軟體附帶一個預設值，調整為在發布前不久匹配當前鏈。可以透過設定 -assumevalid=0 來停用此預設值的使用。 + +最小費率政策 +------------------------- + +自 0.12 中的變更以來，自動限制 mempool 的大小和改進挖礦程式碼中區塊建立的效能，對中繼節點或礦工設定 `-minrelaytxfee` 已不重要。在此版本中，與此選項綁定的以下概念已被分離： +- 用於計算 BIP 125 替換和 mempool 限制的增量中繼費用（1000 satoshis/kB） +- 塵埃輸出的閾值計算（有效 3 * 1000 satoshis/kB） +- 由挖礦程式碼建立的區塊中要包含的交易包的最低費率。如果礦工希望設定此最低值，他們可以使用新的 `-blockmintxfee` 選項（預設為 1000 satoshis/kB） + +`-minrelaytxfee` 選項繼續存在，但建議保持不設定。 + +費用估算變更 +---------------------- + +- 自 0.13.2 以來，1 個區塊的確認目標的費用估算已被停用。費用滑桿將不再能夠選擇 1 個區塊的目標。這只是一個小的行為變更，因為無論如何這個目標通常沒有足夠的資料。`estimatefee 1` 現在總是返回 -1，`estimatesmartfee 1` 將從目標 2 開始搜尋。 + +- 費用估算的預設目標在 GUI（先前為 25）和 RPC 呼叫（先前為 2）中都更改為 6 個區塊。 + +移除優先級估算 +------------------------------ + +- 已移除對在目標區塊數內包含交易所需「優先級」的估算。RPC 呼叫已棄用，將適當地返回 -1 或 1e24。`fee_estimates.dat` 的格式也已變更為不再儲存這些優先級估算。它將自動轉換為新格式，先前版本的軟體無法讀取。 + +- 挖礦的「優先級」（幣齡）交易排序支援在 Core 中被視為已棄用，並將在下一個主要版本中移除。這不應與 `prioritisetransaction` RPC 混淆，該 RPC 仍將被 Core 支援以向交易新增費用增量。 + +P2P 連線管理 +-------------------------- + +- 透過 `-addnode` 選項或 `addnode` RPC 手動新增的對等節點現在有自己的八個連線限制，不會與其他入站或出站連線使用競爭，也不受 `-maxconnections` 選項施加的限制。 + +- 更快地執行與手動新增的對等節點的新連線。 + +未使用的 mempool 記憶體被 coincache 使用 +---------------------------------------- + +- 在 0.14 之前，為 mempool 保留的記憶體（使用 `-maxmempool` 選項）在初始區塊下載或 IBD 期間未使用。在 0.14 中，當有額外記憶體可用時，UTXO DB 快取（使用 `-dbcache` 選項控制）會從 mempool 借用記憶體。這可能導致在 IBD 期間記憶體使用量增加，對於先前僅依賴 `-dbcache` 選項在該時間限制記憶體的使用者。 + +0.14.0 變更日誌 +================= + +完整的變更日誌包含數百個 PR，涵蓋 RPC 和其他 API、區塊和交易處理、P2P 協定和網路程式碼、驗證、建置系統、GUI、錢包、測試和 QA 等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 120 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-04-22-release-0.14.1.md b/_posts/zh_TW/releases/2017-04-22-release-0.14.1.md new file mode 100644 index 000000000..aba15731d --- /dev/null +++ b/_posts/zh_TW/releases/2017-04-22-release-0.14.1.md @@ -0,0 +1,127 @@ +--- +title: Bitcoin Core 0.14.1 +id: zh_tw-release-0.14.1 +name: release-0.14.1 +permalink: /zh_TW/releases/0.14.1/ +excerpt: Bitcoin Core 0.14.1 版本現已發布 +date: 2017-04-22 +type: releases +layout: page +lang: zh_TW + +release: [0, 14, 1, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.14.1 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。 + +Microsoft 已於 [2014 年 4 月 8 日](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support)終止對 Windows XP 的支援，我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但請注意存在已知的不穩定性和問題。請不要向問題追蹤器回報關於 Windows XP 的問題。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +RPC 變更 +----------- + +- `createrawtransaction` 的第一個位置參數已從 `transactions` 重新命名為 `inputs`。 + +- `disconnectnode` 的參數已從 `node` 重新命名為 `address`。 + +這些介面變更會破壞與 0.14.0 的相容性，當使用在 0.14.0 中引入的具名參數功能時。使用這些呼叫與具名參數的客戶端軟體需要更新。 + +挖礦 +------ + +在先前版本中，一旦功能在網路上啟動，getblocktemplate 就需要下游客戶端/礦工支援 segwit。在此版本中，它現在在啟動後也支援非 segwit 客戶端，方法是從返回的區塊模板中移除所有 segwit 交易。這允許非 segwit 礦工在 segwit 啟動後繼續正常運作。 + +由於先前版本的限制，getblocktemplate 也建議非 segwit 客戶端不要為 segwit 版本位元發送訊號。由於這不再是問題，getblocktemplate 現在總是建議所有礦工發送 segwit 訊號。這是安全的，因為強制執行規則的能力是安全啟動的唯一必要標準，而不是實際生產啟用 segwit 的區塊。 + +UTXO 記憶體計算 +---------------------- + +UTXO 快取的記憶體使用量正在更準確地計算，因此當快取刷新期間記憶體使用量達到峰值時，將遵守配置的限制（`-dbcache`）。先前版本中的記憶體計算估計只佔實際峰值使用量的一半。 + +此版本中的預設 `-dbcache` 也已更改為 450MiB。目前將 `-dbcache` 設定為高值（例如為了在記憶體中保持 UTXO 更完全快取）的使用者應考慮增加此設定，以實現與先前版本相同的快取效能。低記憶體系統（如 1GB 或更少的系統）上的使用者應考慮為此參數指定較低的值。 + +有關在低記憶體系統上執行的其他資訊可以在這裡找到： +[reducing-bitcoind-memory-usage.md](https://gist.github.com/laanwj/efe29c7661ce9b6620a7)。 + +0.14.1 變更日誌 +================= + +### RPC 和其他 API +- #10084 `142fbb2` Rename first named arg of createrawtransaction (MarcoFalke) +- #10139 `f15268d` Remove auth cookie on shutdown (practicalswift) +- #10146 `2fea10a` Better error handling for submitblock (rawodb, gmaxwell) +- #10144 `d947afc` Prioritisetransaction wasn't always updating ancestor fee (sdaftuar) +- #10204 `3c79602` Rename disconnectnode argument (jnewbery) + +### 區塊和交易處理 +- #10126 `0b5e162` Compensate for memory peak at flush time (sipa) +- #9912 `fc3d7db` Optimize GetWitnessHash() for non-segwit transactions (sdaftuar) +- #10133 `ab864d3` Clean up calculations of pcoinsTip memory usage (morcos) + +### P2P 協定和網路程式碼 +- #9953,#10013 `d2548a4` Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt) +- #10176 `30fa231` net: gracefully handle NodeId wrapping (theuni) + +### 建置系統 +- #9973 `e9611d1` depends: fix zlib build on osx (theuni) + +### GUI +- #10060 `ddc2dd1` Ensure an item exists on the rpcconsole stack before adding (achow101) + +### 挖礦 +- #9955,#10006 `569596c` Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar) +- #9959,#10127 `b5c3440` Prevent slowdown in CreateNewBlock on large mempools (sdaftuar) + +### 測試和 QA +- #10157 `55f641c` Fix the `mempool_packages.py` test (sdaftuar) + +### 雜項 +- #10037 `4d8e660` Trivial: Fix typo in help getrawtransaction RPC (keystrike) +- #10120 `e4c9a90` util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj) +- #10130 `ecc5232` bitcoin-tx input verification (awemany, jnewbery) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Alex Morcos +- Andrew Chow +- Awemany +- Cory Fields +- Gregory Maxwell +- James Evans +- John Newbery +- MarcoFalke +- Matt Corallo +- Pieter Wuille +- practicalswift +- rawodb +- Suhas Daftuar +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-06-17-release-0.14.2.md b/_posts/zh_TW/releases/2017-06-17-release-0.14.2.md new file mode 100644 index 000000000..1d8db44e1 --- /dev/null +++ b/_posts/zh_TW/releases/2017-06-17-release-0.14.2.md @@ -0,0 +1,97 @@ +--- +title: Bitcoin Core 0.14.2 +id: zh_tw-release-0.14.2 +name: release-0.14.2 +permalink: /zh_TW/releases/0.14.2/ +excerpt: Bitcoin Core 0.14.2 版本現已發布 +date: 2017-06-17 +type: releases +layout: page +lang: zh_TW + +release: [0, 14, 2, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} + +Bitcoin Core 0.14.2 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。 + +Microsoft 已於 [2014 年 4 月 8 日](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support)終止對 Windows XP 的支援，我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但請注意存在已知的不穩定性和問題。請不要向問題追蹤器回報關於 Windows XP 的問題。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +miniupnp CVE-2017-8798 +---------------------------- + +綁定的 miniupnpc 已更新至 2.0.20170509。這修正了一個整數符號錯誤（存在於 MiniUPnPc v1.4.20101221 到 v2.0 中），允許遠端攻擊者（在 LAN 內）造成拒絕服務或可能產生其他未指定的影響。 + +這只影響透過 GUI 設定或透過 `-upnp` 選項明確啟用 UPnP 的使用者，因為自上次 UPnP 漏洞（在 Bitcoin Core 0.10.3 中）以來，它已預設停用。 + +如果您使用此選項，建議盡快升級到此版本。 + +已知錯誤 +========== + +自 0.14.0 以來，使用幣控制和智慧費用估算時，Bitcoin-Qt 顯示的大約交易費用不會反映智慧費用滑桿的目標變化。它只會使用預設目標顯示大約費用。使用正確目標計算的費用仍會應用於交易並顯示在最終發送確認對話框中。 + +0.14.2 變更日誌 +================= + +### RPC 和其他 API +- #10410 `321419b` Fix importwallet edge case rescan bug (ryanofsky) + +### P2P 協定和網路程式碼 +- #10424 `37a8fc5` Populate services in GetLocalAddress (morcos) +- #10441 `9e3ad50` Only enforce expected services for half of outgoing connections (theuni) + +### 建置系統 +- #10414 `ffb0c4b` miniupnpc 2.0.20170509 (fanquake) +- #10228 `ae479bc` Regenerate bitcoin-config.h as necessary (theuni) + +### 雜項 +- #10245 `44a17f2` Minor fix in build documentation for FreeBSD 11 (shigeya) +- #10215 `0aee4a1` Check interruptNet during dnsseed lookups (TheBlueMatt) + +### GUI +- #10231 `1e936d7` Reduce a significant cs_main lock freeze (jonasschnelli) + +### 錢包 +- #10294 `1847642` Unset change position when there is no change (instagibbs) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Alex Morcos +- Cory Fields +- fanquake +- Gregory Sanders +- Jonas Schnelli +- Matt Corallo +- Russell Yanofsky +- Shigeya Suzuki +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-09-14-release-0.15.0.md b/_posts/zh_TW/releases/2017-09-14-release-0.15.0.md new file mode 100644 index 000000000..c46bd84f5 --- /dev/null +++ b/_posts/zh_TW/releases/2017-09-14-release-0.15.0.md @@ -0,0 +1,167 @@ +--- +title: Bitcoin Core 0.15.0 +id: zh_tw-release-0.15.0 +name: release-0.15.0 +permalink: /zh_TW/releases/0.15.0/ +excerpt: Bitcoin Core 0.15.0 版本現已發布 +date: 2017-09-14 +type: releases +layout: page +lang: zh_TW + +release: [0, 15, 0, 0] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.15.0 版本現已發布，可從以下位置下載： + + + +此主要版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +`fee_estimates.dat` 的檔案格式在版本 0.15.0 中已變更。因此，從版本 0.15.0 降級或升級到版本 0.15.0 將導致所有費用估算被丟棄。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +此版本的 chainstate 資料庫與先前版本不相容，因此如果您執行 0.15 然後決定切換回任何較舊版本，您將需要使用 `-reindex-chainstate` 選項執行舊版本，以舊格式重建 chainstate 資料結構。 + +如果您的節點已啟用修剪，這將需要重新下載和處理整個區塊鏈。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +0.15.0 注意事項 +================ + +當前 SegWit 支援 +---------------------- + +版本 0.15.0 支援透過 `addwitnessaddress` RPC 添加隔離見證地址，但請注意這是一個測試/專家 RPC，不保證從備份中恢復。只有在您知道自己在做什麼時才使用此 RPC。更完整的隔離見證錢包支援將在下一個版本中提供。 + +使用加密錢包重新掃描 +--------------------------------- + +與以前的版本一樣，當使用加密的 HD 錢包時，不解鎖錢包就無法補充 keypool。這意味著目前，為了從加密 HD 錢包的備份中恢復，使用者必須使用很長的逾時解鎖錢包並手動觸發重新掃描，否則當自動補充無法執行時，他們可能會遺漏一些金鑰。不幸的是，此版本中沒有 `rescan` RPC，這將包含在未來版本中，因此目前可以使用其中一個 `import*` 命令，使用由另一個（受信任的）錢包生成的虛擬地址來觸發重新掃描。 + +重要變更 +=============== + +效能改進 +------------------------ + +版本 0.15 包含許多重大的效能改進，使初始區塊下載、啟動、交易和區塊驗證更快： + +- **chainstate 資料庫從按交易模型變更為按輸出模型**。驗證區塊鏈現在快 30-40%，使用記憶體減少 10-20%，磁碟寫入頻率大幅降低。磁碟資料庫大 15%。 + +- **改進快取使用**。整個可用快取（見 `-dbcache`）現在實際用作快取，使寫入頻率減少 2 倍或更多。 + +- **快取完整腳本執行結果**。如果區塊中的交易已被 mempool 接受，scriptSig 不需要重新評估。這使新區塊驗證快 40-50%。 + +- **LevelDB 升級到 1.20 版本**。包含支援 SSE 4.2 的架構的 CRC 硬體加速。 + +- **SHA256 雜湊最佳化**。支援的硬體上 SHA256 快約 50%，IBD 和區塊驗證快約 5%。在版本 0.15 中，SHA256 硬體最佳化在發布版本中預設停用，但可以在建置時使用 `--enable-experimental-asm` 啟用。 + +- **改進 keypool 重填**。建立新錢包的速度提高約 20 倍。預設 keypool 增加到 1000 個金鑰以使恢復更穩健。 + +費用估算改進 +--------------------------- + +版本 0.15 中的費用估算已得到顯著改進，錢包使用更準確的費用估算，`estimatesmartfee` 和 `estimaterawfee` RPC 的進階使用者有更廣泛的選項。 + +- 內部追蹤 3 個不同的時間範圍。 +- 估算可以是*保守的*或*經濟的*。保守估算使用更長的時間範圍。經濟估算使用較短的時間範圍。 +- 預設情況下，錢包將使用保守的費用估算。對於標記為可替換的交易，錢包預設使用經濟估算。 +- 現在可以為最多 1008 個區塊（一週）的確認目標進行估算。 +- `estimatefee` RPC 現已棄用，支援使用 `estimatesmartfee`。 + +多錢包支援 {#multi-wallet-support} +-------------------- + +Bitcoin Core 現在支援載入多個獨立的錢包。錢包完全分離，具有獨立的餘額、金鑰和收到的交易。 + +透過在啟動 Bitcoin 時使用多個 `-wallet` 參數（在命令列或 Bitcoin 設定檔中）來啟用多錢包。 + +**在 Bitcoin-Qt 中，只有第一個錢包將被顯示並可供建立和簽署交易。** 未來版本將支援 GUI 可選擇的多個錢包。 + +在多錢包模式下執行時的 RPC 使用： +* 當執行單個錢包時，RPC 介面或 `bitcoin-cli` **沒有**變更。 +* 執行多錢包時，*節點級* RPC 方法繼續如前工作。 +* 執行多錢包時，*錢包級* RPC 方法必須在每個請求中指定目標錢包。HTTP RPC 請求應發送到 `:/wallet/` 端點。`bitcoin-cli` 命令應使用 `-rpcwallet` 選項執行。 +* 添加了新的*節點級* `listwallets` RPC 方法以顯示當前載入的錢包。 + +GUI 中的 Replace-by-fee 控制 +--------------------------------- + +在版本 0.15 中，GUI 支援建立選擇加入的 RBF 交易以及用更高費用的交易替換未確認的交易。 + +移除幣齡優先級 +---------------------------- + +Bitcoin Core 0.15 移除了對幣齡優先級的所有剩餘支援。這有以下影響： + +- *免費交易*的概念已被移除。`-limitfreerelay` 和 `-relaypriority` 選項已被移除。 +- `-sendfreetransactions` 選項已被移除。 +- `-blockprioritysize` 選項已被移除。 +- `estimatepriority` 和 `estimatesmartpriority` RPC 已被移除。 +- `prioritisetransaction` RPC 不再接受 `priority_delta` 參數。 +- `-minrelaytxfee` 現在可以設定為 0。 + +跨重啟的 Mempool 持久性 +----------------------------------- + +版本 0.15 允許使用 `-persistmempool` 命令列選項開啟或關閉此功能。預設情況下，選項設定為 true，mempool 在關閉時儲存並在啟動時重新載入。如果設定為 false，`mempool.dat` 檔案將不會在啟動時載入或在關閉時儲存。 + +新的 RPC 方法 +--------------- + +- `abortrescan` 停止當前錢包重新掃描。 +- `combinerawtransaction` 接受原始交易的 JSON 陣列並將它們組合成單個原始交易。 +- `estimaterawfee` 返回原始費用資料以便實作自訂邏輯。 +- `getchaintxstats` 返回有關鏈中交易總數和速率的統計資訊。 +- `listwallets` 列出當前載入的錢包。 +- `uptime` 返回自上次啟動以來 `bitcoind` 伺服器的總執行時間。 + +低階 RPC 變更 +--------------------- + +- `gettxout` RPC 在回應中不再有 `version` 欄位。 +- `gettxoutsetinfo` RPC 報告 `hash_serialized_2` 而不是 `hash_serialized`。 +- `estimatefee` RPC 已棄用。客戶端應切換到使用 `estimatesmartfee` RPC。 +- `listunspent` RPC 現在接受 `query_options` 參數，該參數是包含 `minimumAmount`、`maximumAmount`、`maximumCount`、`minimumSumAmount` 成員的 JSON 物件。 +- `dumpwallet` RPC 現在返回轉儲錢包的完整絕對路徑。 +- `getblock` 的 `verbose` 參數已重新命名為 `verbosity` 並現在接受從 0 到 2 的整數。 + +0.15.0 變更日誌 +================= + +完整的變更日誌包含超過 500 個 PR，涵蓋 RPC 和其他 API、區塊和交易處理、P2P 協定和網路程式碼、驗證、建置系統、GUI、錢包、測試和 QA 等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 120 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-09-19-release-0.15.0.1.md b/_posts/zh_TW/releases/2017-09-19-release-0.15.0.1.md new file mode 100644 index 000000000..d15e5c6a5 --- /dev/null +++ b/_posts/zh_TW/releases/2017-09-19-release-0.15.0.1.md @@ -0,0 +1,83 @@ +--- +title: Bitcoin Core 0.15.0.1 +id: zh_tw-release-0.15.0.1 +name: release-0.15.0.1 +permalink: /zh_TW/releases/0.15.0.1/ +excerpt: Bitcoin Core 0.15.0.1 版本現已發布 +date: 2017-09-19 +type: releases +layout: page +lang: zh_TW + +release: [0, 15, 0, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:42c959e5077dade60bb88f19fcb994cb597c2ec8&dn=bitcoin-core-0.15.0.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.15.0.1 版本現已發布，可從以下位置下載： + + + +這是 0.15.0 的小錯誤修正版本。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更高版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +`fee_estimates.dat` 的檔案格式在版本 0.15.0 中已變更。因此，從版本 0.15.0 降級或升級到版本 0.15.0 將導致所有費用估算被丟棄。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +此版本的 chainstate 資料庫與先前版本不相容，因此如果您執行 0.15 然後決定切換回任何較舊版本，您將需要使用 `-reindex-chainstate` 選項執行舊版本，以舊格式重建 chainstate 資料結構。 + +如果您的節點已啟用修剪，這將需要重新下載和處理整個區塊鏈。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +GUI 啟動崩潰問題 +------------------------- + +升級到 0.15.0 後，某些客戶端會在啟動時崩潰，因為設定了 GUI 中不再存在的自訂費用設定。這是避免此問題發生的最小修補程式。 + +0.15.0.1 變更日誌 +==================== + +- #11332 `46c8d23` Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) + +此外，手冊頁也已更新，因為 0.15.0 版本忘記更新。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- Matt Corallo +- Jonas Schnelli +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2017-11-11-release-0.15.1.md b/_posts/zh_TW/releases/2017-11-11-release-0.15.1.md new file mode 100644 index 000000000..fb00b2040 --- /dev/null +++ b/_posts/zh_TW/releases/2017-11-11-release-0.15.1.md @@ -0,0 +1,236 @@ +--- +title: Bitcoin Core 0.15.1 +id: zh_tw-release-0.15.1 +name: release-0.15.1 +permalink: /zh_TW/releases/0.15.1/ +excerpt: Bitcoin Core 0.15.1 版本現已發布 +date: 2017-11-11 +type: releases +layout: page +lang: zh_TW + +release: [0, 15, 1] +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.15.1 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更高版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +`fee_estimates.dat` 的檔案格式在版本 0.15.0 中已變更。因此，從版本 0.15 降級或升級到版本 0.15 將導致所有費用估算被丟棄。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +此版本的 chainstate 資料庫與先前版本不相容，因此如果您執行 0.15 然後決定切換回任何較舊版本，您將需要使用 `-reindex-chainstate` 選項執行舊版本，以舊格式重建 chainstate 資料結構。 + +如果您的節點已啟用修剪，這將需要重新下載和處理整個區塊鏈。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +網路分叉安全性增強 +-------------------------------- + +對 Bitcoin Core 處理對等連線和無效區塊的方式進行了一些變更，作為防止區塊鏈分叉和行為不當對等節點的安全預防措施。 + +- 工作量少於 minimum-chain-work 的未請求區塊現在即使具有比提示更多的工作量也不再被處理（這是 IBD 期間的潛在問題，其中提示可能具有低工作量）。這可以防止對等節點浪費節點的資源。 + +- 在 IBD 期間提供工作量少於 minimum-chain-work 的鏈的對等節點現在將被斷開連線。 + +- 對於給定的出站對等節點，我們現在檢查其最佳已知區塊是否至少與我們的提示具有同樣多的工作量。如果沒有，並且如果在 20 分鐘逾時後我們仍然沒有聽到具有足夠工作量的區塊，那麼我們發送單個 getheaders 訊息，並再等待 2 分鐘。如果在兩分鐘後其最佳已知區塊的工作量不足，我們將斷開該對等節點。我們保護 4 個出站對等節點不被此邏輯斷開連線，以防止由於此演算法而導致過多的網路拓撲變更，同時仍確保我們有合理數量的節點不在虛假鏈上。 + +- 向我們提供已知無效的區塊標頭的出站（非手動）對等節點（緊湊區塊公告除外，因為 BIP 152 明確允許節點在完全驗證之前中繼緊湊區塊）現在將被斷開連線。 + +- 如果鏈提示超過 30 分鐘沒有前進，我們現在假設提示可能已過時，並將嘗試連線到額外的出站對等節點。定期檢查確保如果正在使用此額外的對等連線，我們將斷開最近未公告新區塊的對等節點。 + +- 現在追蹤所有已知本身無效的區塊集合（即我們嘗試連線但發現無效的區塊），並用於檢查新標頭是否基於無效鏈建置。這確保了從無效區塊繼承的所有內容都被標記為無效。 + +礦工區塊大小限制已棄用 +------------------------------------ + +儘管自 0.13.0 以來，blockmaxweight 一直是限制 getblocktemplate 返回的區塊大小的首選方法，但 blockmaxsize 仍作為那些希望直接限制其區塊大小的人的選項保留。使用此選項導致了一些 UI 問題以及非最佳的費用選擇和略微較差的效能，因此現已被棄用。此外，blockmaxsize 選項現在僅用於計算隱含的 blockmaxweight，而不是直接限制區塊大小。任何希望按大小而不是按權重限制其區塊的礦工都必須透過直接從其區塊模板中刪除交易來手動執行此操作。 + +重設時備份 GUI 設定 +------------------------------- + +當使用 `-resetguisettings` 參數時，GUI 設定現在將在清除之前寫入資料目錄中的 `guisettings.ini.bak`。這可用於追溯解決由於 GUI 設定引起的問題。 + +不允許重複錢包 +---------------------------- + +以前，可以透過手動複製錢包檔案來兩次開啟同一個錢包，當兩者同時開啟時會導致問題。現在不再可能開啟同一錢包的副本。 + +添加除錯 `-minimumchainwork` 參數 +---------------------------------------- + +已添加隱藏的除錯參數 `-minimumchainwork`，以允許在驗證鏈時使用自訂的最小工作量值。 + +低階 RPC 變更 +---------------------- + +- getmininginfo 中的「currentblocksize」值已被移除。 + +- `dumpwallet` 不再允許覆蓋檔案。這是一項安全措施，也可以防止危險的使用者錯誤。 + +- `backupwallet` 現在在嘗試備份到源檔案時將失敗，而不是破壞錢包。 + +- 如果傳遞了未知的 `blockhash` 參數值，`listsinceblock` 現在將拋出錯誤，而不是返回自創世區塊以來所有錢包交易的清單。當提供空字串時，行為不變。 + +0.15.1 變更日誌 +================= + +### 挖礦 +- #11100 `7871a7d` Fix confusing blockmax{size,weight} options, dont default to throwing away money (TheBlueMatt) + +### RPC 和其他 API +- #10859 `2a5d099` gettxout: Slightly improve doc and tests (jtimon) +- #11267 `b1a6c94` update cli for estimate\*fee argument rename (laanwj) +- #11483 `20cdc2b` Fix importmulti bug when importing an already imported key (pedrobranco) +- #9937 `a43be5b` Prevent `dumpwallet` from overwriting files (laanwj) +- #11465 `405e069` Update named args documentation for importprivkey (dusty-wil) +- #11131 `b278a43` Write authcookie atomically (laanwj) +- #11565 `7d4546f` Make listsinceblock refuse unknown block hash (ryanofsky) +- #11593 `8195cb0` Work-around an upstream libevent bug (theuni) + +### P2P 協定和網路程式碼 +- #11397 `27e861a` Improve and document SOCKS code (laanwj) +- #11252 `0fe2a9a` When clearing addrman clear mapInfo and mapAddr (instagibbs) +- #11527 `a2bd86a` Remove my testnet DNS seed (schildbach) +- #10756 `0a5477c` net processing: swap out signals for an interface class (theuni) +- #11531 `55b7abf` Check that new headers are not a descendant of an invalid block (more effeciently) (TheBlueMatt) +- #11560 `49bf090` Connect to a new outbound peer if our tip is stale (sdaftuar) +- #11568 `fc966bb` Disconnect outbound peers on invalid chains (sdaftuar) +- #11578 `ec8dedf` Add missing lock in ProcessHeadersMessage(...) (practicalswift) +- #11456 `6f27965` Replace relevant services logic with a function suite (TheBlueMatt) +- #11490 `bf191a7` Disconnect from outbound peers with bad headers chains (sdaftuar) + +### 驗證 +- #10357 `da4908c` Allow setting nMinimumChainWork on command line (sdaftuar) +- #11458 `2df65ee` Don't process unrequested, low-work blocks (sdaftuar) + +### 建置系統 +- #11440 `b6c0209` Fix validationinterface build on super old boost/clang (TheBlueMatt) +- #11530 `265bb21` Add share/rpcuser to dist. source code archive (MarcoFalke) + +### GUI +- #11334 `19d63e8` Remove custom fee radio group and remove nCustomFeeRadio setting (achow101) +- #11198 `7310f1f` Fix display of package name on 'open config file' tooltip (esotericnonsense) +- #11015 `6642558` Add delay before filtering transactions (lclc) +- #11338 `6a62c74` Backup former GUI settings on `-resetguisettings` (laanwj) +- #11335 `8d13b42` Replace save|restoreWindowGeometry with Qt functions (MeshCollider) +- #11237 `2e31b1d` Fixing division by zero in time remaining (MeshCollider) +- #11247 `47c02a8` Use IsMine to validate custom change address (MarcoFalke) + +### 錢包 +- #11017 `9e8aae3` Close DB on error (kallewoof) +- #11225 `6b4d9f2` Update stored witness in AddToWallet (sdaftuar) +- #11126 `2cb720a` Acquire cs_main lock before cs_wallet during wallet initialization (ryanofsky) +- #11476 `9c8006d` Avoid opening copied wallet databases simultaneously (ryanofsky) +- #11492 `de7053f` Fix leak in CDB constructor (promag) +- #11376 `fd79ed6` Ensure backupwallet fails when attempting to backup to source file (tomasvdw) +- #11326 `d570aa4` Fix crash on shutdown with invalid wallet (MeshCollider) + +### 測試和 QA +- #11399 `a825d4a` Fix bip68-sequence rpc test (jl2012) +- #11150 `847c75e` Add getmininginfo test (mess110) +- #11407 `806c78f` add functional test for mempoolreplacement command line arg (instagibbs) +- #11433 `e169349` Restore bitcoin-util-test py2 compatibility (MarcoFalke) +- #11308 `2e1ac70` zapwallettxes: Wait up to 3s for mempool reload (MarcoFalke) +- #10798 `716066d` test bitcoin-cli (jnewbery) +- #11443 `019c492` Allow "make cov" out-of-tree; Fix rpc mapping check (MarcoFalke) +- #11445 `51bad91` 0.15.1 Backports (MarcoFalke) +- #11319 `2f0b30a` Fix error introduced into p2p-segwit.py, and prevent future similar errors (sdaftuar) +- #10552 `e4605d9` Tests for zmqpubrawtx and zmqpubrawblock (achow101) +- #11067 `eeb24a3` TestNode: Add wait_until_stopped helper method (MarcoFalke) +- #11068 `5398f20` Move wait_until to util (MarcoFalke) +- #11125 `812c870` Add bitcoin-cli -stdin and -stdinrpcpass functional tests (promag) +- #11077 `1d80d1e` fix timeout issues from TestNode (jnewbery) +- #11078 `f1ced0d` Make p2p-leaktests.py more robust (jnewbery) +- #11210 `f3f7891` Stop test_bitcoin-qt touching ~/.bitcoin (MeshCollider) +- #11234 `f0b6795` Remove redundant testutil.cpp|h files (MeshCollider) +- #11215 `cef0319` fixups from set_test_params() (jnewbery) +- #11345 `f9cf7b5` Check connectivity before sending in assumevalid.py (jnewbery) +- #11091 `c276c1e` Increase initial RPC timeout to 60 seconds (laanwj) +- #10711 `fc2aa09` Introduce TestNode (jnewbery) +- #11230 `d8dd8e7` Fixup dbcrash interaction with add_nodes() (jnewbery) +- #11241 `4424176` Improve signmessages functional test (mess110) +- #11116 `2c4ff35` Unit tests for script/standard and IsMine functions (jimpo) +- #11422 `a36f332` Verify DBWrapper iterators are taking snapshots (TheBlueMatt) +- #11121 `bb5e7cb` TestNode tidyups (jnewbery) +- #11521 `ca0f3f7` travis: move back to the minimal image (theuni) +- #11538 `adbc9d1` Fix race condition failures in replace-by-fee.py, sendheaders.py (sdaftuar) +- #11472 `4108879` Make tmpdir option an absolute path, misc cleanup (MarcoFalke) +- #10853 `5b728c8` Fix RPC failure testing (again) (jnewbery) +- #11310 `b6468d3` Test listwallets RPC (mess110) + +### Miscellaneous +- #11377 `75997c3` Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds (TheBlueMatt) +- #11437 `dea3b87` [Docs] Update Windows build instructions for using WSL and Ubuntu 17.04 (fanquake) +- #11318 `8b61aee` Put back inadvertently removed copyright notices (gmaxwell) +- #11442 `cf18f42` [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2 (fanquake) +- #10957 `50bd3f6` Avoid returning a BIP9Stats object with uninitialized values (practicalswift) +- #11539 `01223a0` [verify-commits] Allow revoked keys to expire (TheBlueMatt) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andreas Schildbach +- Andrew Chow +- Chris Moore +- Cory Fields +- Cristian Mircea Messel +- Daniel Edgecumbe +- Donal OConnor +- Dusty Williams +- fanquake +- Gregory Sanders +- Jim Posen +- John Newbery +- Johnson Lau +- João Barbosa +- Jorge Timón +- Karl-Johan Alm +- Lucas Betschart +- MarcoFalke +- Matt Corallo +- Paul Berg +- Pedro Branco +- Pieter Wuille +- practicalswift +- Russell Yanofsky +- Samuel Dobson +- Suhas Daftuar +- Tomas van der Wansem +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-02-26-release-0.16.0.md b/_posts/zh_TW/releases/2018-02-26-release-0.16.0.md new file mode 100644 index 000000000..8da0976fc --- /dev/null +++ b/_posts/zh_TW/releases/2018-02-26-release-0.16.0.md @@ -0,0 +1,193 @@ +--- +title: Bitcoin Core 0.16.0 +id: zh_tw-release-0.16.0 +name: release-0.16.0 +permalink: /zh_TW/releases/0.16.0/ +excerpt: Bitcoin Core 0.16.0 版本現已發布 +date: 2018-02-26 +type: releases +layout: page +lang: zh_TW + +release: [0, 16, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:6493ae7a15b4d32bb4eca1dfaf6dcc0c143492cb&dn=bitcoin-core-0.16.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.16.0 版本現已發布，可從以下位置下載： + + + +此主要版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 或更高版本沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +在 0.16 及更高版本中建立的錢包與 0.16 之前的版本不相容，如果您嘗試在舊版本中使用新建立的錢包，它們將無法運作。使用舊版本建立的現有錢包不受此影響。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +錢包變更 +--------------- + +### SegWit 錢包 + +Bitcoin Core 0.16.0 引入了錢包和使用者介面對 segwit 的完整支援。已添加新的 `-addresstype` 參數，支援 `legacy`、`p2sh-segwit`（預設）和 `bech32` 地址。它控制 `getnewaddress`、`getaccountaddress` 和 `createmultisigaddress` 產生的地址類型。還添加了 `-changetype` 參數，具有相同選項，預設等於 `-addresstype`，以控制使用哪種找零類型。 + +已為 `getnewaddress` 和 `addmultisigaddress` RPC 添加新的 `address_type` 參數，以指定要生成哪種類型的地址。已為 `fundrawtransaction` RPC 添加 `change_type` 參數，以覆蓋特定交易的 `-changetype` 參數。 + +- 透過 `getnewaddress` 或 `*multisig` RPC 建立的所有 segwit 地址都會明確將其 redeemscript 添加到錢包檔案。這意味著在建立 segwit 地址後降級將可以運作，只要錢包檔案是最新的。 +- 錢包中的所有 segwit 金鑰都會添加隱式 redeemscript，而不會將其寫入檔案。這意味著只要您使用新軟體，舊備份的恢復將可以運作。 +- 在交易中看到已使用的所有 keypool 金鑰都會明確將其 redeemscript 添加到錢包檔案。這意味著在從包含 segwit 地址的備份恢復後降級將可以運作。 + +請注意，某些 RPC 尚不支援 segwit 地址。特別是，`signmessage`/`verifymessage` 不支援 segwit 地址，此時 `importmulti` 也不支援。將在未來版本中繼續添加對這些 RPC 中 segwit 的支援。 + +如果交易中的任何目的地是 P2WPKH 或 P2WSH 輸出，現在預設使用 P2WPKH 找零輸出。這樣做是為了確保在任何一種情況下找零輸出都盡可能與其他輸出無法區分。 + +### BIP173 (Bech32) 地址支援（"bc1..." 地址） + +現已添加對原生 segwit 地址（BIP173 / Bech32）的完整支援。這包括發送到 BIP173 地址（包括非 v0 地址）的能力，以及生成這些地址（包括作為預設新地址，見上文）。 + +已在 GUI 中添加複選框，以選擇在使用 segwit 地址時應生成 Bech32 地址還是 P2SH 包裝的地址。當使用 `-addresstype=bech32` 啟動時，預設會勾選。當使用 `-addresstype=legacy` 啟動時，它會取消勾選並停用。 + +### 預設 HD 錢包 + +由於錢包資料庫中的向後不相容變更，使用版本 0.16.0 建立的錢包將被先前版本拒絕。此外，版本 0.16.0 將僅建立分層確定性 (HD) 錢包。請注意，這僅適用於新錢包；使用先前版本製作的錢包不會升級為 HD。 + +### GUI 中預設 Replace-By-Fee + +發送螢幕現在預設使用 BIP125 RBF，無論 `-walletrbf` 如何。有一個複選框可將交易標記為最終。 + +RPC 預設值保持不變：要使用 RBF，請使用 `-walletrbf=1` 啟動或為個別交易使用 `replaceable` 參數。 + +### 錢包目錄設定（`-walletdir`） + +Bitcoin Core 現在在錢包目錄的位置上具有更大的靈活性。以前，錢包資料庫檔案儲存在比特幣資料目錄的頂層。現在的行為是： + +- 對於新安裝（資料目錄尚不存在），錢包現在將預設儲存在資料目錄內的新 `wallets/` 子目錄中。 +- 對於現有節點（資料目錄已存在），錢包將預設儲存在資料目錄根目錄中。如果資料目錄根目錄中已存在 `wallets/` 子目錄，則錢包將預設儲存在 `wallets/` 子目錄中。 +- 可以透過指定 `-walletdir=` 選項來覆蓋錢包目錄的位置，其中 `` 可以是目錄或目錄符號連結的絕對路徑。 + +在選擇錢包目錄位置時應小心，因為如果在操作期間變得不可用，資金可能會丟失。 + +建置：最低 GCC 提升到 4.8.x +------------------------------------ + +編譯 Bitcoin Core 所需的 GCC 編譯器的最低版本現在是 4.8。不會努力支援較舊版本的 GCC。Clang 編譯器的最低版本仍然是 3.3。其他最低依賴版本可以在儲存庫中的 `doc/dependencies.md` 中找到。 + +支援訊號修剪節點（BIP159） +--------------------------------------------- + +修剪節點現在可以使用服務位訊號 BIP159 的 NODE_NETWORK_LIMITED，為以後版本中的完整 BIP159 支援做準備。這將允許修剪節點提供最新的區塊。但是，當前變更尚未包括連線到這些修剪對等節點的支援。 + +效能：預設啟用 SHA256 組合語言 +------------------------------------------------- + +支援 SSE4 的架構的 SHA256 雜湊最佳化（在支援的硬體上導致約 50% 的 SHA256 加速，約 5% 的更快同步和區塊驗證）現在預設啟用。在以前的版本中，它們在建置時使用 `--enable-experimental-asm` 標誌啟用，但現在是預設的，不再被視為實驗性。 + +GUI 變更 +----------- + +- GUI 中使用的「µBTC」現在也顯示更通俗的術語「bits」，在 BIP176 中指定。 +- 重複使用先前地址的選項現已被移除。這曾被「重新發送」發票的需求所證明，但現在我們有了請求歷史記錄，該需求應該消失了。 +- 已添加按 TXID 搜尋的支援，而不僅僅是地址和標籤。 +- 已在發送幣對話方塊中添加「使用可用餘額」選項，以將剩餘的可用錢包餘額添加到交易輸出。 +- 已在密碼對話方塊上添加用於取消隱藏密碼欄位的切換。 + +RPC 變更 +------------ + +### 新的 `rescanblockchain` RPC + +已添加新的 RPC `rescanblockchain` 以手動呼叫區塊鏈重新掃描。該 RPC 支援重新掃描的開始和結束高度參數，並且可以在多錢包環境中使用以在執行時重新掃描區塊鏈。 + +### 新的 `savemempool` RPC + +已添加新的 `savemempool` RPC，允許隨時將當前 mempool 儲存到磁碟，以避免由於崩潰/斷電而丟失。 + +### 預設停用安全模式 + +安全模式現在預設停用，如果您希望使用它，必須手動啟用（使用 `-disablesafemode=0`）。安全模式是一項功能，如果偵測到網路的某些問題條件，會自動停用 RPC 呼叫的子集（主要與錢包和發送相關）。然而，開發人員已經認為這些檢查不夠可靠，無法自動採取行動。即使停用了安全模式，它們仍會在 `getneworkinfo` RPC 的 `warnings` 欄位中引起警告並啟動 `-alertnotify` 命令。 + +### 重新命名用於建立 JSON-RPC 憑證的腳本 + +`share/rpcuser/rpcuser.py` 腳本已重新命名為 `share/rpcauth/rpcauth.py`。此腳本可用於為 JSON-RPC 使用者建立 `rpcauth` 憑證。 + +### Validateaddress 改進 + +`validateaddress` RPC 輸出已擴展了一些新欄位，並支援 segwit 地址（P2SH 和 Bech32）。具體來說： + +* 新欄位 `iswitness` 對於 P2WPKH 和 P2WSH 地址（"bc1..." 地址）為 True，但對於 P2SH 包裝的 segwit 地址不為 True（見下文）。 +* 現有欄位 `isscript` 現在也會對 P2WSH 地址報告 True。 +* 新欄位 `embedded` 存在於所有已知腳本且匹配可以解釋為已知地址的腳本的腳本地址中。對於 P2SH-P2WPKH 和 P2SH-P2WSH 地址尤其如此。`embedded` 的值包括如果直接在嵌入地址上呼叫 `validateaddress` 將報告的大部分資訊。 +* 對於 multisig 腳本，已添加新的 `pubkeys` 欄位，報告腳本中涉及的完整公鑰（如果已知）。這是現有 `addresses` 欄位（報告相同資訊但編碼為 P2PKH 地址）的替代品，以更有用和更少混淆的方式表示。對於非 segwit 地址，`addresses` 欄位仍然存在以實現向後相容性。 +* 對於所有具有已知金鑰的單金鑰地址（即使包裝在 P2SH 或 P2WSH 中），`pubkey` 欄位將存在。特別是，這意味著在 `getnewaddress` 的輸出上呼叫 `validateaddress` 將始終報告 `pubkey`，即使地址類型是 P2SH-P2WPKH。 + +### 低階變更 + +- 已移除已棄用的 RPC `getinfo`。建議使用更具體的 RPC：`getblockchaininfo`、`getnetworkinfo`、`getwalletinfo`、`getmininginfo`。 +- 如果使用錢包中不存在的地址呼叫，錢包 RPC `getreceivedbyaddress` 將返回錯誤。 +- 錢包 RPC `addwitnessaddress` 已棄用，將在版本 0.17 中移除，請改為設定 `getnewaddress` 的 `address_type` 參數，或選項 `-addresstype=[bech32|p2sh-segwit]`。 +- `dumpwallet` 現在在轉儲檔案中包含錢包中的十六進位編碼腳本，`importwallet` 現在導入這些腳本，但可能無法正確添加對應的地址，或者可能需要手動重新掃描以查找相關交易。 +- RPC `getblockchaininfo` 現在包含 `errors` 欄位。 +- 已為 `getrawtransaction` RPC 添加新的 `blockhash` 參數，允許從特定區塊（如果已知）獲取原始交易，即使未啟用 `-txindex`。 +- `decoderawtransaction` 和 `fundrawtransaction` RPC 現在具有可選的 `iswitness` 參數，以在必要時覆蓋啟發式見證檢查。 +- `walletpassphrase` 逾時現在被限制為 2^30 秒。 +- 現在不推薦使用 `createmultisig` RPC 使用地址，並將在以後的版本中移除。應改用公鑰。 +- 區塊鏈重新掃描現在不再在整個重新掃描過程中鎖定錢包，因此現在可以同時使用其他 RPC（儘管在重新掃描完成之前，餘額/交易的結果可能不正確或不完整）。 +- `logging` RPC 現在已公開而不是隱藏。 +- 已為 `getblockchaininfo` RPC 添加 `initialblockdownload` 布林值，以指示節點當前是否處於 IBD 中。 +- `minrelaytxfee` 現在包含在 `getmempoolinfo` 的輸出中。 + +其他變更的命令列選項 +---------------------------------- + +- `-debuglogfile=` 可用於指定替代除錯日誌檔案。 +- bitcoin-cli 現在有一個 `-stdinrpcpass` 選項，允許從標準輸入讀取 RPC 密碼。 +- `-usehd` 選項已被移除。 +- bitcoin-cli 現在支援新的 `-getinfo` 標誌，該標誌返回類似於現已移除的 `getinfo` RPC 的輸出。 + +測試變更 +---------------- + +- 預設 regtest JSON-RPC 連接埠已從 18443 更改為 18443，以避免與 testnet 的預設值 18332 衝突。 +- Segwit 現在在 regtest 模式下預設始終處於活動狀態。因此，如果您升級 regtest 節點，您將需要 -reindex 或透過將 `vbparams=segwit:0:999999999999` 添加到您的 regtest bitcoin.conf 來使用舊規則。如果不這樣做，將導致 CheckBlockIndex() 斷言失敗，看起來像：Assertion `(pindexFirstNeverProcessed != nullptr) == (pindex->nChainTx == 0)' failed。 + +0.16.0 變更日誌 +------------------ + +完整的變更日誌包含超過 400 個 PR，涵蓋區塊和交易處理、P2P 協定和網路程式碼、錢包、RPC 和其他 API、GUI、建置系統、測試和 QA、平台支援、文件、重構等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 140 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-06-15-release-0.16.1.md b/_posts/zh_TW/releases/2018-06-15-release-0.16.1.md new file mode 100644 index 000000000..9a90447e7 --- /dev/null +++ b/_posts/zh_TW/releases/2018-06-15-release-0.16.1.md @@ -0,0 +1,147 @@ +--- +title: Bitcoin Core 0.16.1 +id: zh_tw-release-0.16.1 +name: release-0.16.1 +permalink: /zh_TW/releases/0.16.1/ +excerpt: Bitcoin Core 0.16.1 版本現已發布 +date: 2018-06-15 +type: releases +layout: page +lang: zh_TW + +release: [0, 16, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:91069028aaf9f6bb3279e71bfd9ab164922e578e&dn=bitcoin-core-0.16.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.16.1 版本現已發布，可從以下位置下載： + + + +此小版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 或更高版本沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +在 0.16 及更高版本中建立的錢包與 0.16 之前的版本不相容，如果您嘗試在舊版本中使用新建立的錢包，它們將無法運作。使用舊版本建立的現有錢包不受此影響。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +礦工區塊大小已移除 +------------------------ + +在版本 0.15.1 中已被棄用的礦工限制其區塊大小的 `-blockmaxsize` 選項現已被移除。礦工如果想要限制其區塊的權重，應使用 `-blockmaxweight` 選項。 + +0.16.1 變更日誌 +------------------ + +### 策略 +- #11423 `d353dd1` [Policy] Several transaction standardness rules (jl2012) + +### 挖礦 +- #12756 `e802c22` [config] Remove blockmaxsize option (jnewbery) + +### 區塊和交易處理 +- #13199 `c71e535` Bugfix: ensure consistency of m_failed_blocks after reconsiderblock (sdaftuar) +- #13023 `bb79aaf` Fix some concurrency issues in ActivateBestChain() (skeees) + +### P2P 協定和網路程式碼 +- #12626 `f60e84d` Limit the number of IPs addrman learns from each DNS seeder (EthanHeilman) + +### 錢包 +- #13265 `5d8de76` Exit SyncMetaData if there are no transactions to sync (laanwj) +- #13030 `5ff571e` Fix zapwallettxes/multiwallet interaction. (jnewbery) + +### GUI +- #12999 `1720eb3` Show the Window when double clicking the taskbar icon (ken2812221) +- #12650 `f118a7a` Fix issue: "default port not shown correctly in settings dialog" (251Labs) +- #13251 `ea487f9` Rephrase Bech32 checkbox texts, and enable it with legacy address default (fanquake) + +### 建置系統 +- #12474 `b0f692f` Allow depends system to support armv7l (hkjn) +- #12585 `72a3290` depends: Switch to downloading expat from GitHub (fanquake) +- #12648 `46ca8f3` test: Update trusted git root (MarcoFalke) +- #11995 `686cb86` depends: Fix Qt build with Xcode 9 (fanquake) +- #12636 `845838c` backport: #11995 Fix Qt build with Xcode 9 (fanquake) +- #12946 `e055bc0` depends: Fix Qt build with XCode 9.3 (fanquake) +- #12998 `7847b92` Default to defining endian-conversion DECLs in compat w/o config (TheBlueMatt) + +### 測試和 QA +- #12447 `01f931b` Add missing signal.h header (laanwj) +- #12545 `1286f3e` Use wait_until to ensure ping goes out (Empact) +- #12804 `4bdb0ce` Fix intermittent rpc_net.py failure. (jnewbery) +- #12553 `0e98f96` Prefer wait_until over polling with time.sleep (Empact) +- #12486 `cfebd40` Round target fee to 8 decimals in assert_fee_amount (kallewoof) +- #12843 `df38b13` Test starting bitcoind with -h and -version (jnewbery) +- #12475 `41c29f6` Fix python TypeError in script.py (MarcoFalke) +- #12638 `0a76ed2` Cache only chain and wallet for regtest datadir (MarcoFalke) +- #12902 `7460945` Handle potential cookie race when starting node (sdaftuar) +- #12904 `6c26df0` Ensure bitcoind processes are cleaned up when tests end (sdaftuar) +- #13049 `9ea62a3` Backports (MarcoFalke) +- #13201 `b8aacd6` Handle disconnect_node race (sdaftuar) + +### Miscellaneous +- #12518 `a17fecf` Bump leveldb subtree (MarcoFalke) +- #12442 `f3b8d85` devtools: Exclude patches from lint-whitespace (MarcoFalke) +- #12988 `acdf433` Hold cs_main while calling UpdatedBlockTip() signal (skeees) +- #12985 `0684cf9` Windows: Avoid launching as admin when NSIS installer ends. (JeremyRand) + +### 文件 +- #12637 `60086dd` backport: #12556 fix version typo in getpeerinfo RPC call help (fanquake) +- #13184 `4087dd0` RPC Docs: `gettxout*`: clarify bestblock and unspent counts (harding) +- #13246 `6de7543` Bump to Ubuntu Bionic 18.04 in build-windows.md (ken2812221) +- #12556 `e730b82` Fix version typo in getpeerinfo RPC call help (tamasblummer) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 251 +- Ben Woosley +- Chun Kuan Lee +- David A. Harding +- e0 +- fanquake +- Henrik Jonsson +- JeremyRand +- Jesse Cohen +- John Newbery +- Johnson Lau +- Karl-Johan Alm +- Luke Dashjr +- MarcoFalke +- Matt Corallo +- Pieter Wuille +- Suhas Daftuar +- Tamas Blummer +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-07-29-release-0.16.2.md b/_posts/zh_TW/releases/2018-07-29-release-0.16.2.md new file mode 100644 index 000000000..a8187fd28 --- /dev/null +++ b/_posts/zh_TW/releases/2018-07-29-release-0.16.2.md @@ -0,0 +1,121 @@ +--- +title: Bitcoin Core 0.16.2 +id: zh_tw-release-0.16.2 +name: release-0.16.2 +permalink: /zh_TW/releases/0.16.2/ +excerpt: Bitcoin Core 0.16.2 版本現已發布 +date: 2018-07-29 +type: releases +layout: page +lang: zh_TW + +release: [0, 16, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:b64eacae7d6e5f7ba50de3da8aca4368c27f0823&dn=bitcoin-core-0.16.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.16.2 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 或更高版本沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +在 0.16 及更高版本中建立的錢包與 0.16 之前的版本不相容，如果您嘗試在舊版本中使用新建立的錢包，它們將無法運作。使用舊版本建立的現有錢包不受此影響。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +0.16.2 變更日誌 +------------------ + +### 錢包 +- #13622 `c04a4a5` Remove mapRequest tracking that just effects Qt display. (TheBlueMatt) +- #12905 `cfc6f74` [rpcwallet] Clamp walletpassphrase value at 100M seconds (sdaftuar) +- #13437 `ed82e71` wallet: Erase wtxOrderd wtx pointer on removeprunedfunds (MarcoFalke) + +### RPC 和其他 API +- #13451 `cbd2f70` rpc: expose CBlockIndex::nTx in getblock(header) (instagibbs) +- #13507 `f7401c8` RPC: Fix parameter count check for importpubkey (kristapsk) +- #13452 `6b9dc8c` rpc: have verifytxoutproof check the number of txns in proof structure (instagibbs) +- #12837 `bf1f150` rpc: fix type mistmatch in `listreceivedbyaddress` (joemphilips) +- #12743 `657dfc5` Fix csBestBlock/cvBlockChange waiting in rpc/mining (sipa) + +### GUI +- #12432 `f78e7f6` [qt] send: Clear All also resets coin control options (Sjors) +- #12617 `21dd5127` gui: Show messages as text not html (laanwj) +- #12793 `cf6feb7` qt: Avoid reseting on resetguisettigs=0 (MarcoFalke) + +### 建置系統 +- #13544 `9fd3e00` depends: Update Qt download url (fanquake) +- #12573 `88d1a64` Fix compilation when compiler do not support `__builtin_clz*` (532479301) + +### 測試和 QA +- #13061 `170b309` Make tests pass after 2020 (bmwiedemann) +- #13192 `79c4fff` [tests] Fixed intermittent failure in `p2p_sendheaders.py` (lmanners) +- #13300 `d9c5630` qa: Initialize lockstack to prevent null pointer deref (MarcoFalke) +- #13545 `e15e3a9` tests: Fix test case `streams_serializedata_xor` Remove Boost dependency. (practicalswift) +- #13304 `cbdabef` qa: Fix `wallet_listreceivedby` race (MarcoFalke) + +### Miscellaneous +- #12887 `2291774` Add newlines to end of log messages (jnewbery) +- #12859 `18b0c69` Bugfix: Include `` for `std::unique_ptr` (luke-jr) +- #13131 `ce8aa54` Add Windows shutdown handler (ken2812221) +- #13652 `20461fc` rpc: Fix that CWallet::AbandonTransaction would leave the grandchildren, etc. active (Empact) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 532479301 +- Ben Woosley +- Bernhard M. Wiedemann +- Chun Kuan Lee +- Cory Fields +- fanquake +- Gregory Sanders +- joemphilips +- John Newbery +- Kristaps Kaupe +- lmanners +- Luke Dashjr +- MarcoFalke +- Matt Corallo +- Pieter Wuille +- practicalswift +- Sjors Provoost +- Suhas Daftuar +- Wladimir J. van der Laan + +以及那些回報安全問題的人： + +- Braydon Fuller +- Himanshu Mehta + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-09-18-release-0.16.3.md b/_posts/zh_TW/releases/2018-09-18-release-0.16.3.md new file mode 100644 index 000000000..de8c4a304 --- /dev/null +++ b/_posts/zh_TW/releases/2018-09-18-release-0.16.3.md @@ -0,0 +1,93 @@ +--- +title: Bitcoin Core 0.16.3 +id: zh_tw-release-0.16.3 +name: release-0.16.3 +permalink: /zh_TW/releases/0.16.3/ +excerpt: Bitcoin Core 0.16.3 版本現已發布 +date: 2018-09-18 +type: releases +layout: page +lang: zh_TW + +release: [0, 16, 3] + +optional_magnetlink: "magnet:?xt=urn:btih:a6015029671a445a7a07026b3e4a0fe54c2b2df3&dn=bitcoin-core-0.16.3&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.16.3 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 或更高版本沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +在 0.16 及更高版本中建立的錢包與 0.16 之前的版本不相容，如果您嘗試在舊版本中使用新建立的錢包，它們將無法運作。使用舊版本建立的現有錢包不受此影響。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +拒絕服務漏洞 +------------------------------- + +在 Bitcoin Core 版本 0.14.0 到 0.16.2 中發現了一個可被礦工利用的拒絕服務漏洞。建議盡快將任何易受攻擊的版本升級到 0.16.3。 + +0.16.3 變更日誌 +------------------ + +### 共識 +- #14249 `696b936` Fix crash bug with duplicate inputs within a transaction (TheBlueMatt, sdaftuar) + +### RPC 和其他 API +- #13547 `212ef1f` Make `signrawtransaction*` give an error when amount is needed but missing (ajtowns) + +### Miscellaneous +- #13655 `1cdbea7` bitcoinconsensus: invalid flags error should be set to `bitcoinconsensus_err` (afk11) + +### 文件 +- #13844 `11b9dbb` correct the help output for -prune (hebasto) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Anthony Towns +- Hennadii Stepanov +- Matt Corallo +- Suhas Daftuar +- Thomas Kerin +- Wladimir J. van der Laan + +以及那些回報安全問題的人： + +- beardnboobies + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-09-28-release-0.14.3.md b/_posts/zh_TW/releases/2018-09-28-release-0.14.3.md new file mode 100644 index 000000000..c59f16074 --- /dev/null +++ b/_posts/zh_TW/releases/2018-09-28-release-0.14.3.md @@ -0,0 +1,114 @@ +--- +title: Bitcoin Core 0.14.3 +id: zh_tw-release-0.14.3 +name: release-0.14.3 +permalink: /zh_TW/releases/0.14.3/ +excerpt: Bitcoin Core 0.14.3 版本現已發布 +date: 2018-09-28 +type: releases +layout: page +lang: zh_TW + +release: [0, 14, 3, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:171edf5f51820900f24fc72620deaa07ee497dee&dn=bitcoin-core-0.14.3&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.14.3 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。 + +Microsoft 已於 [2014 年 4 月 8 日](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support)終止對 Windows XP 的支援，我們沒有嘗試阻止在 Windows XP 上安裝或執行軟體，您仍然可以自行承擔風險執行，但請注意存在已知的不穩定性和問題。請不要向問題追蹤器回報關於 Windows XP 的問題。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +拒絕服務漏洞 CVE-2018-17144 +------------------------------- + +在 Bitcoin Core 版本 0.14.0 到 0.16.2 中發現了一個可被礦工利用的拒絕服務漏洞。建議盡快將任何易受攻擊的版本升級到 0.14.3、0.15.2 或 0.16.3。 + +已知錯誤 +========== + +自 0.14.0 以來，使用幣控制和智慧費用估算時，Bitcoin-Qt 顯示的大約交易費用不會反映智慧費用滑桿的目標變化。它只會使用預設目標顯示大約費用。使用正確目標計算的費用仍會應用於交易並顯示在最終發送確認對話框中。 + +0.14.3 變更日誌 +================= + +### 共識 +- #14247 `52965fb` Fix crash bug with duplicate inputs within a transaction (TheBlueMatt, sdaftuar) + +### RPC 和其他 API + +- #10445 `87a21d5` Fix: make CCoinsViewDbCursor::Seek work for missing keys (Pieter Wuille, Gregory Maxwell) +- #9853 Return correct error codes in setban(), fundrawtransaction(), removeprunedfunds(), bumpfee(), blockchain.cpp (John Newbery) + +### P2P 協定和網路程式碼 + +- #10234 `d289b56` [net] listbanned RPC and QT should show correct banned subnets (John Newbery) + +### 雜項 + +- #10451 `3612219` contrib/init/bitcoind.openrcconf: Don't disable wallet by default (Luke Dashjr) +- #10250 `e23cef0` Fix some empty vector references (Pieter Wuille) +- #10196 `d28d583` PrioritiseTransaction updates the mempool tx counter (Suhas Daftuar) +- #9497 `e207342` Fix CCheckQueue IsIdle (potential) race condition and remove dangerous constructors (Jeremy Rubin) + +### GUI + +- #9481 `7abe7bb` Give fallback fee a reasonable indent (Luke Dashjr) +- #9481 `3e4d7bf` Qt/Send: Figure a decent warning colour from theme (Luke Dashjr) +- #9481 `e207342` Show more significant warning if we fall back to the default fee (Jonas Schnelli) + +### 錢包 + +- #10308 `28b8b8b` Securely erase potentially sensitive keys/values (tjps) +- #10265 `ff13f59` Make sure pindex is non-null before possibly referencing in LogPrintf call (Karl-Johan Alm) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Cory Fields +- CryptAxe +- fanquake +- Jeremy Rubin +- John Newbery +- Jonas Schnelli +- Gregory Maxwell +- Karl-Johan Alm +- Luke Dashjr +- MarcoFalke +- Matt Corallo +- Mikerah +- Pieter Wuille +- practicalswift +- Suhas Daftuar +- Thomas Snider +- Tjps +- Wladimir J. van der Laan + +以及那些回報安全問題的人： + +- awemany（對於 CVE-2018-17144，先前被列為「匿名回報者」） +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-09-28-release-0.15.2.md b/_posts/zh_TW/releases/2018-09-28-release-0.15.2.md new file mode 100644 index 000000000..819a01663 --- /dev/null +++ b/_posts/zh_TW/releases/2018-09-28-release-0.15.2.md @@ -0,0 +1,115 @@ +--- +title: Bitcoin Core 0.15.2 +id: zh_tw-release-0.15.2 +name: release-0.15.2 +permalink: /zh_TW/releases/0.15.2/ +excerpt: Bitcoin Core 0.15.2 版本現已發布 +date: 2018-09-28 +type: releases +layout: page +lang: zh_TW + +release: [0, 15, 2, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:c0a23591e04ce45dd6349f3abc34df948c45537c&dn=bitcoin-core-0.15.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.15.2 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更高版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +`fee_estimates.dat` 的檔案格式在版本 0.15.0 中已變更。因此，從版本 0.15 降級或升級到版本 0.15 將導致所有費用估算被丟棄。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +此版本的 chainstate 資料庫與先前版本不相容，因此如果您執行 0.15 然後決定切換回任何較舊版本，您將需要使用 `-reindex-chainstate` 選項執行舊版本，以舊格式重建 chainstate 資料結構。 + +如果您的節點已啟用修剪，這將需要重新下載和處理整個區塊鏈。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.8+ 和 Windows Vista 及更新版本的作業系統上經過廣泛測試。不支援 Windows XP。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +重要變更 +=============== + +拒絕服務漏洞 CVE-2018-17144 +------------------------------- + +在 Bitcoin Core 版本 0.14.0 到 0.16.2 中發現了一個可被礦工利用的拒絕服務漏洞。建議盡快將任何易受攻擊的版本升級到 0.15.2 或 0.16.3。 + +0.15.2 變更日誌 +================= + +### 建置系統 + +- #11995 `9bb1a16` depends: Fix Qt build with XCode 9.2(fanquake) +- #12946 `93b9a61` depends: Fix Qt build with XCode 9.3(fanquake) +- #13544 `9fd3e00` depends: Update Qt download url (fanquake) +- #11847 `cb7ef31` Make boost::multi_index comparators const (sdaftuar) + +### 共識 +- #14247 `4b8a3f5` Fix crash bug with duplicate inputs within a transaction (TheBlueMatt, sdaftuar) + +### RPC +- #11676 `7af2457` contrib/init: Update openrc-run filename (Luke Dashjr) +- #11277 `7026845` Fix uninitialized URI in batch RPC requests (Russell Yanofsky) + +### 錢包 +- #11289 `3f1db56` Wrap dumpwallet warning and note scripts aren't dumped (MeshCollider) +- #11289 `42ea47d` Add wallet backup text to import*, add* and dumpwallet RPCs (MeshCollider) +- #11590 `6372a75` [Wallet] always show help-line of wallet encryption calls (Jonas Schnelli) + +### bitcoin-tx + +- #11554 `a69cc07` Sanity-check script sizes in bitcoin-tx (TheBlueMatt) + +### 測試 +- #11277 `3a6cdd4` Add test for multiwallet batch RPC calls (Russell Yanofsky) +- #11647 `1c8c7f8` Add missing batch rpc calls to python coverage logs (Russell Yanofsky) +- #11277 `1036c43` Add missing multiwallet rpc calls to python coverage logs (Russell Yanofsky) +- #11277 `305f768` Limit AuthServiceProxyWrapper.\_\_getattr\_\_ wrapping (Russell Yanofsky) +- #11277 `2eea279` Make AuthServiceProxy.\_batch method usable (Russell Yanofsky) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- fanquake +- Jonas Schnelli +- Luke Dashjr +- Matt Corallo +- MeshCollider +- Russell Yanofsky +- Suhas Daftuar +- Wladimir J. van der Laan + +以及那些回報安全問題的人： + +- awemany（對於 CVE-2018-17144，先前被列為「匿名回報者」） +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-10-03-release-0.17.0.md b/_posts/zh_TW/releases/2018-10-03-release-0.17.0.md new file mode 100644 index 000000000..ef009d514 --- /dev/null +++ b/_posts/zh_TW/releases/2018-10-03-release-0.17.0.md @@ -0,0 +1,205 @@ +--- +title: Bitcoin Core 0.17.0 +id: zh_tw-release-0.17.0 +name: release-0.17.0 +permalink: /zh_TW/releases/0.17.0/ +excerpt: Bitcoin Core 0.17.0 版本現已發布 +date: 2018-10-03 +type: releases +layout: page +lang: zh_TW + +release: [0, 17, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:1c72f17bc1667a2ce81860b75135e491f6637d05&dn=bitcoin-core-0.17.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.17.0 版本現已發布，可從以下位置下載： + + + +此主要版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +如果您的節點有 txindex，第一次執行 0.17.0 或更新版本時，txindex 資料庫將被遷移，這可能需要幾個小時。在此遷移完成之前，您的節點將無法運作。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +此版本的 chainstate 資料庫與先前版本不相容，因此如果您執行 0.15 然後決定切換回任何較舊版本，您將需要使用 `-reindex-chainstate` 選項執行舊版本，以舊格式重建 chainstate 資料結構。 + +如果您的節點已啟用修剪，這將需要重新下載和處理整個區塊鏈。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.10+ 和 Windows 7 及更新版本的作業系統上經過廣泛測試（不支援 Windows XP）。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +從 0.17.0 開始，不再支援 macOS 10.10 之前的版本。0.17.0 使用 Qt 5.9.x 建置，該版本不支援 macOS 10.10 之前的版本。 + +已知錯誤 +============ + +- 從 0.13.0 或更早版本升級目前會導致在回滾區塊到 SegWit 啟動點時記憶體耗盡。在這些情況下，需要完整的 `-reindex`。 + +- GUI 在新的 MacOS 深色模式中存在視覺故障。這與我們的 Qt 主題處理有關，不是 0.17.0 中的新問題，但預計將在 0.17.1 中解決。 + +重要變更 +=============== + +變更的設定選項 +----------------------------- + +`-includeconf=` 可用於包含額外的設定檔。僅在 `bitcoin.conf` 檔案內有效，在包含的檔案內或從命令列無效。可以包含多個檔案。可以透過 `-noincludeconf` 從命令列停用。 + +GUI 變更 +----------- + +在偏好設定的主標籤中可以限制區塊儲存。撤消此設定需要再次下載完整的區塊鏈。此模式與 `-txindex` 和 `-rescan` 不相容。 + +外部錢包檔案 +--------------------- + +`-wallet=` 選項現在接受完整路徑，而不是要求錢包位於 `-walletdir` 目錄中。 + +新建立的錢包格式 +--------------------------- + +如果使用不存在的路徑指定 `-wallet=`，它現在將在指定位置建立錢包目錄（包含 wallet.dat 資料檔案、db.log 檔案和 database/log.?????????? 檔案），而不是僅在該路徑建立資料檔案並將日誌檔案儲存在父目錄中。這應該使備份錢包比以前更直接，因為可以直接歸檔指定的錢包路徑，而無需在父目錄中尋找交易日誌檔案。 + +為了向後相容，作為 `-walletdir` 目錄中現有資料檔案名稱的錢包路徑將繼續被接受並以與以前相同的方式解釋。 + +動態載入和建立錢包 +--------------------------------------- + +以前，錢包只能在啟動時載入或建立，透過在命令列或 bitcoin.conf 檔案中指定 `-wallet` 參數。現在可以在執行時動態載入、建立和卸載錢包： + +- 現有錢包可以透過呼叫 `loadwallet` RPC 載入。錢包可以指定為檔案/目錄基本名稱（必須位於 `walletdir` 目錄中），或作為檔案/目錄的絕對路徑。 +- 新錢包可以透過呼叫 `createwallet` RPC 建立（並載入）。提供的名稱不得與 `walletdir` 目錄中的錢包檔案匹配或當前載入的錢包名稱。 +- 已載入的錢包可以透過呼叫 `unloadwallet` RPC 卸載。 + +此功能目前僅透過 RPC 介面提供。 + +幣選擇 +-------------- + +### 部分支出避免 + +當一個地址被多次付款時，來自這些單獨付款的幣可以分別花費，這會由於連結原本分開的地址而損害隱私。已添加新的 `-avoidpartialspends` 標誌（預設=false）。如果啟用，即使導致更高的費用，錢包也會始終一起花費發送到同一地址的現有 UTXO。如果有人在使用後向地址發送幣，這些幣仍將包含在未來的幣選擇中。 + +testnet 和 regtest 的設定區段 +---------------------------------------------- + +現在可以為單個設定檔設定不同網路的不同選項。這是透過使用區段或透過在選項前加上網路來完成的。 + +錢包的 'label' 和 'account' API +------------------------------------- + +已為錢包引入新的 'label' API。這旨在取代已棄用的 'account' API。可以在 V0.17 中透過使用 '-deprecatedrpc=accounts' 參數啟動 bitcoind 繼續使用 'account'，並將在 V0.18 中完全移除。 + +標籤 RPC 方法反映了帳戶功能，具有以下功能差異： + +- 標籤可以設定在任何地址上，而不僅僅是接收地址。此功能以前僅透過 GUI 可用。 +- 標籤可以透過使用 `setlabel` RPC 方法重新分配所有地址來刪除。 +- 不支援_從_標籤發送交易，或確定交易是從哪個標籤發送的。 +- 標籤沒有餘額。 + +BIP 174 部分簽名比特幣交易支援 +----------------------------------------------------- + +[BIP 174 PSBT](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) 是比特幣交易的交換格式，這些交易尚未完全簽名，連同相關的中繼資料，以幫助實體合作簽署它。它旨在簡化多方需要合作生成交易的工作流程。範例包括硬體錢包、multisig 設定和 [CoinJoin](https://bitcointalk.org/?topic=279249) 交易。 + +### RPC + +- **`converttopsbt` (Creator)** 是一個實用程式 RPC，將未簽名的原始交易轉換為 PSBT 格式。它會忽略現有簽名。 +- **`createpsbt` (Creator)** 是一個實用程式 RPC，接受輸入和輸出列表並將它們轉換為沒有額外資訊的 PSBT。 +- **`walletcreatefundedpsbt` (Creator, Updater)** 是一個錢包 RPC，使用指定的輸入和輸出建立 PSBT，向其添加額外的輸入和找零以平衡它，並添加相關的中繼資料。 +- **`walletprocesspsbt` (Updater, Signer, Finalizer)** 是一個錢包 RPC，接受 PSBT 作為輸入，向缺少的輸入和輸出添加 UTXO、金鑰和腳本資料，並選擇性地簽署輸入。在可能的情況下，它還會最終確定部分簽名。 +- **`finalizepsbt` (Finalizer, Extractor)** 是一個實用程式 RPC，最終確定任何部分簽名，如果所有輸入都已最終確定，則將結果轉換為可以使用 `sendrawtransaction` 廣播的完全簽名交易。 +- **`combinepsbt` (Combiner)** 是一個實用程式 RPC，實作組合器。它可以在工作流程的任何時間點使用，以合併添加到同一 PSBT 的不同版本的資訊。 +- **`decodepsbt`** 是一個診斷實用程式 RPC，它將以人類可讀的形式顯示 PSBT 中的所有資訊，以及如果已知，則計算其最終費用。 + +將非 HD 錢包升級到 HD 錢包 +-------------------------------------- + +自 Bitcoin Core 0.13.0 以來，Bitcoin Core 已支援建立新的 BIP 32 分層確定性錢包，但舊的非 HD 錢包無法升級到 HD。現在可以使用 `-upgradewallet` 命令列選項將非 HD 錢包升級到 HD。此升級將導致金鑰池中的所有金鑰被標記為已使用並生成新的金鑰池。**執行此升級時必須建立新備份。** + +HD 主金鑰輪換 +---------------------- + +已引入新的 RPC `sethdseed`，允許使用者設定新的 HD 種子或設定自己的 HD 種子。這允許使用新的 HD 種子。**設定新 HD 種子時必須建立新備份。** + +低階 RPC 變更 +--------------------- + +- 新的 RPC `scantxoutset` 可用於掃描 UTXO 集以查找與某些輸出描述符匹配的條目。此呼叫類似於 `listunspent`，但不使用錢包，這意味著可以在編譯或執行時停用錢包。此呼叫是實驗性的，可能會在未來版本中更改或移除。 + +- `createrawtransaction` RPC 現在將接受 `outputs` 參數的陣列或字典。這意味著客戶端可以指定交易輸出的順序。 + +- 新的 RPC `testmempoolaccept` 可用於測試交易對 mempool 的接受而不添加它。 + +- JSON 交易分解現在包括 `weight` 欄位，該欄位提供交易的精確權重。 + +- 當 bitcoin 未使用任何 `-wallet=` 選項啟動時，`getwalletinfo` 和 `listwallets` RPC 返回的預設錢包名稱現在是空字串 `""`，而不是 `"wallet.dat"`。 + +其他 API 變更 +----------------- + +- `dumpwallet` 輸出中的 `inactivehdmaster` 屬性已更正為 `inactivehdseed`。 + +### 日誌 + +- 日誌時間戳格式現在是 ISO 8601（例如 "2018-02-28T12:34:56Z"）。 + +- 使用 `-debug` 但沒有 `-daemon` 執行 bitcoind 時，現在預設為記錄到 stdout。設定 `-printtoconsole=1` 不再隱式停用記錄到 debug.log。相反，可以透過設定 `-debuglogfile=0` 明確停用記錄到檔案。 + +交易索引變更 +------------------------- + +交易索引現在與主節點程式分開建置，這意味著可以在不需要完整重新索引的情況下切換 `-txindex` 標誌。如果在已部分或完全同步但沒有交易索引的節點上使用 `-txindex` 執行 bitcoind，交易索引將在背景建置並在趕上後可用。當從執行 `-txindex` 切換到不使用該標誌執行時，交易索引資料庫將*不會*自動刪除，這意味著可以在以後不需要完全重新同步的情況下重新開啟它。 + +礦工區塊大小已移除 +------------------------ + +礦工限制其區塊大小的 `-blockmaxsize` 選項在 V0.15.1 中已被棄用，現在已被移除。礦工如果想要限制其區塊的權重，應使用 `-blockmaxweight` 選項。 + +Python 支援 +-------------- + +已停止對所有測試檔案和工具的 Python 2 支援。 + +0.17.0 變更日誌 +================= + +完整的變更日誌包含超過 400 個 PR，涵蓋共識、策略、挖礦、區塊和交易處理、P2P 協定和網路程式碼、錢包、RPC 和其他 API、GUI、建置系統、測試和 QA、平台支援、文件等方面。由於篇幅限制，請參閱原始版本說明以獲取完整清單。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 140 位貢獻者。完整清單請參閱原始版本說明。 + +以及那些回報安全問題的人： + +- awemany（對於 CVE-2018-17144，先前被列為「匿名回報者」） + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-10-30-release-0.17.0.1.md b/_posts/zh_TW/releases/2018-10-30-release-0.17.0.1.md new file mode 100644 index 000000000..fada5e2f0 --- /dev/null +++ b/_posts/zh_TW/releases/2018-10-30-release-0.17.0.1.md @@ -0,0 +1,57 @@ +--- +title: Bitcoin Core 0.17.0.1 +id: zh_tw-release-0.17.0.1 +name: release-0.17.0.1 +permalink: /zh_TW/releases/0.17.0.1/ +excerpt: Bitcoin Core 0.17.0.1 版本現已發布 +date: 2018-10-30 +type: releases +layout: page +lang: zh_TW + +release: [0, 17, 0, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:70749cf2cf2922a21208b4ae760c9f2f9d1e7f11&dn=bitcoin-core-0.17.0.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.17.0.1 版本現已發布，可從以下位置下載： + + + +此版本為 0.17.0 提供了一個小錯誤修正。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +重要變更 +=============== + +解決了 OSX dmg 生成的問題，該問題影響 macOS 10.12 到 10.14，可能導致 Finder 在安裝時崩潰。 + +對於其他作業系統沒有重大變更，使此版本在其他方面與 [0.17.0](/zh_TW/releases/0.17.0/) 相同。 + +0.17.0.1 變更日誌 +=================== + +### 建置系統 +- #14416 `eb2cc84` Fix OSX dmg issue (10.12 to 10.14) (jonasschnelli) + +### 文件 +- #14509 `1b5af2c` [0.17] doc: use SegWit in getblocktemplate example (Sjors) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Jonas Schnelli +- Pieter Wuille +- Sjors Provoost +- Wladimir J. van der Laan +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-11-24-release-0.19.0.1.md b/_posts/zh_TW/releases/2018-11-24-release-0.19.0.1.md new file mode 100644 index 000000000..19964684f --- /dev/null +++ b/_posts/zh_TW/releases/2018-11-24-release-0.19.0.1.md @@ -0,0 +1,218 @@ +--- +title: Bitcoin Core 0.19.0.1 +id: zh_tw-release-0.19.0.1 +name: release-0.19.0.1 +permalink: /zh_TW/releases/0.19.0.1/ +excerpt: Bitcoin Core 0.19.0.1 版本現已發布 +date: 2018-11-24 +type: releases +layout: page +lang: zh_TW + +release: [0, 19, 0, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:436859e8dddf4d8bd22d9ecc826139b6749a9a4a&dn=bitcoin-core-0.19.0.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.19.0.1 版本說明 +====================== + +Bitcoin Core 0.19.0.1 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（對於舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.10+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。不建議在不受支援的系統上使用 Bitcoin Core。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +從 0.17.0 開始，macOS <10.10 不再受支援。0.17.0 使用 Qt 5.9.x 建置，該版本不支援 macOS 10.10 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +執行 macOS Catalina 的使用者可能需要「右鍵點擊」然後選擇「打開」來打開 Bitcoin Core .dmg。這是由於 Apple 實施的新簽名要求，Bitcoin Core 專案尚未遵守。 + +重要變更 +=============== + +新的使用者文件 +---------------------- + +- [減少記憶體](https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md)建議在記憶體有限的系統上執行 Bitcoin Core 的設定調整。(#16339) + +新的 RPC +-------- + +- `getbalances` 返回一個包含所有餘額（`mine`、`untrusted_pending` 和 `immature`）的物件。請參閱 `getbalances` 的 RPC 說明以獲取詳細資訊。新的 RPC 旨在替換 `getbalance`、`getunconfirmedbalance` 和 `getwalletinfo` 中的餘額欄位。這些舊呼叫和欄位可能會在未來版本中移除。(#15930, #16239) + +- `setwalletflag` 設定和取消設定錢包標誌，這些標誌啟用或停用特定於該現有錢包的功能，例如這些版本說明中其他地方記錄的新 `avoid_reuse` 功能。(#13756) + +- `getblockfilter` 獲取指定區塊的 BIP158 過濾器。只有在使用 `-blockfilterindex` 設定選項建立區塊過濾器時，此 RPC 才啟用。(#14121) + +新設定 +------------ + +- `-blockfilterindex` 啟用為整個區塊鏈建立 BIP158 區塊過濾器。過濾器將在背景建立，目前使用約 4 GiB 的空間。請注意：此版本的 Bitcoin Core 不透過 P2P 網路提供區塊過濾器，儘管本地使用者可以使用 `getblockfilter` RPC 獲取區塊過濾器。(#14121) + +更新的設定 +---------------- + +- `whitebind` 和 `whitelist` 現在接受權限清單，以提供使用指示介面或 IP 地址連線的對等節點。如果未使用地址或 CIDR 網路指定權限，則隱含的預設權限與先前版本相同。請參閱這兩個選項的 `bitcoind -help` 輸出以獲取有關可用權限的詳細資訊。(#16248) + +- 設定自訂 `dbcache` 值的使用者可以稍微增加其設定而不使用更多實際記憶體。最近的變更將記憶體使用減少了約 9%，並使鏈狀態計算更準確（以前低估了記憶體使用）。例如，如果您之前設定了「450」的值，您現在可以設定「500」的值以使用大約相同的實際記憶體量。(#16957) + +更新的 RPC +------------ + +注意：一些主要用於測試的低階 RPC 變更在下面的低階變更部分中描述。 + +- `sendmany` 不再有 `minconf` 參數。此參數沒有很好地指定，即使錢包的幣選擇成功，也會導致 RPC 錯誤。想要影響幣選擇的使用者可以使用現有的 `-spendzeroconfchange`、`-limitancestorcount`、`-limitdescendantcount` 和 `-walletrejectlongchains` 設定參數。(#15596) + +- `getbalance` 和 `sendtoaddress`，以及新的 RPC `getbalances` 和 `createwallet`，現在接受一個「avoid_reuse」參數，該參數控制操作中是否應包含已使用的地址。此外，當啟用 `avoid_reuse` 時，即使尚未透過 `-avoidpartialspends` 命令列標誌啟用此功能，`sendtoaddress` 也將避免部分花費，因為不這樣做會冒著為地址重用情況使用「錯誤」UTXO 的風險。(#13756) + +- 具有 `include_watchonly` 參數或 `includeWatching` 選項的 RPC 現在對僅觀察錢包預設為 `true`。受影響的 RPC 包括：`getbalance`、`listreceivedbyaddress`、`listreceivedbylabel`、`listtransactions`、`listsinceblock`、`gettransaction`、`walletcreatefundedpsbt` 和 `fundrawtransaction`。(#16383) + +- `listunspent` 現在為每個輸出返回一個「reused」布林值，如果啟用了錢包標誌「avoid_reuse」。(#13756) + +- `getblockstats` 現在使用 BlockUndo 資料而不是交易索引，使其速度更快，不再依賴於 `-txindex` 設定選項，並且對所有未修剪的區塊都有效。(#14802) + +- `utxoupdatepsbt` 現在接受一個 `descriptors` 參數，該參數將在已知時填充輸入和輸出腳本和金鑰。當提供描述符顯示它們正在花費 segwit 輸出時，P2SH-witness 輸入將從 UTXO 集中填充。請參閱 RPC 說明文字以獲取完整詳細資訊。(#15427) + +- `sendrawtransaction` 和 `testmempoolaccept` 不再接受 `allowhighfees` 參數來在交易費用超過設定選項 `-maxtxfee` 的值時失敗 mempool 接受。現在有一個硬編碼的預設最大費率，可以在使用 `maxfeerate` 參數呼叫任一 RPC 時變更。(#15620) + +- `getmempoolancestors`、`getmempooldescendants`、`getmempoolentry` 和 `getrawmempool` 不再返回 `size` 欄位，除非使用設定選項 `-deprecatedrpc=size`。相反，將返回一個新的 `vsize` 欄位，其中包含交易的虛擬大小（與其他 RPC（如 `getrawtransaction`）一致）。(#15637) + +- `getwalletinfo` 現在包括一個 `scanning` 欄位，該欄位為 `false`（無掃描）或一個物件，其中包含有關錢包掃描影響其餘額的歷史區塊的持續時間和進度的資訊。(#15730) + +- `gettransaction` 現在接受第三個（布林）參數 `verbose`。如果設定為 `true`，將在回應中新增一個新的 `decoded` 欄位，其中包含解碼的交易。此欄位相當於 RPC `decoderawtransaction`，或當傳遞 `verbose` 時的 RPC `getrawtransaction`。(#16185, #16866, #16873) + +- `createwallet` 接受一個新的 `passphrase` 參數。如果設定，這將建立使用給定密碼加密的新錢包。如果未設定（預設）或設定為空字串，將不使用加密。(#16394) + +- `getchaintxstats` RPC 現在返回 `window_final_block_height` 的額外金鑰。(#16695) + +- `getmempoolentry` 現在提供一個 `weight` 欄位，包含 BIP141 中定義的交易權重。(#16647) + +- `getnetworkinfo` 和 `getpeerinfo` 命令現在包含一個新欄位，其中包含解碼的網路服務標誌。(#16786) + +- `getdescriptorinfo` 現在返回一個額外的 `checksum` 欄位，其中包含使用者提供的未修改描述符的校驗和（即，在 `descriptor` 欄位的描述符規範化之前）。(#15986) + +- `joinpsbts` 現在打亂結果合併 PSBT 的輸入和輸出順序。以前，輸入和輸出按照提供 PSBT 的順序新增。這使得將輸入與輸出關聯變得容易，代表隱私洩漏。(#16512) + +- `walletcreatefundedpsbt` 現在在 `-walletrbf` 設定選項設定為 true 時發出 BIP125 Replace-by-Fee 訊號。(#15911) + +GUI 變更 +----------- + +- GUI 錢包現在預設提供 bech32 地址。使用者可以在發票生成期間使用 GUI 切換變更地址類型，或可以使用 `-addresstype` 設定選項變更預設地址類型。(#15711, #16497) + +- 在 0.18.0 中，引入了一個 `./configure` 標誌以允許在 GUI 中停用 BIP70 支援（預設啟用支援）。在 0.19.0 中，此標誌現在預設__停用__。如果您想使用 GUI 中的 BIP70 支援編譯 Bitcoin Core，您可以將 `--enable-bip70` 傳遞給 `./configure`。(#15584) + +已棄用或移除的設定選項 +------------------------------------------- + +- `-mempoolreplacement` 已移除，儘管預設節點行為保持不變。此選項以前允許使用者阻止節點接受或中繼 BIP125 交易替換。這與剩餘的設定選項 `-walletrbf` 不同。(#16171) + +已棄用或移除的 RPC +-------------------------- + +- `bumpfee` 不再接受 `totalFee` 選項，除非指定設定參數 `deprecatedrpc=totalFee`。此參數將在後續版本中完全移除。(#15996) + +- `bumpfee` 有一個新的 `fee_rate` 選項，作為已棄用的 `totalFee` 的替代。(#16727) + +- `generate` 在 Bitcoin Core 0.18 中被棄用後現已移除。請改用 `generatetoaddress` RPC。(#15492) + +P2P 變更 +----------- + +- BIP 61 拒絕訊息在 v0.18 中已棄用。它們現在預設停用，但可以透過設定 `-enablebip61` 命令列選項來啟用。BIP 61 拒絕訊息將在未來版本的 Bitcoin Core 中完全移除。(#14054) + +- 為了消除 Bitcoin Core 中眾所周知的拒絕服務向量，特別是對於具有旋轉磁碟的節點，`-peerbloomfilters` 設定選項的預設值已變更為 false。這阻止 Bitcoin Core 發送 BIP111 NODE_BLOOM 服務標誌，接受 BIP37 bloom 過濾器，或提供與 bloom 過濾器匹配的 merkle 區塊或交易。仍然想要提供 bloom 過濾器支援的使用者可以將設定選項設定為 true 以重新啟用 BIP111 和 BIP37 支援，或使用這些版本說明中其他地方描述的更新的 `-whitelist` 和 `-whitebind` 設定選項僅為特定對等節點啟用 BIP37 支援。在不久的將來，使用公共 BIP111/BIP37 節點的輕量級客戶端應該仍然能夠連線到舊版本的 Bitcoin Core 和手動啟用 BIP37 支援的節點，但此類軟體的開發人員應考慮遷移到使用特定的 BIP37 節點或替代交易過濾系統。(#16152) + +- 預設情況下，Bitcoin Core 現在將進行兩個額外的僅用於區塊中繼的出站連線。這些連線上不會處理交易或 addr 訊息。這些連線旨在新增很少的額外記憶體或頻寬資源需求，但應該使某些分區攻擊更難以執行。(#15759) + +其他 CLI 變更 +------------------------- + +- `bitcoin-cli -getinfo` 中的 `testnet` 欄位已重新命名為 `chain`，現在返回 BIP70 中定義的當前網路名稱（main、test、regtest）。(#15566) + +低階變更 +================= + +RPC +--- + +- `getblockchaininfo` 不再返回 `bip9_softforks` 物件。相反，資訊已移至 `softforks` 物件，並新增了一個 `type` 欄位，描述 Bitcoin Core 如何確定該軟分叉是否處於活動狀態（例如 BIP9 或 BIP90）。請參閱 RPC 說明以獲取詳細資訊。(#16060) + +- `getblocktemplate` 不再返回包含 `CSV` 和 `segwit`（目前處於活動狀態的 BIP9 部署）的 `rules` 陣列。(#16060) + +- `getrpcinfo` 現在返回一個 `logpath` 欄位，其中包含 `debug.log` 的路徑。(#15483) + +測試 +----- + +- 透過 `-regtest` 命令列標誌啟用的回歸測試鏈現在要求交易預設不違反標準政策。這與主網使用的預設設定相同，並且使在 regtest 上測試主網行為變得更容易。請注意，測試網仍然預設允許非標準交易，並且可以使用 `-acceptnonstdtxn` 命令列標誌為兩個測試鏈本地調整政策。(#15891) + +設定 +------------ + +- 在預設部分中指定但也未在網路特定部分（例如 testnet）中指定的設定現在將產生錯誤，阻止啟動而不僅僅是警告，除非網路是主網。這阻止了針對主網的設定被應用於測試網或 regtest。(#15629) + +- 在支援 `thread_local` 的平台上，日誌行可以以導致日誌的執行緒名稱為前綴。要啟用此行為，請使用 `-logthreadnames=1`。(#15849) + +網路 +------- + +- 當獲取由多個對等節點公告的交易時，以前版本的 Bitcoin Core 會按照收到這些對等節點公告的順序依次嘗試從每個公告對等節點下載交易，直到收到交易。在此版本中，下載邏輯已變更為在對等節點之間隨機化獲取順序，並優先向出站對等節點而不是入站對等節點發送下載請求。這修復了入站對等節點可以阻止節點獲取交易的問題。(#14897, #15834) + +- 如果正在使用 Tor 隱藏服務，即使為 clearnet 連線設定了不同的連接埠，Bitcoin Core 也將綁定到標準連接埠 8333。這防止了透過使用相同的非預設連接埠號碼洩漏節點身份。(#15651) + +Mempool 和交易中繼 +----------------------------- + +- 每個套件允許一個額外的單一祖先交易。以前，如果 mempool 中的交易有 25 個後代，或者它和它的所有後代超過 101,000 vbytes，則任何新收到的也是後代的交易都會被忽略。現在，如果它是直接後代（子代）並且子代的大小為 10,000 vbytes 或更少，則將允許一個額外的後代。這使得雙方合約協定（如 Lightning Network）可以為每個參與者提供一個他們可以立即花費以進行 Child-Pays-For-Parent (CPFP) 費用提升的輸出，而不允許一個惡意參與者填滿整個套件，從而阻止另一個參與者花費他們的輸出。(#15681) + +- 支付 v1 到 v16 見證版本（未來 segwit 版本）輸出的交易現在被接受到 mempool 中，中繼並挖礦。嘗試花費這些輸出仍然被政策禁止（「非標準」）。當此變更被廣泛部署時，錢包和服務可以接受任何有效的 bech32 Bitcoin 地址，而不必擔心支付未來 segwit 版本的交易會卡在未確認狀態。(#15846) + +- 舊式交易（沒有 segwit 輸入的交易）現在必須使用舊式編碼格式發送，強制執行 BIP144 中指定的規則。(#14039) + +錢包 +------ + +- 在修剪模式下，由 `importwallet`、`importpubkey`、`importaddress` 或 `importprivkey` RPC 觸發的重新掃描只有在區塊已被修剪時才會失敗。以前，當設定了 `-prune` 時它會失敗。此變更允許將 `-prune` 設定為高值（例如磁碟大小），而不會導致對任何匯入 RPC 的呼叫失敗，直到第一個區塊被修剪。(#15870) + +- 當建立費用高於 `-maxtxfee`（預設 0.1 BTC）的交易時，RPC 命令 `walletcreatefundedpsbt` 和 `fundrawtransaction` 現在將失敗而不是向下舍入費用。請注意，`feeRate` 參數以 BTC per 1,000 vbytes 指定，而不是 satoshi per vbyte。(#16257) + +- 已新增一個新的錢包標誌 `avoid_reuse`（預設關閉）。啟用時，錢包將區分已使用和未使用的地址，並預設在幣選擇中不使用前者。在現有錢包上設定此標誌時，需要重新掃描區塊鏈以正確標記以前使用的目標。與「避免部分花費」（在 Bitcoin Core v0.17.0 中新增）一起，這可以消除嚴重的隱私問題，即惡意使用者可以透過向先前支付的地址發送小額支付來追蹤花費，然後這些小額支付將包含在未來支付中的不相關輸入中。(#13756) + +建置系統變更 +-------------------- + +- Python >=3.5 現在是專案所有方面所必需的。這包括建置系統、測試框架和 linter。先前支援的最低版本 (3.4) 在 2019 年 3 月達到 EOL。(#14954) + +- 支援的最低 miniUPnPc API 版本設定為 10。這保持了與 Ubuntu 16.04 LTS 和 Debian 8 `libminiupnpc-dev` 套件的相容性。請注意，在 Debian 上，此套件仍然容易受到 [CVE-2017-8798](https://security-tracker.debian.org/tracker/CVE-2017-8798)（僅在 jessie 中）和 [CVE-2017-1000494](https://security-tracker.debian.org/tracker/CVE-2017-1000494)（在 jessie 和 stretch 中）的影響。(#15993) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人，總計超過 100 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2018-12-25-release-0.17.1.md b/_posts/zh_TW/releases/2018-12-25-release-0.17.1.md new file mode 100644 index 000000000..c64ceece1 --- /dev/null +++ b/_posts/zh_TW/releases/2018-12-25-release-0.17.1.md @@ -0,0 +1,164 @@ +--- +title: Bitcoin Core 0.17.1 +id: zh_tw-release-0.17.1 +name: release-0.17.1 +permalink: /zh_TW/releases/0.17.1/ +excerpt: Bitcoin Core 0.17.1 版本現已發布 +date: 2018-12-25 +type: releases +layout: page +lang: zh_TW + +release: [0, 17, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:c56c87ccfaa8e6fbccc90d549121e61efd97cb6f&dn=bitcoin-core-0.17.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.17.1 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +如果您的節點有 txindex，第一次執行 0.17.0 或更新版本時，txindex 資料庫將被遷移，這可能需要幾個小時。在此遷移完成之前，您的節點將無法運作。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +降級警告 +------------------- + +此版本的 chainstate 資料庫與先前版本不相容，因此如果您執行 0.15 然後決定切換回任何較舊版本，您將需要使用 `-reindex-chainstate` 選項執行舊版本，以舊格式重建 chainstate 資料結構。 + +如果您的節點已啟用修剪，這將需要重新下載和處理整個區塊鏈。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.10+ 和 Windows 7 及更新版本的作業系統上經過廣泛測試（不支援 Windows XP）。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +從 0.17.0 開始，不再支援 macOS 10.10 之前的版本。0.17.0 使用 Qt 5.9.x 建置，該版本不支援 macOS 10.10 之前的版本。 + +重要變更 +=============== + +`listtransactions` 標籤支援 +-------------------------------- + +在 0.17.0 中被棄用並重新命名為 `dummy` 的 `listtransactions` RPC `account` 參數已被取消棄用並再次重新命名為 `label`。 + +當 bitcoin 使用 `-deprecatedrpc=accounts` 設定進行設定時，指定 label/account/dummy 參數將返回傳出和傳入交易。沒有 `-deprecatedrpc=accounts` 設定，它將僅返回傳入交易（因為過去可以建立從特定帳戶支出的交易，但使用標籤不再可能這樣做）。 + +設定 `-deprecatedrpc=accounts` 時，可以傳遞空字串 "" 來列出沒有任何標籤的交易。沒有 `-deprecatedrpc=accounts`，傳遞空字串是一個錯誤，因為僅返回無標籤交易通常不是有用的行為，並且可能導致混淆。 + +0.17.1 變更日誌 +================= + +### P2P 協定和網路程式碼 + +- #14685 `9406502` Fix a deserialization overflow edge case (kazcw) +- #14728 `b901578` Fix uninitialized read when stringifying an addrLocal (kazcw) + +### 錢包 + +- #14441 `5150acc` Restore ability to list incoming transactions by label (jnewbery) +- #13546 `91fa15a` Fix use of uninitialized value `bnb_used` in CWallet::CreateTransaction(…) (practicalswift) +- #14310 `bb90695` Ensure wallet is unlocked before signing (gustavonalle) +- #14690 `5782fdc` Throw error if CPubKey is invalid during PSBT keypath serialization (instagibbs) +- #14852 `2528443` backport: [tests] Add `wallet_balance.py` (MarcoFalke) +- #14196 `3362a95` psbt: always drop the unnecessary utxo and convert non-witness utxo to witness when necessary (achow101) +- #14588 `70ee1f8` Refactor PSBT signing logic to enforce invariant and fix signing bug (gwillen) +- #14424 `89a9a9d` Stop requiring imported pubkey to sign non-PKH schemes (sipa, MeshCollider) + +### RPC 和其他 API + +- #14417 `fb9ad04` Fix listreceivedbyaddress not taking address as a string (etscrivner) +- #14596 `de5e48a` Bugfix: RPC: Add `address_type` named param for createmultisig (luke-jr) +- #14618 `9666dba` Make HTTP RPC debug logging more informative (practicalswift) +- #14197 `7bee414` [psbt] Convert non-witness UTXOs to witness if witness sig created (achow101) +- #14377 `a3fe125` Check that a separator is found for psbt inputs, outputs, and global map (achow101) +- #14356 `7a590d8` Fix converttopsbt permitsigdata arg, add basic test (instagibbs) +- #14453 `75b5d8c` Fix wallet unload during walletpassphrase timeout (promag) + +### GUI + +- #14403 `0242b5a` Revert "Force TLS1.0+ for SSL connections" (real-or-random) +- #14593 `df5131b` Explicitly disable "Dark Mode" appearance on macOS (fanquake) + +### 建置系統 + +- #14647 `7edebed` Remove illegal spacing in darwin.mk (ch4ot1c) +- #14698 `ec71f06` Add bitcoin-tx.exe into Windows installer (ken2812221) + +### 測試和 QA + +- #13965 `29899ec` Fix extended functional tests fail (ken2812221) +- #14011 `9461f98` Disable wallet and address book Qt tests on macOS minimal platform (ryanofsky) +- #14180 `86fadee` Run all tests even if wallet is not compiled (MarcoFalke) +- #14122 `8bc1bad` Test `rpc_help.py` failed: Check whether ZMQ is enabled or not (Kvaciral) +- #14101 `96dc936` Use named args in validation acceptance tests (MarcoFalke) +- #14020 `24d796a` Add tests for RPC help (promag) +- #14052 `7ff32a6` Add some actual witness in `rpc_rawtransaction` (MarcoFalke) +- #14215 `b72fbab` Use correct python index slices in example test (sdaftuar) +- #14024 `06544fa` Add `TestNode::assert_debug_log` (MarcoFalke) +- #14658 `60f7a97` Add test to ensure node can generate all rpc help texts at runtime (MarcoFalke) +- #14632 `96f15e8` Fix a comment (fridokus) +- #14700 `f9db08e` Avoid race in `p2p_invalid_block` by waiting for the block request (MarcoFalke) +- #14845 `67225e2` Add `wallet_balance.py` (jnewbery) + +### 文件 + +- #14161 `5f51fd6` doc/descriptors.md tweaks (ryanofsky) +- #14276 `85aacc4` Add autogen.sh in ARM Cross-compilation (walterwhite81) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- Chun Kuan Lee +- David A. Harding +- Eric Scrivner +- fanquake +- fridokus +- Glenn Willen +- Gregory Sanders +- gustavonalle +- John Newbery +- Jon Layton +- Jonas Schnelli +- João Barbosa +- Kaz Wesley +- Kvaciral +- Luke Dashjr +- MarcoFalke +- MeshCollider +- Pieter Wuille +- practicalswift +- Russell Yanofsky +- Sjors Provoost +- Suhas Daftuar +- Tim Ruffing +- Walter +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2019-05-02-release-0.18.0.md b/_posts/zh_TW/releases/2019-05-02-release-0.18.0.md new file mode 100644 index 000000000..4937d6caa --- /dev/null +++ b/_posts/zh_TW/releases/2019-05-02-release-0.18.0.md @@ -0,0 +1,270 @@ +--- +title: Bitcoin Core 0.18.0 +id: zh_tw-release-0.18.0 +name: release-0.18.0 +permalink: /zh_TW/releases/0.18.0/ +excerpt: Bitcoin Core 0.18.0 版本現已發布 +date: 2018-05-02 +type: releases +layout: page +lang: zh_TW + +release: [0, 18, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:a25c86ffa7a512b6d074287f74762b77f91cef4c&dn=bitcoin-core-0.18.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.18.0 版本現已發布，可從以下位置下載： + + + +此主要版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 或更新版本沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.10+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。不建議在不受支援的系統上使用 Bitcoin Core。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +從 0.17.0 開始，不再支援 macOS 10.10 之前的版本。0.17.0 使用 Qt 5.9.x 建置，該版本不支援 macOS 10.10 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +除了先前支援的 CPU 平台外，此版本的預編譯發行版為 RISC-V 平台提供二進位檔案。 + +如果您使用位於 `contrib/init/bitcoind.service` 的 `systemd` 單元設定檔，它已變更為使用 `/var/lib/bitcoind` 作為資料目錄，而不是 `~bitcoin/.bitcoin`。切換到新設定檔時，請確保 `/var/lib/bitcoind` 所在的檔案系統有足夠的空間（使用 `df -h /var/lib/bitcoind` 檢查），並選擇性地複製您現有的資料目錄。詳情請參閱 [systemd init 檔案部分](#systemd-init-file)。 + +已知錯誤 +============ + +錢包 GUI +---------- + +對於同時 (1) 啟用幣控制功能，以及 (2) 同時使用多個載入錢包的進階使用者：使用下拉選單切換錢包時，幣控制輸入選擇對話方塊可能會錯誤地保留錯誤錢包狀態。目前建議不要在載入多個錢包時使用幣控制功能。 + +重要變更 +=============== + +挖礦 +------ + +- 如果未指定 segwit 規則，對 `getblocktemplate` 的呼叫將失敗。不指定 segwit 呼叫 `getblocktemplate` 幾乎肯定是錯誤設定，因為這樣做會導致礦工獲得較低的獎勵。失敗的呼叫將產生錯誤訊息，說明如何啟用 segwit 規則。 + +設定選項變更 +---------------------------- + +- 如果在設定檔中使用無法識別的區段名稱，將印出警告。識別的區段為 `[test]`、`[main]` 和 `[regtest]`。 + +- 提供四個新選項用於設定 ZMQ 在記憶體中排隊的訊息最大數量（「高水位標記」），超過此數量後將丟棄額外的訊息。預設值為 1,000，與先前版本相同。詳情請參閱 [ZMQ 文件](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md#usage)。 + +- `rpcallowip` 選項不能再用於自動監聽所有網路介面。相反，必須使用 `rpcbind` 參數來指定要監聽的 IP 地址。透過公共網路連線監聽 RPC 命令是不安全的，如果使用者選擇此類設定，現在將印出警告。如果您需要為了使用 Docker 等工具而暴露 RPC，請確保僅將 RPC 綁定到 localhost，例如 `docker run [...] -p 127.0.0.1:8332:8332`（這比正常的 Docker 連接埠規格多了一個 `:8332`）。 + +- 如果在設定檔中設定的密碼包含井號字元 (#)，`rpcpassword` 選項現在會導致啟動錯誤，因為不清楚井號字元是用於密碼還是作為註釋。 + +- `whitelistforcerelay` 選項用於從白名單對等節點中轉發交易，即使未被 mempool 接受。此選項現在預設為關閉，這樣策略變更和斷開連線/封禁行為不會導致白名單另一個節點的節點被對等節點丟棄。使用者仍然可以使用命令列選項明確啟用此行為（並可能考慮[聯絡](https://bitcoincore.org/zh_TW/contact/) Bitcoin Core 專案讓我們了解他們的使用案例，因為此功能將來可能會被棄用）。 + +systemd init 檔案 {#systemd-init-file} +----------------- + +systemd init 檔案（`contrib/init/bitcoind.service`）已變更為使用 `/var/lib/bitcoind` 作為資料目錄，而不是 `~bitcoin/.bitcoin`。此變更使 Bitcoin Core 與其他服務更加一致，並使 systemd init 設定與現有的 Upstart 和 OpenRC 設定更加一致。 + +設定、PID 和資料目錄現在完全由 systemd 管理，systemd 將負責它們的建立、權限等。詳情請參閱 [`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=)。 + +使用 `contrib/init` 下提供的 init 檔案時，在 `/etc/bitcoin/bitcoin.conf` 中覆蓋 `datadir` 選項將無效。這是因為 init 檔案中指定的命令列參數優先於 `/etc/bitcoin/bitcoin.conf` 中指定的選項。 + +文件 +------------- + +- 關於 JSON-RPC 介面的新[簡短文件](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md)描述了 RPC 結果可能包含來自不同子系統的資料之間不一致的情況，例如錢包狀態和 mempool 狀態。[REST 介面文件](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md)中添加了一條註釋，指出適用相同的規則。 + +- [JSON-RPC 文件](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md)中添加了關於如何保護此介面的進一步資訊。 + +- 關於 `bitcoin.conf` 檔案的新[文件](https://github.com/bitcoin/bitcoin/blob/master/doc/bitcoin-conf.md)描述了如何使用它來設定 Bitcoin Core。 + +- 新文件介紹了 Bitcoin Core 的 BIP174 [部分簽名比特幣交易 (PSBT)](https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md) 介面，用於允許多個程式協作建立、簽名和廣播新交易。這對於離線（冷儲存）錢包、多重簽名錢包、coinjoin 實作以及許多其他需要兩個或多個程式互動以生成完整交易的情況很有用。 + +- [輸出腳本描述符](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md)文件已更新，包含有關此仍在開發中的語言的新功能的資訊，該語言用於描述錢包或其他程式希望接收通知的輸出腳本，例如它希望知道哪些地址收到了付款。該語言目前用於這些版本說明中描述的多個新的和更新的 RPC，並預計將適用於其他 RPC 和底層錢包結構。 + +建置系統變更 +-------------------- + +- 可以將新的 `--disable-bip70` 選項傳遞給 `./configure` 以防止 Bitcoin-Qt 使用 BIP70 付款協定支援建置或連結 libssl。由於付款協定過去曾將 Bitcoin Core 暴露於 libssl 漏洞，因此鼓勵不需要 BIP70 支援的建置者使用此選項來減少他們對未來漏洞的暴露。 + +- 建置 GUI 時所需的 Qt 最低版本已從 5.2 提升到 5.5.1（[depends 系統](https://github.com/bitcoin/bitcoin/blob/master/depends/README.md)提供 5.9.7）。 + +新 RPC +-------- + +- `getnodeaddresses` 返回此節點已知的對等節點地址。它可用於在不使用 DNS 種子的情況下找到要連線的節點。 + +- `listwalletdir` 返回錢包目錄中的錢包列表（預設錢包目錄或由 `-walletdir` 參數設定的目錄）。 + +- `getrpcinfo` 返回 RPC 伺服器的執行時詳細資訊。目前，它返回當前活動命令的陣列以及它們已執行的時間。 + +- `deriveaddresses` 返回對應於[輸出描述符](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md)的一個或多個地址。 + +- `getdescriptorinfo` 接受描述符並返回有關它的資訊，包括其計算的校驗和。 + +- `joinpsbts` 將多個不同的 PSBT 合併為單個 PSBT。多個 PSBT 必須具有不同的輸入。產生的 PSBT 將包含所有 PSBT 的每個輸入和輸出。任何 PSBT 中提供的任何簽名都將被丟棄。 + +- `analyzepsbt` 檢查 PSBT 並提供有關 PSBT 包含內容以及完成交易所需的後續步驟的資訊。對於 PSBT 的每個輸入，`analyzepsbt` 提供有關該輸入缺少哪些資訊的資訊，包括是否需要提供 UTXO、仍然需要提供哪些公鑰、需要提供哪些腳本以及仍然需要哪些簽名。每個輸入還將列出完成該輸入所需的角色，`analyzepsbt` 還將列出完成 PSBT 通常所需的下一個角色。如果 `analyzepsbt` 有足夠的資訊，它還將提供已完成交易的估計費率和估計虛擬大小。 + +- `utxoupdatepsbt` 搜尋未花費交易輸出 (UTXO) 集，以找到部分交易花費的輸出。PSBT 需要提供所花費的 UTXO，因為簽名演算法需要來自所花費 UTXO 的資訊。對於 segwit 輸入，只需要 UTXO 本身。對於非 segwit 輸出，需要整個先前交易，以便簽名者可以確定他們正在簽署正確的東西。不幸的是，由於 UTXO 集僅包含 UTXO 而不是完整交易，`utxoupdatepsbt` 將僅為 segwit 輸入添加 UTXO。 + +更新的 RPC +------------ + +- `getpeerinfo` 現在返回額外的 `minfeefilter` 欄位，設定為對等節點的 BIP133 費用過濾器。您可以使用它來檢測您擁有願意接受低於預設最小轉發費用的交易的對等節點。 + +- mempool RPC，例如具有 `verbose=true` 的 `getrawmempool`，現在返回額外的「bip125-replaceable」值，指示交易（或其未確認的祖先）是否選擇要求節點和礦工用花費任何相同輸入的更高費率交易替換它。 + +- `settxfee` 以前會悄悄地忽略將費用設定為低於允許的最小值的嘗試。它現在印出警告。仍然可以使用特殊值「0」來請求最小值。 + +- `getaddressinfo` 現在提供 `ischange` 欄位，指示錢包是否在找零輸出中使用該地址。 + +- `importmulti` 已更新以支援 P2WSH、P2WPKH、P2SH-P2WPKH 和 P2SH-P2WSH。對 P2WSH 和 P2SH-P2WSH 的請求接受額外的 `witnessscript` 參數。 + +- `importmulti` 現在為每個請求返回額外的 `warnings` 欄位，其中包含一個字串陣列，說明在有任何欄位被忽略或不一致時的情況。 + +- `getaddressinfo` 現在在 Bitcoin Core 對地址的 scriptPubKey、可選 redeemScript 和可選 witnessScript 有足夠了解時返回額外的 `solvable` 布林欄位，以便錢包能夠生成花費發送到該地址的資金的未簽名輸入。 + +- `getaddressinfo`、`listunspent` 和 `scantxoutset` RPC 現在返回額外的 `desc` 欄位，其中包含包含地址的所有金鑰路徑和簽名資訊的輸出描述符（私鑰除外）。`desc` 欄位僅在地址可解決時為 `getaddressinfo` 和 `listunspent` 返回。 + +- `importprivkey` 將保留先前為對應於導入私鑰的地址或公鑰設定的標籤。例如，如果您在 Bitcoin Core 的早期版本中導入了帶有標籤「冷錢包」的僅觀察地址，隨後導入私鑰將預設為將地址的標籤重置為預設空字串標籤（「」）。在此版本中，將保留先前的「冷錢包」標籤。如果您在呼叫 `importprivkey` 時選擇性地指定除預設值以外的任何標籤，則新標籤將應用於地址。 + +- `getmininginfo` 現在在從未透過 RPC 在此節點上組裝區塊時省略 `currentblockweight` 和 `currentblocktx`。 + +- `getrawtransaction` RPC 和 REST 端點不再檢查未花費 UTXO 集以查找交易。剩餘行為如下：1. 如果提供了 blockhash，檢查相應的區塊。2. 如果未提供 blockhash，檢查 mempool。3. 如果未提供 blockhash 但啟用了 txindex，也檢查 txindex。 + +- `unloadwallet` 現在是同步的，這意味著它將在錢包完全卸載之前不會返回。 + +- `importmulti` 現在支援從描述符導入地址。可以提供「desc」參數而不是請求中的「scriptPubKey」，以及可選的範圍，用於範圍描述符以指定要導入的範圍的開始和結束。透過 `importmulti` 導入的帶有金鑰來源資訊的描述符將在錢包中儲存其金鑰來源資訊，以用於建立 PSBT。有關描述符的更多資訊可以在[這裡](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md)找到。 + +- `listunspent` 已修改，以便在 P2WSH 或 P2SH-P2WSH 輸出的情況下也返回 `witnessScript`，即見證腳本。 + +- `createwallet` 現在有一個可選的 `blank` 參數，可用於建立空白錢包。空白錢包沒有任何金鑰或 HD 種子。它們無法在早於 0.18 的軟體中開啟。一旦空白錢包設定了 HD 種子（透過使用 `sethdseed`）或導入了私鑰、腳本、地址和其他僅觀察的內容，錢包就不再是空白的，可以在 0.17.x 中開啟。加密空白錢包也將為其設定 HD 種子。 + +棄用或移除的 RPC +-------------------------- + +- `signrawtransaction` 在 0.17.0 版本中被棄用並隱藏在特殊設定選項後面後被移除。 + +- 「account」API 在 v0.17 中棄用後被移除。「label」API 在 v0.17 中作為帳戶的替代品引入。請參閱 [v0.17 的版本說明](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#label-and-account-apis-for-wallet)以獲取從「account」API 到「label」API 的變更的完整描述。 + +- `addwitnessaddress` 在 0.16.0 版本中被棄用後被移除。 + +- `generate` 已棄用，將在後續主要版本中完全移除。此 RPC 僅用於測試，但其實作跨越多個子系統（錢包和挖礦），因此正在棄用以簡化錢包節點介面。用於測試目的的專案應該轉換為使用 `generatetoaddress` RPC，它不需要或使用錢包元件。使用 `getnewaddress` RPC 返回的地址呼叫 `generatetoaddress` 提供與舊 `generate` RPC 相同的功能。要在此版本中繼續使用 `generate`，請使用 `-deprecatedrpc=generate` 設定選項重新啟動 bitcoind。 + +- 請注意，`validateaddress` 命令的部分已被棄用並移至 `getaddressinfo`。以下棄用欄位已移至 `getaddressinfo`：`ismine`、`iswatchonly`、`script`、`hex`、`pubkeys`、`sigsrequired`、`pubkey`、`embedded`、`iscompressed`、`label`、`timestamp`、`hdkeypath`、`hdmasterkeyid`。 + +- `addresses` 欄位已從 `validateaddress` 和 `getaddressinfo` RPC 方法中移除。此欄位令人困惑，因為它使用 P2PKH 地址引用公鑰。客戶端應使用 `embedded.address` 欄位用於 P2SH 或 P2WSH 包裝的地址，並使用 `pubkeys` 用於檢查 multisig 參與者。 + +REST 變更 +------------ + +- 添加了新的 `/rest/blockhashbyheight/` 端點，用於根據當前最佳區塊鏈中區塊的高度（它在創世區塊之後的區塊數）獲取區塊的雜湊。 + +圖形使用者介面 (GUI) +------------------------------ + +- 在現有的檔案、設定和說明選單旁添加了新的視窗選單。從其他選單中開啟新視窗的幾個項目已移至此新視窗選單。 + +- 在發送標籤中，「僅支付所需費用」的核取方塊已被移除。相反，使用者可以簡單地將自訂費率欄位中的值一直降低到節點設定的最小轉發費用。 + +- 在概覽標籤中，如果錢包是使用 `createwallet` RPC 建立的並且 `disable_private_keys` 參數設定為 true，則僅觀察餘額將是顯示的唯一餘額。 + +- 如果使用大於 10.11 的 macosx 最小版本編譯（使用 CXXFLAGS="-mmacosx-version-min=10.11" CFLAGS="-mmacosx-version-min=10.11" 設定部署 sdk 版本），則 macOS 上不再提供啟動時啟動選項。 + +工具 +----- + +- 現在與 Bitcoin Core 的其他可執行檔一起發布新的 `bitcoin-wallet` 工具。無需使用任何 RPC，此工具目前可以建立新的錢包檔案或顯示有關現有錢包的一些基本資訊，例如錢包是否已加密、是否使用 HD 種子、包含多少交易以及有多少通訊錄條目。 + +計劃變更 +=============== + +本節描述可能影響其他比特幣軟體和服務的 Bitcoin Core 計劃變更。 + +- 自 0.16.0 版本以來，Bitcoin Core 的內建錢包在使用者想要接收付款時預設生成 P2SH 包裝的 segwit 地址。這些地址與所有廣泛使用的軟體向後相容。從 Bitcoin Core 0.20 開始（預計在 0.18 之後約一年），Bitcoin Core 將預設為提供額外費用節省和其他好處的原生 segwit 地址 (bech32)。目前，許多錢包和服務已經支援發送到 bech32 地址，如果 Bitcoin Core 專案看到足夠的額外採用，它將在 Bitcoin Core 0.19（大約 2019 年 11 月）中改為預設為 bech32 接收地址。如果使用者在 GUI 或透過 RPC 請求，將繼續提供 P2SH 包裝的 segwit 地址，不想更新的任何人都可以設定其預設地址類型。（同樣，希望現在更改預設值的先鋒使用者可以在 0.16.0 及以上的任何 Bitcoin Core 版本中設定 `addresstype=bech32` 設定選項。） + +棄用的 P2P 訊息 +----------------------- + +- BIP 61 拒絕訊息現已棄用。拒絕訊息在 P2P 網路上沒有使用案例，大多數網路節點僅記錄它們以進行除錯。此外，它們會增加頻寬，並且可能對隱私和安全性有害。自 v0.17 以來，可以使用 `-enablebip61=0` 選項停用 BIP 61 訊息。BIP 61 訊息將在未來版本中預設停用，然後再完全移除。 + +低階變更 +================= + +本節描述主要對測試有用的 RPC 變更，大多與生產無關。為了完整性而提及這些變更。 + +RPC +--- + +- `submitblock` RPC 以前在第一次處理被拒絕的區塊時返回該區塊無效的原因，但在後續處理同一區塊時返回通用的「duplicate」拒絕訊息。它現在始終返回拒絕無效區塊的根本原因，並且僅對已接受的有效區塊返回「duplicate」。 + +- 新的 `submitheader` RPC 允許獨立於其區塊提交區塊標頭。這可能僅對測試有用。 + +- `signrawtransactionwithkey` 和 `signrawtransactionwithwallet` RPC 已修改，以便它們也可選擇性地接受 `witnessScript`，在 P2WSH 或 P2SH-P2WSH 輸出的情況下的見證腳本。這與對 `listunspent` 的變更相容。 + +- 對於 `walletprocesspsbt` 和 `walletcreatefundedpsbt` RPC，如果 `bip32derivs` 參數設定為 true，但公鑰的金鑰中繼資料尚未更新，則該金鑰將具有派生路徑，就像它只是一個獨立金鑰一樣（即沒有派生路徑，其主指紋是它自己）。 + +設定 +------------- + +- `-usehd` 設定選項在 0.16 版本中被移除。從該版本開始，建立的所有新錢包都是分層確定性錢包。此版本使指定 `-usehd` 成為無效的設定選項。 + +網路 +------- + +- 此版本允許您的節點因行為不當（例如發送無效資料）而自動斷開連線的對等節點重新連線到您的節點，如果您有未使用的傳入連線槽。如果您的槽已滿，行為不當的節點將被斷開連線以為沒有問題歷史的節點騰出空間（除非行為不當的節點以某種其他方式幫助您的節點，例如透過連線到您沒有許多其他對等節點的網際網路部分）。以前，Bitcoin Core 會在一段時間內（預設為 1 天）封禁行為不當對等節點的 IP 地址；攻擊者很容易透過使用多個 IP 地址來規避這一點。如果您手動封禁對等節點，例如透過使用 `setban` RPC，仍將拒絕來自該對等節點的所有連線。 + +錢包 +------- + +- 第一次 HD 種子可用時，金鑰中繼資料將需要升級。對於未加密的錢包，這將在載入錢包時發生。對於加密的錢包，這將在第一次解鎖錢包時發生。 + +- 新加密的錢包將不再需要重新啟動軟體。相反，此類錢包將被完全卸載並重新載入以達到相同的效果。 + +- Bitcoin Core 的子專案現在提供硬體錢包互動 (HWI) 腳本，允許命令列使用者將多個流行的硬體金鑰管理裝置與 Bitcoin Core 一起使用。詳情請參閱他們的[專案頁面](https://github.com/bitcoin-core/HWI#readme)。 + +安全性 +-------- + +- 此版本將隨機數生成器 (RNG) 從 OpenSSL 更改為 Bitcoin Core 自己的實作，儘管 Bitcoin Core 收集的熵被送出到 OpenSSL，然後在程式需要強隨機性時讀回。這使 Bitcoin Core 更接近不再需要依賴 OpenSSL，這種依賴性過去曾導致安全問題。新實作從多個來源收集熵，包括從支援 rdseed CPU 指令的硬體。 + +特定平台的變更 +-------------------------------- + +- 在 macOS 上，Bitcoin Core 現在在初始區塊鏈下載期間、從當前鏈尖落後超過 100 個區塊時或重新索引鏈資料時選擇退出應用程式 CPU 節流（「app nap」）。這有助於防止這些操作花費過長時間，因為作業系統正在嘗試節省電力。 + +0.18.0 變更日誌 +================= + +完整的變更日誌包含超過 500 個 PR。由於篇幅限制，此處僅列出主要類別的摘要。完整清單請參閱原始版本說明。 + +### 共識、挖礦、區塊和交易處理、P2P 協定和網路程式碼、錢包、RPC 和其他 API、GUI、建置系統、測試和 QA、平台支援等 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的超過 150 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/projects/p/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2019-08-09-release-0.18.1.md b/_posts/zh_TW/releases/2019-08-09-release-0.18.1.md new file mode 100644 index 000000000..b53685c02 --- /dev/null +++ b/_posts/zh_TW/releases/2019-08-09-release-0.18.1.md @@ -0,0 +1,132 @@ +--- +title: Bitcoin Core 0.18.1 +id: zh_tw-release-0.18.1 +name: release-0.18.1 +permalink: /zh_TW/releases/0.18.1/ +excerpt: Bitcoin Core 0.18.1 版本現已發布 +date: 2018-08-09 +type: releases +layout: page +lang: zh_TW + +release: [0, 18, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:c3ba0cfee3ef8413098ac5e81db08a2670e9da8c&dn=bitcoin-core-0.18.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 0.18.1 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此小版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +第一次執行版本 0.15.0 或更新版本時，您的 chainstate 資料庫將被轉換為新格式，這將花費幾分鐘到半小時不等的時間，取決於您機器的速度。 + +請注意，區塊資料庫格式在版本 0.8.0 中也有變更，並且從 0.8 之前的版本升級到 0.15.0 或更新版本沒有自動升級程式碼。不支援從 0.7.x 及更早版本直接升級而不重新下載區塊鏈。然而，如往常一樣，仍然支援舊版本的錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.10+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。不建議在不受支援的系統上使用 Bitcoin Core。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +從 0.17.0 開始，不再支援 macOS 10.10 之前的版本。0.17.0 使用 Qt 5.9.x 建置，該版本不支援 macOS 10.10 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +已知錯誤 +============ + +錢包 GUI +---------- + +對於同時 (1) 啟用幣控制功能，以及 (2) 同時使用多個載入錢包的進階使用者：使用下拉選單切換錢包時，幣控制輸入選擇對話方塊可能會錯誤地保留錯誤錢包狀態。目前建議不要在載入多個錢包時使用幣控制功能。 + +0.18.1 變更日誌 +================= + +### P2P 協定和網路程式碼 +- #15990 Add tests and documentation for blocksonly (MarcoFalke) +- #16021 Avoid logging transaction decode errors to stderr (MarcoFalke) +- #16405 fix: tor: Call `event_base_loopbreak` from the event's callback (promag) +- #16412 Make poll in InterruptibleRecv only filter for POLLIN events (tecnovert) + +### 錢包 +- #15913 Add -ignorepartialspends to list of ignored wallet options (luke-jr) + +### RPC 和其他 API +- #15991 Bugfix: fix pruneblockchain returned prune height (jonasschnelli) +- #15899 Document iswitness flag and fix bug in converttopsbt (MarcoFalke) +- #16026 Ensure that uncompressed public keys in a multisig always returns a legacy address (achow101) +- #14039 Disallow extended encoding for non-witness transactions (sipa) +- #16210 add 2nd arg to signrawtransactionwithkey examples (dooglus) +- #16250 signrawtransactionwithkey: report error when missing redeemScript/witnessScript (ajtowns) + +### GUI +- #16044 fix the bug of OPEN CONFIGURATION FILE on Mac (shannon1916) +- #15957 Show "No wallets available" in open menu instead of nothing (meshcollider) +- #16118 Enable open wallet menu on setWalletController (promag) +- #16135 Set progressDialog to nullptr (promag) +- #16231 Fix open wallet menu initialization order (promag) +- #16254 Set `AA_EnableHighDpiScaling` attribute early (hebasto) +- #16122 Enable console line edit on setClientModel (promag) +- #16348 Assert QMetaObject::invokeMethod result (promag) + +### 建置系統 +- #15985 Add test for GCC bug 90348 (sipa) +- #15947 Install bitcoin-wallet manpage (domob1812) +- #15983 build with -fstack-reuse=none (MarcoFalke) + +### 測試和 QA +- #15826 Pure python EC (sipa) +- #15893 Add test for superfluous witness record in deserialization (instagibbs) +- #14818 Bugfix: test/functional/rpc_psbt: Remove check for specific error message that depends on uncertain assumptions (luke-jr) +- #15831 Add test that addmultisigaddress fails for watchonly addresses (MarcoFalke) + +### 文件 +- #15890 Remove text about txes always relayed from -whitelist (harding) + +### Miscellaneous +- #16095 Catch by reference not value in wallettool (kristapsk) +- #16205 Replace fprintf with tfm::format (MarcoFalke) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- Anthony Towns +- Chris Moore +- Daniel Kraft +- David A. Harding +- fanquake +- Gregory Sanders +- Hennadii Stepanov +- John Newbery +- Jonas Schnelli +- João Barbosa +- Kristaps Kaupe +- Luke Dashjr +- MarcoFalke +- MeshCollider +- Pieter Wuille +- shannon1916 +- tecnovert +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2020-03-09-release-0.19.1.md b/_posts/zh_TW/releases/2020-03-09-release-0.19.1.md new file mode 100644 index 000000000..375498ca3 --- /dev/null +++ b/_posts/zh_TW/releases/2020-03-09-release-0.19.1.md @@ -0,0 +1,125 @@ +--- +title: Bitcoin Core 0.19.1 +id: zh_tw-release-0.19.1 +name: release-0.19.1 +permalink: /zh_TW/releases/0.19.1/ +excerpt: Bitcoin Core 0.19.1 版本現已發布 +date: 2020-03-09 +type: releases +layout: page +lang: zh_TW + +release: [0, 19, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:8b6ad1da5bbb24656234efc2370abc14781a6f83&dn=bitcoin-core-0.19.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.19.1 版本說明 +=============================== + +Bitcoin Core 0.19.1 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（對於舊版本可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.10+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。不建議在不受支援的系統上使用 Bitcoin Core。 + +Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。 + +從 Bitcoin Core 0.17.0 開始，不再支援 macOS 10.10 之前的版本，因為 Bitcoin Core 現在使用需要 macOS 10.10+ 的 Qt 5.9.x 建置。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +除了先前支援的 CPU 平台外，此版本的預編譯發行版為 RISC-V 平台提供二進位檔案。 + +0.19.1 變更日誌 +================= + +### 錢包 + +- #17643 Fix origfee return for bumpfee with feerate arg (instagibbs) +- #16963 Fix `unique_ptr` usage in boost::signals2 (promag) +- #17258 Fix issue with conflicted mempool tx in listsinceblock (adamjonas, mchrostowski) +- #17924 Bug: IsUsedDestination shouldn't use key id as script id for ScriptHash (instagibbs) +- #17621 IsUsedDestination should count any known single-key address (instagibbs) +- #17843 Reset reused transactions cache (fjahr) + +### RPC 和其他 API + +- #17687 cli: Fix fatal leveldb error when specifying -blockfilterindex=basic twice (brakmic) +- #17728 require second argument only for scantxoutset start action (achow101) +- #17445 zmq: Fix due to invalid argument and multiple notifiers (promag) +- #17524 psbt: handle unspendable psbts (achow101) +- #17156 psbt: check that various indexes and amounts are within bounds (achow101) + +### GUI + +- #17427 Fix missing qRegisterMetaType for `size_t` (hebasto) +- #17695 disable File-\>CreateWallet during startup (fanquake) +- #17634 Fix comparison function signature (hebasto) +- #18062 Fix unintialized WalletView::progressDialog (promag) + +### 測試和 QA + +- #17416 Appveyor improvement - text file for vcpkg package list (sipsorcery) +- #17488 fix "bitcoind already running" warnings on macOS (fanquake) +- #17980 add missing #include to fix compiler errors (kallewoof) + +### 平台支援 + +- #17736 Update msvc build for Visual Studio 2019 v16.4 (sipsorcery) +- #17364 Updates to appveyor config for VS2019 and Qt5.9.8 + msvc project fixes (sipsorcery) +- #17887 bug-fix macos: give free bytes to `F_PREALLOCATE` (kallewoof) + +### Miscellaneous + +- #17897 init: Stop indexes on shutdown after ChainStateFlushed callback (jimpo) +- #17450 util: Add missing headers to util/fees.cpp (hebasto) +- #17654 Unbreak build with Boost 1.72.0 (jbeich) +- #17857 scripts: Fix symbol-check & security-check argument passing (fanquake) +- #17762 Log to net category for exceptions in ProcessMessages (laanwj) +- #18100 Update univalue subtree (MarcoFalke) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Aaron Clauson +- Adam Jonas +- Andrew Chow +- Fabian Jahr +- fanquake +- Gregory Sanders +- Harris +- Hennadii Stepanov +- Jan Beich +- Jim Posen +- João Barbosa +- Karl-Johan Alm +- Luke Dashjr +- MarcoFalke +- Michael Chrostowski +- Russell Yanofsky +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2020-06-03-release-0.20.0.md b/_posts/zh_TW/releases/2020-06-03-release-0.20.0.md new file mode 100644 index 000000000..9f4b5b844 --- /dev/null +++ b/_posts/zh_TW/releases/2020-06-03-release-0.20.0.md @@ -0,0 +1,215 @@ +--- +title: Bitcoin Core 0.20.0 +id: zh_tw-release-0.20.0 +name: release-0.20.0 +permalink: /zh_TW/releases/0.20.0/ +excerpt: Bitcoin Core 0.20.0 版本現已發布 +date: 2020-06-03 +type: releases +layout: page +lang: zh_TW + +release: [0, 20, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:1845a0c66b6a728e183b9bd8c5d8c1611dddaaa3&dn=bitcoin-core-0.20.0&tr=https%3A%2F%2Fopenbittorrent.com%2F&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.20.0 版本說明 +==================== + +Bitcoin Core 0.20.0 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.12+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 0.20.0 開始，不再支援 macOS 10.12 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +已知錯誤 +========== + +生成原始碼發布（「tarball」）的過程已變更，以使其更完整，但是，此版本存在一些回歸： + +- 生成的 `configure` 腳本目前遺失，您需要安裝 autotools 並執行 `./autogen.sh`，然後才能執行 `./configure`。這與從 git 檢出時相同。 + +- 不要簡單地執行 `make`，您應該改為執行 `BITCOIN_GENBUILD_NO_GIT=1 make`。 + +重要變更 +=============== + +P2P 和網路變更 +----------------------- + +#### 從 Bitcoin Core 移除 BIP61 拒絕網路訊息 + +啟用 BIP61 的 `-enablebip61` 命令列選項已被移除。(#17004) + +此功能自 Bitcoin Core 0.18.0 版本以來預設已停用。網路上的節點通常不能被信任發送有效訊息（包括拒絕訊息），因此這應該只在連線到受信任的節點時使用。如果您依賴此移除的功能，請使用下面建議的替代方案： + +- Bitcoin P2P 網路協定的測試或除錯應透過檢查最新版本的 Bitcoin Core 產生的日誌訊息來完成。Bitcoin Core 將除錯訊息（`-debug=`）記錄到串流（`-printtoconsole`）或檔案（`-debuglogfile=`）。 + +- 測試區塊的有效性可以透過特定的 RPC 實現： + + - `submitblock` + + - 具有 `'mode'` 設定為 `'proposal'` 的 `getblocktemplate`，用於具有潛在無效 POW 的區塊 + +- 測試交易的有效性可以透過特定的 RPC 實現： + + - `sendrawtransaction` + + - `testmempoolaccept` + +- 錢包不應假設交易已傳播到網路，僅因為沒有拒絕訊息。相反，應監聽網路上其他對等節點公告的交易。錢包不應假設缺少拒絕訊息意味著交易支付了適當的費用。相反，應使用費用估算設定費用，並使用 replace-by-fee 在交易未在所需時間內確認時增加交易費用。 + +移除 BIP61 拒絕訊息支援還有以下次要的 RPC 和日誌影響： + +- 當交易未被接受到 mempool 時，`testmempoolaccept` 和 `sendrawtransaction` 不再返回 P2P 拒絕代碼。它們仍然返回口頭拒絕原因。 + +- 以前在交易未被接受到 mempool 時報告拒絕代碼的日誌訊息現在不再報告拒絕代碼。仍然報告拒絕原因。 + +更新的 RPC +------------ + +- 接受描述符的 RPC 現在接受新的 `sortedmulti(...)` 描述符類型，該類型支援多重簽名腳本，其中公鑰在結果腳本中按字典順序排序。(#17056) + +- `walletprocesspsbt` 和 `walletcreatefundedpsbt` RPC 現在預設包含我們知道的公鑰的 BIP32 派生路徑。這可以透過將 `bip32derivs` 參數設定為 `false` 來停用。(#17264) + +- `bumpfee` RPC 的參數 `totalFee`（在 0.19 中已棄用）已被移除。(#18312) + +- `bumpfee` RPC 在與停用私鑰的錢包一起使用時將返回 PSBT。(#16373) + +- `getpeerinfo` RPC 現在包括一個 `mapped_as` 欄位，以指示用於多樣化對等節點選擇的映射自治系統。請參閱下面_新設定_中描述的 `-asmap` 設定選項。(#16702) + +- `createmultisig` 和 `addmultisigaddress` RPC 現在為新建立的地址返回輸出腳本描述符。(#18032) + +建置系統 +------------ + +- Bitcoin Core 不再使用 OpenSSL。(#17265) + +- BIP70 支援已從 Bitcoin Core 完全移除。`--enable-bip70` 選項仍然存在，但它將在設定期間拋出錯誤。(#17165) + +- glibc 2.17 或更高版本現在是執行發布二進位檔案所必需的。這保持了與 RHEL 7、CentOS 7、Debian 8 和 Ubuntu 14.04 LTS 的相容性。(#17538) + +- gitian 建置提供的原始碼檔案不再包含任何 autotools 工件。因此，要從此類原始碼建置，使用者應從解壓的檔案的根目錄執行 `./autogen.sh` 腳本。這意味著 `autotools` 和其他所需套件已安裝在使用者的系統上。(#18331) + +新設定 +------------ + +- 新的 `rpcwhitelist` 和 `rpcwhitelistdefault` 設定參數允許授予某些 RPC 使用者僅對某些 RPC 呼叫的權限。(#12763) + +- 已新增一個新的 `-asmap` 設定選項，透過將 IP 地址映射到自治系統編號（ASN），然後限制對任何單個 ASN 的連線數量，來多樣化節點的網路連線。請參閱 issue #16599、PR #16702 和 `bitcoind help` 以獲取更多資訊。此選項是實驗性的，可能會在未來版本中移除或破壞性變更，因此 IP 地址的傳統 /16 前綴映射仍然是預設設定。(#16702) + +更新的設定 +---------------- + +- Bitcoin Core 啟動時設定的所有自訂設定現在都會寫入 `debug.log` 檔案以協助疑難排解。(#16115) + +- 透過 `bootstrap.dat` 檔案在啟動時匯入區塊不再預設發生。現在必須使用 `-loadblock=` 指定該檔案。(#17044) + +- `-debug=db` 日誌類別已重新命名為 `-debug=walletdb`，以將其與 `coindb` 區分開來。`-debug=db` 選項已被棄用，並將在下一個主要版本中移除。(#17410) + +- `-walletnotify` 設定參數現在將在其參數中將任何 `%w` 替換為生成通知的錢包名稱。Windows 不支援此功能。(#13339) + +移除的設定 +---------------- + +- `-whitelistforcerelay` 設定參數已被移除，因為發現它在 0.13 版本中變得無效，實際上已經有近四年沒有受到支援。(#17985) + +GUI 變更 +----------- + +- macOS 上的「在系統登入時啟動 Bitcoin Core」選項已被移除。(#17567) + +- 在對等節點視窗中，對等節點的詳細資訊現在顯示一個 `Mapped AS` 欄位，以指示用於多樣化對等節點選擇的映射自治系統。請參閱上面_新設定_中的 `-asmap` 設定選項。(#18402) + +- 0.18 版本說明中[公告](https://bitcoincore.org/zh_TW/releases/0.18.0/#wallet-gui)的「已知錯誤」已修復。該問題影響了同時使用多個 Bitcoin Core 錢包和 GUI 幣控制功能的任何人。(#18894) + +- 對於僅觀察錢包，在發送螢幕中建立新交易或在交易螢幕中提升現有交易的費用將自動將部分簽名的比特幣交易（PSBT）複製到系統剪貼簿。然後可以將其粘貼到外部程式（如 [HWI](https://github.com/bitcoin-core/HWI)）進行簽名。未來版本的 Bitcoin Core 應支援用於最終化和廣播 PSBT 的 GUI 選項，但目前可以使用除錯控制台與 `finalizepsbt` 和 `sendrawtransaction` RPC。(#16944, #17492) + +錢包 +------ + +- 錢包現在預設在使用 RPC 時使用 bech32 地址，並建立原生 segwit 找零輸出。(#16884) + +- 輸出信任的計算方式已修復，這會影響已確認/未確認餘額狀態和幣選擇。(#16766) + +- `gettransaction`、`listtransactions` 和 `listsinceblock` RPC 回應現在還包括包含錢包交易的區塊高度（如果有）。(#17437) + +- `getaddressinfo` RPC 的 `label` 欄位已被棄用（使用設定參數 `-deprecatedrpc=label` 為此版本重新啟用）。`labels` 欄位從返回 JSON 物件更改為返回標籤名稱的 JSON 陣列（使用設定參數 `-deprecatedrpc=labelspurpose` 為此版本重新啟用先前的行為）。使用已棄用的設定參數的向後相容性預計將在 0.21 版本中刪除。(#17585, #17578) + +文件變更 +--------------------- + +- Bitcoin Core 的自動生成的原始碼文件現在可在 https://doxygen.bitcoincore.org 獲得。(#17596) + +低階變更 +================= + +實用程式 +--------- + +- 與 `-getinfo` 參數一起使用的 `bitcoin-cli` 實用程式現在返回一個 `headers` 欄位，其中包含最佳標頭鏈上已下載區塊標頭的數量（類似於也返回的 `blocks` 欄位）和一個 `verificationprogress` 欄位，該欄位估計本地節點已同步了多少最佳區塊鏈。返回的資訊不再包括 `protocolversion`、`walletversion` 和 `keypoololdest` 欄位。(#17302, #17650) + +- `bitcoin-cli` 實用程式現在接受 `-stdinwalletpassphrase` 參數，該參數可在呼叫 `walletpassphrase` 和 `walletpassphrasechange` RPC 時使用，以從標準輸入讀取密碼而不將其回顯到終端，從而提高了對任何可以查看您螢幕的人的安全性。現有的 `-stdinrpcpass` 參數也已更新為不回顯密碼。(#13716) + +命令列 +------------ + +- 以主網/測試網/regtest 網路名稱為前綴的命令列選項（如 `-main.port=8333` `-test.server=1`）以前是允許的但被忽略。現在它們在啟動時觸發「Invalid parameter」錯誤。(#17482) + +新的 RPC +-------- + +- `dumptxoutset` RPC 輸出當前 UTXO 集的序列化快照。在 `contrib/devtools` 目錄中提供了一個腳本，用於在特定區塊高度生成 UTXO 集的快照。(#16899) + +- `generatetodescriptor` RPC 允許使用 regtest 模式的測試人員生成支付任意輸出腳本描述符的區塊。(#16943) + +更新的 RPC +------------ + +- `verifychain` RPC 預設值現在是靜態的，而不是依賴於命令列選項或設定檔（`-checklevel` 和 `-checkblocks`）。使用者可以在不想依賴預設值時明確傳遞 RPC 參數。(#18541) + +- `getblockchaininfo` RPC 的 `verificationprogress` 欄位將不再報告高於 1 的值。以前它偶爾會報告鏈的驗證超過 100%。(#17328) + +測試 +----- + +- 如果在測試網或 regtest 網路上執行，在設定檔中使用不合格的 `walletdir=path` 設定現在是錯誤的。設定現在需要限定為 `chain.walletdir=path` 或放置在適當的 `[chain]` 部分中。(#17447) + +- `-fallbackfee` 對主鏈預設為 0（停用），但對測試鏈預設為 0.0002。現在對所有鏈預設為 0。測試網和 regtest 使用者如果沒有設定它並希望它像以前一樣繼續工作，則必須在其設定中新增 `fallbackfee=0.0002`。(#16524) + +建置系統 +------------ + +- 提供了使用 Android Native Development Kit (NDK) 建置的支援。(#16110) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人，總計超過 150 位貢獻者。完整清單請參閱原始版本說明。 + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2020-08-01-release-0.20.1.md b/_posts/zh_TW/releases/2020-08-01-release-0.20.1.md new file mode 100644 index 000000000..b856511f0 --- /dev/null +++ b/_posts/zh_TW/releases/2020-08-01-release-0.20.1.md @@ -0,0 +1,148 @@ +--- +title: Bitcoin Core 0.20.1 +id: zh_tw-release-0.20.1 +name: release-0.20.1 +permalink: /zh_TW/releases/0.20.1/ +excerpt: Bitcoin Core 0.20.1 版本現已發布 +date: 2020-08-01 +type: releases +layout: page +lang: zh_TW + +release: [0, 20, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:6e2c72d73d763465a725e3ae941b2b937edd0300&dn=bitcoin-core-0.20.1&tr=https%3A%2F%2Fopenbittorrent.com%2F&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.20.1 版本說明 +==================== + +Bitcoin Core 0.20.1 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.12+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 0.20.0 開始，不再支援 macOS 10.12 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +已知錯誤 +========== + +生成原始碼發布（「tarball」）的過程已變更，以使其更完整，但是，此版本存在一些回歸： + +- 生成的 `configure` 腳本目前遺失，您需要安裝 autotools 並執行 `./autogen.sh`，然後才能執行 `./configure`。這與從 git 檢出時相同。 + +- 不要簡單地執行 `make`，您應該改為執行 `BITCOIN_GENBUILD_NO_GIT=1 make`。 + +重要變更 +=============== + +關於行為不當對等節點的變更 +----------------------------------- + +行為不當的對等節點（例如向我們發送無效區塊）現在在日誌輸出中被稱為被阻止的節點，因為它們沒有（也不曾）被嚴格禁止：仍然允許來自它們的入站連線，但它們被優先驅逐。 + +此外，對被阻止地址的處理引入了一些額外的變更： + +- 阻止地址不會在 24 小時（或 `-bantime` 設定）後自動超時。根據來自其他對等節點的流量，阻止可能在不確定的時間超時。 + +- 阻止不會在重新啟動時持久化。 + +- 沒有方法列出被阻止的地址。它們不會由 `listbanned` RPC 返回。該 RPC 也不再報告 `ban_reason` 欄位，因為 `"manually added"` 是唯一剩餘的選項。 + +- 無法使用 `setban remove` RPC 命令移除阻止。如果您需要移除阻止，您可以透過停止-啟動節點來移除所有阻止。 + +通知變更 +-------------------- + +`-walletnotify` 通知現在會針對因與新區塊衝突而從 mempool 中移除的錢包交易發送。這些通知以前在 v0.19 版本之前發送，但自該版本以來已被破壞（錯誤 #18325）。 + +PSBT 變更 +------------ + +PSBT 將同時包含 segwit 輸入的非見證 utxo 和見證 utxo，以恢復與現在要求 segwit 輸入的完整先前交易的錢包軟體的相容性。仍然提供見證 utxo 以保持與依賴其存在來確定輸入是否為 segwit 的軟體的相容性。 + +0.20.1 變更日誌 +================= + +### 挖礦 + +- #19019 Fix GBT: Restore "!segwit" and "csv" to "rules" key (luke-jr) + +### P2P 協定和網路程式碼 + +- #19219 Replace automatic bans with discouragement filter (sipa) + +### 錢包 + +- #19300 Handle concurrent wallet loading (promag) +- #18982 Minimal fix to restore conflicted transaction notifications (ryanofsky) + +### RPC 和其他 API + +- #19524 Increment input value sum only once per UTXO in decodepsbt (fanquake) +- #19517 psbt: Increment input value sum only once per UTXO in decodepsbt (achow101) +- #19215 psbt: Include and allow both non_witness_utxo and witness_utxo for segwit inputs (achow101) + +### GUI + +- #19097 Add missing QPainterPath include (achow101) +- #19059 update Qt base translations for macOS release (fanquake) + +### 建置系統 + +- #19152 improve build OS configure output (skmcontrib) +- #19536 qt, build: Fix QFileDialog for static builds (hebasto) + +### 測試和 QA + +- #19444 Remove cached directories and associated script blocks from appveyor config (sipsorcery) +- #18640 appveyor: Remove clcache (MarcoFalke) + +### Miscellaneous + +- #19194 util: Don't reference errno when pthread fails (miztake) +- #18700 Fix locking on WSL using flock instead of fcntl (meshcollider) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Aaron Clauson +- Andrew Chow +- fanquake +- Hennadii Stepanov +- João Barbosa +- Luke Dashjr +- MarcoFalke +- MIZUTA Takeshi +- Pieter Wuille +- Russell Yanofsky +- sachinkm77 +- Samuel Dobson +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2021-01-14-release-0.21.0.md b/_posts/zh_TW/releases/2021-01-14-release-0.21.0.md new file mode 100644 index 000000000..b75d91993 --- /dev/null +++ b/_posts/zh_TW/releases/2021-01-14-release-0.21.0.md @@ -0,0 +1,435 @@ +--- +title: Bitcoin Core 0.21.0 +id: zh_tw-release-0.21.0 +name: release-0.21.0 +permalink: /zh_TW/releases/0.21.0/ +excerpt: Bitcoin Core 0.21.0 版本現已發布 +date: 2021-01-14 +type: releases +layout: page +lang: zh_TW + +release: [0, 21, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:665c5bdc6f49948e47c1098d91ace98bd216150e&dn=bitcoin-core-0.21.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.21.0 版本說明 +==================== + +Bitcoin Core 0.21.0 版本現已發布，可從以下位置下載： + +{% include download_release.html %} + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.12+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 0.20.0 開始，不再支援 macOS 10.12 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +節點的已知對等節點會以向後不相容的方式持久化到名為 `peers.dat` 的檔案中，以容納 Tor v3 和其他 BIP155 地址的儲存。這意味著如果檔案被 0.21.0 或更新版本修改，則舊版本將無法讀取它。在降級的情況下，這些舊版本將記錄錯誤訊息「Incorrect keysize in addrman deserialization」並繼續正常操作，就像檔案遺失一樣，建立一個新的空檔案。(#19954, #20284) + +重要變更 +=============== + +P2P 和網路變更 +----------------------- + +- mempool 現在追蹤透過錢包或 RPC 提交的交易是否已成功廣播。每 10-15 分鐘，節點將嘗試公告未廣播的交易，直到對等節點透過 `getdata` 訊息請求它或交易因其他原因從 mempool 中移除。節點不會追蹤使用 P2P 中繼提交到節點的交易的廣播狀態。此版本減少了透過 P2P 提交到執行錢包的節點的錢包交易的初始廣播保證。(#18038) + +- 對等節點已公告且我們考慮請求的交易集的大小已從 100000 減少到 5000（每個對等節點），當達到該限制時，將忽略進一步的公告。如果您需要傾倒（非常）大批次的交易，可以使用「relay」網路權限為受信任的對等節點進行例外處理。例如，對於 localhost，可以使用命令列選項 `-whitelist=relay@127.0.0.1` 啟用它。(#19988) + +- 此版本新增了對 Tor 版本 3 隱藏服務的支援，並使用 [BIP155](https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki) 將它們傳播到網路上的其他對等節點。Bitcoin Core 仍然完全支援版本 2 隱藏服務，但 Tor 網路將在未來幾個月開始[棄用](https://blog.torproject.org/v2-deprecation-timeline)它們。(#19954) + +- 透過設定 `-listenonion` 設定參數自動建立的 Tor onion 服務現在將建立為 Tor v3 服務而不是 Tor v2。用於 Tor v2 的私鑰（如果有）將在資料目錄（參見 `-datadir`）中的 `onion_private_key` 檔案中保持不變，如果不需要可以刪除。Bitcoin Core 將不再嘗試讀取它。Tor v3 服務的私鑰將儲存在名為 `onion_v3_private_key` 的檔案中。要使用已棄用的 Tor v2 服務（不建議），可以將 `onion_private_key` 複製到 `onion_v3_private_key`，例如 `cp -f onion_private_key onion_v3_private_key`。(#19954) + +- 客戶端在關閉時寫入一個檔案（`anchors.dat`），其中包含節點的兩個出站僅區塊中繼對等節點（所謂的「錨點」）的網路地址。下次節點啟動時，它會讀取此檔案並嘗試重新連線到這兩個相同的對等節點。這可以防止攻擊者使用節點重新啟動來觸發對等節點的完全變更，這是他們可以用作日蝕攻擊一部分的內容。(#17428) + +- 此版本新增了在啟用時使用 `-blockfilterindex=1 -peerblockfilters=1` 向網路上的對等節點提供 [BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) 緊湊過濾器的支援。(#16442) + +- 此版本除了現有的主網、測試網和 regtest 網路外，還新增了對 signet（[BIP325](https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki)）的支援。Signet 是集中控制的測試網路，使它們能夠比較舊的測試網更可預測的測試環境。維護一個公共 signet，可使用 `-signet` 選擇。也可以建立個人 signet。(#18267) + +- 此版本實作了 [BIP339](https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki) wtxid 中繼。協商後，交易使用其 wtxid 而不是 txid 公告。(#18044) + +- 此版本實作了提議的 Taproot 共識規則（[BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) 和 [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)），但沒有在主網上啟動。可以在 signet 上進行 Taproot 的實驗，其規則已經啟動。(#19553) + +更新的 RPC +------------ + +- `getpeerinfo` RPC 有一個新的 `network` 欄位，提供對等節點連線的網路類型（「ipv4」、「ipv6」或「onion」）。(#20002) + +- `getpeerinfo` RPC 現在有額外的 `last_block` 和 `last_transaction` 欄位，返回從每個對等節點收到的最後一個區塊和最後一個*有效*交易的 UNIX epoch 時間。(#19731) + +- `getnetworkinfo` 現在返回兩個新欄位 `connections_in` 和 `connections_out`，提供入站和出站對等連線的數量。這些新欄位是對現有 `connections` 欄位的補充，該欄位返回對等連線的總數。(#19405) + +- 公開的交易版本號現在被視為無符號 32 位元整數而不是有符號 32 位元整數。這與它們在共識邏輯中的處理相符。大於 2 的版本繼續為非標準（符合先前小於 1 或大於 2 為非標準的行為）。請注意，這包括 `joinpsbt` 命令，該命令透過選擇最高版本號來組合部分簽名的交易。(#16525) + +- `getmempoolinfo` 現在返回一個額外的 `unbroadcastcount` 欄位。mempool 追蹤本地提交的交易，直到對等節點確認其初始廣播。此欄位返回等待確認的交易計數。 + +- Mempool RPC（例如 `getmempoolentry` 和具有 `verbose=true` 的 `getrawmempool`）現在返回一個額外的 `unbroadcast` 欄位。這表示交易的初始廣播是否已被對等節點確認。`getmempoolancestors` 和 `getmempooldescendants` 也已更新。 + +- 除非使用設定選項 `-deprecatedrpc=banscore`，否則 `getpeerinfo` RPC 不再返回 `banscore` 欄位。`banscore` 欄位將在下一個主要版本中完全移除。(#19469) + +- 如果交易將通過驗證，`testmempoolaccept` RPC 將返回 `vsize` 和帶有 `base` 費用的 `fees` 物件。(#19940) + +- `getpeerinfo` RPC 現在返回一個 `connection_type` 欄位。這表示與對等節點建立的連線類型。它將返回六個選項之一。有關更多資訊，請參閱 `getpeerinfo` 說明文件。(#19725) + +- 預設情況下，`getpeerinfo` RPC 不再返回 `addnode` 欄位。此欄位將在下一個主要版本中完全移除。可以使用設定選項 `-deprecatedrpc=getpeerinfo_addnode` 存取它。但是，建議改用 `connection_type` 欄位（當 addnode 為 true 時，它將返回 `manual`）。(#19725) + +- 預設情況下，`getpeerinfo` RPC 不再返回 `whitelisted` 欄位。此欄位將在下一個主要版本中完全移除。可以使用設定選項 `-deprecatedrpc=getpeerinfo_whitelisted` 存取它。但是，建議改用 `permissions` 欄位來了解是否已授予對等節點特定權限。(#19770) + +- 如果手動選擇的輸入不足以支付輸出和費用，`walletcreatefundedpsbt` RPC 呼叫現在將失敗並顯示 `Insufficient funds`。可以透過新的 `add_inputs` 選項自動新增額外的輸入。(#16377) + +- `fundrawtransaction` RPC 現在支援 `add_inputs` 選項，當為 `false` 時，如果需要，將阻止新增更多輸入，因此 RPC 失敗。 + +與錢包或 GUI 相關的 RPC 變更可以在下面的 GUI 或錢包部分找到。 + +新的 RPC +-------- + +- `getindexinfo` RPC 返回節點的主動執行索引，包括它們的當前同步狀態和高度。它還接受 `index_name` 以指定僅返回該索引的狀態。(#19550) + +建置系統 +------------ + +更新的設定 +---------------- + +- 現在可以多次指定相同的 ZeroMQ 通知（例如 `-zmqpubhashtx=address`），以將相同的通知發布到不同的 ZeroMQ socket。(#18309) + +- `-banscore` 設定選項已被移除，該選項修改了斷開和阻止行為不當對等節點的預設閾值，這是 0.20.1 版本和本版本對處理行為不當對等節點的變更的一部分。有關詳細資訊，請參閱 0.20.1 版本說明中的「關於行為不當對等節點的變更」。(#19464) + +- `-debug=db` 日誌類別在 0.20 中已棄用，並替換為 `-debug=walletdb` 以將其與 `coindb` 區分開來，現已移除。(#19202) + +- 已從 `noban` 權限中提取 `download` 權限。為了相容性，`noban` 暗示 `download` 權限，但這可能在未來版本中變更。有關更多詳細資訊，請參閱受影響設定 `-whitebind` 和 `-whitelist` 的說明。(#19191) + +- 不再接受在 0 位元之後包含 1 位元的網路遮罩（1 位元在左側不連續，例如 255.0.255.255）。根據 RFC 4632，它們是無效的。網路遮罩用於 `-rpcallowip` 和 `-whitelist` 設定選項以及 `setban` RPC。(#19628) + +- `-blocksonly` 設定現在完全停用費用估算。(#18766) + +與錢包或 GUI 相關的設定變更可以在下面的 GUI 或錢包部分找到。 + +工具和實用程式 +------------------- + +- 新的 `bitcoin-cli -netinfo` 命令提供網路對等連線儀表板，以人類可讀的格式顯示來自 `getpeerinfo` 和 `getnetworkinfo` RPC 的資料。可以傳遞從 `0` 到 `4` 的可選整數參數，以查看不斷增加的詳細程度。(#19643) + +- 新的 `bitcoin-cli -generate` 命令，相當於 RPC `generatenewaddress` 後跟 `generatetoaddress`，可以為命令列測試目的生成區塊。這是先前 `generate` RPC 的客戶端版本。詳情請參閱說明。(#19133) + +- 當載入多個錢包時（例如在多錢包模式下），且未使用 `-rpcwallet` 指定錢包時，`bitcoin-cli -getinfo` 命令現在為每個載入的錢包顯示錢包名稱和餘額。(#18594) + +- `bitcoin-cli -getinfo` 的 `connections` 欄位現在擴充為返回具有對等連線的 `in`、`out` 和 `total` 數量的 JSON 物件。它以前返回對等連線總數的單個整數值。(#19405) + +新設定 +------------ + +- `startupnotify` 選項用於指定 Bitcoin Core 完成其啟動序列後要執行的命令。(#15367) + +錢包 +------ + +- `getaddressinfo` RPC 已刪除兩個棄用的向後相容性，如 0.20 版本說明中所通知。已刪除棄用的 `label` 欄位以及棄用的返回包含 `name` 和 `purpose` 鍵值對的 JSON 物件的 `labels` 行為。自 0.20 以來，`labels` 欄位返回標籤名稱的 JSON 陣列。(#19200) + +- 為了改善錢包隱私，錢包重新廣播嘗試的頻率從大約每 15 分鐘一次減少到每 12-36 小時一次。為了保持類似水平的錢包交易初始廣播保證，mempool 將這些交易作為新引入的未廣播集的一部分進行追蹤。有關未廣播集的更多資訊，請參閱「P2P 和網路變更」部分。(#18038) + +- `sendtoaddress` 和 `sendmany` RPC 接受可選的 `verbose=True` 參數，也返回有關已發送交易的費用原因。(#19501) + +- 即使密鑰池為空，錢包也可以建立沒有找零的交易。以前會失敗。(#17219) + +- `-salvagewallet` 啟動選項已被移除。新的 `salvage` 命令已新增到 `bitcoin-wallet` 工具，該工具執行 `-salvagewallet` 所做的搶救操作。(#18918) + +- 已新增一個新的設定標誌 `-maxapsfee`，它設定允許的最大避免部分花費（APS）費用。它預設為 0（即使用和不使用 APS 的費用相同）。將其設定為 -1 將停用 APS，除非設定了 `-avoidpartialspends`。(#14582) + +- 如果這不會導致費用與非 APS 變體相比有所不同，錢包現在預設會避免部分花費（APS）。允許的費用閾值可以使用新的 `-maxapsfee` 設定選項進行調整。(#14582) + +- `createwallet`、`loadwallet` 和 `unloadwallet` RPC 現在接受 `load_on_startup` 選項來修改設定清單。除非這些選項明確設定為 true 或 false，否則不會修改清單，因此 RPC 方法保持向後相容。(#15937) + +- 新增了一個新的 `send` RPC，其語法類似於 `walletcreatefundedpsbt`，包括對幣選擇和自訂費率的支援。`send` RPC 是實驗性的，可能會在後續版本中變更。(#16378) + +- `estimate_mode` 參數現在在 `bumpfee`、`fundrawtransaction`、`sendmany`、`sendtoaddress`、`send` 和 `walletcreatefundedpsbt` RPC 中不區分大小寫。(#11413) + +- `bumpfee` RPC 現在在選項中使用 `conf_target` 而不是 `confTarget`。(#11413) + +- 當使用 `lockUnspents` 參數時，`fundrawtransaction` 和 `walletcreatefundedpsbt` 現在除了自動選擇的幣外，還鎖定手動選擇的幣。請注意，鎖定的幣永遠不會用於自動幣選擇，但仍可以手動選擇。(#18244) + +- `-zapwallettxes` 啟動選項已被移除，其功能也已從錢包中移除。此選項最初旨在允許搶救受到可塑性攻擊影響的錢包。最近，它已被用於未發出 RBF 訊號的交易的費用提升。此功能已被放棄交易功能取代。(#19671) + +- 當沒有載入錢包但呼叫錢包 RPC 時的錯誤代碼已從 `-32601`（找不到方法）變更為 `-18`（找不到錢包）。(#20101) + +### 移除自動錢包建立 + +Bitcoin Core 將不再在啟動時自動建立新錢包。它將載入命令列上或 `bitcoin.conf` 或 `settings.json` 檔案中由 `-wallet` 選項指定的現有錢包。預設情況下，它還將載入頂層未命名（「」）錢包。但是，如果指定的錢包不存在，Bitcoin Core 現在只會記錄警告，而不是像以前的版本那樣使用新金鑰和地址建立新錢包。 + +新錢包可以透過 GUI（其具有更顯著的建立錢包選項）、透過 `bitcoin-cli createwallet` 或 `bitcoin-wallet create` 命令，或 `createwallet` RPC 建立。(#15454, #20186) + +### 實驗性描述符錢包 + +請注意，描述符錢包仍然是實驗性的，並非所有預期功能都可用。此外，可能存在一些錯誤，當前功能可能會在未來變更。錯誤和缺少的功能可以回報到[問題追蹤器](https://github.com/bitcoin/bitcoin/issues)。 + +0.21 引入了一種新型錢包 - 描述符錢包。描述符錢包使用輸出描述符儲存 scriptPubKey 資訊。這與傳統錢包結構相反，後者使用金鑰隱式生成 scriptPubKey 和地址。由於這種轉變為基於腳本而不是基於金鑰，傳統錢包執行的許多令人困惑的事情在描述符錢包中是不可能的。描述符錢包對腳本使用「mine」的定義比傳統錢包使用的定義更簡單、更直觀。描述符錢包還對僅觀察事物和匯入使用不同的語義。 + +由於描述符錢包是一種新型錢包，它們的引入不會影響現有錢包。已經擁有 Bitcoin Core 錢包的使用者可以像以前一樣繼續使用它，行為沒有任何變更。新建立的傳統錢包（仍然是預設錢包類型）將像以前版本的 Bitcoin Core 一樣運作。 + +描述符錢包和傳統錢包之間的差異主要限於非使用者面向的事物。它們旨在行為類似，除了如下所述的匯入/匯出和僅觀察功能。 + +#### 建立描述符錢包 + +描述符錢包不是預設的錢包類型。 + +在 GUI 中，已在建立錢包對話框中新增了一個複選框，以指示應建立描述符錢包。並且已將 `descriptors` 選項新增到 `createwallet` RPC。將 `descriptors` 設定為 `true` 將建立描述符錢包而不是傳統錢包。 + +如果未設定這些選項，則將建立傳統錢包。 + +#### `IsMine` 語義 + +`IsMine` 是指用於確定腳本是否屬於錢包的函數。這用於確定輸出是否屬於錢包。傳統錢包中的 `IsMine` 如果錢包能夠簽署花費具有該腳本的輸出的輸入，則返回 true。由於金鑰可以參與各種不同的腳本，這個 `IsMine` 定義可能導致許多意外的腳本被視為錢包的一部分。 + +使用描述符錢包，描述符明確指定錢包擁有的腳本集。由於描述符是確定性的且易於枚舉，使用者將確切知道錢包將考慮哪些腳本屬於它。此外，描述符錢包中 `IsMine` 的實作遠比傳統錢包簡單。值得注意的是，在傳統錢包中，`IsMine` 允許使用者取得一種類型的地址（例如 P2PKH），將其突變為另一種地址類型（例如 P2WPKH），錢包仍然會檢測發送到新地址類型的輸出，即使該地址未從錢包請求。描述符錢包不允許這樣做，只會觀察從錢包明確請求的地址。 + +這些對 `IsMine` 的變更將使推理錢包實際將觀察哪些腳本變得更容易。但是，對於絕大多數使用者來說，此變更在很大程度上是透明的，不會產生明顯的影響。 + +#### 匯入和匯出 + +在傳統錢包中，可以將原始腳本和金鑰匯入到錢包中。這些匯入的腳本和金鑰與錢包生成的金鑰分開處理。這使 `IsMine` 邏輯複雜化，因為它必須區分可花費和僅觀察。 + +描述符錢包以不同方式處理匯入腳本和金鑰。只能匯入完整的描述符。然後，這些描述符被新增到錢包中，就像它是錢包本身生成的描述符一樣。這簡化了 `IsMine` 邏輯，使其不再需要區分可花費和僅觀察。因此，描述符錢包的僅觀察模型也不同，並在下一節中進行了更詳細的描述。 + +要匯入到描述符錢包中，已新增了一個新的 `importdescriptors` RPC，該 RPC 使用類似於 `importmulti` 的語法。 + +由於傳統錢包和描述符錢包使用不同的機制來儲存和匯入腳本和金鑰，因此已為描述符錢包停用了現有的匯入 RPC。尚未新增用於描述符錢包的新匯出 RPC。 + +以下 RPC 已為描述符錢包停用： + +* `importprivkey` +* `importpubkey` +* `importaddress` +* `importwallet` +* `dumpprivkey` +* `dumpwallet` +* `importmulti` +* `addmultisigaddress` +* `sethdseed` + +#### 僅觀察錢包 + +傳統錢包包含私鑰和正在觀察的腳本。那些被觀察的腳本不會貢獻到您的正常餘額。為了查看僅觀察餘額並在交易中使用僅觀察事物，許多 RPC 新增了一個 `include_watchonly` 選項，允許使用者這樣做。但是，很容易忘記包含此選項。 + +描述符錢包移動到每個錢包的僅觀察模型。相反，整個錢包根據是否在停用私鑰的情況下建立而被視為僅觀察。這消除了在錢包本身內區分僅觀察事物和非僅觀察事物的需要。 + +這種變更確實有一個警告。如果具有私鑰*啟用*的描述符錢包具有沒有所有私鑰的多金鑰描述符（例如只有一個私鑰的 `multi(...)`），則錢包將無法簽署和廣播交易。此類錢包需要使用 PSBT 工作流程，但典型的 GUI 發送、`sendtoaddress` 等工作流程仍然可用，只是無法運作。 + +如果錢包同時包含單金鑰（例如 `wpkh(...)`）描述符和此類多金鑰描述符，則此問題會惡化，因為某些交易可以簽署和廣播，而其他交易則不能。這取決於哪些可用以及幣選擇演算法如何選擇輸入，某些交易僅包含單金鑰輸入，而其他交易將同時包含單金鑰和多金鑰輸入。但是，這不被視為受支援的用例；多重簽名應該在它們自己的錢包中，這些錢包還沒有描述符。雖然使用者現在無法匯出帶有私鑰的描述符，如前所述。 + +#### BIP 44/49/84 支援 + +使用描述符的變更改變了 Bitcoin Core 使用的預設派生路徑，以遵守 BIP 44/49/84。可以匯入具有不同派生路徑的描述符而不會出現問題。 + +#### SQLite 資料庫後端 + +描述符錢包對錢包檔案使用 SQLite 而不是傳統錢包中使用的 Berkeley DB。這將破壞對錢包操作的任何現有工具的相容性，但是，透過移動到描述符已經破壞了相容性。 + +### 錢包 RPC 變更 + +- `upgradewallet` RPC 替換 `-upgradewallet` 命令列選項。(#15761) + +- 如果費用設定高於 `-maxtxfee` 命令列設定，`settxfee` RPC 將失敗。錢包已經無法建立費用高於 `-maxtxfee` 的交易。(#18467) + +- 已在 `sendtoaddress`、`sendmany`、`fundrawtransaction` 和 `walletcreatefundedpsbt` RPC 以及實驗性的新 `send` RPC 中引入了新的 `fee_rate` 參數/選項，以 satoshis per vbyte (sat/vB) 計價。`fundrawtransaction` 和 `walletcreatefundedpsbt` 中的傳統 `feeRate` 選項仍然存在，用於以 BTC per 1,000 vbytes (BTC/kvB) 設定費率，但預計很快將被棄用以避免混淆。對於這些 RPC，費率錯誤訊息已從 BTC/kB 更新為 sat/vB，說明文件中的 BTC/kB 已更新為 BTC/kvB。`send` 和 `sendtoaddress` RPC 範例已更新，以幫助使用者建立具有明確費率的交易。(#20305, #11413) + +- `bumpfee` RPC `fee_rate` 選項已從 BTC/kvB 變更為 sat/vB，說明文件已更新。警告使用者這是一個破壞性的 API 變更，但它應該相對溫和：BTC/kvB 和 sat/vB 單位之間的巨大（100,000 倍）差異意味著以 BTC/kvB 而不是 sat/vB 錯誤計算的費率的交易應該會因為費率設定過低而引發錯誤。在最壞的情況下，交易可能以 1 sat/vB 發送，但由於當使用明確費率時預設啟動 Replace-by-Fee (BIP125 RBF)，因此可以提升交易費用。(#20305) + +GUI 變更 +----------- + +- 在 GUI 中建立或載入的錢包現在將在啟動時自動載入，因此不需要在下次啟動 Bitcoin Core 時手動重新載入。要在啟動時載入的錢包清單儲存在 `\/settings.json` 中，並增強了指定更多錢包載入的任何命令列或 `bitcoin.conf` `-wallet=` 設定。在 GUI 中卸載的錢包將從設定清單中移除，因此它們不會在下次啟動時自動載入。(#19754) + +- GUI 對等節點視窗不再顯示「Ban Score」欄位。這是 0.20.1 版本和本版本對處理行為不當對等節點的變更的一部分。有關詳細資訊，請參閱 0.20.1 版本說明中的「關於行為不當對等節點的變更」。(#19512) + +低階變更 +================= + +RPC +--- + +- 為了使 RPC `sendtoaddress` 與 `sendmany` 更一致，以下 `sendtoaddress` 錯誤代碼已從 `-4` 變更為 `-6`： + - Insufficient funds + - Fee estimation failed + - Transaction has too long of a mempool chain + +- `sendrawtransaction` 超過 `maxfeerate` 的錯誤代碼已從 `-26` 變更為 `-25`。錯誤字串已從「absurdly-high-fee」變更為「Fee exceeds maximum configured by user (e.g. -maxtxfee, maxfeerate).」`testmempoolaccept` RPC 返回 `max-fee-exceeded` 而不是 `absurdly-high-fee` 作為 `reject-reason`。(#19339) + +- 為了使錢包和 rawtransaction RPC 更一致，超過最大費率的錯誤訊息已變更為「Fee exceeds maximum configured by user (e.g. -maxtxfee, maxfeerate).」(#19339) + +測試 +----- + +- BIP 325 預設 signet 可以透過 `-chain=signet` 或 `-signet` 設定啟用。設定 `-signetchallenge` 和 `-signetseednode` 允許啟用自訂 signet。 + +- `generateblock` RPC 允許使用 regtest 模式的測試人員生成由自訂交易集組成的區塊。(#17693) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 10xcryptodev +- Aaron Clauson +- Aaron Hook +- Adam Jonas +- Adam Soltys +- Adam Stein +- Akio Nakamura +- Alex Willmer +- Amir Ghorbanian +- Amiti Uttarwar +- Andrew Chow +- Andrew Toth +- Anthony Fieroni +- Anthony Towns +- Antoine Poinsot +- Antoine Riard +- Ben Carman +- Ben Woosley +- Benoit Verret +- Brian Liotti +- Bushstar +- Calvin Kim +- Carl Dong +- Chris Abrams +- Chris L +- Christopher Coverdale +- codeShark149 +- Cory Fields +- Craig Andrews +- Damian Mee +- Daniel Kraft +- Danny Lee +- David Reikher +- DesWurstes +- Dhruv Mehta +- Duncan Dean +- Elichai Turkel +- Elliott Jin +- Emil Engler +- Ethan Heilman +- eugene +- Fabian Jahr +- fanquake +- Ferdinando M. Ametrano +- freenancial +- furszy +- Gillian Chu +- Gleb Naumenko +- Glenn Willen +- Gloria Zhao +- glowang +- gr0kchain +- Gregory Sanders +- grubles +- gzhao408 +- Harris +- Hennadii Stepanov +- Hugo Nguyen +- Igor Cota +- Ivan Metlushko +- Ivan Vershigora +- Jake Leventhal +- James O'Beirne +- Jeremy Rubin +- jgmorgan +- Jim Posen +- "jkcd" +- jmorgan +- John Newbery +- Johnson Lau +- Jon Atack +- Jonas Schnelli +- Jonathan Schoeller +- João Barbosa +- Justin Moon +- kanon +- Karl-Johan Alm +- Kiminuo +- Kristaps Kaupe +- lontivero +- Luke Dashjr +- Marcin Jachymiak +- MarcoFalke +- Martin Ankerl +- Martin Zumsande +- maskoficarus +- Matt Corallo +- Matthew Zipkin +- MeshCollider +- Miguel Herranz +- MIZUTA Takeshi +- mruddy +- Nadav Ivgi +- Neha Narula +- Nicolas Thumann +- Niklas Gögge +- Nima Yazdanmehr +- nsa +- nthumann +- Oliver Gugger +- pad +- pasta +- Peter Bushnell +- pierrenn +- Pieter Wuille +- practicalswift +- Prayank +- Raúl Martínez (RME) +- RandyMcMillan +- Rene Pickhardt +- Riccardo Masutti +- Robert +- Rod Vagg +- Roy Shao +- Russell Yanofsky +- Saahil Shangle +- sachinkm77 +- saibato +- Samuel Dobson +- sanket1729 +- Sebastian Falbesoner +- Seleme Topuz +- Sishir Giri +- Sjors Provoost +- skmcontrib +- Stepan Snigirev +- Stephan Oeste +- Suhas Daftuar +- t-bast +- Tom Harding +- Torhte Butler +- TrentZ +- Troy Giorshev +- tryphe +- Tyler Chambers +- U-Zyn Chua +- Vasil Dimov +- wiz +- Wladimir J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2021-05-01-release-0.21.1.md b/_posts/zh_TW/releases/2021-05-01-release-0.21.1.md new file mode 100644 index 000000000..864d75f40 --- /dev/null +++ b/_posts/zh_TW/releases/2021-05-01-release-0.21.1.md @@ -0,0 +1,159 @@ +--- +title: Bitcoin Core 0.21.1 +id: zh_tw-release-0.21.1 +name: release-0.21.1 +permalink: /zh_TW/releases/0.21.1/ +excerpt: Bitcoin Core 0.21.1 版本現已發布 +date: 2021-05-01 +type: releases +layout: page +lang: zh_TW + +release: [0, 21, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:205b0189271c50a02fe966491e15737a01f94e08&dn=bitcoin-core-0.21.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.21.1 版本說明 +==================== + +Bitcoin Core 0.21.1 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.12+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 0.20.0 開始，不再支援 macOS 10.12 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +重要變更 +=============== + +## Taproot 軟分叉 + +此版本包含 taproot 軟分叉（BIP341）的主網和測試網啟動參數，該軟分叉也新增了對 schnorr 簽名（BIP340）和 tapscript（BIP342）的支援。 + +如果啟動，這些改進將允許單一簽名腳本、多重簽名腳本和複雜合約的使用者都使用外觀相同的承諾，從而增強他們的隱私和所有比特幣的可替代性。花費者將享受更低的費用，並能夠以與單一簽名使用者相同的效率、低費用和大型匿名集來解決許多多重簽名腳本和複雜合約。Taproot 和 schnorr 還包括對全節點的效率改進，例如批次簽名驗證的能力。這些改進共同為未來可能進一步改善效率、隱私和可替代性的潛在升級奠定了基礎。 + +Taproot 的啟動使用 BIP9 versionbits 的變體進行管理，稱為 Speedy Trial（在 BIP341 中描述）。Taproot 的 versionbit 是位元 2，節點將在 2021 年 4 月 24 日 taproot 開始日期之後的第一個重新定位期間開始追蹤哪些區塊發出支援 taproot 的訊號。如果在 2021 年 8 月 11 日時間開始的第一個重新定位期間之前，2,016 個區塊重新定位期間（約兩週）內的 90% 區塊發出支援 taproot 的訊號，軟分叉將被鎖定，然後 taproot 將從區塊 709632（預計在 11 月初或中旬）開始啟動。 + +如果 taproot 未透過 Speedy Trial 啟動鎖定，預計將部署後續啟動機制，並進行變更以解決 Speedy Trial 方法失敗的原因。 + +此版本包括支付 taproot 地址的能力，儘管在 taproot 啟動之前對此類地址的支付並不安全。它還包括在啟動後中繼和挖礦 taproot 交易的能力。除了這兩個基本功能外，此版本不包含任何允許任何人直接使用 taproot 的程式碼。一旦確保 taproot 啟動，預計將在稍後的版本中將 taproot 相關功能新增到 Bitcoin Core 的錢包中。 + +鼓勵所有使用者、企業和礦工升級到此版本（或後續相容版本），除非他們反對啟動 taproot。如果 taproot 被鎖定，強烈建議在區塊 709632 之前升級，以幫助強制執行 taproot 的新規則並避免看到錯誤確認交易的不太可能情況。 + +想要啟動 Taproot 的礦工最好使用此版本來控制他們的訊號。一旦達到適當的開始時間，`getblocktemplate` RPC 結果將自動更新為發出訊號，並將繼續發出訊號直到超時發生或 taproot 啟動。或者，礦工可以隨時手動開始在位元 2 上發出訊號；如果 taproot 啟動，他們需要確保在區塊 709632 之前更新他們的節點，否則未升級的節點可能導致他們在無效鏈上挖礦。詳情請參閱 [versionbits FAQ](https://bitcoincore.org/zh_TW/2016/06/08/version-bits-miners-faq/)。 + + +有關 taproot 的更多資訊，請參閱以下資源： + +- 技術規範 + - [BIP340 secp256k1 的 Schnorr 簽名](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) + - [BIP341 Taproot: SegWit 版本 1 花費規則](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) + - [BIP342 Taproot 腳本的驗證](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) + +- 熱門文章： + - [Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin](https://bitcoinmagazine.com/technical/taproot-coming-what-it-and-how-it-will-benefit-bitcoin) + - [What do Schnorr Signatures Mean for Bitcoin?](https://academy.binance.com/en/articles/what-do-schnorr-signatures-mean-for-bitcoin) + - [The Schnorr Signature & Taproot Softfork Proposal](https://blog.bitmex.com/the-schnorr-signature-taproot-softfork-proposal/) + +- 開發歷史概述 + - [Taproot](https://bitcoinops.org/en/topics/taproot/) + - [Schnorr signatures](https://bitcoinops.org/en/topics/schnorr-signatures/) + - [Tapscript](https://bitcoinops.org/en/topics/tapscript/) + - [Soft fork activation](https://bitcoinops.org/en/topics/soft-fork-activation/) + +- 其他 + - [Questions and answers related to taproot](https://bitcoin.stackexchange.com/questions/tagged/taproot) + - [Taproot review](https://github.com/ajtowns/taproot-review) + +更新的 RPC +------------ + +- 由於實施了 [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)，所有接受地址的 RPC 在傳遞原生見證版本 1（或更高版本）時的行為都會改變。現在這些需要 Bech32m 編碼而不是 Bech32 編碼，並且 RPC 輸出中也將使用 Bech32m 編碼表示此類地址。在共識規則賦予版本 1 地址意義之前，不應為主網建立版本 1 地址（這將透過 [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) 實現）。一旦發生這種情況，預計將對它們使用 Bech32m，因此這不應影響任何生產系統，但可能會在此類地址已具有意義的其他網路（如 signet）上觀察到。 + +0.21.1 變更日誌 +================= + +### 共識 +- #21377 Speedy trial support for versionbits (ajtowns) +- #21686 Speedy trial activation parameters for Taproot (achow101) + +### P2P 協定和網路程式碼 +- #20852 allow CSubNet of non-IP networks (vasild) +- #21043 Avoid UBSan warning in ProcessMessage(…) (practicalswift) + +### 錢包 +- #21166 Introduce DeferredSignatureChecker and have SignatureExtractorClass subclass it (achow101) +- #21083 Avoid requesting fee rates multiple times during coin selection (achow101) + +### RPC 和其他 API +- #21201 Disallow sendtoaddress and sendmany when private keys disabled (achow101) + +### 建置系統 +- #21486 link against -lsocket if required for `*ifaddrs` (fanquake) +- #20983 Fix MSVC build after gui#176 (hebasto) + +### 測試和 QA +- #21380 Add fuzzing harness for versionbits (ajtowns) +- #20812 fuzz: Bump FuzzedDataProvider.h (MarcoFalke) +- #20740 fuzz: Update FuzzedDataProvider.h from upstream (LLVM) (practicalswift) +- #21446 Update vcpkg checkout commit (sipsorcery) +- #21397 fuzz: Bump FuzzedDataProvider.h (MarcoFalke) +- #21081 Fix the unreachable code at `feature_taproot` (brunoerg) +- #20562 Test that a fully signed tx given to signrawtx is unchanged (achow101) +- #21571 Make sure non-IP peers get discouraged and disconnected (vasild, MarcoFalke) +- #21489 fuzz: cleanups for versionbits fuzzer (ajtowns) + +### Miscellaneous +- #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses (sipa) + +### 文件 +- #21384 add signet to bitcoin.conf documentation (jonatack) +- #21342 Remove outdated comment (hebasto) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Aaron Clauson +- Andrew Chow +- Anthony Towns +- Bruno Garcia +- Fabian Jahr +- fanquake +- Hennadii Stepanov +- Jon Atack +- Luke Dashjr +- MarcoFalke +- Pieter Wuille +- practicalswift +- randymcmillan +- Sjors Provoost +- Vasil Dimov +- W. J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2021-09-13-release-22.0.md b/_posts/zh_TW/releases/2021-09-13-release-22.0.md new file mode 100644 index 000000000..7854de87d --- /dev/null +++ b/_posts/zh_TW/releases/2021-09-13-release-22.0.md @@ -0,0 +1,304 @@ +--- +title: Bitcoin Core 22.0 +id: zh_tw-release-22.0 +name: release-22.0 +permalink: /zh_TW/releases/22.0/ +excerpt: Bitcoin Core 22.0 版本現已發布 +date: 2021-09-13 +type: releases +layout: page +lang: zh_TW + +release: [22, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:1538a3b3962215f12e0e5f60105457332cf8fee4&dn=bitcoin-core-22.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +22.0 版本說明 +================== + +Bitcoin Core 22.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.14+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 22.0 開始，不再支援 macOS 10.14 之前的版本。 + +重要變更 +=============== + +P2P 和網路變更 +----------------------- +- 新增支援將 Bitcoin Core 作為 [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P) 服務執行並連接到此類服務。詳情請參閱 [i2p.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/i2p.md)。(#20685) +- 此版本移除了對 Tor 版本 2 隱藏服務的支援，轉而僅支援 Tor v3，因為 Tor 網路在 Tor 0.4.6 版本發布時[停止支援 Tor v2](https://blog.torproject.org/v2-deprecation-timeline)。從現在開始，Bitcoin Core 忽略 Tor v2 地址；它既不會透過網路向其他對等節點傳播這些地址，也不會將它們儲存在記憶體或 `peers.dat` 中。(#22050) + +- 透過 [`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html) 新增 NAT-PMP 連接埠映射支援。(#18077) + +新的和更新的 RPC +-------------------- + +- 由於實施了 [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)，所有接受地址的 RPC 在傳遞原生見證版本 1（或更高版本）時的行為都會改變。現在這些需要 Bech32m 編碼而不是 Bech32 編碼，並且 RPC 輸出中也將使用 Bech32m 編碼表示此類地址。在共識規則賦予版本 1 地址意義之前，不應為主網建立版本 1 地址（這將透過 [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) 實現）。一旦發生這種情況，預計將對它們使用 Bech32m，因此這不應影響任何生產系統，但可能會在此類地址已具有意義的其他網路（如 signet）上觀察到。(#20861) + +- `getpeerinfo` RPC 返回兩個新的布林欄位 `bip152_hb_to` 和 `bip152_hb_from`，分別指示我們是否選擇了對等節點為緊湊區塊高頻寬模式，或對等節點是否選擇我們作為緊湊區塊高頻寬對等節點。高頻寬對等節點透過 `cmpctblock` 訊息而不是通常的 inv/headers 公告來發送新區塊公告。詳情請參閱 BIP 152。(#19776) + +- `getpeerinfo` 不再返回以下欄位：`addnode`、`banscore` 和 `whitelisted`，這些欄位先前在 0.21 中已被棄用。`connection_type` 欄位返回 manual 而不是 `addnode`。`permissions` 欄位指示對等節點是否具有特殊權限，而不是 `whitelisted`。`banscore` 欄位已被簡單移除。(#20755) + +- 以下 RPC：`gettxout`、`getrawtransaction`、`decoderawtransaction`、`decodescript`、`gettransaction` 和 REST 端點：`/rest/tx`、`/rest/getutxos`、`/rest/block` 棄用了以下欄位（預設情況下不再在回應中返回）：`addresses`、`reqSigs`。必須傳遞 `-deprecatedrpc=addresses` 標誌才能在 RPC 回應中包含這些欄位。此標誌/選項僅適用於此主要版本，之後將完全移除棄用。請注意，這些欄位是 RPC 回應中返回的 `scriptPubKey` 物件的屬性。但是，在 `decodescript` 的回應中，這些欄位是頂層屬性，並再次作為 `scriptPubKey` 物件的屬性包含。(#20286) + +- 使用設定了 `-json` 選項的 `bitcoin-tx` 實用程式建立十六進位編碼的 bitcoin 交易時，回應的 tx 輸出中不再返回以下欄位：`addresses`、`reqSigs`。(#20286) + +- `listbanned` RPC 現在返回兩個新的數字欄位：`ban_duration` 和 `time_remaining`。這些新欄位分別指示禁止的持續時間和禁止到期前的剩餘時間，均以秒為單位。此外，`ban_created` 欄位已重新定位到 `banned_until` 之前。(#21602) + +- `setban` RPC 可以再次禁止 onion 地址。這修復了 0.21.0 版本中引入的回歸。(#20852) + +- `getnodeaddresses` RPC 現在返回一個「network」欄位，指示每個地址的網路類型（ipv4、ipv6、onion 或 i2p）。(#21594) + +- `getnodeaddresses` 現在也接受「network」參數（ipv4、ipv6、onion 或 i2p）以僅返回指定網路的地址。(#21843) + +- `testmempoolaccept` RPC 現在接受多個交易（目前仍處於實驗階段，API 可能不穩定）。這旨在測試具有依賴關係的交易套件；不建議批次驗證獨立交易。除了 mempool 政策外，還適用套件政策：清單不能包含超過 25 個交易或總大小超過 101K 虛擬位元組，並且不能相互衝突（花費相同的輸入）或與 mempool 衝突，即使這將是有效的 BIP125 手續費替換。測試接受的準確性存在一些已知限制：`testmempoolaccept` 可能為一組交易返回「allowed」=True，但如果實際提交，則返回「too-long-mempool-chain」。(#20833) + +- `addmultisigaddress` 和 `createmultisig` 現在最多支援 20 個金鑰用於 Segwit 地址。(#20867) + +與錢包或 GUI 相關的 RPC 變更可以在下面的 GUI 或錢包部分找到。 + +建置系統 +------------ + +- 現在使用新的基於 `guix` 的建置系統產生發布二進位檔案。[/doc/release-process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md) 文件已相應更新。 + +檔案 +----- + +- 被禁止主機和網路的清單（透過 `setban` RPC）現在以 JSON 格式儲存在 `banlist.json` 中，而不是 `banlist.dat`。只有在 `banlist.json` 不存在時，才會在啟動時讀取 `banlist.dat`。變更僅寫入新的 `banlist.json`。未來版本的 Bitcoin Core 可能會完全忽略 `banlist.dat`。(#20966) + +新設定 +------------ + +- 已新增 `-natpmp` 選項以使用 NAT-PMP 映射監聽連接埠。如果同時啟用 UPnP 和 NAT-PMP，來自 UPnP 的成功分配優先於 NAT-PMP 的分配。(#18077) + +更新的設定 +---------------- + +與錢包或 GUI 相關的設定變更可以在下面的 GUI 或錢包部分找到。 + +- 傳遞無效的 `-rpcauth` 參數現在會導致 bitcoind 無法啟動。(#20461) + +工具和實用程式 +------------------- + +- 新的 CLI `-addrinfo` 命令返回節點已知的每個網路類型（包括 Tor v2 與 v3）和總計的地址數量。這可用於查看節點是否知道網路中足夠的地址以使用 `-onlynet=` 等選項，或升級到支援僅 Tor v3 的 Bitcoin Core 22.0。(#21595) + +- 新的 `-rpcwaittimeout` 參數用於 `bitcoin-cli`，設定與 `-rpcwait` 一起使用的超時（以秒為單位）。如果超時到期，`bitcoin-cli` 將回報失敗。(#21056) + +錢包 +------ + +- 現在可以透過新的 RPC 方法 `enumeratesigners` 和 `displayaddress` 使用硬體錢包等外部簽名器。`send` RPC 呼叫也新增了支援。此功能是實驗性的。詳情請參閱 [external-signer.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/external-signer.md)。(#16546) + +- 新的 `listdescriptors` RPC 可用於檢查啟用描述符的錢包的內容。RPC 返回所有匯入描述符的公共版本，包括它們的時間戳記和標誌。對於範圍描述符，它還返回範圍邊界和從中生成地址的下一個索引。(#20226) + +- `bumpfee` RPC 不適用於已停用私鑰的錢包。可以改用 `psbtbumpfee`。(#20891) + +- `fundrawtransaction`、`send` 和 `walletcreatefundedpsbt` RPC 現在支援 `include_unsafe` 選項，當為 `true` 時允許使用不安全的輸入來資助交易。請注意，如果其中一個不安全的輸入消失，結果交易可能會變得無效。如果發生這種情況，必須使用不同的輸入資助交易並重新發布。(#21359) + +- 我們現在支援 `wsh()` 下的 `multi()` 和 `sortedmulti()` 描述符中最多 20 個金鑰。(#20867) + +- 只有在使用的網路（例如主網、測試網、signet）上發生啟動後，才能將 Taproot 描述符匯入錢包。請參閱 [descriptors.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/descriptors.md) 以了解支援的描述符。 + +GUI 變更 +----------- + +- 現在可以使用硬體錢包等外部簽名器。這些需要安裝外部工具（例如 [HWI](https://github.com/bitcoin-core/HWI)）並在選項 -> 錢包下進行設定。建立新錢包時，對話框中將出現新選項「External signer」。如果檢測到裝置，其名稱將建議作為錢包名稱。然後自動匯入僅觀察金鑰。可以在裝置上驗證接收地址。發送對話框將自動使用連接的裝置。此功能是實驗性的，執行這些操作時 UI 可能會凍結幾秒鐘。 + +低階變更 +================= + +RPC +--- + +- RPC 伺服器可以處理有限數量的同時 RPC 請求。以前，如果超過此限制，RPC 伺服器將回應[狀態碼 500 (`HTTP_INTERNAL_SERVER_ERROR`)](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_server_errors)。現在它返回狀態碼 503 (`HTTP_SERVICE_UNAVAILABLE`)。(#18335) + +- 錯誤代碼已更新，以便對以下錯誤情況更加準確 (#18466)： + - `signmessage` 現在如果傳遞的地址無效，則返回 RPC_INVALID_ADDRESS_OR_KEY (-5)。以前返回 RPC_TYPE_ERROR (-3)。 + - `verifymessage` 現在如果傳遞的地址無效，則返回 RPC_INVALID_ADDRESS_OR_KEY (-5)。以前返回 RPC_TYPE_ERROR (-3)。 + - `verifymessage` 現在如果傳遞的簽名格式錯誤，則返回 RPC_TYPE_ERROR (-3)。以前返回 RPC_INVALID_ADDRESS_OR_KEY (-5)。 + +測試 +----- + +22.0 變更日誌 +=============== + +此版本中變更的詳細清單如下。為了將清單保持在可管理的長度，不包括小型重構和拼寫錯誤修復，有時將類似的變更濃縮為一行。 + +### 共識 +- #19438 Introduce deploymentstatus (ajtowns) +- #20207 Follow-up extra comments on taproot code and tests (sipa) +- #21330 Deal with missing data in signature hashes more consistently (sipa) + +### 政策 +- #18766 Disable fee estimation in blocksonly mode (by removing the fee estimates global) (darosior) +- #20497 Add `MAX_STANDARD_SCRIPTSIG_SIZE` to policy (sanket1729) +- #20611 Move `TX_MAX_STANDARD_VERSION` to policy (MarcoFalke) + +### 挖礦 +- #19937, bitcoin/bitcoin#20923 Signet mining utility (ajtowns) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Aaron Clauson +- Adam Jonas +- amadeuszpawlik +- Amiti Uttarwar +- Andrew Chow +- Andrew Poelstra +- Anthony Towns +- Antoine Poinsot +- Antoine Riard +- apawlik +- apitko +- Ben Carman +- Ben Woosley +- benk10 +- Bezdrighin +- Block Mechanic +- Brian Liotti +- Bruno Garcia +- Carl Dong +- Christian Decker +- coinforensics +- Cory Fields +- Dan Benjamin +- Daniel Kraft +- Darius Parvin +- Dhruv Mehta +- Dmitry Goncharov +- Dmitry Petukhov +- dplusplus1024 +- dscotese +- Duncan Dean +- Elle Mouton +- Elliott Jin +- Emil Engler +- Ethan Heilman +- eugene +- Evan Klitzke +- Fabian Jahr +- Fabrice Fontaine +- fanquake +- fdov +- flack +- Fotis Koutoupas +- Fu Yong Quah +- fyquah +- glozow +- Gregory Sanders +- Guido Vranken +- Gunar C. Gessner +- h +- HAOYUatHZ +- Hennadii Stepanov +- Igor Cota +- Ikko Ashimine +- Ivan Metlushko +- jackielove4u +- James O'Beirne +- Jarol Rodriguez +- Joel Klabo +- John Newbery +- Jon Atack +- Jonas Schnelli +- João Barbosa +- Josiah Baker +- Karl-Johan Alm +- Kiminuo +- Klement Tan +- Kristaps Kaupe +- Larry Ruane +- lisa neigut +- Lucas Ontivero +- Luke Dashjr +- Maayan Keshet +- MarcoFalke +- Martin Ankerl +- Martin Zumsande +- Michael Dietz +- Michael Polzer +- Michael Tidwell +- Niklas Gögge +- nthumann +- Oliver Gugger +- parazyd +- Patrick Strateman +- Pavol Rusnak +- Peter Bushnell +- Pierre K +- Pieter Wuille +- PiRK +- pox +- practicalswift +- Prayank +- R E Broadley +- Rafael Sadowski +- randymcmillan +- Raul Siles +- Riccardo Spagni +- Russell O'Connor +- Russell Yanofsky +- S3RK +- saibato +- Samuel Dobson +- sanket1729 +- Sawyer Billings +- Sebastian Falbesoner +- setpill +- sgulls +- sinetek +- Sjors Provoost +- Sriram +- Stephan Oeste +- Suhas Daftuar +- Sylvain Goumy +- t-bast +- Troy Giorshev +- Tushar Singla +- Tyler Chambers +- Uplab +- Vasil Dimov +- W. J. van der Laan +- willcl-ark +- William Bright +- William Casarin +- windsok +- wodry +- Yerzhan Mazhkenov +- Yuval Kogman +- Zero + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2021-09-29-release-0.21.2.md b/_posts/zh_TW/releases/2021-09-29-release-0.21.2.md new file mode 100644 index 000000000..38baff7df --- /dev/null +++ b/_posts/zh_TW/releases/2021-09-29-release-0.21.2.md @@ -0,0 +1,114 @@ +--- +title: Bitcoin Core 0.21.2 +id: zh_tw-release-0.21.2 +name: release-0.21.2 +permalink: /zh_TW/releases/0.21.2/ +excerpt: Bitcoin Core 0.21.2 版本現已發布 +date: 2021-09-29 +type: releases +layout: page +lang: zh_TW + +release: [0, 21, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:c1a634e9efb58d783ccda4e710d8105d7ddd31ab&dn=bitcoin-core-0.21.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.21.2 版本說明 +==================== + +Bitcoin Core 0.21.2 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.12+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 0.20.0 開始，不再支援 macOS 10.12 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + + +0.21.2 變更日誌 +================= + +### P2P 協定和網路程式碼 + +- #21644 use NetPermissions::HasFlag() in CConnman::Bind() (jonatack) +- #22569 Rate limit the processing of rumoured addresses (sipa) + +### 錢包 + +- #21907 Do not iterate a directory if having an error while accessing it (hebasto) + +### RPC + +- #19361 Reset scantxoutset progress before inferring descriptors (prusnak) + +### 建置系統 + +- #21932 depends: update Qt 5.9 source url (kittywhiskers) +- #22017 Update Windows code signing certificate (achow101) +- #22191 Use custom MacOS code signing tool (achow101) +- #22713 Fix build with Boost 1.77.0 (sizeofvoid) + +### 測試和 QA + +- #20182 Build with --enable-werror by default, and document exceptions (hebasto) +- #20535 Fix intermittent feature_taproot issue (MarcoFalke) +- #21663 Fix macOS brew install command (hebasto) +- #22279 add missing ECCVerifyHandle to base_encode_decode (apoelstra) +- #22730 Run fuzzer task for the master branch only (hebasto) + +### GUI + +- gui#277 Do not use QClipboard::Selection on Windows and macOS. (hebasto) +- gui#280 Remove user input from URI error message (prayank23) +- gui#365 Draw "eye" sign at the beginning of watch-only addresses (hebasto) + +### Miscellaneous + +- #22002 Fix crash when parsing command line with -noincludeconf=0 (MarcoFalke) +- #22137 util: Properly handle -noincludeconf on command line (take 2) (MarcoFalke) + + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- Andrew Poelstra +- fanquake +- Hennadii Stepanov +- Jon Atack +- Kittywhiskers Van Gogh +- Luke Dashjr +- MarcoFalke +- Pavol Rusnak +- Pieter Wuille +- prayank23 +- Rafael Sadowski +- W. J. van der Laan + + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2021-10-26-release-0.20.2.md b/_posts/zh_TW/releases/2021-10-26-release-0.20.2.md new file mode 100644 index 000000000..58a5aaa23 --- /dev/null +++ b/_posts/zh_TW/releases/2021-10-26-release-0.20.2.md @@ -0,0 +1,147 @@ +--- +title: Bitcoin Core 0.20.2 +id: zh_tw-release-0.20.2 +name: release-0.20.2 +permalink: /zh_TW/releases/0.20.2/ +excerpt: Bitcoin Core 0.20.2 版本現已發布 +date: 2021-10-26 +type: releases +layout: page +lang: zh_TW + +release: [0, 20, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:3386067e3fe9d084c9694304cc116c74bab864b1&dn=bitcoin-core-0.20.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +0.20.2 版本說明 +==================== + +Bitcoin Core 0.20.2 版本現已發布，可從以下位置下載： + + + +此小版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.12+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 0.20.0 開始，不再支援 macOS 10.12 之前的版本。此外，當 macOS「深色模式」啟動時，Bitcoin Core 尚未變更外觀。 + +已知錯誤 +========== + +生成原始碼發布（「tarball」）的過程已變更，以使其更完整，但是，此版本存在一些回歸： + +- 生成的 `configure` 腳本目前遺失，您需要安裝 autotools 並執行 `./autogen.sh`，然後才能執行 `./configure`。這與從 git 檢出時相同。 + +- 不要簡單地執行 `make`，您應該改為執行 `BITCOIN_GENBUILD_NO_GIT=1 make`。 + +重要變更 +=============== + +關於行為不當對等節點的變更 +----------------------------------- + +行為不當的對等節點（例如向我們發送無效區塊）現在在日誌輸出中被稱為被阻止的節點，因為它們沒有（也不曾）被嚴格禁止：仍然允許來自它們的入站連線，但它們被優先驅逐。 + +此外，對被阻止地址的處理引入了一些額外的變更： + +- 阻止地址不會在 24 小時（或 `-bantime` 設定）後自動超時。根據來自其他對等節點的流量，阻止可能在不確定的時間超時。 + +- 阻止不會在重新啟動時持久化。 + +- 沒有方法列出被阻止的地址。它們不會由 `listbanned` RPC 返回。該 RPC 也不再報告 `ban_reason` 欄位，因為 `"manually added"` 是唯一剩餘的選項。 + +- 無法使用 `setban remove` RPC 命令移除阻止。如果您需要移除阻止，您可以透過停止-啟動節點來移除所有阻止。 + +通知變更 +-------------------- + +`-walletnotify` 通知現在會針對因與新區塊衝突而從 mempool 中移除的錢包交易發送。這些通知以前在 v0.19 版本之前發送，但自該版本以來已被破壞（錯誤 #18325）。 + +PSBT 變更 +------------ + +PSBT 將同時包含 segwit 輸入的非見證 utxo 和見證 utxo，以恢復與現在要求 segwit 輸入的完整先前交易的錢包軟體的相容性。仍然提供見證 utxo 以保持與依賴其存在來確定輸入是否為 segwit 的軟體的相容性。 + +0.20.2 變更日誌 +================= + +### P2P 協定和網路程式碼 + +- #19620 Add txids with non-standard inputs to reject filter (sdaftuar) +- #20146 Send post-verack handshake messages at most once (MarcoFalke) + +### 錢包 + +- #19740 Simplify and fix CWallet::SignTransaction (achow101) + +### RPC 和其他 API + +- #19836 Properly deserialize txs with witness before signing (MarcoFalke) +- #20731 Add missing description of vout in getrawtransaction help text (benthecarman) + +### 建置系統 + +- #20142 build: set minimum required Boost to 1.48.0 (fanquake) +- #20298 use the new plistlib API (jonasschnelli) +- #20880 gitian: Use custom MacOS code signing tool (achow101) +- #22190 Use latest signapple commit (achow101) + +### 測試和 QA + +- #19839 Set appveyor vm version to previous Visual Studio 2019 release. (sipsorcery) +- #19842 Update the vcpkg checkout commit ID in appveyor config. (sipsorcery) +- #20562 Test that a fully signed tx given to signrawtx is unchanged (achow101) + +### Miscellaneous + +- #19192 Extract net permissions doc (MarcoFalke) +- #19777 Correct description for getblockstats's txs field (shesek) +- #20080 Strip any trailing / in -datadir and -blocksdir paths (hebasto) +- #20082 fixes read buffer to use min rather than max (EthanHeilman) +- #20141 Avoid the use of abs64 in timedata (sipa) +- #20756 Add missing field (permissions) to the getpeerinfo help (amitiuttarwar) +- #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses (sipa) +- #22124 Update translations after closing 0.20.x on Transifex (hebasto) +- #21471 fix bech32_encode calls in gen_key_io_test_vectors.py (sipa) +- #22837 mention bech32m/BIP350 in doc/descriptors.md (sipa) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Aaron Clauson +- Amiti Uttarwar +- Andrew Chow +- Ethan Heilman +- fanquake +- Hennadii Stepanov +- Jonas Schnelli +- MarcoFalke +- Nadav Ivgi +- Pieter Wuille +- Suhas Daftuar + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2022-04-25-release-23.0.md b/_posts/zh_TW/releases/2022-04-25-release-23.0.md new file mode 100644 index 000000000..76dadf9d1 --- /dev/null +++ b/_posts/zh_TW/releases/2022-04-25-release-23.0.md @@ -0,0 +1,299 @@ +--- +title: Bitcoin Core 23.0 +id: zh_tw-release-23.0 +name: release-23.0 +permalink: /zh_TW/releases/23.0/ +excerpt: Bitcoin Core 23.0 版本現已發布 +date: 2022-04-25 +type: releases +layout: page +lang: zh_TW + +release: [23, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:32bc317cce76b966a26bdb53d42f64d66d595954&dn=bitcoin-core-23.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +23.0 版本說明 +================== + +Bitcoin Core 23.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 Mac 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +P2P 和網路變更 +----------------------- + +- bitcoind 節點預設情況下將不再向入站對等節點傳播地址。在發送 ADDR、ADDRV2 或 GETADDR 訊息後，它們將符合地址傳播的資格。(#21528) + +- 在此版本之前，Bitcoin Core 強烈傾向於嘗試僅連接到監聽連接埠 8333 的對等節點。因此，監聽非標準連接埠的 Bitcoin 節點可能不會獲得任何 Bitcoin Core 對等節點連接到它們。此偏好已被移除。(#23542) + +- 已新增對 CJDNS 網路的完整支援。請參閱新選項 `-cjdnsreachable` 和 [doc/cjdns.md](https://github.com/bitcoin/bitcoin/tree/23.x/doc/cjdns.md) (#23077) + +費用估算變更 +---------------------- + +- 費用估算現在會考慮替換 (RBF) 交易的費率。(#22539) + +移除重新掃描啟動參數 +-------------------------------- + +已移除 `-rescan` 啟動參數。由於損壞而需要重新掃描的錢包仍將在啟動時重新掃描。否則，請使用 `rescanblockchain` RPC 來觸發重新掃描。(#23123) + +Tracepoint 和使用者空間靜態定義追蹤支援 +------------------------------------------------------------- + +Linux 的 Bitcoin Core 發布二進位檔案現在包含實驗性 tracepoint，作為程式內部事件的介面。這些可用於審查、除錯、監控等。tracepoint API 是半穩定的。雖然 API 經過測試，但程式內部可能會在版本之間變更，需要變更 tracepoint。有關現有 tracepoint 的資訊可以在 [doc/tracing.md](https://github.com/bitcoin/bitcoin/blob/23.x/doc/tracing.md) 中找到，使用範例在 [contrib/tracing/](https://github.com/bitcoin/bitcoin/tree/23.x/contrib/tracing) 中提供。 + +更新的 RPC +------------ + +- `validateaddress` RPC 現在為無效地址返回一個 `error_locations` 陣列，其中包含地址中無效字元位置的索引（如果已知）。例如，這將嘗試找到最多兩個 Bech32 錯誤，並在成功時返回它們的位置。只有在少於兩個替換錯誤時，才能保證成功和正確性。 + 當解碼失敗時，`error` 欄位中返回的錯誤訊息現在也返回更具體的錯誤。(#16807) + +- 已移除 `-deprecatedrpc=addresses` 設定選項。RPC `gettxout`、`getrawtransaction`、`decoderawtransaction`、`decodescript`、`gettransaction verbose=true` 和 REST 端點 `/rest/tx`、`/rest/getutxos`、`/rest/block` 不再返回 `addresses` 和 `reqSigs` 欄位，這些欄位先前在 22.0 中已被棄用。(#22650) +- `getblock` RPC 命令現在支援詳細度等級 3，包含交易輸入的 `prevout` 資訊。現有的 `/rest/block/` REST 端點也已修改以包含此資訊。每個 `vin` 欄位將包含一個額外的 `prevout` 子欄位，描述已花費的輸出。`prevout` 包含以下鍵： + - `generated` - 如果花費的幣是 coinbase 則為 true。 + - `height` + - `value` + - `scriptPubKey` + +- 由 RPC `getmempoolentry`、`getrawmempool(verbose=true)`、`getmempoolancestors(verbose=true)` 和 `getmempooldescendants(verbose=true)` 返回的頂層費用欄位 `fee`、`modifiedfee`、`ancestorfees` 和 `descendantfees` 已被棄用，並將在下一個主要版本中移除（如果在此版本中需要，請使用 `-deprecated=fees`）。相同的費用欄位可以透過結果中的 `fees` 物件存取。警告：已棄用的欄位 `ancestorfees` 和 `descendantfees` 以 sats 計價，而 `fees` 物件中的所有欄位都以 BTC 計價。(#22689) + +- `createmultisig` 和 `addmultisigaddress` 現在都包含一個 `warnings` 欄位，如果在使用未壓縮公鑰時請求非傳統地址類型，將顯示警告。(#23113) + +與錢包相關的 RPC 變更可以在下面的錢包部分找到。 + +新的 RPC +-------- + +- 有關軟分叉狀態的資訊已從 `getblockchaininfo` 移至新的 `getdeploymentinfo` RPC，該 RPC 允許查詢任何區塊的軟分叉狀態，而不僅僅是鏈頂端。目前可以使用設定 `-deprecatedrpc=softforks` 在 `getblockchaininfo` 中復原包含軟分叉狀態，但這將在未來版本中移除。請注意，在任何一種情況下，`status` 欄位現在反映當前區塊的狀態，而不是下一個區塊。(#23508) + +檔案 +----- + +* 在啟動時，被禁止主機和網路的清單（透過 `setban` RPC）在 `banlist.dat` 中將被忽略，僅考慮 `banlist.json`。Bitcoin Core 22.x 版本是唯一可以讀取 `banlist.dat` 並將其寫入 `banlist.json` 的版本。如果 `banlist.json` 已存在，22.x 版本將不會嘗試將 `banlist.dat` 轉換為 json。升級後，可以使用 `listbanned` 來仔細檢查解析的條目。(#22570) + +更新的設定 +---------------- + +- 在先前版本中，命令列選項 `-persistmempool`（未提供值）的含義錯誤地停用了 mempool 持久性。`-persistmempool` 現在像其他布林選項一樣處理，表示 `-persistmempool=1`。傳遞 `-persistmempool=0`、`-persistmempool=1` 和 `-nopersistmempool` 不受影響。(#23061) + +- `-maxuploadtarget` 現在允許人類可讀的位元組單位 [k|K|m|M|g|G|t|T]。例如 `-maxuploadtarget=500g`。不允許空格、+- 或分數。如果未提供後綴，預設為 `M`。(#23249) + +- 如果 `-proxy=` 與 `-noonion` 一起給出，則提供的代理將不會設定為到達 Tor 網路的代理。因此將無法手動開啟到 Tor 網路的連線，例如使用 `addnode` RPC。要模仿舊行為，請使用 `-proxy=` 與 `-onlynet=` 一起列出除 `onion` 之外的所有相關網路。(#22834) + +工具和實用程式 +------------------- + +- 更新 `-getinfo` 以以使用者友好的格式返回資料，同時減少垂直空間。(#21832) + +- CLI `-addrinfo` 現在為節點已知的 `onion` 地址數量返回一個欄位，而不是單獨的 `torv2` 和 `torv3` 欄位，因為對 Tor V2 地址的支援已在 22.0 中從 Bitcoin Core 中移除。(#22544) + +錢包 +------ + +- 描述符錢包現在是預設錢包類型。新建立的錢包將使用描述符，除非在 `createwallet` 期間設定 `descriptors=false`，或在 GUI 中取消選取 `Descriptor wallet` 複選框。 + + 請注意，像 `importmulti` 和 `dumpprivkey` 這樣的錢包 RPC 命令不能與描述符錢包一起使用，因此如果您的客戶端程式碼依賴於這些命令而不在錢包建立期間指定 `descriptors=false`，您將需要更新您的程式碼。 + +- 新建立的描述符錢包將包含一個自動生成的 `tr()` 描述符，允許建立單鍵 Taproot 接收地址。 + +- `upgradewallet` 現在將在從非 HD 錢包升級到 HD 錢包時自動重新整理密鑰池，以立即開始使用新生成的 HD 金鑰。(#23093) + +- 已新增一個新的 RPC `newkeypool`，它將重新整理（完全清除並重新填充）密鑰池。(#23093) + +- `listunspent` 現在為仍在 mempool 中的每個交易輸出包含 `ancestorcount`、`ancestorsize` 和 `ancestorfees`。(#12677) + +- `lockunspent` 現在可選地採用第三個參數 `persistent`，這會導致鎖定持久地寫入錢包資料庫。這允許 UTXO 即使在節點重新啟動或崩潰後仍保持鎖定。(#23065) + +- `receivedby` RPC 現在包含 coinbase 交易。以前，以下錢包 RPC 排除 coinbase 交易：`getreceivedbyaddress`、`getreceivedbylabel`、`listreceivedbyaddress`、`listreceivedbylabel`。此版本變更了此行為，並返回考慮從 coinbase 輸出收到的幣的結果。可以使用設定 `-deprecatedrpc=exclude_coinbase` 復原先前的行為，但可能會在未來版本中移除。(#14707) + +- 在相同的 `receivedby` RPC 中，新選項 `include_immature_coinbase`（預設=`false`）決定是否計算未成熟的 coinbase 交易。未成熟的 coinbase 交易是確認數為 100 或更少且不可花費的 coinbase 交易。(#14707) + +GUI 變更 +----------- + +- 透過 GUI 鎖定的 UTXO 現在持久地儲存在錢包資料庫中，因此在節點關閉或崩潰時不會丟失。(#23065) + +- Bech32 複選框已替換為所有地址類型的下拉選單，包括適用於 Taproot 啟用錢包的新 Bech32m (BIP-350) 標準。 + +低階變更 +================= + +RPC +--- + +- `getblockchaininfo` 現在返回一個新的 `time` 欄位，提供鏈頂端時間。(#22407) + +測試 +----- + +- 對於 `regtest` 網路，多個軟分叉的啟動高度設定為區塊高度 1。它們可以透過執行時設定 `-testactivationheight=name@height` 變更。(#22818) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 0xb10c +- 0xree +- Aaron Clauson +- Adrian-Stefan Mares +- agroce +- aitorjs +- Alex Groce +- amadeuszpawlik +- Amiti Uttarwar +- Andrew Chow +- Andrew Poelstra +- Andrew Toth +- anouar kappitou +- Anthony Towns +- Antoine Poinsot +- Arnab Sen +- Ben Woosley +- benthecarman +- Bitcoin Hodler +- BitcoinTsunami +- brianddk +- Bruno Garcia +- CallMeMisterOwl +- Calvin Kim +- Carl Dong +- Cory Fields +- Cuong V. Nguyen +- Darius Parvin +- Dhruv Mehta +- Dimitri Deijs +- Dimitris Apostolou +- Dmitry Goncharov +- Douglas Chimento +- eugene +- Fabian Jahr +- fanquake +- Florian Baumgartl +- fyquah +- Gleb Naumenko +- glozow +- Gregory Sanders +- Heebs +- Hennadii Stepanov +- hg333 +- HiLivin +- Igor Cota +- Jadi +- James O'Beirne +- Jameson Lopp +- Jarol Rodriguez +- Jeremy Rand +- Jeremy Rubin +- Joan Karadimov +- John Newbery +- Jon Atack +- João Barbosa +- josibake +- junderw +- Karl-Johan Alm +- katesalazar +- Kennan Mell +- Kiminuo +- Kittywhiskers Van Gogh +- Klement Tan +- Kristaps Kaupe +- Kuro +- Larry Ruane +- lsilva01 +- lucash-dev +- Luke Dashjr +- MarcoFalke +- Martin Leitner-Ankerl +- Martin Zumsande +- Matt Corallo +- Matt Whitlock +- MeshCollider +- Michael Dietz +- Murch +- naiza +- Nathan Garabedian +- Nelson Galdeman +- NikhilBartwal +- Niklas Gögge +- node01 +- nthumann +- Pasta +- Patrick Kamin +- Pavel Safronov +- Pavol Rusnak +- Perlover +- Pieter Wuille +- practicalswift +- pradumnasaraf +- pranabp-bit +- Prateek Sancheti +- Prayank +- Rafael Sadowski +- rajarshimaitra +- randymcmillan +- ritickgoenka +- Rob Fielding +- Rojar Smith +- Russell Yanofsky +- S3RK +- Saibato +- Samuel Dobson +- sanket1729 +- seaona +- Sebastian Falbesoner +- sh15h4nk +- Shashwat +- Shorya +- ShubhamPalriwala +- Shubhankar Gambhir +- Sjors Provoost +- sogoagain +- sstone +- stratospher +- Suriyaa Rocky Sundararuban +- Taeik Lim +- TheCharlatan +- Tim Ruffing +- Tobin Harding +- Troy Giorshev +- Tyler Chambers +- Vasil Dimov +- W. J. van der Laan +- w0xlt +- willcl-ark +- William Casarin +- zealsham +- Zero-1729 + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2022-05-18-release-23.2.md b/_posts/zh_TW/releases/2022-05-18-release-23.2.md new file mode 100644 index 000000000..b8b25c16f --- /dev/null +++ b/_posts/zh_TW/releases/2022-05-18-release-23.2.md @@ -0,0 +1,79 @@ +--- +title: Bitcoin Core 23.2 +id: zh_tw-release-23.2 +name: release-23.2 +permalink: /zh_TW/releases/23.2/ +excerpt: Bitcoin Core 23.2 版本現已發布 +date: 2022-05-18 +type: releases +layout: page +lang: zh_TW + +release: [23, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:e672796b257f0d3d3043d9022c4df57b2c9f6ede&dn=bitcoin-core-23.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +23.2 版本說明 +================== + +Bitcoin Core 23.2 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +### P2P + +- #26909 net: prevent peers.dat corruptions by only serializing once +- #27608 p2p: Avoid prematurely clearing download state for other peers +- #27610 Improve performance of p2p inv to send queues + +### 建置系統 + +- #25436 build: suppress array-bounds errors in libxkbcommon +- #25763 bdb: disable Werror for format-security +- #26944 depends: fix systemtap download URL +- #27462 depends: fix compiling bdb with clang-16 on aarch64 + +### Miscellaneous + +- #25444 ci: macOS task imrovements +- #26388 ci: Use macos-ventura-xcode:14.1 image for "macOS native" task +- #26924 refactor: Add missing includes to fix gcc-13 compile error + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Anthony Towns +- Hennadii Stepanov +- MacroFake +- Martin Zumsande +- Michael Ford +- Suhas Daftuar + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2022-12-12-release-24.0.1.md b/_posts/zh_TW/releases/2022-12-12-release-24.0.1.md new file mode 100644 index 000000000..e3736b02c --- /dev/null +++ b/_posts/zh_TW/releases/2022-12-12-release-24.0.1.md @@ -0,0 +1,301 @@ +--- +title: Bitcoin Core 24.0.1 +id: zh_tw-release-24.0.1 +name: release-24.0.1 +permalink: /zh_TW/releases/24.0.1/ +excerpt: Bitcoin Core 24.0.1 版本現已發布 +date: 2022-12-12 +type: releases +layout: page +lang: zh_TW + +release: [24, 0, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:d7604a67c8ed6e3b35da15138f8ac81d7618788c&dn=bitcoin-core-24.0.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +24.0.1 版本說明 +==================== + +由於最後關頭的問題 (#26616)，24.0 版本雖然已標記，但從未完全公告或發布。 + +Bitcoin Core 24.0.1 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +交易替換政策新選項公告 +========================================================= + +此版本的 Bitcoin Core 新增了一個新的 `mempoolfullrbf` 設定選項，允許使用者變更其個別節點用於中繼和挖礦未確認交易的政策。該選項預設為先前版本中使用的相同政策，如果每個人都使用預設值，則節點政策不會發生變更。 + +目前某些 Bitcoin 服務期望它們看到的未確認交易的第一個版本將是最終被確認的版本 ─ 這種交易接受政策有時被稱為「first-seen」。 + +Bitcoin 協定不會且無法保證特定節點看到的未確認交易的第一個版本將是被確認的版本。如果同一未確認交易有多個版本可用，只有在區塊中包含這些交易之一的礦工才能決定哪個版本的交易被確認。 + +儘管缺乏這種保證，今天仍有多個商家和服務做出這種假設。 + +移除這種 *first-seen* 簡化對使用者有幾個好處。一個關鍵好處是，交易的發送者能夠用支付更高費用的替代版本替換它，這在 [Bitcoin Core 0.12.0][]（2016 年 2 月）中透過引入 [BIP125][] 選擇加入的手續費替換 (RBF) 實現了。 + +從那時起，一直有關於完全移除 first-seen 簡化並允許使用者用較新的交易替換任何較舊的未確認交易的討論，這一功能被稱為 *full-RBF*。此版本包含一個 `mempoolfullrbf` 設定選項，允許啟用 full-RBF，但預設為關閉（僅允許選擇加入的 RBF）。 + +多個替代節點實作已經預設啟用 full-RBF 多年，並且有幾位 Bitcoin Core 貢獻者正在倡導在未來版本的 Bitcoin Core 中預設啟用 full-RBF。 + +隨著越來越多參與中繼和挖礦的節點開始啟用 full-RBF，用提供更高費用的交易替換未確認交易可能會迅速變得更加可靠。 + +該專案的貢獻者強烈建議商家和服務不要接受未確認的交易作為最終交易，如果他們堅持這樣做，則應採取適當步驟以確保在他們的假設不成立時有一些追索權或計畫。 + +[Bitcoin Core 0.12.0]: https://bitcoincore.org/zh_TW/releases/0.12.0/#opt-in-replace-by-fee-transactions +[bip125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki + +重要變更 +=============== + +P2P 和網路變更 +----------------------- + +- 為了解決潛在的阻斷服務攻擊，從對等節點下載區塊標頭的邏輯已經重新設計。這對於首次啟動的節點（或長時間離線後啟動的節點）特別相關。 + + 每當從對等節點收到的區塊標頭的總鏈上工作量小於節點的 `-minimumchainwork` 值，或明顯低於節點頂端的工作量時，將開始「presync」階段，在此階段中，節點將下載對等節點的區塊標頭並驗證對等節點鏈上的累積工作量，然後才永久儲存這些區塊標頭。一旦該累積工作量被驗證為足夠高，將從該對等節點重新下載區塊標頭並完全驗證和儲存。 + + 這可能導致新節點首次啟動時的初始區塊標頭同步時間更長，這是因為區塊標頭將被下載兩次，而且對等節點在 presync 階段（或當節點的最佳區塊標頭鏈的工作量少於 `-minimumchainwork` 時）斷開連線的影響將導致節點也需要對下一個對等節點使用區塊標頭 presync 機制（再次下載區塊標頭兩次）。(#25717) + +- 對於 I2P 連線，如果 `-i2pacceptincoming=0`，則每個對外連線都會使用一個新的臨時地址。(#25355) + +更新的 RPC +------------ + +- 已移除 `-deprecatedrpc=softforks` 設定選項。RPC `getblockchaininfo` 不再返回 `softforks` 欄位，該欄位先前在 23.0 中已被棄用。(#23508) 現在只能透過 `getdeploymentinfo` RPC 獲取軟分叉狀態資訊。 + +- 已移除 `deprecatedrpc=exclude_coinbase` 設定選項。`receivedby` RPC（`listreceivedbyaddress`、`listreceivedbylabel`、`getreceivedbyaddress` 和 `getreceivedbylabel`）現在始終返回考慮從 coinbase 輸出收到的幣的結果，沒有改變該行為的選項。排除 coinbase 先前在 23.0 中已被棄用。(#25171) + +- 已移除 `deprecatedrpc=fees` 設定選項。頂層費用欄位 `fee`、`modifiedfee`、`ancestorfees` 和 `descendantfees` 不再由 RPC `getmempoolentry`、`getrawmempool(verbose=true)`、`getmempoolancestors(verbose=true)` 和 `getmempooldescendants(verbose=true)` 返回。相同的費用欄位可以透過結果中的 `fees` 物件存取。頂層費用欄位先前在 23.0 中已被棄用。(#25204) + +- `getpeerinfo` RPC 已更新，新增了一個 `presynced_headers` 欄位，指示上面「P2P 和網路變更」部分中提到的 presync 階段的進度。 + +與錢包相關的 RPC 變更可以在下面的錢包部分找到。 + +新的 RPC +-------- + +- `sendall` RPC 將特定的 UTXO 花費給一個或多個接收者，而不建立找零。預設情況下，`sendall` RPC 將花費錢包中的每個 UTXO。`sendall` 可用於清空錢包或從選定的 UTXO 建立無找零的支付。當從特定金額建立支付且接收者承擔交易費用時，請繼續透過 `send`、`sendtoaddress` 或 `sendmany` RPC 使用 `subtractfeefromamount` 選項。(#24118) + +- 已新增一個新的 `gettxspendingprevout` RPC，它會掃描 mempool 以尋找花費任何給定 outpoint 的交易。(#24408) + +- `simulaterawtransaction` RPC 會迭代給定交易的輸入和輸出，並統計給定錢包的餘額變化。例如，這可用於在驗證類似 coin join 的交易不包含錢包隨後會無意中簽署的意外輸入時。(#22751) + +更新的 REST API +----------------- + +- `/headers/` 和 `/blockfilterheaders/` 端點已更新為使用查詢參數而不是路徑參數來指定結果計數。計數參數現在是可選的，兩個端點的預設值均為 5。舊端點仍然可用，並且沒有記錄的行為變更。 + + 對於 `/headers`，使用 + `GET /rest/headers/.?count=` + 而不是 + `GET /rest/headers//.` (已棄用) + + 對於 `/blockfilterheaders/`，使用 + `GET /rest/blockfilterheaders//.?count=` + 而不是 + `GET /rest/blockfilterheaders///.` (已棄用) + + (#24098) + +建置系統 +------------ + +- Guix 建置現在可以跨架構（x86_64 和 aarch64）重現。(#21194) + +新設定 +------------ + +- 已新增一個新的 `mempoolfullrbf` 選項，它允許 mempool 接受交易替換而不強制執行 BIP125 可替換性訊號。(#25353) + +錢包 +------ + +- `-walletrbf` 啟動選項現在預設為 `true`。錢包現在預設在它建立的交易上選擇加入 RBF。(#25610) + +- `createrawtransaction` 和 `createpsbt` RPC 的 `replaceable` 選項現在預設為 `true`。使用這些 RPC 建立的交易將預設啟用選擇加入的 RBF。(#25610) + +- `wsh()` 輸出描述符已擴充支援 Miniscript。您可以在僅觀察錢包中匯入 P2WSH 的 Miniscript 描述符以追蹤幣，但您還不能使用 Bitcoin Core 錢包從它們花費。 + 您可以在[參考網站](https://bitcoin.sipa.be/miniscript/)上找到更多關於 Miniscript 的資訊。(#24148) + +- `tr()` 輸出描述符現在透過 `multi_a()` 和 `sortedmulti_a()` 函數支援多重簽名腳本。(#24043) + +- 為了幫助防止對 Bitcoin Core 錢包建立的交易進行指紋識別，找零輸出金額現在已隨機化。(#24494) + +- `listtransactions`、`gettransaction` 和 `listsinceblock` RPC 方法現在為每個交易包含一個 wtxid 欄位（序列化交易的雜湊，包括見證資料）。(#24198) + +- `listsinceblock`、`listtransactions` 和 `gettransaction` 輸出現在為每個「receive」條目包含一個新的 `parent_descs` 欄位。(#25504) + +- 已為 `listsinceblock` 命令新增一個新的可選 `include_change` 參數。 + +- RPC `getreceivedbylabel` 現在如果標籤不在地址簿中，則返回錯誤「Label not found in wallet」(-4)。(#25122) + +將傳統錢包遷移到描述符錢包 +---------------------------------------------- + +已新增一個實驗性的 RPC `migratewallet`，用於將傳統（非描述符）錢包遷移到描述符錢包。有關遷移流程的更多資訊可以在[文件](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets)中找到。 + +GUI 變更 +----------- + +- 已新增一個新的選單項目，用於從備份檔案復原錢包 (gui#471)。 + +- 在 bitcoin GUI 中進行的設定變更（例如修剪設定、代理設定、UPNP 偏好設定）現在儲存到 `/settings.json` 檔案，而不是 Qt 設定後端（Windows 登錄檔或 Unix 桌面設定檔），因此這些設定現在將應用於 bitcoind，而不是被忽略。(#15936, gui#602) + +- 此外，GUI 設定和 `bitcoin.conf` 設定之間的互動已簡化。來自 `bitcoin.conf` 的設定現在在 GUI 設定對話框中正常顯示，而不是在單獨的警告訊息中（「在此對話框中設定的選項被設定檔覆蓋：-setting=value」）。並且這些設定現在可以編輯，因為 `settings.json` 值優先於 `bitcoin.conf` 值。(#15936) + +低階變更 +================= + +RPC +--- + +- `deriveaddresses`、`getdescriptorinfo`、`importdescriptors` 和 `scantxoutset` 命令現在接受 `wsh()` 描述符中的 Miniscript 表達式。(#24148) + +- `getaddressinfo`、`decodescript`、`listdescriptors` 和 `listunspent` 命令現在可能會在 `wsh()` 中輸出 Miniscript 描述符，而先前返回的是 `wsh(raw())` 描述符。(#24148) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- /dev/fd0 +- 0xb10c +- Adam Jonas +- akankshakashyap +- Ali Sherief +- amadeuszpawlik +- Andreas Kouloumos +- Andrew Chow +- Anthony Towns +- Antoine Poinsot +- Antoine Riard +- Aurèle Oulès +- avirgovi +- Ayush Sharma +- Baas +- Ben Woosley +- BrokenProgrammer +- brunoerg +- brydinh +- Bushstar +- Calvin Kim +- CAnon +- Carl Dong +- chinggg +- Cory Fields +- Daniel Kraft +- Daniela Brozzoni +- darosior +- Dave Scotese +- David Bakin +- dergoegge +- dhruv +- Dimitri +- dontbyte +- Duncan Dean +- eugene +- Eunoia +- Fabian Jahr +- furszy +- Gleb Naumenko +- glozow +- Greg Weber +- Gregory Sanders +- gruve-p +- Hennadii Stepanov +- hiago +- Igor Bubelov +- ishaanam +- Jacob P. +- Jadi +- James O'Beirne +- Janna +- Jarol Rodriguez +- Jeremy Rand +- Jeremy Rubin +- jessebarton +- João Barbosa +- John Newbery +- Jon Atack +- Josiah Baker +- Karl-Johan Alm +- KevinMusgrave +- Kiminuo +- klementtan +- Kolby Moroz +- kouloumos +- Kristaps Kaupe +- Larry Ruane +- Luke Dashjr +- MarcoFalke +- Marnix +- Martin Leitner-Ankerl +- Martin Zumsande +- Michael Dietz +- Michael Folkson +- Michael Ford +- Murch +- mutatrum +- muxator +- Oskar Mendel +- Pablo Greco +- pasta +- Patrick Strateman +- Pavol Rusnak +- Peter Bushnell +- phyBrackets +- Pieter Wuille +- practicalswift +- randymcmillan +- Robert Spigler +- Russell Yanofsky +- S3RK +- Samer Afach +- Sebastian Falbesoner +- Seibart Nedor +- Shashwat +- Sjors Provoost +- Smlep +- sogoagain +- Stacie +- Stéphan Vuylsteke +- Suhail Saqan +- Suhas Daftuar +- t-bast +- TakeshiMusgrave +- Vasil Dimov +- W. J. van der Laan +- w0xlt +- whiteh0rse +- willcl-ark +- William Casarin +- Yancy Ribbens + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2022-12-15-release-22.1.md b/_posts/zh_TW/releases/2022-12-15-release-22.1.md new file mode 100644 index 000000000..d116147a9 --- /dev/null +++ b/_posts/zh_TW/releases/2022-12-15-release-22.1.md @@ -0,0 +1,131 @@ +--- +title: Bitcoin Core 22.1 +id: zh_tw-release-22.1 +name: release-22.1 +permalink: /zh_TW/releases/22.1/ +excerpt: Bitcoin Core 22.1 版本現已發布 +date: 2022-12-15 +type: releases +layout: page +lang: zh_TW + +release: [22, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:30d417cae54b9b1f75ebd6c32a73f9f9d00d5c67&dn=bitcoin-core-22.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +22.1 版本說明 +================== + +Bitcoin Core 22.1 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.14+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +從 Bitcoin Core 22.0 開始，不再支援 macOS 10.14 之前的版本。 + +重要變更 +=============== + +更新的設定 +---------------- + +- 在先前版本中，命令列選項 `-persistmempool`（未提供值）的含義錯誤地停用了 mempool 持久性。`-persistmempool` 現在像其他布林選項一樣處理，表示 `-persistmempool=1`。傳遞 `-persistmempool=0`、`-persistmempool=1` 和 `-nopersistmempool` 不受影響。(#23061) + +### P2P + +### RPC 和其他 API + +- #25237 rpc: Capture UniValue by ref for rpcdoccheck +- #25983 Prevent data race for pathHandlers +- #26275 Fix crash on deriveaddresses when index is 2147483647 (2^31-1) + +### 錢包 + +- #22781 wallet: fix the behavior of IsHDEnabled +- #22949 fee: Round up fee calculation to avoid a lower than expected feerate +- #23333 wallet: fix segfault by avoiding invalid default-ctored external_spk_managers entry + +### 建置系統 + +- #22820 build, qt: Fix typo in QtInputSupport check +- #23045 build: Restrict check for CRC32C intrinsic to aarch64 +- #23148 build: Fix guix linker-loader path and add check_ELF_interpreter +- #23314 build: explicitly disable libsecp256k1 openssl based tests +- #23580 build: patch qt to explicitly define previously implicit header include +- #24215 guix: ignore additional failing certvalidator test +- #24256 build: Bump depends packages (zmq, libXau) +- #25201 windeploy: Renewed windows code signing certificate +- #25985 Revert "build: Use Homebrew's sqlite package if it is available" +- #26633 depends: update qt 5.12 url to archive location + +### GUI + +- #gui631 Disallow encryption of watchonly wallets +- #gui680 Fixes MacOS 13 segfault by preventing certain notifications +- #24498 qt: Avoid crash on startup if int specified in settings.json + +### 測試 + +- #23716 test: replace hashlib.ripemd160 with an own implementation +- #24239 test: fix ceildiv division by using integers + +### 實用程式 + +- #22390 system: skip trying to set the locale on NetBSD +- #22895 don't call GetBlockPos in ReadBlockFromDisk without cs_main lock +- #24104 fs: Make compatible with boost 1.78 + +### Miscellaneous + +- #23335 refactor: include a missing header in fs.cpp +- #23504 ci: Replace soon EOL hirsute with jammy +- #26321 Adjust .tx/config for new Transifex CLI + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- BlackcoinDev +- Carl Dong +- Hennadii Stepanov +- Joan Karadimov +- John Moffett +- Jon Atack +- Kittywhiskers Van Gogh +- Marco Falke +- Martin Zumsande +- Michael Ford +- muxator +- Pieter Wuille +- Ryan Ofsky +- Saibato +- Sebastian Falbesoner +- W. J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2022-12-21-release-23.1.md b/_posts/zh_TW/releases/2022-12-21-release-23.1.md new file mode 100644 index 000000000..78507688c --- /dev/null +++ b/_posts/zh_TW/releases/2022-12-21-release-23.1.md @@ -0,0 +1,97 @@ +--- +title: Bitcoin Core 23.1 +id: zh_tw-release-23.1 +name: release-23.1 +permalink: /zh_TW/releases/23.1/ +excerpt: Bitcoin Core 23.1 版本現已發布 +date: 2022-12-21 +type: releases +layout: page +lang: zh_TW + +release: [23, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:b3a5dd34839ba1f137402928809c51f9d75d9369&dn=bitcoin-core-23.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +23.1 版本說明 +================== + +Bitcoin Core 23.1 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +### P2P + +- #25314 p2p: always set nTime for self-advertisements + +### RPC 和其他 API + +- #25220 rpc: fix incorrect warning for address type p2sh-segwit in createmultisig +- #25237 rpc: Capture UniValue by ref for rpcdoccheck +- #25983 Prevent data race for pathHandlers +- #26275 Fix crash on deriveaddresses when index is 2147483647 (2^31-1) + +### 建置系統 + +- #25201 windeploy: Renewed windows code signing certificate +- #25788 guix: patch NSIS to remove .reloc sections from installer stubs +- #25861 guix: use --build={arch}-guix-linux-gnu in cross toolchain +- #25985 Revert "build: Use Homebrew's sqlite package if it is available" + +### GUI + +- #24668 build, qt: bump Qt5 version to 5.15.3 +- gui#631 Disallow encryption of watchonly wallets +- gui#680 Fixes MacOS 13 segfault by preventing certain notifications + +### 測試 + +- #24454 tests: Fix calculation of external input weights + +### Miscellaneous + +- #26321 Adjust .tx/config for new Transifex CLI + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- brunoerg +- Hennadii Stepanov +- John Moffett +- MacroFake +- Martin Zumsande +- Michael Ford +- muxator +- Pavol Rusnak +- Sebastian Falbesoner +- W. J. van der Laan + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2023-05-18-release-24.1.md b/_posts/zh_TW/releases/2023-05-18-release-24.1.md new file mode 100644 index 000000000..8078bae21 --- /dev/null +++ b/_posts/zh_TW/releases/2023-05-18-release-24.1.md @@ -0,0 +1,106 @@ +--- +title: Bitcoin Core 24.1 +id: zh_tw-release-24.1 +name: release-24.1 +permalink: /zh_TW/releases/24.1/ +excerpt: Bitcoin Core 24.1 版本現已發布 +date: 2023-05-18 +type: releases +layout: page +lang: zh_TW + +release: [24, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:ebb58d7495a8aaed2f20ec4ce3e5ae27aff69529&dn=bitcoin-core-24.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +24.1 版本說明 +================== + +Bitcoin Core 24.1 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +### P2P + +- #26878 I2P network optimizations +- #26909 net: prevent peers.dat corruptions by only serializing once +- #27608 p2p: Avoid prematurely clearing download state for other peers +- #27610 Improve performance of p2p inv to send queues + +### RPC 和其他 API + +- #26515 rpc: Require NodeStateStats object in getpeerinfo +- #27279 doc: fix/improve warning helps in {create,load,unload,restore}wallet +- #27468 rest: avoid segfault for invalid URI + +### 建置系統 + +- #26944 depends: fix systemtap download URL +- #27462 depends: fix compiling bdb with clang-16 on aarch64 + +### 錢包 + +- #26595 wallet: be able to specify a wallet name and passphrase to migratewallet +- #26675 wallet: For feebump, ignore abandoned descendant spends +- #26679 wallet: Skip rescanning if wallet is more recent than tip +- #26761 wallet: fully migrate address book entries for watchonly/solvable wallets +- #27053 wallet: reuse change dest when re-creating TX with avoidpartialspends +- #27080 wallet: Zero out wallet master key upon locking so it doesn't persist in memory +- #27473 wallet: Properly handle "unknown" Address Type + +### GUI 變更 + +- gui#687 Load PSBTs using istreambuf_iterator rather than istream_iterator +- gui#704 Correctly limit overview transaction list + +### Miscellaneous + +- #26880 ci: replace Intel macOS CI job +- #26924 refactor: Add missing includes to fix gcc-13 compile error + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Andrew Chow +- Anthony Towns +- Hennadii Stepanov +- John Moffett +- Jon Atack +- Marco Falke +- Martin Zumsande +- Matthew Zipkin +- Michael Ford +- pablomartin4btc +- Sebastian Falbesoner +- Suhas Daftuar +- Thomas Nguyen +- Vasil Dimov + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2023-05-26-release-25.0.md b/_posts/zh_TW/releases/2023-05-26-release-25.0.md new file mode 100644 index 000000000..ad0666525 --- /dev/null +++ b/_posts/zh_TW/releases/2023-05-26-release-25.0.md @@ -0,0 +1,274 @@ +--- +title: Bitcoin Core 25.0 +id: zh_tw-release-25.0 +name: release-25.0 +permalink: /zh_TW/releases/25.0/ +excerpt: Bitcoin Core 25.0 版本現已發布 +date: 2023-05-26 +type: releases +layout: page +lang: zh_TW + +release: [25, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:092358777175c4306602f9b1b523738df4b4610b&dn=bitcoin-core-25.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +25.0 版本說明 +================== + +Bitcoin Core 25.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +P2P 和網路變更 +----------------------- + +- 現在 mempool 和中繼政策允許非見證大小 65 bytes 及以上的交易。這是為了更好地反映針對 CVE-2017-12842 的實際提供保護，並開放更小交易大小的額外使用案例。(#26265) + +新的 RPC +-------- + +- scanblocks RPC 透過掃描給定範圍內的所有區塊過濾器，從一組描述符返回相關的區塊雜湊值。它可以與 getblockheader 和 rescanblockchain RPC 結合使用，以實現快速錢包重新掃描。請注意，只有在節點建構了緊湊區塊過濾器索引（`-blockfilterindex=1`）時，才能使用此功能。(#23549) + +更新的 RPC +------------ + +- 所有 JSON-RPC 方法都接受名為 `args` 的新[命名參數](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#parameter-passing)，可以包含位置參數值。這是一個方便功能，允許某些參數值透過名稱傳遞，而無需命名每個值。python 測試框架和 `bitcoin-cli` 工具都利用了這一點，因此例如： + +```sh +bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1 +``` + +現在可以縮短為： + +```sh +bitcoin-cli -named createwallet mywallet load_on_startup=1 +``` + +- `verifychain` RPC 現在將返回 `false`，如果檢查沒有失敗，但無法在所需的深度和級別完成。這可能是由於在修剪時缺少資料、由於 dbcache 不足或由於節點在呼叫完成之前被關閉。(#25574) + +- `sendrawtransaction` 有一個新的可選參數 `maxburnamount`，預設值為 `0`。任何包含值大於 `maxburnamount` 的不可花費輸出的交易都不會提交。目前，被視為不可花費的輸出是那些腳本以 `OP_RETURN` 程式碼開頭的（稱為「datacarriers」）、超過最大腳本大小的腳本以及包含無效操作碼的腳本。 + +- `testmempoolaccept` RPC 現在在「fees」結果中返回 2 個額外結果：「effective-feerate」是包括使用套件驗證時一起驗證的交易的費用和大小的費率，並且還包括來自 prioritisetransaction 的任何修改費用。「effective-includes」結果列出了其修改費用和大小用於有效費率的交易的 wtxid。(#26646) + +- `decodescript` 現在可以在 P2WSH 上下文下推斷 Miniscript 描述符（如果不缺少資訊）。(#27037) + +- `finalizepsbt` 現在能夠最終化花費 Miniscript 相容 P2WSH 腳本的輸入的交易。(#24149) + +與錢包相關的 RPC 變更可以在下面的錢包部分找到。 + +建置系統 +------------ + +- `--enable-upnp-default` 和 `--enable-natpmp-default` 選項已被移除。如果您想使用連接埠映射，可以使用 .conf 檔案進行設定，或在執行時傳遞相關選項。(#26896) + +更新的設定 +---------------- + +- 如果使用者明確提供了 `-checkblocks` 或 `-checklevel` 選項，但由於 dbcache 不足而無法完成驗證檢查，Bitcoin Core 現在將在啟動時返回錯誤。(#25574) + +- `-port` 和 `-rpcport` 選項中指定的連接埠現在會在啟動時進行驗證。先前有效且被視為有效的值現在可能導致錯誤。(#22087) + +- 設定 `-blocksonly` 現在將最大 mempool 記憶體減少到 5MB（使用者仍可使用 `-maxmempool` 覆蓋）。先前，將使用預設的 300MB，導致使用 `-blocksonly` 運作的使用者出現意外的記憶體使用，預期它會消除 mempool 記憶體使用。 + + 由於未使用的 mempool 記憶體與 dbcache 共用，這也減少了使用 `-blocksonly` 運作的使用者的 dbcache 大小，可能影響效能。 +- 設定 `-maxconnections=0` 現在將停用 `-dnsseed` 和 `-listen`（使用者仍可設定它們以覆蓋）。 + +與 GUI 或錢包相關的設定變更可以在下面的 GUI 或錢包部分找到。 + +新設定 +------------ + +- `shutdownnotify` 選項用於指定在 Bitcoin Core 開始其關閉序列之前同步執行的命令。(#23395) + + +錢包 +------ + +- `minconf` 選項（允許使用者指定正在花費的 UTXO 的最小確認數）和 `maxconf` 選項（允許指定最大確認數）已在 #25375 中新增到以下 RPC： + - `fundrawtransaction` + - `send` + - `walletcreatefundedpsbt` + - `sendall` + +- 在 `listdescriptors` 的回應中新增了新的 `next_index` 欄位，以與 `importdescriptors` 具有相同的格式 (#26194) + +- RPC `listunspent` 現在有新參數 `include_immature_coinbase`，以包含不符合最小可花費深度要求的 coinbase UTXO（之前會被靜默跳過）。(#25730) + +- 如果可用緊湊區塊過濾器（BIP158），描述符錢包的重新掃描現在明顯更快。由於預設情況下不會建構這些過濾器，因此必須提供設定選項「-blockfilterindex=1」才能利用此最佳化。這改善了 RPC 呼叫 `rescanblockchain`、`importdescriptors` 和 `restorewallet` 的效能。(#25957) + +- RPC `unloadwallet` 現在如果重新掃描正在進行中則會失敗。(#26618) + +- 錢包密碼現在可以包含 null 字元。在此變更之前，只有第一個 null 字元之前的字元會被識別和接受。(#27068) + +- 地址目的字串現在限制為目前已知的「send」、「receive」和「refund」值。具有未識別目的字串的錢包將有載入警告，如果請求未識別的目的，`listlabels` RPC 將引發錯誤。(#27217) + +- 在 `createwallet`、`loadwallet`、`unloadwallet` 和 `restorewallet` RPC 中，「warning」字串欄位已被棄用，改為返回字串 JSON 陣列的「warnings」欄位，以更好地處理多個警告訊息並與其他錢包 RPC 保持一致。「warning」欄位將在 v26 中從這些 RPC 中完全移除。在棄用期間，可以透過使用設定選項 `-deprecatedrpc=walletwarningfield` 啟動 bitcoind 來暫時重新啟用它。(#27279) + +- 描述符錢包現在可以花費發送到 P2WSH Miniscript 描述符的幣。(#24149) + +GUI 變更 +----------- + +- 「Mask values」現在是一個持久選項。(gui#701) +- 「Mask values」選項現在除了影響「Overview」視圖外，也影響「Transaction」視圖。(gui#708) + +REST +---- + +- 已新增新的 `/rest/deploymentinfo` 端點，用於獲取有關共識變更部署的各種狀態資訊。(#25412) + +二進位驗證 +---- + +- 二進位驗證腳本已更新。在先前版本中，它會驗證二進位檔案是否使用單一「release key」簽署。在此版本及後續版本中，它將驗證二進位檔案是否由_信任密鑰的門檻_簽署。有關更多詳細資訊和範例，請參閱： + https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md + (#27358) + +低階變更 +================= + +RPC +--- + +- JSON-RPC 伺服器現在拒絕參數以相同名稱多次指定的請求，而不是靜默地用後面的參數值覆蓋較早的參數值。(#26628) +- RPC `listsinceblock` 現在接受可選的 `label` 參數，以獲取具有指定標籤的傳入交易。(#25934) +- 先前 `setban`、`addpeeraddress`、`walletcreatefundedpsbt` 方法允許將非布林和非 null 值作為布林參數傳遞。傳遞的任何字串、數字、陣列或物件值都會被視為 false。在此變更後，傳遞除 `true`、`false` 或 `null` 之外的任何值現在會觸發 JSON value is not of expected type 錯誤。(#26213) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 0xb10c +- 721217.xyz +- @RandyMcMillan +- amadeuszpawlik +- Amiti Uttarwar +- Andrew Chow +- Andrew Toth +- Anthony Towns +- Antoine Poinsot +- Aurèle Oulès +- Ben Woosley +- Bitcoin Hodler +- brunoerg +- Bushstar +- Carl Dong +- Chris Geihsler +- Cory Fields +- David Gumberg +- dergoegge +- Dhruv Mehta +- Dimitris Tsapakidis +- dougEfish +- Douglas Chimento +- ekzyis +- Elichai Turkel +- Ethan Heilman +- Fabian Jahr +- FractalEncrypt +- furszy +- Gleb Naumenko +- glozow +- Greg Sanders +- Hennadii Stepanov +- hernanmarino +- ishaanam +- ismaelsadeeq +- James O'Beirne +- jdjkelly@gmail.com +- Jeff Ruane +- Jeffrey Czyz +- Jeremy Rubin +- Jesse Barton +- João Barbosa +- JoaoAJMatos +- John Moffett +- Jon Atack +- Jonas Schnelli +- jonatack +- Joshua Kelly +- josibake +- Juan Pablo Civile +- kdmukai +- klementtan +- Kolby ML +- kouloumos +- Kristaps Kaupe +- laanwj +- Larry Ruane +- Leonardo Araujo +- Leonardo Lazzaro +- Luke Dashjr +- MacroFake +- MarcoFalke +- Martin Leitner-Ankerl +- Martin Zumsande +- Matt Whitlock +- Matthew Zipkin +- Michael Ford +- Miles Liu +- mruddy +- Murray Nesbitt +- muxator +- omahs +- pablomartin4btc +- Pasta +- Pieter Wuille +- Pttn +- Randall Naar +- Riahiamirreza +- roconnor-blockstream +- Russell O'Connor +- Ryan Ofsky +- S3RK +- Sebastian Falbesoner +- Seibart Nedor +- sinetek +- Sjors Provoost +- Skuli Dulfari +- SomberNight +- Stacie Waleyko +- stickies-v +- stratospher +- Suhas Daftuar +- Suriyaa Sundararuban +- TheCharlatan +- Vasil Dimov +- Vasil Stoyanov +- virtu +- w0xlt +- willcl-ark +- yancy +- Yusuf Sahin HAMZA + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2023-10-19-release-25.1.md b/_posts/zh_TW/releases/2023-10-19-release-25.1.md new file mode 100644 index 000000000..25fed9cd3 --- /dev/null +++ b/_posts/zh_TW/releases/2023-10-19-release-25.1.md @@ -0,0 +1,115 @@ +--- +title: Bitcoin Core 25.1 +id: zh_tw-release-25.1 +name: release-25.1 +permalink: /zh_TW/releases/25.1/ +excerpt: Bitcoin Core 25.1 版本現已發布 +date: 2023-10-19 +type: releases +layout: page +lang: zh_TW + +release: [25, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:aa13e74abc8e389d4271813e9d0415890f9d8058&dn=bitcoin-core-25.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +25.1 版本說明 +================== + +Bitcoin Core 25.1 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### P2P + +- #27626 Parallel compact block downloads, take 3 +- #27743 p2p: Unconditionally return when compact block status == READ_STATUS_FAILED + +### Fees + +- #27622 Fee estimation: avoid serving stale fee estimate + +### RPC + +- #27727 rpc: Fix invalid bech32 address handling + +### Rest + +- #27853 rest: fix crash error when calling /deploymentinfo +- #28551 http: bugfix: allow server shutdown in case of remote client disconnection + +### 錢包 + +- #28038 wallet: address book migration bug fixes +- #28067 descriptors: do not return top-level only funcs as sub descriptors +- #28125 wallet: bugfix, disallow migration of invalid scripts +- #28542 wallet: Check for uninitialized last processed and conflicting heights in MarkConflicted + +### Build + +- #27724 build: disable boost multi index safe mode in debug mode +- #28097 depends: xcb-proto 1.15.2 +- #28543 build, macos: Fix qt package build with new Xcode 15 linker +- #28571 depends: fix unusable memory_resource in macos qt build + +### Gui + +- gui#751 macOS, do not process actions during shutdown + +### Miscellaneous + +- #28452 Do not use std::vector = {} to release memory + +### CI + +- #27777 ci: Prune dangling images on RESTART_CI_DOCKER_BEFORE_RUN +- #27834 ci: Nuke Android APK task, Use credits for tsan +- #27844 ci: Use podman stop over podman kill +- #27886 ci: Switch to amd64 container in "ARM" task + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Abubakar Sadiq Ismail +- Andrew Chow +- Bruno Garcia +- Gregory Sanders +- Hennadii Stepanov +- MacroFake +- Matias Furszyfer +- Michael Ford +- Pieter Wuille +- stickies-v +- Will Clark + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2023-10-26-release-24.2.md b/_posts/zh_TW/releases/2023-10-26-release-24.2.md new file mode 100644 index 000000000..bb6c6b148 --- /dev/null +++ b/_posts/zh_TW/releases/2023-10-26-release-24.2.md @@ -0,0 +1,83 @@ +--- +title: Bitcoin Core 24.2 +id: zh_tw-release-24.2 +name: release-24.2 +permalink: /zh_TW/releases/24.2/ +excerpt: Bitcoin Core 24.2 版本現已發布 +date: 2023-10-26 +type: releases +layout: page +lang: zh_TW + +release: [24, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:6bde4d046f4aa794df4f3603688cb22e0a8a4a68&dn=bitcoin-core-24.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +24.2 版本說明 +================== + +Bitcoin Core 24.2 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +### Fees + +- #27622 Fee estimation: avoid serving stale fee estimate + +### RPC 和其他 API + +- #27727 rpc: Fix invalid bech32 address handling + +### 建置系統 + +- #28097 depends: xcb-proto 1.15.2 +- #28543 build, macos: Fix qt package build with new Xcode 15 linker +- #28571 depends: fix unusable memory_resource in macos qt build + +### CI + +- #27777 ci: Prune dangling images on RESTART_CI_DOCKER_BEFORE_RUN +- #27834 ci: Nuke Android APK task, Use credits for tsan +- #27844 ci: Use podman stop over podman kill +- #27886 ci: Switch to amd64 container in "ARM" task + +### Miscellaneous +- #28452 Do not use std::vector = {} to release memory + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Abubakar Sadiq Ismail +- Hennadii Stepanov +- Marco Falke +- Michael Ford +- Pieter Wuille + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2023-12-06-release-26.0.md b/_posts/zh_TW/releases/2023-12-06-release-26.0.md new file mode 100644 index 000000000..1d8ccd2ba --- /dev/null +++ b/_posts/zh_TW/releases/2023-12-06-release-26.0.md @@ -0,0 +1,274 @@ +--- +title: Bitcoin Core 26.0 +id: zh_tw-release-26.0 +name: release-26.0 +permalink: /zh_TW/releases/26.0/ +excerpt: Bitcoin Core 26.0 版本現已發布 +date: 2023-12-06 +type: releases +layout: page +lang: zh_TW + +release: [26, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:12f43c4ac1f4cddc6095c17ffb784ccf93446081&dn=bitcoin-core-26.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +26.0 版本說明 +================== + +Bitcoin Core 26.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +P2P 和網路變更 +----------------------- + +- 新增了對 [BIP324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) 中定義的 v2 傳輸協定的實驗性支援。預設為關閉，但使用 `-v2transport` 啟用時，將在每個連線的基礎上與同樣支援它的其他對等節點協商。現有的 v1 傳輸協定仍然完全支援。 + +- 具有多個可達網路的節點現在將主動嘗試至少有一個到每個網路的出站連線。這改善了對 eclipse 攻擊的個別抵抗力和對分區攻擊的網路級抵抗力。使用者不再需要採取主動措施來確保連線到多個啟用的網路。(#27213) + +修剪 +------- + +- 當使用 assumeutxo 與 `-prune` 時，如果修剪預算設定低於 1100MB（即 `MIN_DISK_SPACE_FOR_BLOCK_FILES * 2`），則可能會超過修剪預算。修剪預算通常在每個鏈狀態之間平均分配，除非每個鏈狀態的結果修剪預算低於 `MIN_DISK_SPACE_FOR_BLOCK_FILES`，在這種情況下將使用該值。(#27596) + +更新的 RPC +------------ + +- 設定 `-rpcserialversion=0` 已被棄用，將在未來版本中移除。目前仍可透過同時新增 `-deprecatedrpc=serialversion` 選項來使用。(#28448) + +- `hash_serialized_2` 值已從 `gettxoutsetinfo` 中移除，因為它計算的值包含錯誤且未考慮所有資料。它被 `hash_serialized_3` 取代，後者提供相同的功能但提供正確計算的雜湊值。(#28685) + +- 新欄位 `transport_protocol_type` 和 `session_id` 已新增到 `getpeerinfo` RPC，以指示是否使用 v2 傳輸協定，如果是，session id 是什麼。 + +- 新參數 `v2transport` 已新增到 `addnode` RPC，以指示是否嘗試與對等節點建立 v2 交易連線。 + +- [Miniscript](https://bitcoin.sipa.be/miniscript/) 表達式現在可以在 Taproot 描述符中用於所有使用描述符的 RPC。(#27255) + +- `finalizepsbt` 現在能夠最終化 PSBT，其輸入花費 [Miniscript](https://bitcoin.sipa.be/miniscript/) 相容的 Taproot 葉。(#27255) + +與錢包相關的 RPC 變更可以在下面的錢包部分找到。 + +新的 RPC +-------- + +- 已新增 `loadtxoutset`，它允許載入由 `dumptxoutset` 產生的格式的 UTXO 快照。載入此快照後，其內容將被反序列化為第二個鏈狀態資料結構，然後用於同步到網路的 tip。 + + 同時，原始鏈狀態將在背景中完成初始區塊下載過程，最終驗證到快照所基於的區塊。 + + 結果是一個可用的 bitcoind 實例，可以在幾分鐘而不是幾小時內與網路 tip 保持同步。UTXO 快照通常透過第三方來源（HTTP、torrent 等）取得，這是合理的，因為它們的內容總是透過雜湊值進行檢查。 + + 您可以在 `assumeutxo` 設計文件中找到有關此過程的更多資訊 ()。 + + 已新增 `getchainstates` 以幫助監視 assumeutxo 同步過程。 + +- 已新增新的 `getprioritisedtransactions` RPC。它返回使用者使用 prioritisetransaction 建立的所有費用增量的映射，由 txid 索引。該映射還指示每個交易是否存在於 mempool 中。(#27501) + +- 已新增新的 RPC `submitpackage`。它可用於提交原始十六進位交易列表到 mempool，以使用共識和 mempool 政策規則作為套件進行評估。這些政策包括 package CPFP，允許具有高費用的子交易將低於 mempool 最小費率（但不低於最小中繼費率）的父交易提升。(#27609) + + - 警告：成功提交並不意味著交易將在整個網路中傳播，因為不支援套件中繼。 + + - 並非所有功能都可用。套件限制為一個子交易及其所有未確認的父交易，且沒有父交易可以花費另一個父交易的輸出。此外，不支援 package RBF。有關套件政策和限制的更多詳細資訊，請參閱 doc/policy/packages.md。 + + - 此 RPC 是實驗性的。其介面可能會變更。 + +- 已新增新的 RPC `getaddrmaninfo`，用於查看節點位址管理器中不同網路（ipv4、ipv6、onion、i2p、cjdns）的新表和已嘗試表中的位址分佈。RPC 返回所有網路的新表和已嘗試表中的位址計數以及它們的總和。(#27511) + +- 已新增新的 `importmempool` RPC。它載入有效的 `mempool.dat` 檔案並嘗試將其內容新增到 mempool。這可用於從另一個節點導入 mempool 資料，而無需修改 datadir 內容且無需重新啟動節點。(#27460) + - 警告：導入不受信任的檔案很危險，特別是如果接管了檔案中的元資料。 + - 如果您想套用費用增量，建議使用 `getprioritisedtransactions` 和 `prioritisetransaction` RPC，而不是 `apply_fee_delta_priority` 選項，以避免對 mempool 中已優先處理的任何交易進行雙重優先處理。 + +更新的設定 +---------------- + +- `bitcoind` 和 `bitcoin-qt` 現在將在啟動時引發錯誤，如果正在使用的 datadir 包含將被忽略的 bitcoin.conf 檔案，這可能發生在 bitcoin.conf 檔案中使用 datadir= 行時。錯誤訊息只是一個診斷，旨在防止意外錯誤設定，並且可以停用以恢復使用 datadir 的先前行為，同時忽略其中包含的 bitcoin.conf。(#27302) + +- 傳遞無效的 `-debug`、`-debugexclude` 或 `-loglevel` 日誌設定選項現在會引發錯誤，而不是記錄容易錯過的警告。(#27632) + +與 GUI 或錢包相關的設定變更可以在下面的 GUI 或錢包部分找到。 + +新設定 +------------ + +工具和實用程式 +------------------- + +- libconsensus 中提供了新的 `bitcoinconsensus_verify_script_with_spent_outputs` 函式，可選擇接受正在驗證的交易的已花費輸出。 +- libconsensus 中提供了新的 `bitcoinconsensus_SCRIPT_FLAGS_VERIFY_TAPROOT` 旗標，將使用 Taproot 花費規則驗證腳本。 + +錢包 +------ + +- 此版本中錢包載入已變更。先前可以載入（帶有警告）的某些包含損壞記錄的錢包可能不再載入。例如，包含損壞地址簿條目的錢包可能不再載入。如果發生這種情況，建議在先前版本的 Bitcoin Core 中載入錢包並將資料導入新錢包。也請報告問題以幫助改進軟體並使錢包載入在這些情況下更加健壯。(#24914) + +- 在不同時提供 `-deprecatedrpc=create_bdb` 選項的情況下，設定 `descriptors=false` 時，`createwallet` RPC 將不再建立舊版（BDB）錢包。這是因為舊版錢包將在未來版本中被棄用。(#28597) + +- `gettransaction`、`listtransactions`、`listsinceblock` RPC 現在為所有交易返回 `abandoned` 欄位。先前，「abandoned」欄位僅為已傳送的交易返回。(#25158) + +- `listdescriptors`、`decodepsbt` 和類似的 RPC 方法現在顯示 `h` 而不是撇號（`'`）來指示強化派生。當使用 `private` 參數時不適用，該參數與產生或導入描述符時使用的標記匹配。新建立的錢包使用 `h`。此變更使手動處理描述符字串更容易。例如，`importdescriptors` RPC 呼叫最容易使用 `h` 作為標記：`'["desc": ".../0h/..."]'`。透過此變更，`listdescriptors` 將使用 `h`，因此您可以複製貼上結果，而無需新增轉義字元或手動將 `'` 切換為 'h'。請注意，這會變更描述符校驗和。對於舊版錢包，`getaddressinfo` 中的 `hdkeypath` 欄位不變，錢包轉儲的序列化格式也不變。(#26076) + +- `getbalances` RPC 現在返回 `lastprocessedblock` JSON 物件，其中包含錢包在計算餘額時處理的最後一個區塊雜湊值和高度。不應快取此結果，因為導入新密鑰可能會使其無效。(#26094) + +- `gettransaction` RPC 現在返回 `lastprocessedblock` JSON 物件，其中包含錢包在產生交易資訊時處理的最後一個區塊雜湊值和高度。(#26094) + +- `getwalletinfo` RPC 現在返回 `lastprocessedblock` JSON 物件，其中包含錢包在產生錢包資訊時處理的最後一個區塊雜湊值和高度。(#26094) + +- 幣選擇和交易建置現在考慮未確認的低費率祖先交易。當需要花費未確認的輸出時，錢包將新增費用，以確保新交易及其祖先將達到使用者請求的費率的挖礦分數。(#26152) + +- 對於接受 `options` 參數的 RPC 方法（`importmulti`、`listunspent`、`fundrawtransaction`、`bumpfee`、`send`、`sendall`、`walletcreatefundedpsbt`、`simulaterawtransaction`），現在可以將選項作為命名參數傳遞，而無需嵌套物件。(#26485) + +這意味著可以進行如下呼叫： + +```sh +src/bitcoin-cli -named bumpfee txid fee_rate=100 +``` + +而不是 + +```sh +src/bitcoin-cli -named bumpfee txid options='{"fee_rate": 100}' +``` + +- `-deprecatedrpc=walletwarningfield` 設定選項已移除。`createwallet`、`loadwallet`、`restorewallet` 和 `unloadwallet` RPC 不再返回「warning」字串欄位。相同的資訊透過在 v25.0 中新增的「warnings」欄位提供，該欄位返回字串的 JSON 陣列。「warning」字串欄位也在 v25.0 中被棄用。(#27757) + +- `signrawtransactionwithkey`、`signrawtransactionwithwallet`、`walletprocesspsbt` 和 `descriptorprocesspsbt` 呼叫現在如果其 sighashtype 參數格式錯誤，則返回更具體的 RPC_INVALID_PARAMETER 錯誤，而不是 RPC_MISC_ERROR。(#28113) + +- RPC `walletprocesspsbt` 和 `descriptorprocesspsbt` 返回物件現在包含欄位 `hex`（如果交易完整）包含適合 RPC `sendrawtransaction` 的序列化交易。(#28414) + +- 現在可以在描述符錢包的 Taproot 葉內使用 [Miniscript](https://bitcoin.sipa.be/miniscript/)。(#27255) + +描述符 +----------- + +- 已移除輸出描述符中混合公鑰的使用。混合公鑰是輸出描述符不支援的一種奇特的公鑰編碼（如 BIP380 中指定並記錄在 doc/descriptors.md 中）。Bitcoin Core 先前會錯誤地接受包含此類混合密鑰的描述符。(#28587) + +GUI 變更 +----------- + +- GUI 中的交易列表不再為「付款給自己」提供特殊類別。現在，同時具有影響錢包的輸入和輸出的交易在單獨的行上顯示為花費和接收。(gui#119) + +- 新的選單選項允許將基於儲存在 BerkeleyDB (BDB) 中的密鑰和隱含輸出腳本類型的舊版錢包遷移到使用儲存在 SQLite 中的描述符的現代錢包。(gui#738) + +- PSBT 操作對話框使用「own address」標記支付到您自己錢包的輸出。(gui#740) + +- 正在移除建立舊版錢包的能力。(gui#764) + +Contrib +------- + +- Bash 完成檔案已從 `bitcoin*.bash-completion` 重新命名為 `bitcoin*.bash`。這意味著當完成檔案放入完成目錄（使用 `pkg-config --variable=completionsdir bash-completion` 找到）時，可以根據調用的命令名稱自動按需載入完成檔案，而無需重新命名。(#28507) + +低階變更 +================= + +測試 +----- + +- 預設情況下，testnet 上現在停用非標準交易的中繼和 mempool 接受。可以透過設定 `-acceptnonstdtxn=1` 重新啟用先前的行為。(#28354) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 0xb10c +- Amiti Uttarwar +- Andrew Chow +- Andrew Toth +- Anthony Towns +- Antoine Poinsot +- Antoine Riard +- Ari +- Aurèle Oulès +- Ayush Singh +- Ben Woosley +- Brandon Odiwuor +- Brotcrunsher +- brunoerg +- Bufo +- Carl Dong +- Casey Carter +- Cory Fields +- David Álvarez Rosa +- dergoegge +- dhruv +- dimitaracev +- Erik Arvstedt +- Erik McKelvey +- Fabian Jahr +- furszy +- glozow +- Greg Sanders +- Harris +- Hennadii Stepanov +- Hernan Marino +- ishaanam +- ismaelsadeeq +- Jake Rawsthorne +- James O'Beirne +- John Moffett +- Jon Atack +- josibake +- kevkevin +- Kiminuo +- Larry Ruane +- Luke Dashjr +- MarcoFalke +- Marnix +- Martin Leitner-Ankerl +- Martin Zumsande +- Matthew Zipkin +- Michael Ford +- Michael Tidwell +- mruddy +- Murch +- ns-xvrn +- pablomartin4btc +- Pieter Wuille +- Reese Russell +- Rhythm Garg +- Ryan Ofsky +- Sebastian Falbesoner +- Sjors Provoost +- stickies-v +- stratospher +- Suhas Daftuar +- TheCharlatan +- Tim Neubauer +- Tim Ruffing +- Vasil Dimov +- virtu +- vuittont60 +- willcl-ark +- Yusuf Sahin HAMZA + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 + +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-04-02-release-26.1.md b/_posts/zh_TW/releases/2024-04-02-release-26.1.md new file mode 100644 index 000000000..45a5fc859 --- /dev/null +++ b/_posts/zh_TW/releases/2024-04-02-release-26.1.md @@ -0,0 +1,112 @@ +--- +title: Bitcoin Core 26.1 +id: zh_tw-release-26.1 +name: release-26.1 +permalink: /zh_TW/releases/26.1/ +excerpt: Bitcoin Core 26.1 版本現已發布 +date: 2024-04-02 +type: releases +layout: page +lang: zh_TW + +release: [26, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:1cae6d38169395d3e841d61c6f6afe25de2edaf9&dn=bitcoin-core-26.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +26.1 版本說明 +================== + +Bitcoin Core 26.1 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### 錢包 + +- #28994 wallet: skip BnB when SFFO is enabled +- #28920 wallet: birth time update during tx scanning +- #29176 wallet: Fix use-after-free in WalletBatch::EraseRecords +- #29510 wallet: getrawchangeaddress and getnewaddress failures should not affect keypools for descriptor wallets + +### RPC + +- #29003 rpc: fix getrawtransaction segfault +- #28784 rpc: keep .cookie file if it was not generated + +### Logs + +- #29227 log mempool loading progress + +### P2P 和網路變更 + +- #29200 net: create I2P sessions using both ECIES-X25519 and ElGamal encryption +- #29412 p2p: Don't process mutated blocks +- #29524 p2p: Don't consider blocks mutated if they don't connect to known prev block + +### Build + +- #29127 Use hardened runtime on macOS release builds. +- #29195 build: Fix -Xclang -internal-isystem option + +### CI + +- #28992 ci: Use Ubuntu 24.04 Noble for asan,tsan,tidy,fuzz +- #29080 ci: Set HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK to avoid unrelated failures +- #29610 ci: Fix "macOS native" job + +### Miscellaneous + +- #28391 refactor: Simplify CTxMempool/BlockAssembler fields, remove some external mapTx access +- #29179 test: wallet rescan with reorged parent + IsFromMe child in mempool +- #28791 snapshots: don't core dump when running -checkblockindex after loadtxoutset +- #29357 test: Drop x modifier in fsbridge::fopen call for MinGW builds +- #29529 fuzz: restrict fopencookie usage to Linux & FreeBSD + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- dergoegge +- fanquake +- furszy +- glozow +- Greg Sanders +- Hennadii Stepanov +- Jon Atack +- MarcoFalke +- Mark Friedenbach +- Martin Zumsande +- Murch +- Roman Zeyde +- stickies-v +- UdjinM6 + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-04-02-release-27.0.md b/_posts/zh_TW/releases/2024-04-02-release-27.0.md new file mode 100644 index 000000000..4552c2c26 --- /dev/null +++ b/_posts/zh_TW/releases/2024-04-02-release-27.0.md @@ -0,0 +1,189 @@ +--- +title: Bitcoin Core 27.0 +id: zh_tw-release-27.0 +name: release-27.0 +permalink: /zh_TW/releases/27.0/ +excerpt: Bitcoin Core 27.0 版本現已發布 +date: 2024-04-02 +type: releases +layout: page +lang: zh_TW + +release: [27, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:2b2d123e5e831b245fb1dc5b8b71f89de4a90d00&dn=bitcoin-core-27.0&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +27.0 版本說明 +================== + +Bitcoin Core 27.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +libbitcoinconsensus +------------------- + +- libbitcoinconsensus 已棄用，將在 v28 中移除。此程式庫已存在近 10 年，但已知的採用率或影響很小。它已成為維護負擔。 + + 底層功能在版本之間不會變更，因此程式庫的任何使用者都可以無限期地繼續使用最終版本，但要了解 Taproot 是其最終的共識更新。 + + 未來，libbitcoinkernel 將提供更有用的 API，該 API 了解 UTXO 集，因此能夠完全驗證交易和區塊。(#29189) + +mempool.dat 相容性 +------------------------- + +- 由 -persistmempool 或 savemempool RPC 建立的 `mempool.dat` 檔案將以新格式寫入。此新格式包括對交易內容進行 XOR 處理，以緩解外部程式（例如防毒軟體）嘗試解釋並可能修改檔案的問題。 + + 此新格式無法由先前的軟體版本讀取。為了允許降級，已新增臨時設定 `-persistmempoolv1` 以回退到舊格式。(#28207) + +P2P 和網路變更 +----------------------- + +- BIP324 v2 傳輸現在預設啟用。仍然可以透過使用 `-v2transport=0` 執行來停用 v2。(#29347) +- 手動連線選項（`-connect`、`-addnode` 和 `-seednode`）現在將遵循 `-v2transport` 以預設使用 v2 連線。它們將在失敗時重試 v1。(#29058) + +- 網路調整時間已從共識程式碼中移除。它被（未調整的）系統時間取代。大中位數時間偏移（70 分鐘或更長）的警告保留。這移除了需要大多數出站對等節點誠實的隱含安全假設，並增加了節點營運者確保其系統時間正確（並保持正確）以免與網路失去共識的重要性。(#28956) + +Mempool Policy 變更 +---------------------- + +- 選擇性 Topologically Restricted Until Confirmation (TRUC) Transactions 政策（又名 v3 交易政策）可在設定 `-acceptnonstdtxn=1` 時在測試網路上使用。透過將交易版本號設定為 3，TRUC 交易請求對其未確認輸出的花費施加限制。這些限制簡化了接受或替換 TRUC 交易的激勵相容性評估，從而確保任何替換對節點更有利，並使費用提升更可靠。TRUC 交易目前是非標準的，只能在放寬或停用標準性規則的測試網路上使用（例如使用 `-acceptnonstdtxn=1`）。(#28948) + +外部簽署 +---------------- + +- Windows 上的外部簽署支援已停用。一旦底層相依性（Boost Process）被不同的程式庫取代，它將重新啟用。(#28967) + +更新的 RPC +------------ + +- addnode RPC 現在遵循 `-v2transport` 選項（現在預設開啟，見上文）來建立連線。仍然可以使用 addnode 的 v2transport 參數手動指定傳輸類型。(#29239) + +建置系統 +------------ + +- 現在需要支援 C++20 的編譯器來建置 Bitcoin Core。(#28349) +- MacOS 版本設定為使用強化執行時期程式庫 (#29127) + +錢包 +------ + +- 已引入 CoinGrinder 幣選擇演算法，以減少不必要的大輸入集並降低高費率下的交易成本。CoinGrinder 搜尋權重最小的輸入集。CoinGrinder 找到的解決方案將產生找零輸出。CoinGrinder 僅在費率升高時活躍（預設：30+ sat/vB，基於 `-consolidatefeerate`×3）。(#27877) +- 當使用從輸出中減去費用功能時，Branch And Bound 幣選擇演算法將被停用。(#28994) +- 如果檢測到描述符的出生時間晚於涉及該描述符的第一筆交易，則出生時間將重置為較早的時間。(#28920) + +低階變更 +================= + +修剪 +------- + +- 在初始區塊下載期間修剪時，每次刷新將修剪更多區塊，以加快此類節點的同步速度。(#20827) + +初始化 +---- + +- 各種修正以防止 Bitcoin Core 的後續實例導致刪除現有實例正在使用的檔案的問題。(#28784, #28946) +- 改進對空 `settings.json` 檔案的處理。(#29144) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 22388o⚡️ +- Aaron Clauson +- Amiti Uttarwar +- Andrew Toth +- Anthony Towns +- Antoine Poinsot +- Ava Chow +- Brandon Odiwuor +- brunoerg +- Chris Stewart +- Cory Fields +- dergoegge +- djschnei21 +- Fabian Jahr +- fanquake +- furszy +- Gloria Zhao +- Greg Sanders +- Hennadii Stepanov +- Hernan Marino +- iamcarlos94 +- ismaelsadeeq +- Jameson Lopp +- Jesse Barton +- John Moffett +- Jon Atack +- josibake +- jrakibi +- Justin Dhillon +- Kashif Smith +- kevkevin +- Kristaps Kaupe +- L0la L33tz +- Luke Dashjr +- Lőrinc +- marco +- MarcoFalke +- Mark Friedenbach +- Marnix +- Martin Leitner-Ankerl +- Martin Zumsande +- Max Edwards +- Murch +- muxator +- naiyoma +- Nikodemas Tuckus +- ns-xvrn +- pablomartin4btc +- Peter Todd +- Pieter Wuille +- Richard Myers +- Roman Zeyde +- Russell Yanofsky +- Ryan Ofsky +- Sebastian Falbesoner +- Sergi Delgado Segura +- Sjors Provoost +- stickies-v +- stratospher +- Supachai Kheawjuy +- TheCharlatan +- UdjinM6 +- Vasil Dimov +- w0xlt +- willcl-ark + + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-04-08-release-25.2.md b/_posts/zh_TW/releases/2024-04-08-release-25.2.md new file mode 100644 index 000000000..c08221c9d --- /dev/null +++ b/_posts/zh_TW/releases/2024-04-08-release-25.2.md @@ -0,0 +1,81 @@ +--- +title: Bitcoin Core 25.2 +id: zh_tw-release-25.2 +name: release-25.2 +permalink: /zh_TW/releases/25.2/ +excerpt: Bitcoin Core 25.2 版本現已發布 +date: 2024-04-08 +type: releases +layout: page +lang: zh_TW + +release: [25, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:b9ca1b9dc82295bcba575098dffa8bb601e47ce3&dn=bitcoin-core-25.2&xl=3551532254&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +25.2 版本說明 +================== + +Bitcoin Core 25.2 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 10.15+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### Gui + +- gui#774 Fix crash on selecting "Mask values" in transaction view + +### RPC + +- #29003 rpc: fix getrawtransaction segfault + +### 錢包 + +- #29176 wallet: Fix use-after-free in WalletBatch::EraseRecords +- #29510 wallet: `getrawchangeaddress` and `getnewaddress` failures should not affect keypools for descriptor wallets + +### P2P 和網路變更 + +- #29412 p2p: Don't process mutated blocks +- #29524 p2p: Don't consider blocks mutated if they don't connect to known prev block + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Martin Zumsande +- Sebastian Falbesoner +- MarcoFalke +- UdjinM6 +- dergoegge +- Greg Sanders + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-06-17-release-27.1.md b/_posts/zh_TW/releases/2024-06-17-release-27.1.md new file mode 100644 index 000000000..ff2aaeea4 --- /dev/null +++ b/_posts/zh_TW/releases/2024-06-17-release-27.1.md @@ -0,0 +1,121 @@ +--- +title: Bitcoin Core 27.1 +id: zh_tw-release-27.1 +name: release-27.1 +permalink: /zh_TW/releases/27.1/ +excerpt: Bitcoin Core 27.1 版本現已發布 +date: 2024-06-17 +type: releases +layout: page +lang: zh_TW + +release: [27, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:9e7fa35808fee6efc004a4d3b28e5cf9ce7770f2&dn=bitcoin-core-27.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +27.1 版本說明 +===================== + +Bitcoin Core 27.1 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### Miniscript + +- #29853 sign: don't assume we are parsing a sane TapMiniscript + +### RPC + +- #29869 rpc, bugfix: Enforce maximum value for setmocktime +- #29870 rpc: Reword SighashFromStr error message +- #30094 rpc: move UniValue in blockToJSON + +### Indexes + +- #29776 Fix #29767, set m_synced = true after Commit() + +### Gui + +- #gui812 Fix create unsigned transaction fee bump +- #gui813 Don't permit port in proxy IP option + +### Test + +- #29892 test: Fix failing univalue float test + +### P2P + +- #30085 p2p: detect addnode cjdns peers in GetAddedNodeInfo() + +### Build + +- #29747 depends: fix mingw-w64 Qt DEBUG=1 build +- #29859 build: Fix false positive CHECK_ATOMIC test +- #29985 depends: Fix build of Qt for 32-bit platforms with recent glibc +- #30097 crypto: disable asan for sha256_sse4 with clang and -O0 +- #30151 depends: Fetch miniupnpc sources from an alternative website +- #30216 build: Fix building fuzz binary on on SunOS / illumos +- #30217 depends: Update Boost download link + +### Doc + +- #29934 doc: add LLVM instruction for macOS < 13 + +### CI + +- #29856 ci: Bump s390x to ubuntu:24.04 + +### Misc + +- #29691 Change Luke Dashjr seed to dashjr-list-of-p2p-nodes.us +- #30149 contrib: Renew Windows code signing certificate + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Antoine Poinsot +- Ava Chow +- Cory Fields +- dergoegge +- fanquake +- furszy +- Hennadii Stepanov +- Jon Atack +- laanwj +- Luke Dashjr +- MarcoFalke +- nanlour +- Sjors Provoost +- willcl-ark + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-07-09-release-26.2.md b/_posts/zh_TW/releases/2024-07-09-release-26.2.md new file mode 100644 index 000000000..6bf247a2f --- /dev/null +++ b/_posts/zh_TW/releases/2024-07-09-release-26.2.md @@ -0,0 +1,101 @@ +--- +title: Bitcoin Core 26.2 +id: zh_tw-release-26.2 +name: release-26.2 +permalink: /zh_TW/releases/26.2/ +excerpt: Bitcoin Core 26.2 版本現已發布 +date: 2024-07-09 +type: releases +layout: page +lang: zh_TW + +release: [26, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:9f9db55bc8fcfe0081904613a4f54cdfe306c789&dn=bitcoin-core-26.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +26.2 版本說明 +================== + +Bitcoin Core 26.2 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux kernel、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### Script + +- #29853: sign: don't assume we are parsing a sane TapMiniscript + +### P2P 和網路變更 + +- #29691: Change Luke Dashjr seed to dashjr-list-of-p2p-nodes.us +- #30085: p2p: detect addnode cjdns peers in GetAddedNodeInfo() + +### RPC + +- #29869: rpc, bugfix: Enforce maximum value for setmocktime +- #28554: bugfix: throw an error if an invalid parameter is passed to getnetworkhashps RPC +- #30094: rpc: move UniValue in blockToJSON +- #29870: rpc: Reword SighashFromStr error message + +### Build + +- #29747: depends: fix mingw-w64 Qt DEBUG=1 build +- #29985: depends: Fix build of Qt for 32-bit platforms with recent glibc +- #30151: depends: Fetch miniupnpc sources from an alternative website +- #30283: upnp: fix build with miniupnpc 2.2.8 + +### Misc + +- #29776: ThreadSanitizer: Fix #29767 +- #29856: ci: Bump s390x to ubuntu:24.04 +- #29764: doc: Suggest installing dev packages for debian/ubuntu qt5 build +- #30149: contrib: Renew Windows code signing certificate + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Antoine Poinsot +- Ava Chow +- Cory Fields +- dergoegge +- fanquake +- glozow +- Hennadii Stepanov +- Jameson Lopp +- jonatack +- laanwj +- Luke Dashjr +- MarcoFalke +- nanlour +- willcl-ark + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-10-02-release-28.0.md b/_posts/zh_TW/releases/2024-10-02-release-28.0.md new file mode 100644 index 000000000..f377e3eea --- /dev/null +++ b/_posts/zh_TW/releases/2024-10-02-release-28.0.md @@ -0,0 +1,281 @@ +--- +title: Bitcoin Core 28.0 +id: zh_tw-release-28.0 +name: release-28.0 +permalink: /zh_TW/releases/28.0/ +excerpt: Bitcoin Core 28.0 版本現已發布 +date: 2024-10-02 +type: releases +layout: page +lang: zh_TW + +release: [28, 0] + +optional_magnetlink: magnet:?xt=urn:btih:e18e92024fc9d4026cf8cdef174f03c24080fd1f&dn=bitcoin-core-28.0&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/ +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +28.0 版本說明 +================== + +Bitcoin Core 28.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +在 macOS 上執行 Bitcoin Core 二進位檔案需要自簽。 +``` +cd /path/to/bitcoin-28.0/bin +xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin +codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin +``` + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 UNIX 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +Testnet4/BIP94 支援 +----- + +已新增對 [BIP94](https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki) 中指定的 Testnet4 的支援。可以使用 `-testnet4` 選項選擇該網路，區段標頭也命名為 `[testnet4]`。 + +雖然計劃在即將發布的版本中逐步停止對 Testnet3 的支援，但在此版本中仍可透過已知選項使用 Testnet3。(#29775) + +Windows 資料目錄 +---------------------- + +Windows 上的預設資料目錄已從 `C:\Users\Username\AppData\Roaming\Bitcoin` 移至 `C:\Users\Username\AppData\Local\Bitcoin`。Bitcoin Core 將首先檢查舊目錄的存在，如果存在則繼續使用該目錄以實現向後相容性。(#27064) + +JSON-RPC 2.0 支援 +-------------------- + +JSON-RPC 伺服器現在識別 JSON-RPC 2.0 請求並嚴格遵守[規範](https://www.jsonrpc.org/specification)進行回應。詳細資訊請參閱 [JSON-RPC-interface.md](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-11-vs-20)。(#27101) + +JSON-RPC 客戶端可能需要更新以與 JSON-RPC 伺服器相容。如果發現任何相容性問題，請在 GitHub 上開啟問題。 + +libbitcoinconsensus 移除 +--------------------------- + +libbitcoin-consensus 程式庫在 27.0 中已被棄用，現已完全移除。(#29648) + +P2P 和網路變更 +----------------------- + +- 先前，如果 Bitcoin Core 正在監聽 P2P 連線（使用預設設定或透過 `bind=addr:port`），它也總是會綁定到 `127.0.0.1:8334` 以監聽 Tor 連線。即使節點不使用 Tor，也無法關閉此功能。現已變更，現在 `bind=addr:port` 僅導致綁定到 `addr:port`。綁定到 `0.0.0.0:8333` 和 `127.0.0.1:8334` 的預設行為沒有變更。 + + 如果您使用 `bind=...` 設定而沒有 `bind=...=onion`，並且依賴先前的隱含行為在 `127.0.0.1:8334` 接受傳入的 Tor 連線，您現在需要使用 `bind=... bind=127.0.0.1:8334=onion` 明確指定。(#22729) + +- 如果任何 P2P 綁定失敗，Bitcoin Core 現在將無法啟動，而不是先前只有在所有 P2P 綁定都失敗時才中止啟動的行為。(#22729) + +- UNIX domain sockets 現在可用於代理連線。將 `-onion` 或 `-proxy` 設定為帶有前綴 `unix:` 的本地 socket 路徑（例如 `-onion=unix:/home/me/torsocket`）。(#27375) + +- `-zmqpubrawblock` 和 `-zmqpubrawtx` 現在接受 UNIX socket 路徑，格式為 `-zmqpubrawtx=unix:/path/to/file` (#27679) + +- `-whitelist` 新增了「in」和「out」旗標，用於控制權限是否適用於入站連線和/或手動連線（預設：僅入站）。(#27114) + +- 費率過低的交易將機會性地與其子交易配對並作為套件提交，從而使節點能夠使用現有的交易中繼協定下載 1-parent-1-child 套件。結合其他 mempool 政策，當父交易低於 mempool 最小費率時，此變更允許有限的「package relay」。Topologically Restricted Until Confirmation (TRUC) 父交易還允許低於最小中繼費率（即支付 0 費用）。使用 `submitpackage` RPC 直接向節點提交套件。警告：此 P2P 功能是有限的（與 `submitpackage` 介面不同，不支援具有多個未確認父交易的子交易），並且在對抗性條件下尚不可靠。(#28970) + +Mempool Policy 變更 +---------------------- + +- 版本號設定為 3 的交易現在在所有網路上都被視為標準 (#29496)，並受制於 [BIP 431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki) 中描述的選擇性 Topologically Restricted Until Confirmation (TRUC) 交易政策。該政策包括對花費未確認輸出的限制 (#28948)、如果提交更具激勵相容性的後代則驅逐先前的後代 (#29306)，以及最大交易大小為 10,000vB (#29873)。這些限制簡化了接受或替換 TRUC 交易的激勵相容性評估，從而確保任何替換對節點更有利，並使費用提升更可靠。 + +- Pay To Anchor (P2A) 是一種新的標準 witness 輸出類型，用於花費，是一種新識別的輸出範本。這允許無密鑰的 anchor 輸出，具有緊湊的花費條件，在等效的 `sh(OP_TRUE)` 輸出之上具有額外的效率，以及花費交易的 txid 穩定性。 + 注意：在網路上足夠數量的節點採用此升級之前，此輸出在網路上的傳播將受到限制。(#30352) + +- 現在啟用了有限的 package RBF，其中提議的衝突套件將在 mempool 中產生大小為 2 的連接元件（又名 cluster）。所有被衝突的 cluster 必須為大小 2 或更小。(#28984) + +- `-mempoolfullrbf` 設定選項的預設值已從 0 更改為 1，即 `mempoolfullrbf=1`。(#30493) + +更新的 RPC +------------ + +- `dumptxoutset` RPC 現在以新的改進格式返回 UTXO 集轉儲。相應地，`loadtxoutset` RPC 現在期望其嘗試載入的轉儲採用此新格式。不再支援舊格式的轉儲，需要使用新格式重新建立才能使用。(#29612) + +- 已為高度 840,000 新增 AssumeUTXO mainnet 參數。這意味著 `loadtxoutset` RPC 現在可以在 mainnet 上使用該高度的匹配 UTXO 集。(#28553) + +- `getblockchaininfo`、`getmininginfo` 和 `getnetworkinfo` 中的 `warnings` 欄位現在將所有活動節點警告作為字串陣列返回，而不是單一警告。可以透過使用設定選項 `-deprecatedrpc=warnings` 執行 Bitcoin Core 來暫時恢復當前行為。(#29845) + +- 先前使用 `sendrawtransaction` RPC 並指定 UTXO 集中已存在的輸出時，會返回 RPC 錯誤代碼 `-27`，訊息為「Transaction already in block chain」。錯誤訊息已更改為「Transaction outputs already in utxo set」，以更準確地描述問題來源。(#30212) + +- `estimatesmartfee` RPC 的預設模式已從 `conservative` 更新為 `economical`，預計將減少許多使用者的過度估計，特別是如果 Replace-by-Fee 是一個選項。對於需要對費用估計有高信心但代價是可能過度估計的使用者，`conservative` 模式仍然可用。(#30275) + +- RPC `scantxoutset` 現在在「unspents」JSON 陣列中返回 2 個新欄位：`blockhash` 和 `confirmations`。詳細資訊請參閱 scantxoutset 說明。(#30515) + +- RPC `submitpackage` 現在允許傳遞 2 個新參數：`maxfeerate` 和 `maxburnamount`。詳細資訊請參閱 subtmitpackage 說明。(#28950) + +與錢包相關的 RPC 變更可以在下面的錢包部分找到。 + +更新的 REST API +----------------- +- 透過在截斷或過大的 txid 以及格式錯誤的 outpoint 索引時引發 HTTP_BAD_REQUEST「Parse error」，改進了 `/rest/getutxos` 的參數驗證。這些請求先前是靜默處理的。(#30482, #30444) + +建置系統 +------------ + +- 現在需要 GCC 11.1 或更高版本，或 Clang 16.0 或更高版本，才能編譯 Bitcoin Core。(#29091, #30263) + +- 執行 Bitcoin Core 所需的最低 glibc 現在為 2.31。這意味著不再支援 RHEL 8 和 Ubuntu 18.04 (Bionic)。(#29987) + +- 由於 lcov 版本 1 和 2 之間的不相容性，已移除 `--enable-lcov-branch-coverage`。應改用 `LCOV_OPTS` 設定任何選項。(#30192) + +更新的設定 +---------------- + +- 使用 `-alertnotify` 執行時，現在可以多次引發警報，而不僅僅是一次。先前，僅在啟用未知的新共識規則時才會引發警報。其範圍現已擴大到包括所有核心警告。具體而言，當檢測到具有大量工作量的無效鏈時，現在也會引發警報。未來可能會新增其他警告。(#30058) + +與 GUI 或錢包相關的設定變更可以在下面的 GUI 或錢包部分找到。 + +錢包 +------ + +- 錢包現在檢測錢包交易何時與 mempool 衝突。與 mempool 衝突的交易可以在 `gettransaction` 的 `"mempoolconflicts"` 欄位中看到。當父交易從 mempool 中刪除時，與 mempool 衝突的交易的輸入現在可以重新花費，而無需手動放棄交易，這可能導致錢包餘額顯示更高。(#27307) + +- RPC `fundrawtransaction`、`walletcreatefundedpsbt` 和 `send` 新增了新的 `max_tx_weight` 選項。它指定最大交易權重。如果在資助期間超過限制，則不會建立交易。預設值為 4,000,000 WU。(#29523) + +- 新的 `createwalletdescriptor` RPC 允許使用者將新的自動產生的描述符新增到其錢包。這可用於升級在引入新標準描述符（例如 taproot）之前建立的錢包。(#29130) + +- 新的 RPC `gethdkeys` 列出錢包中所有描述符使用的所有 BIP32 HD 密鑰。這些密鑰可與 `createwalletdescriptor` 結合使用，為錢包已知的特定密鑰建立並新增單一密鑰描述符到錢包。(#29130) + +- `sendall` RPC 現在可以花費未確認的找零，並將視需要包含額外費用，以使產生的交易將未確認交易的費率提升到指定的費率。(#28979) + +- 在 RPC `bumpfee` 中，如果指定了 `fee_rate`，則費率不再限制為遵循錢包的增量費率 5 sat/vb。費率仍必須至少是原始費用和 mempool 增量費率的總和。(#27969) + +GUI 變更 +----------- + +- 「Migrate Wallet」選單允許使用者遷移其錢包目錄中的任何舊版錢包，無論載入的錢包為何。(gui#824) + +- 「Information」視窗現在顯示最大 mempool 大小以及 mempool 使用量。(gui#825) + +低階變更 +================= + +測試 +----- + +- BIP94 timewarp 攻擊緩解現在在 `regtest` 網路上活躍。(#30681) + +- `test_bitcoin` 新增了新的 `-testdatadir` 選項，允許指定單元測試資料目錄的位置。(#26564) + +區塊儲存 +------------ + +- 區塊檔案現在預設使用儲存在 blocksdir 中的密鑰進行 XOR 處理。先前版本的 Bitcoin Core 或先前的外部軟體將無法讀取具有非零 XOR 密鑰的 blocksdir。有關更多詳細資訊，請參閱 `-blocksxor` 說明。(#28052) + +鏈狀態 +---------- + +- 修剪區塊時發生的鏈狀態資料庫刷新將不再清空資料庫快取。快取將保持更長時間填充，這顯著縮短了初始區塊下載完成的時間。(#28280) + +相依性 +------------ + +- 對 Boost.Process 的相依性已被 cpp-subprocess 取代，後者包含在原始碼中。建置者將不再需要 Boost.Process 來建置外部簽署者支援。(#28981) + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： +- 0xb10c +- Alfonso Roman Zubeldia +- Andrew Toth +- AngusP +- Anthony Towns +- Antoine Poinsot +- Anton A +- Ava Chow +- Ayush Singh +- Ben Westgate +- Brandon Odiwuor +- brunoerg +- bstin +- Charlie +- Christopher Bergqvist +- Cory Fields +- crazeteam +- Daniela Brozzoni +- David Gumberg +- dergoegge +- Edil Medeiros +- Epic Curious +- Fabian Jahr +- fanquake +- furszy +- glozow +- Greg Sanders +- hanmz +- Hennadii Stepanov +- Hernan Marino +- Hodlinator +- ishaanam +- ismaelsadeeq +- Jadi +- Jon Atack +- josibake +- jrakibi +- kevkevin +- kevkevinpal +- Konstantin Akimov +- laanwj +- Larry Ruane +- Lőrinc +- Luis Schwab +- Luke Dashjr +- MarcoFalke +- marcofleon +- Marnix +- Martin Saposnic +- Martin Zumsande +- Matt Corallo +- Matthew Zipkin +- Matt Whitlock +- Max Edwards +- Michael Dietz +- Murch +- nanlour +- pablomartin4btc +- Peter Todd +- Pieter Wuille +- @RandyMcMillan +- RoboSchmied +- Roman Zeyde +- Ryan Ofsky +- Sebastian Falbesoner +- Sergi Delgado Segura +- Sjors Provoost +- spicyzboss +- StevenMia +- stickies-v +- stratospher +- Suhas Daftuar +- sunerok +- tdb3 +- TheCharlatan +- umiumi +- Vasil Dimov +- virtu +- willcl-ark + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2024-11-04-release-27.2.md b/_posts/zh_TW/releases/2024-11-04-release-27.2.md new file mode 100644 index 000000000..b4a62856d --- /dev/null +++ b/_posts/zh_TW/releases/2024-11-04-release-27.2.md @@ -0,0 +1,99 @@ +--- +title: Bitcoin Core 27.2 +id: zh_tw-release-27.2 +name: release-27.2 +permalink: /zh_TW/releases/27.2/ +excerpt: Bitcoin Core 27.2 版本現已發布 +date: 2024-11-04 +type: releases +layout: page +lang: zh_TW + +release: [27, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:f21febdf8c54d2a9b09ed54f7eebb909537fb7b0&dn=bitcoin-core-27.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +27.2 版本說明 +===================== + +Bitcoin Core 27.2 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### P2P + +- #30394 net: fix race condition in self-connect detection + +### Init + +- #30435 init: change shutdown order of load block thread and scheduler + +### RPC + +- #30357 Fix cases of calls to FillPSBT errantly returning complete=true + +### PSBT + +- #29855 psbt: Check non witness utxo outpoint early + +### Test + +- #30552 test: fix constructor of msg_tx + +### Doc + +- #30504 doc: use proper doxygen formatting for CTxMemPool::cs + +### Build + +- #30283 upnp: fix build with miniupnpc 2.2.8 +- #30633 Fixes for GCC 15 compatibility + +### CI + +- #30193 ci: move ASan job to GitHub Actions from Cirrus CI +- #30299 ci: remove unused bcc variable from workflow + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Ava Chow +- Cory Fields +- Martin Zumsande +- Matt Whitlock +- Max Edwards +- Sebastian Falbesoner +- Vasil Dimov +- willcl-ark + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-01-09-release-28.1.md b/_posts/zh_TW/releases/2025-01-09-release-28.1.md new file mode 100644 index 000000000..023c90901 --- /dev/null +++ b/_posts/zh_TW/releases/2025-01-09-release-28.1.md @@ -0,0 +1,110 @@ +--- +title: Bitcoin Core 28.1 +id: zh_tw-release-28.1 +name: release-28.1 +permalink: /zh_TW/releases/28.1/ +excerpt: Bitcoin Core 28.1 版本現已發布 +date: 2025-01-09 +type: releases +layout: page +lang: zh_TW + +release: [28, 1] + +optional_magnetlink: "magnet:?xt=urn:btih:60837ded9c7e11b2a44f2ae7bc8e6fe3a3d7ee5c&dn=bitcoin-core-28.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +28.1 版本說明 +===================== + +Bitcoin Core 28.1 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +在 macOS 上執行 Bitcoin Core 二進位檔案需要自簽。 +``` +cd /path/to/bitcoin-28.x/bin +xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin +codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin +``` + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 UNIX 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### P2P + +- 當使用 `-port` 設定選項時，預設的 onion 監聽連接埠現在將衍生為該連接埠 + 1，而不是設定為固定值（在 mainnet 上為 8334）。這重新允許使用不同 `-port` 且未使用 `-bind` 的多個本地節點設定，在 v28.0 中這會因連接埠衝突而導致啟動失敗。 + + 請注意，如果與 `-port` 選項一起使用，在 `torrc` 中手動設定的 `HiddenServicePort` 可能需要調整。 + 例如，如果您使用非標準值 `-port=5555` 且未使用 `-bind=...=onion`，先前 Bitcoin Core 會在 `127.0.0.1:8334` 上監聽傳入的 Tor 連線。 + 現在它會在 `127.0.0.1:5556`（`-port` 加一）上監聽。如果您現在在 torrc 中手動設定了隱藏服務，則必須將其從 `HiddenServicePort 8333 127.0.0.1:8334` 更改為 `HiddenServicePort 8333 127.0.0.1:5556`，或使用 `-bind=127.0.0.1:8334=onion` 設定 bitcoind 以獲得先前的行為。 + (#31223) +- #30568 addrman: change internal id counting to int64_t + +### Key + +- #31166 key: clear out secret data in DecodeExtKey + +### Build + +- #31013 depends: For mingw cross compile use `-gcc-posix` to prevent library conflict +- #31502 depends: Fix CXXFLAGS on NetBSD + +### Test + +- #31016 test: add missing sync to feature_fee_estimation.py +- #31448 fuzz: add cstdlib to FuzzedDataProvider +- #31419 test: fix MIN macro redefinition +- #31563 rpc: Extend scope of validation mutex in generateblock + +### Doc + +- #31007 doc: add testnet4 section header for config file + +### CI + +- #30961 ci: add LLVM_SYMBOLIZER_PATH to Valgrind fuzz job + +### Misc + +- #31267 refactor: Drop deprecated space in `operator""_mst` +- #31431 util: use explicit cast in MultiIntBitSet::Fill() + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- fanquake +- Hennadii Stepanov +- laanwj +- MarcoFalke +- Martin Zumsande +- Marnix +- Sebastian Falbesoner + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-04-14-release-29.0.md b/_posts/zh_TW/releases/2025-04-14-release-29.0.md new file mode 100644 index 000000000..82d647787 --- /dev/null +++ b/_posts/zh_TW/releases/2025-04-14-release-29.0.md @@ -0,0 +1,239 @@ +--- +title: Bitcoin Core 29.0 +id: zh_tw-release-29.0 +name: release-29.0 +permalink: /zh_TW/releases/29.0/ +excerpt: Bitcoin Core 29.0 版本現已發布 +date: 2025-04-14 +type: releases +layout: page +lang: zh_TW + +release: [29, 0] + +optional_magnetlink: "magnet:?xt=urn:btih:c2ebe360dc7e85d9850196ea57712c8ddffbcd59&dn=bitcoin-core-29.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +29.0 版本說明 +================== +Bitcoin Core 29.0 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 13+ 和 Windows 10+ 的作業系統上受到支援和測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### P2P 和網路變更 + +- 已停止對 UPnP 的支援。如果您想自動開啟連接埠，請考慮改用 `-natpmp` 選項，該選項根據路由器支援使用 PCP 或 NAT-PMP。(#31130) + +- libnatpmp 已被內建的 PCP 和 NAT-PMP 實作取代（仍使用 `-natpmp` 選項啟用）。這支援自動 IPv4 連接埠轉送以及 IPv6 pinholing。(#30043) + +- 當使用 `-port` 設定選項時，預設的 onion 監聽連接埠現在將衍生為該連接埠 + 1，而不是設定為固定值（在 mainnet 上為 8334）。這重新允許使用不同 `-port` 且未使用 `-bind` 的多個本地節點設定，在 v28.0 中這會因連接埠衝突而導致啟動失敗。 +請注意，如果與 `-port` 選項一起使用，在 `torrc` 中手動設定的 `HiddenServicePort` 可能需要調整。 +例如，如果您使用非標準值 `-port=5555` 且未使用 `-bind=...=onion`，先前 Bitcoin Core 會在 `127.0.0.1:8334` 上監聽傳入的 Tor 連線。現在它會在 `127.0.0.1:5556`（`-port` 加一）上監聽。如果您現在在 torrc 中手動設定了隱藏服務，則必須將其從 `HiddenServicePort 8333 127.0.0.1:8334` 更改為 `HiddenServicePort 8333 127.0.0.1:5556`，或使用 `-bind=127.0.0.1:8334=onion` 設定 bitcoind 以獲得先前的行為。 +(#31223) + +- 在收到 orphan transaction（花費未知輸入的未確認交易）時，節點將嘗試從所有宣告該 orphan 的對等節點下載缺失的父交易。此變更可能會增加頻寬使用量，但使 orphan 處理更可靠。(#31397) + +### Mempool Policy 和挖礦變更 + +- Ephemeral dust 是一個新概念，允許交易中有單一 dust 輸出，前提是該交易為零費用。為了花費此交易中的任何未確認輸出，花費者除了任何其他所需輸出外，還必須花費此 dust。換句話說，此類型的交易應該在交易套件中建立，其中 dust 同時被建立和花費。(#30239) + +- 由於一個錯誤，固定大小區塊標頭、交易計數和 coinbase 交易的預設區塊保留權重（`4,000 WU`）被保留了兩次且無法降低。因此，總保留權重始終為 `8,000 WU`，這意味著即使指定高於預設值的 `-blockmaxweight`（甚至達到最大 `4,000,000 WU`），實際區塊大小也永遠不會超過 `3,992,000 WU`。 +此修正將保留整合到單一位置，並引入新的啟動選項 `-blockreservedweight`，直接指定保留權重。`-blockreservedweight` 的預設值設定為 `8,000 WU`，以確保依賴先前 `-blockmaxweight` 行為的使用者的向後相容性。 +`-blockreservedweight` 的最小值設定為 `2,000 WU`。將 `-blockreservedweight` 設定為低於預設值的使用者應確保其區塊標頭、交易計數和 coinbase 交易的總權重不超過減少的值，否則可能會冒險挖掘無效區塊。(#31384) + +### 更新的 RPC + +- RPC `testmempoolaccept` 回應現在在某些情況下包含 `reject-details` 欄位，類似於 `sendrawtransaction` 返回的完整錯誤訊息 (#28121) + +- 使用 `submitblock` 提交的重複區塊現在將保留其區塊資料，即使它先前已被修剪。如果啟用修剪，一旦選擇保留資料的區塊檔案進行修剪，該資料最終將再次被修剪。這與 `getblockfrompeer` 的行為一致，即使在修剪時也會保留區塊。(#31175) + +- `getmininginfo` 現在返回 `nBits` 和 `target` 欄位中的當前目標。它還返回一個 `next` 物件，指定下一個區塊的 `height`、`nBits`、`difficulty` 和 `target`。(#31583) + +- `getblock` 和 `getblockheader` 現在在 `target` 欄位中返回當前目標 (#31583) + +- `getblockchaininfo` 和 `getchainstates` 現在在 `target` 欄位中返回 `nBits` 和當前目標 (#31583) + +- `getblocktemplate` RPC 的 `curtime`（BIP22）和 `mintime`（BIP23）欄位現在在所有網路上考慮 BIP94 中提議的 timewarp 修正。這確保在主網上啟用 timewarp 修正軟分叉時，未升級的礦工不會意外違反 timewarp 規則。(#31376, #31600) +提醒一下，使用 `getblocktemplate` RPC 的任何軟體都必須考慮這些值（`curtime` 或 `mintime` 都可以）。在某些情況下，僅依賴時鐘可能會導致無效區塊，特別是在部署 timewarp 修正後。(#31600) + +### 新的 RPC + +- `getdescriptoractivity` 可用於在一組指定的區塊中尋找與給定描述符集合相關的所有花費/接收活動。此呼叫可與 `scanblocks` 一起使用，以減少對額外索引程式的需求。(#30708) + +### 更新的 REST API + +- `GET /rest/block/.json` 和 `GET /rest/headers/.json` 現在在 `target` 欄位中返回當前目標 + +### 更新的設定 + +- 由於最近 UTXO 集的增長，`-dbcache` 設定選項的最大允許值已降低。請注意，在此變更之前，大的 `-dbcache` 值會自動減少到 16 GiB（在 32 位元系統上為 1 GiB）。(#28358) + +- 對否定的 `-noseednode`、`-nobind`、`-nowhitebind`、`-norpcbind`、`-norpcallowip`、`-norpcwhitelist`、`-notest`、`-noasmap`、`-norpcwallet`、`-noonlynet` 和 `-noexternalip` 選項的處理已變更。先前否定這些選項會有各種令人困惑且未記錄的副作用。現在否定它們只是重置設定並恢復預設行為，就像未指定選項一樣。 + +- 從 v28.0 開始，`-mempoolfullrbf` 啟動選項預設設定為 `1`。隨著此政策的廣泛採用，使用者不再從停用它中受益，因此已移除該選項，使 full replace-by-fee 成為標準行為。(#30592) + +- 設定 `-upnp` 現在會記錄警告並被解釋為 `-natpmp`。請考慮直接使用 `-natpmp`。(#31130, #31916) + +- 作為安全檢查，當 `-blockreservedweight` 初始化參數值低於 `2000` 權重單位時，Bitcoin Core 將**無法啟動**。如果 `-blockmaxweight` 或 `-blockreservedweight` 初始化參數超過共識限制 `4,000,000 WU`，Bitcoin Core 也將**無法啟動**。 + +- 傳遞 `-debug=0` 或 `-debug=none` 現在的行為類似於 `-nodebug`：先前設定的除錯類別將被清除，但後續的 `-debug` 選項仍將被套用。 + +- `-rpcthreads` 的預設值已從 4 更改為 16，`-rpcworkqueue` 的預設值已從 16 更改為 64。(#31215) + +### 建置系統 + +建置系統已從 Autotools 遷移到 CMake： + +- 所需的最低 CMake 版本為 3.22。 + +- 不允許原始碼內建置。當使用根原始碼樹中的子目錄作為建置目錄時，建議其名稱包含子字串「build」。 + +- CMake 變數可用於設定建置系統。**某些預設值已變更。** 例如，您現在需要新增 `-DWITH_ZMQ=ON` 來建置 zmq，並新增 `-DBUILD_GUI=ON` 來建置 `bitcoin-qt`。詳細資訊請參閱 [Autotools to CMake Options Mapping](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Autotools-to-CMake-Options-Mapping)。 + +- 對於單一設定產生器，預設建置設定（`CMAKE_BUILD_TYPE`）為「RelWithDebInfo」。但是，對於「Release」設定，CMake 預設使用編譯器最佳化旗標 `-O3`，該旗標尚未在 Bitcoin Core 上進行廣泛測試。因此，建置系統將其替換為 `-O2`。 + +- 預設情況下，建置的可執行檔和程式庫位於建置目錄的 `bin/` 和 `lib/` 子目錄中。 + +- 建置系統支援基於元件的安裝。可安裝元件的名稱與建置目標名稱一致。例如： + +``` +cmake -B build +cmake --build build --target bitcoind +cmake --install build --component bitcoind +``` + +- 如果您在基於 Autotools 的建置過程中使用了任何 `CPPFLAGS`、`CFLAGS`、`CXXFLAGS` 或 `LDFLAGS` 環境變數，您應該改用相應的 CMake 變數（`APPEND_CPPFLAGS`、`APPEND_CFLAGS`、`APPEND_CXXFLAGS` 和 `APPEND_LDFLAGS`）。或者，如果您選擇使用專用的 `CMAKE_<...>_FLAGS` 變數，則必須確保產生的編譯器或連結器呼叫符合預期。 + +有關設定和使用 CMake 的更詳細指導，請參閱官方 [CMake documentation](https://cmake.org/cmake/help/latest/) 和 [CMake's User Interaction Guide](https://cmake.org/cmake/help/latest/guide/user-interaction/index.html)。此外，請參閱特定於平台的 `doc/build-*.md` 建置指南，以獲取針對您作業系統的說明。 + +## 低階變更 + +### 工具和實用程式 + +- 新工具 [`utxo_to_sqlite.py`](https://github.com/bitcoin/bitcoin/blob/v29.0/contrib/utxo-tools/utxo_to_sqlite.py) 將壓縮序列化的 UTXO 快照（如使用 `dumptxoutset` RPC 建立）轉換為 SQLite3 資料庫。有關更多詳細資訊，請參閱腳本的 `--help` 輸出。(#27432) + +### 測試 + +- BIP94 timewarp 攻擊緩解（為 testnet4 設計）在 regtest 網路上不再活躍。(#31156) + +### 相依性 + +- MiniUPnPc 和 libnatpmp 已作為相依性移除 (#31130, #30043)。 + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 0xb10c +- Adlai Chandrasekhar +- Afanti +- Alfonso Roman Zubeldia +- am-sq +- Andre +- Andre Alves +- Anthony Towns +- Antoine Poinsot +- Ash Manning +- Ava Chow +- Boris Nagaev +- Brandon Odiwuor +- brunoerg +- Chris Stewart +- Cory Fields +- costcould +- Daniel Pfeifer +- Daniela Brozzoni +- David Gumberg +- dergoegge +- epysqyli +- espi3 +- Eval EXEC +- Fabian Jahr +- fanquake +- furszy +- Gabriele Bocchi +- glozow +- Greg Sanders +- Gutflo +- Hennadii Stepanov +- Hodlinator +- i-am-yuvi +- ion- +- ismaelsadeeq +- Jadi +- James O'Beirne +- Jeremy Rand +- Jon Atack +- jurraca +- Kay +- kevkevinpal +- l0rinc +- laanwj +- Larry Ruane +- Lőrinc +- Maciej S. Szmigiero +- Mackain +- MarcoFalke +- marcofleon +- Marnix +- Martin Leitner-Ankerl +- Martin Saposnic +- Martin Zumsande +- Matthew Zipkin +- Max Edwards +- Michael Dietz +- naiyoma +- Nicola Leonardo Susca +- omahs +- pablomartin4btc +- Pieter Wuille +- Randall Naar +- RiceChuan +- rkrux +- Roman Zeyde +- Ryan Ofsky +- Sebastian Falbesoner +- secp512k2 +- Sergi Delgado Segura +- Simon +- Sjors Provoost +- stickies-v +- Suhas Daftuar +- tdb3 +- TheCharlatan +- tianzedavid +- Torkel Rogstad +- Vasil Dimov +- wgyt +- willcl-ark +- yancy + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-06-26-release-28.2.md b/_posts/zh_TW/releases/2025-06-26-release-28.2.md new file mode 100644 index 000000000..c35725349 --- /dev/null +++ b/_posts/zh_TW/releases/2025-06-26-release-28.2.md @@ -0,0 +1,93 @@ +--- +title: Bitcoin Core 28.2 +id: zh_tw-release-28.2 +name: release-28.2 +permalink: /zh_TW/releases/28.2/ +excerpt: Bitcoin Core 28.2 版本現已發布 +date: 2025-06-26 +type: releases +layout: page +lang: zh_TW + +release: [28, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:7afc299da40a45400e560d535324c7147fc47a20&dn=bitcoin-core-28.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +28.2 版本說明 +===================== + +Bitcoin Core 28.2 版本現已發布，可從以下位置下載： + + + +此版本包含新功能、各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 UNIX 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### Build + +- #31407 guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries +- #31500 depends: Fix compiling libevent package on NetBSD +- #31627 depends: Fix spacing issue +- #32070 build: use make < 3.82 syntax for define directive +- #32439 guix: accomodate migration to codeberg +- #32568 depends: use "mkdir -p" when installing xproto +- #32693 depends: fix cmake compatibility error for freetype + +### Test + +- #32286 test: Handle empty string returned by CLI as None in RPC tests +- #32336 test: Suppress upstream -Wduplicate-decl-specifier in bpfcc + +### Tracing + +- #31623 tracing: Rename the MIN macro to TRACEPOINT_TEST_MIN in log_raw_p2p_msgs + +### Doc + +- #32003 doc: remove note about macOS self-signing + +### Misc + +- #31611 doc: upgrade license to 2025 +- #32187 refactor: Remove spurious virtual from final ~CZMQNotificationInterface + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： +- 0xB10C +- achow101 +- Brandon Odiwuor +- fanquake +- Hennadii Stepanov +- josibake +- kehiy +- MarcoFalke +- Sjors Provoost + +以及所有在 [Transifex](https://www.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-09-04-release-29.1.md b/_posts/zh_TW/releases/2025-09-04-release-29.1.md new file mode 100644 index 000000000..17d00e94a --- /dev/null +++ b/_posts/zh_TW/releases/2025-09-04-release-29.1.md @@ -0,0 +1,218 @@ +--- +title: Bitcoin Core 29.1 +id: zh_tw-release-29.1 +name: release-29.1 +permalink: /zh_TW/releases/29.1/ +excerpt: Bitcoin Core 29.1 版本現已發布 +date: 2025-09-04 +type: releases +layout: page +lang: zh_TW + +release: [29, 1] + +optional_magnetlink: magnet:?xt=urn:btih:1ca988bcac73e4b47c9929ff5cf20a9f0d4a77e0&dn=bitcoin-core-29.1&xl=3644537532&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/ +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +29.1 版本說明 +===================== +Bitcoin Core 29.1 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 13+ 和 Windows 10+ 的作業系統上受到支援和測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### Mempool Policy + +- 單一標準交易中可能執行的 legacy signature operations 的最大數量現在限制為 2500。所有先前輸出腳本、所有輸入腳本，以及所有 P2SH redeem scripts（如果有）中的 signature operations 都會計入此限制。假設此新限制不會影響任何已知的典型標準交易。此變更是為未來可能部署 BIP54 做準備。 + +- #32521 policy: make pathological transactions packed with legacy sigops non-standard + +- 最小區塊費率（`-blockmintxfee`）已更改為每 kvB 1 satoshi。仍可使用設定選項進行更改。 + +- 預設最小中繼費率（`-minrelaytxfee`）和增量中繼費率（`-incrementalrelayfee`）已更改為每 kvB 100 satoshis。仍可使用各自的設定選項進行更改，但如果決定更改，建議同時更改兩者。 + - 其他最小費率（例如 dust feerate、費用估算器返回的最小值，以及錢包使用的所有費率）保持不變。mempool 最小費率仍會根據高流量而變化。 + - 請注意，除非這些較低的預設值在整個網路中被廣泛採用，否則不保證使用較低費率建立的交易能夠傳播或確認。錢包費率保持不變；在嘗試使用錢包建立較低費率的交易之前，必須更改 `-mintxfee`。 + +- #33106 policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee + +### Logging + +無條件寫入磁碟的日誌現在透過給每個來源位置每小時 1MiB 的配額來進行速率限制。無條件日誌是指日誌級別高於 debug 的任何日誌，即 `info`、`warning` 和 `error`。如果至少有一個來源位置目前被抑制，所有日誌都將以 `[*]` 為前綴。(#32604) + +當啟用 `-logsourcelocations` 時，日誌輸出現在包含整個函式簽名，而不僅僅是函式名稱。(#32604) + +### RPC + +- `dumptxoutset` RPC 現在需要指定 `type` 參數。若要維持 v29.0 之前的行為，請使用 `latest` 參數。此變更在 v29.0 版本說明中遺漏記錄。(#30808) + +### Updated Settings + +- 在 32 位元系統上，`-maxmempool` 和 `-dbcache` 啟動參數現在分別上限為 500MB 和 1GiB。 + +- #32530 node: cap -maxmempool and -dbcache values for 32-bit + +### Wallet + +- #31757 wallet: fix crash on double block disconnection +- #32553 wallet: Fix logging of wallet version + +### P2P + +- #32826 p2p: add more bad ports + +### Test + +- #32069 test: fix intermittent failure in wallet_reorgsrestore.py +- #32286 test: Handle empty string returned by CLI as None in RPC tests +- #32312 test: Fix feature_pruning test after nTime typo fix +- #32336 test: Suppress upstream -Wduplicate-decl-specifier in bpfcc +- #32463 test: fix an incorrect feature_fee_estimation.py subtest +- #32483 test: fix two intermittent failures in wallet_basic.py +- #32630 test: fix sync function in rpc_psbt.py +- #32765 test: Fix list index out of range error in feature_bip68_sequence.py +- #32742 test: fix catchup loop in outbound eviction functional test +- #32823 test: Fix wait_for_getheaders() call in test_outbound_eviction_blocks_relay_only() +- #32833 test: Add msgtype to msg_generic slots +- #32841 feature_taproot: sample tx version border values more +- #32850 test: check P2SH sigop count for coinbase tx +- #32859 test: correctly detect nonstd TRUC tx vsize in feature_taproot +- #33001 test: Do not pass tests on unhandled exceptions + +### Indexes + +- #33212 index: Don't commit state in BaseIndex::Rewind + +### Util + +- #32248 Remove support for RNDR/RNDRRS for aarch64 + +### Build + +- #32356 cmake: Respect user-provided configuration-specific flags +- #32437 crypto: disable ASan for sha256_sse4 with Clang +- #32469 cmake: Allow WITH_DBUS on all Unix-like systems +- #32439 guix: accomodate migration to codeberg +- #32551 cmake: Add missed SSE41_CXXFLAGS +- #32568 depends: use "mkdir -p" when installing xproto +- #32678 guix: warn and abort when SOURCE_DATE_EPOCH is set +- #32690 depends: fix SHA256SUM command on OpenBSD (use GNU mode output) +- #32716 depends: Override host compilers for FreeBSD and OpenBSD +- #32760 depends: capnp 1.2.0 +- #32798 build: add root dir to CMAKE_PREFIX_PATH in toolchain +- #32805 cmake: Use HINTS instead of PATHS in find_* commands +- #32814 cmake: Explicitly specify Boost_ROOT for Homebrew's package +- #32837 depends: fix libevent _WIN32_WINNT usage +- #32943 depends: Force CMAKE_EXPORT_NO_PACKAGE_REGISTRY=TRUE +- #32954 cmake: Drop no longer necessary "cmakeMinimumRequired" object +- #33073 guix: warn SOURCE_DATE_EPOCH set in guix-codesign + +### Gui + +- #864 Crash fix, disconnect numBlocksChanged() signal during shutdown +- #868 Replace stray tfm::format to cerr with qWarning + +### Doc + +- #32333 doc: Add missing top-level description to pruneblockchain RPC +- #32353 doc: Fix fuzz test_runner.py path +- #32389 doc: Fix test_bitcoin path +- #32607 rpc: Note in fundrawtransaction doc, fee rate is for package +- #32679 doc: update tor docs to use bitcoind binary from path +- #32693 depends: fix cmake compatibility error for freetype +- #32696 doc: make -DWITH_ZMQ=ON explicit on build-unix.md +- #32708 rpc, doc: update listdescriptors RCP help +- #32711 doc: add missing packages for BSDs (cmake, gmake, curl) to depends/README.md +- #32719 doc, windows: CompanyName "Bitcoin" => "Bitcoin Core project" +- #32776 doc: taproot became always active in v24.0 +- #32777 doc: fix Transifex 404s +- #32846 doc: clarify that the "-j N" goes after the "--build build" part +- #32858 doc: Add workaround for vcpkg issue with paths with embedded spaces +- #33070 doc/zmq: fix unix socket path example +- #33088 doc: move cmake -B build -LH up in Unix build docs +- #33133 rpc: fix getpeerinfo ping duration unit docs +- #33119 rpc: Fix 'getdescriptoractivity' RPCHelpMan, add test to verify fix +- #33236 doc: Remove wrong and redundant doxygen tag + +### CI + +- #32184 ci: Add workaround for vcpkg's libevent package +- #33261 ci: return to using dash in CentOS job + +### Misc + +- #32187 refactor: Remove spurious virtual from final ~CZMQNotificationInterface +- #32454 tracing: fix invalid argument in mempool_monitor +- #32771 contrib: tracing: Fix read of pmsg_type in p2p_monitor.py +- #33086 contrib: [tracing] fix pointer argument handling in mempool_monitor.py + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- 0xB10C +- achow101 +- Antoine Poinsot +- benthecarman +- bigspider +- Brandon Odiwuor +- brunoerg +- Bufo +- Christewart +- Crypt-iQ +- davidgumberg +- deadmanoz +- dergoegge +- enirox001 +- fanquake +- furszy +- glozow +- instagibbs +- Hennadii Stepanov +- hodlinator +- ismaelsadeeq +- jb55 +- jlopp +- josibake +- laanwj +- luisschwab +- MarcoFalke +- Martin Zumsande +- monlovesmango +- nervana21 +- pablomartin4btc +- rkrux +- romanz +- ryanofsky +- Sjors +- theStack +- willcl-ark +- zaidmstrr + +以及所有在 [Transifex](https://explore.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-10-10-release-30.0.md b/_posts/zh_TW/releases/2025-10-10-release-30.0.md new file mode 100644 index 000000000..ce9505bb8 --- /dev/null +++ b/_posts/zh_TW/releases/2025-10-10-release-30.0.md @@ -0,0 +1,331 @@ +--- +title: Bitcoin Core 30.0 +id: zh_tw-release-30.0 +name: release-30.0 +permalink: /zh_TW/releases/30.0/ +excerpt: Bitcoin Core 30.0 版本現已發布 +date: 2025-10-10 +type: releases +layout: page +lang: zh_TW + +## Use a YAML array for the version number to allow other parts of the +## site to correctly sort in "natural sort of version numbers". +## Use the same number of elements as decimal places, e.g. "0.1.2 => [0, +## 1, 2]" versus "1.2 => [1, 2]" +release: [30, 0] + +## Optional magnet link. To get it, open the torrent in a good BitTorrent client +## and View Details, or install the transmission-cli Debian/Ubuntu package +## and run: transmission-show -m +# +## Link should be enclosed in quotes and start with: "magnet:? +optional_magnetlink: "magnet:?xt=urn:btih:503f19ccf3347fb0045a18ac5c90b7b3ec33264a&dn=bitcoin-core-30.0&xl=5100393877&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/ +" + +# Note: it is recommended to check all links to ensure they use +# absolute urls (https://github.com/bitcoin/bitcoin/doc/foo) +# rather than relative urls (/bitcoin/bitcoin/doc/foo). +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +30.0 版本發行說明 +================== +Bitcoin Core v30.0 版本現已可從以下位址取得： + + + +此版本包含新功能、各種錯誤修復和性能改進，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +要接收安全和更新通知，請訂閱： + + + +隨著此新主要版本的發布，`27.x` 及更舊版本已達「生命週期終止」，將不再接收更新。 + +根據安全政策，我們將在兩週內披露： + +* `28.0` 中修復的中度和高嚴重性漏洞。沒有此類漏洞。 + +* `30.0` 中修復的低嚴重性漏洞。有 5 個此類漏洞。 + +如何升級 +============== + +如果您正在執行較舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（Windows）或直接覆蓋 `/Applications/Bitcoin-Qt`（macOS）或 `bitcoind`/`bitcoin-qt`（Linux）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果資料目錄需要遷移，可能需要一些時間。Bitcoin Core 的舊錢包版本通常都受支援。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 13+ 和 Windows 10+ 的作業系統上受到支援和測試。Bitcoin Core 也應該在大多數其他類 Unix 系統上運作，但在這些系統上測試的頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +政策 +------ + +- 單一標準交易中可能執行的舊版簽名操作數量上限現在限制為 2500。所有先前輸出腳本、所有輸入腳本以及所有 P2SH redeem 腳本（如果有）中的簽名操作都計入此限制。新限制預計不會影響任何已知的典型標準交易。此變更是為了準備未來可能的 BIP54 部署。(#32521) + +- `-datacarriersize` 預設增加到 100,000，這實際上取消了限制（因為會先達到最大交易大小限制）。可以使用 `-datacarriersize=83` 覆蓋以恢復到先前版本中強制執行的限制。(#32406) + +- 現在允許交易中包含多個資料載體（OP_RETURN）輸出進行中繼和挖礦。`-datacarriersize` 限制適用於交易中所有此類輸出的 scriptPubKey 的總大小，不包括 scriptPubKey 大小本身。(#32406) + +- 最小區塊手續費率（`-blockmintxfee`）已變更為每 vB 0.001 聰。仍可使用配置選項變更。礦工可使用此選項設定新增到區塊模板的套件的最小手續費率。(#33106) + +- 預設最小中繼手續費率（`-minrelaytxfee`）和增量中繼手續費率（`-incrementalrelayfee`）已變更為每 vB 0.1 聰。仍可使用各自的配置選項變更，但如果您決定這樣做，建議一起變更兩者。(#33106) + + 其他最小手續費率（例如塵埃手續費率、手續費估算器返回的最小值，以及錢包使用的所有手續費率）保持不變。記憶池最小手續費率仍會根據高流量變化。 + + 請注意，除非這些較低的預設值在整個網路中被廣泛採用，否則不保證以較低手續費率建立的交易會傳播或確認。錢包手續費率保持不變；在嘗試使用錢包建立較低手續費率的交易之前，必須變更 `-mintxfee`。(#33106) + +P2P 和網路變更 +----------------------- + +- 機會性的 1-parent-1-child 套件中繼已改進，可處理子交易在記憶池中已有未確認父交易的情況。這意味著 1p1c 套件即使連接到更廣泛的拓撲結構也可以被接受和傳播：多父-1-子（其中只有 1 個父交易需要手續費提升）、祖父-父-子（其中只有父交易需要手續費提升）等。(#31385) + +- 交易孤兒池暫時保存缺少輸入的交易，同時節點嘗試獲取其父交易，現在具有改進的阻斷服務保護。以前，它強制執行唯一交易的最大數量（預設 100，可使用 `-maxorphantx` 配置）。現在，其限制如下：條目數量（按 wtxid 和對等點唯一），加上每個唯一交易的輸入計數除以 10，不得超過 3,000。唯一交易的總重量不得超過 `404,000` Wu 乘以對等點數量。(#31829) + +- `-maxorphantx` 選項不再有任何效果，因為孤兒池不再限制唯一交易的數量。如果使用者正在使用此配置選項，應將其移除，因為在未來版本中不再識別該設定時，它將導致錯誤。(#31829) + +新的 `bitcoin` 命令 +--------------------- + +- 新增了一個 `bitcoin` 命令列工具，使功能更易於發現和使用。`bitcoin` 工具只是呼叫其他可執行檔，本身不實作任何功能。具體而言，`bitcoin node` 是 `bitcoind` 的同義詞，`bitcoin gui` 是 `bitcoin-qt` 的同義詞，`bitcoin rpc` 是 `bitcoin-cli -named` 的同義詞。其他命令和選項可使用 `bitcoin help` 列出。新的 `bitcoin` 命令是直接呼叫其他命令的替代方案，但它不會取代它們，也沒有計劃棄用現有命令。(#31375) + +外部簽名 +---------------- + +- Windows 上的外部簽名支援已重新啟用。(#29868) + +IPC 挖礦介面 +-------------------- + +- 新的 `bitcoin` 命令確實支援一個新功能：（實驗性）IPC 挖礦介面，允許節點與 Stratum v2 或其他挖礦客戶端軟體協同工作，請參閱 (#31098)。當節點使用 `bitcoin -m node -ipcbind=unix` 啟動時，它將在 unix socket 上監聽 IPC 客戶端連接，允許客戶端請求區塊模板和提交已挖掘的區塊。`-m` 選項啟動一個新的內部二進位檔案（`bitcoin-node` 而不是 `bitcoind`），目前是必需的，但將來會變為可選（透過 #33229）。 + +- IPC 連接引入了新的依賴項（請參閱 [multiprocess.md](https://github.com/bitcoin/bitcoin/blob/master/doc/multiprocess.md)），如果您不打算使用 IPC，可以使用 `-DENABLE_IPC=OFF` 建置選項關閉。(#31802) + +安裝變更 +--------------- + +- `test_bitcoin` 可執行檔現在安裝在 `libexec/` 而不是 `bin/` 中。它仍然可以直接執行，或透過新的 `bitcoin` 命令作為 `bitcoin test` 存取。`libexec/` 目錄還包含新的 `bitcoin-node` 和 `bitcoin-gui` 二進位檔案，它們支援 IPC 功能並透過 `bitcoin` 工具呼叫。僅在原始碼建置中，`test_bitcoin-qt`、`bench_bitcoin` 和 `bitcoin-chainstate` 現在也安裝到 `libexec/` 而不是 `bin/`，可透過新的 `bitcoin` 命令存取。詳情請參閱 `bitcoin help` 輸出。(#31679) + +- 在 Windows 上，安裝程式不再在開始選單條目中新增「(64-bit)」後綴 (#32132)，現在會在升級期間自動移除過時的檔案 (#33422)。 + +索引 +------- + +- coinstatsindex 的實作已變更以防止在預設 Signet 上已經可以觀察到的溢位錯誤。升級節點首次啟動時，需要從頭開始同步新版本的索引。 + + 新版本儲存在 `/indexes/coinstatsindex/` 中，而舊版本儲存在 `/indexes/coinstats/` 中。升級的節點不會刪除舊版本的索引，以防使用者將來選擇降級其節點。如果使用者不打算降級，可以安全地從其資料目錄中移除 `/indexes/coinstats/`。Bitcoin Core 的未來版本可能會自動移除舊版本的索引。(#30469) + +日誌記錄 +------- +- 無條件記錄到磁碟現在透過給每個源位置每小時 1MiB 的配額進行速率限制。無條件記錄是指日誌級別高於 debug 的任何記錄，即 `info`、`warning` 和 `error`。如果至少有一個源位置目前正在被抑制，所有日誌將以 `[*]` 為前綴。(#32604) + +- 當啟用 `-logsourcelocations` 時，日誌輸出現在包含整個函數簽名，而不僅僅是函數名稱。(#32604) + +更新的 RPC +------------ + +- `-paytxfee` 啟動選項和 `settxfee` RPC 現已棄用，將在 Bitcoin Core 31.0 中移除。它們允許使用者為錢包交易設定靜態手續費率，這可能導致過度支付或支付不足。使用者應該依賴手續費估算，或使用 `fundrawtransaction`、`sendtoaddress`、`send`、`sendall` 和 `sendmany` 等 RPC 中的 `fee_rate` 參數為每筆交易指定手續費率。(#31278) + +- 任何參數之一是描述符的 RPC 如果提供的描述符在片段內的公鑰開頭或結尾包含空格，將拋出錯誤 - 例如 `pk( KEY)` 或 `pk(KEY )`。(#31603) + +- `submitpackage` RPC 允許提交子-父套件，不再要求所有未確認的父交易都存在。套件也可以包含其他記憶池中的祖先。(#31385) + +- `waitfornewblock` RPC 現在接受可選的 `current_tip` 參數。它也不再是隱藏的。(#30635) + +- `waitforblock` 和 `waitforblockheight` RPC 不再是隱藏的。(#30635) + +- `psbtbumpfee` 和 `bumpfee` RPC 允許在 fullrbf 下進行替換，不再需要 BIP-125 信號。(#31953) + +- 交易腳本驗證錯誤以前會返回錯誤原因，如果是共識錯誤則以 `mandatory-script-verify-flag-failed` 為前綴，如果是標準性錯誤則以 `non-mandatory-script-verify-flag`（不帶「-failed」）為前綴。現在分別對所有區塊和記憶池錯誤變更為 `block-script-verify-flag-failed` 和 `mempool-script-verify-flag-failed`。(#33183) + +- `getmininginfo` RPC 現在返回「blockmintxfee」結果，指定 `-blockmintxfee` 配置的值。(#33189) + +- `getmempoolinfo` RPC 現在返回額外的「permitbaremultisig」和「maxdatacarriersize」欄位，反映 `-permitbaremultisig` 和 `-datacarriersize` 配置值。(#29954) + +與錢包相關的 RPC 變更可在下面的錢包章節中找到。 + +新的 RPC +-------- + +- 引入了一個新的 REST API 端點（`/rest/spenttxouts/BLOCKHASH`），用於使用區塊的 undo 資料有效獲取已花費的交易輸出 (#32540)。 + +建置系統 +------------ + +更新的設定 +---------------- + +- `-maxmempool` 和 `-dbcache` 啟動參數現在在 32 位元系統上分別限制為 500MB 和 1GiB。(#32530) + +- `-natpmp` 選項現在預設設定為 `1`。這意味著啟用了 `-listen`（預設）但在防火牆後面執行的節點（例如本地網路路由器）如果防火牆/路由器支援任何 `PCP` 或 `NAT-PMP` 協議，將是可達的。(#33004) + +- `-upnp` 設定現已完全移除。請改用 `-natpmp`。(#32500) + +- 以前，`-proxy` 為所有網路指定代理（除了使用 `-i2psam` 的 I2P），並且只能透過 `-onion` 單獨指定 Tor 代理。現在，`-proxy` 的語法已擴展，可以透過附加 `=` 後跟網路名稱來分別為 IPv4、IPv6、Tor 和 CJDNS 指定代理，例如 `-proxy=127.0.0.1:5555=ipv6` 僅為 IPv6 配置代理。`-proxy` 選項可以多次使用來為不同的網路定義不同的代理，例如 `-proxy=127.0.0.1:4444=ipv4 -proxy=10.0.0.1:6666=ipv6`。對於同一網路，後面的設定會覆蓋前面的設定；這可用於移除早期的所有網路代理並僅對給定網路使用直接連接，例如 `-proxy=127.0.0.1:5555 -proxy=0=cjdns`。(#32425) + +- `-blockmaxweight` 啟動選項已更新為僅調試。它仍然可供使用者使用，但現在在預設 `-help` 文字中隱藏，僅在 `-help-debug` 中顯示 (#32654)。 + +與 GUI 或錢包相關的設定變更可在下面的 GUI 或錢包章節中找到。 + +錢包 +------ + +- BDB 舊版錢包不能再建立或載入。它們可以遷移到新的描述符錢包格式。有關更多詳細資訊，請參閱 `migratewallet` RPC。 + +- 移除舊版錢包後，bitcoin-wallet 工具中的冗餘選項（例如 `-withinternalbdb`、`-legacy` 和 `-descriptors`）被丟棄。此外，僅限舊版的 RPC `addmultisigaddress`、`dumpprivkey`、`dumpwallet`、`importaddress`、`importmulti`、`importprivkey`、`importpubkey`、`importwallet`、`newkeypool`、`sethdseed` 和 `upgradewallet` 被移除。(#32944, #28710, #32438, #31250) + +- 新增了對錢包接收的 TRUC 交易的花費支援，以及建立 TRUC 交易的支援。錢包確保滿足 TRUC 政策規則。如果使用者嘗試將 TRUC utxo 與其他版本的 utxo 一起花費，錢包將拋出錯誤。此外，錢包將未確認的 TRUC 兄弟交易視為記憶池衝突。錢包還將確保花費 TRUC utxo 的交易滿足所需的大小限制。(#32896) + +- 由於描述符錢包不允許混合僅監視和非僅監視描述符，`include_watchonly` 選項（及其命名變體）從所有擁有它的 RPC 中移除。(#32618) + +- `iswatchonly` 欄位從任何返回它的 RPC 中移除。(#32618) + +- `unloadwallet` - 當 RPC 錢包端點和 wallet_name 參數都未指定時返回 RPC_INVALID_PARAMETER。以前 RPC 會因 JSON 解析錯誤而失敗。(#32845) + +- `getdescriptoractivity` - 將 blockhashes 和 scanobjects 參數標記為必需，以便使用者在缺少任何一個時收到清晰的幫助訊息。與 `unloadwallet` 一樣，以前 RPC 會因 JSON 解析錯誤而失敗。(#32845) + +- `getwalletinfo` - 移除欄位 `balance`、`immature_balance` 和 `unconfirmed_balance`。(#32721) + +- `getunconfirmedbalance` - 移除此 RPC 命令。您可以查詢 `getbalances` RPC 並檢查 JSON 回應中的 `"mine"` `"untrusted_pending"` 條目。(#32721) + +- 以下 RPC 現在包含一個 `version` 參數，允許使用者建立任何標準版本號（1-3）的交易： + - `createrawtransaction` + - `createpsbt` + - `send` + - `sendall` + - `walletcreatefundedpsbt` + (#32896) + +GUI 變更 +----------- + +- GUI 已從 Qt 5 遷移到 Qt 6。在 Windows 上，現在支援深色模式。在 macOS 上，現在使用 Metal 後端。(#30997) + +- 允許在 fullrbf 下進行交易手續費提升，不再需要 BIP-125 信號。(#31953) + +- 作為移除舊版錢包的副作用，交易頁籤中的自訂列寬被重置。(#32459) + +低階變更 +================= + +- 日誌現在包含哪個對等點向我們發送了標頭。此外，冗餘的標頭日誌訊息更少。此變更的副作用是，對於某些非典型情況，新標頭不再記錄，例如帶有先前未知標頭的直接 `BLOCK` 訊息和 `submitheader` RPC。(#27826) + +致謝 +======= + +感謝直接為此版本做出貢獻的每個人： + +- 0xb10c +- amisha +- Andrew Toth +- Anthony Towns +- Antoine Poinsot +- Ava Chow +- benthecarman +- Brandon Odiwuor +- brunoerg +- Bue-von-hon +- Bufo +- Chandra Pratap +- Chris Stewart +- Cory Fields +- Daniel Pfeifer +- Daniela Brozzoni +- David Gumberg +- deadmanoz +- dennsikl +- dergoegge +- enoch +- Ethan Heilman +- Eugene Siegel +- Eunovo +- Eval EXEC +- Fabian Jahr +- fanquake +- Florian Schmaus +- fuder.eth +- furszy +- glozow +- Greg Sanders +- Hao Xu +- Haoran Peng +- Haowen Liu +- Hennadii Stepanov +- Hodlinator +- hoffman +- ishaanam +- ismaelsadeeq +- Jameson Lopp +- janb84 +- Jiri Jakes +- John Bampton +- Jon Atack +- josibake +- jurraca +- kevkevin +- kevkevinpal +- kilavvy +- Kristaps Kaupe +- l0rinc +- laanwj +- leopardracer +- Lőrinc +- Luis Schwab +- Luke Dashjr +- MarcoFalke +- marcofleon +- Martin Zumsande +- Matt Corallo +- Matthew Zipkin +- Max Edwards +- monlovesmango +- Murch +- naiyoma +- nervana21 +- Nicola Leonardo Susca +- Novo +- pablomartin4btc +- Peter Todd +- Pieter Wuille +- Pol Espinasa +- Prabhat Verma +- rkrux +- Roman Zeyde +- Ryan Ofsky +- Saikiran +- Salvatore Ingala +- Sebastian Falbesoner +- Sergi Delgado Segura +- Shunsuke Shimizu +- Sjors Provoost +- stickies-v +- stratospher +- stringintech +- strmfos +- stutxo +- tdb3 +- TheCharlatan +- Tomás Andróil +- UdjinM6 +- Vasil Dimov +- VolodymyrBg +- w0xlt +- will +- willcl-ark +- William Casarin +- woltx +- yancy +- zaidmstrr + +以及所有在 [Transifex](https://explore.transifex.com/bitcoin/bitcoin/) 上幫助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-10-14-release-29.2.md b/_posts/zh_TW/releases/2025-10-14-release-29.2.md new file mode 100644 index 000000000..7d6e14892 --- /dev/null +++ b/_posts/zh_TW/releases/2025-10-14-release-29.2.md @@ -0,0 +1,98 @@ +--- +title: Bitcoin Core 29.2 +id: zh_tw-release-29.2 +name: release-29.2 +permalink: /zh_TW/releases/29.2/ +excerpt: Bitcoin Core 29.2 版本現已發布 +date: 2025-10-14 +type: releases +layout: page +lang: zh_TW + +release: [29, 2] + +optional_magnetlink: "magnet:?xt=urn:btih:fea822f7e6c0a95544449c81cdcd293ee994f2c5&dn=bitcoin-core-29.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +Bitcoin Core 29.2 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 13+ 和 Windows 10+ 的作業系統上受到支援和測試。Bitcoin Core 也應該可以在大多數其他類 Unix 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### P2P + +- #32646 p2p: Add witness mutation check inside FillBlock +- #33296 net: check for empty header before calling FillBlock +- #33395 net: do not apply whitelist permissions to onion inbounds + +### Mempool + +- #33504 mempool: Do not enforce TRUC checks on reorg + +### RPC + +- #33446 rpc: fix getblock(header) returns target for tip + +### CI + +- #32989 ci: Migrate CI to hosted Cirrus Runners +- #32999 ci: Use APT_LLVM_V in msan task +- #33099 ci: allow for any libc++ intrumentation & use it for TSAN +- #33258 ci: use LLVM 21 +- #33364 ci: always use tag for LLVM checkout + +### Doc + +- #33484 doc: rpc: fix case typo in `finalizepsbt` help + +### Misc + +- #33310 trace: Workaround GCC bug compiling with old systemtap +- #33340 Fix benchmark CSV output +- #33482 contrib: fix macOS deployment with no translations + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： + +- Amisha Chhajed +- Eugene Siegel +- fanquake +- Greg Sanders +- Hennadii Stepanov +- Luke Dashjr +- MarcoFalke +- Martin Zumsande +- Sebastian Falbesoner +- Sjors Provoost +- Vasil Dimov +- Will Clark + +以及所有在 [Transifex](https://explore.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 +{% endgithubify %} diff --git a/_posts/zh_TW/releases/2025-10-17-release-28.3.md b/_posts/zh_TW/releases/2025-10-17-release-28.3.md new file mode 100644 index 000000000..3be118a8e --- /dev/null +++ b/_posts/zh_TW/releases/2025-10-17-release-28.3.md @@ -0,0 +1,115 @@ +--- +title: Bitcoin Core 28.3 +id: zh_tw-release-28.3 +name: release-28.3 +permalink: /zh_TW/releases/28.3/ +excerpt: Bitcoin Core 28.3 版本現已發布 +date: 2025-10-17 +type: releases +layout: page +lang: zh_TW + +release: [28, 3] + +optional_magnetlink: "magnet:?xt=urn:btih:c741e32d51619556f0ca224236becdcfab27a7d7&dn=bitcoin-core-28.3&xl=3537481192&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/" +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +28.3 版本說明 +===================== + +Bitcoin Core 28.3 版本現已發布，可從以下位置下載： + + + +此版本包含各種錯誤修正和效能改善，以及更新的翻譯。 + +請使用 GitHub 的問題追蹤器回報錯誤： + + + +如需接收安全性和更新通知，請訂閱： + + + +如何升級 +============== + +如果您正在執行舊版本，請將其關閉。等待它完全關閉（在某些情況下可能需要幾分鐘），然後執行安裝程式（在 Windows 上）或直接複製 `/Applications/Bitcoin-Qt`（在 macOS 上）或 `bitcoind`/`bitcoin-qt`（在 Linux 上）。 + +可以直接從已達到 EOL 的 Bitcoin Core 版本升級，但如果需要遷移資料目錄，可能需要一些時間。通常支援舊版本的 Bitcoin Core 錢包。 + +相容性 +============== + +Bitcoin Core 在使用 Linux Kernel 3.17+、macOS 11.0+ 和 Windows 7 及更新版本的作業系統上受到支援和廣泛測試。Bitcoin Core 也應該可以在大多數其他類 UNIX 系統上運作，但在這些系統上的測試頻率較低。不建議在不受支援的系統上使用 Bitcoin Core。 + +重要變更 +=============== + +### Mempool & Policy + +最小區塊費率（`-blockmintxfee`）已更改為每 kvB 1 satoshi。仍可使用設定選項進行更改。 + +- 預設最小中繼費率（`-minrelaytxfee`）和增量中繼費率（`-incrementalrelayfee`）已更改為每 kvB 100 satoshis。仍可使用各自的設定選項進行更改，但如果決定更改，建議同時更改兩者。 + - 其他最小費率（例如 dust feerate、費用估算器返回的最小值，以及錢包使用的所有費率）保持不變。mempool 最小費率仍會根據高流量而變化。 + - 請注意，除非這些較低的預設值在整個網路中被廣泛採用，否則不保證使用較低費率建立的交易能夠傳播或確認。錢包費率保持不變；在嘗試使用錢包建立較低費率的交易之前，必須更改 `-mintxfee`。 + +- #33106 policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee +- #33504 mempool: Do not enforce TRUC checks on reorg + +### P2P + +- #33395 net: do not apply whitelist permissions to onion inbounds + +### Test + +- #32765 test: Fix list index out of range error in feature_bip68_sequence.py +- #33001 test: Do not pass tests on unhandled exceptions +- #30125 test: improve BDB parser (handle internal/overflow pages, support all page sizes) +- #30948 test: Add missing sync_mempools() to fill_mempool() +- #30784 test: add BulkTransaction helper to unit test transaction utils + +### Build + +- #32678 guix: warn and abort when SOURCE_DATE_EPOCH is set +- #32943 depends: Force CMAKE_EXPORT_NO_PACKAGE_REGISTRY=TRUE +- #33073 guix: warn SOURCE_DATE_EPOCH set in guix-codesign +- #33563 build: fix depends Qt download link + +### Doc + +- #32776 doc: taproot became always active in v24.0 +- #32777 doc: fix Transifex 404s +- #33070 doc/zmq: fix unix socket path example +- #33133 rpc: fix getpeerinfo ping duration unit docs +- #33236 doc: Remove wrong and redundant doxygen tag + +### Misc + +- #33340 Fix benchmark CSV output +- #33482 contrib: fix macOS deployment with no translations +- #33581 ci: Properly include $FILE_ENV in DEPENDS_HASH + +致謝 +======= + +感謝所有直接為此版本做出貢獻的人： +- 0xB10C +- amisha +- Ava Chow +- fanquake +- glozow +- Hennadii Stepanov +- MarcoFalke +- Martin Zumsande +- romanz +- Sjors Provoost +- theStack +- Vasil Dimov +- willcl-ark +- zaidmstrr + +以及所有在 [Transifex](https://explore.transifex.com/bitcoin/bitcoin/) 上協助翻譯的人。 + +{% endgithubify %}