Oops - Post ist etwas lang geworden
Bin auch gespannt - damit steht zumindest mal fest, dass wir mindestens 2 unterschiedliche Bitcoins haben.
Die Zeit ist natürlich extrem knapp, damit auch Light-Wallets entsprechende Software rausbringen können, damit man sicher die entsprechende Chain auswählen kann, oder eine Reorg-Protection hat.
Naja - ist wohl erstmal ein Grund ein BitcoinABC Full Node laufen zu lassen *lol*
Lustig, dass BCC von Bitfinex schon dem Bitcoin Core Split-Token zugesprochen wurde
Welchen Namen das wohl erhält, falls Bitfinex mitzieht
Grundsätzlich find ich das schon in Ordnung. Es gibt zwar keinen technischen Grund vor Segwit Angst zu haben, vor allem, da es Opt-In ist, also niemand einen zwingen kann das zu benutzen, aber der Zeitpunkt ist ungefähr der letztmögliche um einen Fork zu machen, bei dem es kein Segwit gibt.
Ansonsten bin ich eher enttäuscht, dass der Fork nicht bereits viel früher passiert ist, als noch nicht klar war, dass ein Kompromiss (Segwit2x) gefunden wird, der zwar nicht von allen, aber immerhin von vielen getragen wird.
Ist die Frage, ob das den Hard Fork von Segwit2x jetzt gefährdet - zumindest haben wir die Möglichkeit mal zu sehen, wie so ein Bitcoin Hard Fork abläuft und können daraus ggf. noch etwas lernen.
@MoinCoin: Damit ist das UTXO set bis auf weiteres nicht im geringsten ein Problem. Wenn es mal über 10 Gigabyte geht, könnte man darüber nachdenken, ob man es hier lässt, damit auch Smartphones das ganze UTXO problemlos speichern können. Aber da es noch keine dieser Art von Light-Wallet gibt, die auf Basis des UTXO arbeiten, ist die Frage eher theoretisch. Für die bisherigen Nodes und Miner scheint es keine Rolle zu spielen.
Findest du es nicht seltsam, dass das Team Small Blocks immer wieder gesagt hat: "Das UTXO ist der wahre Flachenhals"? Wie überhaupt die wandernden Flaschehälse recht merkwürdig sind ...
Ja die Größe des UTXO ist und bleibt für die nächsten Jahre zumindest für Miner kein Problem.
Nein ich finde es nicht seltsam, weil beide Seiten Fundamentalisten haben, die es mit der Warheit, oder technischen Details nicht so genau nehmen.
Ich bin auch nicht per se ein Small-Blocker, vielleicht wirkt das nur so, weil von den Themen, die mich stören meistens hier nur die Big-Blocker Punkte aufkommen.
Die wandernden Flaschenhälse sind aber auch nicht merkwürdig - das ist normal bei einem technischen System - hat man einen Flaschenhals beseitigt ist etwas anderes der neue Flaschenhals - das ist immer so. Wenn wir lange genug alles andere optimieren, dann wird das UTXO irgendwann automatisch zum größten Flaschenhals.
Und es ist auch immer eine Frage, ob es gerade im Fokus eines Entwicklers ist. Wenn man einen neuen Anwendungszweck, wie die von dir genannten Light-Wallets die auf Basis eines UTXO arbeiten auf einmal als neuen Anwendungszweck erkennt, kann also auch ohne, dass sich sonst etwas technisch verändert hat, ein neuer Flaschenhals entstehen - bzw. er war für den Anwendungszweck zwar immer schon da, aber man hat es vorher einfach übersehen.
Und die Light-Wallets wurden ja auch entwickelt, weil zum Beispiel der benötigte Speicherplatz ein Flaschenhals war.
Am Ende ist eben alles eine Frage der Optimierung und der damit verbundenen Konsequenzen.
Und nochmal zum Thema - Ich sehe mich nicht als Small-Blocker, oder Team Core:
Luke-Jr mit seinen Zensur Bestrebungen und seinem 300kb Hard Fork Vorschlag ist mir zum Beispiel ein Dorn im Auge. Meine Meinung, das ich BIP148 für gefährlich und unnötig halte habe ich ja auch schon oft genug hier gesagt.
Anderer Punkt: Ich finde nicht, dass wir bereits jetzt einen Fee-Market (was für ein dämliches wort, Preis für eine Gebühr hahaha) entwickeln müssen, noch dass es aufgrund der extrem vielen unbekannten Variablen überhaupt einen vernünftigen Fee-Predictor geben kann, der sich nicht selbst schlägt -> Sprich der konstante Backlog von Greg ist meines Erachtens auch keine Voraussetzung, damit das Bitcoin-Mining auch noch funktioniert, wenn der Block-Reward stark abfällt. Es ist aktuell noch kein Problem, es lässt sich bestimmt anders lösen, als mit einem konstanten Backlog -> Zum Beispiel in dem die Auszahlung des Block-Rewards+Fees auf viele Blöcke verteilt wird
Ich bin aber stark der Meinung, dass wir erstmal alle uns zur Verfügung stehenden Technologien nutzen sollten, bevor wir riskante Dinge anpacken und Block Space grundsätzlich ein knappes Gut bleiben sollte, solange wir nicht die Situation mit den Full Nodes in den Griff bekommen, damit die Zentralisierung nicht zu stark wird. Wenn die risikoarmen Lösungen ausgeschöpft sind, wird sich auch unterstützung für Lösungen mit höherem Risiko (inhärentes Chain Split Risiko) finden.
Und wir hatten immer eine bekannte Feste Obergrenze, die fällt ja bei EB / ABC praktisch weg.
Nee. So viele Seiten der Diskussion, und wir landen wieder da. Das ist traurig.
Ja - und ich hab ja mal ausführlich erklärt warum und da warst du glaub ich nicht unbeeindruckt - kann es gerne wieder raussuchen.
Du hast mir erklärt, wie BU schleichend in die Zentralisierung führen kann. Ich war davon ähnlich beeindruckt wie von Peter-Rs Vortrag, wie SegWit schleichend dazu führt, dass Miner keine Signaturen prüfen / speichern. Beides beruht auf ähnlich realistischen / paranoiden Annahmen. Spielt in derselben Liga wie zu sagen, SPV funktioniere nicht ohne Fraud Proofs.
Beeindruckt != Zustimmung.
Wie gesagt: Wir können bei Ethereum, Dash und Monero sehr gut beobachten, wie Emergent Consensus in freier Wildbahn funktioniert.
Abgesehen davon: Mir ging es um deinen Satz, dass BU / Emergent Consensus kein Limit hat. Das ist eben falsch und ich hätte erwartet, dass du es weißt.
Ja es ist auch nur eine Hypothese. Ein bisschen ärgerer ich mich, dass du das mit Peter-Rs Vortrag vergleichst, weil dazu Segwit erstmal geändert werden müsste (Änderung am P2P Layer und Änderung am Consensus-Layer), damit das funktioniert, was er vorgestellt hat, während meine Hypothese, dass es zu einer schleichenden Zentralisierung mit Emergent Consensus auf einfachen Annahmen fußt:
Sobald es genug freie Kapazität vom sichersten Blockspace gibt, steigt über die Zeit auch der Bedarf
Nachdem einmal der initiale Widerstand überwunden wurde das einzuführen, wird es nie wieder Nicht-Miner-Nodes geben, die zusammen genug Widerstand leisten können um eine Anhebung zu blockieren
Für Miner stellt eine ansteigende Blockgröße nur minimalen zusätzlichen Aufwand dar, das heißt, solange sie irgendwelche andere Vorteile haben, werden diese die Blockgröße einfach immer erhöhen
Gerade bei Ethereum war das schon spannend mit dem Account basierten System - Die Exchanges haben ja teilweise die Deposits und Withdrawals während der hohen Last Phase gesperrt - Das kann bei Bitcoin mit dem UTXO basierten Ansatz ja nicht so einfach passieren -> Da setzt sich die höhere Fee automatisch durch.
Hast du übrigens mal geschaut, wie wenig Transaktionen Dash hat? Ich war erstaunt, wie wenig das sind, wo Roger da doch so oft von redet.
https://bitinfocharts.com/comparison/transactions-ltc-dash-xmr.html#3mBis auf Ethereum kommt kein System auch nur annähernd an Bitcoin heran und ist deswegen auch nur schwer vergleichbar.
Wenn wir jetzt 2 verschiedene Bitcoins haben wird es spannend.
Wird spannend, ob die Lager sich jetzt auch technisch gegenseitig angreifen, indem zum Beispiel einfach sinnlose Daten (Transaktionen) in die Blockchain geschrieben werden.
Wer will da noch gegen eine Vergrößerung gegenhalten? Schließlich muss man ja "besser" sein als die andere Chain und immer genug freien Blockspace haben, damit 0-conf einigermaßen funktioniert.
Also falls wir durch Segwit2x keinen klaren Gewinner bekommen gehe ich stark davon aus, dass sich eine Chain auf die Dezentralisierung konzentriert und die andere Chain das Problem der Zentralisierung erstmal ignoriert und das Blockgrößen Limit effektiv abschafft.
Soso. Das System 0-conf und freier Blockspace hat zwar jahrelang gut funktioniert, und du plädierst für ein "weiter so", aber irgendwie jetzt doch nicht ...?
Und wegen der Konkurrenz durch Altcoins gibst du lieber jetzt auf, als es überhaupt zu versuchen?
Ja, weil immer absehbar war, dass es nur ein bisschen mehr freien Block space gibt.
Was meinst du mit aufgeben?
Nur Kontroversen unter Minern machen eine Hard Fork zum Chain Split. Kontroversen ansonsten sind weitgehend egal. Außerdem macht deine Agitation gegen Hardforks hier eine Hardfork unnötig kontrovers. Du trägst also zu dem Problem bei, das du gelöst sehen willst. Etwa so: "An sich bin ich vollkommen einverstanden, allerdings muss ich einverstanden sein, und ich bin nicht einverstanden, weil ich erst einverstanden sein muss." Du machst die Kontroverse zum Selbstzweck.
Nur weil eine Kontroverse unter Minern bei einem Hard Fork einen Chain Split sicher macht, heißt das nicht, dass man das Gegenteil ausschließen kann, wenn sich die Miner einig sind.
Selbst wenn die Miner sich absolut einig sind und 100% Hash Power haben, haben Nutzer und Entwickler jederzeit die Möglichkeit einen neuen Fork aufzumachen, wenn dieser nicht den exakt gleichen Consensus Mechanismus und im Falle von Bitcoin den Double-SHA256 PoW-Algo nutzt, besonders deutlich wird dies bei einem hypothetischen Wechsel auf Proof of Stake.
Siehe hierzu auch
Ich finde auch nicht, dass ein Chain-Split ein Weltuntergang ist - es ist eben die Frage unter welchen Voraussetzungen der stattfindet.
Deine Vorraussetzung hier: Replay Protection.
und
D.h.: Du willst niemals eine Hardfork.
Falsch - Ich will niemals einen Chain Split.
Ich weiß, die Zitate sind etwas aus dem Zusammenhang gerissen. Etwas widersprüchlich wirkt es aber schon, findest du nicht?
Unter der Annahme, dass ein Hardfork niemals 100% Zustimmung finden wird, ist ein Hardfork immer gleichzusetzen mit einem Chainsplit.
D.h.: Du willst niemals einen Hardfork?
Replay Protection, wie sie derzeit diskutiert wird, ist die sicherste Garantie, um eine Chain Split zu provozieren.
Die Argumentation geht jetzt also etwa so:
1. Wenn schon Hardfork, dann mit Replay Protection
2. Keine Hardfork, wenn Chain Split, also: keine Hardfork, da Replay Protection
Brillant!
Du hast schon recht, dass das ein sich selbst schließender Argumentationskreis ist. Ich halte den deswegen aber nicht für falsch und auch nicht für undurchbrechbar.
Segwit2X kommt dem ja schon recht Nahe - hätte man sich mit dem Hard Fork mehr Zeit gelassen, dann würden am Ende wirklich nur noch extreme Fundamentalisten übrig bleiben.
Mein größtes Problem mit Segwit2X ist, dass ich keine Ahnung habe, was nach dem 2MB Hard Fork passiert. Wie ist der weitere Plan? Bzw. was für Eigenschaften von Bitcoin repräsentiert der - welchen Stellenwert hat Dezentralität und Zensur Resistenz.
Wenn man die Core Leute an Bord hätte, hätte ich ein gutes Gefühl, dass es ausreichend diversifizierte Interessengruppen gibt.
Wenn sich das aufspalten sollte, dann könnten am Ende beide Bitcoins nichts für mich sein.
Die Eine Seite, die sich überhaupt nicht um Dezentralität schert und dann ein anderes Bitcoin, was sich zu sehr darauf konzentriert.
Meine Argumentation hast du allerdings nicht korrekt dargestellt, denn es gibt bereits die klassische Replay Protection das über "Taint" zu regeln.
Die ist einfach sehr fehleranfällig für normale Nutzer, weil kompliziert umzusetzen. Und erstmal braucht man neue Bitcoins, also den Taint, damit die Transaktion nur auf einer Kette gültig ist.
Und eine Replay-Protection hat für mich nichts mit der Chain-Split gefahr zu tun - die ist für mich intrinsisch für einen Hard Fork, dank des Status-Quo-Bias.
Niemand kann vorhersagen, wie sich ein Hard-Fork tatsächlich entwickelt und ob es zu einem Chain-Split kommt oder nicht.
Ich halte es einfach für eine sinnvolle Vorsichtsmaßnahme, die leicht umzusetzen ist, wenn ein Hard Fork folgendes bietet:
1. Wipeout-Protection
2. Replay-Protection
3. Reorg-Protection für Light-Wallets, bzw. sichere Auswahl der Blockchain für Light-Wallets
UAHF hat 1+2, 3 fehlt, Segwit2X hat nur 1
Hast du übrigens gewusst, dass Mike Hearn mal mit Get_UTXO es SPV-nodes erlauben wollte, bei Full Nodes die UTXO abzufragen, das aber von Core niedergeschmettert wurde? Mit Get_UTXO wäre es vermutlich gar kein Problem, einen kleinen "21-Millionen-Prüfer" aufs Smartphone zu bringen, der das UTXO aufbaut und alle 20 Min die Peers wechselt, um zu checken, ob es richtig ist ...
Langsam bitte: Core kann nur entscheiden, was in Core kommt.
Und da Get_UTXO nicht den Consensus-Layer betrifft, sondern nur den P2P-Layer kann Core nicht verhindern, dass das in Bitcoin kommt.
Meines Wissens nach hat er das in Bitcoin-XT eingebaut.
Warum haben Bitcoin Unlimited, Bitcoin Classic und BitcoinABC & Co. das nicht übernommen?
Vielleicht ist es doch nicht so toll?
Ich glaube es war nicht nachprüfbar, ob die Nachricht authentisch ist und damit hat es zu keiner Erhöhung der Sicherheit geführt.
Ggf. wurde es auch nicht gemerged, da es DOS Angriffe erleichtert.
Bringt ja sowieso nur was für 0-conf und die Transaktion dürfte man selbst nur erhalten, wenn der UTXO-Eintrag existiert.
Das heißt die Node, die einem die Transaktion geschickt hat könnte man nicht nach dem UTXO Eintrag fragen, denn warum sollte die Node nur einmal die Wahrheit mitteilen und einmal lügen.
Zudem ist das anfällig für MITM Angriffe.
Verbindet sich der SPV Node mit der Blockchain mit der meisten Arbeit? Wenn ja, bräuchtest du einen sehr ausgefuchsten Sybil-Angriff oder müsstest einen gültigen Block fälschen. Beides ist als Angriff zu teuer, um eine echte Gefahr für die Zielgruppe <20k $ Node zu sein.
Ja - Der Angriff ist sehr teuer - aber bei mehreren Bitcoins, wie wir es bald haben werden lohnt er sich unter bestimmten umständen, ohne das der Miner einen Schaden hat, denn er schadet nur der Kette die er bekämpfen will.
Wir wissen leider nicht, wann Bitcoin die Eigenschaften der Dezentralität verliert. Wenn wir das wissen, wird es leider schon zu spät sein. Ist dann die Frage, ob es noch einen Unterschied macht, ob derjenige, der jetzt die Transaktionen kontrolliert "Miner", "Paypal" oder "Bank" heißt.
Wir wissen noch nicht mal, was "Dezentralität" bedeutet. Ist aber vermutlich recht bequem, wenn man das Wort verwenden will, um Behauptungen zu stützen.
Dezentralität bedeutet für mich, dass ich mir keine Sorgen machen muss, dass es irgendeine Partei geben kann, die die Fungibiltät meiner Bitcoins einschränken kann.
Das wenn ich bereit bin eine Gebühr zu bezahlen, die hoch genug ist, mir sicher sein kann, dass meine Transaktion in die Blockchain aufgenommen wird.
Das bedeutet für mich, dass niemand, auch nicht wenn die Regierungen von den USA, EU und China zusammentun genug Druck auf irgendjemand ausüben können, weil es so viele Teilnehmer im Markt gibt, das ein gezieltes Vorgehen gegen einzelne Teilnehmer mittelfristig keine Auswirkungen hat, weil sofort ein anderer Teilnehmer die Aufgaben übernimmt.
Wenn wir nur wenige Full Nodes oder Miner haben, dann wird das System von innen und von außen angreifbar.
Mit Sidechains und Extension-Blocks kann man aber zumindest das relativ gefahrlos austesten, wann wir da an Grenzen stoßen, während die einfache Erhöhung der Blockgröße unumkehrbare Resultate schafft.
Und gleichzeitig haben wir keinen Chain Split.
Sidechains und Extension Blocks sind sehr viel zentralisierter als echte Bitcoin-Transaktionen. Noch bevor die "Dezentralität" ernsthaft in Gefahr ist, wirfst du unnötigerweise einen Großteil der Transaktionen zentralen Akteuren in den Rachen. Brillanter Plan, um die Dezentralität zu retten.
Ist das wirklich so? Also Extension Blocks sind vielleicht zentralisierter als das aktuelle Bitcoin - aber nicht zentralisierter als ein Bitcoin, bei dem die Miner die Regeln bestimmen, oder bei einem Bitcoin mit großen Blöcken. Und selbst bei Sidechains sind es die Miner die für die Sicherheit sorgen.
Wenn man ein Light-Wallet nutzt, hat man keine größere Gefahr.
Für Sicherheit sorgen bei Extension Blocks wie bei normalen Blöcken die Miner und auch alle Full-Nodes, die Extension Blocks unterstützen. Wir verschlechtern uns also nicht und haben dafür noch zusätzlich ein sehr dezentrales normales Bitcoin, auf das man auch mit einfacher Hardware zugreifen kann. Wenn sich zeigen sollte, dass alle die Extension Blocks nutzen und das die Sorgen über Zentralität unbegründet sind, kann man die Extension-Blocks und die normalen Blöcke sogar zusammenführen. Sowas meine ich mit "gefahrlos ausprobieren"
