Bitcoin Core vs. Bitcoin XT

[deadlock1]

Plan B ist, jetzt nochmal ein paar Monate rumzudiskutieren, bis es dem nächsten Developer reicht und er seinen Hut nimmt, auf die eine oder andere Art und Weise. Dann der nächste und wieder der nächste. So lange, bis nur noch ein Core-Developer übrig ist, und der legt das dann fest.

+1


Pruust... jetzt hab ich fast Kaffee über meine Tastatur geschüttet.

[fronti]

Wo bleibt nun der Plan B, um die Blockgröße im Core zu erhöhen? So etwas muss rechtzeitig angekündigt werden, damit die Poolbetreiber, Exchanges und Payment-Prozessoren umstellen können!

Plan B ist, jetzt nochmal ein paar Monate rumzudiskutieren, bis es dem nächsten Developer reicht und er seinen Hut nimmt, auf die eine oder andere Art und Weise. Dann der nächste und wieder der nächste. So lange, bis nur noch ein Core-Developer übrig ist, und der legt das dann fest.

ein "core Developer" (oder soll man Gott sagen) kann nix von sich aus festlegen.
Das machen immer noch die, hoffentlich mündigen und nachdenkenden Benutzer.
Wenn es nur einen gibt der an diesem einen Client names Bitcoin-Core rumdoktort oder schreibt und dann da sachen Implementiert, ist doch gut.
Man kann ja immer noch andere Clients nehmen oder eine alte Version..

Es geht ja auch um mehr als einen Client.

Das Problem ist, dass man ein Verfahren finden muss, Bitcoin unabhängig von der Referenzimplementation zu machen, dann kann ein Entwickler machen was er will.
Dann kann ein anderer Client sagen, nicht kompatiblel weil in XXX steht YYY -> den block werf ich weg.

man stelle sich mal vor, es gäbe nur einen Stack an TCP implementierungen oder bei Webservern muss sich alles nach dem Apache richten..

Klar bei Bitcoin gehts um Geld, es muss genau überlegt werden, wie man die Blockchain aufbaut/erweitert/verändert/verwaltet das ist komplizierter (evtl) als HTTP zu implementieren.

Daher sehe ich das Bitcoin Projekt mit der Fokusiereung auf den Bitcoin Core kritisch.
Wenn ganz am Anfang (wir sind ja eigentlich noch am Anfang (hoffentlich)) sich die Implementierungen verteilen, es mehr als
Bitocin Core
Btcd
bitcoinj
(und die die ich vergessen habe)
Ich glaube, dann würde die Diskussion auch anders laufen.

Und jetzt fällt eben auf, dass ein Consens findungsmechanismus, schon angelegt im Protokoll, so eben noch? nicht existiert.
Das ist meiner ansicht nach etwas was Satoshi nicht vorhergesehen hat...

so, just my 2cents..

[deadlock1]

Wenn es nur einen gibt der an diesem einen Client names Bitcoin-Core rumdoktort oder schreibt und dann da sachen Implementiert, ist doch gut.
Man kann ja immer noch andere Clients nehmen oder eine alte Version..

Klar könnte man. Es kann dann aber sein, dass sich mangels Inkompatibilität 2 verschiedene Blockchains bilden und du in der unbeliebten bist und keiner deine Coins will.

Ich arbeite übrigens mit eine alten Core Version (hieß damals noch Bitcoin QT... hach dieses Nostalgie!!), selbst compiliert Ende 2013, läuft immer noch gut.  

Bin ich der einzige, der noch mit QT arbeitet??? 

Das Problem ist, dass man ein Verfahren finden muss, Bitcoin unabhängig von der Referenzimplementation zu machen, dann kann ein Entwickler machen was er will.
Dann kann ein anderer Client sagen, nicht kompatiblel weil in XXX steht YYY -> den block werf ich weg.

Utopie!

Das wäre - selbst wenn das möglich wäre - dann eben nicht mehr der Bitcoin. Sondern der Superdupersonstnochwas-Coin

[yxt]

glaub ich nicht, 38.93% der Blöcke der letzten 24h haben ein BIP100 vote...

zwischenzeitlich schon 63.23%
https://www.blocktrail.com/BTC/pools?resolution=24h

[fronti]

Das Problem ist, dass man ein Verfahren finden muss, Bitcoin unabhängig von der Referenzimplementation zu machen, dann kann ein Entwickler machen was er will.
Dann kann ein anderer Client sagen, nicht kompatiblel weil in XXX steht YYY -> den block werf ich weg.

Utopie!

Das wäre - selbst wenn das möglich wäre - dann eben nicht mehr der Bitcoin. Sondern der Superdupersonstnochwas-Coin

klar utopie. aber eben machbar.
Und natürlich ist das dann auch nicht mehr Bitcoin wie man das heute nennt, aber man kann darauf aufbauen, man benötigt eben einen hardfork .)

[mezzomix]

glaub ich nicht, 38.93% der Blöcke der letzten 24h haben ein BIP100 vote...
Dahin wird die Reise wohl gehen

Finde ich durch die dynamische Abstimmung und den Machttransfer zu den Minern nicht unbedingt gut. Da die Grenzen im Vernünftigen Rahmen liegen (32MB und nicht 8GB) kann ich damit aber notfalls leben. Eine einfache Anhebung des Limits (egal ob auf 4MB, 8MB oder 32MB) wäre aber trotzdem besser.

[lassdas]

glaub ich nicht, 38.93% der Blöcke der letzten 24h haben ein BIP100 vote...
Dahin wird die Reise wohl gehen

Finde ich durch die dynamische Abstimmung und den Machttransfer zu den Minern nicht unbedingt gut. ...

Ob dynamisch jetzt besser, oder schlechter ist, als statisch, darüber kann man ja gerne streiten,
aber Machttransfer zu den Minern? Echt jetz? 
Das letzte Wort bei der Größe eines Blockes (maximale Blockgröße hin oder her) hat doch ohnehin immer der Miner, der ihn baut.
 

[mezzomix]

glaub ich nicht, 38.93% der Blöcke der letzten 24h haben ein BIP100 vote...
Dahin wird die Reise wohl gehen

Finde ich durch die dynamische Abstimmung und den Machttransfer zu den Minern nicht unbedingt gut. ...

Ob dynamisch jetzt besser, oder schlechter ist, als statisch, darüber kann man ja gerne streiten,
aber Machttransfer zu den Minern? Echt jetz? 
Das letzte Wort bei der Größe eines Blockes (maximale Blockgröße hin oder her) hat doch ohnehin immer der Miner, der ihn baut.
 

Er kann aber bisher nicht bestimmen, dass ein anderer Miner den nächsten Block nur noch kleiner bauen darf. Im Augenblick bestimmen alle Teilnehmer im System die Grenzen. Mit BIP100 gibt man den Minern einen Spielraum, mit dem sie selbst die Grenzen innerhalb eines definierten Intervall festlegen können.

[lassdas]

Naja, Er und den nächsten Block ist dann doch schon ein wenig überspitzt,
denn damit Er überhaupt irgendwas bestimmen kann, braucht er schon noch ein paar Mitstreiter.

Consensus halt,
iss ja bei der Entscheidung, was denn in Zukunft passieren soll, auchnich viel anders,
welches Mitspracherecht haben wir Nicht-Miner denn, wenn für die BIPs per erzeugtem Block gevotet wird?
Ansich wird da also nich sehr viel Macht transferiert, die iss eh schon lange da. 

[mezzomix]

Consensus halt,
iss ja bei der Entscheidung, was denn in Zukunft passieren soll, auchnich viel anders,
welches Mitspracherecht haben wir Nicht-Miner denn, wenn für die BIPs per erzeugtem Block gevotet wird?

Wir können den Block nicht aktzpetieren/weiterleiten und den Minder damit auf seiner Arbeit und einem wertlosen Block sitzen lassen!

Ansich wird da also nich sehr viel Macht transferiert, die iss eh schon lange da. 

Die Macht ist nur da, solange die Nutzer ihre Rolle nicht schätzen und sich in eine selbstgewählte Opferrolle begeben. Der Wert des Bitcoin entsteht durch die Nutzer / die Nutzung und nicht durch die Miner (Entwickler) / den Mining-Prozess. Mit der Aktzeptanz von BIP100 räumen die Nutzer den Minern in Zukunft (bis zum nächsten Hardfork) die Entscheidung über die Blockgrenzen, also einem Parameter der Konsensregeln, ein. Dazu besteht kein Anlass.

[deadlock1]

Ich mag BIP101 nicht, aber BIP100 ist mir auch nicht wirklich sympathisch. Die Miner entscheiden dynamisch - so ein Quatsch!!!! Sind die alle blind und taub oder bin ich Hellseher, dass ich schon die nächsten Probleme auf uns zukommen sehe? Forks ohne Ende!

Wäre eher für statische Block(ober)größen.

Somit bleiben also nur noch die Altcoins übrig, da Bitcoin sich langsam in einen Haufen Scheixxe verwandelt.

Satoshi würde sich im Grabe rumdrehen, wenn er wüsste, was ihr aus seiner Erfindung gemacht habt. 

[mezzomix]

Ich mag BIP101 nicht, aber BIP100 ist mir auch nicht wirklich sympathisch. Die Miner entscheiden dynamisch - so ein Quatsch!!!! Sind die alle blind und taub oder bin ich Hellseher, dass ich schon die nächsten Probleme auf uns zukommen sehe? Forks ohne Ende!

Massenweise Forks wird es durch BIP100 nicht geben, da die Konsensregeln dann aussagen, dass sich alle an die Abstimmungsergebnisse halten müssen. Das kann bzw. wird dann auch so in den Code aufgenommen.

Der einzige Vorteil von BIP100 gegenüber BIP101 ist, dass die absolute Obergrenze nicht wahnwitzige 8GB pro Block ist, sondern "nur" 32MB.

Wobei meiner Meinung nach  4-8MB für die nächsten Jahre reichen würden und man in dieser Zeit das Pruning und den Datentransfer durch Nutzung des Mempool optimieren kann, sodass man tatsächlich Luft für grössere Blöcke bekommen würde.

Wäre eher für statische Block(ober)größen.

Dieser Meinung bin ich bezüglich der Konsensregeln ebenfalls. KISS - Keep It Stupid Simple.

[deadlock1]

Ich mach jetzt nen eigenen Bitcoin, den Bitcoin XP (=experienced)

Merkmal, wie bisher, nur halt 8 MB statisch. KISS-certified! 

Die Chinesen werden ihn mir aus den Händen reißen.  

[deadlock1]

Massenweise Forks wird es durch BIP100 nicht geben, da die Konsensregeln dann aussagen, dass sich alle an die Abstimmungsergebnisse halten müssen. Das kann bzw. wird dann auch so in den Code aufgenommen.

Ich glaube, du hast die Tragweite nicht ganz verstanden!?

Bisher war nur die Länge bei validen Ketten ausschlaggebend. Ab dann kommt ein weiteres entscheidendes Kriterium dazu, die momentane maximale Blockgröße, diese wird innerhalb der Blockchain selbst festgelegt, d.h. jede Blockchain behauptet von sich "Meine momentane Blockgröße ist die richtigste!". Nehmen wir nur mal an, im netztechnisch suboptimal verbundenen China stimmen die Miner für 8MB und im Rest der Welt für 4 MB. Dies lässt dann tatsächlich mehrere gültige Blockchains nebeneinander koexistieren, aufgrund der schwammigen Merkmale, was bisher unmöglich war.

Beispiel - Das ist wie bei der Partnerwahl:
- Du willst die hübscheste Frau der Welt, sagen wir ausschlaggebend ist das Gremium der Misswahl. Dann nimmst du einfach die Miss World.
- Du willst die reichste Frau der Welt - Blick in die Vermögensaufstellung genügt. Eindeutig!

Nun willst du aber die hübscheste + reichste Frau der Welt!? Hast also 2 Kriterien. Wie entscheidest du das jetzt? Siehste, das wird sehr schwierig.

[Aswan]

Nun willst du aber die hübscheste + reichste Frau der Welt!? Hast also 2 Kriterien. Wie entscheidest du das jetzt? Siehste, das wird sehr schwierig.

Die Reiche kann sich die OPs doch leisten

[mezzomix]

Ich glaube, du hast die Tragweite nicht ganz verstanden!?

Bisher war nur die Länge bei validen Ketten ausschlaggebend. Ab dann kommt ein weiteres entscheidendes Kriterium dazu, die momentane maximale Blockgröße, diese wird innerhalb der Blockchain selbst festgelegt, d.h. jede Blockchain behauptet von sich "Meine momentane Blockgröße ist die richtigste!". Nehmen wir nur mal an, im netztechnisch suboptimal verbundenen China stimmen die Miner für 8MB und im Rest der Welt für 4 MB. Dies lässt dann tatsächlich mehrere gültige Blockchains nebeneinander koexistieren, aufgrund der schwammigen Merkmale, was bisher unmöglich war.

Ich denke schon, dass ich das verstanden habe.

Da das Abstimmungsergebnis aus den Vorgängerblöcken hervorgeht und die längste Kette von Block zu Block bestimmt wird, sollte es dadurch nicht zu grösseren Forks/Reorganisationen kommen, als dies bisher der Fall war. Dauerhafte Splits dürfte es trotzdem keine geben, solange die Implementierungen nicht fehlerhaft sind. Allerdings ist der Mechanismus komplexer und ein Fehler im Konsens-Code damit wahrscheinlicher.

Die Regel längste Kette ist, soweit ich das Verstanden habe, auch mit BIP100 immer noch massgebend. Erst danach schlägt die Regel zu, die für den folgenden Block die maximale Grösse bestimmt. Damit gibt es keine zwei Regeln, die sich widersprechen könnten.

[ulrich909]

Nun willst du aber die hübscheste + reichste Frau der Welt!? Hast also 2 Kriterien. Wie entscheidest du das jetzt? Siehste, das wird sehr schwierig.

Die Reiche kann sich die OPs doch leisten

Nenn mir eine reiche Frau die nach x Operationen hübscher aussieht wie vorher ;-)

[Aswan]

Nun willst du aber die hübscheste + reichste Frau der Welt!? Hast also 2 Kriterien. Wie entscheidest du das jetzt? Siehste, das wird sehr schwierig.

Die Reiche kann sich die OPs doch leisten

Nenn mir eine reiche Frau die nach x Operationen hübscher aussieht wie vorher ;-)

Du hast natürlich recht, war ja auch nur spaß

[deadlock1]

Allerdings ist der Mechanismus komplexer und ein Fehler im Konsens-Code damit wahrscheinlicher.

Genau das mein ich, selbst bei einwandfreiem Konzept und theoretischem Null Risiko ist die Implementierung von BIP100 schwieriger z.B. als bei statischer Blockgröße.

In hochkomplexen Entwicklungen schleichen sich nun mal schneller Fehler ein als in einfachen.

Hier muss permanent vergangenheitsbezogen die Blockchain gelesen werden, um festzustellen wie die Abstimmung zum Zeitpunkt x gewesen war, um die aktuelle Blockgröße festzustellen. Schön oder elegant ist das nicht!

Die Regel längste Kette ist, soweit ich das Verstanden habe, auch mit BIP100 immer noch massgebend. Erst danach schlägt die Regel zu, die für den folgenden Block die maximale Grösse bestimmt. Damit gibt es keine zwei Regeln, die sich widersprechen könnten.

Hoffen wir es, dass es auch so umgesetzt wird, dass es passt. Ich habe dabei eher ein leichtes Magengrummeln.

[fronti]

Hier muss permanent vergangenheitsbezogen die Blockchain gelesen werden, um festzustellen wie die Abstimmung zum Zeitpunkt x gewesen war, um die aktuelle Blockgröße festzustellen. Schön oder elegant ist das nicht!

so in etwa wie die Anpassung der Difficulty...
Hier wird auch aus vielen vorherigen Blöcken errechnet wie sich das in jedem Block zu verhalten hat.

Und auch, welche Kette denn als längste gilt, die mit der "höchsten" Rechenkraft, das muss ja auch dynamisch geprüft werden von den Nodes..

Also IMHO ist es schon machbar, da etwas mehr Dynamik noch reinzubringen, aber ja, KISS ist das nicht unbedingt.