Also du hast mehrere Möglichkeiten.
Du brauchst ein Light-Wallet, wie zum Beispiel Electrum, bei dem du einen Server auswählen kannst.
Achte darauf, dass du dir Taint besorgst oder selbst erstellst, damit du Replay Protection hast und den Taint bei jeder Transaktion verwendest.
Anleitung auf Englisch http://docs.electrum.org/en/latest/hardfork.html
Anleitung ist zwar für BU, funktioniert aber genauso mit BitcoinABC

Die sichere Variante und wenn du sowieso schon einen Historical Full Node hast:


Anleitung um Bitcoin ABC / Bitcoin Unlimited Cash Edition / etc. ohne redundante Daten gleichzeitig zu Bitcoin Core zu nutzen:

Schritt 0:
(Unbedingt durchführen, ansonsten kann eure Bitcoin Core Installation unbrauchbar werden)
Eure Verknüpfung zur BitcoinABC binary anpassen, damit das sein eigenes Datenverzeichnis hat und ggf. Port und RPC-Port anpassen, damit beide Clients gleichzeitig laufen können
-datadir=OrdnerZuNeuemDataVerzeichnis -port=28333 -rpcport=28334

Folgende Schritte gehen nur vor dem Hard Fork, also vor dem 01. August, ansonsten weiter unten gucken:
1. die alten blk...dat und rev..dat Dateien einfach als Symbolic oder Hard link in den "blocks" Ordner im neuen "data" Ordner reinkopieren
2. Optional zur Sicherheit: Die letzten Symlinks von den blk*.dat und den rev*.dat Dateien löschen und die Originale kopieren
    Vorsichtshalber könnt ihr eure *.dat Dateien im alten Verzeichnis als Schreibgeschützt markieren
3. den "chainstate" Ordner kopieren
4. den index ordner im "blocks" ordner kopieren

.bat Datei für Windows um Schritte 1-4 automatisch auszuführen  (Bitte passt die Pfade entsprechend eures Systems an)
Die .bat als Administrator ausführen, ansonsten werden keine symbolischen Links angelegt.



BitcoinABC braucht dann nichts mehr synchronisieren, sondern ist sofort bereit für den Einsatz, allerdings geht das nur vor dem 01. August

Wenn man das nicht vor dem 01. August geschafft hat:
1. Symlinks nur für die blk*.dat Dateien erstellen -> bat datei anpassen (rev*.dat Dateien brauchen wir nicht)
2. Symlinks von blk.*dat Dateien, welche nach dem 31. Juli modifiziert worden sind löschen - ggf. wieder die Ursprungsdateien schreibschützen.
3. Achtung: BitcoinABC mit der -reindex Option starten - ansonsten nutzt er die blk*.dat Dateien nicht, sondern lädt diese neu runter

Die Software muss die blk*.dat Dateien neu in die Datenbank einlesen und die Blöcke, welche nach dem Hard Fork erzeugt wurden neu runterladen - das kann einige Stunden dauern.



Praktischerweise wird man wohl kaum mehrere Full Nodes laufen lassen. Du kannst also die Bitcoins, die dir weniger wichtig sind entweder verkaufen oder in ein anderes Light-Wallet übertragen.

Extrem vorsichtig musst du sein, wegen der Replay Protection sein.
Das heißt spätestens ab dem 30.07. keine Transaktionen mehr ausführen, solange es noch Backlog im Mempool gibt, bzw. darauf achten, dass man auf jeden Fall eine Fee nimmt, die so hoch ist, dass die Transaktion noch vor dem Chain Split bestätigt wird.

https://jochen-hoenicke.de/queue/#4d
https://bitcoinfees.21.co/

Dann auf der Chain, die Replay Protection hat, also am 01. August Bitcoin ABC alle Coins mit einer Replay-Protected Transaktion an eine eigene Adresse schicken.

Wenn du einfach so deine normalen Bitcoins transferierst, kann es sein, dass die Transaktion auf der Bitcoin-ABC (Bitcoin Cash) Chain dupliziert wird (replay) und du die Kontrolle über die Bitcoin-Cash Bitcoins verlierst.

Overkill - die ersten 3 landen (so wie es aktuell aussieht) auf der gleichen Chain - zumindest in den nächsten 3 Monaten
Es wird erstmal nur Bitcoin und Bitcoin Cash geben.

Also:
Das BIP91 Signal wird nicht von Bitcoin Core unterstützt, sondern nur von dem btc1 core client (pools wie viabtc haben ggf. eigene Implementierungen) und hat zunächst einmal nichts direkt mit Segwit zu tun..
Das nutzen nur die Miner untereinander - Als Endbenutzer kann man das ignorieren.

Sobald BIP91 aktiv ist (frühestens in 6 Tagen), sind nur noch Blöcke, die für BIP141 signalisieren gültig und dadurch wird die Aktivierung von Segwit dann bei allen Clients die Segwit unterstützen innerhalb von ca. 4 Wochen erfolgen.

BIP91 muss vor dem 01. August aktiv sein.

Segwit2x beinhaltet BIP91, BIP141 und den 2 MB HF, das kommt praktisch alles nacheinander.

Das 1. Diagramm ist falsch, weil Segwit 4 Wochen bis zur Aktivierung braucht, der Pfad ist aber korrekt.
Wenn wir es einfach halten wollen, dann brauchen wir momentan nicht mehr betrachten.

Edit:
Das mit BitcoinABC ist auch falsch.
Es wird aller Voraussicht nach zum 1. August 2 verschiedene Bitcoins geben:
Das normale Bitcoin - und Bitcoin Cash (womit BitcoinABC kompatibel ist)

Edit2:
Das BIP91 Signal ist so massiv gestiegen in den letzten Stunden, weil btc1 die entsprechende Software erst gestern veröffentlicht hat

Oops - Post ist etwas lang geworden  

Bin auch gespannt - damit steht zumindest mal fest, dass wir mindestens 2 unterschiedliche Bitcoins haben.
Die Zeit ist natürlich extrem knapp, damit auch Light-Wallets entsprechende Software rausbringen können, damit man sicher die entsprechende Chain auswählen kann, oder eine Reorg-Protection hat.
Naja - ist wohl erstmal ein Grund ein BitcoinABC Full Node laufen zu lassen *lol*
Lustig, dass BCC von Bitfinex schon dem Bitcoin Core Split-Token zugesprochen wurde  
Welchen Namen das wohl erhält, falls Bitfinex mitzieht

Grundsätzlich find ich das schon in Ordnung. Es gibt zwar keinen technischen Grund vor Segwit Angst zu haben, vor allem, da es Opt-In ist, also niemand einen zwingen kann das zu benutzen, aber der Zeitpunkt ist ungefähr der letztmögliche um einen Fork zu machen, bei dem es kein Segwit gibt.
Ansonsten bin ich eher enttäuscht, dass der Fork nicht bereits viel früher passiert ist, als noch nicht klar war, dass ein Kompromiss (Segwit2x) gefunden wird, der zwar nicht von allen, aber immerhin von vielen getragen wird.

Ist die Frage, ob das den Hard Fork von Segwit2x jetzt gefährdet - zumindest haben wir die Möglichkeit mal zu sehen, wie so ein Bitcoin Hard Fork abläuft und können daraus ggf. noch etwas lernen.


Ja die Größe des UTXO ist und bleibt für die nächsten Jahre zumindest für Miner kein Problem.

Nein ich finde es nicht seltsam, weil beide Seiten Fundamentalisten haben, die es mit der Warheit, oder technischen Details nicht so genau nehmen.
Ich bin auch nicht per se ein Small-Blocker, vielleicht wirkt das nur so, weil von den Themen, die mich stören meistens hier nur die Big-Blocker Punkte aufkommen.

Die wandernden Flaschenhälse sind aber auch nicht merkwürdig - das ist normal bei einem technischen System - hat man einen Flaschenhals beseitigt ist etwas anderes der neue Flaschenhals - das ist immer so. Wenn wir lange genug alles andere optimieren, dann wird das UTXO irgendwann automatisch zum größten Flaschenhals.

Und es ist auch immer eine Frage, ob es gerade im Fokus eines Entwicklers ist. Wenn man einen neuen Anwendungszweck, wie die von dir genannten Light-Wallets die auf Basis eines UTXO arbeiten auf einmal als neuen Anwendungszweck erkennt, kann also auch ohne, dass sich sonst etwas technisch verändert hat, ein neuer Flaschenhals entstehen - bzw. er war für den Anwendungszweck zwar immer schon da, aber man hat es vorher einfach übersehen.

Und die Light-Wallets wurden ja auch entwickelt, weil zum Beispiel der benötigte Speicherplatz ein Flaschenhals war.

Am Ende ist eben alles eine Frage der Optimierung und der damit verbundenen Konsequenzen.

Und nochmal zum Thema - Ich sehe mich nicht als Small-Blocker, oder Team Core:
Luke-Jr mit seinen Zensur Bestrebungen und seinem 300kb Hard Fork Vorschlag ist mir zum Beispiel ein Dorn im Auge. Meine Meinung, das ich BIP148 für gefährlich und unnötig halte habe ich ja auch schon oft genug hier gesagt.

Anderer Punkt: Ich finde nicht, dass wir bereits jetzt einen Fee-Market (was für ein dämliches wort, Preis für eine Gebühr hahaha) entwickeln müssen, noch dass es aufgrund der extrem vielen unbekannten Variablen überhaupt einen vernünftigen Fee-Predictor geben kann, der sich nicht selbst schlägt -> Sprich der konstante Backlog von Greg ist meines Erachtens auch keine Voraussetzung, damit das Bitcoin-Mining auch noch funktioniert, wenn der Block-Reward stark abfällt. Es ist aktuell noch kein Problem, es lässt sich bestimmt anders lösen, als mit einem konstanten Backlog -> Zum Beispiel in dem die Auszahlung des Block-Rewards+Fees auf viele Blöcke verteilt wird

Ich bin aber stark der Meinung, dass wir erstmal alle uns zur Verfügung stehenden Technologien nutzen sollten, bevor wir riskante Dinge anpacken und Block Space grundsätzlich ein knappes Gut bleiben sollte, solange wir nicht die Situation mit den Full Nodes in den Griff bekommen, damit die Zentralisierung nicht zu stark wird. Wenn die risikoarmen Lösungen ausgeschöpft sind, wird sich auch unterstützung für Lösungen mit höherem Risiko (inhärentes Chain Split Risiko) finden.






Ja es ist auch nur eine Hypothese. Ein bisschen ärgerer ich mich, dass du das mit Peter-Rs Vortrag vergleichst, weil dazu Segwit erstmal geändert werden müsste (Änderung am P2P Layer und Änderung am Consensus-Layer), damit das funktioniert, was er vorgestellt hat, während  meine Hypothese, dass es zu einer schleichenden Zentralisierung mit Emergent Consensus auf einfachen Annahmen fußt:
Sobald es genug freie Kapazität vom sichersten Blockspace gibt, steigt über die Zeit auch der Bedarf
Nachdem einmal der initiale Widerstand überwunden wurde das einzuführen, wird es nie wieder Nicht-Miner-Nodes geben, die zusammen genug Widerstand leisten können um eine Anhebung zu blockieren
Für Miner stellt eine ansteigende Blockgröße nur minimalen zusätzlichen Aufwand dar, das heißt, solange sie irgendwelche andere Vorteile haben, werden diese die Blockgröße einfach immer erhöhen

Gerade bei Ethereum war das schon spannend mit dem Account basierten System - Die Exchanges haben ja teilweise die Deposits und Withdrawals während der hohen Last Phase gesperrt - Das kann bei Bitcoin mit dem UTXO basierten Ansatz ja nicht so einfach passieren -> Da setzt sich die höhere Fee automatisch durch.

Hast du übrigens mal geschaut, wie wenig Transaktionen Dash hat? Ich war erstaunt, wie wenig das sind, wo Roger da doch so oft von redet.
https://bitinfocharts.com/comparison/transactions-ltc-dash-xmr.html#3m

Bis auf Ethereum kommt kein System auch nur annähernd an Bitcoin heran und ist deswegen auch nur schwer vergleichbar.

Wenn wir jetzt 2 verschiedene Bitcoins haben wird es spannend.
Wird spannend, ob die Lager sich jetzt auch technisch gegenseitig angreifen, indem zum Beispiel einfach sinnlose Daten (Transaktionen) in die Blockchain geschrieben werden.

Ja, weil immer absehbar war, dass es nur ein bisschen mehr freien Block space gibt.
Was meinst du mit aufgeben?


Nur weil eine Kontroverse unter Minern bei einem Hard Fork einen Chain Split sicher macht, heißt das nicht, dass man das Gegenteil ausschließen kann, wenn sich die Miner einig sind.
Selbst wenn die Miner sich absolut einig sind und 100% Hash Power haben, haben Nutzer und Entwickler jederzeit die Möglichkeit einen neuen Fork aufzumachen, wenn dieser nicht den exakt gleichen Consensus Mechanismus und im Falle von Bitcoin den Double-SHA256 PoW-Algo nutzt, besonders deutlich wird dies bei einem hypothetischen Wechsel auf Proof of Stake.


Du hast schon recht, dass das ein sich selbst schließender Argumentationskreis ist. Ich halte den deswegen aber nicht für falsch und auch nicht für undurchbrechbar.
Segwit2X kommt dem ja schon recht Nahe - hätte man sich mit dem Hard Fork mehr Zeit gelassen, dann würden am Ende wirklich nur noch extreme Fundamentalisten übrig bleiben.

Mein größtes Problem mit Segwit2X ist, dass ich keine Ahnung habe, was nach dem 2MB Hard Fork passiert. Wie ist der weitere Plan? Bzw. was für Eigenschaften von Bitcoin repräsentiert der - welchen Stellenwert hat Dezentralität und Zensur Resistenz.
Wenn man die Core Leute an Bord hätte, hätte ich ein gutes Gefühl, dass es ausreichend diversifizierte Interessengruppen gibt.

Wenn sich das aufspalten sollte, dann könnten am Ende beide Bitcoins nichts für mich sein.
Die Eine Seite, die sich überhaupt nicht um Dezentralität schert und dann ein anderes Bitcoin, was sich zu sehr darauf konzentriert.

Meine Argumentation hast du allerdings nicht korrekt dargestellt, denn es gibt bereits die klassische Replay Protection das über "Taint" zu regeln.
Die ist einfach sehr fehleranfällig für normale Nutzer, weil kompliziert umzusetzen. Und erstmal braucht man neue Bitcoins, also den Taint, damit die Transaktion nur auf einer Kette gültig ist.
Und eine Replay-Protection hat für mich nichts mit der Chain-Split gefahr zu tun - die ist für mich intrinsisch für einen Hard Fork, dank des Status-Quo-Bias.
Niemand kann vorhersagen, wie sich ein Hard-Fork tatsächlich entwickelt und ob es zu einem Chain-Split kommt oder nicht.

Ich halte es einfach für eine sinnvolle Vorsichtsmaßnahme, die leicht umzusetzen ist, wenn ein Hard Fork folgendes bietet:
1. Wipeout-Protection
2. Replay-Protection
3. Reorg-Protection für Light-Wallets, bzw. sichere Auswahl der Blockchain für Light-Wallets

UAHF hat 1+2, 3 fehlt, Segwit2X hat nur 1

Langsam bitte: Core kann nur entscheiden, was in Core kommt.
Und da Get_UTXO nicht den Consensus-Layer betrifft, sondern nur den P2P-Layer kann Core nicht verhindern, dass das in Bitcoin kommt.
Meines Wissens nach hat er das in Bitcoin-XT eingebaut.
Warum haben Bitcoin Unlimited, Bitcoin Classic und BitcoinABC & Co. das nicht übernommen?
Vielleicht ist es doch nicht so toll?

Ich glaube es war nicht nachprüfbar, ob die Nachricht authentisch ist und damit hat es zu keiner Erhöhung der Sicherheit geführt.
Ggf. wurde es auch nicht gemerged, da es DOS Angriffe erleichtert.

Bringt ja sowieso nur was für 0-conf und die Transaktion dürfte man selbst nur erhalten, wenn der UTXO-Eintrag existiert.
Das heißt die Node, die einem die Transaktion geschickt hat könnte man nicht nach dem UTXO Eintrag fragen, denn warum sollte die Node nur einmal die Wahrheit mitteilen und einmal lügen.
Zudem ist das anfällig für MITM Angriffe.

Ja - Der Angriff ist sehr teuer - aber bei mehreren Bitcoins, wie wir es bald haben werden lohnt er sich unter bestimmten umständen, ohne das der Miner einen Schaden hat, denn er schadet nur der Kette die er bekämpfen will.

Dezentralität bedeutet für mich, dass ich mir keine Sorgen machen muss, dass es irgendeine Partei geben kann, die die Fungibiltät meiner Bitcoins einschränken kann.
Das wenn ich bereit bin eine Gebühr zu bezahlen, die hoch genug ist, mir sicher sein kann, dass meine Transaktion in die Blockchain aufgenommen wird.

Das bedeutet für mich, dass niemand, auch nicht wenn die Regierungen von den USA, EU und China zusammentun genug Druck auf irgendjemand ausüben können, weil es so viele Teilnehmer im Markt gibt, das ein gezieltes Vorgehen gegen einzelne Teilnehmer mittelfristig keine Auswirkungen hat, weil sofort ein anderer Teilnehmer die Aufgaben übernimmt.

Wenn wir nur wenige Full Nodes oder Miner haben, dann wird das System von innen und von außen angreifbar.


Ist das wirklich so? Also Extension Blocks sind vielleicht zentralisierter als das aktuelle Bitcoin - aber nicht zentralisierter als ein Bitcoin, bei dem die Miner die Regeln bestimmen, oder bei einem Bitcoin mit großen Blöcken. Und selbst bei Sidechains sind es die Miner die für die Sicherheit sorgen.
Wenn man ein Light-Wallet nutzt, hat man keine größere Gefahr.
Für Sicherheit sorgen bei Extension Blocks wie bei normalen Blöcken die Miner und auch alle Full-Nodes, die Extension Blocks unterstützen. Wir verschlechtern uns also nicht und haben dafür noch zusätzlich ein sehr dezentrales normales Bitcoin, auf das man auch mit einfacher Hardware zugreifen kann. Wenn sich zeigen sollte, dass alle die Extension Blocks nutzen und das die Sorgen über Zentralität unbegründet sind, kann man die Extension-Blocks und die normalen Blöcke sogar zusammenführen. Sowas meine ich mit "gefahrlos ausprobieren"

Streng genommen müssen nicht mal Miner das ganze im RAM halten, das ist nur eine krasse Vereinfachung.
Macht man aktuell einfach aus praktsichen Gründen -> Das UTXO Set ist klein und RAM ist günstig genug, so dass es bisher nicht optimiert werden musste.
Und Miner heißt in dem Fall Mining-Pools - Hasher müssen überhaupt nichts davon im RAM halten.

Die Transaktionen, welche über das P2P Netzwerk reinkommen werden ja schon zu dem Zeitpunkt des Empfangs validiert und damit kann der UTXO Eintrag in den Cache (RAM) geladen werden.
Für das gesamte UTXO-Set reicht ein schnell zugreifbarer Datenspeicher, das muss nicht unbedingt RAM sein, da reicht auch eine SSD.

Für den Miner gibt es je nach Sichtweise 1-2 Gründe möglichst viel vom UTXO-Set im Speicher zu halten:
Grundsätzlich geht es immer um Profitmaximierung, also immer den Block-Kandidaten zu berechnen, der den maximalen Profit verspricht.
Das heißt zum einen die Transaktionen, welche hohe Gebühren zahlen, möglichst schnell in den aktuellen Block-Kandidaten zu nehmen.

Und es heißt natürlich auch, dass man Blöcke von anderen Minern möglichst schnell validieren will.
Nur, wenn ein anderer Miner also einen Block sendet, der Transaktionen enthält, die aktuell nicht im Mempool sind, muss in dem Fall überhaupt zusätzlich auf das UTXO-Set zugegriffen werden, um feststellen zu können, ob der Block valide ist.

Der einzige Grund für einen Miner auf das UTXO zuzugreifen ist also immer, wenn man eine neue Transaktion erhält und überprüfen muss ob die Transaktion gültig ist. Dazu muss man natürlich schauen, ob der entsprechende UTXO Eintrag existiert. Wenn man das UTXO-Set im RAM hat, kann der Miner also im Mikro-/Millisekunden-Bereich schneller reagieren, was die Spy-Mining- oder SPV-Mining-Zeit (Mining von leeren Blöcken) um Millisekunden verkürzt und ebenso es erlaubt neue Transaktionen Mikro-/Millisekunden schneller in den Block-Kandidaten zu übernehmen.

Effekte:
Kürzere Zeit, in der leere Blöcke gemined werden -> Geringere Zeit in der der Miner durch invalide Blöcke angreifbar ist -> Also theoretisch auch niedrigere Orphan-Rate
Miner kann Blöcke mit höheren Gebühren produzieren

Solange eine normale Full-Node also problemlos die Transaktionen verifizieren kann, während das UTXO-Set bei der Full-Node auf einer HDD liegt, ist der Vorteil bei den momentanen Verhältnissen praktisch ausschließlich ökonomischer Natur und auch da nur sehr minimal gegenüber schnellen Speichern, wie einer SSD.

Ja - weil DNS ein hierarchisches Netzwerk ist. Bitcoin hat ein P2P Netzwerk - Usenet Tier 1 ist praktisch auch P2P, wenn auch privates P2P, bei dem alles kopiert wird, wie bei einem Bitcoin Full Node.
Ich habe im gleichen Post geschrieben, dass ich nicht glaube, dass es dazu kommt - vielleicht habe ich das nicht klar genug ausgedrückt.

Edit:
Danke für das DNS Beispiel
Ggf. lässt sich mit den (Meta-)daten von den Bitcoin Transaktionen genug Geld verdienen, so dass es sogar Interessenten geben würde, um sowas kostenlos zur Verfügung zustellen.
Ökonomisch ist DNS wahrscheinlich das bessere Beispiel, technisch wohl eher weniger

Nein ich find das überhaupt nicht widersprüchlich.
Es gibt wege einen Hard Fork ohne Chain Split durchzuführen, indem man einen Soft Fork vorher schiebt, der alle zum updaten zwingt. Das ist seit Jahren bekannt.
Dann entsteht der Chain Split nicht mehr so einfach, sondern nur noch, wenn der Hard Fork wirklich extrem umstritten war und nicht bei so einer einfachen Sache wie 2 MB.
Ich hab ja auch selbst nichts gegen 2 MB, meine persönliche Meinung ist, dass aktuell Bitcoin und Hardware soweit weiterentwickelt wurde, dass Probleme frühestens bei 4 MB anfangen.

Ein Chain Split ist natürlich schwierig zu verhindern, wenn man so Fundamentalisten hat, wie Luke-Jr mit seiner ganz eigenen (mit meiner inkompatiblen) Vorstellung von Bitcoin hat und Jihan-Wu, der die Core-Devs loswerden will.

Das basiert auf einem Missverständnis - LN kann die Blockchain nicht umgehen - es nutzt sie nur weniger oft - ohne Blockchain kein LN - es gibt kein Fractional Reserve Lending - Ich kenne niemanden (außer vielleicht Luke-Jr), der ein 1 MB Netzwerk haben will.
LN ist übrigens nicht die einzige Layer 2 Technologie - Sidechains, was auch immer man davon halten mag sind davon komplett unabhängig.

Schön, dass du das auch aufschreibst - Lustiger Weise denke ich, dass Bitcoin wahrscheinlich vor dieser Situation durch die Konkurrenz mit den Altcoins gerettet werden wird.
Sollte Bitcoin allerdings die absolut dominierende Währung auf der Welt sein, wäre das allerdings durchaus möglich, dann haben wir praktisch wieder Banken, außer dass diese eben nicht SEPA und SWIFT, sondern Bitcoin nutzen. Ein bisschen spannend wird es aber schon, wer in Zukunft noch Lust hat Full Nodes laufen zu lassen und andere diese kostenlos nutzen zu lassen, vor allem wenn die Anzahl der Full Nodes sinkt und gleichzeitig die Anzahl der Nutzer weiter ansteigt.

Bei Lightning-Channeln (und damit indirekt Hubs) haben wir immerhin noch den Vorteil, dass jeder einen erlaubnisfrei aufmachen kann, ohne jemanden zu fragen.
Das heißt es kann keine Zentralisierung erzwungen werden.

Bei der anderen Extremposition haben wir bestimmt eine ähnliche Struktur wie im Usenet heutzutage - Mit Tier 1 und Tier 2 Providern. Wenn einem keiner Zugriff gibt, dann steht man eben doof da und kann kein eigenen Provider aufmachen.

Beides sind für mich unbefriedigende Lösungen - würde mir wohl auch einen Alt(Bit)coin suchen.


Segwit und die anderen Technologien ergänzen sich sogar sehr gut miteinander.
Segwit auf der Mainchain ermöglicht Atomic Swaps und führt somit dazu, dass ein Nutzer die Coins in Sekundenschnelle zwischen den Systemen transferieren kann.

Nicht jede Transaktion (z.B. Kaffee  ) muss unbedingt über ein extrem dezentralisiertes System bezahlt werden. Es reicht ja, dass man mit Bitcoins bezahlen kann, von daher Eröffnet Rootstock mit dem Lumino Transaction Compression Protocol und ggf. zusätzlich Lumino Network interessante Möglichkeiten, das sehr viel effizienter als derzeit bei Bitcoin zu machen.
Für große Beträge wird es wahrscheinlich immer am interessantesten - aber auch am teuersten sein, diese über "normales" Bitcoin abzuwickeln.

Es ist unklar, ob wir Extension Blocks jemals im Einsatz sehen werden, denn irgendwer muss für die Aktivierung auf der Blockchain sorgen.
Bei Rootstock ist das egal, denn die starten als Federated Sidechain - Das heißt Rootstock kommt auf jeden Fall.

Absolute Zustimmung - Das hatte ich auch schon diese (letzte) Woche vorgeschlagen - hat leider niemand aufgegriffen.


@Christoph
Danke, dass du so viel geschrieben hast.
Nehme mir etwas Zeit und antworte separat darauf  

AFAIK Electrum has a Client-Server architecture - so yes, the client is a light-client.
Be careful, which server you select.
There is a splitting guide for electrum:
http://docs.electrum.org/en/latest/hardfork.html

Basically all Clients, which are not full nodes, are light clients and will have severe problems with said hard forks.


Edit:
Because this is the development subforum:
Using the Hard Fork bit would fix this problem? (At least for 2 distinct chains)

Thank you for your reply.

So essentially, because the developers rushed their code / did not care about consequences the average user now has to fix the mess they created.
This seems to me like it is bound to fail, especially for Bitcoin beginners.

Though i was aware of that theoretic solution - is that really possible with most wallets?
I saw some announcements recently from wallet providers, but i suspect not all wallets do even support this yet.

Doesn't connecting to a "prefered" node open new attack vectors, like sybil and MITM attacks?

I just recently realized, that Segwit2X and UAHF offer no wipeout reorg protection for Lite-Clients like mobile wallets, when they Hard Fork with a block size increase and split the chain.

The wipeout protection for the block size Hard Fork is based on a "Must-Be-Big" rule.
However light clients do not check the block size (because it is not in the block header) and therefore cannot check this rule.

How do current light wallets guard their users from reorgs and hops between chains and the results:
Unintended double-sent transactions - vanished Bitcoins or suddenly again unconfirmed transactions, that may not even be valid on the current chain, because a utxo-entry may have already been spent etc.

How can this be intended design?
Hope this didn't came up in a prominent place already.

Hm also eins hats heute immerhin mir persönlich gebracht:
Ich dachte der Angriff sei sehr schwer auszuführen, da er sich nur unter bestimmten Umständen ökonomisch lohnt, aber das stimmt nicht mehr unbedingt im Rahmen eines Chain Splits, auch weil wir dann andere Spieltheoretische Umstände haben.

Eine Tatsache die mir durch die Diskussionen heute noch klar geworden ist, dass Segwit2x für einen normalen Nutzer keine Reorg Protection bietet, wenn man davon ausgeht, dass ein dieser ein Lite-Wallet benutzt.
Das "Must-Be-Big Rule" sorgt aktuell für die Wipeout Protection und damit für eine Reorg Protection bei Full Nodes. Da ein Lite-Wallet die Blockgröße aber nicht prüfen kann hat es effektiv keine Reorg Protection.
Das heißt das Lite-Wallet könnte unkontrollierbar zwischen den Chains hin und herspringen, weil es immer nur guckt, wer am meisten PoW hat, aber nicht wer am meisten gültigen PoW hat.
Mögliche Folgen sind zum Beispiel: Bitcoins können aus dem Lite-Wallet verschwinden - Bestätigungen für Zahlungen können angezeigt werden und dann wieder verschwinden, auch noch Wochen später.

Mein persönlicher Rat ist auf jeden Fall im Rahmen eines Hard Forks wie der 2MB HF von Segwit2x im November, der keine Reorg Protection für Lite-Wallets bietet entweder ein Full-Node zu nutzen, oder darauf zu achten ein Lite-Wallet zu nutzen, bei es einen Workaround gibt um zumindest die Reorg Protection wieder zu erreichen, indem man zum Beispiel zu einem Full-Node / oder Server verbindet, dem man vertrauen kann. Auch hier haben wir wieder das Problem des Vertrauens eingeführt, wenn man nicht selbst die Full-Node betreibt und die Verbindung zum Full Node nicht gegen Man-In-The-Middle Angriffe absichert.

Das ist auch interessant mit dem neulichen Angriffsszenario von Peter R.: Das Vorenthalten von Signaturen, welches nur funktioniert, wenn die Nodes vorher einen Hard Fork mitgehen um die Consens Regeln zu ändern, damit Transaktionen auch ohne Signaturen akzeptiert werden, wird in einem Netzwerk mit aktivem Segwit BIP141 Regeln dominierten Netzwerk dann  nach einem Chain Split das ganze noch mal schwerer, auch wenn es vorher schon praktisch unmöglich ist, denn wer würde den für den Angriff notwendigen Hard Fork schon mitgehen.

Aber bei einem Chain Split haben Miner dann möglicherweise auf einmal genügend Anreize SPV Nodes zu betrügen um der Kette gezielt zu schaden und brauchen dazu nicht einmal 51% der Hashpower.

Ich muss mir das mal in Ruhe durch den Kopf gehen lassen -> Freue mich, wenn mir da wer helfen kann.
Ein Chain Split ändert auf jeden fall viel an der Sicherheit von Bitcoin die durch die Spieltheorie und Anreize kommt.

Ja finde ich gut, wenn du dann dazu stehst.

Aber diese Abneigung gegenüber Segwit werde ich wohl nie verstehen.
Was gibt es da für Gründe?
Vor allem, wenn man sowieso ein Bitcoin hat, bei dem Hard Forks keine großen Probleme mehr sind, was nach einem Chain Split nicht allzu unwahrscheinlich wäre.
Nach einem Hard Fork wären Transaktionen mit Segwit Inputs oder Outputs ja genauso sicher wie normale Transaktionen, auch wenn ich bezweifle, dass diese überhaupt eine messbar geringere Sicherheit als normale Transaktionen haben - Den Signaturdiscount kann man ohne Probleme anpassen in einem Hard Fork - der Merkle Tree Root lässt sich wieder besser kompatibel zu Asicboost in den Header nehmen, also nur Vorteile, für die man sonst langwierige Eigenentwicklung machen müsste mit vielen Hard Forks.

Sollte erstmal nur eine Beobachtung sein, auch wenn man leicht ablesen könnte, dass ich nicht nur eine Korrelation impliziere.
Ist mir einfach sehr aufgefallen und es hat mich interessiert, was andere dazu denken.

Vorher war es einige Wochen so, dass Ethereum praktisch wie ein Hebel auf Bitcoin zu USD funktioniert hat.
Bitcoin gestiegen -> Ethereum stark gestiegen
Bitcoin gefallen -> Ethereum stark gefallen

Ich denke der Markt war erstmal zufrieden mit Segwit2x.
Das das jetzt nicht nach Plan läuft erhöht eben die Unsicherheit.
Dazu die Ankündigung von Coinbase und Bitcoin.org das man um den 1. August keine Transaktionen tätigen sollte, bzw. Ein- und Auszahlungen ggf. gesperrt werden.
Bin gespannt, was andere so für Theorien haben - ist Bitcoin einfach gerade überbewertet gewesen und Ethereum nicht?
Was hat sich sonst auf einmal geändert? Oder war das nur eine Preisbewegung ohne Grund?

Wie lange haben wir die Debatte jetzt? Ich meine das war doch schon seit Jahren absehbar, dass ein Hard Fork in einem Chain Split endet.
Die Zeit hätte man gut verwenden können um das fertig zu stellen. Purse/Bcoin hat ja auch etwas funktionierendes.
Warum sollten die nicht fungibel sein? Ohne Malleability Fix auf der Mainchain ist das sicherlich etwas schwächer, denn wir haben keine Atomic Swaps, aber man kann ja hin und hersenden.

Wie schlimm wäre das, wenn die nicht 100% fungibel gegenüber Bitcoins sind? Bei Altcoins hält das ja auch niemand davon ab die zu benutzen.


Ja - und ich hab ja mal ausführlich erklärt warum und da warst du glaub ich nicht unbeeindruckt - kann es gerne wieder raussuchen.
Die Situation verschlimmert sich ja sogar noch, wenn wir bereits 2 Bitcoins haben.
Wer will da noch gegen eine Vergrößerung gegenhalten? Schließlich muss man ja "besser" sein als die andere Chain und immer genug freien Blockspace haben, damit 0-conf einigermaßen funktioniert.
Also falls wir durch Segwit2x keinen klaren Gewinner bekommen  gehe ich stark davon aus, dass sich eine Chain auf die Dezentralisierung konzentriert und die andere Chain das Problem der Zentralisierung erstmal ignoriert und das Blockgrößen Limit effektiv abschafft.

Falsch - Ich will niemals einen Chain Split.
Wenn man es nicht schafft, einen Hard Fork unkontrovers zu machen, dann muss man das eben anders lösen.
Zur Not eben mit einem Evil-Soft-Fork oder einem Synthetic-Fork, oder man löst das Problem einfach ganz anders.

Trotzdem können Miner nicht einfach die Spielregeln festlegen - sie können nur die Freiheit nutzen, die Ihnen die Regeln geben.

Das ist eben leider nicht so einfach, weil man eben auch verifizieren müsste, dass das UTXO Set gültig ist.
Mal schauen - Ist die Frage, ob mobile Hardware auch langfristig mit dem Wachstum des UTXO Sets mithalten kann.
Bei entsprechend ansteigender Adoptionsrate ist das zumindest auf Mobiler Hardware schwierig.
Aktuell müsste die Hardware ausreichen, wenn man bereit ist seiner Wallet App eben 1 GB Speicherplatz zu gönnen.

Du kannst nur überprüfen, dass es eine Blockchain gibt, in der deine Transaktion drin ist. Ob die Bitcoins aber bereits vorher jemand anderem übereignet worden sind oder aus der Luft erschaffen worden sind kannst du nur mit Fraud Proofs feststellen. Du kannst also mit aktuellen Lite-Nodes nicht prüfen, ob die Blockchain ungültig ist, die du empfängst.
Das untergräbt einfach die Spieltheorie von Bitcoin und erhöht die Anreize für die Miner zu betrügen, weil dein lokaler Zustand nicht überprüfbar ist, sondern die Daten die dein Lite-Wallet anzeigt auf Vertrauen basieren.

Weil eben so oft von Satoshis Vision geredet wird - Satoshis Vision war, dass jeder selbst überprüfen kann, ob ein Double-Spend vorliegt oder nicht irgendwem blind vertrauen muss.
Das sind die ersten Sätze im White Paper.
Und das können aktuelle Lite-Wallets leider nicht. Und je größer die Blockgröße ist, desto mehr entfernen wir uns von Satoshis Vision, solange wir dieses Problem nicht fixen. Deswegen habe ich ja auch den Text aus dem White-Paper über SPV zitiert.

Wir wissen leider nicht, wann Bitcoin die Eigenschaften der Dezentralität verliert. Wenn wir das wissen, wird es leider schon zu spät sein. Ist dann die Frage, ob es noch einen Unterschied macht, ob derjenige, der jetzt die Transaktionen kontrolliert "Miner", "Paypal" oder "Bank" heißt.

Mit Sidechains und Extension-Blocks kann man aber zumindest das relativ gefahrlos austesten, wann wir da an Grenzen stoßen, während die einfache Erhöhung der Blockgröße unumkehrbare Resultate schafft.
Und gleichzeitig haben wir keinen Chain Split.

Ein Chain Split ändert aber alles, was wir bisher kennen.
Und sonst... Es ist ja irgendwo das schlimme, dass die 2 oder 4 MB wenig ändern. Aber sie setzen eine Bewegung in Gang, die sich möglicherweise nicht stoppen lässt, weil jedes mal verliert man ja nur ein bisschen, da lohnt es sich ja keinen Widerstand zu leisten.

Wir können sehr viel machen - Bitcoins kaufen bzw. verkaufen, die unseren Idealen entsprechen.
Unsere Meinung austauschen - was wir hier machen.
Anderen Leuten erklären, warum wir persönlich den Bitcoin für wertvoll halten.

Und wenn dir auf Dezentralität egal ist, oder einen Hass auf Core hast, dann verkauf nach einem Split entsprechend und kauf Coins von der anderen chain.
Miner wollen auch nach einem Split weiterhin ihre Bitcoins verkaufen können, von daher werden die dann auch die Kette Minen, bei der die Nutzer bereit sind (mehr) Geld für zu zahlen.
Und du kannst das ebenso jetzt schon machen

Ich weiß nicht, wie es nach einem Split aussehen würde, welches die erfolgreiche Chain ist, ist mir auch egal, auch wenn es mir das vielleicht aus finanzieller Hinsicht nicht sein sollte.
Ich bin mir aber ziemlich sicher, dass es eine Chain, die Konsens und Dezentralisierung bevorzugt auch noch in vielen vielen Jahren geben wird, denn die Leute sind aus Prinzip dem Bitcoin treu und nicht nur hinter dem schnellen Geld her.


@hv__
Die Anzahl der Mining-Pools ist erstmal irrelevant.
Vor allem wenn man nicht weiß, wer hinter dem Mining-Pool steht.
Das ist nicht Sybill Angriffs resistent.
Und Miner können ja auch innerhalb von Minuten den Pool wechseln.
Es ist eine riesige Grauzone.
Kleines Beispiel: Keiner weiß, ob Bitmain aktuell 20, 30, 40 oder bereits 50% der gesamten Hashrate direkt oder indirekt kontrolliert.
Jedes mathematische Modell wird so viele Annahmen treffen müssen, dass man nur sehr begrenzte Aussagen treffen können wird, die eben dann nur unter diesen Annahmen gültig wären.


Edit:
Die ersten Sätze aus dem White Paper von Bitcoin

Also welchen spieltheretischen Grundsatz das kaputt macht, wenn man nicht mal mehr von außen überprüfen kann, ob es mehr als 21 Mio Bitcoins gibt...

Vielleicht liest einer ab und zu mal Nachrichten. Wenn man das Institutionen überlässt, die dann von einer Manipulation profitieren können, ohne dass das von außen richtig kontrolliert wird:
Ich meine kennen wir das nicht irgendwoher?
Das mit dem Vertrauen funktioniert ja sooo gut - man siehe nur LIBOR-Skandal, Manipulation beim Goldfixing, Manipulation beim Silberpreis.
Aber die Banken müssten doch interesse daran haben nicht zu manipulieren - schließlich verlieren sie dadurch Ansehen, Ruf und mögliche Kunden und somit Umsätze und Gewinne.
Naja...

Und Peter R. hat ja in seinem Talk neulich vorgestellt, dass Miner ja die Regeln Bitcoin ändern könnten (Hard Fork) und dann Signaturen einfach nicht mehr mit ausliefern mit dem Block. Wenn die Leute mit dem Hard Fork der Miner mitgehen würden könnte man nicht mal beweisen, dass die Miner gestohlen haben.

Hört sich nach einer guten Idee an den Minern die Regeln zu überlassen - schließlich handeln diese ja im eigenen Interesse, wenn sie nicht Schummeln, oder sich nicht beim Schummeln erwischen lassen - oder anders gesagt, sie werden nur so stark schummeln, dass man es ihnen jedes mal noch irgendwie durchgehen lässt, wenn man dann feststellt, dass sie geschummelt haben.

Ein System, was auf Vertrauen basiert wird langfristig nur dazu führen, dass das Vertrauen enttäuscht wird, sobald irgendjemand davon ein Vorteil hat.
Ein System, bei dem man kontrollieren kann, ob die Regeln eingehalten werden, kann einen nicht enttäuschen, es kann höchstens versucht werden das System zu korrumpieren. Also eine Umwandlung in ein System das auf Vertrauen basiert, um es dann zu missbrauchen. Das könnte auf Bitcoin langfristig zutreffen.
Und wenn nicht - wozu das Risiko eingehen?

Was ist denn das alte bewährte bei Bitcoin?
Das alte Bewährte ist keine Chain Splits zu provozieren, sondern einen Konsens herzustellen, und Deployment als SF oder HF ist davon unabhängig.
Die konsensus relevante Konstante "Maximale Blockgröße" wurde von Satoshi eingeführt und danach nie wieder geändert.
Was man öfter mal gemacht hat, das Soft-Limit beim Mining anzupassen ist etwas ganz anderes.
Das ist jetzt ausgeschöpft, das heißt das kann man nicht mehr machen.

Es bleibt also nur den alten bewährten Weg zu gehen.
Konsens herstellen, so dass es bei Anwendung der Lösung nicht zu einem Chain Split kommt und dann die Konsens-Regeln anpassen, egal ob als SF oder als HF.

Einen 2 MB HF als die alte bewährte Methode anzupreisen ist einfach nur ein Euphemismus und grenzt an Realitätsverweigerung.
Ein bleibender Chain Split ist das absolute Gegenteil einer alten bewährten Methode und ist bei Bitcoin etwas noch nie dagewesenes.
Ein Chain Split hat ungefähr 0 mit Satoshis Vision zu tun.

Wenn man das machen will, dann bitte ehrlich und zugeben, das man einen schwierigen Weg gewählt hat und schauen, dass man die Auswirkungen mit technischen Maßnahmen in den Griff bekommt.

Edit:
In Satoshis White Paper spricht er von SPV-Wallets, welche eine Methode unterstützen, die wir heute "Fraud Proofs" nennen - die haben wir aber nicht
Und wenn wir trotzdem in ein zentralisiertes System gehen - wer kann dann noch durchsetzen, dass echte SPV-Wallets mit Fraud Proofs kommen?
Bitcoin mit PoW wurde erfunden um das Double-Spend-Problem zu lösen - ohne überprüfen zu können, ob ein Double-Spend stattgefunden hat, untergräbt man also den ganzen Sinn von Bitcoin
Erst Fraud Proofs, dann können wir auf den breitflächigen Einsatz von Full Nodes verzichten

Da geht es nicht um Angst - es ist einfach so, dass die technischen Eigenschaften spieltheoretische Konsequenzen haben und natürlich auch Auswirkungen auf die Eigenschaften die Bitcoin zu Geld machen.
Es findet ein Wechsel von einem System, bei dem man überprüfen kann, dass alle Regeln eingehalten werden in ein System statt, dass auf Vertrauen basiert.

Edit:
@all, aber speziell @Cristoph
Solange Miner sowas durchlassen, weil diese dann doch keine Lust auf eine funktionierende Flood control haben, siehts duster aus für nicht volle Blöcke. Mein Wallet ist voll damit. Und sei es nur um sich vor bösen Bitcoin Core Devs zu schützen.
https://blockchain.info/address/1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z

Warum messen wir dann den Preis überhaupt noch in €?
Mit aktuellen Lite-Wallets kannst du ja nicht mal prüfen, ob es mehr als 21 Mio Bitcoins gibt oder nicht.

Jeff Garzik hat es nicht geschafft den btc1 Client rechtzeitig zu veröffentlichen.
Prompt steigt der Ethereum Preis und der Preis von Bitcoin fällt.
Das hat es so in den letzten Monaten nicht gegeben.

Ist besonders gut zu sehen bei ETHBTC zu BTCUSD, wo auf einmal die Korrelation von positiv zu negativ gewechselt ist.

Du machst es dir sehr einfach mir was pauschal vorzuwerfen, ohne darauf einzugehen, wo ich das nicht betrachtet habe, bzw. ohne mich zu fragen wie ich zu bestimmten Punkten stehe.
Bitte werde konkret.

Wenn du schon länger mitgelesen hast, weißt du, dass ich kein Small Blocker bin. Ich bin aber ziemlich angekotzt, wenn es Technologien, wie Extension Block (Bcoin) gibt, und das nicht genutzt wird. Segwit + 30 MB oder größere Extension Blocks + Rootstock sind meine präferierte Lösung. Emergent Consensus Blocksize und ähnliches halte ich für einen schleichenden Prozess in die Zentralisierung und sehe damit verbunden den Verlust der Eigenschaften die Bitcoin  wertvoll machen, vor allem im Vergleich zu Gold, € und $.

Was ist die Spieltheorie eine Kryptowährung zu kaufen, wenn die zentralisiert wird und damit die Freiheit verliere, die ursprünglich für mich Grund war die Kryptowährung zu kaufen?
Ja - UAHF ist praktisch das beste Szenario für einen sauberen Split, da für mich da klar ist, dass Bitmain da das sagen hat.

Ich finde auch nicht, dass ein Chain-Split ein Weltuntergang ist - es ist eben die Frage unter welchen Voraussetzungen der stattfindet. Jeder kann jederzeit einen Minderheiten Fork aufmachen. Es geht darum, dass wenn man weiß, dass der Hard Fork kontrovers ist und man weiß, dass es technische Probleme gibt und man die Mittel hat diese technischen Probleme (v.a. Replay Protection) zu lösen, das dann aber bewusst nicht macht. Ich halte das für amateurhaft. Nach einem Jahr Streit haben viele zumindest erkannt, dass man doch eine Wipeout-Protection einbauen sollte.

Vor allem haben wir Technologien um große Blockgrößen ohne Hard Fork zu erreichen - es stellt sich also die Frage, warum dann manche trotzdem so die Hard Forks pushen. Jihan Wu sagt ja öffentlich, dass ihm der Einfluss der Core Entwickler gegen den Strich geht und er die loswerden will - das geht natürlich nur mit einem Chain Split.

Bitcoin ist übrigens immer Settlement Coin, egal, ob die Gebühren hoch oder niedrig sind - wozu braucht man sonst On-Chain, wenn nicht zum Settlement. Natürlich geht es indirekt durch die ökonomischen Effekte darum, ob wir stand heute 0,1 €, 1 €, 10 €, 100 € oder höhere Beträge als würdig für Settlement ansehen und die Konsequenzen in allen Richtungen akzeptieren (Zentralisierung, Kosten für Transaktionen, Kosten für Teilnahme am Netzwerk, Zensur Resistenz) Grundsätzlich gilt natürlich, wer die Gebühr bezahlt, dessen Transaktion wird in einen Block aufgenommen.

HF meinetwegen - Chain Split - wenn manche das unbedingt wollen - kann ich nicht verhindern.
Aber dann bitte so, dass die vorhandene Software auch feststellen kann, welches Bitcoin sie gerade benutzt.


.
Ja - hat aktuell mal wer die Entwicklung bei den anderen Cryptocurrencies angeschaut? Das On-Chain Transaktionsvolumen explodiert - Off-Chain sicher auch, ist aber nicht messbar.
In den letzten Jahren war ja durchaus die Frage, ob Cryptocurrencies nur eine vorübergehende Erscheinung sind.
Jetzt ist die Frage, welche Cryptocurrency bekommt wieviel vom Kuchen ab.
Und wir hatten immer eine bekannte Feste Obergrenze, die fällt ja bei EB / ABC praktisch weg.

Das heißt die Faktoren sind jetzt anders in einem HF Szenario.
Wenn du einem Entwickler entsprechende Ressourcen / Hardware / Bandbreite zur Verfügung stellst, dann wird er die auch nutzen, das heißt das Transaktionsvolumen kann durchaus explodieren, wenn es günstig genug ist.

Jein - Ich bin nicht der Meinung, dass wir nur wenige Entscheidungsträger, wie in einem zentralisierten System in der Form überhaupt bei Bitcoin haben.
Jeder einzelne der Bitcoin nutzt ist Entscheidungsträger.

Jeder kann sich dafür entscheiden, dass ihm die Regeln von Bitcoin egal sind und er zum beispiel nur der meisten PoW folgt, egal ob diese gültig ist oder nicht.
Jeder kann sich dafür entscheiden, wenn er einen Full Node nutzt, welche Software er dafür verwendet.

Entwickler, Miner und CEOs von Bitcoin Unternehmen haben sicherlich eine besondere Stellung, aber sie können niemand zwingen Ihr Produkt zu nutzen.
Deswegen können Sie auch nicht zentralisiert die Entscheidungen für Bitcoin treffen.
Falls sie das versuchen, dann wird das eben in mehreren Versionen von Bitcoin münden.

Was sie aber definitiv tun können, ist Ihren Einfluss zu nutzen und die Freiheiten, die das Bitcoin-Protokoll Ihnen gibt, manche Sachen zu blockieren.
Um etwas Durchzusetzen ist man aber sowieso aufeinander angewiesen.

Was du beschreibst, das ist eigentlich das Szenario, was für mich so unattraktiv finde, dass ich einfach alles schlucken muss, was man mir vorsetzt, oder ich komplett aussteigen muss - das System kenne ich schon vom €, warum wollen wir das mit Bitcoin nachbauen?

HF 100% Probleme garantiert in der aktuellen politischen Situation, da Chain Split

Segwit sehr gering.
Wenn wir davon ausgehen, dass wir von den Bugs letzter Zeit auf die Zukunft schließen können, ist der HF wesentlich gefährlicher, weil dann Clients, wie Bitcoin Unlimited und Bitcoin ABC mehr genutzt werden, die letzer Zeit durch Abstürze aufgefallen sind, während bei Segwit noch keinerlei kritische Fehler gefunden wurden, seitdem es in Bitcoin Core Releases war (27 October 2016).

LN ist ja sowieso unabhängig von Segwit - vielleicht kommt ja auch ein anderer 2nd Layer


Man sollte erstmal die politische Situation fixen, bevor man den HF durchzieht

Genau die Oma ist doch der Grund für SW.

Deine Oma wird nicht mal merken, ob sie SW benutzt, darum kümmert sich die Software, weil eine Transaktion mit Segwit Inputs oder Outputs für einen normalen Endanwender von einer normalen TX ununterscheidbar ist.

HF - das ist ja extrem verwirrend für deine Oma.
Auf einmal hat sie 2 unterschiedliche Bitcoins.
Vielleicht merkt sie das nicht mal - aber auf einmal sind Ihre Bitcoins viel weniger wert.
Dann wird deine Oma ein Angriff eines Replay Angriffs - ohje.

Kann dir mit Segwit nicht passieren.

2 MB HF Oma-Fail.


Wenn wir soweit sind, dass Oma Bitcoin benutzen kann, wird der normale Nutzer nicht mal merken, ob er LN nutzt oder nicht - also wo ist das Problem?

Okay - genau.
Immer wenn ein Computer von einer Oma gehackt wird, dann ist Windows tot, das Internet tot etc.
Wenn Oma mal wieder das Bargeld geklaut wurde, dann hat das auch kaum Auswirkung darauf gehabt, ob andere Bargeld zuhause verstecken.

Ein beliebter Slogan bei Bitcoin war mal "Be your own bank".
Das geht aber auch nur, wenn man die entsprechende Verantwortung übernimmt und selbst für die Absicherung sorgt (Hardware Wallet, Paper Wallet, 2FA, etc.).
Ansonsten ist man wohl besser bei einem zentralisierten Service aufgehoben.

Was wolltest du überhaupt sagen? Das hat ja 0 mit LN zu tun.