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

F2Pool scheint konsequent weiter Segwit-Blocks zu produzieren. Leider reicht es wegen seiner doch etwas geschrumpften Hashrate nur für Gleichstand mit BU (beide im 40-45-Prozent-Bereich).

Vielleicht hat Wang Chun auch nur sozusagen die Notbremse gezogen, um den Fall seines Pools in die Bedeutungslosigkeit zu stoppen (ich meine, vor kurzem hatte er noch deutlich mehr als 10%). Laut einem neueren Artikel soll F2Pool einer der "klassischen Pools" sein, die keine oder kaum eigene Hashrate betreiben sondern unabhängige Miner bündeln. Da tut er sich mit seinem Zickzackkurs sicher keinen Gefallen.

eine schöne zusammenfassung und übersicht wie es sich entwickeln könnte:

https://bitcoinmagazine.com/articles/breaking-down-bitcoins-asicboost-scandal-solutions/

Stimmt natürlich. Der ändert seine Meinung minütlich. Allerdings haben die schon die ersten segwit Blocks gemint. Also zumindest bis jetzt hält er sein Wort.

Mein erster Gedanke war.
Bevor sich Basisorganisationen bilden und mit solchen Ideen wie UASF anfangen Macht zurück zu gewinnen.
EINLENKEN

Der will viel. Statt "soziale" Messages abzusetzen, hätte er ganz einfach das Flag setzen können. Erst mal abwarten was er dann am Ende tatsächlich macht.

F2pool will segwit unterstützen
https://twitter.com/f2pool_wangchun/status/853047376608600065

BIP148 / UASF ist schon eine recht massive Reaktion. Das BU Monopol hat zwar einen Dämpfer verdient, aber man könnte auch erst mal deren Blöcke massiv benachteiligen, indem man immer erst mal abwartet ob nicht ein Block mit segwit Signalisierung kommt. Damit stellt ein neuer Block mit segwit Signalisierung immer die längste Chain dar, auch wenn er sehr viel später gefunden wird. Ein Block ohne diese Signalisierung wird nur aktzeptiert, wenn ein neuerer Block darauf aufbaut. Notfalls kann man diese Kette auch auf mehr als einen Block erhöhen. Die segwit Miner werden diesen kleinen Vorteil sicher dankend annehmen. Wenn der BU Präsident dann wegen des Orphan Risikos beleidigt ist und wegforkt ist das Ziel trotzdem erreicht.

So viel Vernunft, wie fürchterlich.  Roll Eyes

Aber ja, sehe das auch so. Abwarten und Teetrinken.
Und wenn sich zwischenzeitlich was anderes ergibt, kann man immer noch reagieren.

Und am Rande sei noch erwähnt, halte den Flagday für den BIP 148 UASF auch für unglücklich/ungeschickt früh.

Edit:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html

Ist BIP 148 jetzt doch tot, wo er doch gerade angefangen hat etwas mehr Unterstützung zu sammeln?

Naja zumindest wird er nicht in den Core Client kommen denke ich.

Hat jemand Links zu den anderen UASF Vorschlägen?

Das würde ich auch als den besten Weg ansehen. Dann weiß man, ob Asicboost ein Problem ist/war oder nicht.

Schöne Diskussion übrigens, danke für die Einsichten! "It's complicated ".

ähh, wo muss ich jetzt genau unterschreiben?  

ich sach ma so:

man sollte den BIP von Maxwell auf den weg bringen welcher ASICBOOST eliminiert und abwarten wie SegWit bei LiteCoin funktioniert.

das wäre für mich ein recht konservativer weg den man gehen kann mit minimalem risiko. und dann zündet man gegen ende des jahres.

Haha - Ja

Gleiches gilt ja auch für die Blockgröße.
Das Problem der Blockgröße würde sich von ganz alleine lösen, wenn man nur lang genug wartet und es keine sonstigen Entwicklungen im Bereich Bitcoin geben würde.
(... aber auch ohne Segwit und BU / EC gibt es weitere Entwicklungen, die mehr Transaktionen pro Sekunde zulassen)

Die Leute, die die Schnauze voll haben benutzen Bitcoin einfach nicht mehr, senkt eben den Preis, weil die keine HODLer mehr sind.
Entsprechend sinkt deren sichtbarer Einfluss.

Tatsächlich ist es noch komplizierter, da die Nutzer oft auch den Dienstleister wechseln können, falls dieser die gewünschte Leistung (Chain) nicht mehr bereitstellt.

Etwas ähnliches hatte ich ja geschrieben.

Wichtig ist, wir kennen nicht mal die wirkliche Anzahl, da die Seiten nur von außen erreichbare Full-Nodes anzeigen und es gibt zwar von Luke-Jr Daten über nicht von außen erreichbare Knoten, aber er weigert sich zu sagen, wie er seine Daten ermittelt. Die Daten sind also absolut ungeeignet sind um irgendwelche Bewertungen durchzuführen.

Natürlich ergeben die Daten von Bitnodes21.co / coin.dance einen Anhaltspunkt, aber um eine Aussage zu treffen, aber die Werthaltigkeit dieser Aussage kann von jedem zurecht in frage gestellt werden.
Wir können ja noch nicht mal sagen mit welcher Wahrscheinlichkeit die daraus gezogene Aussage richtig ist, ohne weitere Annahmen zu machen.
Das taugt höchstens, um einen Verdacht, der sich aufgrund anderer Daten ergibt zu erhärten.

Für sich persönlich bleibt das aber noch nutzbar - es ist ja sowieso jeder frei seinen eigenen Maßstab anzusetzen.

Aber ich sehe sowieso eher die ökonomische Macht die hinter einem Knoten steht als wichtiger.
Hinter einem Knoten steht zwar ein Betreiber, aber es können indirekt viele Personen diesen Knoten nutzen.
Einfachstes Beispiel ist bei einer Exchange, oder bei einem SPV-Wallet Server.

Knoten sind also leider unterschiedlich wichtig.

Die Anzahl der unabhängigen Knotenbetreiber zusammen mit deren Nutzern ist sehr wichtig. Auch wenn man diese nicht einfach zählen kann, geben die verfügbaren Daten einen Anhaltspunkt über die Verteilung. Im Falle eines Forks entscheiden diese dann über den Wert der entsprechenden Chain.

Ein BIP148 Opt-In wäre möglich, ich würde es aber als Core-Entwickler trotzdem nicht anbieten. Dafür kann ein eigenes Projekt oder ein eigener Bereich genutzt werden, worüber vorübergehend gepatchte Clients zur Verfügung gestellt werden.

Leider ist die reine Anzahl der Knoten nicht aussagefähig, da man für wenige BTC / € hunderte oder sogar tausende Fake Knoten, und für etwas mehr Geld sogar richtige Nodes erstellen kann.

Von außen ist also nicht ersichtlich, ob es sich um eine Person/Organisation mit allen Knoten handelt, die versucht eine übermäßige Unterstützung nach außen vorzugaukeln.
Auch wissen wir nicht, ob tatsächlich hinter jedem Knoten eine echte Person steckt, die Ihre Meinung äußert.

Praktisch gesehen wird es sich wohl um eine Mischung handeln.
http://www.uasf.co/
http://uasf.saltylemon.org/

Ich geb dir ja recht Mezzo.
Aber wie kann man praktisch einem einfachen User auch die Möglichkeit geben seine Meinung zu äußern, so dass diese noch verstehen, was Sie machen, ohne Bitcoin neuer Gefahren auszusetzen.

Wenn ich zurückdenke kommt mir die Aktivierung von P2SH in den Sinn, also Bitcoin Zahlungen an 3er Adressen. Das wurde damals einfach als UASF durchgedrückt, ohne dass es Wahlmöglichkeiten gab bei der Binary für den User, obwohl es seinerzeit auch umstritten war.

Die Situation ist mittlerweile natürlich anders - es haben sich Alternativen zu Bitcoin Core entwickelt.

Es gibt momentan ein recht hohes Momentum für UASF, obwohl es keinen einfachen Weg gibt selbst einen UASF Knoten aufzusetzen.

Wahrscheinlich wäre es sinnvoll in einem ersten Schritt das als echten Opt-In seitens Core anzubieten.
Der Nutzer hätte dann eine einfache und sichere Möglichkeit um UASF BIP 148 tatsächlich zu unterstützen.

Das ganze mal eben selbst kompilieren ist nicht so einfach - während man das für Linux noch ordentlich hinbekommt, wird es für Windows schon deutlich aufwändiger.

Das aktuell als Opt-Out Feature anzubieten ist sicherlich noch zu früh, dazu ist die UASF Unterstützung definitiv noch zu gering und würde von vielen deswegen als politisch motiviert angesehen werden und das ist sicher ein Risiko, was viele Entwickler bei Core nicht eingehen möchten.

Dass ihr über bip148 gesprochen hattet, habe ich alles mitgelesen.
Danke noch mal für den Link. ich versuche nochmal etwas mehr zu verstehen.
Du zwingst mich richtig technisch einzutauchen, wenn ich es verstehen will.
Also die Nodes die UASF wollen müssen es zu core dazu installieren. Denke ich.
Das Zeitfenster finde ich aber sehr eng.
Danke erstmal.
Und euer voriges Gespräch muss ich auch noch mal durchlesen.

Für UASF hat sich bereits ein Projekt gefunden: https://bip148.org

Die Core Entwickler wären gut beraten, sich weiterhin neutral zu verhalten und nicht die Kritik einer Beeinflussung durch entsprechenden Code zu untermauern.

Und wie wäre es mit dem Vorschlag, es gibt
1. Core 0.14.1 ohne uasf und Segwit
2. Core 0.14.2 mit uasf und Segwit Aktivierung ab einer bestimmten Quote?

Bitte nicht die Geduld verlieren mit den nicht-technikern
man kann nur dazulernen.


edit. Beispiel 75% Core 0.14.2 hier https://coin.dance/nodes/share

Gerade vorkompiliert und vor allem voreingestellt sollte es Dinge wie den U(ser!!!)ASF nicht geben. Dies würde nämlich bedeuten, dass der Entwickler des entsprechenden Client nicht mehr neutral ist. Daher würde ich allenfalls eine universelle Lösung über die Flags befürworten. Wenn die User dann nicht mal in der Lage sind, eine Konfiguration zu setzen oder dafür zu faul sind, dann ist das für mich die Abstimmung - das Feature ist nicht wichtig genug und damit bleibt es beim aktuellen Zustand.