Ein Brute-Force hilft da nicht besonders. Cryptoanalyse um den Suchraum deutlich zu reduzieren wäre weitaus wirksamer, benötigt aber entsprechendes Fachwissen.
Ein von 256bit auf 136.75bit reduzierter Suchraum zählt also nicht? Ich bin für das seit Projektbeginn erworbene Fachwissen sehr dankbar und sehe dem im Rahmen dieses Projekts künftig weiter aquiriertem Fachwissen mit Freude entgegen.  Fachfrage am Rande: Zählt z.B. eine Verdoppelung der Suchgeschwindigkeit als Reduzierung des Suchraums oder nicht? Rico |
|
|
|
Strike, TOP30 erreicht.  Das heißt wenn ich heute abend starte, benötige ich mindestens 18 Tage 24/7 um es in die Top 30 zu schaffen... Ich probiere nacher auch mal ein wenig  Gute Schätzung - willkommen im Club. Rico |
|
|
|
Ich seh das zwar auch so, crypto muss gut genug sein das es nicht möglich ist, kann man aber doch mit 202(a) argumentieren. Denn, der private Schlüssel für "meine" Bitcoin ist ja nicht für dich bestimmt. Ich denke es hängt also stark vom Richter ab wie sowas ausgehen würde.
Sagen wir von der langen Reihe aller Richter quer durch die Instanzen. In Deutschland. Das ist klar. Aber was 202(a) betrifft, finde ich einfach, es fehlt das Gespür für die Eigentumsfrage. Bereits Deine Formulierung der private Schlüssel für "meine" Bitcoin ist ja nicht für dich bestimmt suggeriert es gäbe da nur einen privaten Schlüssel, der obendrein noch Dein und nicht mein Eigentum ist. Das ist faktisch nicht zutreffend. Es gibt 2 96 private Schlüssel. Kein einziger davon Dein oder mein Eigentum. Aber angenommen Du kennst einen davon: Der LBC ist genau an den anderen 2 96 - 1 interessiert. Wie könntest Du diese auch für Dich a priori beanspruchen wenn Du sie noch nicht einmal selbst kennst? Geht doch jetzt auch schon, mit Multi-Sig, 2-2 entspricht dann 320-Bit, 3-3 480 bit, etc. Überhaupt checkt der LBC ja "nur" die Version 1 Skripte, keine kleine Untermenge aller möglicher Skripte. Für wenn das Projekt also ins Bedrohungsscenario gehört, der kann sich entsprechend absichern. Für die meisten wird das aber hypothetisch bleiben.
Die letzte Info die ich von Ryan zu P2SH habe, besagt, dass P2SH effektiv nur 80bit geschützt sind und das knacken eines Privkey perfekt per GPU parallelisierbar ist. https://bitcointalk.org/index.php?topic=1581701.msg16344155#msg16344155Rico |
|
|
|
More on the technical side, I managed to get the Bloom filter check done on GPU. Biggest problem was actually the printout in case of a hit. This raised the keyrate of my notebook from 7.3 Mkeys/s to 8.2 Mkeys/s, while the GPU is still at 34% usage with 4 CPU cores firing at it. Needless to say, it works perfectly on my system (24h burn-in with no problems), but raises a segmentation fault on AWS "hardware".  Meanwhile, in ECC land, a potential 2.x speedup is on the horizon, which would translate into a 16 - 24 Mkeys/s on my notebook with the GPU usage at around 70%. We'll see. Also, I'm falling behind in the top30 from #5 to #7, but I think it's a good thing. Rico |
|
|
|
Das ist ja gut und schön das euer Plan ist gefundenes BTC zurückzugeben (wenn sich denn alle dran halten).
Aber man muss ja auch erstmal merken des eine eigene Adresse leer geräumt ist. Wieviele Leute haben eine Coldwallet die nicht ständig beobachtet wird. Oder eine Paperwallet z.b. im Bankschliessfach oder unter'm Kopfkissen... gucken die alle regelmässig ob die BTC noch da sind?
Einmal alle 6 Monate sehen doch einige nach. Außerdem kann man ja eine Nachricht hinterlassen - siehe https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGgÜberdies würde ich empfehlen keine Vergleiche aus der physischen Welt heranzuziehen, weil man damit meist daneben liegt. Dann eben ein Beispiel aus der virtuellen Welt: Im Grunde ist das was ihr macht eine Brutforce-Attacke bei der nicht nur das Passwort durchprobiert wird sondern Accountname UND Passwort, also nicht ein bestimmter Account sondern irgendein Account gehackt wird. Wäre das legal..? (nebenbei: auch bei gehasht gespeicherten Passworten können ja Collisionen auftreten) Schon besser als die Fahrradschloss-Geschichte (bei der ja z.B. nicht einmal das Fahrradschloss dem Fahrrad-Besitzer gehört), aber immer noch nicht zutreffend. Dabei sind gerade im Deutschen alle Voraussetzungen gegeben um den Sachverhalt zu verstehen, da man schön zwischen Besitz und Eigentum unterscheiden kann - bietet nicht jede Sprache. Keiner von uns kann ein Eigentum an einem Privatschlüssel beanspruhen - schon gar nicht an allen zu einer Adresse gültigen Privatschlüsseln. Ein Privkey ist also eben nicht "das Passwort". Wenn überhaupt, ist ein Privkey ein Passwort von vielen möglichen. Der Privkey ermöglicht die Kontrolle (Signatur, Transaktion) einer zugehörigen Adresse. Weder der Privkey - schon gar nicht alle Privkeys - noch die Adresse sind jemandes Eigentum. Es werden auch keine Daten abgefangen. Die Blockchain ist ja öffentlich und unterliegt keiner Zugangssicherung. https://de.wikipedia.org/wiki/Vorbereiten_des_Aussp%C3%A4hens_und_Abfangens_von_DatenEs wird nicht in Computersysteme eingebrochen und wir scannen auch keine "elektromagnetische Abstrahlung einer Datenverarbeitungsanlage" Als Leute in Japan versucht haben an ihre MtGox Bitcoins zu kommen, haben die Gerichte dies abgelehnt mit der Begründung, dass Bitcoins niemandem gehören. Nun mag sich natürlich Hugo Egon in Deutschland denken "was geht mich Japan an", aber die tolle Blockchain hat nunmal die Eigenschaft überall auf der Welt zu sein. Davon schwärmen wir ja alle. Wenn ihr also Eure Bitcoins der Blockchain anvertraut mit dem Wissen, dass diese in alle Herren Länder verteilt wird, kann man schwerlich auf 202 pochen. Wenn jemand seinen Collider in Russland laufen lässt - viel Spaß vor einem deutschen Gericht. Ok - ich betreibe nun also so ein Projekt öffentlich, also muss ich mich auch solchen Themen stellen. Was ist mit den - ganz offensichtlich - existierenden ähnlichen nichtöffentlichen Projekten? "TooDumbForBitcoins" hat es im englischen Thread perfekt formuliert: https://bitcointalk.org/index.php?topic=1573035.msg17701080#msg17701080Eine Alternative Sichtweise wäre die folgende: Wir alle (mich eingeschlossen) haben Teile unseres Eigentums in eine Teilnahme an einem öffentlichen Spiel - "Bitcoin" genannt - konvertiert. Bei diesem Spiel werden Rechnungseinheiten hin- und hergeschoben und wir vertrauen darauf, dass die Mühe in 2^160 öffentlich einsehbare Schubladen so groß ist, dass dies niemand tut. Wenn doch, haben wir u.U. Pech gehabt. Im übrigen finde ich dieses Projekt aber ziemlich interessant. Am Ende wird man vielleicht sehen welche Gefahr Collisionen für BTC-Besitzer wirklich darstellen. Könnte sich ja auch in einer Änderung/Verbesserung beim Bitcoin-Protokoll niederschlagen. (also falls es dann nicht wieder eine "Core-Lösung" und eine "Miner-Lösung" gibt und jede Seite die andere jahrelang ablehnt ) Ich hoffe, wir haben irgendwann echte 256bit Adressen oder sogar echte 512bit Adressen. Funds auf diese zu schieben wäre vielleicht etwas teurer (Transaktionsgröße), aber das wären dann eben "Tresoradressen". Bei einem globalen Gut wie der Blockchain sollte man sich tatsächlich mehr auf technische denn auf juristische Lösungen verlassen. Das werden Juristen sicher ungern hören und sicher auch eine eigene/andere Meinung dazu haben, aber das ist ja deren gutes Recht. Rico |
|
|
|
Das sehe ich genau so. Wenn ich zufällig die Kombination des Zahlenschlosses deines Fahrrads errate und es mitnehme, bekomme ich dann Finderlohn? Wohl kaum, eher wohl eine Anzeige wegen Diebstahls.
Dann hast auch Du nicht verstanden was eine Kollision ist. Überdies würde ich empfehlen keine Vergleiche aus der physischen Welt heranzuziehen, weil man damit meist daneben liegt. Rico |
|
|
|
Wie hoch ist denn schätzungsweise der Prozentsatz der netten Teilnehmer? Und ist ein Finderlohn nicht eigentlich bei Dingen üblich, die vorher jemand verloren hat? Bei ner verlorenen Wallet könnte ich das ja noch nachvollziehen, aber wenn ich meinen Key nich verloren habe (und nur dann kann ich ihn vorweisen), würd ich das doch eher als Erpressung bezeichnen. Wikipedia sagt was von 5-10%, je nachdem ob man sich in D/A/CH befindet. Sowas in der Art. Und wenn Du eines Morgens nachsiehst und Deine Funds sind auf einer Custodial Address dann hast Du die doch verloren - oder nicht? Natürlich kannst Du das bezeichnen als was immer Du möchtest. Aber wenn die Finderlohn-Geschichte in gegenseitigem Einverständnis keine Schule macht, dann kann ich sehr gut prognostizieren wie die Sache eher ablaufen wird: Wo ist dein Key, du hast ihn verloren,
Als ich dir den Weg zeigen mußte
Wer hat verloren? Du dich?
Ich mich? Oder, oder wir uns? FalcRico |
|
|
|
Dazu muss man wissen, dass dieser "Schatz" in 50 BTC Häppchen auf unterschiedlliche Adressen aufgeteilt ist. Man kann also mit dem Brute-Force Ansatz bei einem Treffer immer nur maximal 50 BTC (manchmal vielleicht noch etwas Dust Spam dazu) finden.
Stimmt schon. Es gibt aber ja noch andere. Knapp 157 M$ für die richtige Sequenz von 32 Byte. Verrückte Welt.  Und wenn ich's genau nehme, sollte eine richtige Sequenz von 20 Byte auch genügen. Rico |
|
|
|
Imposante Zahlen.
Nehmen wir an, ihr findet etwas.
Beispielsweise eine meiner Adressen und räumt diese leer.
Ist das nicht defacto Diebstahl?
"Deine" Adressen? So richtig mit Grundbucheintrag beim Notar? https://www.cryptocoinsnews.com/japanese-court-bitcoins-not-tangible-property/Es wäre kein Diebstahl, aber wenn Du einen (Deinen) Privkey vorweisen würdest, und der sich von dem gefundenen unterscheiden würde (= Kollision) dann ist der Plan aller netten LBC Teilnehmer Dir die gefundenen BTC abzgl. des üblichen Finderlohns wieder zukommen zu lassen, Edit:
Waren unter den 500 Billionen Keys Treffer?
Sieh' doch selbst nach: https://lbc.cryptoguru.org/trophiesRico |
|
|
|
Also nur im das mal in Relation zu stellen:
Die Wahrscheinlichkeit so eine Nadel im Heuhaufen zu finden ist geringer, als mit einem C64 zu minen und zwei Blöcke in Folge zu finden.
(citation needed) Die Rechnung würde ich gerne sehen. Wenn ich mir irgendeine chart seite ansehe, dann steht da momentan "Difficulty 440,779,902,287" - plusminus. Also knapp 441 Milliarden mal schwerer als 2009. Das würde bedeuten, mit einem 2009er PC würde ich 441 mrd. * 10 minuten brauchen - oder? Da komme ich auf 8390410 Jahre. Zwei mal hintereinander schaffe ich - bei gleichbleibender Difficulty - in 8390410² Jahren. Sind ja stochastisch unabhängig die Ereignisse, 70398979968100 Jahre. mit einem 2009er PC. Bei einem 64er müsste man den Geschwindigkeitsunterschied zum 2009er PC nehmen, quadrieren und auf o.g. Endergebnis aufmultiplizieren. Ich möchte nur anmerken, dass der Pool irgendwann August 2016 in Betrieb gegangen ist - mit ca. 300 Kkeys/s, Am 17.1.2017 hatte er 250 Billionen Schlüssel durch. Am 25.2.2017 hatte er 500 Billionen Schlüssel durch. Ich hatte im August 2016 das gleiche Notebook das ich jetzt auch habe. Heute schafft mein Notebook 7.5 Mkeys/s - also 25mal mehr als der ganze Pool zu Beginn. Ich weiß noch, wie ich mir gewünscht habe, dass der Pool mal 25-27 Mkeys/s schafft, weil das laut Ryan Castelluccis Hochrechnung die Speed gewesen sein soll, mit der die 1-50 puzzle transactions leergeräumt wurden. Heute wären 25 Mkeys/s lahm.
Ich bin gerade dabei die libsecp256k1 zu kippen und einen ganz neuen ECC Code einzubauen Mein Notebook sollte dann irgendwas zwischen 15 und 24 Mkeys/s haben. Rico |
|
|
|
Auf der Stat-Seite steht, das #51 in x bis y Tagen gefunden werden wird.
Wie kommst du da drauf? Kannst du bestimmen, in welchem Bereich der Key ist?
Also quasi "Seite 1 Mio bis 2 Mio, irgendwo da drin isser"?
Kann man einen Teil der Bits der Seite zurückberechnen?
#51 ist zwischen 2^50 und 2^51 Wir sind derzeit bei 2^48.92 und Y keys/s schnell. Ein Tag hat 86400 Sekunden, Ab da ist's 5. Klasse. Rico |
|
|
|
4. Du hast es bis heute noch nicht geschafft deine eigenen Miner so zu Installieren damit du Sie das ganze Jahr über laufen lassen kannst und unterstellst allen anderen die gleiche Inkompetenz. Doch, habe ich. Meine Bitcoin Miner minen das ganze Jahr über. Zum Nulltarif. Nur meinen LTC Cluster habe ich mal eben über den Winter 2013/2014 betrieben. Das war aber auch von Anfang an so geplant. Ich meine 30 Stück 7990 ... das zieht schon rein... Das ist ganz typisches deutsches pessimistisches klugscheisserverhalten, deswegen ist die Gründerszene in Deutschland auch so schlecht. Ich wollte es Deinem Selbstbewusstsein nicht antun, aber ich bin kein Deutscher. Du wurdest hinsichtlich Sprachkompetenz in - vermute ich - Deiner Muttersprache von einem Ausländer zurechtgewiesen. Also wenn mir das passieren würde - ich würde vermutlich ein Jahr lang das Tageslicht scheuen und nur noch die städtische Kanalisation benutzen um von Punkt A nach B zu kommen. Schamgefühl wissensschon. Ps: man kann eine geschriebene sprache auch ohne groß/kleinschreibung gut verstehen, die ganze welt macht das so.
Das ja, wenn allerdings nicht nur die Groß-/Kleinschreibung fehlt, sondern auch noch die Kommata falsch gesetzt sind oder ganz fehlen, Tippfehler vorhanden sind (wenn man benevolent von Tippfehlern ausgeht), dann wird der Text wirklich unleserlich und nervend (hat nichts mit den Nerf-Pistolen zu tun). Man könnte Deine Ausdrucksweise noch malevolenter interpretieren, nämlich, dass Du Dich einen Dreck um Deine Leserschaft scherst. Glaubst Du, Du würdest mit einem Business-Plan in der Art wie Du hier kommunizierst irgendwo auf einen grünen Zweig kommen? (rhetorische Frage) Ok, Du hast eine Aversion gegen Island. Und Banker. Und Genesis. Kann ich nichts dafür. 7 Grad Temperaturunterschied im Schnitt ist schon eine Menge Holz. Sag mal den Klimaforschern 7 Grad sei nicht viel. Die kippen doch aus ihren Latschen. Und ja, ich respektiere, wenn Du eine eigene Art drauf hast und entsprechend auch nur mit bestimmten Leuten Geschäfte machen könntest/würdest/möchtest. Ich wünsche Dir viel Erfolg (ehrlich), aber ich glaube nicht daran (auch ehrlich). Rico |
|
|
|
Der LBC scannt aus Vereinfachung nur 2^160 Keys, und wenn man davon ausgeht, das es ja 2^256 Adressen gibt und die Schlüssel statistisch schön verteilt sind, so ist zu jeder der 2^256 Adressen/PubKeys ein PrivKey in dem 2^160er Suchraum, die anderen 2^96-1 Privkeys sind in den anderen Suchräumen, die der LBC nicht macht.
Soweit noch ok?
100% Dann kommt mein Problem: Der LBC generiert Schlüssel nach dem gleichen Prinzip, und aktuell ist er auf Seite 4065 Billionen und irgendwas. Ich nehme nun einen bereits gelisteten Schlüsselsatz von Seite 1 und kann da BTC bunkern, die der LBC nicht sieht, selbst wenn die BLF meinen Kontostand enthalten würde. (Jaja, Seite 1 . Seite 471108152017, der dritte von unten.) Theoretisch. Nämlich dann, wenn alle Clients im Auto-mode fahren würden (sprich den Suchraum vom Server zugeteilt bekommen - das läuft effektiv auf eine inkrementelle Suche hinaus). Praktisch jedoch, gibt es noch den "-p" Parameter, wo Leute/Clients selbst bestimmen können welchen Suchraum sie abgrasen möchten. Und das machen die auch, wenn sie z.B. die Puzzle-Transactions selbst finden wollen (einfach mal sehen wie das aussieht bei einem hit). Da wo der LBC schon war - das ist noch ein winziger Suchraum. Ich gehe davon aus, dass wir noch viel schneller werden und dann sind 2^49 Schlüssel "nix". Wenn ich meinen Key vor dem LBC verstecken müsste, dann würde ich mir tatsächlich einen Key bei 2^159 + n aussuchen, sprich in einem Band nach 50% unseres Suchraums. Denn: - bis der LBC da ist, dauerts noch
- der Key ist im 2^160 Wertebereich, also ist die Wahrscheinlichkeit für einen Kollisionszwilling in diesem Bereich geringer.
Also fiele die Wahl auf Seite (2^159 + rand(2^158)) / 128 (auf directory.io) Und ich würde wohl eine Uncompressed Adresse nehmen, weil die sieht der LBC zwar auch, aber die ganzen anderen Tools wie oclvanitygen nicht. Rico |
|
|
|
ich biete eine gute einrichtung wo anlagen installiert werden können. Kryptologen um jemanden zu haben der sich mit den einzelnen Währungen auskennt und die technik dahinter.
wie gesagt bin offen aber ich will jemand der qualifiziert ist, rechtschreibung ist mir nicht so wichtig, alles andere muss aber gut sein. die deutsche rechtschreibung ist sowiso der inbegriff des klugscheisens
Das Problem ist, dass Du ja nicht nur die Rechtschreibung nicht beherrschst, sondern - vereinfacht ausgedrückt - kein Deutsch kannst. Wie gesagt, wenn Du Ausländer sein solltest, an Legasthenie leidest etc. kann man da ja auch keinen Vorwurf machen. Dann empfehle ich aber "Förster" und lass große profffesssionellle Mining-Anlagen links liegen. Ich würde aber mit jemandem, der solche Grundzüge nicht beherrscht, keine Geschäftsbeziehung eingehen wollen und das hat ganz pragmatische Gründe: - Ich hätte Sorge, dass derjenige bei Firmenkorrespondenz auf Kunden-Geschäftspartner einen schlechten Eindruck macht und generell allen Geschäftspartnern signalisiert: "Hier Prolet - zockt mich ab!" (Was natürlich bei mangelndem Sprachverständnis über Verträge sehr einfach möglich ist)
- Die Umgangsformen lassen auf ein potentiell eher schlechtes Betriebsklima schliessen. "Ey Altah was laberst fürn Scheiß, Isch masch Disch Messah bis Du Krankenhaus..." (Rechtschreibung korrigiert, Semantik angepasst)
Generell lässt Deine Herangehensweise zur Kommunikation einen niedrigen Bildungsstand durchblicken. Ich persönlich habe mit sowas ein Problem, denn ich sehe nicht, welchen Mehrwert solche Leute einem "außerordentlichen Business" bringen. Ok, wenn Du körperlich fit wärst, als Türsteher in einem Bordell oder in einer Disco - dann aber um Himmels Willen die Fresse halten und die Leute nicht von der Seite anquatschen - das könnte ich mir noch vorstellen. Ab und zu klingt in Diskussionsforen der Dunning-Kruger an. Ich bin jetzt nicht so der Fan diesen Begriff inflationär zu verwenden, aber es scheint zu sitzen. K.A. welche Ausbildung Du tatsächlich genossen hast, ob nun "Gebäude-Fachwirt" o.ä. Ich bin Informatiker, aber den Kenntnisstand aus dem Bereich Gebäudebau, Kühlung etc. den Du bislang präsentiert hast, habe ich im kleinen Finger - aber auch nur wegen meinem Häuschen. Dennoch musste ich mir - in schlechtem Deutsch - anhören, ich hätte keine Ahnung. Du Null Ahnung von Gebäuden
sag mal was laberst du für nen scheiss? willst du mir erklären wie man ein gebäude kühl hält?
schon mal was von konvektion, installationsdichte, passivekühlung, fernwärmeeinspeisung und KWK gehört?
Laber keinen Scheiss in meinem thread erst recht nicht wenn du kein plan vom Bauen und Stadtwirtschaft hast. Konvektion kenne ich. Konduktion auch, sogar die Wärmestrahlung ist mir ein Begriff. Installationsdichte kenne ich auch, aber auch die spezifische Wärmekapazität von Luft. Passivkühlung - wie es richtig geschrieben wird - natürlich auch. Siehe Konduktion, Konvektion und Wärmestrahlung Fernwärmeeinspeisung. Na klar, aber da muss irgendwo auch eine entsprechende Wärmedichte vorhanden sein. KWK, oder Co-Generation, das sagt mir was. Schliesslich werkelt in meiner Haustechnik ein Brötje Ecogen WGS 20.1 Aber mit Kühlung hat das nix zu tun. Darüber hinaus kenne ich noch ungefähr 10000 weitere Begriffe aus dem Bereich. Stell' Dir vor. Teilweise habe ich das auch der guten alten Schulphysik zu verdanken. Ich will Dir auch nicht unterstellen, dass Du nicht lernfähig wärst. Offensichtlich greifst Du einige Infos, die Du hier erfährst, auf und bildest Dich ein wenig weiter - und das ist gut so! Rico |
|
|
|
Ich bin sicher, das ich da ganz falsch bin, aber wenn du es nicht weißt, weiß es keiner. Wenn ich recht hätte, würde das ja bedeuten, das der LBC nur Adressen mit Guthaben finden kann, die effektiv während der gesamten Laufzeit des LBC unberührt waren (bzw. zufällig gerade passend in den zu durchsuchenden Bereich fallen), und das wäre ja schade. Es kann Adressen geben, die dem LBC "vielleicht entkommen", weil die BLF nicht aktuell genug ist. Das hängt aber von der Updatefrequenz der BLFs ab und nicht von der gesamten Laufzeit des LBC. Was ich versucht habe klarzumachen (und nicht sicher bin ob mir das gelungen ist), dass es hier kein "davor" oder "dahinter" gibt wenn man sich den Suchraum anschaut. Man kann den Privkey inkrementieren, aber das hat mit dem numerischen Wert des hash160 herzlich wenig zu tun, der springt scheinbar chaotisch hin und her. Du bist zu sehr in dem Gedanken verfangen es gäbe nur einen privkey zu einer Adresse. Wirklich. Dem LBC ist es ja egal welchen der 2^96 privkeys er findet. Und da diese prinzipiell gleichmäßig über den gesamten Suchraum (2^256) verteilt sind, wird sich im Schnitt auch einer davon in den ersten 2^160 bits befinden. Einer davon. Der muss numerisch mit dem "originalen privkey" überhaupt nichts zu tun haben. Aber ja: Wenn die BLF 2 Wochen nicht aktualisiert wurde, dann sind alle Adressen, die vor 2 Wochen noch leer waren für den LBC immer noch leer. Und alle Adressen, die in den 2 Wochen geleert wurden, könnten einen hit provozieren, beim Nachsehen aber bereits leer sein. Rico |
|
|
|
Der LBC sucht ja alle Adressen mit Guthaben ab.
Die stehen in einer Datei, extrahiert aus der Blockchain, nehme ich an.
Da sich die Adressen ständig ändern und erweitern, muss auch diese Datei erweitert werden, oder?
Ja, das passiert ja auch: ftp://ftp.cryptoguru.org/LBC/blf/Wenn ich jetzt Angst hätte, das meine BTC in Gefahr sind, weil "meine Adresse" demnächste gescannt wird: könnte ich das Guthaben transferieren, auf eine Adresse im bereits durchsuchten Bereich, weil da nicht mehr gesucht wird? (Zumindest bis zum nächsten Update der "Schlüsseldatei"...)
Oder sogar erst mit einem kompletten Neustart des LBC-Systems, also ab "Bit 0"?
Ich sage es ungern, aber es sollte keine "Angst weil meine Adresse demnächst gescannt wird" geben. Weil nämlich das Gegenteil - die "Zuversicht , dass meine Adresse weit weg ist" auch nicht existieren sollte. Bzw. so eine Zuversicht ein Trugschluss ist. Stell' Dir vor, Dein Privatkey ist irgendeine große Zahl 2^240 irgendwas. Der LBC knödelt momentan bei 2^49 rum. Ist doch hübsch weit weg - oder? Falsch!Eine Kollision ist ja genau der Vorgang, dass ein Schlüssel - und der kann durchaus nur im 2^49 Wertebereich sein - in die gleiche Adresse aufgelöst wird, wie eben ein Schlüssel aus dem 2^240 Wertebereich. Die Wahrscheinlichkeit ist klein, aber nicht 0. Die Stats-Seite zeigt ja diese Wahrscheinlichkeit für die nächsten 24 Stunden an. Wenn Du Angst haben solltest, dass der LBC Deinen Schlüssel findet, dann kann ich vorerst nur empfehlen auf eine P2SH Adrese zu transferieren, weil wir da (noch) nicht suchen. Rico |
|
|
|
Jetzt bitte nicht lachen, aber ich habe wirklich keine Ahnung von Linux:
Gehe ich recht in der Annahme, daß ich die Komandozeile von oben jetzt in eine Datei kopieren muß und diese im Verzeichnis /collider liegen muss und "hook-find" heißen soll?
Wenn ja, was hat es mit dem "#!/bin/bash" aus Deinem Beispiel auf sich & muß ich die Datei noch irgendwie ausführbar machen?
Ja, die Datei sollte ausführbar sein, hook-find heißen, dein Kommando in Zeile 2 oder 3 stehen haben und in Zeile 1 sollte eben jenes #!/bin/bash stehen, welches besagt "Dies ist ein Shellskript, also bitte als solches ausführen". Rico |
|
|
|
You might have misinterpreted what I said, the phrase "attack" was in no way supposed to be an attack on your project, I actually think a successful attack on Bitcoin/SHA256 would be very important and noble of the person showing it in proving that the protocol is no longer effective.
We're trying to show a private key collision. Actually SHA256 plays the least part in this. We know because of the 256->160 bit reduction of RIPEMD160, that there are - on average - 2 96 private keys per address (if you look at both compressed and uncompressed addresses, there actually are 2 97, but that's just a fun fact) However the project is literally an attempt to find collisions, no? Does it prove a point, and if it does, is it any different to, say, finding a collision in SHA256 using a birthday attack?
I don't know if it does prove a point. I don't think so. When I started it, I thought it would be very interesting to actually see a live collision. Like we all know there must be many (2 97 is a quite big number) private keys for any address out there. If anything, my point is, that the private key to your bitcoin address does not provide true 256bit security, but thanks to RIPEMD160 only 160bit security - at best. Evidently, when the public key is known, the security of your private key drops to 128bit - at best. So when you have a bitcoin address with funds on it, and even if you know it has some private key in the - say - 2 240 numeric range, the LBC could basically hit an alternate key to it tomorrow - in the 2 49 numeric range. Probability is low, but not 0. Also, there is no safe distance. more here: https://lbc.cryptoguru.org/man/theoryAnother fun fact is that contrary to BTC mining, we started out with max difficulty and the difficulty is getting lower and lower (thus the probability higher and higher) every day. That's exceptional fun - isn't it? Rico |
|
|
|
Hallo zusammen, ich habe mal noch 2 Fragen bzw. bräuchte, als Windoff-User, mal Hilfe. Als erstes würde ich gerne eine E-Mail versenden wenn etwas gefunden wird. - Dies soll ja mit " hook-find" gehen. - Leider habe ich Null Plan wie ich das Hook-Komando nutze bzw. einbinde und ob ich auf den Servern vorgängig noch irgendwas einrichten muss. Für eine Noob-Anleitung wäre ich dankbar. Hm. Schwierig. Hängt nämlich davon ab ob/wo/wie der Mailversand konfiguriert ist. Beispiel wie ich das bei mir habe: mutt -s 'LBC - FOUND!!!' -- "bots\@cryptoguru.org" < FOUND.txt ist ein mailclient, der es auch ermöglicht über Kommandozeile gesteuert zu werden. (Ich denke obiger Befehl ist selbsterklärend, ggf. Help aufrufen. In diesem fall würde bei Dir bspw. hook-find in etwa so aussehen: #!/bin/bash
mutt -s 'LBC - FOUND!!!' -- "carsten\@domain.tld" < FOUND.txt
Das größere Problem ist den MTA zu konfigurieren und da gibt es keine Einheitslösung. Exim, postfix, sendmail (Gott bewahre), oder an ein Relay senden... Da müsste man konkret wissen was für eine Mail-Infrastruktur vorhanden ist. Wenn Du bereits einen Mailserver hast, der auf Port 25 z.B. aus dem internen Netz connections akzeptiert, kannst Du das ja direkt an den schieben. Ich verwende manchmal exim, manchmal postfix. Zu der privkey Sache. Du hast es ja schon herausgefunden, der folgende link http://directory.io/3196241445567#5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEXxDuJBiUbiVA9ehilft noch besser/visuell die Zusammenhänge zu sehen. (uncompressed <-> compressed) Jo. Rico |
|
|
|
Can we use Golem super computer to find a collision?
I had to look that up. Yes, at least certain nodes in that network would be suitable. Actually LBC would be a perfect application, because it is parallelizable so well. (Golem has high interconnectivity latencies, making it appear somewhat like the early Beowulf clusters). or design ASIC for doing it?
One step after another. :-) In fact, LBC clients will probably undergo a similar evolution like BTC miners did: CPU -> GPU -> FPGA -> ASIC. We're at the transition phase between CPU and GPU. But there are already things like "OpenCL for FPGAs" I am aware of. and should we bring the LBC client to a FPGA, I believe for a specialised company it should be technically no big deal to make an ASIC. Still I am not sure anyone would fork out like 3-4 M$ for such a development. A bit off topic but since you seem like to know things about bitcoin, is it possible to have negative blocks in blockchain? like block 0,1,2 and -0,-1,-2.
Sort of. Except 0 and -0 :-) you could define -1 as being 110427941548649020598956093796432407238805355338168053038220561162489092 -2 being 110427941548649020598956093796432407238805355338168053038220561162489093 etc. Why is this 964MB to download?
That's only the LBC appliance for windows users. These days you want to have a linux machine with some Nvidia or AMD GPU installed and then the download is somewhat around 205 MB. And the resulting client is faster. Rico |
|
|
|
|
Show Posts
