PeWi

22 hours ago, o0Julia0o said:

Screenshot der E-Mail Bestätigung eines anderen Anbieters über den Kauf der Kryptowährung

Diesen Punkt finde ich besonders interessant. Wenn mich mein Gedächtnis nicht trügt, dann habe ich bisher noch auf keiner einziger Börse je eine E-Mail bei einem Trade bekommen. Wäre bei Bottrading mit u.U. -zig Trades täglich auch ziemlich problematisch.

Grundsätzlich sind auch die anderen Punkte nicht trivial zu erfüllen, wenn man viele Trades hat.

37 minutes ago, o0Julia0o said:

Hält sich das Risiko nicht in Grenzen, da ich ja 2 Tage später hineingucken kann

Wenn es dumm läuft, dann kann der Kurs ziemlich schnell und ziemlich heftig drehen. Da stehst du u.U. zwei Tage später schon mit 30% Verlust da.

1 hour ago, o0Julia0o said:

Du hast wohl Maker und Taker im letzten Abschnitt vertauscht.

Tatsächlich - danke! - jetzt korrigiert.

1 hour ago, o0Julia0o said:

Ich verstehe nur nicht, wo der Sinn für die Börse ist.

Maker sind für die Börse lebenswichtig. Ohne von Maker eingestellte Orders könnte kein einziger Taker auch nur einen Coin verkaufen oder kaufen.

Sinnbildlich: Maker sind die Leute, die die Regale im Supermarkt einräumen, Taker sind die Leute, die die Fächern leeren.

50 minutes ago, o0Julia0o said:

Ich verstehe nur nicht, wo der Sinn für die Börse ist. Im Grund macht es doch keinen Unterschied ob ich jetzt zum aktuellen Kurs eine Maker-Order oder Taker-Order einstelle.

Das habe ich oben versucht zu erklären.

Die eine Order vergrößert das Angebot an Orders im Orderbuch, die andere schmälert es.

Eine Börse hat schon ein Interesse daran, ein möglichst volles Orderbuch zu haben. Zum einen sind dann die Preisabstufungen feiner, und zum anderen kann sie dann größere Volumina bedienen, sie bekommt dann auch umsatzstärkere Kunden.

Außerdem - wer würde das Risiko einer Maker-Order (die ja ggf erst "irgendwann" ausgeführt wird) auf sich nehmen, wenn er dafür im Gegenzug einen Vorteil für sein höheres Risiko bekäme?

1 hour ago, AnseBundren said:

An dem anderen Thread sieht man auch lehrbuchmäßig, wie der russische Informationskrieg im Kern funktioniert und wie einfach gestrickte Köpfe für Mütterchen Russland abgerichtet werden.

Nicht böse gemeint - IMHO interpretierst du aus @Krypto-Pattys Post (und vorher aus @mahatmas Posts im anderen Thread) mehr heraus, als tatsächlich drinsteht.

Das klingt nach ziemlich vielen Missverständnissen.

Makergebühren sind günstiger als takergebühren, weil du als Maker das Orderbook um deine Order vergrößerst. Es gibt also mehr Angebot für Leute, die handeln wollen. Ein Taker bedient sich aus den Orders im Orderbook, es bleibt also weniger drin stehen, das Angebot für andere Leute wird kleiner - deswegen muss er mehr Gebühren zahlen.

Wenn deine Order im Orderbook steht, kannst du sie natürlich jederzeit auch wieder löschen, solange sie nicht von einem anderen angenommen wurde.

Ansonsten steht sie solange im Orderbook, bis jemand zu deinem Preis zu kaufen bereit ist. Das kann innerhalb weniger Sekunden passieren, aber auch in Stunden, Tagen oder Monaten. Im schlimmsten Fall: Jemand stellt eine Order zum Preis des sich gerade ereignenden ATHs ein - der Kurs bricht ein, ein bis wei Jahre Bärenmarkt und vielleicht drei bis 4 Jahre nach dem Erstellen der Order kommt endlich der Kurs wieder bei deiner Order vorbei.

Fazit:

Der Maker Taker reduziert das Order-Angebot auf der Börse und hat die Gewissheit, dass seine Order sofort ausgeführt wird. Dafür muss er etwas höhere Gebühren zahlen.

Der Taker Maker vergrößert das Order-Angebot auf der Börse und hat die Ungewissheit, wann seine Order ausgeführt wird. Dafür muss er weniger Gebühren zahlen.

Deswegen: Wenn du zeitnah verkaufen willst, dann zahle lieber die paar Bruchteile mehr und nimm eine Taker-Order. Dafür hast du Sicherheit. (Im Allgemeinen klappt es aber auch mit einer Taker-Order innerhalb weniger Minuten oder Stunden, wenn sie nur dicht genug am Kurs liegt.)

Just now, Aktienspekulaant said:

aber dass wir auch Kernphysiker haben... Respekt

Es gibt mehr Leute, die Physik studiert haben,  als Leute, die Bundestrainer o.ä. studiert haben. 

9 hours ago, Peer_Gynt said:

11 hours ago, ..::. o.Z.o.n.e .::.. said:

Wie sagte mal ein Wisenschaftler sinngemäß, ... die Summe aller Teile eines Atoms mit Masse eins (1) ergibt 0,9. – Wir wissen noch immer nicht woher die zusätzlichen 0,1 kommen.

Kommen die zusätzlichen 0,1 nicht von der Bewegungsmasse, die aus der kinetischen Energie der Bewegungen von Atomen (Protonen, Neutronen und Elektronen) entsteht?

Wiege das mal bei null Kelvin bzw. -273° Celsius (null Kelvin), dann dürfte auch die Summe nur noch 0,9 betragen.

Mein Sprössling hat das gerade als Thema  in der Schule - allerdings genau umgekehrt als es bei euch steht.

Die rechnerische Summe aller Teile eines Atoms ergibt mehr, als das komplette Atom tatsächlich wiegt. ("die Summe aller Teile eines Atoms mit Masse 0,9 ergibt 1,0")

Dem kompletten Atom fehlt also Masse - der sogenannte Massendefekt.

Er entsteht, weil die Kombination der Nukleonen stabiler ist als einzeln herumfliegende Nukleonen. D.h. beim Aneinanderpappen der Nukleonen wird deswegen eine Bindungsenergie frei. Und da dieser nach "außen" angegebenen Energie nach Einstein (e = m x c²) eine Masse entspricht, kann man die dem Atom dann fehlende Energie auch als fehlende Masse wiegen.

Und da die Kernkräfte heftig stark sind (viel stärker als z.B. die Gravitation), wird auch relativ viel Bindungsenergie frei, und damit merklich viel Massenverlust.

https://de.wikipedia.org/wiki/Massendefekt

Edit: Sehe gerade, dass @mahatma schon geantwortet hatte.

1 hour ago, skunk said:

Ich kann dir nicht ganz folgen.

Kein Wunder - ich war ja auch falsch abgebogen. 

In dem hier diskutierten Fehlerfall läuft ja die Finalisierung weiter (nur eben auf fehlerhaften Blöcken).

57 minutes ago, zagota said:

Bei den meisten kann man sich doch per OpenVPN und/oder Wireguard direkt verbinden, so mach ich es. Ist dann halt nicht so komfortabel.

Die Nutzung von kommerziellen VPNs sorgt dafür, dass beim VPN-Betreiber Daten auflaufen,die ich meinem normalen Internet-Provider nicht zugestehen will. (Sofern es nicht einfach nur um Geolocation ö.ä. geht.)

Insofern hat der VPN-Betreiber vermutlich Daten, die sich wirtschaftlich gesehen besonders gut verkaufen ließen.

Das alleine wäre für mich ein Grund, eben keinen kommerziellen VPN-Betreiber zu nutzen, sondern eben Onion oder Wireguard o.ä. - einfach weil mir das Risiko zu groß wäre.

25 minutes ago, skunk said:

Man hat schlicht die Ignoranz und Bequemlichkeit der Validatoren unterschätz. Der Fehler liegt nicht im Protokoll sondern im Verhalten der Validatoren.

Meinst du mit "Validator" die Software oder den Menschen, der ihn betreibt?

26 minutes ago, skunk said:

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.

Die Beschreibungen, die ich bei euch und in dem Artikel gelesen habe, klingen nicht danach, dass der "Ausfall der Finalisierung" ein im Protokoll vorhergesehenes Ereignis ist, auf das spezifisch reagiert wird.

Es wird darauf nur sehr unspezifisch (siehe Artikel) reagiert, und bestraft auch die "kleinen Leute", die ihre ETH-Krümel einem Validator anvertraut haben. Das finde ich noch keine adäquate Reaktion auf das Ereignis "keine Finalisierung mehr" - könnte man darauf nicht spezifischer und geschickter reagieren? (Ernstgemeint, nicht rethorisch.)

2 hours ago, mahatma said:

Die Ursache des ganzen Übels liegt doch darin begraben, dass der geth client so massiv dominiert, oder?

Jein - so wie ich den Artikel verstehe, behandelt das Protokoll bisher nur den Fall, dass einzelne Validatoren - aus welchen Gründen auch immer - ausfallen. Das Protokoll scheint aber keine Sicherung dagegen zu haben, dass aufgrund eines systematischen Fehlers eine komplette Validatoren-Art ausfällt, vor allem, wenn sie die absolute Mehrheit stellt.

Das dieses spezielle Problem nicht auftreten würde, wenn man drei ähnlich stark vertretene, unabhängig voneinander entwickelte Validatoren-Arten hätte, heißt nicht, dass man diesen Fall nicht absehen und sinnvoll im Protokoll behandeln sollte.

Würde sowas im Protokoll berücksichtigt, wäre es egal, dass Geth so stark dominiert.

@skunk in seiner hinterfotzigen Art (*) hätte das vielleicht rechtzeitig erkannt, wenn er bei ETH Test-Verantwortlicher gewesen wäre.

(*: positiv gemeint! 👍)

6 hours ago, groocer said:

Er sprach von Steigerungsraten und nicht vom abnehmenden exponentiellen Kursverlauf einer Zinseszins-Funktion, der prozentualen Steigerung oder "Wachstumsrate"; dass hast Du in die Aussage hineininterpretiert.

Ich habe deinen Hinweis nur ergänzt, damit das nicht jemand falsch versteht.

@Exodus kannst du mal einen Kurs über die richtige und geschickte Bedienung der Forumssuchmaschine abhalten?

Ich habe gerade ewig nichts gefunden und habe dann in meiner Not einfach alle Beiträge von @ngt durchgescrollt. Auf der zwölften Seite wurde ich endlich fündig.

46 minutes ago, AnseBundren said:

Ist doch Wurst, wovon die Miner leben und wie gut deren Incentives sind. Difficulty geht rauf, Miner steigt aus, difficulty geht runter, Miner steigt wieder ein. Das ist ein selbstregulierendes System.

Die Sicherheit von Bitcoin hängt aber doch daran, dass mit genügend Hashrate gemint wird. Wenn die Hashrate zu weit abfällt, wird eine 51%-Attacke möglich.

@ngt hat dazu zwei ausführliche Beiträge gemacht:

Wenn ein Validator immer mindestens 32 ETH haben muss, dann wäre ggf auch ein Ausweg, alle Geth-Validatoren nur mit wenig über 32 ETH zu betreiben? Dann muss nicht so viel verschwinden, bis sie aus ihrer Validatorenrolle herausfallen.

Okay, hilft laut Artikel auch nicht:

One important point here is that it’s unlikely that validators on the invalid chain would sit around doing nothing. They still have the option to withdraw their stake and if they don’t, the network will force eject them anyway when their effective balance reaches 16 ETH. But this does not mean that their downside is limited to 16 ETH.

When you exit a validator (even when force ejected) you go into the exit queue and while you are in the exit queue you will still leak ETH!

Klingt alles so, als sollte ETH noch ein bisschen nachforschen und Maßnahmen für ein solchen Fall, dass der Haupt-Client ausfällt, treffen. 

@mahatma hat schon recht, das ganze ist sakrisch kompliziert.

When a minority client fails, the penalty is losing ETH at the same rate as you gained it (as you can see in the graph of my validator above) but if Geth fails, because it instantly stops the chain from finalising, the penalty is much harsher. This increased penalty is called the inactivity leak and is applied to offline validators when the chain stops finalising for 4 epochs (~25 minutes) or more. This harsher penalty is designed to encourage offline validators to get back online as quickly as possible, or in the worst-case scenario, burn the offline validators' stake until they represent < ⅓ of the total stake allowing the online validators to finalise the chain.

Die "hohe" Strafe (inactivity leak) wird laut Artikel dann verhängt, wenn a) der Validator offline ist und b) die Chain seit mindestens 4 Epochen nicht mehr finalisiert wurde.

Solange ein Nicht-Geth-Validator online ist und arbeitet, ist er also vor dieser höheren Strafe sicher.

Aber solange ein Geth aufgrund des Fehlers nicht offline geht, sondern "nur" falsche Blöcke bestätigt - und das ist ja das Szenario unserer letzten Posts - gilt das für ihn doch genauso?

Bzw: Wenn die Geth-Validatoren aufgrund dieses hypothetischen Fehlers alle offline gehen würden, müsste doch die Zählung der gerade aktiven Validatoren dafür sorgen, dass die noch laufenden Nicht-Geth-Validatoren ziemlich schnell die nötige Mehrheit werden (eben weil die Zahl der aktiven Validatoren massiv sinkt)?

Sprich, in beiden Fällen sollten die Stakes der Geth-Validatoren eben nicht ewig ausbluten müssen.

Aber - offensichtlich - ist es noch weitaus komplizierter, als ich mir das hier zusammen reime ...

6 minutes ago, skunk said:

Weil der Teil mit der Finality außerhalb von Geth liegt. Es gibt hier zwei Prozesse die ineinander greifen. Einmal die Beacon Node und dann Geth selbst. Die Beacon Node würde auch nach dem Patch auf der falschen Chain bleiben einfach weil genau das im Protokoll so vorgesehen ist. Es gibt für Geth keine Funktion mit der es die Beacon Node überzeugen könnte das Protokoll zu verletzten und den Finality Zustand zu vergessen.

D.h. die Beacon Node prüft selber nicht und verlässt sich vollkommen darauf, dass von anderen finalisierte Bläcke schon stimmen werden?

Ist das dann nicht eine Verletzung des Blockchain-Matras "don't trust, verify!"?

Und: Betrifft das dann die Nicht-Geth-Validatoren nicht gleichermaßen, wenn die Beacon Node auf einer falschen Chain sitzt?

42 minutes ago, skunk said:

Stattdessen gewinnt hier immer die Chain, die von mindestens 2/3 der Validatoren als Final anerkannt wurde. Wenn nach 4 Stunden ein Patch kommt, dürfen die Validatoren die Blöcke, die bereits Finality erreich haben, eigentlich nicht mehr anfassen. Sollte der Patch Code enthalten, der ihnen das doch erlaubt, wäre das zugleich ein Bruch mit der eigentlichen Konsensus Regeln.

Laut Artikel gibt es das "große" Problem aber nur, wenn Geth einen Fehler derart hätte, dass ungültige Blöcke finalisiert würden.

Where things get bad is if the bug results in a validator producing an invalid block, and Geth accepts it as valid and attests to it. This will result in a fork in the chain. The chain will split into 1 fork with the invalid block (Geth chain) and another fork where the invalid block is ignored (non-Geth chain). The validators running Geth will consider both forks valid and therefore will decide to build on the heaviest chain.

Mir leuchtet nicht ein, dass auch eindeutig ungültige Blöcke in die Finalisierungsheiligkeit einbezogen sind. (Die anderen Clients erkennen sie ja auch nicht an und bauen deswegen ab dieser Stelle ihre eigene Kette weiter.)

Warum muss ein Geth-Client auch nach dem Neustart nach dem Patch diese regelverstoßenden Blöcke weiterhin anerkennen?

26 minutes ago, groocer said:

33 minutes ago, Aktienspekulaant said:

 Tja und wenn man beide vergleicht, stellt man fest, dass die höchsten Steigerungsraten des BTC-Preises längst Geschichte sind.  ...

Die Y-Achse dieser Charts ist logarithmisch.

Würde BTC jedes Jahr um gleich viel Prozente steigen, hätten wir in logarithmischer Darstellung eine Gerade.

Deutlich sichtbar haben wir aber "weniger" als eine Gerade, weil die Kurve immer weiter von einer hypothetischen Gerade nach unten abweicht. ("Rechtsgekrümmte Kurve").

D.h. BTC steigt also immer langsamer (in Prozenten gerechnet) - Aktienspekulaant hat somit recht.

53 minutes ago, mahatma said:

Geht das? Hab den von ngt Artikel dahingehend verstanden, dass man da gar keine Wahl hätte und das wohl oder über aussitzen müsste...

Quote

In essence, the validators running Geth have committed to the invalid chain and are locked into that chain until the non-Geth chain finalises. This is the critical risk that many misunderstand.

Because the Geth validators are stuck on the invalid chain, they are considered inactive on the non-Geth chain and will suffer the inactivity leak. No software update or bug patch to Geth will save these validators. They will be bled out until their stake represents < ⅓ of the network, allowing the non-Geth chain to finalise.

oder hab ich da was falsch verstanden?

Das habe ich beim - zugegebenernmaßen - schnellen Lesen des Artikels auch nicht verstehen.

Angenommen, für den hypothetischen Geth-Fehler kommt genauso ein Patch nach 4h. Müsste Geth beim Wiederanlaufen nicht ebenso die fehlerhaften Blöcke erkennen und beim letzten gültigen wiederaufsetzen? Warum ist Geth auf der fehlerhaften Chain gefangen?

China hat letztes Jahr mehr PV-Leistung zugebaut, als die USA (als zweitbester) überhaupt haben.
 

China is the world leader in renewable energy, including 40 percent of the planet’s entire solar capacity, reported Rystad Energy. The United States comes in second place with 12 percent.

Last year, China installed more new solar capacity than the total amount ever installed in any other country, Bloomberg reported.

[...]

According to China’s National Energy Administration (NEA), the country increased its solar capacity by 216.9 GW last year, eclipsing its record of 87.4 GW from the previous year, reported Bloomberg. That’s more than the U.S. total of 175.2 GW, estimates by BloombergNEF said.

https://www.ecowatch.com/china-new-solar-capacity-2023.html

1 hour ago, ChrisOha said:

Was mir nicht so gefällt ist, dass Kaspa jetzt ziemlich an Bitcoin hängt und allgemein das Volumen niedrig ist. 

Ja, von der Euphorie und Aufbruchsstimmung, die bis November geherrscht hat, ist nicht mehr viel zu spüren.

55 minutes ago, Jawline said:

Dennoch stimmt es das die Armut auf der Welt gesunken ist obwohl die Bevölkerung gestiegen ist, also ist vornehmlich deine Aussage die Armen werden ärmer und die Reichen Reicher sehr simplifizierend und auch falsch.  

Das geht aber auch etwas durcheinander ...

Die globale Armut ist geschrumpft, weil ein paar Länder mit großen sehr armen Schichten (z.B. China) ein bisschen aufgeholt haben.

Aber die lokale Armut in etlichen westlichen Ländern hat sich verstärkt, weil dort Bevölkerungsschichten ärmer werden.

31 minutes ago, ratzfatz said:

Wenn es so ist wie du denkst, und ich glaube du hast recht damit, dann solltest du noch schnell heiraten bevor es zum eventuellen Bullrun kommt. 😉

Es wird sicherlich ab dem Tag gerechnet an welchem du im Standesamt unterschreibst. 

Rein mathematisch:

Müsste er, falls er recht hat, nicht erst erst nach dem Bullrun heiraten?

Wenn der Teil des Wertzuwachses der Bitcoins, der erst während der Ehe passiert, geteilt werden müsste, dann will er diesen Wertzuwachs doch besser schon bekommen, bevor die Ehe anfängt.