"Azaltılmış Veri Geçici Softfork" BIP, fikir birliğiyle çeşitli Bitcoin özelliklerinin geçici olarak devre dışı bırakılmasını önermektedir. Bu kuralların her birini ihlal eden geçmiş işlemleri belirleyerek potansiyel etkiyi ölçmek için blok zincirini araştırdım. 🧵↓

Kural #1: "İlk işlem kodu OP_RETURN olmadığı sürece 34 baytı aşan yeni çıktı komut dosyasıPubKeys geçersizdir, bu durumda 83 bayta kadar geçerlidir." Bu, tüm P2PK ve P2MS çıkışlarının yanı sıra az sayıda standart dışı SPK'yı da etkiler.

Kural #2: "BIP16 scriptSigs'deki redeemScript push dışında, 256 bayttan büyük yüklere sahip OP_PUSHDATA* geçersizdir." Bunun yalnızca *yürütülen* veri gönderimleri için geçerli olduğunu varsayıyorum, bu yüzden çok sayıda olan taproot yazıt zarfları içindeki gönderimleri hariç tuttum.

Kural #3: "Tanımsız tanık (veya Tapleaf) sürümlerinin (yani, Tanık v0/BIP 141 veya Taproot/BIP 341 değil) harcanması geçersizdir." Tanımsız sürüm numarası çıktılarına sahip 54 binin biraz üzerinde işlem var (çoğunlukla op_return sınırını aşmak için sahte çıktılar kullanılıyor).

Bununla birlikte, BIP 141 ve 341 belirli tanık programı uzunluklarını tanımlar: - v0, uzunluk 20 (P2WPKH) - v0, uzunluk 32 (P2WSH) - v1, uzunluk 32 (P2TR) yazıldığı gibi, RDTS, P2A çapaları (v1, uzunluk 2) dahil olmak üzere diğer tüm program uzunluklarını yasaklıyor gibi görünüyor.

Kural #4: "Taproot eki olan tanık yığınları geçersizdir." Şimdiye kadar 11 işlem, çoğunlukla jpeg'ler için taproot harcamalarına bir ek ekledi.

Kural #5: "257 bayttan büyük ana kök kontrol blokları (128 komut dosyası yaprağı olan bir merkle ağacı) geçersizdir." 100+ kontrol bloğu derinliği (labitbus ve benzeri) ile ~32k açıkça veri gömme ana kök harcaması vardır. Ama aynı zamanda bir avuç "meşru" harcama daha düşük derinlikte.

Kural #6: "Herhangi bir yerde (yürütülmemiş olsa bile) OP_SUCCESS* işlem kodları içeren tapscript'ler geçersizdir." OP_SUCCESS işlem kodları da dahil olmak üzere iki tarihi taproot harcaması vardır: Burak'ın yıldırım kırıcı işlemi ve bu aptal OP_CAT demosu

Kural #7: "OP_IF veya OP_NOTIF talimatı yürüten tapscript'ler (sonuçtan bağımsız olarak) geçersizdir." Bu, şu ana kadar 104 milyondan fazla işlem tarafından kullanılan "yazıt zarfını" devre dışı bırakmayı amaçlıyor.

Ancak RDTS, yazıt zarfını devre dışı bırakmanın ötesine geçerek OP_IF ve OP_NOTIF tamamen yasaklıyor. Yaklaşık 70 yazıt dışı işlem, taproot komut dosyalarında OP_IF kullandı. Birçoğu bitvm tarzı deneylerdir, ancak daha basit finansal kullanım örnekleri de vardır.

Örneğin, bu "çürüyen çoklu imza" komut dosyası şablonunu kullanan birkaç harcama vardır, bu da birden çok OP_IFs

En endişe verici olanı, bir bip341 NUMS noktasının arkasında bu HTLC komut dosyası şablonunu kullanan bir cüzdandan birden fazla harcama yapılması (anahtar yolunu devre dışı bırakmak) Betik, iki imza ve bir karma ön görüntüsü gerektiren bir dal veya göreli zaman aşımından sonra bir imza arasında seçim yapmak için OP_IF kullanır

RDTS savunucuları, kullanıcıların bunun yerine her zaman anahtar yolu üzerinden harcama yapabileceklerini iddia ederek, taproot'taki OP_IF ve büyük kontrol bloklarıyla ilgili müsadere endişelerini reddettiler. Ancak, yaklaşık 560 bin işlem, anahtar yolunun kanıtlanabilir şekilde devre dışı bırakıldığı taproot çıktılarını harcadı.