Bitcoin Forum
March 28, 2024, 07:38:36 PM *
News: Latest Bitcoin Core release: 26.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 »
41  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 10, 2024, 10:21:12 PM
what does the author want to prove? I imagine that the security of bitcoin...

Yes he want to prove the bitcoint security

in his own words:

I am the creator.

You are quite right, 161-256 are silly.  I honestly just did not think of this.  What is especially embarrassing, is this did not occur to me once, in two years.  By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity.  I will spend from 161-256 to the unsolved parts, as you suggest.  In addition, I intend to add further funds.  My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key).  Probably in the next few weeks.  At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology.  The "large bitcoin collider" is especially innovative and interesting!

Now please if you want to continue the discution of that topic please use that "Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it" Topic, not this, this only for Keyhunt related issues.

Any new post that is not keyhunt will be reported as Offtopic or SPAM


hi ALBERTO;

For N value in Keyhunt Program
Example: Nx100000000 = 4294967296 keys
Does it mean that it scans every 4294967296 key sequentially? Is it true ?
It selects a random key and scans 4294967296 wallets sequentially, and then it selects a random key again and scans 4294967296 wallets sequentially.

Did I understand correctly? Does it work like this? Keyhunt N value?

Yes it is exactly like you describe above
42  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: March 10, 2024, 06:02:17 PM
Hello everyone, why do you think Puzzle 66 has not been found yet?
In April 2023, the reward was increased 10 times, but it still has not been found. What do you think is the reason?
Although many amateur people from all over the world searched, it could not be found.
Doesn't anyone have a chance?
Or is puzzle 66 somewhere outside this range?
What are your thoughts?

it was not found because the 66 bit space is absurdly big for regular brute force

It is simple, every extra bit increate the difficulty by a factor of TWO

Puzzle 63 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4 was redeem in June 2019
Puzzle 64 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN was reddem in September 2022

Puzzle 66 range is 4 times bigger than puzzle 64 make your own stimations

Puzzle 65 doesn't count because it was solved with the publickey with kangaro

Or is puzzle 66 somewhere outside this range?

No, all solved puzzles were in their respectives ranges, so please STOP spreading this shit.
43  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 10, 2024, 03:08:07 PM
Personally I believe that whoever made the puzzles did not use a random method, I think the location of the known puzzles in relation to their rank demonstrates this. A while ago I did a linear regression study and I was surprised by the result. I expected the average difference between the predicted and actual location to be approximately 50%, which is what is expected for a linear regression prediction on random data, however the average is 27.81%

I dare to predict that puzzle 66 is at  ~72% of its range. Grin

💩💩💩

Bullshit!

The author already said that it was the result of a random keys padding with bits to match the expected range.
44  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 05, 2024, 04:05:40 PM
  • Added Vanity search : 13zb1hQ
    ...
    Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a0380b2513a178946f75
    ...
First if you are going to use vanity use more than 15 characters not just 7 or  8.

Seconds yes that key is outside of the range because keythunt for address/rmd160/xpoint search on both sides of the curve it do this because if I only seach for one side of the curve the performance would be lesst than the half of it ( It will have less than the half of the current speed ).

It think on this like a feature not a bug... so please use more than 15 characers for your vanity search.
  • Added Vanity search : 13zb1hQ
    ...
    Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a0380b2513a178946f75
    ...
First if you are going to use vanity use more than 15 characters not just 7 or  8.

Seconds yes that key is outside of the range because keythunt for address/rmd160/xpoint search on both sides of the curve it do this because if I only seach for one side of the curve the performance would be lesst than the half of it ( It will have less than the half of the current speed ).

It think on this like a feature not a bug... so please use more than 15 characers for your vanity search.

Alberto is a Legend would love to meet him one day  Smiley

Its not a big deal, I am just another random guy with regular life problems
45  Local / Español (Spanish) / Re: Creando una base de datos ultra ligera de publickeys para fuerza bruta on: March 04, 2024, 06:44:10 PM

1- convertir cada 64 bits de la base de datos original en decimales, ordenar los numeros ,para facilitar su busqueda, en el script de busqueda serian 4096 keys para asegurarnos que no nos saltemos una posible concidencia:

Si, pensé en este y otras variaciones pero ninguna es eficiente, sin un método eficiente de búsqueda la base de datos no se puede utilizar
46  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 04, 2024, 06:00:44 PM

In the post:
 Range
-- from : 0x1
-- to   : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

And what you expected? found the key in seconds?

Genius...... That is the whole range if there is a program to found a key in seconds the bitcoin and all alt-coins will worth ZERO

Please don't ask stupid questions here
47  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 04, 2024, 02:06:59 PM
Bug?

Where in the command do you set the range?

 Roll Eyes Roll Eyes Roll Eyes Tongue
48  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 01, 2024, 12:30:19 PM
I have tried Vanity search with range specified and it has found address that is out of range:

Code:
./keyhunt -m vanity -f tests/van.txt -l compress -R -b 66 -e -s 10 -q -t 32 -n 0x400000000000


Remove -e, by the way don't use vanity for puzzle search
49  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: February 29, 2024, 03:54:26 AM
Is it possible to adapt an ASIC miner to this program as a coprocessor because it has higher speed?

No, its no possible to use them.

Or perhaps use MicroRNG is a hardware (true) random number generator?

In linux it use urandom to get random numbers, i did some test before and the performance is almost the same, there is not much advantage to use the CPU RNG to do that, even the libssl RNG is faster than it.
If the OS have enough entropy even 256 bits of good entropy is enough to generate Random numbers for an eternity see : https://www.2uo.de/myths-about-urandom/
50  Local / Español (Spanish) / Re: Creando una base de datos ultra ligera de publickeys para fuerza bruta on: February 22, 2024, 02:12:15 PM
Aún así sigo pensando que hacer fuerza bruta a las llaves privadas es como buscar un grano de arena específico en una playa de kilometros, podríamos intentarlo durante toda la vida sin éxito y si alguien encuentra una forma efectiva de hacer fuerza bruta a las llaves privadas, eso representaría el final no solo para las criptomonedas sino que para el encriptado sha256.

La analogia correcta seria buscando un atomo en especifico en todo el universo visible, pero se entiende Smiley

En el programa que desarrolle si utiliza Bloom filters no es el mismo que utiliza brainflayer pero si es la misma estrucutura de datos con algunas variaciones.

El detalle es que los items en estos blooms necesitan de 20 a 30 bits por elemento ingresado en el bloom esto varia dependiendo de la cantidad de hashes realizados en funcion del ratio de error (Falsos positivos) que tengamos generalmente uno en cada 10 millones o algo similar.

Lo que se discute aqui es utilziar una nueva base de datos que solo utilize UN SOLO BIT por item en la base de datos lo cual seria fantastico, pero el problema en este caso es el tiempo de busqueda en la base dados para encontrar una coincidencia.
51  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: February 21, 2024, 07:14:02 PM
In fact I can say that I am sure about first few digits but I want to quickly try different first digits,  if I understand it well,  no software tries first digits only without touching the rest of input range.

I already explained something similar here:

Re: Solving partial WIF with two missing parts

With some changes it can be applied to your case it's just matter to know what are you doing
52  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: February 20, 2024, 07:27:51 PM
Has anyone ever seen a tool that tries only a set of keys? Let me explain, imagine you have this key
0x397f5aa7b90de4
What if you want to set the public key of this one 0x5aa7b90de4 and then try all combinations for the first 4 missing characters? as I understand it,  no tool exist to scan selected parts of a range, or do they exist?

If you are sure about the last digits of the Privatekey is easy to make some transformations on the public key with arithmetic and work with the result with BSGS.

53  Bitcoin / Development & Technical Discussion / Re: [For Developers] n0nce's Bitcoin Testnet Faucet [~10 tBTC] on: February 20, 2024, 07:01:29 PM
Amount: 5 tBTC
Address: tb1qr5hfa43nhlpkzz3r4dwq26237k9cz430l4lege
Project: To Add Liquidity to my Project.

Bullshit like the SatoshiVM project Grin Grin Grin

@n0nce you just should close the topic for a while, at least until the SatoshiVM ends
54  Local / Español (Spanish) / Re: Creando una base de datos ultra ligera de publickeys para fuerza bruta on: February 20, 2024, 06:41:56 PM
No olvide decir gracias, para motivarme a contribuir con otras ideas.

Gracias.

Este código es sólo una demostración que puede no estar optimizado correctamente, preferiblemente cree su propia versión en C.

Correcto, no esta optimizado pero la idea se entiende bien!

Code:
#@mcdouglasx
    b = bytes(BitArray(bin=my_str))
    file = open("data-base.bin", "rb")
    dat = bytes(file.read())
    if b  in dat:

Esa parte del codigo es el mayor problema

Code:
   if b  in dat:

No hay una manera eficiente e instantea para buscar un sub-array de bits en un array extremadamente grande.

No estoy hablando de una busqueda en 3 o 4 MB estoy hablando de una busqueda en un array de 128 GB o tal vez hasta un 1 Terabyte

La idea es buena no lo niego, le he dado vueltas desde que la lei pero mientras mas grande es la base de datos mas tarda cada busqueda.

Menciono 128 GB por que es lo que se necesita para 2^40 publickeys para ser almacenadas con ese metodo de 1 llave por bit

Code:
>>> 2**40 // 8 // 1024 // 1024 // 1024
128

Un metodo que se me occurre para realizar busquedas mas eficientes es almacenar cada 16 o 32 bytes de tu  base de datos en un bloom filter, de esta manera la base de datos original de 2^40 llaves publicas que requiere 128 GB en disco, puede ser dividida en 4294967296 items de 32 bytes o 8589934592 items de 16 bytes los cuales pueden ser almacenados en 14 GB de RAM para una busqueda mas eficiente en un bloom filter

Code:
>>> 2**40 // 8 // 32 * 29  // 8 // 1024 // 1024 // 1024
14
>>> 2**40 // 8 // 32
4294967296
>>> 2**40 // 8 // 16
8589934592

De esta manera cada que exista un hit en el bloom filter  (1 de cada 100 Millones por motivos de falso positivo) ahora si se realizara la busqueda full en tu base de datos de 2^40 items (128 GB)

Estaba pensado en algun otro tipo de busqueda probabilistica que no sea tan exhaustivo pero aun no doy con nada.

Saludos!
55  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: February 14, 2024, 05:42:28 PM
In summary, my search is 70%

Is somehow now near of 100%?
56  Local / Primeros pasos y ayuda / Re: Generacion Billeteras Frías / Cold Wallet on: February 14, 2024, 05:35:20 PM
Por lo visto no te molestate en leer lo que te comparti.
57  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: February 01, 2024, 05:06:34 PM
...
I am not demotivating him, no no!! I am happy about him that he is learning good maths here.
...
Whatever secret mcdouglasx has, I am sure many of guys here have already tried & tested and accordingly slapped in ass by EC! SORRY FOR THAT!!

I agree with you, i hope to know what is he doing.
58  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: February 01, 2024, 03:33:45 PM
Oh thats right in any case puzzle 130 is still there:

1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua
59  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: February 01, 2024, 12:09:31 PM
Well, we're waiting  Roll Eyes Roll Eyes Roll Eyes

puzzle 66 is still there @mcdouglasx
60  Bitcoin / Bitcoin Technical Support / Re: Generate private keys on computer without on: January 22, 2024, 02:59:28 PM
Getting 31 Fs in a row has a chance of 1 in 21267647932558653966460912964485513216. If you hit that, it's more likely something else went wrong than that it's created randomly.

I agree with this, like a CPU / OS error / Cosmic beam.

In that case any person with some common sense will generate another key
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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!