willi9974
Legendary
Offline
Activity: 3654
Merit: 2905
Enjoy 500% bonus + 70 FS
|
|
August 26, 2016, 09:40:27 AM |
|
Jetzt hast du es geschafft mein Interesse zu wecken :-)
Kannst Du etwas über den Blockparser sagen?
- wie geht das? - brauch ich dazu einen BTC Core Node? - kann man den Blockparser (2 Mio Adressen in einer Sekunde abfragen) auf Windows installieren?
Wie bist Du vorgegangen / wie geht das / etc. Kannst Du dazu was sagen, das würde mich sehr interessieren...
PS: Gerne auch per PM / Mail oder WhatsApp....
Viele Grüße Willi
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
August 26, 2016, 10:12:24 AM |
|
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
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 03, 2016, 06:04:49 PM |
|
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
|
|
|
|
cagrund
Legendary
Offline
Activity: 1372
Merit: 1000
CTO für den Bundesverband Bitcoin e. V.
|
|
September 06, 2016, 08:19:56 AM |
|
Jepp, bei mir das selbe Problem. Der Download-Link für die WIN-Versionen zeigt in's nix ... Gruß Carsten.
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 06, 2016, 07:31:54 PM |
|
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
|
|
|
|
curiosity81
Legendary
Offline
Activity: 1778
Merit: 1070
|
|
September 06, 2016, 08:24:39 PM Last edit: September 06, 2016, 08:38:08 PM by curiosity81 |
|
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.
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 06, 2016, 08:43:27 PM |
|
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
|
|
|
|
curiosity81
Legendary
Offline
Activity: 1778
Merit: 1070
|
|
September 07, 2016, 06:01:47 AM |
|
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. 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. 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?
Keins, aber diese Adresse ergeben praktisch einen konstanten Faktor in Deiner Rechnung, und dessen Einfluss ist zu gering um das Problem stark zu vereinfachen (Behaupte ich jetzt mal einfach so). Auch wenn dieser Faktor theoretisch nicht konstant ist, 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. 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. 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, also 6.022*10^23 Mol Kohlenstoff und Du hast in etwa 10^25 g = 10^22 kg Kohlenstoff C12 (~3.6*10^47 Teilchen). Der Mond wiegt etwa 10^23 kg (grob = 3.6*10^47*10 Teilchen). D.h. 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).
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 07, 2016, 09:00:01 AM |
|
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
|
|
|
|
curiosity81
Legendary
Offline
Activity: 1778
Merit: 1070
|
|
September 07, 2016, 09:20:28 AM |
|
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 Ok, offensichtlich mal wieder der Dunning-Kruger-Effekt. Ich spreche im ersten Satz von Teilchen, im zweiten von Gramm: 12g*(6*6*10^23*10^23). Klingelts jetzt? Du disqualifiziert Dich gerade selbst als Gespraechspartner, insbesondere weil Du nicht genau liest. Bye und viel Spass beim Strom verbraten.
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 07, 2016, 09:31:41 AM |
|
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
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 13, 2016, 07:40:43 AM |
|
Bis jetzt noch keine Adresse gefunden wo was drauf ist --> ca. 10 Mio Adressen wurden geprüft
Der Pool prüft derzeit 5 Mrd. Adressen die Stunde... mit im Schnitt 3-4 aktiven Clients. 10mio Adressen hat mein Notebook derzeit in 25 Sekunden durch. Ich wünschte, ich würde mich besser in OpenCL oder CUDA auskennen. Die GPU im Notebook macht bei oclvanitygen 15MKeys/s - theoretisch sollte ich dadurch noch einen Speedup von ca. 30 hinbekommen. Rico
|
|
|
|
willi9974
Legendary
Offline
Activity: 3654
Merit: 2905
Enjoy 500% bonus + 70 FS
|
|
September 13, 2016, 08:43:25 AM |
|
Respekt!
Vielleicht teste ich deinen Windows Client auch mal. Ist der auf Basis von Perl? Kann ich da den Quellcode einsehen oder ist das mit Perl2EXE in eine Exe Datei umgewandelt. Ich lass auf meinen BTC Rechner keinen Software laufen die ich nicht kenne...
Viele Grüße Willi
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 13, 2016, 10:18:24 AM Last edit: September 13, 2016, 01:28:14 PM by rico666 |
|
Ist der auf Basis von Perl?
Perl ist sozusagen der Kleber, der die Kommunikation mit dem Server übernimmt und den/die Generatoren steuert. Der Generator selbst ist compiliertes Go. Die ursprünglichen Sourcen sind hier: https://github.com/saracen/bitcoin-all-key-generatorAber mittlerweile habe ich den arg getrimmt/modifiziert. Die Windows-Version macht mich aber nicht so glücklich. Braucht elend viel (mehr) Speicher und scheint auch nicht so stabil zu sein. edit: genau genommen stürzt sie zuverlässig ab, wenn man mehr als eine CPU auslasten will. (-c x für x > 1) Workaround: in mehreren Fenstern einfach "perl LBC -c 1 -t 1" starten, so oft wieviele CPUs (oder Speicher) man hat/nutzen will. Den Perl Source kann man im Editor ansehen #!/usr/bin/env perl
use strict; use warnings;
use bignum lib => 'GMP'; use utf8;
use Config; use Data::Dumper; use Digest::MD5 qw(md5_hex); _use_eval_cpan( 'File::Spec' ) ; .... snipp (geht natürlich noch weiter)
Muss man zwecks besserer Lesbarkeit evtl. mit perltidy drüberhuschen. Kann ich da den Quellcode einsehen oder ist das mit Perl2EXE in eine Exe Datei umgewandelt. Ich lass auf meinen BTC Rechner keinen Software laufen die ich nicht kenne...
Das ist sehr vernünftig, allerdings muss die Software nicht auf einem "BTC Rechner" laufen. Da wird keine Blockchain, Wallet o.ä. benötigt. Momentan probiere ich aus den Client auf einer kostenlosen Amazon-Instanz laufen zu lassen. Die help bekomme ich angezeigt. Aber die EC2 t2.micro kisten haben nur 1GB RAM... [ec2-user@ip-xx-xxx-xx-xxx ~]$ sudo ./LBC -c 1 -t 60 Benchmark info not found - benchmarking... done. Reading balances... storable found - using that (faster)... Out of memory!
Mal schauen ob mir da was einfällt... Rico
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 16, 2016, 09:23:19 PM Last edit: September 17, 2016, 07:22:39 AM by rico666 |
|
Vielleicht teste ich deinen Windows Client auch mal.
Ist keine offizielle Release, aber endlich die erste Win version, die stabil läuft. http://62.146.128.45//download/LBC-0.827_w64.zipBraucht sogar nicht mehr Speicher als die Linuxversion FALLS man nur eine CPU pro Prozess nutzt. Also perl LBC -c 1 -t 600notfalls halt in mehreren Fenstern eingeben, dann laufen eben x LBC prozesse, von denen jeder eine CPU nutzt. Das ist überhaupt kein Problem, der Server kommt mit sowas klar. Wenn man -c 3 oder so eingibt, läuft es zwar immer noch stabil, aber die Speicherhölle geht los. Also: zweimal LBC -c 1 starten ist wesentlich schonender als einmal LBC -c 2 edit: mindestens zwei Win clients haben die ganze Nacht über Daten geknuspert und sind ohne Probleme durchgelaufen. Rico
|
|
|
|
dArkjON
|
|
September 17, 2016, 01:30:27 PM |
|
Vielleicht Blöde Fragen, aber habt Ihr schonmal ein Wallet gefunden ? Was passiert dann mit den Coins ? und ist es am Ende nicht "Diebstahl" eine Key Kombination zu "erraten" und dann die Coins zu entführen ? Freu mich auf eine Antwort !
|
|
|
|
dArkjON
|
|
September 17, 2016, 05:36:19 PM |
|
Was passiert dann mit den Coins ? und ist es am Ende nicht "Diebstahl ...na ja: werden Passende Paaren gefunden, dann werden nur Rechnungseinheiten (nach Bafin) auf eine andere Adresse verschoben, ist also kein Diebstahl HA, Ha, ha Was ich mich eher Frage, ist so ein Netzwerk nicht eigentlich eine "Selbstzerstörung" des Coin Netzwerkes ? Wenn alle Cold Wallets gefunden wurden und alle Paperwallets geleert sind, wo lagern die Pool Betreiber Ihr Coins dann sicher ? Sicherlich ist die vorhandene Rechenleistung nicht ausreichend dafür, sowas kann sich aber schnell ändern...
|
|
|
|
fronti
Legendary
Offline
Activity: 2914
Merit: 1309
|
|
September 17, 2016, 07:15:03 PM |
|
Was passiert dann mit den Coins ? und ist es am Ende nicht "Diebstahl ...na ja: werden Passende Paaren gefunden, dann werden nur Rechnungseinheiten (nach Bafin) auf eine andere Adresse verschoben, ist also kein Diebstahl HA, Ha, ha Was ich mich eher Frage, ist so ein Netzwerk nicht eigentlich eine "Selbstzerstörung" des Coin Netzwerkes ? Wenn alle Cold Wallets gefunden wurden und alle Paperwallets geleert sind, wo lagern die Pool Betreiber Ihr Coins dann sicher ? Sicherlich ist die vorhandene Rechenleistung nicht ausreichend dafür, sowas kann sich aber schnell ändern... wenn man eine solche menge an Daten spiechern und auch wieder Effektiv durchsuchen kann, dann hat nicht nur bitcoin probleme. alleine die Energie die man dann aus den Sternensystemen abzeihen müsste um eine Suche zu starten reicht vermutlich um damit ein paar schwarze Löcher zu erstellen..
|
If you like to give me a tip: bc1q8ht32j5hj42us5qfptvu08ug9zeqgvxuhwznzk
"Bankraub ist eine Unternehmung von Dilettanten. Wahre Profis gründen eine Bank." Bertolt Brecht
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
September 18, 2016, 06:51:39 PM |
|
Bei mir läuft Version 0.827 auf Windows wesentlich besser als die älteren Versionen. Ich habe mir zum starten einfach folgendes Batch-Script erstellt: @echo off cd %userprofile%\Desktop\LBC-client start perl LBC -c 1 -t 1 start perl LBC -c 1 -t 1 start perl LBC -c 1 -t 1 start perl LBC -c 1 -t 1 Nice. Mittlerweile gibt es jedoch version 0.832 und die verlangt der Server auch. Leider leider war die Windows-version zwar stabil, hat aber nicht alle hash160 gefunden die sie sollte... Lange Geschichte, könnte man nun breittreten wer der größere Idiot ist - ob ich oder Windows. Belassen wir es dabei, dass jetzt der Windows client tatsächlich belastbar ist. Zu dem obigen Skript habe ich folgenden Verbesserungsvorschlag. Der Client ist nun wirklich stabil und mit -c 1 sind schon etliche Win clients mehr als 48h durchgelaufen. -t 1 ist daher überflüssig. Ich würde es mit folgenden Zeiten probieren: @echo off cd %userprofile%\Desktop\LBC-client start perl LBC -c 1 -t 3600 start perl LBC -c 1 -t 1100 start perl LBC -c 1 -t 600 start perl LBC -c 1 -t 60
Ist ein kleiner Geheimtipp, weil dann finden einige der Windows Clients "Löcher" in den Intervallen, die einem fetten -c 20 -t 3600 linux client entgehen... Rico
|
|
|
|
|
|