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

So what?
What can I do?

Sorry, understood

Yes. So?


Rico

Download link for linux not work properly.  Just see text (looks like script)

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

It is far more plausible that this was a "challenge" someone made, to see how long it would take to be solved - I have found many such transactions. I doubt that a weak PRNG is the cause of this key, but it being a collision with a properly generated key is so unlikely that we can safely assume that is not what happened. Even if it were, it's not really any cause for concern. Managing to crack a single key via collision by absurd luck is not going to be repeatable.

A few keys I've found:

I don't understand why you would give that advice, given that you're aware that it is much easier (but still so hard as to be not a remotely plausible threat) to brute force a collision with a P2SH address than it is to do so for a P2PKH address.

The A PK for the hash160 "f6cc30532dba44efe592733887f4f74c589c9602"

is

000000000000000000000000000000000000000000000000000022306e3f1a72


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, and when I started it up in auto it never said

"Reading balances... storable found - using that (faster)"

any other flags to add ?

I compiled a new allBalances.txt file, and was curious as to why this file is not converted to a new bloom filter file ?

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

Another point of view .. -> "bitcoin lotto"  


...

An idea to close this russian roulette bug/feature ?

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:


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

I made two mistakes.
1. I did not take into account the fact that the LBC checks only those addresses that were not empty at the time the .pst file
2. The current work block interval [36245522-36245537]
I forgot to divide that number by 8192

I made a transaction of the open test Page 5 October
http://btcdirectory.azurewebsites.net/30000000
after October 6th, you have made a new file balances.pst
but the purchase transaction confirmation came only October 10.
Therefore, no one has found.

Now you can use these amounts for the test after the next update balances.pst
LBS -p 3661-3663

It is convenient but childish way to avoid reasonable questions. People that ignore me usually end up wasting their time and money.

Today bitcoin price is up and I'm in a good mood. I'm sorry you're in a depressed mood right now.

I know. Some prominent place where to announce this?
Not like
 

:-)



I am at a point, where I am shocked, because if it turns out I was right about the BTC PK search space, "stopping this", is like you have a patient with inner bleeding, you have proven he has inner bleeding, but you just turn away, because you think "no see no harm" is a good strategy.

Seriously?

I can stop it and tomorrow a chinaman (or whoever - just an example) decides to set up a clandestine GPU farm doing exactly that.




@becoin: Too bad I see just "this user is ignored". Perhaps you should have spilled out less shit. Maybe someone else can answer you - I'm not in the mood to unignore you right now.


Rico