Bitcoin Adres Türleri Açıklandı

Doğrudan Cevap

Legacy, nested SegWit, native SegWit ve Taproot adres formatlarını, öneklerini, uyumluluğunu ve güvenlik sınırlarını karşılaştırın.

İki Bitcoin adresi de BTC alabilir ve yine de altında farklı işlem yapıları oluşturabilir. Bir ana ağ adresi 1, biri 3, bir bc1q adresi ve bir bc1p adresi geçerli hedefler olabilir, ancak bunlar mutlaka aynı script, kodlama veya gelecekteki harcama koşulunu temsil etmez.

Bu farkı gözden kaçırmak kolaydır çünkü cüzdan adresi tek bir dize olarak sunar. Altında, adres yazılıma bir işlem çıktısının nasıl oluşturulacağını söyler. Bu çıktı onaylandıktan sonra, daha sonra bu çıktı tarafından kodlanan script kurallarına göre harcanması gereken bir UTXO haline gelir.

Bu nedenle pratik soru basitçe “Hangi önek daha yeni?” değildir. Adresin amaçlanan Bitcoin ağına ait olup olmadığı, hangi çıktı türünü temsil ettiği, gönderen yazılımın bu formatı destekleyip desteklemediği ve bir ödemeyi yetkilendirmeden önce adresin size ne söyleyip söyleyemeyeceğidir.

Bir Bitcoin Adresi Ne Temsil Eder

Bir Bitcoin adresi, bankacılık anlamında bir hesap değildir. Bitcoin içermez, özel anahtar tutmaz veya cüzdan bakiyesinin tam bir görünümünü sağlamaz. Bir cüzdanın belirli bir işlem çıktısı oluşturmasına yardımcı olan insan tarafından okunabilir bir kodlamadır.

Basitleştirilmiş ilişki şudur:

Bitcoin adresi
        ↓
Adres çözümleme
        ↓
scriptPubKey
        ↓
İşlem çıktısı
        ↓
Onaylanmış UTXO
        ↓
Gelecekteki harcama koşulu

Bitcoin gönderdiğinizde, cüzdan bir nesneyi bir adres dizisinden diğerine taşımaz. Mevcut UTXO'ları işlem girdileri olarak tüketir ve yeni çıktılar oluşturur. Hedef adres, bu çıktılardan birini oluşturmak için gereken bilgiyi sağlar.

Bu, bir adres formatının teknik olarak neden önemli olduğunu açıklar. Bir P2PKH adresi, bir P2WPKH adresinden farklı bir çıktı script'ine yol açar. Bir Taproot P2TR çıktısı yine farklıdır. Bu çıktıların tümü harcanabilir bitcoin'i temsil edebilir, ancak harcandıklarında kullanılan koşullar ve serileştirme aynı değildir.

Adres, özel anahtar değildir

Özel anahtar, adresten ayrı kalır. Bir cüzdan, harcama koşulunun gerektirdiği imzayı veya tanık verisini oluşturmak için özel anahtar materyalini kullanır. Bir alıcı adresi yayınlamak, özel anahtarı yayınlamaz.

Tersi de önemlidir: bir adresi görmek, belirli bir kişinin ilgili anahtarı kontrol ettiğini kanıtlamaz. Blockchain analizi işlemleri ve çıktıları gözlemleyebilir, ancak tek başına bir adres dizesi kimlik kanıtı değildir.

Neden Birden Fazla Format Var

Bitcoin, işlem sistemi eski çıktılarla uyumluluğu koruyarak geliştiği için birden fazla adres formatına sahiptir. Yeni formatlar, blockchain'deki eski çıktıların yerini almadı. Bunun yerine, harcama koşullarını ifade etmenin ek yollarını tanıttılar.

Bitcoin ana ağında çoğu kullanıcının karşılaştığı dört format şunlardır:

• Eski P2PKH, genellikle ile başlayan bir adresle görüntülenir 1.
• P2SH, genellikle ile başlar 3; iç içe SegWit, P2SH'nin önemli bir kullanımıdır, ancak tek kullanımı değildir.
• Yerel SegWit, Bech32 ile kodlanmış ve genellikle ile başlar bc1q tanık sürümü 0 için.
• Taproot, Bech32m ile kodlanmış ve ile başlar bc1p tanık sürümü 1 P2TR çıktıları için.

Önemli değişiklik, dizenin görünümü değildir. Önemli olan, çözülen hedefin cüzdana yeni çıktıya ne koyacağını söylemesidir.

Bitcoin Adres Türleri Karşılaştırması

Yaygın ad	Ana ağ öneki	Kodlama	Tipik çıktı	Önekin size söylediği
Eski	1	Base58Check	P2PKH	Ana ağ genel anahtar-hash adresi için sürüm bayt ailesi
P2SH (iç içe SegWit dahil)	3	Base58Check	P2SH; iç içe geçmiş SegWit, olası bir kullanım-komut dosyası yapısıdır	Hedef P2SH'dir, içindeki tam kullanım komut dosyası değil
Yerel SegWit	bc1q	Bech32	Witness v0, genellikle P2WPKH veya P2WSH	Mainnet Bech32 witness-version-0 hedefi
Taproot	bc1p	Bech32m	P2TR	Mainnet witness-version-1 Taproot hedefi

Bu tablo tanımlama için yararlıdır, ancak önek gelecekteki harcama davranışının tam bir açıklaması değildir. En açık örnek bir 3... adres: P2SH'yi tanımlar, ancak P2SH birçok kullanım komut dosyasına bağlanabilir. İç içe geçmiş SegWit yalnızca bir olasılıktır.

Eski P2PKH Adresleri

Eski ödeme-anahtar-hash'ine veya P2PKH, erken Bitcoin cüzdan yazılımıyla en yakından ilişkili adres biçimidir. Mainnet'te bu Base58Check adresleri normalde şununla başlar: 1.

Adres, bir genel anahtarın hash'ini temsil eder. Bir cüzdan bu hedefe ödeme yaptığında, çıktı harcandığında geçerli bir imza ve karşılık gelen genel anahtar gerektiren bir P2PKH kilitleme komut dosyası oluşturur.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

Görünür adres bu nedenle komut dosyasının kendisi değildir. Cüzdan Base58Check adresini çözer, sürümü ve yükü çıkarır ve uygun scriptPubKey'i oluşturur.

P2PKH çıktıları geçerli Bitcoin çıktıları olarak kalır. “Eski” geçersiz veya otomatik olarak güvensiz anlamına gelmez. Ayrım, işlem yapısını karşılaştırırken önemli hale gelir: geleneksel bir P2PKH çıktısını harcamak, SegWit witness serileştirmesini kullanmak yerine kilit açma verilerini girdi komut dosyasına yerleştirir.

Bu fark, ortak SegWit anahtar harcamalarına kıyasla işlem ağırlığını artırabilir. Bir P2PKH ödemesinin otomatik olarak belirli bir ücrete sahip olduğu anlamına gelmez. Girdi sayısı, çıktı sayısı, seçilen ücret oranı ve imzalanan işlemin geri kalanı nihai maliyeti belirler.

P2SH ve İç İçe Geçmiş SegWit

Ödeme-komut dosyası-hash'ine veya P2SH, harcama mantığının bir kısmını bir hash'in arkasına taşıdı. Mainnet P2SH adresleri Base58Check kullanır ve normalde şununla başlar: 3.

Standart bir P2SH çıktısı, kullanım komut dosyası hash'ini kilitleme komut dosyasına yerleştirir:

OP_HASH160
<20-byte script hash>
OP_EQUAL

Tam kullanım script'i yalnızca çıktı harcandığında sağlanır. Bu, SegWit tanıtıldığında önemli bir uyumluluk aracı oluşturdu: bir SegWit tanık programı, bir P2SH kullanım script'inin içine yerleştirilebilir ve normal P2SH adreslerini anlayan bir göndericinin, daha sonra SegWit kuralları kullanılarak harcanacak bir çıktıya ödeme yapmasına olanak tanır.

Yaygın bir tek anahtar yapısı P2SH-P2WPKH olarak adlandırılır:

P2SH adresi
    ↓
kullanımScript'inin hash'i
    ↓
kullanımScript bir P2WPKH tanık programı içerir
    ↓
imza ve genel anahtar, harcandığında tanık verileri aracılığıyla sağlanır

3 öneki SegWit'i kanıtlamaz

Bu, görsel adres tanımlamanın en önemli sınırlarından biridir. İle başlayan bir adres 3 size hedefin ana ağ P2SH adres sürümünü kullandığını söyler. Çıktı harcanmadan önce tam kullanım script'ini açığa çıkarmaz.

P2SH, SegWit'ten önce vardı ve diğer script'leri sarabilir. Her 3... adresini “bir SegWit adresi” olarak ele almak bu nedenle çok geniştir.

Teknik sınır: önek, dış adres biçimini tanımlar. Bir P2SH hash'inin arkasında gizlenen tam script'i kanıtlamaz.

Yerel SegWit ve bc1q

Yerel SegWit, P2SH uyumluluk sarmalayıcısını kaldırır ve tanık programını doğrudan temsil eder. BIP 173, yerel SegWit adresleri için Bech32 kodlamasını tanıttı.

Bitcoin ana ağında, insan tarafından okunabilir kısım bc. dir. Tanık sürümü 0, genellikle başlangıcıyla tanınan adresler üretir bc1q.

İki yaygın tanık sürümü-0 çıktısı şunlardır:

• P2WPKHtek anahtarlı cüzdan ödemeleri için yaygın olarak kullanılan 20 baytlık bir tanık programı.
• P2WSH: bir tanık script'ine taahhütte bulunan 32 baytlık bir tanık programı.

Adresin kendisi cüzdana tanık sürümünü ve programını verir. Tanık sürümü 0 için, yaygın çıktı script'leri şu biçimlere sahiptir:

P2WPKH: OP_0 <20-byte key hash>
P2WSH:  OP_0 <32-byte script hash>

Çıktı, bir P2SH sarmalayıcı yerine doğrudan tanık programını içerir. UTXO harcandığında, tanık programının gerektirdiği imza veya script verileri, geleneksel bir P2PKH tarzı scriptSig yerine işlem tanığında sağlanır.

Bech32 hata algılamayı da değiştirir

Bech32 yalnızca farklı bir alfabe değildir. Bu adres ailesi için tasarlanmış bir sağlama toplamı içerir ve insan tarafından okunabilir ağ bölümünü kodlanmış tanık verilerinden ayırır.

Bech32 dizeleri büyük ve küçük harfleri karıştırmamalıdır. Cüzdanlar normalde Bitcoin ana ağı Bech32 adreslerini küçük harfle görüntüler. Tamamen büyük harfli bir kodlama spesifikasyona göre geçerli olabilir, ancak karışık harf kullanımı geçersizdir.

Taproot ve bc1p

Taproot, pay-to-Taproot veya P2TR çıktılarını tanıttı. P2TR, 32 baytlık bir tanık programıyla tanık sürümü 1 kullanır. Bitcoin ana ağında, ortaya çıkan adres şununla başlar: bc1p.

Witness sürüm 1 ve sonrası, orijinal Bech32 sağlama toplamı yerine Bech32m kullanır. BIP 350, daha yeni witness sürümleri için orijinal Bech32 sağlama toplamı davranışının kullanılmasında bir zayıflık tespit edildikten sonra bu değişikliği tanıttı.

Bu, pratik bir tanımlama kuralı verir:

bc1q... → witness sürüm 0 → Bech32
bc1p... → witness sürüm 1 P2TR → Bech32m

Karşılık gelen P2TR kilitleme script'i, witness sürüm 1 ve 32-byte Taproot çıktı anahtarı kullanır:

OP_1 <32-byte Taproot output key>

Bir P2TR çıktısı, bu Taproot çıktı anahtarına bağlanır. Daha sonra anahtar yoluyla veya bir script ağacı bağlanmışsa, geçerli bir açıklanmış script yoluyla harcanabilir.

Adres, hangi yolun sonunda kullanılacağını açığa çıkarmaz. Görmek bc1p size çıktının P2TR olduğunu söyler. Gelecekteki harcayanın anahtar yolu imzası mı kullanacağını yoksa bir script yolunu mu açıklayacağını söylemez.

Bitcoin Önekleri Size Gerçekte Ne Söyler

Önekler, bir insanın olası adres ailesini ve ağını hızlıca tanımlamasına izin verdikleri için kullanışlıdır. Bunlar, tam doğrulama olarak değil, ilk kontrol olarak ele alınmalıdır.

Örnek başlangıç	Olası mainnet anlamı	Kanıtlamadığı şey
1...	P2PKH mainnet adresi	Sahip, bakiye veya alıcı kimliği
3...	P2SH mainnet adresi	Redeem script'in iç içe SegWit olduğu
bc1q...	Yerel tanık sürüm-0 adresi	Yalnızca önekten P2WPKH mi yoksa P2WSH mi olduğu
bc1p...	P2TR tanık sürüm-1 adresi	Hangi Taproot harcama yolu daha sonra kullanılacak

Önek ayrıca size adresi veren kişiyi doğrulayamaz. Mükemmel kodlanmış, sağlama toplamı geçerli bir adres yine de yanlış alıcıya ait olabilir.

Ağ, Adres Türünden Önce Gelir

Legacy, SegWit veya Taproot arasında seçim yapmadan önce, adresin kullanmayı düşündüğünüz Bitcoin ağına ait olduğunu doğrulayın.

Bech32 ailesi adresleri bunu insan tarafından okunabilir kısımlarıyla görünür kılar. BIP 173 şunları tanımlar: bc Bitcoin ana ağı için ve tb Bitcoin test ağı adresleri için. Bu nedenle insan tarafından okunabilir kısım, ağ doğrulamasının bir parçasıdır, dekorasyon değil.

Base58Check adres aileleri de ana ağ ve test ağları arasında farklı sürüm baytları kullanır, ancak fark yalnızca dizeye bakan bir kullanıcı için daha az belirgindir.

Bir cüzdan desteklenmeyen bir ağ/adres kombinasyonunu reddetmelidir, ancak nihai sorumluluk yine de gönderen uygulamanın gösterdiği ağı doğrulamaktır. Adres biçimi tanıma, ağ doğrulamasının yerini tutmaz.

Daha geniş işlem bağlamı için—girdiler, çıktılar, onaylar ve Bitcoin temel katmanı—şunu kullanın: Bitcoin ağ referansı.

Adres Türü ve İşlem Ücretleri

Daha yeni bir Bitcoin adresinin “daha ucuz” olduğunu duymak yaygındır. Bu ifade bazı karşılaştırmalarda yönlü olarak yararlıdır, ancak bir ücret kuralı olarak kullanmak için çok basittir.

Alıcının seçtiği adres, bugün oluşturulan çıktının türünü ve serileştirilmiş boyutunu etkiler. Daha da önemlisi, bu çıktı daha sonra harcandığında, komut dosyası türü ilgili işlem girdisinin yapısını etkiler.

SegWit ayrıca işlem Weight muhasebesini de değiştirir çünkü tanık baytları, tanık olmayan baytlardan farklı şekilde ağırlıklandırılır. Bu nedenle, yaygın bir Native SegWit anahtar harcaması, karşılaştırılabilir bir Legacy P2PKH harcamasından farklı bir Weight profiline sahiptir. Bu, UTXO harcandığında sanal boyutu etkiler, ancak toplam ücreti önceden sabitlemez.

Aynı BTC miktarı farklı gelecekteki maliyetlere yol açabilir

Aynı miktarda bitcoin alan iki kullanıcı düşünün. Biri bir P2PKH çıktısı alır ve diğeri bir P2WPKH çıktısı alır. Değer aynıdır. Gelecekteki girdi yapısı aynı değildir.

Bu UTXO'ler daha sonra harcandığında, kilit açma verileri farklı şekilde serileştirilir. Bu, işlem Weight'sini ve dolayısıyla sanal boyutu değiştirir. Aynı sat/vB oranında, farklı vSize farklı bir toplam ücret anlamına gelir.

Bu, açıklayıcı bir teknik senaryodur; bir kullanıcı işlem kaydı veya belirli bir cüzdan hakkında bir iddia değildir.

Adres türü yine de tek başına nihai ücreti belirlemez. Çok sayıda verimli SegWit girdisi olan bir işlem, tek bir Legacy girdisi olan bir işlemden daha büyük olabilir. Çıktı sayısı, imzalar, script yolları ve seçilen ücret oranı da önemlidir.

Weight, sanal boyut ve sat/vB arasındaki tam ilişki için okuyun Bitcoin işlem ücretlerinin nasıl çalıştığını. okuyun Bitcoin İşlem Ücreti Hesaplayıcı.

. Kavramsal bir karşılaştırma yerine işleme özel bir tahmine ihtiyacınız olduğunda,

Geçerli bir Bitcoin adresi, gönderen cüzdan veya para çekme hizmeti formatı anlamıyorsa bir ödeme iş akışı için kullanışlı değildir.

Bu ayrım, Native SegWit ve daha sonra Taproot'nin benimsenmesi sırasında özellikle önemliydi. Bitcoin ağı çıktı türünü tanıyabilirken, eski uygulamalar bu hedefi oluşturma desteğinden yoksundu.

Bir hizmet bir bc1q veya bc1p adresini reddettiğinde, adresi manuel olarak değiştirmeyin. Karakterleri kaldırmayın, öneki değiştirmeyin veya keyfi bir web sitesi aracılığıyla dönüştürmeyin. Alıcı cüzdanınızın gerçekten oluşturduğu ve gönderenin açıkça desteklediği bir adres formatı kullanın.

Formatlar arasında gönderme dönüştürme değildir

Kaynak ve hedef formatları eşleştirme anlamında bir Legacy adresine ödeme yapmak için bir Legacy cüzdana veya bir Taproot adresine ödeme yapmak için bir Taproot cüzdana ihtiyacınız yoktur. Gönderen işlem, cüzdanın seçtiği desteklenen UTXO'leri tüketir ve hedef komut dosyası için yeni bir çıktı oluşturur.

İlgili soru, gönderen yazılımın istenen hedef çıktıyı çözüp oluşturup oluşturamayacağıdır.

Geçerli Bir Adres Yine de Yanlış Olabilir

Sağlama toplamları belirli yazım hatalarını yakalar. Amaçlanan alıcının kimliğini doğrulamazlar.

Kötü amaçlı yazılım, kopyalanan bir adresi başka bir geçerli Bitcoin adresiyle değiştirirse, değiştirme sağlama toplamı doğrulamasını mükemmel şekilde geçebilir. Teknik format geçerlidir; hedef yanlıştır.

Bu nedenle “cüzdanın adresi kabul etmesi” nihai güvenlik kontrolü değildir. Kabul, yazılımın geçerli veya desteklenen bir hedefi tanıdığını söyler. Adresin nereden geldiğini kanıtlamaz.

Göndermeden Önce Doğrulayın

Yararlı bir doğrulama süreci, format doğrulamasını alıcı doğrulamasından ayırır.

1. Ağı onaylayın. Cüzdanın veya hizmetin, amaçlanan Bitcoin ağında başka bir varlık veya test ortamı yerine Bitcoin gönderdiğinden emin olun.
2. Adres ailesini okuyun. A 1, 3, bc1q veya bc1p öneki size ilk format ipucunu verir.
3. Gönderen desteğini onaylayın. Para çekme hizmeti veya cüzdan, hedef formatı açıkça kabul etmelidir.
4. Hedefi güvenilir bir kanaldan doğrulayın. Pratik olduğunda, yalnızca birkaç baş ve son karaktere güvenmek yerine tam adresi güvenilir bir ekranda karşılaştırın.
5. Cüzdanın son işlem ekranını inceleyin. İmzalamadan önce alıcıyı, tutarı, ağ ücretini ve varsa değişimi onaylayın.
6. Özel materyali koruyun. Alıcı adresi doğrulaması, bir web sitesine tohum ifadesi veya özel anahtar girmenizi asla gerektirmez.

Büyük veya operasyonel olarak hassas transferler için kuruluşlar genellikle bağımsız hedef doğrulama prosedürleri ekler. Bu prosedürler operasyonel bir kontroldür, belirli bir Bitcoin adres formatının bir özelliği değildir.

Adres Yeniden Kullanımı Ayrı Bir Konudur

Bir Bitcoin adresi, yalnızca bir kez kullanıldığı için protokol düzeyinde süresi dolmaz. İlgili harcama koşulu kontrol edilebilir durumda kalırsa, aynı adrese yapılan gelecekteki ödemeler yine de geçerli çıktılar oluşturabilir.

Bu, adres yeniden kullanımını arzu edilir kılmaz. Bir alıcı adresini yeniden kullanmak, işlemlerin genel blok zincirinde ilişkilendirilmesini kolaylaştırabilir ve gizliliği azaltabilir.

Bu gizlilik sorunu, adresin P2PKH, P2SH, P2WPKH veya P2TR olup olmadığından ayrıdır. Modern bir adres formatı, aynı görünür hedefin tekrar tekrar kullanılmasını özel hale getirmez.

Adres Doğrulamanın Sınırları

Format doğrulaması dar bir soruyu yanıtlar: dizenin ilgili adres kuralları altında beklenen türde bir Bitcoin hedefi olarak çözülüp çözülemeyeceği. Onu sağlayan kişinin kimliğini doğrulamaz, özel bir anahtarın sahipliğini kanıtlamaz, bir cüzdanın toplam bakiyesini kanıtlamaz, bir hizmetin formatı desteklediğini garanti etmez veya nihai işlem ücretini belirlemez.

Ayrıca, çıktı yapısı tarafından kasıtlı olarak gizlenen bilgileri ortaya çıkaramaz. Bir P2SH adresi, harcamadan önce tam kullanım komut dosyasını açığa çıkarmaz ve bir P2TR adresi, gelecekteki harcamanın anahtar yolunu mu kullanacağını yoksa bir komut dosyası yolunu mu ortaya çıkaracağını önceden söylemez. Başarılı kod çözmeyi ödeme sürecinde bir kontrol olarak ele alın, çevredeki tüm varsayımların doğru olduğunun kanıtı olarak değil.

Alıcı Formatı Seçme

En güvenli varsayılan, adresi manuel olarak oluşturmak veya dönüştürmek yerine gerçekten kontrol ettiğiniz cüzdan tarafından oluşturulan bir adres kullanmaktır.

Alıcı cüzdan birden fazla adres türü sunuyorsa, cüzdanın amaçlanan script politikasıyla eşleşen ve gönderenin çözebileceği türü kullanın. P2WPKH adresi, cüzdanın bilinçli olarak bir witness-version-0 key-hash hedefi ürettiği durumlarda uygundur. P2TR adresi, cüzdanın bilinçli olarak bir Taproot hedefi ürettiği ve gönderenin bunu desteklediği durumlarda uygundur. Daha eski P2PKH veya P2SH hedefleri, bir iş akışı bu biçimleri gerektirdiğinde geçerli kalır.

Bir biçimi yalnızca birisi “en ucuz” olduğunu iddia ettiği için seçmeyin. Bugün oluşturduğunuz çıktı, yalnızca daha sonra harcandığında bir girdi haline gelir ve bu gelecekteki işlemin nihai maliyeti, tam işlem yapısına ve ücret oranına bağlıdır.

Adres, alıcı cüzdandan gelmelidir. Gönderen bunu desteklemelidir. Ağ eşleşmelidir. Bu üç kontrol, tek başına bir önek aramaktan daha önemlidir.

Bitcoin Adresi SSS

bc1q ve bc1p arasındaki fark nedir?

bc1q genellikle Bech32 ile kodlanmış bir Bitcoin mainnet witness-version-0 adresinin başlangıcıdır, örneğin P2WPKH veya P2WSH. bc1p Bech32m ile kodlanmış bir mainnet witness-version-1 P2TR adresini tanımlar.

3 ile başlayan her Bitcoin adresi SegWit kullanır mı?

Hayır. İle başlayan bir mainnet adresi 3 bir P2SH adresidir. İç içe SegWit, P2SH kullanabilir, ancak P2SH diğer redeem script'lerine taahhüt edebilir, bu nedenle önek tek başına çıktının iç içe SegWit olduğunu kanıtlamaz.

Bitcoin adresleri büyük/küçük harfe duyarlı mıdır?

Base58Check adresleri büyük/küçük harfe duyarlı bir alfabe kullanır. Bech32 ve Bech32m kodlamaları büyük ve küçük harf karakterleri karıştırmamalıdır; Bitcoin cüzdanları normalde bunları küçük harfle görüntüler. Bir adresin harf durumunu elle değiştirmeyin.

Bir Bitcoin adres türünden diğerine gönderebilir miyim?

Evet, gönderen cüzdan hedef biçimi desteklediğinde. Bir işlem, desteklenen bir girdi türünü harcayabilir ve farklı bir desteklenen çıktı türü oluşturabilir. Kaynak ve hedef öneklerin eşleşmesi gerekmez.

Bir Bitcoin adresinin süresi dolar mı?

Hiçbir protokol kuralı, normal bir Bitcoin adresinin belirli bir tarihten sonra veya bir ödemeden sonra süresinin dolmasını sağlamaz. Cüzdanlar genellikle yeni alıcı adresleri üretir çünkü adres yeniden kullanımı gizliliği azaltabilir, daha önce üretilen adreslerin otomatik olarak geçersiz hale gelmesinden değil.

Hangi Bitcoin adres türünü kullanmalıyım?

Kullanmayı düşündüğünüz Bitcoin ağı ve script türü için alıcı cüzdan tarafından üretilen bir adres kullanın ve gönderenin bu biçimi desteklediğini doğrulayın. Yerel SegWit modern ödemeler için yaygındır, Taproot ise her iki tarafın da P2TR desteklemesi durumunda uygundur. Bir adres biçimini elle diğerine dönüştürmeyin.

Teknik Kaynaklar

Yukarıdaki adres biçimi açıklamaları Bitcoin İyileştirme Önerileri ve Bitcoin Core belgelerine dayanmaktadır. Bu referanslar adres kodlamalarını, witness programlarını ve script davranışını tanımlar; belirli bir alıcı adresinin kimliğini veya güvenliğini kanıtlamazlar. BitcoinToolkit'in daha geniş kaynak yaklaşımı şurada açıklanmıştır: Veri Kaynakları page.

• BIP 13: pay-to-script-hash için Adres Biçimi — Base58Check P2SH adres biçimini belirtir.
• BIP 16: Komut Dosyası Karmasına Öde — P2SH harcama modelini ve redeem-script değerlendirmesini tanımlar.
• BIP 49: P2WPKH-içinde-P2SH için türetme şeması — bu kılavuzda tartışılan yaygın tek anahtarlı iç içe-SegWit yapısını belgeler.
• BIP 141: Ayrılmış Tanık — witness programlarını, işlem Weight ve SegWit çıktı anlamlarını tanımlar.
• BIP 173: yerel v0-16 witness çıktıları için Base32 adres biçimi — Bech32 yerel SegWit adres kodlamasını tanıttı.
• BIP 350: v1+ witness adresleri için Bech32m biçimi — daha yeni witness sürümleri için Bech32m ve sağlama toplamı kuralını tanımlar.
• BIP 341: Taproot — Taproot çıktı ve harcama kurallarını, P2TR witness sürüm 1 dahil olmak üzere tanımlar.
• Bitcoin Core Çıktı Tanımlayıcıları — yaygın Bitcoin çıktı scriptlerinin ve anahtar ifadelerinin yapılandırılmış açıklamalarını belgeler.

Kaynaklar

1. BIP 13: P2SH adres biçimi
2. BIP 141: Ayrılmış Tanık
3. BIP 173: Bech32 yerel SegWit adresleri
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Bitcoin Core çıktı tanımlayıcıları

Bir hata mı buldunuz? Bir içerik sorunu bildirin veya okuyun Düzeltme Politikası.