為什麼地址可以短於 34 字節?
Address上的 wiki 條目說:
一些比特幣地址可以短於 34 個字元(理論上少至 27 個)並且仍然有效。[…]這些較短的地址是有效的,因為它們代表恰好以零開頭的數字,並且當省略零時,編碼地址會變短。
好的,但是根據這張圖,主網地址是:
Base58Check(00 ++ RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)) ++ checksum)
接下來我們查看Base58Check的條目,我們看到第 4 步是:
- 將步驟 3 的結果 - 一系列字節 - 視為單個大端大數,使用正常的數學步驟(大數除法)和下面描述的 base-58 字母轉換為 base-58。結果應標準化為沒有任何前導 base-58 零(字元“1”)。
第一件奇怪的事情 - 如果它被視為單個大端數字,不應該在
00
沒有任何效果的主網路字節之前添加?因為這是最重要的字節,所以它就像寫00123
而不是123
正常符號,不是嗎?第二個奇怪的事情 - 如果結果應該被規範化為沒有前導零,這是否意味著輸出中不應該有任何
1
s ?第 5 步似乎與此矛盾
- 前導字元'1’,它在base58 中的值為0,被保留用於表示整個前導零字節,因為當它處於前導位置時,沒有作為base-58 符號的值。當需要表示一個或多個前導零字節時,可以有一個或多個前導“1”。計算步驟 3 結果的前導零字節數(對於舊的比特幣地址,版本/應用程序字節總是至少有一個;對於新地址,永遠不會有)。每個前導零字節應在最終結果中由其自己的字元“1”表示。
似乎第 4 步會刪除任何可能的前導字節。但是,如果它沒有,並且由於某種原因它沒有帶有前置
00
字節,那麼地址不應該有多個前導 1,例如,11175tWpb...
而不是簡單地縮短,例如175tWpb...
?編輯:好的,似乎它的意思是給定的有效載荷
X
,base58(X)
被規範化以刪除零,然後你1
為每個前導字節添加 aX
,而不是base58(X)
。它仍然提出了為什麼地址更短而不是多個1
s 的問題。是不是RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY))
碰巧永遠不會有太多的前導0
s (將作為1
s 前置)而base58(RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)))
確實(並且它們被從最終結果中刪除)?
是的,可以有多個前導“1”字元,每個“1”代表一個前導零字節。這會導致地址更短,因為通常每個 base58 字元代表的資訊略少於 6 位,但前導零字節正好包含 8 位資訊。
例如,您可以擁有的最短地址是 1111111111111111111114oLvT2(表示 0000000000000000000000000000000000000000 的 160 位雜湊)。它有 21 個前導“1”字元,正好代表 21 個前導零字節(雜湊前面加上另一個 00)。