Ich nehme das sehr ernst mit LN.
Aber es bleibt jedem frei LN zu nutzen oder nicht.
Warum willst du es den Leuten verbieten es zu nutzen?
Die Bitcoin-Technologie die dahinter steckt ist ja bereits seit Jahren getestet.

Und LN Software wäre zu dem Zeitpunkt dann schon 3 Jahre in Entwicklung.

Es geht also darum, ob wir der Software vertrauen, die dahinter steht.
Das das nicht so einfach ist, sehen wir zum Beispiel an BitcoinABC, dass dadurch auffällt, dass es abstürzt und wohl noch nicht für den produktiv Betrieb geeignet ist.

Es ging darum das Christoph gesagt hat, dass der Kapazitäts Anstieg recht langsam wäre.
Das würde aber heißen, dass Segwit für die nächsten 2 Jahre reichen würde, vor allem, wenn wir an Schnorr und MAST denken.
Das heißt wir bräuchten die nächsten 2 Jahre überhaupt keinen Blocksize Hard Fork und dann wäre das einfach nur absoluter Wahnsinn den trotzdem zu machen.

LN hin oder her, das würde man zumindest in 1 Jahr abschätzen können, wieviel das bringt.

SF - HF - Egal, hauptsache kein Chain Split

Ja ich bin absolut für KISS.
Aber bei KISS muss man alle Auswirkungen betrachten - Nicht nur, was man initial an Aufwand spendieren muss, sondern auch, was die Auswirkungen auf User, Miner, Exchanges, Entwickler, Codegröße (Bugpotential) sind.
2 MB HF ist eben nur bei einer Größe einfach und verstößt bei allen anderen Punkten gegen KISS.

Wenn das wirklich so wäre, dann würde nur Segwit ja erstmal reichen.
Und in 2 Jahren hätten wir Lightning, das heißt Segwit würde für die nächsten 5 Jahre reichen.

Nein - das ist das, was ich für realistisch halte - wir sehen doch gerade eine Explosion im Bereich Kryptowährungen
Edit:
Ich bin der Meinung, dass wir bisher ein beschränktes Wachstum hatten, weil klar war, das nicht genug Blockspace für neue Anwendungen zur Verfügung stand.
Wenn sich dieser Umstand ändert, dann gehe ich auch davon aus, dass die Wachstumskurve exponentiell bis hyperbolisch ansteigt.

Ja - dann muss man eben die Situation annehmen.
Aber nein, es wird seit Jahren rumgeheult, dass die Core Devs ja so gemein sind.
Das ist auch nicht KISS und vor allem nicht hilfreich.

Deswegen ist ein "einfacher" 2 MB HF ist ja nicht mal aus Entwicklersicht KISS konform, denn der Entwickler muss auf einmal erklären, warum 2 Bitcoins besser als 1 Bitcoin ist oder das kein Problem ist, dass jeder einzelne Benutzer manuell eingreifen muss. Mal abgesehen davon, dass eine Konsequenz auch ist, dass die SPV Client Entwickler jetzt erstmal Lösungen entwickeln müssen um die "Stealth-Hard-Forks" zu unterstützen.

UASF BIP 148 verstößt meines Erachtens ebenso gegen das KISS Prinzip, weil es extrem komplizierte Konsequenzen hat.

Wenn etwas sehr schlecht ist und das andere extrem schlecht, dann sind nicht unbedingt Lösungen, die wir verfolgen sollten.

Wir sollten uns darauf beschränken, was auch in der Vergangenheit funktioniert hat, vor allem aus Anwendersicht.
1 Bitcoin, Software weiter verbessern, so dass es für die Endanwender einfacher wird Bitcoin zu nutzen.
Wenn das nicht ohne größeren Entwicklungsaufwand geht, ist das vielleicht nicht schön, aber die Realität.

Segwit ist fertig entwickelt und getestet.
Das jetzt einfach zu nutzen, weil es schon da ist, entspricht dem KISS Prinzip, vor allem aus Sicht der Endanwender.

Edit:
Wenn wir wollen, dass Hard Forks so ablaufen, wie bei den Altcoins, dann müssen wir bei Bitcoin die Voraussetzungen dafür schaffen, dass dies eben auch so ist - also ein Hard Fork darf nicht umstritten sein.

Das ist doch ein absoluter Trugschluss.
Resultat:
2 verschiedene Bitcoins
2 verschiedene Codebasen

Das ist sowas von extrem weit weg vom KISS Prinzip.

Segwit ist sicherlich komplizierter als ein 2 MB Hard Fork, aber viel einfacher als 2 verschiedene Bitcoins, kommt KISS also viel näher.

Edit es stellt sich immer die frage für wen "KISS":
Segwit:
Umstrittener Hard Fork - KISS für Entwickler, maximal kompliziert für alle anderen

Ich hab überhaupt nichts gegen On Chain, solange die Auswirkungen kontrollierbar bleiben.

Aber warum sollte man dann den mit Abstand schwierigsten und zerstörerischsten Weg nehmen, also einen umstrittenen Hard Fork mit sehr hohem Chain Split Risiko, der dazu führt dass es mehrere Bitcoins gibt?

Es gibt doch genug Alternativen - Segwit - Extension Blocks - Blocksize Soft Fork (mit etwas mehr Vorbereitungszeit ist das dann auch nicht unbedingt ein Evil-Soft Fork) - Sidechains - Off-Chain.

Und genug Altcoins mit den gewünschten Eigenschaften gibt es auch schon.

32 MB könnten wir in 1-2 Jahren doch locker füllen.

Und wenn klar ist, dass man auch 128 MB Blöcke haben könnte gibt es auch sicher neue Use-Cases, dass heißt, wir würden das auch in 3-4 Jahren easy schaffen die 128 MB Blöcke zu füllen. Unternehmen wie Amazon nehmen doch derzeit überhaupt kein Bitcoin an, weil alleine sich mit dem Zweck mehrere MB pro Block füllen ließen.

Und wie schön du das beschreibst, das eins nach dem anderen kommt.
Heißt das, dass wenn wir nicht automatisch langsam in so ein abhängiges System rutschen wollen, bereits jetzt Widerstand leisten sollten?

Ich meine Roger Ver sagt ja immer, dass wir nicht das an Bitcoin zerstören sollten, bei dem wir wissen, was funktioniert, sondern das machen sollten, was wir immer schon gemacht haben, wenn das auch in der Vergangenheit funktioniert hat.

Die Blockgröße wurde  in der Vergangenheit von Bitcoin ohne Hard Fork mehrmals angehoben. Wenn es Hard Forks gab waren diese nicht umstritten. Also sollten wir doch bei dieser Vorgehensweise bleiben.

Es war immer einfach genug einen eigenen Full Node auf dem eigenen Computer laufen zu lassen, so dass es viele gab und man als SPV Client sich keine Sorgen um die Sicherheit machen musste.

Bitcoin hatte immer den größten Netzwerkeffekt von allen Kryptowährungen.

Warum wollen wir diese Eigenschaften zerstören indem wir die Blockgröße mit einem umstrittenen Hard Fork anheben, der zu einem Chain Split führt und damit aktiv den Netzwerkeffekt untergräbt?

Warum bleiben wir nicht bei den Methoden, bei denen wir wissen, dass diese auch in der Vergangenheit funktioniert haben?
-Ein Netzwerk
-Ein Bitcoin
-Keine umstrittenen Forks, die zu Chain Splits führen können
-Erhöhung der Transaktions Kapazität

P.S.
Ich persönlich finde nicht, dass ein Full Node unbedingt noch auf einem Raspi laufen können muss


Warum sollten Shops nicht einfach Bitpay nehmen?
Die Maschine kostet ja nicht nur 20.000$ in der Anschaffung, sondern auch einen hohen, laufenden Unterhalt, z.B. Strom, Versicherung, Gebäude, Personal (Ingenieure) etc.

Ja - ich weiß das es die aktuell gibt. Die Frage zielte in eine andere Richtung.
Wenn es nur noch wenige Full Nodes gibt, wird es dann das immer noch in der Form geben? Gibt es immer noch Full Nodes zu denen man sich kostenlos verbinden kann, oder muss man dann dafür bezahlen (weil kostenlose Nodes überlastet sind).

Unter welchen Umständen würde es kostenlos bleiben können? Bei sonstigen kostenlosen Diensten im Internet geht es immer darum entweder die Nutzerdaten abzugreifen und zu vermarkten, oder andere Produkte zu verkaufen, oder Werbeeinnahmen zu generieren. Die Dienste setzen bisher aber auch auf zentralisierte Plattformen, damit hätten wir dann aber auch keinen Vorteil mit sehr großen Blöcken, weil zentralisierte Services funktionieren auch mit der aktuellen Blockgröße.

Ist schon klar, dass das nicht von heute auf morgen passiert.
Wir haben ja jetzt die Situation, dass es noch so günstig ist einen Node laufen zu lassen, dass es genug Leute gibt die das einfach so machen.

Bei welcher Blockgröße kippt das?
Bereits bei 4-8 MB wird es zwar messbar sein, aber wann wird es kritisch - 32 MB sind schon über 1,5 Terrabyte pro Jahr.

Würde mich auch interessieren.
Wie wird das, wenn es so ist wie in CSW Vision, dass ein Full-Node 20000$ kostet.
Muss man dann bezahlen um die Services von dem nutzen zu können?

Wird das dann so wie mit dem Usenet, dass man ein Bitcoin-Network-Provider braucht?

Lieber einmal mehr nachfragen, wenn es hilfreich ist.
Ist alles nicht immer so leicht zu verstehen vor allem wenn man die ganzen BIP Nummern nicht im Kopf hat. Wenn ich mich so viel damit beschäftige, dann kann es auch mal passieren, dass ich zu sehr mit den Details verliere und dann die einfache Verständlichkeit verloren geht.

Finde ich gut, wenn man nachfragt, falls man nicht alles verstanden hat.
Denn wenn man es selbst nicht verstanden hat, dann wird es wahrscheinlich auch andere in der Community geben, denen es genauso geht.
Der Thread enthält zwar sicher schon einiges, aber solange die Fragen sich nicht wiederholen gibt es sicher kein Problem.
Und ein gewisser Teil liest hier sicher auch einfach nur mit und die können dann auch davon profitieren.

Sehr schön geschrieben - und auch noch so schön formatiert  

Momentan schätze auch ich Szenario 2 als sehr viel wahrscheinlicher ein.
Szenario 1 ist sehr chaotisch und die Auswirkungen und Entwicklung schwer absehbar, kann mir nicht vorstellen, dass da viele Miner mitziehen, wenn sie mit Szenario 2 erstmal Ruhe haben können.
In 10-12 Tagen, wenn die tatsächliche Signalisierung für Szenario 2 anfängt, wissen wir, wie es aussieht

Edit:
Bin mal gespannt, wie das bei Slush aussieht - da kann man momentan noch nicht für Szenario 2 stimmen.

tldr;
BIP148 und BIP91 sind beide nur BIPs, die dafür sorgen, dass es eine Koordination gibt um BIP141 Segwit zu aktivieren.


1. so ungefähr Segwit2x  enthält ein in den Zeitpunkten leicht abgeändertes BIP91 um das normale BIP141 Segwit zu aktivieren. BIP91 erfordert 80 % Hashpower - Start für das Miner Signaling 21. Juli, frühestens 23. Locked in, ab 25. aktiv
Segwit2x ist praktisch BIP91 + BIP141 + 2MB Hard Fork (der Hard Fork kommt ja aber erst später, wenn überhaupt)

2. Ja originale chain

Ergänzung zu 1.
BIP91 ab 25. aktiv würde bedeuten, dass dann nur noch Blöcke gültig sind, die das Bit für die Aktivierung von BIP141 Segwit signalisieren. Das heißt wir hätten zu 100% Blöcke die für die Aktivierung von BIP141 signalisieren.

BIP148 macht praktisch das gleiche, wie BIP91, nur das bei BIP91 die Miner vorher signalisieren.
Es geht darum, dass die Miner sagen können Sie hätten Segwit BIP141 aktiviert und nicht die User über BIP148.

BIP141 Segwit braucht eine Difficulty Periode (2016 Blöcke, ungefähr 2 Wochen) mit 95% aller Blöcke, die die Aktivierung Signalisieren, dann geht es in den "Locked In" Zustand. Eine Difficulty Periode später geht es dann in den aktiven Zustand.

Das heißt, bis wir Segwit nutzen können ist frühenstens Ende August, je nachdem, wann die Difficulity Perioden dann wirklich anfangen.

Da ist nicht nur UASF BIP148 gemeint, was von Luke-Jr gepushed wird, sondern auch der UAHF (haha was für ein Euphemismus) von Bitmain.
Das heißt es könnte kurzfristig 3 verschiedene Bitcoins geben - Das alte Bitcoin - BIP148 Bitcoin - Bitmain Bitcoin.
Das alte Bitcoin existiert nur, solange es mehr Hashpower als BIP148 hätte.

Aber vorher kommt ja der BIP91 ähnliche Teil von Segwit2x. Das heißt, wenn sich die Miner tatsächlich am 21. Juli anfangen den BIP91 Teil von BTC1/Segwit2x zu signalisieren und der am 23. Juli (bzw. spätestens am 29. Juli) dann in den "Lock In" Zustand übergeht, passiert am 01. August überhaupt kein Split.

Schöne Timeline:
http://imgur.com/WDhWkHx

Also ich warte jetzt erstmal die 10 Tage ab.

Kleiner Nachtrag:
Das HF Bit wird laut Jeff Garzik nicht genutzt, damit Lite-Wallets nicht upgedated werden müssen.

Folge davon ist, dass diese Wallets auch keine einfache Möglichkeit haben auszuwählen, welchen Fork sie nutzen wollen.
An der Stelle will man sich wohl den Hard Fork sparen und nutzt aus Sicht eines Lite-Wallets einen nicht feststellbaren Soft Fork.

Falls der Hard Fork auch in der Hashrate kontrovers wird heißt das, dass das Lite Wallet zwischen den Chains hin und herspringen könnte.
Wer Lite-Wallets nutzt, sollte also die Tage nach dem Hard Fork lieber keine Transaktionen machen, soweit er nicht sicher auswählen kann, welche Chain er benutzt.


Quellen:
https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000096.html
https://github.com/btc1/bitcoin/pull/46

Ja Testnet5 synchronisiert auch ohne Probleme wieder mit dem btc1 Client, nachdem der Block jetzt entsprechend den in dem Testnet5 gültigen Hard Fork-Regeln von btc1/Segwit2x neu gemined wurde.

An dem Tag an dem der HF kommt würden die Pool-Betreiber auch hoffentlich wachsam sein und könnten innerhalb von wenigen Minuten eingreifen. Die Situation im Testnet5 mit sehr wenig Hashpower ist schon etwas anders. Vor allem, weil es meines Wissens im Gegensatz zum Mainnet bei dem Hard Fork keine festen Regeln gab, wann der Hard Fork zu erwarten war. Vertrauensbildende Maßnahmen sehen natürlich anders aus.

Absolut richtig - Weil alte Clients den Block ebenso als ungültig ansehen würden, bietet ein erzwungen gesetzes MSB / HF-Bit zum Zeitpunkt des HFs eine einfachere Möglichkeit für Wipe-Out Protection, als ein erzwungener großer Block, bei dem man von äußeren Zuständen abhängig ist.

Einziger Vorteil ist, dass man sich bei dem HF sicher sein kann, dass alle die mitgehen tatsächlich für mindestens einen Block lang Blöcke größer als 1 MB auch unterstützt haben.

Genau -> Segwit2x nutzt den in BIP 91 beschriebenen Prozess um Segwit BIP 141 mit 100% zu aktivieren.
Wenn alles nach Zeitplan läuft, dann werden die Blöcke alle kompatibel zu:

• Den alten Regeln (Bitcoin Core 0.12 / Bitcoin Unlimited & Co.)
• Segwit BIP 141 über BIP 9 Aktivierung mit 95%
• Segwit2x über einen BIP 91 Prozess
• UASF BIP148

Das heißt, dass die Blöcke alle zuvor genannten Regeln (BIPs) befolgen müssen - die BIP 148 Regeln werden praktisch nebenbei mit befolgt, dafür sorgt BIP 91, wenn es rechtzeitig aktiviert wird.

Danke erstmal für die positiven Rückmeldungen  

Kann mir nicht vorstellen, dass das ein echter Showstopper ist.
Die Lösung bei Segwit2x ist eben alles andere als elegant, auch weil die Miner wohl manuell eingreifen müssen um gültige Blöcke minen zu können.

Zur Not steht die Blockchain eben mal ein paar Minuten, falls der Mempool leer ist.
Grundsätzlich lässt sich der Mempool ja schon vor dem kritischen Block füllen. Bitmain oder Roger Ver werden die dafür anfallenden Gebühren wohl kaum stören.

Einfach das Most Significant Version Bit (manchmal auch Hardfork Bit genannt) zu setzen ist sicherlich einfacher und eleganter, weil das nur von der Blockhöhe und keinen anderen Zuständen abhängig ist.
Im Mainnet kommt der kritische Zeitpunkt ja erst ungefähr gegen Ende Oktober, wenn ich das richtig im Kopf hab.

Leute, die jetzt schon überzeugt sind, dass sie den Hard Fork nicht mitgehen sind jetzt eben noch etwas mehr darin bestärkt.
Leute die unentschieden waren - wer weiß, wie sich das bei denen auswirkt.
Leute, die den Hard Fork unbedingt durchziehen wollen wird das wohl kaum abhalten, am wenigsten solche Miner, welche den Hard Fork unbedingt wollen und dafür auch mal 10 Minuten Verdienstausfall in Kauf nehmen werden.

Weil es keine standardisierte Software gibt - es ist einfach für eine normale Person nicht nutzbar und leider gibt es momentan Nur Payment Channels in eine Richtung und nur mit begrenzter Lebensdauer, da OP_CSV meist nur genauso wie OP_CLTV einsetzbar ist, dank der Malleability.

Aber bis sich das ändert, ist es ja nur eine Frage der Zeit.

Ich hab nie gesagt, dass Bitcoin Schrott ist.
Bitcoin macht eben das gut, wofür es designed wurde.
Und Bitcoin könnte auch noch viel mehr, als wir aktuell nutzen (und was Satoshi bestimmt auch wollte - Malleability war sicherlich nicht absichtlich), wenn die Voraussetzungen durch Technologien, wie Segwit geschaffen werden.

Die Diebstähle von Mt Gox und Bitfinex waren ja auch keine direkte Schwachstelle in Bitcoin - aber Bitcoin unterstützt das leider nun mal On-Chain nicht, deswegen wurde das immer über das verwundbare zentralisierte Off-Chain gelöst.

Das heißt, wenn wir sowas in Zukunft verhindern wollen, dann brauchen wir eben dezentralisiertes Off-Chain. Selbst wenn LN komplett zentralisiert wäre - wenn der zentrale Hub gehackt wird betrifft das nicht die User - denn es kann nur das Geld geklaut werde, was gerade dem zentralen Hub gehört - der Nutzer behält sein Geld, was er im Channel hatte.
Sowas geht einfach nicht mit On-Chain.

Das wäre schon mal sehr wichtig.
Dann wäre sicherlich noch Weak-Blocks oder sowas wie Bitcoin-NG wichtig, dann haben wir tatsächlich Voraussetzungen, damit wir Blöcke größer als Segwit-2x ohne größere Nachteile verarbeiten können.

Beim einen geht es um Off-Chain Payments allgemein und zwar eher um Ad-Hoc Payment Channels - Ich hab in dem Beispiel auch nicht von LN geredet, aber wenn man einen neuen Channel aufmacht hat man sowieso nicht das Problem was du beschreibst und könnte dafür auch LN nehmen.

Beim zweiten geht es um eine theoretische Struktur aus einem mathematischen Modell für LN und zwar wenn das LN bereits so weit entwickelt wäre, so dass man kaum noch Off-Chain braucht.

Außerdem ist das 2. Modell nicht optimiert, da es einzig um alleine darum ging zu zeigen, dass z.B. Routing in so einem großen Netz funktionieren kann.
Wir wissen, dass LN technisch gut in kleinen Netzen funktioniert, aber das war der erste Versuch das mal für ein großes Netz zu simulieren.
Es lässt sich daraus aber nicht ableiten, wie viele Bitcoins man tatsächlich für ein Netzwerk in der Größe braucht, oder ob man überhaupt ein Netzwerk in der Größe braucht.
Die benötigten Bitcoins könnten dafür in der Realität durchaus eine ganze Größenordnung weniger sein.

Das LN schon im kleinen Maßstab nützlich sein kann und wir für das Szenario die technischen Grundlagen bereits haben, stellt das ja überhaupt nicht in Frage.
Das andere Szenario ist eigentlich nur für den Fall interessant, ob es möglich ist mit den bisherigen Blockgrößen dauerhaft auszukommen, wovon ich nicht überzeugt bin.


Und klar, wir haben ja genug über Pruning geschrieben.
Pruning funktioniert - allerdings wenn wirklich viele Leute anfangen zu prunen bei 1 TB / Jahr, dann wird es innerhalb kurzer Zeit extrem schwer überhaupt eine neue Node syncen zu können.
Also bevor wir Pruning ernsthaft in der Masse nutzen wollen bitte Clients mit funktionierenden UTXO Commitments oder andere Technologien die ein syncen wieder sicher möglich machen.

Du kannst einen Effizienzgewinn um einen beliebigen Faktor ja auch nutzen um die entsprechende Anzahl mehr Leute in das Netzwerk zu holen.
Wenn man keinen Vorteil hat das auf der Blockchain zu settlen als Nutzer und es funktionierende Alternativen gibt, dann bleibt es einfach verschwendete Bandbreite und Blockspace.

Es gibt auch nicht nur neue Anwendungszwecke durch Kapazitäts Gewinne bei Off-Chain Transaktionen, sondern eben auch neue Einsatzzwecke durch eine höhere Sicherheit in manchen Anwendungsszenarien (siehe mein Börsen Beispiel). Es ergibt daher auf jeden Fall Sinn das weiter zu verfolgen.

Du kannst mit Off-Chain Transaktionen ohne Probleme Beträge von 0,01 ct und noch viel kleinere Beträge überweisen, also viele Services dann extrem genau abrechnen, während das auf einer Blockchain ohne Blockgrößenbeschränkung, aber mit Fee zur Spamcontrol nicht möglich ist, da wir auch dann noch mehrere cent Gebühr pro Transaktion haben werden. Oder wie wäre das für Online-Kasinos? Da könntest du mehrere Transaktionen pro Minute (wenn man will auch pro Sekunde) pro Benutzer problemlos verarbeiten, während das On-Chain einfach nicht skaliert.

Edit:
Hatte als ich 10 Mio als Beispiel genommen und nicht die 10 M Challenge im Kopf - die Zahl hatte ich einfach nur so gewählt - alle Gemeinsamkeiten sind zufällig, ist eben eine einfache Zahl zum Rechnen

Was aber nicht so cool ist, dass auf 1 Tx pro Tag zu beschränken.
Das ist ja nur notwendig, weil man auf einer Blockchain immer ein Settlement hat und das eben teuer ist, weil alle das nachvollziehen müssen.

Die Bandbreite ist für viele sicher kein Problem.
Aber was auch nicht so cool ist ist, dass du dann 1 TB pro Jahr an Daten hast - ganz schön blöd, wenn 90+% davon hätten eingespart werden können.

Naja - es ging ja zunächst auch um die Sicherheit von On-Chain vs. Off-Chain und bei dem Beispiel darum, dass man Off-Chain eben neue Möglichkeiten hat.

Denken wir mal an eine Exchange, bei der man seine Coins nicht mehr vorhab einzahlen muss, sondern stattdessen einen Payment-Channel aufmachen kann (oder bereits offen hat) und die Coins erst Millisekunden vor der Transaktion an die Börse Off-Chain übereignet werden, wenn man Fiat benutzt, oder bei einem Cryptocoin zu Cryptocoin Trade mit einem HTLC sogar beides zeitgleich als Atomic Swap ausgeführt wird. Zudem kenn ich aktuell keine Börse die 0-conf Transaktionen annimmt.

Das sind Einsatzzwecke, bei denen man Off-Chain das Risiko komplett aussparen kann, dass man seine Coins auf der Börse verliert, was in der Vergangenheit leider öfter vorgekommen ist (Mt. Gox, Bitfinex & Co.).
Da ist klassisch On-Chain und dann zentralisiert viel viel Risikoreicher, weil die Gegenseite immer die Möglichkeit hat zu betrügen oder die Coins von der Börse geklaut werden können.