I will be updating the LBC manual, so make sure you have a look from time to time.


duly noted


Good to see, that the VM solution under Windows has superb performance. I do not feel great pressure to push a native Win-version right now and will probably focus more on a GPU client.


Rico

Second guess would be you have no internet connection, or port 20/21 (FTP) is filtered.
Other than that, I have no idea.

You can beat it manually to do your bidding. Also known as "Clubbed to death" method:

Download


ftp://ftp.cryptoguru.org/LBC/generators/161008-1d02144cdfbf81767255c040e0b7861c.gen-hrdcore-sse42-linux64.bz2

bunzip2, rename to gen-hrdcore-sse42-linux64

download


ftp://ftp.cryptoguru.org/LBC/blf/161011-4a9d2c4412e667d864bbfdfa5927bc79.blf.bz2

bunzip2, rename to funds_h160.blf

Try again.

Hope, that helps..


Rico

ls -al would have been more enlightening, but my guess is:

LBC directory belongs to root, you are user "ginky", therefore have no write permission in LBC, therefore no generator and no blf file can be downloaded.


Rico

I agree with the surprise-level. As I wrote further above in the thread (soemewhere discussing the days until the #51 puzzle) I already suspected this, which is why I kept the pool forefront where it is.


Now that's an incentive. I wonder if there would be a better place to announce that than here.
As nrg1zer wrote here: https://bitcointalk.org/index.php?topic=1573035.msg16523769#msg16523769
even if the owner of 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg sees (and cares about) that drain, how should he know where to look?


Rico

Hmm...

Is it executable? (chmod a+x gen-hrdcore-sse42-linux64)
If you are running LBC as a different user - do the files belong to that user?

If all of this is ok, try a

export PATH=$PATH:.

then start LBC. If that works, there is a ./ missing somewhere.


Rico

I'll have a look. You can download the newest .blf from here

ftp://ftp.cryptoguru.org/LBC/blf/

obviously the file is

<newest dateYYMMDD>-<md5>.blf.bz2

bunzip2 it, rename to funds_hash160.blf and off you go.

That process should be transparent and done by LBC ... *sigh* Jarvis-IQ is still not there.  
Fortunately, if I update LBC, your LBC should auto-update and be magically fixed.
In theory.  

edit:


Auto-healing FTW! 


Rico

Or at least anyone who would/could try it?

There is now a generic 32bit HRD-core available and the newest LBC is aware of it.
If you look at the Generator Speeds, that should give your client a nice bump in the keyrate. Also, the memory requirement is now also around 550MB for the Linux 32bit client.

Also, feel free to PM me with your CPU Ids and keyrates, so I can update that table.
I'd be especially interested in AMD CPUs performance as I have no experience with these so far.


Rico


@becoin: *plonk* - I'm really too busy now and cannot put additional effort in your education on top of all that. Sorry.

Yes. So?


Rico

Facts.


If you read the thread again, I didn't claim there was a collision, I left that open. I still leave it open. It was YOU who claimed it is NOT a collision.


BINGO! Therefore you shouldn't have made that statement in the 1st place.


Congrats, you discovered my subtle hint (see above for the resolution), but you failed apply it to the situation. But it's ok, I can give you credit for that. Instead of "heavily infested" I reduce my rating to "The DK is strong in this one." Please, take it as encouragement - you're getting there. Eventually.


Again, false assumption. I did not say "Look! A collision! This is the proof!"
I said "This key looks weird, it is unexpected. If someone comes along to reclaim the funds with another key, we have a collision for sure."
Even to you, I wrote that the proof will be here if another key appears.


That is called cognitive bias.

I do not require you to prove this NOT being a collision. I require you to simply - like me - leaving that statement open until there is proof (a.k.a. "shut up").
Which you didn't - you made the statement "This is NOT a collision" which you cannot prove, so your statement is bullshit. Now you know, everyone does. Try to avoid BS next time.

You managed to sneak in a couple of fallacies again. One being:

The pool IS searching for collisions. Ok, you may have a different opinion. However, stating this "title" is wrong/misleading until a collision is found is utter bullshit extraordinaire.

That's like the following statement: "Saying 'I'm driving to New York' is wrong until I am there."

See? We can reduce the DK level further if you do.


Rico

Then maybe read again the context.

If someone would be - for whatever reasons - afraid of the pool, P2SH is the solution, as the pool simply doesn't search these.


Ryan... I take that statement and put it on my stack, where it remains together with your statement, that the 1st 50bits have been searched already.
Both statements will have the same weight on my stack for the time being.


Rico

Davon redet ja keiner. Aber man kann sich an die Schulmathematik erinnern und weiß, dass zwischen einer Menge von der Mächtigkeit 2²⁵⁶ und einer von der Mächtigkeit 2¹⁶⁰ einfach keine bijektive Abbildung hinzubekommen ist. Das ist ein Problem hinter der EC. (also später im Prozess), da kann die EC vorher rumturnen wie sie lustig ist.


Du hast es immer noch nicht verstanden. Aber egal - kommt schon noch. Kommt Zeit, kommen Gegenbeispiele.

Das war nicht ganz so klug von Satoshi hinter den SHA256 einen RIPEMD160 zu klemmen. Hätte er doch nur einen RIPEMD256 hergenommen. Naja er war vermutlich auch nur ein Mensch oder RIPEMD256 zu der Zeit nicht verfügbar. Ansonsten ist natürlich die Idee diese zwei Standards zu mischen schon elegant.


Rico

Da sieht man gleich, wer schon mal einen LBC benutzt hat und wer noch nicht. 

https://bitcointalk.org/index.php?topic=1573035.msg16530267#msg16530267

Die PKs kommen aus dem HRD_core immer als hex daher. Kein DEAD drin diesmal, aber ich werde das im Hinterkopf behalten.


Rico

The A PK for the hash160 "f6cc30532dba44efe592733887f4f74c589c9602"

is

000000000000000000000000000000000000000000000000000022306e3f1a72


Rico

Vielleicht auch nicht.




Es hat AUCH diesen Effekt. Natürlich - wenn wir von einem so kurzen PK reden.

Der Begriff "a posteriori" sagt Dir was?


Rico

No sweat, I also once wanted to place bounties for the pool and basically underestimated the pools' speed growth, so all people found was a false positive. :-)

Nevertheless with the newest balances there still doesn't seem to be anything in the 3 MKeys you've given:

Or maybe I did the .blf file too late (2-3 hours ago) and the funds are gone already?  

Rico

Ok - to sort some things out:

If you have a HRD-core generator, it doesn't use the balances.pst at all, only a blf file.

balances.pst is used only in conjunction with the the Go-generator

If you have a allBalances.txt file and remove the balances.pst (or call it with -forceparse), it will create a balances.pst and also a file "funds_h160.hex"

the .hex file you have to transform into a .blf file using the hex2blf utility that comes with brainflayer:
https://github.com/ryancdotorg/brainflayer

edit:

Just tested. You found a bug. Remove the balances.pst file, call LBC with -forceparse and it will create a new one and a funds_h160.hex file too.

edit2:

However, I would like to point out, that the possibility to supply your own .blf and .pst files is only a residual from earlier times and probably superfluous with Jarvis' autoupdate capability.
It was meant solely to give you a way of having an up-to-date blf/pst and not to screw around with it, which is a shortcut to the pools' blacklist.

Rico

Oh wie gütig. Danke. Könntest vielleicht noch gleich nachschieben wie ein von "euch" (ist das Pluralis Majestatis oder was?) zu akzeptierender Beweis aussehen müsste?



Das ist nicht bewiesen und auch nicht wahrscheinlich. Schon mal einen Blockexplorer bemüht?
https://blockchain.info/address/1LgLVFKWnvYffKQdwYoKoPQvMvWNDYcS4x
Die 1PV... sieht für mich wie ein ganz normaler unspent Output aus.
Unterscheidet sie sich für Dich irgendwie von all den anderen?

Der Schlüssel ist tatsächlich schlecht und zwar so schlecht, dass den kein User manuell erzeugt.
Selbst eine schlechte Brainwallet -> durch einen SHA256 gejagt hat nicht die führenden 210 bits mit Nullen vollgekleistert.
Also keine mir bekannte.



Ich gebe es nicht zu, ich stelle es fest.


Ich sehe nicht, wei man diesen Schluss ziehen kann.


Ich sehe Dich schon im Mittelalter nachweisen, dass eine Frau die nicht ertrinkt wenn man sie ins Wasser wirft aus Holz und folglich (alternativlos) eine Hexe sein muss und verbrannt gehört. Ehrlich - ganz deutlich vor meinem geistigen Auge sehe ich das.

Guggst Du  im obigen Blockexplorer nach. Sieht nach Standard Output aus. Etliche andere Adressen haben oder hatten nicht größere Beträge drauf.


Wäre da nicht der Smiley (den ich jetzt benevolent als "Satire" interpretiere), müsste ich fragen "Bist Du blöd?"

WENN es etwas gibt, was mich für die investierte Arbeitszeit entschädigt, dann ist es die Möglichkeit hier im Forum Deppen öffentlich vorzuführen. Und dazu gehören auch unqualifizierte Skeptiker.



Ich habe ja auch nicht vor den Collider nach dieser kleinen Schwalbe abzuschalten. Vielmehr sehe ich mit Spannung in die Zukunft um dann die Fakten gegen das Gerede hier im Forum abzugleichen.




Rico

You mean "What can one do to prevent the pool from finding his PK?"?

At the moment my only advice is: Move your funds to a P2SH address.


Rico

I thought I give the shitty Amazon AWS EC2 a try.  




Rico

  Ok Gonzo, you beat me to it:


Why is it not a collision? How do YOU prove the PK used when this address was generated was not different from the PK found now?
At a time, when you by all means most certainly don't know ANY of the PKs. What is it, you do not understand in this statement:


You see - to me, the fact that you are writing many, but short and shitty (= not well thought out) texts just proves you to be some kind of poor miserable existence. Usually I do not waste my time with your kind, because there are way too many like you. So - heaven help - try to understand what this is all about, what's being written/said and THINK about it. I know it's quite a lot of text and it may be hard for you. Just try. It is ok, if you give it more time, because it seems you need more. (In everyday pool operation, I see that missing processing power can be counterbalanced by throwing more time at it.)


Another "I just vomited something without even spending a microsecond thinking about it".

Or maybe you are heavily infested with Dunning–Kruger and do not even know what to think about. Let me help:

Proving the non-existence of something is impossible. That is BTW also the reason why there is the presumption of innocence. You cannot prove you are innocent, you can only be proven guilty. Understood? I sure hope so.

I cannot prove to not have been the "rightful" owner of the found PK, but there is evidence now and in the future to support the claim it is an original not-belonging-to-me-or-someone-I-know PK.

Let's get some pedantic semantics out of the way first:

Now that I found it, I may very well be considered "co-owner" already.
If the PK found is not the original PK used (remember? there are like 2⁹⁶ PKs to every address) I am at the moment the sole owner of the PK found.

Ok - here comes the evidence your honor:

The unspent output is from May 2014. If you think I staged this up 2 years before I even thought about starting the project, I feel flattered. You must certainly think I am some long-term planning mastermind genius. Thank you. Unfortunately, that doesn't change what I think about you - sorry.

Not only would I have to do this at a time when I was doing completely different things, I would also have to rely on a shitty 50bit 45.x bit PK to hold for over 2 years. So I would not only be a long-term planning mastermind genius, I would also have ballz of steel. Again, thank you, thank you. But no - I didn't.

Now would be/is a really a bad time to pull something like that off. I am in the middle of releasing the next LBC and in fact today morning, I 1st checked my private messages with beta tester reports before I realized that FOUND.txt file when I wanted to fix the bugs. I also write the new manual etc. etc. Lots of work, bad time. Bad timing.

First I even thought it was another hash160 found from the puzzle transaction, when I saw it had funds on it, I thought it might have been the bounty that yo-blin announced and only when I saw the date, I realized this is different. Sure. All this is no "proof", only describing the situation as it was.

If in the future really someone comes along and presents a PK that is different from what has been found, you will a) have collision proof b) very strong evidence this is genuine. Until then, shut the fuck up unless you have to say something of importance.

Rico