Ich bezweifle mal, das das ein Base64-kodierter Key ist, aber anyways: Zeigst du mir auch ein Foto deiner Kreditkarte? Vorn und hinten bitte, ich will nämlich auch eine, und ich weiß noch nicht ob mir das Design gefällt.
|
|
|
Leider hat er recht. Die wer weiß wievielen Gigawatt an Strom, die in China in der Pampa und in Island für nix verblasen werden, das ist schon beeindruckend. Sinnlos, aber beeindruckend. Alles nur, weil man ekelhafte Mengen an Dollars generieren kann, wenn man den Leuten laute Heizkisten verkauft, die echt Probleme haben ihre Kosten wieder einzuspielen, Kursgewinne mit eingerechnet. Wenn dem nicht so wäre würden die ja nicht verkaufen, oder?
|
|
|
Ach, "Sicherheit" heißt also "Unmöglichkeit des Auskaufens durch Fiat"? Ja, dann hast du recht. Dann hoffe ich mal, das der Euro/BTC-Kurs bald stabil 5-stellig wird und nächsten Sommer die 6. Stelle erreicht, und das wir dann bei min. 100x so viel Hashleistung sind wie jetzt. Irgendeiner muss den "zwei" sich aktuell um die gesamte Hashleistung kloppenden Chinesen (?) ja mal Einhalt gebieten. Und wenn es der schnöde Mammon ist. Nicht die Anzahl der Miner (nicht Geräte, Nodes), nein, einfach die Unmöglichkeit, genug Dollars zusammenzufegen ist was das System sicher macht. Was Herr Nakamoto da wohl zu sagt... Ist halt die Frage, wie man "sicher" definiert. Mir wär es lieber, wenn jeder einen Miner zuhause hätte, klein leise und sparsam, dafür käme dann so ein Forkmist nicht auf.
|
|
|
Dann mal eine andere Meinung: 1. Der Energieverbrauch eines PoW-Coins ist abhängig von der Minerleistung. Die Minerleistung ist unabhängig von der Sicherheit des Systems. BTC z.B. ließe sich auch mit 100GH Gesamtleistung betreiben und wäre nicht unsicherer als jetzt. Du machst es wie die Spekulanten und rechnest die Minerleistungsinflation in die Sicherheit um. Natürlich kann ein 1TH-Miner ein 100GH-System umkrempeln, aber die Sicherheit des Systems an sich hängt nicht an der Gesamtleistung: Würde man Miner via Zertifikat im Netz authorisieren, so könnte ein RasPI das ganze Netz abdecken, ohne auch nur ein einziges Bit mehr Unsicherheit. Jaja, Monopol und so. Ist ein Beispiel. Das was du "Sicherheit" nennst, ist die Angst vor der Gier der Miner, die (um ihren Anteil an der Torte wieder "anzupassen") massiv Dollars in die Flossen anderer Leute halten, um Rechenleistung zu kaufen. Genau um das Problem zu umgehen gibt es PoS-Coins: Die sinnlose Inflation der Miningleistung fällt weg.
2. Der Energieverbrauch und der Wert sind in keinem Zusammenhang. Der Wert berechnet sich nicht in den geflossenen Wattstunden, sondern alleine dadurch was "das Volk" davon hält. (Oder gibt es ein "Wattcoin"? Es gibt ja auch "Gigabytecoins"...) In der realen Welt sind viele seltene Dinge teurer als Massenverfügbare Dinge, ja. Aber eben nicht alle. Cryptocoins sind da ähnlich, sonst wären die Wert-Unterschiede der verschiedenen Coins nicht so groß, und vor allem nicht anders groß als die Miningleistung. Das du als Individuum einem Coin mehr Wert zusprichst als einem anderen, hat rein psychologische Gründe. Iphones, Gold oder Diamanten z.B. sind alleine deswegen so teuer, weil Tussis auf Glitzerkram stehen. Einen Sinn dahinter gibt es nicht, sonst würde vergoldetes Material oder Swarovski-Perlen einen ähnlichen Wert haben. Technisch ist es jedenfalls egal, ob eine Kette Gold, Vergoldet oder Gold-lackiert ist. Gleiches gilt für x-Coins. Wenn du eine Pizza für 10000 x-Coins bekommen kannst, du sie über hast, der Verkäufer sie haben will, dann werdet ihr euch einig. An einer Börse werden x-Coins mit 1€ct/1000 gehandelt. Nanu? Du rechnest intern mit "Geile, ne Pizza für 10 cent", der VK rechnet intern mit "Geil, 10000 x-Coins für 10 cent, in nem halben Jahr bin ich Millionär". Beide rechnen in Fiat. Möööp.
|
|
|
Mir ist mein geprunter Zweitcomputer mal auf die Art abgeschmiert, war 3 Monate off und hat dann gemeckert das die Datenbank zu alt sei und er neu herunterladen müsste. Keine Ahnung ob das jetzt noch so ist, das war V12 oder so.
|
|
|
Schlüssel importieren geht nicht, und zu lange auslassen darf man die Maschine auch nicht. Wenn er den Anschluss verliert, d.h. die eingestellte Menge würde nicht für die Zeit vom letzten Lauf bis jetzt reichen, knallts auch und man darf nochmal anfangen. Bei 10GB dauert das aber ein paar Wochen würde ich sagen.
Eine bessere Verbindung über den Router mit Portfreigabe hilft nur minimal, beim Laptop mit 160GB würde ich sagen das da eher der Proz die Bremse ist. Will sagen: Der Rechner kann die Blöcke nicht so schnell verifizieren wie sie einfliegen würden...
Einfach mal ein paar Tage laufen lassen, dann wird das schon.
|
|
|
Tja, was soll man auf 0x2b3... antworten?!
Und was das mit Gerichtsverfahren zu tun hat.... Ach lassen wir das.
|
|
|
"gegen BTC, 1500€ Provision" Wait, What? Schreib mal 0,3BTC dran Was soll es denn sein? "Mein" Autohändler hat kein Problem damit, wenn jemand anders bezahlt, sofern er bezahlt.
|
|
|
Naja, "keine" nun nicht gerade, aber wenigstens nur einmal und nicht zweimal.
|
|
|
Das geht auch einfacher, mit nur einer Überweisung und ohne Verlustrisiko für die PKs: - core schließen - Explorer ins Datenverzeichnis, da die wallet.dat umbenennen in wallet.dat.voll - core öffnen - neue Wallet wird erstellt - neue Adresse anlegen und z.B. in den Editor kopieren - core beenden - im Explorer die wallet.dat umbenennen in wallet.dat.neu - wallet.dat.voll umbenennen in wallet.dat - core wieder öffnen - Überweisung an die Adresse aus dem Editor machen - warten bis synchron und bestätigt - core beenden - wallet.dat umbenennen in wallet.dat.leer - wallet.dat.neu umbenennen in wallet.dat - core starten - BTC fliegen ein auf neuer Adresse - alte wallet.dat.leer entsorgen, neue sichern.
Fertig.
|
|
|
4% p.a. und tägliche Überweisung? Wie viel muss man denn da anlegen damit die Gebühren nicht die Zinsen übersteigen? 100BTC?
|
|
|
Da ändert sch nix. Ein Schlüsselpaar ist immer vorhanden, und davon gibt es weiß Gott genug. Eine Wallet egal welcher Art rechnet einfach irgendein Paar aus, und Ende. Das passt bis zum ende der Zeit zueinander, sofern das richtige Verfahren zur Berechnung benutzt wird. Programme machen nur aus Gründen des Cachings und so einfach mal 100 Adressen in einem Rutsch klar, damit die Datensicherung einfacher wird: eine ältere Wallet.dat-Datei hat mit Glück Schlüssel für zukünftige Transaktionen dabei. Eine Paperwalleterzeugungssoftware macht es eben nicht.
Die Empfangsadresse _sollte_ man selber jedesmal ändern, muss man aber nicht, und das ändert nicht den Schlüssel sondern benutzt ein neues Paar. Hat was mit Pseudonymisierung zu tun.
|
|
|
Na super. Bit Boundary überwunden, schon geht ihm™ die Luft aus. Jetzt ärgern sich einige (speziell ich), das sie nicht wieder früher eingestiegen sind, um die paar Satoshis aus dem Pot abzugrasen.
|
|
|
Minen kann nicht einfacher oder erfolgreicher werden, weil das Netz die diff anpasst um die Menge der generierten Blocks (und damit BTC) pro Zeiteinheit auf einem Wert zu halten. Jeder Miner konkurriert mit allen anderen um diesen Pott, und wenn einer anteilsmäßig viel Hashleistung hat, bekommt er genau diesen Anteil an den erzeugten BTC, statistisch. Etwas Glück ist drin, aber grundsätzlich und auf längere Zeit gesehen ist das einfach eine Torte mit verschieden großen Stücken. Wenn nun jemand mehr Leistung ins Netz stellt, so - erhöht er seinen Anteil, und damit die anteilige Ausschüttung, die Anteile der anderen werden weniger (es gibt halt nur 100% Summe) - allerdings steigt die Gesamtleistung auch - daher passt das Netz die Diff an und der Ertrag pro Stunde sinkt wieder, weil Hashleistung weniger wert ist. Daher wird die HL immer weiter aufgepustet: "jeder" Miner ist gierig und will mehr dollars -> mehr HL aufstellen -> diff höher -> mehr TH/s trotzdem nur gleiche $$$ -> vorne anfangen Du würdest jetzt mit deiner Optimierung "nur" deinen Miner mit mehr Leistung ausstatten und damit dein Tortenstück größer machen -> die anderen bekommen weniger -> HL wird aufgestellt -> du musst mitziehen. Da du jetzt nicht soooo großartig viele GH/s hast, wird erstmal nix passieren, und wenn alle dein System nutzen, sind es doch wieder die gleichen Verteilungen, nur eben nicht mit "20GH/s pro Kiste" sondern mit "200 Schlumpf-GH/s pro Kiste" aber der Kuchen ist eben nicht 200000GH groß sondern 2000000 Schlumpf-GH. Dein Anteil bleibt gleich, wie jeder andere auch. Es müsste also "jemand" mit massiver Leistung mit deiner Optimierung massiv dazugewinnen, damit er bis zur Verbreitung des Systems im Vorteil gegenüber den anderen wäre. Danach wären alle gleich schlau. Und jetzt zu deinen Ausführungen: Du willst die (jetzt zufällig besetzte) Nonce vorberechnen, um die W-Kurve zu treffen, das würde die Erzeugung einer gültigen SHA abkürzen. Soweit war ich vorher schon. Allein: Der Beweis fehlt, das es so einen Vorteil geben würde. Also: Schreib ein Programm, das für einen beliebigen Block an Daten (nix BTC, einfach so!) eine nonce findet, ebenso wie BTC das tut. Schreib ein zweites, das die W-Kurve vorberechnet. Lass beide 100000-Mal eine Nonce für einen zufällig gewählten Block an Daten finden, aber für beide Programme den jeweils gleichen Block! Schau, wie viele Versuche BTC braucht, und wie viele deine Version. Wenn deins in der Summe x% weniger braucht, hast du einen Vorteil von x%. Implementier das Verfahren in deinen Bitcoin-Core und mine fröhlich los. Oder CGMiner auf AMD. Oder so. Werd reich. Ich bin sicher, das genau diese Idee schon von fähigen Kryptologen durchgeführt wurde, und ich bin genau so sicher, das selbst wenn so eine Schwäche a) durchführbar und b) vorhanden ist, es trotzdem nicht möglich ist den Aufwand wesentlich zu reduzieren. Das h verloren geht ist richtig, denn h ist ein Wert, der vor dem Hashen vorbesetzt wird und dann als Rechenregister benutzt wird. Dabei wird h immer wieder neu verwürfelt. Deine negative Null erklärt sich mir nicht, aber ich bin beinah sicher, das es ein signed/unsigned-Problem ist, oder einfach eine Vermeidung von Nullbytes. Die W-Kurve hängt wesentlich von den ersten 16 Worten des jeweiligen Blocks ab, aber die ändern sich ja. Und von 16 32bittigen Werten (immerhin 512 bit) letztendlich die Nonce-Wahrscheinlichkeiten für bestimmte Zahlen vorzuberechnen, ist m.E. unmöglich. Du müsstest ja quasi alle Werte durchzählen, die entsprechende Wahrscheinlichkeit errechnen und in eine Tabelle stecken, die dann sortieren und dann wieder durchgehen um die jeweilige Nonce zu prüfen. Sollte rein aufgrund des Speicherplatzes unmöglich sein. Es mag andere Algo's geben, aber mir fiele keiner ein. Ich denke nicht, das es möglich ist via Fourier die Kandidaten in absteigender Wahrscheinlichkeit abzugeben, denn wenn deine "Formel" nur ein Bit danebenliegt klappt es nicht. Testest du 1 Bit "Reichweite", vervielfacht sich ja schon die anzahl der Tests, anstelle einer Nonce musst du "Noncebreite +1" Nonces testen, bei 2 Bit sinds schon "Noncebreite^2 +1".
|
|
|
Es ging nur darum, das 40 S5 bei gleicher Mining-Leistung stromsparender sind als ein (zugegeben schon etwas verstaubter) Intel-Prozessor, also effektiver rechnen können.
Das rechnet sich mit beidem nicht, wenn man die Stromkosten sieht und vor allem in Euro rechnet. Kosten, Nutzen und Sinn wurden völlig ignoriert. Benchmark halt.
|
|
|
Ich würde z.B. BTC -> Börse -> andere Adresse ansetzen. Eine Börse mit großem Volumen hat von der Wallet (hoffentlich) tausende Ein- und Ausgänge, da jetzt den richtigen zu finden ist m.E. unmöglich. Wenn der Betrag nicht identisch ist und die neue Adresse(n) unbenutzt, ist es eine Unmöglichkeit, sie mir zuzuordnen.
Oder?
|
|
|
Also gehst du davon aus, das ihm zwischendrin kurz die Puste ausgeht?
|
|
|
Warum nicht? Pulst er? An den "0" kanns ja nicht liegen, er hat ja eher 4 stellige Zahlen. Oder sogar noch mehr. Oder liegts daran, das er zu spät gestartet ist?
|
|
|
Ich schieb das nicht-verstehen dann mal auf deine Übermüdung... Ich meinte "Codepage". Das was passiert, wenn du im Windows-Editor "echo äöüß" schreibst, es als test.bat speicherst und in der Kommandozeile startest. Das du SHA nicht umdrehen und auch nicht annähern, verkürzen, knacken, umgehen oder sonstwas kannst, lassen wir hier mal weg. Beide. Der Trick an SHA ist, das es als Verfahren offen liegt, und deine Analysen haben schon tausende andere Leute mit dickeren Köppen und Portemonnaies gemacht, und bei keinem kommt auch nur ansatzweise was raus, was dir hilft. Tabellen sind bei SHA sinnlos, weil einfach zu groß, und bei 7000$/BTC versuchen es sicher andere Leute mit allen möglichen Tricks, aber außer Keys zu klauen gibt es nix als Alternative zum Bruten. Keine Panik, da bricht nichts, in den nächsten Jahren. Du wirst also mit deiner Lösung definitiv allein dastehen, der Gottkaiser unter den Minern, und wenn du tatsächlich so viel rückwärts erraten kannst, dann sollte auch Visual C in der Lage sein auf einem 3,8GHz-Prozessor gegen einen ASIC-Miner anzustinken. Was das ganze mit deiner Blaue-Leute-Geschichte zu tun hat, weiß ich nicht.
|
|
|
Wenn deine Generatoren die Wiki-genannten Standardvektoren identisch generieren, "Echtdaten" aber nicht, dann sind deine Daten vermutlich nicht passend groß und werden auf verschiedene Art gestreckt. Schließlich müssen ja irgendwie die 512 Bit pro Runde voll werden. Steht aber sicherlich in der Hilfe zu den Programmen/Seiten... Oder ist es evtl. ein Codepageproblem?
IV und K sind ja auch verschieden lang und sollen verschieden sein?!?!
|
|
|
|