Bitcoin işlemindeki toplam girdi, karşı tarafa gönderilen tutar veya mağdurun zararı değildir. Bir işlem, harcanan Bitcoin’in bir bölümünü alıcıya, kalanını gönderenin kontrolündeki başka bir adrese para üstü olarak yönlendirebilir. Alıcı ödemesi, para üstü ve ağ ücreti ayrılmadan yapılan hesap, gerçekte kaybedilenden çok daha yüksek bir zarar gösterebilir. Buna karşılık, “bu çıktı para üstüdür” varsayımı da gerçekten çalınmış bir tutarı hesabın dışında bırakabilir.
Bu yazı Bitcoin ana ağındaki UTXO işlemleri için okunabilir bir hesap yöntemi sunar. Ethereum veya TRON token transferlerine aynı formül doğrudan uygulanmaz. Amaç adreslerin tamamını tek kişiye bağlamak değil; belirli bir olayda hangi tutarın kimin kontrolünden çıktığını, hangi kayıtla ve hangi belirsizlikle söyleyebildiğimizi ortaya koymaktır.
Bitcoin’de para üstü neden oluşur?
Bitcoin bakiyesi, henüz harcanmamış işlem çıktılarından oluşur. Bunlara UTXO denir. Yeni işlem önceki çıktıların tamamını girdi olarak harcar; ardından yeni çıktılar oluşturur. Ödeme için kullanılan önceki çıktı, gönderilmek istenen tutardan büyükse, kalan değer çoğu cüzdanda aynı cüzdanın yönettiği bir para üstü adresine aktarılır. Bu adresin kullanıcıya daha önce gösterilen alım adresinden farklı olması olağandır.
Bitcoin geliştirici rehberi, girdinin önceki bir işlemin kimliği ve çıktı numarasıyla tanımlandığını açıklar. Yeni çıktılar da sıra numarası taşır. Dolayısıyla bir para hareketini belirlerken yalnız işlem kimliği değil, ilgili vout numarası da önemlidir. Aynı işlemde birden fazla alıcı bulunduğunda hangi çıktının araştırıldığı bu numarayla kesinleştirilir.
Para üstü için ayrıca bir ikinci işlem yapılması gerekmez: Ödeme çıktısı ve para üstü çıktısı aynı işlem içinde oluşabilir. Trezor’un UTXO açıklaması bu cüzdan davranışını örnekler. Kullanıcının “Ben bu ikinci adrese hiç para göndermedim” demesi, tek başına izinsiz bir ödeme bulunduğunu göstermez; cüzdanın bu adresi kendisi üretip üretmediği araştırılmalıdır.
0,30 BTC gönderirken neden 0,90 BTC hareket etmiş görünür?
Aşağıdaki örnek varsayımsaldır. Bir kullanıcıya ait olduğu ayrıca doğrulanmış iki çıktı harcanıyor: 0,60 BTC ve 0,30 BTC. İşlem, karşı tarafa 0,30 BTC; kullanıcının kendi para üstü adresine 0,5998 BTC gönderiyor. Aradaki 0,0002 BTC ağ ücretidir.
| Kayıt | Tutar | Hesaptaki anlamı |
|---|---|---|
| Harcanan birinci UTXO | 0,60000000 BTC | Girdi |
| Harcanan ikinci UTXO | 0,30000000 BTC | Girdi |
| Girdiler toplamı | 0,90000000 BTC | İşlemin kullandığı toplam değer |
| Karşı tarafa giden çıktı | 0,30000000 BTC | İncelenen ödeme |
| Kullanıcıya dönen çıktı | 0,59980000 BTC | Kontrolü doğrulanmış para üstü |
| Ağ ücreti | 0,00020000 BTC | Girdi ile çıktı toplamı arasındaki fark |
Mutabakat şöyledir: 0,90000000 = 0,30000000 + 0,59980000 + 0,00020000 BTC. Bütün girdilerin kullanıcıya ait olduğu ve para üstünün onun kontrolünde kaldığı varsayımı altında cüzdanın bu işlemdeki net azalışı 0,30020000 BTC’dir. Karşı tarafın aldığı tutar ise 0,30000000 BTC’dir. İki rakam arasındaki fark, ayrıca gösterilmesi gereken ücrettir.
Ödeme dolandırıcılık iddiasına konu olsa bile 0,90 BTC’nin tamamını “şüpheliye giden para” diye yazmak bu örnekte yanlıştır. Ancak 0,5998 BTC’lik çıktı için kontrol doğrulanmamışsa onu kesin para üstü kabul edip dışarıda bırakmak da yanlıştır. Bir hesap tablosu, adres atfındaki belirsizliği ortadan kaldırmaz.
Hesaplama sırasında bütün miktarlar aynı birimde tutulmalıdır. Bir BTC 100 milyon satoshidir; sekiz basamaktan sonraki yuvarlama, özellikle çok sayıda küçük işlemin birleştirildiği tabloda fark doğurabilir. Önce satoshi cinsinden tam sayı toplamı oluşturup, okuyucuya BTC karşılığını göstermek denetlenebilirliği artırır. Örnekte ücret 20.000 satoshidir; bir fiyat tahmini değildir.
Bir çıktının para üstü olduğu nasıl doğrulanır?
Blokzincir, çıktının üzerinde “mağdura dönen para üstü” şeklinde hukuki bir açıklama taşımaz. İnceleme, çıktı ile kullanılan cüzdan arasında bağ kurmalıdır. En güçlü kayıtlar genellikle gönderenin kendi cüzdanı veya saklama sağlayıcısındadır. Ekran görüntüsüyle yetinmek yerine, mümkün olduğunda dışa aktarılmış işlem ayrıntısı ve cüzdanın adres türetme bilgisi karşılaştırılır.
- Cüzdan kaydı: İşlemin ödeme tutarı, ücret ve para üstü ayrımı cüzdan yazılımında nasıl görünüyor?
- Adres ilişkilendirmesi: İlgili çıktı adresi gerçekten bu cüzdanın türettiği adreslerden mi? Kontrol hangi yöntemle yapılmış?
- Ödeme belgesi: Karşı tarafın gönderdiği adres ve istenen tutar, işlemdeki hangi çıktıyla eşleşiyor?
- Zaman bağlantısı: Cüzdan kaydı ve yazışma aynı işleme mi ait? Daha sonraki ayrı transferler araya karışmış mı?
- Alternatif açıklama: Toplu ödeme, ortaklaşa oluşturulmuş işlem veya şirket içi transfer ihtimali var mı?
Bitcoin Core getaddressinfo belgesi, cüzdanın bildiği adres için ischange ve descriptor bilgileri gibi alanları açıklar. Bu yerel cüzdan bilgisi, kamuya açık işlem gezgininin tahmininden farklıdır. Başka bir kişinin adresini herhangi bir cüzdanda sorgulamak, o adresin gerçek sahibini ortaya çıkarmaz. Yanlış cüzdan veya eksik içe aktarma üzerinden alınmış sonucun sınırı raporda yazılmalıdır.
Para üstünü belirlemek için kurtarma kelimelerinin rapora konulması gerekmez. Anahtar içermeyen teknik kayıtların da tüm geçmişi ifşa edebileceği unutulmamalıdır: Özellikle genişletilmiş açık anahtar veya geniş kapsamlı descriptor, araştırılan işlemden daha fazla adresi ilişkilendirebilir. İnceleme kapsamına gereken kayıt alınmalı, kamuya sunulan metin ile erişimi sınırlı teknik ek ayrılmalıdır.
Para üstünü tahmin ederken hangi kestirmeler hata verir?
“Küsuratlı çıktı para üstüdür”
Küsurat, ödeme fiyatının veya kur çevriminin sonucu olabilir. Yuvarlak tutar da para üstü olabilir. Tutarın biçimi bir araştırma ipucu sağlayabilir; tek başına adli atıf ölçütü değildir. Aynı nedenle iki çıktıdan büyüğünün daima kullanıcıya döndüğü söylenemez.
“Yeni adres mutlaka gönderene aittir”
Ödeme alan kişi de her ödeme için yeni adres oluşturabilir. Bir adresin zincirde ilk kez görünmesi, gönderenin kontrolünü kanıtlamaz. İlk kez görünen çıktı ile cüzdanın kendi kayıtları eşleşmiyorsa, sınıflandırma “para üstü adayı” seviyesinde kalmalıdır.
“Bütün girdiler aynı kişiye aittir”
Bu varsayım ortaklaşa oluşturulan işlemlerde bozulabilir. Bitcoin’in CoinJoin açıklaması, farklı katılımcıların girdilerinin tek işlemde birleştirilmesini gösterir. İşlem düzeyindeki toplamdan tek bir mağdurun zararını çıkarmak, katılımcı payları belirlenmemişse güvenilir değildir. Aynı dosyada kümeleme kullanılacaksa yöntemin sınırları cüzdan kümeleme ve kimliklendirme rehberindeki ayrı değerlendirmeyle ele alınmalıdır.
Borsa çekiminde görülen büyük işlem kime aittir?
Bir borsa çok sayıda müşterinin çekimini tek Bitcoin işleminde birleştirebilir. Böyle bir işlemde kullanıcının çekimi 0,02 BTC iken toplam çıktılar çok daha yüksek olabilir. İşlem kimliğinin çekim geçmişinde görünmesi, o işlemin bütün girdilerinin veya çıktılarının kullanıcıya ait olduğunu göstermez.
Bu senaryoda uzlaştırma üç kayıt üzerinden kurulur: Kullanıcının borsa hesabından düşülen tutar, borsanın çekim ücreti ve belirtilen alıcı adresindeki ilgili çıktı. Borsanın kullanıcıdan aldığı hizmet ücreti ile işlemde madencilere ödenen toplam ağ ücreti aynı olmak zorunda değildir. Toplu işlemin ağ ücretinin tamamını tek kullanıcının zararı olarak yazmak için dayanak bulunmaz.
Varsayımsal örnekte hesap özeti 0,0205 BTC düşüş, alıcı çıktısı 0,0200 BTC ve borsa tarifesi 0,0005 BTC çekim ücreti gösteriyorsa bu üçlü kendi içinde açıklanabilir. Zincirdeki toplu işlemin ücretinin 0,001 BTC olması, kullanıcının bir 0,001 BTC daha kaybettiğini kanıtlamaz. Ödenen bedelin niteliği kurumun hesap kaydıyla belirlenir; blokzincir tüm müşteri muhasebesini göstermez.
Aynı Bitcoin’i iki kez zarar hesabına eklememek
Mağdurdan çıkan 0,30 BTC’nin önce A’ya, sonra B’ye, ardından bir borsaya gitmesi üç ayrı mağdur zararı doğurmaz. Bu hareketler aynı başlangıç kaybının takip halkaları olabilir. Para üstü ise mağdurun kontrolünde kalan değer olduğundan, sonradan ayrı bir izinsiz işlemle alınmadıkça başlangıç kaybına katılmaz.
İşlem değiştirme kayıtları da kontrol edilmelidir. Aynı ödemeye ilişkin eski ve onun yerine geçen işlem kimliklerini iki tamamlanmış ödeme gibi toplamak hatalı sonuç verir. Bitcoin Core gettransaction çıktısı; onay, çakışma, yerine geçen işlem ve işlem ayrıntısı alanlarını açıklar. Hesabın kesim tarihinde zincirde hangi işlemin bulunduğu sabitlenmeli; yalnız cüzdan geçmişinde görünmekle yetinilmemelidir.
İade veya kısmi geri dönüş bulunuyorsa bu da ayrı satırda gösterilir. İadeyi başlangıç transferinden silip olayın izini kaybetmek yerine brüt kayıp, geri dönen tutar ve net bakiye ayrı tutulur. Sonradan gerçekleşen fiyat hareketi bu varlık akışını değiştirmez; Türk lirası karşılığının hangi tarih ve hangi hukuki talep esas alınarak hesaplanacağı ayrı sorudur.
Denetlenebilir zarar cetveli nasıl kurulur?
İşlem sayısı arttığında her satırın aynı soruya cevap vermesi gerekir: Bu kayıt ilk kayıp mı, aynı varlığın sonraki hareketi mi, para üstü mü, masraf mı, iade mi? Aşağıdaki kolonlar bir teknik raporun hesabını yeniden yapılabilir hâle getirir.
| Kolon | İçerik |
|---|---|
| Olay ve kişi bağlantısı | Mağdur veya hesap kodu; aidiyet belgesinin adı |
| İşlem ve çıktı | Bitcoin ağı, tam TxID, ilgili vout numarası |
| Miktar | Satoshi olarak tutar ve BTC karşılığı |
| Sınıflandırma | İlk çıkış, ödeme, para üstü, ücret, takip halkası veya iade |
| Kontrol dayanağı | Cüzdan kaydı, kurum kaydı, mesaj-adres eşleşmesi veya yalnız tahmin |
| Zaman ve durum | Blok, onay durumu, veri kesim zamanı ve saat dilimi |
| Hesaba etkisi | Zarara eklendi, düşüldü, yalnız takipte kullanıldı veya belirsiz bırakıldı |
Her “para üstü” sınıflandırmasının yanına kanıtı yazmak gerekir. Belirsiz iki çıktı varsa tek bir kesin tutar vermek yerine doğrulanmış en az kayıp ile henüz aidiyeti belirlenmemiş tutar ayrı gösterilebilir. Bu ayrım, belirsiz kısmın kayıp olmadığı anlamına gelmez; hükme esas olacak hesabın hangi ek kayıtla tamamlanabileceğini açıklar.
Teknik azalış ile hukuken talep edilecek zarar aynı şey midir?
Her zaman değildir. Teknik inceleme hangi varlığın, hangi işlemle, hangi kontrol alanından çıktığını belirler. Tazminat değerlendirmesi ise fiilin hukuka aykırılığı, kusur, nedensellik, talep türü, varsa iade ve diğer hukuki unsurları da kapsar. Bir transferin rızayla imzalanması aldatma iddiasını kendiliğinden ortadan kaldırmaz; zincirde imza bulunması, hukuki iradenin bütün koşullarını açıklamaz.
TBK m.50, zarar görenin zararını ve zarar verenin kusurunu ispat yükünü düzenler; miktar tam ispat edilemiyorsa hâkimin hakkaniyete uygun belirleme yapmasına ilişkin hüküm içerir. Bu düzenleme hesap yapmaktan kaçınmanın gerekçesi değildir. Eldeki Bitcoin işlem kayıtlarıyla belirlenebilen bölüm açıklanmalı, eksik bölümün neden belirlenemediği gösterilmelidir.
Ceza dosyasında CMK m.217 çerçevesinde delillerin hukuka uygunluğu ve değerlendirilmesi esastır. İşlem gezginindeki bir etiket mahkemenin yerine fail veya mal sahibi belirlemez. Teknik hesap, olayın tamamıyla ilişkilendirildiğinde değer taşır. Raporun düzeni ve delil bağlantıları için kripto teknik uzman raporu; kayıtların bir arada tutulması için cüzdan delil dosyası açıklamalarına başvurulabilir.
İşlem kaydını okurken kalan iki soru
Para üstü adresindeki Bitcoin sonra harcanmışsa ilk ödeme büyür mü?
Hayır. İkinci harcama ayrı bir olaydır. Aynı kişinin kendi transferi, sonraki bir ödeme veya ikinci bir izinsiz çıkış olabilir. İlk ödeme miktarı geriye dönük büyümez; ikinci olay varsa kendi delilleriyle hesaplanır.
İşlemde tek çıktı varsa para üstü yok mu?
Tek çıktılı olağan bir harcama işleminde ayrıca bir para üstü çıktısı bulunmaz. Ancak bu bilgi, çıktının kime ait olduğunu veya bütün girdilerin aynı mağdurdan geldiğini çözmez. Kendi cüzdanına toplama işlemi de tek çıktı üretebilir. İşlem biçimi ile ekonomik amaç ayrı incelenmelidir.
Kaynaklar ve inceleme tarihi
Bu rehber, metin içinde bağlantıları verilen Bitcoin geliştirici belgeleri, Bitcoin Core 30.0.0 işlem ve adres kayıt tanımları, Trezor’un UTXO açıklaması ile TBK m.50 ve CMK m.217 temel alınarak hazırlanmıştır. Sayısal örnekler gerçek dosya değildir. İnceleme tarihi: 6 Ekim 2026. Hesap yöntemi bir kaybın varlığını varsaymaz; aidiyet ve olay bağlantısı ayrıca doğrulanır.
