# ما الذي يحدث داخل Bitcoin

Source: https://flashbackcrypto.com/ar/articles/test-btc-steal
Language: ar
Updated: 2026-10-06

السرقة BTC عبر معاملة تجريبية

أولاً، شرح بسيط؛ ثم تحليل فني

يُقال لك: «التحويل معلق. ادفع الرسوم، وسيتم تحويل المبلغ». وأنت تتوقع مبلغًا صغيرًا، فتضغط على «تأكيد»، ثم تدرك أن مبلغًا مختلفًا تمامًا قد تم خصمه من محفظتك.

في إحدى أشكال هذه الحيلة، يقوم المحتال بإعداد معاملة مسبقًا — وهي تحويل مبلغ BTC الخاص بك إلى عنوانه. ويقدمها لك على أنها «دفعة عمولة» أو «رسوم إلغاء القفل». وإذا قمت بتأكيد وتوقيع هذا التحويل المحدد، فأنت بذلك تمنح الإذن بإرسال الأموال بنفسك. وتقوم الشبكة بتنفيذ المعاملة الموقعة، وليس الوعود التي قدمها الشخص الذي أرسلها.

ببساطة: تعتقد أنك تدفع رسومًا فقط، لكن في الواقع، قد تكون تصرح بتحويل مبلغ BTC الخاص بك. تكمن المشكلة في ما تقوم بتأكيده فعليًّا. فالتسمية «butTON» والمبلغ الصغير الموضح على الموقع الإلكتروني لا يعنيان بالضرورة أن محفظتك تصرح بدفع مبلغ صغير فقط.

هناك احتمال آخر: أن التوقيع المطلوب قد تم الحصول عليه بالفعل، أو أن المحتال يعرف مفتاح المحفظة بالفعل. في هذه الحالة، قد يتم إرسال التحويل المُعدّ لاحقًا. وأحيانًا ما يكون دفع رسوم إضافية مجرد إجراء لتأكيد عملية خصم تمت الموافقة عليها بالفعل.

ولكن بدون توقيع أو أي تفويض صالح آخر لإنفاق مبلغ BTC الخاص بك، فإن هذه الحيلة لن تنجح. فإذا قمت ببساطة بدفع ثمن معاملة واحدة من محفظتك الآمنة، فلن يتمكن المستلم من الوصول إلى باقي رصيدك. لذلك، فإن القصة التي تقول إن «شخصًا ما دفع الرسوم — وتم خصم المبلغ بالكامل تلقائيًا من حساب شخص آخر» تغفل النقطة الأساسية: من أين جاء التفويض بخصم الأموال.

والآن دعونا نحلل العوامل التي قد تكون وراء هذه القصة: PSBT، وتبديل التغييرات، ووضع SIGHASH، وخطأ في الرقم العشوائي (nonce)، وتسرب المفتاح. هذه آليات محتملة مختلفة، وليست بالضرورة مراحل هجوم واحد. ويتم تحديد السيناريو المحدد بناءً على المعاملات وإجراءات المالك.

يتكون الرصيد Bitcoin من مخرجات المعاملات غير المنفقة (UTXOs). وتقوم المعاملة الجديدة بإنفاق مخرجات معينة من هذه المخرجات غير المنفقة (UTXOs) وإنشاء مخرجات جديدة. والفرق بين مجموع المدخلات ومجموع المخرجات هو رسوم المعاملة. وقد تؤدي رسوم المعاملة المنخفضة إلى تأخير التأكيد، لكنها لا تمنح الإذن بإنفاق أموال أخرى.

من المهم التمييز بين الملف المُعدّ، والمعاملة الموقعة، والمعاملة الموجودة في ميمبول، والمعاملة المُدرجة في كتلة. فملف PSBT الذي يحتوي على مجموعة غير كاملة من التوقيعات ليس بالضرورة جاهزًا للإرسال. ولا تُثبت الحالة «معلقة» التي تظهر على الموقع الإلكتروني، في حد ذاتها، وجود المعاملة على الشبكة.

يمكن بث المعاملة الموقعة بالكامل إلى الشبكة في وقت لاحق. ولذلك، فإن إمكانية الإنفاق تحدث أحيانًا قبل وقت طويل من ظهور خصم المبلغ من الحساب. ولا يعني اختفاء السجل من ميمبول أو حذف الملف من الواجهة أن المشارك الآخر لم يعد يمتلك نسخة من التوقيع.

الاحتيال في عملية التوقيع على اتفاقية PSBT

PSBT هو تنسيق قياسي لتبادل البيانات خاص بالمعاملات الموقعة جزئيًا Bitcoin. وهو يتيح الفصل بين عملية إعداد المعاملة وعملية إنشاء التوقيعات، بما في ذلك عند استخدام محفظة الأجهزة. والتنسيق بحد ذاته ليس ضارًا. لكن الخطر ينشأ إذا قام المستخدم بالتوقيع على معاملة أعدها طرف ثالث دون التحقق من محتواها.

قبل تأكيد أي معاملة، من الضروري التحقق من المستلمين والمبالغ والرسوم ووجهة الفكة. يصف BIP 174 عملية التحقق من صحة المدخلات، وفحوصات صحة SIGHASH، والتحقق من وجهة الفكة. ولا يكون الجهاز المادي مفيدًا إلا عند استخدامه جنبًا إلى جنب مع التحقق من البيانات على شاشته الموثوقة.

تغيير عنوان التسليم

عندما يتم إنفاق UTXO، يتم استخدام قيمته بالكامل. وإذا كان مبلغ الدفع أقل من تلك القيمة، فعادةً ما يتم إرجاع المبلغ المتبقي إلى المالك كإخراج فكة منفصل. على سبيل المثال، مع مدخل يبلغ 1 BTC، ودفعة تبلغ 0.01 BTC، ورسوم تبلغ 0.0001 BTC، فإن الفكة تبلغ 0.9899 BTC.

إذا تم، في معاملة مُعدة مسبقًا، إرسال هذا الرصيد إلى طرف غير مصرح له وقام المالك بتأكيد التحويل، فإن المالك يفقد الجزء الأكبر من المبلغ، على الرغم من أن الدفعة الصغيرة المتوقعة تُنفذ أيضًا. هذا مثال افتراضي، وليس وصفًا لحادثة حقيقية.

في حالة التوقيع القياسي الذي يسجل جميع المخرجات، لا يمكنك ببساطة تغيير عنوان التسليم بعد التوقيع مع الحفاظ على صلاحية التوقيع نفسه. يجب أن يُدرج التغيير في البيانات التي يتم توقيعها أو أن يتطلب تأكيدًا جديدًا. أما بالنسبة للتوقيع ذي النطاق المختلف، فإن النتيجة تعتمد على وضعه وعلى التوقيعات الأخرى.

لماذا يُعد وضع SIGHASH مهمًا؟

يحدد SIGHASH أجزاء المعاملة التي يحميها التوقيع من التعديل. تتوفر أوضاع مختلفة للمعاملات الكلاسيكية ومعاملات SegWit v0. ويتم تحديد هذه الأوضاع بواسطة البروتوكول، لذا فإن مصطلح «غير قياسي» هنا يشير إلى شيء غير معتاد بالنسبة لإجراء معين يقوم به المستخدم، وليس إلى شيء يُعتبر غير صالح تلقائيًا.

| **الوضع** | **ما تحتاج إلى فهمه** |
| --- | --- |
| SIGHASH_ALL | يسجل جميع المعاملات الصادرة، بما في ذلك المستفيدين والمبالغ. |
| SIGHASH_NONE | وهو لا يؤمن النتائج. فقد تكون هذه النتائج محمية بتوقيعات أخرى. |
| SIGHASH_SINGLE | يقوم بتأمين المخرج المقابل؛ أما حماية المخرجات الأخرى فتعتمد على التوقيعات الأخرى. |
| يمكن لأي شخص أن يدفع | يقتصر الربط على المدخلات الموقعة. وتعتمد حماية المخرجات على الوضع الأساسي. |

مصدر هذا الجدول هو BIP 143 ودليل المطور Bitcoin.

التوقيع الذي يتمتع بنطاق حماية محدود لا يمنح حق الوصول إلى المحفظة بأكملها؛ بل ينطبق فقط على معاملة محددة. ومع ذلك، قد تتجاوز توقعات المالك الضمانات التي يوفرها هذا التوقيع. ولذلك، فإن أي سلوك غير معتاد أثناء عملية دفع روتينية يتطلب تفسيرًا واضحًا. وبالنسبة لـ Taproot، يجب التحقق من قواعد التوقيع بشكل منفصل.

خطأ في توليد الرقم العشوائي في خوارزمية ECDSA

يُستخدم قيمة «نونس» سرية «k» عند إنشاء توقيع ECDSA. وهذه القيمة ليست عمولة ولا عداد معاملات. وقد تؤدي إعادة استخدام نفس القيمة «k» لرسائل مختلفة موقعة بنفس المفتاح، أو الكشف عنها، أو حدوث أخطاء معينة في عملية التوليد، إلى إمكانية استعادة المفتاح الخاص. ومجرد وجود التوقيعات العامة لا يخلق، في حد ذاته، مثل هذه الإمكانية.

بمجرد استعادة المفتاح، يمكن إنشاء توقيعات جديدة لإنفاق الأموال التي يحميها. وفي هذه الحالة، يكون سبب الفقدان هو خلل في برنامج التوقيع، وليس تصرفات الشخص الذي دفع الرسوم. ولا يعني وجود توقيع واحد معرض للخطر بالضرورة الكشف عن جميع المفاتيح المشتقة من عبارة البذرة.

يصف RFC 6979 عملية توليد الرقم العشوائي (nonce) الحتمية؛ وتدعم مكتبة libsecp256k1 هذه الطريقة. وفي أي تطبيق حتمي صحيح، لا يمكن اعتبار إعادة توقيع الرسالة نفسها بمثابة تكرار خطير للرقم العشوائي في رسائل مختلفة.

لا يغطي نظام ECDSA جميع المعاملات الحديثة Bitcoin. يستخدم Taproot توقيعات Schnorr كما هو محدد في BIP 340. ولا يزال أمن الرقم العشوائي (Nonce) ذا أهمية كبيرة، ولكن لا يمكن تطبيق وصف ثغرة أمنية محددة في نظام ECDSA على أي عنوان دون التحقق من نوع الإنفاق.

محفظة تم اختراقها بالفعل

إذا كان المفتاح الخاص أو عبارة البذرة معروفين بالفعل لطرف ثالث، فلا يحتاج هذا الطرف إلى الحصول على توقيع المالك مرة أخرى. ومن الأمثلة على ذلك استيراد عبارة البذرة التي قدمها شخص آخر: فلا يمكن اعتبار هذه المحفظة خاضعة للسيطرة الحصرية للمستلم. وينشأ خطر مماثل في حالة تسرب نسخة احتياطية أو استخدام محفظة مزيفة.

قد يسبق تحويل الأموال إلى هذه المحفظة إنفاقها من قِبل حامل مفتاح آخر. في هذه الحالة، يُعد طلب «إضافة رصيد لتغطية الرسوم» بمثابة توضيح للمستخدم، وكانت إمكانية خصم الرسوم موجودة مسبقًا. في Bitcoin، يتم تضمين الرسوم في معاملة BTC؛ ولا يوجد رمز غاز إلزامي منفصل للتحويل القياسي BTC.

إن معرفة مفتاح خاص واحد ومعرفة عبارة البذرة بأكملها لهما مستويات تأثير مختلفة. في الحالة الأولى، تكون الأموال التي تسمح شروط إنفاقها باستخدام ذلك المفتاح معرضة للخطر. أما في الحالة الثانية، فقد يكون العديد من مفاتيح المحافظ المشتقة معرضة للخطر. تتطلب العبارة «سيتم سرقة كل الأموال» التحقق من بنية UTXO والأذونات المتاحة للمهاجم.

ما هي الأدوار التي يلعبها كل من «RBF» و«CPFP»؟

تسمح تقنية RBF باستبدال معاملة غير مؤكدة بمعاملة متعارضة تستوفي قواعد العقدة، وعادةً ما يكون ذلك مقابل رسوم أعلى. كما يجب أن يكون الاستبدال صالحًا: فزيادة الرسوم لا تعفي من متطلبات التوقيع والإنفاق.

تستخدم CPFP معاملة فرعية تنفق مخرجًا من معاملة أم غير مؤكدة. ويمكن أن تجعل الرسوم التي تتضمنها هذه المعاملة تأكيد الكتلة المرتبطة بها أكثر جاذبية للمُعدِّن. ويجب أن يكون للمشارك الحق في إنفاق المخرج المحدد؛ حيث إن إنشاء معاملة فرعية لا يمنحه صلاحية تغيير تحويل من محفظة شخص آخر بشكل تعسفي.

وبالتالي، يمكن أن تساعد عملية «التسريع» في تأكيد معاملة غير مرغوب فيها تمت الموافقة عليها بالفعل. ومع ذلك، فإنها لا تؤدي إلى الموافقة بحد ذاتها. فالتأخير في التأكيد وسرقة الأموال هما حدثان مختلفان، حتى لو اعتبرهما المستخدم معاملة واحدة تنطوي على رسوم.

ما الذي يجب التحقق منه في حالة معينة

لا يُعرِّف مصطلح «عنوان الاحتفاظ» أو «هجوم الاحتفاظ»، في حد ذاته، شروط الإنفاق الواردة في Bitcoin. قد يكون «عنوان الاحتفاظ» مصطلحًا داخليًّا تستخدمه الخدمة. عليك فحص البرنامج النصي والمعاملة وأذونات المشاركين، وليس اسم العنوان. وبدون هذه المعلومات، من الخطأ ربط «الاحتفاظ» بثغرة أمنية محددة.

لتحديد السبب، ستحتاج إلى أرقام TXID للمعاملة الأصلية والمعاملات اللاحقة، وقائمة المدخلات والمخرجات، والمبالغ، والعناوين، واسم المحفظة، وتسلسل التأكيدات. إذا تم إرسال ملف PSBT، فمن المفيد الحصول على نسخة منه قبل التوقيع. ولا تُعد لقطة الشاشة التي تُظهر الرصيد أو كلمة «Retention» بديلاً عن هذه البيانات.

السؤال الرئيسي هو: من أين جاءت تفويض الإنفاق؟ إذا وقع المالك على الملف، يتم التحقق من البيانات الموقعة ومن قيمة SIGHASH. أما في حالة عدم وجود توقيع، فيتم التحقيق في تسرب المفتاح ومصدر عبارة البذرة وسلوك التطبيق. ويتطلب استبدال المعاملة التحقق من هوية مستلم الرصيد. أما خطأ الرقم العشوائي (nonce) فيتطلب تحليل التوقيعات ذات الصلة وطريقة التنفيذ، بدلاً من التكهنات حول سبب التأخير.

قبل تأكيد المعاملة مرة أخرى، تحقق من المبالغ الإجمالية والرسوم والمستلمين والرصيد المتبقي في محفظتك الموثوقة. لا تدخل أبدًا عبارة البذرة أو مفاتيحك الخاصة على مواقع «التفعيل». إذا اشتبهت في تعرض عبارة البذرة للاختراق، فإن حماية أموالك المتبقية تتطلب إنشاء محفظة جديدة بعبارة بذرة جديدة على جهاز موثوق. لأغراض التحقيق، احفظ سجل الدردشة والملفات وتفاصيل المعاملات دون الكشف عن مفاتيحك الخاصة.

الاستنتاج الفني: تُفسَّر عملية السرقة بالقدرة على إنشاء أو استخدام تفويض إنفاق صالح. تؤثر اللجنة على شروط التأكيد، لكنها لا تمارس سيطرة على BTC الخاص بالآخرين. وإلى أن يتم التحقق من المعاملات، تظل الآليات المذكورة تفسيرات بديلة، ويظل مصطلح «الاحتفاظ» مصطلحًا غير مُعرَّف.

المصادر

الوثائق Bitcoin والمواد الفنية الأساسية

[https://Bitcoin.org/en/how-it-works](https://bitcoin.org/en/how-it-works)

[https://developer.Bitcoin.org/devguide/transactions.html](https://developer.bitcoin.org/devguide/transactions.html)

[https://bips.dev/174/](https://bips.dev/174/)

[https://bips.dev/143/](https://bips.dev/143/)

[https://www.rfc-editor.org/rfc/rfc6979](https://www.rfc-editor.org/rfc/rfc6979)

[https://github.com/Bitcoin-core/secp256k1/blob/master/README.md](https://github.com/bitcoin-core/secp256k1/blob/master/README.md)

[https://bips.dev/340/](https://bips.dev/340/)

[https://github.com/Bitcoin/Bitcoin/blob/master/doc/policy/mempool-replacements.md](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md)

[https://Bitcoincore.reviews/24152](https://bitcoincore.reviews/24152)

[https://Bitcoin.org/Bitcoin.pdf](https://bitcoin.org/bitcoin.pdf)

[https://bips.dev/32/](https://bips.dev/32/)

## Related

- [عمليات الاحتيال على سلسلتي الكتل WAXP و Telos](https://flashbackcrypto.com/ar/articles/waxpscam.md)
- [كيف تعمل عمليات الاحتيال على منصات P2P](https://flashbackcrypto.com/ar/articles/p2pscam.md)
- [فلاش USDT TRC20/ERC20/BEP20](https://flashbackcrypto.com/ar/articles/flashusdt.md)
- [الصفقة في ETH قيد الانتظار](https://flashbackcrypto.com/ar/articles/ethpending.md)
- [إلغاء المعاملة BTC](https://flashbackcrypto.com/ar/articles/btcpending.md)