Ok, offensichtlich mal wieder der Dunning-Kruger-Effekt. Du disqualifiziert Dich gerade selbst als Gespraechspartner.
(10^23)^2 sind 10^46. Der Rest ist trivial.
Bye und viel Spass beim Strom verbraten.
Ach komm - sei keine Memme. Und der reineditierte DK ist auch ganz nett. Nur weil man Dir in anderen Foren den Dunning-Kruger um die Ohren gewatscht hat, musste den nicht bei jeder Gelegenheit selbst rausholen. So hätte ich die "Diskussion" (eigtl. Tutorial) ja schon bei Deiner ersten Einlassung beenden können. Ich schlage einfach vor, Du lernst noch etwas über Datenstrukturen. Kannst ja mal bei Tries, Bloom Filtern, Golomb-Kodierung u.ä. anfangen. Wenn Du etwas nicht kapierst, kannst Du mir gerne eine PM senden, ich erkläre Dir das dann. Rico |
|
|
|
Dann gilt aber nicht mehr das Argument, dass du den Suchraum stark verkleinern kannst, weil Du ja nur (!) einen PK mit Adresse mit positiver Balance finden musst. Hingegen musst Du exakt einen PK erwuerfeln, welcher die Satohsi-Adresse ergibt.
Du - wir sind hier nicht im Heise-Forum. Die Beiträge sollten schon einen Mindest-Qualitätsstandard erfüllen.  Das Argument mit dem verkleinerten Suchraum ergibt sich aus dem SHA256->RIPEMD160 Tandem und der Tatsache, dass RIPEMD160 durch folding (im mathematischen Sinn) bewirkt, dass wir pro öffentliche Adresse plusminus 2 96 private Keys haben. Da ist es erstmal unerheblich, ob wir nur einen PK oder 10 mio PK suchen wollen, denn diese ergeben - wie Du unten fast richtig ausführst - einen konstanten Faktor (eigtl. Divisor, aber ja 1/Faktor). Der ist 10 7 (ca. 2 23), also ist der Suchraum "nur" 2 137 groß bis man "etwas" findet. So lange man noch nicht 50% des Suchraums abgearbeitet hat, ist die Wahrscheinlichkeit, dass etwas "hinter einem" geschieht natürlich geringer, als die Wahrscheinlichkeit, dass etwas "vor einem" geschieht. Wenn sich aber die Bitcoin-Community nicht malevolent gegen einen verschworen hat, ist die Wahrscheinlichkeit, dass etwas "hinter einem" auftaucht sogar noch geringer als 50%, da es ja die immobilen Bitcoin Adressen gibt (verloren, DontSendBitcoinEater..., Satoshi etc.). Im übrigen werden Satoshi ca. 1 mio BTC zugerechnet, die natürlich nicht auf einer Adresse liegen. ... so nehmen die Betraege auf den Adressen mit der Dauer, die Bitcoin existiert, ab. D.h., auch wenn sich die Wahrscheinlichkeit erhoeht, solch eine Adresse zu finden, ist der Gewinn vernachlaessigbar.
Gewinn? Ich verstehe nicht, was Du sagen willst. Ich! Selbst wenn im Schnitt ein PK nur ein Byte ausmacht, und das ist sehr optimistisch gerechnet, dann brauchst Du 2^160 Bytes = 1.5*10^48 Bytes.
Nochmal: Und im Heise-Forum regt man sich auf, wenn die Meldung kommt, deutsche Programmierer seien nur Mittelfeld...  Um das in Relation zu setzen:
Ein Mol enthaelt 6.022*10^23 Teilchen, was exakt 12 g Kohlenstoff C12 entspricht. Nimm das im Quadrat, ... und Du ... muesstest jedes Kohlenstoffatom anfassen, welches im Erdmond enthalten ist, wenn dieser aus Kohlenstoff C12 bestehen wuerde (und Kaese ist bekanntlich zum Grossteil Kohlenstoff). Zmdst in der Groessenordnung (ich habe uebrigens sehr generoes gerundet).
Seit wann sind (12g) 2 der Mond? Rico |
|
|
|
Halte ich fuer aussichtslos. Auch, weil Du naemlich auf ein bewegliches Ziel schiesst. Was heute Adressen mit nonzero Balance sind, dass sind sie in 10 Jahren nicht notwendigerweise mehr. Bzw. wenn Du den Suchraum zu x% mit negativem Ergebnis abgegrast hast, ist dann in den x% vllt nach Abschluss schon eine nonzero Balance enthalten. Da Du das (2^160 Privatekeys) nicht abspeichern kannst so entgeht Dir das.
Kurze Zwischenfrage: Wie oft wurden Satoshis Bitcoins seit 2009 bewegt? Zumindest im Suchraum des Pools können diese "abgehakt" werden. Nächste Frage: Was ist mit all den Adressen zu denen die Keys verschwunden/verloren sind? Oder auf irgendeiner englischen Mülldeponie liegen? Welch' beweglich Ziel geben die ab? Wer sagt ich kann keine 2^160 Privatkeys abspeichern? https://bitcointalk.org/index.php?topic=1587485.0Rico |
|
|
|
Jepp, bei mir das selbe Problem. Der Download-Link für die WIN-Versionen zeigt in's nix ...  Öööh ... tralala  War ein Intelligenztest für die Windows-User. Ich habe den jetzt abgeschaltet. Rico |
|
|
|
I wonder if a pattern in private keys could be found using machine learning?
Just feed a list of known private keys/addresses and see if it can find a pattern?
What do you think?
To quote you: "I had the same idea" Nothing seems better suited than hashing to provide a perfect training set for neural networks. Lots of outputs (hashed value - input for the NN) and their respective inputs (in that case output for the NN) .... and then give it a new set to find inputs (NN output). However, I think that this idea has already been tried and SHA256 (and probably RIPEMD160 too) looks like noise to the NN. So you get ... noise back. I do have cuDNN here, so I could try it in practice, but I won't come around to it until October. Rico |
|
|
|
Mit Windows kenne ich mich überhaupt nicht aus - ich weiß höchstens wie man ein Spiel startet. Zum Arbeiten benutze ich normalerweise richtige Betriebssysteme.
Nichtsdestotrotz gibt es nun Windows clients für 64 und 32bit Systeme ( http://lbc.cryptoguru.org:5000/download) Bei mir stürzen diese zwar nach einer Weile ab  bei den Betatestern jedoch nicht, also bitte: wer probieren mag, probiere. Einen kleinen Nachteil haben die Windows-Clients gegenüber den linux-Clients: sie benötigen mehr Speicher. Pro CPU Thread braucht die 64bit Windows Version ca. 3.5GB (Linux: 1.9GB). Sorry, geht momentan nicht besser. Das ist eben der Preis für den offline-Balancecheck (= Speed). Bei Problemen gibt es nun auch eine Diagnosefunktion (LBC --info), die Daten benötige ich, wenn ich auf Bugsuche gehen soll. Rico |
|
|
|
For 2017, i don't think it will be a year of bitcoin. Because there is no big news on 2017, but we don't know though.
So you already know the news for 2017? Care to share? Rico |
|
|
|
Hmm. Looks like you're right, though it does a batch conversion of point format. I should try to add that optimization to brainflayer. Doubling the key rather than incrementing it should still be faster, though.
Do you really think a shift vs. an increment is that much of a difference? I'd bet, that a more efficient SHA256 and/or RIPEMD160 implementation makes tons of CPU cycles difference and the shift/increment is negligible compared to that. Also, handling the big integer numbers (potentially up to 2 256) seems to take its toll. At least I observe a significant penalty for 32bit systems. Rico |
|
|
|
|
*feels like a noob, because he has to look up what HYIP is*
...
Aw shit. I looked it up. Lost 106 brain cells in the process.
Rico
|
|
|
|
ich verstehe mein handwerk, ich selbst bin grafik designer und seit mehreren jahren selbsständig in dem gebiet.
Und ich hätte bei dem Deutsch Angst bei/von Dir was machen zu lassen. Rico |
|
|
|
Wir Konzipieren, Designen, Hosten
...
Gerne auch erstellen wir auch
...
Wir konzipieren. Jeder Kunde wird Fachmännisch...
Wir designen. Insofern Sie die Previews für Gut beheißen befinden, so stellen wir das Layout für Sie fertig.
Wir Hosten. Bei uns sind Ihre Daten sicher gehostet hinter einer 1 TB DDOS Protection.
...
Wir beraten und Informieren
...
Alle layer...
Unser Custom Browsercheck
...
Wir akzeptieren ausschließlich Bitcoin und verlangen keine Persönlichen...
Wer macht denn die Rechtschreibprüfung bei euch? edit: Dann mache ich auch mal Farbe... Rico |
|
|
|
Your README makes no indication of source being available, and I didn't want to download the whole archive to look.
It seems either we are talking about different READMEs then, or we at least have different text understanding traits. Q: Is this software secure?
A: If you have a genuine version - yes. To make sure, never download
anything that claims to be LBC from any other source than
http://lbc.cryptoguru.org:5000/download
If you want to be extra-sure, check the md5sums at
http://lbc.cryptoguru.org:5000/downloads/LBC-client/md5sums
for the MD5 sums of all relevant files. On your command line,
verify the files by doing
> md5sum "filename"
Q: No, I mean can I trust *you*?
A: Send me 100BTC and I will send them back to you. After this, answer
the question for yourself. The LBC is compiled Perl source - it's
scattered, but ultimately you can look at it in the text
editor. The generate binary is a derivative of
https://github.com/saracen/bitcoin-all-key-generator
with just added command line parsing for block offsets.
Other than that, observe the LBC thread(s) on bitcointalk.org
for any complaints. If in doubt, don't use the software.
Ah brainflayer... I have played with it in the past and I will certainly look at the talk about sequential search. Right now it seems like a nice exercise in bloom filter application, but at the moment I'm unable to see it's use for any of my projects. I think I get around 550k/sec on my i7-2600 running on all cores. I always simply include all addresses seen on the blockchain regardless of whether they've got a balance.
Currently I get on 4 cores of my notebook 8M/min (~ 133k/sec) and checking only against addresses with funds, which is slower than your 550, although I wouldn't say a lot. However, I believe, a single modern CPU core should be capable of generating and testing around 500k/sec, so that is my goal. Not to speak of GPU... Unfortunately my C is rusty at best, assembler virtually nonexistant, so while I would like (and actually have) hack something togther in C, it was even slower than the Go implementation. I'd love to use the Intel SHA256 implementations ( http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/sha-256-implementations-paper.html), but right now I'm not up to it. Right now I'm busy providing clients for different OSes and architectures, which has the nice side effect that you will be able to plug in your own key generators. Vanitygen uses some techniques to generate addresses without computing individual private keys...
It actually does exactly what we do: It simply chooses a private key and then increments it. IIRC the docs vanitigen 1 million times, oclvanitygen 100 million times. ...though I think it would be a waste of energy to run that.
 We'll see. Rico |
|
|
|
FYI, someone already did a search of the first 2^50 addresses.
Do you have source code for your tool? Some people don't like running random binaries, and I've already released code that's a lot faster than the speeds you're reporting for doing sequential address searching.
- Link to previous search project?
- How about reading the README.txt?
- How about contributing your code (and to kill two birds with one stone? ... well 3 actually)
@Jude Austin: congrats. https://blockchain.info/address/1TinnSyfYkFG8KC3gZ72KpYxBXsxSadD8Another bounty will be planted. Rico |
|
|
|
Well, let us know when you find something worthy of general public's attention. Or, rather, let me be the first to know so that I could safely and timely get rid of my Bitcoin stash (however small it might be) before the markets implode on hearing the news
Given the amount of crap you have unloaded so far to the general public (nothing worthy of general public's attention), I think you'll hear it 1st in the news than from me. Rico |
|
|
|
Der Generator den ich jetzt habe ( http://lbc.cryptoguru.org:5000/downloads/LBC-client/generate), macht so ca. 2 mio Adressen in 1 Minute pro CPU. Zu lahm. oclvanitygen macht (und checkt) auf meinem Notebook schon so 15MKeys/Sekunde. Also wenn es einer hinbekäme, mir oclvanitygen so zurechtzubiegen, dass der output identisch zum derzeit verwendeten generator ist und da zumindest die 2 mio adressen pro Sekunde rausploppen... dafür wäre ich bereit BTCs auf den Tisch zu legen. Rico |
|
|
|
Der blockparser ist nicht von mir. Was er macht ist folgendes: Er geht die blockchain durch (man braucht diese also lokal) und gibt eine Liste der Adressen mit Funds aus. Die sieht dann ungefähr so aus: ---------------------------------------------------------------------------
State of the ledger at block 425733 (minted : Thu Aug 18 12:39:39 2016)
---------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Balance Hash160 Base58 nbIn lastTimeIn nbOut lastTimeOut
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
140955.81971855 e95dbb25283cc35d4a6aefa76c0382e63ce0fa36 3Nxwenay9Z8Lc9JBiywExpnEFiLp6Afp8v 67 Sat Aug 13 14:47:06 2016 15 Thu Aug 4 17:39:49 2016
83553.31541517 b3b9f5025c397c07e7e37db7e5c9259ac95cd344 3J5KeQSVBUEs3v2vEEkZDBtPLWqLTuZPuD 441 Fri Aug 12 02:23:15 2016 301 Thu Aug 11 03:26:25 2016
79957.11605233 a0b0d60e5991578ed37cbda2b17d8b2ce23ab295 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF 88 Fri Jul 29 02:50:12 2016 0 Thu Jan 1 00:00:00 1970
78172.33497629 c5464169a9aabad0e361ccf1d436d3e843708e7d 3Kg7Cmooris7cLErTsijq6qR1FH3cTiK2G 20889 Sun Jul 3 15:23:05 2016 4 Tue May 17 17:14:55 2016
69370.10526197 b3dd79fb3460c7b0d0bbb8d2ed93436b88b6d89c 1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx 66 Fri Aug 12 02:23:15 2016 1 Thu Apr 23 14:10:25 2015
66650.59620465 3d03002dbed5cb1dc10fc6bcb0886d2df32f2838 16ZbpCEyVVdqu8VycWR8thUL2Rd9JnjzHt 168 Fri Apr 29 10:29:14 2016 0 Thu Jan 1 00:00:00 1970
66583.22391617 cd4b7b8f9db1b0c709fd0c9f0534fca6a9f40495 1KiVwxEuGBYavyKrxkLncJt2pQ5YUUQX7f 120 Sat Feb 13 06:40:01 2016 0 Thu Jan 1 00:00:00 1970
66452.06624862 f9e6bbcdc83d8f351014e07495f386fe1067ec7b 1PnMfRF2enSZnR6JSexxBHuQnxG8Vo5FVK 114 Sat Feb 13 06:40:01 2016 0 Thu Jan 1 00:00:00 1970
66378.80961189 6a6015e3793207af6dff7c48ee9e193d73547cdc 1AhTjUMztCihiTyA4K6E3QEpobjWLwKhkR 181 Thu Feb 18 17:09:28 2016 0 Thu Jan 1 00:00:00 1970
66235.82427687 8b70193546504fa3623598722575f70b5b1c6455 1DiHDQMPFu4p84rkLn6Majj2LCZZZRQUaa 125 Sat Feb 13 06:40:01 2016 0 Thu Jan 1 00:00:00 1970
...
Der Aufruf (bei mir) ist ./parser allBalances -w 17000000 > allBalances2.txt
Der LBC client kann entweder diese Liste direkt parsen (langsam), oder aber er legt ein Storable (binary blob des Hashes) ab und benutzt das. Naja und einen Wert abfragen ob er in einem Hash (assoziatives Array) ist, ist in so ziemlich jeder Programmiersprache trivial. Wie gesagt, aktualisiere ich diese Daten von Zeit zu Zeit. Da das ca. 20GB Speicher braucht, mache ich das auf einem Server von mir und die Clients bekommen bereits das geparste aufbereitete Datenhäppchen. Mit Windows kenne ich mich überhaupt nicht aus - ich weiß höchstens wie man ein Spiel startet. Zum Arbeiten benutze ich normalerweise richtige Betriebssysteme. Rico |
|
|
|
Aber gegen welchen Server checkst du die Balance, also wo fragst du die BTC Adresse ab ob Coins drauf sind, das würde mich am allermeisten interessieren, da ich für jede Abfrage 0,6 Sekunden benötige...
Nochmal: Der check gegen die Balance erfolgt offline. Jeder client hat ein Hash von Adressen (derzeit ca. 9 10 mio) mit Funds drauf. Dieser Hash wird von Zeit zu Zeit aktualisiert. Diese Adressen bekommt man z.B. von https://github.com/znort987/blockparserUnd so benötigt der Client für einen Abgleich von ca. 2 mio generierten Adressen gegen alle Adressen mit Funds drauf... ca. 1 Sekunde Das Nadelöhr bei mir ist momentan das Generieren der Adressen ("der Müll" - s.o.). Das möchte ich beschleunigen. Rico |
|
|
|
If a collision is found the private key is sent from the miner to the server encrypted.
Then on the front page of the pool announce the finding,
So far so good. transfer the funds with a message to the owner.
Which owner? The original owner or the new owner? Transfer where? A new address is needed to transfer. If the owner signs a message with the address their funds are refunded, if not, distributed to the miners.
What period would you see as sufficient to wait? 1 year? More? Less? Rico PS: The LBC Pool found it's 1st bounty. |
|
|
|
Ich verstehe noch nicht wirklich was das für einen Zweck hat.
Dabei gibst Du mit Deinen Versuchen schon eine Teil-Antwort. Deine Versuche sind kläglich. Meine Versuche sind ca. 13800 mal besser (edit: oder doch 27600 mal?) , aber immer noch kläglich. Wenn ich nochmal um den Faktor 1000 besser werde ist's nicht mehr ganz so kläglich, aber immer noch ungefährlich für Bitcoin. Also Zweck: Mal schaun' was geht. Wenn Du Adressen erzeugst und deren Keys hast, hast Du im ersten Schritt ja einen mega Datenmüll und zwar sehr viel.
Naja ... der Müll ist nur von kurzer Lebensdauer, weil er von einem Programm zum anderen "gepiped" wird. Falls das Zielprogramm (check gegen Adressen mit einer Balance) nichts findet, verwirft es den Müll der da kommt. Zumindest in diesem Projekt. Ich habe noch ein anderes, da wird der Müll gespeichert. Wie willst Du dann prüfen ob auf einer der erzeugten Adressen eine Balance ist / BTC drauf sind?
Indem der Client ein Hash mit allen Adressen, die eine Balance drauf haben hat und "den Müll" der da vom Generator kommt, dagegen abgleicht. Bis jetzt noch keine Adresse gefunden wo was drauf ist --> ca. 10 Mio Adressen wurden geprüft
Der LBC Pool hat - außer Bounties - auch noch nichts gefunden und - Stand jetzt - knapp 138 Milliarden Adressen keys (276 Mrd. Adressen) geprüft. Update:16-08-28: ~350 Mrd. Adressen 16-08-30: ~420 Mrd. Adressen 16-09-01: ~490 Mrd. Adressen 16-09-03: ~545 Mrd. Adressen 16-09-05: ~600 Mrd. Adressen 16-09-10: ~780 Mrd. Adressen 16-09-13: ~930 Mrd. Adressen 16-09-14: ~1 Bio. Adressen Rico |
|
|
|
|
Show Posts
