 Show Posts
|
|
Pages: [1]
|
|
Haberi olmayanlar için özet:
Cem Uzan, Fransa'da; çalınan mal varlıklarına yönelik açılan davanın NFT'lerini piyasaya sürüyor. Davanın tazminatı 69 milyar dolar ve sonuçlandığında tazminat gelirinin %20'sini NFT sahiplerine eşit şekilde paylaştırılacakmış.
Whitelist'e katılım hakkım var ama elimdeki son kurşunu boşa sallamak istemiyorum. O yüzden sizlerin fikirlerini merak ediyorum.
Bu NFT projesi hakkında düşünceleriniz neler?
|
|
|
|
|
Entry sahibi fak fakir olduğundan milyon dolarları hesaba katamıyor ufak beyni ile. Bu ülke de cahil olacaksın aga, en rahat yaşam yoludur bu toplumun arasında cahil olmak. Zaten çevrende cahil olacağı için her düşüncene hee diyecekler.
|
|
|
|
Wow! Impressive; 2,700,000,001 unique xpoints?!?! How long did that take to create and what is the size of that file? How much RAM does your system have lol?!
Also, how long did it take for the program to load all of those xpoints before it started working?
I don't remember exactly, but on average: It took 5-6 hours to generate the file with keysubtructer. -rw-r--r-- 1 root root 180900000067 May 12 23:20 200.txt
Booting with keyhunt took about 3 hours. /0/4 processor Intel(R) Xeon(R) Platinum 8370C CPU @ 2
/0/6 memory 64GiB System Memory
|
|
|
|
Try BSGS mode instead of xpoint mode because in xpoint mode the search space is 2^120 not 2^60. Most likely you won't find anything in xpoint mode.
I don't quite understand what you are trying to convey. We're already looking for a ^120-bit range, how come in BSGS mode you detect a ^120-bit field as ^60-bits? Also, loading 2 billion 700 million points in BSGS mode will not be efficient. Searching for a point with the -R option will take much longer. |
|
|
|
I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man. root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] Threads : 8
[+] Mode xpoint
[+] Random mode
[+] Quiet thread output
[+] Stride : 1267650600228229401496703205376
[+] Opening file 200.txt
[+] N = 0x80000
[+] Range
[+] -- from : 0x800000000000000000000000000000
[+] -- to : 0x80000fffffffffffffffffffffffff
[+] Allocating memory for 2700000001 elements: 51498.41 MB
[+] Bloom filter for 2700000001 elements.
[+] Loading data to the bloomfilter total: 9255.29 MB
[+] Bloomfilter completed
[+] Sorting data ... done! 2700000001 values were loaded and sorted
[+] Total 2626285058048 keys in 155310 seconds: ~16 Mkeys/s (16909954 keys/s)
|
|
|
|
|
even if it were possible, it would be indistinguishable from the partition, i.e. the private key would be out of range.
|
|
|
|
|
Key# 0 [1S]Pub: 0x0230960F9F8099D13485EDE4817C4C9B88620A99F96060434E4E47B4FB07C6A73B
Priv: 0x555555555555555
|
|
|
|
Dear albertobsd,
can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68?
if we get the publickeys, the puzzles would be solved in less than minute.
Thanks in advance.
He already has that, its called pub2rmd mode its under Experimental modes https://github.com/albertobsd/keyhunt#pub2rmd-modeKeyhunt searches the whole range in pub2rmd mode. It searches in the range given in the link I shared above. |
|
|
|
|
Is this a different distance from puzzle 120? I don't quite understand, what are we going to try to decrypt this public key for?
|
|
|
|
Dear albertobsd,
can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68?
if we get the publickeys, the puzzles would be solved in less than minute.
Thanks in advance.
I just know little python and I did something like this: https://github.com/sezginyildirim91/keysubtracterIf it is adapted to the C language, it can be very productive. |
|
|
|
I already use this tool in WSL... I don't feel any trust issues. Since I don't know the C language, I can't change it according to my own opinion. I know a little Python language and if there is a Python version of it, I would like to realize a few of my ideas on it. You can not be serious? |
|
|
|
Given that the private key range is known for each puzzle, I am not sure I understand the advantage that someone will have once the public key is known.
For Pollard's Kangaroo, you need to know the public key that you're trying to match. OP was theorising that once they publish their transaction, someone could use Pollard's Kangaroo to trivially solve the private key in a matter of minutes and then publish their own transaction stealing their prize. I'm not overly familiar with the performance of this particular algorithm or the available scripts for it... but if the actual winner just disables RBF and sends with a "decent" fee, the odds of their prize being "stolen" would be pretty minimal, I would think. It was reported that one Tesla V100 can check 715 M keys per second by using bitcrack. Assuming you can get google to rent you 176k V100's, I calculate a 1 in 488 chance that you will find the private key within 5 minutes. It was reported on that same post that a V100 can make 1430 Million "kangaroo jumps" per second (about 2x as many private keys tas than it can check using bitcrack). Assuming that the scope of what needs to be searched is the same, this would give someone a 1 in 244 chance of finding the private key within 5 minutes. I am not sure how many V100 google has on its platform but 176k is a lot, but I calculate that many V100s as having a retail price of about $1.1 billion. If you spend more than 5 minutes trying to crack the private key, you will be spending more money than the value of the coin in the address. I hope this is an accurate calculation, crossword 64 and above will also minimize the suspicion that there will be a thief. |
|
|
|
|
