Hai soldi non dichiarati in cassette di sicurezza? (200 miliardi di euro in tutto), paghi il 15% e passa la paura.
mentre gli stronzi onesti che pagano le tasse, il 15% se lo sognano come percentuale ste cose mi fanno imbestialire come non mai vedete che infondo ho ragione In sostanza in Italia per quanto riguarda il tema tassazione / criptovalute si viene incentivati a ragionare in questo modo: 1) detenere bitcoin senza denunciarne il possesso 2) fra x anni, quando ci sarà il condono/sanatoria specifico, pagare solo il 10% di tasse |
|
|
|
It is possible that all these addresses will be reset to zero in the next few days.
I don't think so, the #85 and #90 for sure, maybe #95 and #100, but not the other addresses. And it will take many many days, not just a few. |
|
|
|
there is nothing strange about this. If you have the right software ans a lots of RAM (I assume much more than 128 Gb) you can do it too. I think that beyond #85 it will be very difficult to recover the private key, even with 1 TB of RAM (with the Baby-Giant Step algorithm). With my 32 GB finding the #70 is already a hard task. But there are other algorithms more suitable that don't need so much ram. If the aim of this puzzle transaction has been to test the sha256 cracking power, now the challenge is cracking the elliptic curve relationship between private and public key. |
|
|
|
Somebody Found the # 70? It was spent. Arulbero, can you help us finding the PrivKey? You are the only one that has the working code for that  PubKey is: 0490e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483d7319f127105f 492fd15e009b103b4a83295722f28f07c95f9a5443ef8e77ce0  This address # 70 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7GR probably also took agulbero - well done. Congratulations ! I didn't sweep that address. I can try to recover the private key but it will take time (70 bit are 32 times 65 bit!) |
|
|
|
01 0000000000000000000000000000000000000000000000000000000000000001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
02 0000000000000000000000000000000000000000000000000000000000000003 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
03 0000000000000000000000000000000000000000000000000000000000000007 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
....
60 0000000000000000000000000000000000000000000000000fc07a1825367bbe 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su
61 00000000000000000000000000000000000000000000000013C96A3742F64906 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
65 000000000000000000000000000000000000000000000001a838b13505b26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe Private key : 000000000000000000000000000000000000000000000001a838b13505b26867
Public key : 30210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b e383c4a8ed4fac77c0d2ad737d8499a362f483f8fe39d1e86aaed578a9455dfc
PrKey WIF c.: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
Address c. : 52e763a7ddc1aa4fa811578c491c1bc7fd570137
Address c. : 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
|
|
|
|
Se penso che fra dieci anni con 90 franchi comprerò 200 kg di mele, tanto vale allora tenermi tutti i 100 franchi iniziali anzichè perderne 10 per prestarli a qualcuno (senza contare inoltre il rischio (seppur piccolo) che non mi venga restituito proprio nulla). |
|
|
|
Quando si parla di casi d'uso della blockchain dove si limita la possibilità di scrittura, sono tutti casi dove si poteva benissimo usare un db, l'unica cosa forse è che usando la blockchain diventa più semplice verificare/confermare l'integrità dei dati dall'esterno rispetto ad un db. Quello che dici è vero, però vale solo con gli oggetti "digitali". Non si può verificare/confermare l'integrità di un pollo con la blockchain! EDIT: ogni singolo elemento diventa come un coin non fungibile che si combina con altri per generare prodotti elaborati che a loro volta sono tocken o coin, sempre non fungibili, e con proprietà differenti.
Non si può fare l'hash di un pomodoro!!! Tutto si può fare, il problema è il costo: mentre fare l'hash di una transazione (cioè il controllo di integrità e autenticità della tx) è immediato, per fare la stessa cosa in altri ambiti bisognerebbe prima riuscire a estrarre una qualche informazione specifica dell'oggetto (tipo le impronte digitali delle persone o il loro DNA). In pratica bisogna riuscire a mappare gli oggetti fisici in stringhe di bit (informazioni). Lo svantaggio rispetto alle tx tradizionali è, come dicevi tu, che nel caso di Bitcoin ciò che va autenticato è già naturalmente informazione "pura" (oggetto digitale) mentre nel caso di oggetti reali bisogna aggiungere uno step di conversione. Forse si potrebbero aggiungere dei codici da assegnare ai prodotti con delle specie di etichette, ma allora il punto debole diventerebbe garantire la correttezza dell'accoppiata oggetto - etichetta. A ben pensarci se si riuscisse a superare questo problema allora avremmo trovato anche un metodo anticontraffazione per le monete fiat: si potrebbero autenticare mediante blockchain dedicata le banconote in euro che abbiamo in tasca, in tal modo ogni commerciante sarebbe in grado di valutare automaticamente se le banconote che riceve sono valide o no. Ma il punto è che è proprio difficile e costoso creare una "unicità" non contraffabile a livello fisico. |
|
|
|
Today, we’ve already mined 82% of the world’s bitcoin. By 2040, we’ll have mined close to 100%. Though bitcoin mining will be possible until 2140, it may not be profitable since its difficulty increases exponentially. Mining nodes will require higher and higher hashrates—the speed at which they can solve bitcoin equations—and receive diminishing rewards. You would need a lot, perhaps an infinite amount, of computing power to create the last bitcoin block.
In other words, the mining cap has consequences beyond giving the currency value today. The approaching end of bitcoin mining could affect those already invested as well as people looking to buy in way before 2140.
Cerco qualcosa di più tecnico se trovo. Beh è veramente molto teorica come supposizione. Troppi fattori possono scardinare completamente questa tesi da qui al 2140: 1) btc potrebbe essere già morto e sepolto da oltre un secolo 2) potrebbero esserci chip molto più evoluti degli attuali Asic e tali da girare su hw ridicolo (quindi tali da superare la domanda sulla profittabilità come la intendiamo oggi) 3) i computer quantici potrebbero aver reso non più logico l'utilizzo della pow 4) .....mille altri fattori oggi non noti su un arco di tempo così lungo. Diciamo che porsi questi problemi ora penso sia proprio una perdita di tempo.....  Non ha alcun senso dire che non sarà possibile minare l'ultimo blocco con ricompensa. Sarebbe come dire che la blockchain e Bitcoin hanno una precisa data di scadenza (cosa che ovviamente non è). Esiste semplicemente un blocco preciso (6929999 -> https://en.bitcoin.it/wiki/Controlled_supply) con il quale verrà immesso nel sistema l'ultimo "nuovo" satoshi. E' previsto dal protocollo sin dall'inizio. Il concetto di "infinita energia" è semplicemente ridicolo, cosí come le "equazioni" che devono essere risolte di cui parla l'articolo. |
|
|
|
Ma quindi torniamo al discorso che facevo io: diventa un secondo lavoro. Per me è assurdo pensare che uno per poter mantenere il suo rank debba scrivere un tot di messaggi al giorno/settimana/mese e che siano pure di un certo livello, se uno per mancanza di tempo, interesse, situazioni personali etc non ha più modo di partecipare al forum per svariato tempo cosa succede, si ritrova a dover ricominciare tutto da capo? Qui si rischia di diventare schiavi di un forum online allora.
L'assurdo è tenere così tanto a qualcosa di così "impalpabile" come il rank in un forum. Troverei interessante come esperimento testare quanto uno sia disposto a pagare in termini di risorse personali (tempo, energia, studio,...) per mantenere il titolo di "Legendary". Capisco il bisogno che abbiamo un po' tutti di sentirci speciali e anche il bisogno quasi infantile di vederci riconosciuto in modo giusto e imperituro l'impegno profuso nel fare qualcosa, ma stiamo parlando di un forum su Internet, niente di più. E' quasi una barzelletta. Se riuscissi a trovare un modo di gratificare con titoli a costo zero (costo zero per chi li emette, cioè per me) il lavoro altrui, potrei smettere di lavorare io e far lavorare gratis per me migliaia di persone! Ovviamente in cambio di titoli e onoreficenze ambitissime solo perchè difficili da ottenere per chi lavora, che ideona |
|
|
|
Sarebbe bello fare “corrodere” piano piano i meriti “regalati”....lasciando alla fine solo quelli “guadagnati”...oppure fare scadere anche quelli, magari più lentamente.
Non è che se ho scritto una guida su un full node su raspi 10 anni fa... allora oggi nel 2029 devo ancora goderne i frutti.
Mi piace!
Prova ad applicare lo stesso concetto alla moneta. Molti si lamentano che le monete fiat si corrodono (perdono potere d'acquisto) nel tempo, in questo bitcoin si differenzia: una volta guadagnata una certa quantità di "punti/bitcoin" non li perdi più (in tutti i sensi). O pensa ai vari riconoscimenti che si possono ricevere nella vita: una medaglia d'oro in una gara sportiva, un titolo di studio, .... ti piacerebbe se si corrodessero nel tempo? |
|
|
|
Ok, that means that the requester must know how to reconstruct the final private key.
Does Vanity pool support the needed methods ?
I just had a quick look on the site and there is not information on how to submit the partial private key (which format to use) and the reconstruction method.
Unfortunately I think that: 1) only uncompressed keys are considered 2) no other ways to reconstruct the key are considered it is a old site. Maybe someone could organize a new site that supports the new options (at the end the final user doesn't care about the method to rebuild the private key, if it is sure and it works). |
|
|
|
Yes that could be interesting. But as we start with an offset (the given public key), can we still apply symmetry and endomorpshim optimization ? Yes. Let P be the public key (offset). Let be 'secret' the private key of P. Let 's' be the start random private key you generate from the seed, and s*G = Q the current start point. Instead of starting from P, you start from Q+P. Let's say Q' = Q + P Now, you find a public key R' such that --> ripemd160(sha256(R')) = address with a certain prefix. Your program works exactly like now, it finds only the private key of Q, not of Q'. Simply you get a partial key of Q instead of the final private key of Q'. Now there are 3 possibilities: if R' is a standard point (no symmetry / endo), then you have found R' = R + P and you know only the private key k of R (k*G = R), not the private key of R'. Then k is the correct partial private key. The final user needs to add the k found to the secret private key of P (that he only knows) to get the final private key: final private key = (k + secret) mod n (explanation: (k + secret)*G = k*G + secret*G = R + P = R') if R' is a simmetric point, then R' = -(R + P). You found the private key k of -R (k*G = -R), nothing more. The final user needs to build the final private key this way: final private key = (k - secret) mod n (explanation: (k -secret)*G = k*G - secret*G = -R - P = R') if R' is a endo point, then R' = lambda1*(R + P). (or lambda2) You found the private key k of lambda1*R (k*G = lambda1*R), then: final private key = ( k + lambda1*secret)) mod n (explanation: (k + lambda1*secret)*G = k*G + lambda1*secret*G = lambda1*R + lambda1*P = R') |
|
|
|
Have you a _ModSqrMontgomery function? I would try to compute the inverse this way: __device__ void _ModInv(uint64_t* a) {
uint64_t x2[4], x3[4], x6[4], x9[4], x11[4], x22[4], x44[4], x88[4], x176[4], x220[4], x223[4], t1[4];
uint8_t j;
/** The binary representation of (p - 2) has 5 blocks of 1s, with lengths in
* { 1, 2, 22, 223 }. Use an addition chain to calculate 2^n - 1 for each block:
* [1], [2], 3, 6, 9, 11, [22], 44, 88, 176, 220, [223]
*/
_ModSqr(x2, a);
_ModMult(x2, a);
_ModSqr(x3, x2);
_ModMult(x3, a);
memcpy(x6,x3,32);
_ModSqr(x6);
_ModSqr(x6);
_ModSqr(x6);
_ModMult(x6, x3);
memcpy(x9,x6,32);
_ModSqr(x9);
_ModSqr(x9);
_ModSqr(x9);
_ModMult(x9, x3);
memcpy(x11,x9,32);
_ModSqr(x11);
_ModSqr(x11);
_ModMult(x11, x2);
memcpy(x22,x11,32);
for (j=0; j<11; j++) {
_ModSqr(x22);
}
_ModMult(x22, x11);
memcpy(x44,x22,32);
for (j=0; j<22; j++) {
_ModSqr(x44);
}
_ModMult(x44, x22);
memcpy(x88,x44,32);
for (j=0; j<44; j++) {
_ModSqr(x88);
}
_ModMult(x88, x44);
memcpy(x176,x88,32);
for (j=0; j<88; j++) {
_ModSqr(x176);
}
_ModMult(x176, x88);
memcpy(x220,x176,32);
for (j=0; j<44; j++) {
_ModSqr(x220);
}
_ModMult(x220, x44);
memcpy(x223,x220,32);
_ModSqr(x223);
_ModSqr(x223);
_ModSqr(x223);
_ModMult(x223, x3);
/* The final result is then assembled using a sliding window over the blocks. */
memcpy(t1,x223,32);
for (j=0; j<23; j++) {
_ModSqr(t1);
}
_ModMult(t1, x22);
_ModSqr(t1);
_ModSqr(t1);
_ModSqr(t1);
_ModSqr(t1);
_ModSqr(t1);
_ModMult(t1, a);
_ModSqr(t1);
_ModSqr(t1);
_ModSqr(t1);
_ModMult(t1, t1, x2);
_ModSqr(t1);
_ModSqr(t1);
_ModMult(a, t1);
}
|
|
|
|
gcc version 7.0.1 20170407 (experimental) [trunk revision 246759] (Ubuntu 7-20170407-0ubuntu2)
Ok. I observed the issue with gcc 6 but with my gcc 7.3.0 it worked. It seems that this optimization bug is still here with 7.0.1. mmm... I will add a test for minor version and let the volatile up to gcc < 7.3. I tried with gcc 8.2 and it also works. Thanks for the report. With -O0 in the makefile CXXFLAGS = -DWITHGPU -m64 -mssse3 -Wno-write-strings -O0 -I. -I$(CUDA)/include
it works without "volatile". |
|
|
|
Hi, I've just downloaded the VanitySearch Master, it works perfectly if I add "volatile" in this piece of code:
OK, which release of gcc are you using for compiling VanitySearch (not the CUDA code) ? gcc version 7.0.1 20170407 (experimental) [trunk revision 246759] (Ubuntu 7-20170407-0ubuntu2) |
|
|
|
Hi, I've just downloaded the VanitySearch Master, it works perfectly if I add "volatile" in this piece of code: void Int::ModSquareK1(Int *a) {
#ifndef WIN64
#if __GNUC__ <= 6
#warning "GCC lass than 7 detected, upgrade gcc to get best perfromance"
volatile unsigned char c; <--
#else
volatile unsigned char c; <--
#endif
#else
unsigned char c;
#endif
|
|
|
|
How it is possible??  Found by the CPU ? Try with -t 0... Ok! Mystery solved!  |
|
|
|
|
Show Posts
