Cookies statt Coins^^

Gute Hinweis 👍 Ja, der neue Raspberry Pi 5 soll ja nun auch M.2-SSD unterstützen, jedoch hat er weiterhin nur 8 GB RAM, d.h. die SSD wird zusätzlich mit Swapping beschäftigt sein. Aktuell bin ich noch auf meinen beiden Raspi Pi 4 unterwegs, wobei das eher schlecht als Recht läuft, habe viele Ausfälle (vermutlich aufgrund langsamer USB-3.0 Festplatte mit zusätzlich einige GB Swapping). Hatte aber immer noch keine Zeit, mich weiter damit zu beschäftigen. Erst müsste ich noch meine Auszahladresse hinterlegen, erst wenn das funktioniert, dann kaufe ich mir mit dem Erlös neue Hardware 😄

Konnte mittlerweile mittels Pruning meine Geth-Blockchain von 1,1 TB auf 665 GB fast halbieren. Habe mich dabei an folgender Anleitung orientiert: https://geth.ethereum.org/docs/fundamentals/pruning Der Vorgang verlief relativ unkompliziert. Trotzdem hier ein paar wichtige Tipps noch: Nutzt am Besten zu Beginn den tmux-Befehl, damit auch bei kurzen Verbindungsabbrüchen des Terminalfensters das Pruning nicht abgebrochen wird und die Session im Hintergrund weiterläuft Man darf erst mit dem Pruning beginnen, wenn Geth keinerlei Zugriff mehr auf die Dateien im Filesystem hat. Obwohl der Geth-Service beendet war, war auf der Festplatte zunächst noch eine Aktivität festzustellen (für ca 2 bis 3 Minuten). Also entweder zur Sicherheit etwas warten, oder mit dem iostat-Befehl prüfen, ob das Filesystem mit den Geth-Daten noch in Verwendung ist. Das Pruning verläuft in drei Phasen ("Iterating state snapshot" -> "Prune state data" -> "Compacting database"). Bei einer Größe von 1,1 TB sollte der gesamte Vorgang eigentlich in 5 Stunden durch sein (habe ich im Geth-Discord-Kanal gelesen). Nur auf meinem Raspberry Pi hat es aufgrund des langsamen USB-Festplattenanschlusses insgesamt 16 Stunden gedauert. Da es dann in der Nacht fertig wurde und ich im Anschluss auch noch eine Sicherung des Geth-Ordners machte, war mein Validator somit mal wieder für 24 Stunden offline. Das sind die ärgerlichen Nachteile bei einem langsamen Raspberry Pi^^ Hier meine eingetippten Shell-Befehle mit entsprechenden Kommentaren zur Erläuterung: # 1.) TMUX starten (analog zu Screen) # tmux enables pruning to keep running even if you disconnect # # Neue Session beginnen: tmux new -s GethPruneSession # # Session später ggfs wiederherstellen: #tmux attach -t GethPruneSession # 2.) Prozess beenden: sudo systemctl stop Geth.service # 3.) Warten, bis keine Zugriff mehr auf Festplatte besteht (ca. 2-3 Minuten nach Beenden von Geth) iostat -d -x -m 10 -p sda # 4.) Prune: # Dauer auf meinem Raspi: 16 Stunden; Größe: 1,1 GB -> Eigentlich sollte es bei 1,1 GB nur 5h dauern # 1. Iterating state snapshot: 3h # 2. Prune state data: 5h # 3. Compacting database: 6h # geth --datadir /mnt/ssd/EthMerge/.ExecutionClientGeth snapshot prune-state # 5.) Backup vom Geth-Ordner erstellen: # scp -r <quelle> <ziel> # scp -r /mnt/ssd/EthMerge/.ExecutionClientGeth /mnt/ssd/EthMerge/Backup/.ExecutionClientGeth_Backup # 5.) Logdatei ins Archiv verschieben (+ umbenennen) # 6.) Prozess starten: sudo systemctl start Geth.service PS: Jetzt, knapp 2 Wochen nach dem Pruning ist das Geth-Verzeichnis schon wieder um 85 GB stark angewachsen (+6,5 GB pro Tag). Das nächste Pruning steht somit wieder in 2 bis 3 Monaten an....

Vielen Dank für den Hinweis, das hatte ich noch gar nicht im Blick. Auch ich habe noch eine 0x00 Adresse ._. Das ist sehr ärgerlich, dass wir da eine solche sehr riskante Migration durchführen müssen. Die in deinem Link verlinkte Anleitung finde ich ja mehr als kompliziert beschrieben. Aber ich bin zuversichtlich, dass da noch eine neue Anleitung kommt. Beim Durchsuchen des Prysm-Discord-Kanals wird eine solche Anleitung in Aussicht gestellt ( https://discord.com/channels/476244492043812875/476588476393848832/1064439606898069504 ). Aktuell kann man diese Änderung sowieso noch gar nicht durchführen, wir müssen erst noch bis März auf das Shanghai/Capella-Upgrade warten...

Seit den letzten zwei Monaten ist mein Geth-Verzeichnis um durchschnittlich 5 GB täglich angewachsen. Bei deinem Geth gibt es einen Zuwachs von 3 GB pro Tag. In dem gestern von mir geposteten Link ( https://geth.ethereum.org/docs/fundamentals/pruning ) wird von einem Zuwachs von 14 GB pro Woche ausgegangen, also 2 GB pro Tag. Sobald die Festplatte zu 80% voll ist, sollte man demnach das "Prunen" durchführen, um Geth wieder auf die ursprünglichen 650 GB zu verkleinern. Wenn man alle drei Aussagen kombiniert, dann kann man mit einem Zuwachs von 2 bis maximal 5 GB pro Tag rechnen. In voraussichtlich 2 bis 3 Monaten wird meine Festplatte dann zu 80% voll sein und ich müssten das Prunen durchführen. Würde mich dann wieder melden, wenn ich erste Erfahrungen damit gesammelt habe... Vermutung: Mit regelmäßigen Prunen von Geth (und bei Bedarf mit einem Neustart einer leeren Beacon-Chain von einem Checkpoint) sollte dauerhaft eine 2 TB-Festplatte ausreichend sein. Zumindest nach aktuellem Stand. Wer weiß, welche Speicheranforderungen die zukünftigen Releases mit sich bringen.

Hallo zusammen, es wird auch mal wieder Zeit für ein Update von meiner Seite.. 🙂 1. Aktuelles Setup (2x Raspi) Ich habe es nun auch auf zwei Raspberry Pi aufgeteilt. Geth läuft auf dem 8 GB Raspi mit angeschlossener NVMe (SK hynix Gold P31). Und Prysm läuf auf dem 4 GB Raspi mit angeschlossener SATA-Festplatte (Samsung SSD 870 EVO). Beide Festplatten haben jeweils 2 TB. Es läuft nicht perfekt, aber es läuft gut genug. Einmal im Monat stürzt der Prysm-Raspi ab, dann muss ich den manuell neustarten. Vermutlich bräuchte ich mehr Arbeitsspeicher, möchte aber so lange es geht beim Raspberry Pi bleiben und die 8-GB-Modelle sind ja schon seit Monaten ausverkauft oder nur zu überteuerten Preisen zu haben. (Außerdem hoffe ich darauf, dass mittelfristig mal ein neues Modell auf den Markt gebracht wird; hoffentlich mit NVMe-Anschluss 😉 2. Stromverbrauch (max 38 Watt bzw max 200€ pro Jahr) Bei Minimum 9 Volt und 2 Ampere verbraucht der Rock 5B mindestens 18 Watt. Die Empfehlung liegt jedoch bei einem 30-Watt-Netzteil ( https://wiki.radxa.com/Rock5/FAQs ). Das kommt dann auch in die Größenordnung, die meine zwei Raspis benötigen: Maximal erhalten diese durch das Netzteil jeweils 15 Watt (5 Volt bei 3 Ampere) und der eine mit der NVMe-Festplatte hat noch einen aktiven USB-Hub, der auch nochmal maximal 8,3 Watt zieht (3,3 Volt bei max 2,5 Ampere). Somit zieht mein System insgesamt maximal 38,3 Watt (vermutlich deutlich weniger, da es nicht immer auf Vollast läuft). Bei einem Strompreis von mittlerweile 60 Cent pro kWh sind das dann maximal 200€ Stromkosten im Jahr. Beim aktuellen Preis von ca 1.500 € pro ETH hat man diese jährlichen Stromkosten nach eineinhalb Monaten wieder herein gewirtschaftet (bei aktuell 0,09 eingenommene ETH pro Monat). 3. Festplatten Speicherverbrauch (2 TB noch ausreichend) Geth verbraucht bei mir 1,1 TB (Stand Februar 2023) und Prysm verbraucht aktuell 34 GB. Wer sich nun fragt, wieso Prysm bei mir so wenig benötigt: Die Snychronisation auf dem Raspi war sehr langsam, es dauerte mehre Tage um die Node neu zu synchronisieren. Nachdem nach einigen Abstürzen öfter mal die Datenbank korrupt war, habe ich herausgefunden, dass man nicht die komplette Historie benötigt: Man kann einfach die Synchronisation ab einem Checkpunkt starten. Das läuft bei mir nun sehr stabil. Dazu muss man folgende zwei Parameter in der Prysm-Beacon-Chain-Konfig (jaml-Datei) eintragen: # Sync from Checkpoint # Doku: https://eth-clients.github.io/checkpoint-sync-endpoints/ checkpoint-sync-url: https://sync-mainnet.beaconcha.in genesis-beacon-api-url: https://sync-mainnet.beaconcha.in Vor dem Start der der Beacon-Chain jedoch die "beaconchain.db" im Ordner "beaconchaindata" löschen (oder zur Sicherheit nur umbenennen) und schon beginnt die Beacon-Chain mit 0 GB ab dem letzten Checkpoint. Die vergangen Daten werden dabei nicht nachgeladen. So spart man sich u.U. auch etwas Speicher. Vor allem spart man sich bei einer korrupten Datenbank die lange Nachladezeit. Ein Backup meines Geth-Ordners von vor 2 Monaten belegte nur 830 GB Speicherplatz. Das macht einen Zuwachs von 300 GB in 2 Monaten. Das ist fast etwas viel habe ich beim Schreiben dieses Textes bemerkt. Das muss ich weiter beobachten. Bzw wie ich eben recherchiert habe, müsste man die Geth-Datenbank regelmäßig prunnen, um unnötigen Speicherplatz wieder freizugeben: https://geth.ethereum.org/docs/fundamentals/pruning . Das muss ich mir bei Gelegenheit mal näher anschauen.. 4. MEV Boost (noch) nicht aktiviert Den MEV Boost habe ich bei mir noch nicht aktiviert. Ein Proposal hat mein Validator verpasst, da er vermutlich zu langsam/ überlastet war. Evtl bringt der MEV Boost hier einen Vorteil, da hier einfach ein vorgefertigter Block genommen wird statt den Block selbst zu bauen. Der MEV Boost könnte daher auch einen Performancegewinn bei den Proposal bewirken (ist aber bislang nur eine Vermutung von mir, muss ich weiter beobachten). 5. Steuer (Liebhaberei statt Gewerbe) Zum Thema Steuern hat @skunk ein gute Antwort verfasst, auch ich werde es erst mal als Liebhaberei deklarieren, bis das Finanzamt etwas anderes entscheidet:

Vielen Dank für eure zahlreichen Tipps. Hatte mich heute schon nach entsprechend neuer Hardware umgesehen.. Interessant finde ich die Aussage von @satoshi21, wonach es doch klappen sollte: Du hast also keine NVMe-SSD, sondern eine SATA-SSD: Samsung 870 EVO: https://www.amazon.de/dp/B08PC5ZYB1/ Dazu den passenden StarTech-SATA-USB-Adapter: https://www.amazon.de/StarTech-com-Inch-SATA-Adapter-Cable/dp/B00XLAZODE Verwendest du als Validator auch die Software von Prysm? Oder vermutlich Nimbus? Denn habe heute auch auf Discord (Erigon-Server) erfahren, dass auf dem Raspberry Pi nur die Kombination von Geth mit Nimbus funktionieren soll: "the only combo that still works on RasPi4 is a Nimbus/Geth with reduced Geth cache, and a Samsung T5. T7 is too slow. Geth benefits from 1.11 for the state heal fixes." Bin also am überlegen, nach Nimbus zu wechseln.. Ich verwende eine ähnliche Geth-Version, sogar eine etwas aktuellere Version: 1.10.25-stable Wie startest du Geth, verwendest du noch spezielle Parameter? Ich starte es so: ExecStart=geth --mainnet --datadir /mnt/ssd/xxxx --authrpc.jwtsecret /mnt/ssd/xxxx --cache 4096 --syncmode snap --port "35555" Hatte mit dem Cache-Parameter experimentiert und Werte zwischen 8192 und 128 ausprobiert, aber auch alles ohne Besserung.

Hallo zusammen, noch ein neues Update meinerseits: Hab es bisher nicht geschafft, Geth auf dem Raspberry Pi zum Laufen zu bringen. D.h. mein Validator ist nun seit über einem Monat offline und ich mache fleißig Minus 😕 Ich habe verschiedene Dinge ausprobiert, die alle keine Besserung gebracht haben: - Eine neue SSD gekauft ("SK Hynix P31 Gold" -> die Top #1 auf der Liste der empfohlenen NVMe-SSDs, die ich mit langer Wartezeit extra aus den USA importiert hatte. Leider lief dadurch die Synchronisierung von Geth auch nicht schneller) - Einen aktiven USB-Hub gekauft, zuerst mit 2,0 Ampere, dann mit mit 2,5 Ampere. (Mindestens ein aktiver USB-Hub ist notwendig, sonst schaltet sich das System nach hoher IO-Last ab, aber ich denke, es macht keinen Unterschied ob nun 2,0 oder 2,5 Ampere, da die Festplatte am USB-Anschluss eh nicht die volle Leistung entfalten kann) - Ein Firmeware-Update des Raspberry Pi durchgeführt und das Betriebssystem gewechselt. Bisher hatte ich "Raspberry Pi OS 64-bit (Bullseye)" auf dem aktuellsten Stand, nun habe ich "Ubuntu Server 64-Bit". All das hatte aber keinen Einfluss auf die Sync-Speed von Geth. - Jedoch war dieses neue Betriebssystem auch notwendig, um den nächsten Schritt auszuprobieren: Statt Geth versuchte ich dann Erigon als Execution-Client zu verwenden (Denn mit dem Raspberry Pi OS läuft Erigon beim Starten auf einem Memory-Fehler, was mit Ubuntu nicht passiert). Nun lässt sich Erigon ohne Fehler starten. Leider läuft dort die Synchronisierung sehr langsam, nach meiner Hochrechnung brauche ich noch 3 Wochen, obwohl es bereits seit einer Woche läuft. Und auch dann habe ich keine Garantie, dass es läuft. Ich überlege mir daher nun, eine neue Hardware zu kaufen. Zumindest als Überbrückung, bis ich es evtl. doch noch auf einem Raspberry Pi zum Laufen bekomme. Habe mir überlegt, dass ich folgendes brauche: - 16 GB RAM (oder mehr) - NVMe-Steckplatz (mindestens einer) Bei der Suche nach einem passenden PC bin ich auf folgenden Intel NUC PC für 650€ gestoßen, der meine Mindestvoraussetzung erfüllt: https://www.amazon.de/-/en/gp/product/B09M7LFCTQ Der müsste doch eigentlich passen, vor allem auch Preis-Leisungs-Verhältnis? Oder könnt ihr Alternativen empfehlen? @skunk: Du meintest ja, du hattest auch so 400 bis 600 € für dein Setup bezahlt. Aber da müsste ich mir die Einzelteile besorgen und selbst alles zusammen bauen, dafür habe ich aktuell wenig Zeit und keine Nerven dafür.

Kurzes Update meinerseits: Mein Execution-Client Geth läuft leider immer noch nicht. Habe aber nun die Ursache gefunden: Habe mir wohl die falsche Festplatte gekauft, denn nicht alle M.2-SSDs sind gut genug. Für alle, die auch noch mit dem Raspberry Pi ihre Probleme haben: Auf dieser Seite sind Festplatten aufgelistet, bei denen die Synchronisation funktionieren muss: https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038 M.2 NVMe: SK Hynix P31 Gold Samsung 970 EVO Plus 2TB (the 1TB model is slower but should still work) WD Red SN700 WD Black SN750 (but not SN750 SE) HP EX950 Mushkin Pilot-E Mushkin Redline Vortex AData XPG Gammix S50 Lite Und dort sind auch Festplatten aufgelistet, die einfach (warum auch immer) zu langsam sind, und genau eine von dieser "The Bad"-Liste habe ich mir zugelegt, um Geld zu sparen und da der Raspberry Pi meiner Meinung nach eh nicht die voll Leistung der Festplatte ausnutzen würde. Aber das war wohl eine falsche Annahme.. 😄🙈 Habe mir nun heute auf Amazon die "Samsung 970 EVO Plus 2TB" bestellt. Die wird mir bis morgen geliefert, dann muss ich schnell die Daten rüber kopieren und die Festplatten austauschen und dann erneut versuchen, Geth zu synchronisieren. Wer keine M.2-SSD, sondern ne SATA-SSD verwendet, der sollte sich die "Samsung Portable T5 SSDs" kaufen mit dem Adapter "Startech SATA to USB Cable", denn damit sollte es auf dem Raspberry Pi definitiv auch funktionieren: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/user-guide/storage.html#raspberry-pi-4 Leider werde ich dann wohl nicht rechtzeitig bis zum Merge fertig sein. Schade, ich hoffe mal, die Verluste halten sich dann in Grenzen...

Hier noch ein interessanter Link eines Steuerberaters zur Besteuerung des Staking, speziell hier bei Ethereum: https://www.winheller.com/bankrecht-finanzrecht/bitcointrading/bitcoinundsteuer/besteuerung-von-staking/ethereum-staking.html Demnach handelt es sich hier nicht um ein Gewerbe. Auszüge aus obigem Link: 1. Einordnung als gewerbliche Einkünfte [fraglich] [...] Die Gewerblichkeit ist allerdings an hohe Voraussetzungen geknüpft. Insbesondere muss hierfür die Selbstständigkeit gegeben sein, was beim Staking in der Regel abzulehnen ist. Investoren, die ihre ETH dem Netzwerk zur Verfügung stellen, verlieren die Verfügungsgewalt über ihre Coins. Ebenfalls erfolgt die Auswahl der zur Verifizierung berufenen Teilnehmer und damit auch, wer überhaupt Rewards erhält, nach dem Zufallsprinzip. Da der Teilnehmer deshalb über keinerlei Kontrolle bezüglich der Einkünfte aus dem Staking verfügt, spricht dies gegen den Begriff der Selbstständigkeit und mithin gegen eine Einordnung als gewerbliche Einkünfte. [...] Eine finale höchstrichterliche Entscheidung zu dieser Thematik steht allerdings nach wie vor aus. 2. Einordnung als Einkünfte aus sonstigen Leistungen Plausibler erscheint es, die Staking-Belohnungen als Einkünfte aus sonstigen Leistungen [...] besteuern. Der Anwendungsbereich der Norm ist sehr weit gefasst, weshalb grundsätzlich jedes Tun, Dulden oder Unterlassen eine Besteuerung zur Folge hat, sofern dadurch eine Gegenleistung ausgelöst wird. Dies ist bei einer Teilnahme am Staking zu bejahen. [...] Besonderheiten bei der Besteuerung von Ethereum-Staking Voraussetzung für eine Besteuerung ist allerdings immer, dass dem Staker die Rewards auch tatsächlich zugeflossen sind [...]. Da die Ethereum-Staker zum gegenwärtigen Zeitpunkt allerdings noch nicht auf ihre Rewards zugreifen können, weil diese noch bis zum endgültigen Abschluss des Ethereum-Updates 2.0 gesperrt sind, liegt für diese Zeitspanne noch keine wirtschaftliche Verfügungsmacht und damit auch kein Zufluss vor. Eine Besteuerung wäre demnach erst nach Fertigstellung des Ethereum-2.0-Updatesmöglich. Daher werde ich nächstes Jahr in der Steuererklärung die Staking-Erträge einfach unter der Anlage "SO" im Abschnitt "6-Leistungen" eintragen (sofern der Merge bei mir erfolgreich verlauft). Die Frage bleibt nur, wie ich dann die bisher erzeugten ETH versteuere, über die ich dann plötzlich eine Verfügungsgewalt bekomme. Aber das überlege ich mir dann im nächsten Jahr..

Nein, die Synchronisation von Geth läuft leider immer noch, obwohl die schon seit gestern Vormittag zu 99% fertig ist. Aber die letzten Blöcke erreicht er nie, er springt dann immer wieder ein paar Blöcke zurück und erreicht scheinbar nie das Ende der Blockchain. Die Aktivität von Geth hat mittlerweile spürbar nachgelassen, die durchschnittliche CPU-Auslastung vom Gesamtsystem liegt nun bei knapp unter 50% (mit weiterhin sehr kurzen Lastspitzen bis zu 99%). Auch ändert sich seit gestern die Größe im Geth-Ordner "chaindata" nicht mehr (hat nun 576 GB erreicht). D.h. der Download der Blockchain im großen Stil ist nun scheinbar beendet. Die Logausgabe hat sich auch geändert. Statt eines Download-Status erscheint bei mir im Logging nun hauptsächlich nur noch folgendes: INFO [09-09|15:47:08.277] State heal in progress accounts=746,768@37.43MiB slots=918,520@71.04MiB codes=1372@10.96MiB nodes=7,091,994@2.12GiB pending=1 INFO [09-09|15:47:09.676] Imported new block headers count=1 elapsed=11.952ms number=15,503,071 hash=855e03..57b531 Ich weiß auch nicht, was das zu bedeuten hat. Aber scheinbar scheint das normal zu sein, wenn du dasselbe Problem hast. Hatte diesbezüglich gestern auch schon mal gegoogelt, und scheinbar muss man einfach nur lange genug warten: "I have synchronizing geth node running on a Raspberry Pi Model B (8 GB RAM) with an external 1TB SSD attached via USB-3 running Arch Linux. I've been "synchronizing" for about 5 days or so now. My "currentBlock" is always fluctuating between 50-100 blocks away from "highestBlock" count." [...][2 Tage später:] "The solution was simply more time. The resources at my disposal claimed that an RPi would be able to sync in a matter of 2-3 days with a speedy internet connection. For me, it took about a week." ( https://ethereum.stackexchange.com/questions/126478/geth-node-taking-way-too-long-to-sync ) D.h. normalerweise dauert die Synchronisation von Geth wohl zwei bis drei Tage, auf dem Raspberry Pi dauert es aber eine Woche. Durch diesen Hinweis beobachte ich nun seit gestern, wie viele Blöcke noch benötigt werden, bis Geth vollständig synchronisiert ist. Dazu kann man "geth attach" aufrufen (unter Angabe des Datenverzeichnisses) und den nachfolgenden Befehl absetzen: #Get Sync-Status: ~/go-ethereum/build/bin/geth attach --datadir /mnt/ssd/ethereum/Geth # To see the remaining blocks you could do: eth.syncing.highestBlock - eth.syncing.currentBlock Diesen Befehl führe ich nun in unregelmäßigen Abständen aus und ich merke schon, wie die Differenz zum letzten Block langsam geringer wird. Gestern noch sprang die Differenz zwischen 60 Blöcken und bis zu 2.000 Blöcken, heute pendelt die Differenz "nur" noch zwischen 60 und ca. 150 Blöcken. --------------------------------------------- Interessant, aber das erklärt zumindest, dass meine alte Festplatte auch ganz ohne Anpassungen gelaufen ist. Wie weiter oben geschrieben denke ich, dass du auch eine "normale" SSD-Festplatte nehmen kannst, es muss keine M.2 sein, denn zumindest bei mir ist diese nicht wesentlich schneller. Aber führe doch auch mal bei Gelegenheit diesen Geschwindigkeitstest durch, würde mich mal interessieren ob es auf deinem Raspberry Pi dann evtl etwas schneller läuft: --------------------------------------------- Mit dem MEV-Boost habe ich mich noch nicht beschäftigt. Ich hätte erst mal abgewartet, ob die Standard-Konfiguration zuverlässig läuft. Bei Gelegenheit wollte ich mir das aber auch mal anschauen: https://github.com/remyroy/ethstaker/blob/main/prepare-for-the-merge.md#choosing-and-configuring-an-mev-solution --------------------------------------------- Ja das stimmt, man spürt an der Regaldecke über dem Raspberry Pi schon eine erhöhte Temperatur, ein bischen mehr Freiraum wäre nicht schlecht. Im Regal darunter befindet sich der Testnet-Raspberry-Pi. Da wäre es wohl besser, wenn ich aus beiden kleinen Regaleinlagen ein einzelnes großes Regalfach mache, welches sich dann beide teilen müssen. Noch bessere wäre es natürlich, wenn die noch mehr Freiraum hätten, aber das klappt in der aktuellen kleinen Mietswohung nicht (was aber hoffentlich nicht immer so bleibt, wenn man mit dem Validator endlich auch mal echtes Geld verdiehen könnte^^). Wäre interessant, wenn du zur Stromversorgung was finden könntest. Nicht, dass es langfristig doch zu Problemen kommt. Ich wollte auch schon zur Sicherheit mittels "smartctl" die Festplattentemperatur auslesen. Aber leider unterstützt das meine Festplatte nicht so gut, bei der Temperartur wird nur 0 Grad angezeigt: sudo smartctl --all /dev/sda -d scsi #Ausgabe: smartctl 6.6 2017-11-05 r4594 [aarch64-linux-5.10.5-v8+] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: ANYOYO Product: EC-SP02 Revision: 1.00 Compliance: SPC-4 User Capacity: 2.000.398.934.016 bytes [2,00 TB] Logical block size: 512 bytes LU is fully provisioned Rotation Rate: Solid State Device Logical Unit id: 0x3001237923792379 Serial number: 0000000000000000 Device type: disk Local Time is: Fri Sep 9 16:58:24 2022 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Disabled or Not Supported === START OF READ SMART DATA SECTION === SMART Health Status: OK Current Drive Temperature: 0 C Drive Trip Temperature: 0 C Error Counter logging not supported Device does not support Self Test logging

Bei diesen Punkten stimme ich mir dir überein. Ich habe erst vor Kurzem meiner Steuererklärung für 2021 fertig gemacht, aber habe da die virtuellen Staking-Eträge auch mit dieser Überlegung nicht mit angegeben. Erst, wenn ich vollständig über die erwirtschafteten ETH verfügen kann, erst dann werde ich diese in der Steuer angeben. Bis dahin ist auch ein Totalverlust möglich. Die Frage ist nur, wie ich dann bisher gewonnen ETH nachträglich versteuere, falls das mit der Auszahlung mal klappen sollte. Das muss ich mir noch bis nächstes Jahr überlegen. Das mit der gewerblichen Tätigkeit muss ich auch noch genauer recherchieren, falls das mit dem Merge und der Auszahlung der Staking-Erträge funktioniert. Fände das aber übertrieben, dazu ein Gewerbe anzumelden. Habe auch bisher nichts in die Richtung aus anderen Quellen gehört. Lass uns das Thema im nächsten Jahr nochmal aufgreifen...

Hallo zusammen, in den letzten Tagen ist bei meinem Validator auf dem Raspberry Pi viel passiert und ich kann folgende positive Nachricht verkünden: time="2022-09-07 08:38:19" level=info msg="Connected to new endpoint: http://localhost:8551" prefix=powchain time="2022-09-07 08:38:29" level=info msg="Ready for The Merge" latestDifficulty=17179869184 network=mainnet prefix=powchain terminalDifficulty=58750000000000000000000 Mein System (Validator + Beacon-Chain + Execution-Client) ist nun auch endlich Ready-for-the-Merge!! 🙂 Mit zwei kleinen Wermutstropfen: Erstens: Mein Execution-Client (Geth) ist noch nicht vollständig synchronisiert, was aber hoffentlich nur noch eine Frage der Zeit ist: time="2022-09-07 08:40:49" level=error msg="Unable to process past deposit contract logs, perhaps your execution client is not fully synced" error="no contract code at given address" prefix=powchain Obwohl ich mit Geth im Goerli-Testnet auch nach zwei Tagen Laufzeit keine passenden Peers zum Synchronisieren gefunden hatte, hat es beim Wechsel ins Mainnet problemlos geklappt. Seitdem synchronisiert Geth fleißig und laut dem Log von Geth sollte die Synchronisation in weniger als 20 Stunden komplett abgeschlossen sein. Und das zweite noch offene Thema: Ich habe nun nur noch den Raspberry Pi aus dem Mainnet am laufen. Der für das Testnet ist aktuelle nicht lauffähig (Geth synchronisiert nicht). Darum werden ich mich in den nächsten Tagen noch kümmern. Da kann ich dann in Ruhe auch noch mit einem anderen Execution-Client experimentieren.. Bis hierher war es aber noch ein anstrengender Weg: Denn zunächst musste ich noch im laufenden Betrieb die Festplatte vom Mainnet-Raspberry-Pi austauschen und die 1 TB SSD durch eine 2 TB SSD ersetzen. Vielen Dank an der Stelle an @Cricktor für deinen Hinweis: Da ich auf die Schnelle für Windows kein Programm gefunden hatte, um eine Linux-Partition zu kopieren, und ich keinen anderen Linux-PCs hatte als die beiden Raspberry Pi, musste ich die alte und die neue Festplatte an jeweils einen von beiden Raspis anhängen und diese dann mittels Linux-Kopier-Befehl über das Netzwerk rüber kopieren: scp -r pi@192.168.0.13:/mnt/ssdMainnetOld/ethereum/ /mnt/ssd/ethereum/ Um die Gefahr eines unbeabsichtigten Slashings zu verhindern (wenn versehentlich zwei Validatoren mit denselben Daten aktiv sind), musste ich zunächst die Validator-Prozesse auf beiden Systemen deaktivieren und zusätzlich habe ich die eine Festplatte unter einem anderen Verzeichnis gemounted. Hat soweit ganz gut geklappt, denn mein Validator läuft immer noch ohne Slashing, obwohl das schon ein kleine Zitterpartie war 😄. Zusätzlich hat mir das eine Downtime von einem halben Tag für meinen Validator gekostet. Nun lauft der Mainnet-Raspberry-Pi seit einigen Tagen sehr stabil mit seiner 2GB M.2-SSD. Aber bei einem genauen Vergleich bringt mir die M.2-SSD im Raspberry Pi keinen großen Performance-Gewinn im Vergleich zu einer schnellen Standard-SSD: read-/write-Speed M.2-SSD: 386/ 299 MB/s Mit meiner alten Festplatte hatte ich folgende Werte (vgl meinen Beitrag vom 27.11.2020 auf Seite 2): read-/write-Speed SSD: 353/ 231 MB/s Zusätzlich habe ich auf dem Raspberry Pi nach folgender Anleitung die Konfiguration angepasst, damit die USB-Ports die maximal Stromleistung erhalten (1,2 Ampere): https://www.elektronik-kompendium.de/sites/raspberry-pi/2206111.htm sudo vi /boot/config.txt #Hinzufügen: safe_mode_gpio=4 max_usb_current=1 program_usb_timeout=1 Und obwohl die neue Festplatte laut Aufdruck 1,8 Ampere benötigt, läuft das System seit Tagen stabil, und das auch mit Dauer-Schreibzugriff auf die Festplatte. Aber die bisherige Festplatte, die zuvor Jahre stabil lief, brauchte laut Aufdruck auch 1,7 Ampere. So genau hatte ich da in der Vergangenheit nicht drauf geschaut, aber scheinbar ist das die maximale Stromstärke, die für die maximale Geschwindigkeit benötigt wird, die aber eh nicht über den langsamen USB-Port erreicht wird, anders kann ich mir das nicht erklären. Nun läuft das System auf dem Raspbbery Pi aber sehr stabil. Ich hatte zunächst befürchtet, dass ich die komplette Hardware tauschen müsste, dass der Raspberry Pi nicht leistungsstark genug wäre. Dem ist aber anscheinend doch nicht so. Trotzdem danke für eure Tipps, die hatte ich mir als Backup überlegt, falls ich es gar nicht zum Laufen kriegen würde. Aktuell während der Synchronisierungsphase benötigt Geth sehr viel CPU, wodurch der Raspberry Pi durchschnittlich zu 70% ausgelastet ist. Teilweise ist er auch über mehrere Minuten zu fast 100% ausgelastet. (Ich hatte mir dazu ein Skript geschrieben, um die CPU-Auslastung zu protokollieren). Damit trotzdem der Validator stabil läuft, läuft der Validator-Prozess mit der höchsten Priorität, die Beacon-Chain mit der zweit höchsten Priorität und Geth lauft aktuell noch mit der Standard-Priorität, aber werde den Execution-Client später mal mit der dritthöchsten Prio laufen lassen. Bei der hohen Auslastung könnte man befürchten, dass der Raspberry zu heiß wird. Aber die passive Kühlung funktioniert sehr gut. Auch hier protokolliere ich alle zwei Minuten die CPU-Temperatur. Diese liegt bei durchschnittlich 58°C und maximal 66°C, was für diese Dauerbelastung sehr gut ist, wenn man bedenkt dass der Raspberry Pi erst ab 80°C runterschaltet. Hatte mir dazu bereits vor zwei Jahren ein eigenes Kupfer-Gehäuse mit "Kühlturm" nach folgender Anleitung gebaut: https://progpi.de/raspi4-passiv-gekuehlt/ So sieht nun mittlerweile mein Mainnet-Raspberry-Pi aus: Jetzt kann ich mich in Ruhe zurücklehnen, und warten, bis morgen oder übermorgen Geth vollständig synchronisiert hat. Dann bis zum 15 September warten, bis der Merge vollständig durchgeführt wurde, und dann habe ich hoffentlich für die nächsten Jahre wieder meine Ruhe und kann mich auch wichtiger Dinge konzentrieren^^ 😄 Nagut, und nebenbei muss ich mein Testnet mit einer Alternative zu Geht auf dem Raspberry Pi zum laufen bringen, aber das hat nun etwas Zeit..

Und bei dieser Übersicht ist mein System noch gar nicht mit dabei, da ich meinen Validator bislang nur über Infura betrieben habe, was hier gar nicht auftaucht.. Ich habe mich noch ziemlich eingelesen in die Materie. Grundsätzlich ist es gar nicht so kompliziert: Zusätzlich zum bereits bestehenden Beacon-Node und zum Validator braucht man nur noch einen Execution-Client. Dazu gibt es ja mehrere zur Auswahl. Danach kommen noch ein paar kleinere Konfigurationen, was ja alles sehr ausführlich auf diversen Seiten beschrieben ist, z.B. https://github.com/remyroy/ethstaker/blob/main/prepare-for-the-merge.md Was mir jedoch noch Sorgen macht ist die Installation des Execution-Clients auf meinem Raspberry Pi. Ich habe mich aktuell für Geth entschieden, da dieser auf dem Rasperry Pi am besten laufen sollte: "Ethereum on ARM supports 4 Eth1 clients: Geth, Nethermind, Openethereum and Besu [...]. We recommend running Geth as default as it is the most reliable and tested client for ARM devices." [ https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/running-ethereum.html ] Das große Risiko bei einem globalen Ausfall von Geth ist mir bewusst und damit lebe ich zunächst. Viel wichtiger ist es mir, die benötigte Konfiguration schnellstmöglichst zum Laufen zu bekommen. Ich habe vor zwei Tagen Geth auf meinem Testsystem im Testnet "Goerli" installiert und es startet auch ohne Fehler. Jedoch startet hier die Synchronisation nicht, da der Client seit Tagen keine passenden Peers für die Synchronisation findet. Die Anzahl der verbundenen Peers schwankt zwischen 0 und 2, mehr werden es aber nie. Habe es mit den Synchronisierungs-Optionen "Full" und "Snapshot" versucht, beides ohne Erfolg. Vielleicht würde es im Mainnet besser klappen, weil es mehr Clients gibt, aber was hilft mir das auf Dauer, wenn ich dann keine passende Testumgebung habe. Werde dies aber trotzdem als nächstes mal versuchen, ob es im Mainnet besser laufen würde. Werde mir aber noch einen anderen Client heraussuchen. Welchen könnt ihr hier empfehlen, der sich schnell und einfach installieren lässt und der mit möglichst wenig Ressourcenverbrauch auch auf einer ARM-CPU läuft? Für den Mainnet-Raspberry-Pi brauche ich eine zusätzliche Festplatte, denn die aktuelle hat nur 1 TB Speicher, empfohlen werden aber nun 2 TB mit dem Execution-Client (z.B bei Geth). Die bisherige 1-TB-SSD würde ich am Raspberry-Pi für die Beacon-Chain und Validator belassen und stattdessen zusätzlich an den zweiten USB-3-Steckplatz eine zweite Festplatte anschließen und beide parallel laufen lassen (ich hoffe, das überlastet nicht den USB-Controller). Dieses mal werde ich mir eine M.2-SSD zulegen. Kenne mich mit Hardware nicht gut aus, aber würde folgendes kaufen: Festplatte: https://www.amazon.de/Crucial-CT2000P2SSD8-Internes-2400-NAND/dp/B08GVDNTGJ/ - Kosten: 139€ - Kapazitäten: bis zu 2TB mit sequentiellen Lese/Schreibvorgängen bis zu 2.400/1.900 MB/s - unterstützt NVMe Dazu sollte folgender USB-M.2(NVME)-Adapter passen: https://www.amazon.de/Adapter-basierter-Festplattenkonverter-tragbare-Unterstützung/dp/B09H6K3TTQ - max Speed: 10 Gbit/s mit USB 3.1 Die ausgesuchte M2-SSD ist zwar relativ langsam im Vergleich zur Konkurrenz (Geschwindigkeit von bis zu 5.000 MB/s möglich), jedoch unterstützt USB 3.0 eh nur eine maximale Geschwindigkeit von 5Gbit/s (625MB/s). Somit sollte die ausgewählte Festplatte für den Raspberry Pi genau richtig sein. Wenn sich jemand besser dazu auskennt, dann bitte melden, werde die mir morgen kaufen.

Hi, danke für deine Erinnerung. Ich habe es schon mitbekommen, dass bald der Merge bevorsteht, aber habe es immer weiter verdrängt. Habe privat sehr viel um die Ohren und habe mich daher schon lange nicht mehr damit beschäftigt. Ich muss nun dringen anfangen, mich da einzulesen.. Vermutlich muss ich neue Hardware kaufen, denn das wird wohl auf meinem alten Raspberry Pi nicht laufen. Ich hatte ja bisher Infura genutzt, da ich damals Geth auf dem Raspberry Pi nicht zum laufen gebracht hatte. Ich überlege mir mal einen Schlachtplan und melde mich dann die Tage wieder. Ihr seid dann wohl alle schon bereit für den Merge?

Hi, sehr gut, dass du diesen alten Thread wieder ins Leben rufst. Wollte mich auch schon lange wieder mit einem Update melden, aber bei mir ist privat viel passiert: Während der Corona-Zeit hat sich mein entspanntes Single-Leben zum äußerst stressigen Familien-Leben weiter entwickelt, so dass seitdem nun alles Kopf steht und ich keine Zeit mehr für irgendetwas anderes habe.. 😄 Das Positive vorweg: Mein Beacon-Node und Validator laufen ohne irgendwelche manuellen Eingriffe relativ stabil. Ein oder zweimal habe ich ein neues Update der Prysm-Software installiert, mehr musste ich bisher nicht machen. Ein kleines Problemchen gibt es: Hin und wieder verpasse ich eine Attestation (ca. 1x pro Tag) oder ein Proposal (seit einigen Monaten erreiche ich hier nur noch eine Quote von knapp über 50 Prozent erfolgreiche Proposals, das ist sehr schlecht). Ich vermute, dass hier entweder die Hardware des Raspberry Pi nicht ausreicht, um ausreichend schnell zu antworten. Oder es hängt damit zusammen, dass ich aufgrund eines neuen Routers das Port-Forwarding nicht mehr einstellen kann. Hatte aber bisher keine Zeit, dem näher nachzugehen. Ich bin froh, dass es ansonsten ohne Eingriff relativ stabil läuft (d.h. kein Komplettausfall, keine Fehler, kein Neustart usw). Einen Failover-Mechanismus habe ich gar nicht. Zur Not muss ich alles neu installieren oder auf dem Testnet-Raspberry-Pi alles neu konfigurieren. Dabei gehen wohl einige Tage verloren, aber mit dem Risiko kann ich leben. Aber wieso hast du ein Slashing-Risiko, wenn deine Node ausfällt und du daraufhin ein Backup aktivierst? Du aktivierst es ja nur, wenn von deinem alten System kein Lebenszeichen mehr kommt? Somit wirst du ja nie denselben Validator doppelt in Betrieb haben, oder gibt es da eine Konstellation, an die ich hier nicht gedacht habe? Und natürlich bin ich für 2021 in die Steuerfall getappt: Anders als ursprünglich geplant habe ich nicht kontinuierlich die Menge an ETH, die ich durch das Staking erwirtschaftet habe, von meinen übrigen ETH auf der Seitenlinie verkauft. Das führt aufgrund des stark eingebrochenen Kurses dazu, dass ich nun mehr ETH versteuern muss (ca. 5.000€), als wie diese nun tatsächlich noch wert sind. Außerdem gehe ich noch vom worst-case aus, denn es ist ja noch gar nicht sicher, dass ich jemals diese gestakten ETH auch in Euro umtauschen kann. Denn bis zum mehrmals verschobenen Merge kann noch viel passieren (vgl. Lunar^^) oder evtl aufgrund eines Fehler bei der Einrichtung kann ich mir den falschen Key notiert haben und hätte somit gar keinen Zugriff mehr auf die gestakten ETH. Denn eine Auszahlung konnte ich bislang noch nicht testen. Daher bin ich noch am überlegen, wie ich das in der Steuer angeben soll.. Somit war es keine schlechte Idee von dir, erst mal mit dem Staking im Mainnet zu warten. Allerdings gebe ich zu bedenken, dass du evtl. nicht zu lange warten solltest, denn soweit ich mich erinnern kann, gab es mal eine maximale Grenze an Validatoren. Anfangs hieß es, dass nur maximal 10 Mio ETH fürs Staking gebunden werden können. Mittlerweile sind aber schon über 12 Mio ETH im Staking, somit hat sich diese Grenze entweder verschoben oder wurde ganz aufgelöst: https://beaconcha.in/

Sehr schön, diese Auswertung ist neu, die kannte ich auch noch gar nicht. Damit vereinfacht sich die Steuerauswertung enorm. Per Knopfdruck hat man alle Infos, die man benötigt. Ich würde das Staking separat von den anderen Krypto-Geschäfte für die Steuer abrechnen. Einfach das Staking-Endergebnis fürs komplette Jahr ermitteln und dies dann in die Steuererklärung eintragen. So spart man sich auch noch das Einlesen in ein Steuer-Tool. Außerdem stehen in der Steuererklärung die Staking-Erträge eh an einer anderen Stelle als die Trading-Eträge, somit kann man beides unabhängig voneinander abrechnen. Genau, das ist der wichtigste Punkt. Ich möchte mich nächstes Jahr auch nicht darauf verlassen müssen, dass es dann diesen Service noch kostenlos gibt. Daher sammle ich alle nötigen Daten selbst. Aber diese Auswertung von beaconcha.in/rewards werde ich dann zusätzlich als Backup nutzen bzw. dann am Jahresende vergleichen, ob meine Berechnung zum selben Ergebnis kommt. In meiner letzten Nachricht vom 06. Juli habe ich das Python-Skript gepostet, mit dem ich alle 10 Minuten den aktuellen ETH-EUR-Kurs ermittle und in eine Datei schreibe. Und darauf aufbauen durchlaufe ich mit nachfolgendem Skript zuerst Zeile für Zeile die zuvor erstellte Datei mit den Kursen und suche mir für jeden Eintrag (Datum&Kurs) in einer weiteren Schleife aus der Logdatei des Validators ein dazu zeitlich passende Änderung des Staking-Guthabens. Falls es fürs jeweilige Zeitintervall eine Guthabensänderung in der Logdatei des Validators gibt, dann multipliziere ich die dazugewonnen (oder verlorenen) ETH mit dem zuletzt eingelesenen ETH-EUR-Kurs, um somit den jeweiligen Euro-Wert zu erhalten, welcher dann in eine weitere CSV-Datei geschrieben wird. Summiert man dann am Ende in Excel sämtliche Euro-Werte für das gewünschte Jahr, so erhält man den Gesamt-Staking-Ertrag in Euro, den ich dann in der Steuererklärung angeben werde. So sieht dann mein zweites Skript aus: #!/usr/bin/python # -*- coding: utf-8 -*- # # Creation: 16.01.2021 # Last Update: # import linecache import re def main(): sLogdateiValidator = "LogValidator.txt" #Dies ist die Datei, die vom Prysm-Validator geeriert wird und protokolliert u.a. die Balance-Änderung im Validator sLogdateiKurswert = "Logging.log" #Diese Datei wurde mit dem vorherigem Skript erzeugt und enthält alle 10 Minuten den aktuellen ETH-Wert sCsvDateiOutput = "Ergebnis.csv" #In diese Datei wird die Auswertung dieses Skriptes geschrieben. print ("Finde Startwert ('oldBalance') in Validator.log") iZeilennummerValidatorLog = 0 rDateiLogValidator = open (sLogdateiValidator, "r") for line in rDateiLogValidator: iZeilennummerValidatorLog = iZeilennummerValidatorLog + 1 items = re.findall("oldBalance=[0-9]+\.[0-9]+", line) #z.b: oldBalance=33.097292113 #print items[0] if len(items) > 0: #d.h. wenn der RegEx einen Treffer findet, dann werden diese Ergebnisse nach "Items" geschrieben. Aber nur der erste Inhalt (Index 0) ist relevant und wird erneut aufgeteilt.. data = items[0].split("=" , 2) print data[0] + "=" + data[1] + " in Zeile: " + str(iZeilennummerValidatorLog) OldBalanceWert = float(data[1].strip()) break rDateiLogValidator.close() print ("Erstelle CSV-Datei für Ergebnisse: " + sCsvDateiOutput) wDateiCsvOutput = open (sCsvDateiOutput, "a") wDateiCsvOutput.write ("ZeitpunktKurswert;KursWert[Euro/ETH];ZeitpunktValidatorNewBalance;ValidatorOldBalance[ETH];ValidatorNewBalance[ETH];ZuwachsValidator[ETH];ZuwachsValidator[Euro];\n") #Schreibt die Überschrift der CSV-Datei print ("Logdatei mit Kurswerten öffnen") rDateiKursWert = open (sLogdateiKurswert, "r") for line in rDateiKursWert: #print(line.strip()) #Die Funktion 'strip' entfernt Leerzeichen am Anfang und Ende data = line.split(";" , 2) if len(data) > 1: #d.h. es existieren mindestens zwei Elemente: Datum + Kurswert if data[1].find("None") == -1 \ and data[1].find("Error") == -1: #d.h keiner der Begriffe darf in der Zeile enthalten sein KursZeitpunkt = data[0].strip() KursWert = float(data[1].strip()) sKursWertString = data[1].strip().replace(".",",") #Ersetzt Punkt durch Komma, also: 1000.99 -> 1000,99 print (KursZeitpunkt + " => Kurswert=" + sKursWertString) #Suche im Validator-Log nach passendem Wert (anhand des Datums), in dem "newBalance" enthalten ist: print "Find next 'NewBalance' in Validator.log:" Weiter = False while (Weiter == False): sZeileninhaltValidatorLog = linecache.getline(sLogdateiValidator, iZeilennummerValidatorLog).strip() items = re.findall("newBalance=[0-9]+\.[0-9]+", sZeileninhaltValidatorLog) #print items[0] if len(items) > 0: #d.h. wenn der RegEx einen Treffer findet, dann werden diese Ergebnisse nach "Items" geschrieben. Aber nur der erste Inhalt (Index 0) ist relevant und wird erneut aufgeteilt.. data = items[0].split("=" , 2) #print data[0] + "=" + data[1] NewBalanceWert = float(data[1]) #print "Zeile=" + str(iZeilennummerValidatorLog) NewBalanceZeitpunkt = sZeileninhaltValidatorLog[6:25] print NewBalanceZeitpunkt + " -> NewBalance=" + str(NewBalanceWert) if NewBalanceZeitpunkt > KursZeitpunkt: Weiter = True else: #Berechnung der Balance durchführen bzw in CSV schreiben: KursZeitpunkt;NewBalanceZeitpunkt;KursWert;(OldBalanceWert - NewBalance);KursWert*(NewBalanceOld - NewBalance); wDateiCsvOutput.write (KursZeitpunkt+";"+sKursWertString+";"+NewBalanceZeitpunkt+";"+"{:.10f}".format(OldBalanceWert).replace(".",",")+";"+"{:.10f}".format(NewBalanceWert).replace(".",",")+";"+"{:.10f}".format(NewBalanceWert-OldBalanceWert).replace(".",",")+";"+"{:.15f}".format(KursWert*(NewBalanceWert-OldBalanceWert)).replace(".",",") +";\n") OldBalanceWert = NewBalanceWert if Weiter == False: iZeilennummerValidatorLog = iZeilennummerValidatorLog + 1 rDateiKursWert.close() wDateiCsvOutput.close() return 0 if __name__ == "__main__": main() Damit dieses obige Skript hier funktioniert, braucht man die Logdatei des Validators. Die erhält man, wenn man den Validator mit entsprechendem Parameter aufruft (z.B.: "log-file: /mnt/ssd/Logging/LogValidator.txt") oder wenn der Dienst als Service läuft und dabei die Consolen-Ausgabe in eine Textdatei umleitet (z.B: "StandardOutput=append:/mnt/ssd/Logging/LogValidator.txt"). Naja, jetzt wenn ich das nach einem halben Jahres alles nochmal beschreibe, klingt es rückblickend schon etwas kompliziert. Aber damals hatte ich noch mehr Zeit als heute und das Skripten muss einem auch Spaß machen. Ansonsten einfach die vorgeschlagene Lösung von @Muesli2k nehmen (siehe oben) und hoffen, dass der Service dauerhaft verfügbar bleibt.

Ich hatte diese Diagramme vor einigen Monaten mal erstellt. Aber als ich letztes Wochenende mal wieder reingeschaut hatte, hatte ich festgestellt, dass die Diagramme seit 17. Juni keine neuen Werte mehr bekommen haben, da das Skript zum Sammeln der Daten ständig auf einen Fehler lief, da die Daten aus dem PLC_EUR-Orderbook auf Coinsbit nicht mehr abgerufen werden konnten, da dieses Handelspaar plötzlich nicht mehr erreichbar ist. Vermutlich war das der Zeitpunkt, als Platincoin das große 3-wöchige Update angekündigt hatte und alle Börsen (incl. Coinsbit) abgekoppelt hatte. Da ich in den letzten Monaten aber auch aus den meisten PLC-Telegram-Gruppen rausgeworfen wurde, kann ich nicht sagen, was genau passiert ist. Jedenfalls gibt es das bisherige Orderbuch PLC-Euro nicht mehr. Ich glaube aber nicht, dass diese offenen 100.000 PLC verkauft wurden, sondern vermute eher, dass sämtliche Verkaufsanfragen einfach gestrichen wurden. Denn einen Verkauf hätte ich sonst noch im Diagramm mitbekommen. Als einziges Handelspaar gibt es scheinbar nur noch PLC-USDT, und das mit immer steigender Beliebtheit. Ich musste daher das Skript zum Sammeln der Daten etwas umbauen und die Diagramme neu aufbauen um Platz für das zusätzliche PLC-USDT-Handelspaar zu bekommen (in der kostenlosen Version sind nur sieben Diagramme erlaubt, daher musste ich etwas umräumen^^). Beim Exportieren und Importieren der Diagramm-Daten sind mir irgendwie die ersten Monate verloren gegangen, daher beginnen nun die Diagramme erst mit November 2020. Aber die alten Daten sind eh nicht so relevant. Seit Samstag (03. Juli) ist das Skript zum Sammeln der Daten nun entsprechend erweitert und schreibt nun zumindest die anderen Diagramm-Werte weiter, auch wenn das PLC-Euro-Paar aktuell keine Daten mehr liefert. Viel spannender ist tatsächlich, was aktuell mit der Umlaufversorgung passiert. Diese stieg seit diesem PLC-Update extremst an. @Flensthatte das vor einigen Tagen schon berichtet und eine Vermutung geäußert: Naja, es bleibt spannend, beobachten wir einfach mal, wie sich alles weiter entwickelt... Bin mal gespannt, ob sich die PLC-Führung für diese Hyper-Inflation eine kreative Ausrede einfallen lässt (z.B. Hackerangriff, Vorbereitung auf Coin-Burning, usw.), oder ob das einfach totgeschwiegen wird 🙊☠️

Wie gesagt habe ich das Prysm-Projekt die letzten Monate nur noch sehr wenig beobachtet. Was ich aber raus gefunden habe ist, dass die API scheinbar noch in der Entwicklung ist: https://docs.prylabs.network/docs/how-prysm-works/ethereum-2-public-api Die einzige Abfrage, die bisher auf dem Beacon-Node funktioniert, ist scheinbar folgende: http://127.0.0.1:3500/eth/v1alpha1/beacon/chainhead Hier bekommt man aber nur die letzten Daten zur Beacon-Chain. Keine Daten vom eigenen Validator. Ist also aktuell noch nicht wirklich hilfreich. Du könntest hingegen die Api von BeaconCha.in nutzen: https://beaconcha.in/api/v1/docs/index.html Jedoch ist man dann wieder sehr abhängig von diesem Anbieter. Aber so könntest du dir hier am Beispiel vom Validator #1234 die Änderung des Guthabens für die letzten 100 Epochen ausgeben (d.h. die letzten 10 Stunden): https://beaconcha.in/api/v1/validator/1234/balancehistory Aber an deiner Stelle, wenn dir die Tageswerte reichen, würde ich folgendes machen: 1.) Nimm die CSV-Datei mit den täglichen Staking-Erträge, die du auf BeaconCha.in bekommst: https://beaconcha.in/validator/1234/stats 2a.) Schreibe dir ein Skript, welches täglich den ETH-Euro-Preis ermittelt (siehe mein Beispiel unten) 2b.) Alternativ: Finde eine Seite, welche die historischen ETH-Euro-Kurse bereitstellt, z.B. hier für die letzten 31 Tage: Ethereum - Euro historische Kurse | finanzen.net 3.) Öffne die CSV-Datei (aus 1.) mit Excel und füge zum passenden Tag in einer neuen Spalte den ETH-Euro-Preis (aus 2a. oder 2b.) hinzu. 4.) Dann muss man in Excel nur noch die Spalte mit dem Einkommen ("Income") als deutsche Kommazahl umformatieren, und schon kannst du in einer neuen Spalte die Summe berechnen 5.) Zum Schluss berechnet dir Excel die Jahres-Gesamtsumme über die einzelnen Tageswerte und fertig ist der Eintrag für die Steuererklärung! Würde dann in etwa so aussehen: Und mit nachfolgendem Python-Skript kannst du dir aus Coinmarketcap den jeweils aktuellen ETH-Euro-Wert holen. Wenn du dieses Skript zeitgesteuert einmal täglich ausführst, bist du etwas unabhängiger und hast am Jahresende deine eigenen Daten für die Steuererklärung. Das Hauptskript: (Die Wiederholung muss natürlich individuell angepasst werden, aktuell würden die Daten alle 10 Minuten abgegriffen werden) #!/usr/bin/python # -*- coding: utf-8 -*- # # Creation: 02.01.2021 # Last Update: # from time import sleep #Für die Sleeps from datetime import datetime, timedelta import sys, traceback #Zur detaillierten Fehlerauswertung/ Verarbeitung im Exception-Block import os import ApiCoinMarketCap def main(): Logdatei = "ETH-Kurs.csv" try: print datetime.now(), 'Programmstart:' while True: Preis = ApiCoinMarketCap.GetEthPrice() Timestamp = time.localtime() Jahr, Monat, Tag, Stunden, Minuten, Sekunden = Timestamp[0:6] Zeitpunkt = "%04i-%02i-%02i %02i:%02i:%02i" % (Jahr, Monat, Tag, Stunden, Minuten, Sekunden) #print ("Logdatei öffnen um neue Zeile anzuhängen") Datei = open (Logdatei, "a") Datei.write (Zeitpunkt + " ; " + str(Preis) + "\n") Datei.close() #print ("Eintrag in Logdatei geschrieben") print 'Warte 10 Minuten bis um..', (datetime.now() + timedelta(seconds=600)) sleep(600) #10 Minuten warten except KeyboardInterrupt: # Mit STRG+C beendet print("Programm vom User mit STRG+C gestoppt") return(0) except Exception as e: print(e) print("Unbekannter Fehler.") return("Error#03: Unknown error in Main") if __name__ == "__main__": main() Und hier das dazugehörige Skript "ApiCoinMarketCap.py" zum eigentlichen Abruf der Daten aus Coinmarketcap: #!/usr/bin/env python # -*- coding: utf-8 -*- # # Creation: 02.01.2021 # Last Update: 14.01.2021 Error-Handling "except" erweitert und stabilisiert # #This example uses Python 2.7 and the python-request library. #https://coinmarketcap.com/api/documentation/v1/#section/Quick-Start-Guide from requests import Request, Session from requests.exceptions import ConnectionError, Timeout, TooManyRedirects import json def GetEthPrice(): url = 'https://pro-api.coinmarketcap.com/v1/cryptocurrency/quotes/latest' parameters = { 'slug':'ethereum', 'convert':'EUR' } headers = { 'Accepts': 'application/json', 'X-CMC_PRO_API_KEY': 'XXXXXXX-XXXX-XXXX-XXX-XXXXXXX', } session = Session() session.headers.update(headers) try: response = session.get(url, params=parameters) data = json.loads(response.text) #print(data) Preis = str(data.get('data').get('1027').get('quote').get('EUR').get('price')) print ("Preis = " + Preis) #for key,value in data.items(): # print str(key) + " => " + str(value) return(Preis) except (ConnectionError, Timeout, TooManyRedirects) as e: print(e) print("Vermutung: Keine Verbindung zu Coinmarketcap-Api möglich.") return("Error#01: Connection lost") except (AttributeError) as e: print(e) print("Vermutung: Leerer Inhalt abgerufen.") return("Error#02: Empty values") except Exception as e: print(e) print("Unbekannter Fehler.") return("Error#03: Unknown error") if __name__ == "__main__": GetEthPrice() Achja, eine wichtige Info zu obigem Skript: Den Api-Key habe ich hier durch "XXXXX" ersetzt. Jeder muss sich natürlich selbst bei Coinmarketcap anmelden um einen individuellen Api-Key zu erhalten. Ich habe festgestellt, dass mit dem kostenlosen Konto ein Abruf alle 10 Minuten möglich ist, ohne das tägliche und monatliche Limit zu überschreiten.

Ja, natürlich gibt man in der Steuererklärung nur einen einzigen Wert an: den aufsummierten Jahresgewinn. Aber falls der ETH-Preis in Zukunft noch weiter steigt und die Summen größer werden, dann wird evtl. schon mal das Finanzamt nachfragen und im Einzelfall eine detaillierte Auflistung der Erträge sehen wollen. Und auch, wenn man mal in ein paar Jahren eine Handvoll gestakte ETHs verkauft, wird dann vermutlich auch mal die Bank nachfragen, woher plötzlich die hohen Summen auf dem Konto kommen (vorausgesetzt der Preis steigt wie erhofft weiter stark an). Da ist es immer gut, über die Jahre hinweg eine sehr detaillierte Auflistung für den Nachweis zu haben. Streng genommen müsste man immer sofort, sobald man seine Staking Erträge bekommen, den aktuellen Euro-Preis berechnen und dieses dann fürs Steuerjahr aufsummieren. Also im Falle von ETH müsste man alle 6 Minuten bei jeder Attestation den Preis berechnen. Aber ich denke, für die Steuer sollte es reichen, wenn man es auf den einzelnen Tag mittelt. Aber auf keinen Fall würde ich es auf das Jahr mitteln, sonst zahlt man im Bullenmarkt zu viel (und im Bärenmarkt zahlt man zu wenig). Z.B. lag der ETH-Preis am 01.01.2021 bei 615€. D.h in den ersten Wochen musste ich noch deutlich weniger Steuer bezahlen im Vergleich zu heute, obwohl ich dieselbe Menge an ETH bekomme (bzw zu Beginn des Jahres gab es sogar noch mehr ETH pro Attestation, da die Anzahl der Validatoren niedriger war). D.h. wenn ich die ersten ETH vom Jahresanfang mit dem aktuellen EHT-Kurs verrechnen würde, dann würde ich zu viel Steuer bezahlen. Die genaue Besteuerung ist meines Wissens noch nicht zu 100% final, aber meines Wissens verhalten sich die gestakten Coins anders als die gekauften Coins: - Bei den gekauften Coins zahlt man die Steuer auf die Differenz von Anschaffungspreis minus Veräußerungspreis. z.B. 1 ETH für 300€ gekauft und für 2.000€ verkauft -> Steuer ist auf 1.700€ Gewinn fällig. Und auch nur, wenn Kauf und Verkauf innerhalb von 365 Tagen geschieht. Danach ist es steuerfrei. - Beim Staking zahlt man einmalig die Steuer auf den gesamten Gegenwert, sobald man die Coins durch das Staking bekommt. Dann beim Verkauf fallen keine Steuern mehr an (da ich ja bereits die Steuer bezahlt habe). z.B ich erhalte durch Staking 1 ETH zu einem aktuellen Kurs von 300€. Später verkaufe ich das gestakte 1 ETH zu einem Kurs von 2.000€ -> Steuer ist nur auf die 300€ beim Staking fällig und zwar sofort in dem Steuerjahr, in dem man dies erwirtschaftet hat. => Im Bullenmarkt ist das Staking sehr vorteilhaft, es kann aber z.B. im Bärenmarkt auch sehr schnell zur Steuerfalle werden. Oder auch z.B. wenn ich 1.000 Scam-Coins zum Preis von je 5€ durch angebliches Staking erhalte (d.h. müsste beim Erhalt 5.000€ Steuer bezahlen). Der Verkauf ist dafür steuerfrei, aber da es sich um einen Scam-Coin handelt, kann ich diesen nicht verkaufen bzw er ist dann in einem Jahr nur noch 0 Euro Wert, dann habe ich ein ziemliches Verlustgeschäft gemacht... Nachtrag: Jedoch die 32 ETH, die ich für das Staking einsetze, diese muss ich nun 10 Jahre halten bevor ich diese wieder verkaufe, denn sonst muss ich darauf beim Verkauf auch wieder Steuern bezahlen. So habe ich zumindest bisher die Steuer bei Staking verstanden. Falls hier noch ein gravierender Fehler in meiner Betrachtung ist, dann bitte melden 😄

Irgendwo habe ich mal gelesen, dass wirklich absolut Zufall sein soll, wann dein Validator einen eigenen neuen Block erstellen darf ("Proposal"). Innerhalb von sieben Monaten (bzw innerhalb der ersten 30 Wochen) hat mein Validator ca. 20 Proposals durchgeführt. Also kann man durchschnittlich mit 2 Proposals alle drei Wochen rechnen. Die Verteilung ist bei meinem Validator aber sehr unterschiedlich: Mal bekommt er einen Monat gar kein Proposal mehr, dann kommen mehrere in wenigen Tagen. Ja genau, die Bestätigung der erzeugten Blöcke ("Attestation") findet zu jeder Epoche statt, als ca. alle 6 Minuten. Bei einer Auswertung meiner Daten komme ich auf folgende Wert (Wobei diese Werte vermutlich davon abhängig sind, wie viele andere Validatoren gerade aktiv sind): Proposal: +0,004 ETH (aktuell ca. 10 Euro) Attestation: +0,000025 ETH (aktuell ca. 5 Cent)

Hi, es ist tatsächlich mal wieder an der Zeit ein Update zu geben. Ich habe das Projekt die letzten Monate etwas sehr auf Sparflamme köcheln lassen aber das Positive vorweg: Es läuft immer noch sehr stabil und ich musste fast gar nicht eingreifen. Fehler traten in den letzten Monaten fast gar keine. Zu Beginn hatte ich das System genauer kontrolliert und Ausfälle gab es nur, wenn mal das Internet für wenige Minuten ausgefallen war. Nun hat der Raspberry Pi direkt ein Lan-Kabel zum Router (nicht mehr über Switch), seitdem ist mir da auch kein Ausfall mehr aufgefallen. Oder ich bekomme die Ausfälle nicht mit, weil die zu kurz sind und ich die Logdateien nicht mehr kontrolliere. D.h. ich musste nur eingreifen, um in unregelmäßigen Zeitabständen die Prysm-Updates einzuspielen, was auch relativ schnell geht: - Wenn man die Prysm-Discord-Gruppe verfolgt dann wird man alle paar Wochen per Mail informiert, dass es ein neues Update gibt. - Dieses neue Update spiele ich zuerst auf dem Test-Raspberry-Pi im Testnet ein und beobachte, ob nach dem Neustart noch alles läuft. - Dann einige Tage später spiele ich das Update auch auf meinem Raspberry-Pi im Mainnet ein. Dauer: ca 10 bis 15 Minuten (d.h. Update einspielen und warten bis die Synchronisation mit der Beachon-Chain wieder steht und danach warten, bis dann der erste Block wieder korrekt validiert wurde). Ursprünglich wollte ich mir auch eine eigene Überwachung bauen, die mich informiert, wenn mein Validator nicht mehr läuft. Das gibt es aber mittlerweile ja auch schon: Wenn man sich über Beaconcha.in einloggt, dann kann man beliebige Validatoren folgen und sich informieren lassen, sobald dieser Validator keine Blöcke mehr bestätigt. Sehr praktisch: So kann man sich entspannt zurück lehnen und muss nicht täglich die Balance des Validators prüfen. Seit Dezember hat mein Validator nun schon über 1,8 ETH durch das Staking erwirtschaftet. Und das mit minimalen Hardware-Aufwand! Zum Thema Steuer melde ich mich später nochmal. Habe da auch aus meiner Sicht eine praktikable Lösung mittels selbst erstellten Skript gefunden. Wobei dieser CSV-Export ist neu, den kenne ich noch gar nicht. Evtl melde ich mich heute Abend oder morgen noch mal im Detail dazu.. Wie läuft es bei dir? Nachtrag zum Thema "Steuern": Da ich meinen Validator schon seit 1. Dezember in Betrieb habe, musste ich die Einnahmen für den Monat Dezember in der Steuererklärung mit angeben, musste jedoch keine Steuern bezahlen: Denn für diesen einen Monat hatte mein Validator ca. 205 Euro eingebracht (bei einem Grundfreibetrag von 256€). Diesen Euro-Wert habe ich mir anhand der täglichen ETH-Einnahmen und anhand des aktuellen Tages-Ende-Kurs selbst per Hand ausgerechnet. Davon wurden dann noch die Investitionskosten abgezogen (Neuer Raspberry Pi + SSD-Festplatte + Kühlung). Eingetragen habe ich das alles in Anlage SO ("Sonstige Einkünfte") in Zeile 10. Die Steuererklärung ging dieses Jahr so ohne Beanstandungen durch. Nächstes Jahr dürfte die Steuererklärung etwas komplizierter werden, da ich viel mehr Werte für die Berechnung habe und es daher nicht mehr per Hand zusammenzählen möchte. Außerdem war mir der Tages-Schluss-Kurs zu ungenau. Daher habe ich mir fürs aktuelles Jahr für die Berechnung der Steuer zwei Python-Skripte geschrieben: Das erste Skript ruft alle 10 Minuten von der Coin-Market-Cap-Api den aktuellen ETH-Euro-Wert ab und speichert diesen in einer CSV-Datei. Dieses Skript läuft durchgängig als Linux-Service auf dem Testnet-Raspberry-Pi. So sehen die gesammelten Werte beispielhaft für die Monate Januar und Februar in meiner CSV-Datei aus: https://pastebin.com/7sPudeiz Das zweite Skript wird einmalig ausgeführt und durchforstet mittels RegEx die Logdatei des Validators. Immer, wenn dort eine Änderung der ETH-Balance zu einem bestimmten Zeitpunkt protokolliert ist, dann suche ich mir zu diesem Zeitpunkt den passenden ETH-Euro-Wert aus der CSV-Datei meines ersten Skriptes heraus und berechne dazu den Gewinn in Euro. Da das erste Skript zur Ermittlung des ETH-Wertes nur alle 10 Minuten läuft, habe ich somit eine maximale Differenz von 10 Minuten, was meiner Meinung nach völlig in Ordnung ist. Ich denke, sogar eine tägliche Mittlung der Werte sollten für die Steuer auch noch OK sein, da kann ich mit dieser geringen Abweichung leben. Aber so erhalte ich nun ein relativ genaue Berechnung der eingenommenen Erträge, welche ich dann später gesammelt in der Steuererklärung abgeben kann. D.h. auf eine zusätzliche Software wie Cointracking-Tool o.ä. kann ich daher für die Staking-Erträge komplett verzichten. Auf dem ersten Blick klingt das etwas kompliziert, denn statt alle 10 Minuten den aktuellen ETH-Euro-Preis lokal auf dem Raspberry Pi zu speichern, könnte ich auch direkt eine öffentliche DB bei der einmalig Auswertung der Logdatei anzapfen. Jedoch habe ich hier keine kostenlose Datenbank gefunden, denn z.B. wenn ich hier auch die API von Coins-Market-Cap nutzen würden, dann müsste ich für den Zugang zu den historischen Daten einige Hundert Dollar bezahlen. Daher gehe ich den kostenlosen aber komplizierten Weg, was auch den Vorteil hat, dass ich stets alle benötigten Daten lokal auf meiner Festplatte des Raspberry Pi habe. Falls jemand diese Python-Skripte haben möchte, dann kann ich die hier gerne mal veröffentlichen. Müsste die aber vorher noch etwas verschönern, bevor ich die hier poste. Deine CSV-Datei aus Beacconcha.in ist auch sehr praktisch: Hier werden die Gewinne bzw Verluste pro Tag aufgeführt. Jetzt müsste man nur noch pro Tag den jeweiligen ETH-Euro-Kurs dem gegenüberstellen und schon könnte man auch selbst einfach seine Gewinne berechnen. Auch wieder ganz ohne Steuertool. Und die ETH-Tageswerte sind vermutlich deutlich einfacher aus einer Übersicht zu ermitteln als die Minutenwerte. Und noch im Dezember hatte ich geschrieben, dass ich von meiner zusätzlichen ETH-Hodl-Position monatlich eine Betrag in Höhe von ca. 25-50% meiner Staking-Erträge verkaufen möchte, um diesen Fiat-Betrag beiseite zu legen, um damit im nächsten Jahr problemlos die Steuer bezahlen zu können. Aber ich habe nun doch noch nichts verkauft, denn in der ersten Jahreshälfte dachte ich, dass der Kurs noch weiter steigt. Und jetzt aktuell ist mir der Kurs eh zu niedrig um zu verkaufen und ich gehe eher davon aus, dass der Preis die nächsten Monate noch weiter steigen wird. Habe auch heute mein Skript zur Ermittlung meiner Staking-Gewinne durchlaufen lassen und festgestellt, dass ich Stand heute knapp 2.500€ Gewinn gemacht habe, die ich zur nächsten Steuererklärung mit angeben muss. Das ist noch überschaubar, da werde ich wohl dieses Jahr gar kein ETH mehr verkaufen.

Hallo Susanne, kann dir und allen anderen, die ihr Geld zurück haben wollen, folgende Telegram-Gruppe empfehlen: https://t.me/joinchat/kegO1aExzJAwMDBi In dieser Gruppe wurde vor Kurzem (vor ca. drei Wochen) mit Alex persönlich vereinbart, dass alle, die aussteigen wollen, ihr investiertes Geld zurück bekommen können, wenn diese sich anschließend nicht mehr negativ über PLC äußern. Man muss dazu den Support anschreiben mit dem Hinweis, dass man vom Vertrag zurücktreten will. Der Support antwortet mit der Standard-Antwort, dass die zwei Wochen Rückgabefrist verstrichen wären, aber diese Ticketnummer muss man dann an Alex weiterleiten und er kümmert sich dann um alles weitere. Jedoch hat bisher fast noch niemand sein Geld tatsächlich zurück bekommen, daher wird aktuell auch über mögliche weitere Schritte vor Gericht nachgedacht. Also falls du noch kein Telegram auf dem Handy hast, dann installiere dir diese App, tritt der Gruppe bei, und kämpfe dich durch die Nachrichten der letzten drei Wochen. Mit etwas Glück bekommst du somit unkompliziert dein Geld zurück. Falls es nicht so einfach klappt, dann hast du zumindest weitere Ansprechpartner in derselben Situation... Viel Erfolg!

Hi, habe etwas Off-Topic beizutragen: Denn habe heute zufällig eine interessante Reportage gesehen, bei der ich große Ähnlichkeiten zu Platincoin sehe. Wer eine halbe Stunde Zeit hat, kann ja mal rein schauen und sich ein eigenes Bild davon machen: https://www.ardmediathek.de/video/reportage-und-dokumentation/millionen-fuer-ruinen-dubiose-geschaefte-mit-anlegergeldern/das-erste/Y3JpZDovL2Rhc2Vyc3RlLmRlL3JlcG9ydGFnZSBfIGRva3VtZW50YXRpb24gaW0gZXJzdGVuLzgyMDA4YzY1LTFmY2QtNDZiYi1iZjg1LWU4NzIwM2NhMDA5OQ/ Grob gesagt geht es hier um ein Immobilienunternehmen, welches Gelder von Investoren eingesammelt hatte, um angeblich in Immobilien zu investieren, was aber nicht geschehen ist. Aber was haben Immobilien hier mit der Blockchain gemeinsam? Das Geschäftsmodell ist hier gar nicht relevant, aber ich sehe trotzdem verdächtig viele Ähnlichkeiten bei der Umsetzung: Die Firma in dem Beitrag hatte "hohe Rendite von 15% für Investoren" versprochen <-- Hmm, eigentlich nicht vergleichbar, denn über diesen mickrige Prozentwert kann der PLC-Investor nur lachen. Bei PLC werden 30% versprochen. Die Finanzberater bekamen für die Vermittlung "schwindelerregende Provision von 20% und mehr" <-- Und darüber kann der PLC-Vertriebler nur lachen, dort wird mit bis zu 60% Provision geworben. Viele Projekte wurden anfangen, aber nichts wurde zu Ende gemacht. Stattdessen wurden die Investoren mit einer Hinhaltetaktik besänftigt. <-- Kommt uns auch irgendwo her bekannt vor...? Das Unternehmen in dem Beitrag wurde 2008 gegründet; manche Investoren haben 11 Jahre einbezahlt, bis es dann seit 2019 ins Stocken geriet. Zunächst wurden jahrelang noch Zinsen ausbezahlen, später aber nicht mehr. <-- PLC begründet seine Seriosität ja u.a. darin, dass sie auch schon seit 4 oder 5 Jahren am Markt bestehen. Aber wie der Beitrag zeigt, kann sich ein gut strukturierter (bzw intransparenter) Betrug auch über 10 Jahre hin ziehen, bis alles zusammen bricht. Der Kopf des Unternehmens ist sehr charismatisch, machte aber nur leere Versprechen. Es wurde mit pompösen Image-Videos und mit der Seriosität und dem gutem Image des Standorts "Deutschland" geworben. Kommentar des Insolvenzverwalter: Wenn das Geld eines Anlegers nicht in die Immobilie geht, sondern zur Befriedigung der der Zahlungen der andere Anleger, dann ist das ein Schneeballsystem. <-- Werden bei PLC nicht auch die Einnahmen der einen Investoren (Paketkäufe) für die Ausgaben der anderen Investoren benötigt (Aufkauf der offenen Orders auf Coinsbit, Debitkartentests, Amazon-Gutscheine)? Oder gibt es zusätzliche Einnahmen, von denen wir noch nichts wissen? (Rhetorische Frage^^) Verworrene Firmengeflechte: Das Geld der Anleger wurde nicht nach Deutschland, sondern auf Konten von Firmen auf den Cayman Islands überwiesen. D.h. obwohl die Ermittler mehrere Gerichtsurteile gewonnen hatten, ist keine Geld mehr auf Deutschen Konten verfügbar, somit ist keinen Zwangsvollstreckung möglich und die geschädigten Investoren gehen leer aus. <-- Wo muss man bei Platincoin nun gleich nochmal sein Geld hin überweisen, gab es nicht zuletzt diese dubiosen Konten in der Türkei? Vermutlich wird hier auch nicht viel Geld in Deutschland oder in EU zu holen sein. Die Bafin hätte besser kontrollieren müssen, sah sich lange dafür aber nicht zuständig, obwohl das Unternehmen ein Bankerlaubnis hätte haben müssen (Da das Unternehmen Gelder für Darlehen eingesammelt und verwaltet hatte).

Also das mit dem Passwort zurücksetzen ist kein Problem. Das muss immer möglich sein, falls der Kunde sein Passwort vergessen hat o.ä. Aber auch dann sieht der Systemadministrator das ursprüngliche Passwort des Kundens niemals in Klartext, sondern im Passwortfeld steht auf der Oberfläche z.B. nur "******" und auch in der Datenbank steht der Hash-Wert des Passwortes, worauf man ohne Weiteres nicht auf das ursprüngliche Passwort zurück schließen kann. Das ist eigentlich Standard und vermutlich auch Vorgabe für alle Online-Unternehmen in Deutschland. Aber wie gesagt: Vermutlich gibt es für diese Aussage von Alex noch eine andere Erklärung...

Wow, interessant, Platincoin weiß scheinbar, welches Passwort die einzelnen Nutzer verwenden (ab Timestamp 03:02:44): Eigentlich muss ein Unternehmen die Passwörter verschlüsselt speichert, so dass nicht mal der Admin die Passwörter lesen kann. Aber vielleicht habe ich mich auch verhört und es gibt eine andere Erklärung dafür, woher Alex weiß, dass die Kunden zu einfache Passwörter verwenden... Aber wie seit heute in den Telegram-Gruppen zu lesen ist, scheint es allgemein mit der IT-Sicherheit etwas im Argen zu sein..^^ Ja das stimmt. Da ich gerade auch über meiner Steuererklärung für 2020 sitze (aber nicht mit PLC^^), kann ich bestens davon berichten: 1.) Sollte das "PLC-Minting" so ablaufen, wie von Platincoin beworben ("Coins werden in der PLC-Box bzw in der Farm direkt beim User erzeugt"), dann müsste man wohl die Coins analog wie Staking-Coins versteuern: Anlage "SO" im Abschnitt "6 - Leistungen". Man müsste zu dem Zeitpunkt, an dem man die Coins erhalten hat, den aktuellen Gegenwert berechnen (entweder 5€ oder den aktuellen Kurs bei Coin-Market-Cap) und dies dann als Gewinn ausweisen. Dafür kann man dann die Coins zu einem beliebigen Zeitpunkt zu einem beliebigen Kurs verkaufen ohne weitere Steuern auf den Verkauf bezahlen zu müssen. So ist zumindest meines Wissen der aktuelle Stand zum Staking (kann sich aber jederzeit vom Gesetzgeber noch ändern). 2.) Sollten das "PLC-Minting" lediglich eine Umbuchung der bereits existierenden Coins aus dem Pre-Mining sein, dann handelt es sich wohl eher um ein Anschaffungs- und Veräußerungsgeschäft. D.h. man notiert sich die Anschaffungskosten (z.B. Paketpreis). Und erst beim Verkauf tritt eine Steuer-relevante Aktion ein. D.h. in der Steuererklärung gebe ich beim Verkauf in Anlage "SO" im Abschnitt "9 - Private Veräußerungsgeschäfte" meinen Gewinn an: Veräußerungskosten minus Anschaffungskosten. Dies ist jedoch nur Steuer-relevant, wenn der Zeitraum zwischen Veräußerung und Anschaffung (First-in-First-Out-Prinzip) kleiner als 365 Tage ist. D.h. habe ich die Coins länger als ein Jahr gehalten, muss ich beim Verkauf gar keine Steuer bezahlen und dies auch gar nicht in der Steuererklärung angeben. Ich bitte um Korrektur, falls ich etwas falsches geschrieben. Aber zumindest so handhabe ich das für meine Steuererklärung. Leider kommt das Thema "Steuern" trotz der vielen Webinare bei PLC etwas zu kurz. Daher ist es fraglich, ob diese Kenntnisse bei allen PLC-Nutzern so präsent sind, da diese sich vermutlich nicht so sehr mit anderen Kryptowährungen und deren Besteuerung beschäftigen. Aber meiner persönlichen Meinung nach wird man als reiner Investor mit PLC niemals Tausende von Euros an Gewinn erwirtschaften können (durch Minting, nicht durch Provision), daher wird wohl auch niemals das Finanzamt nachfragen, woher das viele Geld auf dem Konto plötzlich kommt, daher kann man das Thema "Steuern" als reiner PLC-Investor schon mal etwas ignorieren..^^