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

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.

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.

Hier eine zusammenfassung der Attacke auf die BU-Nodes:


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.

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


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.

Charlie Lee ist der Erfinder von Litecoin und Bruder von Bobby Lee die beide bei BTCC eine leitende Funktion haben.

Wer ist Charlie Lee noch gleich? Ich kann mir Namen leider nicht so gut merken.

http://imgur.com/8i5xJvC

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

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

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.


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)?

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:
 

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).

Auf kurze Sicht vielleicht. Aber long-term? Bitcoin ist ja nicht die einzige coin mit der man Geld verschieben kann.

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.

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.

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.

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 

Das ist wirklich TOP !! Gefällt mir...

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   

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.

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)

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 ?