BTC 出售與保管
礦工如何保管 Bitcoin：交易平台、硬體錢包與備份
礦工保管 Bitcoin 不只是「哪個錢包最好」。還要一併決定何時出售、誰能簽名、seed 備份在哪裡、關鍵人不在時怎麼恢復，以及平台暫停提領時如何支付電費。 資料核對日期：2026-08-09（UTC+8）。錢包、平台狀態與安全做法會變；投入實際資金前先完成恢復演練。 目錄 按時間分層 Seed
礦工保管 Bitcoin 不只是「哪個錢包最好」。還要一併決定何時出售、誰能簽名、seed 備份在哪裡、關鍵人不在時怎麼恢復，以及平台暫停提領時如何支付電費。
資料核對日期：2026-08-09（UTC+8）。錢包、平台狀態與安全做法會變；投入實際資金前先完成恢復演練。
目錄
- 按時間分層
- Seed 與恢復
- 分離職責
- 平台只留營運額度
- 轉帳程序
- 緊急情境
- 對帳與隱私
- 先寫威脅模型，再選錢包
- 把恢復能力當成保管控制的一部分
- 常見問題
按時間分層
近期要出售的營運 BTC 保持可進入受監管平台，但不在平台放超過需要的金額；中期準備可放獨立 self-custody；長期餘額則與日常操作隔離於 cold storage。
這不是對某產品的結論，而是把平台對手方/提領風險與 self-custody 的 seed 遺失/錯轉風險分開。每層都要有金額上限和核准規則。
Seed 與恢復
BIP-39 mnemonic 很常見，但仍要記錄實際錢包的相容性和 derivation path。不要把 seed 拍照、放 cloud note、email 或聊天。紙張或金屬備份應分隔保存，兼顧火水損害、偷竊與未授權複製。
有備份不等於能恢復。用新的空白設備或隔離測試環境做 recovery rehearsal，核對首個收款地址和小額測試；任何客服、網站或聊天都不應取得 seed。
分離職責
單一人持有完整控制會形成 key-person risk。至少分開申請、覆核與對帳。是否採 multisig 取決於金額、團隊與技術能力；未演練的複雜方案可能令資金反而無法取回。
Access matrix 寫明誰可看餘額、改 whitelist、提出交易、簽名和啟動緊急恢復；人員離職時立即 revoke。
平台只留營運額度
用 AFSA register 核對法律實體和牌照。啟用 MFA、withdrawal whitelist、anti-phishing code、session review 與登入警報；同時保護 email。
平台餘額不高於近期出售與 operational buffer。若 account review 或提領暫停，仍要有 KZT 備援支付電費。
轉帳程序
新地址要用另一安全管道確認、核對 network 並先小額測試。大額轉帳雙人檢查完整地址，copy-paste 後重新比對，防止 clipboard malware。
每次保存目的、金額、fee policy、收款方、核准和 txid；memo/tag 與網路要求以平台當前說明為準。
緊急情境
預演 signer 失聯、硬體錢包故障、seed 地點不可進入、平台暫停、malware 疑慮和員工離職。為每種寫出前 30 分鐘、24 小時及恢復步驟，每年至少做兩次 tabletop exercise，但演練文件不記真實 seed。
對帳與隱私
把 pool payout address、wallet label、txid 與會計用途對上。公開實際營運地址會增加 privacy 與 phishing 風險；備份台帳只記 sealed package ID、custodian、檢查和測試日期，不記 seed 本身。
常見問題
BTC 放平台一定錯嗎？
近期出售可能需要，但應有對手方限額與備援流動性。
加密後把 seed 放雲端可以嗎？
仍增加攻擊面；優先採離線且經驗證的實體保管。
多久測一次備份？
架構改變時和固定週期測試，但避免不必要暴露 production seed。
先寫威脅模型，再選錢包
要防的不只是外部駭客。單一員工掌握全部權限、email 被接管、硬體故障、seed 地點無法進入、繼承人不知道程序、偽造付款要求與錯誤地址，都是礦場常見的資產風險。逐項列出資產、威脅、控制、負責人與殘餘風險；未實際啟用的 MFA、whitelist 或告警不能在表內標成「已有控制」。
近期電費用的營運餘額與數月不動的儲備，不能使用完全相同的便利性和權限。把線上查看、提出交易、簽名、備份及對帳拆成不同層，而不是把所有責任交給一個「最安全產品」。
建立 wallet 與 address 台帳
每個 wallet 記錄內部 ID、用途、軟硬體與版本、network、account/descriptor 標識、signer 數、備份方式、最後恢復測試與責任人；台帳不存 private key、seed 或 passphrase。Pool payout address 變更要有舊址、新址、原因、雙人覆核、pool confirmation 與首次小額 payout 證據。
Address rotation 可以改善隱私，但不能破壞會計追蹤。每個地址要連到 wallet ID、使用期間與 purpose label。實際營運地址不放在公開文章、客服聊天或不必要的文件中，避免外界把地址與產量、餘額和人員身份連結。
備份不只有 mnemonic words
不同錢包可能還需要 network、derivation path、account index、script type、multisig quorum、cosigner 公開資料或 descriptor。這些非秘密 metadata 要與 seed 分開保存，否則多年後即使助記詞正確，也可能無法重建預期地址。
Passphrase 若遺失，正確 mnemonic 仍可能開出另一個 wallet。不要只靠某人記憶，也不要把 passphrase 與 seed 放在同一個未受控信封。每個備份包設定 tamper-evident ID、日期、格式、custodian 與檢查紀錄；金屬板能改善耐火耐水，卻不能自動防止偷竊、抄錯或拍照外洩。
用隔離環境做 recovery rehearsal
恢復測試不是把 production seed 輸入日常電腦。先用空白測試 wallet 演練，再在核准的隔離環境、乾淨設備和監督人員下檢查正式備份是否可讀、metadata 是否完整，以及恢復後能否產生預期 public address。
紀錄只保留 package ID、參與者、時間、public fingerprint、結果與設備清理方式，不寫 seed。若相機、clipboard、printer queue 或 cloud sync 可能取得秘密，立即停止。測試成功後仍要評估 exposure；有疑慮時規劃把資金移到全新且已驗證的 wallet。
每次簽名都從標準付款單開始
付款單至少包含商務目的、收款方、完整地址、network、金額、fee policy、期限、invoice 與申請人。覆核者對原始文件驗證，申請人不能獨自核准。Email 裏的 invoice 與同一封 email 裏的「新地址」只算一個來源，大額付款須用既有聯絡方式再次確認或先做小額測試。
Signer 在 trusted display 或硬體錢包畫面檢查完整地址和金額後才簽名。Broadcast 後把 txid、approval、wallet ID 與會計用途綁在一起；fee 超過內部上限時要第二次核准，而不是因對方催促就放寬。
Multisig 也會增加新的故障點
Multisig 能降低單一關鍵人風險，但 quorum、相容性、metadata backup 或 signer 地理分隔做錯，反而可能鎖死資金。同一辦公室內的三個 signer 仍是同一物理故障點。M-of-N 應依人員可用性與威脅情境設計，不跟隨流行配置。
每個 signer 的設備、備份 custodian 和替換程序分開管理；需要恢復的 descriptor 或 cosigner 公開資料保存在多個受控位置。Signer 變更後，以新設定、測試 wallet 與小額交易重新驗證全流程。團隊若不能穩定操作複雜架構，簡單而反覆演練的方案可能更可靠。
人員異動立即觸發 exposure review
Onboarding 只給角色所需最小權限，查看餘額、改 whitelist、提出交易、簽名與對帳分開。Offboarding 同時撤銷 email、password manager、VPN、exchange session、監控、實體保管庫與 approval group。
還要問離職人員是否曾看過 seed、進入備份地點或控制 payout address。若曾接觸，不應只改密碼；要評估建立新 wallet、修改 pool payout、受控 sweep 與保留舊地址監控。所有輪替都以雙人覆核執行。
把繼承與長期失聯寫進程序
法律授權與技術恢復是兩件事。繼承人拿到 seed 不代表法律上有權動用；法律文件也不會自動提供 derivation path、signer 或操作能力。應由熟悉當地法律與稅務的專業人士檢查架構。
Emergency envelope 可以只列法律聯絡人、package ID、程序位置、所需角色與第一步，不必直接放秘密。每年做 tabletop exercise，模擬主要 signer 失聯：誰啟動、如何驗證權限、怎樣取得 metadata、誰核准轉到新 wallet，以及會計如何留痕；演練不展示真實 seed。
懷疑外洩時不要在受感染設備上急着轉幣
先隔離可疑設備、保存 access log 與 alert、指定 incident lead，並準備獨立乾淨環境。直接在原電腦建立新 wallet 可能把相同惡意程式帶到新地址。依外洩類型判斷範圍；若只是 exchange email 受影響，不必無故打開 cold-storage seed。
確需轉移時，目的 wallet 必須事前驗證，地址在 trusted display 核對，並有 fee 與 confirmation 計畫。事件結束後記錄 root cause、失效控制、實際損失、金鑰輪替與新架構，而不是只把警報關閉。
每月做一次 custody close
把 wallet 台帳與 pool、鏈上及會計資料對上，找出未知地址、無說明交易、長期 pending、過期 signer、逾期 recovery test 和超出政策的 exchange balance。Close 包保留 public balance evidence、txid、平台 statement、核准紀錄及 exception 處理，不含 seed、private key、token、email 或內部 URL。
遇到台帳過期、恢復測試逾期、signer 職責不清、目的地址未獨立確認、備份疑似外洩、平台授權或提領狀態未核對，或 KZT 緊急準備不足時，停止新的 payout address 變更與大額轉帳。
把恢復能力當成保管控制的一部分
錢包備份存在，不代表真的能恢復。至少每季在隔離環境進行一次演練，使用不持有正式資產的測試資料，驗證助記資訊、簽署裝置、密碼片段與操作說明是否能由授權人員依序取得。演練不應輸入正式助記詞到連網電腦，也不應拍攝或複製敏感內容；只記錄步驟是否成功、耗時與發現的缺口。
多簽保管要測試的不只是正常簽署，也包括一名保管人離職、裝置故障、地點暫時不可進入及聯絡人失效。每種情境都寫明最低可用簽章數、替代裝置、法律授權與重新建立錢包的條件。任何門檻或地址變更，都先用小額測試並由另一人比對新地址，舊地址則保留監控直到遷移完全對平。
把錢包清單與財務月結連結：每個地址標示用途、owner、建立與停用日期，月底餘額和鏈上交易要與礦池付款及出售記錄相符。不明入帳、未批准轉出或長期無 owner 的地址立即進入例外清單。如此保管不是一份靜態助記詞，而是一套可演練、可交接、可對帳的營運制度。