將沒有奇偶校驗前綴的 33 字節公鑰轉換為地址

我正在編寫一個區塊鏈解析器，並且在萊特幣區塊鏈中不斷遇到這種類型的 scriptPubKey：

20a75ca72ffd994d2004d67b0e89015913f7352455d0111ede590430037c9fe2ac
20e664c3f6909687499d9bf13108e35306477a8d71b20655a75cbc64270416a9f2
20651b85139631645bfd68327d85af913a7e33e74433848c5facfe48368c7d1504
20604f5ced8c595af687a0e8718098c4818b7d51f2ba79cca931dc74d6cdb8c021

長度表明它們可能是壓縮的公鑰，但沒有奇偶校驗字節。我可以查看其中的幾十個，所有字節都不同，除了前綴 20 是長度。

Blockchair 似乎將這些解析為“s-something”地址，如下所示：

<https://blockchair.com/litecoin/address/s-31fa6bd469e97be4fe639911ca60bddf>

<https://blockchair.com/litecoin/address/s-4e7d283f055044b547f571bfdbbdb291>

這些地址是什麼，它是如何做到的？我假設他們人為地添加了s-因為破折號不在base58中，但我也無法得到任何與它右側的地址相匹配的東西。

我已經嘗試過像這樣壓縮其他格式的正常方法：

temp = prefix + hash160(scriptPubKey)
address = base58Check(temp + checksum(temp))

有和沒有校驗和，有和沒有 hash160。即使掃描所有可能的前綴字節，我也無法獲得破折號右側的地址。

我發現我必須對 23 個字節的東西進行 base58 才能獲得目標長度，但僅此而已。

其他解析器似乎無法解碼此地址（請參閱 blockchair 頁面本身的連結），只有 blockchair。

這些不是公鑰。並非所有 33 字節的內容都是公鑰。在這種情況下，它是一個 32 字節的散列。第一個字節表示接下來的 32 個字節將被壓入堆棧。所以結果是這個 scriptPubKey 中的實際數據是一個 32 字節的字元串。

在這種情況下，此特定交易是由 p2pool 開采的區塊中的 coinbase 交易。這個特定的腳本是一些 p2pool 特定的數據，是一個散列，而不是一個公鑰。

這些不是公鑰，它們是數據或比特幣腳本片段。

比如地址s-38f26094a4e3514933fc2bf56a1f2f26其實就是比特幣腳本：

OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH

地址是人工構造的，只有某些定義明確的比特幣腳本（p2pk、p2pkh、p2sh、p2wpkh、p2wsh）可以轉換為地址。所有其他 scriptPubKeys（或鎖定腳本，如果您喜歡這樣稱呼它們）都是非標準輸出，並且由不同的資源管理器以不同的方式解釋。Blockchair 似乎更喜歡一個s-前綴，後跟某種原始腳本的散列。

引用自：https://bitcoin.stackexchange.com/questions/88885