Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 61. (Read 185830 times)

Ja BU in seiner aktuellen Form ist einfach ein Wunschtraum, der sich nicht mit der Realität vereinbaren lässt.

Zum anderen - mein persönliches Problem, was ich mit Segwit habe ist der 75% Discount - mit allem anderen habe ich kein Problem, oder finde das sogar sehr gut gelöst.

Technische Kritik an Segwit ist auch schwer. Und diese "Anyone-Can-Spend ist so unsicher" Kritik und Co. kann man total vergessen, weil dann wären alle Bitcoins potentiell Anyone-Can-Spend, weil nach der Logik die Miner die Regeln festlegen / ändern könnten, wird aber auf /r/btc & Co. immer mit wiederholt.

Zum anderen ist es auch eine interessante Qualität, die Bitcoin zeigt, dass es nicht leicht zu ändern ist.
Vielleicht sehen das andere bei Bitcoin auch so.
Für mich ist das eher von geringerem Wert, da solange wir keine Layer 2 Blockchain (aka Extension Blocks haben) die Fähigkeit sinnvolle Änderungen an den kanonischen Blöcken durchzuführen etwas wichtiger ist.

Zum anderen haben wir gerade ein recht starkes Momentum, was UASF angeht.
BU/EC hat es in den letzten Tagen schon fast eingeholt bei der Zustimmung: https://coin.dance/poli
Die größte Hürde für eine Teilnahme der breiten Masse sind meiner Meinung nach aktuell noch vorkompilierte Binaries aus einer "vertrauenswürdigen" Quelle.

Weiteres Momentum könnte aus der möglichen Aktivierung von Segwit bei Litecoin hervorgehen.

Mit gleichgültigen Nutzern, und einem Opt-Out UASF in einer Core Binary 0.14.2 würde das ganze mal interessant werden.

Die 30% Miner könnte sogar funktionieren, die breite Unterstützung durch die Nutzer wird es nicht.


Ohne die Nutzer bzw. mit gleichgültigen Nutzern wird genau nichts passieren. Ist auch eine Form der Abstimmung und das Ergebnis ist zumindest besser als ein BU Präsident.

Wie soll das funktionieren?
Die Pools brauchen nur ein paar Sekunden um sich über FIBRE, Cornell-Falcon-Network und XThin Xpedited alle auszutauschen.
Alle Miner arbeiten bereits aufgrund des so verbreiteten Blocks.

Parallel dazu findet der Block über das Bitcoin-P2P Network seinen Weg - wie lange das dauert hat aber keine Auswirkung aufs Mining, da die Miner ihre eigenen Netze haben. Selbst wenn das einige Stunden dauert haben die Miner sich ja bereits außerhalb des Bitcoin-P2P-Networks ausgetauscht und arbeiten auf einer gemeinsamen Blockchain.

Was du in deinem Knoten einstellst ist den Minern egal, weil die das Bitcoin P2P-Network nur als Rückfallebene benutzen, bzw. da die sich ja bereits vorab über die Relay-Netzwerke ausgetauscht haben. Die entscheidende Latenz ist deswegen diejenige zwischen den Minern in den von den Minern genutzten Verbreitungsarten (FIBRE etc.) und da ist das Bitcoin-P2P Netzwerk das wir benutzen unwichtig.

Wenn ich meinen Core Knoten an die Briding Funktion eines Cornell-Falcon-Netzwerk Knoten verbinde, dann bekomme ich über dessen Bridging-Funktion in das Bitcoin P2P Netzwerk die Blöcke deutlich bevor andere Knoten mir das über das Bitcoin P2P Netzwerk anbieten.
Kann ich allen empfehlen, die sich mal von der Leistungsfähigkeit ein Bild machen wollen - ggf. mit Wireshark die Meldungen abfangen.

Außerdem gibt es immer noch Spy-Mining, was auch komplett am Bitcoin P2P Netzwerk vorbei geht.

Die Latenz schadet sowieso immer nur den kleinen Minern, bzw. dem Teil, der die geringere Hashpower hat, denn sonst erzeugt man durch die Latenz denjenigen, denen man schaden möchte ggf. sogar noch einen Vorteil. Aktuell ist das nicht der Teil, den die meisten bestrafen wollen.

Was ein Knoten unterstützt kann man sowieso nicht sagen. Ein Miner kann einen Knoten nutzen um die eingehenden Blöcke zu bekommen, diesen aber so einstellen, dass dieser niemals Blöcke nach außen weitergeleitet.
Von außen ist der nicht als solcher zu erkennen. Aktuell haben wir wahrscheinlich bereits einige Knoten die sich als BU ausgeben, obwohl es Core Knoten sind und andersrum.
Was will man da sperren?

Selbst wenn, die Mining-Pools sorgen aktuell selbst dafür, dass Ihre Blöcke so leicht nach außen erkennbar sind. Damit können die aber jederzeit aufhören und zusätzlich Maßnahmen ergreifen um die Herkunft eines Blocks zu verschleiern. Das macht die Situation festzustellen, wer was wie unterstützt dann total unübersichtlich.

Ich sehe einfach keinen Vorteil dadurch, dass man da irgendetwas sperrt, außer das man die funktionalität von normalen Nutzern verschlechtert.

Der einzige Ansatzpunkt den ich sehe sind da aktuell die BIP 9 Version Bits in den neu geschürften Blöcken, aber da sehe ich keine Möglichkeiten etwas an der Latenz zu tun, ohne dass das unerwünschte Auswirkungen hat.

Ganz sperren, also den block als ungültig anzusehen, wie bei einem UASF kann wieder funktionieren.
So lassen sich zumindest die Auswirkungen abschätzen.

Achtung - Missverständnis - Ich spreche von einem PoW Change. Wenn man sich tatsächlich gezwungen sieht einen PoW Change durchzuführen, impliziert das für mich, dass man erkannt hat, dass PoW in der aktuellen Form versagt hat, sonst hätte man ja den PoW Change nicht initiieren müssen. Ich spreche nicht davon, dass PoW grundsätzlich nicht funktionert.
Aber einfach nur den Hashing-Algorithmus zu ändern reicht da nicht meiner Meinung nach, weil es wieder zur gleichen Situation führen kann.

Fände es besser, wenn wir eher gucken, wie wir es schaffen trotz der Situation klar zu kommen.
UASF mit min. 30 % Miner Unterstützung und breiter ökonomischer Unterstützung - klar ich bin dabei.
In dem Fall gehe ich nämlich davon aus, dass die Mehrheit der Miner folgt.

Ansonsten bin ich eben auch zufrieden mit Rootstock und was sonst noch so kommt und würde es bevorzugen, wenn der UASF ausfällt.

Die Latenz erhöht die Wahrscheinlichkeit, dass ein anderer Miner einen "besseren" Block der gleichen Höhe findet! Immer wenn das passiert verliert der Miner den Block Reward und die Fee. Je mehr Knoten die Blöcke nicht weiterleiten, desto höher wird die Wahrscheinlichkeit für den Miner, dass der das Rennen für einen gefundenen Block verliert.


Dann ist der Betreiber offensichtlich mit dem Ablauf zufrieden. In diesem Fall ist keine Option einzustellen auch eine gültige Auswahl.


Ich sehe nicht, dass PoW nicht funktioniert. Letztendlich hat nur das gewählte Verfahren schwächen, da es Arbeit ohne Entscheidungsgewalt (Pool Mining) erlaubt.

Ich weiß immer noch nicht, was du meinst.
BIP 148 UASF Knoten leiten nur Blöcke weiter, die Segwit Version Bits gesetzt haben.

Die Latenz zwischen den Knoten ist für Miner aber irrelevant. Welchen Miner stört das schon, wenn ein Block jetzt 10 Sekunden braucht um durch das Netzwerk zu kommen oder 2 Minuten.
Wichtig ist doch nur die Latenz zwischen den Pools - siehe mein vorheriger Post (FIBRE, Cornell Falcon Network)
Und solange die Pools untereinander sich nicht blockieren zählt doch nur, ob die Blöcke als gültig anerkannt werden oder nicht und nicht, wie lange es dauert, bis die ankommen, weil immer noch alle in der gleichen Kette sind.

Ich weiß, dass man jede Menge einstellen kann, praktisch passiert das aber nicht, bzw. nur ein kleiner Bruchteil der Knoten stellt aktuell etwas ein.

Ja die Hashleistung zählt primär nur um gegenüber 51% Angriffen geschützt zu sein.
Allerdings heißt eine höhere Hashleistung ja auch, dass die Sicherheit vor 51% Angriffen höher ist und führt somit indirekt zu einer höheren Akzeptanz.
Die Faktoren beeinflussen sich also gegenseitig in einem gewissen Rahmen.
Die niedrigere Hashleistung führt denke ich so leider auch zu einer niedrigeren Bewertung, sei es auch nur temporär.
Ich denke, dass der Effekt geringer ist, aber was wirklich passiert ist für mich unklar.

Hashleistung an sich bleibt aber erstmal wertlos, dazu muss man mehr bieten.
Das ist klar aus dem Gedankenexperiment, wenn 100% aller Miner beschließen sie müssten ab sofort für immer 100 BTC pro Block bekommen.
Aber was passiert, wenn man jetzt aber mit der Hashleistung erzwingen kann, dass es praktisch keine Alternative gibt, sondern nur die ursprüngliche Chain, die bereits alle akzeptieren?

Wenn man dann trotzdem segwit haben will, würde man durch den Gegner mit seiner Hashleistung dazu gezwungen, dass man alle alten Clients upgraden muss, weil diese nicht zwischen den neuen Ketten unterscheiden können.

Das wäre für Nutzer sehr verwirrend. Unterschiedliche Leute hätten dann unterschiedliche Ansichten, wer das echte Bitcoin wäre.

Und bei dem oft genannten PoW Change kommt mir da eines immer wieder in den Sinn:
Okay wir wissen, dass PoW nicht funktioniert, weil es zu einer Zentralisierung kommt bzw. die ökonomischen Anreize nicht ausreichend funktionieren, aber versuchen wir es einfach noch mal.
Da wäre mir dann PoS oder Hybrid PoW/PoS lieber.

Außerdem macht es ein PoW Change schwieriger für sich zu proklamieren, dass man das einzige echte Bitcoin wäre.

Die Weiterleitung von Blöcken hängt nicht vom UASF ab! Jeder Knoten kann heute schon ohne grosse Nachteile (evtl. höhere Confirmation Latenz) entscheiden, Blöcke nicht weiterzuleiten. Passiert dies zielgerichtet und auf breiter Ebene gegen Pool-Blockaden, haben die blockierenden Pools Nachteile bei der Verbreitung ihrer gefunden Blöcke. Das sorgt erst mal nicht für einen Fork, sondern bringt lediglich einen Nachteil für diese Poolbetreiber. Tatsächlich müsste das jeder Knotenbetreiber im eigenen Interesse jetzt schon machen, immerhin stellt er die Leistung für den Knoten zur Verfügung und bezahlt diese auch. Jeder Knotenbetreiber müsste daher ein Interesse daran haben, dass diese Leistung nicht für Aktionen gegen sein Interesse genutzt wird.

Bei einem Fork zählt letztendlich nicht die Hashleistung, sondern die Aktzeptanz. Mittelfristig führt eine niedrige Aktzeptanz zu einer niedrigen Bewertung. Eine niedrige Bewertung wiederum führt zu einer sinkenden Hashleistung, d.h. das System wird (muss!) sich auf Dauer ökonomisch einschwingen.

Ja allerdings sind die normalen ökonomischen Knoten da zunächst irrelevant.
Die Miner haben ja zusätzlich ihre eigenen Netze (Bitcoin Relay Network), da könnte man auch ansetzen.
Während ich mir eine Unterstützung bei FIBRE für BIP 148 theoretisch vorstellen kann, wird das bei dem Cornell Falcon Network sicherlich schwerer, vor allem weil es den Block schon weiterleitet, bevor es den vollständig empfangen hat und nicht überprüft. Bei BIP 148 wäre aber eine Unterstützung zumindest technisch denkbar, weil die Version Bits ja so früh im Header kommen. Und manche Miner setzen auch eigene Netze auf XThin xpedited auf. Kann mir kaum vorstellen, dass jemand da in BU die Unterstützung einbauen wird.

Ich denke der Zustand den du beschreibst hängt vom Szenario ab:
Szenario 1 - UASF konforme Miner haben mehr Hashpower und somit die längere Kette an Blöcken:
Miner, die nicht UASF konform sind sehen die Blöcke, die UASF-Miner erstellen als gültig an und minen auf dieser Kette. Sobald diese einen Block erzeugen, sehen nicht UASF konforme Miner diesen als gültig an. Ggf. schaffen es die nicht UASF konformen Miner einige Blöcke zu erzeugen, die UASF Miner werden jedoch diese Blöcke mit einer längeren Kette später verdrängen und es kommt zu kleinen Reorgs.

Die nicht UASF konformen Miner müssen natürlich jetzt handeln, sonst könnte es sein, dass Sie über 4 Wochen Hashzeit verschwenden.
Entweder schließen diese sich den anderen Minern an, oder provozieren gemeinsam einen koordinierten Chain-Split mit einer Minderheit der Hasrate - das geht sowohl über einen Soft Fork, der zum Beispiel sagt Blocks mit Segwit Version bits sind ungültigt oder direkt einen bilateralen Hardfork, also mit Schutz vor Auslöschung (wipeout protection).
Natürlich können die Miner auch einfach die Unterstützung für den UASF faken und so ihre Entscheidung verschieben, dazu müssen die Miner ja nur ihr Block-Template ändern und sie müssen nicht updaten.

Das heißt solange der UASF-Verdrängungs-Kampf aktiv ist kann man als Benutzer vorübergehend nicht auf wenige Bestätigungen setzen,weil diese mit überdurchschnittlicher Wahrscheinlichkeit wieder verschwinden, sondern sollte lieber auf 6++ Bestätigungen warten. Denn während dessen sehen alle Knoten, welche nicht upgegraded haben kurzfristig nicht UASF kompatible Blöcke, die dann aber durch UASF Blöcke ersetzt werden. Dieser Zustand sollte aber nur kurzfristig herrschen, bis die nicht UASF konformen Miner gehandelt haben.

Szenario 2 wäre UASF haben nur eine Minderheit der Hashrate, aber die höhere ökonomische Unterstützung
UASF wird aktiviert
Sobald ein nicht UASF konformer Miner einen Block erstellt kommt es mittelfristig zum chain split.
UASF-konforme Miner bauen ihre eigene Minderheiten-Hashrate Blockchain.
Das geht, da durch den UASF ein Schutz vor Auslöschung für die UASF Kette besteht.
Für die nicht UASF Kette besteht übrigens kein Schutz vor Auslöschung.

Knoten ohne UASF upgrade (alle bisherigen Versionen von Core, Unlimited, Classic) sehen einfach immer die Kette mit am meisten PoW, die mit UASF upgrade natürlich nur die UASF Kette.

Jetzt wird es wirklich interessant.
Bitcoin ist für einen nicht technisch versierten Nutzer in dem Zustand schlecht nutzbar, auch wenn man mit einem alten Client über RPC und invalidateblock einstellen kann, welcher Fork man folgen will.

Die Frage ist dann, zu welchen Preisen die Bitcoins gehandelt werden und welche Effekte das hat.

Die nicht UASF-Miner müssen sowieso in ständiger Angst leben, dass ihre Kette ausgelöscht wird, falls die UASF Miner doch noch die Merheit der Hashrate bekommen. Sie können sich zwar selbst vor Auslöschung schützen, indem Sie per Softfork den ersten UASF-Block als invalid erklären (das geht auch über RPC mit invalidateblock), allerdings müssten Sie auch nicht Miner davon überzeugen, weil bei allen, die nicht vorsorgen kann es jederzeit zu großen Reorgs kommen, die dafür sorgen, dass es aus ihrer Sicht vereinfacht gesagt mal nur die eine, dann wieder nur die andere Kette gibt.

Die Exchanges müssen sich natürlich vorab dagegen absichern, damit sie keine Bitcoins verlieren. Entweder können Sie dann während dieser Zeit einfach verbieten, dass man neue Bitcoins an Sie sendet und auch das abheben in der Zeit deaktivieren, oder sie unterstützen direkt vorab den UASF.

Auch als normaler Benutzer, kann es sein, dass man mehrere 100 Bestätigungen warten müssen um sich sicher zu sein, dass man wirklich die Bitcoins empfangen hat.

Da gibt es dann wirklich extrem viele Varianten, wie es weiter gehen könnte.
Wenn der UASF nicht abgesagt wird, aber nicht genug Unterstützung hat, könnte sich das ganze eine Weile hinziehen.

51% Attacken auf den UASF sind übrigens nicht so einfach. Dazu bräuchte man eher 70% der gesamten Mining Power, denn man muss dafür sorgen, dass der nicht-UASF-Fork aufgrund dem fehlenden Schutz vor Auslöschung immer vor dem UASF-Fork ist, und gleichzeitig braucht man noch mal mehr Hashpower, als die UASF-Miner, um auch dort leere Blöcke oder Blöcke mit unsinnigen Transaktionen zu erstellen und so eine längere Fake-UASF Kette zu erstellen.
Insgesamt braucht man während der UASF Phase also mehr als doppelt so viel Hashpower, wie die UASF-Miner um die UASF Chain anzugreifen.

Mit 30% initialer Hashpower pro UASF könnte der UASF also funktionieren - und die Hashpower ist zumindest in Reichweite.
Soweit die Pools, die aktuell auch Segwit minen den UASF durchziehen würden, denke ich, dass der ökonomische Druck genügen würde, dass der Rest der Miner sich anschließen würde.
Falls der UASF erstmal eine kritische Schwelle der Unterstützung überschritten hat, wird es fast unmöglich den aufzuhalten.

Ohne genügend Hashpower für UASF-Chain wird es immer schwerer vorherzusehen, was passiert.

Interessant ist aber, dass mit genügend ökonomischem Druck der Chain-Split nicht permanent ist, sondern über einen bilateralten Hardfork, mit kurzfristig 3 Forks, oder einen weiteren Softfork erzwungen werden muss, was den ökonomischen Druck mit dem BIP 148 UASF mitzugehen noch verstärkt.

Szenario 3 wäre UASF ohne starke ökonomische Unterstützung und dann wird der UASF abgesagt oder scheitert kurz nach Aktivierung, ist also uninteressant.

Edit:
Danke auch an dich, dass du dazu beiträgst.
Ich für meinen Teil gebe mir Mühe - hoffe, dass man den großteil meiner Bandwurmsätze verstehen kann.
Freue mich immer über konstruktive Kritik und Anregungen, denn so bekomme ich oft einen Anreiz mit einem anderen Blickwinkel oder noch detaillierter mir etwas anzuschauen. Falls irgendetwas von mir mal zu besserwisserisch / überheblich klingt, bitte freundlich darauf hinweisen.

Unsere deutschsprachige Community ist für mich persönlich definitiv angenehmer, als die englischsprachige. Vielleicht liegt das daran, dass es etwas teurer ist deutsche Astroturfer und Trolle zu kaufen XoD

Das momentane technische und respektvolle Niveau hier, schafft Vertrauen.

Da die Weiterleitungsregeln immer greifen verbreiten sich Blöcke mit von den Knoten nicht erwünschter Signalisierung langsamer (bei einem breiten Konsens praktisch gar nicht) im Netzwerk. Ein Miner der solche Blöcke erzeugt wird ab und zu (statistisch gesehen, abhängig von der Unterstützung) einen Block früher finden, wird aber von einem anderen Miner verdrängt der einen Block mit der erwünschte Signalisierung später findet.


UASF ist kein normaler Soft-Fork, führt also früher oder später zu einem Split. Das ist ein Sonderfall, da es normalerweise nicht den Fall 3-4 Miner und ein paar Mitläufer gegen den Rest der Nutzer gibt (geben sollte). Eine kleine Gruppe, die das System einnehmen möchte ist normalerweise (im Interesse der meisten Nutzer) unerwünscht und sollte ökonomisch bestraft werden. Dies funktioniert durch die unvorhergesehene Entwicklung des Pool Mining und die (vorsichtig ausgedrückt) sehr spezielle Persönlichkeitsstruktur der Hash-Lieferanten leider nicht (mehr).

Ja, das ist auch mein Verständnis.
UASF BIP 148 sorgt dafür, dass Segwit BIP 141 (und BIP 143) über die BIP 9 Version Bits (Softfork Flags) aktiviert wird.
Solange Segwit eben nicht über BIP 9 aktiviert wurde, werden die Blöcke von UASF Knoten nach dem Flagday einfach abgewiesen.
Bei BIP 148 ist es so, dass wenn Segwit dann aktiv ist, oder wenn die MedianZeit nach Wed 15 Nov 2017 00:00:00 UTC überschritten ist, wird BIP 148 inaktiv, also legen die aktiven Konsens Regeln inkl. aktiver Softforks wieder fest, welche Blöcke gültig sind und somit weitergeleitet werden.

Aber was meinst du mit "Bad Luck"? Entweder steht die überwiegende ökonomische Mehrheit hinter dem UASF oder eben nicht, das sollte am Flagday hoffentlich absehbar sein. Der Miner folgt dann eben seinen eigenen Zielen (ob nun politisch oder ökonomisch).

ASICBOOST kollidiert übrigens nach meinem Verständnis noch nicht direkt mit Segwit / BIP 141, da kein Miner gezwungen wird Segwit-Transaktionen in den Block aufzunehmen und es im BIP heißt
Naja Miner müssen schon upgraden um sich sicher zu sein, dass ihre Blöcke weiterhin valide sind und sie eben nicht eine wertlose Chain verlängern - zur Not eben mit Edge-Nodes.

Softforks sind für Miner in der Regel nicht Opt-In, weil das ökonomische Risiko zu hoch ist, dass es sonst zu einzelnen verwaisten Blöcken oder sogar zum permanenten Chain-Split kommen kann. Deswegen gibt es ja BIP 9 um dem vorzubeugen.

Andererseits können Miner jederzeit selbst Softforken, soweit Sie die Mehrheit der Hashpower haben, ohne, dass wir das überhaupt bemerken würden, weil unsere (Core-)Clients noch alles akzeptieren, theoretisch denkbar zum Beispiel bei Extension Blocks. Miner müssen ja nicht über BIP 9 und über Core koordiniert einen Softfork ausführen. Core Clients würden die Extension Blocks einfach ignorieren - es gäbe keinen Chainsplit (außer durch einen absichtlichen Counter-Softfork), aber trotzdem gab es einen Softfork, der den Core Clients eben nicht bewusst ist Oligopol hin oder her.

Bei UASF sehen wir eben erst hinterher, was Sache ist. Vorher gibt es ggf. Möglichkeiten über synthetische Produkte die an Börsen gehandelt werden Indizien zu sammeln, wie es ablaufen wird. Put Optionen oder Futures wären da extrem interessant.

Vielleicht verstehe ich gerade nicht ganz, was du mir sagen willst. Softforks führen ja eher selten zu Chain splits, aber bei BIP 148 hängt das eben sehr von der Unterstützung ab. Wenn die ökonomische Unterstützung nicht groß genug ist, wird nie ein Miner UASF aktivieren und es wird die UASF chain nie geben, weil kein Miner daran arbeitet.

Einen interssanten Artikel über die Arten von Soft und Hard Forks gibts übrigens von Vitalik Buterin:
http://vitalik.ca/general/2017/03/14/forks_and_markets.html
Mit Counter-Softfork meine ich übrigens, wenn praktisch 2 verschiedene Soft Fork Kreise im Kreis "Things valid under the original protocol" sind und ggf. überlappen. Counter-Softforks können logischer Weise sowohl von Minern ausgehen, als auch durch einen UASF erfolgen. Oder es gibt natürlich auch die Methode die Vitalik am Ende beschreibt, damit Miner den UASF umgehen können mit einem eigenen Softfork.

Das ist auch richtig, allerdings funktioniert es leider meiner Meinung nach auch nicht so einfach.
Die Miner haben natürlich über PoW eine wunderbare Möglichkeit für Softforks dezentral zu einer Entscheidung zu kommen.

Wir haben allerdings ohne die Miner keine so eine einfache Möglichkeit. Und je mehr Optionen man anbietet, desto schwieriger wird das zu handhaben. Wenn Core einen Client rausgebracht hätte, der einen 2 MB Hardfork als Wahl einfach zugelassen hätte, dann hätte es meiner Meinung schon vor langer Zeit einen 2 MB Hardfork gegeben, gab es aber wie wir wissen aus diversen Gründen eben nicht. (ja HF ist ein schlechtes Beispiel, aber wir hatten eben noch keine SF Vorschläge, die nicht über Core gegangen sind)

Das erinnert mich etwas an Tone Vays - vielleicht hat jemand die Debatte mit Ver noch im Kopf.
Das ist schon eine relativ prominente Person, die sich viel mit Bitcoin beschäftigt, aber er hat gesagt, das er seine technische Expertise an Core outgesourced hat und denen vertraut, also macht was die sagen.
Und der gehört meiner Meinung nach schon zu den Leuten, die sich besser auskennen.
Es muss für den Endanwender möglichst einfach bleiben.
Ich könnte mir vorstellen, dass dein Vorschlag da leider zu kompliziert ist.
Ein Opt-Out für UASF wäre wesentlich einfacher für einen Endanwender zu verstehen und moralisch noch vertretbar.

Ich hätte es auch gerne anders, aber ich glaube nicht, dass das realistisch ist.
Node Signaling kann man als Metrik einfach vergessen, weil es absolut unzuverlässig ist.
Und leider haben wir keine in Bitcoin anderen eingebauten Konsens Methoden (vgl. DASH Masternodes - nein ich finde DASH nicht gut).
Also brauchen wir einen Seitenkanal zum Informationsaustausch und das ist eben wesentlich einfacher, je weniger Wahlmöglichkeiten es gibt. Also ist eine Vorinstanz, die die Auswahl verringert meines erachtens aktuell leider notwendig.

Einschränkungen beim Weiterleiten sind nur vor einem BIP9 Fork sinnvoll und sorgen bei breiter Anwendung für "Bad Luck" bei den betroffenen Minern.

Richtig ist, dass Soft-Forks nur die wenigen Miner betreffen. Ohne breite Aktzeptanz bringt aber einem Miner-Oligopol die vermeintliche Mehrheit auf einem Soft-Fork nichts, da sie auf einer wertlosen Chain arbeiten.

Der von mir vorgeschlagene Weg bietet nur eine Schnittstelle, implementiert aber im Gegensatz zu UASF keine eigene Regel. Es ist ein Unterschied, ob man einem Nutzer eine fertige Lösung vorsetzt (friss oder stirb) oder ob man ihm die Möglichkeit gibt, eine Lösung zu bauen bzw. zu konfigurieren. Manche Zeitgenossen scheinen allerdings den Unterschied nicht zu verstehen (bzw. wollen ihn nicht verstehen), dabei liegt genau in diesem Punkt der feine Unterschied zwischen Freiheit und Herrschaft.

Wieso nicht beim Weiterleiten?
Deine Knoten würde nach dem Flag Day doch alle anderen Blöcke ignorieren und die anderen Knoten bannen, die nach deiner Einstellung ungültige Blöcke senden.

Verstehe auch nicht, was du meinst mit Softfork.
Ja - Hardforks führen höchstwahrscheinlich zu einem chain split, wenn sich nicht alle Miner einig sind und die überwiegende ökonomische Mehrheit hinter dem Hardfork wissen, weswegen BU in den nächsten Jahren keine Option ist.

Softforks ohne überwiegende Miner Unterstützung können aber ebenso zu chain splits führen, wenn die clients, welche die neuen Regeln nicht anwenden / kennen / unterstützen mehr Mining Power haben, als die Knoten, welche die strengeren Regeln (z.B. BIP 148 UASF) anwenden.
Alte clients landen dann einfach auf dem Fork, der mehr Mining Power hat, welcher auch immer das ist.

BIP 148 kann wunderbar mit der Minderheit der Hashpower funktionieren, soweit es nicht angegriffen wird.
Alte Clients sind dann aber nicht einfach kompatibel. Wenn alle upgraden müssen, hat es die wichtigste Eigenschaft eines Softforks verloren und ist praktisch wie ein Hardfork.

Das mag noch gut funktionieren, dass man für ein speziellen UASF (BIP 148) durch ökonomischen Druck die Miner dazu versucht zu zwingen auch die neuen Regeln anzuwenden, aber wenn jeder einfach selbst einstellt was er will, haben wir Emergent Consensus Softforks.

Ich sehe auch einfach noch nicht den Druck das jetzt unbedingt durchboxen zu müssen. Es gibt ständig neue Entwicklungen. Zum Beispiel in etwas weniger als 3 Monaten haben wir Rootstock.

Beim Weiterleiten gar nicht und bei der Akzeptanz von Blöcken nur dann, wenn eine Zentrale entscheidet, was das gewünschte oder unerwünschte BIP9 Flag ist. Nebenbei geht es bei BIP9 immer noch um einen Soft-Fork und keinen Hard-Fork. Daneben sind für die Aktivierung 95% und nicht 75% der Blöcke notwendig.

Hab ich mir auch gedacht. Aber in Angesicht des drohenden Aufstiegs der Altcoins und dem G von Bitcoins, ist das vielleicht doch die beste Lösung.

Das ist grundsätzlich natürlich auch in Ordnung.
Allerdings kommen wir da etwas in die Richtung, was BU macht mit EB/AD und das kann ich mir nicht direkt vorstellen von Core -> https://bitcoinmagazine.com/articles/how-bitcoin-unlimited-users-may-end-different-blockchains/

Wenn das kommt, dann würde das eher als spezieller Opt-Out Flag für BIP 148 kommen.
Das ist aus meiner Sicht moralisch auf der Grenze.
Bei einer GUI kann man das ja auch mit einem Wizard abfragen.

Eine sinnvolle Änderung wäre, jedem Knoten die Entschiedung über die BIP9 Flags per Konfiguration zu geben. Damit könnte jeder für jedes BIP9 Flag konfigurieren, welche Blöcke er weiterleitet oder aktzeptiert. Damit könnte jeder individuell das Verhalten des Knotens festlegen.

Danke für die Erläuterung, bin mir dem bewusst und hatte das auch bereits mehrmals in diesem Thread geschrieben, ist wohl aber nicht klar ersichtlich aus meinem Post gewesen. Finde den BIP von Maxwell in Ordnung, auch wenn die Auswirkung bzw. der finanzielle Vorteil mir deutlich übertrieben scheint. Siehe auch Verbesserung des BIPs von Sergio Lerner in der Mailingliste.

Allerdings bin ich auch der Meinung, dass die BIP 148 UASF Bewegung seit diesem Vorfall deutlich an Schwung gewonnen hat und eben andere Leute versuchen das auszuschlachten. Und da bin ich eben der Meinung, dass es zu früh dafür ist.

Ich bin dafür erstmal die Auswirkung von ASICBOOST abschwächen und dann weiterzuschauen.

Klar ist es aktuell politisch eine interessante Situation, wenn man einfach Segwit durchdrücken will, da aktuell die Gegenseite ein weiteres Glaubwürdigkeitsproblem hat und aktuell entsprechend noch schwächer ist.

Und ich wäre sogar damit einverstanden, den Leuten die Wahl zu geben.
Ich fände es akzeptabel, wenn Core jeweils 2 Binaries veröffentlicht - 1 mal ohne UASF und 1 mal mit UASF, ohne eine herauszustellen. Hat sowieso keine großen Auswirkungen, da der einfache Nodecounter nicht zuverlässig überprüfbar ist, wegen Sybil-Attacken.
Beste Metrik die ich kenne: https://coin.dance/poli
Und um einen hoffentlich einen Fall durchzuspielen, der reine Theorie bleibt: Falls Core direkt BIP 148 UASF Binaries veröffentlicht, wäre das für mich ein starkes Indiz, dass auch die Core/Blockstream Verschwörungstheorien wahr sind.

Ich bin auch nicht überzeugt davon, dass der BIP 148 UASF technisch funktioniert - mit 51% Hashpower können die Miner ja auch einfach Fake-Segwit Blöcke produzieren die zwar Segwit Unterstützung signalisieren, tatsächlich aber nur Transaktionen mit dem alten Transaktionstyp enthalten. Alle neuen Blöcke, die Segwit Transaktionen enthalten könnten die "bösen Miner" dann einfach verwaisen.

Wird schwierig das auszuhebeln, selbst mit einer Änderung des PoW.

Das ist eh, was gmaxwell mit seinem ersten Post vorgeschlagen hat -- einen BIP, der ASICBOOST blockiert, aber unabhängig von segwit ist.  (Miner müssten entweder segwit signalisieren, oder eine andere Änderung machen, die ASICBOOST auf die gleiche Weise blockiert.  Aber was davon bleibt ihnen frei gestellt, es ist also unabhängig von segwit.)  Das halte ich auch für einen guten Ansatz -- damit eben nicht "segwit oder ASICBOOST" die Frage ist, sondern beides unabhängig von einander entschieden und gelöst werden kann.

Ich finde es überhaupt nicht wichtig, ob Bitmain aktuell ASICBOOST nutzt oder nicht, ich finde eher das sie es nutzen könnten und es somit einen offensichtlichen Interessenkonflikt Konflikt gibt wichtiger. An allem Schuld sein wird das aber auch nicht.

ASICBOOST als Grund zu nutzen Segwit zu aktivieren finde ich moralisch nicht einwandfrei, dazu hätte sich Core auch einwandfrei verhalten müssen.
Den Hong Kong Konsens hätte es nie geben dürfen, da aufgrund die Core Entwickler aufgrund der Struktur von Core dazu kein Recht hatten, aber es wundert mich nicht, dass da einige Miner immer noch sehr verärgert sind, weil die beteiligten Core Entwickler sich nicht an den Geist der Vereinbarung gehalten haben, egal ob da ein Pool kurzzeitig Classic benutzt hat oder nicht.

(UA)SF um ASICBOOST zu blocken würde ich aber unterstützen.
Danach kann man ja noch mal sehen, was Sache ist und wie die Interessen wirklich verteilt sind.
Vor allem wenn das nicht genutzt wurde, sollte Bitmain damit ja auch nicht so ein großes Problem haben.

Bis das Thema durch ist halte ich auch nichts davon einen UASF für Segwit durchzudrücken.
Wir haben genug andere Möglichkeiten Bitcoin zu skalieren - Siehe Rootstock, Purse Extension Blocks etc., da brauchen wir nicht so viel zu riskieren - Bitcoin funktioniert immer noch gut.

Benutze Bitcoin Core jetzt mit uacomment=EXTBLK  

Zum Thema EC - mich würde das auch interessieren, wie es in freier Wildbahn funktionieren würde.
Als Altcoin ist es aber uninteressant, weil der Blockspace von Bitcoin ja so interessant ist für Leute die Daten speichern wollen, weil es mit Abstand der sicherste ist.
Das würde automatisch verschwinden, wenn man das als Altcoin ausprobieren könnte und man könnte somit keine Aussage mehr treffen, inwiefern wir tatsächlich Monsterblöcke bekommen würden, die zu einen übermäßigen Zentralisierungs-Effekt auslösen würden.

Das gleiche gilt, falls BU auf einer eigenen Chain wäre nach einem Hardfork,

BU braucht aufgrund seiner Philosophie einfach einen breiten Konsens und zwar bei Minern, als auch bei der überwiegenden ökonomischen Mehrheit, das wird aber extrem schwer das jemals zu erlangen. Selbst wenn Core aktiv versuchen würde Bitcoin anzugreifen hätte ggf. der Status quo immer noch Vorteile gegenüber BU.

d5000, da ist deine Kompetenz was zu sehen besser, als was ich mir so zusammenreime.