The rightfull owner could send you a signed message, BUT if i would be the owner, i would have no idea who to contact. I dont think alot of people are reading your thread. It could be any wallet... maybe a cold storage or something. You could wait years before someone show up. And even if the one realizes, his coins are gone, how could he know you took them.
I know. Some prominent place where to announce this? Not like “There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.”
:-) I think you are at a point where you have to decide if you want to stop this, because you have proven it works, or if you want to continue, but this could be called theft. Which way you will go?
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 |
|
|
|
https://bitcointalk.org/index.php?topic=1573035.msg16523548#msg16523548Wobei ich im Moment eigentlich keine Zeit für so einen Mist habe. (Jarvis Betatest) edit:Ok - was ist passiert? Sieht so aus, als hätte ich (ja, ich - mein Client) den Privatschlüssel zu https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGggefunden. Naja "sieht so aus": Für euch sieht das so aus, für mich ist das so, denn ich konnte den Schlüssel in mein Wallet importieren und die Funds auf die Addresse https://blockchain.info/address/16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE transferieren. Nein, ich habe nicht die Absicht diese 7.x Millies zu behalten. Wenn sich der Eigentümer meldet (Fristen wie in der EU nach Fundrecht üblich), runde ich den Betrag sogar auf 0.01 BTC auf und gebe ihm den zurück. Wenn nicht, geht das als Bounty an die Poolmitglieder. Ich vermute stark, dass es sich tatsächlich um eine Kollision handelt, weil kein Mensch wäre so blöd und würde einen PK mit 45.x Bits Länge verwenden. Daher denke ich auch, dass der rechtmäßige Eigentümer ohne Probleme einen alternativen PK vorweisen kann. Wenn nicht, soll er bitte nachweisen wie er zu diesem PK kam (kaputte Software?). Der Fall zeigt aber auch zwei weitere Sachen: a) Ich liege mit meiner Suchraum-Hypothese vermutlich richtig b) Die ersten 50bit Suchraum wurden eben nicht bereits - wie von Ryan C. behauptet - komplett durchsucht. Kann ich beweisen, dass https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg nicht ursprünglich mir gehört hat? Wohl kaum, denn wenn ich eines Negativbeweises fähig wäre, würde ich mir als erstes Gott vorknöpfen. Aber diese Adresse lag da schon seit Mai 2014, also über 2 Jahre, bevor ich auch nur einen Gedanken an einen Collider verschwendet habe. Zudem - wie gesagt - mit einem wirklich schlechten Schlüssel, wenn ich also damals (grandios vorausschauend und von langer Hand geplant) diese BTCs hinterlegt hätte, dann muss ich überdies mächtig Eier in der Hose haben, weil ein 45.x Bit PK über 2 Jahre in der Blockchain zu lassen... Kurzum: Der erste richtige/tatsächliche Fund und ich hoffe sehr, dass sich der Eigentümer meldet. Wenn er dann nämlich einen anderen PK zu dieser Adresse hat, als vom Pool gefunden wurde, haben wir das Corpus Delicti. Rico
|
|
|
|
Hi I stay gift on the secret page directory.io for check I think it will be found this about one week  You wrote this October 5th and although a week is almost over, I assume you are not talking about https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGgbecause this has been deposited in May 2014. I swear I have nothing to do with this address - except my client found its private key tonight!I must admit, I am still quite puzzled, because if things are as they seem (to me), this would be the 1st real (like in real real) PK found by the pool. Is this for real or am I still not fully awake? Damned be the TODO - I thought we would have more time to sort that out. Ok, how to proceed if I find something?
The most important thing is to handle your knowledge about the found private key as if it was yours. I.e. under no circumstances is that key to be announced anywhere publicly. You may have good intentions, but you never know who's listening. See if you can contact the person behind the address you have found the key to. TODO: Reference to a best practice approach of contacting the owner has to be elaborated/added.
I know - I wrote this text, but it is bad. So what will be the process? I looked up various European national regulations for finders-keepers. There is a deadline of 6 months after which the finder gains the ownership if the original owner does not show up or make a claim. If the value of the found is less than 10EUR (Germany), this deadline runs from the day found which would be today. Still, the original owner can claim it back for a period of 3 years. Here's what I think - so far - should be done: - I transferred the funds to 16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE
- When the confirmations are through, I may or may not (should I? What are the pros/cons?) publish the PK
- I have of course no intention to keep these funds (like $5 dollar atm)
- If the rightful owner does show up within the 6-month period, I will even round up that sum to 0.01 BTC and give that back.
- If no one will show up within the 6 months, the funds will go as pool bounty to its members.
- If - after that - the owner should appear within 3 years, I will transfer these 0.007899 BTC back to him regardless
Phew. I'm glad this has happened with such a small sum. Honestly, I pulled this process out of my nose today morning, so I'd really really appreciate if the Bitcoin community could work out some "standard" to this. I've looked up the forums and this case seems so exotic, that most of the takes on it is really just nonsense blah blah. So: How can one make clear he is actually the rightful owner? Just stating "It's me" obviously won't cut it. It may very well be, that he used an entirely different PK (of the 2 96) for this address (because this one is a little bit shitty), so I assume providing ANOTHER PK to this address would count as good proof - wouldn't it? Rico |
|
|
|
And.... how to get .857 ?
Try to steal my notebook.  Or wait a couple of days and get 0.860 - or so. Working on a new release as fast as I can. Rico |
|
|
|
Got it, thanks.. I was mining last night and I woke up to see "Server requires minimum client version 0.841.". Where is .841 ?
Glitch during the server update (new shinier stats) - unfortunately. Apologies. For now 0.832 is still good enough a.k.a. minimum requirement. I ditched the "factor" info in favor of the keys/s already: # LBC -v
0.857
# rm benchmark.pst
# LBC -c 1 -t 1 -l 1
Best generator chosen: gen-hrdcore-avx2-linux64
Benchmark info not found - benchmarking... done.
Your maximum speed is 562959 keys/s per CPU core.
Ask for work... got blocks [33206546-33206593] (50 Mkeys)
I hope it's more intuitive this way. Rico |
|
|
|
So what's up with this latest build ? I was getting a benchmark of 2.5 with 2 cores, went up to 16 cores and my benchmark went DOWN to 2.49 ??
Lower numbers are better? Although 2.5 -> 2.49 is probably a measurement tolerance. The benchmark is 1 mio keys per <time shown in seconds> I will add a translation to keys/s. If you get a factor of 2.5 it means you're doing like 400000 keys/s per core. 2.49 -> 401606 edit: Also please be aware, that hyperthreaded cores yield only about 30% of the performance of physical cores. So let's say you have a 8-core CPU with hyperthreading enabled (16 logical cores) and benchmark shows 2.5 That means you can do about 3.2 mio keys/s with LBC -c 8, but only about 4.16 mio keys/s with LBC -c 16 Modern CPUs may perform a little better. Personally, I leave the hyperthreaded cores alone, so while my CPU has 4 physical and 8 logical cores, I drive LBC with -c 4 The hyperthreaded cores are left for the OS and are more than enough (for me) to do my programming, browsing, even compiling. Rico |
|
|
|
Who's trembling in despair now, mortal?  Indeed. In my defence, the reason why this lapse happened is me programming my ass off for the past two weeks. Dropping off the keyboard - barely awake, I just started my LBC client to have it some searching done while I was snoring away. I didn't realize it was still pointed to my development server. Well... So what am I programming anyway? This is what a "cold start" looks like now: # ./LBC -c 2
Generator: gen-hrdcore-sse42-linux64
New generator found. (DL-size: 0.41MB)
New BLF data found. (DL-size: 166.22MB)
Benchmark info not found - benchmarking... done.
Benchmarked factor 3.581787
Ask for work... got blocks [31833874-31834225] (369 Mkeys)
ooooooo
etc.
You basically download ~40kB of code and it figures out the rest. In theory. If there is a new generator available, it updates and benchmarks. If there is new balances data available it updates. If there is only a diff, it downloads that and patches to minimize data traffic. If the server is unresponsive, it retries. If you query the server, it answers: $ LBC -q
Server answer to 'query' is:
{
"done" : 999204,
"lastsee" : 1475960421,
"ips" : {
"<some IP>" : 2028,
"<some other IP>" : 234
}
}
'done' means we have delivered 1047.741 valid Gkeys.
So I will - once again - need 2-3 diehards to test a "Jarvis" pre-release next week. You should have a Linux 64bit and a machine capable of AVX2 or SSE4.2 Rico |
|
|
|
I turned on my notebook with my special icc-compiled Skylake-optimized generator. So - tremble and despair mortals - tomorrow we should see at least 15 MKey/s provided no one else jumps on or off. ;-)
(yesterday evening)
$ LBC -t 20
Will use 4 CPUs.
Ask for work... got blocks [17036118-17038805] (2818 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
etc.etc.
Ask for work... got blocks [17630502-17633189] (2818 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [17633190-17635877] (2818 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (today morning "wtf? only 2GKeys in stats) ***AAAAAAAH DAT DEVELOPMENT SERVER!!!!!****
My notebook hammered 33.5 GKeys over night to the development server in some area explored long ago.  Please someone shoot me. Rico |
|
|
|
Only 12m keys/sec right now.
What happend? :O
Hmm... Seems someone needs their processing power for other tasks. Let's see if that is only temporary or not. As 90% of the pools performance seems to come from 5 (in words: f*i*v*e) people, such a fluctuation may happen if 2-3 of them have to point their machines to some other task. The pool speed shown is a moving average updated once per 24h. I turned on my notebook with my special icc-compiled Skylake-optimized generator. So - tremble and despair mortals - tomorrow we should see at least 15 MKey/s provided no one else jumps on or off. ;-) Rico |
|
|
|
edit: if you download the HRD-client after I posted this, I have already repacked http://62.146.128.45/download/LBChrd-0.837_l64.tbz2so it contains the newest blf file (also md5sums is updated, so you can check). In that case reloading the blf file is not necessary. Hi I stay gift on the secret page directory.io for check I think it will be found this about one week In order to be able to find it, all HRD client operators should download (166MB) the newest blf file from: http://62.146.128.45/download/LBChrd-client/161005-635eefe9b85d45003fecc19b747d3817.blf.bz2After download, please bunzip2 that file > bunzip2 161005-635eefe9b85d45003fecc19b747d3817.blf.bz2 Then you can check file integrity by > md5sum 161005-635eefe9b85d45003fecc19b747d3817.blf Which should yield the same result as you can see in the file name. Finally, rename the file to funds_h160.blf > mv 161005-635eefe9b85d45003fecc19b747d3817.blf funds_h160.blf Of course the new funds_h160.blf file has to be put in the LBC-client directory. And during the replacement, no LBC client/generator should run as you might get errors in block generation and therefore lose work. ---- All Go-client operators, should download (215 MB) the newest balances file from http://62.146.128.45/download/LBC-client/161005-73794d00771f739e5f8e9845ba2f75e7.pst.bz2Procedure is the same as above, except you rename it to balances.pst Rico
|
|
|
|
Die normalen Privaten Schlüssel mit dem Beginn 5J fangen erst extrem viele Keys später an, da Rico ja mit seinem Generator sozusagen Directory.io durchsucht nach der Reihenfolge der Keys. Genau das ist aber der große Irrtum. Ich behaupte: Wenn SHA256 und RIPEMD160 genau so funktionieren wie sie funktionieren sollten, also für eine gleichmäßige Verteilung der Hashwerte sorgen, dann befinden sich alle Bitcoin Adressen bereits in den 160 ersten Bits Suchraum. Und dann nochmal in den nächsten 160bit Suchraum, und dann nochmal, und dann... Und das wiederholt sich 2 96 mal. Natürlich sind sie nicht in diesen Suchräumen immer an der gleichen Stelle und auch nicht in der gleichen Reihenfolge und vielleicht sogar nicht immer alle. Aber prinzipiell ist es ja so, dass es 2 96 private Schlüssel zu einem hash160 gibt. Reicht ja nur Einen davon zu finden. Wenn diese Hypothese nicht stimmt, dann verteilen die Hashfunktionen nicht gleichmässig und dann haben sie eh ein ganz anderes Problem. Rico |
|
|
|
|
Would you please form your own thread for ETH/ETC in the Altcoin section?
I'd like to not have to bother the admin.
Rico
|
|
|
|
Hi Bro,
...
Would you please guide me how to replicate your source code and Super Vanitygen for building a Collider Pool for ETH/ETC and also leverage Brainwallet by hooking into it.
...
I look forward to hearing from you.
Yo man... ... You can hire me for 0.1BTC/h but that's only the special bitcointalk.org rate for my ngah brethren. Usually its 0.3BTC/h.
For ETH/ETC projects it's of course at least 0.3BTC/h Rico |
|
|
|
Beobachte das Projekt oder den Ableger nun schon eine Weile... hätte nicht gedacht, dass es so schnell geht! WoW!
Danke, aber mit World of Warcraft hat das Projekt Nichts am Hut. Würde aber niemals alle meine Coins auf einer Adresse lagern, nicht das er sie noch findet.
Je mehr Adressen, desto besser. Wenn es statt der gegenwärtigen 9 mio P2PKH Adressen, die Funds draufhaben, 18 mio Adressen gäbe, wäre der effektive Suchraum im Schnitt nur noch ca. 135.75 Bits, bis man auf eine trifft. Wer vor dem Pool Muffensausen hat, soll seine Coins einfach auf eine (oder mehrere) P2SH Adresse schieben - da sucht der Pool nicht. Noch nicht. Rico |
|
|
|
Ich habe mit meinem Skript keine Rechenpower was ihm zur Verfügung steht, wollte nur mal schauen wie sicher BTC sind und habe den Schluss das sie ziehmlich sicher sind. Würde aber niemals alle meine Coins auf einer Adresse lagern, nicht das er sie noch findet.
Und nö, hinter schwedische Gardinen will ich nicht 😀
Keine Sorge. War schon oft genug Sachverständiger vor Gericht. Das Gutachten, das den Staatsanwalt aus dem Saal spült, bekämst Du kostenlos. Rico |
|
|
|
10mio Adressen hat mein Notebook derzeit in 25 Sekunden durch.
Sagen wir 128mio/25s ... und es ist immer noch das gleiche Notebook.  Der Pool knuspert momentan 10 mio Adressen in 0.015s durch. Rico |
|
|
|
Du kannst natürlich directory.io hier herunterladen: https://github.com/saracen/directory.ioHat lächerliche 173 lines (139 sloc) 4.73 KB Die Jugend von heute denkt immer nur in Terabytes. Zu meiner Zeit... Rico |
|
|
|
Huh? 209 days in just 24 hours? http://lbc.cryptoguru.org:5000/stats  We had a nice surge of search power last (Europe's) night. I don't mind to do the time warp again. Rico edit:Right now, I could shortcut the time to roughly 201 days by putting the pool forefront at 2^50. I won't do that, however, because I assume this is exactly what the guy(s), who emptied the previous addresses of that transaction, did: After each find, skip the search space. It may very well be possible, that by doing this, they overlooked a far more interesting address... |
|
|
|
eyyy, I am nr 7 on the stats page  I remember a time, when being nr 15 on stats page meant you had 8 blocks (0.008 GKeys) done  Actually not so long ago. I do not intend to extend the top20 list, but the next LBC release will have a -query parameter where the client can actually ask the server about itself (a.k.a. how the server sees the client), one information being blocks/keys done. That way, even those not in the top20 can check if their work "arrives" or how far they are away from being in the top20. Rico |
|
|
|
#45 https://blockchain.info/address/1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbkFetching adequate work... got block interval [19063782-19076773]
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooof0225bfc68a6e17e87cd8b5e60ae3be18f120753:c:
(hex)priv:0000000000000000000000000000000000000000000000000000122fca143c05
oooooooooooooooooooooooooooooooooooo
...
Rico |
|
|
|
|
Show Posts
