The private key is the private key. I am having a hard time understanding how this has anything to do with hashing or collisions, whether "fraudulent" or not, whatever that means.
If we found a private key capable of unlocking funds on a address, there would be only 2 possibilities to be sure we have found a real collision: 1) the owner of the address sends us its private key, and that key is different from ours 2) the address has already exposed its public key on the blockchain (there is a transaction from that address to another); in this case it would be trivial to verify if our public key and that public key are different or not. We could have a collision even if we don't know the other private key. In each case by "collision" we mean 2 different public keys (and then 2 different private keys) with the same hash160. |
|
|
|
If anyone can add legitimacy to those unverified collisions, please do contribute.
Nobody knows if the 3 addresses with bitcoins we found so far are collisions. Given that the probability to get a real collision so soon is very very very low, my guess is that they aren't real collision, but only addresses generated by a poor entropy source. In that cases I think we have found simply the "original" private keys used to generate that addresses. The problem is that the owners didn't show up. |
|
|
|
The overcomplete representation reduces the number of carries needed between limbs, so it makes the operations faster. The fe_add should already be more or less optimal when written in C-- it's a trivial function in part because it doesn't need to handle any carrying at all.
It's possible that some other representation might be faster yet, esp if using SIMD.
In the case of the fe_add I understand that with the overcomplete representation there are no carries (but one more addition). In the case of fe_mul? 64x64 bit = 128 bit, and a*b + c + d is always less than 2^128 already. Using the 52x52 representation, 52x52 is 104 bit (still 2 uint64), the only advantage is that a*b + c + d + f < 2^128? But there are 5x5 = 25 multiplications against 4x4 =16 multiplications. Besides there is the reduction mod p, and being p almost equal to 2^256 it seems to me that should be faster with the 4x64 bit representation. Using the 4x64 representation, it is enough to multiply the high 4 limbs of the product by 0x1000003d1 and add the result to the low 4 limbs. |
|
|
|
|
After some months of work, eventually I did a my library to implement some functions of ECC. I didn't use GMP anymore.
My purpose is only to generate as fast as possible public keys from private keys. Therefore I use consecutive private keys.
About the field operation, I did a my version of fe_mul and fe_sqr. Each field element is simply an array of 4 uint64. The performance are pretty good. I don't have a benchmark precise like AlexGR, I can say that with my mobile Intel Xeon E3-1505M v6 KabyLake I got (using only 1 core) about 16.5 M PublicKeys / s.
Reviewing the libsecp256k1 now I understand better the code. I noted that for the scalar there is a representation 4x64 bit, while for the field element only 5x52 (or 10x26). There are some safety reason or these representations make effectively faster the operations? Why there is only an asm version of the fe_mul and not of the fe_add too?
I'd like to know besides if someone know if it is possible to exploit avx instructions to speedup operations with 64 bit representation.
|
|
|
|
Quello che sa l'investitore non posso deciderlo io e non ho idea di cosa creda e, sinceramente, non mi interessa.
Io so che chi compra 1 BTC compra 1/21000000 di tutti i bitcoin, possedendo la chiave privata sarà in grado di spostare parte di questa frazione ad altri.
...
Anche BTC potrebbe azzerarsi qualora i miner decidessero di interrompere il mining ... fino ad allora il valore sarà allineato ai costi di produzione/mining per una questione economica e di protocollo che si autoregola.
Quello che pensano gli investitori in questo momento decide il prezzo molto di più di miner e protocollo che si autoregola... Ergo per capire (ammesso che sia possibile) se per esempio in questo momento sia ancora conveniente entrare o sia meglio uscire bisogna guardare anche a quello che pensa il mercato. Il valore attuale di certo non è per nulla allineato ai costi di produzione/mining, in una settimana il prezzo è passato da 10k a 17k, cosa è cambiato in quella settimana per i costi di produzione? Nulla. |
|
|
|
...
A me in questi giorni viene in mente la bolla di una ventina d'anni fa relativa alle azioni di aziende legate ad internet. ...
Io trovo una grande differenza, ora l'investitore puo' sapere esattamente cosa compra e informarsi con una ragionevole certezza, le bolle internet e diamanti e derivati sono spazzatura imposta dagli esperti finanziari che hanno l'obiettivo di sopravvivere anche a discapito degli investitori che sono solo carne da macello. La blockchain mi da fiducia e speranza e credo valga la pena vedere come si evolveranno le cose. Io holdo salvo per esigenze ma va compreso fiscalmente come agire. Può sapere esattamente cosa compra ma di fatto non lo sa. Oggi si parla di bolla proprio perchè la maggior parte dei nuovi entrati non sa cosa sta comprando e si basa solo sull'euforia della novità. Ma a dirla tutta anche chi è entrato da qualche anno come il sottoscritto non può sapere esattamente cosa ha in mano: qualche anno fa ho comprato una nuova moneta, ora mi ritrovo in mano una riserva di valore, domani chissà? Internet non era una bolla come non è una bolla la rivoluzione tecnologica alla base delle criptomonete. Da qui a dire che la criptomoneta x sia un buon investimento ce ne passa eccome. Non abbiamo nessuna idea di come valutare il "giusto" prezzo di questo asset poichè non sappiamo ancora bene che cosa sia questo nuovo asset, quindi come si può parlare di investimento ponderato? Qui tutti stiamo investendo a sensazione, neanche gli sviluppatori di Core sanno che cosa hanno per le mani, nè i miner, la realtà è che c'è moltissima confusione, quindi incertezza, ma un solo dogma: il prezzo del btc può solo salire! |
|
|
|
Calcola che la sola Apple capitalizza oltre 600 miliardi, il BTC ora è a solo 260 miliardi e tutte le cripto arrivano a 425 miliardi.
Se il bitcoin e le cripto diventano "mainstream" e attuano la rivoluzione promessa e devastante che dovranno invadendo tutta l'economia globale si parla di triliardi e triliardi di dollari!
Quindi si, credo che per il momento si salirà ancora per molto.
I prodotti della Apple sono già usati da molti milioni di persone in tutto il mondo, il btc attualmente non sarà usato neanche dall'uno per mille della popolazione. Secondo me il prezzo attuale del bitcoin sconta già la possibilità (tutta da verificarsi) che il bitcoin diventi mainstream. Non dico che questo sia impossibile, mi sembra solo che si dia quasi per scontato che accadrà. E a me non sembra affatto scontato. Se per "rivoluzione promessa" intendi che bitcoin soppianterà addirittura euro e dollari, concorderai almeno sul fatto che non si tratta di un evento così probabile? Inoltre bitcoin e le criptomonete non sono la stessa cosa: se io oggi investo pesantemente su btc e domani si afferma come moneta vincente ethereum, la rivoluzione tecnologica si è compiuta ma io ho fatto comunque un cattivo investimento. |
|
|
|
In questi ultimi giorni si sta assistendo a una crescita esponenziale del prezzo. La cosa che però più mi colpisce è l'idea che quasi tutti hanno per la quale il prezzo "deve" continuare a salire. E' opinione diffusa che, anche se nel breve termine una correzione è molto probabile, nel medio-lungo periodo il prezzo sarà "quasi sicuramente" superiore a quello attuale. Ma perchè? Io non sostengo ovviamente che non ci sia del valore nel bitcoin e nella tecnologia della blockchain, ma se parliamo di prezzi, questa sembra veramente una bolla (molto più bolla di quella di fine 2013). Nessuno sa quale possa essere il prezzo "giusto" su cui si stabilizzerà il bitcoin tra 10 anni, ma veramente vi sembrano verosimili cifre tipo 100k dollari o addirittura 1 milione di dollari per btc? Diverse persone stanno aspettando, con magari solo 1 btc, di sistemarsi per tutta la vita. Troppe illusioni. A me in questi giorni viene in mente la bolla di una ventina d'anni fa relativa alle azioni di aziende legate ad internet. Anche allora c'era una grande rivoluzione tecnologica, ma l'entusiasmo irrazionale della massa delle persone che investirono in quella rivoluzione gonfiò a dismisura i prezzi (pur restando internet un mezzo utilissimo). In questi giorni il prezzo è cresciuto grazie soprattutto a investimenti di coloro che non sanno nulla di bitcoin, ma hanno solo intuito che c'è la possibilità di guadagnarci. Ribadisco, attenzione alle trappole logico-psicologiche del tipo "il bitcoin è scarso e quindi il suo valore può solo aumentare nel tempo". Non è vero. Oppure: molti sostengono che quella attuale è una bolla ma allo stesso tempo affermano che non appena il prezzo sarà sceso (sarà "corretto" perchè quello attuale non lo sembra proprio) compreranno a mani basse, dando per scontato che il prezzo alla fine deve per forza crescere. Ma perchè? Non esiste una crescita (soprattutto di tipo esponenziale) infinita in natura. Allego un articolo che riassume le trappole psicologiche in cui si tende a cadere nei periodi delle bolle: http://www.ampcapital.com.au/article-detail?alias=/olivers-insights/november-(1)/bubbles-busts-investor-pyschology |
|
|
|
Io sto usando da un po' questo tool in python https://github.com/sr-gi/bitcoin_tools per fare il parsing degli utxo (mi serve per avere tutti gli indirizzi con bitcoin, ci vogliono circa 45 minuti). L'ultima volta che ho fatto il parsing (2 settimane fa) risultavano circa 19,5 milioni di indirizzi P2PKH con bitcoin (compresi i "dust", ovvero le quantità troppo basse per essere spostate) + circa 3 milioni di indirizzi P2SH. Serve python 2. Per utilizzare il nuovo formato del database (da Core 0.15 in poi) bisogna utilizzare la versione più aggiornata e in via di sviluppo https://github.com/sr-gi/bitcoin_tools/tree/dev . Dalla descrizione di questo programma risulta che è possibile ricavare diverse statistiche e anche grafici, ma io non ho mai utilizzato queste opzioni. L'analisi e le statistiche sono relativi solo al database degli utxo, nessuna statistica mi pare sia effettuata sui blocchi della blockchain. Pertanto questo tool non permette di ricavare il numero totale di indirizzi usati (sul quale gbianchi basava le sue analisi) ma solo il numero di indirizzi attivi. Tra l'altro sarebbe interessante, alla luce degli aumenti di prezzo degli ultimi tempi, andare a riprendere la famosa formula e vedere se, con qualche aggiustamento, essa riesce a descrivere bene l'andamento attuale del prezzo. Riporto un riassunto che avevo fatto in inglese per spiegare come utilizzare questo programma (la versione relativa al branch "master") per ricavare gli indirizzi: This is my way: 1) you need python2 (not python3) , Core 0.14.2 not running (or a version before 0.15), Linuxgit clone https://github.com/sr-gi/bitcoin_tools.git
cd bitcoin_tools
pip install -r requeriments.txt (on my system I needed to do: "sudo apt-get install libleveldb-dev" to complete this task)
cp sample_conf.py conf.py
you have to modify the conf.py, this is my conf.py: home_dir = "/home/arulbero/"
btc_core_path = "/home/arulbero/.bitcoin/"
bitcoin_tools_dir = "/home/arulbero/bitcoin_tools/"
address_vault = "/home/arulbero/bitcoin_tools/bitcoin_addresses/"
data_path = "/home/arulbero/bitcoin_tools/bitcoin_tools/data/"
figs_path = "/home/arulbero/bitcoin_tools/bitcoin_tools/figs/"
mkdir data (where the results are stored)
cd data
create this extract.py in data directory (for more details see: https://bitcoin.stackexchange.com/questions/56655/getting-a-crypto-proof-utxo-set), it is the script to extract the data from the utxo: import sys
sys.path.append('/home/arulbero/bitcoin_tools/')
sys.path.append('/home/arulbero/bitcoin_tools/bitcoin_tools/core/')
sys.path.append('/home/arulbero/bitcoin_tools/bitcoin_tools/analysis/')
sys.path.append('/home/arulbero/bitcoin_tools/bitcoin_tools/analysis/leveldb/')
from bitcoin_tools import *
from bitcoin_tools.analysis.leveldb.data_dump import utxo_dump
from bitcoin_tools.analysis.leveldb.utils import parse_ldb
f_utxos = "utxos.txt"
f_parsed_utxos = "parsed_utxos.txt"
# Parse all the data in the chainstate.
parse_ldb(f_utxos)
# Parses transactions and utxos from the dumped data.
utxo_dump(f_utxos, f_parsed_utxos)
# Data is stored in f_utxos and f_parsed_utxos files respectivaly
finally create this script address_from_utxo.sh : #! /bin/bash
python extract.py;
cat parsed_utxos.txt | grep '"out_type": 0' | awk '{ print $18 }' | sed 's/"//g' | sed 's/}//g' | sort | uniq > addresses0.hex;
#(0 means: only P2PKH output) : 1' 43'' for 17799787 addresses
cat parsed_utxos.txt | grep '"out_type": 1' | awk '{ print $18 }' | sed 's/"//g' | sed 's/}//g' | sort | uniq > addresses1.hex;
#(1 means: only P2SH output) : 23'' for 2693300 addresses
cat addresses0.hex addresses1.hex | sort | uniq > addresses.hex; #: 20''
and run it chmod +x address_from_utxo.sh
./address_from_utxo.sh
It takes about 46' to perform the entire task. I got a file "addresses.hex" with 20M addresses: less addresses.hex
...
0c13ba8939a180e7a40d78b9de00ee9ccc8dc62d
0c13bc32887255113583203570b600e0d4c4835e
0c13bd220b298398947e7ee645b159b94184ff1e
0c13be023e31606953081d8abafbaa9d05b4c139
0c13beef754c6e70ccee7d71732b75c0c7da55a3
0c13bfef9da1d0e4c05b93ca79869066f4a91e47
0c13c05c87f0a46e8905a8511760484ed61c2c25
0c13c15e4a669cf67dc4339310890dc20e6f187f
0c13c2cd431979495847a7428ba292821aa77361
0c13c2d064c853aeea1e12f284b372a283e285fe
0c13c33b5b38bc509fa4b84f4de1cae63b859f88
0c13c38a87cfe76fe2554fd170165326b323b897
0c13c452add0f4ddcbf17012db46f085cf741ae3
0c13c5446493834e892d8a2663e1b9d3c5f60d62
0c13c58c01cc4472f4e4d4acbff272aa377d8d39
0c13c5e1ed38e110dc8d05e5f3fbcc29cf8f1c8a
0c13c7263cb5aa1305c7eab11da0c934d77946df
0c13c786b27225c7ad88d20c9955ab0d1a49a23b
0c13c787552c797a1e2de1c127ed5dd7df516e24
0c13c83a83892eaf3c953f21ec1e29d13b739f39
0c13ca8a84ce21cdbe5b0bfe73302e0136a52fdb
...
In this way you can run very easily this script every week and you have a complete and updated list of address with bitcoin. Just "./address_from_utxo.sh". |
|
|
|
A number of people have raised this matter: how to read properly the FOUND.txt file? I decided to share a little python script. First we generate a FOUND.txt file to make a test: $ ./LBC -x
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly ............ keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
$ ls
FOUND.txt
....
$ more FOUND.txt
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
Then you can use this python script, called "lbc_output.py": https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0Copy the line of FOUND.TXT you are interested of and you get the result: $ ./lbc_output.py 2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
Private key : 000000000000000000000000000000000000000000000000000000000000005f
Public key :
x : 15d9441254945064cf1a1c33bbd3b49f8966c5092171e699ef258dfab81c045c
y : d56eb30b69463e7234f5137b73b84177434800bacebfc685fc37bbe9efe4070d
PrKey WIF u.: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreMQiR4w7
Address u. : 2d17543d32448acc7a1c43c5f72cd5be459ab302
Address u. : 157RMZhbBLC1wucv3jxQqqHjbKezL1yy7g
What does the script? First it reads and parses the line. Then it computes the private key (it does the addition, in our example: 0000000000000000000000000000000000000000000000000000000000000001 + 0x5e) and using the ecc arithmetic it generates the public key. Then it generates the address (compressed or uncompressed) and checks if it matches with the address in FOUND.txt (in this case 2d17543d32448acc7a1c43c5f72cd5be459ab302). Finally it provides the private key in WIF format and the address b58 encoded. |
|
|
|
We have tried it with 1 page and 1000 pages still no hit!...
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Will use 2 CPUs.
Estimated duration: 35.013005625s
oo (2.02 Mkeys/s)
Try with a wider interval: Example: $ ./LBC -c 1 -p 9512381750-9512381800
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 7.5619516875s
ooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001 + 0xf42
(1.01 Mkeys/s)
$ ./LBC -c 2 -p 9512381750-9512381800
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 3.855112625s
oo (2.86 Mkeys/s)
$ ./LBC -c 2 -p 9512381700-9512381850
Loop off! Work on blocks [9512381700-9512381850] (158 Mkeys)
Estimated duration: 11.26879075s
ooooooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001 + 0xf42
o (2.15 Mkeys/s)
As you can see, in the first case the program computes 3 'o' (3*2^24 keys, about 50.3 Mkeys) instead of 53 Mkeys. In the second case it computes only 2 'o' (2*2^24 keys, about 33.4 Mkeys) instead of 53 Mkeys. In the third case it computes 8 'o' (8*2^24 keys, about 134 Mkeys) instead of 158 Mkeys. Maybe the rounding error is < number of cpus * 2^24 keys (I'm not sure). EDIT: if you try directly with the generator: $ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f40 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f40 + 0x3
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f41 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f41 + 0x2
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f42 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f42 + 0x1
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f43 + 0
there are no problems. |
|
|
|
|
Concordo sul fatto che affermare che ciò che è raro vale in quanto raro sia sbagliato. Così come è sbagliato pensare che il valore del bitcoin alla lunga possa solo aumentare. Non è affatto detto.
Si potrebbero scoprire delle vulnerabilità strutturali che azzererebbero il valore del btc oppure semplicemente potrebbe arrivare sul mercato una nuova criptomoneta nettamente migliore e molte persone si trasferirebbero dal bitcoin a quella nuova moneta. Secondo me molti confondono il fatto che le criptomonete sono una rivoluzione con prospettive impressionanti con il fatto che il bitcoin aumenterà di valore. Una cosa non implica l'altra.
In un thread di trading è utile ribadire che non è scritto da nessuna parte che il valore di questa moneta debba aumentare nel medio-lungo periodo.
Non sono invece d'accordo sul fatto che la vera rivoluzione sia solo la blockchain. Il nuovo concetto di moneta che si ha con bitcoin e con le criptovalute più in generale non va sminuito. Che poi al momento il funzionamento di bitcoin come moneta non sia granchè è un altro discorso ancora.
|
|
|
|
I don't really get the trophy page of the LBC site. I can't see what the private key is they found. So what is the private key of the last address they found. #54?? This sentence The pool found a private key to cb66763cf7fde659869ae7f06884d9a0f879a092 (1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy) as 0x236fb6d5ad1f43. At the time of the find, there were 0.54 BTC on that address. This is #54 of the puzzle transaction.
means: private key: 0x236fb6d5ad1f43 (hex format) or KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjhHvuTMSDchRp5hktc (WIF format) address: cb66763cf7fde659869ae7f06884d9a0f879a092 (1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy in base58) from private key to address: private key: 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 public key: X = 4af4b81f8c450c2c870ce1df184aff1297e5fcd54944d98d81e1a545ffb22596 Y = 5f8151d32bd6771ea637e2c8328097d49d2498c3ddd4c76a81f2bad58944cd public key: 034af4b81f8c450c2c870ce1df184aff1297e5fcd54944d98d81e1a545ffb22596 (compressed format) ripemd160(sha256(public key)) = address = cb66763cf7fde659869ae7f06884d9a0f879a092 |
|
|
|
Rico, can you tell about 160 key space?? U mean addresses wich begins with 0a-b - 01-9? or 00 or 000 ?
160 space is the space of the first 2^160 private keys (from 1 to 2^160). What you mean with: "it is into 60 field of 90?" |
|
|
|
keys per day: 17.36 tn Per provarne 2^54, il numero di giorni supera i 1000, poi ovviamente se la potenza di calcolo dedicata aumenta nel frattempo, il tempo necessario si riduce di conseguenza. Alla velocità attuale di 240 tn al giorno, in massimo altri 39 giorni verrà individuata la chiave numero 54! https://lbc.cryptoguru.org/stats |
|
|
|
Pool has 1.2 Gkeys/s already.
The "one week before bit boundary" was exactly this. You can never know when you are "just one week before the bit boundary".
Interestingly, if Unknownhostname overdoes it, he will not be eligible for LBC Pot distribution himself.
If it were so, at the moment there would be only a few people currently active that could get the LBC Pot (at least in the top 30, from what I can see). And besides, If we could mantain a 1.5 Gkeys/s speed for 1 year, we would find #54, #55 and #56 by the end of 2018. EDIT: now we are almost at 2 Gkeys/s, #54 by the end of this year!  And we will hit the next bit boundary in less than 4 days! At this speed, in the next 50 days we will generate as many addresses as we have been generating from the beginning of this project so far. |
|
|
|
|
Show Posts
