skunk

Wie sieht der Fall aus wenn ich nie die Grundausbildung durchlaufen habe? Können sie mich trotzdem einziehen? Selbst die Musterung habe ich nie komplett abgeschlossen. Habe ich damit einen Freifahrtschein? Nicht wenn er innerhalb der EU bleibt. Wobei das bei einem eskalierenden Krieg vermutlich komplett mit reingezogen wird und nicht nur Deutschland. Es gibt aber noch andere Konstellation. AfD kommt an die Macht und möchte aus der EU austreten. Das wären gleich zwei gute Gründe noch schnell in ein anderes EU Land umzusiedeln. Und solange Deutschland noch Teil der EU ist, wäre man erstmal kein Flüchtling sondern EU Bürger mit entsprechenden Rechten.

Ich stimme dir in allen anderen Punkten zu würde jedoch eine Sache hinzufügen. Auch ein zentrales Exchange, dass nicht mit den Kundengeldern Staked kann in Schieflage geraten. Also Grundsätzlich besteht das Risiko einer Insolvenz ja immer. Hier nur zusätzlich durch eine Art 51% Angriffs bei dem die Exchange ebenfalls Kundengelder verlieren kann. Ich zahle ETH ein, verkaufe gegen BTC, zahle die BTC sofort aus und später stellt sich raus meine Einzahlung hat auf der fehlerfreien Chain nie stattgefunden aber die BTC sind dennoch weg. Jedes Exchange, dass das nicht aus eigener Tasche ausgleichen kann, müsste in der Folge Insolvenz anmelden. Edit: Wer seine ETH auf einem Hardware Wallet lagert, dürfte vor dem gröbsten sicher sein. Der ETH wird vielleicht massiv an Wert verlieren aber das heißt ja nur, dass man kostengünstig nachkaufen kann. Einfach den Sturm abwarten mit der Gewissheit auf beiden Chains seine ETH liegen zu haben.

Woran machst du das fest? Ich hätte bis vor 2 Tagen noch behauptet, dass es in den letzten Jahren überhaupt keine Ausfälle gab. Zumindest nicht, dass ich davon etwas mitbekommen hätte. Und dann lese ich, dass vor 2 Wochen einer der Execution Clients für mehrere Stunden offline war: https://github.com/NethermindEth/nethermind/issues/6588 In dem Fall hat der Execution Client einen eigentlich validen Block für invalide erklärt und war dann unfähig der Chain weiter zu folgen. Das ist schon verdammt dicht dran an dem Worst Case Szenario. Und wie man so ließt ist das nicht das erste Problem dieser Art. Hier mal eine grobe Liste was so alles passiert ist: Besu: Geth: Und dann ist irgendwann Anfang 2023 einer der Consensus Clients ausgefallen und es gab ein Blockchain Reorg in einem Ausmaß was mathematisch ebenfalls für unmöglich gehalten wurde. Nach der langen Liste habe ich eher das Gefühl, dass dieses hypothetische Szenario bereits häufiger eingetreten ist als mir überhaupt bewusst war. Ich habe diese Events zwar mitbekommen aber weil sie nicht meinen Execution Client betrafen habe ich mir das nicht weiter durchgelesen. Erst jetzt wird mir bewusst wie knapp wir an dem schlimmsten möglichen Fehler vorbei geschrammt sind und das gleich mehr als einmal.... Da fehlt mir auch die Fantasie zu. Nehmen wir vielleicht einfach den Geth Bug von oben als Vorlage. Wenn ich das richtig verstehe gibt es eine Queue für die Auszahlungen der Staking Rewards. Alle paar Tage bekommt der Validator seine Auszahlung. Er kann selbst nicht bestimmen wann das der Fall ist. Es wird einfach durch alle Validatoren durch rotiert. Geth hat das mit den Auszahlungen etwas anders gesehen und damit einen fehlerhaften Block gebaut. Also das weglassen einer Auszahlung die in dem Block hätte enthalten sein müssen. Reicht dir das als Beispiel? Ich habe jetzt noch nicht verfolgt ob es bereits damals eine 2/3 Mehrheit für Geth gab und wenn ja welcher Schaden genau angerichtet wurde. Wenn es dich interessiert könnte ich mal schauen ob ich noch weiter Infos finde. Vom Ablauf her scheint es so zu sein, dass der Consensus Client den fehlerhaften Block bekommt und diesen vom Execution Client prüfen lässt. Sollte der Execution Client einen Fehler zurück melden, wird der Consensus Client diese Chain nicht weiter verfolgen können völlig egal ob mit oder ohne 2/3 Mehrheit. Müsste exakt die Situation aus dem ersten Github Ticket bei Nethermind sein. In dem Fall war Nethermind jetzt im Unrecht aber das Prinzip ist das gleich. Nethermind sieht die 2/3 Mehrheit der anderen Chain aber setzt sich wegen des darin enthaltenen invaliden Blocks darüber hinweg und würde im weiteren Verlauf ohne menschlichen Eingriff theoretisch seine eigene Blockchain weiter pflegen. Der Mensch vor der Maschine bestimmt am Ende welche der beiden Chains die richtige ist.

Erigon hat sich bei mir jetzt dauerhaft verabschiedet. Ich habe 3 mal versucht es nochmal von 0 zu Syncen aber alles ohne Erfolg. Ich mit den Problemen nicht alleine. Ursache ist wohl, dass das Entwickler Team die Fehler nicht behebt sondern als Universale Lösung für alle Fehler immer "alles Plattmachen und nochmal neu aufsetzen" drunter schreibt. Mit der Zeit summieren sich so die Fehler im Code sodass es mir inzwischen unmöglich ist Erigon noch lauffähig zu bekommen. Glücklicherweise hat Nimbus (wie vermutlich auch die meisten anderen Consensus Clients) die Möglichkeit sich mit mehreren Execution Clients zu verbinden. Ich habe zeitweise Geth aufgesetzt um damit überhaupt erst die Möglichkeit zu bekommen alle denkbaren Varianten mit Erigon durchspielen zu können. Ich habe inzwischen auf Nethermind umgestellt. Der Initiale Sync kam mir bei Nethermind stellenweise etwas Resourcen Intensiv vor. Keine Ahnung wie sich das auf einem Single Board Computer auswirken würde. Der Sync war ansonsten vergleichbar schnell wie Geth und nach fertigen Sync verbraucht Nethermind auch angenehm wenig Resourcen. Von daher würde ich es als Geth Alternative durchaus empfehlen. Außerdem erlaubt mir Nethermind praktisch zur Laufzeit ein Backup anzulegen. Ich habe jetzt ein rsync bzw rclone Job, der mir ein Backup meines Nethermind Verzeichnis auf HDD ablegt. Der erste Durchlauf dauert einige Stunden aber ohne Downtime. Danach führe ich es noch ein zweites mal aus um die in den Stunden veränderten Daten abzugleichen. Das dauert dann einige Minuten. Für den letzten Durchlauf stoppe ich Nethermind kurz und mache den finalen Durchlauf. Dabei werden nochmal ein paar wenige Dateien kopiert, die vorher mit Fehlermeldungen übersprungen wurde. Der letzte Durchlauf dauert nur wenige Sekunden und im Anschluss kann ich Nethermind sofort wieder starten. Es ist also nicht komplett ohne Downtime aber dennoch dicht genug dran um es als "praktisch zur Laufzeit" zu bezeichnen. Das Spiel sollte auch mit jedem anderen Execution Client funktionieren. Natürlich kann ich Nethermind von HDD nicht starten. Im Ernstfall kann ich das Backup aber in recht kurzer Zeit zurück auf die SSD kopieren und bin damit schneller als bei einem kompletten Resync. Ich möchte zu der Sicherheitskopie auf der SSD immer auch eine weitere Kopie auf der HDD vorhalten. Nachdem ich 3 mal kein Glück mit Erigon hatte, würde ich auch bei allen anderen Execution Clients mit mehreren Durchläufen rechnen bei dem die Sicherheitskopie auf der SSD jedes mal unbrauchbar wird und ich vor dem nächsten Anlauf die Daten von der HDD zur Korrektur heranziehen muss. Diese Backup Strategie sollte auch bei den meisten anderen Execution Clients funktionieren. Es gibt inzwischen Anleitungen für jeden Execution Client. Ich kann euch nur empfehlen euch für den Erstfall vorzubereiten. Für dieses Jahr sind einige Code Änderungen geplant. Damit steigt auch das Risiko neue Fehler einzubauen. Noch auf meiner ToDo Liste steht Besu. Ich habe mit meiner 8 TB SSD genug Speicher für solche Spielerein dann will ich die Chance auch nutzen. 2 Backups sind besser als eines... Edit: Falls es jemand braucht: rclone sync /mnt/ssd/eth/nethermind /mnt/hdd/eth/nethermind-backup --create-empty-src-dirs -P --transfers 4 --checkers 8 Die letzen beiden Parameter einfach so anpassen, dass der Job den noch laufenden Validator nicht stört. Den ganzen Prozess mit einem geringeren Nice Level zu starten können auch hilfreich sein.

Der Payload ist auch weiterhin der Block. In der Dokumentation steht sogar die Funktion drin, die im Ernstfall den Block bauen würde. engine_getPayloadV2 mit folgenden Rückgabeparametern: { "id": 1, "jsonrpc": "2.0", "result": { "executionPayload": { "parentHash": "0x3b8fb240d288781d4aac94d3fd16809ee413bc99294a085798a589dae51ddd4a", "feeRecipient": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "stateRoot": "0xca3149fa9e37db08d1cd49c9061db1002ef1cd58db2210f2115c8c989b2bdf45", "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "prevRandao": "0xc130d5e63c61c935f6089e61140ca9136172677cf6aa5800dcc1cf0a02152a14", "blockNumber": "0x112720f", "gasLimit": "0x1c9c380", "gasUsed": "0xbad2e8", "timestamp": "0x64e7785b", "extraData": "0x", "baseFeePerGas": "0x7", "blockHash": "0x1256f99fb899c2de0aeac0c5aa6aad69de188b6a0f4ac29f2d075a53aa3ed0e4", "transactions": [ "0x03f88f0780843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a0010657f37554c781402a22917dee2f75def7ab966d7b770905398eba3c44401401a0840650aa8f74d2b07f40067dc33b715078d73422f01da17abdbd11e02bbdfda9a04b2260f6022bf53eadb337b3e59514936f7317d872defb891a708ee279bdca90", "0x03f88f0701843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001521d528ad0c760354a4f0496776cf14a92fe1fb5d50e959dcea1a489c7c83101a0a86c1fd8c2e74820686937f5c1bfe836e2fb622ac9fcbebdc4ab4357f2dbbc61a05c3b2b44ff8252f78d70aeb33f8ba09beaeadad1b376a57d34fa720bbc4a18ee", "0x03f88f0702843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001453362c360fdd8832e3539d463e6d64b2ee320ac6a08885df6083644a063e701a037a728aec08aefffa702a2ca620db89caf3e46ab7f25f7646fc951510991badca065d846f046357af39bb739b161233fce73ddfe0bb87f2d28ef60dfe6dbb0128d" ], "withdrawals": [ { "index": "0xf0", "validatorIndex": "0xf0", "address": "0x00000000000000000000000000000000000010f0", "amount": "0x1" }, { "index": "0xf1", "validatorIndex": "0xf1", "address": "0x00000000000000000000000000000000000010f1", "amount": "0x1" } ] }, "blockValue": "0x10a741a46278014d" } } Parent Hash, Block Number, Block Hash, Transactions usw. Ich sehe nicht ein einziges Feld was dort fehlen würde. Der Execution Client liefert einen fertigen Block an den Consensus Client. Genau dafür ist die 2/3 Mehrheit da. Jeder Validator schaut sich den neuen Block an stimmt ihm zu oder verweigert seine Zustimmung. Nur wenn 2/3 aller Validatoren den Block als fehlerfrei ansehen, wird er Teil der Blockchain. Wegen der hohen Geth Dominanz kann es passieren, dass auch ein fehlerhafter Block die 2/3 Mehrheit bekommen könnte. Wenn die Geth Dominanz auf ein gesundes Maß reduziert wird, würde die 2/3 Mehrheit ausbleiben und damit hätten dann alle Gewissheit.

Sieht so aus als müssten wir vielleicht gar nicht so lange warten bis die Geth Dominanz reduziert wird. Einige der Pools stellen gerade um: https://blockworks.co/news/ethereum-geth-client-diversity Hintergrund ist, dass vor 2 Wochen einer der Execution Clients tatsächlich ausgefallen ist. Nur kurz und zum Glück einer der Minderheiten Clients. Der Warnschuss wurde gehört und jetzt handeln die Pools. Wenn noch ein paar mehr folgen, könnten wir es unter die 66% schaffen. @Drayton ^ Das ist zugleich auch der Beweis, dass der Execution Client nicht so unwichtig ist wie du bisher glaubst. Wenn du diesem Bericht nicht glaubst dann findest du über die letzten 2 Wochen verteilt noch ganz viele andere davon. Alle mit der gleichen Botschaft.

Ja ich meine den Menschen vor der Maschine. Ich kann dir nicht ganz folgen. In einer perfekten Welt ohne Geth Dominanz würde im Fehlerfall die Finalisierung einfach zeitweise ausbleiben. Selbst wenn es zu einem Chainsplit kommt, würde keine der beiden Chains die Finalisierung erlangen. Der Vorteil ist, dass sofort alle Nodes im Netzwerk gewarnt sind. Binance könnte zum Beispiel Deposits kurzzeitig pausieren und das völlig automatisch in dem Moment in dem der Chainsplit stattfindet. Die erhöhten Strafen für die Validatoren sollen dafür sorgen, dass sie sich zügig darauf einigen welche der beiden Chains jetzt die richtige ist. Die fehlerhaften Validatoren installieren ein Update, innerhalb von Stunden funktioniert die Finalisierung wieder und das ist das Signal für alle anderen Nodes genau dieser Chain zu folgen. Problematisch wird das ganze erst in Verbindung mit einer zu hohen Geth Dominanz. Dann ist eine der beiden Chains durchgängig Finalisiert und dieser Schutzmechanismus greift nicht. Ab da wird es dann Spaßig...

Nein und Ja. Ich bin kein Freund von CoinTracking hauptsächlich wegen der ungenügenden Validierung meiner Daten und nutze stattdessen ein anderes Steuertool. Das Prinzip ist aber das Gleiche. Ich übertrage die Zahlen in meine Steuererklärung und gebe den Steuerreport mit ab.

Der Satz ging mir seit 2 Tagen nicht mehr aus dem Kopf. Ähnlich haben es auch @chip und @mahatma formuliert. Es hat eine Weile gedauert aber ich habe endlich eine für mich zufriedenstellende Antwort gefunden. Etwas übertrieben formuliert: Man hat schlicht die Ignoranz und Bequemlichkeit der Validatoren unterschätz. Der Fehler liegt nicht im Protokoll sondern im Verhalten der Validatoren. Würden sie sich so verhalten wie es von ihnen erwartet wird, hätten wir das Problem nicht. Ich würde sogar soweit gehen und behaupten Ethereum ist die Beste aller möglichen PoS Implementierungen. Ethereum macht es richtig und spricht den menschlichen Faktor offen an. Es liegt an uns das Protokoll vollumfänglich zu erfüllen und damit das Problem dauerhaft zu beseitigen. Zugegeben ich habe wenig Hoffnung, dass die Geth Dominanz so schnell gebrochen wird. Wenn man genau hinhört dann ist den Validatoren das Problem zwar teilweise bewusst aber noch überwiegen andere Überlegungen. Einfaches Setup, vertrauter Client oder auch "ich wähle den Pool mit den geringsten Gebühren für maximalen Profit". Ich habe bisher noch niemanden gehört der einen Pool danach ausgewählt hätte welcher Execution Client im Hintergrund läuft. Ich habe inzwischen meine lokale Geth Node erfolgreich gegen Nethermind ausgetauscht. Bisher sieht es positiv aus. Vielleicht erledigt sich das Problem langfristig von selbst. Es bedarf nur etwas mehr Wissenstransfer. So oder so sehe ich die Situation positiv. Mein aktuelles Investment in ETH ist klein genug um einen Totalverlust zu verkraften. Gleichzeitig ist es groß genug um dafür extra eine Full Node aufzusetzen und aktiv zu hinterfragen wie gut PoS wirklich ist und welche Probleme noch gelöst werden müssen. Ich werde mein kleines ETH Investment wohl noch etwas halten einfach um ein Grund zu haben mich weiter mit dem Thema beschäftigen. Etwas Weiterbildung schadet nie. Ich erhoffe mir davon einen Wissensvorsprung den ich irgendwann in der Zukunft wieder zu Geld machen kann. Ich muss mich die Tage etwas mehr mit Danksharding bzw Layer 2 beschäftigen. Da habe ich noch viele ungeklärte Fragen.

Das steht in deiner Tabelle. Der Payload ist der Block. Der Consensus Client kann nicht entscheiden ob ein Block valide ist oder nicht. Er ist zwingend auf die Mithilfe des Execution Clients angewiesen. MEV ist eine Ausnahme. Beim MEV wird ein Block erst blind vorgeschlagen, dann validiert und notfalls wenn er invalide sein sollte nicht weiter im Netzwerk verbreitet. In dem Fall geht der Validator einfach nur leer aus aber ansonsten gibt es keine Nachwirkungen. Problematisch wird es wenn der Geth Client einen invaliden Block als valide anerkennt. Ab da wird es dann lustig.... Edit: Du siehst die Validierung der Blöcke auch in den Logs meines Execution Clients. engine_newPayloadV2 kannst du hier nachschlagen: https://ethereum.github.io/execution-apis/api-documentation/ Dort steht dann Runs Execution Payload Validation mit folgenden Request Parametern: { "id": 1, "jsonrpc": "2.0", "method": "engine_newPayloadV2", "params": [ { "parentHash": "0x3b8fb240d288781d4aac94d3fd16809ee413bc99294a085798a589dae51ddd4a", "feeRecipient": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "stateRoot": "0xca3149fa9e37db08d1cd49c9061db1002ef1cd58db2210f2115c8c989b2bdf45", "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "prevRandao": "0xc130d5e63c61c935f6089e61140ca9136172677cf6aa5800dcc1cf0a02152a14", "blockNumber": "0x112720f", "gasLimit": "0x1c9c380", "gasUsed": "0xbad2e8", "timestamp": "0x64e7785b", "extraData": "0x", "baseFeePerGas": "0x7", "blockHash": "0x3559e851470f6e7bbed1db474980683e8c315bfce99b2a6ef47c057c04de7858", "transactions": [ "0x03f88f0780843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a0010657f37554c781402a22917dee2f75def7ab966d7b770905398eba3c44401401a0840650aa8f74d2b07f40067dc33b715078d73422f01da17abdbd11e02bbdfda9a04b2260f6022bf53eadb337b3e59514936f7317d872defb891a708ee279bdca90", "0x03f88f0701843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001521d528ad0c760354a4f0496776cf14a92fe1fb5d50e959dcea1a489c7c83101a0a86c1fd8c2e74820686937f5c1bfe836e2fb622ac9fcbebdc4ab4357f2dbbc61a05c3b2b44ff8252f78d70aeb33f8ba09beaeadad1b376a57d34fa720bbc4a18ee", "0x03f88f0702843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001453362c360fdd8832e3539d463e6d64b2ee320ac6a08885df6083644a063e701a037a728aec08aefffa702a2ca620db89caf3e46ab7f25f7646fc951510991badca065d846f046357af39bb739b161233fce73ddfe0bb87f2d28ef60dfe6dbb0128d" ], "withdrawals": [ { "index": "0xf0", "validatorIndex": "0xf0", "address": "0x00000000000000000000000000000000000010f0", "amount": "0x1" }, { "index": "0xf1", "validatorIndex": "0xf1", "address": "0x00000000000000000000000000000000000010f1", "amount": "0x1" } ] } ] }

Der Consensus Client hat keine Möglichkeit ankommende Blöcke zu validieren. Er fragt Geth ob der Block valide ist. Er muss Geth fragen weil ihm selbst die Möglichkeit fehlt den Block inhaltlich zu prüfen. Zum Beispiel könnte ein Transaktion einen fehlerhaften Nonce beinhalten. Solche Fehler kann der Consensus Client nicht erkennen und ist auf die Mithilfe des Execution Clients angewiesen. Und wenn der Geth Client den fehlerhaften Block als fehlerfrei zurück meldet dann fängt der Spaß mit der 2/3 Mehrheit an. In deiner eigenen Tabelle steht "Create execution payload" drin. Der Execution Client baut den Block oder alternativ MEV. Der Consensus Client übernimmt dann die Abstimmung mit den anderen Consensus Clients. Der Execution Client verwaltet auch die Blöcke. Hier mal Logs von meiner Nethermind Node: 03 Feb 00:27:13 | ***** JSON RPC report ***** ------------------------------------------------------------------------------------------------------------------------------------------------------------- method | successes | avg time (µs) | max time (µs) | errors | avg time (µs) | max time (µs) | avg size | total size | ------------------------------------------------------------------------------------------------------------------------------------------------------------- engine_exchangeTransitionConfigurationV1| 5 | 66 | 74 | 0 | 0 | 0 | 204 | 1020 | engine_forkchoiceUpdatedV2 | 26 | 1471 | 12459 | 0 | 0 | 0 | 199 | 5173 | engine_newPayloadV2 | 26 | 197349 | 404753 | 0 | 0 | 0 | 164 | 4263 | eth_getBlockByNumber | 44 | 175 | 841 | 0 | 0 | 0 | 14582 | 641590 | eth_getLogs | 22 | 157 | 580 | 0 | 0 | 0 | 38 | 835 | ------------------------------------------------------------------------------------------------------------------------------------------------------------- TOTAL | 123 | 42120 | 404753 | 0 | 0 | 0 | 5308 | 652881 | ------------------------------------------------------------------------------------------------------------------------------------------------------------- eth_getBlockByNumber macht genau das was der Name schon sagt. Damit kann man den Execution Client um die Herausgabe jedes Blockes bitten. Schau nochmal in deine Tabelle. Ein Validator hat keine Peers. Effektiv läuft es wie folgt: Beim Start meldet der Validator sich bei seinem Consensus Client mit seinem Public Key. Der Consensus Client filtert aus den eingehenden Events alle raus die diesen Public Key betreffen. Der Conensus Client merkt darüber auch wann es Zeit ist einen Block vorzuschlagen. Der Consensus Client kann sich wahlweise von MEV einen Block geben lassen oder den Execution Client bitten einen Block mit den im Mempool enthaltenen Transaktionen zu bauen. In der Regel wird MEV mehr Gewinn abwerfen. Um diesen Block vorschlagen zu können muss der Validator mit seinem Private Key eine Runde signieren. Der Consensus Client verteilt diese Signatur im Netzwerk an alle anderen Consensus Clients. Zustimmung zu diesem neuen Block verläuft genauso ab. Der Consensus Client meldet sich beim Validator wenn es Zeit wird etwas zu signieren.

Der Consensus Client stimmt dem fehlerhaften Block zu und wegen der 2/3 Mehrheit gibt es dann erstmal kein Zurück. Genau aus diesem Grund wird in der offiziellen Dokumentation vor der Geth Dominanz gewarnt mit der Bitte doch einen der anderen Alternativen zu benutzen. Danke, dass du es direkt selbst zugibst.... Die Panik habe ich auch zuvor bereits relativiert. Wir reden hier von den ganz normalen Risiken und Nebenwirkungen von PoS. Ich finde es sogar vorbildlich wie offen und ehrlich Ethereum damit umgeht. Es hilft nicht das Risiko zu verschweigen so wie das andere Blockchains gerne machen. Dann lieber ganz offen und ehrlich in die Dokumentation schreiben. Das gibt mir die Möglichkeit entsprechende Vorsichtsmaßnahmen zu ergreifen.

Es steht in der offiziellen Dokumentation. Ich hatte es bereits verlinkt und sehe keinen Sinn darin den Link jetzt immer wieder zu wiederholen nur weil du noch nicht einmal die offizielle Dokumentation anerkennen willst. Natürlich bekommst du dafür einen Downvote. Auch finde ich es schwach, dass du nicht mal eine Full Node hast. Du weißt ja nicht einmal von welchen Logs ich hier rede. Soll ich sie dir die Logs vielleicht hier rein kopieren?

Ich habe mal wieder ein sehr spezielles Thema für die Gruppe. Bei Startup Unternehmen ist es üblich die Mitarbeiter mit Stock Options zu motivieren. Wenn das Startup Unternehmen irgendwann aufgekauft werden sollte, können diese Stock Options angewendet werden um die Differenz zwischen Ausgabepreis der Stock Options und Kaufpreis des Startups als Gewinn ausgezahlt zu bekommen. Jetzt habe ich den Fall dass mir ein Startup Unternehmen anbietet ein Repricing durchzuführen. Ich habe über die Jahre mehrere Packete bekommen mit unterschiedlichen Ausgabepreisen. Im aktuellen Jahr ist der Ausgabepreis gefallen. Beim Repricing würden die Pakete die einen höheren Ausgabepreis hatten einfach zurück gegeben und im Gegenzug bekomme ich neue Stock Optionen zu dem tieferen Ausgabepreis. Die Vorteile der Aktion verstehe ich. Sollte die Firma aufgekauft werden, bekomme ich auch mehr Gewinn raus. Die restlichen Konditionen sind auch alle gleich. Es wird tatsächlich nur der Preis reduziert. Was ich nicht verstehe sind die Nachteile. Meine US Kollegen fangen jetzt an zu rechnen weil sie teilweise ISO bekommen haben. Das Repricing hat für sie Auswirkungen auf die zu zahlenden Steuern. Ich habe ausschließlich NSO, die davon wohl nicht betroffen sein dürften? Ich habe von dem Thema keine Ahnung und würde mich freuen wenn mich jemand an die Hand nehmen könnte und mir das erklären könnte.

Weil praktisch auf jeder Seite davor gewarnt wird. Weil es in sämtlichen Dokumentationen steht. Und wegen den Logs meiner Full Node.

Weil praktisch auf jeder Seite davor gewarnt wird. Weil es in sämtlichen Dokumentationen steht. Und wegen den Logs meiner Full Node.

Ja ich würde das als Normal bezeichnen. Zu viel Nachfrage bei zu geringem Angebot. Praktisch alle mir bekannten Steuerberater, die sich auch mit Kryptowährungen auskennen, sind überlaufen und kommen mit der Abarbeitung nur schwer hinterher. Meine Lösung: Ich mach den Spaß jetzt selbst. Ich fange damit natürlich nicht erst am Jahresende an sondern setze mich mehrmals im laufenden Jahr hin um meine Buchungen glatt zu ziehen und schon mal probeweise einen Steuerreport zu ziehen. Am Jahresende habe ich dann bereits alles fertig und kann meine Steuererklärung zeitnah abgeben. Funktioniert natürlich nur wenn alle Unklarheiten durch den Steuerberater beseitigt wurden. Bei mir gab es zum Beispiel ein paar Bonus Zahlungen bei denen ich nicht wusste wie diese zu versteuern wären. Das hat mein Steuerberater einmalig sowohl dem Finanzamt als auch mir erklärt und ich wiederhole die dafür notwendigen Schritte einfach nur jedes Jahr. Wenn man einmal verstanden hat wie das funktioniert, verliert das Thema seinen Schrecken. Letzte Jahr ist bei mir Cashback mit dazu gekommen. Es gibt Anleitungen wie man diese Transaktionen zu versteuern hat. Plötzlich ergeben diese Anleitungen einen Sinn und man versteht auch wie es in der eigenen Steuererklärung auszusehen hat.

Ok halten wir fest. Du kaufst keine Coins und ich kaufe keine Coin. Ich glaube du hast noch nicht verstanden wie der Marktpreis gebildet wird....

Dafür wird es im Ernstfall zu spät sein. Die 2/3 Mehrheit signalisiert allen im Netzwerk, dass die falsche Chain vermeintlich fehlerfrei ist. Das heißt auch die großen Exchanges, Blockexplorer, Wallets usw werden alle auf die falsche Chain blicken sofern sie ebenfalls auf Geth aufbauen. Da werden Stunden ins Land gehen bis das überhaupt an alle Kommuniziert wurde. Genug Zeit um einiges an Schaden anzurichten. Nur mal als Beispiel. Ich zahle meine ETH bei Binance ein. Wegen der 2/3 Mehrheit muss Binance annehmen meine Transaktion hätte genug Bestätigungen sodass ich sie gegen BTC verkaufen darf. Die BTC zahle ich selbstverständlich unverzüglich an mein Hardware Wallet aus. Du bist mein Handelspartner und freust dich darüber. Sagen wir du verkaufst deine 0,6 BTC und bekommst von mir 100 ETH dafür. Ein überaus verlockender Deal zu dem du sicherlich nicht nein sagen wirst. Irgendwann updatet Binance seine Geth Node und schwenkt damit auf die fehlerfreie Chain um auf der die ETH weiterhin beim mir liegen. Effektiv hast du mir deine 0,6 BTC geschenkt. Wenn du Glück hast, wird Binance dich entschädigen. Wenn du Pech hast, stehst du am Ende ohne ETH und ohne BTC da und hast beides verloren. Das fällt mir zunehmend schwerer. Ich schwanke zwischen Aufklärung und "Dont feed the Troll". Du hast keine Full Node am Laufen bildest dir aber trotzdem ein mehr darüber zu verstehen als alle anderen hier. Wenn meine Begründungen bisher nicht bei dir gefruchtet haben, dann werde ich auch durch Wiederholungen nicht zu dir vordringen können. Ich sehe mich auch nicht in der Pflicht dazu. Wenn du Fragen hast, beantworte ich sie gern. Wenn du weiterhin falsche Behauptungen aufstellen möchtest, werde ich auch weiterhin auf die Wiedersprüche hinweisen. Soll das jetzt ein billiges Wortspiel werden? Ohne Execution Client funktioniert der Validator nicht. Und aktuell wird dafür leider viel zu häufig Geth eingesetzt.

Ich habe die Coins nicht ohne Grund als wertlos bezeichnet

Einfach alles. Ich habe das Gefühl dir ist nicht bewusst wie Execution und Consensus Client ineinander greifen. Setz gern mal eine eigene Full Node auf dann dürfte es klar werden. Wenn 2/3 aller Validatoren von ihren Geth Nodes den gleichen invaliden Block zur Abstimmung vorgelegt bekommen, stimmen sie selbstverständlich zu mit allen daraus resultierenden Konsequenzen sowohl für den Validator selbst als auch für alle Exchanges, Blockexplorer usw die zufällig ebenfalls Geth im Einsatz haben.

Weil das interne Wallet Closed Source ist und auch maximal entfernt von Dezentralität. Wertlose Coins kaufen? Wozu? Ich kann mir recht billig selbst ERC-20 Token drucken...

Das ist schlicht falsch. Jeder Validator braucht einen Execution Client. Wie am Namen unschwer zu erkennen ist der Consensus Client für die Abstimmung mit den Validatoren zuständig und der Execution Client schreibt die eigentliche Blockchain fort. Ohne Execution Client hat der Consensus Client nichts zum Abstimmen. Und mit einem fehlerhaften Execution Client bekommt der Consensus Client unter Umständen falsche Blöcke zur Abstimmung. Rate was der Consensus Client machen wird... Die Abhängigkeit geht in beide Richtungen. Seit dem Umstieg auf PoS ist auch der Execution Client auf den Consensus Client angewiesen. Das bedeutet wenn der schlimmste anzunehmende Fall eintrifft und die Validatoren ihre Zustimmung auf einen fehlerhaften Block erteilen, wäre das komplette Netzwerk betroffen. Die einzigen, die den fehlerhaften Block erkennen würden wären die Minderheiten Clients. Der Grund warum die Berichte sich damit nicht beschäftigen ist recht einfach. Die Validatoren sind wichtiger als der Rest vom Netzwerk. Hätten wir bei den Validatoren keine kritischen Mehrheiten, könnte der Rest vom Netzwerk zu 100% auf Geth setzen. Im Fehlerfall bleibt die 2/3 Mehrheit aus und alles verläuft nach Plan. Jetzt haben wir aber leider bereits eine 2/3 Mehrheit bei den Validatoren. Der Rest vom Netzwerk kann sich somit nicht mehr auf den Schutz der 2/3 Mehrheiten verlassen. Wenn wir diesen Zustand noch etwas länger beibehalten würde ich in Zukunft auch Berichtet bezüglich der zusätzlichen Risiken und Nebenwirkungen dieser neuen Situation erwarten. So schwer ist es ja nicht sich vorzustellen was die eigene Geth Node daheim in der Situation machen wird. Sie folgt natürlich der 2/3 Mehrheit und wird damit ebenfalls zum Risiko auch ohne angeschlossenen Validator.

Die einzig mir bekannte Lösung wäre PoW. Ich dachte davon wollten wir weg? Vielleicht sollten wir die Kirche lieber im Dorf lassen. Du stellst gerade Forderungen obwohl du keine Full Node betreibst. Das ist in etwa so wie ein Nichtwähler, der sich dann über den Ausgang der Wahl beklagt. Du selbst kannst jederzeit etwas an dem Problem ändern. Ich fordere daher eine Stellungnahme von dir was dich daran hindert selbst die Geth Dominanz zu reduzieren. Ganz so einfach wegdiskutieren lassen sich die Probleme auch nicht. Das die Geth Dominanz ein Problem ist, steht sogar auf den offiziellen Onboarding Webseiten. Zum Beispiel hier: https://launchpad.ethereum.org/en/geth Und das ist ganz sicher nicht irgend so ein Bericht aus dem Internet. Mir ist praktisch kein einziger Bericht bekannt, der behauptet die Geth Dominanz wäre in Ordnung. Und selbst wenn es nur irgend eine Internet Seite wäre, so müsste ich nochmal auf den DAO Vorfall hinweisen. Damals waren es eine Handvoll von Stimmen, die auf die Probleme des DAO hingewiesen haben. Einige haben das ernstgenommen und haben sich selbst Gedanken gemacht und andere eben nicht...

Du bist sehr dicht dran. Es fehlt nur ein kleines Detail. Die Geth Nodes und die Nicht Geth Nodes haben nach dem Hardfork eine jeweils eigene Blockchain auf der die jeweils anderen Clients scheinbar offline sind. Die Strafen sind nur asymmetrisch verteilt. Die Geth Node bekommt die deutlich teurere Strafe während es den Nicht Geth Nodes fast schon egal sein kann ob sie im Recht oder Unrecht sind. Auch gibt es Unterschiede bei der Frage wie schnell die Geth Nodes und die Nicht Geth Nodes sich ihrer Situation bewusst sind. Die Geth Nodes merken nicht eine falsche Abzweigung genommen zu haben während die Nicht Geth Nodes das sofort erkennen und gegensteuern könnten. Ebenfalls können die Geth Nodes einen Fix wegen der schon erteilten Finality nicht so einfach installieren während die Nicht Geth Nodes dank der ausbleibenden Finality jederzeit einen Fix installieren und vermutlich mit minimalen Nacharbeiten wieder lauffähig währen. Das Protkoll sieht so einen Bugfix durchaus vor nur eben nur solange keine Finality erreicht wurde. Das ganze ist jetzt vom Blickwinkel der jeweiligen Clients beschrieben unter der Annahme, dass die jeweils andere Chain die eigentlich fehlerfreie wäre. Das Risiko für einen solchen Fehler mag 50/50 sein aber die Strafen sind sehr Einseitig zulasten von Geth.