true-cost-bitcoin-transactions

[mezzomix]

Warum wurden dann nicht Detached Signatures, Flexible Transactions, UTXO Commitments und die ganzen anderen tollen Features implementiert, wenn es nicht um das Blockieren geht?!

Im übrigen könnte man die Abstimmung über die Blockgrösse ebenfalls Off-Chain durchführen. Forken kann man sowieso immer, wenn man bereit ist, die Konsequenzen zu tragen. Dafür hätte es also kein BU gebraucht. So sehe ich die technische Notwendig von BU nicht. Machtansprüche, Politik und Blockade sind allerdings deutlich sichtbar.

[1713282690]

1713282690

[d5000]

Die aktuelle Situation liegt aber an den Minern/Entwicklern nicht an den Nutzern.

Mich als Nutzer fragt ja keiner, [...]
Aber ohne die Miner geht es jawohl nicht und die sitzen halt am längeren Hebel -> Gridlock und es sollte in unser aller Interesse sein zu einem Konsenz zu kommen.

Ich habe mal hier die Frage gestellt, ob Nutzer mit Full Node Druck auf die Miner ausüben können, um bestimmte Ziele (z.B. Segwit) zu erreichen, indem sie die Blocks bestimmter Pools blockieren. Mezzomix, du hast das ja mal angesprochen. Mal sehen ob/was mir geantwortet wird.

[mezzomix]

Ich hatte dazu schon mal was in anderen Threads geschrieben. Sollte die Überwiegende Zahl der Knotenbetreiber für segwit stimmen, ein paar der Miner dies aber trotzdem blockieren, dann könnten die Knoten neue Blöcke ohne segwit Signalisierung nicht mehr weiterleiten und diese - sobald verfügbar - durch Blöcke der gleichen Höhe mit segwit Signalisierung ersetzen.

Damit würden diese Knoten den Minern die segwit signalisieren einen ökonomischen Vorteil verschaffen, da sich die Blöcke ohne segwit langsamer im Netz verbreiten und statistisch gesehen teilweise durch segwit Blöcke verdrängt werden, bevor diese durch den folgenden Block letztendlich bestätigt werden.

Je mehr Knoten hier mitmachen, desto kleiner wird die Chance eines solchen Miners, seine Blöcke gegen den Rest der Knoten durchzubekommen. Eigene Knoten helfen nicht dagegen, da der Miner die Blöcke dann trotzdem nur in seinem eigenen Netz verbreiten kann. Ignoriert er das Votum der Knoten und besteht auf seinen eigenen Block, dann forkt er sich mit dem nächsten darauf aufbauenden Block automatisch aus dem Netzwerk.

[d5000]

Genau das meinte ich. Finde ich auch eine legitime Möglichkeit, Einfluss auf (Softfork-)Entscheidungen zu nehmen, da somit den Minern etwas Macht genommen wird.

Die Frage ist: Wie geht das genau? Muss der Code des Bitcoin-Clients dafür geändert werden oder geht das z.B. über eine Blacklist mit dem aktuellen Client?

Hab mir natürlich gleich Franky1 aufgehalst, aber immerhin hat er was brauchbares beigetragen, indem wohl die Versionsnummer des Clients Ausgangspunkt für eine solche "Weiterleitungsblockade" sein kann. Nur: Bitcoin 0.13.x kann man ja so konfigurieren, dass "Not Ready" für Segwit (oder einen beliebigen anderen Softfork) signalisiert wird. Sieht man dieses "Not Ready" direkt, wenn ein neuer Block an meinen Client weitergeleitet wird, oder muss ich separat das "Not Ready" eines Mining Pools erschnüffeln und auf dieser Basis dann die IP-Adresse blockieren? Hab das nicht ganz verstanden. Vielleicht gibts ja in der Protokolldokumentation was interessantes dazu ...

[doc12]

Genau das meinte ich. Finde ich auch eine legitime Möglichkeit, Einfluss auf (Softfork-)Entscheidungen zu nehmen, da somit den Minern etwas Macht genommen wird.

Die Frage ist: Wie geht das genau? Muss der Code des Bitcoin-Clients dafür geändert werden oder geht das z.B. über eine Blacklist mit dem aktuellen Client?

Hab mir natürlich gleich Franky1 aufgehalst, aber immerhin hat er was brauchbares beigetragen, indem wohl die Versionsnummer des Clients Ausgangspunkt für eine solche "Weiterleitungsblockade" sein kann. Nur: Bitcoin 0.13.x kann man ja so konfigurieren, dass "Not Ready" für Segwit (oder einen beliebigen anderen Softfork) signalisiert wird. Sieht man dieses "Not Ready" direkt, wenn ein neuer Block an meinen Client weitergeleitet wird, oder muss ich separat das "Not Ready" eines Mining Pools erschnüffeln und auf dieser Basis dann die IP-Adresse blockieren? Hab das nicht ganz verstanden. Vielleicht gibts ja in der Protokolldokumentation was interessantes dazu ...

Würde mich auch mal interssieren wie man das realisieren kann ... finde ich durchlaus legitim wenn die Nodes dadurch etwas Stimmgewicht bekommen.

[mezzomix]

Es benötigt dafür einen Patch für den Knoten.

Die Realisierung ist einfach. In jedem Block steckt nach BIP9 im entsprechenden Version-Bit die Signalisierung für den entsprechenden Soft-Fork. Für segwit ist dies das Bit 1. Jeder Block, der dieses Bit gesetzt hat, zählt as Stimme für die segwit Aktivierung. Wenn 95% der letzten 2016 Blöcke dieses Bit gesetzt haben, dann wird die neue Regel kurz darauf aktiv.

Jeder Knoten kann entscheiden, ob er einen Block ohne dieses Bit weiterleiten möchte oder nicht. Bekommt er nun einen Block der gleichen Höhe mit gesetztem Bit, verwirft er den Block ohne dieses Bit. Ein Block ohne dieses Bit wird nur dann aktzeptiert und weitergeleitet, wenn ein darauf aufbauender Block mit gesetztem Bit verfügbar ist.

Der Rest (IP Adressen, Version des Clients etc.) spielt bei diesem Mechanismus keine Rolle. Man blockiert damit auch nicht die Blöcke selbst, sondern gibt lediglich Blöcken den Vorzug, die den eigenen Vorstellungen entsprechen. Man kommuniziert diese Vorstellung auch nicht an andere Knoten. Das wäre sinnlos, da es über Komunikationsprotokoll Angriffmöglichkeiten durch Fake-Nodes gibt und daher eine saubere und ehrliche Abstimmung nicht möglich ist. Das ist übrigens auch der Wunde Punkt von BU - die Knoten können sich ohne Mining nicht an einer Abstimmung beteiligen, da das Ergebnis beliebig manipulierbar ist. BU geht von ehrlichen Knoten im Netz aus, die ihre Vorstellungen korrekt kommunizieren. Eine kuriose Annahme, wenn man die aktuelle Lage betrachtet.

[d5000]

Danke Mezzomix! Jetzt hab ich auch kapiert, was Franky mit der Versionsnummer meinte.

Bin ja echt mal gespannt ob jemand mal so einen Patch rausbringt. Sieht auf den ersten Blick so aus, als würde es einiges Bitcoin-spezifisches Programmierwissen benötigen. Ich hoffe ja, dass es nicht so weit kommt, aber alleine die Möglichkeit wäre eventuell genug, um ein ewiges Patt zu entschärfen.

Allerdings: Da ja bei Nicht-Minern jeder beliebig viele Nodes aufsetzen kann, könnte ich mir ein Sybil-Attack-Szenario vorstellen, bei dem beispielsweise Segwit-Fans und BU-Fans gegenseitig darum konkurrieren, wer das größere Client-Netzwerk aufbaut und die Blöcke der Gegenseite nicht mehr weiterleitet. Das wäre auch nicht optimal, allerdings meines Erachtens schon eine höhere Eskalationsstufe als heute.

[mezzomix]

Dieser Angriff hilft nur bei BU. Dort kaann über Fake-Nodes ein falsches Bild über die aktuell gewünschte / aktzeptierte Blockgrösse transportiert und so eine Fehlentscheidung der Miner produziert werden.

Bei meinem Patchvorschlag ist es egal, da das Netz nicht tatsächlich grösser wird, wenn ein Miner plötzlich 10k Nodes in Betrieb nimmt. Dann verbreiten sich seine Blöcke zwar unter diesen 10k Nodes, was aber keine praktische Relevanz hat, den es wird trotzdem keine der "echten" Nodes diese Blöcke aktzeptieren.

Sollten die BU Knoten die segwit Blöcke nicht mehr weiterleiten, dann forken sie sich in ein eigenes BU Netz. Das wurde der BU Gruppe bereits vorgeschlagen, wird aber von ihnen - aus naheliegenden Gründen - abgelehnt. Sie wollen, dass jeder ihr (fehlerhaftes da angreifbares, s.o.) System übernimmt.

[flipperfish]

Warum wurden dann nicht Detached Signatures, Flexible Transactions, UTXO Commitments und die ganzen anderen tollen Features implementiert, wenn es nicht um das Blockieren geht?!

Im übrigen könnte man die Abstimmung über die Blockgrösse ebenfalls Off-Chain durchführen. Forken kann man sowieso immer, wenn man bereit ist, die Konsequenzen zu tragen. Dafür hätte es also kein BU gebraucht. So sehe ich die technische Notwendig von BU nicht. Machtansprüche, Politik und Blockade sind allerdings deutlich sichtbar.

Bitcoin Classic hat Flexible Transactions seit v1.2.0 im Betastadium implementiert [1]. Auch Xthin war Teil dieses Releases. Um deine Frage zu beantworten: Aus dem gleichen Grund, aus dem die Qualität der Umsetzung nicht mit Blockstream mithalten kann: VC gesponsortes Unternehmen mit Vollzeitentwicklern vs. Freizeit-Entwickler, die nebenbei für ihr Geld arbeiten müssen.

Um die Abstimmung über die Blockgröße geht es bei BU auch nur indirekt. Es ist ein Feature, um den Fork auf eine größere Blockgröße zumindest ein wenig zu Koordinieren. Die eigentliche Abstimmung findet statt, indem es einfach ein Miner umsetzt und schaut was passiert. Als Nutzer folgt man innerhalb gewisser (konfigurierbarer) Grenzen einfach der längsten Chain, muss also keine Angst haben vom Netzwerk geforkt zu werden. Wenn jeder Bitcoin-Teilnehmer in der Lage wäre, den Client selbst entsprechend für größere Blöcke umzubauen, dann hätte es tatsächlich kein BU gebraucht. Aber da eben nicht jeder das Wissen dazu hat bzw. nicht die Zeit sich damit zu befassen, gibt es mit BU eine einfache Möglichkeit das Schicksal von Bitcoin ein wenig mehr selbst mitzubestimmen.

Dieser Angriff hilft nur bei BU. Dort kaann über Fake-Nodes ein falsches Bild über die aktuell gewünschte / aktzeptierte Blockgrösse transportiert und so eine Fehlentscheidung der Miner produziert werden.

Was soll der Angriff durch eine Sybil-Attacke dem Angreifer bringen? Ein Miner wird nur dann einen größeren Block fabrizieren, wenn genügend andere Miner Unterstützung dafür im Blockheader ankündigen. Außer die Fork-Koordination zu stören erreicht der Angreifer also nichts. BU geht davon aus, dass ein Angriff nutzlos ist und damit die Daten durch das Node Announcement wieder eine gewisse Aussagekraft bekommen. Es ist ein Anhaltspunkt, nicht mehr und nicht weniger.


[1] https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0

[mezzomix]

Die Daten der Knoten haben eben keine Aussagekraft, da eine Lüge (für diesen Knoten) keine Folgen hat. Zusammen mit den niedrigen Hard-Fork Grenzen führt das zu unschönen Effekten im Netzwerk, falls nicht alle Knoten 24/7 überwacht werden. Ich vermute man hat das System nur eingeführt, weil man - zurecht- befürchtet, dass eine Protokollentscheidung durch 3-10 Miner nicht mehrheitsfähig ist. Wie Du allerdings richtig erkannt hast, übergibt man mit BU den Minern mehr oder weniger verdeckt sowieso die Protokollentscheidung. Eine Funktion die so nie vorgesehen war und der ich nicht zustimmen möchte.

[flipperfish]

Eine Lüge hat aber für den Knoten auch keinen Nutzen. Damit ist die Wahrscheinlichkeit groß, dass nur wenige Knoten lügen. Und damit haben die Daten wieder eine gewisse Aussagekraft. Unschöne Effekte gibt es bei den BU Clients eben genau nicht: Die folgen wie bereits geschrieben in gewissen konfigurierbaren Grenzen immer der längsten Chain, egal welcher Blockgröße.

Satoshi schrieb in seinem Whitepaper "One CPU, one vote". Damit war von Anfang an klar, welche Rolle die Miner spielen. Diese Rolle werden sie früher oder später auch wahrnehmen, ob mit oder ohne BU. Wichtig dabei ist nur, dass die Miner zwar das Protokoll direkt bestimmen, die Nutzer aber durch ihre wirtschaftliche Beteiligung indirekt die Miner bestimmen.

[Pug]

Bei meinem Patchvorschlag ist es egal, da das Netz nicht tatsächlich grösser wird, wenn ein Miner plötzlich 10k Nodes in Betrieb nimmt. Dann verbreiten sich seine Blöcke zwar unter diesen 10k Nodes, was aber keine praktische Relevanz hat, den es wird trotzdem keine der "echten" Nodes diese Blöcke aktzeptieren.

Könntest du das mit der "keine Relevanz" etwas näher ausführen. Für mich würde das nur Sinn machen wenn die anderen Miner nur auf die "echten" Nodes hören würden um an neue Blöcke zu gelangen, sobald die doch auch den "fake" Nodes zuhören würden die doch anfangen auf dem Block die Kette zu erweitern was ja nach deinem Vorschlag aus nicht passieren soll.

[doc12]

Satoshi schrieb in seinem Whitepaper  ....

Das hört sich immer so an wie "Und Gott sprach ... bla". Bitcoin muss sich weiterentwicklen um zu überleben und da hilft ein rezitieren eines 9 Jahren alten Whitepapers nichts.

Unschöne Effekte gibt es bei den BU Clients eben genau nicht: Die folgen wie bereits geschrieben in gewissen konfigurierbaren Grenzen immer der längsten Chain, egal welcher Blockgröße.

Oder die Clients folgen gar keiner Chain weil die Freizeit-Entwickler, die nebenbei für ihr Geld arbeiten müssen zu viele Bugs eingebaut haben ... dann lieber VC gesponsorten Vollzeitentwickler.

BU führt eine gravierende Ändrung des Konsensmechanismus ins System ein und da gibt es wirklich Leute die das untersützten ohne das es jemals getestet wurde, keine Worte ... und dann so Argumente Segwit sei zu komplex.

Kannst du mir das mal erklären wie man allen ernstes eine völlig ungetestete weitreichende Änderung ohne jegleiche Tests ins Bitcoin-System einbringen will ? Seid ihr eigentlich des Wahnsinns ? Das kann egentlich nur jemand mit destruktiven Absichten gutheißen.

[mezzomix]

Eine Lüge hat aber für den Knoten auch keinen Nutzen. Damit ist die Wahrscheinlichkeit groß, dass nur wenige Knoten lügen. Und damit haben die Daten wieder eine gewisse Aussagekraft. Unschöne Effekte gibt es bei den BU Clients eben genau nicht: Die folgen wie bereits geschrieben in gewissen konfigurierbaren Grenzen immer der längsten Chain, egal welcher Blockgröße.

Stresstest und segwit blockieren hat in diesem Sinne auch keinen Nutzen und wird trotzdem gemacht. Im übrigen folge nicht jeder Client der Chain, da sinnvollerweise auch ein Maximum konfigurierbar ist. Wir diese überschritten, dann ist der Knoten - genauso wie heute auch - draussen.

Könntest du das mit der "keine Relevanz" etwas näher ausführen. Für mich würde das nur Sinn machen wenn die anderen Miner nur auf die "echten" Nodes hören würden um an neue Blöcke zu gelangen, sobald die doch auch den "fake" Nodes zuhören würden die doch anfangen auf dem Block die Kette zu erweitern was ja nach deinem Vorschlag aus nicht passieren soll.

Es stört nicht. Baut ein segwit Miner einen Block basierend auf dem non-segwit Block, dann ist das so. In diesem fall werden beide Blöcke aktzeptiert. Es geht dabei nicht um eine Blockade, es wird nur ein Vorrang entsprechend der eigenen Präferenz umgesetzt.

[Pug]

Ein Block ohne dieses Bit wird nur dann aktzeptiert und weitergeleitet, wenn ein darauf aufbauender Block mit gesetztem Bit verfügbar ist.

Hatte das "mit gesetzem Bit" als ausschließlich verstanden.

Würde das dann nicht die Orphan-Block Rate auf beiden Seiten heraufsetzen?  (bei angenommen ungefähr gleicher Hashrate beider Gruppen)

[d5000]

Dieser Angriff hilft nur bei BU. Dort kaann über Fake-Nodes ein falsches Bild über die aktuell gewünschte / aktzeptierte Blockgrösse transportiert und so eine Fehlentscheidung der Miner produziert werden.

Das verstehe ich nicht. Es ist doch egal, welche Seite die Blockweiterleitung verzögert - schließlich geht es ja bei deinem Patch darum, den Minern es schmackhaft zu machen, einen Client mit einer bestimmten Versionsnummer zu betreiben (also im Beispiel entweder ein Core mit Segwit-Versionsbit oder eine BU-Version) und durch eine hohe Akzeptanz weniger Orphans zu produzieren (bzw. besser andersherum: die "nicht gewünschte" Version produziert mehr Orphans). Egal wer den Angriff startet, die Gegenseite wird benachteiligt. Denke ich jedenfalls.

Bei meinem Patchvorschlag ist es egal, da das Netz nicht tatsächlich grösser wird, wenn ein Miner plötzlich 10k Nodes in Betrieb nimmt. Dann verbreiten sich seine Blöcke zwar unter diesen 10k Nodes, was aber keine praktische Relevanz hat, den es wird trotzdem keine der "echten" Nodes diese Blöcke aktzeptieren.

Auch da stehe ich gerade auf dem Schlauch. Was unterscheidet die "Fake Nodes" (also die "politischen Nodes", die eine bestimmte Version benachteiligen möchten) von "echten Nodes"? Wenn das richtig gemacht wird (also die Nodes auf verschiedenen Rechenzentren weltweit verteilt) kann man die nicht von echten Nodes unterscheiden - sie werden sich also überall mit echten Nodes verbinden und somit beeinflussen, welche Blocks schneller weitergeleitet werden. Es sei denn, man könnte diese "politischen Nodes" erkennen und blacklisten, aber dann müsste man sie ja überwachen.

PS: Deine Bedenken bezüglich BU teile ich und unterstütze diese Version daher nicht. Classic wäre eine imho bessere Möglichkeit gewesen - und hat mit Flexible Transactions ja auch einen Malleability Fix, der wohl auch LN und Co. ermöglichen würde.

[mezzomix]

Dieser Angriff hilft nur bei BU. Dort kaann über Fake-Nodes ein falsches Bild über die aktuell gewünschte / aktzeptierte Blockgrösse transportiert und so eine Fehlentscheidung der Miner produziert werden.

Das verstehe ich nicht. Es ist doch egal, welche Seite die Blockweiterleitung verzögert - schließlich geht es ja bei deinem Patch darum, den Minern es schmackhaft zu machen, einen Client mit einer bestimmten Versionsnummer zu betreiben (also im Beispiel entweder ein Core mit Segwit-Versionsbit oder eine BU-Version) und durch eine hohe Akzeptanz weniger Orphans zu produzieren (bzw. besser andersherum: die "nicht gewünschte" Version produziert mehr Orphans). Egal wer den Angriff startet, die Gegenseite wird benachteiligt. Denke ich jedenfalls.

Wenn die Knoten und Miner einigermassen gleich verteilt wären, dann ist so ein System sinnlos. Ich bin davon ausgegangen, dass die Knoten überwiegend segwit wollen und die Miner das blockieren. Dann werden die Miner den Knoten folgen oder forken, während die Knoten niemals den non-segwit Minern folgen werden. Es wird nur derjenige Benachteiligt, der seine Vorstellung gegen eine massive Mehrheit der Knoten durchsetzen möchte.

Bei meinem Patchvorschlag ist es egal, da das Netz nicht tatsächlich grösser wird, wenn ein Miner plötzlich 10k Nodes in Betrieb nimmt. Dann verbreiten sich seine Blöcke zwar unter diesen 10k Nodes, was aber keine praktische Relevanz hat, den es wird trotzdem keine der "echten" Nodes diese Blöcke aktzeptieren.

Auch da stehe ich gerade auf dem Schlauch. Was unterscheidet die "Fake Nodes" (also die "politischen Nodes", die eine bestimmte Version benachteiligen möchten) von "echten Nodes"? Wenn das richtig gemacht wird (also die Nodes auf verschiedenen Rechenzentren weltweit verteilt) kann man die nicht von echten Nodes unterscheiden - sie werden sich also überall mit echten Nodes verbinden und somit beeinflussen, welche Blocks schneller weitergeleitet werden. Es sei denn, man könnte diese "politischen Nodes" erkennen und blacklisten, aber dann müsste man sie ja überwachen.

Man kann die Knoten nicht erkennen, darum geht es nicht. Ein Miner muss seinen Block zum Ziel bringen und das sind die Knoten der anderen Miner, die Knoten der Händler und die Knoten der Nutzer. Wenn diese anderen Knoten nun seine Blöcke benachteiligen, dann wird er diesem Ziel auch mit einer übermacht an eigenen Knoten nicht sehr viel näher kommen. Er kann die anderen Teilnehmer nicht dazu zwingen, seine Blöcke zu aktzeptieren und weiterzuleiten.

Nochmal - es geht nicht darum einen Miner auszusperren oder komplett zu blockieren, sondern lediglich darum einen kleinen statistischen Nachteil zu erzeugen, wenn ein Miner gegen die anderen Knoten(betreiber) die Weiterentwicklung blockiert.

[d5000]

Ich bin davon ausgegangen, dass die Knoten überwiegend segwit wollen und die Miner das blockieren.

Ah ok, jetzt hab ich deine Argumentation verstanden. Bei meinem Szenario dagegen wären die meisten Nodes "neutral" bzw. "unpolitisch", d.h. in diesem Fall würde von beiden Seiten aus ein Sybil Attack Sinn haben. Aber es stimmt ja, dass die Mehrheit eigentlich für Segwit tickt und es doch ziemlich schwierig wäre, dieses Verhältnis umzukehren. Irgendwo hatte ich auch mal eine genaue Statistik gesehen, aber die ist mir verlorengegangen (also nicht zu den Minern sondern zu den Nodes allgemein).

Der Rest ist klar.

[flipperfish]

Satoshi schrieb in seinem Whitepaper  ....

Das hört sich immer so an wie "Und Gott sprach ... bla". Bitcoin muss sich weiterentwicklen um zu überleben und da hilft ein rezitieren eines 9 Jahren alten Whitepapers nichts.

Ändert nichts an der Tatsache, dass es auch heute noch Gültigkeit hat. Und zumindest die Aussage von oben wird es auch weiterhin haben, solange am Mining nichts geändert wird.

BU führt eine gravierende Ändrung des Konsensmechanismus ins System ein und da gibt es wirklich Leute die das untersützten ohne das es jemals getestet wurde, keine Worte ... und dann so Argumente Segwit sei zu komplex.

Kannst du mir das mal erklären wie man allen ernstes eine völlig ungetestete weitreichende Änderung ohne jegleiche Tests ins Bitcoin-System einbringen will ? Seid ihr eigentlich des Wahnsinns ? Das kann egentlich nur jemand mit destruktiven Absichten gutheißen.

Die Änderung einer Konstanten von 1 auf derzeit maximal 32 ist weder gravierend, noch komplex, noch weitreichend.

Eine Lüge hat aber für den Knoten auch keinen Nutzen. Damit ist die Wahrscheinlichkeit groß, dass nur wenige Knoten lügen. Und damit haben die Daten wieder eine gewisse Aussagekraft. Unschöne Effekte gibt es bei den BU Clients eben genau nicht: Die folgen wie bereits geschrieben in gewissen konfigurierbaren Grenzen immer der längsten Chain, egal welcher Blockgröße.

Stresstest und segwit blockieren hat in diesem Sinne auch keinen Nutzen und wird trotzdem gemacht. Im übrigen folge nicht jeder Client der Chain, da sinnvollerweise auch ein Maximum konfigurierbar ist. Wir diese überschritten, dann ist der Knoten - genauso wie heute auch - draussen.

Ich würde nicht behaupten, dass Segwit zu blockieren keinen Nutzen hat. Ich finde es gerade sehr nützlich... Bei Stresstests kenne ich den Nutzen gerade nicht, aber es wird einen haben, denn warum sollte sich sonst jemand die Mühe machen.

Die konfigurierbaren Grenzen bei BU sind schon etwas komplexer als ein simples Maximum. Und im schlimmsten Fall kann man auch ziemlich schnell die Parameter anpassen, ohne gleich den ganzen Client neu kompilieren zu müssen.

[doc12]

BU führt eine gravierende Ändrung des Konsensmechanismus ins System ein und da gibt es wirklich Leute die das untersützten ohne das es jemals getestet wurde, keine Worte ... und dann so Argumente Segwit sei zu komplex.

Kannst du mir das mal erklären wie man allen ernstes eine völlig ungetestete weitreichende Änderung ohne jegleiche Tests ins Bitcoin-System einbringen will ? Seid ihr eigentlich des Wahnsinns ? Das kann egentlich nur jemand mit destruktiven Absichten gutheißen.

Die Änderung einer Konstanten von 1 auf derzeit maximal 32 ist weder gravierend, noch komplex, noch weitreichend.

Doch klar und zwar alle drei zusammen, wenn du bei einem technischen System einfach die Konstanten änderst ohne das vorher zu testen dann kann das sehr wohl  gravierend, komplex, weitreichend sein. Der Sattelit z.B. verglüht dann in der Atmosphäre oder das Motor-Regelungssystem schwingt oder oder das dezentrale Netzwerk forkt sich in 10 Teile mit "Divergent Consensus™"