Bitcoin (BTC) Taproot Yükseltmesi 709.632 Blokta Cüzdan Desteğini İsteğe Bıraktı

Cüzdanlar ve Borsalar bc1p Sorusunun Önünde

Ekranında artık bir Taproot seçeneği gösteren Bitcoin (BTC) cüzdanları ile bu cüzdanların ürettiği bc1p adreslerini kabul etmek zorunda kalan borsalar ve donanım imzalayıcıları, yükseltmenin getirdiklerinin sıradan kullanıcıya ulaşıp ulaşmayacağını belirleyen taraflar. Taproot, Bitcoin (BTC) protokolünün yumuşak bir çatallanması (soft fork) olarak 2021'de ana ağda 709.632 blok yüksekliğinde devreye alındı. Sürüm 1 tanıklık (witness) kurallarına tabi Pay-to-Taproot (P2TR) çıktılarını kullanıma sundu. Değişiklik coinlerin nasıl harcandığını etkiliyor; elindekileri değil: alıcılar yine BTC almaya devam ediyor, ayrı bir Taproot tokeni yok ve Bitcoin fiyatı ile arz takvimi bu değişikliğin kapsamı dışında kalıyor.

Yükseltme, birbirine bağlı üç öneriyi tek pakette taşıyor. BIP 340, secp256k1 eğrisi üzerinde Schnorr imzalarını tanımlıyor; Bitcoin'in yıllardır dayandığı ECDSA şemasından farklı bir cebirsel yapı söz konusu ve bu yapı çok taraflı imza protokollerine elverişli. BIP 341 Taproot çıktı biçimini, taahhüt yapısını ve harcama kurallarını belirliyor. BIP 342 ise Tapscript adıyla anılıyor ve o çıktıların içinde betik yürütme kurallarını koyuyor. Üçü birbirine geçiyor ama ayrı katmanları anlatıyor; hepsini tek özellik sanmak sık yapılan bir hata.

Adres tarafında ana ağdaki Taproot çıktıları genellikle bc1p ile başlıyor ve Bech32m kodlamasını kullanıyor; sürüm 0 yerel SegWit adresleri ise bc1q ile başlıyor ve Bech32 kodlamanın ürünü. İkisi de aynı blockchain üzerinde yaşıyor; ikinci bir Bitcoin (BTC) ağı yok ve öneki elle değiştirmek bir dönüşüm sağlamıyor. Önek, numaralı tanıklık sürümleri oluşturan Segregated Witness sürümleme sistemine yaslanıyor ve Taproot sürüm 1'in yerini alıyor. Eski çıktılar aktivasyondan sonra da geçerli kalıyor, göç gönüllü: coinleri bir Taproot çıktısına taşımak yine zincir üstü işlem ücretine patlıyor. Yumuşak çatallanma aynı zamanda Proof of Work mutabakat katmanına dokunmuyor; uyumluluk işinin protokolde değil cüzdanlarda yoğunlaşmasının nedeni bu.

Key Path ve Script Path Aynı İşi Yapmıyor

Bir Taproot çıktısı iki yoldan harcanabilir ve bu ayrım, gözlemcinin zincir üzerinde gördüğü her şeyi belirliyor. Key Path, harcamayı çıktının açık anahtarına karşı doğrulanan bir Schnorr imzasıyla yetkilendiriyor. Alternatif betiklere dair hiçbir şey ifşa edilmiyor; MuSig tipi bir protokol gibi işbirlikçi bir tasarımda birkaç katılımcı, zincir üzerinde tek bir kişinin imzası gibi görünen ortak bir imza üretebiliyor. Zincir analizi, tek başına yapılan bir harcamayı ortak yapılandan güvenilir biçimde ayırt edemiyor. Script Path ise taahhüt edilmiş bir koşul devreye girdiğinde uygulanıyor: harcayan seçilen betiği açıyor, koşulu sağlayan veriyi teslim ediyor ve betiğin çıktının taahhüdüne ait olduğunu kanıtlıyor. Kullanılmayan dallar gizli kalıyor ama devreye alınan betik ve kanıtları görünür oluyor.

Tipik kullanımlar da buna göre ayrışıyor. Doğrudan ödemeler ve işbirlikçi çok taraflı harcamalar Key Path'ten akıyor; zaman kilitleri, yedek koşullar ve diğer bekâryet senaryoları Script Path'i kullanıyor. Fon taşıyan herkesin bilmesi gereken iki yanlış var. Çoklu imza (multisig) aktivasyonla birlikte kendiliğinden tek imzaya küçülmüyor; bunun için uygun bir çok taraflı imza protokolü ve cüzdan desteği gerekiyor, eski multisig coinleri dönüştürülmüyor. Girdiler arası imza toplama da bu yükseltmenin otomatik sunduğu bir özellik değil. Mahremiyet konusunda ise Taproot harcama koşullarının ifşasını kısıyor ve farklı tasarımların aynı görünen Key Path harcamalarında buluşmasına izin veriyor; ama tutarlar, çıktı yapısı ve işlem bağlantıları herkese açık ve çözümlenebilir kalıyor. Yani bc1p adresi anonimlik güvencesi değil.

Ücretler de her durumda düşmüyor. Maliyet, işlemin sanal boyutuna, seçilen sat/vB oranına ve mempool rekabetine bağlı; bir Taproot çıktısı açmanın veri bedeli ile onu sonradan harcamanın bedeli farklı olduğu için iki aşamanın birlikte değerlendirilmesi gerekiyor. İki taraflı bir saklama düzeni örnek alınabilir: normal işleyişte taraflar Key Path üzerinden işbirliği içinde imza atıyor, zaman kilitli yedek betik baştan taahhüt ediliyor ve işbirliği kopmadıkça açılıp karşılanmıyor. Kavram genel geçer ama etkinin var olabilmesi için anahtarların, betiklerin, yedeklerin ve imza protokollerinin doğru kurulması şart.

Cüzdan Desteği Hâlâ Ne Belirliyor

Protokol işi kendisi kapandı: BIP 341 çıktıyı, taahhüdü ve harcama kurallarını sabitledi ve güncel mutabakat kurallarını çalıştıran düğüm operatörleri P2TR harcamalarını ek ayar olmadan doğruluyor. Kapanmayan, çevresindeki araç seti. Bir Taproot adresinde alım yapabilen bir cüzdan, otomatik olarak Key Path harcaması imzalayabilen bir cüzdan demek değil; donanım cihazlarının ve özel multisig kurulumlarının yeni yolu güvenle kullanmak için baştan inşa edilmesi gerekiyor. Bugün Bitcoin DeFi çatısı altında toplanan projelerin üzerine kurduğu genişlemiş betik tasarım alanı ile sonradan Bitcoin Ordinals yazılarını taşıyan sürüm 1 tanıklık yapısı da aynı kurallara dayanıyor. İmzalayıcılar, cihazlar ve para yatırma platformları bc1p üzerinde hizalanana kadar benimseme isteğe bağlı ve dengesiz kalıyor.