Yazar: Av. Ahmet Karaca · İlk yayın ve kaynak kontrolü:
Bitcoin gönderim ekranında işlem kimliği oluşması, alıcının ödemeyi kesin olarak aldığı anlamına gelmez. İşlem henüz onaylanmamışsa başka bir işlemle değişebilir, düğümlerin bekleyen işlem havuzundan düşebilir veya cüzdanda “iptal edildi” olarak görünebilir. Bir uyuşmazlıkta ilk ekran görüntüsü ile daha sonra blokzincire giren işlem birlikte incelenmelidir.
Bekleyen veya değiştirilen bir Bitcoin işlemini belgelerken ilk TxID’yi silmeyin; onun yerine geçtiği doğrulanan işlemi, ilgili alıcı çıktısını ve kontrol zamanındaki zincir durumunu da kaydedin. Aynı ödeme girişiminin iki işlem kimliğini iki ayrı tamamlanmış ödeme gibi toplamak, hem teslim hem zarar hesabını bozabilir.
Yazının bölümleri
Gönderildi, bekliyor ve onaylandı aynı kayıt değildir
Cüzdanın bir işlem oluşturması, onu ağa duyurması ve işlemin bir blokta yer alması farklı aşamalardır. Mempool, bir düğümün henüz bloka alınmamış işlemler için tuttuğu havuzdur; bütün dünyada tek ve değişmez bir bekleme listesi değildir. Bir gezginin işlemi göstermesi, başka bir düğümün aynı işlemi aynı anda kabul ettiğini kanıtlamaz.
Bitcoin’in ödeme işleme belgesi, sıfır onaylı ödemeler ile bloklara alınmış işlemlerin riskini ayırır. Onay sayısı arttıkça işlemin zincirden çıkması riski genel olarak azalır; bu, bütün ödemeler için kanunun koyduğu tek bir “güvenli onay sayısı” bulunduğu anlamına gelmez. Platformun yatırma koşulu, tarafların teslim anlaşması ve incelemenin amacı ayrıca değerlendirilir.
| Görünen durum | Teknik olarak ne söyler? | Dosyada ne korunmalı? |
|---|---|---|
| İşlem oluşturuldu | Bir işlem taslağı veya imzalı işlem vardır; ağda kabul ve teslim henüz gösterilmiş olmayabilir. | Varsa işlemin tam kimliği; taslak veya imzalı işlem kaydı, çıktı adresi, tutar ve cüzdanın durumu. |
| Bekliyor, sıfır onay | İşlem henüz esas alınan aktif zincirde bir blokla doğrulanmamıştır. | Sorgu zamanı, veri kaynağı ve varsa mempool/çakışma bilgisi. |
| Yerine başka işlem geçti | En az bir ortak girdinin harcanmasıyla ilişkili farklı bir işlem olabilir; yalnız “yerine geçti” etiketiyle alıcının değiştiği sonucu çıkarılmaz. | İki TxID, ortak girdiler ve her işlemin ilgili çıktı adresi ile miktarı. |
| Blokta onaylandı | İşlem kontrol anında belirlenen zincir bağlamında bir blokta yer alır. | Blok kimliği, yükseklik, onay sayısı ve veri kesim zamanı. |
| Aramada bulunamadı | Tek başına “hiç gönderilmedi” sonucunu vermez; veri kaynağı veya arama kapsamı yetersiz olabilir. | Doğru ağ/TxID kontrolü, cüzdan kaydı ve ikinci doğrulama kaynağı. |
RBF neyi değiştirir?
Replace-by-fee (RBF), onaylanmamış bir Bitcoin işleminin yerine, düğümün kabul politikasına uygun başka bir işlem alınabilmesiyle ilgilidir. Ücret artırma için kullanılabilir. Yerine geçen işlem alıcıya aynı tutarı gönderebilir; bazı cüzdanların “iptal” dediği işlem ise aynı girdileri kullanıcıya dönen başka çıktılara yöneltebilir. Bu nedenle işlem kimliğinin değişmesi ile ödemenin geri dönmesi aynı şey değildir.
BIP 125 isteğe bağlı değiştirilebilirlik sinyalinin tarihsel çerçevesini açıklar. Ancak bugünkü değerlendirmeyi yalnız cüzdandaki RBF kutusuna dayandırmak güvenli değildir: Bitcoin Core 29.0 sürüm notları, full-RBF politikasının 28.0’da varsayılan olduğunu ve 29.0’da bu politikayı kapatmaya yarayan seçeneğin kaldırıldığını belirtir. Bunlar belirli yazılım sürümlerinin politikalarıdır; her düğümün ve her madencinin aynı işlemi mutlaka kabul edeceği anlamına gelmez.
2021 tarihli Avrupa Konseyi Kripto Paralara El Koyma Kılavuzu’nun basılı 37. sayfasında Electrum’daki RBF seçeneğini kapatmaya dayanan bir uygulama önerisi bulunur. Bu öneri güncel bir kesinlik güvencesi olarak kullanılamaz. Eski ekran talimatını izlemek yerine işlemin gerçekten hangi blokta, hangi çıktılarla yer aldığını doğrulamak gerekir.
“İptal ettim” denilen işlem için hangi soru sorulmalı?
Gönderenin uygulamasında “iptal edildi” yazması, tek başına alıcının adresine hiçbir ödeme ulaşmadığını kanıtlamaz. Önce iptal denilen kaydın ne yaptığı belirlenir: Yalnız yerel cüzdanın takibinden vazgeçilmiş mi, çakışan yeni işlem yayımlanmış mı, yoksa yeni işlem de onaylanmış mı? Alıcının aynı adrese gelen başka bir işlemi varsa o da ayrı değerlendirilir.
Örneğin ücret artırmak için yenilenen işlemde alıcının 0,02000000 BTC’lik çıktısı korunmuş olabilir. Buna karşılık farklı bir yenilemede bu çıktı bulunmayabilir. İlk senaryoda yalnız TxID değişti diye “ödeme iptal oldu” denemez; ikinci senaryoda da ilk ekran görüntüsü üzerinden teslimin tamamlandığı ileri sürülemez. İki ihtimali ayıran şey, aktif zincirdeki işlem ve ilgili çıktıdır. Bu sayılar açıklama amaçlıdır; gerçek dosya veya güncel ağ ücreti değildir.
İşlem geçmişini yorumlayan uzman, Bitcoin Core 30.0 gettransaction belgesindeki onay, çakışma ve yerine geçme alanlarının neyi gösterdiğini açıklamalıdır. Bu kayıtlar kullanılan yerel cüzdanın bildikleriyle sınırlı olabilir. Alanın boş olması, dünyadaki bütün çakışma ihtimallerinin dışlandığını göstermez.
TxID, çıktı ve zaman birlikte nasıl kaydedilir?
Bitcoin’de bir işlem birden fazla alıcıya ve para üstü adresine çıktı üretebilir. Bu yüzden yalnız TxID yazmak çoğu zaman yeterli değildir. Uyuşmazlık konusu alıcı adresi ile çıktı sıra numarası (vout) belirtilmeli; bütün işlem tutarı tek kişinin ödemesi sayılmamalıdır. Bu ayrımı Bitcoin para üstü ve zarar hesabı yazısında ayrıca ele alıyoruz.
- Ödeme talebini koruyun: Alıcının bildirdiği ağ, tam adres, tutar ve varsa fatura/emir numarasını yazışmayla eşleştirin.
- İlk kaydı saklayın: İlk TxID’yi, uygulama durumunu ve ekranın alındığı zamanı kaydedin. Ekranı son durumla değiştirmek yerine yeni kaydı ekleyin.
- İlişkili işlemleri ayırın: Yerine geçen veya çakışan işlemi ayrı satıra yazın; ilişkinin hangi veriye dayandığını gösterin.
- Zincir durumunu sabitleyin: Aktif zincir bağlamı, blok, onay sayısı, sorgu kaynağı ve kontrol saatini aynı kayda koyun. Cihaz saati ile blok zamanını birbirinin yerine kullanmayın.
- Alıcı kaydıyla uzlaştırın: Bir borsaya gönderim varsa zincirdeki çıktı ile borsanın hesap içi yatırma/alacaklandırma kaydını karşılaştırın.
getrawtransaction belgesi, blok bağlamı ve işlem çıktıları gibi alanları tanımlar; düğümün indeksleme ve blok verisine erişimi sorgunun kapsamını etkiler. Tek sorguda kayıt bulunamaması üzerine “işlem yoktur” yazmak yerine aramanın sınırı belirtilmelidir.
Aynı ödeme girişimi zarara iki kez yazılmamalı
Varsayımsal kayıt örneği: A işlemi alıcıya 0,02000000 BTC göndermeyi amaçlıyor, ancak onaylanmıyor. A’nın yerine geçtiği doğrulanan B işlemi aynı alıcıya 0,02000000 BTC gönderiyor ve kontrol anında aktif zincirde onaylı. Bu kayıtlardan alıcıya toplam 0,04000000 BTC ödendiği sonucu çıkmaz. A olay geçmişinde korunur; tamamlanan ödeme, B’nin ilgili çıktısıyla açıklanır.
B işlemi alıcıya ödeme yapmıyorsa sonuç değişir. Fakat bu durumda dahi taraflar arasındaki borcun sona erip ermediği, başka bir ödeme bulunup bulunmadığı ve tarafların ne üzerinde anlaştığı ayrıca araştırılır. Teknik inceleme, belirli adrese doğrulanan teslimi saptar; sözleşmenin bütün sonuçlarını kendi başına belirlemez.
Bir dolandırıcılık şikâyetinde bekleyen işlem bilgisi de olayın parçası olabilir. Bununla birlikte gönderilmek istenen tutar, tamamlanmış çıkış ve sonradan iade edilen tutar birbirine karıştırılmamalıdır. Cüzdan delil dosyasındaki kronoloji, bu kayıtları yazışma ve platform hareketleriyle birlikte tutmaya yarar.
Bitcoin kuralını başka ağlara taşımayın
Bu yazı Bitcoin işlemleri içindir. Ethereum’daki aynı nonce ile yenileme, TRON’daki işlem durumu veya bir borsanın kendi iç transferi aynı teknik kurallarla açıklanamaz. Borsa ekranındaki “işleniyor” kaydı henüz zincir işlemi oluşturulmadığı anlamına da gelebilir. İncelemeye ağın ve işlem türünün kesinleştirilmesiyle başlanmalıdır.
“İşlemi kesin iptal ederiz”, “bekleyen transferi açarız” diyerek kurtarma kelimesi veya yeni ödeme isteyen kişilere bilgi göndermeyin. Zincirdeki işlem durumunun incelenmesi için özel anahtarın halka açık bir gezgine girilmesi gerekmez. Hukuki başvuruda ihtiyaç duyulan şey, eski ve yeni kayıtların birbirini tamamladığı, kontrol tarihi belli bir delil dizisidir.
Kaynak ve kapsam
Bu inceleme, metinde bağlantıları verilen Bitcoin geliştirici belgeleri, Bitcoin Core 29.0 ve 30.0 sürüm belgeleri ile 10 Şubat 2021 tarihli iPROCEEDS-2 kılavuzunun tarihsel uygulama örneğine dayanır. Kaynak kontrolü: 20 Ekim 2026. Sürüm notları bütün ağın tek tip davranacağını, işlem kaydı da kişinin kimliğini veya hukuki hak sahipliğini göstermez. Kişi bağlantısı için kontrol, kimlik ve mülkiyet ayrımı ayrıca korunmalıdır.
