Topic: Large Bitcoin Collider (Collision Finders Pool) - page 47. (Read 193484 times)

I think I understood it. So, it seems that you can fetch work but then if you stop the execution of the program that work will be lost. is that it?
What will be the best way to stop LBC in a graceful manner? Or instead would be better to use  --time ?
.. and if there is no way to stop it gracefully you can just stop it and then process the blocks interval you were working with --pages  -, right?

thanks

If you are from Helvetia, https://bitcointalksearch.org/topic/m.16815398
if no, same applies here and I can translate the german text.


Rico

Hi, this seems a very interesting project - great work rico666!
I'm still getting familiar with it but meanwhile when I try to check my rank - for sake of curiosity - I'm getting:

$ ./LBC -q

Problem connecting to server http://lbc.cryptoguru.org:5000//query(status: 500 Internal Server Error). Retries left: 2
Sleeping 8.488 s...

Problem connecting to server http://lbc.cryptoguru.org:5000//query(status: 500 Internal Server Error). Retries left: 1
Sleeping 15.169 s...

thanks

Would you mind to work on your excessive quoting habbits?


Rico

There is. In theory, the multiplier between two consecutive keys can be anything between "a little bit more than 1"

0b11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111

->

0b10000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000

and "almost 4"

0b10000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000

->

0b11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111

  hehe - count the digits.

However, these extremes could only co-exist with their extreme counterparts for the pre-previous or the after-next key respectively.

i.e. if #M is almost 4 times smaller than #N, then #O can be at most 2 times bigger than #N and then #L would be at most nearly 2 times smaller than #M

(for the L > M > N > O sequence)

This is also the reason why the sum of two consecutive numbers in your list will never be more than 6. If you send me your spreadsheet, I'll have a look and maybe do some enhanced statistical analysis on it. I need a break from the horror that is (portable) OpenCL.


Rico

Nice, added to my spreadsheet!

Thanks Rico!

P.S. going from my records the next key will be found between 1.1 and 3.1 times the previous decimal key found.

Starting from the first address to number 47 this is the multiplier of the previous PK decimal value:

0
3
2.333333333
1.142857143
2.625
2.333333333
1.551020408
2.947368421
2.084821429
1.100642398
2.247081712
2.322943723
1.944092434
2.021472393
2.548084219
1.917221871
1.860279557
2.073291381
1.799651682
2.414636329
2.098608043
1.659986069
1.861611443
2.577100601
2.299969103
1.643454135
2.052663677
2.033358892
1.760317772
2.578335793
2.034906801
1.471408704
2.307257358
1.980132413
1.42310685
2.107494664
2.365105799
1.466027419
2.202637167
3.100321289
1.452946896
1.985510149
2.559189118
2.07896823
1.298070259
2.570888168
2.327752465

Lowest: 1.100642398
Highest: 3.100321289

Is there a reason behind this?

f828005d41b0f4fed4c8dca3b06011072cfb07d4 -> 0x6cd610b53cba


have a nice day.


Rico

I've built a new .blf (and patch) with todays state of the blockchain.
Please restart your clients, so they will check for updates and download.


Rico

None of any significance.

GPU generator in the making, got an alternative implementation from a member here, inspecting that, maybe merging best of both worlds.

Patience. Maybe Christmas present or maybe a New Year's resolution for LBC to go GKeys/s.


Rico

Any news?

Damn BN calculators!

I count only 2.92300327466180583641e48 - that's a whopping 29 orders of magnitude smaller.

Rico

Yay, only 1.1579208923731619542357098500868790785283756427907E+77 more addresses left to check!

As of today, 100 trillion keys were searched.

As for #47 of the puzzle transaction: ETA is anything between 0 and 269 hours.


Rico

That would be the jackpot, of course. But really interesting question is who is providing the pile of money to be burnt out in unproductive hashing?

Nah - that's not the purpose of the LBC pool.
That will be the purpose of the CWR pool I will set up after we have searched the whole PK space.

While I do believe the pool will find a significant number of PKs, I also do believe this (and how we will handle it) will have no adverse effect on Bitcoin price. These two beliefs are not mutually exclusive - I believe.


Rico

.
.
.
.
.
.

CraigWrightReloaded - in case you had trouble figuring it out.

no, rico is trying to find a key from an address of the first tansaction so that he can claim to be satoshi when he sign with this key.

SCNR

This is pretty simple actually. The purpose of the pool is to cause a drop in bitcoin price so that rico and the likes buy back the bitcoins they have sold out at much lower level.

Sounds cool.

My client is currently down as it does not have the newest update.

But I have a nVidia Quadro 4000 in the client that is also ready to work