Re: Der Aktuelle Kursverlauf blockgrösse

[doc12]

Der kleine BU-Fauxpas hat die core >= 13.1 nodes doch glatt auf 62% der Gesamtnodes gehievt. Noch ein paar Bugs und wir sind diesen Mist endlich los. Nur die BTUcoin-supporter wahrscheinlich nicht, aber damit muss man leben. Ein paar wochen später wird dann wieder ein neuer Altcoin promotet.

[1714941814]

1714941814

[1714941814]

1714941814

[1714941814]

1714941814

[1714941814]

1714941814

[1714941814]

1714941814

[molecular]

Deshalb ist übrigens auch das BU Design fehlerhaft, da die Annahme über eine ehrliche Abstimmung durch die Knoten nicht haltbar ist.

Das BU Design ist das Bitcoin Design. Jeder kann auch den core-code nehmen und das blocksize limit rauseditieren. Daß Bitcoin funktioniert basiert nicht auf der Unmöglichkeit dies zu tun.

Das stimmt nicht ganz, da die Knoten auch noch ihre gewünschte und maximal aktzeptierte Blockgrösse mitteilen. Diese Information ist nicht vertrauenswürdig (= kann falsch sein), dient aber als Basis zur Berechnung der maximalen Blockgrösse. BU heisst nicht, dass der Client beliebige Blockgrössen aktzeptiert!

Ja, das stimmt. Es gibt dieses zusätliche Signalling. Auch die andere Aussage stimmt: BU heisst nicht, daß eine Node (oder ein anderer Miner) größere Blöcke akzeptiert.

Was nicht so ganz stimmt ist, daß diese Information als "Basis zur Berechnung der maximalen Blockgrösse" dient. Diese wird vom Miner explizit eingestellt. "miningmaxblock", ist also ein dritter Konfigurationsparameter von BU.

Es gibt keine technische Möglichkeit, auf Basis einer unsicheren Information, sicher eine überall aktzeptierte maximale Blockgrösse zu errechnen!

Ja, auch richtig, dieses Signaling ist "unsicher". Das Node signalling ist durch die Miner entsprechend zu bewerten (mit Vorsicht). Es ist ja auch so, daß eine potentielle Mehrheit der Nodes (auch wenn diese nicht lügen) nicht unbedingt ausreicht. Wenn beispielsweise alle Exchanges EB=1MB haben, alle anderen Node EB=2MB, dann sollte der miner lieber nicht einen 2 MB block minen.

[molecular]

Es geht auch nicht um eine Abstimmung. Es geht darum den Minern die Sicherheit zu signalisieren (auf rein technischer Ebene), daß Ihre blocks auf zustimmung stossen (oder auch nicht). Diese technische Ebene ist aber nicht die einzige Ebene die die Miner beachten müssen: Sie haben die Aufgabe und auch das starke Eigen-Interesse nach solchen Regeln zu minen, daß die größtmögliche Ökonomische Mehrheit die chain akzeptiert. Das findet nicht nur auf der Netzwerk-Protokoll-Ebene (blocksize limit) statt, sonder auch auf der Ebene der monetären Parameter: wenn sie beispielsweise das coin limit auf 42 millionen erhöhen, dann findet das die ökonomische Mehrheit voraussichtlich nicht gut. Wenn sie drauf beharren, dann gibt es einen Split (UASF, PoW-Change, minority fork oder was auch immer) und der Markt regelt den Rest. Ganz schnell crasht der Preis dieses "Bitcoin 42". Also werden die Miner soetwas nicht tun. Sie werden versuchen einen Chain zu bauen, die den größtmöglichen Wert hat. Ich finde darin kann man Vertrauen haben. Funktioniert bisher blendend. Das ist Bitcoin.

Nein, das ist bisher eben nicht Bitcoin (s.o.). Bisher basiert Bitcoin auf vollständiger Verifikation und nicht darauf, dass das System erst mal zerfällt (Split) und der Markt danach den Gewinner aussortiert.

Was verstehst du unter "vollständiger Verifikation"? Das verstehe ich nicht so ganz.

[molecular]

Der kleine BU-Fauxpas hat die core >= 13.1 nodes doch glatt auf 62% der Gesamtnodes gehievt. Noch ein paar Bugs und wir sind diesen Mist endlich los. Nur die BTUcoin-supporter wahrscheinlich nicht, aber damit muss man leben. Ein paar wochen später wird dann wieder ein neuer Altcoin promotet.

Daß du die Gegenseite scheisse findest bringt uns nicht weiter. Auch das hier kundzutun hat überhaupt keinen Wert.

EDIT:
Und sorry daß ich deine Hoffnung zerstören muss, aber der Bitcoin Unlimited Nodecount erhohlt sich recht flott:

Noch ein paar Bugs und wir sind diesen Mist endlich los.

Du meinst Angriffe, aber ich verstehe natürlich, daß du dieses Wort in diesem Falle vermeiden willst.

[Danton]

Die BU-Nodes sind Teil des Bitcoin-Netzwerks und stellen momentan keine Gefahr dar, sondern unterstützen das Netzwerk so wie jede Core Node auch. Ein Angriff auf diese Nodes ist ein Angriff auf Bitcoin. Die Zensur des hotfixes finde ich genauso verwerflich wie die Attacke selbst.

Ganz unterstes Niveau mittlerweile.

In der Tat!

Es sollte das Ziel sein gemeinsam an einem stabilen Netzwerk zu arbeiten, anstatt zu versuchen die jeweils andere Seite bloßzustellen. Jede Stück Software hat Fehler. Dies trifft auf BU genauso zu wie auf Bitcoin Core. Jetzt hat man sich mal wieder über BU lustig gemacht, irgendwann wird auch mal wieder ein Bug in Core entdeckt. Für Außenstehende dürfte das ganze Theater einfach nur abschreckend wirken. Im Ernst: Wer möchte denn die vermeintliche Zukunft des Geldes und Zahlungsverkehrs einer Community anvertrauen, die ihre eigenes Netzwerk attackiert, nur um bei internen Rivalitäten einen Punkt zu machen??

[600watt]

hier ein paar tweets, die für sich sprechen.

Peter Todd @petertoddbtc

FYI, BU nodes started crashing about 30 mins after BU published it on Github; I tweeted 1hr later.

I had _nothing_ to do with the attack. pic.twitter.com/C0WWMG80ab

Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

BU bug: This isn't about individual competence. It's about a process with diverse and laborious review, which catches bugs before production
7 Antworten 25 Retweets 71 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

If you depend on every dev being a "dream team", you can't scale. It takes a diverse team to be able to produce quality code, consistently
5 Antworten 12 Retweets 35 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

Bugs like this pop up in Core code too. The important difference: they *never* make it to production releases. The QA process catches them
3 Antworten 19 Retweets 50 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

This is not the result (only) of competent devs. It is review, diverse skills, test coverage & a large user base testing release candidates
1 Antwort 8 Retweets 23 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

The whole system works to be able to produce large volume of quality production code, even when not all the contributors are "dream team"
1 Antwort 5 Retweets 17 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

Blaming this on "incompetence" of BU devs misses the point & undervalues the invisible but highly effective QA process that Core offers
3 Antworten 6 Retweets 23 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

It's not about preventing bugs from being written. It's about preventing them from going into production. That takes a TEAM & a PROCESS
2 Antworten 11 Retweets 26 Gefällt mir
Andreas‏Verifizierter Account @aantonop 3 Std.vor 3 Stunden

Core's QA process & team review has managed to deliver tens of thousands of changes without an exploit like this in production.
1 Antwort 9 Retweets 22 Gefällt mir

Andreas‏Verifizierter Account @aantonop

BU has shipped an exploitable bug on a code base that is 0.001 of the size of Core's. That's several orders of magnitude worse QA process

ich denke andreas hat, wie so oft, völlig recht.

meiner meinung nach hat das BU konzept auf allergefährlichste und allerpeinlichste art versagt. und das aus einer ecke, die soooooo laut schreit, sie wären besser, wichtiger, die einzig wahren.

wäre BU bereits, wie angedroht, geforkt und "der alleinige" bitcoin, dann wären wir gestern untergegangen. dann wäre das spiel möglicherweise aus gewesen. da sagt mir der konservative und vorsichtige weg, den CORE geht, wesentlich mehr zu und das ist jetzt wirklich milde ausgedrückt. ich würde meine BU coins sofort verkaufen. das wäre mir zu riskant. ausgerechnet den minern solche macht zu geben und mit einem dev team, das solche sachen passieren lässt und mit einem "präsidenten".

dass es so weit gekommen ist, liegt aber auch an core. die 2 mb hätten schneller kommen müssen. jetzt sind sie allerdings in greifbarer nähe (segwit) - aber das wollen einige grosse miner nicht und blockieren. was für ein kindergarten.

was mich verwirrt ist, das zum thema kompetentere menschen als ich (wie molecular) den BU weg gehen. es muss also was dran sein. aber sehen/erkennen kann ich das nicht. mir ist klar, dass nur weil ich es nicht sehe, es nicht trotzdem valide gründe geben muss, warum BU überhaupt supporter hat. problematischerweise gibt es natürlich echte "bad actors" - feinde des bitcoin - und die nutzen den riss natürlich aus, der hier am entstehen ist und giessen öl ins feuer - auf beiden seiten.

was ich daran lernen kann, ist, dass sich wichtige, große communities spalten können und keiner ist wirklich "böse" oder hat schlechte absichten. alle wollen, dass historisch grosse ideen wie bitcoin (oder das christentum, oder der kommunismus, oder der feminismus oder die sozialdemokratie etc) funktioniert. trotzdem spalten sich die die gruppen bis zu einem punkt, wo sie sich anfeinden. hier sehen wir in echtzeit, wie so eine spaltung vor sich geht.

entweder es wird ein kompromiss gefunden - hoffentlich! (ist aber nach den gestrigen vorfällen nicht wahrscheinlicher geworden) oder wir müssen mit zwei bitcoins leben. dann sollte die trennung aber nicht mit feuer und schwert vollzogen werden, sondern rational und auf augenhöhe.

https://twitter.com/petertoddbtc/status/841906105479528449/photo/1
https://twitter.com/aantonop/status/841928772790190080?ref_src=twsrc%5Etfw

[mezzomix]

Nein, das ist bisher eben nicht Bitcoin (s.o.). Bisher basiert Bitcoin auf vollständiger Verifikation und nicht darauf, dass das System erst mal zerfällt (Split) und der Markt danach den Gewinner aussortiert.

Was verstehst du unter "vollständiger Verifikation"? Das verstehe ich nicht so ganz.

Ich kann im Augenblick einen Block verifizieren und die absolute Aussage treffen, dass er korrekt ist. Mit BU kann ich das nicht mehr, da korrekt im Ernstfall nur noch eine relative Aussage bezüglich der aktuellen Gruppierungen mit der jeweils maximalen Blockgrösse ist. Der Markt muss dann aussortieren oder auch nicht, ob es mit mehreren Zweigen weitergeht oder ob bestimmte Zweige sterben.

Die Verifikation wird hier durch die Hoffnung auf vernünftiges Handeln aller Beteiligter ersetzt. Eine zweifelhafte Annahme, die meiner Meinung nach bereits durch die aktuelle Entwicklung wiederlegt wurde.

[molecular]

wäre BU bereits, wie angedroht, geforkt und "der alleinige" bitcoin, dann wären wir gestern untergegangen.

Das ist wohl eine Übertreibung. Die "Netzwerk-downtime" wäre wahrscheinlich nicht länger als eine Stunde gewesen.

Ich gebe Andreas und Dir natürlich recht. BU braucht eine erheblich bessere QS.

[molecular]

Ich kann im Augenblick einen Block verifizieren und die absolute Aussage treffen, dass er korrekt ist.

"korrekt" nach welchen Regeln?

[Danton]

"korrekt" nach welchen Regeln?

Derzeit:
Block <= 1MB: Wird von Allen akzeptiert
Block > 1MB: Wird von Allen abgelehnt

Mit BU gibt es diese simple Regel nicht mehr. Stattdessen hängt es davon aber, wie sich andere verhalten ob ein Block letztlich akzeptiert wird. Ein einzelner Client kann sich daher nicht eindeutig bestimmen ob sich ein Block letztlich als "wirklich gültig" herausstellt.

Allerdings ist das auch jetzt schon so, da "gültige" Blöcke zu "Orphans" werden können. Gültig ist - mit oder ohne BU - letztlich nur, was fest in der Blockchain verankert ist!

[mezzomix]

"korrekt" nach welchen Regeln?

Derzeit:
Block <= 1MB: Wird von Allen akzeptiert
Block > 1MB: Wird von Allen abgelehnt

Richtig!

Sind diese Regeln nur noch relativ gültig, dann müssen alle alternativen Zweige verfolgt werden. Passiert dies nicht, können Transaktionen unerwünscht im falschen Zweig landen, bis "der Markt" das Problem gelöst hat. ETH hat demonstriert wie schnell dieser Markt das Problem löst (Hint: bis heute ist es ungelöst).

[molecular]

Sind diese Regeln nur noch relativ gültig, dann müssen alle alternativen Zweige verfolgt werden. Passiert dies nicht, können Transaktionen unerwünscht im falschen Zweig landen, bis "der Markt" das Problem gelöst hat. ETH hat demonstriert wie schnell dieser Markt das Problem löst (Hint: bis heute ist es ungelöst).

wieso ungelöst? jeder hat bekommen was er will, oder?

[molecular]

"korrekt" nach welchen Regeln?

Derzeit:
Block <= 1MB: Wird von Allen akzeptiert
Block > 1MB: Wird von Allen abgelehnt

Mit BU gibt es diese simple Regel nicht mehr. Stattdessen hängt es davon aber, wie sich andere verhalten ob ein Block letztlich akzeptiert wird. Ein einzelner Client kann sich daher nicht eindeutig bestimmen ob sich ein Block letztlich als "wirklich gültig" herausstellt.

Proof of Work? BU Nodes folgen immer der längsten chain.

Längste chain... proof of work, wisst ihr noch? Die Lösung zur Konsensfindung in Bitcoin?

[mezzomix]

Sind diese Regeln nur noch relativ gültig, dann müssen alle alternativen Zweige verfolgt werden. Passiert dies nicht, können Transaktionen unerwünscht im falschen Zweig landen, bis "der Markt" das Problem gelöst hat. ETH hat demonstriert wie schnell dieser Markt das Problem löst (Hint: bis heute ist es ungelöst).

wieso ungelöst? jeder hat bekommen was er will, oder?

Nein. Manche Börsenkunden haben verloren, Transaktionen sind auf auf dem falschen Zweig gelandet. Die Probleme wurden bis heute nicht zufriedenstellen gelöst. Ignorieren ist keine Lösung.

Proof of Work? BU Nodes folgen immer der längsten chain.

Sie folgen der längsten gültigen Chain!

[600watt]

so langsam kommen mehr hintergründe ans licht bezüglich des BU bugs.

https://bitcoinmagazine.com/articles/security-researcher-found-bug-knocked-out-bitcoin-unlimited/

sieht echt übel aus. die BU verantwortlichen sind nicht vertrauenswürdig und nicht kompetent, imho. teile der BU community sind krass am austeilen, statt selbstkritisch damit umzugehen.

peter todd als angreifer zu diffamieren finde ich bedenklich. im bericht steht, dass es wohl noch mehr dieser bugs gibt. ich finde den artikel überzeugend, aber ob das alles tatsachen sind, weiss ich nicht.

[600watt]

Hier eine zusammenfassung der Attacke auf die BU-Nodes:

These guys moved fast. It went like this:

• BU devs found a bug in the code, and the fix was committed on Github.
• Only about 1 hour later, Peter Todd sees that BU devs found this bug. (Peter Todd did not find this bug himself).
• Peter Todd posts this exploit vulnerability on twitter, and all BU nodes immediately get attacked.
• r/bitcoin moderators, in coordination, then ban all mentions of the hotfix which was available almost right away.
• r/bitcoin then relentlessly slanders BU, using the bug found by the BU devs, as proof that they are incompetent. Only mentions of how bad BU is are allowed to remain.

Die BU-Nodes sind Teil des Bitcoin-Netzwerks und stellen momentan keine Gefahr dar, sondern unterstützen das Netzwerk so wie jede Core Node auch. Ein Angriff auf diese Nodes ist ein Angriff auf Bitcoin. Die Zensur des hotfixes finde ich genauso verwerflich wie die Attacke selbst.

Ganz unterstes Niveau mittlerweile.

das steht im gegensatz zu diesem bericht:

When contacting Bitcoin Magazine on Monday, Gardner did not immediately want to make the vulnerabilities public. That would have been irresponsible, she explained, as the bugs could still be exploited before the Bitcoin Unlimited development team had the chance to fix it.

But she did also submit the vulnerabilities to Mitre’s Common Vulnerabilities and Exposures (CVE) database. This ensures that Mitre discloses the bugs in one month from now, which pressures the developers to actually fix the problem in time.

However, even following this responsible disclosure, Gardner thought there was a risk that the vulnerabilities would be abused as soon as they were fixed in the Bitcoin Unlimited code repository. After all, at that point the problem isn’t really solved: anyone running the released Bitcoin Unlimited software is still vulnerable until they download and run the new, revised version. This opens a window for attackers.

“The problem is, the bugs are so glaringly obvious that when fixing it, it will be easy to notice for anyone watching their development process,” she said.

It now appears that is exactly what has happened. While the Bitcoin Unlimited developers did indeed fix the issue shortly after it was pointed out to them, they did so with far too conspicuous a GitHub commit message, Gardner told Bitcoin Magazine once it appeared the bugs seemed fixed and before the attacks began.

“Their commit message does ring alarm bells. I’m not sure if anyone will notice, but they probably should have obfuscated the message a bit more. The wording might attract closer scrutiny. But if it went unnoticed for this long, maybe it will go unnoticed.”

Clearly, it did not.

As Gardner warned, it didn’t take long for attackers to exploit one of the vulnerabilities: the first attacks happened shortly after the bugs were fixed. A little later, user “shinobimonkey” took the issue to Reddit, Bitcoin Core developer Peter Todd tweeted about the bug and social media blew up.

https://bitcoinmagazine.com/articles/security-researcher-found-bug-knocked-out-bitcoin-unlimited/?utm_content=buffer6e884&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer


BU und teile der BU community auf r/btc sehen hier nicht gut aus, wenn der bericht stimmt.

[doc12]

Und die BU nodes wurde innerhalb weniger stunden ALLE geupdated und sind jetzt wieder auf >800. Aber sixher doch    D.h. doch die Nodes werden praktisch nur von wenigen Leuten betrieben.

[Lincoln6Echo]

Und die BU nodes wurde innerhalb weniger stunden ALLE geupdated und sind jetzt wieder auf >800. Aber sixher doch    D.h. doch die Nodes werden praktisch nur von wenigen Leuten betrieben.

Ja das denke ich auch. Ist meiner Meinung nach sehr unwahrscheinlich, dass so viele so schnell updaten..

[d5000]

Hier gibts noch einen "neuen" Vorschlag: BIP 100 upgedated (von Jeff Garzik).

Wie beim von mir vorher vorgebrachten Vorschlag (der ja seinerseits auf BIP 100 basiert) voten die Miner gemeinsam eine Erhöhung oder Schrumpfung der Blockgröße, die aber dann von allen akzeptiert werden muss. Es gibt also nicht die Möglichkeit, dass im Netzwerk Votes für mehrere Blockgrößen gleichzeitig nebeneinander bestehen wie bei BU. Im Gegensatz zur ersten Variante von BIP 100 wurde die Erhöhung / Schrumpfung der Blockgröße auf 5% pro "Wahlperiode" begrenzt.

Zum BU-Bug: Der ist ein Hinweis darauf, dass das Development Team dahinter überfordert ist. Er ist aber kein Beweis, dass die Idee größerer Blöcke insgesamt falsch ist. BU halte ich nach wie vor für "zu gefährlich" als Scaling-Lösung, aber aus anderen Gründen (zu große Macht für Miner).


Kurzes Wort noch dazu:

Deshalb wäre dein Patchvorschlag (dass Full Nodes Blöcke, die für "unerwünschte" Entscheidungen voten, zurückhalten können) keine schlechte Idee, um ein wirksames Korrektiv durch die anderen Full-Nodes für den Fall zu erhalten, dass sich die Miner vom Mehrheitswillen entfernen.

Ja, wobei ich das als Notlösung sehe, wenn gar nichts anderes mehr geht.

Ich würde das vom Scaling-Vorschlag als solchen trennen, aber eigentlich könnte ich es mir sogar voll offiziell als Option im GUI vorstellen, bei der jeder die Softfork-Optionen "abstellen" kann, die er nicht möchte. Oder auch eine zu hohe Blockgröße (bei einem dynamischen Block-Voting-System wie bei BIP 100). Den Minern wird dadurch signalisiert, was ökonomisch sinnvoll für sie ist. Müsste man aber tatsächlich erst mal testen.

Eine andere Idee wäre ein Proof-of-Stake-basiertes Wahlsystem (ohne natürlich PoS als Konsensmechanismus für Blöcke einzuführen). In dem Fall hätten allerdings wohl derzeit die Exchanges die Macht, die im aktuellen Wahlsystem die Miner haben.

[mezzomix]

Zum BU-Bug: Der ist ein Hinweis darauf, dass das Development Team dahinter überfordert ist. Er ist aber kein Beweis, dass die Idee größerer Blöcke insgesamt falsch ist.

Die Richtung, mehr Transaktionen in einen Block zu bekommen halte ich für richtig. Das geht aber nicht über eine Abstimmung, basierend auf manipulierbaren Informationen.

Ich würde das vom Scaling-Vorschlag als solchen trennen, aber eigentlich könnte ich es mir sogar voll offiziell als Option im GUI vorstellen, bei der jeder die Softfork-Optionen "abstellen" kann, die er nicht möchte. Oder auch eine zu hohe Blockgröße (bei einem dynamischen Block-Voting-System wie bei BIP 100). Den Minern wird dadurch signalisiert, was ökonomisch sinnvoll für sie ist. Müsste man aber tatsächlich erst mal testen.

Mit der aktuellen System-Architektur ist eine automatisierte Anpassung der Blockgrösse nicht möglich, ohne die Entscheidungsgewalt zu verändern. Daher halte ich nichts davon, Automatismen einzubauen die nahelegen, eine automatisierte Anpassung wäre möglich.

Eine andere Idee wäre ein Proof-of-Stake-basiertes Wahlsystem (ohne natürlich PoS als Konsensmechanismus für Blöcke einzuführen). In dem Fall hätten allerdings wohl derzeit die Exchanges die Macht, die im aktuellen Wahlsystem die Miner haben.

Davon halte ich nichts. Warum sollte der Anteil bestimmten Teilnehmern mehr Stimmrecht verleihen? Weshalb sollte jemand mit grösserem Anteil eher dafür qualifiziert sein, eine Entscheidung zu treffen?

Übrigens haben die Miner aktuell keine Macht in dieser Richtung. Es gibt schlicht kein Wahlsystem für Hard-Forks in der Architektur. Die Miner bzw. das ganze System lebt vom Handeln aller Teilnehmer. Der erste grobe Fehler ist, anzunehmen eine Rolle im System hätte hier eine höhere Entscheidungsgewalt. Saubere Änderungen erfordern einen Konsens oder - falls dies unmöglich ist - einen Split.