Kommt jetzt das Flippening zu XRP? /s

Wer schon ein bisschen länger dabei ist kann sich vielleicht noch daran erinnern, dass die Market-Cap von XRP schon mal über der von BTC lag  

Die Aktion von ViaBTC war echt seltsam.
Erst fragen und dann der Tweet "hash power is law" um die Leute auf die Palme zu bringen.

Wäre mal interessant zu wissen, wie viele Leute da auf Nein bei Segwit gedrückt haben, nur weil sie wollen, dass Bitcoin schlecht da steht, weil die andere Interessen haben (z.B. Altcoins) und wie viel da echte Opposition ist.

Das das Ergebnis nicht repräsentativ ist, ist klar, aber es mal wieder ein starkes Indiz dafür, wie viele Segwit wirklich haben wollen.
Eben ähnlich wie der Node-Count.

Ist das nicht auch beim aktuellen Status mit OP_RETURN so?
Sind wir es nicht aktuell einfach nur gewohnt es so zu machen um Daten zu speichern?
OP_RETURN sorgt ja dafür, dass der Script fehlschlägt, nicht, dass irgendwas gespeichert wird, das muss man ja extra in den skript einbauen.

Kenne mich mit NXT nicht aus, ob die da extra Funktionen haben, aber Bitcoin hat keinen "Speichere Daten in der Blockchain" OP soweit ich weiß, das heißt man muss das eben mit der bestehenden Skriptsprache irgendwie machen. Alles andere ist höchstens Konvention.

Das einzig besondere ist, dass die Regeln für Standard-Transaktionen genau einen Output erlauben, der OP_RETURN enthält und danach genau eine Push Operation mit maximal 40 Byte haben darf. (Stimmt das?)
Deswegen ist das wohl die offensichtlichste und einfachste Möglichkeit das Skriptsystem so zu benutzen um externe Daten in der Blockchain zu speichern.

Beispiel bei der genannten Adresse:
https://blockchain.info/tx/b9e7bfe11bae8d686340a79c0b8e98dcce6e40326cf46de739d2f5fd3f62b591
https://blockchain.info/tx/b9e7bfe11bae8d686340a79c0b8e98dcce6e40326cf46de739d2f5fd3f62b591?format=hex

OP_RETURN PUSH_28 cc5e5fd92d93471b0325811df107cbfe999b29f0d3c5929252cdb28bed53d1e3fffffffffffffff f

Das gleiche könnte man einfach in den redemscript der nächsten TX packen und dort mit OP_IF (statt OP_RETURN) vor Ausführung schützen.

Ob das jetzt im 2. Output interpretiert wird, oder im mit OP_IF geschützten Teil des redeemscripts macht ja keinen großen Unterschied. Dafür gewinnt man eben viele Freiheitsgrade, was man machen kann und kann so Platz in der Blockchain zu sparen.

Bei den aktuellen TX haben wir 40 Bytes "Nutzdaten" pro 390 Bytes Transaktionsgröße.

Ja das wäre wohl auch ein passender Anwendungszweck für RBF.

Ist aber auch nicht so einfach mal eben die technische Infrastruktur aufzubauen für non-std-tx und dann auch noch eine Vereinbarung mit einem Pool zu haben, dass die diese Tx dann verarbeiten.

Kostet eben auch Geld und Zeit.

Könnte man das ganze nicht eigentlich auch mit P2SH Pseudo Smart Contract machen?
Dann wird das eben nicht im Output, sondern im Input der TX gespeichert.
Das heißt man hätte jedes Mal eine andere Adresse, aber das wäre ja wahrscheinlich egal.

Und RBF würde immer noch funktionieren.

Ist dann ja trotzdem eine Standard-TX und würde an alle Nodes/Miner weitergeleitet.

Das kommt aktuell so oft vor.
Irgendwelche Anschuldigungen ohne irgendwelche Nachweise und ohne richtig nachzudenken.

Wenn Blockstream so darauf angewiesen wäre und wenn Blockstream so eine Macht über Core hätte, dann hätten die ja wohl versucht Core zu zwingen Segwit irgendwie zu aktivieren. Ggf. über einen 2 MB Hardfork Kompromiss.

Ist aber nicht passiert.

Und außerdem ist das gegen die Regeln der Veranstaltung zu veröffentlichen wer was gesagt hat.

Über die wahre Intention der Person kann man nur mutmaßen.
Könnte ein echter Unterstützer von Big Blocks sein, könnte aber auch sein, dass er Bitcoin einfach nur schaden will, indem er beide Seiten gegeneinander aufhetzt.

Sowas ist einfach unbrauchbar.

Und selbst wenn Blockstream Segwit braucht - was ist daraus die Folge?

Ja das wäre schön, aber offensichtlich geht das ja nicht - Segwit ist einsatzbereit, BU muss erstmal seine aktuellen Probleme lösen, bevor man überhaupt wieder darüber nachdenken kann, dass für die breite Masse zu nutzen.
Und in einem Jahr mit BIP 149 ist mir immer noch lieber, als garnicht.

Und solange eben Rootstock.
Vielleicht wird ja auch TumbleBit (als payment hub) ein bisschen beliebter.
Kenne da nur NTumbleBit als Implementierung, die haben allerdings den Payment Hub noch nicht fertig.

Viel Glück mit deinen ETH - vielleicht ist Bitcoin einfach nichts für dich, wenn dir andere Eigenschaften wesentlich wichtiger sind. ETH hat in manchen Bereichen deutliche Nachteile gegenüber Bitcoin. Der aktuelle Preis ist für mich nicht so wichtig, viel mehr die Freiheit, die ich durch Bitcoin genieße.

Wenn wir mit Sicherheit wissen würden, dass der Preis steigt, dann wäre der Preis bereits gestiegen.
Wir wissen also überhaupt nicht, ob ETH eine bessere Performance haben wird als BTC.

Ich schätze Momentan eben auch das Risiko bei ETH deutlich höher als bei BTC.
Wird spannend, wenn Leute die das erste mal in Crypto investiert haben und dann in ETH gegangen sind den ersten Crash mitbekommen.

Ich weiß nicht, was du für Wallets verwendest - Ich komme in der Regel mit 50 cent/Tx locker hin um in 1-2 Blöcken bestätigt zu werden, am Wochenende auch mit viel weniger.

Bist du sicher, dass du noch im richtigen Board postest?
Ich meine das ist ja schön, dass wir uns hier nicht alle nur bauchpinseln, aber du redest ja nur noch von ETH und wie scheiße Blockstream ist. Komisch, dass dich das bei Litecoin nicht stört.

Mal eine Frage an die "Blockstream ist böse und kontrolliert Core" Verschwörungstheoretiker.
Man sollte meinen Blockstream würde Core zwingen einen 2 MB Hardfork zu implementieren, damit Segwit aktiviert wird, wenn man den ganzen Verschwörungstheorien glauben darf.
1MB zu 2MB würde nämlich keinen großen Unterschied machen, wenn Blockstream dafür Bitcoin beherrscht.

@mezzo
Huh - dann konnte man das sogar verstehen, was ich da geschrieben habe?
Hatte irgendwie das Gefühl, dass in meinem letzten Post die Struktur etwas durcheinander war und es schwer wäre mein Gedankengang nachzuvollziehen.
Kann wohl auch etwas daran liegen, das nachdem ich so viel gelesen habe über das Thema, mir einfach wünsche, dass Segwit aktiviert wird und beim Schreiben etwas genervt war.

Letztes Jahr war meine Meinung zu Segwit eher umgekehrt, nachdem ich zu viel /r/bitcoin gelesen hatte.
Finde mittlerweile, dass die Vorteile extrem überwiegen und es nichts an den technischen Voraussetzungen ändert später einen Hardfork durchzuführen.
Mittlerweile gibt es auch einfach viel Software die Segwit unterstützt, deswegen zählt das auch nicht mehr als Argument.

Was haltet ihr von BIP 149 -> Segwit über das relativ neue BIP 8 (MASF und Fallback zu UASF mit Flagday) zu aktivieren.
https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
BIP8 starttime 6 November 2017 UTC
BIP8 timeout will be 4 July 2018 UTC

Würde dann zwar etwas über ein Jahr dauern, bis wir es sicher haben, aber es besteht zumindest kein Risiko, dass die Blockchain sich aufspaltet, wie bei dem erzwungenen UASF über BIP 148.

Und vorzeitig können die Miner das ja sowieso aktivieren.
Und natürlich können die Miner sich dann auch entscheiden die Blockchain absichtlich zu splitten, was ja jetzt bereits jederzeit möglich ist, wenn man nicht die gleichen Consensus-Rules benutzt.

Soll das jetzt ein Argument gegen Segwit und gegen BU / größere Blöcke sein?
Warum gegen größere Blöcke? Das gleiche könnte man auch als Argument gegen Regulierung bei Mining-Pools anwenden.

Segwit, weil es Malleability hinreichend löst und somit LN ermöglicht und möglicherweise einige Paymenthubs enstehen?

Zu LN wissen wir aktuell nur, wie es technisch funktioniert (gibt glaube ich noch keinen Routing Algo für großes Netz), aber wie es in der Realität überhaupt genutzt werden wird wissen wir ja überhaupt nicht. Funktioniert ökonomisch einfach anders, als was wir aktuell von BTC gewohnt sind.

Ich halte es für einen Fehler LN zu blockieren, weil es theoretisch zu Paymenthubs führen kann, aber halte es ebenso für einen Fehler das bereits als die Lösung für die Blockgröße zu bezeichnen. Bis die Kapazität von Segwit erschöpft ist, sollten wir zumindest funktionierende Software für LN haben - und dann kann man neu bewerten.

Wenn es wirklich zu Paymenthubs kommt und diese dann Regulierung unterworfen sind, wäre das für mich ein Grund stärker für mehr OnChain Transaktionen zu arbeiten, aber vorher sollten wir es mal versuchen.

Und andererseits - ich meine die Pools genauso wie eventuelle Paymenthubs siedeln sich eben dort an, wo sie nicht so starker Regulierung unterworfen sind.

Hab mich gefreut, dass es heute mal wieder schön viel zu lesen gab
Auch wenn ich nicht mit dir einer Meinung bin, so schätze ich es jedoch wie du schreibst. Und wenn alle eine Meinung haben, dann ist es sowieso langweilig und das Forum hier hat für mich weniger Wert.

Ich sehe momentan einfach nicht, dass wir die Voraussetzungen für einen erfolgreichen HF haben.

Bei einem MASF, wie man ihn bei Extension Blocks machen könnte braucht man nur die Unterstützung der meisten Miner. Bei einem UASF braucht man die überwiegende ökonomische Unterstützung. Die ist zwar schwer Messbar, aber funktionieren kann das trotzdem.

Bei einem HF wird es aber richtig schwierig, weil man beides braucht und zwar beides in einem erheblich höherem Maße, als man es für einen MASF oder UASF jeweils brauchen würde.

Außerdem haben die Entwickler der beliebten Clients erheblichen Einfluss auf die Meinungsbildung bei einem UASF und einem HF. Das ist einfach eine aus meiner Sicht auf lange Zeit unüberwindbare Hürde für BU & Co.

Und Core Developer hin oder her - die haben wenig Einfluss, wenn Extension Blocks als MASF ausgerollt werden. Wenn die Leute das nutzen wollen, dann können Sie das tun, wenn nicht, dann eben nicht.
Wie wir an dem Erfolg von Altcoins sehen können funktionieren ökonomische Anreize nämlich nicht nur bei Minern, sondern auch bei Nutzern.
Es ist also gar nicht notwendig seine Energie im Kampf gegeneinander zu verschwenden, wenn man einfach einen leichteren Weg nehmen kann und trotzdem das Ziel erreichen kann mehr Transaktionen Onchain zu ermöglichen (BU vs. Extension-Blocks). Segwit ändert an dem Umstand ja auch nichts. BU entscheidet selbst, ob sie mit Core das Spiel weiter spielen wollen.

Und das ganze Thema Voraussetzungen ist auch warum ich für Rootstock trotz der Federation einen Platz sehe, so sind die Voraussetzungen für einen Start noch geringer. Mittelfristig soll das ja sowieso als Drivechain funktionieren, aber das in Angriff zu nehmen ist erst nach einer möglichen Segwit Aktivierung geplant, soweit ich weiß.

Meiner Meinung nach bringen die Devs von Rootstock einfach Pragmatismus mit, der bei BU & Co. und Core momentan wenig sichtbar ist.

Ja war mir bekannt - Finde den Trend aber beruhigend - letzte Version von Core ist 0.10.1, wenn ich das richtig lese.

Soweit ich weiß kann man mit sehr geringem Aufwand Covert Asicboost ineffizient und damit uninteressant machen.
Und das niemand overt Asicboost benutzt können wir ja sehen.

Bin ich jetzt Blockstream-Shill (Danke Commander) oder BU-Fanboy? Ach man ohne eigene Meinung könnte das Leben so einfach sein.

Ich sehe es auch so, dass Bitcoin onchain skalieren sollte.
Allerdings muss man sich da etwas schlauer anstellen als BU & Co.

Mal am Beispiel von BU:
Inkompatibler Hardfork ohne Wipeout protection - braucht also eine massive Mehrheit der Hashrate und wegen ökonomischem Widerstand sogar soviel, dass man die Minority Chain killen kann/muss.

Die hatten genug Zeit um ihre Ideen mal weiter zu entwickeln, aber es kommt immer nur das gleiche.

Immer wieder extrem schwerwiegende Bugs und auch weiterhin Sicherheitsprobleme mit Kollisionen in Xthin, aber trotzdem bleibt das Feature standardmäßig aktiviert.

Das ist doch dann kein Wunder das kein Vertrauen in das BU-Team besteht.

Und man sollte sich mal mit der Realität auseinandersetzen, dass es einfach viele Menschen gibt, die es für wichtig halten, das man Bitcoin nebenbei auf einem alten Computer laufen lassen kann (Stichwort Zentralisierung).

Satoshis Vision hin oder her - Die Regeln von Bitcoin werden eben von den aktuellen Benutzern gemacht und wenn das nicht mehr mit der Vergangenheit übereinstimmt sind einige frühere Anwender (Ver & Co.) vielleicht enttäuscht, aber ändern können die das auch nicht.

Es ist ja nicht so, dass es Lösungen geben würde mit Extension Blocks, so dass auch die Smallblocker weiterhin ihre kleinen Blöcke haben können, aber nein, dass wäre ja zu kompliziert, also lieber an was arbeiten, was nicht funktioniert.

Extension Blocks könnte man mit einer Mehrheit der Miner Unterstützung als Softfork sicher aktivieren, ohne einen Chain-Split herbeizuführen. Und gleichzeitig besteht eine Wipeout-Protection, falls sich die Mehrheit der Hashrate dann doch entscheidet das nicht mehr zu unterstützen.

Und die Vorbereitungszeit wäre jetzt auch nicht länger, als bei einem BU-Hardfork, wenn man bedenkt, dass BU jetzt nach dem ganzen Schlamassel erstmal einige Monate brauchen wird um etwas Vertrauen zurück zu gewinnen.

Und diese Anyone-Can-Spend Kritik an Segwit - lol - demnach wären alle Bitcoins Anyone-Can-Spend, weil OP_1 OP_RETURN früher ein gültiger Unlock Script für alle Bitcoins war. Soll mal einer probieren das heute als unlock script zu verwenden und dann mal schauen, wer Lust hat der Chain zu folgen. Wenn der Softfork aktiv ist, dann ist es eben kein Anyone-Can-Spend mehr. Und fast alle Nodes (90+%) im Netzwerk würden Segwit validieren.

BU stellt sich einfach unglaublich ungeschickt an.

Asicboost wenn es keiner nutzt lieber deaktivieren, denn es behindert die Protokoll Entwicklung. Und falls es mal einer benutzt, halte ich die Auswirkung für erheblich. Das keine Initiative von Bitmain kommt finde ich zumindest verdächtig.

Antbleed - Hab den Code nur kurz überflogen - sehe keine direkte Remote Code Execution Möglichkeit, auch wenn der String nicht ordentlich auf Nullterminierung geprüft wird, strstr arbeitet allerdings nur lesend. Das die Verbindung nicht authentifiziert ist, ist natürlich äußerst schlampig, kann da aber keine gezielte Bösartigkeit erkennen. Vor allem, wenn Bitmain es missbrauchen würde, könnte jeder innerhalb von wenigen Minuten den Miner mit dem Workaround wieder aktivieren und die Lücke dauerhaft selbst schließen.

Das viel zitierte Hongkong Abkommen ist ein seltsames Stück. Die anwesenden Leute hatten ja niemals die Möglichkeit einen Hardfork zu versprechen, weil Sie nicht für alle Core Entwickler sprechen. Das Abkommen ist also nie etwas wert gewesen.
Einige Miner sind jetzt eben immer noch beleidigt und Luke-Jr & Co sorgen nicht gerade dafür, dass sich die Wogen glätten.
Ja auch Core stellt sich eben ungeschickt an, wenn es das Ziel ist Segwit mit BIP-9 zu aktivieren.

Aber immerhin funktioniert die Software von Core und wir haben mit Segwit etwas fertiges, was wir so oder so später brauchen werden (Malleability Fix), was nebenbei noch mehr Platz für Transaktionen schafft.

P.S.
Go Bcoin, Go RSK  

Keiner da. Bedienung weiß von nichts. Hab beim rumgehen auch niemand auffälliges gesehen...

Schade

Vielen Dank für diesen hochqualitativen Beitrag und für die ausführlichen Begründungen, die du geliefert hast.
Warum bin ich da nicht schon früher drauf bekommen  

Kann man sehr gut bei Litecoin sehen, welchen negativen Einfluss Segwit hat.

Welchen Vorteil hat Blockstream da? Solange man keine inkompetenten Programmierer hat sind auch nach einer Segwit Aktivierung die Voraussetzungen für alle gleich.

Im Vergleich dazu, wie kompliziert in Bitcoin eine Transaktion signiert und serialisiert wird, ist Segwit geradezu lächerlich einfach.

Weiß noch nicht genau, ob ich es morgen schaffe.
Würde mich freuen, wenn sich wer bei mir meldet (PM?).
Das erhöht auf jeden fall meine Motivation  


So ab 19:00 könnte ich vielleicht Donnerstags.

Für mich ist Bitcoin ein System, was ohne Vertrauen in das System seinen Wert verliert.

Mit dem was bei BU momentan passiert zeigt, dass die noch einen langen Weg vor sich haben, bis die ihre Software und den Entwicklungsprozess in den Griff bekommen.

Da kann BU selbst 75% aller Blöcke haben, das hat keine große Bedeutung. Wenn die dann den Hardfork aktivieren würden, würde sich nur zeigen, dass Sie weniger Macht haben, als Sie gedacht haben. Nur Altcoins würden davon profitieren.

Erweckt für mich auch nicht gerade Vertrauen, wenn Peter Tschipper es wichtiger findet lieber Gmax persönlich anzugreifen, als sich mit den von ihm gefundenen Sicherheitslücken vernünftig auseinander zu setzen, soviel zur Alternative XT.
https://github.com/BitcoinUnlimited/BitcoinUnlimited/issues/485

Ich hatte selbst BU am laufen und mein subjektiver Eindruck war, dass Xthin deutlich Bandbreite gespart hat, bringt aber nichts. Wenn es da bekannte Schwachstellen gibt, gehört das deaktiviert bis das komplett gefixt ist. Vor allem wenn man den Anspruch hat der wichtigste Client in einem Netzwerk zu sein.

Mal schauen. Falls BU oder jemand anders, der größere Blöcke unterstützt es schafft über einen längeren Zeitraum (1 Jahr?) nicht so viel Mist zu machen, dann wären zumindest für größere Blöcke auch mal wieder eine Option.

Roger Ver sagt immer, dass die Blockgröße das wichtigste Problem ist.
Dem möchte ich widersprechen - aktuell ist das wichtigste Problem Bitcoin vor schlechter Software zu bewahren.

Achja - und für die Blockgröße gibt es ja auch eine Übergangslösung - Segwit, die fertig entwickelt und getestet ist und man innerhalb von 4 Wochen nutzen könnte, wenn man denn nur will.

Verstehe in der aktuellen Situation nicht mehr die Argumente gegen Segwit.
Reine Politik und verletzte Egos.
Als ob Blockstream / Core danach mehr Einfluss auf irgendetwas hätte.

Ja so ungefähr.
Manche Pools haben aber auch komplett eigene Software geschrieben, die nicht auf Bitcoin-Core aufbaut (z. B. ViaBTC), was man an deren letzten Tweets zum Thema Segwit bei LTC gut sehen konnte.

Alternativ kann man natürlich auch Bcoin oder andere fertige Implementierungen nehmen.

An sich ist das aber schon ein schönes Update um es den Minern leichter zu machen. Somit gibt es noch einen Grund weniger, warum diese Segwit nicht signalisieren sollten.

Ob das aber jemals ein Pool / Miner nutzen wird, ist schwerer zu beurteilen.

Danke für die Info - versuche auf jeden Fall vorbei zu kommen.
Wie erkenne ich euch? 

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?

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.

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.

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/

Das ist allerdings auch der Grund, warum eine Aktivierung über die Anzahl der Knoten nicht nutzen kann, da es sich zu leicht manipulieren lässt.

Die Anzahl der Knoten die UASF unterstützen sind natürlich trotzdem wichtig, allerdings ist es eben die ökonomische Macht der Teilnehmer die wesentlich ist. Leider ist diese aber nach Außen nicht direkt ersichtlich, weswegen man ja über andere Kanäle das kommunizieren muss. Ein Teil davon sind die Unternehmen, die sich offiziell zu dem BIP 148 Segwit UASF bekennen.
https://coin.dance/poli

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.

So - steht der 30.?
Gibts Neuigkeiten, wegen dem Veranstaltungsort?
Sind laut der Homepage wohl neue Gastronomen.
Ist aber bei den aktuellen Gebühren für mich nicht so wichtig, ob bitcoin angenommen wird 

Hätte definitv Lust zu kommen und passt zeitlich auch zusammen mit dem Russland F1 GP, der Endet etwa gegen 16:00