Now let's look at something I just pasted from JeanLucPons Kangaroo: dy.ModSub(p2y,p1y);
_s.ModMulK1(&dy,&dx[g]);
_p.ModSquareK1(&_s);
rx.ModSub(&_p,p1x);
rx.ModSub(p2x);
ry.ModSub(p2x,&rx);
ry.ModMulK1(&_s);
ry.ModSub(p2y);
It roughly translates to (((p2y-p1y) * dx)^2 - p1x - p2x) = rx and (p2x - (((p2y-p1y) * dx)^2 - p1x - p2x)) * ((p2y-p1y) * dx) - p2y = ry That's 6 subtractions, 3 multiplications, and one squaring in total. What if there were a way to optimize this calculation through bit shifts and the like, just like how libsecp256k1 multiplies two numbers with not only muls and adds but also bitwise arithmetic? We have a pattern: (a - b) * c which occurs twice in this calculation in total. Rather than consuming a subtraction and multiplication, I wonder if there was a way to calculate them at once (not just concatenate them together). The point addition formula is: Point Addition for X₁ ≠ X₂ #
s = (y2 - y1) / (x2 - x1)
x3 = s ** 2 - x1 - x2
y3 = s * (x1 - x3) - y1
If you have to generate a batch of public keys with same distance, for example B = 10*G, 15*G, 20*G, 25*G ... you can generate only x coordinates (y coordinates are not necesssary) and compute only 1 inversion for the entire batch B; you don't need Montgomery ladder, projective coordinates, 5x52 limbs, ... To generate 1000 public keys you need to compute: 1000 squares --> s**2 1000 multiplications (y2-y1) * 1/(x2-x1) 1 inversion 1500 multiplications --> to get 1/(x2-x1) tot: 2500 mult + 1000 sqr + 1 inv to compute 1000 public keys -> 2.5 mul + 1 sqr + 4 subtractions for each key. |
|
|
|
Crescono quindi nel tempo anche gli usi dinamici di bitcoin. Sarebbe bello distinguere, all'interno di questi, quelli legati al trading (es tx da e per exchange) da tutti gli altri. Se ho tempo cerco qualcosa nell'archivio di glassnode anche in questo senso.
Sarebbe bello anche distinguere gli utxo per importi. E' chiaro che un conto sono poche migliaia di satoshi, importi già creati per essere spesi facilmente (come succede su LN), un conto sono milioni di satoshi, nel qual caso propenderei per una più spiccata tendenza alla conservazione. |
|
|
|
...
Ma non posso, per definizione, rendere un sistema centralizzato immune dal problema dell'avere un ente centrale che lo controlla,
e che quindi prima o poi approfittera' di questo potere. E la controparte di non dovermi fidare di un sistema centralizzato...
e' che devo fidarmi di me stesso, e quindi devo acquisire (anzi tornare ad acquisire) una consapevolezza per farlo.
...
So benissimo che quasi tutti non leggeranno oltre la prima riga, non si interesseranno di approfondire e capire, quindi non acquisiranno consapevolezza ma
si preoccuperanno solo di arricchirsi velocemente, smania che poi si tradurra' nel fare arricchire velocemente altri e rimanere con un pugno di mosche,
ma se anche solo 5 persone su 100 avranno compreso il messaggio, ed incrementato la loro consapevolezza, io credo che avremo fatto un'ottima opera.
Non so se io ho compreso completamente il tuo messaggio, ma ho letto tutto il post. Cosa intendi con " tornare ad acquisire una consapevolezza" ? Potresti articolare meglio questo concetto? Intendi tornare a fidarsi di se stessi in una società che invece tende, a causa della sempre maggiore specializzazione del lavoro, a produrre in molti campi una separazione tra pochi esperti da una parte e il resto della massa di incompetenti / inconsapevoli ? Una massa di persone che delegano la competenza, la conoscenza, la fiducia e quindi anche la consapevolezza ad autorità esterne / Stato ... ? Giusto per capire, visto che attribuisci come merito fondamentale di bitcoin proprio quello di spingere verso una maggiore "consapevolezza". |
|
|
|
ecco questo e' un esempio di quel che intendevo io https://decrypt.co/117214/99-people-will-lose-crypto-storing-self-custody-binance-ceo-changpeng-zhao
“For most people, for 99% of people today, asking them to hold crypto on their own, they will end up losing it,”
he said in a Twitter Space discussion held on Wednesday.
Questo e' vero FUD. Questo e' tradire completamente il messaggio rivoluzionario di Bitcoin. Non devi custodire i tuoi averi in autonomia, perche' li perdi praticamente di sicuro (ergo invece dalli a noi exchange, cosi' sei molto piu' al sicuro) Per quanto mi riguarda, l'affermazione: "la maggioranza delle persone non è in grado di custodire in autonomia i propri bitcoin" è corretta, non mi esprimo ovviamente sulle percentuali esatte, ma sul senso generale io concordo. Che poi la conseguenza di questa affermazione non sia automaticamente: "allora devo affidare i miei btc a un exchange" quanto piuttosto: "allora scelgo una persona fidata (marito/moglie/sorella/amico) che mi aiuti a conservarli" è un altro discorso. |
|
|
|
Il prezzo per me è molto importante ma continuo a dire che non è tanto rilevante " a quanto arriva" ma "perchè" e "come" ci arriva.
Ad esempio, andare a 800$ perchè è stato scoperto un bug catastrofico che permette a tutti di fare il double spending sarebbe una cosa totalmente diversa da andarci perchè FTX è fallita.
Scendere del 70% perchè LN è troppo complicato da utilizzare, poco conveniente e funziona peggio delle carte di credito sarebbe cosa molto differente da scendere della stessa percentuale perchè Powell alza i tassi o Musk preferisce dogecoin.
Nel primo caso sono fattori critici "reali", nel secondo sostanzialmente speculativi.
Sicuramente BTC ha retto molto meglio di quanto mi potessi aspettare, per la portata dell'evento io pensavo che avremmo perso un 40-50%, così non è stato, una volta tanto una bella notizia all'interno di una negativa. Forse da un lato ha giocato a favore di BTC il fatto che eravamo già a livelli abbastanza bassi e quindi le vendite sono state limitate, se gli altarini fossero stati scoperti quando BTC stava a $60k probabilmente, in %, avremmo visto un altro genere di calo.
Il punto per me è questo: se 69k dollari è una quotazione gonfiata al rialzo, ci sta anche la discesa a 15k, una quotazione probabilmente eccessivamente sgonfiata: la forza della speculazione in questo ribasso si è basata molto anche sulla precedente euforia. Ma se dall'attuale livello (già percepito come basso da molti) precipitassimo a 800 dollari, allora la domanda sarebbe: come mai la speculazione ha un potere così forte? Non sarà che ci sarà qualcosa che non va nei fondamentali, i quali non tengono su la quotazione come dovrebbero, anche se non lo vediamo? Perchè tutti ma proprio tutti svendono? Quindi dal mio punto di vista, anche in assenza di ragioni 'serie', un movimento troppo importante sarebbe un segnale dal valore informativo in sè, sufficiente a farmi dubitare dell'intero progetto. Io ad esempio davo abbastanza per scontato che non saremmo scesi troppo in questo ultimo mese nonostante le ultime vicende, se il progetto è valido ci devono essere dei limiti che la speculazione non è in grado di superare. E questa volta eravamo già molto vicino a questi limiti, come osservato da Ale88. Ma se questi limiti venissero superati, per quanto mi riguarda io metto in dubbio il progetto stesso. |
|
|
|
Correggimi se sbaglio ma se ho 1 btc che giace nel mio wallet da 1 anno e tu hai 1 btc che giace nel tuo wallet da 1 giorno, la probabilità che uno dei due venga mosso nel corso, ad esempio, della prossima settimana dovrebbe essere, matematicamente parlando e a parità di altri fattori, esattamente la stessa.
Esatto, non dovrebbe contare da quanti giorni è fermo. Per fare un'analogia: ogni giorno per decidere se spendo il mio btc effettuo un giro di roulette: se esce 0, spendo (p = 1/37), se non esce (1-p = 36/37) non lo spendo; lo stesso fai tu con la tua roulette. E' chiaro che, per l'indipendenza delle uscite dei numeri, anche se nel tuo caso sono 365 giorni che non esce 0 mentre nel mio è solo 1 giorno, la probabilità che proprio oggi esca 0 nella tua roulette rimane esattamente 1/37, cioè la stessa che esca 0 oggi nella mia roulette. Invece i dati della blockchain dicono che è il secondo, quello fermo da appena un giorno, che ha molte più probabilità di venire mosso nei successivi 7 giorni.
L'altra cosa interessante è che la probabilità tende a stabilizzarsi superato un certo valore che corrisponde all'incirca a 6 mesi.
1 btc fermo da 8 mesi ha una probabilità di essere mosso più simile ad uno fermo da 8 anni che ad uno fermo da 4 mesi, nonostante l'intervallo tra i primi tempi sia molto più lungo.
Ok, quindi ho interpretato male la tua spiegazione: Questo grafico è bellissimo: mostra come la probabilità che un UTXO venga speso nei successivi X giorni dalla sua creazione (dove x, a seconda della curva, è uguale a 7,14,30,60,90 e 120 giorni) è funzione (decrescente) dell'anzianità dell'UTXO.
...
se un utxo oggi ha 200 giorni di vita, quel grafico mostra la probabilità che venga speso nei prossimi 7 giorni; si tratta quindi già di una probabilità condizionata; se la distribuzione fosse realmente geometrica, tutte quelle linee allora dovrebbero essere orizzontali; il fatto che almeno inizialmente non lo sono indica che c'è una forte correlazione tra la non spesa immediata e la data della futura spesa: se non spendo nella prima settimana, aumenta notevolmente la possibilità che non spenda per un lungo periodo. E' come se, continuando l'analogia con la roulette, dopo i primi 7 roll, se non è uscito lo zero, passassi dalla roulette alla tombola (supponendo che ci sia anche lo 0) per stabilire se spendere o meno: passo dalla mentalità speculativa a quella da hodler: improvvisamente la probabilità di spendere ogni giorno passerebbe da 1/37 a 1/91. Dopo molti giorni la probabilità di spendere nella prossima settimana è la stessa, perchè a quel punto uso sempre la stessa tombola. In realtà come dici tu c'è chi usa la roulette sin dall'inizio (anzi, usa una semplice moneta testa: spendo / croce: non spendo) e quindi finisce per spendere subito, e chi usa la tombola sin dall'inizio (ed è lui che produce quindi gli utxo più anziani). |
|
|
|
Questo grafico è bellissimo: mostra come la probabilità che un UTXO venga speso nei successivi X giorni dalla sua creazione (dove x, a seconda della curva, è uguale a 7,14,30,60,90 e 120 giorni) è funzione (decrescente) dell'anzianità dell'UTXO.
...
In altre parole quando dei btc sono spesi è alta la probabilità che vengano rispesi velocemente. Se questo non accade, la probabilità che vengano rispesi cala velocemente con l'andare del tempo.
La cosa interessantissima è che, indipendentemente dall'intervallo temporale considerato e quindi della curva rappresentata sul grafico, le linee tendono a "diventare orizzontali" tutte dopo circa 6 mesi (linea tratteggiata verticale).
In media, dopo 6 mesi, la probabilità che i bitcoin vengano rispesi nei successivi X giorni (dove x va da 7 a 120 gg) si stabilizza e diventa quasi costante.
Dal grafico che hai postato non si riesce a capire bene se non si tratti piuttosto, in prima approssimazione, di una classica distribuzione geometrica / esponenziale distribuzione discreta -> https://it.wikipedia.org/wiki/Distribuzione_geometricadistribuzione continua -> https://it.wikipedia.org/wiki/Distribuzione_esponenzialeLa distribuzione geometrica è la distribuzione che stima il tempo di accadimento di un evento casuale, ad esempio il momento di rottura di un componente elettronico, un componente che si suppone senza usura; è l'unica distribuzione 'senza memoria' : la probabilità che un oggetto si rompa fra 3 anni se ha già 2 anni di vita è uguale alla probabilità che un oggetto identico ma nuovo si rompa fra 3 anni. Ogni giorno che passa la probabilità che si rompa il componente è la stessa, ma la probabilità complessiva ovviamente diminuisce. In pratica questo tipo di distribuzione descrive il tempo di accadimento di un evento casuale (la rottura di un componente o la spesa di un UTXO nel nostro caso) supponendo che il tempo di questo accadimento non sia influenzato dal tempo che è già passato rispetto al precedente accadimento. Se così fosse, la probabilità che un utxo appena creato oggi venga speso dopo più di 30 giorni sarebbe uguale alla probabilità che un utxo venga speso fra più di 30 giorni a partire da oggi anche qualora sia stato creato già da 1 giorno / 1 mese / 1 anno. Insomma, mi pare che il fatto che la funzione sia decrescente sia scontato, ma potrei sbagliarmi. Se ogni utxo ha una probabilità uniforme p (cioè uguale per tutti i giorni), con 0 < p < 1, di essere speso ogni giorno, allora: la probabilità che sia speso nel primo giorno è p, la probabilità che sia speso non nel primo giorno ma nel secondo giorno è (1-p)p < p la probabilità che sia speso nel terzo giorno è (1-p)(1-p)p < (1-p)p la probabilità che sia speso nel k-esimo giorno è (1-p)^k * p quindi questa funzione deve essere per forza decrescente, no? Se invece ha un asintoto orizzontale non è decrescente, ma dal grafico è difficile valutare la distribuzione di valori così vicini a zero. EDIT: qual è la probabilità che un utxo di 300 giorni sia speso entro 7 giorni / 14 giorni / 21 giorni dalla sua creazione? 0, per definizione di giorni di vita di un utxo. Non è che il tuo grafico nella parte di destra indica semplicemente questo fatto? |
|
|
|
In quel caso è anche possibile che Btc torni di nuovo a 3 cifre come giustamente dici, ma..... dov'è l'icona che fa le spallucce ?  Il mondo è bello perché è vario. A me personalmente importerebbe molto se BTC tornasse a 3 cifre perché mi piacerebbe potermi togliere qualche sfizio prima o poi nella vita, sarei più contento con una bella casetta piuttosto che morire con BTC a $30 però intanto la blockchain funziona perfettamente. Pensiero egoista, lo so, ma la vita è solo una. Sostenere che il prezzo di BTC non abbia alcuna importanza ovviamente è una forzatura. In questo momento non cambia nulla se 1 bitcoin vale 14k, 18k o 25k dollari, però la prospettiva cambierebbe eccome se precipitasse a 800 dollari, perchè questo fatto costituirebbe un'espressione storica sulla (s)fiducia in bitcoin non attribuibile a una semplice fluttuazione speculativa. La stessa cosa si potrebbe dire se fra 3 mesi la quotazione raggiungesse 200k dollari. Quindi concordo che in generale il prezzo spot non deve contare rispetto ad altri fattori fondamentali, ma sempre fino a un certo punto, visto che parliamo di un oggetto il cui valore sta nella sua capacità (tecnicamente fondata) di ispirare fiducia nelle persone. Vorrei essere più chiaro: se il prezzo calasse 'troppo' sarebbe un segnale che qualcosa non va in bitcoin, non nelle persone. Perchè o bitcoin suscita fiducia nelle persone, o non lo fa, nel qual caso avrebbe in gran parte fallito la sua funzione. Siamo comunque ancora ampiamente dentro le fluttuazioni 'senza importanza' di prezzo, magari verso la parte bassa della forchetta ma ampiamente all'interno. |
|
|
|
In the multiplication function of the libsecp256k1 repository at Github, there is a stranger constant that the carry is multiplied with in various steps. It is referenced as the constant R and has the value of 0x1000003d10. Everything else is more or less explanatory. But what is this constant supposed to mean? Remainder?  Example: https://github.com/bitcoin-core/secp256k1/blob/master/src/field_5x52_asm_impl.hIt is pretty simple. Imagine you want to multiply 2 numbers mod 97 (100 - 3) and you have only 2 digits in memory: for example 23*49 mod 97 (note that 97 = 100 - 3) 23*49 = 1127 how to compute efficiently now 1127 mod 97 ? the idea is: 1127 = 11*100 + 27 a) 1127 mod 100 = 27 (the lowest 2 digits of the multiplication, remember, you don't have space for 4 digits) b) then multiply the highest digit 11 * 3 = 33 c) result = 33 + 27 = 60 explanation --> 1127 = 11*100 + 27 = 11*(97 + 3) + 27 = 11*97 + 11*3 + 27 = 11*3 + 27 mod 97 Same thing with a*b mod p p = 2*256 - Ra*b = (highest 256 bits of a*b) * 2^256 + lowest 256 bits of a*b a) lowest 256 bits = (a*b) mod 2^256 b) then compute (highest 256 bits)* Rc) result = (highest 256 bits)* R + (a*b) mod 2^256 explanation --> result = a*b = highest * 2^256 + lowest = highest * (2^256 - R) + highest * R + lowest = (highest * R + lowest) mod p EDIT : R is used for fast reduction of the result of the multiplication, from 512 bits to 256 bits, because R is small compared to 2^256 |
|
|
|
Yeah, everything i said is in case the key IS even.
If there existed such method to determine whether point is even or odd that would break ecdsa security.
Or if there existed a method to know if a key is 'greater' than a certain key that would break ecdsa security. If I search a key x in the range [1, ..., 2^80] and I know that the key x is greater than 2^79 too, then I can work only on range [2^79,..., 2^80]. Better: if I know that the key x is a multiple of 3 (it is divisible by 3), then I can remove 2/3 of the possible values. where one can find your renowned ecc fast library code base?
"renowned"  ? I wrote that library 5 years ago to build my version of vanitygen and BSGS. It's a library tailored to generate a bunch of public keys with same distance very quickly, like: 1G , 2G, 3G ,4G, ... or 5G, 15G, 25G, 35G, ... where G is the generator of the curve. Each public key is an array of 4 x 64 bit. Each operation is mod p. I have to clean the code before I can make it public. If I'll have time, maybe by the end of the year. |
|
|
|
So, the only way to get the private key of a public key, is simple guessing it/brute forcing it - Which can take forever to compute at some key ranges.
But What if we could reduce the key range? For example, if a public key is even, you can multiply it by 57896044618658097711785492504343953926418782139537452191302581570759080747169
And get a new public key, which is in the original range -1-bit range, which its private key is / 2 the value of the original private key.
It is like: guess a number between 1 and 10. If the correct key is 8, and you divide it by 2, you have to perform only 4 steps: 1,2,3,4 -> found! But you don't know if the correct key is even or odd. Knowing that is equal to have an additional information that let you to reshrink the search space. But again you don't have this information, then you cannot reduce the key range. If you divide each key by 2: [1 ... 10] -> [1/2, 2/2, 3/2, ... , 8/2, 9/2, 10/2] your range has the same size, it is not 'smaller'! Each of these 10 keys may be the correct one. |
|
|
|
sì, ma dice: "In questo modo la successiva plusvalenza futura sarà determinata a partire da questo valore come valore d'acquisto. Starà al singolo contribuente, a questo punto, farsi i conti su quale sia la strada più conveniente da seguire"
Parla di successiva plusvalenza, quindi immagino al momento della vendita.
Ti torna?
La plusvalenza è per forza futura, in quanto a gennaio per definizione la plusvalenza sarà 0. L'imposta del 14% è sul valore in possesso a gennaio 2023. A logica si dovrebbe pagare solo alla vendita ... Supponiamo il prezzo di gennaio sia 16k euro. Se l'imposta sulla plusvalenza rimane del 26%, conviene aderire a questo reset qualora il prezzo di carico x sia tale che il 14% di 16000 = 2240 < 26% di (16000 - x) ovvero x < 7385 euro. Con un prezzo di carico di 7385 euro, pagare il 26% di 16000 - 7385 = pagare il 14% di 16000. |
|
|
|
EDIT: leggendo il link a me sembra che il 14% faccia riferimento al capital gain, non al possesso di un bitcoin!
Di fatto dicono: se fai un gain e non sei in grado di dimostrare quanto hai pagato, te lo contiamo zero. Però, se vuoi, consideriamo il 14% dal prezzo del 1/01/2023...
Ho capito male?
Io ho letto solo l'artico di hwupgrade, che dice: Con l'articolo 32 della bozza, però, viene messa a disposizione una strada alternativa: "resettare" il valore d'acquisto alla data del 1 gennaio 2023, con il pagamento di un'imposta sostitutiva del 14% sul valore totale in possesso. In questo modo la successiva plusvalenza futura sarà determinata a partire da questo valore come valore d'acquisto. Starà al singolo contribuente, a questo punto, farsi i conti su quale sia la strada più conveniente da seguire.
Quindi si parla del 14% sul valore totale, in pratica per chi ha ottenuto 1 bitcoin gratis, invece di pagare il 26% sulla plusvalenza da 0 a 16k euro, deve pagare solo il 14% sulla plusvalenza da 0 a 16k. Se invece il bitcoin l'hai acquistato a 20k euro, allora è chiaro che per te diventa una specie di tassa sul possesso. Non ho capito inoltre se questo valore fittizio di gennaio 2023 si può 'resettare' al momento della vendita o se va fatto comunque nella prossima dichiarazione. |
|
|
|
.....
That is 4.5 Petakeys per second this will solve 64 bits in 4,094 Seconds
...
In that post I show a test solving the puzzle 70 with a single thread and near 32GB of RAM it took me 9 hrs to solve it
Ok, thanks for the answer. On my current laptop (i7-12700H + 16GB), with my software, I can scan an entire 2^60 range in less than 2 minutes (116 seconds), using 8 GB. To scan the entire 2^60 range, we need to compaire 2^29 baby steps against 2^30 giant steps. I create a table for baby steps: 2^29 elements (64 bits each: 32 bits for the private key + 32 bits for the x-coordinate) -> total 2^35 bit -> 2^32 bytes -> 4 GB; I use 8 GB of Ram for the table (the double) to minimize collisions (half table is empty). Then I compute 2^30 giant steps. My program doesn't write / read on ssd. It takes 120 seconds to compute (2^29 bs + 2^30 gs) , about 30 seconds for the table and 90 seconds to compute 2^30 elements and check in the table. The speed to create the keys is about 2^24 keys/s, the check against the table increase the time by 50%. To work in higher range the program needs to create multiple table; for example, to cover an entire 2^64 range, the program splits the 2^31 baby steps in 4 table of 2^29 elements. Each table is compared against 2^32 giant steps. So it computes: 4 * (2^29 bs + 2^32 gs) = about 16 the time to explore a 2^60 range (2^29 bs + 2^30 gs), then 32 minutes. If I had the double of ram, I would need to compute only 2 * (2^30 bs + 2^32 gs) = about 8 the time to resolve a 2^60 range (2^29 bs + 2^30 gs) : 2minutes * 8 = 16 minutes. In a small range, it seems the my program is faster than yours, on higher range the viceversa. |
|
|
|
|
How do you compute the speed?
If you search a 2^40 interval in 1 s you compute 1 Terakeys/s ?
How long it takes to scan a 2^64 interval (with 1 thread)?
|
|
|
|
Qui: https://www.hwupgrade.it/news/web/criptovalute-e-tasse-nella-legge-di-bilancio-2023-arriva-l-inquadramento-fiscale_112073.htmlsi dice che: - la tassazione sulle plusvalenze (come "redditi diversi") è del 26% (sopra i 2000 euro), tutte le plusvalenze sotto i 2000 euro per anno sono esentasse - le operazioni di conversione tra criptovalute diverse non costituiscono un evento fiscalmente rilevante - a partire dal 1 gennaio 2023 le cripto attività dovranno essere indicate nel quadro RW della dichiarazione dei redditi a solo scopo di monitoraggio fiscale - chi non ha mai dichiarato il possesso può regolarizzare la propria posizione presentando una apposita autodichiarazione indicando la quantità detenuta alla fine di ogni anno di imposta e versando una sanzione dello 0,5% per ciascun anno sul valore non dichiarato - allo 0,5% si aggiunge il 3,5% nel caso siano stati realizzati redditi - se non si è in grado di documentare il prezzo di acquisto, si può resettare il valore di acquisto alla data del 1 gennaio 2023, con il pagamento di un'imposta sostitutiva del 14% sul valore totale in possesso. La plusvalenza futura verrà calcolata a partire da questo valore. EDIT: In base a questa norma, per regolarizzare un bitcoin mai dichiarato servono: (i primi dati che ho trovato in rete, non saranno precisi): data valore 0,05% 31/12/2022 -> 16000 euro -> 80 euro per bitcoin 31/12/2021 -> 41000 euro -> 205 euro per bitcoin 31/12/2020 -> 23500 euro -> 118 euro per bitcoin 31/12/2019 -> 6400 euro -> 32 euro per bitcoin 31/12/2018 -> 3300 euro -> 17 euro per bitcoin totale = 452 euro a questi 452 euro, se non si possiede la documentazione relativa alla spesa di acquisto, va aggiunto il 14% del valore di gennaio 2023 (ipotizziamo sempre 16000 euro): 2240 euro In pratica per regolarizzare 1 bitcoin mai dichiarato servono circa 2700 euro, circa il 17% di 16000 euro, più di 1/6 del valore attuale. |
|
|
|
Thank you!
Do you happen to have a function for multiplication as well?
#define MultiplyWordsLoHi(low, high, a, b) asm ( "mulx %2, %0, %1;" : "=r"(low), "=r"(high) : "gr" (a), "d" (b) : "cc");
// compute a * b = (low, high)
#define AccAdd4WordsBy4_wc(a0, a1, a2, a3, b0, b1, b2) asm ("addq %4, %0; adcx %5, %1; adcx %6, %2; adcq $0, %3;" : "+r"(a0), "+r"(a1), "+r"(a2), "+r"(a3) : "r"(b0), "r"(b1), "r"(b2) : "cc");
// (a0, a1, a2, a3) = (a0, a1, a2, a3) + (b0, b1, b2, 0) without carry
#define MulAcc(c, a0, a1, a, b) asm ("mulx %3, %3, %4; addq %3, %1; adcq %4, %2; adcq $0, %0;" : "+r"(c), "+r"(a0), "+r"(a1), "=a"(a), "=d"(b) : "a"(a), "d"(b) : "cc");
#define MulAcc_11(a0, a1, c0, a, b) asm ("mulx %3, %0, %1; addq %2, %0; adcq $0, %1;" : "+r"(a0), "+r"(a1): "r"(c0), "r"(a), "d"(b) : "cc");
//compute u * v = r mod p
void mul(uint64_t *r, const uint64_t *u, const uint64_t *v) {
uint64_t u0 = u[0];
uint64_t u1 = u[1];
uint64_t u2 = u[2];
uint64_t u3 = u[3];
uint64_t v0 = v[0];
uint64_t v1 = v[1];
uint64_t v2 = v[2];
uint64_t v3 = v[3];
uint64_t r0, r1, r2, r3, r4, r5, r6, r7;
uint64_t z1, z2, z3, z4, z5, z6, z7, z8, z44, z66;
z2 = z3 = z4 = z5 = z6 = z7 = z8 = r1 = r2 = r3 = r4 = r5 = r6 = r7 = 0;
MultiplyWordsLoHi(r0, z1, u0, v0) //x1 --> r0 ok
MultiplyWordsLoHi(z2, z3, u1, v0)
MultiplyWordsLoHi(z4, z5, u2, v0)
MultiplyWordsLoHi(z6, z7, u3, v0)
MultiplyWordsLoHi(z66, z8, u3, v1)//
AccAdd4WordsBy4_wc(z2, z4, z6, z7, z1, z3, z5)
MulAcc_11(r1, z1, z2, u0, v1) //x1 --> r1 ok
MultiplyWordsLoHi(z2, z3, u1, v1)
MultiplyWordsLoHi(z44, z5, u2, v1)
AccAdd4WordsBy4_wc(z1, z3, z5, z8, z4, z6, z7)
AccAdd4WordsBy4_wc(z2, z44, z66, z8, z1, z3, z5)
MulAcc_11(r2, z1, z2, u0, v2) //x1 --> r2 ok
MultiplyWordsLoHi(z2, z3, u1, v2)
MultiplyWordsLoHi(z4, z5, u2, v2)
MultiplyWordsLoHi(z6, z7, u3, v2)
AccAdd4WordsBy4_wc(z1, z3, z5, z7, z44, z66, z8)
AccAdd4WordsBy4_wc(z2, z4, z6, z7, z1, z3, z5)
MulAcc_11(r3, z1, z2, u0, v3) //x1 --> r3 ok
MultiplyWordsLoHi(r4, z3, u1, v3)
MultiplyWordsLoHi(r5, z5, u2, v3)
MultiplyWordsLoHi(r6, r7, u3, v3)
AccAdd4WordsBy4_wc(z1, z3, z5, r7, z4, z6, z7)
AccAdd4WordsBy4_wc(r4, r5, r6, r7, z1, z3, z5) //r4, r5, r6, r7 ok
//Reduction
uint64_t p = 0x1000003d1;
MultiplyWordsLoHi(z3, z4, r5, p)
MultiplyWordsLoHi(z5, z6, r6, p)
MultiplyWordsLoHi(z7, z8, r7, p)
MulAcc_11(z1, z2, r0, r4, p)
AccAdd4WordsBy4_wc(z2, z4, z6, z8, r1, r2, r3)
uint64_t c = 0;
AccAdd4WordsBy4_wc(z3, z5, z7, z8, z2, z4, z6)
MulAcc(c, z1, z3, p, z8)
r[0] = z1;
r[1] = z3;
if(c == 1){
asm (
"addq $1, %0; adcq $0, %1; \n"
: "=r" (z5), "=r" (z7)
: : "cc");
}
r[2] = z5;
r[3] = z7;
} MultiplyWordsLoHi and other functions are here: https://www.cryptopp.com/docs/ref/integer_8cpp_source.html |
|
|
|
I haven't found many other fixed-point or 256-bit classes. So what are you guys using?
The function I use to compute a subtraction between 2 256-bit numbers (mod p): ##############################################################
#compute r = (a - b) mod p
void sub (uint64_t *r, const uint64_t *a, const uint64_t *b) {
uint64_t a0, a1, a2, a3, b0, b1, b2, b3, p;
a0 = a[0];
a1 = a[1];
a2 = a[2];
a3 = a[3];
b0 = b[0];
b1 = b[1];
b2 = b[2];
b3 = b[3];
size_t borrow = 0;
//compute: (a0, a1, a2, a3) = (a0, a1, a2, a3) - (b0, b1, b2, b3) with borrow //
asm("subq %5, %1\n\t"
"sbbq %6, %2\n\t"
"sbbq %7, %3\n\t"
"sbbq %8, %4\n\t"
"sbbq $0, %0"
: "+r" (borrow), "+r" (a0), "+r" (a1), "+r" (a2), "+r" (a3)
: "r" (b0), "r" (b1), "r" (b2), "r" (b3)
: "cc");
if(borrow == 0){ //if a >= b
r[0] = a0;
r[1] = a1;
r[2] = a2;
r[3] = a3;
return;
}
//if a < b
p = 0x1000003d1;
//compute: (a0, a1, a2, a3) = (a0, a1, a2, a3) - p
asm("subq %4, %0\n\t"
"sbbq $0, %1\n\t"
"sbbq $0, %2\n\t"
"sbbq $0, %3"
: "+r" (a0), "+r" (a1), "+r" (a2), "+r" (a3)
: "r" (p)
: "cc");
r[0] = a0;
r[1] = a1;
r[2] = a2;
r[3] = a3;
return;
}
##################################################################
in the main function:
//a = a0 + a1*(2^64) + a2*(2^128) + a3*(2^196)
uint64_t a = {0x59f2815b16f81798, 0x029bfcdb2dce28d9, 0x55a06295ce870b07, 0x79be667ef9dcbbac};
uint64_t b = {0x9c47d08ffb10d4b8, 0xfd17b448a6855419, 0x5da4fbfc0e1108a8, 0x483ada7726a3c465};
uint64_t c [4];
uint64_t* ptra = &a[0];
uint64_t* ptrb = &b[0];
uint64_t* ptrc = &c[0];
sub(ptrc, ptra, ptrb); //compute c = a - b mod p
|
|
|
|
|
Show Posts
