Pages:
Author

Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 83. (Read 185692 times)

legendary
Activity: 2618
Merit: 1253
Ja, lässt sich aber wohl nicht vermeiden. Solange Lücken (egal ob im Systemdesign, Protokoll oder in der Implementierung) da sind, werden diese auch genutzt. Andere Beispiele: "Stresstest", Mempool Exhaustion, Transaction Malleability, ...

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

Besser als die Angriffe auf BU Knoten wäre eine Abstimmung mit den vom Bitcoin-Design vorgesehenen Mitteln: Jeder Knoten verifiziert Blöcke und Transaktionen und entscheidet eigenständig über die Aktzeptanz und die Weiterleitung. Das ist die Kernfunktion des System, daher sollte diese Funktion auch genutzt werden.
donator
Activity: 2772
Merit: 1019
http://imgur.com/8i5xJvC

Upsi kleiner Bug bei den BU nodes.Passiert... Roll Eyes

https://mobile.twitter.com/SatoshiLite/status/841788146958270465

Quote
1/ Today’s Bitcoin Unlimited node crashing bug proves that users cannot trust Bitcoin’s $20B network in the hands of BU developers.

FUD!

Der gute Mann vergisst zu erwähnen, daß der Bug nicht einfach von selbst zugeschlagen hat. Es war eine entsprechende Attacke mit speziell angefertigten XTHIN Messages nötig. Wer die Attacke ausgeführt hat? Darüber kann jeder mal selber nachdenken.

Die BU-Software hat auf diese fehlerhaften Pakete mit Ausgabe einer Fehler-Info und stop der node reagiert. Das kann man als Bug bezeichnen (der übrigens bereits gefixt war als Peter Todd auf twitter drüber hergezogen ist: die Nodes welche solche fehlerhaften Nachrichten schicken werden jetzt als DOS-Nodes geflaggt und die angegriffene Node läuft weiter).

Diese Art von bugs hat jede software. Auch Core.

Wie macht mein ein dezentrales Netzwerk resilienter gegen Attacken die sich aus solchen Bugs ableiten lassen?

Diversität

Wenn das Netzwerk aus verschiedenen Implementationen besteht, ist immer nur ein Teil angreifbar. Bei einer Monokultur ist gleich das ganze Netz verwundbar.
donator
Activity: 2772
Merit: 1019
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.
legendary
Activity: 2618
Merit: 1253
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.

Hast du schon mal an ein BIP gedacht (oder gibt es schon eins)?

Gibt keins und die Methode ist sicher nicht konsensfähig. Ausserdem sind noch mehr Optionen das allerletzte was man gerade benötigt. Es liegen genug ernsthafte Optionen auf dem Tisch (segwit, 2-8MB Hard-Fork), die die aktuellen Probleme lösen, teilweise sehr gut getestet wurden, kein grosses Risiko bringen und die Arbeitsteilung / das Systemverhalten nicht ändern.
legendary
Activity: 2459
Merit: 1057
Don't use bitcoin.de if you care about privacy!
Wer ist Charlie Lee noch gleich? Ich kann mir Namen leider nicht so gut merken.

Charlie Lee ist der Erfinder von Litecoin und Bruder von Bobby Lee die beide bei BTCC eine leitende Funktion haben.
legendary
Activity: 1190
Merit: 1000
Wer ist Charlie Lee noch gleich? Ich kann mir Namen leider nicht so gut merken.
legendary
Activity: 2459
Merit: 1057
Don't use bitcoin.de if you care about privacy!
http://imgur.com/8i5xJvC

Upsi kleiner Bug bei den BU nodes.Passiert... Roll Eyes

https://mobile.twitter.com/SatoshiLite/status/841788146958270465

Quote
1/ Today’s Bitcoin Unlimited node crashing bug proves that users cannot trust Bitcoin’s $20B network in the hands of BU developers.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
Was soll denn der Punkt mit den Fees höher als bei letzter Blocksize-Änderung?
Das bedeutet im Klartext, daß, um ein Wachstum des Systems zu ermöglichen, die Fees zwangsläufig immer steigen müssen.
Gemeint sind die Gesamt-Fees pro Block, also nicht die durchschnitllichen Fees pro Transaktion. Das bedeutet, dass auch bei mehr / größeren Transaktionen die Fees ansteigen können, ohne dass die durchschnittliche Fee pro kB ansteigen muss. Bei jeder 10%-Änderung steigt ja die Kapazität, und wenn die Blöcke voll sind, muss somit die Gesamt-Fee steigen, wenn die Durchschnitts-Fee nicht fällt.

Der Punkt stammt aus BIP 106. Ich habe mir auch schon überlegt, ob der wirklich sein muss. Das Problem ist halt, dass ohne die Bedingung eventuell Anreize für Spamattacken zugunsten einer Blocksize-Erhöhung entstehen.

Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben.

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. Hast du schon mal an ein BIP gedacht (oder gibt es schon eins)?
donator
Activity: 2772
Merit: 1019
Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben. Vor allem nicht, da manche Poolbetreiber gerade zeigen wie bösartig und schädlich sie schon mit den aktuellen Rechten umgehen (SPV Mining, Nutzung der Miningleistung zur Blockade der weiteren Entwicklung, Malleated TX).


Ich möchte weder dich in eine Schublade stecken noch selbst in eine gesteckt werden, aber beim lesen dieses gerade erschienenen Artikels "Two Theories of Bitcoin" von Mengerian musste ich immer wieder an deine (von mir angenommene) und meine eigene Sichtweise denken. Die Sichtweisen nennt der Autor:

  • Extreme Consensus
  • Market Consensus

Der Artikel ist leider auf englisch. Ich möchte ihn hier nicht zusammenfassen. Fehlt mir die Zeit dies angemessen zu tun.

EDIT: aus dem Artikel:
 
Quote
In trying to understand one another better, perhaps we can also nudge our understanding closer to an accurate representation of reality.
legendary
Activity: 2618
Merit: 1253
Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben. Vor allem nicht, da manche Poolbetreiber gerade zeigen wie bösartig und schädlich sie schon mit den aktuellen Rechten umgehen (SPV Mining, Nutzung der Miningleistung zur Blockade der weiteren Entwicklung, Malleated TX).
donator
Activity: 2772
Merit: 1019
Warum sollten die miner denn für größere Blöcke voten? Ein großer Mempool erhöht doch ihre gewinne.

Auf kurze Sicht vielleicht. Aber long-term? Bitcoin ist ja nicht die einzige coin mit der man Geld verschieben kann.
full member
Activity: 243
Merit: 108
Warum sollten die miner denn für größere Blöcke voten? Ein großer Mempool erhöht doch ihre gewinne.

Und welcher Anteil der Miner muss denn für eine Blocksize-Änderung voten damit die durchgesetzt wird? Wenn dieser Wert zu hoch ist, ist es wahrscheinlich, dass überhaupt nichts passiert, so wie jetzt gerade.
legendary
Activity: 3657
Merit: 1448
Was soll denn der Punkt mit den Fees höher als bei letzter Blocksize-Änderung?
Das bedeutet im Klartext, daß, um ein Wachstum des Systems zu ermöglichen, die Fees zwangsläufig immer steigen müssen.
Den Sinn dahinter versteh ich mal garnicht.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
Zum Kompromissvorschlag mit den 10%-votes: Den diskutieren wir gerade hier. Lauda hat eine zusätzliche Obergrenze vorgeschlagen, die verhindert, das allzu große Werte gevotet werden.

Folgendes ist mein bisher konsensfähigster Vorschlag:
1) Zuerst wird SegWit implementiert und eine längere Zeit (bis 1 Jahr) bleibt dies die einzige Blocksize-Änderung, um auf mögliche Spam-Angriffe/neue Risiken reagieren zu können.
2) Nach Ablauf der Frist wird das Voting-System freigeschaltet. Miner können 10% plus oder 10% minus voten, sobald die Bedingungen (50% der Blöcke über 90% der alten maximalen Blocksize, Fees höher als bei letzter Blocksize-Änderung -> Miner dürfen für +10% voten, bei 90% der Blöcke unter 50% dürfen sie für 10% weniger voten) gegeben sind.

Dazu kommt aber eine feste 2 MB Base / 8 MB Weight Obergrenze, die 2 Jahre lang Bestand hat.

3) nach weiteren 2 Jahren wird die feste Obergrenze auf 3 MB / 12 MB erhöht.

Das ganze wird zusammen gecodet, damit auch Miner mit einer Vorliebe für große Blöcke zustimmen können. Die Core Devs könnten dafür eine Erklärung abgeben, dass sie die höheren Blockgrößen später nicht mehr heruntersetzen werden.

Super wäre es, wenn jemand, der des BTC-Programmieren mächtig ist, daraus ein echtes BIP erstellt.
sr. member
Activity: 545
Merit: 250
http://wmstudios.com.au/index.php/blog/108-bitcoin-is-under-attack-but-only-because-it-is-a-threat-to-the-global-elites


Hier der Grund wieso Maxwex und Adam nie die Blocksize erhöhen werden das würde Ihre Eigene Firma zerstören  Wink
copper member
Activity: 2324
Merit: 1348
Ich habe jetzt einen Vorschlag aufgegabelt, der mir wirklich gefällt. Credits gehen an Jeff Garzik, "upal" und "DooMAD", der das etwas ausgearbeitet hat. Es ist eine Mischung aus BIP 100 und 106.

Grundsätzlich voten hier auch die Miner die Blocksize, aber ganz anders als bei Bitcoin Unlimited. Und zwar dürfen die Miner in jeder Difficulty-Periode (2016 Blocks), wenn 50% der Blöcke der vorigen Periode fast voll (also >90% der Kapazität) waren, dafür voten, die Blockgröße um 10% zu erhöhen. Analog dazu darf gevotet werden, die Blockgröße 10% zu verringern, wenn die 90% der Blöcke weniger als 50% des Maximums erreichen.

Um Spam-Attacken teuer zu machen (verhindern kann man sie leider nicht), wird gleichzeitig festgelegt, dass eine solche Erhöhung nur dann passieren darf, wenn die gesamten durchschnittlichen Fees der aktuellen Periode höher sind als in der letzten Periode, und eine Verringerung nur dann, wenn analog dazu die Fees niedriger sind.

Die Vorteile:
- eine Mega-Blockerhöhung, wie sie bei BU befürchtet wird, würde lange dauern und würde, falls die Miner dafür per Spam-Attacken konspirieren müssen, sie hohe Fees für die Spam-Attacken kosten.
- da das ganze langsam vor sich geht, hätten bei einer zu stark steigenden Blocksize die normalen Nodes Zeit, Gegenmaßnahmen treffen, z.B. mit der "mezzomix-Weiterleitungsblockade".
- trotzdem kann relativ schnell auf Bottlenecks reagiert werden.

(Edit: Zahlendreher)

Das ist wirklich TOP !! Gefällt mir...
sr. member
Activity: 545
Merit: 250
https://zander.github.io/posts/BitClub-attack/


Wieso schreibt eigt keiner was das die Segwit Supporter das NEtzwerk  Attacken jetzt wo klar ist langsam selbst dem letzten kronleuchter

das Blockstream Core Failed ist sieht man das wahre Gesicht von den Segwit Leuten indem sie versuchen durch Attacken zu zeigen das wir unbedingt Segwit brauchen  ...

Hätte auch schief gehen können und Bitcoin mächtig schaden können  Roll Eyes  Huh Huh Huh Huh
legendary
Activity: 2618
Merit: 1253
Der Vorschlag ist besser als BU. Er enthält allerdings ziemlich viele Fallstricke, über die eine schlechte Implementierung stolpern kann. Ich persönlich möchte eine solche Entscheidung gar nicht bei den Minern sehen, vor allem nicht mit der aktuellen Pool Landschaft.

Ich hätte nichts gegen einen grösseren Hard-Fork einzuwenden, bei dem man neben einigen Optimierungen und einer für die nächsten Jahre ausreichenden Block-Size auch einen Mining Algorithmus nutzt, der eine Auslagerung von Arbeitsleistung effektiv unmöglich macht. Ein Algorithmus, der in jeder Runde die Informationen aus dem Block und aus dem UTXO Set verwertet, würde das Mining wieder auf die ursprüngliche Idee zurückführen. Daneben würde dies einen einfacheren Bootstrap auf Basis eines UTXO Commitments erlauben.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
Ich habe jetzt einen Vorschlag aufgegabelt, der mir wirklich gefällt. Credits gehen an Jeff Garzik, "upal" und "DooMAD", der das etwas ausgearbeitet hat. Es ist eine Mischung aus BIP 100 und 106.

Grundsätzlich voten hier auch die Miner die Blocksize, aber ganz anders als bei Bitcoin Unlimited. Und zwar dürfen die Miner in jeder Difficulty-Periode (2016 Blocks), wenn 50% der Blöcke der vorigen Periode fast voll (also >90% der Kapazität) waren, dafür voten, die Blockgröße um 10% zu erhöhen. Analog dazu darf gevotet werden, die Blockgröße 10% zu verringern, wenn die 90% der Blöcke weniger als 50% des Maximums erreichen.

Um Spam-Attacken teuer zu machen (verhindern kann man sie leider nicht), wird gleichzeitig festgelegt, dass eine solche Erhöhung nur dann passieren darf, wenn die gesamten durchschnittlichen Fees der aktuellen Periode höher sind als in der letzten Periode, und eine Verringerung nur dann, wenn analog dazu die Fees niedriger sind.

Die Vorteile:
- eine Mega-Blockerhöhung, wie sie bei BU befürchtet wird, würde lange dauern und würde, falls die Miner dafür per Spam-Attacken konspirieren müssen, sie hohe Fees für die Spam-Attacken kosten.
- da das ganze langsam vor sich geht, hätten bei einer zu stark steigenden Blocksize die normalen Nodes Zeit, Gegenmaßnahmen treffen, z.B. mit der "mezzomix-Weiterleitungsblockade".
- trotzdem kann relativ schnell auf Bottlenecks reagiert werden.

(Edit: Zahlendreher)
sr. member
Activity: 545
Merit: 250

Bitcoin won't be ready for mainstream until we have an adaptive blocksize. It's that simple.

Do you really want to wait two to four years while the theoretical Lightning Network is developed?

Further, once implemented, LN transactions need to both open and close connections by making an on-chain transaction. On-chain transactions will be really expensive by the time the LN is ready. Who wants to make a $100 transaction in order to send small amounts back and forth? Maybe exchanges, but not general users. Either way, it increases centralization which is bad for the network.

The LN is generally meant for small or micro-transactions, yet if there is a disputed transaction the sender has no way to get their money back. This is because the price to settle on-chain will be more than the disputed transaction amount. It's a very serious flaw that Peter Todd mentioned here: https://bitcoinmagazine.com/articles/here-s-how-bitcoin-s-lightning-network-could-fail-1467736127/
The solution? An adaptive blocksize.

Further, who wants to keep their money locked up in a channel for years? With the LN there is no peace of mind of being able to see your transaction on the blockchain from anywhere in the world. So much is left up to trusting hubs. More centralization, middlemen and trust that Bitcoin was meant to replace.

Blocks are full. Unconfirmed transactions sometimes reach 100,000. 54% of addresses with amount are not spendable due to high fees.
The new transactions aren't spam - this is organic user growth that Bitcoin needs to embrace. Instead core is telling people to use their credit cards for everyday transactions. It's shameful and developer negligence if I've ever seen it.

If Bitcoin Unlimited is adopted and larger blocks start to handle the transaction backlogs while lowering fees, this will tell the world that Bitcoin is ready for mainstream.


 Wer wiederspricht meiner logischen erläuterung hier ?  Grin
Pages:
Jump to: