---
title: "กระเป๋าสินทรัพย์ดิจิทัลแบบออฟไลน์: การลงนามแบบออฟไลน์ การกู้คืน และการควบคุมการปฏิบัติงาน"
description: "เรียนรู้วิธีการออกแบบและตรวจสอบการเก็บรักษากระเป๋าสินทรัพย์ดิจิทัลแบบออฟไลน์ในด้านการสร้างกุญแจ, ตัวตนของกระเป๋าสินทรัพย์ดิจิทัล, การสำรองข้อมูล, การตรวจสอบการทำธุรกรรม, การลงชื่อแบบออฟไลน์, การใช้หลายลายเซ็น, การกู้คืน, และการตอบสนองต่อเหตุการณ์"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# กระเป๋าสินทรัพย์ดิจิทัลแบบออฟไลน์: การลงนามแบบออฟไลน์ การกู้คืน และการควบคุมการปฏิบัติงาน

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

กระเป๋าสินทรัพย์ดิจิทัลแบบออฟไลน์คือระบบดูแลสินทรัพย์ที่แยกข้อมูลลับสำหรับการลงนามและขั้นตอนอนุมัติขั้นสุดท้ายออกจากซอฟต์แวร์ที่เชื่อมต่ออินเทอร์เน็ตตามปกติ สินทรัพย์ยังคงบันทึกอยู่บนบล็อกเชน ส่วนระบบนี้ควบคุมกุญแจหรือสิทธิ์อื่นที่ใช้อนุมัติการเปลี่ยนแปลงสถานะ คำว่า "กระเป๋าสินทรัพย์ดิจิทัลแบบออฟไลน์" เป็นคำเรียกด้านการปฏิบัติงาน ไม่ใช่ประเภทอุปกรณ์ที่โปรโตคอลกำหนด และต้องประเมินความเป็นออฟไลน์จากกระบวนการทั้งหมด ไม่ใช่จากยี่ห้อหรือชนิดการเชื่อมต่อเพียงอย่างเดียว

อุปกรณ์ฮาร์ดแวร์สำหรับลงนามอาจรองรับการเก็บรักษาแบบออฟไลน์แม้เชื่อมต่อผ่าน USB เพราะกุญแจส่วนตัวยังคงอยู่ในสภาพแวดล้อมแยก แต่กระบวนการยังไม่ปลอดภัยหากผู้ใช้ลงนามให้ปลายทางที่ไม่ได้ตรวจสอบหรือคำสั่งสัญญาที่อ่านไม่เข้าใจ ในทางกลับกัน คอมพิวเตอร์ air-gapped ไม่ได้ปลอดภัยเพียงเพราะไม่มีอินเทอร์เฟซเครือข่าย เอนโทรปี สื่อสำหรับติดตั้ง ตัวแยกวิเคราะห์ธุรกรรม สื่อถอดได้ ข้อมูลสำรอง หรือหน้าจอที่ถูกโจมตียังทำลายขอบเขตนี้ได้ การเก็บรักษาแบบออฟไลน์ช่วยลดความเสี่ยงที่กุญแจจะถูกดึงออกจากระยะไกล แต่ไม่ได้พิสูจน์เจตนาของธุรกรรม ความถูกต้องของซอฟต์แวร์ ความสามารถในการกู้คืน ความเป็นส่วนตัว หรือไฟนอลิตี้

ข้อมูลกู้คืนไม่ใช่ "แค่ข้อมูลสำรอง" วลีช่วยจำ seed, seed ดิบ, กุญแจส่วนตัวแบบขยาย หรือ share สำหรับกู้คืนที่เทียบเท่าอาจสร้างสิทธิ์ใช้จ่ายขึ้นใหม่ได้ จึงต้องป้องกันในระดับเดียวกับอุปกรณ์ลงนาม การกู้คืนที่อยู่เดิมอาจต้องใช้พาสเฟรส เส้นทางการสร้างกุญแจ เครือข่าย ประเภทสคริปต์ wallet descriptor ลำดับกุญแจ และนโยบายเกณฑ์ร่วมด้วย กระเป๋าสินทรัพย์ดิจิทัลแบบดูอย่างเดียวมักลงนามไม่ได้ แต่ `xpub` หรือ descriptor อาจเปิดเผยความเชื่อมโยงของที่อยู่และประวัติธุรกรรม และกุญแจสาธารณะแบบขยายตาม BIP-32 มีผลด้านความปลอดภัยมากกว่ากุญแจสาธารณะทั่วไป

<a id="mechanism"></a>

## วิธีการออกแบบและตรวจสอบระบบเก็บความเย็น

### 1. กำหนดขอบเขตอำนาจและโมเดลภัยคุกคาม

บันทึกเครือข่าย สินทรัพย์ บัญชีหรือนโยบายเอาต์พุต เจ้าของ ผู้รับประโยชน์ สิทธิ์กู้คืน ความถี่ธุรกรรมที่คาดไว้ และวงเงินความเสี่ยงทางปฏิบัติการให้ชัดเจน แยกมัลแวร์ระยะไกล แอปที่เป็นอันตราย การโจมตีห่วงโซ่อุปทาน การสมคบคิดภายใน การโจรกรรม การข่มขู่ ไฟไหม้ น้ำท่วม การสูญหาย การไร้ความสามารถ และการสืบทอดเป็นคนละภัยคุกคาม จากนั้นกำหนดว่าส่วนใดต้องอยู่ออฟไลน์ ได้แก่ กุญแจส่วนตัวหนึ่งดอก กุญแจทั้งหมดในชุดเกณฑ์ ควอรัมของอุปกรณ์ลงนาม กุญแจอนุญาต EIP-712 หรือผู้ดูแลที่เปลี่ยนโค้ดของกระเป๋าสินทรัพย์ดิจิทัลได้

### 2. สร้างเอนโทรปีและตั้งค่าซอฟต์แวร์ที่เชื่อถือได้

รับอุปกรณ์และซอฟต์แวร์จากช่องทางที่ยืนยันแหล่งที่มา ตรวจสอบสถานะเริ่มต้น ตรวจสอบรุ่นที่เผยแพร่เมื่อรองรับ และปฏิเสธวลีช่วยจำ seed หรือความลับที่สร้างไว้ล่วงหน้าในกล่องหรือโดยผู้ช่วย สร้างเอนโทรปีในสภาพแวดล้อมที่ควบคุมและบันทึกมาตรฐานกับซอฟต์แวร์ที่ใช้ BIP-39 เข้ารหัสเอนโทรปีตั้งแต่ `128` ถึง `256` บิตเป็นวลีช่วยจำ seed และสร้าง seed ขนาด `512-bit` จากวลีดังกล่าวร่วมกับพาสเฟรสที่เลือกใช้ มาตรฐานนี้ไม่ได้ทำให้ประโยคที่ผู้ใช้คิดเองกลายเป็นกระเป๋าสินทรัพย์ดิจิทัลที่ปลอดภัย

### 3. ผูกข้อมูลระบุตัวตนของกระเป๋าสินทรัพย์ดิจิทัลให้สร้างซ้ำได้

ก่อนรับเงินจำนวนมาก ให้บันทึกเครือข่าย master fingerprint มาตรฐานและเส้นทางการสร้างกุญแจทั้งหมด ดัชนีบัญชี ประเภทที่อยู่หรือสคริปต์ และที่อยู่รับชุดแรกที่ตรวจสอบแล้ว สำหรับนโยบาย Bitcoin ต้องเก็บ output descriptor, checksum, key origin, เกณฑ์ จำนวนอุปกรณ์ลงนาม ลำดับกุญแจ และสาขาเงินทอน อุปกรณ์ลงนามแต่ละเครื่องต้องยืนยันกุญแจของตนและนโยบายที่แสดงอย่างอิสระ ถือ `xpub` เป็นเมตาดาต้าที่ละเอียดอ่อน เพราะใช้สร้างกุญแจสาธารณะลูกแบบ non-hardened กระทบความเป็นส่วนตัว และเมื่อรั่วพร้อมกุญแจส่วนตัวลูกแบบ non-hardened ที่เกี่ยวข้อง อาจเปิดเผยกุญแจส่วนตัวแบบขยายของแม่ตาม BIP-32

### 4. สำรองข้อมูลและทดสอบการกู้คืน

ป้องกันข้อมูลทุกส่วนที่จำเป็นต่อการกู้คืน รวมถึงวลีช่วยจำ seed หรือ share, พาสเฟรส, descriptor หรือการตั้งค่าสมาร์ทแอคเคานต์, เส้นทางการสร้างกุญแจ และคำแนะนำ อย่าแบ่งคำในวลีช่วยจำเองแบบไม่มีมาตรฐาน หากไม่ต้องการให้สำเนาเดียวกู้คืนได้ ให้ใช้ระบบเกณฑ์หรือ multisig ที่มีข้อกำหนดชัดเจน เก็บสำเนาไว้ใน failure domain ที่เป็นอิสระจริงและติดตามการเข้าถึงโดยไม่เปิดเผยเนื้อหา ฝึกกู้คืนบนอุปกรณ์สำรองที่เชื่อถือได้หรืออุปกรณ์ลงนามที่ตั้งค่าใหม่ เปรียบเทียบ fingerprint นโยบาย และที่อยู่รับที่คาดไว้ก่อนล้างสภาพแวดล้อมทดสอบ

### 5. สร้างและตรวจสอบเจตนาการลงนามทั้งหมด

ผู้ประสานงานออนไลน์อาจอ่านสถานะเชนและสร้างคำขอที่ยังไม่ลงนาม แต่ต้องถือว่าไม่น่าเชื่อถือ สำหรับ Bitcoin `PSBT` ให้ตรวจสอบเครือข่าย อินพุตและมูลค่า UTXO ทุกชุด เอาต์พุตผู้รับ จำนวน ค่าธรรมเนียม อัตราค่าธรรมเนียม locktime นโยบาย sighash และยืนยันว่าเอาต์พุตอื่นทุกชุดเป็นเงินทอนของตน สำหรับธุรกรรม EVM ให้ตรวจสอบ `chainId`, `nonce`, `to`, `value`, gas limit, fee cap และ `data` ที่ถอดรหัสแล้ว สำหรับ EIP-712 ให้ตรวจสอบโดเมน `chainId`, `verifyingContract`, ฟิลด์ข้อความ nonce และ deadline เมื่อเกี่ยวข้อง EIP-712 ทำให้ข้อมูลมีโครงสร้างและแยกโดเมน แต่ไม่ได้ป้องกัน replay ด้วยตัวมาตรฐานเอง

### 6. ลงนามผ่านขอบเขตการถ่ายโอนที่ควบคุมไว้

ส่งเฉพาะ payload ที่ยังไม่ลงนามหรือลงนามบางส่วนผ่าน QR การ์ด สายเคเบิล หรือช่องทางที่อนุมัติ Air gap และ QR ไม่ได้ทำให้ parser หรือสื่อน่าเชื่อถือ อุปกรณ์ลงนามต้องแยกวิเคราะห์ payload ยืนยันนโยบายและเงินทอน แสดงผลกระทบสำคัญ และปฏิเสธฟิลด์ที่ไม่รองรับ สำหรับ multisig ต้องแยกอุปกรณ์ ผู้ปฏิบัติงาน สถานที่ ผู้ขาย และเส้นทางกู้คืนให้เป็นอิสระตามโมเดลภัยคุกคาม ผู้ประสานงานควรเปลี่ยนแทนได้และแก้นโยบายโดยไม่มีใครสังเกตไม่ได้ ก่อนเผยแพร่ให้เทียบธุรกรรมหรือคำสั่งที่ลงนามแล้วกับเจตนาที่อนุมัติ

### 7. กระทบยอด บำรุงรักษา และเตรียมการย้าย

หลังเผยแพร่ ให้เทียบ transaction ID ธุรกรรมที่ถูกรวม เอาต์พุตหรือ log ค่าธรรมเนียมจริง เงินทอน nonce ของบัญชี allowance และยอดคงเหลือกับเจตนาที่ลงนาม แล้วรอไฟนอลิตี้ตามเชนและกรณีใช้งาน ดูแลซอฟต์แวร์ที่เข้ากันได้ ช่องทางเฟิร์มแวร์ที่ตรวจสอบแล้ว ข้อมูลสำรองที่อ่านได้ descriptor ที่มีเอกสาร และการฝึกกู้คืนเป็นระยะโดยไม่ป้อนความลับจริงในอุปกรณ์ออนไลน์ หากกุญแจลงนามหรือข้อมูลกู้คืนอาจรั่ว บัญชีแบบกุญแจเดียวไม่สามารถเพิกถอนกุญแจเดิมได้ ต้องสร้างสิทธิ์ใหม่ ย้ายสินทรัพย์และบทบาท ยกเลิกสิทธิ์ที่เหลือเมื่อโปรโตคอลรองรับ และเก็บบันทึกเหตุการณ์

<a id="example"></a>

## ตัวอย่างที่มีการทำงาน

### การจัดสรรและการจัดหาทุนเป็นระยะ

แผนดูแลกำหนดให้กระเป๋าสินทรัพย์ดิจิทัลออนไลน์ถือไม่เกิน `5%` ของมูลค่าสินทรัพย์ `100,000 units` ดังนั้นส่วนออนไลน์คือ `100,000 × 5% = 5,000 units` และส่วนออฟไลน์คือ `95,000 units` เริ่มด้วยการทดสอบ `100-unit` ไปยังปลายทางออฟไลน์ แล้วโอนส่วนที่เหลือ `95,000 - 100 = 94,900 units` หลังสองรายการ ยอดเป้าหมายออฟไลน์คือ `100 + 94,900 = 95,000 units` การทดสอบเล็กช่วยจำกัดข้อผิดพลาดในการตั้งค่าครั้งนี้ แต่ไม่ยืนยันการลงนามหรือการกู้คืนในอนาคต

### ค่าธรรมเนียมและการเปลี่ยนแปลง Bitcoin PSBT

`PSBT` ใช้อินพุต `0.80 BTC` และ `0.35 BTC` รวมเป็น `1.15 BTC` จ่ายผู้รับ `1.00 BTC` และคิดค่าธรรมเนียม `250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC` เอาต์พุตเงินทอนที่ยืนยันแล้วจึงต้องเป็น `1.15 - 1.00 - 0.000020 = 0.149980 BTC` หากอุปกรณ์ลงนามระบุไม่ได้ว่าเอาต์พุตนี้เป็นเงินทอนตามนโยบายที่บันทึกไว้ ก็ไม่ควรลงนามแม้ยอดรวมจะคำนวณลงตัว

### งบประมาณสูงสุด EVM เปรียบเทียบกับค่าธรรมเนียมจริง

บัญชี EVM เริ่มด้วย `5 ETH` และอนุมัติการโอน `1.2 ETH` ค่า `30,000 gas` เป็น gas limit และ `50 gwei` เป็นค่าธรรมเนียมสูงสุด จึงให้งบค่าธรรมเนียม `30,000 × 50 gwei = 0.001500 ETH` หากใช้จริง `21,000 gas` ที่ effective price `25 gwei` ค่าธรรมเนียมจริงคือ `21,000 × 25 gwei = 0.000525 ETH` และเหลือ `5 - 1.2 - 0.000525 = 3.799475 ETH` อุปกรณ์ลงนามต้องตรวจ fee cap และ `data` ไม่ควรคิดว่างบสูงสุดจะถูกเรียกเก็บทั้งหมด หรือหน้าจอที่ดูว่างเปล่าพิสูจน์ว่าเป็นการโอนธรรมดา

### ความยืดหยุ่นของอุปกรณ์ลงนามสองในสาม

นโยบาย `2-of-3` ใช้อุปกรณ์ลงนาม `A`, `B`, `C` และมีคู่ที่ลงนามได้ `3` คู่ คือ `AB`, `AC`, `BC` หากใช้ไม่ได้หนึ่งเครื่องจะเหลือ `1` คู่ หากถูกเจาะหนึ่งเครื่อง ผู้โจมตีเพียงรายเดียวยังคุมคู่ที่ใช้ได้ `0` คู่ แต่หากถูกเจาะสองเครื่อง ผู้โจมตีจะคุม `1` คู่และใช้จ่ายได้ ระบบจึงทนต่อการสูญหายหนึ่งเครื่องหรือการเจาะแยกหนึ่งเครื่อง แต่ไม่ทนต่อสองเครื่อง และการกู้คืนยังต้องมี descriptor ข้อมูลการสร้างกุญแจ และลำดับกุญแจที่ถูกต้อง

<a id="risks"></a>

## ความเสี่ยงและความล้มเหลวในการทบทวน

- **เครือข่ายหรือนโยบายผิด:** การกู้กุญแจที่ถูกต้องภายใต้เชน ประเภทที่อยู่ สคริปต์ บัญชี หรือนโยบายสมาร์ทแอคเคานต์ที่ผิด อาจได้ที่อยู่อื่นหรือที่อยู่ที่ใช้ไม่ได้
- **เอนโทรปีไม่เพียงพอ:** ค่ากึ่งสุ่มที่คาดเดาได้ brainwallet หรือเครื่องสร้างที่ถูกเจาะ อาจทำให้กุญแจออฟไลน์ถูกเดาได้
- **ความลับที่ผู้อื่นจัดเตรียม:** วลีช่วยจำ seed ที่พิมพ์ไว้ล่วงหน้า นำเข้า ถ่ายภาพ หรือได้จากผู้ช่วย อาจอยู่ภายใต้การควบคุมของผู้โจมตีแล้ว
- **ข้อมูลสำรองรั่วไหล:** กระดาษ โลหะ สำเนาคลาวด์ เครื่องพิมพ์ กล้อง การขนส่ง หรือเอกสารมรดก อาจเปิดเผยสิทธิ์ใช้จ่ายทั้งหมด
- **พาสเฟรสผิดพลาด:** พาสเฟรส BIP-39 ที่สูญหายหรือพิมพ์ผิดอาจสร้างกระเป๋าสินทรัพย์ดิจิทัลอีกชุดโดยไม่แสดงข้อผิดพลาด
- **ค่าการสร้างกุญแจไม่ตรงกัน:** เส้นทาง coin type ดัชนีบัญชี หรือข้อกำหนดเฉพาะของกระเป๋าสินทรัพย์ดิจิทัลที่หายไป อาจทำให้มองไม่เห็นสินทรัพย์ที่กู้ได้
- **ข้อมูลกำหนดค่าสูญหาย:** กุญแจ multisig ที่ไม่มี descriptor เกณฑ์ ประเภทสคริปต์ key origin และลำดับ อาจสร้างกระเป๋าสินทรัพย์ดิจิทัลที่รับเงินไว้แล้วซ้ำไม่ได้
- **เมตาดาต้าสาธารณะรั่วไหล:** `xpub`, descriptor, รายการที่อยู่ หรือฐานข้อมูลผู้ประสานงาน อาจเปิดเผยยอด ความเชื่อมโยง และที่อยู่ในอนาคต
- **ห่วงโซ่อุปทานถูกโจมตี:** ฮาร์ดแวร์ เฟิร์มแวร์ ซอฟต์แวร์ บรรจุภัณฑ์ หรือช่องทางอัปเดตที่ถูกแก้ไข อาจเปลี่ยนเอนโทรปี ที่อยู่ หรือลายเซ็น
- **โฮสต์สับเปลี่ยนข้อมูล:** ผู้ประสานงานออนไลน์อาจเปลี่ยนผู้รับ จำนวน ค่าธรรมเนียม เงินทอน calldata ข้อความแบบ typed data หรือ payload ที่ยังไม่ลงนาม
- **หน้าจอแสดงข้อมูลไม่ครบ:** การตัดข้อความ blind signing สคริปต์ที่ไม่รองรับ หรือการถอดรหัสไม่สมบูรณ์ อาจซ่อนสิทธิ์สำคัญ
- **โจมตีที่อยู่เงินทอน:** หากอุปกรณ์ลงนามไม่ยืนยันเงินทอนกับนโยบาย ธุรกรรม Bitcoin อาจส่งเอาต์พุตที่ปลอมเป็นเงินทอนไปยังผู้โจมตี
- **ค่าธรรมเนียมหรือ nonce ผิด:** ค่าธรรมเนียมสูงเกิน nonce EVM เก่า locktime ผิด หรือโหมด sighash ที่ไม่ตั้งใจ อาจทำให้ธุรกรรมล่าช้า ถูกแทนที่ หรือเปลี่ยนผล
- **สิทธิ์สัญญายังคงอยู่:** การอนุมัติโทเค็น permit โมดูล delegate และคำสั่งผู้ดูแล อาจมีผลนานกว่าธุรกรรมที่เห็น
- **โจมตีช่องทางถ่ายโอน:** QR, USB, การ์ดหน่วยความจำ สายเคเบิล และรูปแบบ parser อาจนำ payload อันตรายหรือทำให้เมตาดาต้ารั่ว
- **องค์ประชุมมีความสัมพันธ์กัน:** อุปกรณ์ลงนามอยู่ที่เดียวกัน ใช้ seed ร่วมกัน พึ่งผู้ขายหรือผู้ปฏิบัติงานรายเดียว หรือมีจุดกู้คืนเดียว จะลดความเป็นอิสระของเกณฑ์
- **การโจมตีทางกายภาพ:** การโจรกรรม การข่มขู่ การเฝ้าติดตาม การแก้ไขอุปกรณ์ และการค้นพบความลับ ยังเกิดได้โดยไม่ต้องเชื่อมต่อเครือข่าย
- **ความเสียหายจากสภาพแวดล้อม:** ไฟไหม้ น้ำท่วม การกัดกร่อน สื่อเสื่อม ตู้เซฟเข้าไม่ได้ การเสียชีวิต หรือการไร้ความสามารถ อาจทำให้ใช้ความลับที่ถูกต้องไม่ได้
- **ความเข้ากันได้เสื่อมลง:** เฟิร์มแวร์เก่า วิธีสร้างกุญแจหรือประเภทสคริปต์ที่ไม่รองรับ และการย้ายที่ไม่มีบันทึก อาจขัดขวางการกู้คืนหรือการลงนามในอนาคต
- **ตอบสนองเหตุการณ์ไม่ครบ:** การตรวจยอดโดยไม่ย้ายกุญแจ บทบาท การอนุมัติ และสิทธิ์กู้คืน อาจปล่อยให้การเจาะเดิมยังมีผล

<a id="misconceptions"></a>

## ความเข้าใจผิดทั่วไป

### กระเป๋าสินทรัพย์ดิจิทัลแบบออฟไลน์ต้องคงอยู่โดยไม่เชื่อมต่อทางกายภาพตลอดไปหรือไม่?

ไม่ คุณสมบัติสำคัญคือสิทธิ์ลับยังถูกแยกและการลงนามผ่านขอบเขตที่ควบคุมและตรวจสอบได้ อุปกรณ์ฮาร์ดแวร์ที่ต่อสายอาจยังรักษาคุณสมบัตินี้ ขณะที่คอมพิวเตอร์ air-gapped ซึ่งขั้นตอนตั้งค่าหรือตรวจ payload ถูกเจาะอาจรักษาไม่ได้

### เหรียญถูกเก็บไว้ภายในอุปกรณ์ฮาร์ดแวร์หรือไม่?

ไม่ สถานะบล็อกเชนเป็นผู้บันทึกสินทรัพย์ อุปกรณ์เพียงป้องกันหรือใช้สิทธิ์สำหรับลงนามธุรกรรม และข้อมูลกู้คืนที่เข้ากันได้อาจสร้างสิทธิ์นั้นบนระบบอื่นได้

### การสำรองด้วยวิธี mnemonic มีความไวต่อความเสี่ยงน้อยกว่าอุปกรณ์เซ็นต์หรือไม่?

ไม่ วลีช่วยจำ seed ที่ครบและพาสเฟรสที่ต้องใช้สามารถสร้างกระเป๋าสินทรัพย์ดิจิทัลขึ้นใหม่ได้ แม้ข้อมูลสำรองไม่ถูกใช้ทุกวัน แต่การรั่วไหลอาจมีผลเท่ากับกุญแจลงนามที่ใช้งานอยู่ถูกดึงออกมา

### การใช้มัลติซิกจะช่วยลดความจำเป็นในการสำรองข้อมูลและบันทึกการตั้งค่าหรือไม่?

ไม่ ระบบเกณฑ์ช่วยลดจุดล้มเหลวเดี่ยวบางประเภท แต่กุญแจแต่ละดอกยังต้องมีแผนกู้คืน และต้องสร้างนโยบายหรือ descriptor ของกระเป๋าสินทรัพย์ดิจิทัลซ้ำได้ หากเหลือกุญแจไม่ถึงเกณฑ์หรือข้อมูลกำหนดค่าสูญหาย สินทรัพย์ยังถูกล็อกได้

### การทดสอบโอนข้อมูลที่ประสบความสำเร็จพิสูจน์ได้หรือไม่ว่าระบบเก็บข้อมูลเย็นปลอดภัย

ไม่ การทดสอบยืนยันเพียงเส้นทางจำกัด ณ เวลาหนึ่ง ไม่ได้พิสูจน์คุณภาพเอนโทรปี ความลับของข้อมูลสำรอง การกู้คืน การถอดรหัสธุรกรรมในอนาคต ความเป็นอิสระขององค์ประชุม การอัปเดตซอฟต์แวร์ ความปลอดภัยของสัญญา หรือการรับมือเหตุการณ์

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [กระเป๋าสินทรัพย์ดิจิทัลฮาร์ดแวร์](/th/crypto/hardware-wallet/)
- [วลีเมล็ดพันธุ์](/th/crypto/seed-phrase/)
- [กุญแจสาธารณะและกุญแจส่วนตัว](/th/crypto/public-private-key/)
- [กระเป๋าสินทรัพย์ดิจิทัลมัลติซิก](/th/crypto/multisig-wallet/)
- [การจำลองธุรกรรม](/th/crypto/transaction-simulation/)

<a id="sources"></a>

## แหล่งที่มา

- [ภาพรวมเทคโนโลยีบล็อกเชน](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [BIP 32: กระเป๋าสินทรัพย์ดิจิทัลกำหนดแบบลำดับชั้น](https://bips.dev/32/) - Bitcoin (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [BIP 39: รหัสจำสำหรับการสร้างกุญแจแบบกำหนดได้](https://bips.dev/39/) - Bitcoin (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [BIP 44: โครงสร้างลำดับชั้นหลายบัญชีสำหรับกระเป๋าสินทรัพย์ดิจิทัลเชิงกำหนด](https://bips.dev/44/) - Bitcoin (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [BIP 174: รูปแบบธุรกรรม Bitcoin ที่ลงนามบางส่วน](https://bips.dev/174/) - Bitcoin (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [BIP 380: คำอธิบายสคริปต์ขาออก การปฏิบัติการทั่วไป](https://bips.dev/380/) - Bitcoin (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [BIP 129: การตั้งค่า Multisig แบบปลอดภัย Bitcoin](https://bips.dev/129/) - Bitcoin (เข้าถึง: 2026-08-19)
- ข้อเสนอในการปรับปรุง [EIP-712: การแฮชและการลงนามข้อมูลที่มีโครงสร้างแบบพิมพ์](https://eips.ethereum.org/EIPS/eip-712) - Ethereum (เข้าถึง: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/cold-wallet/index.mdx