satoshi21

vor 1 Stunde schrieb skunk:

Bei mir steht dort eine 0x01. Damit bin ich dann erstmal raus

Kannst du doch beliebig oft im Testnet ausprobieren oder nicht?

Das stimmt! Pro Testnet Validator 1x 😉

vor einer Stunde schrieb Muesli2k:

Bisher bin ich davon ausgegangen das die Coins, im Falle von man löst den Validator auf... auf die Einzahladresse zurück gehen.... 

Bei mir auch 0x00 

Aber vor 2030 habe ich sowieso nicht vor meinen Validator aufzulösen, oder gilt das auch für die Rewards wenn ich jetzt nach dem Shanghai Upgrade mal 1-2 ETH entnehmen will ??

 

Genau, das gilt auch für "Teilauszahlungen", die m. E. auf auf jeden Fall Sinn machen. Die ETH kann man z. B. ins Liquid Staking geben.

Ist auch kompliziert!

Man benötigt sog. 0x01 Withdrawals Credentials. Unter beaconcha.in kann man diese einsehen. Hier z.B. https://beaconcha.in/validator/10000#deposits sind 0x00 Credentials hinterlegt, d.h. es wurde noch keine Withdraw Adresse eingestellt. Für das Einstellen dieser Adresse hat man genau eine Chance! Da darf nichts schiefgehen, sonst kommt man nie wieder an seine Coins...

Näheres dazu:

https://notes.ethereum.org/@launchpad/withdrawals-faq

Interessantes Update! Mein Geth Node wächst ebenfalls um ca. 5 GB pro Tag.

Ein anderes Thema treibt mich gerade um. Mein Validator hat (leider) eine BLS 0x00 Withdraw Adresse, d.h. ich muss, um nach dem Exit an meinen Stake(+Gewinne) zu kommen auf eine 0x01 Adresse wechseln. Das ist übrigens auch für das sog. Skimming, d.h. das regelmäßige Auszahlen der ETH >32 notwendig.

Hat sich schon jemand mit dem Adresswechsel-Prozess näher beschäftigt? 

vor 21 Stunden schrieb Borli:

Hallo zusammen, schön mal was deutsches zu lesen zum Thema Home Staking :). Ich plane meinen eigenen validator laufen zulassen, jedoch schreckt mich die hohe Besteuerung ab. Wird das Home-Staken(mit eigenem validator) steuerlich gleich behandelt wie liquid staking tokens wie stEth? Ich weiß es gibt wstEth bei dem sich einfach der Wert relativ zu Ether mit der Zeit erhöht(was steuerlich viel besser ist) aber ich würde gerne mit eigenem Validator staken. Oder gibt es Möglichkeiten ein Gewerbe anzumelden, wo der Freibetrag hoch genug ist um keine Steuern zahlen zu müssen. Ansonsten verliert man ja fast die Hälfte seiner Stakingerträge. Vielleicht kennt sich hier jemand mit der Thematik gut aus .

 

Das BMF Schreiben ist m.E. auf Grund der Annahme der Gewerblichkeit (Rz. 35ff.) tatsächlich für das Home Staking in Deutschland fatal.

Müssen dann nicht Wertsteigerungen des 32-ETH-Stakes bei späterer Veräußerung (oder Beendigung des Stakings) versteuert werden, da der Stake in das Betriebsvermögen eingebucht wird? D.h. ich tausche (mögliche) steuerfreie Gewinne im Privateigentum gegen (mögliche) zu versteuernde Gewinne im Betriebsvermögen. Für mich ist das das entscheidende KO-Kriterium.

Auch spielt m.E. nach dem Schreiben die 22.500 EUR-Grenze für die Gewerblichkeit keine Rolle.

Die Nach-Steuer-Rendite beim Staking mit Rocket Pool wäre damit deutlich höher, das hier sämtliche Erträge steuerfrei bleiben bis Haltedauer der rETH > 1Jahr.

Gerne würde ich meinen Validator weiter betreiben (seit Genesis dabei), aber das steuerlich Risiko erscheint mir zu hoch.

Oder sehe ich das zu streng / zu negativ?

Mein Setup aus zwei rpi 4 8GB läuft weiterhin sehr stabil mit geth und prysm. Die 2TB geth SSD ist zu ca. 75% voll aktuell. Kürzlich habe ich auch MEV implementiert, allerdings noch ohne Glück in der Proposal-Lotterie. Also aus technischer Sicht also alles perfekt!

Allerdings werde ich mich wohl schweren Herzens aus steuerlichen Gründen (Stichwort: Gewerbe) mit dem Shanghai Update aus dem aktiven Staking ("Forging") verabschieden und ins Rocketpool Lager als steuerlich privilegierter passiver Staker wechseln.

Ich nutze für den Consensus Layer prysm auf einem zweiten Raspi (Mit einer Samsung T7, dort kein Problem)
 

Geth läuft mit folgenden Parametern: 

ARGS="--metrics --metrics.expensive --pprof --http --http.addr 0.0.0.0 --http.api 'eth,net,engine,admin,web3' --cache=1024 --authrpc.jwtsecret=/home/jwt.hex --authrpc.addr=192.168.0.xxx --authrpc.port=8551 --authrpc.vhosts 192.168.0.yyy"

xxx=IP geth

yyy=IP prysm

CPU Auslastung liegt unter 50%, meist so 33%. RAM ist zu 75% ausgelastet.

Mein 8 GB- Raspi läuft mit Ubuntu Server + Geth 1.10.23 nach mehreren erfolglosen Versuchen mit unterschiedlichen (M.2) SSDs nun mit der Samsung EVO 870 und einem Startech SATA Adapter extrem stabil. Sync war innerhalb 2-3 Tagen durch, seitdem keine Probleme mit dem Setup. Gib den Raspi nicht auf! 😉  

Am 7.9.2022 um 17:40 schrieb Cookies statt Coins^^:

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..

Ist Geth inzwischen synchronisiert? Ich war vom Geth Bug 1.10.22 betroffen und nach dem Zurücksetzen der Datenbank steckt Geth nun schon sehr lange beim State Heal Prozess fest.

Ich hatte auch Probleme mit der Stabilität mit M.2 SSDs. Dein Tip mit der Anpassung der /boot/config.txt läuft wohl leider für den Pi 4 ins Leere, weil er wohl schon standardmäßig 1.2A am USB Port bereitstellt. 

Ganz so entspannt bzgl. des Solo Home Staking ("Forging" lt. BMF) sehe ich es nicht. Nach dem Wortlaut des BMF-Schreibens liegt auch ohne Erreichen einer "Gewerbesteuer-Gewinngrenze", eine zu wiederlegende Annahme eines Gewerbes vor.

Für die Staking-Erträge wohl trotzdem steuerlich egal, wenn diese regelmäßig (kurz nach Zugang) veräußert werden. Aber was ist dann mit Gewinnen des Stakes (32 ETH)? Ist dieser Gewinn dann auch zu versteuern, weil gewerblich? Für mich wäre das das KO für Solo Staking in Deutschland. 

vor 18 Stunden schrieb Cookies statt Coins^^:

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/

Ich stecke in einer ähnlichen Situation. Habe auch seit Genesis prysm auf einem Raspi 4 laufen. Auf einem zweiten Raspi 4 läuft inzwischen Geth. 1-2x am Tag wird eine Attestation versäumt. Ansonsten habe ich auch schon insgesamt zwei Proposals verpasst. 

Mich treibt aktuell insbesondere das aktuelle Krypto BMF Schreiben um. Ich habe im Steuerthread dazu gerade mal meine Überlegungen dargestellt. Was sagst du dazu?

Meine aktuellen Überlegungen zu dem Thema:

• Bis nach dem Merge kein Zugriff auf die rewards möglich
• Zusätzlich Unsicherheit, ob Merge überhaupt funktioniert, Totalverlust ist also möglich
• Daher steuerlich bislang kein Zufluss
• Weil bisher keine Erträge/Gewinne zugeflossen sind, ist das Ganze "Liebhaberei", d.h. kein Gewerbe
• Wenn nach dem Merge Zugriff auf den Stake plus rewards möglich sein wird, steuerlicher Zufluss (=Anschaffungsvorgang) und damit Versteuerung der rewards (mit dem dann gültigen Tageskurs!?)
• Es entsteht m.E. dann bei Weiterbetrieb der Node eine gewerbliche Tätigkeit nach Rz 35-39 des BMF Schreibens
• Für ich bedeutet das dann das Ende des aktiven Stakings mit eigener Node (="Forging") und ein Wechsel in den privaten Bereich z.B. durch ein Staking z. B. bei Kraken o.ä. (Was natürlich dem Gedanken der Dezentralität diametral entgegen steht)

Nachvollziehbar? Meinungen dazu?

Nach ein bisschen weiterer Internetrecherche deutet für mich doch vieles auf eine Gewerblichkeit des Ethereums Staking hin, wenn dieses mit eigener node (z.B. prysm) erfolgt. Also "Forging" im BMF Sprech. Spätestens nach dem Merge. Bis dahin kann man evtl. argumentieren, dass auf die Rewards nicht zugegriffen werden kann. 

z.B. https://pekuna.de/18-spannende-punkte-zum-bmf-schreiben-fur-krypto-steuer/

Würde der 32-ETH-Stake dann eigentlich in das "Betriebsvermögen" wandern? Mit der Konsequenz, bei Ende des Forgings "Rückbuchung" in das Privatvermögen mit entsprechenden steuerlichen Konsequenzen, d.h. Versteuerung eines evtl. zwischenzeitlichen Gewinns?  

Ich lese das aus den Ziffern 35-39 heraus.

Nach dem aktuellen BMF Schreiben wird das sog. Forging, also durch das Betreiben eines Ethereum Staking Nodes eine gewerbliche Tätigkeit vermutet. Welche Argumente könnte man gegen diese Vermutung anbringen? Hat da jemand eine Idee?  

Verstehe ich das BMF Schreiben richtig, dass man mit dem Betreiben eines eigenen Ethereum Validators grundsätzlich als Gewerbetreibender eingestuft wird?