Java entfernt NIST-EC-Kurven secp256k1 die bei Bitcoin verwendet wird.

[MixMax]

Neustes Java Update: https://www.java.com/de/download/java8_update.jsp

Zitat

Sonstige Hinweise: Veraltete NIST-EC-Kurven aus den TLS-Standardalgorithmen entfernen
Bei dieser Änderung werden veraltete NIST-EC-Kurven aus den standardmäßigen benannten Gruppen entfernt, die während der TLS-Verhandlung verwendet werden. Folgende Kurven werden entfernt: sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 und secp256k1.

Die EC-Kurve secp256k1 wird für die Signaturen bei Bitcoin verwendet. 

Java hält sie also für veraltet und entfernt sie.

Richtig wäre es umgekehrt: Java sollte entfernt werden, weil es völlig veraltet ist und noch nicht mal 64bit Arrays unterstützt!

 

Die ganze Sache hat aber auch Vorteile: Ich hab mir eh meine eigene ECDSA Bibliothek programmiert und bin damit völlig unabhängig. So können auch keine Bugs aus der Java eigenen Bibliothek kommen.  Ich empfehle das jedem auch selbst zu machen! Mit der neuen Java Version, ist jetzt ja auch jeder dazu gezwungen.

[Jokin]

vor 36 Minuten schrieb MixMax:

Ich empfehle das jedem auch selbst zu machen!

Mach ich!

... sobald ich mit meinem Nullpulsinduktor fertig bin - den sollte sich auch jeder mal selber gebaut haben.

 

(ernsthaft? Wer ist denn als Laie schon in der Lage eine eigene 'fehlerfreie' ECDSA-Bibliothek zu bauen? Ich musste schon bei den 5 Abkürzungsbuchstaben die richtige Reihenfolge zweimal kontrollieren)

[PeWi]

1 hour ago, Jokin said:

... sobald ich mit meinem Nullpulsinduktor fertig bin - den sollte sich auch jeder mal selber gebaut haben.

Du meinst aber schon die verbesserte Version mit dem Differentialdiskriminator vor dem Eingangssignal, damit man die Fluktuationen des Nullpulses besser generalisieren kann?

Bearbeitet 13. Januar 2020 von PeWi
Schreibfehler

[Ulli]

Denkt bitte auch daran, immer genug Material für den Fluxkompensator bereitzuhalten. Inzwischen kann man damit sogar die Natur schonen, da der Müll direkt dafür verwendet werden kann.

[MixMax]

vor 1 Stunde schrieb Jokin:

(ernsthaft? Wer ist denn als Laie schon in der Lage eine eigene 'fehlerfreie' ECDSA-Bibliothek zu bauen?

Als Softwaeentwickler steht man oft vor der Entscheidung eine fremd Bibliothek zu nutzen oder es selbst zu machen.

Allgemein wird geraten die Bibliothek zu nutzen. Meistens stimmt das, aber eben nur meistens.

In speziell kritischen Fällen kann es aber sein, das genau dort die Abhängigkeit zum Verhängniss wird, weil die Lizenz nicht passt, Module verändert oder eingestellt werden, oder Schadsoftware genau über diesen Kanal unbemerkt eingeschleust werden könnte.

Dieses Beispiel zeigt, dass ich mich richtig entscheiden habe, es selbst zu machen. Klar ist es ein großer Aufwand, aber wenn es notwendig ist, lohnt es sich hinterher.

[¯\_(ツ)_/¯]

vor 3 Stunden schrieb MixMax:

Richtig wäre es umgekehrt: Java sollte entfernt werden, weil es völlig veraltet ist und noch nicht mal 64bit Arrays unterstützt!

Programmiere ja auch bissle Java, aber was ist denn ein 64 Bit Array ? 

[MixMax]

vor 51 Minuten schrieb ¯\_(ツ)_/¯:

Programmiere ja auch bissle Java, aber was ist denn ein 64 Bit Array ?

byte[] b = new byte[2147483646+1];

Genau das geht nicht, die Länge des Array ist auf 32bit begrenzt. Also auf Integer.MAX_VALUE.

Dabei sind Arrays die Grundlage von fast allen Komplexen Klassen. Ein Datenbank z.B. kann mit Java dann nicht größer als dieser Wert sein.

Ein 46bit-Array wäre dann ein Array welches die maxial Länge von 2^64 haben kann.

 

Bearbeitet 13. Januar 2020 von MixMax

[Jokin]

vor 9 Minuten schrieb MixMax:

byte[] b = new byte[2147483646+1];

Genau das geht nicht, die Länge des Array ist auf 32bit begrenzt. Also auf Integer.MAX_VALUE.

Dabei sind Arrays die Grundlage von fast allen Komplexen Klassen. Ein Datenbank z.B. kann mit Java dann nicht größer als dieser Wert sein.

Ein 46bit-Array wäre dann ein Array welches die maxial Länge von 2^64 haben kann.

 

Ich mach in PHP:

$byte = "2147483646"; // Strings sind toll
$byte++; // einer geht noch, einer geht noch rein!

[battlecore]

Zwei Bibliotheken.

Sacht die eine "Puh ey, alles ganz schön veraltet hier ne?"

Sacht die andere "Waaah eine sprechende lib"

[¯\_(ツ)_/¯]

vor 4 Stunden schrieb MixMax:

byte[] b = new byte[2147483646+1];

Genau das geht nicht, die Länge des Array ist auf 32bit begrenzt. Also auf Integer.MAX_VALUE.

Dabei sind Arrays die Grundlage von fast allen Komplexen Klassen. Ein Datenbank z.B. kann mit Java dann nicht größer als dieser Wert sein.

Ein 46bit-Array wäre dann ein Array welches die maxial Länge von 2^64 haben kann.

 

Okay... wozu auch immer man diese Riesen Arrays braucht... für Datenbanken ganz sicher nicht... Kenne in Java implementierte Datenbanken, die haben damit anscheinend kein Problem.

[¯\_(ツ)_/¯]

vor 8 Stunden schrieb MixMax:

Java hält sie also für veraltet und entfernt sie.

Bezieht sich nur auf Oracle JDK 8 u231 oder ? ... hab das leider nicht mehr aufm Rechner, um die Oracle 8 Flags zu überprüfen mit denen man das wieder aktivieren kann.
Zumindest mit OpenJDK 11, 12, 13 und 14 ist der "secp256k1" noch da... 

Hab mich aber auch net all zu tief mit der Thematik beschäftigt. ist das korrekt so ?

        KeyPairGenerator keyGen = KeyPairGenerator.getInstance("EC");
        ECGenParameterSpec ecs = new ECGenParameterSpec("secp256k1");
        keyGen.initialize(ecs, new SecureRandom());
        KeyPair pair = keyGen.genKeyPair();
        PrivateKey priv = pair.getPrivate();
        PublicKey pub = pair.getPublic();
        System.out.println(pub.toString());

[MixMax]

vor 26 Minuten schrieb ¯\_(ツ)_/¯:

Hab mich aber auch net all zu tief mit der Thematik beschäftigt. ist das korrekt so ?

        KeyPairGenerator keyGen = KeyPairGenerator.getInstance("EC");
        ECGenParameterSpec ecs = new ECGenParameterSpec("secp256k1");
        keyGen.initialize(ecs, new SecureRandom());
        KeyPair pair = keyGen.genKeyPair();
        PrivateKey priv = pair.getPrivate();
        PublicKey pub = pair.getPublic();
        System.out.println(pub.toString());

Ob es korrekt ist, weis ich nicht, hab ja meine eigene ECDSA Bibliothek die ich nutze. Aber sieht mal gut aus. Hab es mal in eclipse Kopiert:

Sun EC public key, 256 bits
public x coord: 112758068002153022625078478295291747283781294379435620512715355697155022578995
public y coord: 20135104044387078135880922179441490526785410273179790892918959045391968766675
parameters: secp256k1 (1.3.132.0.10)

Da wird einfach nur nen Random Priv.Key erzeugt und der Pub.Key ausgegeben.

 

vor 36 Minuten schrieb ¯\_(ツ)_/¯:

Okay... wozu auch immer man diese Riesen Arrays braucht... für Datenbanken ganz sicher nicht... Kenne in Java implementierte Datenbanken, die haben damit anscheinend kein Problem.

Also "Riesig" ist was anders.  Integer.MAX_VALUE ist so klein, das man damit nur ne Datenbank für die Eissorten der Eisdiele um die Ecke machen könnte.

Was glaubst du wie viel Transaktionen in der Blockchain sind? Ich schreibe gerade meinen lokalen Blockchainexplorer und dort ist Integer.MAX_VALUE viel zu klein für alle Transaktionen die in einen Bloomfilter sollen.

Und andere Datenbanken? Na ja, frag mal Google wie viel Webseiten es gibt. Oder schau dir mal SAP-Datenbanken an. Die würden über Integer.MAX_VALUE nur müde lächeln.

Und warum müssen die in ein Array rein? Also die gesamte Datenbank kommt nirgens in ein Array rein, sonder ist auf viele Datein verteilt. Nur muss man die auch Indizieren um einen Datensatz finden zu können.  Dazu gibt es große Index-Listen mit Bloomfiltern und noch viel mehr Kram wie HashTabellen oder TreeSetz, in denen die Index Listen dann sortierte Schlüssel haben, nach denen gesucht wird. Diese HashMaps, TreeSets und BloomFilter verarbeiten aber intern Arrays die dann in Java bei Integer.MAX_VALUE ein Ende haben und so mit nicht zu gebrauchen sind! Und genau darum geht es, hier ist dann das beschriebene Problem.

Das Thema ist also etwas komplexer als es den Anschein macht.

 

 

Bearbeitet 13. Januar 2020 von MixMax

[¯\_(ツ)_/¯]

vor 15 Minuten schrieb MixMax:

Also "Riesig" ist was anders.  Integer.MAX_VALUE ist so klein, das man damit nur ne Datenbank für die Eissorten der Eisdiele um die Ecke machen könnte.

Was glaubst du wie viel Transaktionen in der Blockchain sind? Ich schreibe gerade meinen lokalen Blockchainexplorer und dort ist Integer.MAX_VALUE viel zu klein für alle Transaktionen die in einen Bloomfilter sollen.

Und andere Datenbanken? Na ja, frag mal Google wie viel Webseiten es gibt. Oder schau dir mal SAP-Datenbanken an. Die würden über Integer.MAX_VALUE nur müde lächeln.

Keine Ahnung was du da erzählst... zumindest scheint es kein grosses Problem zu sein.

Sind dir PB genug ?
Dann nehm einfach Apache Cassandra. Kann gut Peta-Byte an Daten speichern. Ist in Java Implementiert....
Ansonsten probier mal ElasticSearch aus. Kann auch sehr riesige Datenmengen speichern. ist auch in Java implementiert...

und das sind beides keine Datenbanken für Eisdielen... 

Aber wünsche Dir viele Erfolg deine eigene Datenbank zu schreiben... 

[MixMax]

vor 2 Minuten schrieb ¯\_(ツ)_/¯:

Aber wünsche Dir viele Erfolg deine eigene Datenbank zu schreiben... 

Sie ist ja schon lang fertig. Natürlich gibt es immer Mittel und Wege etwas über Umwege doch hinzubekommen. So hab ich es ja auch machen müssen.

Einfacher währe es allerdings, wenn Java mit der Zeit gehen würde und nicht bei ihren 32Bit Integer stehen geblieben wäre. Aber sie haben wichtigere Dinge zu tun, wie die Secp256k1 Kurve als veraltet zu erklären.

 

 

[¯\_(ツ)_/¯]

vor 36 Minuten schrieb MixMax:

Einfacher währe es allerdings, wenn Java mit der Zeit gehen würde und nicht bei ihren 32Bit Integer stehen geblieben wäre. Aber sie haben wichtigere Dinge zu tun, wie die Secp256k1 Kurve als veraltet zu erklären.

Du verwechselst hier irgendwie eine Programmiersprache und die Implementierung dessen. Das hat mit Java, der Programmiersprache, nicht viel zu tun.
Sondern Oracle hat es in ihrer Implementierung im OracleJDK entschieden. Und secp256k1 ist nicht entfernt worden, sonder per default einfach nur nicht aktiv
für TLS Handshake z.B. Per Flag kann es aber wieder aktiviert werden. Der entscheidende Faktor ist, dass TLS 1.3 wohl secp256k1 als deprected markiert hat.

Ganz interessant dazu  zu lesen ist:
https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses

 

Wie auch immer.. Du hast deine eigene ECDSA lib implementiert... du hast deine eigene Datenbank implementiert. Hauptsache du bist glücklich.
So schlecht scheint Java ja dann doch nicht zu sein, wenn du das alles mit Java implementiert hast...

Bearbeitet 13. Januar 2020 von ¯\_(ツ)_/¯

[MixMax]

vor 26 Minuten schrieb ¯\_(ツ)_/¯:

Du verwechselst hier irgendwie eine Programmiersprache und die Implementierung dessen. Das hat mit Java, der Programmiersprache, nicht viel zu tun.
Sondern Oracle hat es in ihrer Implementierung im OracleJDK entschieden. Und secp256k1 ist nicht entfernt worden, sonder per default einfach nur nicht aktiv
für TLS Handshake z.B. Per Flag kann es aber wieder aktiviert werden. Der entscheidende Faktor ist, dass TLS 1.3 wohl secp256k1 als deprected markiert hat.

Ganz interessant dazu  zu lesen ist:
https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses

Ja mag sein, danke für die Info. Ich hab das tatsächlich nicht genauer untersucht, sondern hab das in der Update-Beschreibung gelesen.  Danke für die Aufklärung, dann ist es nicht ganz so schlimm wie ich dachte.

vor 29 Minuten schrieb ¯\_(ツ)_/¯:

Wie auch immer.. Du hast deine eigene ECDSA lib implementiert... du hast deine eigene Datenbank implementiert. Hauptsache du bist glücklich.
So schlecht scheint Java ja dann doch nicht zu sein, wenn du das alles mit Java implementiert hast...

Ja, so schlecht ist Java nicht. Das stimmt schon, sonnst würde ich wohl kaum damit programmieren. Es gibt immer irgendwas, was einem stört, in jeder Programmiersprache sicherlich.

[PeWi]

On 1/13/2020 at 10:01 AM, MixMax said:

Ich hab mir eh meine eigene ECDSA Bibliothek programmiert und bin damit völlig unabhängig.

fefe hält anscheinend wenig von ECDSA:

"[...] Denn wir reden hier von ECDSA. ECDSA war damals schon angeschossen, weil es so fragil ist, und es so einfach ist, damit einen Totalschaden zu produzieren. Die Playstation war über ihr DSA gehackt worden. djb hatte bereits mit explizitem Hinweis auf die Fragilität von ECDSA und den NIST-Kurven seinen Gegenvorschlag Ed25519 publiziert. Und unter diesen Umständen haben die den Code nochmal angefasst und ihn schlimmer gemacht. Dazu muss man wissen, dass Krypto-Code so der am wenigsten volatile Code überhaupt ist. Alle sind sich bewusst, wie kritisch da jedes Bit und jeder CPU-Zyklus ist, und keiner will da irgendwas anfassen. [...]"

Quelle: https://blog.fefe.de/?ts=a0e1ef44

(Disclaimer: Mir fehlen die Kenntnisse, das zu beurteilen. Und ob diese Fragilität für BTC eine Rolle spielen könnte.)

[MixMax]

vor 33 Minuten schrieb PeWi:

fefe hält anscheinend wenig von ECDSA:

"[...] Denn wir reden hier von ECDSA. ECDSA war damals schon angeschossen, weil es so fragil ist, und es so einfach ist, damit einen Totalschaden zu produzieren. Die Playstation war über ihr DSA gehackt worden. djb hatte bereits mit explizitem Hinweis auf die Fragilität von ECDSA und den NIST-Kurven seinen Gegenvorschlag Ed25519 publiziert. Und unter diesen Umständen haben die den Code nochmal angefasst und ihn schlimmer gemacht. Dazu muss man wissen, dass Krypto-Code so der am wenigsten volatile Code überhaupt ist. Alle sind sich bewusst, wie kritisch da jedes Bit und jeder CPU-Zyklus ist, und keiner will da irgendwas anfassen. [...]"

Quelle: https://blog.fefe.de/?ts=a0e1ef44

(Disclaimer: Mir fehlen die Kenntnisse, das zu beurteilen. Und ob diese Fragilität für BTC eine Rolle spielen könnte.)

Ha ha schön, dass du es ansprichst.

Die Playstation wurde gehackt, weil die so absolut selten dämlich bei der Implementierung wahren und die Zufallszahl "k" überhaupt nicht beachtet hatten und sie auf einen festen Wert gesetzt hatten, so konnte der Priv.Key einfach zurückgerechnet werden.

Die Stabilität von ECDSA ist ganz einfach zu beschreiben: Entweder ist sie 1 oder 0. Entweder ist die Signatur am Ende nun richtig oder falsch.
Dazwischen gibt es nix, was irgendwie instabil sein könnte. Wenn die Signatur fehlschlägt, hat man entweder nen Bug drin oder sie ist falsch.
Die ganze Berechnung ist eine deterministische Rechnung, die gar nicht irgendwie instabil sein kann. Ist einfach wie eine Formel die ausgerechnet wird.

Hier der Link zu meiner Version, falls die sich jemand rein ziehen möchte.
https://github.com/MrMaxweII/Secp256k1-Calculator/blob/master/Secp256k1.java

 

Bearbeitet 15. Januar 2020 von MixMax

[PeWi]

54 minutes ago, MixMax said:

Die Playstation wurde gehackt, weil die so absolut selten dämlich bei der Implementierung wahren und die Zufallszahl "k" überhaupt nicht beachtet hatten und sie auf einen festen Wert gesetzt hatten, so konnte der Priv.Key einfach zurückgerechnet werden.

fefe würde schreiben: einmal mit Profis arbeiten!

54 minutes ago, MixMax said:

Die Stabilität von ECDSA ist ganz einfach zu beschreiben: Entweder ist sie 1 oder 0. Entweder ist die Signatur am Ende nun richtig oder falsch.
Dazwischen gibt es nix, was irgendwie instabil sein könnte. Wenn die Signatur fehlschlägt, hat man entweder nen Bug drin oder sie ist falsch.

Wenn das so simpel, verstehe ich die Aussage von fefe nicht. Ich hätte spekuliert, dass man sich womöglich leicht um ein Bit vertun kann, es diverse Sonderfälle beim Errechnen der eliptischen Kurven o.ä. geben könnte, ... oder sonstwas. 😉

[MixMax]

vor 23 Minuten schrieb PeWi:

Wenn das so simpel, verstehe ich die Aussage von fefe nicht. Ich hätte spekuliert, dass man sich womöglich leicht um ein Bit vertun kann, es diverse Sonderfälle beim Errechnen der eliptischen Kurven o.ä. geben könnte, ... oder sonstwas. 😉

"simpel" hab ich nicht geschrieben. Es ist ne komplexe Rechnung, die aber nicht irgendwie instabil wird.

Wenn man sich "um ein Bit" vertut (also irgendwo nen Fehler einbaut) dann funktioniert es halt am Ende nicht und man bekommt dadurch keine Verifizierung die gültig ist.

"Sonderfälle" gibt es eigentlich nicht. Es ist ein deterministischer Rechenweg, der vom Anfang bis zum Ende genau stimmen muss.

 

Simmt am Ende das Ergebnis (Dafür werden Prüfcodes geschrieben) stimmt alles.  So wie bei einem Taschenrechner z.B.

Bearbeitet 15. Januar 2020 von MixMax

[PeWi]

4 minutes ago, MixMax said:

"simpel" hab ich nicht geschrieben.

Mit "simpel" meinte ich die von dir erwähnte Stabilität ("Entweder ist sie 1 oder 0. Entweder ist die Signatur am Ende nun richtig oder falsch."), nicht den Rechenweg.
Ich habe kurz in deinen Quelltext reingeschaut, aber als weitgehender Kryptolaie ist das für mich alles China (falls du diese Redewendung kennst).

[MixMax]

Also falls du wirklich Interesse daran hast ECDSA zu lernen oder nen Überblick zu bekommen kannst mich gerne Details fragen. Gibt nicht viele mit denen ich mich über dieses Thema austauschen kann.

Ich könnte auch nen Thema erstellen, in dem ich ne kleine Anleitung darüber poste? Die Arbeit sollte aber nicht für die Katz sein, also nur wenn es wirklich jemand interesseirt.

Bearbeitet 15. Januar 2020 von MixMax

[PeWi]

11 hours ago, MixMax said:

Also falls du wirklich Interesse daran hast ECDSA zu lernen oder nen Überblick zu bekommen kannst mich gerne Details fragen.

Danke für das Angebot.

Wie mein bisheriges Unwissen zeigt, reicht es mir, Anwender zu sein. 🙄

11 hours ago, MixMax said:

Gibt nicht viele mit denen ich mich über dieses Thema austauschen kann.

Das glaube ich gerne.

Ich habe früher auf der Basis der Infozip-Sourcen Backup-Programme mit Deduplizierung geschrieben. Das fand/finde ich super, es hat sich nur auch kein anderer dafür interessiert. 😁

[MixMax]

Oh je, noch nie gehört, aber klingt interessant.

[PeWi]

23 minutes ago, MixMax said:

Oh je, noch nie gehört, aber klingt interessant.

Das ganze wurde vor 30 Jahren angeregt durch ein DOS-Backup-Programm namens BackMagic. (Leider wurde das nicht weiterentwickelt.)

Das hat die Festplatte blockweise in einen Backupcontainer gespeichert. Das nächste Vollbackup wurde in den selben Container hineingeschrieben. Da sich meist nur wenige Dateien ändern, aber die meisten gleich bleiben, wurden für die gleich gebliebenen Blöcke nur Verweise angelegt.

Das funktioniert so gut, dass nachfolgende Backups nur ganz wenig zusätzlichen Speicherplatz brauchen, obwohl du jedesmal ein Vollbackup machst und auch auf jedes Backup wahlfrei zurückgreifen kannst. Oder speichere mehrere verschiedene Windowsrechner in den gleichen Container. Der erste wird auf vielleicht 50% komprimiert, die anderen aber auf 1% bis 5%.

Da es das für mein damaliges OS/2 nicht gab, habe ich angefangen, das nachzuprogrammieren (allerdings filebasiert und nicht sektorbasiert).

Ich verwalte meine Bot-Sourcen mit einer Linuxversion davon - momentan 670 Vollbackups mit insgesamt 340GB Platzbedarf in einem Container, der nur 853MB benötigt. Und ich kann auf jede einzelne Datei dieser 340GB direkt zugreifen.

Ausschnitt:
 

NDBList V0.7.9w0: startup at Thu Jan 16 11:30:39 2020
Using zlib-1.2.3 and source parts of zip-2.3 and unzip-5.50

Chapter List:
  No              Date  Files       Size     Packed Ratio  Name                
----  ----------------  -----  ---------  --------- -----  --------------------
[...]
 640  2019-04-28 15:08   4514  624471184     306672  100%  kurz vor Freigabe 0.8.0
 641  2019-04-28 15:31   4514  624470827     252398  100%  Freigabe 0.8.0      
 642  2019-04-29 23:20   4494  625350754     546849 99.9%  Anfang DCAScalper   
 643  2019-05-08 02:22   4503  626312771     576962 99.9%  Updates Rebal       
 644  2019-05-08 20:39   4505  626314248     262421  100%  Rebal vor Umbau     
 645  2019-05-08 22:59   4507  626550326     478298 99.9%  Zwischenstand Rebal
 646  2019-05-09 20:45   4500  619157242     296644  100%  Zwischenstand Rebal
 647  2019-05-10 09:37   4501  619175185     294350  100%  Debugging Rebal     
 648  2019-05-10 22:01   4503  621036970     485602 99.9%  Strat New changed   
 649  2019-05-11 01:25   4503  621069813     335195 99.9%  Zwischenstand New   
 650  2019-05-11 23:35   4504  621074348     278824  100%  Zwischenstand New   
 651  2019-05-13 11:21   4504  621072852     317233 99.9%  Wriggle Check for MA3
 652  2019-05-15 19:39   4505  624377285     701522 99.9%  before changing SL function
 653  2019-05-15 22:02   4506  625274454     415938 99.9%  double SL (Tharp method)
 654  2019-05-16 09:57   4506  625419516     883084 99.9%  polish double SL    
 655  2019-05-16 10:14   4506  625418968     259058  100%  double SL on both testbots
 656  2019-05-21 13:51   4507  625609514    1428732 99.8%  try new at ma3      
 657  2019-05-21 22:15   4508  627449072     482565 99.9%  Umbau lrexchange    
 658  2019-05-23 10:56   4508  627501379     411557 99.9%  vor Position Sizing
 659  2019-05-25 10:08   4511  627552722     352920 99.9%  Test mit Parabelscheitel
 660  2019-05-28 22:51   4518  630180347     723138 99.9%  Anfang DualMomentum
 661  2019-05-30 23:04   4521  630457395     511728 99.9%  added covariance to rebal
 662  2019-06-01 22:22   4520  629086030     285758  100%  updated rebal       
 663  2019-06-08 14:04   4526  629234268     554442 99.9%  dualm �berarbeitet  
 664  2019-06-10 20:08   4528  630641116     436574 99.9%  Fehler in Rebal behoben
 665  2019-06-11 17:03   4622  633158345     471684 99.9%  Fehler in Rebal behoben
 666  2019-06-30 17:43   4628  634941543    1047159 99.8%  Zwischenstand       
 667  2019-09-04 11:39   4640  634236225     971037 99.8%  vor Umbau von ma3   
 668  2019-09-06 19:57   4637  631084413     338631 99.9%  ma3 vereinfacht     
 669  2020-01-05 23:31   4651  647154611    1421300 99.8%  lrpairs.py: setfullbacktestpric
----  ----------------  -----  ---------  --------- -----  --------------------
                                 340.50G    853.37M   99%  670 chapters        

NDBList: finished at Thu Jan 16 11:30:40 2020