Bitcoin Classic erscheint – Auftakt der Fork-Wars?
Seit kurzem gibt es Binaries für Bitcoin-Classic. Der alternative Client, der laut seinen Entwicklern Satoshis Vision von Bitcoin verwirklicht, möchte die maximale Größe der Blöcke durch eine Hardfork auf 2 MB erhöhen. Darüber hinaus soll Classic die Bitcoin-Entwicklung etwas mehr demokratisieren.
Letzten Endes ist der Unterschied zwischen Core und Classic minimal und man fragt sich, was das ganze Drama soll. Classic ist ein von den Kernentwicklern Gavin Andresen und Jeff Garzik sowie von Jonathan Toomin entwickeltes Update für Bitcoin Core, das genau ein Detail ändert, um das seit mehr als einem Jahr gestritten wird: die Blockgröße. Classic möchte die maximale Blockgröße von 1 MB auf 2 MB erhöhen und damit den Weg frei machen für weiteres Wachstum.
Seit einigen Tagen sind nun die Binaries der zweiten Beta-Version verfügbar. Die Installation ist wirklich leicht, vor allem, wenn man bereits Core installiert hat. Einfach die Dateien ziehen und Bitcoin starten. Hat bei mir keine fünf Minuten gedauert.
Bitcoin Classic wird gewissermaßen eine Abstimmung unter den Minern starten. Wenn genügend Miner dafür sind, wird Classic eine Hardfork einleiten, um die Blocksize zu erhöhen. Eine Hardfork bedeutet, dass es neue Regeln für Bitcoin gibt. Die Knoten, die nicht nach diesen Regeln handeln, sind dann draußen. Bisher gibt rund 500 Classic-Nodes. Gemeinsam mit den XT und Unlimited Nodes macht die „2 MB Partei“ rund 14 Prozent aller Nodes aus, die rund 6.000 an der Zahl sind. Alle anderen Nodes werden ungültig, sofern es zur Hardfork kommt und sie nicht updaten.
Für das Auslösen der Hardfork ist die Anzahl der Classic-Nodes egal. Das einzige, das zählt, sind die Miner. Wer also jetzt schon Classic laufen lässt, macht nicht mehr, als seine Meinung auszudrücken. Ansonsten ist Classic exakt wie Core 0.11.2. Spannender als Classic sind daher die Clients Core 0.12 (noch beta) und Unlimited. Aber dazu ein andermal. Hier nun die Details zu Classic, so wie sie Gavin Andresen beschrieben hat:
- die Erhöhung der maximalen Blockgröße von 1 MB auf 2 MB. Dies ist eine konsens-kritische Änderung, die erst unter bestimmten Umständen in Kraft tritt: Wenn 750 der letzten 1000 Blöcke eine Zustimmung zu dieser Änderung enthalten haben und eine 28-tägige „Grace Period“ verstrichen ist. Das bedeutet, Classic ist zunächst 100 Prozent kompatibel zum Netzwerk und es kann eine Weile dauern, bis eine Hard Fork ausgelöst wird. Falls überhaupt.
- Neue Limits für sigop und sighashes. Diese beiden Limits adressieren das Problem der „Monster-Transaktionen“: Es ist möglich, riesige Adressen zu schreiben, die so viele und so komplexe Signaturen enthalten, dass die Nodes extrem lange brauchen, um sie zu validieren. Da die Dauer der Validierung exponentiell zur Blockgröße wachsen kann, sind für 2MB Blöcke neue Limits notwendig, um zu verhindern, dass eine Monster-Transaktion reihenweise Nodes ausknockt bzw. in den Limbus der unendlichen Validierung schickt.
Technisch ist Classic weitgehend unkritisch. Die Resultate des zweiten Scaling-Bitcoin-Workshops im Dezember 2015 waren, dass das Netzwerk genügend Kapazität hat, um 2 MB Blöcke zu propagieren und zu verteilen. Dass dies die Core-Entwickler nicht bewegt hat, die Blocksize zu erhöhen, war der Auslöser, der zu Classic geführt und dafür gesorgt hat, dass der Vorstoß massiven Beifall von Bitcoin-Unternehmen und Minern gefunden hat. Nachdem Andresen nun das Problem der „Monster-Transaktionen“ gelöst hat, dürfte Classic eigentlich ein sicheres Update sein, das die Kapazität des Netzwerkes in einem Moment erhöht, in dem 1 MB Blöcke zunehmend voll sind.
Politisch hingegen ist Classic äußerst brisant. Zum einen möchte Classic der Community mehr Einfluss auf die Entwicklung geben. Dazu wurde eine consider.it-Seite eingereichtet, auf der User für das weitere Vorgehen stimmen können. Was genau passiert, hängt zwar weiterhin von den Entwicklern ab, doch die Stimme der User bekommt so eine Form und kann zur Leitlinie werden. Zum zweiten stellt sich Classic gegen Bitcoin Core, also die Implementierung, die die absolute Mehrheit der Bitcoin-Entwickler vereint. Core hat in der Roadmap explizit eine Blocksize-Erhöhung für 2016 ausgeschlossen, was Classic zu einem Votum wirtschaftlicher Akteure (Börsen, Miner) und User gegen die Kernentwickler macht.
Insgesamt ist der Streit viel mehr politisch als technisch, während er von Personen ausgetragen wird, die viel mehr Techniker als Politiker sind. Das ist wohl genauso ungünstig, wie wenn Politiker technische Entscheidungen treffen. So wird aus einer an sich harmlosen Sache ein Richtungsstreit, der das Bitcoin-Netzwerk in einer Hardfork zerteilen kann. Es ist lächerlich, dass Core nicht einfach 2 MB Blöcke akzeptiert, aber es ist genauso lächerlich, dass Classic den Fahrplan von Core verwirft, bevor dieser gescheitert ist.
Klar ist aber, dass mit Classic nun eine Lösung zu einer einfachen und weitgehend risikolosen Kapazitätserhöhung da ist und bereit steht. Classic ist nicht – wie manchmal behauptet – ein Coup oder ein Staatsstreich. Classic ist eher die Erweiterung des Bitcoin-Pateiensystem von einer Partei auf zwei Parteien. Ob es nun zur Hardfork kommt oder nicht – dies ist an sich eine gesunde Entwicklung.
Open-Source wie es lebt!
Man sollte sich endlich mal mit dem Gedanken anfreunden, dass jedes Entwicklungsteam dieser Welt ein eigenes Angebot machen kann und dies nicht zu einem Krieg hochstilisiert werden muss.
Man sollte anerkennen, dass Menschen unterschiedlicher Meinung sind und auch sein dürfen sollen, so entsprechend auch verschiedene Angebote ihre Existenzberechtigung haben.
Und wer weiß, vielleicht kristalisieren sich zwei oder mehrere Bitcoin-Forks heraus, aber auch das wäre kein Beinbruch und erst recht nicht der Untergang des Bitcoin, sondern Resultat aus Meinungsvielfalt und demokratisch bedingtem Kalkül.
Am Ende werden die Verfächter der 1MB Blöcke abwägen müssen, ob ein massiver Wertverlust ihrer Bitcoin es wert ist sich gegen eine Erhöhung zu stemmen oder ob man am Ende nicht kurzerhand 2MB-Blöcke ebenfalls implementiert und quasi die Forks merged.
Die Core Entwickler sind doch garnicht gegen eine Erhöhung der Blockgrösse, sie sind nur gegen eine vorzeitige Hardfork ohne richtigen Konsens.
Auf Dauer kommen auch sie nicht an der Hardfork vorbei und das wissen sie auch (Entwickler haben schon technisches Verständnis) aber dann wird vielleicht 2017 mit vielen neuen Features geforkt, die sich nicht als Softfork implementieren lassen, den Bitcoin aber derart voranbringen, dass eigentlich niemand mehr die alte Chain weiterführen will. (was teilweise schon in Elements Alpha läuft)
Erzwingt Classic aber JETZT den Hardfork, so sind auch die Core Entwickler gezwungen zu handeln und müssen u.a. ein neues Proof-of-Work einbauen um das Core Netz zu schützen. Das heisst die Miner müssen neue Hardware anschaffen. Weiterhin kann man dann gleich neue Features hardforken, was bedeutet dass die paar Classic Entwickler nicht mehr einfach den Code Code von Core übernehmen können.
Das Resultat ist ein Core Coin ohne Miner und ein Classic Coin ohne Entwickler. Wie sich das auf den Kurs auswirkt, kann sich jeder denken.
Es ist einfach nicht sinnvoll wegen jeder Kleinigkeit zu forken, sonst hat man am Ende zehn Bitcoins die alle nur noch Cents wert sind.
Das geht am Open-Source-Gedanken vorbei, denn das Open-Source-Prinzip lebt von einen freien unbestimmten demokratischen Entwicklungsverlauf.
D.h. Jeder Entwickler sollte zu Jeder Zeit das Recht darauf haben eine Fork vorschlagen zu dürfen, so dass zu Jeder Zeit die Anwender (Miner, Händler, Besitzer, Investoren, usw.) selbst entscheiden können ob sie die Fork mitmachen wollen oder nicht.
Denn was bei aller Debatte vergessen wird ist, dass nicht die Entwickler, sondern die Miner und Anwender am Ende entscheiden, u.a. indem sie die Fork mehrheitlich akzeptieren.
Wenn sich nun Classic gegenüber Core durchsetzen würde, müsste sich Core die kritische Frage stellen, weshalb sie mit ihren Plänen die Masse nicht erreichen konnten, weshalb ihre Vorschläge und Ideen nicht dazu geführt haben, dass die Masse Core weiterhin treu geblieben ist und sich eine Alternative durchsetzen konnte.
Ferner stellt sich die Frage, inwieweit das Core-Team überhaupt noch unabhängig agiert, denn nicht wenige der Entwickler arbeiten gegen Entgelt bei Blockstream, ein Projekt welches wiederum selbst durch kommerzielle Partner getrieben wird. Das Projekt Blockstream lebt letztendlich von der Limitierung der Blockgröße, weil dadurch der Druck auf Sidechains weiter erhöht wird, d.h. Blockstream die Sidechains deutlich besser an den Mann bringen kann.
An dieser Stelle sollte man sich schon die Frage stellen, inwieweit das Core-Team überhaupt noch unabhängig agieren kann und inwieweit das Risiko tolerabel ist, denn Blockstream kann ebenso auch technisch scheitern bzw. Probleme offenbaren, welche nicht in Kürze behoben werden können. Das Risiko eines eskalierenden Mempools halte ich für zu hoch als dass man die Blocksize einfach so auf 1MB belassen sollte.
Und diese Ansicht teilt eine deutliche Mehrheit der Bitcoiner, dessen Mehrheit kommt Classic nun faktisch nach. https://bitcoin.consider.it/
Wie soll denn Core das Core-Netzwerk „schützen“ mit einer Proof-Of-Work-Änderung? Eine POW-Änderung erfordert ebenfalls einen Hardfork und würde alte Clients auch ausschließen. Damit die Core-Chain langfristig überleben kann, muss der Hardfork zur gleichen Zeit wie der Classic-Hardfork durchgeführt werden und das „Core-Netzwerk“ müsste vorher auf die neue Version upgraden.
Eine Änderung des POW-Mechanismus würde nur zeigen, dass die Core-Entwickler schlechte Verlierer sind, die sich wie kleine Kinder darüber ärgern, dass man nicht ihrer Meinung ist.
Die großen Miner haben bereits ihre Unterstützung für Classic signalisiert, ebenso wie die Zahlungsanbieter und Walletanbieter. Kaum einer der großen Player würde noch die Core-Chain unterstützen, wenn es zur Hardfork kommt (nicht zuletzt auch dank der höchstumstrittenen Einführung von Replace-By-Fee in Core). Wenn kaum einer den „Core-Coin“ akzeptiert, dann kann sich jeder denken, wie sich das auf dessen Kurs auswirkt.
Was meinen Sie überhaupt mit richtigem Konsens? Bitcoin ist eine Konsensus-Machine. Wenn es zur Hardfork kommt, dann wurde Konsens über die neuen Regeln des Bitcoin erreicht.
Hinter Classic stehen schon jetzt gute Entwickler. Falls Core scheitert, so würde sich denke ich kaum ein Core-Entwickler von der Bitcoin-Entwicklung verabschieden, sondern am „neuen“ Bitcoin mitarbeiten.
dito!
@Aononym Full ACK.
„Einfach die Dateien ziehen und Bitcoin starten. Hat bei mir keine fünf Minuten gedauert.“
ignoriert ja völlig die politische Dimension dessen.
Der Artikel ist leider stark einseitig und informiert nicht richtig. Das musst du dir eingestehen.
Z.B. was soll bedeuten:
„Wenn 750 der letzten 1000 Blöcke eine Zustimmung zu dieser Änderung enthalten haben und eine 28-tägige “Grace Period” verstrichen ist. … bis eine Hard Fork ausgelöst wird. Falls überhaupt.“
Wann ist „Falls überhaupt“?
Letztes mal gab es eine Frist.
Was ist in wenn in der „Grace Period“ die „letzten 750 von 1000 wieder unterschritten wird?
Gute Frage. Eine von tausenden Fragen, die man angesichts des Themas stellen kann. Leider ist jede Art von Erklärung / Einordnung mit Meinung verbunden und auf irgendeine Weise einseitig. ich versuche das hier zu vermeiden aber es gelingt mir nicht immer. Umso wichtiger ist eine ausgewogene Diskussion in den Kommentaren.
p.s. was wird aus den Bitcoin auf Bitcoin.de? Das sind Bitcoin. Werden die mit den ClassicCoin vermischt?
Hallo Gast,
im Falle einer Fork werden lediglich die frisch erzeugten Coins gemischt. Ehrlich ausgeführte Transaktionen kommen in beiden Chains an (wenn auch in anderen Blöcken und zu anderen Zeiten). Um zu verhindern, einseitig erzeugte frische Coins unterzumischen oder double spends aufzusitzen. sollte es ausreichen, beide Chains zu beobachten. Aber das ist nur meine persönliche Meinung.
Es steht ja jedem frei, einen Fork zu machen, nur hat man dann halt einen Altcoin. Welches dann der „neue Bitcoin“ ist, ist reine Ansichtssache, beide Coins sind oder waren mal Bitcoin.
Wenn Classic mit der mehrheitlichen Hashpower forkt, gibt es für Core drei Möglichkeiten:
1. Weitermachen wie bisher. Dann gibt es aber mit Classic ein Netz was jederzeit einen 51% Angriff durchführen kann. Dies wäre nicht vertretbar.
2. Ebenfalls auf 2 MB gehen und so die Forks wieder vereinigen. Durchaus eine Möglichkeit, sofern die Entwickler der Meinung sind, dass 2 MB + SegWit technisch sinnvoll ist. Der Schaden durch die Hardfork ist ja dann bereits entstanden. Aber auch diese Lösung
kann zu ungeahnten Problemen führen.
3. PoW ändern und jede Menge neue Features hardforken. Dann gibt es sogar 3 Bitcoins wobei man nicht weiss, ob der jetzige weitergeführt wird. Somit können die Classic Entwickler nicht mehr einfach die Features von Core übernehmen sondern müssen
selbst Innovationen hervorbringen, wofür wohl die Personalstärke viel zu gering ist.
Ich denke aber, dass Classic garnicht erst forken wird bzw. sie erst dann den nötigen Zuspruch bekommen, wenn im jetzigen Bitcoin z.B. wegen Überlast „nichts mehr geht“. In einem solchen Fall hätte aber auch sicher Core irgendein Notfallprogramm.
Hier kann ich nur zustimmen. Vor allem diesem Satz
Vielleicht noch mit der Anmerkung, dass im Falle einer Überlast zunächst zu klären sein wird, ob die vielen Transaktionen berechtigt sind oder Spam. Es gibt keine wirkliche Methode, das rauszufinden, aber wenn Sie eine Verschwörungstheorie wollen, schauen Sie sich mal den Verlauf der Anzahl der Transaktionen und das Transaktionsvolumen seit Anfang dieses Jahres an (auf blockchain.info).
Dass es zu einer PoW-Änderung kommt glaube ich nicht.
Von aussen kann man Transaktionen leider weder als Spam erkennen noch einordnen. Lediglich subjektiv kann man sagen, die Transaktion ist dann sinnvoll, wenn sie mir einen grösseren Vorteil bietet, als die Gebühr, die ich bezahle.
„Spammer“ zahlen also drauf und werden dies nicht dauerhaft durchhalten (wollen). In dieser Definition kann natürlich auch ein Satoshi Dice ähnliches Glücksspiel als Spam definiert werden.
Letztendlich führt dies zu zwingend steigenden Gebühren, die natürlich keiner gerne sieht. Aber selbst wenn sich die Gebühren verdoppeln oder vervierfachen liegt man immer noch im Centbereich bei den aktuellen Kursen. Sinnvollerweise sollte man halt die Transaktionen manuell mit Coincontrol auswählen. Hier ist ja AFAIK auch ein besseres automatisches Auswahlverfahren in Entwicklung.
Der 51%-Angriff erscheint unwahrscheinlich, wie man bei Altcoins sehen kann, welche ja ebenfalls permanent dieser Gefahr ausgesetzt sind.
Gibt auch gar keinen Grund für einen 51%igen Angriff, weil der Wert des Core-Bitcoin deutlich fallen würde.
————————–
„Ich denke aber, dass Classic garnicht erst forken wird bzw. sie erst dann den nötigen Zuspruch bekommen, wenn im jetzigen Bitcoin z.B. wegen Überlast “nichts mehr geht”. In einem solchen Fall hätte aber auch sicher Core irgendein Notfallprogramm.“
So wie Core sich bislang nach Außen präsentiert hat, ist stark anzuzweifeln, dass sie tatsächlich einen Notfallplan haben. Ausgehend von den steigenden Tx ist davon auszugehen, dass die Sache eskalliert, lange bevor die Lösungen von Core implementiert sind.
Das Notfallprogramm könnte z.B. einfach der Fork auf 2 MB sein, wie Classic ihn will. Der Unterschied ist nur, dass Core damit so lange wie möglich warten will. Als technisch möglich wurde er auch von den Core Entwicklern eingestuft. Dagegen spricht nur das Risiko, das ein Hardfork mit sich bringt. Aber in Notfällen ist man sicher bereit, dies einzugehen.
Und wenn dann die Notfallsituation eintritt (wenn sie nicht schon längst da ist, da die Blöcke bereits jetzt an ihrer Kapazitätsgrenze sind), was macht dann das Notfallprogramm besser, als jetzt zu forken? Momentan kann man sich gut auf den Fork vorbereiten, da noch genügend Zeit ist, bis es zum Fork kommt.
Wenn Core in einer Notfallsituation hektisch forkt, wie soll sich das Bitcoin-Ökosystem darauf vorbereiten?
Mal ganz davon abgesehen, dass sich der Gebührenmarkt in so einem Fall katastrophal ändern wird. (Bei vollen Blöcken – hohe Gebühren; dann irgendwann Fork auf höheres Blockgrößenlimit –> Platz wird frei in den Blöcken –> Gebührenmarkt bricht zusammen). Wie soll das besser sein als ein geplanter Fork jetzt?
Hallo Jan,
die Notsituation bedeutet ja nicht, dass plötzlich alles kaputtgeht. Eher dass es einen heftigen Stau gibt. Der Code für eine Hardfork liegt mit Classic jetzt ja vor und kann prinzipiell in Stunden übernommen werden. Wenn der Druck durch den Notfall stark genug ist, wird sich keiner gegen die HF sträuben, was sie harmlos macht.
Dass Core jetzt, wie derzeit diskutiert, daran arbeitet, eine Hardfork sicherer zu machen, gibt auch Hoffnung.
Letzten Endes bin ich gerade optimistisch, dass es, so oder so, gut gehen wird.
Hallo Christoph,
ich hab ja auch nicht behauptet, dass alles kaputt geht 😉
Wie gesagt, dass Problem ist der Gebührenmarkt. Sobald Druck aus dem System in Form einer Blockgrößenlimiterhöhung (was für ein Wort :D) genommen wird, bricht dieser sofort zusammen. Es ist nicht klar, ab wann für Core der Druck zu groß wird (also bis wohin die Gebühren steigen müssen), bevor sie handeln. Für viele Teilnehmer des Bitcoinsystems ist es aber wichtig zu wissen, wie sich der Gebührenmarkt entwickeln wird, um dies in ihren finanziellen Planungen zu berücksichtigen (also insbesondere für Unternehmen).
Ganz zu schweigen davon, dass hohe Gebühren natürlich viele Teilnehmer und Anwendung aus dem Markt drängen und auspreisen werden (solange es keine funktionalen Alternativen wie das Lightning-Netzwerk gibt – was aber immernoch in weiter Ferne ist).
Einen Hardfork innerhalb von ein paar Stunden durchzuziehen wäre zudem katastrophal. Der Code muss getestet werden, der Code anderer darauf aufbauender Programme muss geändert werden und dann wiederum getestet werden. Das in wenigen Stunden durchzuziehen ist einfach nicht machbar. Vielleicht können Miner innerhalb des Zeitraums schnell upgraden, aber der Großteil der Full-Nodes wird das nicht machen können und schon hat man den Großteil des Bitcoin-Netzwerks rausgekickt. (Vielleicht hab ich dich aber auch missverstanden, und du meinst wirklich nur die Codeübernahme in Core und einen geplanten Hardfork dann Wochen später – womit dann aber natürlich auch die Notsituation über Wochen bestehen bleiben wird).
Man sollte den Stau einfach schon von vornherein vermeiden. Ein Stau ist nie schön und einfach nicht kalkulierbar.
PS: schlechter Autovergleich: Core rast gerade mit voller Geschwindigkeit auf ein Stauende zu und meint, in Zukunft wird es Lösungen für den Stau geben (jeder fliegt dann nur noch oder so und nur wichtige Dinge werden auf Autobahnen transportiert). Dass sie aber vorher auf das Stauende prallen und enormen Schaden verursachen werden, ist ihnen egal.
Classic/XT dagegen möchte die Autobahn um weitere Spuren erweitern, bevor ein Stau überhaupt entsteht.
Ja.
Allerdings … ich versuche gerade, auf einem Laptop einen Node zu installieren und die Blockchain zu laden. Bin mittlerweile irgendwann im Jahr 2015 angekommen. Aber da die Blöcke immer größer werden, schafft mein Laptop mittlerweile am Tag kaum mehr als 2 Wochen. d.h. ich werde noch einige Wochen dransitzen. Wenn wir 2 MB Blöcke haben (oder gar 4 MB) und die auch noch voll sind, wird es so gut wie unmöglich, einen Node neu aufzusetzen.
Ich glaube, das ist ein sehr großes Problem, um das man sich unbedingt kümmern muss.
Was das in deinem Bild bedeutet, weiß ich nicht genau. Vielleicht dass die Straßenbauarbeiter eh schon auf Monate ausgebucht sind und dass die Ausbildung neuer Straßenbaufachkräfte sich mit den neuen Spuren verlängert – nein, ziemlicher Quatsch 🙂
„Es ist nicht klar, ab wann für Core der Druck zu groß wird (also bis wohin die Gebühren steigen müssen), bevor sie handeln.“
Genau darin liegt der Hund begraben, es gibt seitens Core keinen Fahrplan und dies ist aus Sicht eines Anwenders und Unternehmens äußerst ungünstig und stellt vielmehr die Kompetenz oder den Willen des Core-Teams in Frage.
Btw. nochmals sei erwähnt, hängt ein nicht kleiner Teil des Teams mittlerweile am Faden des Kommerzes a la Blockstream, so dass auch aus diesem Hintergrund die Unabhängigkeit mittlerweile eine fragwürdiges Niveau erreicht hat.
Hallo Christoph,
dein Notebook ist zu langsam 😀 …
Sicher, wenn man eine Fullnode betreiben will, dann kann das schonmal ne Weile dauern, bis diese vollständig synchronisiert ist. Ich betreibe seit Mitte letzten Jahres eine Node auf einem Raspberry Pi 2. Wie lange der initiale Synch gedauert hat, kann ich nicht mehr sagen (sicher auch um die 2 Wochen). Aber nach der Synchronisation ist die Last doch relativ gering.
Aber ganz davon abgesehen war es nie in Satoshis Sinn, dass jeder eine Fullnode betreibt – das hat er ausdrücklich gesagt („The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate.“ https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 – das war am 29.07.2010). Wieso möchte man Bitcoin zu etwas machen, was Satoshi und die early adopters so nie geplant hatten?
Der Großteil der Nutzer hat schon heute kein Interesse daran, eine Fullnode zu betreiben, weil es für sie bessere Alternativen gibt. Wenn man aber trotzdem eine Node betreiben will, so ist das abgesehen vom initialen Synch aber weiterhin kein Problem (man braucht nur Geduld).
In Zukunft kann ich mir vorstellen, dass man (manuell) Checkpoint-Blöcke bestimmt, ab welchen dann die Validierung startet.
PS: schön, dass du auch auf /r/btc unterwegs bist 😉
ich bin überall 🙂
Ja, mein alter Laptop ist auf jeden Fall zu langsam für eine Full Node. Ich wollte Core 0.12 mit Pruning probieren, aber dabei nicht risikoeren, meine andere Node kaputtzumachen. Ich bin gespannt, wie sich der Laptop macht, wenn die Synchronisierung abgeschlossen ist. Mein PC leidet prinzipiell gar nicht unter der Node.
Die andere Frage die du ansprichst: Wie viele Nodes brauchen wir, um dezentral zu sein? Eines der Probleme mit den alten Aussagen von Satoshi war, dass er kein Pool-Mining vorausgesehen hat (und ich glaube auch keine Asics.) D.h. Satoshi ging davon aus, dass jeder Node durchs Mining belohnt wird. Die Wirklichkeit ist aber, dass Miner keine Node betreiben, sondern lediglich hashes an die Pools schicken. Das andere ist, dass selbst Börsen nicht zwingend eine Node brauchen, sondern das über die API eines Supernodes machen können. D.h. es wäre möglich, dass wir in einer Situation landen, in der es nur noch 10-12 Nodes gibt, die auf 3-4 Länder verteilt sind.
Aber, nächster Punkt: Ja, man bräuchte dringend einen Ansatz, um das Syncen zu vereinfachen. Ist es wirklich notwendig, dass mein Laptop jede Transaktion von 2010 validiert?
Satoshi hat ASICs vorausgesehen und sogar pooled mining. Siehe dazu folgenden Blog: http://webonanza.com/2015/10/02/did-satoshi-predict-pooled-mining-big-farms-and-asics/
Er mag das ganze nicht ASICs oder Pools genannt haben, aber ich denke, es ist relativ eindeutig, dass er dieses mit seinen Aussagen gemeint hat.
Die Diskussion mit der Anzahl der Nodes hatten wir ja schon einmal. Ich denke, dass es in Zukunft zwar weniger Nodes geben wird, aber dass gleichzeitig der Anreiz steigt eine Node zu betreiben, wenn Bitcoin im Mainstream ankommt. Es wird irgendwann Banken geben, die Bitcoins verleihen werden. Diese werden auf jeden Fall Nodes betreiben. Unternehmen könnten Nodes betreiben und den Zugang zu den APIs lizensieren. Letztendlich läuft wieder alles auf die Frage hinaus, wie viele Nodes braucht das Netzwerk um sicher zu sein – Ich denke, deutlich weniger als heute.
Es gibt doch einen Fahrplan von Core, der stand sogar hier im Bitcoinblog.
Feb 2016 libsecp256k1 (Geschwindigkeitsgewinn für alle Full Nodes)
Apr 2016 SegWit (entspricht ca. 1.6 MB Blocks)
danach IBLT oder weak blocks.
Mittelfristig Payment Channel / Lightning Network
Dagegen Classic:
Hard fork auf 2MB irgendwann(!) vermutlich lange nach April 2016. Und danach???
Hmm, ja, der Fahrplan von Core ist auf jeden Fall wichtig (auch wenn man über die langfristigen Vorteile streiten kann). Das Problem ist imho dass in der Sache, um die es derzeit geht – die Kapazitätserhöhung – Classic mehr bietet. Aber ich glaube, wir haben eine Lösung: Core macht weiter, und wenn es nicht reicht, forkt Classic und erzwingt ein Upgrade auf 2 MB. Wird ein wenig chaotisch, eventuell gibt es einige Wochen Stau. Aber ein unlösbares Problem oder eine echte Gefahr sieht anders aus.
Ja, Core hat einen Fahrplan, aber was nützt der, wenn er die aktuellen Problem nicht zeitnah löst? Jeder mag SegWit, jeder mag libsecp256k1, viele unterstützen die Idee der weak blocks und IBLT und viele erkennen auch das Potential von LN (auch wenn da noch viele grundsätzliche Probleme vorliegen (die dezentrale Routenfindung zum Beispiel)). Diese Dinge sind alle grundsätzlich gut und notwendig. Die meisten sind aber noch weit von einer Realisierung entfernt und lösen das jetzige Problem nicht (bzw. verschaffen nur geringfügige Besserung).