|
Ottimo il post di Plutosky, i concetti sono spiegati molto chiaramente.
Guardando alla linea rossa del suo ultimo grafico sembra che il prezzo attuale sia ancora alto rispetto alle transazioni sulla blockchain, forse quindi non è ancora il momento giusto per entrare, io ho qualche dubbio sull'attuale utilizzo di bitcoin (che mi sembra usato pochissimo tranne realtà particolari tipo quella venezuelana).
O forse il vero utilizzo del bitcoin più che nelle transazioni per acquisti sta proprio "solo" nella difesa del valore dei propri risparmi nel medio lungo periodo.
|
|
|
|
Segui la linea azzurra. Ad oggi non esiste una ragione valida e concreta per cui questo trend si debba invertire. Potrebbe succedere di tutto in questi due anni, ma ad oggi, la previsione obiettivamente più attendibile è che il prezzo segua il suo percorso lungo questa linea come ha fatto praticamente da quando esiste
Non esiste una ragione valida e concreta? Il caro vecchio e buon senso dice che nulla cresce esponenzialmente se non per "brevi" periodi iniziali, ora si può discutere se questo breve periodo finirà tra 2 anni, tra 10 o se sia finito già da 1, ma un grafico che sale ci dice solo quello che è successo nel passato, seguendo questa logica tra qualche anno un iphone costerà più di un'automobile... Il trend di crescita di lungo periodo dei fondamentali (indirizzi, transazioni, nodi, potenza di mining...) è stato finora compatibile con quello di prezzo. L'osservazione di trend parabolici simili relativi a nuove tecnologie ci dice che btc è solo agli inizi della curva S di adozione. Si stima che bitcoin sia posseduto ed usato da meno dell'1% della popolazione mondiale, a differenza degli smartphone, con margini di crescita potenziali enormi. Ha l'1% della capitalizzazione dell'oro, pur avendone molte caratteristiche di commodity e pur essendo molto più diffuso e noto dell'oro tra i millennials, che saranno la grossa fetta dei possibili investitori di domani. Potrei continuare per qualche pagina ma non vorrei annoiarvi e passare come un markettaro che invoglia all'acquisto. Bitcoin potrebbe morire domattina o morire lentamente nei prossimi 2,3,5 anni nessuno ha la sfera di cristallo ma non è questo il punto. Il punto è che la morte, lenta o veloce, non è al momento l'ipotesi più probabile. Chi ritiene che lo sia fa benissimo a venderli domattina, anche se la domanda che mi faccio sempre in questi casi è per comprare cosa, visti gli scenari a dir poco tetri che circondano l'economia mondiale, fatta di valute fiat, banche centrali, debiti pubblici e rendimenti dei titoli. Perchè nessun investimento tradizionale ha, al momento e in base alla mia personale opinione, un rischio/ricompensa di lungo periodo migliore di questa tecnologia. Ok, tu parli di curva di adozione, crescita di lungo periodo dei fondamentali e della probabilità che ci sarà una maggiore adozione di bitcoin in futuro piuttosto che una sua morte. Fermo restando che neanche io ho la sfera di cristallo, e che sarei ben contento che si avverasse lo scenario da te ritenuto più probabile, non riesco a collegare in automatico il possibile/auspicabile scenario futuro positivo con la questione dell'andamento del prezzo: come facciamo a dire che il trend di crescita dei fondamentali (supponiamo pure che continui così) non sia già stato ampiamente scontato dal livello attuale dei prezzi? A gennaio i fondamentali erano peggiori e il prezzo 5 volte superiore a quello attuale, c'è un legame così diretto tra fondamentali e prezzo? Se bitcoin verrà usato da 1 miliardo di persone, è così ovvio che il prezzo schizzerà alle stelle? E' questo che non mi sembra così scontato. La linea di tendenza da te tracciata porterebbe a 100k dollari per btc a fine 2020, solo a me paiono valori giganteschi? In pratica c'è al momento un'opportunità di investimento che con una discreta probabilità potrebbe farci fare un x25 in 2 anni, e pochi nel mondo se ne accorgono? Sto cercando solo di capire il tuo ragionamento, non sono certo esperto di questioni finanziarie. |
|
|
|
Detto questo, e per gli stessi motivi, se pensate che 20k dollari sia il vostro ATH da qui a ,diciamo, fine 2020, credo che vi sbagliate di grosso. Mi sfugge una cosa, ovvero a quanto lo vedresti tu per fine 2020  Segui la linea azzurra. Ad oggi non esiste una ragione valida e concreta per cui questo trend si debba invertire. Potrebbe succedere di tutto in questi due anni, ma ad oggi, la previsione obiettivamente più attendibile è che il prezzo segua il suo percorso lungo questa linea come ha fatto praticamente da quando esiste Non esiste una ragione valida e concreta? Il caro vecchio e buon senso dice che nulla cresce esponenzialmente se non per "brevi" periodi iniziali, ora si può discutere se questo breve periodo finirà tra 2 anni, tra 10 o se sia finito già da 1, ma un grafico che sale ci dice solo quello che è successo nel passato, seguendo questa logica tra qualche anno un iphone costerà più di un'automobile... |
|
|
|
Dovrebbero anche servire per consolidare i prezzi, in parte almeno. Ovviamente ci saranno sempre gli speculatori incalliti, ma c'è anche chi compra ora a prezzi scontati capendo quale sia vero valore a lungo termine, tra qualche anno. Poi gli alti e bassi ci saranno sempre, non può certo andare solo su  Io terrei sempre ben separati l'analisi della tecnologia e dei fondamentali da una parte dalla questione del prezzo dall'altra, per esempio se la tecnologia pur ottima alla base bitcoin venisse ripresa e superata nell'implementazione di una nuova coin, il prezzo del btc diminuirebbe pur rimanendo a livello concettuale una pietra miliare di questa rivoluzione tecnologica e di pensiero. Ma questo fatto sarebbe di magra consolazione per chi ha investito dei soldi per guadagnarci. Non credo sia possibile avere un'effettiva separazione, il sistema sta in piedi perchè viene dato un incentivo per fare in modo che funzioni correttamente. Non c'è un valore fisso di incentivo, se il prezzo di bitcoin fosse 1000 dollari i miner adeguerebbero verso il basso l'HP fornito, semplicemente il sistema sarebbe meno sicuro. Non è che non funzionerebbe correttamente. Inoltre ricordo che l'incentivo è legato in gran parte al prezzo del bitcoin solo in questa prima fase di distribuzione delle coin attraverso le ricompense dei blocchi, fra 10 anni la situazione sarà molto diversa, saranno soprattutto le fee (legate più all'uso del bitcoin e all'esigenza di transare realmente sulla blockchain che alla speculazione sul prezzo) l'incentivo per i miner. EDIT: @Sampey mi hai preceduto su quest'ultima considerazione |
|
|
|
Dovrebbero anche servire per consolidare i prezzi, in parte almeno. Ovviamente ci saranno sempre gli speculatori incalliti, ma c'è anche chi compra ora a prezzi scontati capendo quale sia vero valore a lungo termine, tra qualche anno. Poi gli alti e bassi ci saranno sempre, non può certo andare solo su La questione però è: cosa si intende per "vero valore a lungo termine" ? Perchè i prezzi attuali dovrebbero essere "scontati" (o "eccessivi"), scontati rispetto a cosa? Un conto è dire che la tecnologia è valida e ha interessanti prospettive, un altro è parlare di valore e prezzi: non potrebbe essere che il "vero valore" sia 500 dollari? Probabilmente non esiste il vero/giusto valore, perchè i prezzi comunque variano nel tempo causa speculazione da una parte e causa cambiamento dei contesti dall'altra (il mondo tra 5 / 10 anni sarà diverso dal mondo di oggi). Io terrei sempre ben separati l'analisi della tecnologia e dei fondamentali da una parte dalla questione del prezzo dall'altra, per esempio se la tecnologia pur ottima alla base bitcoin venisse ripresa e superata nell'implementazione di una nuova coin, il prezzo del btc diminuirebbe pur rimanendo a livello concettuale una pietra miliare di questa rivoluzione tecnologica e di pensiero. Ma questo fatto sarebbe di magra consolazione per chi ha investito dei soldi per guadagnarci. |
|
|
|
Can anyone explain to me the concept or link me some source that explains how can vanitygen find a pattern in an unreversible hash?
It's clearly following some search pattern that isn't just trying out random private keys and hoping to find the desired pattern. People can let it run for weeks to find a 8-char pattern for example. And it'll slowly display the probability percentage until it finds one. I'd like to know the maths behind that if anyone can give me a clue, cheers.
First you need to know how the 8 bit (byte 00) + 160 bit (ripemd160) + 32 bit (checksum) of an address are encoded in base58 : https://bitcoin.stackexchange.com/questions/48586/best-way-to-calculate-difficulty-of-generating-specific-vanity-addressYou got so far some inaccurate answers. For each 22 addresses there is an address that starts with 1A, so we say that the difficulty of the prefix 1A is 22 (= number of addresses you have to generate on average to get a match). Instead the difficulty of the prefix 11 is 256, i.e. 11xxx addresses are less than 1/10th of the 1Axxx addresses. The formula 58^n is not correct at all, because the 58 characters don't have the same chance of happening. How does vanitygen compute the probability? Let's do an example with 1A prefix. Let T be the target set of the addresses 1Axxxxx. To get on average 1 match we have to generate 22 addresses. Smaller is the target, bigger is the difficulty to hitting it and viceversa. Let me rephrase this: difficulty * size of target = search space, in our case a small difficulty and therefore a big target ( it's easy to hit this target!): 22 * 63703009616853067642911677093369144589991624155 = 2^160
number of keys we have to use (= numbers of addresses we have to generate to get on average 1 match) * number of addresses in T = 2^160 possible addresses. Every time we try a new private key, we have 1 chance over 22 to hit our target set T (the probability is 1/22). At every roll then we don't hit the set T with probability 1 - 1/22. If we use k private keys, we don't hit T with probability (21/22)^k. The probability of hitting T in k trials is then: P = 1 - (21/22)^khttps://en.wikipedia.org/wiki/Geometric_distributionThe geometric distribution gives the probability that the first occurrence of success requires k independent trials, each with success probability p. If the probability of success on each trial is p, then the probability that the kth trial (out of k trials) is the first success is
P(X=k) = p(1-p)^(k-1) for k = 1, 2, 3, ....
The cumulative distribution function is P(X<=k) = 1 - (1-p)^k (it is the probability that X will take a value less than or equal to k ).
If we want to have : a 50% chance, 1 - (21/22)^k = 0.50 --> k = log(0.50)/log(21/22) = 14.9 tries (not 11!) a 64% chance, 1 - (21/22)^k = 0.64 --> k = log(0.36)/log(21/22) = 22.0 tries a 75% chance, 1 - (21/22)^k = 0.75 --> k = log(0.25)/log(21/22) = 29.8 tries (not 11!) a 90% chance, 1 - (21/22)^k = 0.90 --> k = log(0.10)/log(21/22) = 49.5 tries a 95.5% chance, 1 - (21/22)^k = 0.955 --> k = log(0.045)/log(21/22) = 66.7 tries (3 times 22!!) a 99% chance, 1 - (21/22)^k = 0.99 --> k = log(0.01)/log(21/22) = 99 tries and so on (100% only for k -> infinity). On average it takes 22 tries to get 1 match, but if you do 22 tries only once you will have only a 64% chance to get a match! And vanitygen computes right the probability to find a match in the particular sequence you are running, vanitygen doesn't compute anything "on average". |
|
|
|
No, it would require much more than 2^80 work. Or you would require 2^80 work + a storage capable of containing a hash table of 2^80 * (256 bit + 80 bit) = 336 * 2^80 bit = 2^88.4 bit = more than 2^38 PB.
The current max size of my hash table is now 2^28 * (64 bit + 32 bit) = 96 * 2^28 bit = 2^34.58 bit = 24 GB (to store 2^28 keys in ram). It is only 1/2^54 of 2^88.4!
It is not possible to get such amount of ram in the next 40 years.
Could you go a bit more into how you get the numbers in the parentheses? You lost me there. Look at this code: https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89You need to store a list of 2^80 public keys in a hash table. For the sake of simplicity we suppose we have enough ram. Then: #define GSTEP (1<<80)
typedef struct hashtable_entry {
uint256_t x;
uint81_t exponent;
} hashtable_entry;
#define HASH_SIZE (2*GSTEP)
hashtable_entry table[HASH_SIZE];
each entry has the x coordinate (256 bit) of a public key + a exponent (a key to access faster to the entry). The exponent must be longer than the size of the list (to minimize collisions, see https://en.wikipedia.org/wiki/Hash_table), then if the list has 2^80 elements, it takes at least 81 bit for the exponent (HASH_SIZE is 2*GSTEP = 2^81). --> (81 + 256 bit)
For the #57 key instead: #define GSTEP (1<<28)
typedef struct hashtable_entry {
uint64_t x;
uint32_t exponent;
} hashtable_entry;
#define HASH_SIZE (2*GSTEP)
hashtable_entry table[HASH_SIZE];
I use 32 bit for the exponent (32 > 28) and I store only the first 64 bit of the x coordinate (there is a low chance to have a partial collision in a list of 2^28 element, i.e. two different x with the same first 64 bit) --> (64 + 32 bit) To avoid any collisions you should use always 256 bit for the x coordinate. And the size of the hash table should be at least two times the size of the list you want to store. |
|
|
|
This is correct only for BSGS (Baby-Step-Giant-Step).
Using Pollard Rho method, the expected work is 3*2^80 group operations with almost zero memory requirements.
Note that unlike BSGS this method is probabilistic, and might fail with very low probability (on the order of 2^-160).
One can improve the algorithm using Distinguished Points, bringing the expected work down to 1.253*2^80 group operations, using both less memory and less group operations (on average) than BSGS.
Pollard Rho can't exploit the fact that the private key is in the range from 1 to 2^160 for example, because it is probabilistic. It would need always 2^128 steps. Only BSGS is suitable for this task. If you try to retrieve #57 with Pollard Rho, you won't retrieve the private key in a few seconds or in a few years. With "space search is 2^160" in this context we mean a 2^160 points subset in the space of the 2^256 points of the secp256k1 curve. |
|
|
|
Sul punto 1 non posso che essere d'accordo infatti la notiziona per me è più per la novità inattesa che per la notizia in se per sè visto che io un ETF su criptovalute non lo userò mai (con dentro bcash abc poi ). Leggendo meglio comunque : le prime 3 coin per market cap saranno sempre incluse, mentre le altre due saranno scelte dal gestore tra la 4 e la 7 del ranking. Cercheranno credo di modificare la composizione delle coin il meno possibile anche se come detto se una scivola sotto la 7a posizione andrebbe per forza delistata. The index does not include crypto assets that:
• are tied to a fiat currency or a commodity such as gold or diamonds.
• are ongoing ICOs,
• have been newly created in the last twelve months, other than forks of existing assets (see further
details on our fork policy),
• are designed to be anonymous or private,
• do not trade on an eligible exchange,
• trade less than thirty-three percent of three-month circulating supply,
• trade < $25M of daily volume over past thirty days,
• have market cap below $1 billion over past thirty days,
• are not accepted as underlying assets by the Switzerland legal and regulatory bodies,
• are not accepted by the Swiss Stock Exchange (SIX) as an underlying,
• are without a reliable multi-signature hardware wallet solution,
• do not trade against a common fiat currency, i.e. USD or EUR,
• do not publish transparently (english website).Il criterio "market cap non sotto 1 miliardo di dollari negli ultimi 30 giorni", fra poco equivarrà al criterio "considero solo le prime 7 coin" (se si continua a scendere). |
|
|
|
No matter how often you roll, there's never a guarantee you'll get a 1. But you know the chance of your next roll is always 16.667%, and the more times you try, the more likely it becomes to roll a 1 eventually.
That's the classic gambler's fallacy right there... Assuming you are using "fair" dice, the chance is always 16.667%. It never increases and it never decreases, regardless of the number of rolls made. LoyceV is right. The chance of your next roll is always 16.667%, but if you try 100 times instead of 5 your chance to get 1 (once or more) will be closer to 100% (1-(5/6)^100 against 1-(5/6)^5). After n tries, P("do not get 1") = (5/6)^n --> P("get 1 once or more") = 1 - (5/6)^n, and when you increase n (n -> infinity) then P -> 1. So this sentence: the more times you try, the more likely it becomes to roll a 1 eventually.
is correct. Example: I bet you 1.000.000 $ on this game: if I roll a dice 5 times and I got 1, you give me 1.000 $, otherwise I give you 1.000.000 $. Do you think it is a fair game? And if I rolled instead the dice 1000 times would be the game the same (=same odds)? The game would be the same (from the point of view of the odds) only if after 995 rolls I didn't get a 1, then game 1 = game 2. |
|
|
|
Adesso funziona tutto end to end, proverò a leggermi i tuoi commenti per vedere se riesco a capirne un pò di più su come funziona il resto, grazie
Ok, e se riesci a trovare un modo per velocizzare il tutto fammi sapere! |
|
|
|
@arulbero
If you have the public key and the search space is 2^160 how fast can you find the private key?
It would require 2^80 work. That is just beyond what is currently feasible today. But not impossible. No, it would require much more than 2^80 work. Or you would require 2^80 work + a storage capable of containing a hash table of 2^80 * (256 bit + 80 bit) = 336 * 2^80 bit = 2^88.4 bit = more than 2^38 PB. The current max size of my hash table is now 2^28 * (64 bit + 32 bit) = 96 * 2^28 bit = 2^34.58 bit = 24 GB (to store 2^28 keys in ram). It is only 1/2^54 of 2^88.4! It is not possible to get such amount of ram in the next 40 years. |
|
|
|
@ Piggy Ho notato adesso che la tua funzione di generazione di address "controlla" che una chiave pubblica sia corretta guardando solo la lunghezza delle coordinate, non capisco che senso abbia, quindi una chiave pubblica (x,y) che soddisfa l'equazione y^2 = x^3 + 7 mod p ma ha coordinata x con meno di 64 caratteri hex non è valida? In media è ovvio che 1 chiave ogni 16 sarà lunga 63 caratteri (quindi per te non valida), 1 ogni 16^2 sarà lunga 62 caratteri (sempre non valida) e così via, mi pare normale quindi che molte chiavi ti risultino non valide. Ma perchè x = 3 (1 sola cifra) dovrebbe essere per forza non valida? In media ogni 2 valori di x (tra quelli possibili da 1 a p) corrisponde a una coordinata di un punto sulla curva. Se tu generassi tutti i 2^256 punti della curva (chiavi pubbliche) con il mio script la tua funzione classificherebbe circa 1/2 dei 2^252 valori possibili (minori di 64 cifre esadecimali) per le coordinate come non valide. Devi aggiungere degli zeri davanti alla sequenze più corte fino a raggiungere i 64 caratteri, se vuoi dare in pasto a sha256 queste chiavi pubbliche. EDIT: per chi fosse interessato alla lunghezza delle coordinate dei punti della curva secp256k1 (chiavi pubbliche), questo punto è quello con la coordinata x minore di tutti: x = 0000000000000000000000000000000000000000000000000000000000000001
y = 4218f20ae6c646b363db68605822fb14264ca8d2587fdd6fbc750d587e76a7ee
tempo fa ho provato a generare molte chiavi pubbliche ( 2^48 o giù di lì) e quella con la x minore che ho trovato (e della quale quindi conosco anche la chiave privata) è questa: x = 000000000000aeea7a7a5c04504f6e4e45452940431c9a264011686f3b746f92
mentre quella con la x minore tra quelle di cui è nota chiave privata ha la seguente x : x = 00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
ed è stata trovata da Gregory Maxwell, la storia di quest'ultimo punto è molto interessante ed è legata alla costruzione del punto G, il generatore della curva https://crypto.stackexchange.com/questions/60239/elliptic-curve-and-vanity-public-keys. |
|
|
|
Se ho capito bene come usare il codice, su 16.396.194 chiavi pubbliche pare calcolarne 331.575 non correttamente.
Il primo caso si trova prendendo le coordinate dei due punti appena calcolati dal ciclo for interno in gen_batches_points08 per:
Non l'ho mai testata bene quella libreria, era più che altro un proof of concept per realizzare poi quella in C. Grazie comunque delle osservazioni, quando avrò tempo ci darò un'occhiata, deve trattarsi di qualche bug, 1 chiave sbagliata ogni 50 è una frequenza strana. Io uso questo script da me creato per controllare gli indirizzi: python2 genadd.py 0x03
Private key : 0000000000000000000000000000000000000000000000000000000000000003
Public key : f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9 388f7b0f632de8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672
PrKey WIF u.: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB1FQ8BZ
Address u. : ec7eced2c57ed1292bc4eb9bfd13c9f7603bc338
Address u. : 1NZUP3JAc9JkmbvmoTv7nVgZGtyJjirKV1
PrKey WIF c.: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
Address c. : 7dd65592d0ab2fe0d0257d571abf032cd9db93dc
Address c. : 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
genaddy.py #!/usr/bin/env python
#genera indirizzo
import hashlib, binascii
import sys
####__ECC COMPUTATION__####################################################
Gx=0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy=0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
p=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F #caratteristica del campo
n=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 #ordine della curva
#calcola l'inverso di a modulo p --> a^-1
#a e' un numero compreso tra 1 e p-1
#p e' un numero primo
#vedi http://www.springer.com/?SGWID=4-102-45-110359-0 pag.40 algoritmo 2.20
def inv(a,p):
u, v = a%p, p
x1, x2 = 1, 0
while u != 1 :
q = v//u
r = v-q*u
x = x2-q*x1
v = u
u = r
x2 = x1
x1 = x
return x1%p
#test: stampa l'inverso di 3 modulo 7
#print inv(3,7)
def aff_to_jac(ax, ay):
jax, jay, jaz = ax, ay, 1
return jax, jay, jaz
def jac_to_aff(jax, jay, jaz):
invjaz=inv(jaz,p)
ax, ay = (jax*invjaz**2) % p, (jay*invjaz**3) % p
return ax, ay
#https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates
#coordinate jacobiane
def add(jax, jay, jaz, jbx, jby, jbz):
u1 = (jax*jbz**2) % p
u2 = (jbx*jaz**2) % p
s1 = (jay*jbz**3) % p
s2 = (jby*jaz**3) % p
h = (u2-u1) % p
r = (s2-s1) % p
jcx = (r**2 -h**3-2*u1*h**2) % p
jcy = (r*(u1*h**2-jcx)-s1*h**3) % p
jcz = (h*jaz*jbz) % p
return jcx, jcy, jcz
def double(jax, jay, jaz):
s = (4*jax*jay**2) % p
m = (3*jax**2) % p
jax2 = (m**2 - 2*s) % p
jay2 = (m*(s-jax2) - 8*jay**4) % p
jaz2 = (2*jay*jaz) % p
return jax2, jay2, jaz2
def mul(d,jax,jay,jaz):
dax, day, daz = 0, 0, 1
if (d%2 == 1):
dax, day, daz = jax, jay, jaz #solo se d e' dispari
q=d//2
while q>0:
jax, jay, jaz = double(jax,jay,jaz)
if (q%2 > dax): #puo' succedere solo se dax=0 e q%2=1 cioe' la prima volta
dax, day, daz = jax, jay, jaz #solo se d e' pari
elif (q%2):
dax, day, daz = add(jax, jay, jaz, dax, day, daz)
q=q//2
return dax, day, daz
########################################################################
# 58 character alphabet used
__b58chars = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
__b58base = len(__b58chars)
def b58encode(v): #encode v, which is a string of bytes, to base58.
long_value = 0
if bytes == str: # python2
for (i, c) in enumerate(v[::-1]):
long_value += ord(c) << (8*i) # 2x speedup vs. exponentiation
else: # python3
for (i, c) in enumerate(v[::-1]):
long_value += ord(chr(c)) << (8*i) # 2x speedup vs. exponentiation
result = ''
while long_value >= __b58base:
div, mod = divmod(long_value, __b58base)
result = __b58chars[mod] + result
long_value = div
result = __b58chars[long_value] + result
# Bitcoin does a little leading-zero-compression:
# leading 0-bytes in the input become leading-1s
nPad = 0
if bytes == str: # python2
for c in v:
if c == '\0': nPad += 1
else: break
else: # python3
for c in v:
if chr(c) == '\0': nPad += 1
else: break
return (__b58chars[0]*nPad) + result
###########################################################################
######## PRIVATE KEY #####################################
pr=int(sys.argv[1],16)
#print (pr)
print ('Private key : ' + hex(pr)[2:].rstrip('L').rjust(64,'0'))
######## PUBLIC KEY ######################################
jax, jay, jaz = mul(pr,Gx,Gy,1)
ax, ay = jac_to_aff(jax, jay, jaz)
print ('Public key : ' + hex(ax)[2:].rstrip('L').rjust(64,'0') + ' ' + hex(ay)[2:].rstrip('L').rjust(64,'0'))
####################################################################################
#### PRIVATE KEY WIF UNCOMPRESSED (start with 5, 51 car.) ##########################
#pr=int(sys.argv[1],16)
#print ('Private key : ' + '0'*(64+2-len(hex(pr))) + hex(pr)[2:])
pr_wif = '80' + hex(pr)[2:].rstrip('L').rjust(64,'0') #primo passaggio: aggiungi 80
#print (pr_wif)
pr1=binascii.unhexlify(pr_wif)
h=hashlib.new('sha256') #secondo passaggio: sha256 di 80+pr
h.update(pr1)
#print h.hexdigest()
pr2=binascii.unhexlify(h.hexdigest())
h2=hashlib.new('sha256')
h2.update(pr2) #terzo passaggio: sha256(sha256(80+pk))
#print h2.hexdigest()
pr3=pr_wif+h2.hexdigest()[:8] #quarto passaggio: aggiungere primi 4 byte del terzo passaggio a pr_wif
#print (pr3)
pr_wif=b58encode(binascii.unhexlify(pr3)) #ultimo passaggio: codifica in base 58
print (' ')
print ('PrKey WIF u.: ' + pr_wif)
###############ADDRESS UNCOMPRESSED###########################
pk = '04' + hex(ax)[2:].rstrip('L').rjust(64,'0') + hex(ay)[2:].rstrip('L').rjust(64,'0')
#pk = '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001'
pkb=binascii.unhexlify(pk)
#pkb = 'bitcoin'
h=hashlib.new('sha256') #secondo passaggio: sha256 di pk
h.update(pkb)
#print h.hexdigest()
r=hashlib.new('ripemd160') #terzo passaggio: ripmed160 di pk
r.update(h.digest())
#print r.hexdigest()
pk4='00'+r.hexdigest() #quarto passaggio: aggiungere byte 00
pk5=binascii.unhexlify(pk4) #quinto passaggio: sha256 di pk4
h2=hashlib.new('sha256')
h2.update(pk5)
#print h2.hexdigest()
h3=hashlib.new('sha256')
h3.update(h2.digest()) #sesto passaggio: sha256 di pk
#print h3.hexdigest()
pk7=pk4+h3.hexdigest()[:8] #settimo/ottavo passaggio: sha256 di pk
#print (pk7)
print ('Address u. : ' + pk7[2:-8])
address=b58encode(binascii.unhexlify(pk7)) #ultimo passaggio: codifica in base 58
print ('Address u. : ' + address)
####################################################################################
#### PRIVATE KEY WIF COMPRESSED (start with a, K or L, 52 car.) ##########################
pr_wif_c = '80' + hex(pr)[2:].rstrip('L').rjust(64,'0') +'01' #primo passaggio: aggiungi 80 e 01
#print (pr_wif_c)
pr1=binascii.unhexlify(pr_wif_c)
h=hashlib.new('sha256') #secondo passaggio: sha256 di 80+pr
h.update(pr1)
#print h.hexdigest()
pr2=binascii.unhexlify(h.hexdigest())
h2=hashlib.new('sha256')
h2.update(pr2) #terzo passaggio: sha256(sha256(80+pk))
#print h2.hexdigest()
pr3=pr_wif_c+h2.hexdigest()[:8] #quarto passaggio: aggiungere primi 4 byte del terzo passaggio a pr_wif
#print pr3
pr_wif_c=b58encode(binascii.unhexlify(pr3)) #ultimo passaggio: codifica in base 58
print ('')
print ('PrKey WIF c.: ' + pr_wif_c)
#########ADDRESS COMPRESSED##########################################
if (ay % 2) == 0:
pk = '02' + hex(ax)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
else:
pk = '03'+ hex(ax)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y dispari
#pk = '020000000000000000000000000000000000000000000000000000000000000001'
#pk = '0200000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63'
#pkb =
pkb=binascii.unhexlify(pk)
h=hashlib.new('sha256') #secondo passaggio: sha256 di pk
h.update(pkb)
#print h.hexdigest()
#print (h.hexdigest())
r=hashlib.new('ripemd160') #terzo passaggio: ripmed160 di pk
r.update(h.digest())
#print r.hexdigest()
pk4='00'+r.hexdigest() #quarto passaggio: aggiungere byte 00
pk5=binascii.unhexlify(pk4) #quinto passaggio: sha256 di pk4
h2=hashlib.new('sha256')
h2.update(pk5)
#print h2.hexdigest()
h3=hashlib.new('sha256')
h3.update(h2.digest()) #sesto passaggio: sha256 di pk
#print h3.hexdigest()
pk7=pk4+h3.hexdigest()[:8] #settimo/ottavo passaggio: sha256 di pk
#print (pk7)
print ('Address c. : ' + pk7[2:-8])
address=b58encode(binascii.unhexlify(pk7)) #ultimo passaggio: codifica in base 58
print ('Address c. : ' + address)
|
|
|
|
qui c'e' tutta lo storia di HP e prezzo.
verso meta' 2011 c'e stato un discreto calo (a occhio direi come conseguenza del calo del prezzo repentino)
altro calo (meno marcato) dopo l'halving a 25, probabilmente causato dal diminuito rendimento del mining
(in quel momento il prezzo era in fase ascendente)
lievissima flessione (ma ancora meno marcata) dopo l'halving a 12.5.
La scala logaritmica in effetti può trarre in inganno, comunque si può dire che nella storia recente del bitcoin (da quando si è un po' diffuso, fine 2013, prima l'hash power era solo quella dei singoli utenti) l'hash power è sostanzialmente sempre salito o si è preso brevi periodi di stabilità. |
|
|
|
Rimango dell'idea che sia stato solo l'aumento di prezzo del btc che abbia portato come conseguenza (non cercata da nessuno) l'aumento del compenso per i miner e di conseguenza la corsa dei miner stessi ad aumentare l'hash rate per aggiudicarsi le compense dei blocchi. Se il prezzo del btc si fermasse per molto tempo o crollasse stai pur certo che farà lo stesso anche l'HP. La sicurezza è data solo da un incentivo economico, che non è detto continui ad aumentare nel tempo.
Mi autoquoto, la HP attuale è circa la stessa di fine agosto (48 EH/s), in 2 mesi e mezzo la frenata (e crollo di oggi) del prezzo del btc sta automaticamente calmierando la crescita di potenza della rete. Se il prezzo dovesse scendere sotto i 5k e magari avvicinarsi ai 4k, per i calcoli che si faceva qualche post indietro, molti miner andrebbero in perdita e l'HP potrebbe calare bruscamente (finora non mi risulta ci siano mai stati grossi cali dell'HP). https://bitcoinwisdom.com/bitcoin/difficulty |
|
|
|
@arulbero
If you have the public key and the search space is 2^160 how fast can you find the private key?
Infeasible. More than universe age. |
|
|
|
Quali hash? Sto generando chiavi pubbliche da chiavi private, niente hash (non sto parlando di generazione di indirizzi, ma di chiavi pubbliche). Per l'aritmetica "multiprecision" è essenziale usare assembly, perchè a livello di C normale il "carry" (il riporto) non è gestito. Sommare o moltiplicare 2 numeri da 256 bit purtroppo è ben diverso da sommare o moltiplicare 2 vettori formati ciascuno da 4 elementi di 64 bit. Nell'aritmetica devi sommare prima le due cifre più a destra, poi verificare se hai fatto overflow, e poi passare alla cifre successive. Esempio con 2 cifre: (a1, a0) + (b1,b0) = c0 = a0+b0 c1 = a1 + b1 + (c0 < a0) <-- questa condizione, se vera, testimonia che a0 + b0 ha sforato per esempio: 16 + 27 cifra unità = 6 + 7 = 3 cifra decine = 1 + 2 + (3 < 6) = 4 risultato = 43 ti consiglio di dare una rapida occhiata a questo se ti interessa --> https://cryptojedi.org/peter/data/pairing-20131122.pdf pagina 8 |
|
|
|
Hi. I probably misunderstood something.
In your example #57 (first 200 bit + last 56 bit) =
0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000011101011001001011100100100000111100101 011101011000011100
HEX: 00000000000000000000000000000000000000000000000000eb25c90795d61c => 1J9zB6p4dRgyinst2eCVsyXvgYXtNhw2Y2
This is not a private key for #57
What did I miss?
I forgot '1' at the beginning of the number: last 56 bit of the private key#57: 1101011001001011100100100000111100101011101011000011100
but there are only 55 bits Correct--> last 56 bit of the private key#57: 11101011001001011100100100000111100101011101011000011100
0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000 111101011001001011100100100000111100101011101011000011100 HEX 0000000000000000000000000000000000000000000000000 1eb25c90795d61c |
|
|
|
|
Show Posts
