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/