Bitcoin Forum
September 19, 2020, 12:21:32 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 79 »
1  Local / Italiano (Italian) / Re: Tema Coronavirus on: July 21, 2020, 11:50:51 AM

rispetto a quello di Moderna (ne discutevamo qualche giorno fa) questo sembra "messo meglio".
Non abbiamo la stima pessimistica dei 5 anni, ma in 2 anni ce la potremmo fare Wink
(devono fare la fase 3 ... analizzare i dati... ricevere le approvazioni ... produrlo ... distribuirlo ...)

Veramente si ipotizza la commercializzazione già a inizio 2021, io spero che per la prossima primavera sarà disponibile per tutti.
2  Local / Italiano (Italian) / Re: Tema Coronavirus on: July 21, 2020, 10:15:39 AM
giornalisti, come si fa a sbagliare una proporzoine, mi dispiace ma secondo me era in mala fede

quindi 55 ogni 100k, ha piu senso pero come dice appunto bitbollo non e' comparabile (causa densita della popolazione sopratutto)

mah, io la vedo male, speriamo di sbagliarmi

trovo molto più in mala fede gli articoli clickbait che annunciano/annunciavano l'arrivo imminenti vaccini o terapie farmacologiche.
non faccio l'elenco della lunga lista di cantonate, basta pensare a quanti vaccini o prodotti miracolosi per il covid19 abbiamo in commercio Roll Eyes ma penso che abbiamo visto una delle pagine più tristi dell'informazione scientifica Sad


Comunque adesso pare proprio che il vaccino ci sia, se tutti i test verranno confermati:

https://www.ansa.it/canale_saluteebenessere/notizie/medicina/2020/07/20/coronavirus-lancet-forte-risposta-immunitaria-dal-vaccino-di-oxford_6b6de39f-041b-438f-b74e-9bc41fd99b4b.html
3  Local / Italiano (Italian) / Re: Tema Coronavirus on: July 21, 2020, 10:13:00 AM

Norvegia = 4,7 decessi su 100.000 abitanti
Svezia = 55,8 decessi           ""
Finlandia = 5,9 decessi          ""
Danimarca = 10,5 decessi       ""

Lombardia: 168 decessi su 100.000 abitanti
Belgio: 86 decessi su 100.000 abitanti
Gran Bretagna :  67 decessi su 100.000 abitanti
Spagna : 60 decessi su 100.000 abitanti
Italia: 58 decessi su 100.000 abitanti
Svezia : 56 decessi su 100.000 abitanti
USA: 44 decessi su 100.000 abitanti
Francia: 44 decessi su 100.000 abitanti
Brasile : 38 decessi su 100.000 abitanti
Messico: 31 decessi su 100.000 abitanti
Germania: 11 decessi su 100.000 abitanti
Cina: 0,3 decessi su 100.000 abitanti
4  Local / Italiano (Italian) / Re: Tema Coronavirus on: July 20, 2020, 12:27:11 PM

Quote
Norvegia, coi suoi 4,5 milioni di abitanti, è uscita dalla prima fase del coronavirus con 252 morti, ovvero circa 4,6 per 100mila abitanti. Analogamente lusinghiero è il bilancio finlandese. La Svezia invece, con 10 milioni di abitanti, puntando sulla libera scelta dei cittadini responsabili e sperando in fenomeni da immunità di gregge, ha avuto 5500 morti che continuano a salire, in altre parole ben 252 morti ogni 100mila persone.


Italia: 58 morti ogni 100mila persone.
5  Local / Italiano (Italian) / Re: Tema Coronavirus on: July 17, 2020, 10:06:38 PM
https://www.youtube.com/watch?v=P7RUh2AAQ38
6  Local / Italiano (Italian) / Re: Tema Coronavirus on: July 15, 2020, 04:56:47 PM
Oggi il corriere della sera online riprende i risultati di questa ricerca:

https://www.medrxiv.org/content/10.1101/2020.06.03.20121392v1
https://www.medrxiv.org/content/10.1101/2020.06.05.20123463v2

sembra che i raggi ultravioletti siano oltremodo efficaci contro il virus.
7  Local / Italiano (Italian) / Re: BITCOIN PUMP! on: July 13, 2020, 08:18:25 AM
Sulla differenza tra il QE degli anni 2009-11 e quello attuale:

https://www.youtube.com/watch?v=UXAuViyezOc (dal minuto 39:21)

In pratica in questo caso l'inflazione sembra molto più probabile, a differenza del caso precedente.
8  Local / Italiano (Italian) / Re: BITCOIN PUMP! on: July 09, 2020, 12:34:02 PM
Interessante articolo di Stefano Capaccioli:

http://rivista.biodiritto.org/ojs/index.php?journal=biolaw&page=article&op=download&path%5B%5D=672&path%5B%5D=570
9  Bitcoin / Development & Technical Discussion / Re: Using secp256k1 endomorphism on: July 06, 2020, 06:09:17 AM
All six points related through negation and endomorphism share the same value for x^3. (see your forum messages from me, from a few months back

Yes I know, but I don't see how to use this property in the random walk. For the symmetry you can select the next point according to the sign of the y value and then select always the positive point which divide by 2 the search space. It is easy to calculate the corresponding distance at each step of the random walk but it generates useless cycles.
If I cube the x value of a DP and look for collision on x^3 then the gain is negligible due to the fact that the selection is not done at each step of the random walk.
Any idea would be welcome Wink


Each step (each jump) must depend on the last bits of x^3 mod p.  But you have no advantage in the search in [-(a+b)/2,(a+b)/2] interval, you have a speedup only in the union of 3 intervals:  [-(a+b)/2,(a+b)/2] U [-lambda*(a+b)/2,lambda*(a+b)/2] U [-lambda^2*(a+b)/2,lambda^2*(a+b)/2]
10  Bitcoin / Development & Technical Discussion / Re: Using secp256k1 endomorphism on: July 04, 2020, 07:41:11 AM

But symmetry is not interesting on large range due to small cycle apparition in random walks. The overhead needed to limit cycle is more than the gain of using equivalence class, especially on GPU where the cache usage can drastically decrease performance.

I did some tests with symmetry (python for cpu), with num_jumps = 32 you can get 1.6 / 1.7.sqrt(N) steps (instead of 2.08.sqrt(N)) if the DP is 12 or lower.

With longer paths you have to increase the number of the jumps, and that decreases the performance.
11  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 24, 2020, 09:53:27 AM
I will definitely reduce jD to 128 bits in the next release, the less constant mem usage is better, there is 64Kb available but for L1 cache the lowest is the best.

What about removing completely the jD array?
12  Local / Italiano (Italian) / Re: Grayscale Bitcoin Trust on: June 20, 2020, 12:59:42 PM
Visto che si parla sempre più spesso di questo veicolo di investimento su Bitcoin (e altre criptovalute) ho pensato di creare un thread apposito provando a descrivere cos'è e come funziona anche a chi non è molto esperto di strumenti finanziari.

Grayscale Investiment Trust (GIT) è un fondo fiduciario che permette agli investitori di esporsi alle variazioni di prezzo di bitcoin senza doversi preoccupare dell'acquisto, gestione e custodia di bitcoin fisici.

A differenza di contratti per differenza (come i futures di CME) nei quali viene solo tracciato il prezzo e l'esposizione non comporta acquisto di bitcoin fisici, le quote di GIT ("share") corrispondono a bitcoin "fisici" detenuti da Grayscale per conto degli investitori.  

Quindi, un investitore che vuole mettere i propri soldi in questo strumento acquista delle quote del fondo sapendo che a quelle quote corrispondono dei bitcoin effettivamente posseduti da Grayscale.

Come si acquistano le quote? Esistono due mercati, molto diversi tra loro, che permettono di farlo.

Nel mercato primario chi vende è Grayscale che emette nuove quote a favore di chi ne fa richiesta.

Nel mercato secondario le quote in circolazione possono essere scambiate (quindi comprate e vendute) come un titolo qualsiasi.


Molto molto interessante.

L'operazione che Grayscale fa dunque è quella di raccogliere bitcoin veri convertendoli in quote, ovvero in credito di bitcoin non redimibile; il valore di queste quote starebbe:

1) per gli acquirenti del mercato primario, nel poter liquidare le quote a un prezzo maggiorato nel secondario dopo 6 mesi

2) per gli acquirenti del mercato secondario, nel poter esporsi alla volatilità del prezzo di bitcoin vs moneta fiat senza i problemi di gestione tecnica e fiscale dei bitcoin veri

In pratica Grayscale raccoglie bitcoin veri per dare in cambio bitcoin virtuali, più facili da maneggiare e da scambiare con gli attori del mercato secondario, i quali evidentemente preferiscono acquistare questi bitcoin virtuali anzichè quelli reali.

Queste quote sono delle stablecoin garantite da un corrispettivo identico di bitcoin anzichè di moneta fiat.

Non è chiaro a questo punto perchè Grayscale non piazzi le sue quote con un premio del 10% anzichè lasciare dei margini di guadagno agli acquirenti del mercato primario, vista tutta questa richiesta di bitcoin 'facili' da manipolare.

13  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 19, 2020, 06:36:49 PM

But why it didn`t work when we move DPs to range*32 with arulbero method ?


Because each patch can reach only 1/32 of the points.
14  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 19, 2020, 06:40:55 AM
@JeanLuc
How much constant memory do you use for the multiplication and for the addition?
32 jumps are 16kB for x and y-coordinate + 8 kB for their private keys (32 * 256bit = 8kB) + what else?

I use the following setting to prefer L1 cache as shared mem is not used.
cudaDeviceSetCacheConfig(cudaFuncCachePreferL1);

In constant mem:
Code:
__device__ __constant__ uint64_t _0[] = { 0ULL,0ULL,0ULL,0ULL,0ULL };
__device__ __constant__ uint64_t _1[] = { 1ULL,0ULL,0ULL,0ULL,0ULL };
__device__ __constant__ uint64_t _P[] = { 0xFFFFFFFEFFFFFC2F,0xFFFFFFFFFFFFFFFF,0xFFFFFFFFFFFFFFFF,0xFFFFFFFFFFFFFFFF,0ULL };
__device__ __constant__ uint64_t MM64 = 0xD838091DD2253531; // 64bits lsb negative inverse of P (mod 2^64)
__device__ __constant__ uint64_t _O[] = { 0xBFD25E8CD0364141ULL,0xBAAEDCE6AF48A03BULL,0xFFFFFFFFFFFFFFFEULL,0xFFFFFFFFFFFFFFFFULL
__device__ __constant__ uint64_t jD[NB_JUMP][4];
__device__ __constant__ uint64_t jPx[NB_JUMP][4];
__device__ __constant__ uint64_t jPy[NB_JUMP][4];

I will definitely reduce jD to 128 bits in the next release, the less constant mem usage is better, there is 64Kb available but for L1 cache the lowest is the best.


128 bit * 32 = 4kB saved, good.

If you accept to break the compatibility with the #115 search, you can save another 1kB picking as jumps points with the first 32 bits of the x-coordinate = 0; you have many of them in the file of the old DPs.
15  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 10:23:26 PM
Also i done test 1000 pubs with the same range but with normal soving without tricks.
here result:
Total    OP: 273125509453.87 = 2^37.99
Average  OP: 28.04

Unfortunately the difference is very small.

--------------------------------------------------------------------------------------------------------

I read this article:

https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752

this is the puzzle https://twitter.com/alistairmilne/status/1266037520715915267

I think that zielar could have won that prize easily too.

About this part of the arcticle:

Quote
In a GPU you have four main types of memory available to you (Global, Constant, Local, and Private). Global memory is shared across all GPU cores and is very slow to access, you want to minimize its use as much as possible. Constant and Private memory are extremely fast but limited in space. I believe most devices only support 64kB of constant memory. Local memory is shared by a “group” of workers and its speed is somewhere between Global and Constant.

My goal was to fit everything I needed into the 64kB of constant memory and never need to read from global or local memory to maximize the speed of the program. This proved to be a bit tricky because the standard precomputed secp256k1 multiplication table took up exactly 64kB by itself.

@JeanLuc

How much constant memory do you use for the multiplication and for the addition?

32 jumps are 16kB for x and y-coordinate + 8 kB for their private keys (32 * 256bit = 8kB) + what else?

16  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 06:41:51 PM
The best time complexity with the birthday paradox and kangaroo having a starting position uniformly distributed in [0..N] is obtained when drawing alternatively one tame and one wild. When using DP0, you get ~2.sqrt(N). When using DPx, it is like drawing alternatively 2^x TAME and then 2^x WILD, you have then a DP overhead.
I managed to get the formula for parallel version which is: ~2.CubicRoot( N (k.theta + sqrt(N)) ) where theta=2^dpbit and k the number of kangaroo-2 running in parallel.
For theta=1 (DP0) and k=0 (or when k.theta << sqrt(N)) we well get ~2.sqrt(N), when k.theta >> sqrt(N), the time complexity tend to ~2.CubicRoot(k.N.theta).
So it is important to choose a DP such as k.theta << sqrt(N).


Great work!

The number of kangaroos running in parallel transforms DP (that means less RAM) in a overhead.

For the #120, if you and Zielar use 2^30 kangaroos, you need to use a DP < 28.

The problem is: how fast is a single kangaroo? You can't 'concentrate' the speed of several kangaroo in more speed for one. And it takes a lot for a single kangaroo to walk through a path of length = 2^28.

If you reduce k, you reduce the speed, then you have to reduce theta (DP).

How many kangaroos run in parallel on a single V100 ? At wich speed?
17  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 06:06:54 PM
-snip-

To get 2^27.98, it is like 2^25.876 was worth about 2^21.8, the effect of reuse of old DPs is reduced by a factor of 16.
I think that for birthday paradox is a big difference between have 16Tame DP and 2 wild DP or 9tame and 9wild.
Maybe if Kangaroo app first launch wild (as you say somewhere above) gain the same amount as tame DPs maybe in this case we will have faster result.

Yes, but in that case there is no big difference:

(2^x  +  2^25.876) tame * (2^x + 2^25.876) wild = 2^54 couples

2^x + 2^25.876 = 2^27

x = log2(2^27-2^25.876) = 26.1

--> only 2^26.1 tame + 2^26.1 wild  + 2^25.876 wild steps are needed -> 2^27.61
18  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 05:31:12 PM
-snip-
The gain (- 5,4%) is little, how many DPs have you generated for the key in 49 bit?
-snip-
DP Count  : 240568 2^17.876 in 49bit workfile

Then you have computed 2^17.876 * 2^8 = 2^25.876 points,


(2^x  +  2^25.876) tame * (2^x) wild = 2^54 couples

--> x = 26.67  

In theory it would be enough 2^27.67 steps instead of 2^27.98.

To get 2^27.98, it is like 2^25.876 was worth about 2^21.8, the effect of reuse of old DPs is reduced by a factor of 16.
19  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 04:16:08 PM
@arulbero test with 1000 pub keys fulfilled.
Workfile taken from puzzle 49 bit and prepared to work in the range 54 bit.
Each wild DPs tamed. All DPs multipled by 32 and checked (x-coordinate was correct when distance*G' )
-xbit was 5 so G'=G*inv(32) = (bb2228d3ea32cb3c1eb160cc824a4ba8115f9a7f415d18ddcaac8193defc2c47,
71f8c9c7cc35f99b8b2abcdcab86d12cb7539b3fbb45bc433b3bd9421b35be53)
1000 keys was generated in range 40000000000000:7fffffffffffff
Each pubkeys was multipled by inv(32) and solved with G'and Kangaroo v1.4
Expected operations 2^28.06
Total op was 261530636052 = 2^37.93
In average 2^27.98

Many thanks.

The gain (- 5,4%) is little, how many DPs have you generated for the key in 49 bit?

If you have generated 2^25.08 points, then:

(2^x  +  2^25.08) tame * (2^x) wild = 2^54 couples

2^(2x) + 2^(25.08)*2^x - 2^54 = 0

--> x = 2^26.81

Then you should have computed on average 2^26.81 tame-steps + 2^26.81 wild-steps = 2^27.81 steps
20  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 17, 2020, 09:14:56 PM
@arulbero here is 10 test with random generated pubkeys in range 2^64
With trick 7 pub was solved much faster then expected op 2^33.09
---
Tomorrow i will publish result with the same pubs but without trick.

Thanks, but a test must have:

a) 1000 pub_keys
b) the average steps after 1000 pub_keys

I think it is better to use a lower range to get the results quickly.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 79 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!