C'e' un motivo per il quale hai moderato il 3d?
Dopo il thread nel quale avevo avuto interventi del tipo "mi aiuti a ricavare la chiave privata da quella pubblica?" preferisco mantenere un minimo di controllo almeno sui miei thread, così alleggerisco anche il lavoro dei moderatori del forum. Al momento comunque non mi è mai capitato di eliminare messaggi altrui. |
|
|
|
A questo punto uno potrebbe dire ma perchè usare la libreria mini_ecdsa già fatta invece di costruirne una da zero? D'altra parte abbiamo fatto tanta teoria, cerchiamo quindi di costruire da zero una libreria molto succinta, che fa l'essenziale (non nel modo più veloce possibile), quindi la chiameremo micro_ecdsa. Cerchiamo di renderla inoltre compatibile sia con python2 che con python3 e andiamo infine a riadattare anche lo script signmsg.pyLo scopo è imparare in profondità i meccanismi di funzionamento e costruire una libreria più snella possibile da studiare (circa 40 200 righe con l'aggiunta di cose extra rispetto all'algoritmo ECDSA) La libreria micro_ecdsaPer costruire una libreria da importare poi in altri script python è sufficiente creare un file con suffisso ".py" contenente le definizioni delle funzioni che ci servono. Nel nostro caso costruiamo un file micro_ecdsa.py da tenere nella stessa directory degli script che dovranno utilizzare questa libreria. Iniziamo: PARAMETRI DELLA CURVA SECP256K1 p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F #caratteristica del campo
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 #ordine della curva
ADDIZIONE TRA 2 PUNTI DELLA CURVA A + B -> C ( formula) def add(ax, ay, bx, by):
bxax_inv = pow(bx-ax, p-2, p) # 1/(x2-x1)
m = ( (by-ay) * bxax_inv ) % p # m = (y2-y1)/(x2-x1)
cx = (m * m - ax - bx) % p # x3 = m^2 - x1 -x2
cy = (m * (ax - cx) - ay) % p # y3 = m*(x1 - x3) - y1
return cx, cy
RADDOPPIO DI UN PUNTO DELLA CURVA A -> 2*A ( formula) def double(ax, ay):
due_inv = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffff7ffffe18 #1/2 modulo p
ay_inv = pow (ay, p-2, p) # 1/y
m = ((3 * due_inv) % p ) * (ax * ax * ay_inv % p) % p # m = 3x^2/2*y
aax = (m * m - 2* ax) % p # x_2a = m^2 - 2x
aay = (m * (ax - aax) - ay) % p # y_2a = m*(x - x_2a) -y
return aax, aay
MOLTIPLICAZIONE DI UNO SCALARE QUALSIASI PER UN PUNTO DELLA CURVA d , A --> d*A l'idea: 25 * A significa A+A+A+....A venticinque volte (sarebbe molto oneroso fare ripetutamente tutte le addizioni necessarie, soprattutto considerando che lo scalare d, la chiave privata, di solito è dell'ordine di 2^256, 2^256 addizioni sono un'infinità !!!) Allora si decompone semplicemente 25 nella sua rappresentazione binaria 11001 (1*2^4 + 1*2^3 + 1*2^0): questo vuol dire che devo fare solo 3 -1 addizioni (quelle relative agli 1 presenti - 1) e 4 raddoppi (in generale dovrò fare al massimo 255 raddoppi e 255 addizioni tra punti della curva, in media 255 raddoppi e 127 addizioni) def mul(d,ax,ay):
dax, day = 0, 0
if (d%2 == 1):
dax, day = ax, ay #solo se d e' dispari
q=d//2
while q>0:
ax, ay = double(ax,ay)
if (q%2 > dax): #puo' succedere solo se dax=0 e q%2=1 cioe' la prima volta
dax, day = ax, ay #solo se d e' pari
elif (q%2):
dax, day = add(ax, ay, dax, day)
q=q//2
return dax, day
Sarebbe comodo avere anche un paio di funzioni per : 1) generare da una chiave privata il suo address 2) poter importare una chiave privata in formato WIF (di solito è quello il formato nel quale si ottiene dai wallet, una stringa anzichè un numero) Quindi, pur non facendo parte a rigor di logica della curva ellittica e dell'algoritmo ECDSA, le aggiungiamo: DALLA CHIAVE PRIVATA ALL'ADDRESS def priv_to_addr(d,compressed): #prende in input una chiave privata in formato esadecimale,
#restituisce in output una stringa contenente l'address corrispondente
#vedi https://gobittest.appspot.com/Address
#vedi https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc#bitcoin-addresses
Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
Px, Py = mul(d,Gx,Gy) # P = d*G
if (compressed == 1):
if (Py % 2) == 0:
P_string = '02' + hex(Px)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
else:
P_string = '03' + hex(Px)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
else: #uncompressed
P_string = '04' + hex(Px)[2:].rstrip('L').rjust(64,'0') + hex(Py)[2:].rstrip('L').rjust(64,'0')
h = sha256(a2b_hex(P_string)).digest() #sha256
h1 = hashlib.new('ripemd160') #ripmed160
h1.update(h)
a = b'\x00' + h1.digest() #aggiunge byte 00 all'inizio
h2 = sha256(sha256(a).digest()).digest() #doppio sha256 per controllo
addr = a + h2[:4]
address = b58encode(addr) #ultimo passaggio: codifica in base 58
return address
CHIAVE PRIVATA: DAL FORMATO WIF (STRINGA) A NUMERO def wif_to_hex(k,compressed): #prende in input una chiave privata in formato WIF (string),
#restituisce in output la chiave privata come numero (long)
#https://gobittest.appspot.com/PrivateKey
a = b58decode(k, compressed + 37) # decodifica --> stringa di byte
version = a[0]
checksum = a[-4:]
b = a[:-4] # Version plus hash160 is what is checksummed
if (compressed == 1):
key = b[1:-compressed] # elimina primo byte e l'ultimo (compressed)
else:
key = b[1:] # elimina solo primo byte (uncompressed)
h = sha256(sha256(b).digest()).digest()
if h[0:4] == checksum :
c = b2a_hex(key) # da stringa di byte a stringa di caratteri esadecimali
d = int(c, 16) # trasforma una stringa in un numero
return d
else:
print ("Errore: l'indirizzo non e' valido!")
exit()
In più ci saranno altre due funzioni ausiliarie che servono per la codifica/decodifica in base58 (dal momento che sia gli address bitcoin che le chiavi private in formato wif usano quella codifica; queste 2 funzioni relative alla base58 le ho prese da qui https://bitcointalk.org/index.php?topic=1026.msg12557#msg12557 e https://github.com/stequald/bitcoin-sign-message/blob/master/signmessage.py#L125 , la funzione di decodifica ho dovuto integrarla rispetto all'originale per renderla compatibile con python3) Mettiamo quindi tutto insieme: MICRO_ECDSA.PY import hashlib #se non c'e'ripemd160 nel tuo sistema --> https://stackoverflow.com/questions/42601709/hashlib-cant-find-ripemd160
from hashlib import sha256
from binascii import a2b_hex, b2a_hex
import struct #per la conversione di un intero in byte
p=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F #caratteristica del campo
n=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 #ordine della curva
def inv(a,k): #a --> a^-1 mod k
u, v = a%k, k
x1, x2 = 1, 0
while u != 1 :
#q = v//u
#r = v-q*u
q, r = divmod(v,u)
x = x2-q*x1
v = u
u = r
x2 = x1
x1 = x
return x1%k
def add(ax, ay, bx, by): #A + B -> C
bxax_inv = inv(bx-ax, p) #1/(x2-x1)
m = ( (by-ay) * bxax_inv ) % p #m = (y2-y1)/(x2-x1)
cx = ( m*m - ax - bx) % p
cy = (m * (ax - cx) - ay) % p
return cx, cy
def double(ax, ay): #A --> 2*A
due_inv = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffff7ffffe18 #1/2 modulo p
ay_inv = inv(ay, p) # 1/y
m = ((3 * due_inv) % p ) * (ax * ax * ay_inv % p) % p # m = 3x^2/2*y
aax = (m * m - 2* ax) % p # x_2a = m^2 - 2x
aay = (m * (ax - aax) - ay) % p # y_2a = m*(x - x_2a) -y
return aax, aay
def mul(d,ax,ay):
dax, day = 0, 0
if (d%2 == 1):
dax, day = ax, ay #solo se d e' dispari
q=d//2
while q>0:
ax, ay = double(ax,ay)
if (q%2 > dax): #puo' succedere solo se dax=0 e q%2=1 cioe' la prima volta
dax, day = ax, ay #solo se d e' pari
elif (q%2):
dax, day = add(ax, ay, dax, day)
q=q//2
return dax, day
###########################################################################################
#Funzioni legate agli address
#Generazione di un address a partire da una chiave privata + codifica in base58
#formato wif per le chiavi private
# vedi --> https://github.com/stequald/bitcoin-sign-message/blob/master/signmessage.py#L125
# --> https://bitcointalk.org/index.php?topic=1026.msg12557#msg12557
# 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
def b58decode(v, length):
""" decode v into a string of len bytes."""
long_value = 0
for (i, c) in enumerate(v[::-1]):
long_value += __b58chars.find(c) * (__b58base**i)
div, mod = divmod(long_value, 256)
result = struct.pack("B", mod) #converte numero intero tra 0 e 255 in 1 byte https://docs.python.org/2/library/struct.html
long_value = div
while long_value >= 256:
div, mod = divmod(long_value, 256)
result = struct.pack("B", mod) + result #stringa di byte
long_value = div
result = struct.pack("B", long_value) + result
nPad = 0
for c in v:
if c == __b58chars[0]: nPad += 1
else: break
result = struct.pack("B", 0)*nPad + result
if length is not None and len(result) != length:
return None
return result
def priv_to_addr(d,compressed): #prende in input una chiave privata in formato esadecimale,
#restituisce in output una stringa contenente l'address corrispondente
# vedi https://gobittest.appspot.com/Address
# vedi https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc#bitcoin-addresses
Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
Px, Py = mul(d,Gx,Gy) # P = d*G
if (compressed == 1):
if (Py % 2) == 0:
P_string = '02' + hex(Px)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
else:
P_string = '03' + hex(Px)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
else: #uncompressed
P_string = '04' + hex(Px)[2:].rstrip('L').rjust(64,'0') + hex(Py)[2:].rstrip('L').rjust(64,'0')
h = sha256(a2b_hex(P_string)).digest() #sha256
h1 = hashlib.new('ripemd160') #ripemd160
h1.update(h)
a = b'\x00' + h1.digest() #aggiunge byte 00 all'inizio
h2 = sha256(sha256(a).digest()).digest() #doppio sha256 per controllo
addr = a + h2[:4]
address = b58encode(addr) #ultimo passaggio: codifica in base 58
return address
def wif_to_hex(k,compressed): #prende in input una chiave privata in formato WIF (string),
#restituisce in output la chiave privata come numero (long)
#https://gobittest.appspot.com/PrivateKey
a = b58decode(k, compressed + 37) # decodifica --> stringa di byte
version = a[0]
checksum = a[-4:]
b = a[:-4] # Version plus hash160 is what is checksummed
if (compressed == 1):
key = b[1:-compressed] # elimina primo byte e l'ultimo (compressed)
else:
key = b[1:] # elimina solo primo byte (uncompressed)
h = sha256(sha256(b).digest()).digest()
if h[0:4] == checksum :
c = b2a_hex(key) # da stringa di byte a stringa di caratteri esadecimali
d = int(c, 16) # trasforma una stringa in un numero
return d
else:
print ("Errore: l'indirizzo non e' valido!")
exit()
Possiamo così aggiornare anche lo script sign_msg.py (150 righe, molte di commenti) con le seguenti novità: 1) utilizza la libreria micro_ecdsa anzichè mini_ecdsa 2) funziona sia con python2 che python3 4) può importare la chiave privata in formato wif (stringa) anzichè hex (numero) 5) implementa un paio di controlli (per esempio verifica che l'indirizzo fornito sia compatibile con la chiave privata che si usa per firmare) 6) controlla la lunghezza di r e s aggiungendo eventuali zeri per mantenere 32 byte + 32 byte 7) prima della stampa finale fa una verifica autonoma sulla correttezza del risultato trovato 8 ) nella libreria micro_ecdsa è stata aggiunta una funzione 'inv' che calcola l'inverso di un elemento in un gruppo finito in modo più efficiente (si vedano nell'ultimo paragrafo intitolato teoria dei campi finiti i link relativi all'identità di Bezout e all'algoritmo che implementa la procedura per trovare l'inverso) SIGN_MSG.PY #!/usr/bin/env python
from micro_ecdsa import add, mul, inv, priv_to_addr, wif_to_hex
from hashlib import sha256
from binascii import a2b_hex, b2a_hex, b2a_base64
import subprocess #se si vuole generare k casualmente con /dev/urandom
#DATI DA IMPOSTARE MANUALMENTE
msg = 'Ciao oggi 31 dicembre 2018 sto provando a firmare un messaggio' #inserire qui il messaggio scelto
#d = 0xd02e0eb2ef0ce08168fe746b58a91d485be97e71d2e2061f7807248a739f68d2 #inserire qui la propria chiave privata in formato hex
#oppure
d = 'L4CPJpu97pDVe3dscT6V6UJ4c68eENqHRhZGW39sYzjQf1WaLQX5' #inserire qui la propria chiave privata in formato WIF come stringa
address = '1FWBBmKhoPu3f6EZPhA6QiqTKoyz7Gj5CC'
compressed = 1 #se e' compresso segnare 1, altrimenti 0
if (type(d) == str):
d = wif_to_hex(d,compressed) #dal formato wif al numero + controllo validita' del formato della chiave
verifica = 0 #0 se non ti interessa, 1 per attivarla (la verifica rende molto piu' lenta tutta l'operazione)
verifica_online = 0
########################################################################################################################
#DATI CURVA SECP256K1
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F #caratteristica del campo
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 #ordine della curva
Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
#CONTROLLO CHE LA CHIAVE PRIVATA d CORRISPONDA ALL'ADDRESS FORNITO
address2 = priv_to_addr(d, compressed)
#assert address2 == address, "Errore! L'address fornito non coincide con la chiave privata!"
if(address2 != address):
print ("Errore! L'address fornito non coincide con la chiave privata!\n")
exit()
#CHIAVE PRIVATA USA E GETTA E RELATIVA CHIAVE PUBBLICA (qui si setta la prima parte della firma, r)
# di per se' k puo' essere completamente random
# oppure va calcolato cosi' --> https://tools.ietf.org/html/rfc6979#section-3.3'
#k = 0x890e92faef7387295984abe9d583eb269bba942077f29b227c825788e13fe9be
k = subprocess.Popen(['hexdump', '-n', '32', '-e','8/4 "%08X"', '/dev/urandom'], stdout=subprocess.PIPE).communicate()[0]
k = int(k,16) #trasforma una stringa in un numero, se si vuole si puo' inserire qui a mano un altro valore
assert (k % n) != 0, "Che incredibile sfortuna! k trovato non e' accettabile!" #k non dev'essere ne' 0 ne' n
k = k % n #non strettamente necessario
Qx, Qy = mul(k,Gx,Gy) # Q = k*G
assert (Qx % n) != 0, "Che incredibile sfortuna! Qx trovato non e' accettabile!" #Qx non dev'essere ne' 0 ne' n
if (Qx < n):
r = Qx
i = 0;
else:
r = Qx - n;
i = 2;
if (Qy%2 == 1):
i = i+1;
if (compressed == 0):
i = i + 27
else:
i = i + 31
#per il significato di i si veda https://bitcoin.stackexchange.com/questions/38351/ecdsa-v-r-s-what-is-v
#FORMATTAZIONE MESSAGGIO
msg_formattato = "\x18Bitcoin Signed Message:\n" + chr( len(msg) ) + msg
e = sha256(sha256(msg_formattato.encode('utf-8')).digest()).digest()
e = int(b2a_hex(e),16) #trasforma una stringa di byte in un numero
#FIRMA DEL MESSAGGIO
#(firmare vuol dire trovare a partire da r casuale un valore s che dimostri di possedere la chiave privata d;
#il valore s dipende ovviamente sia dalla chiave privata d che dal messaggio e)
k_inv = inv(k,n)
s = k_inv * (r * d + e) % n
#VERIFICA prima di codificare la firma e stamparla a video insieme al messaggio,
#verifichiamo che la firma corrisponda effettivamente all'indirizzo bitcoin (e quindi alla chiave privata)
#in nostro possesso
if (verifica == 1):
# calcoliamo P2 = r^-1 * (s*Q -e*G)
# calcoliamo P = d*G
# verifichiamo che P = P2 prima di procedere
r_inv = inv(r,n)
ax, ay = mul((r_inv * s) % n, Qx, Qy) #r^-1*s*Q
e = e % n
bx, by = mul((r_inv * (n-e)) % n, Gx, Gy) #-r^-1*e*G = r^-1*(n-e)*G
P2x, P2y = add(ax,ay,bx,by) #r^-1*(s*Q - e*G)
Px, Py = mul(d,Gx,Gy)
if (Px != P2x) or (Py != P2y):
print ("Errore! La firma trovata non e' corretta!\n")
exit()
#CODIFICA DELLA FIRMA IN BASE 64
#per fare le cose bene controlliamo che sia r che s siano formati da 64 cifre esadecimali,
#in caso contrario aggiungiamo degli zeri all'inizio della stringa che rappresenta il numero;
#la codifica della firma di un messaggio consiste sempre in una sequenza di 65 byte,
#mentre nel caso delle firme delle transazioni bitcoin si usa la codifica DER
#vedi https://bitcoin.stackexchange.com/questions/12554/why-the-signature-is-always-65-13232-bytes-long
#e https://bitcointalk.org/index.php?topic=653313.0
# https://github.com/bitcoin/bitcoin/pull/13666
r_string = hex(r)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
s_string = hex(s)[2:].rstrip('L').rjust(64,'0') #formato compresso - caso y pari
sig = b2a_base64( a2b_hex( hex(i)[2:] + r_string + s_string ) )
sig = sig.decode('utf-8')[:-1]
#per il significato di i si veda https://bitcoin.stackexchange.com/questions/38351/ecdsa-v-r-s-what-is-v
#STAMPA RISULTATO FINALE
print ('')
print ('-----BEGIN BITCOIN SIGNED MESSAGE-----')
print (msg)
print ('-----BEGIN SIGNATURE-----')
print (address)
print (sig)
print ('-----END BITCOIN SIGNED MESSAGE-----')
print ('')
#VERIFICA ONLINE
if (verifica_online == 1):
print ('Verifica qui --> ')
msg2 = msg.replace(' ','%20')
print ('http://brainwalletx.github.io/#verify?vrAddr=' + address + '&vrMsg=' + msg2 + '&vrSig=' + sig)
print ('')
Se non l'avete già fatto, ora che siete in grado di firmare un messaggio con un vostro indirizzo bitcoin fatelo e poi andate qui e lasciate una testimonianza che colleghi il vostro nick a quell'indirizzo. Fatelo come buon proposito di inizio anno! |
|
|
|
Continuo il thread iniziato qui: https://bitcointalk.org/index.php?topic=1339031.0Vediamo come firmare un messaggio qualsiasi con la chiave privata di un indirizzo bitcoin. Esempio pratico di firma di un messaggio e verifica utilizzando l'algoritmo ECDSA applicato alla curva secp256k1Firma di un messaggioRicordo brevemente l'algoritmo di firma: Let (r,s) be the signature, m the message, e = H(m) the message digest, G the curve generator, d the private key, P=d*G the public key.
ECDSA works this way:
1) pick a random nonce k (a private key you use once) in [1,n-1]
2) k -> k*G = Q(xq,yq) then r = xq mod n (r is more or less like the x coordinate of Q)
3) s = k^-1 * (r*d + e) mod n
---------------------------------------------------------------------------------------------------------------- Premessa tecnica: 1) utilizzo per iniziare python 2 in modalità interattiva, poi passeremo allo script quindi >>> prompt python ~$ prompt shell 2) python è in grado di gestire operazioni tra numeri molto grandi senza problemi, anche modulo n per quanto riguarda invece il calcolo tra punti della curva è necessario avvalersi di una libreria, in questa prima parte ci avvaliamo di una libreria "mini_ecdsa" (non scritta da me) ad uso didattico, in seguito ne scriveremo una da zero per scaricarla : git clone https://github.com/qubd/mini_ecdsa.gitper utilizzarla : quando si è entrati in modalità interattiva, execfile('mini_ecdsa.py') (con il percorso relativo corretto) 3) la parte più rognosa per me è stata la manipolazione delle stringhe e le varie codifiche, per usare correttamente sha256 e le varie conversioni tra ascii e altri formati binari bisogna importare 2 altre librerie, "hashlib" e "binascii" ------------------------------------------------------------------------------------------------------------------- Dati iniziali: MESSAGGIO DA FIRMARE >>>import hashlib
>>>import binascii
>>>
>>>msg = 'Ciao oggi 31 dicembre sto provando a firmare un messaggio'
>>>
>>>msg_formattato = "\x18Bitcoin Signed Message:\n" + chr( len(msg) ) + msg
>>>
>>>e = hashlib.sha256(hashlib.sha256(msg_formattato).digest()).digest()
>>>print binascii.b2a_hex(e)
5ae332695b7d534336b1245b720a771cb4eeaefd3d53583aad108327de30a38c
PARAMETRI DELLA CURVA SECP256K1 >>>execfile('mini_ecdsa.py')
>>>
>>>p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F #caratteristica del campo
>>>n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 #ordine della curva
>>>C = CurveOverFp(0, 0, 7, p)
y^2 = x^3 + 7 over F_115792089237316195423570985008687907853269984665640564039457584007908834671663
>>>G = Point(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) #generatore del gruppo dei punti della curva
GENERAZIONE CHIAVE PRIVATA - CHIAVE PUBBLICA - INDIRIZZO ~$ hexdump -n 32 -e '8/4 "%08X" 1 "\n"' /dev/urandom
D02E0EB2EF0CE08168FE746B58A91D485BE97E71D2E2061F7807248A739F68D2
>>>d = 0xd02e0eb2ef0ce08168fe746b58a91d485be97e71d2e2061f7807248a739f68d2 (la chiave privata generata mediante urandom)
>>>P = C.mult(G,d) # P = d*G
>>> print P
(56648515016038393520262952982723707918005872252984079682254662011250519474519,34439720842813318822435587706376241065257505597204067160331538221043835853710)
>>>xp = 56648515016038393520262952982723707918005872252984079682254662011250519474519
>>>yp = 34439720842813318822435587706376241065257505597204067160331538221043835853710
>>> print hex(xp)
0x7d3dec5b3f7bda2eacaa48dfadee6922c741771463b60ce5586371842afe8157L
>>> print hex(yp)
0x4c2430f3c7fd57de7ede4e2723558e804f59c4930ac9023afa0c816fe5c5db8eL
>>>address_compressed = '1FWBBmKhoPu3f6EZPhA6QiqTKoyz7Gj5CC'
GENERAZIONE CHIAVE PRIVATA USA E GETTA - CHIAVE PUBBLICA ~$ hexdump -n 32 -e '8/4 "%08X" 1 "\n"' /dev/urandom
890E92FAEF7387295984ABE9D583EB269BBA942077F29B227C825788E13FE9BE
>>>k = 0x890e92faef7387295984abe9d583eb269bba942077f29b227c825788e13fe9be (chiave privata usa e getta)
>>> Q = C.mult(G,k) # Q = k*G
>>> print Q
(84999791795797315190007927603153314605480098556488635859498606522553519770078,13375324783711542103436223255037217772249325984154197258846945690589726740778)
>>> xq = 84999791795797315190007927603153314605480098556488635859498606522553519770078
>>> print hex(xq)
0xbbec2d615c78aa43815c618648897518ca36904e2bcd1b7950da9819c53709de
Riassumendo i dati fondamentali: e = 0x5ae332695b7d534336b1245b720a771cb4eeaefd3d53583aad108327de30a38c (doppio hash del messaggio)
d = 0xd02e0eb2ef0ce08168fe746b58a91d485be97e71d2e2061f7807248a739f68d2 (chiave privata)
P = (0x7d3dec5b3f7bda2eacaa48dfadee6922c741771463b60ce5586371842afe8157, 0x4c2430f3c7fd57de7ede4e2723558e804f59c4930ac9023afa0c816fe5c5db8e)
k = 0x890e92faef7387295984abe9d583eb269bba942077f29b227c825788e13fe9be (chiave privata usa e getta)
Q = (0xbbec2d615c78aa43815c618648897518ca36904e2bcd1b7950da9819c53709de, 0x1d922a618d45e1ba97a4cc0bb53598b73ad408c9cb728d302b2987dab2cf912a)
La firma di questo messaggio consiste in una coppia di valori 'r' e 's', entrambi devono essere compresi tra 1 e n-1. r è uguale a xq mod n, e poichè in questo caso xq < n, i due valori coincidono: r = 0xbbec2d615c78aa43815c618648897518ca36904e2bcd1b7950da9819c53709de
s è uguale a k^-1 * (r*d + e) mod n >>>k_inv = pow(k, n-2, n) #qui si sfrutta il teorema di Fermat per il quale se n è primo allora a^n = a --> a^(n-1) = 1 --> a^(n-2) = 1/a mod n
>>>
>>>s = k_inv * (r * d + e) % n
>>>print hex(s)
0x5c40b6ed461d4c1856595432f126050fde4eefd7ab6135bbc2edaf536abe237dL
Abbiamo ottenuto quindi la firma: r = 0xbbec2d615c78aa43815c618648897518ca36904e2bcd1b7950da9819c53709de
s = 0x5c40b6ed461d4c1856595432f126050fde4eefd7ab6135bbc2edaf536abe237d
Questi valori vanno codificati in base64: >>>r_string = hex(r)[2:-1] #eliminiamo 0x iniziale e L (long) finale
>>>s_string = hex(r)[2:-1]
>>>
>>>print r_string #di per sè bisognerebbe anche controllare che il numero di caratteri sia sempre 64
bbec2d615c78aa43815c618648897518ca36904e2bcd1b7950da9819c53709de
>>>
>>> s_string = hex(s)[2:-1]
>>> print s_string
5c40b6ed461d4c1856595432f126050fde4eefd7ab6135bbc2edaf536abe237d
>>>
>>>i=0
#questo parametro i è 0 se xq < n e yq è pari, è 1 se xq < n e e yq è dispari, è 2 se xq >= n e yq è pari, è 3 se xq >= n e yq è dispari
#l'unico carattere da premettere a r e s nella firma finale è chr(27+i) se si sta usando un address non compresso,
#chr(31+i) se invece si sta usando un address compresso
>>>sig = binascii.b2a_base64( chr(31+i) + binascii.a2b_hex(r_string) + binascii.a2b_hex(s_string) )
>>> print sig
H7vsLWFceKpDgVxhhkiJdRjKNpBOK80beVDamBnFNwneXEC27UYdTBhWWVQy8SYFD95O79erYTW7wu2vU2q+I30=
Ottenuta la firma codificata in base 64 H7vsLWFceKpDgVxhhkiJdRjKNpBOK80beVDamBnFNwneXEC27UYdTBhWWVQy8SYFD95O79erYTW7wu2 vU2q+I30=se vogliamo verificare online la correttezza di questo messaggio possiamo farlo così: -----BEGIN BITCOIN SIGNED MESSAGE-----
Ciao oggi 31 dicembre sto provando a firmare un messaggio
-----BEGIN SIGNATURE-----
1FWBBmKhoPu3f6EZPhA6QiqTKoyz7Gj5CC
H7vsLWFceKpDgVxhhkiJdRjKNpBOK80beVDamBnFNwneXEC27UYdTBhWWVQy8SYFD95O79erYTW7wu2vU2q+I30=
-----END BITCOIN SIGNED MESSAGE-----
Effettivamente risulta verificato! Se non siamo soddisfatti da questo tipo di verifica esterna e ne vogliamo realizzare una interna possiamo procedere così: innanzitutto ricordiamo la teoria: poichè s = k^-1 * (r*d + e) mod n si ha che k = s^-1*r*d + s^-1*e k*G = s^-1*r*d*G + s^-1*e*G Q = s^-1*r*P + s^-1*e*G (poichè k*G = Q e d*G = P, P è la chiave pubblica) di solito questa è la verifica che si fa quando si invia la chiave pubblica P. Quando si invia invece l'address come nel nostro caso si ricava invece autonomamente la chiave pubblica dalla firma e dal messaggio, supponendo valida la relazione precedente si ha che: s*Q = r*P + e*G da cui si ottiene che P = r^-1 * (s*Q - e*G)quindi una volta ottenuto la chiave pubblica P possiamo controllare che l'address generato sia effettivamente quello proposto (ovvero la chiave pubblica sia quella giusta) >>> A = C.mult(Q,s) #s*Q
>>> B = C.mult(G,n-e) #-e*G
>>> R = C.add(A,B) #s*Q - e*G
>>> P = C.mult(R,pow(r,n-2,n)) #r^-1 * (s*Q - e*G)
>>> print P
(56648515016038393520262952982723707918005872252984079682254662011250519474519,34439720842813318822435587706376241065257505597204067160331538221043835853710)
effettivamente abbiamo ritrovato la chiave pubblica di partenza, se generiamo l'address compresso da questa chiave pubblica si ottiene il nostro indirizzo di partenza. SCRIPT PYTHON (funziona solo con python2 e mancano diversi controlli sulla lunghezza delle stringhe ma più avanti c'è una versione più completa che funziona anche con python3) Riassumendo l'intero discorso, condensiamo tutto in uno script sign_msg.py : #!/usr/bin/env python
execfile('mini_ecdsa.py') #https://github.com/qubd/mini_ecdsa
import hashlib, binascii
import subprocess #se si vuole generare k casualmente con /dev/urandom
#DATI DA IMPOSTARE MANUALMENTE
msg = 'Ciao oggi 31 dicembre sto provando a firmare un messaggio' #inserire qui il messaggio scelto
d = 0xd02e0eb2ef0ce08168fe746b58a91d485be97e71d2e2061f7807248a739f68d2 #inserire qui la propria chiave privata
address = '1FWBBmKhoPu3f6EZPhA6QiqTKoyz7Gj5CC'
compressed = 1 #se e' compresso segnare 1, altrimenti 0
########################################################################################################################
#DATI CURVA SECP256K1
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F #caratteristica del campo
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 #ordine della curva
print
C = CurveOverFp(0, 0, 7, p)
G = Point(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) #generatore del gruppo dei punti della curva
#CHIAVE PUBBLICA
P = C.mult(G,d) # P = d*G (P serve solo per la verifica, non per la firma in se')
#CHIAVE PRIVATA USA E GETTA E RELATIVA CHIAVE PUBBLICA (qui si setta la prima parte della firma, r)
#k deve essere diverso da 0 e minore di n, qui diamo per scontato che sia cosi'
#k = 0x890e92faef7387295984abe9d583eb269bba942077f29b227c825788e13fe9be
k = subprocess.Popen(['hexdump', '-n', '32', '-e','8/4 "%08X"', '/dev/urandom'], stdout=subprocess.PIPE).communicate()[0]
k = int(k,16) #trasforma una stringa in un numero, se si vuole si puo' inserire qui a mano un altro valore
Q = C.mult(G,k) # Q = k*G
if (Q.x < n):
r = Q.x
i = 0;
else:
r = Q.x - n;
i = 2;
if (Q.y%2 == 1):
i = i+1;
if (compressed == 0):
i = i + 27
else:
i = i + 31
#FORMATTAZIONE MESSAGGIO
msg_formattato = "\x18Bitcoin Signed Message:\n" + chr( len(msg) ) + msg
e = hashlib.sha256(hashlib.sha256(msg_formattato).digest()).digest()
e = int(binascii.b2a_hex(e),16) #trasforma una stringa di byte in un numero
#FIRMA DEL MESSAGGIO
#(firmare vuol dire trovare a partire da r casuale un valore s che dimostri di possedere la chiave privata d;
#il valore s dipende ovviamente sia dalla chiave privata d che dal messaggio e)
k_inv = pow(k, n-2, n)
s = k_inv * (r * d + e) % n
#CODIFICA DELLA FIRMA IN BASE 64
#per fare le cose seriamente qui bisognerebbe controllare che sia r che s siano formati da 64 cifre esadecimali,
#in caso contrario bisognerebbe aggiungere degli zeri all'inizio del numero;
#qui questo controllo NON viene fatto
sig = binascii.b2a_base64( chr(i) + binascii.a2b_hex(hex(r)[2:-1]) + binascii.a2b_hex(hex(s)[2:-1]) )
sig = sig[:-1]
print
print '-----BEGIN BITCOIN SIGNED MESSAGE-----'
print msg
print '-----BEGIN SIGNATURE-----'
print address
print sig
print '-----END BITCOIN SIGNED MESSAGE-----'
#VERIFICA ONLINE
print
print 'Verifica qui --> '
p1 = subprocess.Popen(["echo", msg], stdout=subprocess.PIPE)
msg2 = subprocess.Popen(["sed", "s/ /%20/g"], stdin=p1.stdout, stdout=subprocess.PIPE).communicate()[0]
p1.stdout.close()
print 'http://brainwalletx.github.io/#verify?vrAddr=' + address + '&vrMsg=' + msg2[:-1] + '&vrSig=' + sig
print
Proviamolo: ~/src2/mini_ecdsa$ python sign_msg.py
y^2 = x^3 + 7 over F_115792089237316195423570985008687907853269984665640564039457584007908834671663
-----BEGIN BITCOIN SIGNED MESSAGE-----
Ciao oggi 31 dicembre sto provando a firmare un messaggio
-----BEGIN SIGNATURE-----
1FWBBmKhoPu3f6EZPhA6QiqTKoyz7Gj5CC
H7vsLWFceKpDgVxhhkiJdRjKNpBOK80beVDamBnFNwneXEC27UYdTBhWWVQy8SYFD95O79erYTW7wu2vU2q+I30=
-----END BITCOIN SIGNED MESSAGE-----
Verifica qui -->
http://brainwalletx.github.io/#verify?vrAddr=1FWBBmKhoPu3f6EZPhA6QiqTKoyz7Gj5CC&vrMsg=Ciao%20oggi%2031%20dicembre%20sto%20provando%20a%20firmare%20un%20messaggio&vrSig=H7vsLWFceKpDgVxhhkiJdRjKNpBOK80beVDamBnFNwneXEC27UYdTBhWWVQy8SYFD95O79erYTW7wu2vU2q+I30=
|
|
|
|
Accanto alle notizie spazzatura ci sono anche degli articoli come questo del TIME http://time.com/5486673/bitcoin-venezuela-authoritarian/Probabilmente la miglior analisi sul ruolo e la funzione dei bitcoin che abbia mai letto su una rivista non di settore. Consigliata a tutti la lettura. Interessante lettura, c'è anche un link https://medium.com/opacity/bitcoin-1537e616a074 a un articoletto di Nassim Taleb (quello del famoso libro sul cigno nero) che vede in Bitcoin una polizza assicurativa contro i futuri possibili regimi. |
|
|
|
Let (r,s) be the signature, m the message, e = H(m) the message digest, G the curve generator, d the private key, P=d*G the public key.
ECDSA works this way:
1) pick a random nonce k (a private key you use once) in [1,n-1]
2) k -> k*G = Q(xq,yq) then r = xq mod n (r is more or less like the x coordinate of Q)
3) s = k^-1 * (r*d + e) mod n
Then k*s = (r*d + e) mod n --> e = (s*k - r*d) mod n you know r and s (the signature) but not k and s (the two private keys), then you cannot retrieve the value of 'e'. (Usually you know 'e' too, in that case if you found out k, you could get d easily or viceversa, because it would be an equation with 4 known values and only 1 unknown.)
You could retrieve only e*G, because:
e*G = s*k*G - r*d*G = s*Q - r*P mod n, but again from e*G you can't retrieve the message digest 'e' (it would be like getting a private key from the public one).
Usually, when you verify a signature, you know 'e', and s*Q = e*G + r*P mod n -> Q = s^-1*e*G + s^-1*r*P, the last equation can be verified by knowing r, s, e, P.
Let's give an example. From here: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.htmlwe see how this tx was constructed we get this data: >>> n=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 (this is the group order)
>>>
>>> d=0x0caecf01d74102a28aed6a64dcf1cf7b0e41c4dd6c62f70f46febdc32514f0bd (the private key)
>>> e=0x5fda68729a6312e17e641e9a49fac2a4a6a680126610af573caab270d232f850 (the double hash of the tx/message)
>>>
>>> r=0x2cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713 (the first part of the signature)
>>> s=0x6c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168233e82 (the second part of the signature)
Now we try to retrieve the random nonce k (remember, k -> k*G = Q(xq,yq) then r = xq mod n , namely r is the x coordinate of Q, a sort of a public key, and k is its private key) e = (s*k - r*d) mod n s*k = (e + r*d) mod n k = s^-1 * (e + r*d) mod n >>> s_inv=pow(s,n-2,n) --> we are using the Fermat's little theorem to compute 1/s
>>> hex(s_inv)
'0x947f7b9fc41f37348c3a53a146757b9759e79da5fe039a35a9024bec1fb0ea0cL'
>>>
>>> hex((s_inv * s) % n) --> we check that s_inv * s = 1
'0x1L'
>>>
>>> k=(s_inv * (e + r*d)) % n
>>> hex(k)
'0x4526b5ab1973ab68afd06517996d22823441dd9ef52663a57de11d6642e961e7L'
k is supposed to be the private key to r. To have a confirm let's put 4526b5ab1973ab68afd06517996d22823441dd9ef52663a57de11d6642e961e7 here and we get the public key 04
X = 2CB265BF10707BF49346C3515DD3D16FC454618C58EC0A0FF448A676C54FF713
Y = B317A494AB75813F8737AC779BDF68AC5235C683A0FF92AEB81655DE137FB862
As expected, X = r ! |
|
|
|
In un'analisi costi-benefici più un miner è potente, e quindi più sarebbe potenzialmente capace di prendere il controllo di bitcoin, e più ha da perdere economicamente se questo avvenisse. E' questo meccanismo di incentivazione economica al comportamento onesto che è la più geniale invenzione del processo di consenso distribuito.
L'unico punto debole di questo ragionamento è che l'incentivo economico da solo potrebbe non essere garanzia sufficiente nel caso in cui i miner diventassero molto/troppo pochi e il comportamento autolesionistico di uno fosse sufficiente a mandare tutto all'aria. Esempio 1): il dittatore che spinge il pulsante di una bomba atomica che porterà a una guerra di distruzione anche per il proprio Paese non sta ragionando in termini razionali, anzi. Esempio 2): se sali su un aereo ti aspetti che il pilota piloti l'aereo con attenzione perchè ne va in primo luogo della sua stessa vita, purtroppo può accadere che in preda a qualche disturbo decida di schiantarsi volontariamente contro una montagna trascinando con sè tutti i passeggeri. La morale è che in una moltitudine di persone si dà per scontato che almeno la maggioranza decida sempre in modo razionale o perlomeno in modo non evidentemente autolesionistico-antieconomico. E' questa la garanzia/speranza della decentralizzazione (se pensiamo alla attuali democrazie le cose non vanno purtroppo sempre proprio così ma questo è un altro discorso). Ma quando da una moltitudine si passa a 2 o 3 individui la situazione cambia notevolmente, sul comportamento del singolo non è possibile fare alcuna previsione, uno potrebbe "impazzire" e bruciare tutto il sistema in modo del tutto irrazionale economicamente parlando senza che gli altri siano sufficientemente forti per fermarlo. Quindi va benissimo l'incentivo economico al comportamento onesto e va benissimo la separazione massima tra potere esecutivo e potere legislativo (miner / full node) cui alludevi in un tuo post precedente. Rimane la questione di come proteggersi dall'imprevidibilità che a livello di singoli individui è sempre possibile e che inizia a diventare un problema reale man mano che i miner diventano molto meno numerosi. Non solo può succedere che qualcuno di essi impazzisca letteralmente, può anche accadere che diventi target di attacchi personali (o alla famiglia). Concentrare nelle mani di pochi un grosso potere li espone molto in prima persona a differenza di quanto accade in una rete di molte migliaia di partecipanti. Io confido per questo che il processo di centralizzazione del mining comunque non raggiunga mai livelli eccessivi, altrimenti il tuo discorso sull'incentivo economico diventa improvvisamente una garanzia troppo debole. Si passerebbe in tal caso dal doversi fidare del comportamento non autolesionistico della maggioranza di una moltitudine di individui (evento molto probabile) al doversi fidare del comportamento non autolesionistico di A, B e C (evento del tutto imprevedibile). Trustless nel contesto bitcoin vuol dire letteralmente non doversi fidare di nessuno in particolare ma vuol dire al contempo fidarsi della maggioranza di una moltitudine di persone sconosciute, perchè in una moltitudine (da qui il valore della decentralizzazione) emerge con ogni probabilità la tendenza volta alla massima soddisfazione economica personale e su questa si basa in ultima analisi questa fiducia "trustless". |
|
|
|
Apro questo thread perchè si sta sviluppando una discussione interessante ma off topic nel thread sul consumo energetico. La discussione ha preso una strada diversa dal tema energetico da questo post https://bitcointalk.org/index.php?topic=2957043.msg48749013#msg48749013 fino a questo https://bitcointalk.org/index.php?topic=2957043.msg48789905#msg48789905Direi quindi di continuare qui per non inquinare ulteriormente l'altro thread. Per rispondere a duesoldi e a Plutosky: 1) certo che non mi farebbe affatto piacere che l'attività di mining si concentrasse nelle mani di una sola persona; non è questione però del fatto che gli utenti si disinteressano del mining delegando questa attività ad altri, la questione è che non vedo (per ora) come sia possibile costruire un sistema aperto nel quale tutti possano scrivere in un registro pubblico liberamente (cioè senza sforzo) senza che questo automaticamente diventi un enorme problema di sicurezza. Accessibilità a chiunque senza difficoltà non fa rima con sicurezza. Il Proof of Work è il metodo migliore trovato finora per garantire alla comunità che chi scrive nella blockchain (nota bene: solo uno alla volta può scrivere un blocco!) lo faccia solo dopo aver dato ampia dimostrazione di non avere altro interesse che quello di far funzionare correttamente la rete. Il momento della scrittura di un blocco e quindi dell'aggiornamento della catena determina potenzialmente più versioni della blockchain e ci vuole un qualche criterio per passare dalle molte possibili versioni a una sola; come fa questo passaggio a essere gestito in modo efficiente (anche dal punto di vista della sicurezza) da molti? Ribadisco che l'atto di scrivere un blocco costituisce di per sè un momento di inevitabile accentramento (almeno momentaneo), non si può scrivere un blocco in due (anche se si può minare in molti attraverso le pool). Purtroppo non vi è alcun modo che io sappia di contare il numero di persone che realmente sostengono un blocco o meno, si può misurare invece solo l'HP che supporta quel dato blocco. L'HP (o meglio la difficulty) è l'unico dato certo sul quale si può costruire un consenso che converga su un'unica catena. E l'HP ha a che fare con la capacità dei miner, c'è poco da fare, non con la democrazia. Altri sistemi come il PoS sono peggiori. 2) riguardo al discorso fungibilità è sicuramente una questione aperta e potenzialmente limitante lo sviluppo di bitcoin. A ben vedere nel primo caso il problema nasce dal fatto che il sistema non può associare agli indirizzi in modo univoco un'identità, se così fosse avremmo risolto il problema della decentralizzazione del mining perchè al posto della proof of work si potrebbe far votare agli utenti ogni blocco in modo da essere sicuri che la maggioranza effettiva degli utenti abbia sempre il controllo della scrittura dei blocchi. Nel secondo caso il problema è quasi l'opposto, comunque la blockchain è pubblica ed è possibile ricostruire la storia di quasi ogni utxo, e appena vi è un contatto con il mondo esterno alla blockchain si può risalire a un'identità e quindi potenzialmente censurare delle transazioni. |
|
|
|
L'esempio del medico/ingegnere secondo me non è adattissimo..... loro sono per definizione figure con alta specializzazione, e nel momento in cui ti rivolgi a loro ti metti nelle loro mani. Riponi tutta la tua fiducia in loro, non vai a discutere quel che un medico ti dice di fare (se no non ti saresti rivolto a lui).
Questo riporre fiducia in uno (o pochi) soggetti, non è però l'esatto contrario del mantra di base di bitcoin ? (che è qualcosa del tipo "non dare fiducia a nessuno, verifica tutto tu")
Sono 2 cose distinte. Far fare qualcosa a chi si è specializzato nel fare quel qualcosa vuol dire ottenere il miglior rapporto qualità / costi poichè chi ha investito molto del suo tempo nell'imparare un mestiere (superando una forte competizione) ha costi marginali bassissimi nell'eseguire il suo compito a fronte di una certa perizia nell'eseguirlo. Questo non vuol dire che tu ti fidi ciecamente del professionista, il controllo a posteriori c'è sempre (sai quanti ricorsi e pendenze giudiziarie varie ci sono in Italia contro i medici che sbagliano?) I full node controllano soprattutto a posteriori i blocchi dopo che sono stati minati. Lo chiedo non per polemica ma perché io vedo di buon occhio una rete di 100 mila cpu al posto di una centralizzata con Asic - parlando ovviamente solo del punto sulla decentralizzazione, non certo dell'efficienza energetica.
Probabilmente era l'idea originaria del paper di satoshi, ma poichè fare mining è un lavoro con un compenso è inevitabile che chi lo sa fare meglio ( ovvero è in grado di fornire un servizio migliore (+ hash al secondo) al miglior prezzo al sistema bitcoin) accentri nelle sue mani questo lavoro. La sicurezza non deriva dal numero di dispositivi usati ma solo dalla potenza computazionale messa in gioco. Numero di dispositivi != numero di persone. Poter accedere e utilizzare la rete bitcoin in modo democratico è un discorso, scrivere materialmente le transazioni nella blockchain è un altro (il primo è il vero servizio/valore che gli utenti cercano e che contribuiscono essi stessi a far crescere, il secondo è un lavoro accessorio utile per supportare il sistema). Il lavoro è ciò che fai per gli altri, il mining si fa perchè qualcun altro dà valore a quello che stai facendo (calcolare hash non ha nessun valore in sè per il miner), la rete la utilizzi invece perchè ti interessa, quindi è un servizio che tu utente richiedi e al quale tu utente con la tua richiesta e con il tuo utilizzo contribuisci direttamente a dare valore. Detta altrimenti, ci sono almeno 3 livelli nel sistema bitcoin, e per ciascuno dei quali lo scopo è tirare fuori il massimo valore possibile: 1) sviluppo software 2) mining (scrivere le transazioni) 3) utilizzare bitcoin e la sua rete per fare transazioni I protagonisti del caso 1) sono gli sviluppatori, ci sono diversi software anche se il principale è Core, codice aperto, chiunque potenzialmente con le capacità necessarie può contribuire ma alla fine non sono tantissimi proprio perchè bisogna essere molto competenti (matematici, crittografi, ....) Nel caso 2) abbiamo già detto dei miner e degli asic, il discorso è sempre volto al conseguimento della maggiore efficienza possibile (più sicurezza possibile al minor prezzo) Nel caso 3) i protagonisti sono gli utenti, il cui compito fondamentale è utilizzare e quindi fornire valore a bitcoin (e quindi indirettamente fornire senso al lavoro di sviluppatori e miner). Come si fa a dare più valore possibile a bitcoin? Utilizzandolo sempre di più e aumentando il numero di persone che lo supportano (e magari aumentare anche il numero dei full node). Il caso 3) è l'unico livello nel quale più persone ci sono, maggiore è il valore che si ottiene (a differenza dei livelli 1) e 2)). E' solo al livello 3) che si produce il senso generale del sistema e la vera decentralizzazione sta qui, non da altre parti. Ma è anche qui che sta a mio avviso il vero punto debole di bitcoin, poichè servono tantissime persone per creare fiducia (valore) in questa moneta, e il comportamento di tantissime persone non è per nulla prevedibile. Se domani uscisse una nuova moneta potrebbero cambiare opinione su bitcoin e passare ad altro. Attenzione ad una cosa però: trovare migliaia di cpu non protette è molto facile - hai ragione - però sono cpu "di tua nonna", non sono certo cpu di computer recenti o di geek/appassionati (che hanno cpu ovviamente più potenti).
Non perché "tua nonna" non possa permettersi la cpu recente, ma semplicemente perché a quel tipo di pubblico non interessa affatto la tecnologia perciò probabilmente usa un pc di 6 o 7 anni fa.
Pc di quel tipo sono probabilmente anche non protetti e quindi facili da violare, mentre un pc recente o di un appassionato no.
Per tornare al tuo discorso: la botnet che infetta pc probabilmente andrebbe a infettare pc che avrebbero poco peso nella globalità della rete e quindi dell'HP.
Se ne infetti tanti il peso ce l'hanno eccome, e andrebbe tutto a diminuire il costo di un attacco (e di conseguenza ad aumentare il peso delle fee che gli utenti dovrebbero pagare per ottenere una data sicurezza con un netto calo del rapporto qualità / costi). Ma non è il mining la componente centrale di bitcoin, non è esso che dà valore a bitcoin, il mining aiuta solo a proteggerlo così come le guardie di una banca proteggono i valori custoditi al loro interno ma non sono essi che generano quel valore. Hai ragione su questo punto - oltretutto riconosco che è un punto di estremo interesse (non scherzo eh!). Devo però proseguire con una riflessione: guarda la cosa dal punto di vista dell'utente e riprendo l'esempio delle guardie della banca. Non sono le guardie di una banca a generare il valore che custodiscono (vero!), ma quando tu utente entri in banca e vedi le guardie lì fuori, non provi un pizzico di preoccupazione al pensiero che quelle guardie potrebbero domani "impedirti" di accedere in banca ? Con i miner è uguale: non sono loro a generare valore, ma se decidessero di impedirti di accedere ai btc ? ovviamente con un atteggiamento distruttivo che farebbe crollare il valore di tutta la baracca ma verso il quale (atteggiamento) tu saresti a quel punto impotente! A me sta cosa non è che faccia stare molto tranquillo, per questo NON vedo bene questa concentrazione di HP nelle mani dei miner..... Come fa un miner a impedirti di accedere ai tuoi btc? Quando tu crei una tx e la invii a tutta la rete il miner ha come unico interesse quello di includere la tua tx in un blocco per guadagnarci. Ricorda che i compensi dei blocchi andranno a calare molto nei prossimi anni. Perchè un miner dovrebbe lavorare gratis (cioè produrre hash contro la doppia spesa senza intascare le fee delle transazioni?) In questo periodo dove i compensi per blocco sono ancora alti comunque il miner vede la sua retribuzione legata al valore del btc, che senso economico avrebbe per lui impedire le transazioni azzerando così il valore dei token che ha in mano? Se parli poi di atteggiamento distruttivo nel senso di attacco ostile dall'esterno della rete di cui si parlava qualche post fa, i numeri per ora dicono che ci vogliono più di 2 miliardi di dollari per avere delle possibilità, questa è la misura della sicurezza attuale. Il fatto che i miner rimasti dopo una dura selezione siano pochi (ma chi sa veramente quanti pochi sono? Certo non 100.000 ma nemmeno 2) non rende per forza più probabile un loro attacco, nel senso che per essere rimasti tra quei pochi devi avere investito pesantemente e lavorato duramente, penso (spero) che se solo uno di essi provasse un'azione autodistruttiva (e quindi antieconomica per eccellenza) gli altri reagirebbero alla grande. |
|
|
|
quindi, centralizzato o no, bisognerebbe cercare di tirare fuori il buono, che e'
minimizzare il costo del consumo energetico, e puntare apertamente tutta
la sicurezza sul costo dell'HW.
per fare questo, il PoW andrebbe cambiato in un PoA Prof of ASICs
con un ASIC progettato su misura in modo da consumare pochissima energia
ed avere un costo abbastanza significativo. Sarebbe il costo
di questa apparecchiatura a garantire la sicurezza della rete, e non il suo consumo.
Ricordo che l'acronimo ASIC significa Application Specific Integrated Circuits
che credo sia perfetto in questa accezione.
Sarebbe interessante delineare tecnicamente quali potrebbero
essere le caratteristiche di questo "ipotetico" HW dedicato,
e quindi di un potenziale PoA da utilizzare in Bitcoin 2.0 (la vendetta)
Non so se sia così indolore togliere l'energia dall'equazione. L'utilizzo di tanta energia garantisce non solo che possiedo un asic, ma anche che lo sto usando al 100% su uno specifico task. Se non lo uso al 100% (se non uso tutta l'energia che esso può consumare) data l'enorme competizione in bitcoin è garantito che non ci guadagno. Non avrebbe senso spendere molti soldi per un apparecchio di una altissima efficienza e poi non utilizzare tutta l'energia possibile. Se fosse possibile tirare fuori da un asic un valore utile al mining ogni 10 minuti senza particolari richieste di energia mi verrebbe da pensare che questo apparecchio non sta lavorando a pieno regime. Allora potrei usare lo stesso apparecchio per minare contemporaneamente tutte le monete che utilizzano lo stesso tipo di Proof. Se potessi minare contemporaneamente Bitcoin, Bitcoin Cash e altre con la stessa macchina, potrei utilizzare lo stesso dispositivo per attaccare una moneta e nel frattempo finanziarmi con le altre, in pratica diminuirei il costo di un 51% attack. E ogni fork diminuirebbe ulteriormente la protezione di ciascuna moneta, mettendo direttamente le une contro le altre. Al momento invece i miner a ogni fork devono scegliere dove andare e lasciano completamente perdere le altre catene/monete, non hanno convenienza alcuna ad attaccarle. |
|
|
|
Questo accade quando c'è inflazione, un sistema economico con un PIL basso non può buttare fuori moneta, altrimenti non è più rappresentativo di se stesso.
Si può anche eccedere ma la capacità produttiva di un paese di base, ci deve essere.
Alla fin fine se ti do un Bitcoin o ti do un contratto dove ti vendo la mia produzione di grano del 2028, ti sto dando la stessa cosa, sostanzialmente una promessa.
Quanto varrà nel 2028 il grano ? sarà richiesto il grano ? ci saranno altri produttori in grado di fornirli ? avremo bisogno di grano ?
In questa situazione teorica di scambio, tu mi dai denaro o una cosa oggi, per avere, forse, un vantaggio domani.
Ammesso che io riesca a produrre grano nel 2028, che valore avrà ?
Produrre Bitcoin, non significa poi produrre lavoro, la ricchezza non si crea e non si distrugge a piacimento... altrimenti avremmo risolto la povertà del mondo in un secondo.
Stampare moneta in più o stampare tanta cripto, come ne è stata stampata fin ad adesso... il confine è labile...
...troppe promesse, troppa confusione... Bitcoin ~ $ 3.200 o più...
Il denaro è sempre e solo una promessa. Se io ti vendo una sedia in cambio di 20 euro, io ti sto dando un bene fisico che ho prodotto con il mio lavoro, tu mi stai dando in cambio solo la promessa che qualcun altro in futuro mi darà l'equivalente di 20 euro (del futuro) in altri beni. Il denaro in sè e per sè non costituisce mai un pagamento definitivo, ma sposta semplicemente in là nel tempo la consegna di un bene o di un servizio. Nel caso delle valute fiat come dici tu queste promesse sono legate alle economie di uno Stato. Quando ricevevi 10.000 lire sapevi che quel valore ti avrebbe dato diritto al frutto del lavoro di un altro italiano nel futuro. Lo Stato garantiva che qualunque prodotto dell'economia italiana in vendita nel futuro sarebbe potuto essere acquistato con quel tipo di mezzo di pagamento (perchè il venditore avrebbe dovuto accettare quel mezzo di pagamento). In più la Banca d'Italia doveva impegnarsi come poteva per garantire un minimo di stabilità dei prezzi (con i risultati che tutti conosciamo) in modo che quelle 10.000 lire avessero grosso modo lo stesso significato a distanza di qualche tempo. E' questo il compito di una banca centrale. Con l'euro la situazione per noi è nettamente migliorata, inflazione molto più sotto controllo, mercato dove poter spendere i nostri euro molto più ampio, in una parola garanzie più solide. Bitcoin, se considerata come moneta, è anch'esso una promessa di pagamento nel futuro. Il problema qui è il soggetto che manca: chi fa questa promessa? Chi mi può promettere che i miei btc verranno accettati tra un anno in cambio di qualcosa? Chi lavora per evitare/limitare una possibile perdita del potere d'acquisto (che si può realizzare anche se i bitcoin sono 21 milioni, come dimostra l'ultimo anno)? Sono i soggetti di queste promesse molto fumosi, non metto in discussione che anche l'euro sia una promessa, ma in quest'ultimo caso è fatta da chi ha la legge e la forza dalla sua parte (e quindi la credibilità) per poter fare questo tipo di promessa (per quanto tempo poi riesca a mantenerla è un altro discorso). |
|
|
|
ehehe avevo "astutamente" evitato l'argomento.
...
Come sai, sono anni che non credo piu' alla decentralizzazione di bitcoin, e di nessun'altra crypto.
Do' proprio per scontato che qualsiasi sistema si inventi verra' centralizzato
in mani piu' furbe, intelligenti, intraprendenti, ricche, fortunate... insomma su
questo tema credo che non sia nulla da fare.
Io invece più passa il tempo più mi sto convincendo che la questione della decentralizzazione è vitale in Bitcoin ma va considerata nella sua giusta prospettiva. Cioè per farla breve non è il mining che deve essere decentralizzato, soprattutto se per decentralizzato si intende qualcosa del tipo una testa un voto (o per dirla alla Satoshi "una cpu un voto", idea affascinante alla M5S ma che non ha riscontri nella realtà). Il mining è un'attività specifica che come tale deve essere il più efficiente possibile e quindi è molto meglio che di fronte a questo tipo di attività io, mia nonna e un grande miner non siamo messi sullo stesso piano. Se oggi ci fossero solo cpu per il mining anzichè gli asic, questa particolare tipo di attività sarebbe sicuramente più decentralizzata di quanto lo è oggi ma sarebbe più sicura la blockchain? Per avere una sicurezza analoga ai 2 miliardi di dollari per gli asic, con 2 miliardi a 200 dollari l'una si dovrebbero impiegare 10 milioni di cpu. Ma gli utenti che hanno effettivamente le chiavi private dei propri bitcoin non saranno più di 2-3 milioni, quindi del tutto irrealizzabile. Quanto costerebbe acquisire allora diciamo 400k cpu? 80 milioni di dollari contro i 2 miliardi per gli asic, cioè una sicurezza ridicola in confronto a quella attuale. Anzi sarebbe ancora peggio, il valore di quella sicurezza è ancora minore in quanto si potrebbe in maniera ancora più economica creare una botnet con il computer di mia nonna compreso per tentare un 51% attack. Trovare migliaia di cpu non protette nel mondo è molto facile. Provate invece ad accedere da remoto a un asic. Il fatto che non sia troppo facile (anzi che sia volutamente estremamente costoso e assolutamente non alla portata di tutti) poter scrivere nella blockchain implica necessariamente che pochi possano specializzarsi in questa attività e va bene così, quando io cerco qualcuno che sia bravo (medico, ingegnere, professionista) so che dovrò necessariamente rivolgermi solo a persone che hanno speso una parte considerevole del loro tempo per poter fare molto bene quel tipo di attività (tutto ciò crea selezione), oppure deve essere un diritto democratico per tutti quello di fare il medico o l'ingegnere senza spendere troppa fatica e indipendentemente dai risultati/capacità? Se vogliamo un sistema di assicurazione contro la doppia spesa efficiente alla fine è inevitabile che pochi prevalgano, è giusto che sia così, se il mining (con l'esempio di prima solo attraverso le cpu) lo facessi anch'io e mia nonna il costo totale sarebbe inutilmente alto per gli utenti, mentre sarebbe possibile un 51% attack spendendo molti meno soldi (basterebbe riuscire a essere più efficienti di me, cosa molto facile, magari rubando facilmente il controllo di altri pc). Un sistema molto efficiente contro la doppia spesa di fatto traduce fedelmente la spesa degli utenti in fee in sicurezza, un sistema poco efficiente invece farebbe pagare un prezzo molto più alto rispetto alla sicurezza prodotta (sicurezza prodotta = soldi realmente necessari per un 51% attack). Il sistema Bitcoin per me rimane invece nel suo complesso assolutamente decentralizzato (letteralmente senza un centro) nel senso che le transazioni partono da qualsiasi computer e senza alcun controllo centrale vengono trasmesse alla rete e prima o poi vengono incluse in un blocco. Inoltre non c'è nessuna autorità centrale che decide le politiche monetarie. Nessun registro principale ma un database distribuito in migliaia di copie verificabili in prima persona. Sono gli utenti che danno valore al bitcoin e che tramite i full node controllano che le regole vengano rispettate dai miner. Ribadisco che considerare il mining come l'attività centrale di bitcoin svia completamente tutti i giudizi. Se il mining è la componente centrale di bitcoin e il mining non è decentralizzato, ergo bitcoin non è decentralizzato. Ma non è il mining la componente centrale di bitcoin, non è esso che dà valore a bitcoin, il mining aiuta solo a proteggerlo così come le guardie di una banca proteggono i valori custoditi al loro interno ma non sono essi che generano quel valore. |
|
|
|
Sono d'accordo ma dobbiamo sempre ricordarci che questo vale ANCHE per le Fiat: tendiamo a dare per scontato che avendole le si possa spendere (perché c'è l'obbligo di accettarle per i pagamenti e così via) ma ogni tanto si arriva a situazioni nelle quali si blocca tutto e tu rimani con le tue belle Fiat in mano - se sei fortunato ad averle - improvvisamente diventate inutili.
Faccio sempre l'esempio della Grecia che nel 2015 ....
E' un paragone oggi improponibile..... però l'esempio della Grecia dice che non è tutto oro quel che luccica, ovvero non è che le fiat siano esenti da difetti e offrano mille garanzie mentre bitcoin no.
Chiaro che le valute fiat non sono perfette, nessuno lo afferma, dico solo che le considero più sicure in generale di bitcoin (almeno le principali, dollaro e euro). Nessuno si aspetta che l'euro faccia un x10 con il suo potere d'acquisto nel prossimo anno, molti invece sperano che questo possa accadere con bitcoin: il fatto stesso che possa accadere indica quanto sia probabile purtroppo anche il salto all'indietro. Bitcoin non può essere bloccato come è successo in Grecia, ma se si riduce grandemente il suo potere d'acquisto il risultato è lo stesso se non peggiore. Inoltre nel caso della Grecia c'erano delle avvisaglie, anni di debiti e difficoltà dell'economia greca, in qualche modo ci si poteva aspettare che ci sarebbero stati dei problemi, con Bitcoin gli avvenimenti positivi o negativi invece sono molto più improvvisi e non riconducibili a nessun fatto particolare: perchè sale? perchè scende? E' molto più facile purtroppo rimanere con il cerino in mano (ovviamente mi auguro che non accada). Tutto questo lo dico solo perchè mi sembra necessario mantenere un punto: il sistema di incentivi, la crittografia e i miner possono garantire che una certa transazione sia effettivamente avvenuta un tal giorno e che i bitcoin legati a un certo indirizzo non possano essere mossi senza la relativa chiave privata, ottimo, ma il valore del bitcoin non può certo basarsi solo su questo tipo di garanzia, esso dipende molto di più da quanto effettivamente gli utenti troveranno utile questa strana moneta. E i valori attuali a mio parere riflettono più una scommessa sull'aumento futuro del valore che una fotografia del valore attuale, visto che ad oggi Bitcoin è usato pochissimo e solo in particolari circostanze. |
|
|
|
...
Con Bitcoin questa garanzia come noto non è data da nessuno, tuttavia sappiamo che c’è dietro un ecosistema (utenti, miners, exchange) che consentono a Bitcoin di continuare ad avere un valore almeno per un arco di tempo non trascurabile. Traducendo: anche in un mercato down come l’attuale, penso che tra un mese difficilmente Btc potrà valere una cifra troppo distante dall’attuale, diciamo che mi aspetto tra i vari su e giù ai quali siamo abituati, al massimo un -20% (sì lo so che se guardassimo l'ultimo mese saremmo messi ben peggio!!).
Questo valore quindi è quello che in questo momento vedo insito nel sistema, ovvero il sistema fa da “garante” (il virgolettato ha ovvio significato) affinché nel breve il valore di Bitcoin possa restare in questo range.
Non si tratta di garanzie assolute – è evidente – sono sempre soggette ad un margine di rischio…. Ma d’altro canto anche noi in Italia con il nostro bell’Euro non siamo stati nello scorso mese vicinissimi ad un tracollo finanziario ?
Il valore è dato solo dagli utenti, molti beni materiali un qualche valore intrinseco ce l'hanno (una mela la posso mangiare, su una sedia posso sedermi) mentre altri "beni" come bitcoin sono totalmente immateriali e hanno valore solo finchè c'è una certa massa critica di persone che glielo dà. Io da solo con 1 btc non sono in grado di farci nulla se non c'è qualcun altro che lo accetta come pagamento. Non possiamo fare particolari previsioni sul valore di bitcoin nemmeno da qui a 1 anno, ci sono solo sensazioni, e questo è un dato di fatto. Il margine di rischio dell'euro che tu citi dal mio personale punto di vista non è neanche lontanamente paragonabile a quello insito in bitcoin. Dietro l'euro c'è un gruppo di Stati europei con tutte le rispettive economie che hanno tutto l'interesse che l'euro sopravviva. Dietro bitcoin ci sono pochi utenti (5 milioni?) sparsi per il mondo, le cui vite economiche non sono in larga parte basate nemmeno su bitcoin (investi in bitcoin quello che sei disposto-puoi permetterti di perdere). Quindi poche persone, disperse (non legate tutte in un'unica economia), che loro stesse hanno investito solo una piccola parte dei loro risparmi in bitcoin (penso sia la situazione più comune anche tra gli utenti di questo forum). Di fatto siamo tutti in attesa che bitcoin decolli, ma al momento l'utilizzo sembra relegato a moneta di crisi / riserva di valore in particolari situazioni. E con un grosso punto interrogativo sulla stabilità del prezzo, al confronto del quale l'inflazione dei principali Paesi (USA, Germania, Italia, Giappone) scompare. Poi il fatto che molti puntino a un apprezzamento del bitcoin non toglie che il rischio di "inflazione" del bitcoin (nel senso di perdita di potere d'acquisto dei beni reali) sia molto superiore al rischio di inflazione delle monete standard. Non si può pensare di avere concrete possibilità di poter fare un x10 con il valore del bitcoin se non ammettiamo nel contempo che ci sono altrettante discrete possibilità che possa fare un /10. Il valore di bitcoin è completamente slegato di per sè dalle singole economie, mentre le monete come l'euro in teoria hanno Stati e banca centrale che provano quantomeno a mantenere un minimo di stabilità dei prezzi e che garantiscono con la forza della legge che quella moneta deve essere accettata come mezzo di pagamento. In qualche modo il valore delle monete viene legato alla forza dell'economia che esse stesse fanno girare. Non mi pare proprio la stessa cosa di bitcoin. |
|
|
|
C'è un però, gli hard disk a differenza degli asic non sono strumenti "usa e getta", cioè un attaccante potrebbe investire 10 milioni di dollari in hard disk per distruggere la rete burst e poi rivendere quegli hard disk o riutilizzarli per altri scopi.
Nel caso degli asic invece il giorno dopo la distruzione della rete bitcoin il loro valore crollerebbe a zero, quindi i soldi spesi per gli asic sarebbero veramente bruciati tutti, a differenza del caso degli hard disk.
Infatti piu' approfondisco l'argomento piu' mi convinco che alla fine l'algoritmo migliore sarebbe un "PROF of ASICS" con asics che consumino pochissimo, (meno di un pc+HD, pochi milliwatt) e facciano ogni tanto un calcolo (tipo burst) per dimostrare di essere operativi. Il principio base è che gli asic sono uno strumento dedicato solo a bitcoin (quindi molto più sicuri di cpu e gpu dei primi tempi), li devi usare per forza quindi sia se vuoi sfruttare il protocollo per guadagnare soldi come fanno i miner onesti, sia se vuoi affossare la rete, ma così facendo sei costretto a perdere per forza anche tutti i soldi che tu stesso hai messo negli asic. Ma non erano il male assoluto, contro la decentralizzazione?  Lo stesso oggetto produce ricchezza se usato in un modo, la distrugge (anche per chi lo usa) se utilizzato in un altro. Per salvaguardare secondo me l'aspetto energetico servirebbero dei speciali hard disk dedicati, che potessero magari accedere molto velocemente solo a certe combinazioni di settori sparsi e ricavare ogni tot minuti un certo valore. Direi una sorta di "Proof of Scattered Capacity" che leghi quindi il valore di quei dispositivi solo alla moneta particolare che si sta minando. Un dispositivo del genere consumerebbe molto di meno di un asic ma sarebbe dedicato, nel senso che un hard disk standard impiegherebbe troppo tempo a ricavare questa combinazioni di valori e non riuscirebbe quindi a minare in tempo il blocco. L'importante sarebbe che un hard disk specializzato in questo senso a sua volta dovrebbe funzionare male o per niente per gli usi comuni, potendo accedere solo a determinate combinazioni di settori alla volta, quindi perderebbe valore in caso venisse utilizzato per distruggere il valore della criptomoneta a cui è legato. |
|
|
|
ideare un dispositivo asics che non consuma praticamente un cazzo (quindi ancor meno di un HD)
che ha come unica funzione di accertare che un certo "calcolo" o qualcosa di unico sia davvero
fatto da quel dispositivo.
Cosi' almeno l'impatto energetico (che ripeto a conti fatti da' una garanzia molto marginale) sarebbe quasi annullato.
E fondamentalmente rivaluto la bonta' del progetto burst.
@arulbero sarebbe interessante fare due conti consumo energetico/costo dispositivi nel mondo hd/burst.
Questa è una stima di inizio anno sui costi dell'hardware presa da qui: https://hackernoon.com/burst-part-4-network-analysis-a8c1305a5750la stima è fatta assumendo che la capacità media sia di 9.5 TB per pc: Average Cost per TB: $25
Average Miner Overhead Cost (Computer): $500
Total Capacity Cost = 25 x 184,372 = $4,609,300
Total Overhead Cost = 500 x 19,461 = $9,730,500
Total Network Cost = 4,609,300 + 9,730,500 = $14,339,800
Considerando che attualmente ( https://www.burst-coin.org/) la rete di mining ha una capacità di 241 PB, il calcolo aggiornato sarebbe: Average Cost per TB: $25
Average Miner Overhead Cost (Computer): $500
Total Capacity Cost = 25 x 241,000 = $6,020,000
Total Overhead Cost = 500 x 25,368 = $12,680,000
Total Network Cost = 6,020,000 + 12,680,000 = $18,700,000
Aggiungo che non sono molto convinto della stima di una capienza media di 9,5 TB per pc, secondo me è di più (anche se io mino con soli 0,5 TB), ma non ho altri dati. Quanto consuma al giorno un pc quasi spento (visto che il mining qui richiede semplicemente un accesso ogni 4 minuti all'hard disk)? Lascio la parola agli esperti, moltiplicate per circa 25k pc che formano la rete e otterrete il risultato finale. EDIT: si può minare tranquillamente anche con un raspberry, quindi i costi minimi per poter replicare e superare questa rete dovrebbe tener conto molto più del costo degli hard disk (stimato intorno ai 6 milioni di dollari) che del costo dei pc. Stesso discorso per i consumi energetici. C'è un però, gli hard disk a differenza degli asic non sono strumenti "usa e getta", cioè un attaccante potrebbe investire 10 milioni di dollari in hard disk per distruggere la rete burst e poi rivendere quegli hard disk o riutilizzarli per altri scopi. Quindi a conti fatti la sua spesa effettiva per l'attacco sarebbe ben minore. Nel caso degli asic invece il giorno dopo la distruzione della rete bitcoin il loro valore crollerebbe a zero, quindi i soldi spesi per gli asic sarebbero veramente bruciati tutti, a differenza del caso degli hard disk. La sostanza del discorso è che qualcosa bisogna bruciare / spendere definitivamente per rendere sicuro un sistema, in caso contrario, se si cerca di risparmiare qualcosa (per esempio utilizzando hard disk riutilizzabili) i costi reali sono ben minori, ma altrettanto lo diventano per il potenziale attaccante. Il fatto che bitcoin utilizzi come dici tu una "proof of asics" è interessante proprio perchè gli asic servono solo a uno scopo, e nel momento in cui lo utilizzi contro la rete annulli il suo valore insieme a quello della rete. Il valore degli hard disk invece non è legato certo solo al valore di burst, quindi gli hard disk si possono usare temporaneamente come arma contro burst e poi si possono convertire per altri scopi. Nel caso di burst infatti si parla correttamente di Proof of Capacity, tu per minare devi dimostrare in un certo momento che hai riservato un certo spazio per gli hash, ma quello spazio non è perso per sempre, quindi quello spazio ha un costo per te sicuramente inferiore al costo dell'hard disk. |
|
|
|
tirando un po' le somme:
costo affitti: 20.000.000$
costo personale: 2.000.000$
costi vari (allacciamenti, ecc) 2.000.000$
-------------
primo totale 24.000.000$
moltiplico per due per eventuali sottostime:
totale struttura e personale: 50.000.000$
costo energia per 48H di attacco: 17.000.000$
costo ASICS: 2.000.000.000$
--------------------------------------------------
Totale 2.067.000.000$
Emerge ancora chiaramente che attualmente la sicurezza NON e' data dal costo energetico, (che alla fine e' il costo piu' piccolo per 48 ore di attacco) ma bensi' dal costo degli ASICS, che e' due ordini di grandezza superiore. Da notare che aumentando il personale si possono ridurre molto i tempi di preparazione, impattando pochissimo sui costi, con un 200 persone in qualche mese l'attacco si prepara, e i costi salgono di una manciata di milioni di dollari. Inoltre una volta messa in piedi l'infrastruttura, attaccare per un giorno o per una settimana diverrebbe abbastanza marginale sui costi, quindi l'attacco si protrarebbe fino alla devastazione certa della rete. Tirando le somme: con 2.1/2.2 miliardi di dollari ad oggi si puo' senza dubbio distruggere la rete, con un'operazione pianificata qualche mese fa. Quindi il costo per distruggere la rete dall'esterno (partendo da zero) è per fortuna molto più alto, in pratica avrebbe ragione chi considera nelle sue analisi principalmente solo un attacco interno e non considera mai un attacco esterno (perchè troppo più costoso, e la sicurezza si calcola considerando il costo minimo per attaccare). Riassumendo: 1) attacco interno: i costi dipendono dalla posizione di partenza di un miner, se parte già da un 30% di HP, gli bastano un 21% in più di energia + nuovi asic; nei costi però deve aggiungere anche l'attuale 30% di energia che dirotterebbe verso un lavoro autodistruttivo. Al momento si ritiene però questo attacco meno probabile. 2) attacco esterno: i costi dipendono soprattutto dal reperimento sul mercato di questi asic, senza i quali non è possibile trasformare energia elettrica in scritture di tx nella blockchain. In questo caso l'attaccante deve da solo replicare e superare la potenza visibile di tutti gli altri miner. Se i costi sono legati soprattutto ai macchinari questo è un bene, probabilmente in futuro per avere anche solo una piccola percentuale di miglioramento di efficienza (che fa comunque la differenza su una grande quantità di energia) si spenderà molto di più per questi macchinari il cui alto valore garantirà contro la doppia spesa. L'importante però è che nel frattempo non si svalutino eccessivamente asic con una efficienza minore ad esempio solo del 10%, non appetibili ai miner onesti che vogliono sfruttarli per molto tempo per guadagnarci usando meno energia possibile, ma interessanti per chi vuole solo distruggere in poco tempo la rete e che non ha quindi interesse a risparmiare un po' di energia. Insomma sarebbe più pericolosa la capacità computazionale dormiente presente nel pianeta anzichè la sua efficienza affinchè un attacco esterno ostile abbia chance di successo. Miner onesti e attaccanti ostili giocano in realtà 2 giochi diversi pur utilizzando gli stessi giocattoli. 2 miliardi per una rete che ne vale 60 mi sembrano rassicuranti da un lato (lato sicurezza), non sostenibili dall'altra, questo 3,3% (anzi un po' di più) dovremo metterlo direttamente noi utenti fra qualche anno, e francamente mi sembra un po' troppo. Se la rete però passasse da 60 miliardi a 2000 miliardi di valore, allora anche un più ragionevole 1% di fee (20 miliardi) sarebbe più che sufficiente. Interessante alla fine che la spesa per buttare giù 10 giorni di blockchain o 1 mese sia simile, alla fine effettivamente bitcoin da questo punto di vista è abbastanza simile a burst. Per curiosità, quanto sarebbe la spesa stimata per riscrivere da zero tutta la blockchain? EDIT: quindi alla fine bitcoin ha 2 punti fondamentali sui quali può essere attaccato: 1) si può sfruttare il protocollo con il 51% attack e riscrivere un pezzo della blockchain causando una perdita di fiducia generalizzata (ma ci vogliono molti soldi) 2) la perdita di interesse dei propri utenti può drenare valore dei bitcoin senza nessun attacco pianificato: alla fine il valore viene dall'utilizzo e dall'utilità che gli utenti riscontrano ma anche e soprattutto da ciò che ciascuno pensa verrà deciso dagli altri utenti, quindi rimane un grosso interrogativo sulla credibilità a lungo termine del sistema (che non è legata ripeto solo alla presunta inviolabilità del sistema ma anche al semplice valore che viene assegnato al token, valore che può essere appunto drenato in ogni istante senza apparenti motivazioni). |
|
|
|
Avere un'idea degli ordini di grandezza economici che servono a demolire bitcoin, mi sembra un utile esercizio. Anzi sempre con un po' di approssimazione, potemmo creare un indicatore: Costo Stimato Distruzione Ostile Bitcoin Vorrei decidere con voi qualche assunto il primo: secondo voi basta un giorno di attacco 51% per distruggere la credibilita' della rete ? Non è facile rispondere, un attacco con successo è già stato portato a Bitcoin Gold: https://medium.com/formosa-financial/a-51-attack-happened-how-did-it-happen-to-bitcoin-gold-da131a8080a6ma con impatti non drammatici sul prezzo di allora. Un attacco ostile, non un mero tentativo di doppia spesa, che annullasse le tx di un centinaio di blocchi non solo toglierebbe dei btc a chi li ha ricevuti in cambio di qualcos'altro, ma rischierebbe anche di eliminarli dalla disponibilità di chi li aveva inviati (qualora nel frattempo avesse buttato via la chiave privata). Non so nemmeno se sarebbe possibile una qualche forma di resistenza (non credo che i miner potrebbero volontariamente continuare a lavorare sulla vecchia catena aspettando che l'attacco si esaurisca, il protocollo non mi sembra che lo consenta). Una stima per un attacco si trovava in questo sito: http://www.crypto51.app/ma secondo me per calcolare una stima dei costi di un attacco ostile (supponendo che provenga dall'esterno, e che quindi parta da zero), bisognerebbe tener conto di tanti elementi, poichè in quel caso la sicurezza sarebbe data dall'insieme di tutte le risorse necessarie a costruire l'attacco, tempo compreso: Attualmente, come sappiamo, servono macchine ASIC per minare... La rete attuale è sui 350-400mila Terahash... per fare un 51% voluto, e magari forkando non solo un blocco ma buona parte della rete, come scritto, biosgna minare vari blocchi in parallelo.
Il che significa o convincere la metà dei miner a spostarsi (cosa che vedo ben infattibile, chi ha speso soldi per minare non ha convenienza a portare un attacco che creerebbe un panic-sell e ne farebbe precipitare il valore).. oppure crearsi un altra rete con potenza superiore a quella principale, staccata... e solo dopo X blocchi metterla online, le potenze si sommerebbero e vincerebbe la nuova chain.
Ora, per metter in piedi 500mila Tera servono, usando uno dei prodotto migliori sul mercato (gli S5) qualcosa come 400mila miner... per una spesa di 60milioni di dollari ed un assorbimento di qualcosa come 240MegaWatt...
Un spesa alta ma che richiederebbe un infrastruttura enorme...
Il tutto per minare dei blocchi in parallelo, far "crollare" la catena principale che porterebbe ad un crollo del prezzo e quindi renderebbe la "truffa" inutile comunque.
Poi, sono calcoli fatti a mente ed a spanne... ma che rendono l'idea del perchè si può definire, secondo me, il bitcoin sicuro dal 51%
...
Vi fermate alla parte economica dei miner... non è solo li il problema.
Prima di tutto, dovete trovare chi ve li produce (i miner), se non crearvi una propria azienda investendo centinaia di milioni.. perchè se per dire li comprate da bitmain ora che vi arrivino e li colleghiate.. ne avete troppo pochi, la rete è aumentata.
Poi la logistica? Farvi arrivare 400mila miner richiederebbe mesi solo per attaccarli insieme, fare i cablaggi della rete dati ed elettrica... e su quest'ultimo, i consumi?
400mila miner consumano appunto 240-250MegaWatt... Una centrale moderna nucleare (per capirci) produce circa il doppio (600MW)... quindi a voi serve una mezza centrale per alimentare i miner.
Quindi i 60milioni di dollari per comprarli sono il meno... è tutto il resto che rende complicatissimo\impossibile praticare, ad ora, questo attacco. Ed è anche il motivo per cui gli asic non sono certo la fine del bitcoin ma anzi, sono una manna per garantirne la sicurezza.
|
|
|
|
Riflettendo su quando avevo scritto, ho calcolato che il 17 dicembre 2017, quando bitcoin ha raggionto il
suo ATH a quasi 20.000 dollari, l'energia necessaria per condurre un 51% attack per un'ora era di "soli" 1100 MWh circa,
ossia costava circa 100.000 $ fare un attacco del 51% di un'ora, ossia circa 2.500.000$ per tenere la rete in
scacco un giorno (e probabilmente distruggerla).
Puo sembrare tanto, ma per proteggere una rete che in quel momento valeva circa 350 miliardi di dollari, e'
veramente pochissimo.
quindi piu' ci rifletto, piu' mi sembra che la "vera" protezione derivi dal costo dell'HW necessario
a sviluppare tanta potenza di calcolo, piuttosto che l'energia stessa, quindi penso sarebbe interessante
fare anche un'analisi approssimativa del costo dellHW.
(sono riflessioni che nascono dopo la discussione con arulbero sul tema "burst" , che punta piu' sulla risorsa hard disk
per proteggere la rete piuttosto che sul costo dell'energia elettrica)
EDIT e mi fa anche riflettere su quanto dovrebbe costare mettere davvero al sicuro una rete che stabilmente
avesse un valore di 100.000$ a bitcoin, ossia un valore totale di circa 2 trilioni di dollari.
Aggiungo un ulteriore elemento. Prendiamo per un istante l'oro, visto che spesso viene confrontato con i bitcoin. Tiro fuori da wikipedia questo dato: Nel 2001, si calcola che ci fosse in circolazione una quantità totale di oro pari a 140 000 tonnellate, una quantità che può essere rappresentata, in volume, come un cubo di lato pari a circa 20 metri.
a 40k dollari al chilo fanno 40k * 140 * 10^6 = 5.600.000.000.000 ovvero circa 5600 miliardi di dollari. Quanto si spende attualmente per mantenere in sicurezza questi 5600 miliardi di dollari? Una risposta è difficile perchè l'oro è situato in molti posti diversi mentre i bitcoin sono tutti registrati nella stessa blockchain. Eppure l'oro ha una sua sicurezza intrinseca che i bitcoin non hanno, l'oro non ha bisogno di nessuna spesa per rimanere credibile. E questo non è un fatto da poco. Apparentemente solo i bitcoin o meglio gli utxo creati negli ultimi blocchi sono a rischio diretto di un 51% attack, ma in realtà essendo un sistema di fiducia, se viene attaccata con successo anche solo una piccola parte degli utxo ci sarebbe un crollo complessivo del valore. Quindi la mia considerazione: è più facile far cadere la fiducia delle persone nell'oro o nei bitcoin? Lo so che il paragone non sembra equo per niente in quanto l'oro esiste da molto più tempo, ma se ci pensate un attimo la sicurezza dell'oro non dipende dalla sicurezza dei singoli lingotti: il fatto che qualcuno mi rubi un lingotto non decreta una caduta generale di fiducia verso il metallo prezioso. Con bitcoin invece molti continuano a sostenere che la sua grande forza è il fatto che finora ha resistito a ogni attacco, ma che sicurezza/garanzia può mai dare qualcosa che se venisse bucata anche una sola volta rischierebbe di crollare? In un certo senso mi sembra che la supposta forza di bitcoin (considerato inviolabile) nasconda in realtà una grossissima vulnerabilità, nessun sistema è inviolabile per sempre, e paradossalmente dal punto di vista della sicurezza l'oro è maggiormente sicuro perchè più decentralizzato fisicamente e quindi un attacco generalizzato all'oro non sarà mai possibile, mentre tutti si aspettano attacchi al bitcoin, e la questione mi sembra che sia non se ma solo quando questo avverrà. E almeno uno prima o poi avrà successo. Sarà importante per allora che avremo metabolizzato anche il mito dell'inviolabilità, cioè le conferme dei blocchi hanno un significato probabilistico, e quindi se fra 5 anni qualcuno sconvolgerà 100 blocchi, dovremo considerarlo come un evento triste ma assolutamente possibile. A me non sembra possibile continuare ad andare avanti credendo fermamente che mai nessuno potrà attaccare con successo il sistema, finora nessuno sufficientemente grosso ci ha mai provato sul serio, questo perchè al momento bitcoin non viene preso sul serio quasi da nessuno, ma immaginate domani una Cina che decida di buttare 50 / 100 milioni di dollari in un attacco per annientare bitcoin, qualche possibilità di successo almeno parziale ce l'avrebbe, no? |
|
|
|
Provo ad aggiungere un elemento di discussione. In questo thread stiamo argomentando in maniera critica le funzioni di bitcoin, ma in generale se si frequenta il resto del mondo delle crypto la maggior parte delle opinioni vanno tutte nella stessa direzione, e cioè sono solo volte a magnificare i nuovi concetti introdotti da bitcoin. Personalmente per riacquistare un po' di equilibrio di giudizio sto cercando di approfondire qualche concetto economico (soprattutto legato alla moneta e al concetto di denaro), visto che a parte le nozioni tecniche sul funzionamento di bitcoin, l'aspetto economico è assolutamente centrale. Riassumendo, alcune considerazioni: 1) molti economisti sostengono che una moneta per essere efficace in quanto tale (cioè come mezzo di scambio) non deve essere limitata, ma al contrario deve essere possibile una politica di emissione flessibile a adattiva alle mutevole condizioni dell'economia 2) ogni moneta trae la propria garanzia ultima dalla forza di chi la impone agli altri come mezzo di pagamento 3) l'oro costituisce una riserva di valore soprattutto in momenti di crisi ma in modo parziale e limitato solo ad alcuni contesti specifici In base a questi assunti bitcoin come moneta, cioè come mezzo di scambio, non avrà mai successo, poichè è limitato by design in 21 milioni di pezzi. Vi linko più sotto ad esempio il video di un economista famoso Boldrin, che lavora negli Stati Uniti, il quale sostiene che il valore del dollaro è garantito in ultima analisi dalla forza del governo americano, in pratica dai marines. E' solo con la forza che si può garantire che un certo token sia accettato da qualcuno in cambio del frutto del proprio lavoro. Chi si fida del dollaro sa di chi si sta fidando, questo non vuol dire che il dollaro sicuramente non fallirà, ma è chiaro qual è la forza che lo sostiene. Il principale limite di bitcoin invece sta proprio nel fatto che quando io scambio il frutto del mio lavoro (=bene reale) con 1 btc, non ho nessuna garanzia che domani troverò qualcun altro disposto a cedermi il frutto del suo lavoro in cambio del mio btc. In pratica bitcoin può garantire con certezza con una certa transazione sia effettivamente avvenuta da A a B in un certo momento, può garantire contro la doppia spesa, può garantire anche che io possiedo sempre 1 parte su 21 milioni di pezzi del circolante, ma non può garantire nulla sul fatto che ci sarà qualcuno pronto a riconoscere un valore a quel token. Il valore di Bitcoin si basa solo sulla fiducia nel fatto che altre persone dopo di me avranno fiducia in quel token, e quest'ultima fiducia si basa a sua volta su aspettative dello stesso tipo riguardo ad altre persone e così via. In caso contrario mi ritrovo con niente in mano. Nel dollaro invece questo tipo di fiducia a catena, che pure esiste, è rinforzata e garantita per imposizione con la forza della legge, mentre in bitcoin per ogni utente bitcoin esiste solo la fiducia nel fatto che tutti gli altri utenti continueranno a mantenere spontaneamente fiducia nei comportamenti reciproci, cioè continueranno in futuro a dare valore al token. Questo punto ribadisco esula da questioni tecniche come crittografia, scaling o quant'altro, ma cerca di chiarire un aspetto centrale: da dove si origina la fiducia in una moneta? In un sistema formato da milioni di persone la risposta classica è attraverso la forza di una figura centralizzata che fa da garante, la risposta bitcoin è invece attraverso la convenienza (da dimostrare) liberamente scelta da milioni di persone che si accordano grazie a un meccanismo ben congegnato di incentivi e controlli reciproci. In questo senso è oggettivamente più facile (dicono alcuni economisti) quantificare la credibilità del dollaro, basta quantificare la credibilità del governo americano (e ognuno qui ha il suo giudizio), mentre con bitcoin prevedere le aspettative di una massa di persone è sostanzialmente impossibile. Il riassunto è che se oggi ho 10k dollari in tasca, riesco a prevedere con una buona approssimazione quale sarà il mio potere d'acquisto tra 5 anni (salvo catastrofi), se ho invece 3 btc nessuno ha la più pallida idea di cosa potrò comprarci: e qui il discorso non è il valore di btc rispetto al dollaro, ma il valore di btc rispetto ai beni che ci servono. Non è molto consolatorio a questo punto pensare che avrò comunque 3 btc su 21 milioni, visto che nessuno vincola questi 21 milioni di token a nessun prodotto del lavoro umano. Bitcoin appare molto più come un nuovo metallo prezioso (nuovo oro digitale) che non esiste nella tavola periodica degli elementi, artificialmente fabbricato dagli uomini, con dei vantaggi, tipo la trasmissibilità via Internet, ecc., ma in questo senso può aspirare al massimo a diventare una riserva di valore in momenti di crisi (in determinati Paesi e per periodi limitati di tempo) e nulla più. Vi linko un video tra i tanti che parlano di questi argomenti (saltate pure i primi 4-5 minuti): https://www.youtube.com/watch?v=VV94VQaKWY8Il prof. di economia Boldrin evidentemente non è un esperto di bitcoin, ma forse in questi contesti non è uno svantaggio confrontarsi con opinioni di chi è fuori da un mondo piccolo come quello delle criptovalute che inevitabilmente ti condiziona. La sua tesi tra l'altro è che il mito dell'autorganizzazione spontanea delle persone che non avrebbero bisogno di una forza dall'alto è miseramente destinato a fallire, lo chiama mito libertario-comunista. |
|
|
|
|
Show Posts
