OP_CHECKMULTISIG

Ortak saklamayı mümkün kılan şey 0xae baytıdır: bir anahtar sayısını, o kadar genel anahtarı, bir gerekli imza sayısını, o kadar imzayı ve ardından bir öğe fazlasını yığından çıkarır. Konsensüs tek bir çağrıda en fazla 20 anahtara izin verir. Bir şirketin, para çekme işlemini beş yetkiliden üçünün onaylamasını, hiçbiri tek başına hareket edemeyecek şekilde şart koşabilmesinin nedeni budur.

Nasıl çalışır

Doğrulama bir arama değil, iki liste üzerinde tek bir geçiştir. Opcode imzaları sırayla gezer ve her birini art arda gelen genel anahtarlara karşı dener, bu yüzden imzalar ait oldukları anahtarlarla aynı göreli sırada yer almalıdır. Geçerli bir 2/3 yapılandırmasını iki imza yer değiştirmiş halde sunarsanız betik başarısız olur; bu, insanlar çoklu imza harcamalarını elle bir araya getirirken sık görülen bir karışıklık nedenidir.

Yığın bir öğe eksik kalır ve bu her zaman böyle olmuştur. İlk uygulama hiç kullanmadığı fazladan bir öğeyi yığından çıkarıyordu; bu, mevcut tüm coinleri bozmadan kaldırılamayacak bir hataydı. İmzalayanlar önce tek kullanımlık bir öğe eklemeyi öğrendi ve BIP-147, o öğenin boş olmasını şart koşarak bundan doğan değiştirilebilirliği 481.824 bloğundan itibaren kapattı.

Asıl sıkıntı maliyet muhasebesindedir. Yalın bir çağrı, içinde gerçekte kaç anahtar olursa olsun 20 imza işlemi olarak ücretlendirilir; yalnızca hemen önünde küçük bir sayı opcode'u varsa ücret o sayı olur. Bir blok 80.000 birim imza işlemi maliyetiyle sınırlıdır ve aktarım politikası tek bir pay-to-script-hash girdisinde en fazla 15 tanesine izin verir. Betik adreslerinin en fazla on beş ortak imzacıya ulaşmasının nedeni, opcode'un kendi 20 sınırı değil, bu politika sayısıdır.

Tapscript bunu tamamen emekliye ayırdı. BIP-342, opcode'un ve doğrulama varyantının bir Taproot yaprağı içinde görüldüğü anda başarısız olmasını sağladı, çünkü bir Schnorr imza grubunu tek işlemde bir listeye karşı kontrol etmek, Schnorr'u değerli kılan toplu doğrulamayı boşa çıkarır.

Nerede görülür

Her Lightning kanalını fonlayan 2/2 çıktısı OP_CHECKMULTISIG kullanır; bu tek başına opcode'u ağın betik harcamalarının büyük bir bölümüne sokar. Şirket hazineleri, eski eşler arası pazaryerlerindeki emanet (escrow) düzenlemeleri ve Taproot öncesinde kurulmuş borsa soğuk saklaması da bunu kullanır, genellikle bir betik hash'i içinde 2/3 olarak.

Anahtarların hiçbir hash olmadan doğrudan çıktıda durduğu yalın çağrılar, üç anahtara kadar aktarım standardıdır ve neredeyse hiç kullanılmaz, çünkü gönderen her anahtar için ödeme yapar ve tek bir coin hareket etmeden önce tüm düzenleme herkese açıktır. 2014 yılında bu biçim kısa süreliğine zincir üzerinde dosya saklamanın bir yolu haline geldi; veri saklama tartışmalarının, biri aktarım politikasına her dokunduğunda yeniden gündeme gelmesinin bir nedeni de budur.

Şimdi ortak saklama kuruyorsanız, cüzdanınız büyük olasılıkla sayılan alternatifi kullanan bir Taproot düzeni ya da uyumluluk ücretlerden daha önemliyse bir P2WSH betiği üretecektir.

OP_CHECKMULTISIG vs P2SH çoklu imza

OP_CHECKMULTISIG bir komuttur ve P2SH çoklu imza onu paketlemenin bir yoludur. Opcode bir yeter sayının nasıl kontrol edildiğini söyler; paketleme, yeter sayının bir hash'in arkasında gizlendiğini ve harcama anında açığa çıktığını söyler. Aynı komut, anahtarların açıkça göründüğü yalın bir çıktıda, 3 ile başlayan bir adresin arkasındaki bir kullanım betiğinde ya da bc1q adresinin arkasındaki bir tanık betiğinde yer alabilir; üçü aynı doğrulama mantığını çalıştırırken maliyet ve gizlilik açısından son derece farklıdır. Yapamayacağınız şey, komutu bir Taproot yaprağında kullanmaktır; modern yeter sayıların tamamen farklı bir opcode'dan kurulmasının nedeni budur.