حفاظت اور تحویل
Bitcoin seed phrase کیا ہے؟ محفوظ backup بنانے کا طریقہ
Seed phrase کو offline لکھنے، backup جانچنے، recovery drill، نئی seed پر migration اور پرانے backup کو محفوظ طور پر retire کرنے کا طریقہ۔

Seed phrase یا والیٹ بیک اپ الفاظ کی وہ ترتیب ہے جس سے موزوں والیٹ میں نجی کلیدیں دوبارہ بن سکتی ہیں۔ جس شخص کے پاس درست بیک اپ اور، اگر لگائی گئی ہو، درست passphrase ہو، وہ متعلقہ BTC تک رسائی حاصل کر سکتا ہے۔ اسی لیے seed phrase عام پاس ورڈ نہیں: اسے reset لنک یا معاونتی درخواست سے واپس نہیں لایا جا سکتا۔
تمام والیٹس ایک ہی بیک اپ معیار استعمال نہیں کرتے۔ BIP39 میں 12، 15، 18، 21 یا 24 الفاظ ممکن ہیں، جبکہ بعض والیٹس SLIP39 جیسے دوسرے معیار میں 20-word shares دیتے ہیں۔ اپنے مخصوص والیٹ کی سرکاری ہدایات کو اصل قاعدہ سمجھیں؛ انٹرنیٹ پر لکھی عام word count دیکھ کر بیک اپ نہ بنائیں۔
Seed phrase، نجی کلید، PIN اور passphrase میں فرق
یہ چار چیزیں ملتی جلتی نہیں:
| راز | کام | گم یا ظاہر ہونے کا اثر |
|---|---|---|
| Seed/والیٹ بیک اپ | والیٹ کلیدیں restore کرنا | گم ہو تو بازیابی ختم؛ ظاہر ہو تو رقم چوری ہو سکتے ہیں |
| نجی کلید | مخصوص ایڈریس/کلیدیں سے spend authorize | ظاہر ہو تو متعلقہ رقم خطرے میں |
| ڈیوائس PIN | جسمانی ڈیوائس کھولنا | بھولنے پر ڈیوائس reset ہو سکتا ہے؛ seed سے بازیابی ممکن ہو سکتی ہے |
| Optional passphrase | seed سے الگ والیٹ derive کرنا | بھولنے پر صحیح seed کے باوجود مطلوب والیٹ نہیں ملتا |
پاس ورڈ منیجر میں ایکسچینج پاس ورڈ رکھنا اور seed phrase کو آن لائن store کرنا ایک حفاظت decision نہیں۔ Seed پورے والیٹ کا master بازیابی material ہو سکتی ہے۔
پہلا اصول: بیک اپ خود والیٹ بنائے
اپنے پسندیدہ الفاظ، شعر، اردو جملہ، تاریخ پیدائش یا آن لائن “seed generator” استعمال نہ کریں۔ BIP39 انسان کے لیے پڑھنے کے قابل الفاظ دیتا ہے، مگر اصل randomness والیٹ کے قابل اعتماد generation process سے آنی چاہیے۔ خود بنائی mnemonic کا اندازہ لگایا جا سکتا ہے۔
ہارڈویئر والیٹ ترتیب میں پہلے سے لکھی ہوئی card یا seller-provided words ملیں تو ڈیوائس استعمال نہ کریں۔ Genuine ترتیب کو نئی والیٹ بیک اپ ڈیوائس کے اپنے عمل میں generate کرنی چاہیے۔
پہلی نقل کیسے لکھیں؟
- Private جگہ میں والیٹ کا سرکاری ترتیب شروع کریں۔
- ڈیوائس یا قابل اعتماد والیٹ interface کے دکھائے الفاظ عین ترتیب میں ہاتھ سے لکھیں۔
- ہر لفظ کا املا اور ترتیب نمبر دوبارہ جانچیں۔
- اسکرین بند ہونے سے پہلے سرکاری confirmation عمل مکمل کریں۔
- نقل کو temporary desk، packaging یا camera view میں نہ چھوڑیں۔
Camera، اسکرین شاٹ، cloud note، ای میل، messaging ایپ، shared printer یا براؤزر form استعمال نہ کریں۔ Connected ڈیوائس پر plain-text نقل malware، sync یا اکاؤنٹ breach سے leak ہو سکتی ہے۔
پہلے اپنے خطرات لکھیں
بیک اپ رکھنے کا بہترین طریقہ ہر گھر کے لیے ایک جیسا نہیں۔ کم از کم ان خطرات کی شدت لکھیں:
- accidental loss یا cleaning میں پھینک دیا جانا؛
- آگ، پانی، نمی یا مواد کا خراب ہونا؛
- گھر کا فرد، visitor یا thief دیکھ لے؛
- فون/computer malware؛
- دباؤ ڈال کر رسائی لینا یا ہدف بنا کر چوری؛
- آپ کی incapacity یا death؛
- اتنی پیچیدگی کہ خود بازیابی نہ کر سکیں۔
ایک خطرہ کم کرتے ہوئے دوسرا نہ بڑھائیں۔ مثال کے طور پر کئی نقول گم ہونے کا خطرہ کم کرتی ہیں، مگر ہر نئی جگہ چوری کا ایک اور موقع بناتی ہے۔
کاغذی بیک اپ کی حدود
کاغذ سادہ، پڑھنے کے قابل اور electronics سے آزاد ہے۔ اس کی کمزوریاں آگ، پانی، مدھم ہوتی سیاہی، پھٹنا اور آسانی سے تصویر بن جانا ہیں۔ سیاہی اور کاغذ کی پائیداری، بند محفوظ جگہ اور جسمانی رسائی سوچیں۔ Lamination پانی سے کچھ حفاظت دے سکتی ہے، مگر گرمی، نمایاں ہونے اور مواد کے طویل مدتی خطرات الگ ہیں۔
Paper پر کوئی label نہ لگائیں جو باہر سے “Bitcoin seed” واضح کرے۔ دوسری طرف اتنا خفیہ code بھی نہ بنائیں کہ future میں خود نہ سمجھ سکیں۔
دھاتی بیک اپ کب مفید ہے؟
دھات گرمی، پانی اور جسمانی نقصان کے مقابلے میں کاغذ سے زیادہ پائیدار ہو سکتی ہے، مگر خود بخود محفوظ نہیں۔ دیکھیں:
- material اور tested temperature claims؛
- words یا indexed letters درست درج کرنے کا طریقہ؛
- sharp tools اور ترتیب privacy؛
- plate مکمل phrase ظاہر کرتی ہے یا نہیں؛
- tampering کا پتہ چل سکتا ہے؟
- رکھنے کی جگہ چوری سے محفوظ ہے؟
غلط stamping مستقل اور صاف نظر آنے والی غلطی بن سکتی ہے۔ Product marketing کے بجائے independent durability evidence اور والیٹ compatibility دیکھیں۔
ایک نقل رکھیں یا دو؟
ایک نقل
چوری کے مواقع کم، مگر ایک ہی جگہ ناکامی کا سبب بن سکتی ہے۔ گھر کی آگ یا غلطی سے پھینک دینا مکمل بازیابی ختم کر سکتا ہے۔
دو مکمل نقول
Redundancy بہتر، مگر دونوں میں سے کوئی بھی رقم recover کر سکتی ہے۔ دونوں کو ایک drawer، building یا keychain پر رکھنا جغرافیائی redundancy نہیں۔ Access rules دونوں جگہ برابر مضبوط ہونے چاہئیں۔
الفاظ خود تقسیم کرنے کا خطرہ
Seed phrase کو خود آدھا آدھا بانٹنا خطرناک improvisation ہے: ایک حصہ گم ہو تو بازیابی رک سکتی ہے، مشترک الفاظ حفاظت کم کر سکتے ہیں اور وارث غلط سمجھ سکتے ہیں۔ Cryptographic sharing چاہیے تو SLIP39 یا multisig جیسے باقاعدہ معیار اور موزوں والیٹ کی ہدایات سمجھیں؛ گھر کا بنایا کاغذی طریقہ استعمال نہ کریں۔
بیک اپ کی محفوظ تصدیق
تصدیق کا مقصد یہ یقین کرنا ہے کہ الفاظ اور ترتیب والیٹ کے مطابق ہیں، مگر phrase کو کسی نئی website میں لکھنا تصدیق نہیں—یہ چوری کی کوشش ہو سکتی ہے۔ ترجیح یہ ہے:
- والیٹ یا ڈیوائس کی سرکاری built-in بیک اپ جانچ؛
- ہارڈویئر والیٹ ہو تو words ڈیوائس پر enter کرنا، computer keyboard پر نہیں، اگر manufacturer یہی instruction دے؛
- سافٹ ویئر والیٹ میں صرف سرکاری documented method؛
- آزمائشی کے دوران camera، اسکرین-share اور remote معاونت بند۔
رقم والے والیٹ کو صرف تجربے کے لیے reset نہ کریں جب تک تصدیق شدہ بیک اپ، واضح بازیابی منصوبہ اور ناکامی کا نتیجہ مکمل نہ سمجھیں۔ بیک اپ جانچ اور مکمل restore drill ایک جیسی چیز نہیں۔
بازیابی کی مشق کیسے کریں؟
Full بازیابی drill advanced اور خطرہ-bearing عمل ہے۔ اگر کرنا ہو تو:
- والیٹ format اور derivation compatibility کی سرکاری ہدایات پڑھیں؛
- original funded ڈیوائس کو wipe نہ کریں؛
- قابل اعتماد اضافی compatible ڈیوائس استعمال کریں؛
- phrase صرف approved secure input path پر دیں؛
- receive addresses original والیٹ سے match کریں؛
- کوئی لین دین ضروری نہ ہو تو send نہ کریں؛
- آزمائشی environment کے بعد راز traces نہ چھوڑیں۔
غیر یقینی user کے لیے built-in بیک اپ verification زیادہ محفوظ ہو سکتی ہے۔ YouTube comments یا direct-پیغام “expert” سے بازیابی نہ کروائیں۔
اختیاری passphrase: اضافی حفاظت، اضافی ذمہ داری
BIP39 passphrase seed سے ایک الگ والیٹ derive کر سکتی ہے؛ ہر مختلف passphrase technically valid مگر مختلف والیٹ دے سکتی ہے۔ Typo بھی خالی والیٹ دکھا سکتا ہے۔ کوئی “wrong passphrase” warning لازماً نہیں آتی۔
Passphrase استعمال کرنے سے پہلے:
- عین املا، بڑے چھوٹے حروف اور spaces سمجھیں؛
- seed اور passphrase ایک جگہ رکھنے کا trade-off لکھیں؛
- memory کو واحد بیک اپ نہ بنائیں؛
- inheritance منصوبہ میں اس کا وجود واضح مگر راز محفوظ رکھیں؛
- small آزمائشی اور بازیابی verification کریں۔
Beginner کے لیے مضبوط single بیک اپ پہلے، advanced passphrase بعد میں بہتر sequence ہو سکتا ہے۔ Extra feature خطرہ capacity نہیں بڑھاتی اگر user اسے recover نہ کر سکے۔
بیک اپ کے الفاظ، زبان اور املا
BIP39 specification non-English wordlists کو discourage کرتی ہے کیونکہ وسیع compatibility زیادہ تر English list کے ساتھ ہے۔ والیٹ جو words خود دے، انہیں translate نہ کریں۔ Urdu معنی لکھ کر اصل English word بدلنا بازیابی تباہ کر سکتا ہے۔
Capitalization عموماً BIP39 English list میں relevant نہیں، مگر spelling اور order ضرور ہیں۔ Generic assumption کے بجائے والیٹ کی سرکاری rules دیکھیں۔
Seed ظاہر کیے بغیر جگہ کا نقشہ
ایک الگ بازیابی instruction document مفید ہو سکتا ہے جس میں seed خود نہ ہو:
- والیٹ brand/model یا سافٹ ویئر name؛
- بیک اپ format، مثلاً BIP39 یا vendor-specific؛
- بیک اپ کی قانونی access location کا اشارہ؛
- ڈیوائس PIN اور seed کا فرق؛
- سرکاری ہدایات کا URL؛
- قابل اعتماد executor اور پیشہ ور رابطہ؛
- last جائزہ تاریخ۔
Document ایسا نہ ہو کہ thief کو مکمل route مل جائے، مگر وارث مکمل اندھیرے میں بھی نہ رہے۔
وراثت کا منصوبہ
صرف phrase خاندان کو دے دینا منصوبہ نہیں۔ وہ phishing، wrong والیٹ یا passphrase error کا شکار ہو سکتے ہیں۔ منصوبہ میں:
- کون قانونی طور پر access کرے گا؛
- کس event کے بعد instructions کھلیں گی؛
- compatible ڈیوائس کہاں سے آئے گا؛
- small آزمائشی ایڈریس کیسے verify ہوگا؛
- tax/estate professional کب شامل ہوگا؛
- بیک اپ exposure کے بعد رقم نئی کلیدیں پر کب منتقل ہوں گے۔
عوامی will، shared ای میل یا ordinary cloud folder میں seed phrase خود نہ لکھیں۔ مقامی inheritance اور tax law کے لیے qualified adviser درکار ہو سکتا ہے۔
Seed phrase ظاہر ہو جائے تو کیا کریں؟
Seed phrase کی تصویر بن گئی، website میں داخل ہوئی، کسی شخص نے دیکھی یا محفوظ نقل چوری ہوئی تو صرف ڈیوائس PIN یا ایکسچینج پاس ورڈ بدلنا کافی نہیں۔ اس phrase سے بنی کلیدیں متاثر سمجھی جائیں گی۔
محتاط emergency path:
- suspected scammer سے رابطہ بند کریں؛
- صاف اور قابل اعتماد ڈیوائس پر والیٹ کے سرکاری ماخذ کی تصدیق کریں؛
- بالکل نئی seed/کلیدیں والا والیٹ بنائیں؛
- نئی بیک اپ صحیح اور آف لائن verify کریں؛
- متاثر والیٹ سے نئی verified ایڈریس پر رقم منتقل کریں؛
- پہلے ایڈریس/نیٹ ورک confirm کریں؛ urgency میں بھی جعلی help نہ لیں؛
- old seed کو آئندہ receive کے لیے استعمال نہ کریں۔
اگر حملہ آور سرگرم ہو تو وقت اہم ہے، مگر کوئی نامعلوم آن لائن recovery service مزید خطرہ بن سکتی ہے۔ راز کو “جانچنے” کے لیے کسی کو نہ بھیجیں۔
بیک اپ گم ہو مگر والیٹ ابھی چل رہا ہو
یہ محفوظ حالت نہیں۔ ڈیوائس کی خرابی کسی بھی وقت رسائی ختم کر سکتی ہے، اور ہر والیٹ موجودہ seed دوبارہ نہیں دکھاتا۔ سرکاری ہدایات سے دیکھیں کہ تصدیق شدہ نیا والیٹ بنا کر رقم کیسے منتقل کی جائے۔ نیا بیک اپ مکمل جانچنے سے پہلے پرانا والیٹ wipe نہ کریں۔
نئی seed پر منتقلی کے بعد پرانا بیک اپ کیسے retire کریں؟
نئی wallet بنانا migration کا آغاز ہے، اختتام نہیں۔ پرانی seed یا backup فوراً تلف کرنے سے ایسا incoming payment، change output یا account record چھوٹ سکتا ہے جو ابھی پرانے wallet سے وابستہ ہو۔ دوسری طرف پرانا backup ہمیشہ active سمجھ کر رکھنا confusion اور غیر ضروری exposure بڑھاتا ہے۔ اس لیے retirement کے واضح مراحل لکھیں۔
- نئی seed صرف trusted wallet process سے بنائیں اور اس کا offline backup verify کریں؛
- نئی receive address کو wallet یا hardware device کی trusted screen پر دیکھیں؛
- پہلے چھوٹی test transfer کریں اور confirmations کے بعد spendable balance دیکھیں؛
- باقی BTC منتقل کریں اور ہر transaction ID اپنے private record میں رکھیں؛
- پرانے wallet میں باقی balance، pending transaction، change اور استعمال ہونے والے receive addresses دوبارہ دیکھیں؛
- لوگوں، services یا notes میں محفوظ پرانا receive address آئندہ استعمال کے لیے retire کریں؛
- migration مکمل ہونے کے بعد ہی پرانے physical backup کی retention یا destruction policy نافذ کریں۔
Migration record میں seed words نہیں، صرف یہ fields ہوں: old wallet label، new wallet label، migration date، transaction IDs، verification date، remaining balance اور old receive routes بند کرنے کی حالت۔ Label ایسا نہ ہو جو گھر میں ملنے پر فوراً Bitcoin holdings ظاہر کر دے۔
پرانا wallet خالی ہو تب بھی اس کی seed غیر حساس نہیں ہو جاتی۔ وہ address history اور past transactions ظاہر کر سکتی ہے، اور کسی غلطی سے دوبارہ موصول رقم پر اختیار دے سکتی ہے۔ اسے social media، support chat یا عام waste میں نہ ڈالیں۔ Physical material تلف کرنا ہو تو اس کے medium اور مقامی safety rules کے مطابق ایسا طریقہ اپنائیں جس سے الفاظ دوبارہ پڑھے نہ جا سکیں؛ آگ یا hazardous tools خود نیا خطرہ بنا سکتے ہیں۔
اگر پرانی seed پہلے ہی leak ہو چکی ہے تو کامل documentation کے انتظار میں رقم وہیں نہ چھوڑیں۔ صاف setup، نئی verified seed اور درست address کی تصدیق پہلے ہے؛ retirement paperwork بعد میں مکمل کیا جا سکتا ہے۔ لیکن urgency میں کسی online “recovery expert” کو دونوں seeds دینا دو wallets متاثر کر دے گا۔
سالانہ جسمانی جانچ
بیک اپ کو بے وجہ ظاہر کیے بغیر سال میں کم از کم ایک بار یہ جانچ کریں:
- رکھنے کی جگہ قابل رسائی مگر نجی ہے؟
- پانی، corrosion، fire یا tampering کا نشان؟
- heirs/executor information تازہ؟
- والیٹ کی ہدایات اور compatible ڈیوائس دستیاب ہیں؟
- passphrase ریکارڈ اور separation policy برقرار؟
- کوئی نقل move یا photograph تو نہیں ہوئی؟
Audit log میں seed words نہ لکھیں؛ صرف تاریخ، condition اور next action لکھیں۔
کبھی نہ کریں
- فون photo، اسکرین شاٹ یا cloud sync؛
- ای میل، Telegram، WhatsApp یا معاونت chat؛
- seed کو پاس ورڈ منیجر میں plain text؛
- website یا براؤزر ایکسٹینشن میں “verification”؛
- seller کی پہلے سے لکھی phrase؛
- phrase translate یا reorder کرنا؛
- memory کو واحد نقل بنانا؛
- نامعلوم ایپ میں بازیابی آزمائشی؛
- بیک اپ کے ساتھ والیٹ ایڈریس اور واضح label عوامی رکھنا۔
Bitcoin phishing اور 2FA کی حفاظتی checklist سماجی چال کے خطرے کو مزید واضح کرتی ہے۔
بنیادی ذرائع
- BIP39 specification: Mnemonic code
- Bitcoin.org: Securing Your Wallet
- Trezor: Wallet backups — 12, 20 or 24 words
- Ledger: What Is a Seed Phrase?
یہ کسی vendor کی تشہیر نہیں بلکہ حفاظتی تعلیم ہے۔ اپنے مخصوص والیٹ کی موجودہ سرکاری ہدایات کو مقدم رکھیں؛ بیک اپ کی غلطی مستقل مالی نقصان بن سکتی ہے۔
