Denn irgendwie dauert das Scannen immer noch viel zu lange 😃 Das muss doch schneller gehen.

high5: aber wieso sollte ein weiteres modul gainz bringen? irgendwie check ichs ned.

xmpp-bridge
high5: aber wieso sollte ein weiteres modul gainz bringen? irgendwie check ichs ned.

Im Moment scannt die Wallet alles einzelnIch finde [Das neue Ding] sollte alles scannenWenn man Postgres etc. nutzt kann man auf jahrzehntelange Erfahrung mit Parallelisierung beim Lesen etc zurückgreifen. Ich denke das könnte schon Gainz bringen

Und so ein Postgres-Modul ist ziemlich nah "am Metall".Und Postgres kann auch super flexible Arrays und so

Irgendwie ist die Interaktion zwischen Wallet und Daemon imho ziemlich "teuer" im Moment

high5: okay jetzt habe ich es verstanden

Als erstes Beispiel fällt mir zB ein: Warum muss jede Tx überhaupt einzeln gescannt werden?Idee: [Das neue Ding] hat erst einmal eine "lineare" Liste/Tabelle an Outputs. Auf diesen können die ECC-Operationen doch viel schneller ausgeführt werden als wenn man jede Tx einzeln angucktDer erste Schritt bei so einem Projekt wäre also ein View-Only-Wallet zu ermöglichen. Da würde man schon sehen ob sich das mit Postgres lohntVielleicht fange ich damit mal an

John
Du musst für jede einzelne Transaktion die Stealth Adresse berechnen. Wenn die von dir berechnete Adresse der in der Transaktion entspricht gehört der Output dir und kann decrypted werden.

Exactly. Und ich glaube das geht wesentlich schneller wenn man die Outputs i.e. Stealthadressen schon "linear" zur Hand hatDann macht man einfach ratatatatata statt jede Tx/jeden Block einzeln anzugucken

50667: + ratatatatata

John
hm

da ratterst du einfach die Stealthadressen durchRatatatata

xmpp-bridge
50667: + ratatatatata
So ungefähr wie hier https://twitter.com/glurmgler/status/[email protected]
Max
da ratterst du einfach die Stealthadressen durchRatatatata

Aber zum Berechnen brauchst du doch noch mehr Transaktionsdaten.Und das was so "lange" dauert ist ja nicht das Abfragen der TX sondern das Berechnen und vergleichen der Steal Adressen

John
Aber zum Berechnen brauchst du doch noch mehr Transaktionsdaten.Und das was so "lange" dauert ist ja nicht das Abfragen der TX sondern das Berechnen und vergleichen der Steal Adressen

Das sind letztlich empirische FragenMeine Idee:"light wallet" sendet Secret View Key an (trusted) [Das neue Ding], dieses rattert das alles durch; die light wallet encrypted dann nur genau das, was [Das neue Ding] zurückgibt an "besessenen" OutputsBin da schon optimistisch

John
Aber zum Berechnen brauchst du doch noch mehr Transaktionsdaten.Und das was so "lange" dauert ist ja nicht das Abfragen der TX sondern das Berechnen und vergleichen der Steal Adressen

Übrigens dachte ich letzteres auch früherDann habe ich ECC selbst mal genutzt und damit ein bisschen in Python rumprogrammiertEs ist rattenschnellRattert nur so durch

Wir können echt stolz darauf sein, dass Daniel Bernstein ein deutscher Staatsbürger ist. Ein wahrer Held der Freiheit!https://safecurves.cr.yp.to/https://en.wikipedia.org/wiki/Daniel_J._Bernstein

high5: das war vermutlich auch gethreaded?

xmpp-bridge
high5: das war vermutlich auch gethreaded?

meinst du meine Experimente? Nee neeECC rattert einfach

John
Also willst du das generieren der Stealth Adressen einfach auslagern, damit der User weniger Rechenleistung benötigt?

Hmm ja also ich möchte im Prinzip das CheckenView Key + Adresse == Stealthadresse + ECCauslagernUnd zwar vor allem indem ich die Stealthadressen schon effizient speichere und vorhalte, sodass ich die einfach durchrattern kann wenn ein User daher kommt

Max
Hmm ja also ich möchte im Prinzip das CheckenView Key + Adresse == Stealthadresse + ECCauslagernUnd zwar vor allem indem ich die Stealthadressen schon effizient speichere und vorhalte, sodass ich die einfach durchrattern kann wenn ein User daher kommt

Für jeden Output auf der Blockchain musst du Hs(r*PV | i)*G + PS berechnen. Wobei Hs = Keccak-256 mod p, r = Public TX Key, PV = Private ViewKey, i = Output Intex, G ist der Base Point der Elliptischen Kurve und PS ist der Private Spend KeyAus dieser Berechnung ergibt sich die Stealth Adresse. Und das ist das rechenintensive.

Nicht die lmdb Abfrage

Komisch. Kp ob die Rechnung richtig ist... Hatte ich mir aber so notiert

Und beim ratatatata musst du ja bei jedem einzelnen Eintrag die Berechnung durchführen

John
Komisch. Kp ob die Rechnung richtig ist... Hatte ich mir aber so notiert

Hast sicher recht. Steht ja auch in Mastering Monero so oder so ähnlich drinAber ich denke eben dass es relativ effizient ist und dass das Bottleneck weniger bei dieser Berechnung liegt

Schau dir mal die Auslastung der CPU bei syncen an Das sagt alles

initial sync ist tatsächlich rechenintensiv, deswegen sollte man beim erstellen des wallets zum seed zusätzlich auch die aktuelle blockhöhe aufschreiben

scannen aller blöcke der letzten 5 jahre ist unnötiger overhead, wenn man das wallet vor einem monat erstellt hat