Premessa: dal punto di vista della sicurezza personale, ogni fase della diffusione delle cryptomonete presenta situazioni di pericolosità diverse (e crescenti nel tempo): Fase 1 (attuale): cryptomonete pochissimo diffuse, quasi nessuno le conosce, è abbastanza sicuro gestirle anche solo personalmente poichè sono pochissimi coloro i quali sono in grado di maneggiarle e quindi sono una frazione trascurabile i possibili ladri che tra l'altro non saprebbero neanche chi derubare Fase 2 : la maggior parte delle persone ha sentito parlare di cryptomonete e sa più o meno cosa sono, quindi inizia a esserci un numero non trascurabile di potenziali ladri; in questa fase però sono ancora una minoranza i detentori di bitcoin, quindi l'atteggiamento "low profile" potrebbe essere sufficiente Fase 3 (se mai ci arriveremo): la maggior parte delle persone detiene dei bitcoin. In questa situazione chiunque è un bersaglio potenziale, 1 testa = 1 salvadanaio. Per non affidarsi alla pura fortuna/casualità di non entrare nel mirino di qualche malintenzionato, sarebbe utile che si diffondesse una prassi analoga a quella attuata con le valute fiat : separare in qualche modo i bitcoin dalla nostra persona fisica, affidandoci a un servizio esterno che ci aiuti nella custodia dei bitcoin proviamo a definire funzioni e compiti di questo ente terzo, poi gli diamo un nome.
Questo ente terzo dovrebbe: 1) non possedere mai i nostri bitcoin, cioè non dovrebbe mai poter disporre delle chiavi private sufficienti per muovere da solo i nostri bitcoin verso altri indirizzi 2) essere in grado di valutare la nostra identità in un posto fisico in mezzo ad altre persone fisiche (l'ente garante non può essere un servizio online, esso ci deve vincolare ad effettuare le transazioni in un posto ben preciso dove sia molto difficile per un ladro controllare la situazione) 3) dovrebbe fornirci immediatamente una transazione firmata (che noi custodiremo) la quale ci permetta di rientrare in pieno possesso dei nostri bitcoin dopo un certo blocco x, casomai l'ente fallisca o scompaia Di fatto il principale compito dell'ente sarebbe quello di custodire una chiave privata e di usarla solo in nostra presenza dopo aver verificato la nostra identità per permetterci di spendere i nostri bitcoin in una situazione di maggior sicurezza per la nostra incolumità. L'uso diffuso di un tale tipo di servizi dovrebbe scoraggiare gli aspiranti ladri così come avviene adesso con le valute fiat. I nostri bitcoin non sarebbe più sempre con noi, ma depositati temporaneamente presso un servizio terzo. Ma deve essere una sorta di luogo fisico, un exchange come quelli attuali non andrebbe bene, dovrebbero avere delle filiali fisiche. |
|
|
|
il punto 3 e' quello che rende tutto estremamente piu' rischioso rispetto alle valute tradizionali:
quando i ladri capirano che si puo' fare SUBITO una transazione senza intermediari (banche polizia ecc)
ma semplicemente "convincendo" il propietario delle crypto a farla, capiranno che rubare delle crypto
e poi farla franca sara' facilissimo.
questo per me e' un punto cardine: con le fiat, a parte un po' di contanti che tieni in casa, il resto per smuoverlo devi coinvolgere qualcuno(banca, carta di credito, assegno, bonifico...) per le crypto, sei TU che alla fin fine custodisci il segreto per come smuoverle, e uno volta venuti in possesso di questo segreto, si puo' fare la transazione. e' questa la sottile distinzione: per le fiat, i ladri sanno benissimo che il grosso dei capitali uno li tiene in banca, e quindi in casa se trovano qualche centinaio di euro in contanti sono gia' contenti. ma con le crypto, sanno che tu nella tua testa sai alcuni segreti che poi permettono di fare le transazioni,
e questa la sottile distinzione che ti mette piu' in pericolo con le crypto rispetto che con le fiat (almeno a mio modo di vedere) Perfetto, quindi per rendere le cripto più sicure abbiamo bisogno di coinvolgere altre persone/enti, eliminando l'associazione immediata tra i miei bitcoin e la mia testa. Già con l'address trappola stai lanciando una richiesta d'aiuto a qualcun altro. La debolezza/pericolosità intrinseca nell'uso e nel possesso dei bitcoin è massima proprio nel momento in cui sono solo io che li gestisco. Ciascuno di noi da solo è vulnerabile. La provocazione dell'hw wallet in una banca (o magari anche solo di una chiavetta contenente un wallet criptato) vuole proprio sottolineare come il condividere la custodia con qualcun altro (che non mi può rubare i bitcoin poichè se il wallet è criptato solo io posso sbloccarlo) aumenta la mia sicurezza personale senza cedere al contempo la possibilità a un terzo di disporre dei miei bitcoin. Se i ladri sapessero che nessuno "tiene con sè" grosse quantità di bitcoin, non li cercherebbero neanche a casa mia, come già succede adesso per le valute fiat. Se invece tutti i miei bitcoin "stanno" nella mia testa, e tutti i possessori di bitcoin si comportassero così, per il ladro ogni testa diventerebbe un salvadanaio potenziale da violare. Sono i bitcoin che attirano i ladri, non la mia testa, perchè allora devo associarli alla mia testa? Meglio tenere ben separate le due cose. EDIT: forse si potrebbe utilizzare un sistema di multisig tipo greenaddress, sistema per il quale la banca o chi per lei detiene una chiave privata che unita alla tua ti permette di spendere i bitcoin. La banca da sola non può spendere i bitcoin. Inoltre essa dovrebbe fornirti una transazione già firmata che insieme alla tua firma ti restituisce i bitcoin tra x blocchi. In questo modo la banca non avrebbe alcun potere di disporre/requisirti i bitcoin (anche se la banca sparisse tu hai la tua transazione) e tu ti vincoleresti a spendere quei bitcoin solo in banca (o in presenza di un qualche garante). |
|
|
|
|
Per me il modo migliore per garantire la mia sicurezza personale è creare le condizioni per non essere aggredito; idee tipo il "low profile" vanno in questa direzione. In questo caso la sicurezza personale e quella dei miei bitcoin coincidono.
Una volta però che il ladro è entrato in casa mia e mi tiene in ostaggio allora il discorso cambia: ovvio che la mia vita è più importante dei miei bitcoin.
Nella sicurezza "preventiva" io ci faccio rientrare anche il fatto di non avere con me in casa mia a disposizione grosse quantità di denaro immediatamente spendibili. Pensiamo ai contanti delle valute fiat: è buona prassi non tenere con sè grossi quantitativi di denaro, questo fatto rende meno appetibile il furto e quindi l'aggressione in generale.
|
|
|
|
Dipende se lo scopo primario è ingannare il ladro oppure costruire un meccanismo che sia ben noto a tutti a priori e che quindi funga da deterrente al furto. Secondo me non è ragionevole trattare le piccole cifre come quelle grandi. Se fosse risaputo che gli importi notevoli sono lenti da smuovere e che questa è una buona prassi adottata dalla stragrande maggioranza dei possessori di bitcoin, sarebbe un grosso disincentivo per un ladro, il quale saprebbe in anticipo di dover rischiare moltissimo dovendo aspettare delle ore. Chiaro che se uno è disposto a sequestrare una famiglia per una giornata intera allora il discorso cambia, ma questi per fortuna sono casi molto rari. Per quanto riguarda il meccanismo dell'address trappola, una volta che il meccanismo diventasse noto, non funzionerebbe più così com'è, dal momento che il ladro potrebbe estorcere questo dato con la forza. Forse sarebbe meglio vincolare a quel punto direttamente tutto il wallet. Riassumendo: per rendere più sicuri i nostri bitcoin (e di conseguenza noi stessi) bisognerebbe accettare di rendere più difficoltosa la loro spesa, aumentando il tempo necessario per la spesa effettiva e vincolando la spesa a qualche allarme. EDIT: un altro metodo potrebbe essere usare un hw wallet (sempre per le grosse cifre) e custodirlo in una cassetta di sicurezza in banca -> eresia?  |
|
|
|
|
Il tempo ritardato tra invio della transazione e la sua prima conferma è fondamentale, la presenza di questo lasso di tempo completa (non sostituisce) il meccanismo dell'address trappola.
L'allarme si innesca solo al momento dell'invio della transazione (o meglio quando questa raggiunge la mempool di qualche nodo monitorato in qualche posto). Se quella transazione venisse immediatamente confermata, allora l'allarme sarebbe inutile: scatterebbe di fatto quando il ladro sta già andando via. A quel punto tanto varrebbe aspettare che il ladro esca di casa e poi telefonare autonomamente alla polizia.
Un allarme utile anche come deterrente dovrebbe scattare ben prima che i bitcoin siano effettivamente spostati, non quasi contemporaneamente.
Per assurdo se la pattuglia della polizia fosse anche sotto casa tua e arrivasse un minuto solo dopo l'invio della transazione, ma quest'ultima venisse accettata in un blocco solo dopo 30 secondi, quei bitcoin potrebbero essere persi per sempre: anche se il ladro venisse catturato, potrebbe farsi qualche mese/anno di prigione senza rivelare mai le chiave private relative ai bitcoin sottratti.
|
|
|
|
|
In aggiunta all'address trappola forse si potrebbe trovare un modo per vincolare una parte di bitcoin in modo che tra il momento in cui viene trasmessa alla rete la transazione per spenderli e la sua prima conferma passino almeno tot blocchi di tempo (ammesso si possa fare).
Secondo me il minimo tempo necessario per smuovere i bitcoin è un fattore di sicurezza fondamentale: se la maggior parte dei bitcoin che ho sono un deposito a lungo termine e non mi servono nelle spese quotidiane, il fatto di dover impiegare delle ore per smuoverli a me non creerebbe problemi, mentre il ladro sarebbe messo in difficoltà. Se invece passasse solo un minuto tra l'invio dell'allarme automatico innescato dell'address trappola e il momento in cui il ladro può scappare perchè ha spostato definitivamente i miei bitcoin, non ci sarebbe un grosso rischio per il ladro.
Oppure servirebbe una super-blockchain con conferme molto più lunghe, utilizzata magari solo per le grosse transazioni.
|
|
|
|
|
Argomento molto interessante.
Le criptovalute sono di fatto contante elettronico, e come una volta i nostri nonni nascondevano il denaro nel materasso, così anche noi oggi con i bitcoin stiamo tornando a pratiche analoghe. Non fidandoci più di una terza parte (banche) ci assumiamo in pieno la responsabilità anche della custodia dei nostri soldi.
Faccio notare inoltre che ci sembra strano che uno custodisca 1 milione di euro in contanti in casa propria o che uno vada in giro con 10 mila euro nel portafoglio, mentre ci sembra "naturale" che una persona memorizzi una password e si porti sempre dietro con sè di fatto la stessa quantità di valore in bitcoin.
Perchè questo doppio atteggiamento? È da tempo che penso che il maggior senso di sicurezza che si prova nel secondo caso derivi solo dal fatto che pochissimi sanno cosa sono le criptovalute, e se anche un ladro entrando in casa mia oggi trovasse un foglio con la chiave privata di un mio indirizzo bitcoin non gli attribuirebbe nessun valore.
Butto lì anche un'altra considerazione. I bitcoin si possono veramente rubare? Essi appartengono a qualcuno?
L'affermazione "io possiedo 1000 euro" è concettualmente diversa dall'affermazione "io possiedo 1 bitcoin".
Quando io infatti acquisto/ricevo una criptomoneta sto essenzialmente vincolando del valore a una stringa segreta (chiave privata o password che sia). Non sto vincolando quel valore alla mia persona.
Voglio dire che se gbianchi riuscisse in qualche modo a trovare la chiave privata di un "mio" indirizzo bitcoin, diventerebbe a tutti gli effetti anche lui "possessore" di quei bitcoin. In che senso quindi starebbe rubando i "miei" bitcoin?
I bitcoin non si possiedono, si vincolano solo a stringhe casuali completamente scollegate dalle identità delle persone. Sono queste stringhe casuali che possiedono i bitcoin, non noi. E non è una differenza da poco.
Invece con i soldi che abbiamo sul conto corrente la situazione è diversa, il conto corrente è intestato a me e solo a me, e se anche qualcuno venisse a conoscenza delle mie credenziali di accesso al conto, comunque potrei far valere il fatto che quei soldi erano "miei" e che mi sono stati quindi estorti/ rubati in qualche modo. In questo caso non sono le credenziali di accesso al conto che possiedono i soldi del conto.
Con le criptovalute è il concetto stesso di possedere/rubare che cambia. Se per assurdo io generassi casualmente un indirizzo associato già a dei bitcoin, questi diventerebbero immediatamente anche "miei".
|
|
|
|
Mi aspettavo dei fuochi d'artificio nell'immediato post fork del 1 agosto(forte dump sotto i 2000$ o il veloce superamento del muro dei 3000$) e invece il btc è rimasto pressochè stabile con valori compresi tra i 2600 e i 2800$!
Prima del fork 1 btc valeva 2700 dollari circa, ora quello stesso btc vale 2700 + 400 dollari. Non è male come aumento... |
|
|
|
Dal mio punto di vista l'indipendenza tecnica dagli sviluppatori di Core è ancora tutta da dimostrare......in questo passaggio ti riferisci a brevetti o capacità tecniche al di fuori di Core?
Mi riferisco soprattutto alle capacità tecniche, di brevetti non so nulla. So invece che finora bitcoin dal punto di vista tecnico è stato un successo (ha sempre funzionato per anni senza particolari problemi) e si è sempre basato di fatto su Core e quindi sui suoi sviluppatori; ad esempio, Wuille, colui che ha ideato segwit, è anche colui che ha implementato la libreria secp256k1 che ha velocizzato di moltissimo tutta l'aritmetica relativa alla curve ellittiche e di conseguenza la verifica delle transazioni. Negli ultimi anni il sofware Core con la sua gestione della blockchain è oggettivamente migliorato parecchio, raggiungendo uno standard qualitativo che ha contribuito alla fiducia crescente (e quindi al valore crescente) di bitcoin. Invece di client alternativi ce ne sono pochi e soprattutto pochissimi miner si fidano di farli girare al posto di Core, ad esempio Unlimited ha avuto in poco tempo almeno 2 gravi bug, e pare che molti miner mentre a parole sostenevano Unlimited nei fatti continuavano a utilizzare Core. Altre valide alternative io non ne conosco. E anche adesso con segwit2x e il software btc1 i miner si stanno accordando di fatto sul codice di segwit, che rimane una proposta tecnica di Core. |
|
|
|
|
Io spero che però le parte "da zero" coinvolga segwit. Se invece la novità consiste solo nell'attivazione al 80% e poco altro, rimarrebbe il fatto che questo nuovo client non porta nessuna novità tecnica rilevante.
Inoltre penso che ci stiano lavorando da un po', non è una modifica fatta in 4 settimane.
|
|
|
|
In rete per esempio c'è anche chi sostiene che si tratti proprio dello stesso segwit, dello stesso codice preso da Core.
Da quanto avevo letto, starebbero scrivendo un nuovo client da zero; a quel punto sarebbe difficile che si trattasse dello stesso codice preso da Core. Tuttavia adesso cercando delle fonti affidabili non sono riuscito a trovare niente. Qualcuno ha un link al codice del progetto, sempre che sia già pubblico? Grazie! btc1 project bitcoin implementation : https://github.com/btc1il problema è: --> Forked from bitcoin/bitcoin altro che da zero... |
|
|
|
Attenzione che il segwit di segwit2x sarà probabilmente diverso tecnicamente dal segwit di Core, e non più legato a doppio filo con le specifiche volute da Blockstream e a loro necessarie. Dovrebbe insomma essere una piattaforma più neutrale.
Poi i dettagli non li conosco; li studierò eventualmente se/quando diverranno operativi.
Questo punto non è affatto chiaro, io non ho trovato fonti affidabili a riguardo (e ovviamente non ho voglia di confrontare i codici sorgente). In rete per esempio c'è anche chi sostiene che si tratti proprio dello stesso segwit, dello stesso codice preso da Core. Se così fosse, non sarei granchè sicuro neanche dell'hard fork a 2 MB tra qualche mese. Dal mio punto di vista l'indipendenza tecnica dagli sviluppatori di Core è ancora tutta da dimostrare. |
|
|
|
E pensare che la proposta segwit + hard fork a 2 MB non è niente di nuovo sotto al sole, cose già viste e riviste negli ultimi 2 anni, di fatto avevano già trovato un accordo verbale su qualcosa di simile molto tempo fa, con la differenza che allora gli sviluppatori di Core erano coinvolti mentre adesso si dovrebbe cambiare software.
non mi va di studiare perche' qui di tecnico non c'e' piu' nulla da mesi e mesi. se ricordi quando insistevo (fino alla noia ammetto) sul concetto che bitcoin e' diventato un sistema governato da oligarchie... Quello che a me preoccupa maggiormente è che non solo il potere è concentrato nelle mani di pochi, ma anche l'intelligenza e/o le capacità tecniche (e probabilmente le due cose sono correlate). E' possibile che alla fine, a parte forse Bitcoin Unlimited, nessuno al di fuori del team di Core sia riuscito a proporre qualcosa di tecnicamente valido e alternativo? Se alla fine si approvasse veramente segwit, sarebbe la dimostrazione che non ci sono idee al di fuori di Core capaci di coagulare consenso e di convincere gli stessi miner che sono alla fine quelli maggiormente investiti in questa situazione; ad esempio, anche ai tempi del massimo consenso per Unlimited, pare che in realtà i miner facessero girare Core con una dichiarazione solo formale di appoggio a Unlimited (il quale tra l'altro ha patito pure qualche grave bug). Se non ci sono alternative tecniche degne di note e finchè i miner stessi non si fideranno in pieno di altri sviluppatori e altri software, alla fine è chiaro che Core avrà sempre un certo potere; ma sono i miner stessi che glielo hanno concesso finora (e dal mio punto di vista non partono bene se iniziano adesso implementando proprio il cavallo di battaglia di Core). Non sono certo un sostenitore degli sviluppatori di Core, ma i miner che dopo tanto indecisionismo alla fine approvano esattamente quello che aveva proposto loro il team di Core ci hanno fatto perdere in questi ultimi tempi solo tempo e soldi con le loro fee stratosferiche, e non mi ispirano più di tanto. Il banco di prova sarà comunque il loro nuovo software, un conto è dichiarare di appoggiare un'idea, un conto è rischiare di perder soldi veri in prima persona facendo girare effettivamente un software nuovo. |
|
|
|
@arulbero @stemby grazie ragazzi.
Scusatemi ma di sbattermi ad andare in giro a leggere/studiare sta' roba proprio non mi va.
Anch'io negli ultimi tempi ho perso la voglia di approfondire tutti questi aspetti, ho solo la netta sensazione che il prossimo mese sia davvero decisivo questa volta, e se hai qualcosa investito conviene tenersi giusto un attimo aggiornati. E pensare che la proposta segwit + hard fork a 2 MB non è niente di nuovo sotto al sole, cose già viste e riviste negli ultimi 2 anni, di fatto avevano già trovato un accordo verbale su qualcosa di simile molto tempo fa, con la differenza che allora gli sviluppatori di Core erano coinvolti mentre adesso si dovrebbe cambiare software. |
|
|
|
ho visto su coindance che nella votazione ultimi 144 blocchi (la media giornaliera)
hanno votato il 66% su segwit2x... se non erro nessuna di queste n-mila diavolerie
e' mai giunta ad un punteggio tanto alto.
sarebbe ? un soft fork ? un hard fork ? il compromesso storico AKA le convergenze parallele ?
che percentuali deve raggiungere per passare ?
Provo a rispondere io in breve: - segwit originale è un soft fork (BIP 141 -> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) proposto dagli sviluppatori di Bitcoin Core, prevede soglia di attivazione del 95% e segnalazione tramite il bit 1 - segwit2x (noto anche come New York Agreement -> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77) non è invece appoggiato da Bitcoin Core, ma è una proposta mista soft-hard fork partita dai miner e in particolare è appoggiata da Bitmain. Questa proposta consiste inizialmente in un segwit attivato con una soglia del 80% e segnalato in modo diverso dall'originale (tramite bit 4), seguito dopo 6 mesi da un hard fork con un aumento a 2 MB della dimensione massima dei blocchi. I miner stanno preparando un software apposito, denominato btc1: A software project, btc1, which is addressing the New York Agreement, has been under active development and will likely deliver a consensus rule change plan called SegWit2x. The testnet5 for SegWit2x is already alive. Alpha version of the software will be released on June 16th and everything is still on time. Follow the github here: https://github.com/btc1Read a reddit discussion about it here: https://www.reddit.com/r/btc/comments/6h1wpr/segwit2x_a_summary/Al momento non è chiaro come si comporteranno i sostenitori di UASF (User Activated Soft Fork, BIP148) qualora segwit2x venisse attivato prima del 1 agosto (rinuncerebbero al loro fork o no?); inoltre il software btc1 non è ancora pronto, e non è chiaro nemmeno come verrebbe attivato l'eventuale hard fork da 2 MB: https://medium.com/@jimmysong/segwit2x-what-you-need-to-know-b747e6326266Da questo articolo si evince inoltre che la percentuale che riporti tu (al momento salita al 68,8% ) è solo una indicazione mediante stringa nella coinbase, visto che il sofware apposito in realtà ancora non è stato rilasciato (al momento è quindi da intendersi come una dichiarazione d'intenti). Mi sembra comunque che qualcosa dovrebbe succedere a breve, nel bene o nel male. |
|
|
|
Another interesting thing is: how many private keys I have to check to get all addresses? There are "only" 2^160 addresses and 2^256 private keys, so there are 2^96 private keys for each address.
Nope. There are 2^97 private keys for each address. Proof is left to the mathematician. Ok, for the sake of semplicity I didn't want to talk here about compressed/uncompressed keys ... |
|
|
|
The birthday problem can be applied to estimate the probability of a collision given the size of a hash function. ......... In this case we should be able to safely use up to 2 103 Bitcoin addresses before collisions would be a problem. Another interesting thing is: how many private keys I have to check to get all addresses? There are "only" 2^160 addresses and 2^256 private keys, so there are 2^96 private keys for each address. Expected Number of Hashes until all Slots of a Hash Table Are Occupied. The expected
number of items needed to fill all slots of a hash table of size k is between klnk+1/2k and klnk+k.
# private keys = # items = n # addresses = # slots = k To get all k = 2^160 addresses, it is enough to use k*lnk+k = 160*2^160 + 2^160 = 161*2^160 = 2^(167.32) keys. If you use only 2^160 private keys, you will have about 63% of all addresses: Expected Number of Empty Slots in Hash Table. In hashing n items into a hash table with
klocations, the expected number of empty locations is k(1−1/k)^n.
Infact: # empty locations (addresses never generated) = 2^160 (1-1/2^160)^(2^160) = 2^160 * 1/e = 0.37*2^160. You could find other interesting formulas like this one: The Expected Number of Collisions in Hashing. In hashing n items into a hash table with
k locations, the expected number of collisions is n−k+k(1−1/k)^n.
here --> https://math.dartmouth.edu/archive/m19w03/public_html/Section6-5.pdfWhat is the maximum key generation rate you have every recorded, even for a short period of time?
I remember about 2500 Mkeys/s. |
|
|
|
Hi, I want to exploit the speed of the field operations in libsecp256k1 to make faster operations modulo p (p=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F). I wrote a simple program to compute a multiplication of two 256-bit numbers. My code performs 100M times the mult: Gx*Gy mod p. There are 2 versions: A (gmp library), B (secp256k1 library) The problem is that at the moment I can get better results with gmp library than libsecp256k1 (at least +10%): Program A (gmp library): ---@ubuntu:~/src/var/mul$ time ./a.out
Result: fd3dc529c6eb60fb 9d166034cf3c1a5a 72324aa9dfd3428a 56d7e1ce0179fd9b
real 0m5.399s
user 0m5.324s
sys 0m0.012s
Program B (secp256k1 library): ---@ubuntu:~/src/var/mul$ time ./a.out
Result: fd 3d c5 29 c6 eb 60 fb 9d 16 60 34 cf 3c 1a 5a 72 32 4a a9 df d3 42 8a 56 d7 e1 ce 1 79 fd 9b
real 0m6.076s
user 0m5.988s
sys 0m0.004s
Shouldn't it be the other way around? Is there something wrong in my code? Program A (gmp library) :#include <stdio.h>
#include <stdlib.h>
#include <gmp.h>
inline void red(unsigned long int* a) {
...> performs "a mod p"
}
int main(){
unsigned long int i;
unsigned long int a[8];
unsigned long int Gx[4] = {0x59f2815b16f81798, 0x029bfcdb2dce28d9, 0x55a06295ce870b07, 0x79be667ef9dcbbac};
unsigned long int Gy[4] = {0x9c47d08ffb10d4b8, 0xfd17b448a6855419, 0x5da4fbfc0e1108a8, 0x483ada7726a3c465};
for(i=0;i<100000000;i++) {
mpn_mul_n(a, Gx, Gy, 4); // #1M
red(a);
}
printf("Result: %lx %lx %lx %lx\n", a[3], a[2], a[1], a[0]);
return 0;
}
//Compile with:
//gcc -O2 -I secp256k1/src/ -I secp256k1/ mul.c -lgmp
#include <stdio.h>
#include <stdlib.h>
#include "libsecp256k1-config.h"
#include "include/secp256k1.h"
#include "secp256k1.c"
int main(){
const unsigned char Gx[32]={0x79,0xBE,0x66,0x7E,0xF9,0xDC,0xBB,0xAC,0x55,0xA0,0x62,0x95,0xCE,//
0x87,0x0B,0x07,0x02,0x9B,0xFC,0xDB,0x2D,0xCE,0x28,0xD9,0x59,0xF2, //
0x81,0x5B,0x16,0xF8,0x17,0x98};
const unsigned char Gy[32]={0x48,0x3A,0xDA,0x77,0x26,0xA3,0xC4,0x65,0x5D,0xA4,//
0xFB,0xFC,0x0E,0x11,0x08,0xA8,0xFD,0x17,0xB4,//
0x48,0xA6,0x85,0x54,0x19,0x9C,0x47,0xD0,0x8F,0xFB,0x10,0xD4,0xB8};
secp256k1_fe a,b,r;
unsigned char c[32];
secp256k1_fe_set_b32(&a, Gx);
secp256k1_fe_set_b32(&b, Gy);
for(i=0;i<100000000;i++) { //100 000 000
secp256k1_fe_mul(&r, &a, &b);
//secp256k1_fe_normalize_var(&r);
}
secp256k1_fe_get_b32(c, &r);
printf("Result: %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x\n", //
c[0],c[1],c[2],c[3],c[4],c[5],c[6],c[7],c[8],c[9],c[10],c[11],c[12],//
c[13],c[14],c[15],c[16],c[17],c[18],c[19],c[20],c[21],c[22],c[23],c[24],//
c[25],c[26],c[27],c[28],c[29],c[30],c[31]);
return 0;
}
|
|
|
|
verrebbe comodo avere un po' di statistiche per capire come sta andando
la distribuzione dei conti attivi...
in pratica per capire se c'e' davvero un fuggi fuggi o sono semplici dinamiche
di notizie a caso+speculazioni varie.
sapete se ci sono in giro statistiche tipo quelle che facevo io ?
Dettagliate come le tue no. Qui c'è qualcosa solo sulla distribuzione dei bitcoin per indirizzi: https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html |
|
|
|
|
Show Posts
