يطرح SIGHASH_ANYPREVOUT، المعروف اختصارا بـ APO، فكرة مختلفة عن أسلوب التوقيع المعتاد في بيتكوين. فبدلا من ربط التوقيع بمدخل UTXO محدد بعينه، يمكن استخدامه لتفويض أي UTXO متوافق يطابق الشروط المتبقية في التوقيع.
هذا المقترح ورد في BIP 118، وهو امتداد لفكرة SIGHASH_NOINPUT التي ظهرت مبكرا في ورقة شبكة Lightning عام 2015، ثم طُرحت لاحقا بشكل رسمي على قائمة bitcoin-dev في فبراير 2016. وهو ليس تعليمة جديدة داخل سكربت بيتكوين، بل قيمة جديدة ضمن علم SIGHASH، ويُفترض أن يصل عبر ترقية soft fork.
من الناحية التقنية، يحدد علم SIGHASH ما الذي تغطيه التوقيعات وما الذي تتحقق منه تعليمة CHECKSIG. وفي الأنماط الحالية مثل SIGHASH_ALL وSIGHASH_NONE وSIGHASH_SINGLE وANYONECANPAY، تبقى هناك درجة من الارتباط بالمدخلات أو المخرجات، لكن لا يوجد نمط يتجاهل الارتباط بالـ outpoint نفسه، أي معرف المعاملة مع رقم المخرج. هنا يأتي دور APO.
يقترح BIP 118 نسختين: SIGHASH_ANYPREVOUT وSIGHASH_ANYPREVOUTANYSCRIPT. في النسخة الأولى يُستبعد الـ outpoint من ملخص التوقيع، لكن يبقى الالتزام بالمبلغ وscriptPubKey وnSequence. أما النسخة الثانية فتتجاوز أيضا المبلغ وscriptPubKey، ما يجعل التوقيع غير مرتبط بقفل المخرج السابق.
النتيجة العملية هي إمكانية إعادة استخدام التوقيع نفسه لصرف أي UTXO متوافق يحقق الشروط المتبقية. فإذا جرى توقيع معاملة مسبقا لإنتاج مخرج بقيمة 0.5 BTC، يمكن إعادة ربطها لاحقا بمدخل آخر بالقيمة نفسها حتى لو لم يعد المفتاح الخاص المستخدم في التوقيع الأصلي متاحا. لكن إذا كان المدخل الجديد أكبر من 0.5 BTC ولم تتضمن المعاملة مخرجا للباقي، فقد يذهب الفائض إلى المعدنين.
هذه الخاصية تجعل APO مفيدا خصوصا في بروتوكولات الطبقة الثانية، حيث قد تحتاج المعاملة الموقعة مسبقا إلى العمل مع أكثر من UTXO محتمل على السلسلة من دون إعادة إنشاء توقيع جديد في كل مرة. كما أن النسخة التي تحتفظ بالالتزام بـ scriptPubKey تبدو أكثر ملاءمة للاستخدامات الشبيهة بالـ covenants، لأنها تسمح بإعادة الاستخدام مع الحفاظ على الارتباط بنفس القفل.
في المقابل، يحمل هذا التصميم مخاطرة واضحة هي إعادة الاستخدام غير المقصود للتوقيع. فبما أنه لا يرتبط بمدخل محدد، قد يصبح صالحا لصرف UTXO آخر إذا تطابقت الشروط المتبقية. وتزداد حساسية هذه النقطة في بعض التركيبات مثل ANYPREVOUT | SINGLE أو عندما يوجد UTXO آخر بنفس scriptPubKey والمبلغ، أو عندما يتكرر المفتاح العام داخل سكربت متوافق.
ورغم أن الفكرة لا تقدم وحدها covenants تكرارية أو introspection للمعاملات، فإنها تخفف بشكل ملموس من صلابة الربط بين التوقيع وUTXO واحد بعينه. ولهذا ينظر إليها كثير من المطورين كأداة قد تقلل تعقيد إدارة المفاتيح في بعض تصميمات Lightning والمحافظ والطبقات الثانية، مع بقاء تفاصيل الأمان ومنع إعادة الاستخدام جزءا أساسيا من أي تطبيق عملي.
