Bu seride şimdiye kadar multisig'in ne olduğunu ve hangi eşiğin seçileceğini kapsadık. İki yazı da bir multisig cüzdanın davranışını anlatıyordu — m adet n anahtar imzalıyor, chain eşiği kontrol ediyor, para hareket ediyor. İkisi de cüzdanın altında gerçekte nasıl monte edildiği hakkında pek konuşmuyordu. Bu yazı o.
Kısa hali: SSP sana bir cüzdan oluşturduğunda, sadece iki rastgele anahtar üretip işini bitmiş saymıyor. Onları BIP48 denen belgelenmiş bir standartı takip eden bir biçimde üretiyor, böylece ortaya çıkan cüzdan birlikte çalışabilir, SSP dışında bir yazılımda kurtarılabilir ve zincirde incelemek için öngörülebilir oluyor. Bu yazı BIP48'in ne olduğunu, neden var olduğunu ve "bu cüzdan BIP48 kullanıyor"un multisig'deki en sıkıcı-ve-en-önemli cümlelerden biri olduğunu açıklayan yazıdır.
TL;DR
- Türetme yolu, bir cüzdandaki belirli bir anahtara (ve adrese) tek bir seed phrase'den giden yoldur. BIP44 / BIP48 gibi standart yollar, farklı cüzdan yazılımlarının aynı seed'den aynı anahtarlara ulaşmasını sağlar.
- BIP48, multisig cüzdanlara özgü bir spec'tir. Şunu der: işte 2-of-3, 3-of-5 vb. bir cüzdanı oluşturan
manahtarın belli başlı çıktı script türleri arasındaki kanonik türetme yolu. - SSP, BIP48 kullanır. Bu, SSP cüzdanının ürettiği iki seed'in BIP48 ile uyumlu başka herhangi bir cüzdandan (Sparrow, Electrum, Bitcoin Core'un descriptor'ları) kullanılabileceği anlamına gelir — sadece SSP'den değil.
- BIP48, daha eski multisig spec'inin (BIP45) bir sorununu giderir: farklı script türleri (legacy, P2SH-wrapped SegWit, native SegWit, Taproot) için anahtarları temizce ayırır, böylece tek bir seed phrase çakışma olmadan hepsini tutabilir.
- SSP'yi kullanmak için türetme yollarıyla elle uğraşmana gerek yok. Var olduklarını bilmen gerekir ki "cüzdan kurtarma" sihir gibi gelmesin — ve seed'inin gerçekte neye karşılık geldiğini anlayasın.
Türetme yollarında 30 saniyelik tur
BIP48'in herhangi bir anlamı olmadan önce, altındaki makinenin var olması gerekiyordu. O makine BIP32: hierarchical deterministic (HD) cüzdanlar. Temel fikir: bir seed phrase'den türetilmiş tek bir ana anahtar, deterministik olarak sonsuz bir alt anahtar ağacı üretebilir. Ağaçta belirli bir yoldan yürürsen, her zaman aynı alt anahtara varırsın. Farklı bir yoldan yürürsen başka birine varırsın.
Yollar şöyle görünür:
m / purpose' / coin_type' / account' / change / index
Örneğin BIP44 yolu m / 44' / 0' / 0' / 0 / 0, BIP44 kuralları altında Bitcoin'in ilk hesabının ilk alma adresine ulaşır. coin_type'ı 60' yap ve Ethereum'un alanındasın; purpose'u 84' yap ve BIP84 (native SegWit) alanındasın; ve böyle. Tek tırnak (') hardened türetmedir — çocuk ebeveyne geri çevrilemez. Master'dan sonraki her segment, gelenekle bölümlenmiş 32-bit bir sayıdır.
Bu, gözden kaçırılan bölümdür: yol bir metadata'dır, sır değil. Yolu ve özel anahtarını (veya genişletilmiş anahtarını) bilen herkes aynı adresleri türetebilir. Yol, cüzdana nereye bakacağını söyler. Seed, orada ne olduğunu söyler.
Seed'in ne olduğuna dair dostça bir tazeleyici için, seed phrase best practices yazısı önkoşul okumadır.
BIP48 neyi belirler
BIP48 şurada yaşar: m / 48' / coin_type' / account' / script_type' / change / index. İlginç ekleme script_type' — sondan ikinci segment.
Bu segment, yolun hangi multisig output türüne hizmet ettiğini kodlar:
0'→ P2SH (legacy multisig)1'→ P2SH-wrapped SegWit (P2WSH-in-P2SH)2'→ native SegWit (P2WSH)3'→ Taproot'a eşdeğer multisig (BIP48 değişiklikleri ile)
Bu önemlidir çünkü pratikte aynı m-of-n cosigner kümesi, hangi output script'in kullanıldığına bağlı olarak zincirde farklı adresler üretir. BIP48 olmadan bir cüzdan sessizce bir tür kullanabilir, kurtarma yazılımı başka bir türü varsayabilir ve sonuç, aynı paraları türetmesi gerektiği gibi görünen ama farklı adresler hesapladıkları için türetmeyen iki cüzdan olur.
BIP48 ayrıca purpose' segmentini 48''e sabitler, böylece multisig yolları single-sig BIP44/BIP49/BIP84 yollarıyla çakışamaz. Tek bir seed, BIP84'te bir single-sig cüzdan ve BIP48'de bir 2-of-2 multisig cüzdan tutabilir, etkileşim olmadan. Her biri kendi alt ağacında yaşar.
Yolun ötesinde BIP48, multisig output'unu oluştururken cosigner public anahtarlarının ("xpubs") nasıl sıralanması gerektiğini belirler. Kanonik kural, public anahtarların redeem script'ine girmeden önce leksikografik sıralanmasıdır. Bu, belirsizliği kaldırır — aynı xpubs'lardan oluşturan her BIP48 uyumlu cüzdan aynı adresi hesaplar. O kural olmadan, iki cüzdan aynı anahtarları farklı sırada birleştirebilir ve aynı redeem kuralı ile farklı adreslerde sona erebilir.
Spec'i tam metniyle okumak istersen Bitcoin BIPs reposunda yaşar (bips/bip-0048.mediawiki).
SSP, BIP48'i pratikte nasıl kullanır
Bir SSP cüzdanı kurduğunda iki seed phrase üretilir — biri tarayıcı eklentisinde, biri SSP Key mobil uygulamasında. Her seed phrase bir master özel anahtara karşılık gelir. Her master'dan SSP, ilgili chain için (Bitcoin, Ethereum, Flux ve SSP'nin desteklediği setin geri kalanı) BIP48 yolunu script_type' = 2''de türetir (Bitcoin'de native SegWit; uygulanabilir olan diğer chain'lerde eşdeğer kanonik formlar).
Her iki imzacının xpubs'ları sonra değiş tokuş edilir. Her taraf artık BIP48'e göre leksikografik sıralı aynı iki xpubs setine sahiptir. O çiftten her taraf bağımsız olarak aynı adresi hesaplar. İki yarı asla özel anahtar paylaşmaz — yalnızca public anahtarlar cihazlar arasında hareket eder.
Para aldığında, sana gösterilen adres, her iki xpubs'tan hesaplanan BIP48-türetilmiş adrestir. Harcadığında, her cihaz aynı işlemi kendi özel anahtarı altında imzalar. Zincirdeki redeem script her iki public anahtara atıfta bulunur; ağ her iki imzayı kontrol eder. Protokolün tamamı bu.
Bunun bir kurtarma senaryosunda neden önemli olduğu: SSP bir ürün olarak yarın yok olsaydı, hâlâ BIP48 uyumlu iki seed phrase'in olurdu. Her ikisini Sparrow'a (veya SSP'nin kullandığı BIP48 yollarını destekleyen başka herhangi bir multisig yeteneğine sahip cüzdana) yüklemek aynı cüzdanı, aynı adreslerde, tam harcama yeteneğiyle yeniden inşa eder. Cüzdan SSP'nin içinde yaşamaz — zincirde yaşar ve seed'ler artı BIP48 spec'i, ona her yerden ulaşmaya yeterlidir.
Bu özellik, self-custody-without-cold-storage yazısının bir 2-of-2 SSP cüzdanını custodial tatlı bir merak yerine ciddi bir cüzdan olarak ele almasının büyük nedenidir. Açık standartlardan kurtarılabilir.
Neden BIP45 yerine BIP48 (ve neden BIP44 değil)
Önceki multisig spec'i BIP45'ti. Dürüst bir ilk denemeydi: m / 45' / cosigner_index' / change / index, cosigner_index' cüzdandaki hangi cosigner olduğunu kodluyordu. Geriye bakıldığında iki sorunu vardı.
Birincisi, cosigner_index' sırayı yolun kendisine pişiriyordu. Bu, imzacıların eklendiği sıranın türetmeyi etkilediği anlamına geliyordu, bu da ortak kurulumu kırılgan yapıyordu — sırayı kaçırırsan cosigners'ından farklı adresler türetirsin. BIP48 bunu cosigner index'i yoldan tamamen çıkarıp leksikografik public anahtar sıralamasının halletmesine bırakarak çözer.
İkincisi, BIP45 script türüne göre ayırmıyordu. Cüzdan ister legacy P2SH multisig isterse SegWit-wrapped multisig kullansın, aynı yol yeniden kullanılacaktı. Bu yukarıda anlatılan adres-çakışması-ama-aynı-paralar-değil sorununu yaratıyordu.
BIP44, daha genel HD spec'i, hiç multisig'i kapsamayı iddia etmedi. BIP44'ü multisig yollarıyla aşırı yüklemek kendi çatışmalarını yarattı. BIP48 açık düzeltmeydi: özel bir purpose numarası, açık bir script-type yuvası ve deterministik bir anahtar sıralaması. Bugün çoğu modern multisig cüzdanı bunda buluşur; fiili standarttır.
Bunun multisig'in sonraki bölümüne — birden fazla imzanın tek bir imzaya sıkıştırıldığı Schnorr toplaması — nasıl bağlandığının daha derin hikayesi için, bu serideki sonraki yazı Schnorr signatures and multisig aggregation konuyu devralır.
Bu, birlikte çalışabilirlik için ne anlama gelir
"Bu multisig cüzdanı gerçekten self-custodial mı?" sorusunun en temiz testi: cüzdanın yazılımı olmadan bunu kurtarabilir miyim? Cevap evet ise — belgelenmiş seed'leri, belgelenmiş bir türetme yolunu ve standart araçları kullanarak — cüzdan gerçekten senindir. Cevap hayır ise, cüzdanın gizli custodial unsurları vardır.
SSP'nin BIP48 uyumluluğu, evet diyebilmemizi sağlayan şeydir. Seed phrase'ler BIP39 (standart mnemonik), türetme BIP48, adres yapımı BIP48-kanoniktir. Aynı standartları konuşan herhangi bir cüzdan, cüzdanı yeniden inşa edebilir.
Bu nedenle Meet SSP Wallet tanıtımı SSP'yi yönetilen bir hizmet olarak değil "2-of-2 multisig ile self-custody" olarak çerçeveler. Altındaki standartlar, bu çerçevelemenin dürüst olmasının nedenidir.
Bu senin için ne anlama geliyor
Üç çıkarım:
- SSP'yi kullanmak için yolları ezberlemen gerekmez.
m/48'/0'/0'/2'/0/0sayısı, normal bir kullanıcının asla yazması gereken bir şey değildir. Ama var olduğunu bilmek, "bu cüzdanı SSP olmadan kurtarabilirim"i pazarlama değil gerçek bir iddia yapan şeydir. - İki seed'in birlikte çalışabilir. Üçüncü taraf bir multisig cüzdana kurtarman gerektiğinde, BIP48 artı iki BIP39 seed'in artı chain'in
coin_type'ı tariftir. Self-custody kontrol listesi bunu prova adımı olarak boşuna ismiyle anmıyor. - BIP48 (veya benzeri) kullanmayan bir multisig cüzdan sorgulanmaya değer. Bir ürün adreslerin anahtarlarından tam olarak nasıl türetildiğini söyleyemiyorsa, bu self-custody değildir — fazladan adımlı custody'dir. Standartlara uyum, "anahtarlarınız, paranız" iddiasını doğrulanabilir yapan şeydir.
