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

Kurze Frage dazu: Ein Nutzer im englischen Forum behauptet, die Miner könnten mehrere Extension-Block-Chains bilden und dann selbst entscheiden, wo sie Extension-Block-TX unterbringen. Ein Nutzer (Full Node), der sich für Extension Blocks entscheidet, müsste also, um sicher zu gehen, alle "Extension Blockchains" validieren und herunterladen.

Hat er recht? Falls du das irgendwo schon mal angesprochen hast, reicht ein Link

Abgesehen davon fühle ich mich als Benutzer von den Minern missachtet.
Das Core oder Blockstream Segwit für irgendwas in der Zukunften brauchen mögen ist mir doch egal.
Mein Eindruck ist, dass deutlich über 80% aller Bitcoin Nutzer Segwit nutzen möchten.
Ich als Benutzer will es haben - die Miner sind doch keine Dienstleister gegenüber Core oder Blockstream, also sollten die doch bitte im Sinne der Nutzer handeln.





äähhmm von welchen Nutzern Sprichst du ?? von den 0.0001 % Core Supportern auf der Welt  ?

Meinst du echt die Konsum menschen von heute erstellen erstmal ein Payment Channel um VPN ,Weed etc  zu bezahlen ?

Ich nutze jeden tag Bitcoin um meine Rechnugen zu bezahlen im Darknet wird niemand iwelche Payment Channel erstellen das totaler unsinn .


Ich kenn kein Einzigen Menschen der Bitcoin kennt außerhalb dieser Website und ihr Meint iwer interessiert sich für Segwit was ein Technisches Blockchain Detail ist was schon 10000 x mal more kein Mensch auf der Erde interessiert Außer Blockstream vllllt  da sie das für ihre Payment Channel Brauchen .

Das einzigste was ich von  Real Usern aus dem Darknet höre ist wie Bitcoin sucks und  tagelang das Geld nicht ankommt.

Daran ändert Segwit auch genau NICHTS . Da 1,5 MB genauso schnell Voll sind .


Sieht man ja bei Litecoin jetzt wie im Reddit die ganzen Noobs iwas von Segwit gehört haben und wunder erwarten  und auf ihren Coins sitzen während der Kurs jetzt schön richtung 10 usd geht .

Segwit kennen 99 % der nutzer nicht und interessiert auch keinen die Technischen Details.  Es ist keine Scaling sondern fixt nur die TM.

Und das auch noch schlecht Flexibel Trans sind da viel besser.


160 000 unconfirmed und von Segwit reden als wenn jemand Payment channel aufmacht um einmalige Zahlungen zu erledigen
was aber auch wieder tagelang dauern wird da jeder Channel auch eine on Chain Tx braucht  



Bip 149 Bip Das Bip Jenes Bip Extension Blocks Bip 100 Bip Bip Bip Bitpay

seit 3 Jahren kommen 100 Scaling vorschläge und die Blockstream Zentral Planer über Bitcoin lachen sich  kaputt.  


Nur Gut für Banken um untereinander Geld zu senden.  Bitcoin = Digital COin = Settlement Coin =   Banking Settlement Coin.  


Die ganze Diskussion die hier geführt wird ist einfach nur überflüssig da es sowieso nichts Bringt da Borgstream jedes On Chain Scaling verboten hat für Bitcoin.  


Bitcoin war der Cia undercover Push die Blockchain Tech in die Public zu releasen und ETH wird jetzt zum Future Internet Money aufgebaut womit sie dann die Rfid Chips in der Zukunft verbinden.  Wird ja alles schon getestet mit der UN und den Refugees.

ETH hat quasi alle Globalisten Companys der Welt hinter sich und wird das neue Facebook des Blockchain Space .

Bitcoin wird das Myspace werden bzw ist es schon Technisch gesehen.

Ich wollte mal von meiner Exodus Wallet 86 Coins verschicken nachdem ich ein paar tausend LTC an Dumb Segwit Hype Victims abgeladen habe und Exodos möchte 47 USD Network Fees haben damit ich 70 BTC  versenden kann .  

 

Und dort gibts keine möglichkeit Fees anzupassen im interface. Da bei allen anderen Coins solch Probleme unbekannt sind wurde sowas nicht mit eingebaut . 


Bitcoin ist echt Done . Genauso unbeweglich& teuer wie Gold mittlerweile.

Der Sinn dahinter ist ja erstmal Segwit mit dem höchstmöglichen Konsens durchzubringen. Man könnte es ja mit BIP 149 kombinieren, denn wenn die Hälfte der BU-Pools den Vorschlag gut findet, hätte man eine komfortable Mehrheit für den UASF und ein Chainsplit wäre weit unwahrscheinlicher.

Was natürlich angemerkt wurde im dortigen Faden ist dass er vielleicht nicht allzuviele Big Blocker anziehen könnte - Small Blocker dagegen dürften kaum Probleme damit haben. Aber wenn der UASF oder sogar die Nuclear Option im Hintergrund droht, könnte es ja dazu kommen, dass man als Big Blocker das kleinere Übel akzeptiert.


Hört sich plausibel an, kann ich im dortigen Thread gerne weitergeben (oder du äußerst dich).

Ja - erinnere mich mal, dass es ein Deck gab von Roger Ver, allerdings ohne Quellenangaben und ohne Kontext und ohne Zeitangabe, von wann diese Aussagen stammen - ggf. sind diese Aussagen veraltet und die betreffenden Personen haben ihre Meinung geändert?
Edit: Quellenangaben sind doch unten auf den Slides - naja werde ich mir mal in Ruhe durchlesen
https://www.docdroid.net/NG1sbVq/pantera-march-2017.pdf.html

Aber was weiß ich? Segwit hat einen Witness Scaling Factor größer 1, was bedeutet, dass der verfügbare Blockspace mit Segwit erhöht wird.
Taten sind für wichtiger als Worte, und das zeigt für mich zumindest, dass die Segwit Macher aktuell etwas gegegen volle Blöcke machen wollen.

Ich bin zumindest der Meinung, dass eine gewisse Fee wirkungsvoll gegen Spam schützt. Die sollte eben in dem Rahmen liegen, in dem es einen nicht wirklich stört, also unter 50 cent / Tx.
Jeder einzelne 1 € Kaffee muss nicht wirklich in die Blockchain (siehe /r/btc Thread neulich)

Aus meinem Studium weiß ich aber auch, dass Systeme die an der Kapazitätsgrenze arbeiten und nicht konstante Verarbeitungsgeschwindigkeit aufweisen (hier Blockzeit) sehr unvorhersehbar reagieren.
Das kann man ja ganz leicht mit einer diskreten (/eventbasierten) Simulation nachweisen, ohne das man die Mathematik dahinter verstehen muss.

Volle Blöcke mit dem aktuellen Mining Prozess ist wirklich suboptimal. Mit Bitcoin-NG könnte ich mir das besser vorstellen. Aber auch da bleibt es schwer, weil man beim Senden der eigenen Tx abschätzen muss, was alle anderen Menschen auf der Welt für Tx demnächst senden werden, um die eigene Gebühr richtig zu setzen.

Abgesehen davon fühle ich mich als Benutzer von den Minern missachtet.
Das Core oder Blockstream Segwit für irgendwas in der Zukunften brauchen mögen ist mir doch egal.
Mein Eindruck ist, dass deutlich über 80% aller Bitcoin Nutzer Segwit nutzen möchten.
Ich als Benutzer will es haben - die Miner sind doch keine Dienstleister gegenüber Core oder Blockstream, also sollten die doch bitte im Sinne der Nutzer handeln.
Einige Miner weisen leider ein Verhalten auf, wo ich mich frage, für wen die Minen wollen.
Wenn die Miner sich so auf Core fixieren (HongKong Agreement) kommt das bei mir so an, als ob wir Nutzer unwichtig sind.

Am Ende sind doch wir Nutzer die Entscheiden, ob wir Bitcoin benutzen wollen.


Also meiner Meinung nach macht es einen Hard-Fork nur schwerer, wenn sich zeigen sollte, dass Segwit ausreichen sollte und LN Software verfügbar ist und zufriedenstellend funktioniert.
Wenn man das Gegenteil zeigen könnte, würde dies meiner Meinung nach die Argumente für einen Hard-Fork stärken.
Bis dahin ist Segwit eben die einfacherer auszurollende, besser getestete, sowie technisch elegantere Lösung.

Und für den Fall, dass Blockstream sagen würde - ihr müsst jetzt leider alles weitere auf unserer Elements Sidechain machen und dafür bezahlen würde sich automatisch ein Sturm der Entrüstung ausbreiten, der einem Hard-Fork breite Unterstützung zusichern würde. Aber solange das nicht eintritt bleibt das nicht mehr als eine Verschwörungstheorie.

Je länger man aber Segwit nicht aktiviert, desto schwächer sehe ich die Argumente für einen Hard-Fork. Wenn man lang genug wartet haben wir bald die LN-Software, andere Sidechains und ggf. Extension-Blocks.

Das Spam-Limit hat überhaupt keine Bedeutung im Rahmen eines HFs - siehe auch Bitcoin-Dev Mailingliste diesen Monats - Diskussion von Sergio Lerner. Im Rahmen eines Hard-Forks kann man doch alles ändern, was man will.
Andersrum - das macht doch einen HF einfacher zu verkaufen, weil man die Magic Numbers loswerden kann die man für den Softfork als Übergangslösung braucht.

Und zu den Validierungszeiten.
Eine Transaktion mit 200 Inputs erzeugt einen Berechnungsaufwand bei den Signaturen von 40000 Inputs.
Mit der Rechenzeit kann man also bereits die Signaturdaten von über 1 MB Segwit Transaktionen locker abdecken.
Soweit ich weiß ist aktuell bei CPU-Zeit der limitierende Faktor immer noch die Signaturoperationen.
Das heißt Segwit schafft da die Möglichkeit für einen Hard-Fork hinsichtlich der CPU Validierungszeit sub-linear zur Blockgröße zu skalieren.

Kurz noch zum pruning:
Man muss ja eine gewisse Menge an Blöcken vorhalten bei einem geprunten Client, damit man auch einen Reorg verarbeiten kann.
Mit Segwit kann man allerdings auch da schon die Signaturdaten prunen und sich trotzdem sicher sein, dass die lokalen Transaktionsdaten noch intakt sind. Somit kann man auch auf einem Gerät mit eingeschränktem Speicherplatz leichter wesentlich große Blöcke verarbeiten.

Für mich macht Segwit deswegen in Summe einen Hard-Fork viel einfacher. Soweit ich weiß haben ja auch viele Core Developer gesagt, dass für die Segwit ebenfalls eine Voraussetzung für einen Hard-Fork für die erhöhung der Blockgöße sehen, vielleicht deswegen.

@MoinCoin

Es gab mal eine Folie von Roger Ver mit Zitaten von Team Blockstream, dass volle Blöcke klasse sind. Mit dabei: Pieter Wuille, Gregory Maxwell: Auch Wladimir van der Laan, der ja nicht bei Blockstream ist. Jedes Zitat lässt nicht den geringsten Zweifel, dass kleine / volle Blöcke von manchen als Design-Entscheidung erwünscht sind.



Nein, vielleicht, nein.

SegWit macht eine HF nicht einfacher, sondern viel schwieriger. Siehe 4MB-Spam Limit + 2 Magical Numbers in Blockweight-Gleichung. So etwas macht eine HF garantiert nicht leichter. Ich vermute sogar so gut wie unmöglich.

Zweites Nein: Pruning geht heute wie mit SegWit. Macht keinen Unterschied. Angeblich ist es einfacher, mit SegWit ohne Verifizierung zu minen, aber das ist ein anderes Thema. Auf Pruning hat SW keinerlei Einfluss. Ist aber eine seit langem zirkulierende Falschaussage.

Vielleicht: Was meinst du mit "Worstcase Validierunugs-Zeiten für den Block viel geringer"? Quadratic Scaling?

Ist wieder einiges passiert in letzter Zeit - ich versuch mal etwas aufzuholen

lol ihr seid lustig. Bin noch weit davon entfernt, das ich mich selbst als technischen Profi bezeichnen würde. Aber schön, dass es euch nützt, was ich schreibe und wohl auch noch einigermaßen verständlich ist.

Und zu dem Vorschlag. Finde den recht interessant. Selbst, wenn man den Algo durch einen Spam-Angriff austricksen will sind die Auswirkungen gering genug.
Meine Meinung ist, dass wir mit den Hauptblöcken sehr konservativ umgehen sollten was Blockspace angeht um die Dezentralisierung nicht zu gefährden.
Ich habe aktuell Zweifel, ob Moores Law in seiner jetzigen Form bestehen bleibt, von finde ich eine lineare Skalierung interessant.

Die Frage bleibt, findet sich eine ausreichende Mehrheit dafür? Und meine persönliche Meinung ist, dass wir so wie Bitcoin aktuell funktioniert eher 1 Jahr braucht, bis man einen Hardfork aktivieren kann, nachdem wichtige Clients die Software rausgebracht haben. Wird dann wohl frühestens 2019 was.

Paar kleine Anpassungen sind sicher auch nicht schlecht, zum Beispiel, dass man für die alten Transaktionen mit dem quadratischen Rechenaufwand für Signaturen weiterhin insgesamt nur 1 MB pro Block maximal zulässt und den zusätzlichen Speicherplatz nur linear skalierenden Transaktionen (z.b. Segwit) gestattet. Ich weiß, dass es nicht quadratisch zur Blockgröße ist, aber das alte Design von Satoshi ist einfach schlecht und man kann so viel Rechenzeit sparen, ohne das irgendwelche alten Transaktionen ungültig werden und so dem Zentralisierungs-Effekt entgegen wirken. Wäre mal interessant zu wissen, wie der Faktor ist für Worst-Case 1 MB Block mit alter TX und Worst-Case Block mit 1 MB an Segwit TX. Denke das wir da irgendwo zwischen Faktor 100 und 100000 liegen, die Segwit schneller ist - hat da irgendwer Daten?

Kurzer Abschweif:
Bei Extension Blocks halte ich persönlich die Auswirkungen von Zentralisierung für beherrschbar. Wir haben ja immer noch die dezentralisierten kanonischen Blöcke die weiter jeder benutzen kann. Das ist übrigens auch das einzige was mich an dem Purse/Bcoin Vorschlag stört. Fände es besser da aggressiver zu sein und  in die vollen gehen und den Code so designen, dass man direkt auf 20+ MB Blockgröße bei Bedarf wechseln kann (statt max 6MB).

Hallo Christoph,
welche Macher meinst du denn? Hast du irgendwelche Nachweise?
Eric Lombrozo?
Johnson Lau wohl kaum, so viel wie der mit Hardforks und Extension Blocks forscht?
Pieter Wuille?
Gmax? Hat soweit ich weiß Segwit nicht implementiert, und zudem hatte er diese Woche noch auf Reddit geschrieben, dass er volle Blöcke für nicht notwendig hält, damit Bitcoin ökonomisch stabil ist.
Adam3us programmiert ja sowieso nicht für Bitcoin hat nichts mit Segwit zu tun.
Der einzige, der verbleibt ist Luke-Jr. Aber ist der ein Segwit-Macher? Soweit ich weiß hat er nur die Idee beigetragen, Segwit als Soft-Fork möglich zu machen. Davon abgesehen hat er ein paar komische Ansichten bzgl. voller Blöcke und Spam, aber die sind meiner Meinung nach überhaupt nicht repräsentativ für Core.

Und was hat das damit zu tun, das wir in Zukunft auch volle Blöcke haben? Segwit macht doch einen Blocksize Hard-Fork viel einfacher. Man hat dann im Hardfork die Worstcase Validierungs-Zeiten für den Block viel geringer zu gestalten. Und mehr prunen kann man auch, also kann man so die Hardwareanforderungen im Vergleich zu einem einfachen Blocksize Hard-Fork viel geringer gestalten.

Und mittlerweile gibt es auch so viele Programmierer die sich mit Segwit auskennen - sogar ViaBTC kennt sich ja jetzt dank Litecoin mit Segwit aus.

Hatte gestern etwas Glück, dass meine Transaktionen noch durchgegangen sind.
RBF ist aber auch nciht so einfach. Hatte eine TX mit 130 Sat/Byte, wollte auf 150 Sat/Byte erhöhen, Bitcoin-Core hat mich das aber nicht Broadcasten lassen - hat mir nur eine Fehlermeldung zurückgegeben, dass die Fee zu gering sei. Glücklicherweise ist es dann doch nach einer Stunde bestätigt worden.

Und zum Schluss gibts sogar mal was neues von BU - da kommt ja sonst nicht so oft was letzter Zeit
BUIP055: Increase the Block Size Limit at a Fixed Block Height
Macht es denke ich auch möglich sich besser vor einem BU Hard-Fork zu schützen.

Edit:
Hatte vor ein paar Tagen kurz zur Segwit Aktivierung über BIP8/BIP149 geschrieben, hat noch niemand hier im Tread was dazu gesagt. Würde mich freuen zu hören, was ihr darüber denkt.
Damit würde man sich ja die Nuclear-Option sparen - die Miner müssten die Spaltung der Blockchain aktiv herbeiführen.
Wesentlich sauberer als BIP148. Der einzige Bekannte, der für BIP148 noch trommelt ist soweit ich weiß Luke-Jr.

Ich erwähne mein persönliches Maximum gern, das 266 Tage durch die Mempools geisterte (unregelmäßig durch Core selbst gepusht).
https://blockchain.info/tx/8e2e0cdbce7663e6a269a5a09222c7101c2d15fa59ed2f33406f167bd86ff8b8
(Die Lock-Zeit ist original und unverändert)

Die Coins sollten zu Bittrex, ich weiß nicht wie die Frist bei denen ist. Geschickt wurden sie von blockchain.info, bei denen ist ein nachträgliches RBF anscheinend nicht mehr verfügbar (dachte sowas dort mal gesehen zu haben).
Gibt es eigentlich Erhebungen zu den Transaktionen die am längsten gedauert haben? 

Im Großen und ganzen ist das, soweit ich das beurteilen kann, korrekt beschrieben.

Allerdings fehlt ein Hinweis auf den größten Trumpf, den die Core-Verfechter in der Hinterhand haben: die "nuclear option", also ein Wechsel des PoW-Algorithmus, so dass die Miner-ASICs wertlos werden. Man könnte theoretisch sogar zu PoS wechseln, wenn man Angst hätte, dass die Miner schnell eben mal neue Mining-Hardware kaufen (FPGAs?) um die Chain mit dem "neuen PoW" zu zerstören.

Andererseits handelt es sich bei der "nuclear option" dann schon um eine derartige Eskalation, dass der Bitcoin sicherlich auf die eine oder andere Weise davon Nachteile davontragen wird. Da ist mir eine Kompromisslösung wie oben beschrieben lieber.

(PS: Das bezieht sich nur darauf, dass die PoW-Änderung von einer Gruppe gegen die andere durchgesetzt wird, um Segwit durchzuboxen. Gibt es dagegen weitgehenden Konsens - man könnte es ja lange vorher ankündigen, damit die Miner sich auch drauf einstellen können - bin ich sogar für eine PoW-Änderung).

das nicht, aber man kann sie nicht für eine andere bezahlung nutzen solange sie unbestätigt sind und nicht ins wallet "zurückgeholt" wurden. also das guthaben verringert sich schon erst mal.

und dann gibt es dienste welche eine bestimmte frist für eine bezahlung setzen bis die bitcoins eintreffen müssen. die haben jedoch teilweise schon auf die geänderten bedingungen reagiert und die zeitspannen erhöht.

bitmixer.io oder bitpay.com zum beispiel. bitmixer.io hat von 2h auf 24h erhöht. da kann man schon mal ins schwitzen kommen. wenn man jedoch gleich von anfang RBF aktiviert kann man auch erst mal mit kleineren fees arbeiten und abwarten wie schnell die tx in einen block aufgenommen wird. dann erhöht man schrittweise die fee wenn man eine schnellere bestätigung braucht.

EDIT: ich persönlich arbeite mit Electrum + Trezor und kann das nur jedem empfehlen.

Danke für den Tip. Panic habe ich keine, die Coins können ja schlecht verschwinden.

am besten immer mit RBF die fee schrittweise erhöhen. geht mit Electrum sehr gut. da kommt keine panic auf.

Ihr wisst doch, die SegWit-Macher finden nicht, dass volle Blöcke ein Problem sind, und SegWit ist ein guter Schritt dahin, dass wir auch in Zukunft volle Blöcke haben 

Da wir hier immer über die Rolle von Nodes und Minern diskutieren, habe ich etwas darüber geschrieben: Das Ying und Yang von Bitcoin ...

https://bitcoinblog.de/2017/05/11/das-ying-und-yang-von-bitcoin/

Beschreibt auf relativ grobe, einfache Art, welche Rollen Miner und Nodes haben. Bin offen für jede Diskussion --

Ja, von mir hängen seit gestern abend auch 2x1 BTC mit jeweils 0 Bestätigungen fest  

weiss man bei Litecoin nach erfolgreicher SegWit aktivierung wie jetzt mit LN weitergemacht wird?

EDIT:
ca. 125k unbestätigte tx im moment bei 4.64 tx/s--> https://blockchain.info/unconfirmed-transactions
fees jetzt bei ca. 100 sat/Byte --> http://bitcoinfees.21.co/

Ja.


Die Blocksize-Erhöhung ist ein Hardfork und braucht daher nicht die Zustimmung von 95%, auch wenn eine möglichst hohe Zustimmung natürlich wünschenswert ist. Ob ein Segwit-Softfork mit 95% (bzw. als UASF) dem Hardfork vorgeschaltet wird oder Segwit ebenfalls mit dem Hardfork aktiviert wird, geht glaube ich aus dem Text nicht hervor.

Ich glaube um die exakten Details der Einführung wurde noch nicht diskutiert - das ganze ist noch kein ausgearbeitetes BIP, sondern erst mal nur eine Basis für einen Vorschlag. Der Initiator ist mir aber als konstruktiv und wohl auch kompetent aufgefallen, auch wenn er kein Core-Dev ist.

+1

Klingt beim ersten lesen für mich gut, wegen der Anti-Spam Anpassung.
Ist ein Kompromiss der die Einführung von SegWit voraussetzt?
Ist ein Hardfork? Auf Basis 95% Miner-SegWit Einführung?
Weiß noch nicht was ich davon halten soll.
Wenn ich's falsch verstanden habe Bitte immer gern Korrektur.

Und jetzt bitte Austausch der technischen Profis.
Am besten verstehe ich immer wenn Mezzo und MoinCoin diskutieren.

Hier ein neuer Vorschlag für eine Blocksize-Erhöhung nach der Einführung von Segwit. Er ist ähnlich BIP 100, aber noch einmal eine Spur konservativer.

Pro Difficulty-Periode darf die maximale Base-Blocksize (die ja wegen des "quadratic hashing time"-Problems wichtig ist, da nur Segwit-Transaktionen den Rest der Blocksize nutzen) um 10 kB steigen (also maximal ~270 kB pro Jahr), aber nur dann, wenn die Blocks über 90% voll sind und die Gesamt-Fees höher liegen als in der vorigen Periode. (Sie darf umgekehrt auch fallen, wenn die Blocks leer sind). Die Gesamt-Blocksize (Base + Weight) steigt um maximal etwa 1 MB pro Jahr, ebenfalls linear.

Die Blocksize-Erhöhung bleibt linear (im Gegensatz zu BIP 103), ist damit sehr gut zu kontrollieren, und Spam-Attacken für eine signifikante Erhöhung der Blocksize werden extrem teuer.

Ich betrachte es als ein Art Hard-Fork, da entweder der eine oder der andere Zweig gültig ist. Man könnte es auch User-Fork oder irgendwie anders nennen, denn tatsächlich ist es weder ein Hard-Fork noch ein Soft-Fork.

Eine PoW Änderung würde das Problem ebenalls lösen, nimmt aber auch die nicht feindlichen Miner aus dem Spiel.

@mezzo
Okay - also dann doch eher manuell.
Das Muster ist zumindest nicht BU, denn die wollen ja Hardforken.
Wenn irgendwelche Pools die alte Chain zusätzlich killen wollen vielleicht.

Das mit der Marketingkampagne wird schwierig..
Da müssten sich so viele miteinander verschwören, damit viele darauf reinfallen würden.
Ein staatlicher Akteur, der das Internet in seinem Land zensieren kann, hätte vielleicht den Hauch einer Chance, aber nur in seinem Land. Außerhalb kann ich mir das schwer vorstellen.

Kannst du mir erklären was du da mit Hardfork meinst? Die Validationsregeln werden doch nicht aufgeweicht oder inkompatibel mit den alten Regeln.
Chain split != Hardfork

Für mich ist das ganz klar ein Softfork.
Entweder man sagt, dass Block X ungültig ist, wenn er nicht einen bestimmten block hash hat, oder man sagt, dass Block X ungültig ist, wenn er einen bestimmten block hash hat. Beides sind Verschärfungen der Validierungsregeln und damit ein Softfork.

Bei einem Hardfork müsste man ja auch die Software updaten.

Ich denke im Fall eines Angriffs muss man eben als Nutzer auf der Hut sein und sollte auch ruhig mal einen Tag warten bis man eine Tx als bestätigt ansieht. Miner müssen wirklich aktiv arbeiten und sich untereinander abstimmen, damit Sie mit Ihrer Hashpower an der gleichen Chain arbeiten.

Wahrscheinlich wird ein Wechsel weg vom aktuellen PoW sinnvoll, denn der Angreifer könnte immer wieder neue (kurze) Attacken starten.