OP_CHECKLOCKTIMEVERIFY

Bu, harcayan işleme değil, coinin kendisine yazılmış bir zaman kilididir. Peter Todd bunu BIP65'te tanımladı; burada eski no-op işlem kodu NOP2'nin yerini aldı ve kural Aralık 2015'teki 388.381 numaralı bloktan beri uygulanıyor. Bir miras planı ya da kurtarma yolu kurduysanız, kapıyı kapalı tutan şey bu işlem kodudur.

Nasıl çalışır

OP_CHECKLOCKTIMEVERIFY script yığınından bir sayı okur, bunu coini harcamaya çalışan işlemin locktime alanıyla karşılaştırır ve harcama erken ise tüm scripti iptal eder.

BIP65 kontrolün başarısız olduğu beş durumu sıralar: yığın boştur, en üstteki öğe negatiftir, öğe ile işlemin locktime değeri blok mu yoksa saniye mi saydıkları konusunda uyuşmaz, öğe işlemin locktime değerinden büyüktür ya da girdinin sıra numarası 0xffffffff olarak ayarlanmıştır. Bu son koşul bariz bir açığı kapatır. Tüm girdiler final olarak işaretlendiğinde locktime tamamen yok sayılır; dolayısıyla bu koşul olmadan harcayan kişi son tarihi kapatıp parayı alıp gidebilirdi.

Böyle bir scripti ilk kez okuyanları iki ayrıntı şaşırtır. İşlem kodu kontrol ettiği sayıyı tüketmez, bu yüzden gerçek scriptlerde onu yığını düzenlemek için OP_DROP izler. Ayrıca olağan dört bayt yerine beş baytlık bir işlenen kabul eder, çünkü karşılaştırması gerekebilecek en büyük değer 2**32-1, yani kontrol ettiği alanın tam aralığıdır.

Yumuşak çatallanma (soft fork) mekaniği olağan türdendi. Bir no-op'u yeniden tanımlamak, güncellenmemiş yazılımlar için görünmezdir: eski bir düğüm işlem kodunu çalıştırır, hiçbir şey yapmaz ve bloğu yine de kabul eder. Etkinleştirme, dönemin madenci sinyal eşiklerini kullandı: uygulamaya başlamak için 1.000 blokta 750 blok ve zorunlu kılmak için 1.000 blokta 950 blok.

Nerede görülür

OP_CHECKLOCKTIMEVERIFY, paranın bir tarih gelene kadar hareketsiz durması gereken her yerde karşınıza çıkar.

Miras ve kurtarma cüzdanları en açık örnektir. Bir descriptor, kendi anahtarınızın her an harcayabildiğini, yedek anahtarın ise yalnızca belirtilen bir yükseklikten sonra harcayabildiğini söyleyebilir; bu da bir varise kimsenin işbirliğine ve mühürlü zarf tutan bir avukata ihtiyaç duymayan bir yol verir. Miniscript bunu after() parçası olarak yazar ve bunu destekleyen cüzdanlar yüksekliği ham script yerine sade bir dille gösterir.

Lightning bunu yönlendirilen bir ödemenin mutlak son tarihi için kullanır. Bir BOLT11 faturası, varsayılan olarak 18 blokluk bir nihai sona erme deltası taşır ve rota boyunca hashlenmiş sözleşmeler bu rakamın üzerinde katmanlanır, böylece ödeme hiç tamamlanmazsa her sıçrama fonlarını sabit bir sırayla geri alabilir.

Emanet (escrow) ve güven gerektirmeyen geri ödemeler de aynı biçimi izler: şimdi bir scripte ödeyin ve karşı taraf hiç imzalamazsa son tarih geçtikten sonra parayı geri alın. İşlem kodu, “zaman kilitli kasa”yı ürün olarak satan herkese verilecek dürüst yanıttır da, çünkü böyle bir ürünün olabileceği tek şey budur.

OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY bir anı adlandırır; OP_CHECKSEQUENCEVERIFY bir süreyi adlandırır. Biri “Aralık'tan önce değil” der, diğeri “bu belirli coin onaylandıktan 144 blok geçmeden değil” der ve saatini yalnızca ikincisi coin geldiğinde başlatır. BIP112 göreli biçimi tanımladı ve bu biçim, mutlak kardeşinden yaklaşık yedi ay sonra, Temmuz 2016'da 419.328 bloğunda etkinleşti. Sözleşme protokolleri ikisini birlikte, çoğu zaman tek bir scriptte kullanır: tüm anlaşmayı sınırlamak için mutlak bir son tarih ve bir tarafa tepki verebileceği bir pencere garantilemek için göreli bir gecikme.