載入中…
上面是重點。下面每一塊都是完整的原始揭露(計算方法、更正紀錄、驗證方式),一個字都沒刪 —— 點開就能看。
當多個 AI 的組合高度重疊,代表它們在追同一批幣(擁擠)。研究(BIS/FSB)顯示:AI 同源訓練會讓決策趨同,共識越高越是風險警訊而非高信心。我們把它公開量測。
總曝險上限 100%。若模型輸出超標或幻覺出不存在的幣種,系統不會自動幫它縮到 100%——會回饋錯誤讓它重試一次;仍違規就記錄違規並維持原倉。這是「指令遵循能力」的真實量測。
載入中…
這一頁以前寫著「帳本不可竄改」,而在 2026-09-05 之前, 那條鏈從來沒有被任何程式驗證過,也沒有任何入口讓你自己驗。 ⭐ 一條沒有人驗證的雜湊鏈是裝飾品,不是證據。
現在驗證程式跟鏈一起公開。它只用 Python 標準庫, 不需要我們的任何其他程式碼:
# 一次抓齊:驗證器 + 鏈 + 鏈所保護的四個檔案 B=https://crypto-trading-academy.com/data/shadow for f in verify_chain.py anchor_chain.json dashboard_data.json CHANGELOG.md PROTOCOL.md diaries.json anchor.json push_receipts.json PROTOCOL_LEARNING.md learning_data.json; do curl -sO $B/$f; done python verify_chain.py
⚠️ 少下載任何一個檔,那一項會顯示「本機沒有這個檔案」—— 那是沒有比對到,不是「通過」。這支程式把三種結果分開:通過 / 不符 / 沒有檔案可比對。
🔴 它會自己印出它證明不了什麼,請一起讀: 雜湊鏈只防「改掉其中一筆」,防不了「整條重算」。
🔴🔴 2026-09-21 更正:我們先前在這裡寫錯了。
這一段本來說「防重算靠的是推到公開 git repo 留下的外部時間戳」——
那個時間戳不是外部的。git 的 author 與 committer 時間
都是提交那台機器寫的,GitHub 不背書;而 GitHub 的 commits 頁
預設顯示 author 時間,它在 rebase 之後原樣保留。
⭐ 實例(你可以自己驗):第 43 號錨點在鏈上與 GitHub 上都標 2026-09-03,
而那個 commit(03e2d9b)的 committer 時間是
2026-09-04 18:08:55 +0800 —— 差 33.5 小時,
兩天份的證據同一晚落地,而在此之前這一頁一個字都沒說。
指令:git log --format=%cd 03e2d9b
所以誠實的講法是:我們目前無法向你證明某一筆是當天推上去的。
能給你的是 push_receipts.json
(自 2026-09-22 起側錄):每一筆記「我們這邊在什麼時刻、推了哪一個 commit、成功與否」。
它仍然是我們自己寫的,但 chain_utc 與 push_returned_utc
的差距會把「當天推的」與「事後補推的」分開;而且它會被下一筆錨點的雜湊蓋住
—— 事後改它會讓下一筆對不上。
🔴🔴 所以請這樣讀這一頁:今天這一筆,你不該相信。
一筆錨點要到下一筆出來、把它的雜湊蓋住之後,才有東西擋得住事後修改。
也就是說最新的那一筆有大約 24 小時完全沒有被保護 ——
而這是一個每天結算一次的實驗,
⭐ 24 小時的空窗,對日頻資料而言就是全部。
講白:在 2026-09-22 之前,T−1 以前的帳本可驗證;當日那一筆只是「我們自己說的」。
我們不會用打包票的字眼描述那段期間的當日資料,也請你不要這樣理解它。
(2026-09-22 起,當日那一筆改由下面那個外部時間戳蓋住 —— 見下一段。)
📌 這個限制是結構性的:錨點的雜湊必須在推送之前封死,
收據不可能塞回它自己那一筆。
✅ 2026-09-22 起:已經有一個真的外部時間戳了。
每一筆錨點的雜湊,在推送之前會送進
OpenTimestamps,
最終落在比特幣區塊上。比特幣的區塊時間不是我們能控制的 ——
這是第一個真的外部的時間。證明檔就放在
data/shadow/ots/seq<N>.ots,而且跟那一筆錨點在同一個 commit 裡。
驗證(需要 opentimestamps-client,那是別人的工具,不是我們寫的):
pip install opentimestamps-client
ots verify -d <那一筆錨點的 hash> seq<N>.ots
🔴 一定要加 -d:我們蓋的是錨點的雜湊,不是某個檔案的雜湊。
不加 -d 的話 ots 會去找一個叫 seq<N> 的檔案 ——
那個檔案不存在,你會卡在那裡拿不到任何結論。
hash 去 anchor_chain.json 裡那一筆的 hash 欄位拿。
📌 這句指令我們在 2026-09-22 印錯過一次(少了 -d),當天更正。
🔴 它證明的、與不證明的:它只證明「這個雜湊在那個時間點之前就已經存在」。
它不證明我們的數字是對的,也不證明我們沒有在更早以前算過別的版本再挑一個來蓋。
剛送出的是待確認證明,要等區塊確認後 ots upgrade 才完整。
🔴 已錨定的 PROTOCOL 裡也有同一句錯話,而我們不改它。
PROTOCOL.md:131 寫「平台接收時間戳=外部錨點」、
:166 寫「由平台接收時間戳背書,非 git commit 時間」——
後面那句比我們剛更正掉的還強。它們同樣是錯的。
依 §9,已錨定的協議原文不得編輯(改了就失去預先登記的意義),
所以我們在這裡更正,原文保留不動。
📌 CHANGELOG-048 當時寫「兩處」,實際至少四處(頁面、驗證器、協議兩行)——
那句話本身也低估了,一併更正。
⚠️ seq 73 以前的錨點沒有這個(第一筆是 2026-09-22 的 seq 73)——
在那之前的帳本,上面那段 24 小時空窗的說法仍然成立,我們不追溯補蓋
(事後補蓋的時間戳證明不了當時,那會是另一句假話)。
⚠️ 還有一件我們現在做不到的事: 驗證程式證明的是「GitHub 上那份檔案沒被改」, 而你正在看的是這個網頁 —— 網頁本身不會在你的瀏覽器裡即時比對雜湊。 所以「你螢幕上的數字 = 被錨定的那一份」這件事,我們目前沒有給你證明。 要自己確認,請用上面的指令下載原始檔比對。
📌 錨點是每天 00:36 UTC 拍一次快照。 我們當天稍後更新過檔案時,驗證器會顯示「不符」並說明它分辨不出 「正常更新」與「被竄改」—— 那時請看 git 歷史。
預先登記書 §4 寫著:任一觸發即該腦當期失格
—— 最大回撤 > 35% / 發生爆倉 / 正式違規率 > 10% 的決策日。
🔴 這張表就是那條規則的執行結果,包含已經觸發的。
在 2026-09-06 之前,這一頁完全不顯示回撤與違規率 ——
唯一出現「失格」兩個字的地方是「失格條件跑之前就寫死」那句話本身。
門檻從已錨定的 PROTOCOL 原文解析,不是寫死在這一頁上。
預先登記書 §3 指定的唯一主指標是「相對等權多頭的 Information Ratio」,
§9 禁止中途更換基準 —— 所以我們不換,下表左欄就是那個指標。
🔴 但它有一個我們必須講出來的後果:那個「等權多頭」不是大盤。
它取候選表前 10 檔,而候選表按「近 30 日絕對漲跌幅」排序 ——
也就是波動最大的 10 支幣(持倉年化波動中位數 331%,BTC 持有是 43%),
再機械地全部做多、每日輪動。
⭐ 結果是:拿它當尺,連「完全空手」和「賠錢的腦」都拿到正分。
所以右欄併列「相對 BTC 買進持有」的同一個算法,不替你選一個。
這一頁寫著「不隱藏違規與爆倉」。 下表就是那句話的可檢查版本:每一類事件的發生天數與分母,逐日從帳本算出。 零也列出來 —— 沒有分母的零,跟「這個欄位不存在」看起來一樣。