Re: Der Aktuelle Kursverlauf blockgrösse

[Rakete4]

Auf dieser Seite ist unten eine Erläuterung, wie Exchanges sowohl BIP-148 Bitcoin als auch Legacy-Bitcoin handeln können.
Es ist leider ziemlich kompliziert:
https://www.weusecoins.com/uasf-guide/
Bitte selbst den Link durchlesen, ich möchte das nicht alles hier reinkopieren.
Für große Exchanges ist so etwas vom Aufwand her wohl machbar, aber für die Nutzer schwer verständlich.

Es hätte natürlich für die Exchanges den Vorteil, dass sie sich selbst keinem Risiko aussetzen. Eine Exchange, die einen Alleingang macht und komplett auf BIP-148 umstellt, geht zwar auch nicht unbedingt Pleite im Fall eines Mißerfolgs, aber sie verliert den Großteil ihrer Kunden, sowie alle ihre Coins auf der BIP-148 Chain, die nicht Kundeneinlagen waren. Die Coins der Kunden verliert sie natürlich auch, aber die muss sie ja nicht erstatten. Gleiches gilt natürlich für eine Exchange, die bei der UASF-Fork nicht mitmacht, in dem Fall, dass die UASF erfolgreich ist.

Ideal wäre es, wenn sich mehrere Exchanges absprechen und gemeinsam auf BIP-148 umstellen. Über entsprechende einklagbare Verträge mit verbindlichen Schadenssummen könnten sie sich gegenseitig versichern, dass sie sich nicht gegenseitig im Regen stehen lässen.

Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.

[1714921893]

1714921893

[d5000]

Core-Entwickler Eric Lombrozo geht unter die bösen Verräter, die statt dem Chainsplit noch einen Konsens verfolgen. So wie ich es interpretiere, will er versuchen, aus Barry Silbert's Agreement was brauchbares zu machen, dem auch die Core-Leute zustimmen können.

[Gyrsur]

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

[Lincoln6Echo]

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

Wer ist denn James Hilliard? Er ist ja der Autor von BIP91.
Mir sagt der Name im Moment gar nichts. Schon mal gut das es ein Softfork ist.

[Rakete4]

Ich denke, mit dem BIP wird lediglich Bitcoin Core kompatibel gemacht mit dem ersten Teil des New York Agreements.

Barry Silbert wird sicher derzeit versuchen, ein neues Dev-Team aufzustellen, das den 2 MB Hardfrok codiert (so trivial ist das nämlich nicht),  und vermutlich auch im Weiteren dann die Geschicke von Bitcoin leiten soll. Bei dem New York agreement war mit Gavin Andresen nur 1 ehemaligen Bitcoin Developer beteiligt.

Die Stille zu dem Thema ist ja geradezu ohrenbetäubend.

Soweit ich mich erinnere, gibt es auch einige anderen Bugs/Unschönheiten im Bitcoin Code, die man nur durch einen Hardfork beseitigen kann. Es wäre daher wünschenwert, wenn da sinnvoll zusammengearbeitet wird mit einigen erfahrenen Core developpern.

Aber das wünschenswerte passiert beim Bitcoin schon lange nicht mehr, also machen wir uns mal alle schön auf die nächsten Enttäuschungen gefasst.

[Greshamsches Geld]

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

...

 Schon mal gut das es ein Softfork ist.

Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

[Rakete4]

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

...

 Schon mal gut das es ein Softfork ist.

Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

Dann minen sie ungültige Blöcke und verdienen nichts.

[Greshamsches Geld]

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

...

 Schon mal gut das es ein Softfork ist.

Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

Dann minen sie ungültige Blöcke und verdienen nichts.

Verstanden. Wenn SegWit entweder (4) ab 80% oder SegWit(1) ab 95% offiziell durch ist, ist es durch. Danke.

[Bergmann_Christoph]

...
Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.

Kannst du mir erklären, warum dir eine UASF so wichtig ist?

Es gibt jetzt ein Agreement, das von genügend Minern und Unternehmen getragen wird, um OHNE split mehr Kapazität + SegWit zu schaffen, und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.

Die ganze Zeit hieß es, eine Hard Fork sei schlecht, weil sie zu einem Chain split führen kann. Nun haben wir die Möglichkeit, die Hard Fork ohne Chain splitt zu schaffen, und die UASF Fans versuchen auf Teufel komm' raus SegWit auf eine Weise zu aktivieren, die garantiert zum Chain Split führt.

Warum? Nur aus Prinzip, weil "Jihan böse" + "User haben die Hosen an"? Also, um einen Punkt zu machen?

[Greshamsches Geld]

OHNE split mehr Kapazität + SegWit zu schaffen,

Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.

Ach, ist das so?

[mezzomix]

OHNE split mehr Kapazität + SegWit zu schaffen,

Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

Doch das scheint zu gehen. Irgendwo im Development Bereich hat vor kurzem jemand eine Lösung, basierend auf den erweiterten segwit Transaktionen, skizziert. Damit wären 2MB per Soft-Fork möglich.

Allerdings würden die 2MB nur für segwit Transaktionen gelten. Ist aber auch klar, da die alten Knoten davon nichts wissen können. Ausserdem wäre es sinnvoll, da nur für die segwit Transaktionen das Problem mit dem quadratischen Aufwand zur Hashberechnung gelöst ist.

Möchte man segwit + 2MB per Hard-Fork, wäre die von Gavin vorgeschlagene segwit Umsetzung sinnvoller, da dort das Block-Format deutlich vereinfacht wird. Daneben könnte (sollte!) man mit einem Hard-Fork gleich noch ein paar andere Sachen geradeziehen. In diesem Zug könnte man dann gleich die bisherigen Transaktionsformate über Bord werfen. Warum Altlasten mitschleppen, wenn sowieso alle zum Stichtag umstellen müssen?! Die bisherigen Soft-Fork vorschläge sind nur unter der Annahme sinnvoll, dass die alten Knoten ohne Änderung weiterarbeiten können. Peilt man einen Hard-Fork an, muss man das gesammte System vereinfachen. Alles andere wäre grober Unfug.

[Bergmann_Christoph]

OHNE split mehr Kapazität + SegWit zu schaffen,

Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.

Ach, ist das so?

Wenn weniger als 10 Prozent der Miner mitmachen, gibt es keine Chainsplit.

Soweit ich es gehört habe, ja, die allermeisten sind mit SW + 2 MB einverstanden. Du nicht?

Beantwortet alles aber meine Frage nicht: Warum unbedingt ein ChainSplit?

[Bergmann_Christoph]

OHNE split mehr Kapazität + SegWit zu schaffen,

Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

Doch das scheint zu gehen. Irgendwo im Development Bereich hat vor kurzem jemand eine Lösung, basierend auf den erweiterten segwit Transaktionen, skizziert. Damit wären 2MB per Soft-Fork möglich.

Allerdings würden die 2MB nur für segwit Transaktionen gelten. Ist aber auch klar, da die alten Knoten davon nichts wissen können. Ausserdem wäre es sinnvoll, da nur für die segwit Transaktionen das Problem mit dem quadratischen Aufwand zur Hashberechnung gelöst ist.

Möchte man segwit + 2MB per Hard-Fork, wäre die von Gavin vorgeschlagene segwit Umsetzung sinnvoller, da dort das Block-Format deutlich vereinfacht wird. Daneben könnte (sollte!) man mit einem Hard-Fork gleich noch ein paar andere Sachen geradeziehen. In diesem Zug könnte man dann gleich die bisherigen Transaktionsformate über Bord werfen. Warum Altlasten mitschleppen, wenn sowieso alle zum Stichtag umstellen müssen?! Die bisherigen Soft-Fork vorschläge sind nur unter der Annahme sinnvoll, dass die alten Knoten ohne Änderung weiterarbeiten können. Peilt man einen Hard-Fork an, muss man das gesammte System vereinfachen. Alles andere wäre grober Unfug.

Wie gesagt: Wenn Unternehmen und Miner einverstanden sind, ist ein Chainsplit vermutlich nicht weiter relevant, egal wie man es macht. Die Schwierigkeit beim Bitcoin-Mining ist mittlerweile so astronomisch ...

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

[mezzomix]

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

Ist es nicht. Wer mit "zu spät" argumentiert will andere nur grundlos in die Ecke drängen. Wenn man sowieso eine Revolution macht, dann wirft man Altlasten über Bord und zieht diese nicht wie beim evolutionären Ansatz hinter sich her. Wenn man an einem Geldsystem herumschraubt, dann macht man das unter den gegebenen Bedingungen (Hard-Fork / Soft-Fork) richtig - oder gar nicht.

Also entweder alles per Soft-Fork oder aber ein Hard-Fork ohne die ganzen Altlasten.

Meine Meinung.

[flyer88]

Im Grunde richtig aber imo nicht realistisch. Dann gehen die ganzen Diskussionen wieder von vorne los und wir haben in 10 Jahren noch keine Lösung. Denn ich bin mir ziemlich sicher irgendwer hat was dagegen und gründet eine Bewegung um zu zeigen, dass sein Ego das größte ist.

[Bergmann_Christoph]

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

Ist es nicht. Wer mit "zu spät" argumentiert will andere nur grundlos in die Ecke drängen. Wenn man sowieso eine Revolution macht, dann wirft man Altlasten über Bord und zieht diese nicht wie beim evolutionären Ansatz hinter sich her. Wenn man an einem Geldsystem herumschraubt, dann macht man das unter den gegebenen Bedingungen (Hard-Fork / Soft-Fork) richtig - oder gar nicht.

Also entweder alles per Soft-Fork oder aber ein Hard-Fork ohne die ganzen Altlasten.

Meine Meinung.

Ich möchte jetzt nicht überdramatisieren. Aber sorry. Seit 2014 haben Leute gesagt "Erhöht die Blocksize", und es ist nichts passiert. Core hätte noch 2015, vielleicht auch noch 2016, eine Hardfork in xx Monaten ankündigen können und da all die tollen Dinge reinpacken. Haben sie aber nicht gemacht. Jetzt haben die Miner und die Wirtschaft die Geduld verloren und machen ohne Core eine Mimimal-Hardfork, um das Blocksize-Problem zu fixen.

Sowieso: Es ist war an sich logisch, in eine Hardfork so viel reinzupacken wie möglich, wenn man sie schon macht. Andererseits aber bedeutet das, dass der Code für die Hardfork und diese selbst komplexer wird, dass es mehr Möglichkeiten gibt, wie etwas schief geht, dass es mehr Kontroversen geben kann, dass es schwieriger wird, entstandene Schäden zu beheben, und dass die Umstellung der Clients und der darum herum gebauten Software eventuell schwieriger wird. Wenn ich es mir so überlege, sollte man es vermeiden, allzu viel in eine HF zu stecken.

[mezzomix]

Es wäre logisch so wenig wie möglich in den Hard-Fork zu packen, also viel alten Code zu entfernen und wenig neuen Code einzubauen. Das senkt das Risiko und erhöht die Testabdeckung, da es weniger Variationen zu testen gibt.

Von mir aus kann man auch segwit als Soft-Fork und 2MB als Hard-Fork machen, wenn alle das tatsächlich wollen. Das würde ich für mich dann eben unter verpasste Chance ablegen.

Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!

[Bergmann_Christoph]

Es wäre logisch so wenig wie möglich in den Hard-Fork zu packen, also viel alten Code zu entfernen und wenig neuen Code einzubauen. Das senkt das Risiko und erhöht die Testabdeckung, da es weniger Variationen zu testen gibt.

Genau, sehe ich auch so. So unkompliziert wie möglich, so dass es so viele Leute wie möglich verstehen und verifizieren können.

Von mir aus kann man auch segwit als Soft-Fork und 2MB als Hard-Fork machen, wenn alle das tatsächlich wollen. Das würde ich für mich dann eben unter verpasste Chance ablegen.

Für mich sind wir schon seit einigen Monaten auf dem Kontinten der "verpassten Chancen". Mich würde aber interessieren, welche Chance wir deiner Meinung nach mit 2MB + SW verpassen werden?

Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!

Manchmal wird SegWit als 2MB Softfork bezeichnet. Das ist falsch, da SegWit eher eine 1,5 MB Size mit DoS-Angriffsfläche von 4mb ist. Und darüber hinaus eine Menge andere Dinge als Blocksize-Erhöhung macht.

Extension Blocks ist die andere Idee von 2mb Softfork. Daran wird gerade gearbeitet, siehe bcoin, und vermutlich wird das der Ausweg werden, wenn wir ans Limit von 2MB+SW knallen bzw. wird schon vorher eingerichtet, um eine Art Sidechain für billige Massentransaktionen zu werden.

[mezzomix]

Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!

Manchmal wird SegWit als 2MB Softfork bezeichnet. Das ist falsch, da SegWit eher eine 1,5 MB Size mit DoS-Angriffsfläche von 4mb ist. Und darüber hinaus eine Menge andere Dinge als Blocksize-Erhöhung macht.

segwit + 2MB als Soft-Fork bedeutet segwit und zusätzlich noch ein 2MB softfork. D.h. die Blöcke können inkl. Signaturen bis zu 8MB gross werden und nicht nur die 4MB bei segwit!

Es geht nur darum, dass man die zusätzlichen 2MB nicht per Hard-Fork löst, wenn man sowieso den alten Kram weiter mit sich rumschleppt. Dann sollte man die Gelegenheit nutzen und die alten Knoten einfach weiterlaufen lassen. Denn tatsächlich ist der Soft-Fork "nur" ein politisches Problem 1-3 der Miner, während der Hard-Fork jeden Knoten (inkl. aller Patches und Anpassungen) betrifft. Ein kurzfristiger Hard-Fork bedeutet, dass alle (nochmal alle!) Implementierungen zum Stichtag angepasst sein müssen.

[Rakete4]

...
Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.

Kannst du mir erklären, warum dir eine UASF so wichtig ist?

Es gibt jetzt ein Agreement, das von genügend Minern und Unternehmen getragen wird, um OHNE split mehr Kapazität + SegWit zu schaffen, und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.

Die ganze Zeit hieß es, eine Hard Fork sei schlecht, weil sie zu einem Chain split führen kann. Nun haben wir die Möglichkeit, die Hard Fork ohne Chain splitt zu schaffen, und die UASF Fans versuchen auf Teufel komm' raus SegWit auf eine Weise zu aktivieren, die garantiert zum Chain Split führt.

Warum? Nur aus Prinzip, weil "Jihan böse" + "User haben die Hosen an"? Also, um einen Punkt zu machen?

Hallo Christoph,

die UASF an sich ist mir gar nicht wichtig, wichtig ist mir, dass jetzt endlich mal etwas vorangeht. Wichtig ist mir dabei,

-dass Segwit als Soft Fork kommt, vor allem damit man testen kann, ob sich das Lightening network bewährt, aber auch aus anderen Gründen, z.B. dass endlich mal die Outputs genauso viel ins Gewicht fallen wie die Inputs bei der Transaktionsgebühr, und vieles mehr.

-dass eine Erhöhung der Blocksize per Hardfork massvoll ausfällt

-dass das Bitcoin Core Team den Client stellt und die Detailarbeit macht, denn auf deren technische Fähigkeiten vertraue ich am meisten


Aber es ist schön, dass sich der Fokus der Diskussion endlich verschoben hat in Richtung Kompromissfindung und die Eckpfeiler schon stehen (Segwit+2 MB), auch wenn vieles noch zu klären ist. Sieht man auch hier im Thread schön, wie sich der Fokus verschoben hat.

Den UASF-Avatar behalte ich noch so lange, bis es von der New York Consensus-Seite um Barry Silbert endlich mal etwas konkretes gibt: Wo ist der neue Github, wo sind die neuen Devs, oder soll doch alles von den Core-Devs gemacht werden?
Die Segwit-Blockierer sind da in der Bringschuld, und da ist es legitim, als User so lange noch weiter an der UASF-Propaganda festzuhalten.

Die Leute haben sich Bitcoins gekauft, weil sie dachten, dass Miner als Serviceleistung Double-Spends verhindern und dafür entlohnt werden, nicht weil sie von den Minern regiert werden wollen. Fremdregieren lassen kann man sich genauso gut im FIAT-System. Dass der Clique um Jihan Wu offenbar gar nicht klar ist, warum die Leute so verärgert sind, zeigt schon wie abgehoben die mittlerweile sind.

Gruß,

Rakete4

P.S. Dass ich nicht unter meinem Klarnamen schreibe, hat einfach den Grund, dass es meinen Namen nur einmal weltweit gibt, so dass dann jeder bei Google gleich auf Bitcoin stösst, der nach mir googelt. Und auf Neider habe ich keine Lust. Ich bin mittlerweile bei drei Bitcoin-Exchanges verifiziert, lande also auch im Gulag, wenn die Regierungen alle Bitcoiner dorthin befördern eines Tages. Es geht mir nur um die privaten Neider.