Strategien zum kommenden Bitcoin-Fork (ab Januar 2016)

[bluetowel]

Wäre es nicht möglich auch eine dynamische Blocksize zu programmieren? So wie die Difficulty immer angepasst wird. So könnte das Netzwerk, wenn es merkt dass das Transaktionsvolumen steigt, die Blocksize anheben bis das Transaktionsvolumen in die Blockkette eingeflossen ist. Um dann wieder runter zugehen mit der Blocksize. Und da stelle ich mir eine konservative, langsame dynamische Erhöhung vor.

[mezzomix]

Was haltet ihr davon eine Petition gegen die Core-Developer zu schreiben, die BIP 101 in den Core auf zu nehmen.

Weil einen Split will doch eigentlich keiner.

Wie wäre es, wenn ihr eine Petition schreibt, damit die Core Entwickler den mezzomix Fork in den Core Client aufnehmen.

Weil einen Split will doch eigentlich keiner.

Mann, mann, mann...  

[e-coinomist]

Schön da mal eine Übersicht zu haben:

Um die verschiedenen Vorschläge mal kurz zu charakterisieren:

BIP 100 (Jeff Garzik)
1. hard fork
2. dynamische Anpassung der blocksize
3. Beibehaltung der historischen Grenze von maximal 32 MB
4. wenn diese 32 MB erreicht werden und weiterhin Bedarf für größere blocks besteht -> erneuter hard fork

BIP 101 (Gavin Andresen)
1. hard fork
2. 8 MB limit, Verdoppelung alle zwei Jahre
3. das würde z.B. bedeuten, in ca. 10 Jahren würden heutige DSL-Leitungen nicht mehr ausreichen, um einen Full Node zu betreiben
4. Stellt man fest, dass man eine erneute Beschränkung der blocksize braucht, weil es zu groß wird, reicht ein -> soft fork

BIP "102" (Jeff Garzik)
1. hard fork
2. 2 MB limit
3. reicht dieses 2 MB limit nicht mehr -> erneuter hard fork
(BIP "102" scheint mir eher eine Trotzreaktion gewesen zu sein anstatt ein konstruktiver Vorschlag)

BIP "103" (Pieter Wuille)
1. hard fork
2. 4.4% Erhöhung der blocksize spätestens alle 100 Tage oder so, maximal 17.7% Erhöhung pro Jahr
3. Maximal ca. 2 GB im Jahr 2063
BIP "103" ist sehr konservativ und vorsichtig, aber es dürfte klar sein, dass damit auf absehbare Zeit eben auch nicht viel gewonnen ist.
Das bedeutet, sollte sich in den nächsten ein, zwei, drei Jahren herausstellen, dass tatsächlich ein bisschen mehr Transaktionen benötigt werden, führt uns auch BIP "103" zu einem -> erneuten hard fork

...

Schließlich und endlich noch der Verweis auf die mittlerweile historische Hardfork Wishlist. Diese sieht tatsächlich noch satoshis Hotfix einer simplen Änderung vor. Also blocksize=10MB oder 20MB oder was auch immer Dem kommt natürlich BIP "102" am nächsten. Kann aber natürlich ernsthaft keiner mehr wollen.

Da wäre noch Lightning protocol https://lightning.network/

[Queenvio]

Ich denke mal die "Angst" die viele Developer haben, ist der hard fork.


Weil dann jede Node updaten müsste.  Aber ich sehe da auch keine alternative im moment.

Gabs eigentlich schon mal einen hard fork in der Core geschichte

[Legov]

Nicht den BIP101 aufnehmen! Nur die Änderung der max. Blocksize. Auf 2...4 MB statisch.

Warum wieder statisch auf einen festen Wert festlegen? Damit mit man alle Jahre wieder die gleiche Diskussion hat?

Ich finde die Devs sollten sich einfach zusammensetzen bis sie einen Kompromiss ausgearbeitet haben. Man kann nicht als ,,Team'' etwas zum Erfolg führen, wenn jeder stur bei seiner Meinung bleibt. Teamwork und so... Diese anscheinend fehlende soziale Kompetenz der Devs macht mir bei der ganzen Sache am meisten Sorgen...

Frage: Warum haben wir denn diese Diskussion?
Antwort: Weil es aktuell keinen Konsens über die Notwendigkeit der Änderung gibt. Also braucht man die Änderung nicht wirklich. Auch wenn uns das einige mächtige Interessengruppen mit ihren Spammern (ich meine: Stress-Testern) suggerieren wollen.

Wenn es alle paar Jahre eine Notwendigkeit zur Änderung gibt, dann gibt es auch einen Konsens. Und eine Änderung. Mit hard fork.
Was ist so schlimm am hard fork? Der letzte für BIP66 ist erst ein paar Wochen her und alle haben mitgezogen. Weil es eben vorher einen Konsens gab. Für BIP101 gibt es keine Notwendigkeit. Also gibt es dafür keinen Konsens.

Den fehlenden menschlichen Konsens durch einen Maschinen-Konsens erzwingen zu wollen - das führt uns wieder auf das Thema der sozialen Kompetenz der Devs...

[Greshamsches Geld]

Die allgemeine Verunsicherung finde ich nicht gut.
Wenn jetzt aber nichts passiert ...- also BIP101 unter 75% und keine Einigung - ... bleibt die Unsicherheit latent im Raum.

Weiterhin bleibt für  mich die Frage, wird es durch BIP101 mehr als 21 Millionen Bitcoin geben?!?

P.s.  6-Monatstief erreicht.

[deadlock1]

Man muss sich mal vorstellen, wieviel größer das Problem erst bald bei Ethereum sein wird.

Da explodiert die Blockchain geradezu! Alle 12 Sekunden ein Block und man kann auch noch richtig viel Coding hinterlegen.  

Gut, das wird vorläufig nicht ins Gewicht fallen, aber irgendwann wird sich das sicher rächen.


Beim Bitcoin Core wäre ich für 4 MB statisch oder für BIP102 (2 MB). Das Netzwerk wächst nicht exponentiell, daher kann es ruhig statisch sein. Ich teile Mezzomix' These, dass ein exponentieller Größenanwachs langfristig verheerend wäre. Nur, wer denkt sooo langfristig? 5 Jahre sind in der Cryptowelt schon eine halbe Ewigkeit!

[bluetowel]

Ich finde die Devs sollten sich einfach zusammensetzen bis sie einen Kompromiss ausgearbeitet haben. Man kann nicht als ,,Team'' etwas zum Erfolg führen, wenn jeder stur bei seiner Meinung bleibt. Teamwork und so... Diese anscheinend fehlende soziale Kompetenz der Devs macht mir bei der ganzen Sache am meisten Sorgen...

Die Devs sollten sich besinnen, und es wie die verdammten Politker machen: Einen Kompromiss! , bei dem jedem Beteiligten klar sein muss, dass niemand am Ende das bekommt was er wollte. Aber Alle bekommen etwas womit man leben kann.

Da müsste sich THEORETISCH sowieso einiges tun. Wenn man sich in der Gesellschaft umguckt: alle Vereinigungen der unterschiedlichsten Art, sei es einfache Vereine oder Stiftungen, Institute, Freie Unis, Gesellschaften aller Art ob kommerziell oder nicht, NGO's, Fussballclubs, Gewerkschaften, Lobbyverbände, AktienG's und so weiter. Also überall gibt es Leute die die Führer sind, an der Spitze stehen "das Amt inne haben". Und überalle gibt es auch eine Art "Gremium" diese zu überwachen und notfalls zu kippen. Irgendwie fehlt das bei Bitcoin.

Das kann man sich in der THEORIE vielfach vorstellen: Die BitcoinFoundation müsste ein Gremium schaffen welches die Macht hat (alles demokratisch natürlich, je Mehr mitmachen desto besser) auf die DEV Gruppe Einfluss zu nehmen oder auch einzelne zu kippen oder rein zu holen. Man wird dann nicht mehr einfach DEV weil man das KnowHow hat, sondern man wird vom Gremium gewählt. Oder die DEVs selbst schaffen eine Art Kodex, ein Regelwerk, dass im Streitfall den Konsenz wieder herstellt, demokratische Regeln halt. Die DEVs könnten Wahlverfahren etablieren, oder Vermittler bestellen die neutral von der Foundation kommen.

Das sind nur flüchtige Gedanken, aber bei Bitcoin war ja schon immer alles neu&anders nicht wahr?!!

[neogen1]

momentan nutzen ca 15% der nodes xt http://xtnodes.com/
hoffe das mehrere das boykottieren, durch diese debatte rauscht der kurs in den keller

[e-coinomist]

Das kann man sich in der THEORIE vielfach vorstellen: Die BitcoinFoundation müsste ein Gremium schaffen welches die Macht hat (alles demokratisch natürlich, je Mehr mitmachen desto besser) auf die DEV Gruppe Einfluss zu nehmen oder auch einzelne zu kippen oder rein zu holen. Man wird dann nicht mehr einfach DEV weil man das KnowHow hat, sondern man wird vom Gremium gewählt. Oder die DEVs selbst schaffen eine Art Kodex, ein Regelwerk, dass im Streitfall den Konsenz wieder herstellt, demokratische Regeln halt. Die DEVs könnten Wahlverfahren etablieren, oder Vermittler bestellen die neutral von der Foundation kommen.

Das sind nur flüchtige Gedanken, aber bei Bitcoin war ja schon immer alles neu&anders nicht wahr?!!

Ein Wahlapparat auf der Foundation Webseite, wo jede BTC Adresse eine signierte Stimme abgeben kann. Adressen die > 1 BTC seit > 4 Wochen halten. Abstimmung über Vorschläge die von einer Arbeitsgruppe erstellt wurden. (geht leider nicht pro Kopf oder pro Wallet wegen virtueller machines, multiple Persönlichkeiten)

Erst Brainstormen, dann Auswählen, dann Abstimmen, Und Erst Dann Halt Etwas Als Programcode Entwerfen, diese Reihenfolge ist da wichtig.

[BTCynic]

Weiterhin bleibt für  mich die Frage, wird es durch BIP101 mehr als 21 Millionen Bitcoin geben?!?

Ich glaube nicht, dass es mehr Bitcoin geben wird.
Nach dem Fork wird es höchstens einen Streit um die Namensrechte geben. Wer darf sich dann "Bitcoin" nennen?!
Der Verlierer wird jedenfalls danach kein Bitcoin, sondern sowas wie ein AltCoin sein.

Aber ruhig, Brauner.
Bisher gibt es gerade mal 4 BIP101-Blöcke.
"(only) one BIP101-Block a day keeps BitcoinXT away"
hey hey hey

[OhShei8e]

Ich glaube nicht, dass es mehr Bitcoin geben wird.
Nach dem Fork wird es höchstens einen Streit um die Namensrechte geben. Wer darf sich dann "Bitcoin" nennen?!

Die Namensrechte lagen zuletzt bei Tibanne und gehören jetzt mit zur Konkursmasse der insolventen Firma.

[Greshamsches Geld]

http://xtnodes.com 40%
Die Anzahl der XTnodes ist in die Höhe geschossen, aber nicht die Anzahl der corenodes im gleichen Verhältnis gesunken.
Da stimmt etwas nicht! Ich weiß  nicht ob ich mal etwas von virtuellen Servern gelesen hatte die letzten Tage.

[chrismaster]

http://xtnodes.com 40%
Die Anzahl der XTnodes ist in die Höhe geschossen, aber nicht die Anzahl der corenodes im gleichen Verhältnis gesunken.
Da stimmt etwas nicht! Ich weiß  nicht ob ich mal etwas von virtuellen Servern gelesen hatte die letzten Tage.

für mich sieht das wirklich extrem nach Manipulation aus.
Und genau aus diesem Grund werde ich XT wieder runterschmeisen.

Auch wenn XT Vorteile hat zwecks Blockgröße, aber diese Manipulation sollte man nicht unterstützen.

[Greshamsches Geld]

Sollte da ein falscher Block eingebaut werden? http://xtnodes.com/xt_blocks.php

[chrismaster]

Sollte da ein falscher Block eingebaut werden? http://xtnodes.com/xt_blocks.php

das stinkt bis zum Himmel

[deadlock1]

Ich habe den Block noch nicht überprüft! Kann den Link auch irgendwie nicht interpretieren.

Hieße das, wenn es Abweichungen gibt, dass es schon jetzt 2 verschiedene Blockchains gibt? Bei 2 Clients durchaus vorstellbar. Das wäre in der Tat sehr interessant, so rein vom spekulativen Aspekt her gesehen!

"Alte Bitcoins" wären dann wertvoller als neue, weil die alten in beiden Blockchains auftauchen.


Sorry, falls meine Frage blöd ist. In dem Fall möchte ich mich im voraus entschuldigen, aber ich habe momentan nicht so viel Zeit, XT immer im Auge zu behalten.

[deadlock1]

Um die Fragen noch einmal neu zu formulieren:

- Ist es möglich, dass es zufällig durch unvorhersehbare Abweichungen im Bitcoin XT (bzw. auch Manipulation?) vorzeitig zu einer Fork kommt (d.h. bereits vor dem 11. Januar 2016) ??

- Wie wahrscheinlich ist dieses Szenario?

- Wie kann man das am besten feststellen, ob die Blockchains noch übereinstimmen?

[yxt]

Hier ist eine schöne Übersicht wie sich die großen Pools positioniert haben:
https://bitcoinmagazine.com/21699/major-mining-pools-make-stand-bitcoin-xt-fork-support-bip-100-grows/

persönlich lehne ich BIP101 ab und tendiere ebenfalls zu BIP100

[nrg1zer]

Den Topic Titel finde ich auch verwirrend. Suggeriert, dass es fix ist mit der Forke.