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

Bizim ekip 1milyon adrese bölerek yapıyoruz işlemi ortalama 21m adresin varlık kontrolunu  ortalama 10 dakikada bitirebiliyoruz

Bir dat dosyası ne kadar adres barındırabilir? (sorunsuz olarak)

Benim küme farklı olduğu için daha doğrusu aradığım adres listesi çok dar olduğu için yakınından bile geçmedi.
ama hobi maksatlı arıyoruz bakalım.

Bu 5 milyar keyden çıkan bir amorti var mı acaba merak ettim.


Bu arada keylerden sıyrılıp farklı bulmacalarla kafa soğutalım ha ne dersiniz?

Lokalde denk gelmedim, canı sıkılan denesin.
Bulan olursa profilde adresim mevcut

Kolay gelsin.


https://www.reddit.com/r/Bitcoin/comments/9kq7it/introducing_the_310_btc_bitcoin_challenge/

başlık içerisinde bakiye olan adresi nasıl sorgularım da takıldı kaldı. Herhangi bir siteden cURL UrlParser, HttpRequest vs. vs  yöntemlerle bakiye kontrolü yaparsanız en fazla arkadaşın dediği gibi 10-15 sorgudan sonra cevap gelmez, üstüne IP adresiniz de blackliste alınır.

Tavsiyem bitcoin full node çalıştıracaksınız. aynı makine üzerinde kurmayacaksanız RPC ile bağlanacaksınız. Daha sonra ürettiğiniz private keyleri bu cüzdana import edeceksiniz. Tabi üretim hızınıza bağlı olarak data şişecek. belirli aralıklarla da ürettiğiniz wallet.dat'ları bir başka depolama alanında saklayacaksınız. Şimdi birçok arkadaş " o kadar depolama alanı hayal felan diyecekler" önemli değil , çok extreme sıkıştırma algoritmaları mevcut. Onlar faydalı olabilir (henüz denemedim.)

Depolama ile ilgili bilgi sahibi arkadaşlar bizi aydınlatırlarsa çok memnun olurum .

Saygılar
imza
(Birden fazla makinede adres üreten , 5  milyar üzeri priv key'e sahip orta yaşlı eski yazılımcı )

Bu şekilde dış bir kaynaktan sorgulama yaparsanız en fazla 10 sorguya yanıt alırsınız, bir süre sonra site ddos saldırısına uğradığını düşünüp sizi bloklayacaktır.

Bunun yerine core kullanmanız daha yerinde olacaktır.

blockparser uygulamasını linux tarafında make yapabilen biri varmı yapılmış halini paylaşabilirmi tuaftır hata alıyorumda

Arkadaşlar Python öğrenmeye çalışıyorum da bir sorum olacak ustalardan ;

kod şu

bu kodla girilen adresin bakiye kontrolü yapılıyor
>>>>>>

from bs4 import BeautifulSoup
import urllib.request
 
tr = input(" Adres Girin ")
url = ("https://blockchain.info/q/addressbalance/"+tr)

url_oku = urllib.request.urlopen(url)

soup = BeautifulSoup(url_oku, 'html.parser')
 
print(soup)
print (tr)

<<<<<<<

ben burada bir txt dosyasından tr değişkenini satır satır çekmek istiyorum... (her bir satıra bir adres gelecek şekilde oluşturulmuş 10 satırlık bir txt dosyası mesala ) Bunu nasıl yapabilirim? çıktıyıda başka bir txt dosyasına yazdırmak...

tekrar okuyunca karışık yazdığımı farkettim. yanması normal. daha önce yazdığım;  sıralı, parça parça arama, sözlük, rastgele, vanitygen, adres oluşturmada tekrar var mı şeklindeki  tarama yöntemlerinden kalın yazılı olanlar ve her tarama işleminde tekrar oluşturmamak için nasıl bir yol izlediği var kısaca. birde bulduğunda ne yapıyor o yazıyor. Yoksa Allah büyükte, kulları kul değil )

ben tüm tarama yöntemlerini durdurup, tekrarlanma sistemine bakıyorum. Birde heks havuzu oluşturmaya çalışıyorum. uğraşan arkadaşlar sizde durumlar nedir?

miyav@brain:~$  make mugt_uanlamak
cc     mugt_uanlamak.c   -o mugt_uanlamak

miyav@brain:~$ ls -l mugt_uanlamak
-rwxr-xr-x 1 miyav users 8312 Eki  3 20:31 mugt_uanlamak

miyav@brain:~$ ./mugt_uanlamak

segmentation fault (core dumped)

miyav@brain:~$ exit

abi büyüksün. beynim yandı

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.