TgWitness參考資料 / 證據
證據的運作方式
文中以驗證者實際使用的精確公式，詳盡闡述了雜湊鏈、簽名、檢查點及見證者的運作原理。
TgWitness 會保存收集帳戶所觀察到的內容，將這些觀察結果 串聯成一份經簽署的日誌，並允許其他人透過可信 金鑰及先前保留的檢查點，對匯出內容進行驗證。
本地文件網站另提供
互動式範例（網址：/docs/concepts/），以及檢查點決策探索工具（網址：
/docs/witness/）。所有範例訊息、
計數及延遲皆為虛構。鏈式沙盒中的雜湊值係透過
瀏覽器中的 SHA-256 演算法計算得出。任何資料均不會傳送至 Telegram。
訊息隨之改變；觀察結果不斷累積#
圖表轉為文字
- Telegram → 收集器: 新訊息：10:00 見面
- 收集器 → 經簽署的日誌: 追加訊息.new
- Telegram → 收集器: 編輯：11:00 見面
- 收集器 → 經簽署的日誌: 追加訊息.已編輯
- Telegram → 收集器: 刪除通知
- 收集器 → 經簽署的日誌: 追加訊息.已刪除
- 關於 經簽署的日誌 的說明: 原始訊息、編輯紀錄及刪除紀錄均予以保留
此簡化流程假設 Telegram 已成功傳送每則更新，且選定的 帳戶能夠看到該更新。操作事件也會記錄在日誌中。刪除通知 不會提供刪除者身分或確切的刪除時間。重複傳送的訊息 會被視為獨立的觀察記錄；日誌中不會進行全域性的重複資料抑制。
哈希值涵蓋的範圍#
從內到外解讀此公式：C 將九個欄位轉換為精確的位元組； SHA-256 產生其摘要；hex 則是儲存該摘要的方式。前一個 雜湊值已包含在事件中。unhex 將儲存的雜湊值還原為 32 位元組，供 Ed25519 進行簽名。
設 C(ei) 為九個事件欄位的標準 UTF-8 JSON 格式。第一個
previous_hash 由 64 個零字元組成。每個後續記錄皆包含前一個
記錄的十六進位雜湊值：
該簽名涵蓋 32 位元組的原始摘要。雜湊輸入內容精確包含
seq、observed_at、source_at、kind、chat_id、message_id、actor_id、
payload 及 previous_hash。物件金鑰已排序；省略空白字元與 ASCII
轉義字元；NaN 與無窮大值將被排除。請參閱
確切的編碼方式。
圖表轉為文字
- 64 個零字元 → 記錄 1 / 雜湊值 h1
- 記錄 1 / 雜湊值 h1 → 記錄 2 包含 h1 / hash h2
- 記錄 2 包含 h1 / hash h2 → 記錄 3 包含 h2 / 雜湊 h3
- 記錄 3 包含 h2 / 雜湊 h3 → 簽名檢查點：計數 3，標題 h3 (保留於其他位置)
| 改為提供的日誌 | 偵測依據 |
|---|---|
| 修改記錄 2 同時保留其已儲存的雜湊值 | 重新計算的事件雜湊值有所不同；其簽名已不再涵蓋該變更後的事件 |
| 重建經竄改的記錄及其後續所有雜湊值 | 原始簽名驗證失敗；位於受影響邊界的保留檢查點結果亦不一致 |
| 移除結尾部分，但保留剩餘的前綴不變 | 在所提供的前綴之後，一個較早保留的檢查點顯示，匯出內容過短 |
| 使用另一把金鑰重新簽署替換日誌 | 透過獨立受信的金鑰指紋，可駁斥身分替換行為 |
請試著對第 2 筆記錄進行驗證：將已儲存事件中的 Meet at 11:00 改為 Meet at 12:00。
其重新計算後的雜湊值將不再匹配。重新計算後續鏈
雖可修復其連結，但無法讓原始簽名涵蓋新的摘要。
相較之下，經觀察到的 Telegram 編輯操作，則會成為新的日誌記錄。
僅憑哈希連結並無法防止他人重新計算替代鏈。 信任源自於透過獨立可信的金鑰驗證簽名， 並與儲存於收集器外部的參考資料進行比對。
先前檢查點新增的內容#
當日誌持續增長時，參考點保持不變。若檢查點顯示 「3 筆記錄，頭部 h3」，則包含四筆記錄的匯出檔可透過匹配第 3 位置的 h3 而通過驗證。 其最新頭部為 h4，預期會有所不同。僅包含兩筆記錄的匯出檔將驗證失敗。
在驗證檢查點簽名後，需執行以下操作：
匯出資料可能跨越檢查點。其內容必須在保留的邊界處保持一致。 真正的驗證者還會檢查每個事件的順序、前一個連結、雜湊值及 簽名。若僅比較最終儲存的頭部資料，將無法察覺內部 記錄遭篡改的情況，因為其儲存的雜湊值並未隨之更新。
證人的歸屬之地#
圖表轉為文字
- 收集器 / 帳戶會話 / 金鑰 A → 唯讀檢查點端點
- Witness / 固定收集器金鑰 / 自有金鑰 B → 獨立的簽名證據日誌
- Witness / 固定收集器金鑰 / 自有金鑰 B → 唯讀檢查點端點 (申請審核)
- 唯讀檢查點端點 → Witness / 固定收集器金鑰 / 自有金鑰 B (經簽署的回答)
- Witness / 固定收集器金鑰 / 自有金鑰 B → 包含經簽署的 TGW1 貼文的頻道 (Bot API / 專屬代幣)
該見證系統會記錄回滾、相同計數下的不同頭部、變更的金鑰、 無效答案及缺失的回應。僅憑計數增加，並不能證明 所有較早的記錄均未被修改；請將匯出內容與保留的 檢查點進行比對。將見證系統部署於另一台主機，可避免受收集器主機中斷的影響； 由獨立的操作員負責，則能提供額外的獨立性。
該「見證者」僅針對收集器所回報的日誌狀態進行認證，並不會 獨立監控所有 Telegram 訊息。請參閱見證者設定說明。
針對已知操作進行測試#
請使用受控群組、獨立的收集帳號以及新的標記。有目的地發送、 編輯及刪除訊息，並在各階段之間檢查擷取狀況。在檢視結果前，請先定義預期 的操作行為及截止條件。
僅計入與預期動作相符的項目；重複的收據不會增加 分子。分母必須不為零。若缺少收據，則無法測量 延遲。請記錄時間不確定性；請使用您自行控制的刪除動作時間， 因為 Telegram 並未提供確切的刪除時間。 例如 5/6 (83.3%) 這樣的結果描述的是測試動作，而非所有 Telegram 流量的完整性。
選擇工作流程#
完整的調查流程指南將以某起事件為例， 涵蓋頻道、群組、機器人及私人聊天室等情境：
- 啟用「整個帳戶」調查模式，並清點所有可存取的聊天室。
- 可取得日誌快照、各聊天室的完整歷史紀錄以及已保存的附件。
- 將即時變更及任何有意的面板互動連同其交易憑證一併保留。
- 透過引用的記錄及用戶檔案，追蹤數值發送者 ID、回覆關係、重複收件者及檔案 雜湊值。
- 重建跨聊天室的時間軸，其中包含時間戳記及明確的空白處。
- 在保持原始來源與金鑰獨立的前提下，比較其他帳戶的工作區。
- 彙整並驗證經簽署的日誌、使用者檔案及歷史記錄匯出檔，並附上案件筆記。
該網站的《/docs/cases/指南》包含互動式案件地圖，並針對
機器人爭議、已刪除訊息及參與者更名等情況提供多種處理方案。案件筆記
與跨工作區分析屬外部功能；本應用程式不會自動
生成全球調查圖譜或合併案件檔案庫。
已完成驗證與待完成工作 · 匯出與驗證 · 從一個帳戶開始