Topic: Bitcoin; Algoritma Üzerine Yöntemler - page 22. (Read 33759 times)

hocam malum herkeste ssd yok, postgresql'i yemek için ömrümüz yetmez, ayrıca filleri çok seviyoruz oluşturulan değerin kontrolü için anlık sorgularda farklı şekillerdeki lock table ile bottleneck denilen illetler oluşmasın diye yazdım. ikinci içinde izlediğim yol şu şekilde. daha önce yazdım sanırım. sıralı yada belirli aralıkla tarattığımda db'deki tablodan baslangic-satirSayisi kontrol ediyor. oluşturulacak değerler tablodaki tanımlı başlangıç + bitiş değeri arasında ise sonrakine bakıyor. ilave olarak kelime bazlı çalışmada hashleri alınmış değerlerini unique indeksli heks formatında (ascii_binary) tutarak, adres oluşturmaya girmeden sadece sha256 karşılaştırması ile min. yük bindirmiş oldum sözlük taramasında heks-tab-adres1-tab-adres2-tab-kelime-satırSonu şeklinde dosyaya yazdırıyorum. zaten tekrar kelime oluşturulmadığı için eşsiz oluyor. 50Milyon parçalı şekilde sonra heks'leri db'deki tabloya kaydediyor. adres1-adres2  mevcut adreslerle karşılaştırıyor, bulduğunu bulunan tablosuna kaydediyor. formatı heks-desimal-wif-adres-adresTürü(kısa mı uzun private keymi)-kelimeDegeri-AdresHash160-TxSayisi-alinan-gonderilen-sonKullanilma-dolu(eğer bakiye var ise 1 yapıyor)-DosyaNo-SatirNo-guncelSorguTarihi-BulunmaTarihi. bulduğunda direkt olarak bakiyeyi kontrol ediyor. ayrıca her seferinde aynı kullanılmışlar arasında taramasın diye DosyaLog tablosunda hangilerinde taradığını kaydediyor tekrar taramada en son tablodan başlayarak yeni tablo varsa ondan devam ediyor. eski mesajlarda yöntemlerin hepsi tek tabloda toplanıyor. Bulduğu adresler eşsiz olduğu için tekrar bulundu diye eklemiyor.
vanitygen üretme daha sıkıntılı. günlük olarak dosyayı açıyor, gereksiz yerleri temizliyor, istenilen formata dönüştürüyor. önce csv formatına kaydediyor. gelen wif değerini, heks'e dönüştürüyor, oradan sonra yukarıdaki karşılaştırma işlemleri ve dbdeki vanity tablosuna (adresler eşşiz) ondan dolayı tekrar ekleyemiyor. ancak buradaki sıkıntı vanity K ve L ile başlayan private keylerin değerlerini üretmiyor. Eğer aradığım değer o aralıkta ise diye heks değeri tekrar işleme sokup kısa adres dediğimiz 2. aralıktaki adresi tekrar oluşturuyorum. bana bu aşamada heks-adres1-adres2-onEk yeterli oluyor. OnEk indeksli olduğu için gruplayarak istediğim başlangıç değerlerinde kaçar adet ürettiğine bakıyorum. misal vanitygende char length(onEk) ile uzunluk aralığına bakıyorum. falan filan. ne yazdım be  birde tekrarlanma olayı var onu daha önce yazdım. sistem ilk 2-3 aşamada farklılık göstersede 4.-5. aşaması aynı. döngü şeklinde gidiyor. işlem gücü arayışındayım şu an.

aklımıza geldi aslında ya vanitygen aynı adresi bir daha üretirse diye,
çakışmaları aza indirmek adına prefix yaptık. her uç bilgisayarda farklı kombinasyon aralığı için adres üretiyoruz.

PC1 1a...
PC2 1b
PC3 1c
PC4 1d
şeklinde ayırdık. eve geçince bir select atayım veritabanına duplicate kayıt var mı kontrol edeyim.

yok artık. mysql, postgresql i yediniz bitirdiniz noSQL e koşuyorsunuz.

Her şey den önce, bir kere ürettiğiniz bir adresi ikinci kere üretmemek için bir ayıklama yoluna gitmeniz lazım.

@miyav sende ki adres tablosunda duplicate kayıt var mı kontrol ediyor musunuz bunu?

Paylaşılan python script i inceledim bu arada. Bir vanitygen değil. Ama programlama öğrenmeye çalışanlar için aydınlatıcı kesinlikle.
ayrıca sonuçta yorumlayıcı bir dili c ile yazılmış compile edilmiş bir yazılım ile kapıştırmak çok doğru gelmedi  bana.

redis üzerine çalışmak çok faydalı gözüküyor...
paylaşım güzel bir bilgi oldu teşekkürler hocam...

redis ile ilgili bir ön bilgi okumakta fayda var...
http://aristona.github.io/redis-kullanimi-ve-incelikleri

Sürekli olarak ürettiği adresi kontrol edenler için tavsiyem; redis gibi bir sistem üzerinden karşılaştırma yapın. Şu an 1 ile başlayan kullanılmış adres sayısı yaklaşık 190 Milyon (küsüratı attım, dolu-boş kapsamakta), daha önce konudan paylaştığım (20180818 tarihli kayıt) 18 Milyon (küsüratı attım) dolu adres bulunmakta. bu kayıtları tekrarsız şekilde RAM'e atıp oradan istediği programlama dili yardımıyla kontrol edebilir. hem hdd iletişimini minimize edip, hem RAM'in hız avantajından faydalanabilirsiniz. redis'in belirli aralıklarla hafızasını hdd'ye kayıt etmesi güzel bir özellik

tarama yöntemlerinde hala alternatif çözüm bulunmamakta ve belirli bir adrese yönelik çalışmaya devam ediyorum. ancak hızı artırmak için zombi bilgisayarlara yaymak ve yazılım yapılarak belirli aralıkları üretmesi sağlanabilir gibi duruyor  

 
 DB ile çalışan ve bu yöntem ile sorgulama yaptıran arkadaşlara;

3 yıl önce  oldukça fazla  DB sorgulaması  gerektiren  bir PHP ve Flash AC3 tabanlı  yazılım  kullanıyordum.
MySQL den  MariaDB  ye  geçiş yaptığımda  gözle görülür ve hissedilir derecede hızlanma olmuştu sorgularda.
Şimdide öyle midir bilmiyorum ama o zamanlar baya rahatlatmıştı işlerimi.

paython' da yazılmış bir yazılım
adres üretimi yapıp balance kontrolü yapıyor.
oluşan adresleri csv dosyasına atar...
modülleri yükleyip hemen kullanabilirsiniz.




#!/usr/bin/env python

import os
import ecdsa
import hashlib
import base58
import requests
import time
from smtplib import SMTP_SSL as SMTP
import logging


wif = ""



logging.basicConfig(filename='BTC_PrivateKeys_'+time.strftime("%Y-%m-%d-%H-%M")+'.csv', \
level=logging.INFO, format='%(message)s', datefmt='%Y-%m-%d,%H:%M:%S')
logging.getLogger("requests").setLevel(logging.WARNING)
logging.info ('"Timestamp", "WifKey", "PublicAddress"')



def ping_address(publicAddress):
   global pk
   global wif
   global publicKey

   """
   sends Request to a Block Explorer   
   Main one is blockexplorer - seems to be UNLIMITED...using chain.so has a rate limiter
   https://blockexplorer.com/api/addr/
   balance =  pmts['balance']
   https://chain.so/api/v2/get_address_balance/BTC/
   balance =  pmts['data']['confirmed_balance']
   """

   req = requests.get("https://blockexplorer.com/api/addr/"+publicAddress)
   pmts = req.json()
   balance =  pmts['balance']
   print balance

   # "WifKey", "HexKey", "PublicAddress", "PublicKey", "Balance"
   logging.info (''+ time.strftime("%m-%d-%y %H:%M:%S") +','+ wif +','+publicAddress +',        ' + str(balance) )

   if float(balance) > 0.00000000:
      print "Tebrikler, aktif bir hesap buldunuz"

def wif_conversion(pk):
   global wif
   padding = '80' + pk
   # print padding

   hashedVal = hashlib.sha256(padding.decode('hex')).hexdigest()
   checksum = hashlib.sha256(hashedVal.decode('hex')).hexdigest()[:8]
   # print hashedVal
   # print padding+checksum

   payload = padding + checksum
   wif = base58.b58encode(payload.decode('hex'))
   print wif
   

while True:

   pk = os.urandom(32).encode("hex")
   wif_conversion(pk)

   sk = ecdsa.SigningKey.from_string(pk.decode("hex"), curve = ecdsa.SECP256k1)
   vk = sk.verifying_key
   publicKey = ("\04" + vk.to_string())
   ripemd160 = hashlib.new('ripemd160')
   ripemd160.update(hashlib.sha256(publicKey).digest())
   networkAppend = '\00' + ripemd160.digest()
   checksum = hashlib.sha256(hashlib.sha256(networkAppend).digest()).digest()[:4]
   binary_address = networkAppend + checksum
   publicAddress = base58.b58encode(binary_address)
   print publicAddress
   while True:
      try:
         ping_address(publicAddress)   
      except ValueError:
         print "bekleyin 3 saniye"
         print pk
         print publicAddress
         time.sleep(3)
         continue

      break

# msg = "I own your Private Key for %s" %(publicAddress)
# signed_msg = sk.sign(msg)
# encoded_msg = signed_msg.encode("hex")

mugt doğru söylüyor. csv olarak alıp copy ile atabilirdiniz. kullandığınız tablonun özelliklerini yazarsan optimizasyon yönünde önerilerde bulunabiliriz. bence iyi gidiyorsunuz. Bir düşün bakalım. 3 ay önceki bilgi birikimin ile şimdiki bir mi? geliştiriyorsunuz kendinizi.

miyav tablo id türünü int'te bıraktığınız için olabilir. mysql'den Toad, sqlyog gibi yazılımlarla dışarı csv olarak çıkartıp, postgresql'e copy ile aktarabilirdiniz. Hazır mysql->postgresql transfer eden yazılımlarda var. 5milyon kayıt indeksleri ile maksimum 5 dakika sürmesi lazımdı.

site aşırı basitleştirmiş olayı. benzer ekranı bende yapmaya çalışıyordum. javascriptte bazı yerler şifreli gibi duruyor. eğer ayırıp node.js'e dahil edebilirsem buradan paylaşırım.

1 ay daha geçti. adres üretip bakiye kontrol etmeye devam ediyoruz.
25 Ağustos - 25 Eylül döneminde yaptığımız değişiklikler:

mysql de bir tabloda 2.4 milyondan dan fazla kayıt tutamıyorduk. postgresql'e geçtik.
veritabanı değişince adres üreten uçların  kodlarını güncellememiz gerekti.
kod güncellemeleri ile yaklaşık 1 hafta zaman kaybettik.

artık oclvanitygen'i birden fazla GPU olan sistemde çalıştırabiliyoruz.
iki arkadaşımızın bilgisayarında çift ekran kartı var. onların özel isteği idi.

adres üreten bilgisayar sayısını artırdık ama bilgisayarlar sürekli açık olmadığı için yinede hızımız bana göre yavaş.

postgresql e geçip uç bilgisayar sayısını artırınca VPS i upgrade etmek zorunda kaldık.
aylık vps kiramız 2 katına çıktı.

mysql deki 5 küsür milyon adres bilgisini postgresql e aktarırken bir tarafımızdan kan geldi.
bu iş bu kadar zor olmamalıydı. mysqldump ile aldığımız yedeği çat diye yükleyebiliriz zannediyorduk.
meğer bu işler o kadar basit değilmiş.  sonunda bir amelelik yapıp php de bir otoasyon yazdım.
birinden select yapıp diğerine insert yaptırarak veritabanını taşıdım.

gelelim istatistiklere:

bitcoin= SELECT COUNT(*) FROM public.adresler;
count
--------
14542678
(1 row)

işe başladığımızdan beri taradığımız adres sayısı 14 milyonu geçmiş.

bitcoin= SELECT COUNT(*) FROM public.adresler WHERE bakiye>0;
count
--------
19
(1 row)

toplam bulduğumuz 0 dan büyük bakiyeli adres sayısı sadece 19


bitcoin= SELECT SUM(bakiye) FROM public.adresler WHERE bakiye>0;
 sum
----------
0.01500941
(1 row)

25 haziran da otomasyonu aktif çalıştırmaya başladık.
25 eylül de 3 ay bitti.
14 milyonda 19 gibi bir oran, iğne ile kuyu kazıyoruz ama teknik olarak çok şey öğreniyoruz.
eğer bu 19 adresi boşaltır isek 15 mbtc toplamış oluruz.
şimdilik gelişmeler bu kadar.

vanitygen mi kulanıyorsun?

bu olayı sadece btc tarafında düşünmemek gerekli en eski coinlerin tamamında bu benzerlikler yapılabilir ether tarafında da mevcut vanithygen aklınızda bulunsun dedim.

1xx türünde 340.000 kullanılmış adres export ettim ancak sanırım 11.000 adresi ortalama 1,5 saatte üretiyorum birkaçgünde nasıl oluyor da siz çok ciddi rakamlarda adres üretebiliyorsunuz enteresan geliyor bana bunu hızlandıracak bir yapı mevcutmudur?

evet aynen doğru yazılım bilgisi olmayan arkadaşlar için izlenecek en hızlı ve kolay sonuç alınabilecek yöntem... tabi şunu da unutmamak gerek milyarlarca adres üretmek gerekiyor (ben 20 gündür 1xx için adres üretiyorum kaç milyar tane oldu bilemiyorum ve ürettirmeye devam ediyorum)...

Ama yazılımsal çözüm bu başlıktada yazıldığı gibi daha önce
1- her kişisel bilgisayara bitcoin-core kurulacak
2- pattern, random yada belli bir sayfalamayla üretilen adresler bir txt dosyasına export edilecek
3- tüm bloklar bir yazılımla indexlenecek
4- aynı yazılımla import edilen txt dosyası satır satır bakiye kontrolü yapılacak
5- bulunan bakiyeli adresler başka bir txt dosyasına yazdırılacak...

bu 5 adımlı çözüm ise daha sistematik ve kişisel yorgunluk oluşturmayan bir çözüm...(bilgisayar kendi kendine takılıyor)

Bu arada, aşağıdaki sitede çok hızlı bir şekilde saniyede 12.000 adrese kadar çıkıyor, bakiye (1 Btc ve üstü 3 yıl çıkış olmamış adresleri tarıyor, eğer bulursa %30 komisyon alacakmış) taradığını idda ediyorlar. İsterseniz deneyebilirsiniz. Benim tahminim browser üzerinden cpu minning yapıyorlar (yanlış bir tahminde olabilir bir araştırma yapmadım). Ben bir bilgisayarı verdim deniyorum 12 saattir 500 milyon adres taradı şu ana kadar 2 -3 gün denemekte yarar var diye düşünüyorum...
https://privatekeys.pw/scanner

BU TÜR SİTELERİN HİÇ BİRİNE LÜTFEN DENEME AMAÇLI BİLE OLSA KEYLERİNİZİ GİRMEYİN

Harika bilgiler paylaştınız hocam teşekkür ederim yeminle meritim olsa verirdim. bu işin kötü tarafı ne kadar saklayacak olsak da birileri ellerindeki teknolojik gelişmeler sayesinde gün gelecek adreslere bir şekilde erişecek

sıralama

1.blockparser adresleri üret
2. üretilen adresleri ayıkla bulmak istediklerini arşivden çıkart
3. adres üret ve karşılaştır

bütün mantık bu diyebilirmiyiz.

vanitygen64 -k -o list 1xx >list.txt

bir txt dosyasına bu komutu yazıp,bunu bat dosyası haline getirirsin 1xx....... şeklinde adresler oluşur, cmd yi kapattığında list.txt dosyasında yada list (tüm adresler burda kayıt edilir, komutu her çalıştırdığında list.txt dosyası kendini yeniler ama list dosyası o ana kadar oluşturulmuş adresleri sürekli kayıt eder, list dosyasını notepad++ ile açabilirsin) dosyasında adresler oluşmuş olur, daha sonra kimi düzenlemelerle txt dosyasını düzenleyip sadece adresleri alıp ister balance kontrolü yaparsın istersen karşılaştırma...

Evet sadece bu hafta içinde 4 adres yakaladım, hedefimdeki adres kümesi 1xx..... idi. 4 ün 3 ü kullanılmış birinde 0,000124 BTC mevcut, hala devam ediyorum adres oluşturmaya amacım içinde 10 ve 1 olan adreslerden birini bulmak yaklaşık 4000 tane sinde 0.25, 0.5, 1 ve 10 BTC (benim bir siteden bulup eklediklerim) mevcut kullanılmışlarla toplam 200.000 adreslik bir gurupta karşılaştırma yapıyorum.
200.000 (kullanılmış adres) & 1.000.000 (oluşturulan adres) şeklinde

vanitygen ile oluşturma işlemi nedense bende aşırı yavaş komutlarda bir yerlerde hata yapıyorum ancak nere yaptığımı anlayamadım.

tamam şimdi oturdu kafama hersey

ben bir dönem denemiş anlayamayında vazgeçmiştim yola giriyorum ama ortaya sonuç çıkaramıyordum  cidden sonuç aldığınız oluyor mu hala heyecanlandırıyor bu konu beni.
bulduğunuz sonuçlarda dolu çıkan olduğu zaman boşaltıyormusunuz adresleri?

"""elimde kullanılmış bütün adresler mevcut ancak acemi olduğum için pratik bir kullanım yolu bulamadım"""

ben hedef bir 1xx şeklinde kullanılmış adresleri çıkartıyorum. 200.000 tane kadar. sonrasında üç dört gün bir bilgisayara adres ürettirip (1xx........) oluşan adreslerle benzerlik taraması yaptırıyorum (bu tarama 1 saat içinde bitiyor) ve sonuçlar ilginç oluyor kimi zaman

tabi bu yöntem basit ve programcılıkla alakası olmayan bir metod bizim çözümümüz & gelişimimiz daha sistematik ve yazılımsal bir altyapıda ilerlemeli...

Curl komutu ile denemeler yapmak sorun değilde verinin büyüklüğü göz önüne alındığında ciddi anlamda işlem uzun sürecektir

elimde kullanılmış bütün adresler mevcut ancak acemi olduğum için pratik bir kullanım yolu bulamadım.