Octagon

Glaub die Importe tun nichts, sind lediglich ein paar Interfaces, und werden gar nie benutzt. Der Compiler haut alles raus, was nicht benutzt wird. Rudimentärer Decompiler zeigt, dass nur die start/withdraw public Funktionen da sind, wenn ich das richtig interpretiere. Tja, und woher der swap kommt & warum das Guthaben noch da ist,... steh da grad voll auf dem Schlauch. Fallback ist auch keins implementiert. Interessant.

Hab mit genau dem selben snippet rumgespielt welches @sladostrastnik oben gepostet hat. MyContract & MyContractResolver

Vermutlich failed die Transaction, deshalb. Kurzer Test: Falls du von MyContractResolver die Funktion aufrufst gehts nicht. Denn: modifier onlyCreator() { require(msg.sender == creator, "Only contract creator can call this function."); _; } Das require wird fehlschlagen, da msg.sender != creator. Wenn so aufgerufen ist msg.sender der callende contract und nicht der creator. Ich vermute das es fehlschlägt, und deshalb so hoch anzeigt. Normal ist es höchstens vielleicht ein Euro, wenn die Ausführung klappt, kostet ca. 37k gas, also nicht viel.

Stimmt, habs auch nochmals durchgespielt und bei mir geht das Guthaben bei start sofort raus. Er hat ja start ausgeführt. Hab gedacht, dass es ein revert gewesen ist, weil zu wenig gas, hab das falsch gelesen, aber es ging ja durch und Guthaben ist wirklich noch da. Und einen Tag danach hat eine andere Adresse "swap" ausgeführt. Function: swap(string aggregatorId, address tokenFrom, uint256 amount, bytes data) Das gibts aber gar nicht in diesem Contract !? @sladostrastnik Sicher, dass es der Code von dem Video war? Vielleicht besteht ja noch Hoffnung....

Ja, die Gier,.. kennt wohl jeder... kann ja mal passieren. Ich denke mal, dass er den einen useCase gar nicht bedacht hat und davon ausgeht, dass der User sowieso "start" ausführen wird, da er ja das ganze so weit fertiggestellt hat, und er ja loslegen sollte. Dass der Zufall es will, und nicht mehr genug ETH dafür da sind, war nicht Teil des Plans. Er kann nicht wissen, dass dieser Contract existiert. Soweit gab es keine Funktion, die irgendeine Meldung oder was irgendwohin verschickt beim Deployen. Er ist darauf angewiesen, dass jemand "start" ausführt. Oder er scannt alle neuen Contracts auf ETH, um sie zu suchen. Wird kaum was kosten den transfer auszuführen, würde sich also auf jeden fall lohnen.

Ein Contract ist kein „Vertrag“ im eigentlichen Sinn, den man öffnen/abschließen oder sonst irgendwie als Vertrag behandeln kann. Du musst das ganze so sehen: Es ist schlicht ein Programm. Das grundsätzlich, wenn mal deployed genau das macht was der Code dir oder jemandem anderen erlaubt. Und sonst nichts. Die Grundlage eines Contracts ist eine sehr hohe Sicherheit, die eben dafür sorgt, dass nur EXAKT genau das ausgeführt werden kann, was als code geschrieben ist. Die Idee mit dem „closeContract“ ist nicht verkehrt, kann man sicherlich in einen NEUEN Contract einbauen, falls das irgendeine Funktionalität erfüllen sollte. Aber eben nicht in dem bereits vorhandenen. Dieser ist beriets in Stein gemeißelt und kann GENAU das, wofür er geschrieben worden ist und überhaupt kein bisschen was anderes. Was genau dieser Contract kann, habe ich oben geschrieben. Mann kann sich auf den Kopf stellen, aber es bleibt unmöglich etwas auszuführen, was nicht explizit genau so im code steht. Und eben „vertrag schließen“ gibt es nicht, einen Vertrag gibt es so gesehen nicht. Mann kann vieles in einen Contract bauen, wenn es jetzt aber nicht drin ist, kann man nichts mehr hinzufügen/ändern. Es gibt auch kein „Recht“, das erstellt wurde, welches du hättest auf den Contract. Der Contract weiß eigentlich nichts von dir als „Besitzer“, somit hast du dort auch kein Recht mehr oder weniger als jeder beliebige. Du bist nicht als Besitzer "registriert". WEIL es so im Code drinn steht jetzt. Das ist die Idee von Contracts, das dies eben genau so sein muss, und wenn mal geschrieben nichts geändert werden kann. Wie erwähnt das ist kein „Standard“ Contract, sondern eben genau für diesen Zweck gebaut, den er auch erfüllt hat, und das erfolgreich. Und dabei hast du noch die ganzen Fees/Deployment selbst bezahlt. Stell dir nun vor, du könntest mit deinem Beispiel von „close contract“ so irgendeinen beliebigen Contract schließen. Dann würde ich mal Tether schließen oder so. Das funktioniert so nicht. Falls Tether eine solche Funktion eingebaut hätte, dann aber auch nur mit der Bedingung: nur Ich, der Besitzer, Deployer, oder Adresse XY darf das. Ansonsten kann ja mal jeder kommen… Aber sowas ist nicht Teil des Contracts und deshalb kann man auch nichts machen. Nichts. Vieles erscheint vielleicht nicht ganz so nachvollziehbar, aber das alles sind Grundlagen von solchen „Verträgen“. Im Übrigen habe ich grad bemerkt, vermutlich auch mit Absicht so implementiert, der Scammer kann sich deine Ether sowieso holen. Falls er bereit ist die Gasfee zu bezahlen, kann er selber start oder withdrawl ausführen. JEDER der möchte könnte es, da die Funktion öffentlich ist, und eben nur die vorhandenen ETH transferiert. Egal wer, wie oder was die Funktion aufrufen wird, er bekommt die ETH. Solange er nicht weiß das dieser Contract existiert, passiert nichts, falls er aber irgendwie davon erfährt werden die ETH von alleine verschwinden. Zur Veranschaulichung, wäre eben sowas grundsätzlich notwendig wie in deinem Beisipiel: modifier onlyCreator() { require(msg.sender == creator, "Only contract creator can call this function."); _; } function withdrawal() onlyCreator public payable Jetzt könntest NUR DU auch withdraw/start etc. ausführen. Das wäre „normal“, und so sieht man schon hier überhaut nichts stimmt an dem Zeugs.

Ich habe schnell den Contract angeschaut, das Video selbst ist schon verdächtig… Das ist ein typischer momentan sehr verbreiteter Scam der einem vorgaukelt das der Contract ein MEW bot ist auf Contract Basis. Rein technisch funktioniert die Idee schon mal gar nicht so. Skunk hat das oben schon etwas beschrieben. Ein Contract kann nicht "gestartet" werden und macht dann was. Es benötigt immer eine Transaktion für jede Interaction. Nur falls Uniswap von ihren eigenen Contracts aus bei einer Transaktion einen Hook zu einem anderen Contract aufruft, wäre so was möglich. Die Fees würden vom jeweiligen User des Swaps bezahlt. ABER es gibt eigentlich keine grössere Sicherheitslücke die jemals aufgetan werden kann als sowas, jedenfalls in der Form.. externe Contract-Calls zu "irgendwas und allem" zu erlauben. Kurzum: Sowas ist nicht möglich in der Form auf Uniswap. Der Contract hier ist schön eingewickelt in nette Buzzwords wie, frontrun, uniswap withdraw, mew bot, etc. und all das Gedöns nur damit es aussieht als würde da irgend sowas gemacht. Was grundsätzlich in dieser Form sowieso so nicht möglich ist. Jedenfalls ist das meiste aus einigen anderen Contracts zusammengewürfelt, Copy/Past. Hat keinen Kontext, wird weder aufgerufen noch werden viele Variablen/Funktionen überhaupt benutzt. Sieht aber toll aus. Das sind typische Scam Contracts die so obfuskiert sind, dass man die wahre Funktionalität nur sehr schwer herausfindet. Also Leie sieht das alles grossartig aus. Die "fundest" den Contract aus dem folgendem Grund und was danach genau passiert: «Funden» weil man so nicht sofort erkennt, dass deine ETH eigentlich woanders hin gesendet werden sollten. 1. Du sendest ETH an den Contract, Funding. Die bleiben vorerst dort. Du hast nun nur 2 Möglichkeiten, die schlussendlich genau dasselbe machen: 2. Start: Durch den Aufruf mehrerer "getarnten" mit großartigen Funktionsnamen wird am Ende so bloss eine Fixe Adresse generiert: 0xBcF87A18e05e562BD307d76682677d2388973cc6 Es ist absichtlich sehr low Level und Wirrwarr mässig obfuskiert damit man eine Wahnsinns- Funktion hat bei der man denk, "was die alles macht, wow". Generiert aber nur versteckt auf simpelste Weise des Scammers Ziel Adresse. Der eigentliche Transfer und alles was die Funktion eigentlich macht, findet jetzt statt: Es werden alle Ether, die du auf dem Contract hast, dem netten Scammer(die generierte Adresse) direkt auf sein Konto überwiesen. Ende der Funktionalität. 3. Withdraw: Macht exakt dasselbe. Somit sind deine Ether verloren. Du kannst die nur mit start oder withdraw dem Scammer die ETH überweisen, das ist alles. Leider gibt es keine Alternative. Am besten lässt die sie da wo sie sind, damit der nicht noch davon profitiert, und als Lehrgeld abschreiben. Also nicht start oder withdrawl ausführen! Aber leider sind die ETH dennoch verloren.

Du brauchst nicht noch einen weiteren Account zu erstellen in der MM. So gesehen erstellst du keinen MM Account um ihn "abzusichern" mit dem Ledger. Was du möchtest, ist dein Ledger mit der MM verbinden und den Account(s) des Ledgers benutzen. Der Account ist auf dem Ledger, nicht einer in der MM, das ist der Unterschied. Aber nach einem Verbinden wird er dort als (Ledger) Account angezeigt den du benutzen kannst über das verbundene HW-Wallet. (Kann man im 2. Video schön sehen) Somit musst du lediglich das HW-Wallet verbinden. Und die Account(s) auswählen & "unlocken" damit sie angezeigt werden. So wie es bei Leder selber hier beschrieben ist. https://www.ledger.com/de/academy/der-sicherste-weg-metamask-mit-einer-ledger-hardware-wallet-zu-verwenden Einfach mal probieren wie beschrieben: "Connect Hardwarewallet". Das ist sicher, und es kann nichts passieren, du verbindest einfach den Ledger damit, aber du siehst was passiert und siehst nachher den Ledger Account in der MM. Mehr brauchst du nicht zu tun, vorerst. Ohne gebühren geht nichts.....

Das erste Video ist ein absolutes No-Go. Leider gibt es dutzende von unwissenden YouTubern, die nicht verstanden haben was ein Hardwarewallet ist. Das Dümmste, was man machen kann, ist eine Seed Phrase importieren von einer MM zum Beispiel. Im Video warnt der Ledger sogar noch deutlich davon beim Einrichten: "Ledger kann die Sicherheit von externen Wiederherstellungsätzen nicht garantieren. ... Wenn sie nicht vom Ledger selber generiert wurden." Und der schlaue Autor ignoriert es einfach. Ein Hardware-Wallet ist nur sicher, wenn es so benutzt wird wie angedacht. Genau so verlieren Leute ihre Kryptos, obwohl sie ein HW-Wallet haben! Das zweite Video ist ok. Hier wird lediglich der Ledger mit der MM verbunden. Und genau so ist das auch richtig wenn man das möchte. Also: Verbinden: Ja. Muss/kann man. Importieren eines "fremden" Seeds: NIEMALS. Wenn du geprüft hast, dass dein Ledger mit dem Seed wiederhergestellt werden kann. (Ansonsten hast du vielleicht schon jetzt ein echtes Problem), dann brauchst du keinen extra Aufwand zu betreiben. Einfach alles von deiner "Normalen" MM an den Ledger (Adressen) senden. Fertig. Und den MM account nicht mehr benutzen, oder einfach nur fürs Kleingeld und täglichen Gebrauch. Wenn du den Ledger mit MM verbinden/benutzen willst und so betrieben, kannst du machen, brauchst du aber nicht.

Nach all dem, was ich gelesen hab, versuche ich das Problem mal anders darzustellen. Falls du einen Coin machen willst, klar, mach mal, kostet auch kaum was, bringt dir aber auch nichts, anhand vieler Punkte, die schon aufgezählt wurden. Zu deiner eigenen Chain: Auflisten der weiteren Details der Problematik, macht keinen Sinn, da es das ganze Forum sprengen könnte.... 🙂 Stell dir das einfach mal so vor, ganz pragmatisch, und auf gröbster Ebene zusammengefasst: Dich erwartet ein Monate/Jahr-langer Prozess an Wissensaufbau und Arbeit. Dazu, das in vielen Bereich umzusetzende der Thematik. Das ergibt 10'000de Probleme und"Dinge, aus diversen Bereichen", die auf dich zukommen werden, mit einer zu lösenden Problematik diverser Schwierigkeitsgrade, sagen wir mal alles auf einer Schwierigkeits-Skala zwischen 1 und 10000. So, du stehst eigentlich bei den allerersten dieser Probleme schon komplett, hoffnungslos und völlig überfordert an, auf der allerersten untersten Stufe von vielleicht 10. Aus einer solchen Sicht macht das absolut null Sinn auch nur sowas in Erwägung zu ziehen. Sorry, aber spar die das Geld, und die Qual. Mach ein Token, wenn überhaupt, und wenn du nur da schon etwas kreierst, dass überhaupt jemand will und es nicht bereits hunderttausende von gibt, gut, dann kannst du vielleicht mal einen Schritt weiter denken.

Sollte kein grosses Problem sein. Nehme an, dass sich nur ein Teil der Daten stündlich ändert, nicht die ganzen 500GB. Man könnte 1x pro Tag Morgens z.B. ein volles Backup machen, dann stündlich ein differentielles, für alle Änderungen, und dabei den täglichen Verlauf für x Tage behalten. Denke die meisten normalen Backup Programme können das. Ich nutze seit Jahren Akeeba für solche Tasks.

AES ist sicher, einer der sichersten und am meisten benutzten Standards, es braucht einfach einen guten Schlüssel, und hier liegt wie immer das eigentliche Problem, genau wie bei deinen PKs. Elliptic-Curve ist eine asymmetrische Verschlüsselung und nicht wirklich für file/disc encryption geeignet. SSD disc-encryption benutzt, soviel ich weiss, grundsätzlich auch AES, passiert aber auf einem Hardwarelevel, was es einfach noch schneller macht, aber die Sicherheit dürfte am Ende dieselbe sein. Nachteil ist, dass wenn das Drive fehlerhaft ist, kann es auch problematisch sein zu recovern. Nachteil bei der Softwarevariante: Ist so sicher wie der Rest deines PCs/Systems halt…. Frage vielmehr, was für welche oder wie viele Daten möchtest du verschlüsselt sichern? Kilobytes, Megabytes, Terabytes? Viele einzelne Files, oder grosse "Blöcke"? Das System mit z.B. Bitlocker abzusichern ist vorteilhaft, bei uns Pflicht, aber das nützt dir für Backups auch nichts. Ich benutze auch Veracrypt Container. Hier sollte es eigentlich keine Probleme geben, wenn jeweils ein volles Backup gemacht wird, nicht inkrementell, mit einem x-Tage Verlauf. Nur für PWs benutze ich Keepass. Kann man aber auch noch in einem Container sichern, ist aber eigentlich nicht nötig. Anstatt eines regelmässigen Backups kann man auch noch die File-History/Synchronisation benutzen, glaube Synology hat sowas dabei. Dabei wird immer automatisch ein neues versioniertes File-Backup gemacht, sobald das File geändert wurde. Das wäre für kleinere Files oder sowas wie Keepass sehr gut/schnell und sicher. Wichtig ist, dass man volle Backups hat (zwischendurch), mit einem Verlauf, auf den nicht zugegriffen werden kann. Viele vergessen dabei Ransomware Attacken. Dabei nützt dir eine System/Bitlocker, Soft/Hardwareverschlüsselung nichts. Selbst ein inkrementelles Backup, oder "nur" ein Backup kann am Ende nutzlos sein, da es evtl. verschlüsselt/gehackt gespeichert wird, bevor man es merkt. Somit nur auf eine verschlüsselte SSD speichern, löst dieses Problem nicht, ohne einen nicht manipulierbaren Verlauf zu haben. (Es gibt auch hochsichere Cloud-Speicher Dienste, die genau für sowas gemacht sind, und diese Probleme lösen, und grundsätzlich zuverlässiger und sicherer sind als eigene Lösungen.) Für sichere Backups gibts noch die goldene 3-2-1 Regel.

Nein. Die Warnung sagt aus, dass eine beliebige Anzahl neuer Tokens erzeugt werden können. Nicht, dass sie zurückgeholt werden können. Hab kurz das Audit Dokument angeschaut, sogar im Audit steht, dass es möglich ist. Ist aber "nur" ein Preis/Supply Problem, wenn die Tokens erzeugen können. Ansonsten sieht der Audit grundsätzlich ok aus, somit eher nicht von deren Seite ein Problem, sondern evtl. eines der genannten Security Issues.

Das sollte keine Unterstellung werden. Danke! Genau, das Video ist sehr bekannt, man muss es aber eben auch verstanden haben. Zumal du schreibst "nur bei Bitcoin". & "und auch erst haben wird, wenn ich auszahle" Es gibt keine grössere Sicherheitslücke, die du überhaupt aufmachen könntest.... ?! Das ist keine Glaubensfrage... Dann liste doch mal folgendes auf: Angriffe, die auf ein HW-Wallet möglich sind, jedoch NICHT für dein "System". Falls du hier auch nur einen Punkt findest, gratulation. (Umgekehrt auflisten macht keinen Sinn..😁) Aber egal, hat jeder selber zu verantworten, ob er wirklich weis, was er da tut. Sollte einfach ein Gedankenanstoss sein für Leute, die hier vorbeikommen, und sich überlegen, wie sie sicher, sichere Wallets erstellen.

Na ja, für ein falsch gekauftes Wallet gibt es auch das pendent des fake Software Wallets. Klar sind Angriffsvektoren genau auf ein Wallet zugeschnitten, jedoch ist das HW-Wallet eben genau so konzipiert, dass es keine Angriffsfläche bietet. Jeder kann machen, was er will, klar, jedoch ist es nicht förderlich solche falsche Annahmen zu posten, denn nein, dein System ist in vielerlei Hinsicht nicht sicherer als ein HW Wallet, sondern eben genau das Gegenteil. Sich gegen Angriffe so abzusichern, ist schlicht ein Irrglaube, cyberkriminelle sind immer 1 Schritt voraus.... Eben, aus dem Grund hat man das HW Wallet erfunden, um genau all den Gefahren gekonnt aus dem Weg gehen zu können. Leder supportet Cardano, Daedalus auch, denke, andere tun das auch...

Kannst du den Prozess und die Handhabung (& das wie, wo und was) dafür mal etwas detaillierter aufzeigen, damit man nachvollziehen kann, was genau dabei am Schluss sicherer sein soll als ein Hardware-Wallet? Was ist "theoretisch sicherer"? Ich hab da so meine Zweifel....

Ich nehme an dass das foren-spam-werbung ist. Was für ein Schwachsinn.... Ansonsten, wenn es tatsächlich Leute gibt, die mit einer solchen Naivität und Unwissenheit ihre Euros loswerden wollen, klar, die sind sicherlich auch dem richtigen Pfad 🙂

Würde mich auch interessieren, wie sie sowas machen wollen!? Die Contracts sind in der Regel die Dezentrale Börse selbst, DEXEs sind auch nur Contracts, nicht nur die Buchungsdaten. Die Wallet hat grundsätzlich damit nichts zu tun, das ist nur ein visuelles Hilfsmittel und einen Account zu verwalten etc. Der «Zugang» zum Contract ändert sich nicht. Ein Contract kann als einziges eigentlich signierte Transaktionen verarbeiten. Und hierbei prüft er z.B. die Adresse des Senders. Als Beispiel: Eine Funktion «dex abschalten» erwartet oder erlaubt lediglich der Adresse XY die Funktion auszuführen. (XY ist hinterlegt in contract). Somit ändert sich nichts auf der neuen Chain. XY ist noch dieselbe Adresse, die von immer noch gleichen PK abstammt. Und der alte ETHS User hat nun jetzt auch genau dieselbe ETHW Adresse. Somit ist alles 1:1 wie vorher. Allg: Wenn alle Ihre Tokens in ETHW umtauschen und verkaufen wollen, wird der Preis dafür schnell ins bodenlose fallen. Aber da die Börsen dezentral über Liquidity Providers funktionieren, sollte eigentlich der Preis des verkauften Tokens dann wiederum steigen, das wäre ja der natürliche Arbitrage-Effekt. Somit könnte da der auch vorgesehene Ausgleich wiederum stattfinden, und die Tokens steigen im Preis, aber der ETHW fällt zumindest so sollten diese Dexes funktionieren. (Aber da alles eigentlich keinen Wert hat, fraglich wie sich das auswirkt...) Pulsechain hat das Problem ganz anders angegangen. Sie haben einen Bot, der Pre-lauch schon läuft und eigentlich unlimitiert PLS hat und dieser "leert" dann einfach alle grossen relevanten DEXes indem es sämtliche Liquidity aufkauft mit PLS-Token pairs. (Ehemalige ETH-Token pairs). Somit sind die DEXes nachher relative nutzlos. Und alle Tokens vom Bot werden in die eigene neue PulseX gebraucht als Liquidity. Somit ist PulseX liquide gleich zu beginn, und eigentlich die einzige nutzbare DEX. Mit dem Beigeschmack, dass dem Founder auch noch gleich eine riesen Portion der Tokens/Liquidity gehört... So richtig voraussagen kann das glaub niemand, was wirklich passieren wird, aber die "Balance" der Chain wird vermutlich sehr schnell nicht mehr so sein wie sie mal war auf ETH. Ich bin gespannt!

Zu Punkt 1: Man kann nicht forken und die Tokens einfach weglassen. Was ist ein Token? Einfach nur ein Contract. Falls es sowas, wie ein ERC20 oder ein ähnlicher Standard ist, könnte man die identifizieren. Nun, vieles ist kein Standard. Was ist mit den ganzen "restlichen" Contracts? Das kann alles sein, token, dex, game, rug, was auch immer, das lässt sich nicht sagen. Einfach alles. Somit kann man in erster Linie nicht identifizieren, was ein Contract macht oder ist, und was filtrieren/weglassen. Aber das spielt auch keine Rolle, denn: Ein Contract besteht nur aus Daten, oder genauer Bytecode, der Teil einer Transaktion war, und so gespeichert wurde. Genau wie andere Daten einer «normalen» Transaktionen, Transfer etc. Damit kommen wir zum eigentlichen Problem: Eine Transaktion ist somit Teil eines Blockes, und naja, Blöcke sind nun mal nie mehr änderbar. Somit kann man nichts "weglassen" beim Forken, ohne die Chain neu zu berechnen.... Man könnte einfach eine komplett leere Chain erstellen, aber das bringt wohl niemanden was, ist dann auch nicht wirklich eine fork. Probleme mit tokens: Wer den key zu einer Adresse hat, hat nun auch alle Kopien 1:1 jeder pool, dex etc. und Contract hat auch genau den 1:1 Stand. Also wenn ich z.B. Liquidity irgendwo drin hab, dann ist das genau gleich. Alle Contracts die nicht kontrolliert sind, wie die meisten "normalen" ERC20 Tokens sind unproblematisch, da sie weiter so funktionieren und niemand was ändern kann. Anders z.B. Tether, und jeder Contract der «admins» hat und von irgendwem kontrollier ist, die können z.B. das "System" sogar abschalten. Oder auch immer tun was sie dort im Contract eingebaut haben. Chainlink die die Chain nicht supporten als Beispiel: Jeder Contract der intern Chainlink nutzt wird nicht mehr richtig tun. Gibt noch viele weitere andere ähnliche Probleme. Das Ganze kann Konsequenzen mit sich ziehen. Der Status der Chain, ist kann man kann fast sagen, etwas korrumpiert schlussendlich, ein bisschen ein kaputtes System am Ende.

Nein, am Limit sind sie sicherlich nicht, aber die Rücklagen zu verballern, ist kein sinnvolles Geschäftsmodell. Raum für Spekulation ist sicherlich drin, aber stell dir folgendes Szenario vor: Man verbraucht die Reserven nach und nach, da der Preis nur runter geht, ohne dass man verkauft. Irgendwann ist nichts mehr da. Der Kurs bleibt tief und der Verkauf bringt gar nichts mehr. Ende des Tunnels. Deshalb muss laufend verkauft werden, egal wo der Preis steht, wie bei einem normalen Geschäft, mal gibt halt mehr Umsatz, mal weniger, aber der Betrieb ist gesichert. Je höher der Spekulationszeitraum, desto höher das geschäftliche Risiko. Auf dem absteigenden Ast bezüglich Rentabilität, der Preis kann das nicht mehr ausbalancieren. Sieh dir mal die Charts an auf z.B. whattomine. ETC war lange immer eine gute, fast die beste Option nach ETH. Jetzt rutscht es immer weiter runter. Ich kann das mit meinen eigenen Zahlen bestätigen. Der Profit ist sehr schnell in den letzten 2,3 Monaten bei ETC ca. 50+ % runter, wobei der vorher sehr stabil war. Die Hashrate ist von ca. 20-25 rapide auf 40+ TH gestiegen. Doppelte Hashrate, halber Gewinn. Der Preis müsste sich verdoppeln, um das auszugleichen. Nun gibts ca. 850+ TH von ETH die noch kommen werden! Kannst du dir mal ausrechnen, wie hoch die Rentabilität danach noch sein wird. Der Preis müsste ein 20x hinlegen, um die diese zu bewahren. Eher unwahrscheinlich. Nein, der Merge löscht die Anwendungen natürlich nicht bei ETH. Es gibt aber dann eben 2 ETH chains. Und alles was bis zum Zeitpunkt des Merges existiert gibt’s dann auch auf beiden. Die gleichen Anwendung, Tokens etc., ja alles da. Darum eben, wer Token xy hat, hat nun eine Kopie, Dexes etc. alles (das meiste) funktioniert. Hat eigentlich kein Wert, aber das ganze könnte trotzdem Gefallen finden. Und eben Leute sind schon da. Pulsechain macht eigentlich auch genau dasselbe, und wird gross ausgehängt als «Biggest airdrop in history» auch wenn’s nicht mehr ETH heisst und POS wird. Ich denke es wäre besser, da die Hashrate dadurch besser verteilt werden würde. Klar, aber beim halvening passiert genau das. Ganz viele können ihre Anlagen einstampfen, weil sie per sofort nicht mehr rentieren. Der Preis geht auch nicht hoch wegen der Hashrate, sondern wegen der scarcity, weil nun weniger BTC auf den Markt kommen. Die Hashrate ging gleich nach dem letzten halvening stark runter. Genau aus diesem Grund. Halber Gewinn bei derselben Hashrate. Heisst für viele das Ende der Fahnenstange und die Anlagen werden abgeschaltet. Profitable bleibt nur wer die neusten effizientesten grössten Anlagen hat. Die andern sind meistens schon am untersten Limit der Rentabilität, und ein halvening oder ein massiver Anstieg der Hashrate bedeutet das aus.

Worauf sollen sie sich vorbereiten? Sie minen so lange ETH, was am profitabelsten ist, dann müssen sie wechseln. ETC ist jetzt schon auf dem absteigenden Ast, eben weil schon viel Hashrate reingeflossen ist, auch als die 4 GB Karten nicht mehr für ETH gingen. Grosse Farmen sind Unternehmen, welche enorme, laufende Betriebskosten haben, die konstant gedeckt werden müssen, da kannst du nicht einfach mal warten und hoffen, dass der Preis sich dann entwickelt und irgendwann Gewinne machen. Sie müssen verkaufen, um den Betrieb aufrechtzuerhalten, sonst kann da ganz schnell das Licht ausgehen. Technisch gesehen ist die Codebase nicht dieselbe, war ja auch der Grund für eine Fork. Geschweige denn die Projektanzahl und das Ecosystem heute, das ist schon eine andere Grössenordnung. Was ich aber eigentlich anspreche, ist das der Systemstand. Alles, was auf ETH existiert, in der neuen Fork auch dabei sein wird. Das ist bei ETC nicht der Fall, dort gibts alles, was dort gebaut wurde, nicht was auf ETH gebaut wurde. Daher, sehe ich das als einen Vorteil einer neuen Fork, da dies "alles bleibt" für die Leute, die sowieso schon dort sind. Warum soll eine extrem hohe difficulty irgend wem was nützen? Viele werden schlicht und einfach sehr, sehr schnell unprofitable sein. Ich mine selber, und noch nie hat der Anstieg der Hashrate einen positiven Effekt gehabt, die Rendite geht dabei einfach nur Bergab.

Die Community ist schon gespalten in vielerlei Hinsicht. Zum einen wollen die POS Gegner den neuen Konsens schlicht und einfach nicht. Die Miner verlieren wirklich Ihr Geschäftsmodell, deshalb ist die neue POW ETH Fork auch schon beschlossene Sache und wird auch relativ gut unterstützt, Binance z.Bsp. Es gibt Miner die x Fabrikhallen voll von ETH Asics/GPUs besitzen. In der jetzigen Situation sicherlich schwierig zu entscheiden, wies damit weiter gehen soll. Solche Imperien gibt man nur ungern auf. Alles verkaufen? Wer wird Interesse daran haben, wenn's voraussichtlich nicht mehr profitabel ist. Alles abschreiben, aufgeben? Die Hashrate die in ETC und auch z.B. in Ravencoin fliessen werden sind massiv. Die difficulty wird durch die Decke gehen und bei dem Preisniveau der Coins ist die Rentabilität kaum noch gegeben. Kann den Preis hochtreiben, aber wahrscheinlicher ist, dass enormer Verkaufsdruck entsteht. Grosse Farmen/Pools müssen verkaufen, um den Betrieb zu sicheren. Und wie auch bei Raven, was soll ein Coin schlussendlich bringen welcher ausschliesslich zum Minen da ist? Kann mir vorstellen, dass dies nicht grad optimal ist für diese Coins. Wobei ETC, den Vorteil hat gut etabliert zu sein, Raven und andere überhaupt nicht. Ich denke da kommt zu viel Hashpower auf einmal in einer ungesunden Menge rein. Eine neue POW Fork hätte zumindest den Vorteil schon alles zu haben, user, coins Projekte etc. und den letzten ETH Stand. Würde auch die Hashpower die in existierende Coins geht etwas mindern, und evtl. eine bessere Preisfindung haben gleich zu Beginn, da die Hashrate gegeben ist, aber noch kein Preis. Aber auch hier, was nützt eine alte ETH Chain die nur da ist, damit die Miner was minen können, sehe da langfristig keinen Nutzen, kurzfristig villeicht. Und wer soll die weiterentwickeln? Es ist eine alte ETH chain warum sollte man auch da bauen oder die benutzen? Ich sehe da schwierige Zeiten aufkommen....

Noch anzufügen, Vorsicht bei Tutorials/YouTube etc. Dort findet man sehr viele Tutorials, wie man MetaMask auf z.B. Ledger migriert. NICHT nachmachen. IMMER das Wallet neu aufsetzen, mit einem neuen Seed, und dann nachher mit MetaMask zusammen benutzen. NIEMALS mit dem Seed von MM das Hardware-Wallet erstellen. (Das andere hat einen ganz kleinen speziellen use case, führt aber dazu, dass ein sicheres Hardware-Wallet dann nicht mehr als sicher gilt. Leider verstehen das viele falsch und machen sowas.)

So rein statistisch gesehen ist vermutlich auch das Feuer/Wasser, Ehefrau, Einbruch Szenario etc. sogar praktisch null, falls dein Seed z.B. in 2 verschiedenen Schliessfächern ist. Ein Aufwand, der aber in Relation mit dem Betrag stehen sollte, aber maximale Sicherheit. Für eine Metamask mit Kleingeld für den täglichen Gebrauch, ist das erwähnte Keepass nicht nur völlig ausreichend, sondern auch sicherer als alle ausgedachten Tricks. Ansonsten google mal was z.B. Antonopolous zu dem Thema sagt, nämlich genau das man sowas alles am besten lässt.

Gar nichts. Wie Vorredner bereits erwähnt haben, damit schiesst du dir höchstens selber in den Fuss. Die höchste Sicherheit eines Seeds besteht darin, dass er NIE auf einem Device existiert, welches eine Verbindung mit dem Netz hat. Zudem finden Angriffe, Hacks, Diebstähle etc. in der Regel zu 99,9% digital statt, nicht physisch. Somit ist ein Seed auf einem Papier weitaus weniger gefährdet als alles, was du digital versuchst auf einem Gerät/Wallet am Netz zu bewerkstelligen.