導入私鑰時，會使用壓縮格式還是未壓縮格式？
我正在研究在Vanity Pool上實現對壓縮公鑰的支持。但是，我擔心以該格式將解決方案導入所需的虛榮地址。從我對壓縮密鑰格式如何工作的解釋中可以看出，一個私鑰似乎可以映射到兩個不同的比特幣地址。
是否有某種方法可以在標準客戶端中指定要使用哪種格式進行導入，或者是否會一直首選其中一種格式？
從密碼學的角度來看，只有一種類型的私鑰和一種類型的公鑰。私鑰是 1 到 115792089210356248762697446949407573529996955224135760342422259061068512044368 範圍內的整數，公鑰是橢圓曲線 secp256k1 上的一個點。這裡沒有魔法。
問題是比特幣使用地址，而地址是從公鑰的散列中派生出來的。由於您無法對“點”的數學概念進行雜湊處理，因此需要先將其轉換為字節序列。然而，標準比特幣定義了兩種將公鑰轉換為字節序列的方法：普通的一種（產生 65 個字節）或壓縮的一種（產生 33 個字節）。沒有理由使用普通的，當然兼容性除外。由於兩種編碼的結果字節序列不同，因此地址也會不同。如果硬幣被發送到一個地址，則需要使用與其完全匹配的公鑰編碼來花費它們。
因此，為了支持兩者，我們必須記住每個公鑰/私鑰對是使用普通編碼還是壓縮編碼。正如您所指出的，我們在導入私鑰時也需要這些資訊。為此，擴展了私鑰的“錢包導入格式”（base58 格式，通常以“5”開頭）。如果要從公鑰的壓縮編碼中導出特定私鑰的公鑰/地址，則私鑰最後會獲得一個額外的 0x01 字節，從而產生以“K”或“L”開頭的 base58 格式’。
所以回答你的問題：當將私鑰導入參考客戶端時，如果私鑰使用“5”格式，它將使用公鑰的普通編碼，如果使用“K”/“L”，則使用壓縮編碼’ 格式被使用。嘗試將一個轉換為另一個是沒有意義的：客戶端必須使用與生成地址時相同的編碼，否則地址將不匹配。不幸的是，很多軟體還不支持壓縮公鑰（很遺憾，因為它們節省了區塊鏈空間）。