Das folgende ist bestimmt eine Anfaengerfrage aber es beschaeftigt mich. Als Beispiel nehme ich BTC und LTC. Auf der Seite http://litecoinchart.com/ ist der aktuelle Ratio von LTC zu BTC (LTC/BTC) ca. 0.032 (28.04.2013, 22:00). Eine aehnliche Schreibweise findet man auch auf https://vircurex.com. Ich lese "LTC/BTC" nun wie folgt: "LTC pro BTC", d.h. wieviel LTCs bekommt man fuer einen BTC (man kann auch fragen wieviele LTCs man fuer x BTCs bekommt, aber das x kuerzt sich raus und man landet bei ersterem). In dem Fall bekaeme man fuer einen LTC ca. 30 BTCs. Ich bezweifel dass das stimmt bzw. dass es andersrum ist. Man kann das natuerlich auch wie folgt interpretieren: 1 BTC = 132 $, 1 LTC = 4 $ und demnach LTC/BTC = 4/132 was ungefaehr 0.032 ist. Wieso diese verwirrende Notation? Ersterer Fall ist intuitiver und man macht nicht mehr den Umweg ueber den Dollar ... Gruss, cu |
|
|
|
Es kann auch gut sein, dass, je groesser die Difficulty ist, desto besser ist die vorgeschlagene Methode.
Soweit ich das verstanden habe, hängt das mit den führenden 'Nullen' zusammen. sobald da eine 1 auftaucht kann man dann den nächsten Versuch starten. Allerdings ist meine Vermutung das der Test zwar schneller durch ist, dafür aber mehr Anläufe nötig sind. Was ich mich derzeit frage ist ob es 'was' bringt a) statt dem Ansatz mit dem midstate einfach die zwei SHA256 hashes 'hintereinander' durchzurechnen und/oder b) statt einem sequentiell abzuarbeitendem C-Programm eine Netzliste zu verwenden. Die Frage mit der Anzahl der Anlaeufe waere beantwortbar wenn man verstehen wuerde wie das mit der Noncekodierung funktioniert. Im Moment geht mir das noch nicht wirklich auf. So wie ich das oben beschrieben haben ist es nicht ganz richtig. Der Autor reserviert den Platz fuer 1000 Nonces in der Booleschen Formel (oder 10000 in einem anderen Beispiel) und dann beginnt der Solver diese zu fuellen. Zmdst verstehe ich jetzt warum der Solver auch UNSAT ausgeben kann (Fall (v)), naemlich wenn die 1000 Nonces nicht reichen. Gruss, cu P.S.: kennst du ein Tutorial wo das Prinzip BTC-Mining relativ genau erklaert wird? Also "target" holen, zweimal Hashfunktion drauf ansetzen, Ergebniss pruefen, sowie wie die Difficulty bestimmt wird ... am besten erklaert an Code. |
|
|
|
Nochmal: das ist nicht die nächste Generation von Minern!
Ich wuerde das so nicht stehen lassen. Ich habe noch ein bischen ueber das Paper nachgedacht. Und eigentlich ist es relativ simpel. Die vorgeschlagene Methode ist sozusagen "Mining in elegant". Das worauf heute alle gucken, die GH/s, wuerde der Solver uebernehmen. Wenn ich das BTC-Prinzip richtig verstehe, so bekommen alle die gleiche Aufgaben, jeder versucht per Brute Force die Loesung zu berechnen (eine Schleifendurchlauf = 1 H) und der erste bekommt dann den Zuschlag. Mit der in der Publikation genannten Methode wuerde die Schleife vom Solver uebernommen, d.h. solange der Solver keine Loesung gefunden hat und Teilbaeume des Suchbaums verwirft, solange beweist der Solver, dass Mengen (!) an Hashs nicht die Loesung sein koennen. Das kann die vorhandene Software nicht, die kann diese Aussage immer nur fuer den gerade gegebenen Hash treffen. Ein Miningalgorithmus wuerde dann wie folgt aussehen: (i) hole Aufgabe; (ii) erzeuge und schreibe die Constraints in eine Datei; (iii) starte den Solver mit Constraints als Input; (iv) wenn der Solver satisfiable ausgibt: (a) lese die Loesung ein; (b) erzeuge daraus das was man benoetigt um den Zuschlag zu bekommen und hole Zuschlag; (c) gehe zu (i); (v) wenn der Solver unsatisfiable ausgibt, hmm ... weiss noch nicht recht; (vi) wenn jmd anderes die Loesung findet: (a) stoppe Solver; (b) gehe zu (i); Was die Publikation unter "non-deterministic" versteht, bedeutet, so glaube ich (bin mir aber nicht 100% sicher), dass die Loesung fuer die Nonce nicht eindeutig ist, es kann sehr viele Loesungen geben, die Nonce haengt dann einfach von der Implementierung des Solvers ab bzw. wenn man einen Zufallsgenerator benutzt um das Branching des Solvers zu bestimmen, eben von der Sequenz der Zufallszahlen. Ich kann mich mit meiner Interpretation der Methoden aber auch irren ... Es kann auch gut sein, dass, je groesser die Difficulty ist, desto besser ist die vorgeschlagene Methode. Ich habe die Erfahrung gemacht, dass, je constrainter ein Problem ist, desto schneller findet der Solver eine Loesung. Aber mit solchen Aussagen muss man vorsichtig sein, SAT ist nun mal sehr schwer zu loesen. Wer Lust hat das mal zu implementieren, ich koennte den SAT-Teil uebernehmen. Gruss, cu |
|
|
|
|
Fuer die zweite Datei out_1k_sat.cnf braucht Cryptominisat 50s und reportet ein Variablenbelegung. Ich muss mir das Paper mal genauer zu Gemuete fuehren ... hab aber keine Ahnung von Kryptographie, arggghhhhh ... Minisat abgeschossen, dauert zu lang!
|
|
|
|
|
Cryptominisat hat unsat reportet nach 53s. Geht also. Minisat roedelt immer noch.
|
|
|
|
|
hmm ... bei mir konnte noch keiner der Solver die out_1k_unsat.cnf loesen, selbst minisat muss beissen.
|
|
|
|
LTC Mining kann ich nicht beurteilen hab ich noch nicht gemacht, allerdings wirst du da wegen scrypt noch weniger H/s haben. Ich denke mal das log stammt von Bitcoin? Allerdings würde ich mit der Hashrate nicht solo minen  Nene, ist schon LTC, BTCmining macht ja kaum Sinn. Ich teste momentan wo es noch machbar ist mitzuminen, das mach ich auf meinem Schlepptop, dann guck ich mal ob ich mir bessere HW zuleg'. Gruessle und danke fuer die Infos, cu |
|
|
|
[2013-04-22 09:50:52] accepted: 4/4 (100.00%), 1.57 khash/s (yay!!!) Neuer Block wurde von dir oder deinem Pool erfolgreich berechnet. Ich rechne hierbei bei einem Pool mit, d.h. also meine Krücke von Laptop hat einen kleinen Anteil an diesem Block und diesen bekomm ich gutgeschrieben? Oder hat den mein Rechner berechnet und eigentlich mache ich so Verlust? Wie sieht das denn bei den HW-Anforderungen beim LTCmining aus? Gruss, cu |
|
|
|
|
Kann mir jmd erklaeren was folgendes bedeutet?
...
[2013-04-22 09:47:33] thread 0: 37000 hashes, 0.66 khash/s
[2013-04-22 09:48:22] LONGPOLL detected new block <= das da?
[2013-04-22 09:48:22] thread 0: 33852 hashes, 0.69 khash/s
[2013-04-22 09:48:22] thread 1: 38740 hashes, 0.74 khash/s
[2013-04-22 09:49:19] thread 0: 41356 hashes, 0.73 khash/s
[2013-04-22 09:49:19] thread 1: 44520 hashes, 0.79 khash/s
[2013-04-22 09:50:20] thread 0: 44008 hashes, 0.72 khash/s
[2013-04-22 09:50:20] thread 1: 47236 hashes, 0.77 khash/s
[2013-04-22 09:50:52] thread 1: 27396 hashes, 0.85 khash/s
[2013-04-22 09:50:52] accepted: 4/4 (100.00%), 1.57 khash/s (yay!!!) <= und das da?
...
thx.
gruss,
cu
|
|
|
|
Darf dann Adresse C fuer weitere Einzahlungen genutzt werden?  |
|
|
|
|
Du hast vollkommen Recht!
Aber wenn man kein Smartphone besitzt (ich z.B. besitze kein Smartphone) dafuer aber mehrere Rechner (z.B. Laptops), dann hilft das hoffentlich weiter.
Gruss,
cu
|
|
|
|
Auf http://www.nongnu.org/oath-toolkit/index.htmldas Paket runterladen (nun alles per Konsole): tar -xzvf oath-toolkit-2.0.2.tar.gz cd oath-toolkit-2.0.2/ ./configure (falls Pakete fehlen, entsprechend nachinstallieren) make cd oathtool/ ./oathtool --totp --base32 <secret key> und dann die Zahl die da rauskommt in das entsprechende Feld eingeben und auf den Knopf druecken. (siehe auch http://www.nongnu.org/oath-toolkit/oathtool.1.html) Edit: vllt noch ganz klug danach immer die history zu loeschen per history -c |
|
|
|
|
Wieder ne dumme Frage: Weiss jmd ob man mit BTCs auch Open Source Projekte finanzieren kann? Z.B. Eclipse? Oder JabRef? Oder hat da jmd Einfluss so dass sowas realisiert wird?
Das ist z.B. Software die ich nutze. Wuerde da gerne BTCs spenden. Auch waere es interessant hier mal ne Liste zu erstellen welche Projekte BTCs akzeptieren. Auch hier natuerlich mit dem zusaetzlichen Hintergedanken der Synergie.
Falls sowas schon existiert, Admin, loesch diesen Beitrag!!!1elf
Gruss,
cu
|
|
|
|
|
@lame duck: Ich schmiss einfach mal Ideen in den Raum.
Zum Recht: Es benoetigt halt ein Interface zur Realitaet, das muss nichts Fassbares sein und kann sich auch ueber juristisches Gefasel definieren. Sollte halt kurz und buendig sein (Oxymoron, ja ich weiss). Nichtsdestotrotz, man muss einen Verbindung zur realen Welt herstellen.
Zur Rechenleistung: Naja, ich denke, dass Rechenleistung immer noch knapp ist, sonst wuerde es sowas wie BOINC nicht geben. Und wenn das Volk Bitcoins berechnen moechte ... so sei es, das ist Demokratie. Dann gruendet man halt eine weitere Republik und umgibt sich mit Gleichgesinnten. Das ist Freiheit.
Energie und Informationsverabeitungskapazitaet sowie die Bereitstellung der Bandbreite um Information von A nach B zu bekommen, das ist die Ware der Zukunft, Bitcoins u.ae. sind das entsprechende Geld.
|
|
|
|
|
@Chefin: man hat dann halt mindestens zwei Staatsbuergerschaften. Die erste, Altmodische, so wie wir sie seit einigen Jahrzehnten kennen und eine neue, Virtuelle. Laeuft der Client ist man Staatsbuerger und hat noch zu definierende Rechte, welche man in Anspruch nehmen kann.
Ueber die Unabhaengigkeitserklaerung, welche juristisch Hand und Fuss haben muesste, haben altmodische Staaten nicht das Recht sich einzumischen. Ansonsten muss um die Unabhaengigkeit gekaempft werden, mglw. mit DDos-Angriffen. Solche Methoden sollten aber wirklich nur zur Verteidigung der Republik genutzt werden. Wenn man sich zu Beginn nirgends einmischt, so sollte es keine Probleme geben, ist ein bestimmter Threshold erreicht kann man international mitmischen, so wie Anonymous, nur vernuenftiger und mit einer entsprechenden Rechtsgrundlage (Unabhaengigkeitserklaerung).
Das Kapital der dezentralisierten Republik besteht in der Rechenkapazitaet des P2P-Netzwerkes. Steuern wuerde ueber die Bereitstellung von Rechenkapazitaet gezahlt, was aber automatisch eintritt sobald der Client laeuft. Also eigentlich wie BOINC nur noch etwas weiter gedacht. Die Buerger der Republik definieren demokratisch bestimmte Ziele welche ueber die Rechenkapazitaet geloest werden.
Gruss,
cu
|
|
|
|
|
Ich koennte mir Rechenkapazitaet als Kapital der Republik vorstellen, mit der Bandbreite das Hauptkapital der Zukunft. Hab aber wahrscheinlich zuviel Charles Stross gelesen.
|
|
|
|
|
Show Posts
