Re: Der Aktuelle Kursverlauf blockgrösse

[mezzomix]

Nach den aktuellen Aussagen hat BU sich gegen segwit positioniert, d.h. nach einem von BU getragenen Hard-Fork wird es trotzdem kein segwit geben.

Daneben heisst 2MB nicht, das ich damit einem Hard-Fork Automatismus zustimme. Meine Knoten werden dann 2MB aktzeptieren, aber weiteren Hard-Forks nicht folgen. 2MB bedeutet also nicht, dass es mit BU weitergehen wird!

Mit einem Hard-Fork könnte man übrigens segwit sauber Implementieren und das alte Transaktionsformat nicht mehr weiter unterstützen. Allerdings würde man dann über 1 Jahr Testzeit verwerfen.

[1713560627]

1713560627

[1713560627]

1713560627

[1713560627]

1713560627

[1713560627]

1713560627

[Z80]

Nach den aktuellen Aussagen hat BU sich gegen segwit positioniert, d.h. nach einem von BU getragenen Hard-Fork wird es trotzdem kein segwit geben.

Daneben heisst 2MB nicht, das ich damit einem Hard-Fork Automatismus zustimme. Meine Knoten werden dann 2MB aktzeptieren, aber weiteren Hard-Forks nicht folgen. 2MB bedeutet also nicht, dass es mit BU weitergehen wird!

Mit einem Hard-Fork könnte man übrigens segwit sauber Implementieren und das alte Transaktionsformat nicht mehr weiter unterstützen. Allerdings würde man dann über 1 Jahr Testzeit verwerfen.

Okay, das bedeutet die einzige Chance 2MB-SegWit zu bekommen ist ein einsehen der Core-Entwickler, richtig?
Weil mit BU bedeutet >2MB + ohne Segwit.

[mezzomix]

Es könnte sein, dass man die 2MB und die segwit Aktivierung selbst in die Hand nehmen muss. segwit wird von den BU Poolbetreibern boykottiert und zumindest ein paar Core Entwickler wollen keine 2MB.

Die notwendigen Änderungen sind allerdings einfach, dafür braucht es die Core Entwickler nicht. Die Frage bleibt, ob die kompromissbereiten Nutzer eine alternative Software bzw. einen entsprechenden Patch einsetzen. Enthält eibn solcher Patch segwit, werden die BU Poolbetreiber sowieso mit diesem Hard-Fork aus dem Netz geforkt.

[Limx Dev]

Nach den aktuellen Aussagen hat BU sich gegen segwit positioniert, d.h. nach einem von BU getragenen Hard-Fork wird es trotzdem kein segwit geben.

Daneben heisst 2MB nicht, das ich damit einem Hard-Fork Automatismus zustimme. Meine Knoten werden dann 2MB aktzeptieren, aber weiteren Hard-Forks nicht folgen. 2MB bedeutet also nicht, dass es mit BU weitergehen wird!

Mit einem Hard-Fork könnte man übrigens segwit sauber Implementieren und das alte Transaktionsformat nicht mehr weiter unterstützen. Allerdings würde man dann über 1 Jahr Testzeit verwerfen.

Okay, das bedeutet die einzige Chance 2MB-SegWit zu bekommen ist ein einsehen der Core-Entwickler, richtig?
Weil mit BU bedeutet >2MB + ohne Segwit.

Ich denke 8 MB wären notwendig ggf ab 2MB mit steigenden Fees. Weil zur Zeit ist JEDER Altcoin Leistungsfähiger außer (42). ^^

Best Grüße Christian

[mezzomix]

Zur Zeit muss jeder Altcoin seine Leistungsfähigkeit erst noch beweisen, weil kein Altcoin eine solche Transaktionsmenge zu verarbeiten hat.

[Z80]

Es könnte sein, dass man die 2MB und die segwit Aktivierung selbst in die Hand nehmen muss. segwit wird von den BU Poolbetreibern boykotiert und zumindest ein paar Core Entwickler wollen keine 2MB.

Die notwendigen Änderungen sind allerdings einfach, dafür braucht es die Core Entwickler nicht. Die Frage bleibt, ob die kompromissbereiten Nutzer eine alternative Software bzw. einen entsprechenden Patch einsetzen. Enthält eibn solcher Patch segwit, werden die BU Poolbetreiber sowieso mit diesem Hard-Fork aus dem Netz geforkt.

Ja aber wie stellst du dir das vor? Soll jeder kompromissbereiter User die Änderung selbst durchführen..? Solang es kein Projekt gibt wie sagen wir mal... "Bitcoin-Core-Plus" wo sich alle User einen sauberen Segwit+2MB Client runterladen können, wird das wohl eher Theorie bleiben.

Wie Groß siehst Du die Chance da Core doch 2MB zulässt, bzw. wir tatsächlich 2MB-SegWit bekommen?

[Limx Dev]

Zur Zeit muss jeder Altcoin seine Leistungsfähigkeit erst noch beweisen, weil kein Altcoin eine solche Transaktionsmenge zu verarbeiten hat.

Hab bei Bitsend mal 2,3 MB an TX reingehauen...ging ohne Probleme... Screenhots gerne auf Anfrage...

https://chainz.cryptoid.info/bsd/block.dws?000000000e0401ecead5cf26b34c93f717e2cdb482c064c728a089343b523f27.htm

Nach meiner Erfahrung sind Hardforks nicht so schlimm... ich habe bestimmt bei diversen Coins schon 20-30 Forkes gemacht.

Gruß Christian

[Bergmann_Christoph]

Das ist genau das, wohin die chinesischen Miner hinwollen. Wenn eine Fork zu 2 MB gelingt, werden wir in wenigen Monaten SegWit haben. Da bin ich ziemlich optimistisch.

Beides gleichzeitig ist ein Deal.

Aber BU ist ja kein 2MB Fork...  richtig? :-)
Scheint als wäre BU nur ein Druckmittel der Miner, wenn sie doch eigentlich (wie ich) 2MB+SW wollen.
Ich hoffe das ganze geht gut. Lieber wäre mir ein sauberer "SegWit-Core mit 2MB Patch". "Sauber" deshalb, weil eben in diesem Fall das gut getestete Core nur durch einen winzigen Patch auf 2MB gebracht wird. Also wenig Gelegenheit für Programmierfehler...

Und wenn ich eigentlich als User 2MB-SegWit möchte, sollte ich dann auf BU hoffen..?
So wie es aussieht stehen wir ja vor der Frage ob es einen BU-HF gibt und nicht vor der Frage ob wir 2MB + SegWit bekommen.

2MB + SegWit würde doch nur kommen wenn sich die Core-Entwickler bewegen bzw. auf einen Kompromiss einlassen würden... und das, bei allem Optimismus, sehe ich nicht. Ich glaube die sind viel zu Stolz/Ideologisch/Hochnäsig ähm... wie drückt man sowas diplomatisch aus..?

Hm ... also, BU bedeutet nicht mehr, als dass die Miner eine Software benutzen, die kein Blocksize Limit für das Erzeugen von Blocks hat, aber ein frei einstellbares Limit für die Größe von Blöcken, die Miner und Nodes akzeptieren.

Kannst du einen Miner / Knoten daran hindern, diese Software zu benutzen, um in einem Konsens zu bleiben? Nein.
Kann ein Miner dich dazu zwingen, diese Software auch zu benutzen? Nein.

Gibt es einen Widerspruch zwischen Knoten, die bis zu 2 MB akzeptieren, und Minern und anderen Knoten die Unlimited benutzen? Nein.

Da Core nicht kompromisbereit zu sein scheint, ist das benutzen von BU durch die Miner tatsächlich deine einzige Chance, SegWit und 2 MB zu bekommen.

[Bergmann_Christoph]

Daneben heisst 2MB nicht, das ich damit einem Hard-Fork Automatismus zustimme. Meine Knoten werden dann 2MB aktzeptieren, aber weiteren Hard-Forks nicht folgen. 2MB bedeutet also nicht, dass es mit BU weitergehen wird!

Exakt! Darauf will ich ja die ganze Zeit hinaus. Die Miner benutzen BU, und du und hoffentlich viele andere Nodes setzt ein hartes Limit von 2 MB. Wenn die Miner dann irgendwann dieses Limit weiter erhöhen wollen, gibt es keinen Automatismus, sondern sie müssen dich erneut überzeugen.

Genau genommen hoffe ich sogar, dass nicht alle Miner BU verwenden, sondern mindestens 10-30 Prozent ein hartes Limit von 2 MB. Oder 4 MB.

Mit einem Hard-Fork könnte man übrigens segwit sauber Implementieren und das alte Transaktionsformat nicht mehr weiter unterstützen. Allerdings würde man dann über 1 Jahr Testzeit verwerfen.

Die BU-Entwickler diskutieren / planen so etwas. Man könnte SegWit an die erste oder eine spätere Hardfork koppeln oder wie bei der Blocksize den User / Miner entscheiden lassen. Wäre an sich interessant, weil man damit Probleme wie Malleabiity und Quadratic Scaling vollständig aus der Welt zu schaffen könnte. Aber ich habe dagegen heftig protestiert, aus denselben Gründen wie du. Ich denke, es wird am Ende auf SW als Softfork rauslaufen, vermutlich ohne den 3:1 Discount.

[Z80]

Hm ... also, BU bedeutet nicht mehr, als dass die Miner eine Software benutzen, die kein Blocksize Limit für das Erzeugen von Blocks hat, aber ein frei einstellbares Limit für die Größe von Blöcken, die Miner und Nodes akzeptieren.

Kannst du einen Miner / Knoten daran hindern, diese Software zu benutzen, um in einem Konsens zu bleiben? Nein.
Kann ein Miner dich dazu zwingen, diese Software auch zu benutzen? Nein.

Gibt es einen Widerspruch zwischen Knoten, die bis zu 2 MB akzeptieren, und Minern und anderen Knoten die Unlimited benutzen? Nein.

Da Core nicht kompromisbereit zu sein scheint, ist das benutzen von BU durch die Miner tatsächlich deine einzige Chance, SegWit und 2 MB zu bekommen.

Du hast in allen Punkten recht. Wo ich nicht folgen kann ist wie die Chance auf 2MB+SegWit eintreten soll..?

Also nehmen wir an wir haben folgenden Zustand:
Der HF ist da und viele Miner minen Blöcke grösser 1MB (nehmen wir mal an bis max 2MB). Einige Knoten haben nen simplen 2MB Patch, also akzeptieren >1MB (also alle) Blöcke. Einige Knoten fahren BU, akzeptieren die Blöcke natürlich auch. Einige Knoten fahren Core, akzeptieren also nur bis 1MB, Kette spaltet sich ab. -> Zwei BTC-Varianten.

Wie auch immer die Verteilung jetzt ist, wieviel Hashpower welche Kette nun auch immer hat.. wie genau sieht jetzt die Chance auf 2MB+SegWit aus?
 - Core stirbt, BU setzt sich durch und besinnt sich darauf auch SegWit zu nutzen..? (ich finde unwahrscheinlich)
 - BU stirbt, Core setzt sich durch und sagt "okay, sind wir nicht so, machen wir 2MB"...? (auch nicht wirklich wahrscheinlich)
 - Beide BTC-Varianten existieren nebeneinader und Core seht sich genötigt 2MB zu akzeptieren um die Oberhand zu gewinnen...? (echt? Core gibt nach?)
- ....?

Oder wie würdest Du due Chance auf 2MB+SegWit beschreiben?

Edit:
Okay, Dein zwischenzeitlicher Post hat meine Frage quasi halb erklärt... :-)

[Bergmann_Christoph]

Oder wie würdest Du due Chance auf 2MB+SegWit beschreiben?

Edit:
Okay, Dein zwischenzeitlicher Post hat meine Frage quasi halb erklärt... :-)

Ich weiß nicht, ob ich das nochmal erklären muss. Ich bin einfach sehr zuversichtlich, dass die absolute Mehrheit von Bitcoin-Usern nicht so wahnsinnig ist, das ganze System und damit ihr Business und ihr Investment abzufackeln, nur um eine Hardfork zu 2 MB zu verhindern.

Wenn das geklappt hat, werden die Miner aller Voraussicht nach gerne bereit sein, SegWit zu aktivieren.

[OhShei8e]

Ich weiß nicht, ob ich das nochmal erklären muss. Ich bin einfach sehr zuversichtlich, dass die absolute Mehrheit von Bitcoin-Usern nicht so wahnsinnig ist, das ganze System und damit ihr Business und ihr Investment abzufackeln, nur um eine Hardfork zu 2 MB zu verhindern.

Warum nicht? Solange man für sich persönlich einen Vorteil darin sieht, ist die Sache doch klar. So läuft es eben.  

Mir ist das ganze inzwischen viel zu kompliziert geworden. Wenn man erstmal raus ist und sich dann mal wieder damit beschäftigt, merkt man das erstmal so richtig.

Bitcoin war ein schöner einfacher Entwurf. Jetzt mit "SegUnlimited" und einer ausufernden Blockchain macht es wirklich keinen Spaß mehr. Ist wirklich nur noch was für eine handvoll Experten.

Gäbe es vertrauenswürdige Zahlungsdienstleister bräuchte man den ganzen Scheiß nicht. Ebenfalls könnten Bitcoins dann auch an der ganz normalen Börse gehandelt werden. Das ist ja letztlich auch daran gescheitert, dass es außerhalb der Blockchain eben keine Strukturen gibt sondern nur Streit.

Und das Ganze wird jetzt halt immer undurchsichtiger und verworrener, weil an Transparenz niemand ein echtes Interesse hat. Es geht ausschließlich um Kapitalinteressen. So zumindest mein Eindruck. Und das schreibe ich als langjähriger Beobachter und ehemals überzeugter Unterstützer des Systems.  

[doc12]

Ist es nicht völlig scheißegal, ob die Blöcke jetzt 1,2 oder 20 MB haben? Bitcoin kann sowieso nicht onchain skalieren, nur über weitere Layer und die Abwehrhaltung dagegen kann ich nicht nachvollziehen.

Der ganze Bitcoin-Space ist nur noch nervtötend, nichts mehr da vom einstigem Optimismus und von der Idee "die Welt zu verändern". Hier gehts nur noch darum wie man das meiste Fiat rausziehen kann und jetzt noch diese Grabenkämpfe nach trumpscher Art.

Und langsam glaube ich diese BU-Diskussion ist auch nur FUD um Altcoins zu pumpen und dann BTC Preis zu drücken. Nachdem dann genug BTC mit Altcoins gemacht wurde gibt es plötzlich ein Lösung. Die ganzen Sucker bleiben auf Ihren Alts sitzen und die Pumper reiten dann mit Ihren BTC auf der "Scaling-Problem-Gelöst" Monster Welle. Wer möchte schon Altcoins haben, ganz ehrlich? Altcoins sind einzig und allein dazu da Bitcoins (oder Fiat) schnell zu vermehren, zu NIX sonst.

[Z80]

Ich weiß nicht, ob ich das nochmal erklären muss. Ich bin einfach sehr zuversichtlich, dass die absolute Mehrheit von Bitcoin-Usern nicht so wahnsinnig ist, das ganze System und damit ihr Business und ihr Investment abzufackeln, nur um eine Hardfork zu 2 MB zu verhindern.

Wenn das geklappt hat, werden die Miner aller Voraussicht nach gerne bereit sein, SegWit zu aktivieren.

Okay, hab verstanden wie du es meinst, ich hoffe sehr du behälst Recht!
Hauptsache es zieht sich nicht mehr so lange hin... weitere Monate der Unsicherheit tun dem Bitcoin nur schaden.

[d5000]

Zur Zeit muss jeder Altcoin seine Leistungsfähigkeit erst noch beweisen, weil kein Altcoin eine solche Transaktionsmenge zu verarbeiten hat.

Hab bei Bitsend mal 2,3 MB an TX reingehauen...ging ohne Probleme... Screenhots gerne auf Anfrage...

Ein Block ab und zu mit 2,3 MB ist auch kein Problem, für keine Blockchain. Das Problem ist wenn die Blockgröße dauerhaft zu groß wird.

Der Initial Block Download (also das erste Synchronisieren der Blockchain) ist einer der Haupt-Flaschenhälse. Schon die 107 GB heute möchte nicht jeder auf seinen Heim-PC laden. Man kann zwar prunen, aber trotzdem muss jeder Client alle Blocks erst mal validieren und das kostet Zeit, CPU und RAM. Bei wenig Network-Kapazität kann es vorkommen, dass ein Node nicht mehr "mitkommt" und permanent der Blockchain hinterherläuft.

Die Möglichkeiten, dieses Problem zu lösen, machen alle irgendwo Abstriche. Es gibt im Bitcoin-Bereich Lumino, das versucht, die Transaktionen zu komprimieren, dabei aber darauf angewiesen ist, dass der User immer nur eine Adresse verwendet - sonst (also z.B. bei Privacy-liebenden Nutzern, die für jede TX eine neue Adresse nutzen) sind die Vorteile minimal.

Dann gibt es natürlich die "Sharding"-Lösungen, also die Möglichkeit, die Blocks entweder in mehrere "Side- oder Childchains" oder anderswie aufzuteilen, so dass nicht jeder Node die gesamte Blockchain validieren und speichern muss. Hier gibt es tatsächlich einige interessante Projekte, sowohl im Bitcoin- als auch im Altcoinbereich, aber marktreif ist noch keine. Der Abstrich ist hier, dass die Sicherheit einiger Side- oder Childchains kleiner sein könnte als bei der Hauptchain.

Und schließlich eben Off-Chain - also LN und Konsorten.

Nach meiner Erfahrung sind Hardforks nicht so schlimm... ich habe bestimmt bei diversen Coins schon 20-30 Forkes gemacht.

Bei kleinen Coins besteht auch eigentlich kaum die Möglichkeit, dass die unterlegene Chain weiterexistiert und der Hauptchain Konkurrenz macht. Das ist ja das Risiko eines Hardforks bei Bitcoin oder auch einem großen Altcoin wie Ethereum.

[mezzomix]

Der Initial Block Download (also das erste Synchronisieren der Blockchain) ist einer der Haupt-Flaschenhälse. Schon die 107 GB heute möchte nicht jeder auf seinen Heim-PC laden. Man kann zwar prunen, aber trotzdem muss jeder Client alle Blocks erst mal validieren und das kostet Zeit, CPU und RAM. Bei wenig Network-Kapazität kann es vorkommen, dass ein Node nicht mehr "mitkommt" und permanent der Blockchain hinterherläuft.

Es gäbe noch die Möglichkeit, einen UTXO Set Hash im Header abzulegen (UTXO Commitment). Damit könnte man dann basierend auf einem bereits verifizierten Stand (Blocknummer + Hash) einen erneuten Bootstrap beginnen.

[Z80]

Das sind wieder 1 bis 2 Monate die ins Land streichen, aber wenigstens redet man miteinander...:
https://www.btc-echo.de/skalierungsdebatte-treffen-im-mai-geplant/

Schade nur das nicht alle bereit sind durch Kommunikation zu einem Kompromiss zu gelangen:

... Aus diesem Grund hält Back (Blockstream) das Meeting für wenig zielführend und hat angekündigt diesem, trotz Einladung, fern zu bleiben.

...

Es gäbe noch die Möglichkeit, einen UTXO Set Hash im Header abzulegen (UTXO Commitment). Damit könnte man dann basierend auf einem bereits verifizierten Stand (Blocknummer + Hash) einen erneuten Bootstrap beginnen.

Würde das nicht bedeuten das ein solcher Knoten dann eine verkürzte Blockchain hat und ihm alle Adressen mit Guthaben vor diesem Zeitpunkt fehlen?

[mezzomix]

Es gäbe noch die Möglichkeit, einen UTXO Set Hash im Header abzulegen (UTXO Commitment). Damit könnte man dann basierend auf einem bereits verifizierten Stand (Blocknummer + Hash) einen erneuten Bootstrap beginnen.

Würde das nicht bedeuten das ein solcher Knoten dann eine verkürzte Blockchain hat und ihm alle Adressen mit Guthaben vor diesem Zeitpunkt fehlen?

Nein, da die Unspent Outputs komplett im UTXO Set vorhanden sind und der Hash darüber dann im Header stehen würde.

Praktisch überprüft ein Knoten bei der Verifikation die Transaktionen sowieso nur mit Hilfe des UTXO Set und nicht über die gesammte Blockchain. Die Blockchain wird ausschliesslich für den Bootstrap benötigt. Hat man einen (bereits früher verifizierten) Block-Header mit UTXO Hash, kann man direkt mit mit diesem Block und dem dazu passenden UTXO-Set starten.

[Greshamsches Geld]

Bergmann_Christoph du schreibst in etwa so lasst uns 2 BM einführen, danach werden die Bergleute bestimmt SegWit zulassen.
1. Glaube ich das nicht.
2. Ist das kein Deal. Das ist Verarsche.

[molecular]

@molecular, schön dass du mal vorbeischaust. Wollte dich nämlich fragen, ob für dich als BU-Nodebetreiber eine BIP-100-basierte Lösung akzeptabel wäre.

Da könnten die Miner auch eine Blockgröße wählen, aber in engen Grenzen - der jetzige geupdatete Vorschlag von Jeff Garzik geht von einer 5% Änderung pro Difficulty-Periode aus. Meiner Meinung nach geht das in die richtige Richtung, da dann auf Fehlentwicklungen reagiert werden kann.

Ja, ich glaube schon daß ich damit einverstanden wäre (wobei ich ja als node nicht viel zu husten habe)

Ich hab's mir jetzt nicht im Detail angeschaut, aber im Prinzip coinbase (also miner) voting auf's blocksize limit mit max 5% reduktion/anstieg?

Bitcoin Magazine schrieb 2005 (zum ersten Bip-100):

The intended purpose of BIP 100, as described by Garzik, is to take the power to set the block-size limit away from the Bitcoin developer community and, instead, hand it to the free market.

Diesen Ansatz finde ich gut.

Was ich nicht ganz verstehe, was meinst du mit

Meiner Meinung nach geht das in die richtige Richtung, da dann auf Fehlentwicklungen reagiert werden kann.

Wer reagiert und was ist die Reaktion?

Was ich so ein bisschen schade finde, ist daß die Nodes bei bip-100 selbst garkeinen Einfluss haben (oder?). Bei BU können sie wenigstens noch den Minern ihre Präferenzen kundtun und ein bisschen das orphan-Risiko für ihrer Meinung nach zu große Blöcke erhöhen.

Meinst du denn BIP-100 könnte breit genuge Unterstützung finden? Wärst du persönlich mit sowas einverstanden?