Na verdade quando o Satoshi criou o Bitcoin existia um esquema de pagamento chamado P2PK (Pay-to-Public-Key) implementado no client que era a opção default no pagamento pela mineração.
Ou seja, as recompensas de bloco eram pagas diretamente para chaves publicas. Até hoje muitas moedas dessa época ainda estão nessas chaves publicas, pois nunca foram movidas.
O que acontece é que a maioria dos exploradores de bloco conectam erroneamente esses outputs P2PK ao endereço P2PKH derivado da chave publica.

Vamo usar como exemplo o endereço do bloco Genesis. Os primeiros 50 Bitcoins minerados por Satoshi não estão no famoso endereço P2PKH 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa e sim na chave publica dele:

Mais alguns exemplos desse fenômeno:

Apesar desses endereços nunca terem gasto moedas, as chaves publicas deles são literalmente publicas pois foram elas que receberam as moedas. Fazendo um parsing na blockchain é possível obtê-las.
Existia também uma função chamada Pay-to-IP nos primeiros clients e o default dessa função também era transacionar através do P2PK. Mais tarde ela foi descontinuada.
Várias dessas chaves publicas da era P2PK provavelmente estão associados ao proprio Satoshi.

O interessante é que apesar das chaves privadas de 256 bits, o esquema P2PK fornece uma segurança de 128 bits por causa dos algoritmos como Pollard Kangaroo e BSGS que trabalham diretamente com a chave publica.
Esses algoritmos exploram algumas propriedades da curva elíptica pra resolver o ECDLP em sqrt(O) steps (raiz quadrada do tamanho do problema).
Pra uma chave privada de 256 bits temos sqrt(2^256) = 2^128. O algoritmo precisaria então computar "apenas" 2^128 operações pra derivar uma chave privada de 256 bits através da chave publica.
Vale lembrar que 2^128 operações ainda é um numero astronômico e algo praticamente impossível de alcançar.


A hipótese pode ser testada fazendo um parsing na blockchain pra resgatar todas as chaves publicas usadas nessa época.
Carrega essas chaves publicas num BSGS e aí solta os cachorros. Coloca o algoritmo pra procurar as chaves privadas no espaço 1:FFFFFFFFFFFFFFFFF por exemplo.
Se alguma chave privada desse range foi utilizada o algoritmo vai encontrar.
Mas é claro que o Satoshi não iria cometer esse tipo de gafe. 

Até aqui você acertou.

Com poucas linhas de Python é possível armar um script que checa a mempool de segundo em segundo através de um node ou API, monitorando um endereço específico, aguardando esse endereço submeter uma transação pela primeira vez e revelar a chave publica, informação que até então (no contexto do puzzle #66) é conhecida apenas pelo detentor da chave privada.

Quando a primeira transação que gasta fundos do endereço #66 chega na mempool, a chave publica daquele endereço é revelada pra rede inteira instantaneamente. O script do atacante recebe retorno em questão de milissegundos e agora o atacante também tem aquela chave publica.

Basta agora iniciar uma instancia de Pollard Kangaroo ou BSGS pra derivar a chave privada. No pior dos cenários essa etapa poderia levar uns 30 segundos (Pra um ECDLP de 66 bits a complexidade é de apenas 2^33 operações usando os algoritmos citados) mas dependendo do hardware e implementação é possível derivar uma chave privada de 66 bits instantaneamente.

Tendo a chave privada o atacante começa a spammar a mempool com novas transações que gastam os mesmos fundos para outro endereço, pagando taxas mais altas do que a transação original e recebendo maior prioridade (Replace By Fee). O processo inteiro é facilmente automatizado do inicio ao fim com um único script em Python que faz tudo em menos de 1 minuto:

*A transação original é enviada a mempool pela pessoa que resolveu a chave privada primeiro e está aguardando confirmação*

- Detectar essa transação na mempool = milissegundos
- Recuperar a chave publica dos metadados = milissegundos
- Derivar chave privada de 66 bits através da chave publica = 1~30 segundos
- Usar a chave privada pra assinar novas transações = milissegundos
- Relay dessas transações através de APIs = milissegundos

Enquanto isso a transação original levaria seus ~10 minutos até ser confirmada. Obviamente não da tempo, pois antes disso acontecer a mempool já foi enxurrada com as transações do atacante, mais atrativas pros mineradores por conta das taxas mais altas sendo oferecidas.

Mesmo que a transação original venha com a bandeira Replace By Fee desabilitada e tenha sido aceita por um node que respeita essa bandeira, o atacante ainda pode submeter as transações dele pra mempool através de outros nodes, já que a grande maioria deles permite full RBF independente da bandeira RBF presente na transação original.

Esse hack só funciona no contexto do puzzle/desafio por conta das chaves privadas mais curtas (66,67,68,69 bits etc). Fora desse contexto é impossível empregar o método pois as chaves privadas usadas na rede possuem todos os 256 bits.

I'm working around the clock to fit 2^160 magic circles into mcdouglasx brain fart db so I can astral project myself in front of it at 3am during a full moon, while Rotor-Cuda runs on the background searching for 1 trillion divided public keys in a smaller range. This is it guys, wish me luck.

Update: Was chased down by some NSA wraith wielding a huge scimitar, am now lost beyond the coordinates 00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63, 3f3979bf72ae8202983dc989aec7f2ff2ed91bdd69ce02fc0700ca100e59ddf3. Please send help.

Oh, look! Digirombs is here too, hey dude

If I might ask, GPU based or is it something else?

Congratulations by the way, we are pleased to finally meet you.

Regarding this very specific problem, one limited approach I can think of is to subtract G from your initial pubkey and keep them both; the initial and the offset resulting from this subtraction.

Now one of these two is sure to have an even private key, as some pubkey minus G = its private key minus 0x1.

Then you "divide" them both and at least one resulting offset will be within the desired interval.

Idk if this would be a feasible approach for your original problem tho, as the "decision tree" grows exponentially every time we repeat this process.

I'd like to add here that it was announced from the very beginning that his program was limited to a 125bit interval. lol.


So yeah, for the people that ran it against #130; this stupidity is entirely on you. Instead of complaining that someone else did not hand out to you a perfect implementation go and actually create your own.

Otherwise you will end up with 0 Bitcoins AND 0 knowledge. And knowledge is the only thing that most of us here might ever gain from this challenge. 

Shouldn't we be looking at FPGAs by now?

I'm actually working on a little project to get me started with Verilog.

It is a simple xpoint-only bruteforcer for now. The design works fine, but I couldn't fit it on the target chip yet.

The main goal is to get to the level where I can create a HDL Kangaroo implementation.

No, I don't have enough XP to meddle with the Wheel of Fortune. This thing is just too powerful.

Just by making this simple edit it took me so much mana and HP that will take me weeks to recover.

Holy snappers, guys! How could we forget about this?

We did not write #66 off our bingo cards. Here, let me sort this out real quick:

Holy snappers, guys! How could we forget about this?

We did not write #66 off our bingo cards. Here, let me sort this out real quick:

That's right. But once you buy it you gain access to any version, I think.

I'm not going to tell you guys that you could get it from some torrent cause it might be against forum rules/country laws.

And since I'm not telling anyone that, I don't even need to say to be careful with potentially backdoored software provenient from torrents.

 

Yes, that's correct. Otherwise you could just straight up solve #130 as the public key was available from the beginning.

Most bots can steal from puzzle #67 up to the 75-80ish bits, depending on the rig's capabilities.

Any key that takes less than ~10 minutes to crack is not safe. (~10m avg block time, not always the case).

I personally would only feel safe above 110 bits, just to be sure, as we cannot really know what is out there regarding other people's cracking capabilities.

Anything less then 110 bits I would send through MARA's slipstream.

This has been answered 10 thousand times in this same thread some pages back.

The only public available Kangaroo that works beyond 125 bits is Etar's.

It's based on JLP's but it can go up to 192 bits.

It has an edge on the speed too, yielding +-1Gk/s more than JLP's (at least on my setup).

https://github.com/Etayson/Etarkangaroo

Note that its Windows only and if you want to compile it yourself you need PureBasic, which is paid.

"Here is my own assumption being profered as straight facts without any proof"

Where is the evidence to back all this fud about the creator of this challenge?

Wow. Two in a row.

 

Hey OP, any updates from Foundry?

Keep us posted, I wanna know how this ends.

I'm tending to think it wasn't any of the usuals in this thread 'cause we all thought the solver would go through MARA. For his very reason I didn't even bother to finish developing mine.

Also, I don't think anyone would bother to precompute against 66 in this scenario as the key can be cracked in mere seconds anyways.

If that was the case it would have taken much less than 45s to replace the original tx, as once you have the key it might take less than 1 second to relay the first replacement.

I was also thinking.... What if the creator himself triggered the attempted withdraw?

Reason: To officially embed this event in the challenge's timeline at the cost of 6.6 BTC, as now "puzzle #66" will be notoriously known to have been hijacked by a bot in the proposed scenario.

Am I making any sense here or am I just hitting my bong too much?  

Yes.

Wait until someone solves it and then steal the coins with a bot.

How could you not find this information? It's literally in this same page, above your own post.

There are other 4, consecutive posts showing a huge list with every known COMPRESSED pubkey from this puzzle.

I'm speechless. Someone really just sent the public key to the mempool all willy nilly