Topic: true-cost-bitcoin-transactions (Read 4285 times)

Ein Pool trägt überhaupt nichts positives zum System bei. Ich weigere mich, einem Pool auch nur im Ansatz einen besonderen Stellenwert oder gar besondere Rechte einzuräumen. Wenn einzelne Personen einen Pool dann auch noch dazu benutzen um ihre eigene Agenda voranzutreiben, dann sollte meiner Meinung nach jeder andere Bitcoin Nutzer im eigenen Interesse dagegen vorgehen.

Die sinnvollste Änderung zur Lösung der vollen Blocks wäre eine Änderung des Mining-Algorithmus. Als mit Abstand wichtigste Änderung für den nächsten Hard-Fork sehe ich eine Änderung der Mining-Algorithmus.

Würdest du Core dann auch ablehnen, wenn das Projektteam einen eigenen Pool startet? Wie definierst du "eigen"? Reicht es dafür aus den Pool nur zu "beraten"?

Prinzipiell skizziert das Dokument nur den Aufbau des Projektteams. Dass dazu auch der Poolbetreiber des BU Projektteams gehört, auf dessen Pool vielleicht neue Releases auch mal getestet werden können, begründet doch keine Wirkung auf andere Pools. Hier wird immer die Qualität der Umsetzung kritisiert, aber wenn das Projektteam einen eigenen Pool betreiben möchte, der vielleicht positiv zur Qualität der Software beiträgt, ist es auch nicht recht.

Ich bleibe dabei, dass ein Pool (Operator) keine (tragende) Rolle im Bitcoin System spielen darf. Nur weil die technischen Möglichkeiten die Bildung der Pools erlaubt haben, gestehe ich ihnen keine ausgezeichnete Rolle zu, wie es in diesem Dokument vorausgesetzt wird. Da dieses Dokument die Leitlinien der Entwicklung skizziert, ist die Wirkung letztendlich nicht auf den "eigenen" Pool beschränkt.

Er mal Fehlentwicklungen zulassen/fördern, weil sie ja (erst mal) "nur" in einem begrenzten Rahmen stattfinden, ist für mich kein erstrebenswertes Ziel.

Ich glaube du hast hier etwas missverstanden: Mit "Pool Operator" in dem von dir verlinkten Dokument ist der Operator des vom BU Projektteam betriebenen Pools (den es soweit ich weiß noch gar nicht gibt) gemeint, nicht "die Pool Operatoren irgendwelcher Pools".

Der Verdacht ist leider absolut korrekt. Man kann sich das das PDF Articles of Federation durchlesen. Eine hierarchische Struktur in der Pool Operator eine Rolle spielen sollen und so eine Rolle zementieren, die nicht unbedingt erwünscht ist und zu den aktuellen Problemen beiträgt.

Ehrlich gesagt gefällt es mir gar nicht, was hier zwischen den Zeilen oder auch direkt, angestrebt wird. Eine Herrscherkaste im Bitcoin System?! Nein!

Das Problem bei BU ist meines Erachtens, dass die "einfache Konstantenänderung" sehr weitreichende Konsequenzen beim Thema Machtverteilung im Bitcoin-Ökosystem hat. Ich weiß zwar nicht, ob die BU-Macher da (angemessen komplexe/aufwändige) Simulationen haben laufen lassen, aber es ist ja sehr wahrscheinlich, dass große Miningpools durch BU noch mehr Macht bekommen - da sie auch die Blockgröße bestimmen können und eine Gruppe, die eine höhere Blockgröße will, wohl bei entsprechender Hashrate (wahrscheinlich auch unter 50%, also immer, wenn es eine gewisse Wahrscheinlichkeit gibt mehrere Blocks hintereinander in der Gruppe zu minen) immer gewinnt.

Wenn - wie ich weiter vorne beschrieben habe - eine Zahl von Nodes da gegenarbeiten wollten (weil sie zu große Blocks nicht mehr weiterleiten) steht die Gefahr eines Forks im Raum.

Das Testen einer geänderten Konstanten ist im Vergleich zum Testen eines komplett neuen Systems nicht komplex. Bei einem Satelliten oder einem Motor-Regelungssystem kann man das ziemlich leicht vorausberechnen, was passiert wenn man eine Konstante ändert. Wenn du hingegen den Motor von Benzin auf Elektorantrieb umstellst, kannst du das Regelungssystem komplett neu entwickeln. Was ist jetzt komplexer?

Ich kann vorausberechnen (wie ich es oben ja schonmal als Abschätzung versucht habe), wie sich Bitcoin bei geänderter Konstante "Blockgröße" verhält und welche Auswirkungen das haben wird. Die wirtschaftlichen Effekte, die sich bei bei Beibehaltung der aktuellen Blockgröße von 1 MB entwickeln werden, kann ich nicht mal erahnen... Wie weit wird die Fee ansteigen? Wie wird sich der Wert entwickeln, wenn neue Nutzer Altcoins nutzen müssen?
Auch die Auswirkungen von Segwit mit der Bevorzugung von signaturintensiven Transaktionen sind genauswenig abschätzbar.

Habe ich im Thread bereits beschrieben.

Das mit Abstand wichtigste, was Du tun kannst ist aber, Dich nicht als "Endverbraucher" der "sowieso nichts tun kann" zu betrachten.

Also, was können/sollen wir als Endverbraucher dann tun 

Habt Ihr Ideen"

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™"

Ä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.


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


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.

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.

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.


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.

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.


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.

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)

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.


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.

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.


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.

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.

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.

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.