Das ist nicht ganz falsch, aber auch nicht so richtig hilfreich. Vielleicht orientierst du dich zu sehr an den Bitcoin Transaktionen?
Versuche lieber mal die übergeordneten Vorgänge zu erfassen, das ist viel einfacher und absolut ausreichend.
Wie die Bitcoin Transaktionen aufgebaut sind ist teilweise recht kompliziert und hilft nicht wirklich weiter.
Zu jedem Vertrag werden nämlich mehrere verkettete Bitcoin Transaktionen erstellt.
Diese Transaktions-Ketten bilden aber wiederum nur die Verträge zwischen den einzelnen Handelspartnern ab.
Es reicht deswegen erstmal sich rein auf die Verträge zu konzentrieren, da die Bitcoin Transaktionen eben diese nachbilden.

Vereinfacht funktioniert es so:
Szenario:
Alice - Hub - Bob
Alice will Bob eine Zahlung über x Bitcoins senden - beide haben einen offenen Channel mit dem Hub mit genügend freier Kapazität.
Zur Absicherung der Zahlung holt sich alice einen Hash des Geheimnisses (Preimage) von Bob.

1. (Abschnitt ist noch nicht ganz korrekt, überarbeite ich bei Gelegenheit) Alice und Bob schließen einen übergeordneten Vertrag (Dieser Vertrag erzeugt also im Gegensatz zu den anderen Verträgen keine eigenen Bitcoin Transaktionen), dass Alice eine Schuld über x Bitcoins begleichen kann, unter der Voraussetzung, dass Alice es schafft Bob einen Vertrag zu vermitteln, der es wiederum Bob erlaubt das Geheimnis für x Bitcoins innerhalb von einem Tag zu verkaufen.
Anstelle der Zahlung (Lieferung von Bitcoins) tritt also ein Vertrag, der es dem Gläubiger (Zahlungsempfänger) ermöglicht auf anderem Wege die Leistung (Lieferung von Bitcoins) zu erlangen.
Die direkte Zahlung wird also durch eine Forderung auf Bitcoins an eine andere Person ersetzt.

2. Alice handelt einen Vertrag aus mit dem Hub:
Ich verpflichte mich dir x+Fee Bitcoins zu senden, wenn du mir dafür verrätst, wie das Geheimnis für diesen Hash ist.
Wenn du mir das Geheimnis innerhalb von zwei Tagen nicht sagst, dann ist der Vertrag ungültig und ich muss ich dir keine Bitcoins senden.
Alice gibt dem Hub noch eine Information, dass Bob das Geheimnis für x Bitcoins verkauft. Der Hub ist aber nicht verpflichtet das Geheimnis dort zu kaufen.
Der Hub nimmt den Vertrag von Alice an, schließlich kann er ja nur gewinnen.

3. Der Hub handelt freiwillig einen Vertrag mit Bob aus:
Ich verpflichte mich dir x Bitcoins zu senden, wenn du mir dafür verrätst, wie das Geheimnis für diesen Hash ist.
Wenn du mir das Geheimnis innerhalb von einem Tag nicht sagst, dann ist der Vertrag ungültig und ich muss ich dir keine Bitcoins senden.
Bob nimmt den Vertrag an, schließlich will er bezahlt werden.
Aber warum handelt der Hub den Vertrag mit Bob aus?
Der Hub kann Gebühren verdienen und dies ist der einzige Weg, den er kennt um an das Geheimnis zu kommen.
Das Geheimnis muss er zwar für x Bitcoins kaufen, aber er kann das Geheimnis ja für x+Fee Bitcoins weiterverkaufen, handelt also im eigenen Interesse und nicht, weil er Alice einen Gefallen tun möchte. Auch ist dem Hub aus ökonomischen Gesichtspunkten erstmal egal, ob Alice irgendwen anders bezahlen will, oder was das alles soll.
Der Hub sieht nur, dass er etwas kaufen kann, dass er zu einem höheren Preis wieder verkaufen kann.

4. Erfüllung der Verträge
Alice fragt bei Bob nach, ob er einen gültigen Vertrag hat, dass er x Bitcoins für das Geheimnis bekommt, welches zu dem Hash gehört, Bob bestätigt.
Bob verrät dem Hub das Geheimnis und erhält x Bitcoins vom Hub - Der Vertrag zwischen Bob und dem Hub ist erfüllt.
Der Hub verrät Alice das Geheimnis und erhält dafür dann die x+Fee Bitcoins - Der Vertrag zwischen dem Hub und Alice ist erfüllt.
[Alice verrät Bob das Geheimnis, damit hat Alice Bob einen Wert von x Bitcoins übereignet. Das weißt auf jeden Fall nach, dass der übergeordnete Vertrag zwischen Alice und Bob erfüllt ist.]* (Muss ich noch mal im Protokoll nachlesen, ob dieser Schritt stattfindet)

Und ganz wichtig: Es gibt keinen Kredit, da die Verträge voneinander unabhängig sind.
Bob kann, muss aber nicht dem Hub das Geheimnis verraten. Er wird das natürlich tun, damit er die x Bitcoins erhält.
Auch dem Hub steht es frei, ob er Alice das Geheimnis verrät und somit die Lieferung der Bitcoins auslöst. Auch der Hub will natürlich seine Bitcoins haben, vor allem, weil er bereits Bob bezahlen musste.
Grundsätzlich hat Alice alle Verpflichtungen gegenüber Bob erfüllt, sobald sie Bob den Vertrag vermittelt hat.
Damit Alice auf dem normalen Weg an das Geheimnis kommt müssen natürlich alle die Verträge erfüllen.

Und kurz noch zur Privatsphäre:
Tatsächlich weiß der Hub nicht, dass Bob der endgültige Zahlungsempfänger ist, weil Bob auch wieder einen Vertrag mit dem gleichen Hash hätte haben können, da Alice dem Hub nur verrät, das Bob vor ihm das Geheimnis weiß, aber nicht woher.
Nur die beiden Endpunkte wissen, wer tatsächlich die Zahlung sendet/erhält.

Die Bitcoin Transaktions-Ketten sind so gebaut, dass ein Schummeln ausgeschlossen wird. Es handelt sich um harte Versprechen. Allerdings wird dazu Segwit gebraucht, bzw. ein txid-malleability-fix.
Das Schlimmste was beim aushandeln der Verträge passieren kann ist, dass man diesen einen Tag warten muss bis alles zurück abgewickelt wird, wenn irgendjemand unkooperativ war und auch bei der Rückabwicklung bleibt.
Bei einem Scheitern kann man jedoch sofort einen neuen Versuch mit einem neuen Geheimnis versuchen, soweit die Kanäle noch genug freie Kapazität haben.
Das Schlimmste, was nach dem aushandeln der Verträge passieren kann, ist dass man nicht Off-Chain, sondern über den Umweg On-Chain die Verträge abwickeln muss.

Was die Bafin entscheidet - wer weiß .
....
So habe es jetzt einige Male umgeschrieben.
Hoffe jetzt ist es wirklich einfach verständlich geworden und klar warum die einzelnen Teilnehmer so handeln, wie sie es tun.

Werde in nächster Zeit (2-3 Monate) leider weniger online sein.
Wenn es was wichtiges gibt -> PM an mich
Danke  

Naja - in den letzten 2,5 Tagen waren das immerhin 20k BCH, die da zusätzlich auf den Markt gekommen sind.
Immerhin 12 Mio €.
Zugegeben ist das nicht viel, aber auch nicht verschwindend wenig.

Also das die Hashrate dem Preis folgt haben wir gesehen.
BCH war lohnender zu schürfen -> BCH Hashrate steigt.

So jetzt kommt der umgekehrte Effekt:
Kurzfristig:
BCH Hashrate steigt -> Mehr BCH werden geschürft -> Miner verkaufen mehr BCH -> BCH Preis sinkt

Langfristig könnte es aber durchaus auch einen Effekt geben, dass auch der Preis der Hashrate folgt, denn schließlich heißt das, dass die Kette sicherer ist und somit für mehr Leute interessant.

Ich denke der stärkste Effekt ist eindeutig das die Hashrate dem Preis folgt, schließlich wollen die Miner Profit machen
Bei ViaBTC konnte man wunderbar sehen, wie schnell die Hashrate jetzt wieder zu Bitcoin zurück kommt.
Hoffe das gibt dem BTC einen kleinen Preisschub

Also so richtig Sinn ergibt das nicht für mich, so wie du das schreibst.
Wenn du so argumentierst, dann musst du aber auch beachten, dass der Hub kurz vorher eine gleiche (größere) Menge an Bitcoins bekommen hat, bevor er diese weitergibt (also nach deiner Logik einen Kredit erhalten hätte)- abgesehen davon kann ich immer noch nicht erkennen, wie das ein Kredit sein soll.
Die Bitcoins werden tatsächlich übereignet. Ansonsten wäre On-Chain ja auch immer ein Kredit.

Vielleicht kannst du das mal etwas ausführlicher darlegen.

Ein Hub könnte durchaus als Zahlungsdienstleister eingestuft werden, aber niemals werden Bitcoins übereignet und dabei ein Schuldverhältnis erzeugt.
Ohne das Preimage ist die Transaktion ungültig.
Keine gültige Transaktion - Kein Kredit.

Edit:
Vor allem - der HTLC ist ja auch so konstruiert, dass wenn was schief geht, der Hub die Bitcoins wieder erhalten würde, ohne, dass die Gegenseite was dagegen tun könnte (passiert immer, wenn das Preimage nicht veröffentlicht wird).
Wenn es ein Kredit wäre, dann wäre dieser Umstand nicht möglich.

Das ist doch eher ein Vertrag - Wenn du mir diese Information lieferst, dann liefere ich dir diese Bitcoins.
Oder man könnte es auch anders sagen - der Hub kauft für x Bitcoins das Preimage in dem einen Channel und im anderen Channel verkauft er das gleiche Preimage für x+Fee Bitcoins.
Da die Lieferungen/Leistungen und Zahlungen (Erfüllung der Forderung) gleichzeitig erfolgen sehe ich auch hier keinen Kredit.
Das Preimage erhält praktisch einen Wert, der genau den zu sendenden Bitcoins entspricht.
LN Paper Seite 30 und Seite 34

Edit2:
Das ganze könnte eher steuerrechtlich interessant sein - also ob das jeweils ein fiktiver Kauf und Verkauf von Bitcoins ist, wenn man gleichzeitig Bitcoins in einem Channel empfängt und dafür im anderen weitergibt, oder ob man dort ein Netting durchführen darf, wie die erhaltenen Gebühren zu versteuern sind - und wie sich das auf die Haltedauer 1 Jahr / 10 Jahre auswirkt.

Sehe ich auch so - Zum senden und empfangen wird man es allerdings unabhängig nutzen können, solange man nur Channel zu einer anderen Person/Hub offen hat, kann man auch keine rechtlichen Probleme bekommen - und der Hub muss ja nicht in Deutschland sitzen, ist also rechtlich auch unproblematisch / lösbar.

Das mit den Krediten müsstest du mir mal erklären. Die Bitcoins die im Channel sind gehören ja trotzdem der Person, welche diese in den Channel gebracht hat.

Meinst du die HTLCs? Das ist ja eher ein Vertrag "Lieferung von Bitcoins gegen Lieferung von Bitcoins".
Die sind ja zunächst ungültig und werden dann durch die Veröffentlichung gleichzeitig gültig, also auch da nicht wirklich ein Kredit.

Nein - Erstmal ist covert ja sowieso "covert", also nicht direkt nachweisbar.
Und CSW hat ja zum Beispiel auch gesagt, dass er keine Segwit Transaktionen schürfen wird.
"Vertraut uns - wir benutzen kein ASICBoost, wir hassen nur Segwit."

Antpool schürft im Augenblick auch wieder fleißig fast leere Blöcke - aber nachweisen, dass das covert ASICBoost ist - schwierig.

Covert ASICBoost wird ja vor allem schwerer, weil sich immer die Coinbase Transaktion ändert, durch das Witness Commitment - und dadurch der linke Teil des Merkle-Trees.
Es ist eben nicht mehr so effizient die Transaktionen zu vertauschen und zu permutieren um Kollisionen zu finden, funktioniert aber grundsätzlich auch weiterhin.

Grundsätzlich ja.
Wie gesagt - bei Bitcoin Cash lohnt sich ASICBoost auf jeden Fall.

Wenn wir Segwit haben und das breit verwendet wird, dann lohnt sich ASICBOOST wahrscheinlich kaum bzw. nicht. (ob es sich wirklich nicht lohnt - ohne Gewähr - müsste man noch mal genau nachrechnen, grundsätzlich ist es aber die Situation, in der es sich am wenigsten lohnt)

Mit Segwit2X wird es sich bis auf weiteres definitiv wieder lohnen ASCIBoost einzusetzen.

Zunächst funktioniert ASCIBoost auch mit Segwit, eben nicht mehr so effizient.
Und zweitens braucht man ja keine Segwit Transaktionen mit in den Block aufnehmen, oder produziert einfach direkt (fast) leere Blöcke.

Die Frage ist eben, was man an Strom spart (z.B. 20%) und so entweder weniger Kosten hat, oder zusätzlich an Ertrag/Hashleistung generieren kann. 100%/(100%-20%) wären 25% mehr Hashleistung für die gleiche Energiemenge, wenn man zum Beispiel durch Kühlung bzw. Menge der zur Verfügung stehenden elektrischen Leistung begrenzt war.

Ist ein Rechenspiel, wieviel man dafür weniger Transaktionen in Blöcke bekommt und deswegen weniger Ertrag hat und wieviel man sparen kann.
Je niedriger die Transaktionsgebühren sind, weil die Blöcke nicht voll sind, desto mehr lohnt sich ASICBoost.

Bitcoin Cash und Emergent Consensus Blocksize bieten optimale Bedingungen für den Einsatz von ASICBoost.

Das ist ja nur ein Problem, weil nicht jeder ASICBoost einsetzen kann, vor allem nicht kleine private Miner.

Ja - Gegen Antbleed kann man sich mit einem Workaround schützen, indem man dafür sorgt, dass die Verbindung nicht aufgebaut werden kann.
Das Problem endgültig lösen kann man aber wie du selbst schreibst nur indem man eine neue nicht betroffene Firmware flasht.
Bin da nicht ganz auf dem Stand - Weiß nicht, ob das endgültig gefixt wurde von Bitmain.
Jedenfalls hat Bitmain das alte Github offline genommen.

Auch interessant:
https://www.reddit.com/r/Bitcoin/comments/686rwq/also_latest_bitmain_firmware_fix_calls_home_sands/

Meine persönliche Meinung ist, dass das zwar ein Unding ist, aber es sehr unwahrscheinlich ist, dass das wirklich mal zu einem Problem wird.

Ich halte covert ASCIBoost für das größere Problem.
Das lohnt sich vor allem, wenn die Gebühren keinen wesentlichen Anteil an dem Block-Reward darstellen, also wir keine vollen Blöcke haben, da man dann auf weniger Ertrag verzichtet, sondern praktisch nur Vorteile durch den Einsatz von ASICBoost hat.

BCH hat mittlerweile einen nicht unwesentlichen Anteil der Hashpower > 25%
http://fork.lol/pow/hashrate
Soviel mal zu dem NYA, dass die über 90% der Hashpower hätten.

Schätze in weniger als 2 Tagen wird Bitcoin wieder wirtschaftlicher sein, als BCH.
http://fork.lol/pow/retarget

Huh das ist nicht ganz korrekt - es gibt noch die ScriptSig Malleability.
Dann wird aus der Transaktion zwar eine Non-Standard-Tx, wird also nur von Nodes weitergelteitet, die Non-Std-Tx explizit unterstützen, aber gültig bleibt diese trotzdem.
Vor allem Miner, können sowas machen - Vielleicht erinnert sich der ein oder andere noch an den Malleability-Angriff von Bitclub dieses Jahr.

Segwit Outputs sind jedoch vor der ScriptSig Mallebility geschützt, indem nur bestimmte Witness-Programme (ScriptSigs) gültig sind.


Du machst es dir auch gerne leicht. Unsicheres Off-Chain ist, was wir aktuell haben - Siehe Mt.Gox / Bitfinex - mit Segwit brauchen wir sowas nicht mehr und kommen davon hoffentlich langfristig weg.
Findest du das aktuelle unsichere Off-Chain schön?
Ich freue mich, dass wir mit Segwit vom unsicheren Off-Chain Scaling loskommen können.

Für eine Blockgrößenerhöhung mag SegWit vielleicht kompliziert erscheinen, insgesamt ist es das aber nicht, wenn man die ganzen anderen Vorteile mitnehmen kann.
Bis auf die Entwickler von Bitcoin Unlimited & Co. beschwert sich kaum jemand - und wenn man dann auf r/btc nachliest bekommt man mit, dass die meisten Entwickler und Leute die sich beschweren, dass es so kompliziert ist nicht mal die BIPs gelesen haben, also überhaupt nicht wissen, wovon Sie reden.
Unter den Gesichtspunkten finde ich Segwit überhaupt nicht kompliziert - also ja ich finde es schön.

Schön, dass Segwit uns beides gibt.

Weniger sicher sagt wer?
Die Frage ist ja, wie man die beste Kombination aus Sicherheit und Usability erreicht.
Nur mit größeren Blöcken (Bcash) hat man weder die bessere Usability noch die bessere Security.

Ich hab das Gefühl wir reden teilweise aneinander vorbei.

1. Unruhestifter können alles mögliche sein, Big-Blocker mögen ein Teil davon sein, aber es gibt ja noch andere Interessengruppen außerhalb von Bitcoin.

2. Bitcoin Cash Coins hört sich scheiße an. Vgl. Bitcoins geht einfach so - Bcash Coins finde ich noch erträglich - ich nutz das einfach als Abkürzung - jeder weiß was gemeint ist - wir schreiben ja auch BTC und BCH. Falls es zum Split kommt schreib ich möglicherweise auch Bcore  

3. Sehe ich auch so - es ist aber schon interessant, dass die Miner bereit sind mal eben so auf über 10+ Mio USD zu verzichten - Das Abkommen wurde sowieso zwischen irgendwelchen Pools geschlossen und nicht den Minern direkt und sowieso nicht mit der Community

4. Ich würde mir wünschen, dass man aufgrund der neuen Situation mit Bcash ernsthaft versucht einen neuen Kompromiss zu finden und einen neuen Anlauf wagt die Blockgröße zu erhöhen, aber sich dabei mehr Zeit lässt und Verbesserungen wie das Spoon-Net etc. einbaut. Wird wohl kaum passieren, aber man darf ja ein bisschen träumen. Ich denke, dass Segwit2X jedenfalls sein Ziel verfehlen wird bzw. schon verfehlt hat Bitcoin gemeinsam weiter zu entwickeln. Fürchte das wird im Chaos enden. Wenn sich die Transaktionen auf mehr Netzwerke aufteilen hat man sowieso automatisch die doppelte Transaktionskapazität, dann braucht man die Blockgrößen Erhöhung auch nicht mehr. Ethereum wird denk ich der Hauptprofiteur - Bcash und Litecoin Nebenprofiteure.

Danke - ohne mich - das andere Ende der extreme erzeugt auch wieder nur Zentralisierung.

Warum sollten Unruhestifter jetzt aufhören?
Ist doch gerade eine super Zeit um Chaos in Bitcoin zu stiften.
Technisch kann Bcash außer der Blockgröße kaum mit einem Bitcoin mit Segwit mithalten.
Und nur niedrige Transaktionsgebühren reichen langfristig auch nicht.
Im Vergleich dazu, was an (Opportunitäts-)Kosten für das Mining von Bcash anfällt ist doch alles andere extrem günstig.

Bleiben 1152 Blöcke in dem Zyklus - also 8 Tage normal - 80 Tage bei 10%.
14.400 Bitcoins sind das - oder bei aktuellem Preis 3000 €, 43,2 Mio € + die Fees.

Kommt eben auf den Preis an, wie dieser sich ergibt. Wenn der nicht hoch genug ist, ist eben die Frage ob es genug Miner gibt, die auf 20+ Mio € verzichten können.
Andersherum gilt das natürlich auch für Segwit2X.

... und Bcash konkurriert ja auch noch um die Hashpower.

Man könnte es sagen, es ist genau anders herum und sorgt dafür, dass die anderen Nodes nicht gebannt werden, bei dem Hard Fork.
Alle Core Clients sind sowieso inkompatibel mit Segwit2X, daran ändert sich nichts durch den neuen Code.

Das heißt zum Zeitpunkt des Hard Forks würden die Verbindungen sowieso getrennt - es könnte dazu kommen, dass viele Segmentierte Bitcoin-Netzwerke entstehen, die untereinander keine Verbindungen haben.
Man könnte also danach auch keinen anderen Client benutzen, vor allem nicht beide gleichzeitig, da das bannen sich immer auf die IP bezieht und nicht auf das IP:Port-Tupel.
Jedenfalls wäre es absolutes Chaos.

Die Änderung jetzt sorgt einfach dafür, dass die Verbindungen schon vorher sauber getrennt werden.
Das heißt man kann beide Clients gleichzeitig benutzen und statt dass sich die Nodes gegenseitig bannen wird die Verbindung vorher sauber getrennt.

Was man hätte machen können, wäre, dass die Verbindungen erst ein paar Tage vorher getrennt werden - aber so ist der Code einfacher.
Und so ist man unabhängig davon, ob btc1 seinen Hard Fork Zeitpunkt oder ähnliches noch mal ändert.
Core bis 14.2 und ansonsten BU und Classic und andere Clients sorgen sowieso dafür, dass bis zum kritischen Zeitpunkt extrem viele Brücken zwischen den Netzen bestehen.

Core kann gar keinen Krieg an btc1 erklären, weil der freie Markt entscheidet (die User), welche Software sie benutzen wollen.

https://en.bitcoin.it/wiki/Payment_channels
Das serialisierte Transaktionsformat hat auch as Feld "Sequence Number", das dafür ursprünglich vorgesehen war.

Naja - aber das Design war fehlerhaft.
Das feld wird jetzt für RBF und OP_CLTV genutzt, soweit ich weiß.

Okay okay... Sorry.
Wir haben wohl unterschiedliche Vorstellungen davon, wer/was für den Konsens wichtig ist.

Wie gesagt - ich bin der Meinung, dass wir bereits einen freien Markt haben und der sich aktuell aufgrund von mangelnden vernünftigen / belastbaren Alternativen auf Core festgelegt hat.
Das nicht alle damit zufrieden sind sehen wir daran, dass wir möglicherweise bald den nächsten Split mit B2X haben.
Allerdings sehe ich da wieder das Problem, das die Leute (NYA) keinen Konsens finden wollen, sondern einfach vorschreiben wollen, was Bitcoin zu sein hat.
So funktioniert das auch nicht.

Und was Luke-Jr und Adam Back so von sich geben, das widerstrebt mir auch sehr.
Bitcoin kann keine mehrere Hundert € Fees haben, solange es Alternativen gibt - das ergibt kein stabiles Nash-Equilibrium wegen der Altcoins.

Abgesehen von den vorgenannten Extremisten sieht kaum einer ein Problem in einer 2 MB Blockgröße, es geht rein um das wie und wann.
Und genau das ist auch meine Position.
Wenn ich Bitcoin nicht mehr vernünftig benutzen kann und keine vernünftige Entwicklung sehe, die das ändern kann, dann ist es Zeit andere Maßnahmen zu ergreifen und ein Konsens wird sich ganz natürlich entwickeln, der nicht von den Minern oder irgendeinem Unternehmenszusammenschluss diktiert werden muss.

Segwit ist jetzt gottseidank durch - LN mal schauen, wie das wird - Sidechains sind interessant - und Miner könnten es selbst in die Hand nehmen und Extension Blocks einführen.
Wenn die Miner das nicht wollen, dann ist das eben traurig und leider ein Beweis dafür, dass das Nash Equilibrium sehr schwer zu finden ist, weil extrem viele unbekannte Faktoren da rein spielen.

Etwas ähnliches sehen wir ja auch schon bei Bitcoin Cash - Die Miner haben mal eben 10 Mio USD versenkt um die Kette am leben zu erhalten.
Wer weiß wie da ASICBoost reinspielt. Das spielt ja für die Entwickler von Bitcoin Cash keine Rolle, bzw. die sehen das als Optimierung.

@CB
Und weil ich gerade bei Bitcoin Cash bin
Ich kann nicht verstehen, warum man da Segwit entfernt hat - es wäre so einfach gewesen die ganzen Vorteile mitzunehmen.
Es wäre so leicht gewesen ein paar Kleinigkeiten anzupassen an denen man sich stört - schließlich kann man bei einem Hard Fork alles ändern.
Immerhin hat man das Signatur Schema von Segwit mit übernommen, das hat einen großen Vorteil, dass Bitcoin Cash jetzt überhaupt nicht mehr unter dem Quadratic Scaling leidet.

Aber das ging wohl politisch nicht, schließlich braucht man irgendwie einen Feind, sonst hätte man ja keine Daseinsberechtigung.
Jetzt ergibt es auch im Rückblick Sinn, dass so eine konzertierte Kampagne gegen Segwit gefahren wurde, weil sonst hätte Bitcoin Cash kaum eine Daseinsberechtigung, Dank Segwit2X.
Traurig ist auch, dass es die Position von Segwit2X untergräbt.

Aber weil man es ja besser weiß, hat man jetzt schon mit Malleability Angriffen zu kämpfen - naja.
Um das später zu lösen, muss man dann später Segwit neu erfinden, außer das es nicht Segwit sein darf, weil Segwit ja böse ist.
Den Witness-Discount hätte man ganz einfach auf 0% setzen können - und das Witness Commitment hätte man auch einfach in den normalen Merkle-Tree aufnehmen können - dann wäre es auch besser mit ASICBoost kompatibel.

Die UAHF Roadmap ist interessant, aber es ist nur eine Roadmap, mal schauen was davon jemals umgesetzt wird.
Aktuell weiß man ja nicht mal, wer die Miner sind und die sind vor allem im Weltbild von Bitcoin Cash wohl sehr wichtig für Entscheidungen.
Ich habe allerdings wenig Vertrauen in die Entwickler in dem Umfeld, da diese sich für mich mit Aussagen über Segwit lächerlich gemacht haben.
Auch das neuerliche Debakel mit den Schnorr-Signaturen spricht nicht gerade für die Entwickler.
Etwas gestiegen ist mein Vertrauen immerhin dadurch, dass der Hardfork eine saubere Replay-Protection hat und auch für Lite-Clients sauber erkennbar ist durch die Difficulty-Anpassung.
Da hat man die wichtigsten Kritikpunkte angepackt - Deswegen habe ich auch aktuell nur einen Teil meiner BCH verkauft, ist für mich persönlich jetzt auch ein bisschen ein Hedge gegen die 1MB-4eva Fraktion.

Mich würde vor allem interessieren Bitcoin-NG mal in freier Wildbahn zu sehen.
Extension Blocks ergeben meiner Meinung nach wenig Sinn, wenn man sich sowieso schon darauf festgelegt hat die Blockgröße stark zu erhöhen, mit allen Vor- und Nachteilen.
Um neue Dinge auszuprobieren sind Sidechains viel einfacher.


Das ist der Knackpunkt:
Der freie Markt entscheidet (Nash-Equilibrium)
Das heißt nicht, dass jeder entscheiden kann, wie sich der Markt zu verhalten hat

@hv
Du hast eine seltsame Einstellung gegen den freien Markt.
Habe das Gefühl, dass du dir wünscht, dass die Miner entscheiden und dass dann irgendwie der freie Markt wäre.
Fakt ist doch, das wir allerdings einen freien Markt haben.
Das dir nicht gefällt, was der freie Markt entscheidet (zum Beispiel das 1MB Blocklimit) ist doch eine ganz andere Geschichte.
Der freie Markt wird das schon regeln, dass es nicht zu der Situation kommt.
Ggf. über Sidechains.

Und auch du wirst dir ja wohl aus den 2/3 Bitcoins eine aussuchen können bzw. unterstützen, wo du nicht darauf angewiesen sein wirst LN zu nutzen.
So werde zumindest ich das machen.
Die Gebühren können nicht einfach beliebig steigen - dafür sorgen dann schon die Altcoins.