Like in 23 days "or so" we will have #52 
https://lbc.cryptoguru.org/stats

And that's just because we're covering our 4-day "search debt". @BurtW - you hear this?


Rico

-c is the challenge. 10000 is for testing purposes (normally you can see the challenges if you look at the process table when LBC is running)

-L is the number of loops = number of times 16,7 Mkeys consecutive blocks search to perform

if you want to check individual keys,  LBC -p is a way better option:

https://lbc.cryptoguru.org/man/user#manual-mode

as you can give them in binary form, LBC correctly "snaps" the key range into block boundary form and you can give a from-to range without having to worry about the loops or challenges. You can even mix hexadecimal and binary from-to parameters. And even key and block numbers. I had an attack of genericity when implementing that.

If you are afraid not to give away any information about privkeys, either pull the network plug, or simply give the "to" parameter with some more distance and end the LBC hard with Ctrl+C before it ends.

With the -p parameter, LBC does not even send a promise (to do work) to the server and if you end it hard before the work is done, it does not send its PoW -> as if it never happened.

edit: But not sending PoW will of course freeze your stats. So unless you are testing privkeys you do not want to disclose, send the PoW.


Rico

More or less? 

The difference is 1461501637330902918203684832716283019655932542976 keys to search.



I have the suspicion that more people want that...

By the way: The 6-month grace period for 16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE will end May, 10th. Then, these funds will go to the LBC pot (= for distribution among clients) and yes, I assume the pot will contain some bonus BTCs also.


Rico

1%/Monat gibt es bei mir auch:

100 BTC Mindesteinlage, 1 BTC monatlich zurück. Laufzeit: 100 Monate.

mbH 


Rico

(ist nicht ernst gemeint, bevor jetzt jemand einen Anfall bekommt)

If I was to have per-user keyrate charts (hourly), would you agree them to be public or not?


Rico

Why 2^161?

1 bit = 2^1 keys (-1)
2 bit = 2^2 keys (-1)
3 bit = 2^3 keys (-1)
...
160 bit = 2^160 keys (-1)

Anyway:

https://lbc.cryptoguru.org/stats
https://lbc.cryptoguru.org/trophies

Rico

I think the same reason as for sweeping #1 - #50: These are bounties - right?

Rico

Ich bin dabei die Stats etwas aufzubohren, wo man die individuelle Keyrate sehen kann.
Ganz ehrlich: Wenn der diesmal auch nichts gefunden hätte, dann wäre das extremes Pech gewesen.
Bei seinem Anteil an der Keyrate hätte ich dann seine Wahrscheinlichkeit ausgerechnet nichts zu finden.

Rico

It's not me.  Don't know if Unknownhostname is experimenting or what.

I do consider all puzzle transaction addresses bounties, so this one does belong to Unknownhostname.
As far as I am concerned it's his.

Rico

I repeat: LBC found #51 tonight!   


Rico

Mir hams! 

Unknownhostname just informed me, that he found #51.
And because he has shown me the privkey, I know he's not making it up.

Please stand by for further details...


Rico

  Sorry, LBC needs at least 3 3 in 1337

I know what you mean. We have no proof of correct work @ runtime. Even less so for every single key.
We have proof of correct work before generators are released. Then, we have "only" proof of work (done).


It is. If your machine had e.g. faulty memory or a CPU/GPU that would exhibit faulty computations, your client would effectively pollute the "done"-db. Of course, your client would have to exhibit this behavior after the LBC -x run (which would have to run without errors).


Do you have any mechanism in mind? We could issue periodic "LBC -x" runs for the extra paranoid.


I think I am pretty well aware of the "rare event" problem. In fact, programming the LBC is like programming a spacecraft: After months of no events, you need it to do the right thing within seconds. I give you that "anyone with ADHD is in the wrong place here" is not soothing. Ok.

But "I trust the LBC codebase" should be.

We have still over 100 tn keys search space, so there is hope. We may also have already a FOUND.txt slumbering somewhere again and the operator slumbering too.  There is still hope. Time for frustration is tomorrow 11 a.m. UTC


Rico

We don't. It might actually be the reason why #51 is "still standing". Then, on the other hand, the so-called puzzle transaction would have a certain trolling aspect and it would not fulfill the "canary in a coalmine" function as many (including me) suspect it does.


LBC is certainly not for the faint of heart. It's actually one of the reasons I do not give e.g. GPUauth to anyone who thinks his "willingness to test it" is qualification enough. If you start with LBC you know you're in for the long run. If not, you're just wasting your time and resources.
As for incentives: We will have a nice incentive firework from SlarkBoy soon - where "soon" with LBC means "within a week or so". Clearly, anyone with Attention deficit hyperactivity disorder would be in the wrong place here. 

We're giving found BTCs back to their rightful owners, because that's the morally right thing to do. On the other hand, there are potentionally a million lost BTCs we might be able to recycle. If that's no incentive for someone - I could understand that - then LBC is of course the wrong project for him.

---

While I do trust the LBC codebase, we're really entering uncharted territory here, so if someone of us doesn't confirm the #51 find, probably no-one will. Except the maker of the puzzle transaction and that one chooses to remain silent.

As for proof of work, read https://lbc.cryptoguru.org/man/tech and https://lbc.cryptoguru.org/man/admin#security
there is a tight challenge-response framework in place to make sure delivered work was really done by the generators and code tampering  to circumvent this has been refuted ever since.

Should we ex-post become aware of any client having cheated, it's one script call to carve this client's work from the "done"-database.


Rico

Good morning guys (and becoin)!

No sign of #51 yet? We're seriously running out of search space - less than 24h left.

Rico

I am willing to answer a stripped down version of your questions.

That is, after you have read this thread where some of your questions are discussed - in length - already.


Rico

Just yesterday I have thrown the pleiades source code from my Sandbox (I have it still in the repository though), because
with the arulbero-EC arithmetics and my GPU hash160 implementation we have something better.

Having said that, both the KNL as well as the Skylake-EX with their AVX512 engines are a hell of a machine for EC arithmetics.
If anyone has these processors, I can provide a generator binary.
So if anyone is looking for a dedicated machine with quite some key generation performance:

KNL + GPUs (probably too expensive) or Skylake-EX + GPUs (less expensive, but still some bucks)

With these we're getting in the region of 100s of Mkeys/s per machine.


Rico

Holy Sh!t - if you look at the "Notable Dates" section of https://lbc.cryptoguru.org/about
you'll see the pool needed about 4 months to crunch its first 100tn keys.

The more we are into #51 search space (only 270 MBlocks to go), the more nervous I get. #51 is a mean bitch for sure - but should we get to the end of the search space without a hit I will have to shoot myself.

On the other hand - that's how I felt with #49 too. 


Rico

Very nice.
Please always remember

LBC: 100 Mkeys/s = 200 Maddresses/s
oclvanitygen: 270 Mkeys/s = 270 Maddresses/s (only compressed)

edit:

theoretically, you could distribute the load to your GPUs 3x 10 (or 10+11+11) and let one do other mining stuff.
4 x 64% = ~ 256% -> 144% spare capacity so one full GPU for sure.

I thought about exactly such a configuration (4 x 1080, but Skylake-EX core to feed the GPUs, should come close to 200 Mkeys/s)


Rico