Multisig arıza modları ve SSP onları nasıl azaltır

Bu, Multisig Deep Dive'in kapanış yazısıdır. Önceki altı yazı boyunca tabloyu kurduk: multisig nedir, hangi eşiği seçmeli, BIP48 kablolaması, Schnorr toplaması, social-recovery karşılaştırması ve gerçek insanlar için her şeyi bağlayan single-signer UX. Soyutlama normal koşullarda iyi çalışır. Bu yazı anormal koşullar hakkında.

Her multisig cüzdanın öngörülebilir arıza modları vardır — single-signer rahatlığının kırıldığı ve alttaki protokolün görünür olduğu noktalar. Hangi arızanın hangi kurtarmaya karşılık geldiğini bilmek, stresli bir olay ile rutin bir olay arasındaki farktır. Beşini en olası gerçekleşme sırasına göre, SSP'nin gerçekten ne yaptığı (ve sizin ne yapmanız gerektiği) ile geçeceğiz.

TL;DR

• Mod 1: Bir cihaz kayıp, o cihazın seed'i sağlam. Önemsiz kurtarma — yedek cihaza SSP yükle, seed'ten geri yükle, yeniden eşleştir. Fonlar risk altında değil.
• Mod 2: Bir cihaz kayıp ve onun seed'i kayıp. Cüzdan zayıflamış ama kaybolmamış: ikinci seed'i tek kurtarma anahtarı olarak kullanarak kalan cihazınızdan harca, sonra fonları yeni eşleştirilmiş bir cüzdana taşı.
• Mod 3: Bir cihaz malware/phishing ile tehlikeye atılmış. Saldırgan iki imzadan yalnızca birine sahip olduğu için fonlar güvende. Temiz bir cihazla yeniden eşleştirerek ihlali kapatıyorsunuz; SSP, tek bir tehlikeye atılmış cihazdan boşaltılamaz.
• Mod 4: SSP'nin koordinasyon katmanı kullanılamıyor. Rahatsız edici, felaket değil. Koordinasyon metadata taşımacılığıdır; alttaki multisig cüzdan, sadece iki seed kullanılarak BIP48 uyumlu herhangi bir yazılım ile kurtarılabilir.
• Mod 5: Her iki cihaz ve her iki seed kağıdı aynı anda tahrip oldu. Bu tek felaket senaryosu, ve self-custody kontrol listenizin coğrafi olarak ihtimal dışı kılmak için tasarlandığı şey de bu.

Bu yazıyı bir kez okumak yeterli. Ezberlemek gerekmez. Önemli olan şu: gelecekteki kendinizin endişelenebileceği her arıza için belirli, uygulanabilir bir yanıt vardır.

Mod 1: Tek cihaz kayıp, seed sağlam

Bu en yaygın arıza: telefonunuzu değiştirirsiniz, laptopunuzu düşürürsünüz veya temiz bir OS yeniden kurulumu yaparsınız. SSP cüzdanınızın bir yarısını çalıştıran cihaz gitti, ama o yarının seed phrase'i hâlâ yerinde (çünkü ilk 1000 kontrol listesini takip ettiniz ve fiziksel olarak ayrı sakladınız).

Kurtarma şudur:

1. Yedek bir cihaza SSP yükleyin (yeni telefon, yeni laptop, vb.).
2. O yarıyı seed phrase'inden geri yükleyin.
3. Hayatta kalan cihazınızla yeniden eşleştirin. SSP, iki cihazı birbirine yeniden gösterme sürecinde size rehberlik eder — multisig koordinasyon katmanı yeni cihazda aynı xpub'u tespit eder ve kabul eder.
4. Cüzdanı normal şekilde kullanmaya devam edin. Cüzdanın zincir üstü kimliği değişmedi — aynı adres, aynı bakiye, aynı geçmiş.

Bu akış boyunca hiçbir noktada fonlar risk altında değildir. Seed phrase tam da bunu yapmak için tasarlanmıştır: bir imzalama yarısını sıfırdan yeniden oluşturmak. SSP'nin onboarding'inin her iki seed'i ayrı yedeklemekte bu kadar ısrarcı olmasının nedeni, ödediğiniz kurtarmanın bu olmasıdır.

Zaman maliyeti: seed kağıdınız elinizdeyse ~20 dakika.

Mod 2: Cihaz ve onun seed'i kayıp

Mod 1'in daha zor sürümü: bir cihazı ve onun seed kağıdını aynı anda kaybettiniz. Ev yangını, sel, tek bir fiziksel konumun çalınması, vb. Artık o imzalama yarısını kendi seed'inden yeniden oluşturamazsınız.

Bu tam olarak 2-of-2 vs 2-of-3 kararının sonuçlarını gösterdiği durumdur. 2-of-2 altında — SSP varsayılanı — tam olarak bir imzalama yarısı kaldı (hayatta kalan cihaz, kendi seed'iyle). 2-of-3 altında üç anahtardan ikisine sahip olur ve aceleye gerek olmadan harcayabilirdiniz; 2-of-2 altında bu cüzdandan hiç harcayamazsınız, çünkü chain hâlâ iki orijinal imzayı gerektiriyor.

Kurtarma şudur:

1. Panik yapmayın. Fonlar güvende — hiçbir saldırgan onları da harcayamaz çünkü 2-of-2 kuralı altındalar.
2. Hayatta kalan cihazınızın seed'inin hâlâ yedeklendiğinden ve erişilebilir olduğundan emin olun. Birden tek geri dönüşünüz oldu.
3. Yeni bir cihaz çiftinde yeni bir SSP cüzdanı kurun (kalan cihazınız ve yeni bir cihaz, her biri yeni seed'lerle).
4. Eski cüzdandan fonları gönderin — durun, gönderemezsiniz. 2-of-2 kırılmış durumda.

Hmm. 4. adım 2-of-2 hakkındaki dürüst gerçeği ortaya koyuyor: bu spesifik arıza modunda fonlar dondurulmuş. Çalınmamış. Kriptografik anlamda kaybolmamış. Hâlâ zincir üstündeki adreste. Ama onları taşıyamazsınız çünkü cüzdan 2-of-2 harcama kuralını uyguluyor ve sizde sadece bir yarı var.

Yapabileceğiniz şey cüzdanı yeniden yaratmak. Konkret olarak: hayatta kalan cihaz hâlâ seed'ine sahip, sıfırdan yeni bir cihazı sıfırdan yeni bir seed ile kurarsınız, onları yeni bir 2-of-2 cüzdanı olarak eşleştirirsiniz, ve eski cüzdandan yenisine harcarsınız — anahtar bu — hayatta kalan orijinal seed'i kayıp olanla başka bir yerden kurtarılarak birleştirerek. Kayıp seed'in başka bir kopyası yoksa, fonlar gerçekten mahsur kalmıştır.

Bu nedenle kontrol listesinin "iki seed, iki fiziksel olarak ayrılmış konum, bunlardan biri yangına dayanıklı" talimatı paranoya değildir. Mod 2'nin yanıtıdır. Tek bir self-custody tavsiyesini izlemek zorunda olsaydınız, her iki SSP seed'iniz için seed phrase en iyi uygulamalarını izleyin. Cüzdanın geri kalanı bunu yaptığınız varsayımı etrafında iyi tasarlanmıştır.

Mod 3: Bir cihaz tehlikeye atılmış

Daha kötü senaryoyu hayal edin: laptopunuz malware ile tehlikeye atılmış. Tarayıcı uzantısı hâlâ kurulu; saldırgan potansiyel olarak kullanımınızı gözlemledi, o cihazın imzalama anahtarına tam erişimi olabilir. Ne elde ediyor?

Tek imzalı bir hot wallet altında — her şeyi alır. Bir sonraki harcamayı denediğinizde cüzdan boşaltılır (veya daha önce, eğer malware sessizce harcama başlatabilirse).

2-of-2 bir SSP cüzdanı altında, henüz hiçbir şey almaz. Bir imzası var; chain iki istiyor. Tek başına harcayamaz. En fazlasını şöyle yapabilir: bir işlem önerisi üretir, SSP'nin koordinasyon katmanı üzerinden telefonunuza iter, ve fark etmeden telefonunuzda onaylamanızı umut eder.

Burası single-signer UX tartışmasının güvenlik ile kesiştiği yer. Telefondaki onay adımı UX'in güzel bir detayı değil; tehlikeye atılmış bir laptop ile boşaltılmış bir cüzdan arasındaki tek şey. Telefonda işlem ayrıntılarını okuyun. Alıcı adresini eşleştirin. Tutarı eşleştirin. Bir şey yanlış görünüyorsa, onaylamayın, istem oraya nasıl gelmiş olursa olsun.

Tehlikeyi keşfettiğinizde kontrol altına alma yanıtı:

1. Tehlikeye atılmamış cihazınızdan fonlarınızı yepyeni bir SSP cüzdanına (iki yeni cihaz, iki yeni seed ile kurulmuş) gönderin. Bu tek bir multisig işlemidir — her iki eski cihaz da bir kez imzalamalıdır, ama hemen sonrasında tehlikeye atılmış olanı kullanmayı bırakırsınız.
2. Tehlikeye atılmış cihazı temizleyin. Fabrika ayarlarına sıfırlama; sadece uzantıyı kaldırmak değil.
3. Tehlikeye atılmış seed'i yakılmış olarak değerlendirin. O spesifik seed'i asla yeniden içe aktarmayın; sızdırılmış olarak kabul edin.

Bu kontrol altına alma, saldırganı geçmeniz gereken tek imzalı bir cüzdanın eşdeğerinden çok daha hızlı ve düşük risklidir. Multisig ile sakince hareket etmek için zamanınız vardır çünkü saldırgan ikinci imza olmadan kilitlenmiştir. Önceki serideki yedi arıza modu yazısı bunu dolar cinsinden ifade eder: retail self-custody kayıplarının çoğu tek anahtar tehlikeleridir ve 2-of-2 en yaygın senaryonun yanıtıdır.

Mod 4: SSP'nin koordinasyon katmanı kullanılamıyor

SSP, şirket, kesinti yaşarsa ne olur? Veya tarayıcı uzantınız ile telefonunuz arasında PSBT'leri taşıyan koordinasyon servisi çökerse? Ya da SSP'yi artık hiç kullanmak istemediğinize karar verdiyseniz?

Dürüst yanıt şu: koordinasyon katmanı metadata taşımacılığıdır — rahatlık verici ama yük taşıyıcı değil. Asıl cüzdan zincir üstünde yaşar, iki BIP48 seed'inizden türetilir. SSP'nin imza sunucusu bir saat çökerse, bir saat bekleyebilirsiniz. Bir hafta çökerse, can sıkıcı. Sonsuza kadar çökerse, yine de iki seed'i BIP48 uyumlu başka herhangi bir cüzdana yükleyerek cüzdanı kurtarabilirsiniz — Bitcoin'de Sparrow, Electrum, Bitcoin Core descriptor cüzdanları, EVM zincirlerinde eşdeğer multisig istemcileri, vb.

Buradaki kurtarma yolu:

1. Sorunun SSP tarafında olduğunu doğrulayın (yerel cihazlarınız değil) — SSP durum sayfası veya topluluk kanalları söyleyecek.
2. Acil harcama gerekiyorsa, BIP48 multisig yolunu destekleyen üçüncü taraf bir cüzdan yükleyin. Sparrow Bitcoin için en kullanıcı dostu seçim; EVM için Safe veya benzer bir multisig istemcisini kullanırsınız.
3. Her iki seed'i o üçüncü taraf cüzdana yükleyin. Aynı adres görünür, aynı bakiye, aynı harcama yeteneği.
4. Oradan normal şekilde imzalayın ve yayınlayın.

Bunu yapabilmenizin nedeni — bunun pazarlama iddiası değil, doğrulanabilir bir özellik olmasının nedeni — SSP'nin standartları kullanmasıdır. BIP48 makalesi ve 2-of-2 multisig nedir bunu açıklar. SSP, SSP'den bağımsız olarak var olan bir cüzdanın üzerinde uygun bir ön-uçtur.

Pratikte SSP'nin imzalama altyapısı yüksek erişilebilirlik için inşa edilmiştir — ama cüzdanın SSP olmadan kurtarılabilir olduğu garantisi, sizi korkutmak yerine rahatlığı önemli hale getiren şeydir.

Mod 5: Her iki cihaz ve her iki seed aynı anda yok edildi

Bu felaket arıza modu ve açıkça ifade edilmeye değer: eğer her iki imzalama yarısını ve her iki seed yedeğini aynı olayda kaybederseniz, cüzdan kalıcı olarak erişilemezdir. Fonlar hâlâ zincir üstünde, multisig adresinde, ama kimse — SSP dahil — onları taşıyamaz. Bu, gerçek self-custody'nin maliyetidir; SSP'nin fonlarınızı donduramayacağı anlamına gelen aynı özellik, çözemeyeceği anlamına da gelir.

Savunma coğrafi ve yapısaldır:

• İki seed fiziksel olarak ayrılmış konumlarda yaşar. İlk 1000 kontrol listesi "farklı oda, pratikse farklı bina" der.
• Seed'lerden en az biri yangına dayanıklı bir kapta yaşar.
• Stack'ınız bunu haklı çıkaracak kadar büyükse, sonunda 2-of-3'e geçersiniz — üçüncü bir anahtar eklemek (genellikle bir avukatla, aile üyesiyle veya banka kasasında tutulan) felaket arıza yüzeyini "her iki fiziksel konum yok edildi" durumundan "üç konumdan herhangi ikisi yok edildi" durumuna indirir.

Dürüst çerçeveleme şu: bu arıza modu olasılığı şiddetle takas eder. Tek anahtarlı cüzdanlar çok daha sık başarısız olur (mod 1 ve 3 verilerde hakimdir) ama olay başına daha düşük şiddetle. Coğrafi seed ayrımı ile multisig, arıza sıklığını bir büyüklük derecesi azaltır ama olay başına şiddeti biraz yükseltir. Çoğu kullanıcı kazançlı çıkar.

Meet SSP Wallet girişi ürünü sofistike retail self-custody için bir araç olarak çerçeveler. Mod 5'in ciddiyeti, bu çerçevelemenin dürüst olmasının bir nedenidir — ürün, seed kağıtlarını yük taşıyıcı altyapı olarak ele almaya istekli insanlar için inşa edilmiştir, bir kez yazıp unutacağınız bir şey olarak değil.

Bu sizin için ne anlama gelir

Kapanış çıkarımları:

1. Çoğu arıza modunun rutin kurtarmaları vardır. Modlar 1, 3 ve 4 — açık ara en yaygın olanlar — iyi tanımlanmış, düşük stresli kurtarma yollarına sahiptir. 2-of-2 modeli vaat ettiğini gerçekten yapar: tek nokta tehlikelerini emer ve size yanıt vermek için zaman verir.
2. Felaket durumu coğrafidir, kriptografik değil. Mod 5, seed phrase en iyi uygulamalarınızın konusudur. Cüzdanın kriptografisi iyi denetlenmiştir; kalan arıza yüzeyi, iki seed'i fiziksel olarak farklı, dayanıklı yerlerde saklayıp saklamadığınızdır.
3. Artık tüm tabloya sahipsiniz. Bu seri (makale 1, makale 2, makale 3, makale 4, makale 5, makale 6, bu) multisig'in ne olduğunu, hangi eşiği ne zaman seçeceğinizi, her şeyin nasıl kablolandığını, toplamanın neyi değiştirdiğini, kurtarma modellerinin nasıl farklı olduğunu, UX'in neden öyle hissettirdiğini, ve her arıza modunun operasyonel olarak nasıl göründüğünü kapladı. Önceki Self-Custody Fundamentals serisi size neden'i verdi; bu seri size nasıl'ı verdi. Buradan iş operasyonel disiplindir: yedek hijyeni, periyodik kurtarma provaları, ve gerçekleştiğinde mod 1/2/3/4 kurtarmalarını sakince yapma sabrı.

Cüzdan iyi tasarlanmıştır. Kalan değişken sizsiniz.