Du kannst gerne versuchen da Fehler zu finden.

Nur mal ein Beispiel. Um die theoretische Leistungsfähigkeit einer Off-Chain Technology on chain zu haben bräuchtest du praktisch unendlich große Blöcke.
Eben so große Blöcke, wie Nodes Off-Chain Transaktionen untereinander aushandeln können - also pro Node mindestens 10 Transaktionen / Sekunde
Bei angenommen 10 Millionen Teilnehmern kommen wir dabei schon auf 2,5 Gbyte/s, wenn eine Transaktion 250 Byte hat.
Versuch mal einen Bruchteil davon über eine Blockchain zu schieben.

Das ist natürlich nur ein rein theoretisches Beispiel - der Vorteil ist eben, dass die Masse der Transaktionen nicht von allen Knoten im Bitcoin Netzwerk überprüft werden muss, sondern nur das öffnen und das schließen des Payment Channels.

Der Rest der Transaktionen wird nur im Fehlerfall oder auf Wunsch eines Teilnehmers ins Netzwerk übertragen und wird dann zur on-chain tx.

Der Ablauf ist bei allen dezentralisierten 2nd Layer Lösungen grundsätzlich ungefähr so:

1. Eine On-Chain TX1 zum eröffnen des Payment-Channels
2. Beliebig viele Off-Chain TX
3. (optional) On-Chain TX2 zum schließen des Payment-Channels
4. (optional) Im Falle, dass eine Seite bei der Veröffentlichung der On-Chain-TX2 betrogen hat, wird eine On-Chain-Strafzahlungs-TX aus der On-Chain TX2  fällig, die dem Betrogenen gutgeschrieben wird

Solange On-Chain TX sicher sind kann man auch die Off-Chain TX sicher machen.

Edit:
Ja für Off-Chain braucht man aber auch indirekt den "PoW Zirkus".
White Paper gibt es bereits lange
https://lightning.network/lightning-network-paper.pdf

Hast du dir mal das LN Paper durchgelesen?
Es gibt da keine Schnittstelle im eigentlich Sinne.

Alles sind ganz normale (Segwit) Bitcoin Transaktionen, die aber nur veröffentlicht werden, wenn es sinnvoll ist.

Die Schnittstelle ist also die selbe, wie eine normale Bitcoin Transaktion, die man in das Netzwerk veröffentlicht für On-Chain Payments.
Wenn man der nicht vertraut, kann man keine On-Chain Payments nutzen.

Der PoW Zirkus ist dafür, dass man On-Chain und Off-Chain nutzen kann.
Denn ohne On-Chain gibt es auch kein dezentralisiertes Off-Chain.


Edit: Das geht sicher, hätte aber nur zusätzliche Nachteile - da kann man ja gleich on-chain nehmen und hat eben "nur" die bestehenden Nachteile, dass eine dezentralisierte Blockchain leider immer ineffizienter als ein zentralisiertes System ist

Wow - unter welchen Gesichtspunkten?
Pauschal würde ich weder sagen das eine on-chain tx sicher als eine off-chain tx mit dezentralisierter Technologie, noch, dass dies anders herum gillt.

Double Spend Risiko ist bei einer on-chain tx höher, solange die Transaktion nicht unter genügend PoW vergraben ist, da dies bei richtigem Design bei einer off-chain tx nicht möglich ist, bzw. der Betrüger dem Betrogenen eine sehr hohe Strafgebühr zahlen muss  (zum Beispiel bei LN wird es so gemacht).

Eine 2nd layer tx kann weniger sicher sein, wenn die Software die man für die 2nd Layer tx nutzt weniger sicher ist, bzw. nur online funktioniert und deswegen leichter gehackt werden kann.

Denk dir beliebige Sachen aus.

Edit:
Und für die Sicherheit durch PoW ist es analog.
Off-Chain kann die Sicherheit erhöhen, wenn die Gebühren on-chain durch die off-chain tx gehebelt werden und der Wert des Bitcoins dadurch steigt, weil Bitcoin nützlicher ist und somit der Blocksize Reward steigt.
Das Gegenteil kann man natürlich auch behaupten, aber das haben die Miner in der Hand.

Bitte beziehe dich auf was konkretes, so das auch ich und andere verstehen, was du meinst und darauf dann korrekt antworten können.

Ich lese nur Schlagworte - Bitte im Zusammenhang mit dem, was du an meinem Text kritisieren willst.
Und wenn du mir mangelndes Verständnis unterstellen willst, dann bitte noch ausführlicher  

Ich hab dich ja gefragt warum.
Weißt du es nicht?
Bzw. was hältst du für die wichtigen Punkte.

Edit:
Also grundsätzlich - Warum PoW
Und wie erhöht sich die Sicherheit durch mehr PoW

Ja - Aber Sicherheit vor wem? Vor allem vor "bösartigen Minern", Zensur und Double Spends? - Vor wem oder was noch?
Die Sicherheit des eigenen private Keys, oder die Sicherheit vor Hackern ist ja unabhängig davon.

Die dezentralisierten Off chain Transaktionen basieren ja auf On Chain Transaktionen, also erben diese bei entsprechendem Design die Sicherheit der On Chain Transaktionen.
Ggf. sind ein paar Anpassungen sinnvoll - vgl. Bcoin Extension Blocks mit Möglichkeit zur Kapazitätsreservierung.

Die Sicherheit vor Hackern ist sicher nicht schlechter als bei einem Hot-Wallet, womit es üblicherweise konkurrieren wird.

Jedenfalls senken dezentralisierte Off-Chain-Transaktionen nicht die On-Chain Sicherheit, wenn stattdessen überhaupt nicht Bitcoin benutzt werden würde, da sich neue Use-Cases ergeben.

Okay - War es ein contentious Hard Fork?
Wieviele Entwicklerteams waren dagegen? War der meist eingesetzte Client nicht zu dem Hard Fork kompatibel?
Wieviele Entwicklerteams gibt es überhaupt bei der Coin.
Gibt es mehrere politische Lager die sich bekämpfen?

Ist die Situation irgendwie mit Bitcoin vergleichbar?
Wie kann man bei Bitcoin ähnliche Voraussetzungen schaffen?

Hard Forks sind nicht grundsätzlich schlecht, aber wenn sie umkämpft sind, dann sind sie eben extrem schwierig und führen schnell zu zwei Chains.
Und wenn wir eben wie bei Bitcoin mittlerweile teilweise die Situation haben, dass die Lösungen der einen Gruppe grundsätzlich inakzeptabel für die ander Gruppe sind, dann müssen wir eben andere Wege finden.

Es wäre sicher einfacher gewesen, wenn man Segwit frühzeitig aktiviert hätte. Ich find den Gedanken überhaupt nicht doof, sondern beruhigend.
Du weißt ja wie das mit Analogien bei Bitcoin ist - meine findest du ja auch nicht so toll - ich bin jetzt auch nicht von deiner begeistert, denn immerhin bewegen wir uns in die richtige Richtung und packen das in unseren Rucksack (Malleability Fix, etc.), was wir sowieso für unterwegs brauchen und uns schneller zum nächsten Ziel vorankommen lässt (Effizienzsteigerungen wie Schnorr - Senkung des benötigten Blockspaces).

MAST und Schnorr zusammen werden langfristig auch nicht genug bringen - die Frage ist eben, bringen sie zu dem Zeitpunkt wo sie kommen für die absehbare Zeit bis zur nächsten Maßnahme genug?

Wenn Segwit wirklich kurzfristig nicht reichen sollte, dann würden viele das eben auch nicht mehr glauben, dass die kleinen Maßnahmen ebenso reichen.
Ich glaub ich habs schon öfter gesagt, dass ich das nur im Zusammenhang mit Sidechains (insbesondere RSK) und Extension Blocks mittelfristig (die nächsten paar Jahre) für ausreichend halte.

Falls Sidechains und Extension Blocks nicht funktionieren, oder einfach nicht angenommen werden, lässt sich das zumindest auch relativ leicht rückgängig machen, entweder indem man direkt das UTXO Set kopiert, oder den Leuten bis zu einem bestimmten Zeitpunkt die Möglichkeit gibt ihre Bitcoins wieder in die Main-Chain zu übernehmen, während man das bei Segwit und Emergent Consensus Blocksize aus politischen und technischen Gründen nicht ohne massive technische und ökonomische Auswirkungen rückgängig machen können wird.

Ja es ist höchstens ein mittelbarer "Angriff", weil die 2nd Layer Technologien momentan auf Segwit aufbauen.
Ein Machtspiel ist es allerdings definitiv, weil er ökonomische Incentives dafür ignoriert. Das Bitcoin Protokoll gibt ihm allerdings diese Freiheit - soll er halt machen.
Für mich umso mehr ein Grund, dass ich lokal ein Bitcoin Node habe, da solche Maßnahmen für mich nicht das Vertrauen in die Miner stärken.

Ja es ist egoistisch, aber momentan gibt es meiner Meinung nach noch genug nicht ausgeschöpfte Maßnahmen.
Und wie wir sehen können hat es doch genug Einfluss, so dass die Miner nicht einfach einen Hard Fork durchgezogen haben.
Und im schlimmsten Fall - auch die Raspi entwickeln sich technisch weiter - und die Clients werden auch besser.

Tragedy of the commons spielt aber auch in die andere Richtungen - Maximierung des eigenen Ertrags auf Kosten der Anderen. Bei der Blockgröße ist sogar sehr offensichtlich, wenn die Miner einfach alles in die Blöcke schmeißen und einfache Nodes die Kosten dafür tragen - Nutzung von begrenztem Blockspace, wenn man die Transaktion nicht hätte On-Chain machen müssen, also wenn Kosten für die Nutzer der Blockchain höher ist, als der daraus entstehende gemeinsame Nutzen und damit die verbundene Wertsteigerung von Bitcoin.

Die Miner könnten ja auch an etwas arbeiten, damit normale Nodes entlohnt werden, so wie das bei RSK sein soll.

Dafür haben die Sidechains allerdings nicht mit der technical debt aus Satoshis Zeiten bei Bitcoin zu kämpfen, sondern können wesentlich effizienter arbeiten und gezielter optimiert werden

Ja das LN definitiv die Lösung ist, ist auch aus meiner Sicht quatsch, ich kann mir aber gut vorstellen, dass es helfen kann, wenn seine Zeit gekommen ist. Andererseits denke ich da eher wie Andreas Antonopoulos, dass wir Scaling niemals abschließend lösen können, sondern das Scaling ein Ziel ist, dem man sich immer nur temporär annähern kann.

Edit:
Mir fällt da noch was ein.
Wäre es nicht ein Traum für die Anti-Core-Fraktion, wenn sich zeigen würde, dass Segwit Fehler enthält?
Noch ein Grund um Segwit zu aktivieren, wenn da doch so viel neuer Code mit so viel möglichen Bugs drin ist.
Damit könnte man wunderbar die Position der Core-Devs schwächen.
Man hat ja schließlich davor gewarnt, aber musste es ja leider auf Wunsch der Community aktivieren, deren Meinung so extrem durch Zensur beeinflusst wurde.

Ich denke mir nur immer dabei - super das müsste einen Big Blocker doch freuen.
Einfach die Leute das aktivieren lassen, dann wird sich zeigen, dass es nicht reicht, falls es so sein sollte.
Die anderen Verbesserungen in Segwit sollten Grund genug sein das zu aktivieren.

Wenn das für normale Nutzer offensichtlich wird, dass es nicht reicht, ohne dass Sie sich entscheiden müssen, welcher Doktrin sie sich unterordnen wollen, dann gibt es auch Konsens für andere Optionen zum Beispiel solche, die einen Hard Fork erfordern.

Ja ich werde mir Mühe geben - er wird eben sehr extrem gefeiert auf /r/btc und dann kommt mir das eben schnell in den Sinn
Hatte ja auch gesagt, dass ich mir den Vortrag noch mal anschauen müsste. Angriff ist ein sehr starkes Wort, vielleicht etwas zu stark. Aber ganz abwegig auch nicht, wenn er mit einem Mining-Pool aktiv dafür sorgen will, dass Segwit Transaktionen verlangsamt werden - das ist dann nämlich keine Kritik mehr, sondern etwas das darüber hinausgeht.
Präziser wäre es sicher zu sagen, dass es momentan kein Angriff ist, aber er etwas in der Art angekündigt hat.

Jihan Wu ist da nicht ganz so extrem - Meiner Meinung nach geht es Ihm eben darum möglichst viel Einflussnahme auf Bitcoin zu haben, was ich als problematisch empfinde. Roger Ver ist leider technisch schwach aufgestellt.


1. sehe ich nicht so, bzw. warum sollte man die Nachteile in Kauf nehmen wollen die das mit sich bringt? Nutzer sollten entscheiden, was Sie bevorzugen - und dazu gehört ebenso, ob Sie Lust haben eine Software zu nutzen, für die man einen 20.000 $ PC braucht, bzw. ob die Nutzer selbst einen Node laufen lassen wollen
2. Wenn wir mal Rootstock nehmen - das ist merged mined, saugt also 0 Hashpower ab
3. Ja das wird interessant - Es gibt Systeme, da kann man sich in der Theorie nicht erklären, warum sie funktionieren, aber in der Praxis funktionieren sie dann Problemlos - und es gibt Systeme, die theoretisch einwandfrei funktionieren sollten, aber in der Praxis scheitern. LN könnte beides sein - Es gibt ja Versuche beides mathematisch zu beweisen. Meine Meinung ist, dass wir es erst in der Praxis wissen können.

1. Ist eben Geschmack - Es ist allerdings nicht vollständig unberechtigt: Segwit Transaktionen verbrauchen zumindest weniger Rechenkapazität als alte Transaktionen (quadratic scaling) und die Motivation war ja, dass es nicht mehr kosten sollte einen UTXO Eintrag zu konsumieren, als einen UTXO Eintrag zu erstellen. Kann Kritik daran durchaus verstehen - in einem Hard Fork könnte man den Discount auch für alte Transaktionen einführen.

2. Wow - ernsthaft? Was wäre der Vorteil von einem Hard Fork? Ja genau, dass alle ihre Software anpassen müssen, weil sonst nicht mehr funktioniert! Tolle Idee. /s
Außerdem was ist noch bei einem Hard Fork? Dann kann es sein, dass es Leute gibt, die Ihre Bitcoins verlieren, weil diese Timelocked sind und bereits signierte, aber noch nicht veröffentlichte Transaktionen ungültig werden. Man kann nicht einfach ein neues Transaktionsformat einführen und das alte verbieten oder ändern ohne das Problem willentlich zu ignorieren, deswegen gibt es auch keinen einfachen Hard Fork Malleability Fix. Wir haben ja schon mehr oder weniger mehrere Bitcoin Clients mit mehreren Entwicklerteams. Bald wird es absolut unmöglich sein, solche Änderungen (Malleability Fix, Quadratic Scaling Fix) mit Hard Forks einfließen zu lassen. Das hätte Core vielleicht noch vor 2013 machen können, aber jetzt kann das niemand mehr.
Und worin besteht die technical debt? Das der Merkle-Tree-Root in der Coinbase-Tx und nicht im Block Header, bzw. die Merkle-Trees nicht zu einem verschmolzen sind? Dir ist schon klar, dass man extrem einfach in den Griff bekommt, indem man sauber modularisiert, bzw. das beschaffen des Merkle-Tree-Roots in eine Funktion auslagert? Achja - falls das wirklich technical debt ist, dann ließe sich das ja trivial in einem späteren Hard Fork lösen.

3. Es gibt mittlerweile so viele parallele Kommunikationskanäle - Ich schreibe nicht auf Reddit, weil beide beide Reddits Müll sind für Bitcoin und Ihre eigenen Agendas pushen. Und was hat das mit Segwit zu tun? Segwit und ein Hard Fork schließen sich ja nicht aus, vor allem wenn klar ist, was Segwit dann wirklich in der Praxis bringt.

4. Ja - Deswegen gibt es ja Segwit2x, die anderen Änderungen, welche Segwit mit sich bringt sind nämlich alle nützlich. Einfach Segwit aktivieren - gucken ob es reicht - wenn nicht andere Mittel nutzen und zwar das, was sich aus technischer, politischer und sozialer Sicht am einfachsten umsetzen lässt, ohne dass wesentliche Eigenschaften von Bitcoin in Mitleidenschaft gezogen werden.

Wir werden es nie schaffen das Scaling zu lösen, da es aus praktischer Sicht einen unbegrenzten Bedarf an günstigem Blockspace gibt, wir können nur versuchen, dass wir es immer wieder einen Schritt weiter voranbringen, ohne dabei die anderen Eigenschaften von Bitcoin zu zerstören und dabei eine Lösung zu haben die "gut genug" ist.

Hilf mir mal auf die Sprünge, was du meinst?!
Das gemeinsame Ideal gibt es nur bei unbegrenzten Rechenressourcen zu einem unendlich kleinen Preis und nur unter der Berücksichtigung, dass staatliche Stellen keine Möglichkeit haben das System zu zensieren oder zu unterwandern.

Haben wir aber leider nicht, von daher haben wir immer Zielkonflikte.

Deswegen ist für mich das erreichbare ideale System genau das, was gut genug ist um seine Aufgabe zu erfüllen - und im Laufe der Zeit im Rahmen der technischen Möglichkeiten an die Bedürfnisse der Benutzer angepasst und verbessert wird, ohne dass dabei grundsätzliche Eigenschaften verloren gehen, die das System charakterisieren.

Ich sehe momentan keinen Weg um ein gemeinsames Ideal zu erreichen, wenn es Leute wie CSW und Luke-Jr gibt, die auf ihren Extrempositionen beruhen. Wenn man trotzdem einen gemeinsamen Weg haben will, dann muss man eben Extension Blocks und Sidechains nutzen. Da können alle haben, was Sie wollen, ohne dass der andere darunter leiden muss.

Ich würde mich freuen, wenn du deine Segwit Kritik entweder vernünftig erklärst oder mal Stellung beziehst zu dem, was ich hier schon mehrfach geschrieben habe.

Edit:
Falls du meinst, dass ich zu einigen Dingen keine Stellung bezogen habe - d5000 hat in den letzten Antworten das so beschrieben, wie ich das auch im Großen und Ganzen sehe und deswegen nicht glaube, dass das mit einem so minimalen Satz an Regeln funktioniert. Lasse mich aber gerne eines besseren belehren, wenn belastbar gezeigt werden kann, wie das funktionieren könnte.

Natürlich kenne ich das wie die alten Tx gesigned werden - und das ist ein bisschen verrückt.
Weil das so kompliziert ist, ist das Resultat, dass wir TX Malleability haben und gleichzeitig auch noch Quadratic Scaling bei dem Hashing durch Signaturen.
Also Gottseidank macht Segwit das anders, da gibt es diese Probleme nämlich nicht.

CSW und Peter R. machen bei Ihrer Kritik an SW und den (in Wirklichkeit nicht) separaten Signaturen allerdings immer wieder einen riesen Fehler - Segwit funktioniert einfach so nicht. Ohne Signaturen ist die Transaktion und der Block für einen Segwit Client ungültig, was nach Aktivierung die deutliche Mehrheit des Netzwerks sein wird.

Es verhindert nur einen Hard Fork, wenn Segwit selbst genug echte Skalierung (On chain + Off chain)mitbringen würde - pass auf, dass du dir nicht selbst widersprichst.
Sehe nicht, warum Segwit nicht in Satoshis Sinn ist, der wäre als Pragmatiker sicherlich froh, wenn die alten Fehler behoben würden.

Und was soll das überhaupt heißen, nur HF bringt Skalierung?
Wenn wir auf dem Niveau argumentieren, dann bin ich verleitet zu sagen - nur HF bringt sofort die absolute Zentralisierung - alles andere bringt keine Zentralisierung.
Da ist zwar auch was wahres dran, aber auch viel zu einfach dargestellt.

Der Code von Bitcoin Core ist echt schwer zu lesen - trotzdem setzten viele wieder immer auf Forks von Bitcoin Core. Jetzt gerade erst BitcoinABC, die sich damit rühmen, dass sie Ihren Nutzern keine Wahlmöglichkeit lassen, ob diese Segwit benutzen wollen.

Es ist niemand gezwungen die Codebasis zu verwenden - aber so schlecht wird sie dann wohl doch nicht sein.
Ich persönlich würde eher auf eine Alternative zurückgreifen.

Das war sicherlich ein Fehler von Satoshi - er ist eben nicht perfekt, aber das musste er ja auch nicht sein. Umso schöner zu sehen, dass Bitcoin trotzdem funktioniert - es ist eben noch "gut genug".


Was CSW da beschreibst funktioniert einfach nicht. Ohne ein Hard Fork ist es nicht möglich, dass man Blöcke ohne Signaturen verbreiten kann. Wer sollte so bescheuert sein und so einen Hard Fork installieren?

Miner machen ja bereits jetzt ähnliches mit SPV und Spy-Mining und es gibt keinen Grund, warum die das nur mit Segwit machen sollten, aber nicht mit normalen Transaktionen. Für mich ist das FUD und verdrehung der Warheit um eine politische Agenda zu verfolgen.

Es hat schon einen Grund, warum die das nicht simuliert haben, bzw. keine Zahlungen in dem System modelliert haben, denn dann würde sich zeigen, dass sich die Blöcke ja gar nicht im Bitcoin-P2P-Netz verbreiten, weil die Blöcke ungültig sind ohne Signaturen.

Hab ich übrigens schon X-Mal hier geschrieben im Thread, schade, dass du das immer wieder überlesen hast, oder keine Fragen stellst, wenn du es nicht verstehst. Ich beantworte nämlich gerne Fragen, wenn ich damit jemand anders helfen kann.

Immerhin nicht die "AnyOneCanSpend" Fehldarstellenung.
Aber mal ernsthaft - hast du mal überlegt, wie viel Code geändert werden müsste in anderen Programmen, wenn der Malleability Fix per Hard Fork kommt? Das sind Code Monster.

Kann dir nur empfehlen Segwit genauer anzuschauen. Die BIPs sind relativ einfach zu lesen - und auch den Code kann man nach einiger Zeit ganz gut lesen.

Und sag mir mal bitte was daran nicht Satoshi ist? Die Idee? Der Code? Warum nicht?

Satoshi hat einige Ideen ziemlich genial kombiniert zu dem, was Bitcoin geworden ist, aber er war kein besonders guter Coder.
Guck dir mal den Signature Signing Code von Satoshi an da hast du dein Codemonster und ein schlechtes Design obendrauf.

Satoshi hat auch Payment-Channels beschrieben, seine Implementierung in Bitcoin 0.1 war allerdings unsicher.
Und zwar aus mehreren Gründen - erstmal weil wenn man mit Minern zusammengearbeitet hat, konnte man schummeln und das war nicht behebbar, weil Satoshi ja leider bei den Transaktionen aus versehen die Malleability eingebaut hat.

Oder noch viel mehr. Wenn der Speicherplatz in der Blockchain ist, mach ich gerne regelmäßig ein Backup meiner persönlichen Daten, anderen fallen bestimmt noch bessere Ideen ein - Satoshi Dice oder sowas.

Es gibt aktuell allerdings nicht genug Platz in der Blockchain, dass da jeder kleine Transaktionen drüber schieben kann. Deswegen bin ich ja auch nicht ganz abgeneigt gegenüber Segwit2X, damit man genug Zeit hat ausgereifte dezentralisierte 2nd Layer auszuprobieren, auch wenn man sich bei dem HF ruhig etwas mehr Zeit hätte lassen können.


Ich würde gerne damit bezahlen. Das hieße Bitcoin sei nützlicher und ich bräuchte weniger € - die Debit Karten liegen alle so bei 2-3 Prozent Gebühren, meistens versteckte Gebühren.

Hab daran schon beim Schreiben gedacht, dass dir das bestimmt in den Sinn kommt

Ich bin ja einer leichten Erhöhung nicht abgeneigt, aber es bleibt das Problem:
Die Blocksize Erhöhung ist Rückblickend nur der vermeintlich einfachste Weg:
Technisch muss man nicht viel anpassen - Quadratic Scaling Problem ist zwar extrem hässlich, aber der Worst Case verschlimmert sich immerhin nur linear mit einer kleinen Anpassung.

Das Problem ist aber - es ist der schwierigste Weg den man wählen kann, wenn man die sozialen / politischen Aspekte von Bitcoin berücksichtigt.
Die Small Blocker haben nur die Möglichkeit kompletten Widerstand zu leisten, weil es nicht Opt-In ist, wenn man der Chain folgen will - und trotzdem meinen viele Big Blocker, dass sie die Leute zwingen könnten sich Ihnen unterzuordnen indem sie dafür sorgen, dass die andere Kette keine Mining-Power oder ähnliches hat. Dabei gibt es ja Alternativen, vor allem Extension Blocks und Sidechains, mit denen man das gleiche erreichen kann, ohne die Smallblocker zu unterjochen bzw. die von den Smallblockern geschätzten Eigenschaften des Bitcoin zu zerstören.

Müsste mir den Vortrag von CSW noch mal anschauen, aber ich hatte das Gefühl, dass das klar ein Angriff auf dezentrale 2nd Layer war.

Es gibt ja bereits 2nd Layer Solutions
Zum Beispiel Unocoin in Indien um mit Bitcoin zu bezahlen - davon sehen die Miner dann eben 0 an Gebühren.
Damit funktioniert Bitcoin wunderbar im Retail.

Schön wäre es doch aber, wenn man die Mittelsmänner nicht zwangsweise nutzen muss.
Bargeld ist aktuell viel langsamer im Einzelhandel als per Karte kontaktlos zu bezahlen.
Da sind wir Deutschen schon im Vergleich zu unseren europäischen Nachbarn sehr konservativ.

Es ergibt einfach wenig Sinn dafür zu sorgen, dass Bitcoin absichtlich schlechter zu machen, wenn die Technologie zur Verfügung steht.
Die meisten Parameter die Altcoins angefasst haben bringen auch technische Nachteile mit sich - zum Beispiel kürzere Blockzeiten - höhere Orphanrate, etc.

Gerade dezentrale 2nd Layer Solutions werden sicherlich auch sehr stark vom Netzwerkeffekt getrieben werden.
Ob Lightning jetzt wirklich den Durchbruch bringt weiß ich nicht - und ja bis es für Endanwender nutzbare Software geben wird, dauert es sowieso noch mehrere Monate, dagegen aber aktiv zu kämpfen führt eben dazu, dass vor allem die Alternativen profitieren, wenn es dann funktioniert.
Wir haben jedoch großes Glück, dass es mit Litecoin eine technisch kompatible Altcoin gibt, die genug genutzt wird, dass wir uns immerhin nicht zu große Sorgen machen müssen, dass wir technologisch so weit zurück gegenüber Ethereum im Bereich dezentrales Offchain Payment zurückfallen, dass es sich überhaupt nicht mehr lohnen würde das für Bitcoin zu entwickeln, weil der Netzwerkeffekt bereits so groß bei der Konkurrenz wäre, dass der schwer einholbar wird.

Ein globales Settlement System wie eine Blockchain zu nutzen ist einfach nicht optimal für jeden Einsatzzweck.
Wenn wir keine volle Blöcke haben, dann bräuchten wir aber immer noch einen Schutz gegen parasitäre Nutzung der Blockchain, das heißt auch nach CSWs Vision wären die Transaktionen nicht kostenlos und somit nicht überall konkurrenzfähig, vor allem nicht beim Streaming von Geld.

Wirft auch ein schlechtes Licht auf Bitcoin, wenn die Miner versuchen zu bestimmen, dass Benutzer das nicht dürfen auf Ihrer Blockchain, das bei anderen Blockchains aber selbstverständlich ist.


Ich weiß nicht was du meinst.
Double Spends und neu geprägte Coins haben doch nichts mit Sidechains zu tun?
In der Sidechain werden keine Coins neu gemined.
Und von und zur Sidechain gibt es einen virtuellen Transfermechanismus.
Mal als Beispiel von Rootstock RSK im Testnet:
https://github.com/rsksmart/rskj/wiki/Convert-your-Testnet-Bitcoins-to-Ginger-Smart-Bitcoins-and-viceversa

Später wäre der Transfermechanismus im Wallet nur noch ein Button, aber aktuell muss man es eben manuell machen.

Sidechains sind vor allem in der Hinsicht genial, dass man keinen um Erlaubnis fragen muss um eine neue Sidechain einzuführen.

Mir ging es bei "theoretisch" vor allem darum, dass die Annahmen von Peter R. einfach extrem weit hergeholt sind sind, weil es kein Segwit gibt, das so funktioniert, wie er das beschreibt.
Man kann die Signaturen nicht separat übertragen.

Segwit Clients akzeptieren keine Segwit Blöcke ohne Signaturen, das heißt die Transaktionen finden aus Sicht von Segwit Clients nie statt.


Und zum anderen:
Warum ich glaube, dass Miner doch ein Interesse an 2nd Layer Solutions haben müssten:
Bitcoin konkurriert mit den Altcoins.

Bei Ethereum wird es 2nd Layer Solutions geben, bei anderen Altcoins (z.B. Litecoin) ebenso.
Das heißt, wenn andere Blockchains eine stark überlegene Benutzererfahrung mit unumkehrbahren Transaktionen in 1-2 Sekunden bieten und wir bei Bitcoin immer noch mit 10 Minuten Blockzeit arbeiten, dann wäre Bitcoin weniger wert, weil es weniger nützlich ist als die Alternativen.

Die 2nd Layer Solutions erhöhen den Wert von Bitcoin - die Transaktionsgebühren, die auf 2nd Layer anfallen stehen zwar nicht den Bitcoin Minern zur Verfügung, aber im anderen Fall würden diese den Bitcoin Minern auch nicht zur Verfügung stehen, denn es würde ja eine Altcoin benutzt.

Zumindest in den nächsten Jahren ist zudem der Blockreward noch ausreichend, so dass sich die Miner sowieso keine Sorgen machen müssen, dass auf 2nd Layer Transaktionsgebühren verloren gehen, solange der Wert des Bitcoins erhöht wird.

Das Whitepaper ist übrigens mittlerweile ungefähr 8 Jahre alt. Meiner Meinung nach ist die großartige Leistung von Satoshi vor allem, dass er bereits bekannte Technologien kombiniert hat und in die Praxis geführt hat. Wenn er die heutigen Technologien kennen würde, dann wäre das Whitepaper sicher etwas anders. Die Technik entwickelt sich eben weiter.

Edit:
Ein großer Teil der Transaktionen findet sowieso schon 2nd Layer Offchain statt und die Miner erhalten davon nichts an Transaktionsgebühren
siehe Unocoin in Indien, oder Coinbase
Der offensichtliche Unterschied ist, dass bisherige 2nd Layer Solutions zentralisiert funktionieren.
Die kommenden 2nd Layer Solutions sind dann eben dezentral.
Bei diesen erhalten die Miner zumindest ab und zu Transaktionsgebühren, da immer mal wieder ein Settlement auf der Blockchain notwendig ist.

Hrhr - Danke, dass du schreibst - meinte auch Donnerstag.
Morgen bin ich den ganzen Tag unterwegs, deswegen hab ich das wohl gedanklich übersprungen.

Bin auf jeden Fall morgen abend in Stuttgart muss aber noch schauen, wie es morgen genau passt.
Denke ich schaue vorbei.

Wenn man die Artikel genau liest, dann hat er glaub ich nirgendwo gesagt, dass Bitcoin Core für den Angriff anfällig ist.
Einen klaren Fehler, den er gemacht hat, habe ich ja zitiert:
Das ist einfach falsch, weil wenn man beliebiege SegWit Software benutzt sind die Signatur Daten nicht separat, sondern beides ist fest zusammen.

Und zudem ist die Seperation nicht spezifisch für SegWit:
Damit das so möglich ist müsste man sowieso eigene Software entwickeln - aber warum sollte man dann das nicht auch für normale Transaktionen machen?
Wenn der Grund ist, dass man Übertragungskapazität sparen kann, warum nicht auch die Signaturdaten von traditionellen Transaktionen wegsparen?
Das geht genauso einfach, indem man zusätzlich einen Merkle-Tree-Root für eine Normalized TXID überträgt und dann alle Signaturdaten von normalen Transaktionen separat übertragen würde.


Und bei dem Rest - Was kann er dafür, wenn alle anderen so ungenau lesen und das falsch interpretieren, was er geschrieben hat.

Er impliziert ja in dem Artikel, dass User (inkl. Exchanges) nicht dafür sorgen wollen, dass die Segwit Regeln aufrecht erhalten werden, wenn die Miner dies nicht mehr wollen.
Unter der Annahme ist das alles grundsätzlich korrekt.
Die Annahme ist allerdings sehr extrem, weil das bedeuten würde, dass Benutzer und Entwickler kein Anteil daran haben, wer die Regeln für Bitcoin festlegt.

Das ist aus meiner Sicht natürlich total unrealistisch und unfair gegenüber der absoluten Mehrheit aller Bitcoin Usern, weil die nicht so tief drin stecken und den Artikel so nicht richtig lesen können.
Man muss sich nur mal /r/btc aktuell durchlesen, da sind einige nicht in der Lage die Annahmen zu verstehen, welche Wright und Peter R. machen bei Ihrer Argumentation.

Gelogen hat er sonst nicht direkt.
Er hat seine Annahmen nicht klar ausgedrückt.

Man muss das eben im Kontext sehen, was er für politische Ziele hat.
Sein Vortrag in Arnheim passt für mich da ganz gut ins Bild.
Dann ist auch klar, dass er die Teile ausspart, die seine Argumentation schwächen.

Auch wenn das Wissen über Segwit in den Kreisen in den er sich bewegt meist fehlerhaft oder zumindest sehr lückenhaft ist, und dann das fehlerhaft oft untereinander zitiert wird und darauf neue fehlerhafte Argumente aufgebaut werden, gehe ich schon davon aus, dass er das weiß. Aber das ist meine persönliche Meinung und spielt eine geringe Rolle.

Es ist zumindest traurig, das ich sowas weiß, weil das klar wird, wenn man sich einmal kurz die BIPs zu SegWit durchliest.
Ich hab das ja nur so zum Spaß gemacht habe, und habe aktuell noch keinen akademischen Titel - und er hat extrem viele akademische Titel - naja.

Was wäre Bitcoin heutzutage schon ohne ein bisschen Drama.  

Achtung: Für einen Segwit Knoten sind die Signaturen direkter Teil der Transaktion.
Für einen nicht Segwit Knoten existieren sie nicht.
Also wie gesagt ist das aber unabhängig von Segwit, sondern gilt auch für normale Transaktionen

Allerdings gibt es momentan keine Software die das kann

Ja der Angriff basiert auf Unwissen, bzw. absichtlicher Falschdarstellung - Zumindest Bitcoin Core ab 0.13.1 ist so nicht angreifbar.

Naja - Jein - Nein? Er wäre nur aus Sicht von Nicht-Segwit-Knoten ein Historical Node. Ein normaler Segwit Knoten könnte keine Blöcke mehr von dem Knoten runterladen und keine Transaktionen anfordern. Ein normaler Segwit Knoten kann auch nicht nur die Transaktionen ohne Signaturen runterladen und später die Signaturen - es geht nur beides gleichzeitig.

Wenn alle die SegWit Signaturen prunen, dann würde ohne die Einführung eines neuen P2P Protokolls eine weiterverbreitung von Blöcken überhaupt nicht mehr möglich sein. Das ist aktuell also gar nicht möglich.
Die Signaturdaten sind nicht gerade unwichtig, deswegen halte ich nicht so viel davon die unabhängig zu prunen.
Es ist wahrscheinlich sinnvoll die Signaturen von den eigenen Transaktionen aufzubewahren.

Sehe ich auch so - verstehe nicht, warum da gerade so eine koordinierte FUD Welle anläuft.
Segwit + 2 MB ist zumindest aus meiner Meinung aus Sicht einer Dezentralisierung unproblematisch.
Mal schauen was passiert.

Gute Frage - also soweit ich weiß, werden die heruntergeladenen Dateien als valide angesehen, ohne das die erneut geprüft werden beim Clientwechsel.
Wenn jetzt allerdings ein anderer Segwit Knoten eine Transaktion bei dir anfordern würde, dann könnte dein Knoten die Daten nicht liefern, obwohl er das nach außen als Service anbietet.
Ggf. stürzt dein Client ab, oder der andere Client wird dich bannen, weil du keine gültige Transaktion liefern kannst.
Gleiches, wenn ein anderer Segwit-Client den Block von dir runterladen will - du könntest nur einen ungültigen Block liefern.
Könnte man mal mit dem Testnet ausprobieren.
Ich würde es zumindest nicht empfehlen

Schätze mal, dass man nur die blk...dat Dateien behalten kann, die keine Segwit Blöcke enthalten und alles andere löschen muss und dann neu syncen.

Bitcoin Unlimited wird wahrscheinlich auch verrückt spielen, wenn man vorher mit Bitcoin Core bei aktiviertem Segwit synchronisiert hat und dann in den Dateien Daten serialisierst sind, die es nicht versteht.

Hab ich ja schon bezug darauf genommen:
FUD, weil es keine Software gibt, die so arbeitet, wie im Artikel beschrieben, bzw. das Problem unabhängig von Segwit ist

Das ist ein Missverständnis von Wright.
Es gibt aktuell kein Segwit Client der auf dem P2P Layer die Signaturen separat überträgt, es gibt nur Clients, wie Bitcoin Unlimited die Segwit Signaturen überhaupt nicht übertragen.
Die Witness Daten sind trotzdem dem Namen Segregated Witness nicht einfach abgetrennt, sondern werden immer mit der Transaktion übertragen, jedoch niemals separat.

Sobald Segwit aktiv ist, kann Bitcoin Core ab 0.13.1 auf dem P2P Layer bei einem Block der Segwit Transaktionen enthält entweder den ganzen Block und die Transaktionen inklusive Witness Daten, oder gar nicht empfangen.
Das Vorenthalten von Witness Daten ist zumindest mit Bitcoin Core nicht möglich.
Damit fällt die ganze Argumentation in sich zusammen.

Den Mining-Pools steht es bereits jetzt frei für normale Transaktionen die Signaturen nicht zu überprüfen oder ein anderen P2P Layer zu nutzen, der auch für normale Transaktionen die Signaturen nicht verarbeitet.
Mining-Pools benutzen bereits jetzt eigene P2P Netze und Technologien um die Blöcke mit sehr niedriger Latenz untereinander zu übertragen -> Spy-Mining, FIBRE, Xthin-Xpedited, Cornell Falcon Network, etc.
Durch ökonomische Anreize werden die Miner sich aber hüten invalide Blöcke zu produzieren, weil Sie die Bitcoins ja nirgendwo verkaufen können, weil Sie dann einen neuen Altcoin erschaffen hätten.

Die Blöcke erreichen die ökonomischen Nodes und ein normales Wallet jedoch niemals, wenn die Miner ungültige Blöcke produzieren.
Die Miner können sich also nur gegenseitig kurzfristig schaden.
Ein normaler Bitcoin-Nutzer wird davon nicht betroffen sein.

Das Risiko besteht insofern grundsätzlich, dass wenn Miner die ökonomische Mehrheit überzeugen können auch ungültige Blöcke anzunehmen, also dass Sie irgendwelche Bitcoins auch ohne Signaturen senden (klauen) können.
Das ist aber unabhängig von Segwit.
Und es ist sehr unwahrscheinlich, weil dann kein Bitcoin mehr sicher wäre und somit alle Bitcoins wertlos, was sicher nicht im Interesse von den Minern ist.
Zudem geht das immer nur mit einem Hard-Fork und jedem steht es frei sich zu entscheiden, ob er einem Hard-Fork folgen will.

Der einzig mir bekannte theoretische Angriff ist es die Blockchain mehrere Wochen neu zu schreiben.
Also alle Blöcke neu zu errechnen, die in den zwei Wochen erstellt wurden, welche zur Aktivierung von Segwit geführt haben.
So würde man praktisch Segwit nachträglich deaktivieren und könnte dann einen Replay-Angriff starten.
Weil Segwit dann nie aktiv war aus der Sicht der Blockchain, wären Segwit Transaktionen bei einem Replay-Angriff Anyonecanspend.
Das heißt aber, dass alle Transaktionen mit mehreren Tausend Bestätigungen auf einmal wieder ungültig würden, was ebenfalls zu einem Zusammenbruch von Bitcoin führen würde, also auch nicht im Interesse der Miner liegen kann.
Zudem könnte man sich gegen den Angriff mit einem UASF schützen, denn Segwit Transaktionen haben kein einfaches Anyonecanspend, sondern ein Witness-Program, welches Segwit Transaktionen von absichtlichen Anyonecanspend unterscheidet.
Somit hat man eine leichte Unterscheidungsmöglichkeit um den Angriff auszuhebeln.

Meine Meinung ist genau das Gegenteil:
Je mehr Bitcoins wir in Segwit Outputs haben, desto sicherer wird Segwit, denn mehr Leute haben ein Interesse daran, dass diese Segwit Coins nicht gestohlen werden.
Ihr solltet berücksichtigen, dass Wright der Meinung ist, dass ausschließlich die Miner festlegen, welche Regeln für Bitcoin gelten. Das stimmt allerdings nur, wenn man das so zulässt.