Nein, wird es genausowenig wie z.B. die Whatsapp Herrschaft im Messenger-bereich von einem Gremium entschieden wird.

Genau, es gibt auch Späteinsteiger, wie z.B. mich. 


Angst an der Börse wird ein Fest für die Profi-Spekulanten. 

Also ihr seid schon eine verwöhnte Bande! Vor einem Jahr hättet ihr bei 1000 EUR/BTC Freudentänze aufgeführt und Raketenbilder gepostet.  

Aber wie hat Einstein schon gesagt? Alles ist relativ und es gibt nur zwei Dinge, die unendlich sind ... 

Ja, 2MB am einem zu bestimmenden Block in der Zukunft ist kein Problem. Das sind nur wenige Zeilen Code, die jeder Softwareentwickler einfügen kann. Daneben sollten noch die Tests angepasst werden und die Änderung mit etwas Vorlauf im Testnetz aktiviert werden. Ingesammt ist das kein nennenswerter Aufwand.

Der tatsächliche Aufwand steckt darin, diese Änderung im Vorfeld mit allen (vernünftigen) Nutzern abzustimmen und notfalls Unterstützung zu leisten (Änderung/Anpassung aller bisherigen Lösungen). Dieser Punkt macht den Löwenanteil der Änderung aus - ausser man ist auf Konfrontation aus. Dann rotzt man einfach schnell einen Quick'n'Dirty Patch in die Welt, verbreitet kräftig FUD und greift jeden Kritiker persönlich an.

Vom Regen in die Traufe? Nein.

Ich denke ich würde dann einfach das Experiment als gescheitert betrachten, da die Zeit (der überwiegende Teil der Community) für sowas (noch) nicht reif ist.

Ich vermute stark, das geht den allermeisten "Investoren" ebenso. 


Und wenn doch, wäre es auch kein Beinbruch. Sehe es einfach als Gelegenheit für einen günstigen Einstieg. Es gibt ja hier Leute die auf 600 warten. 

Richtig, ET? ist kein Coin und die Tokens sind Gas (also Sprit für die Scripte) - ähnlich wie bei XRP. Umso verwunderlicher ist die ganze Sache, denn diese Token werden nur benötigt, um Scripte zu befeuern. Da es aber nicht massiv viele Anwendungen gibt und daher nicht endlos viele Scripte befeuert werden müsse, ist eigentlich auch kein grosser Bedarf an Tokens da. Egal, ich muss ja nicht alles verstehen.

Ob sich BTC im Downtrend befindet und damit wieder einmal tot ist, wird sich zeigen. Eine endgültige Klärung wird es nämlich nicht geben, da der nächste "unbedingt notwenige Hard-Fork" mit Sicherheit bereits in Vorbereitung ist. Eine endgültige Lösung kann es nur durch vollständige Kapitulation geben.

BTU werde ich sicher nicht halten. Sollte die Herde BTU folgen, werde ich auch keine BTC halten.

Im Augenblick sieht es aber nicht so aus, als ob BU einen Fork machen möchte. 1 Poolbetreiber / ASIC Hersteller und 100 Herdentiere machen noch lange keinen erfolgreichen Fork. Wenn die anderen Poolbetreiber schlau sind, werden sie sich darüber freuen, dass ihr grösster Konkurrent aufgegeben hat und sie nun mehr Anteil haben. Die grosse Core Nutzerbasis und die existierenden Services sollten dafür genug Anreiz liefern.

Indem Du beim Aufruf z.B. die Option "-prune=1000" bzw. in der Konfigurationsdatei "prune=1000" angibst, dann wird von der Blockchain nur noch ca. 1GB gespeichert und noch ein paar GB für UTXO Set / Verwaltungsinfo.

Double Spend funktioniert nicht, da die meisten Knoten eine Transaktion nicht aktzeptieren, wenn diese mit einer bereits im Mempool existierenden Transaktion kollidiert (also Inputs nochmal nutzt).

CPFP funktioniert, wenn man den Key für mindestens einen Output der unbestätigten Transaktion hat.

Interessant. Was vermutlich auch noch gefragt wird: Musst Du tatsächlich der Empfänger der Ware sein, oder reciht es, wenn Du der Rechnungsempfänger (d.h. Käufer) bist? Im letzten Fall könntest Du auch Wunschlistenbestellungen anbieten, dann würde das Waschmaschinenproblem entfallen.

Verstehe ich das richtig, Du bietest eine Dienstleistung (nennen wir es Amazon Logistik Abwicklung) an und bezahlst dafür 5% vom Warenwert an Deine Kunden?! 

Das wäre in diesem Umfeld aber nichts neues.

Das Problem daran ist, dass die Eingangsparameter für einen solchen Änderungsalgorithmus nur aus den Blöcken (sicher) abgeleitet werden kann. alle anderen Quellen für diese Parameter sind manipulierbar. Dies verschiebt aber die Kontrolle hin zum Mining, was gerade in der aktuellen Umgebung - gepägt durch wenige Pools in der Hand noch weniger Betreiber - unerwünscht ist.


Es gibt diverse Möglichkeiten, die das aktuelle System erlaubt. Wichtig ist, dass die Knotenbetreiber sich ihrer Möglichkeiten durch die Verifikation bewusst sind und nicht einfach blind dem Argument, sie hätten sowieso gegenüber einem Miner nichts zu melden, folgen.


Nicht das ich wüsste. Ein Teil der Idee stammt aus dem Bereich UTXO Commitment, bei dem ein Hash über das UTXO Set in den Blockheader aufgenommen wird. Diese erlaubt dann einen sicheren Bootstrap, basierend auf einem bereits aktzeptierten/verifizierten UTXO Set und erweitert das Pruning.


Wäre interessant, aber es ist relativ schwer, im aktuellen Nebel der Diskussion echte Details zu finden. Für die Prüfung des BU Code fehlt mir irgendwie der Antrieb.


Dann ist das eben so. Glücklicherweise muss ich der Herde zumindest hier nicht folgen.

Nach den kürzlichen Ereignissen könnte man vermuten, dass der Anteil an Core Betreibern sogar deutlich über 83% liegt. 


Warum befürchtest Du das?

Aber ja, wenn die Leute sich entscheiden, dass ihnen ein BU-Coin mehr Wert ist als ein Bitcoin, dann würde genau das passieren. In diesem Fall müsstest Du im Vorfeld entsprechend handeln und vor allem sicherstellen, dass die Coins vor dem Fork unter Deiner alleinigen Kontrolle sind. Falls Dir dann die BU-Coins nicht zusagen, kannst Du (mit einigen Tricks und Kniffen) die BU Coins teuer verkaufen und die BTC behalten. Oder Du verkaufst alles und suchst Dir was anderes.

Ich habe bei Kraken (noch) nichts. Allerdings habe ich keine Lust (vielleicht in einigen Jahren) etwas vom MtGox Insolvenzverwalter zu bekommen, um es dann an Kraken zu verlieren.

Core has delivered. If you like it or not is a different topic.

Nur soviel dazu: Es muss nicht zwingend alles automatisch vorgeplant ablaufen. Kontrollmöglichkeiten durch die Nutzer sind nicht generell etwas schlechtes!


Die Miner (wichtig: faktisch Pools) haben nur solange Macht, solange der Rest der Nutzer ihnen diese gibt. Es gibt durchaus Handlungsmöglichkeiten für die Nutzer, sich nicht von 3-4 Pools (evtl. kontrolliert von einem Betreiber!) blockieren zu lassen.


Die Zusammenschaöltung lässt sich nicht verhindern, ist aber massiv ineffizient, wenn in jeder Runde der vollständige Block und das UTXO Set benötigt wird. Ein Mining Knoten, der diese Informationen hat, ist sowieso nahezu vollständig funktionsfähig und hat keinen Grund mehr, sein Ergebnis bei einem Pool abzuliefern. Nebenbei erzeugt alleine die Übertragung des jeweils aktuellen Blocks einen massiven Overhead, sodass lokales Mining deutlich effizienter wird. Daneben lässt sich ein solcher Algorithmus nicht mehr auf einem einfachen ASIC umsetzen. Interessant, da der blockierende Poolbetreiber gleichzeitig der ASIC-Baron ist.


Das Problem der BUler ist, dass es keine feindliche Übernahme geben kann, solange das Netzwerk grösstenteils aus Nicht-BU Knoten besteht. Mit dem Versuch würden sie sich selbst aus dem Netz forken. Unter diesem Gesichtspunkt ist auch das lautstarke Auftreten und die Implikation einer Herrschaft der Poolbetreiber zu sehen. Statt dem Fork könnten sie mit dem selben Effekt auch einfach das Mining abschalten.

D.h. mit Tier 2 kann man bei Kraken gar nichts mehr machen? (Mein Geld nicht bekommen ist für mich = nichts!)

SPV Mining is the opposite of playing well!