2) Ich habe mir überlegt um die Geschichte spannender zu machen, also zumindest so spannend wie Angeln, dass ich selbst auf einige Adressen, die der Pool innerhalb der nächsten Tage finden sollte einen Betrag überweise. Die Beträge wären sowas wie 6660 oder 66600 Satoshi, also wüsste man, dass sie von mir sind und der Finder darf die auch behalten.
Und so sieht das dann in der Praxis aus: https://blockchain.info/address/1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq# LBC -c 10 -t 60
Reading balances... storable found - using that (faster)... done.
Fetching adequate work... got block interval [13715469-13715478]
...FOUND: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq 1CFmxJisuaGrPCTjeUPJeLAoQPUjTJH57w 1048471
(13715469) !!!
Visit directory.io page 112357122048 for privkey! Congrats.
.......
Fetching adequate work... got block interval [13715479-13715488]
....
Ich habe die Blockzahlen etwas verändert, da ich die Satoshis stehen lassen werde. Der Pool-Offset wird so gelegt, dass diese Funds von einem Betatester mit Sicherheit Anfang nächster Woche gefunden werden. @Betatester: Heute Abend werde ich einen neuen client und eine aktuelle balances.pst bereitstellen. Ohne die macht es keinen Sinn nach diesen Funds zu suchen, da in eurer balances.pst noch nicht drin. Für mich selbst ist das ein Novum, denn bislang hatte ich einen Match nur durch simulierte Daten getestet, nicht mit einer Adresse die tatsächlich "scharf mit Funds" in der Blockchain steht. Waidmannsheil! Rico |
|
|
|
Where am I? Where am I?? Oh such vanity - almost unbearable!  Rico |
|
|
|
|
Prinzipiell möchte ich irgendwann vanitygen und oclvanitygen dafür missbrauchen, aber die "millionen von adressen" die die erzeugen, müssen kontrolierbar sein, d.h. Nicht einfach per Zufall irgendwo was rauspicken, sondern man müsste z.B. oclvanitygen sagen:
oclvanitygen <start>
<start> wäre der numerische Wert einer privkey und dann würde der - sagen wir - die nächsten 2^24 Adressen (sowohl uncompressed wie compressed) auskotzen.
Das ist das Ziel. Soweit mir bekannt macht oclvanitygen fast sowas. Er pickt sich eine Adresse raus und inkrementiert dann einfach den privkey 100 mio mal. Dieses zufällige rauspicken müsste also durch eine Wahl auf der kommandozeile ersetzt werden und dann müsste er auch noch uncompressed Adressen rausgeben (denn die von Satoshi sind definitiv nicht compressed).
Denn das Einzige was der Pool macht - und was er versucht gut zu machen - ist eine ausgefeilte multi-interval arithmetik, die sicherstellt, dass bei N verteilten clients dennoch keine Arbeit doppelt gemacht wird.
Wenn wir da die vanitygens unkontrolliert loslassen würden, dann wäre das die berüchtigte horde Affen mit Schreibmaschinen, die nach x millionen Jahren durch Zufall ein Werk von Shakespeare ausspuckt.
Rico
edit:
Das "generate" binary (compiled Go source), was ja Bestandteil des clients ist macht ja genau das. Es generiert 2 Millionen adressen und diese werden dann gegen die 9.2 mio Adressen mit Funds abgeglichen. Wenn wir es schaffen das binary durch was schnelleres zu ersetzen (sagen wir ein modifiziertes oclvanitygen), dann erwarte ich einen erheblichen Speed-Up.
|
|
|
|
Eine erste funktionierende Pool Statistik läuft seit gestern. Wir haben bald glorreiche 37 Bits des 160 bit Suchraums abgearbeitet. (Also fast Nichts  ) Ich habe zwei Ideen wie man die Sache interessanter gestalten könnte: 1) @fronti: Sorry, dass ich die "vanitygen" Geschichte so schnell verworfen habe, denn theoretisch könnte man Vanity-Keys "en passant" - wie der Franzose sagt - also "im Vorbeigehen" generieren. Das wäre für die Poolteilnehmer ggf. ein möglicher Anreiz, denn entsprechende Keys wird der Pool natürlich früher finden als eine Kollision. Momentan will ich die Geschichte robuster hinbekommen - einige Betatester machen da wilde Dinge  - und dann kann ich mich dem Thema zuwenden. 2) Ich habe mir überlegt um die Geschichte spannender zu machen, also zumindest so spannend wie Angeln, dass ich selbst auf einige Adressen, die der Pool innerhalb der nächsten Tage finden sollte einen Betrag überweise. Die Beträge wären sowas wie 6660 oder 66600 Satoshi, also wüsste man, dass sie von mir sind und der Finder darf die auch behalten. So würde man zumindest die Funktionsfähigkeit des Pools demonstrieren und es wäre auch ein wenig Spaß und Anreiz dabei. Was meint ihr? Rico |
|
|
|
I got stats working.  Some 4 lonely clients are munging blocks, so let's see if we've tomorrow glorious 37bits of the search space done. Rico edit:Well - almost - some new clients claimed large chunks, so the stats went to 41.x bits of search space, but the server rejected these blocks later for missing POW, so we are at 36.93 bits. |
|
|
|
|
Our beloved big boy is very good and enthusiastic at announcements and start-ups, but his endurance has been below average.
The only long-term project he managed to sustain so far is his life.
Rico
|
|
|
|
Na ja, nicht böse sein, aber wer ein solches Projekt startet, will auch das machen was Du unter Punkt 2 ansprichst, möchte den sehen, der ein Wallet knackt mit 100BTC und dann nicht zulangt, sehr schwer vorstellbar...
Ja, mir ist auch schon aufgefallen, dass sich die "Bitcoin Community" - nicht nur hier auf Bitcointalk - gegenseitig für die miesesten Typen unter der Sonne hält. Macht natürlich etliche Sachen schwerer. Damals - ja damals(tm) war das mit der Linux Community doch deutlich anders, aber da ging es ja auch nicht um Geld. Würde mich aber nicht wundern, wenn das latente Misstrauen einer der Gründe wäre, warum sich Crypto nicht oder wenn dann nur wesentlich schwerer durchsetzt als z.B. Linux oder "das Internet". Oder es ist wirklich so, dass solche "die Du sehen möchtest" wirklich in der Minderheit sind. Es gibt schliesslich auch solche, die lassen 250 BTC stehen https://bitcointalk.org/index.php?topic=1147035.0Vielleicht hängt das ja auch damit zusammen, dass um den Bitcoin herum lauter arme Schlucker hängen, die irgendwie auf den großen Reichtum hoffen. Wenn für Dich 100 BTC in etwa 4 Monatsgehälter (netto) wären, würdest Du die Coins auch liegen lassen. Hoffe ich zumindest. Denn bei genauerer Betrachtung ist sogar der potentielle Verdienstausfall durch Knast ja ein Risiko was man nicht eingeht. Klar gibt es für jeden irgendwo eine Grenze. Ich bin mir auch nicht sicher, ob ich ne Wallet mit 50000 BTC stehen lassen würde, aber 100 BTC? Das sind ja gerade mal 2 Wochen Urlaub. ;-) Rico |
|
|
|
ich habe deinen Beitrag oben grade überflogen, und weiß nicht ob ich das richtig verstehe, aber im Prinzip wäre das doch ein Pool mit der Absicht Bitcoinadressen zu knacken?
Naja - "knacken" ist ein hartes Wort. Zum knacken brauchts zwei Dinge 1) den privaten Schlüssel 2) die Absicht das "Konto" auch leerzuräumen. Hier geht's um 1), in den FAQs schreibe ich auch recht deutlich, dass es je nach Jurisdiktion deutlich illegal sein kann 2) zu begehen und das man sich vermutlich mit einem legalen Finderlohn begnügen sollte. Darüber hinaus lasse ich diese Entscheidung schön feige in den Händen der Clients, deswegen checkt auch der Client die Adressen mit Bitcoins ab und nicht der Server. In dem Beispiel ist die Wahrscheinlichkeit quasi nicht vorhanden, aber wenn da genug Leute mit genug Rechenleistung mitmachen... kann das nicht gefährlich werden?!
Damit kommst Du ziemlich ohne Umschweife zur Kernfrage. Ich denke früher oder später wird es gefährlich werden und die Leute werden auf P2SH umschwenken, bzw. ihre Bitcoins mehr verteilen (keine hohen Beträge auf einer Adresse). Vielleicht werden sogar die Wallets eine Art auto-distribution unterstützen. Momentan ist das noch kein Thema, aber ich gebe zu bedenken was wir wohl 2009 von einem S9 mit 14TH/s gehalten hätten als eine CPU mit 8MH/s vor sich hingenudelt hat. Ich sehe es momentan ähnlich wie mit Solomining: Der nächste Block kann 11000 Jahre dauern oder auch morgen da sein. Rico |
|
|
|
Nutz doch die Rechenzeit (und Strom) die du in dem Pool zusammenziehst evtl für was geschickeres, z.b um Vanity Addressen im Auftrag zu berechnen.
Das Thema hier lautet nicht: "Bitte liebe Leute ich habe keine Ahnung was ich machen möchte - gebt mir Ratschläge von möglichst langweiligen Projekten, die es anderweitig bereits gibt."  Auch frage ich mich, wie du effektiv überprüfen willst, ob du mit einem PrivKey Erfolg hast.
Packst du die alle in eine Wallet.dat oder datenbankabfrage auf eine liste "der Key hat was drauf?"
...
Wie schnell ist hier deine Abfrage, wenn du schon mit sekunden hantierst?
Das überprüfe nicht ich, sondern der Client. Jeder Client hat ein Hash aller Bitcoin Adressen die was drauf haben. Das überprüfen ob eine generierte Adresse in diesem Hash ist, is O(1), also "sofort". Also ja, 300.000 Keys pro Sekunde gegen 9.2 mio Adressen gecheckt = 2760000000000 checks die Sekunde. Und das ist noch nicht besonders schnell, ich denke, da geht noch mehr. Das man viele Keys erzeugen kann (man kann ja einen ASIC (keine SHA2 ASICS) dafür bauen ist ja keine Frage.
Und das man da Forschen will, auch dem will ich nicht wiedersprechen, aber für ein Forschungsprojekt ist es noch etwas unklar was das Ziel ist.
Etwas machen, von dem Viele/Alle behaupten es sei unmöglich. Praktisch klarstellen, ob es tatsächlich unmöglich ist (das sollte dem Bitcoin einen fetten Vertrauensbonus geben) oder irgendwann durch eine Kollision beweisen, dass Praxis und Theorie auseinanderklaffen. In dem Fall würde ich auf ein "Upgrade des Bitcoin" hoffen. Ich gebe gleich zu Bedenken, dass ich mich hier auf eine Diskussion "Das ist unmöglich" nicht einlassen werde. Ich glaube, ich kenne mich mit Stochastik besser aus, als die Meisten hier. Zur Erinnerung: Das Thema ist "Suche Betatester". Rico |
|
|
|
Ok. Bei dem Projekt geht es im Grunde genommen darum private Keys zu finden zu Adressen auf denen Bitcoins liegen. Das hat zunächst einmal den Aufkleber "unmöglich" und ist für mich daher genau die richtige Herausforderung. http://directory.io/ kennst Du ja. Nun könnte man versuchen mit wget auf directory.io loszugehen, allerdings würde - selbst wenn man eine Seite pro Sekunde abarbeitet - unsere Sonne früher verlöschen, bevor man auch nur 10 -56% des Suchraumes abgegrast hätte. Unsere Sonne wird nämlich in ca. 157680000000000000 Sekunden kaputt sein und bei 115792089237316195423570985008687907853269984665640564039457584007913129639936 privaten Schlüsseln und 128 davon pro Seite, sinds halt 904625697166532776746648320380374280103671755200316906558262375061821325312 Seiten. Also muss man schneller sein. Das versucht dieses Projekt. Wie? 1) Es gibt die Möglichkeit die Keys offline zu generieren. Gegenwärtig schaffe ich mit einem (dickeren) Server 300.000 keys pro Sekunde, mithin das Äquivalent von 2343 Seiten auf directory.io pro Sekunde. (und schon hätte ich 10 -52% des Suchraumes abgegrast bevor unsere Sonne verlöscht) 2) Nun muss man aber wissen, dass der Suchraum gar nicht 256bit ist, sondern im Schnitt nur 160bit, denn es gibt zwar 2 256 private Schlüssel, aber diese werden auf 2 160 Adressen abgebildet. Daraus folgt übrigends, dass es im Schnitt pro Bitcoin Adresse 2 96 private Schlüssel gibt. 3) Dann ist es ja nicht so, dass man nach einer bestimmten Adresse sucht auf der Bitcoins liegen, sondern nach irgendeiner. Davon gibt es derzeit etwas über 9.2 Millionen. Wollen wir mal kurz nachrechnen: Suchraum 2 160 geteilt durch 9.2 * 10 6 bedeutet ich muss 158858873622924230239530960077856849962601 Adressen abnudeln bis ich mit 100% Wahrscheinlichkeit auf eine stoße, die Bitcoins gelagert hat. Mit meinen 300k pro Sekunde brauche ich nur noch 16791272791193580906427676314 Jahre. Das mag sich nach viel anhören, aber immerhin kann ich bereits 0.00000000000939059248% des Suchraumes abhandeln bevor unsere Sonne verlöscht. Das ist gegenüber den 10 -56% von oben doch schon ein Fortschritt. Das alles noch unter den Voraussetzungen, dass ich alleine suche und dass ich die Schlüsselgenerierung nicht beschleunigen kann. Ich möchte mit dem Collision Finders Pool eine Infrastruktur aufbauen, die diese Suche nach Kollisionen bestmöglich unterstützt. D.h. effiziente Verteilung der Suche auf möglichst viele Teilnehmer und Beschleunigung der Generierung von Adressen. Was also steht an? Der Pool funktioniert bereits und verteilt Suchblöcke an Clients von gegenwärtig 3 Betatestern. Die Clients nutzen momentan nur die CPU und vermutlich auch noch nicht besonders effektiv. Ich hoffe in den kommenden Tagen/Wochen - bessere CPU clients
- wesentliche bessere GPU clients
zu bekommen. Und es ist im Übrigen Waschweiber-Gewäsch man könne ASICs (ggf. die Miner) prinzipiell nicht für so eine Aufgabe herannehmen. Gegenwärtig sind 6 x SHA256 Berechnungen notwendig pro privaten Key (compressed/uncompressed address). Wenn ich mir die Beschleunigung beim Mining ansehe, wo heutige moderne Miner um einen Faktor 1.000.000 und mehr schneller sind als die CPUs mit denen Mining angefangen wurde... Es ist nicht abwegig, dass man 300GK/s (GigaKeys pro Sekunde) mit ASICs in einem "miner-ähnlichen Gerät" hinbekommen würde. Es können sich nun im Laufe der Zeit diverse Eigenheiten des RIPEMD160(SHA256(x)) Verfahrens zeigen, vielleicht Informationen die bestimmte Bereiche des Suchraumes lohnenswerter erscheinen lassen als da brute force uniform durchzumarschieren (im übrigen habe ich da bereits eine Vermutung, aber der Rand ist hier zu schmal um sie niederzuschreiben). Mit so einem operativen Pool steht man dann ja auch schnell Gewehr bei Fuß um solche Gebiete abzugrasen. Aber um es ganz klar zu sagen: Derzeit ist das Minen von X mit GPUs und ASICs wesentlich "lukrativer" als irgendeine Suche nach Kollisionen. Deswegen ist diese Suche hier eher was für ungenutzte CPU Kapazitäten. Ok - so in etwa. Ich hoffe, es wurde etwas klarer, worum es hier geht. Man könnte noch mehr schreiben (wie z.B. dass auch wenn der Pool nie etwas finden würde, dies auch Vorteile hat - nämlich für den Bitcoin als Ganzes, etc.) aber ich denke diese ersten paar Worte sollten reichen. Rico |
|
|
|
How can transparency lottery?
How is the operation?
Didn't you know Mr. Korkmaz? There is a Gödel Theorem that explains it all. Rico |
|
|
|
First successful 'auto' work distribution today! Started up two clients on two different machines, each of them asked the server for 10 minutes of work, depending on the overall speed of the client (number of CPUs * benchmarked block generation time). Which resulted in client1 geting 50 blocks for its 10 CPUs and client2 got 36 blocks for its 4 - evidently faster - CPUs. Each block is 2 20 compressed and 2 20 uncompressed addresses. Checking against all addresses (up to 1 Satoshi) with funds. client1 # LBC -p auto -c 10 -t 600
Fetching adequate work... got block interval [100123-100172]
Generating pages from 100123 to 100172 on 10 CPUs.
Reading balances... storable found - using that (faster)... done.
..............................
at the same time: client2 # LBC -p auto -c 4 -t 600
Fetching adequate work... got block interval [100173-100208]
Generating pages from 100173 to 100208 on 4 CPUs.
Reading balances... storable found - using that (faster)... done.
....................
So within 10 minutes, these two clients checked the equivalent of 704512 pages on directory.io (180355072 addresses so ~ 300k addresses per second). Rico |
|
|
|
Behold! My mighty solar power plant   Hardware: PV - 520Wp, 2.3KWh LiFePO4 storage, 230W Microinverter Victron Blue Solar MPPT/Charger Production around 4.6KWh/day about 230W for 20h daily. Provided there is enough sunshine.  In fact, I now HAVE TO run something else I would feed back power to the grid. Rico |
|
|
|
I'm using neither vanitygen nor oclvanitygen. Tried to get a grip on the code, but gave up for now. Instead I hacked a C-Implementation of some bitcoin library, but it's slower than https://github.com/saracen/bitcoin-all-key-generatorwhich I am using with slight modifications right now. I also started to hack a pooling server, so if someone with a 64bit Linux box is interested to try the beta (available - say - next week), drop me a PM with your HW specs. I think we'll try it with 10 beta testers in the 1st wave. Rico |
|
|
|
|
If this is meant like "give us your blog texts for free and placing them on our new blog may kickstart your writing career", then it's beyond pathetic.
I have another proposal for BITMAIN: Give me a couple of S9s for free and it may kickstart your reputation as miner manufacturer.
Rico
|
|
|
|
Let's say you incorporate in Panama or Gibraltar. How would you deal with the US trade policies? It does not matter where you incorporate if you accept people from the US you must follow their rules. Are you going to accept US clients?
Any thoughts on this?
Yes. I do not agree with the "Lex Americana" attitude. If the US government claims global jurisdiction, there's only the way to either not accept US customers or incorporating in a country that doesn't give a fuck about US claims (may bring other problems as these countries are themselves often not pro-crypto). I was slightly shocked that Bitfinex - run by a company registered on the British Virgin Islands - operating under Hong Kong Law actually gave a shit about the CFTC, which actually led to the mess we are facing now (because the CFTC effectively forbade Bitfinex to use cold wallets, see http://www.cftc.gov/idc/groups/public/@lrenforcementactions/documents/legalpleading/enfbfxnaorder060216.pdf). I would probably have sought for other solutions. Rico |
|
|
|
Thanks for the laugh. That's like driving a Ferrari to your next door neighbor's house. OVERKILL. You can run a bitcoin node on a Raspberry Pi. It doesn't need server-grade hardware.
I am not sure what's more sad. Someone not laughing because he doesn't get the joke or if someone laughing where there is no joke at all. I didn't say this hardware is used exclusively for a bitcoin node. Just a VM on it. Probably using 1/100th of the capacity of the hardware. Still - 1/100th means around 130 EUR if you consider the total purchase price. And if you consider the monthly cost, then that is 1.58 EUR for the Bitcoin node. What does your Raspi do when it has to bootstrap and index currently 93GB of blockchain? How much does a Raspi cost with a 256GB memory (provided you want to participate for longer than 6 months)? Ok - you will have no Gigabit Ethernet throughput no matter what you do, you will probably not get it run 24/7 at some ISP, but hey! We're the Bitcoin community - right? We are ok to be miserable running 3rd grade hardware in moms basement as long as we show it those darn evil banks! Rico |
|
|
|
|
Ideas are cheap - work is expensive.
Of course all those patent trolls nowadays seem to suggest otherwise, but I'm convinced that is only a temporary glitch in the Darwinian greater scheme of things.
"Genius is one percent inspiration, ninety nine percent perspiration." - Thomas Alva Edison
That prologue left aside, I have seen tons of "idea guys" who had nothing but the idea. So they had that 1%, but they thought and acted like they had the 99%. These projects are destined to fail. Now to use your own words:
I say the odds here are in favor of that, but there is that small chance...
So do you have only the idea, or do you have also the (at least initial) funds? Do you have any project management experience? How many years? Do you have any proven track of record of successful other projects that are up and running?
Rico
|
|
|
|
|
Show Posts
