@liwi 16 December 2021 more from that month

如前述，最近在試著更深入了解比特幣的公私鑰與交易簽署系統： https://noise.cash/post/lgw06k5j https://noise.cash/post/l4ng2z75 https://noise.cash/post/lrxm2x79 那麼如 @Ayukawayen 所指出的，公鑰有所謂壓縮格式與未壓縮格式： https://noise.cash/post/l7n2p90v 就著這脈絡去探究比特幣的發展可以發現很多有趣的東西。以下是我的理解，提出來做參考、討論。 概念理解上沒什麼，都是一樣的東西，實作上知道這些區別蠻重要的，比如說我在檢查 Electron Cash 的公私鑰時花了好一番功夫才理解到公鑰用的也是壓縮格式。我在猜或許因為如此而有了 Compressed WIF 的存在，兩相對應比較不會搞混。基本上我猜到了今天，大家應該都是用壓縮格式了，原因是可以節省手續費。一些教學可能還是會用未壓縮格式，就注意一下教學與實際應用間的落差就行。 壓縮格式之所以可以省手續費是因為當你要花 utxo（就是你的比特幣或比特現金）時要給出地址的公鑰與 ECDSA 簽名，而手續費是以 X sat/byte 來計算，壓縮格式的公鑰長度只有一半。（這邊描述或許不夠精確，見 @Ayukawayen 下方留言討論補充。） 咦，為什麼又是地址、又是公鑰？有一派的說法認為我們所知的比特幣地址不應該稱為地址，而應該叫做發票（invoice）號碼。我有交易需求，開發票給你讓你匯款進來。當我想要處理這筆進帳時，我就給比特幣網路該發票的公鑰，與我用私鑰作的數位簽名。系統可以用公鑰->發票的 hash 雜湊來檢查是否符合發票號碼，然後用 ECDSA 來檢查簽名是否有效。 也就是說，比特幣的交易簽署安全性是複合地同時建立在兩個雜湊（SHA256 與 RIPMD-160）與橢圓曲線數位簽章演算法 ECDSA 上。 這有兩個意涵：一是從系統安全性（security / robustness）上來說，中本聰的設計很精妙，就算 ECDSA 被破解，只要公鑰沒有流出、雜湊函式不可逆（基本上為真因為資料量被壓縮了）且不被碰撞，比特幣系統就還是可以用。 另外一個意涵則跟日常生活比較相關，就是發票號碼（就是地址）不要重複用，如果你很在意安全性的話。重複用的意思是，曾經把錢從這個發票號碼（就是地址啦）轉出去，因為在做這個動作的時候，你的公鑰就被送到區塊鏈上了。如果哪天 ECDSA 被破解了，funds are safu 可能就不成立了。零錢包就算了，如果是比較重要的資金，送到一個新的地址可能是較安全的作法。當然需不需要這樣做是另一回事，客觀來說比較安全不代表不這樣做就不安全。 更多關於地址/invoice 的說明可以看看 https://en.bitcoin.it/wiki/Address_reuse Pieter Wuille 在 Stack Exchange 上關於為什麼公鑰要雜湊的回應也蠻值得看的 https://bitcoin.stackexchange.com/questions/72184/why-is-p2pkh-used-instead-of-the-simpler-p2pk https://bitcoin.stackexchange.com/questions/5952/why-does-bitcoin-support-both-compressed-and-uncompressed-keys-addresses 基本上印證了之前舊文裡提到的「 ECDSA 不是中本聰的強項」這樣的說法 未壓縮的 ECDSA 公鑰有 512 位元，取雙雜湊後有 160 位元，算是大幅節省區塊儲存空間。但如果用壓縮格式的話，ECDSA 公鑰只有 256 位元，是不是要多花兩個雜湊運算壓到 160 位元或許就值得商榷。所以 Pieter Wuille 提出了系統安全性的看法。 那說到節省區塊空間就會牽涉到 BTC / BCH（還有其他...），或者，從 BIP 角度來看，就是 SegWit/SegWit2X/Unlimited... 等等。比特幣的歷史我不是很了解，不過概念上是這樣的：同樣十分鐘的出塊時間，要怎樣讓交易不塞車呢？一是讓區塊大一點，另外是讓區塊能容納更多的交易紀錄。談到這些就會有些現時性了，就先打住了。