Bitcoin Forum

(Thread umbenannt: Neben LN dürfen auch anderen "Second Layer"-Technologien wie Sidechains und Extension Blocks hier diskutiert werden)

Ich würde hier gerne mal einen Thread zum Lightning Network aufmachen (hab im deutschen Unterforum keinen gefunden, außer einer Pressemeldung).

Das ist sicherlich eine der kontroversesten Entwicklungen, die in der Zukunft bei Bitcoin anstehen. Einige sehen es als Allheilmittel an, andere als Gefahr, die zu einer verstärkten Zentralisierung führen könnte. Ich befasse mich z. Zt. etwas damit. Deshalb würden mich ein paar Meinungen der hiesigen Community interessieren.

Was ist das Lightning Network?

Ich beschränke mich mal auf eine ganz einfache Erklärung. Wer Details wissen will, kann z.B. hier (dreiteilige Erklärung auf Englisch) (https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791) oder hier (deutsche Erklärung) (http://blockchain-nachrichten.com/blockchaintechnologien/lightning-network) nachlesen.

Grundsätzlich geht es darum, Zahlungskanäle zwischen zwei Personen aufzubauen. Ein Zahlungskanal kann z.B. zwischen einem Kunden und seinem Supermarkt aufgebaut werden. Über diesen Kanal kann er alle Produkte zahlen, die er kauft.

Der Knackpunkt: Anders als bei regulären Bitcoin-Transaktionen wird nicht jede Transaktion in der Blockchain festgehalten, sondern im Idealfall nur die erste Transaktion, mit welcher der Kanal eröffnet wird (und eventuell eine zweite, wenn der Kanal wieder "geschlossen" werden soll). Die anderen Transaktionen werden nur zwischen den beiden Parteien, die den Kanal betreiben, ausgetauscht.

Dass dabei nicht getrickst werden kann, wird über eine Art Smart Contract sichergestellt (Details siehe die obigen Links).

Man kann sich dies mit einer Analogie vorstellen: Man bucht eine größere Geldmenge auf eine Prepaid-Karte und zahlt dann mit dieser im Supermarkt. Man braucht dann nicht ständig auf das Hauptkonto zurückgreifen.

Das Lightning Network soll aber noch mehr können: Man soll damit auch Zahlungen zu Bitcoin-Adressen durchführen können, zu denen man selbst keinen direkten Zahlungskanal aufgebaut hat. Entweder soll dies über zentralisierte Anbieter mit Tausenden Kanälen zu allen möglichen Konteninhabern oder aber über ein dezentrales "Routing" über mehrere Adressen hinweg geschehen.

Das LN-Projekt ist übrigens grundsätzlich eine Open-Source-Anwendung. Es gibt mehrere Implementierungen, die alle noch experimentell sind und erst nach der Aktivierung von SegWit funktionieren werden (z.B. von Blockstream und http://lightning.network).

Was sind die Vorteile?

Befürworter des Lightning Networks erhoffen sich, dass dadurch weniger Blockchain-Transaktionen notwendig werden. Pro Kanal können beliebig viele Zahlungen geleistet werden, es entstehen in der Regel jedoch nur zwei Blockchain-Transaktionen. Damit würde die Blockchain weniger belastet und könnte noch lange mit kleinen Blöcken auskommen.

Zudem sollen die Zahlungen sofort eine Sicherheit besitzen, die mit einer Confirmation im Bitcoin-Netzwerk vergleichbar ist (deshalb auch der Name "Lightning" = "Blitz").

Welche Nachteile werden befürchtet?

Einige Gegner befürchten, dass das Lightning Network nur dann möglich sein würde, wenn es große zentralisierte Anbieter ("Supernodes" oder "Hubs") gibt, über die die allermeisten Zahlungen laufen würden (und die z.B. auch Gebühren nehmen könnten). Diese könnten zwar nicht "mit dem Geld abhauen" (wie etwa bei einem IOU oder einer herkömmlichen Börse), aber doch Einfluss darauf nehmen, z.B. welche Zahlungen akzeptiert werden und welche nicht.

Auch müssten Empfänger und Sender bei einer LN-Zahlung beide gleichzeitig online sein, genau so wie alle Zwischenstationen. Das ist bei einer regulären Bitcoinzahlung nicht der Fall.

Ein dritter Nachteil könnte sein, dass es schwierig sein dürfte, viele Nutzer zu finden, die ihre BTC in einem "Zahlungskanal" quasi "kaltstellen" möchten, solange der Bitcoinpreis so volatil wie z.B. Anfang 2017 ;) ist. Viele User könnten bei einem Kursrutsch alle ihre Kanäle sofort schließen oder alle BTC (gegen Güter oder andere Währungen) verkaufen. Dann wäre der Vorteil der "geringeren Blockchain-Belastung" dahin - es ist bei sehr starken Schwankungen eher eine höhere Transaktionszahl als heute zu erwarten.

Eine unaufgeregte, aluhut-unverdächtige Zusammenfassung einiger befürchteter Nachteile findet sich hier (https://chrispacia.wordpress.com/2015/12/23/lightning-network-skepticism/).

Was meint der Threadstarter? Ich finde, ausprobiert werden sollte es auf jeden Fall. Ich habe aber den leisen Verdacht, dass es wegen seiner Nachteile eine Nischenanwendung bleiben wird, die nur bei sehr kleinen Micropayments interessant sein wird - zumindest, solange Bitcoin nicht einen "stabilen" Kurs erreicht hat und nicht (nahezu) jeder Bitcoin-Nutzer eine echte Wallet hat und diese ständig online lässt.

Nun, es liegt an euch (auch an den Gegnern) hier aktiv zu werden und die grossen Hubs mit entsprechenden KYC/AML/Filter Regeln zu meiden. Ich kann mir sehr gut vorstellen einen solchen Hub zu kostenlos betreiben, denn ich würde selbst auch von einer breiten Vernetzung profitieren.


Viele sind doch sowieso Online (und schenken ihre Stimme einem Miner). Da sollte so ein Hub kein grosses Problem darstellen. OK, man darf die Dummheit mancher Menschen niemals unterschätzen, aber tatsächlich sollte das kein grosses Problem darstellen.


Da ich die BTC sowieso nicht verkaufe hätte ich damit überhaupt kein Problem. Im Gegenteil: Von erweiterten Nutzungsmöglichkeiten des Systems kann ich (und jeder andere Nutzer) nur profitieren. Ich wäre dämlich, wenn ich diese Möglichkeit nicht nutzen würde.


Das könnte durchaus sein. Viele Menschen schimpfen über die Sklaverei, um sich im nächsten Moment direkt für die Stelle des Haussklaven zu positionieren.

Ja, "altruistische" Hubs könnten schon eine interessante Lösung darstellen. Man muss eben sehen, wie sich das entwickelt.


Die Poweruser und Techniknerds ja - bin ich ganz bei dir. Bei den "Massen" sieht es wahrscheinlich anders aus, obwohl die ja gleichzeitig zu Onlinewallets tendieren. Natürlich würden größere Händler (wie der beispielhafte Supermarkt) sicherlich ebenfalls immer online bleiben, schon bei kleineren Geschäften könnte es aber schon anders aussehen. Wobei kleinere ja aber vielleicht auch eher Bitpay und Co. nutzen würden. Also könntest du recht haben, dass dieses Argument eher weniger schwer wiegt. Muss man halt sehen.


Auch hier gilt m.E. wieder "der Hardcore-Bitcoiner ja, aber die Massen eher nicht" und ich glaube, das wiegt hier schwerer als beim "stets online-sein-Argument". Das Problem ist ja auch, dass der Zahlungskanal ständig erneuert werden muss, wenn z.B. das Gehalt eintrifft. Dass das Gehalt ebenfalls per Lightning eintrifft wird eher selten passieren, d.h. man muss dann mindestens monatlich neue BTC nachschießen, was wiederum Transaktionen kostet.

Attraktiv ist das ganze natürlich bei sehr kleinen Zahlungen, also z.B. wen mann regelmäßig MP3s im Internet kauft oder ähnliches und dafür z.B. 0.1 BTC pro Monat reserviert. Solche Dinge würden vom Lightning enorm profitieren. Aber schon beim Supermarkt-Wocheneinkauf gehe ich davon aus, dass es die meisten Leute Überwindung kosten würde, dafür im Vorfeld schon genügend BTC zu reservieren - bei instabilem Kurs, versteht sich. Dann würde es wieder auf normale BTC-Transaktionen - oder noch schlimmer, weiterhin Fiat-Zahlungsdienste - herauslaufen.

Spielst du hier auf die Möglichkeit an, dass Lightning gegenüber Fiatdiensten den Kürzeren ziehen könnte? Ansonsten verstehe ich den Post nicht.

Es ist eben nicht altruistisch, einen Hub zu betreiben, da man faktisch selbst davon profitiert!


Das Argument passt auch zum Verhalten, sich über die begrenzten TX pro Zeiteinheit der Bitcoin Blockchain zu beklagen und gleichzeitig Offline-TX und Sub-Chains abzulehnen. Am besten wird es, wenn dann politische Argumente (die böse Firma Coinbase oder wie auch immer die heisst) an den Haaren herbeigezogen wird, anstatt in Betracht zuziehen selbst aktiv zu werden um eine Zentralisierung zu verhindern.

Im Prinzip ist es das alte Spiel: Andere haben gefälligst meine Probleme zu lösen - hauptsache ich muss selber nichts machen ausser lautstark zu jammern und mich in die Opferrolle fügen.

Deshalb auch in Anführungszeichen ;) Ist wie bei NGOs oder Open Source Software: Ganz altruistisch ist das alles nie ...


Ja, verstehe ich. Aber wenn Sub-Chains und Offline-TX erlaubt sein sollen, warum dann nicht auch mehrere weitgehend unabhängige Blockchains? Die Alternative (die ich persönlich bevorzuge) zu einem LN, das praktisch alle Transaktionen "normaler" User durchführt, wären mehrere große Kryptowährungen, die parallel existieren (und gerne verschiedene Konzepte ausprobieren dürfen).

Der Vorteil: Man bräuchte von der traditionellen Blockchain-Transaktion nicht auch für mittlere Beträge abzukehren. Per Atomic Swaps wären alle Blockchains potenziell miteinander vertrauenslos verbunden.

Bei Bitcoin+LN als (Quasi-)Monopolist wärem bei einer weiter steigenden Nutzung auch die Bitcoin-Blockchain-Transaktionen nur noch als Vehikel für sehr große Zahlungen nützlich, da ansonsten die Fees zu hoch wären (und es eh keinen Platz dafür in der Blockchain gäbe). LN hat aber gegenüber Blockchain-Transaktionen meines Erachtens deutliche Nachteile und ist nur für Micropayments tatsächlich das Mittel der Wahl.


Da bin ich wieder ganz bei dir.

Das ist halt das Problem, wie lösen diesen Engpass? Ich muss sagen die Idee ist nicht schlecht, aber man gibt natürlich Dezentralität wieder auf, das ist aber nicht anders möglich. Möchte man eine Beschleunigung muss man entweder das System komplett neu aufbauen oder eben eine Art Delegation einführen.

Wenn Bitcoin das nicht hinbekommt, also eine Beschleunigung und die Nutzung der kompletten Ressource der Satoshis (denn momentan macht es eben keinen sinn 100Satoshi zu versenden) war es das. Dann wird der BTC über kurz oder lang technologisch überholt.

Mir fehlt einfach eine breite Erklärung was derzeit so geplant ist. Wenn das Einigermaße aufgearbeitet immer irgendwo vorliegen würde, würden sich viel mehr Leute dafür interessieren. Ich weiß zum Beispiel jetzt aus dem Stehgreif nicht wie ich über irgendwas abstimmen kann. Durch meinen Background (Informatik) würde ich jetzt tippen, ok, das werden sie wohl darüber lösen wer welchen Client nutzt. Aber den ganzen Part mit den großen Minerpools ist für mich eine abgeschlossene Blackbox da in China. Ich wüsste jetzt nicht welcher Pool für was steht und welche technologischen Ziele verfolgt. Kann ich zwar alles mir mühsam in Foren zusammensuchen, aber 99% der Leute machen das nicht.

Das beide bei dem LN-Transfer online sein müssen, müsste man mal näher beleuchten. Die Masse der Transaktion wird doch B2C ablaufen. Also der Anbieter wird online sein, der Verbraucher wird die Dienstleistung in dem Moment wo er kauft auch bezahlen und dementsprechend auch online sein. Jemand der was anbietet wir also immer online sein. Das zwischen Privatpersonen da es etwas schwieriger wird ist logisch. Muss man sich halt organisieren. Aber so oft wird das nicht vorkommen.

Waere das eine Umfrage (oder waere ich ein Miner) so wuerde ich dafuer stimmen:

1.) Die Anzahl der Transaktionen werden in Zukunft nicht weniger.

2.) Ca. 60 Minuten bis eine Transaktion wirklich durch ist koennte in Zukunft schlicht zu langsam sein.

3.) LN ist eigentlich nichts anderes als eine Transaktion offline durchzuführen und irgendwann, wenn man lustig ist, zu broadcasten (nur allgemeiner).

4.) Kann man mit LN seine Coins mixen, richtig? Alles was im Kanal passiert ist unsichtbar (ausser es wird vom Dienstleister aufgezeichnet).

5.) Zentralisierung? So what? Es wird nicht nur den einen zentralen Hub geben, welcher alles kontrolliert, sondern immer auch Alternativen. Wer einmal den Falschen nutzt wird dies hoffentlich nicht ein zweites mal tun.

6.) Wer die ganze Zeit auf die Volatilitaet guckt, der wuerde mit Bitcoins eh nicht bezahlen, sondern nur spekulieren, diese also nur lagern und warten.

Da aber aktuell SegWit fuer LN scheinbar eine notwendige Bedingung ist, so stellt sich mir die Frage zu LN noch gar nicht, stecken wir doch immer noch bei 25% Miner Zustimmung fest.

Genau und hier liegt für mich als winziger User/Bezahler/Bitcoinhalter die Krux, wo und wie bitte kann ich hier auf die Miner Einfluss nehmen? Wo kann ich meine Stimme einfach abgeben? Ich mein jetzt nicht aktive in Foren / Blogs etc. agieren, das machen/können die wenigsten sondern seine Stimme simpel "abgeben". Ist alles undurchsichtig und wird schon lang wohl von Investoren, Geldgebern und Interessensgruppen vertreten die ich nicht mal kenne. Die Masse schwimmt hier einfach mit und wenn es zu "langweilig" wird war es das, der Hype um das nächste ATH hält die meisten im Bitcoin.

Für mich stellt Micropayment den Durchbruch dar, was durch volle Blöcke verhindert wird, das muss aber möglich sein auch in 10Jahren, schnell und einfach für den Nutzer. Dafür würde ich auch Dezentralität 'opfern'.

Nun, dann must du einen Hardfork anstreben. Ich finde es z.B. unfair, dass nur Miner was vom Blockreward haben obwohl alle die, welche einen Fullnode betreiben, auch Kosten zu decken haben.

Im Prinzip koennte man eine Abstimmung von den gehaltenen Coins abhaengig machen. Ich nenne das einfach mal "vote by stake" oder in kurz "VBS". Wale haetten dann natuerlich den groessten Einfluss. Aber zmdst haette dann auch die stille Masse eine Stimme. Also die Personen, welche das Netzwerk auch benutzen (wollen). Wie gesagt, das setzt aber einen Hardfork vorraus. Und ob es ueberhaupt eine gute Idee ist sei mal dahingestellt: man muesste ja alle seine Public-Keys veroeffentlichen, wenn man mit allem stimmen wollte was man hat. Das moechte ich nicht, der Quantencomputer kommt bestimmt ...

Mehrere komplett unabhängige Chains sind nicht verboten, es gibt sie jetzt schon in unüberschaubarer Anzahl: Altcoins.

Der Nachteil ist, dass ich keinen sicheren Geld-Übergang von einer Chain in die andere bekomme. Ich benötige immer einen Mittelsmann, dem ich zu 100% vertrauen muss (eine Altcoin Börse), oder mindestens einer der Geschäftspartner muss in Vorleistung gehen.


Änderungen im Netzwerk können nur durch einen Konsens aller zukünftigen Nutzer (und damit auch der Miner) durchgeführt werden. Sollten allerdings einige Miner den Übergang ablehnen, aber alle Nutzer wollen die neuen Funktionen, dann gäbe es noch die Möglichkeit, dass alle neuen Blöcke der ablehnenden Miner von den Knoten abgelehnt werden. Das wäre OK, da diese Miner sich sowieso nicht mehr an der Weiterentwicklung des Systems beteiligen wollen. Damit würde das Mining für diese Miner sehr teuer, sodass sie es vermutlich aufgeben. Ob wir nun 8 oder 10 Miner haben macht für die Nutzer keinen grossen unterschied. Ich denke auf die 1-2 Miner, die ihre eigene Agenda durchsetzen wollen kann man verzichten.

Noch sehe ich einen solchen Konsens bei den Nutzern allerdings nicht. Ich persönlich hätte gerne die neuen Funktionen (unabhängig ob für LN oder ob es am Ende für TN oder eine Sub-Chain genutzt wird).

Eben das würde ja mit Atomic Swaps anders werden, da Atomic Swaps vertrauenslose Handelsvorgänge zwischen verschiedenen Blockchains ermöglichen. Auch mit PeerAssets (einer Coloured-Coin-ähnlichen Initiative aus dem Peercoin-Umfeld) sind fast vertrauenslose Cross-Blockchain-Trades vielleicht möglich (ist aber noch Alpha).


Das ist interessant, wusste ich noch nicht bzw. habe ich noch nicht darüber nachgedacht. Danke für die Info! Also dann würde es ja tatsächlich für jeden, der die Möglichkeit hat und die neuen Funktionen haben will, Sinn machen, einen Full Node zu betreiben und damit für SegWit und Co. zu "voten".

Ich hätte die Funktionen auch gerne. Lightning gerne auch - für kleine Micropayments ist es sicher eine klasse Lösung. Nur wäre ich skeptisch, wenn die gesamte Entwicklung von BTC auf Lightning ausgerichtet werden sollte - d.h. dass wirklich nur noch richtig große Transaktionen auf der Blockchain durchgeführt werden sollen. Ich würde mir Blockchain-Transaktionen gerne auch für mittlere TX im ~20-200 USD/EUR-Bereich offen halten, zu vertretbaren Gebühren. Wenn nicht bei BTC, dann eben bei einer anderen Blockchain.

Was meint der Threadstarter? Ich finde, ausprobiert werden sollte es auf jeden Fal



Ich bin dafür es bei Litecoin auszuprobieren. Ich finde es für den allgemeinen Nutzer zu Kompliziert

iwelche channel eröffnen zu müssen etc das ist alles viel zu kompliziert für die massen das wäre nur was für

die grossen BTC Companys die dann zeit sparen und Geld.

Ich bin gespannt aber lehne es ab weil Blockstream einfach nur eine Blackbox ist die mit millionen usd

leute und Journalisten Kauft und nur ihre Agenda pusht.   Alles andere wird zensiert .

Wozu zensur wenn Ihre Lösung doch die beste ist würde es Sich ohne Zensur und Bestechnung durchsetzen


Und 95 % aller early adopter die die meisten Coins besitzen wollen Blockstream Diktatur nicht .


Es muss die Blocksize erhöht werden um die Adoption die jetzt da ist nicht wegzutreiben in andere coins die 2 layer

Projekte kann man später wenn sie mal fertig sein sollten iwann immer noch implementieren und schauen wer es

nutzen will aber durch 1 MB Limit wird bald jeder gezwungen sein es zu nutzen da onchain viel zu teuer ist wer schnelle confirmaton braucht.

Sicher muss das passieren, und zwar nachdem die Verifikation der Signaturen in linearer Zeit abläuft. Eleganterweise bringt die SegWit Änderung beides.

Lightning Network (oder andere ähnliche Lösungen) sind nicht nur was für "große", wie hier im Thread schon erläutert wurde. Es lohnt sich eigentlich für jedes Paar Nutzer (Mensch, Firma, Bot, etc.) die regelmäßig Coins hin und her schieben wollen. Natürlich passiert das zwischen Firmen die einfach mehr Transaktionen zwischeneinander haben öfter, aber es böte sich ggf. auch für dich und das Cafe um die Ecke an. Die Frage ist lediglich wieviel Coins Du in Kaffee o.ä. anlegen willst und ob sich in Deutschland mal mehr als eine handvoll Firmen/Läden trauen Bitcoin zu akzeptieren.


Das hätt ich gern in Form signierter Nachrichten oder ich muss annehmen du ziehst dir Zahlen ausm Arsch.


Irgendwie scheint das der Preis nicht zu beeinflussen wie man gerade erst gesehen hat. Ich fände es ungemein hilfreich wenn die Seiten dieser Diskussion endlich aufhören würden die andere als Teufel (aus was für Gründen auch immer) darzustellen und wieder sachlich diskutierten. Das was aus meiner Sicht zur Zeit den Laden aufhällt, ist die Aufsplittung in diverse Lager die alle mit anderer Meinung für Teil eines Komplotts halten.

Vielleicht tut uns Litecoin ja den Gefallen. Dort scheint ja zumindest Segwit gute Chancen zu haben.

Die "Kompliziertheit" ist tatsächlich auch ein für mich valides Argument. Natürlich würde ein Lightning-Client die meisten Details vor dem Nutzer verstecken, aber dennoch ist die Nachvollziehbarkeit einer Lightning-Zahlung über mehrere Ecken weitaus niedriger als bei einer Blockchain-Transaktion. Wenn es ein Problem gibt (etwa ein Node eine Transaktion nicht weiterleitet), ist der Weg zur Lösung wohl schwieriger.

Am einfachsten finde ich bei Lightning eigentlich noch die direkten "Zahlungschannels" ohne Routing über mehrere Nodes, für einfache Micropayments. Dort sehe ich auch das Hauptpotenzial, z.B. in Verbindung mit einem Anbieter wie Bitpay. Das einzige Problem ist wie gesagt, dass die Coins im Voraus reserviert werden müssen, wie bei einer Prepaid-Karte.

Das mit der Zensur auf Reddit hat natürlich ein "Geschmäckle", ich möchte dazu aber nichts sagen, da ich nicht besonders aktiv auf Reddit bin und es nicht beurteilen kann. Aber jetzt Blockstream als "das Böse schlechthin" hinzustellen ist auch nicht zielführend, immerhin ist ihre Lösung Open Source.

Ich denke LN ist eine sehr sinnvolle Möglichkeit Bitcoin-Micropayments abzuwickeln ohne die Dezentralisierung des Bitcoin Netzwerks durch überhöhte Ressourcenanforderungen zu gefährden. Bei der ganzen Debatte sollte man nicht vergessen, dass niemand gezwungen wird, LN zu nutzen. Größere Transaktionen können ja nach wie vor ausschließlich on-chain abgewickelt werden. Für Micropayments bietet LN ausreichende Sicherheit.

Egal, ob LN nun kommt oder nicht, ich halte SegWit für einen ganz wichtigen Beitrag für die Zukunft von Bitcoin. Man kann nur hoffen, dass Psychopathen wie Roger Ver mit ihrer unverantwortlichen Bigblock-Agenda keinen Erfolg haben. (Die angebliche Zensur-Debatte wurde im übrigen auch von Ver inszeniert, nachdem r/bitcoin und bitcointalk von seinen Altcoin-Trollen geflutet wurde. Später hat Ver in seinem Konkurrenz-Subreddit dann selber unliebsame Posts unterdrückt.)

Ich hab nix gegen LN, eben weils nur ne Option ist,
man kann sie nutzen, oder eben nicht.

Die Dezentralisierung des Bitcoin Netzwerks durch überhöhte Ressourcenanforderungen zu gefährden, ein oft verwendetes Argument gegen größere Blöcke jedweder Art halte ich hingegen für nen schlechten Scherz.
Speicherplatz is billig, Traffic is billig, Bandbreite mehr als genug vorhanden, Rechenleistung braucht man eh nich viel,
was für "überhöhte Ressourcenanforderungen" sollen das denn bitte sein, von denen da immer die Rede ist?
Die Risiken und damit verbundene Angst vor nem Hardfork kann ich ja noch nachvollziehen, aber Ressourcen?
Ich verstehs nich.

Speicherplatz ist bei der Betrachtung in der Tat irrelevant. Das Problem ist die Bandbreite, insbesondere Upstream. Die ist eben weltweit nicht überall gleichermaßen gut ausgebaut und so billig wie in DE. Dazu kommt das Problem der Latenz durch die dezentrale Natur des Netzwerkes.

Zwar sind etwas größere Blöcke durchaus noch realisierbar, unbegrenzt große Blöcke oder auch nur eine Blockgröße, die nach Moores law hochskaliert wird, aber nicht. Die Upstream-Kapazität der Inet-Infrastruktur wächst deutlich langsamer als die Kapazität des Speicherplatzes.

Das gilt nur für den Heimanschluss. Ich musste vor kurzem zwei meiner Mietserver durch grössere (und teurere) ersetzen, da mir der Plattenplatz ausgegangen ist. Der Upstream wäre kein Problem gewesen.

Ja, aber Mietserver sind sowieso schon eine andere Hausnummer. Wenn man schon Mietserver für einen Fullnode benötigt, sind das Extrakosten, die viele jetzige Node-Betreiber scheuen würden. Außerdem gibt man ein Stück Kontrolle aus der Hand (wenn Server außer Haus).

Egal, in welchem Fall jetzt wo der Flaschenhals ist: Ein sparsamer Umgang mit Ressourcen ist für die Dezentralität des Netzwerkes förderlich. Deshalb sind Optimierungen wie SegWit eine gute Sache.

Man benötigt keinen Mietserver, aber bezüglich des Upstream ist ein Mietserver für 24/7 Einsatz einfach die bessere Wahl. Nebenbei sind für mich die weltweit verteilten Mietserver die bessere Wahl. Zuhause kommt vielleicht morgen schon ein angeblicher Amtsträger und nimmt den Rechner mit.

Der war gut.  :D

Und noch so'n gern genutztes Horror-Szenario.
Von einem Extrem (1MB) ins andere (unbegrenzt).

Ich hab wie gesagt nix gegen SegWit und LN, soll ruhig kommen,
aber das is imho nur ne Umgehung des Blockgrößen-Problems und nicht dessen Lösung.
Kurzfristig sicher sinnvoll, aber auf lange Sicht werden wir um größere Blöcke kaum herum kommen, wenn das System weiter wachsen (im "Mainstream" ankommen) soll.

Nein, es ist auch keine Umgehung. Es ist eine Vorbereitung.

Linearer Zeitaufwand zum Verifizieren der Transaktionen ist für mich eine Grundvoraussetzung für mehr Transaktionen pro Zeit.

wann wird denn jetzt SegWit in Litecoin adaptiert? dann kann LN mit LTC getestet werden.

Guter Punkt. Wäre also sinnvoll, das durchschnittliche weltweite Internet-Bandbreiten-Wachstum zu ermitteln. Habe dazu das hier ausgegraben:

http://venturebeat.com/2015/03/24/akamai-global-average-internet-speed-grew-20-year-over-year-to-4-5-mbps-mobile-traffic-jumped-by-54/

Das sieht schon ziemlich nach schnellem Wachstum aus (20% Wachstum im Jahr). Ist zwar nicht ganz wie Moore's Law, aber immerhin halb so schnell. Mobile sind es sogar 50% Wachstum im Jahr. Ist aber nur oberflächliche Googelei meinerseits, vielleicht sagen andere Statistiken was ganz anderes aus.

Dazu jetzt die entsprechende Bitcoin-Statistik. Die durchschnittliche Blockgröße wuchs in den letzten Jahren um etwa 30 Prozent im Jahr.

https://blockchain.info/charts/avg-block-size?daysAverageString=7&timespan=2years

Wenn wir jetzt davon ausgehen, dass Bitcoin weiter etwa wächst wie bisher, aber nicht der alleinige Monopolist bleibt, dann können wir in einem Anfall von Optimismus sagen, dass langfristig ein jährliches Blockgrößenwachstum von ca. 20-30 Prozent ausreichen wird, wenn andere Kryptowährungen als Alternative bereitstehen (wobei außer Bitcoin ja _alle_ anderen, auch LTC, noch ohne Segwit massig Platz in ihren Blockchains haben). Dazu kommt noch LN für die Micropayments.

@Gyrsur: Habs im Kursverlaufthread beantwortet (ab 28. Januar  können die Nodes ihre Unterstützung signalisieren)

Der Amtsträger kann überall kommen. Wenn jetzt viele Node-Server beim selben Anbieter laufen kann der Amtsträger sogar noch mehr Schaden anrichten. Ideal ist Node über Proxy/TOR (auf Kosten der Bandbreite). Geografische Verteilung macht natürlich auch Sinn.


Ja, stell Dir vor, Deutschland ist nicht Schlusslicht. :D


Das ist kein Horror-Szenario, sondern das, was die diversen Hardfork-Vorschläge von Andresen, Hearn und Ver bezüglich MAX_BLOCKSIZE vorgeschlagen haben.


Das Problem ist, dass die Statistik Up- und Downstream Volumen kombiniert. Upstream wächst langsamer. Darüber hinaus klafft eine große Lücke zwischen Industrienationen und Schwellenländern. Jetzt kann man natürlich sagen, auf Schwellenländer käme es nicht so an. Ich denke aber, es ist ein großer Verteil, wenn die Bitcoin-Nodes über möglichst viele Jurisdiktionen verteilt sind.

Vor mehr als einem Jahr hatte mal jemand eine wirklich gute Statistik gepostet (ich glaube auf reddit). Leider finde ich das nicht mehr.

Das ist völlig richtig und ein sehr wichtiger Punkt, der bisher noch zu wenig beachtet wurde.

Gerade durch die dezentrale Natur des Netzwerkes könnte eine dadurch entstehende Latenz nämlich zu massiven Problemen führen.

@IIOII: Zum Thema Upstream: Du scheinst recht zu haben, schon einer der ersten Googletreffer spricht hier nur von etwa 10 Prozent Wachstum pro Jahr.

http://www.ieee802.org/3/ad_hoc/bwa/public/sep11/cloonan_01a_0911.pdf

Das wäre eine Verdoppelung etwa alle 7 Jahre, was sicherlich deutlich weniger als das Wachstum der Nachfrage nach Kryptowährungen ist. Es wäre aber immer noch kein Drama, wenn wir bedenken, dass es theoretisch Hunderte stabile Blockchains geben kann. Es könnte dann einfach mehr große, weithin akzeptierte Coins geben, dann würde es auch hier reichen (wie gesagt setze ich große Hoffnungen in die Technik der "Atomic Swaps", um nicht mehr von Altcoinbörsen abhängig zu sein).

Ich glaube eher, dass Altcoins immer ein Nischenphänomen bleiben werden. Für eine wesentliche Existenzberechtigung bringen sie einfach keine fundamentalen Vorteile gegenüber Bitcoin - vor allem wenn man berücksichtigt, dass Bitcoin ja sinnvolle Features von Altcoins übernehmen kann.

Bitcoin hat den stärksten Netzwerk Effekt, die breiteste Akzeptanz und die größte Entwickler-Community. Dagegen können später eingeführte Altcoins nicht so einfach ankommen.

Ich bin zuversichtlich, dass letztendlich eine zufriedenstellende Skalierungslösung implementiert wird.

Für "mehrere starke Blockchains" sprechen meines Erachtens zwei Gründe:
- dass nicht alle Transaktionen auf allen Servern gespeichert werden müssen und damit ein Full-Node einfacher zu betreiben wird
- dass beim Ausfall einer Blockchain (braucht gar nicht mal ein 51%er zu sein, sondern auch z.B. ein zeitweiliger Stillstand wie bei Ixcoin aufgrund einer Designschwäche) weitere starke Blockchains als "Fallback" bereitstehen.

Dagegen spricht natürlich die fehlende Fungibilität, da jede Blockchain einen eigenen Preis (und möglicherweise auch ein anderes Inflationsmodell) hat. Aber wenn Atomic Trading kommt, sind andere Coins auf einmal vergleichbar mit Sidechains und damit quasi in das Bitcoin-Netzwerk integriert. Das Bitcoin trotzdem noch auf lange Sicht die bei weitem stärkste Chain sein wird, ist für mich keine Frage - es sei denn, die Community macht das Vertrauen in den BTC mit einer sehr schlechten Entscheidung wie etwa einem (nicht von der überwiegenden Mehrheit getragenen) Hardfork kaputt.

Und hat damit das 21M Limit beseitigt.

Eine Sub-Chain, welche einen Teil der Bitcoin Einheiten über eine bestimmte Zeit verwaltet wäre die naheliegende Lösung. Die heutigen Altcoins können und wollen das nicht leisten.

Ja, das stimmt. Ich habe mir über diesen Fakt schon mehrmals Gedanken gemacht. Theoretisch könnte es ja tatsächlich sein, dass der Wert aller Kryptowährungen bei einem unbegrenzten Altcoin-Markt ohne Limit der Geldmenge gegen Null geht und damit die Knappheit flöten geht. Aber inzwischen gehe ich davon aus, dass dies doch nicht so schlimm ist. Aus folgendem Grund:

Wenn wir einen Bitcoin besitzen, dann haben wir ja sozusagen einen Anteil in einer Art "Unternehmen" (Bitcoin wird ja auch als eine Art "DAO" gesehen). Das Bitcoin-Unternehmen besteht aus allen Nutzern, Minern, Bitcoin-Unternehmen und -Händlern und allen anderen, die dem System irgendwie einen Wert zugestehen. Der Preis richtet sich nach dem ungefähren Wert, den man "im Moment" und "potenziell in der Zukunft" für dieses Netzwerk schätzt.

Tritt nun ein neuer "Anbieter" (=Altcoin) dazu, dann muss er, um einen ähnlichen Status wie BTC zu bekommen, ein solches Netzwerk erst mal selbst aufbauen. Jede Kryptowährung hängt ja insbesondere von der Sicherheit und auch vom Nutzen (Händler, Verbreitung) von der Größe seines Unterstützer-Netzwerkes ab.

Daraus ergeben sich folgende Konsequenzen:

1) Bis ein Altcoin nachhaltig die BTC-Netzwerkgröße erreicht hat, vergeht einiges an Zeit und es werden eine Menge Ressourcen benötigt. Ich rechne also nicht damit, dass BTC in absehbarer Zukunft so stark von Altcoins "bedroht" sein wird, als dass nicht auch ein deutlich höherer Preis als jetzt erreicht werden kann. (Damit bleibt auch der "To-Da-Moon"-Mythos und auch die Knappheit der BTC bestehen.)

2) Die Zahl aller ernstzunehmenden Kryptowährungen wird begrenzt bleiben, da es nicht unendlich viele starke Netzwerke wie etwa BTC geben kann, weil der Aufbau eines solchen Netzwerks eine Menge externer Ressourcen kostet. Damit wird es auch (bei gegebenem Nutzen von Kryptowährungen) unmöglich, dass der Wert aller Währungen gegen Null tendiert und die Knappheit der Geldeinheiten passé wäre. Es wäre eher so wie heute, nur mit mehr starken Chains.

Das einzige, was dadurch wegfällt, ist die Möglichkeit, dass Bitcoin-Earliest-Adopter wie Satoshi sozusagen die Welt regieren. Das sehe ich aber auch nicht als erstrebenswert an.


Ist ja Blockstream wohl dabei, sowas zu entwickeln. Soll auch mit Segwit möglich werden. Ich bin auch darauf gespannt. Meiner Meinung nach werden alle drei Lösungen nebeneinander existieren (Lightning-ähnliche "Offchain-Transaktionen", Sidechains und Altchains).

Das wäre perfekt. Mehr Auswahl ist nie verkehrt. Vermutlich werde ich dann Bitcoin, die freien Bitcoin Off-Chain Lösungen und die freien Bitcoin Sub-Chains bevorzugen. Für Altcoins sehe ich persönlich dann keinen Platz und auch keinen Bedarf. Ich lasse mich aber gerne überzeugen, falls eine technisch deutlich überlegene Lösung angeboten wird.

danke!

ja, dann wäre LiteCoin mal zu etwas nütze ausser als backup für Bitcoin zu dienen falls bei Bitcoin der Super GAU eintreten sollte.

Ich kann mir ehrlich gesagt nicht vorstellen dass LN die große Lösung bringt. Es geht dabei doch um feste Zahlungskanäle. Wie viele davon hat denn der normale Bitcoinuser? Das dürfte doch eher selten der Fall sein. Zusätzlich, wer hat Zahlungskanäle und der Empfänger von Coins braucht die Bitcoins nicht nach einer Zahlung? Dazu müsste man den Zahlungskanal schließen damit die Bitcoins ankommen.

Ich selbst wüsste jetzt keinen Fall wo ich das nutzen würde. Es gibt vielleicht Sachen wo regelmäßig Coins fließen aber selbst da kann oder will ich mir nicht leisten die Coins nicht wirklich erhalten zu haben. Weil die Coins kann ich auch erst wo hin senden wenn ich sie habe.

Außerdem ist es auch nicht jederzeit oder wenn man es nur alleine will den Zahlungskanal zu schließen.

Vielleicht sehe ich da manches noch nicht was das verbessern würde aber momentan sehe ich für ich selbst keinerlei Nutzwert. Und ich kann mir ehrlich gesagt auch kaum vorstellen dass irgendein nennenswert großer Anteil von normalen Bitcointransaktionen irgendwann von LN übernommen werden kann. Z.B. Zahlungskanal zu kraken.com. Wozu? Wenn ich Coins kaufe dann will ich sie danach benutzen, also muss es ohnehin in eine Bitcointransaktion umgewandelt werden. Will ich Coins verkaufen, ok, vielleicht will kraken warten und hoffen dass ich in ein paar Wochen noch mal was sende, aber das klingt einfach nur wie ein Umweg.

Vielleicht gibt es Einzelfälle wo das nutzen würde aber ein großer Anteil der Bitcointransaktionen wird das sicher nicht sein.

Solange man die empfangenen Zahlungen weiterleiten kann, muss man keine Zahlungskanäle schliessen. Bei einer breiten Vernetzung, ähnlich den P2P Netzen, wäre das Etablieren und Schliessen von Zahlungskanälen nur noch selten nötig. Am Anfang wird das natürlich anders aussehen. Es extrem schwer ohne jede Entwicklung sofort ein fertiges Netz vorzuweisen.


Ich weiss einen Fall, bei dem wir das alle in grossem Stil regelmässig nutzen (und dabei nicht mal die geringste Kontrolle über die Nutzung der Zahlungskanäle haben) - Giralgeld. Wobei Giralgeld in diesem Fall eher einem Altcoin gleicht, der von einer Bank heraugegeben wird, als einer Sub-Chain.


Wenn man Bitcoin als reines Zockerinstrument mit ein paar Börsen sieht, benötigt man tatsächlich keineerlei weitere Entiwcklung. Das funktioniert heute schon sehr gut. Auf die Spitze getrieben bräuchte man gar keine Blockchain mehr, wenn die Börsen sauber ihre Bücher führen und eine Weitergabe der Buchungsstände ermöglichen.

Wenn man tatsächlich Bitcoin als Geld nutzen möchte sieht es anders aus. Dann hat man plötzlich mit begrenzten Ressourcen zu kämpfen.

Sind die Zahlungskanäle nicht zwischen zwei Parteien erstellt? Wie kommt dann eine dritte Partei hinzu? Ähnlich wie bei ripple wo Schulden gegengerechnet werden? Aber wie wird das dann mit den Verträgen geregelt ohne dass man auf einen zentralisierten Server vertrauen muss?

Beim Giralgeld wäre doch auch jedes mal ein neuer Zahlungskanal nötig wenn man wieder zu einem anderen Empfänger senden will oder wie meinst du das?

Vielleich kann man ja von Zahlungskanälen in andere Zahlungskanäle schicken aber das würde schon eine Komplexität an Transaktionen erfordern bzw eine Adoption von Bitcoin von der wir momentan noch weit entfernt sind. Vermutlich sogar weiter als wir bereits waren. Speziell was Reallife-Nutzung angeht.

Genau das ist die Weiterentwicklung von den gerade entwickelten Off-Chain Verfahren (LN ist nur eins von mehreren). Bisher sind sichere Verbindungen über mehrer Punkte relativ schwierig zu realisieren. Ohne das Transaction Melleability Problem geht es deutlich einfacher. Solange es sich bei den Off-Chain Transaktionen nur um eine Applikation im Bitcoin System handelt, kann die Nutzung langsam wachsen.

Bei der Nutzung von Zwischenstationen (Hubs) sind die Limits dieser Hubs mit den Geschäftspartnern ausschlaggebend. Im Rahmen der Limits der Gesammtstrecke kann sich die Transaktion dann bewegen. Auf den ersten Blick besitzt so ein Hub Ähnlichkeit mit einer Bank. Tatsächlich muss der Hub-betreiber das Geld allerdings tatsächlich haben und kann nicht einfach Geldschöpfung betreiben. Für die Abwicklung der Transaktionen nutzt man also (im Idealfall nur für einen Sekundenbruchteil) die Bonität der beteiligten Hubs.

Ich habe jetzt mal selbst eine Verständnisfrage, falls sich jemand auskennt: Kann man beim Lightning Network auch einen Zahlungskanal (in der Regel zu einem Hub) aufmachen, bei dem man selbst als Endnutzer gar keine Bitcoins "reserviert"? Das wäre ja für den Fall interessant, dass man auch sein Gehalt über LN erhält (oder eben BTC über eine Börse kauft, die auch per LN auszahlt).

Die in den oberen Links genannten Beispiele gehen ja immer davon aus, dass beide Parteien, die einen LN-Kanal öffnen, die gleiche Menge BTC reservieren. Das gibt ja den Anreiz, dass niemand den anderen betrügt, da jeder bei einem Fehlverhalten die gleiche Menge BTC zu verlieren hat (nämlich die selbst bei der Eröffnung des Kanals reservierten BTC).

Wenn man als Endnutzer nämlich gar keine BTC reservieren müsste, dann wäre die Hemmschwelle, einen Kanal aufzumachen, viel niedriger. Aber wie gesagt, ich zweifele ob sich ein "Zahlungs-Hub" darauf einlassen würde, da sonst allein der Endnutzer einen Anreiz zum Betrügen hätte.

Ich stehe da etwas auf dem Schlauch und bräuchte da so ein Kindergarten-Alice-und-Bob-Beispiel ;) Also wenn jemand einen Link kennt (oder meine Überlegung als totalen Bullshit widerlegt ;) )...

PS: Ich habe noch mal drüber nachgedacht und glaube inzwischen, dass dieses Szenario tatsächlich Bullshit ist und dass die Menge an BTC, die man für einen Kanal reserviert, die Maximalmenge ist, die man für eine Zahlung (bzw. einen Geldempfang) verwenden kann. Wäre schön wenn mir das jemand bestätigt.

Klar, das ist der einfache Fall. Man kann dann (erst mal) keine Zahlung senden, aber das war ja auch nicht gefragt. Für den Sender gibt es auch kein zusätzliches Risiko, da er das Geld sowieso verschickt hätte. Für den Sender ist es egal, ob er Dir erst mal eine Unterschriebene Transaktion (Off-Chain) schickt oder ob er diese Transaktion gleich ins Netz stellt. Du kannst ihn auch nicht betrügen, denn mehr als die einzelnen Zahlungen wird er sinnvollerweise niemals signieren.

Das er Off-Chain-BTC über diesen Weg "empfangen" kann, ist erstmal klar.

Aber kann der Empfänger diese "Off-Chain-BTC" dann auch weiterleiten, ohne echte BTC zu reservieren? Ich denke eher nicht, oder? Sonst könnte man ja selbst als Hub fungieren, ohne einen einzigen echten BTC zu riskieren.

(Ich glaube, ich muss mir das Prinzip noch mal genau anschauen, habe irgendwie einen Knoten im Kopf ;) )

Da der Empfänger mit der Signatur des Senders unwiderruflich die Zahlung erhalten hat, könnte das schon funktionieren. Ich müsste aber auch erst mal nachschauen, ob das Script das tatsächlich hergibt.

Danke für die Einschätzung.

Einen ähnlichen Effekt (also dass man keine BTC "kaltzustellen" und damit zu riskieren braucht, um einen Kanal aufzumachen - z.B. wenn man einen Crash fürchtet) kann man aber wohl so erzielen:

- Kanal zu Hub aufmachen und eine Anzahl "X" Bitcoins dafür reservieren
- Alle "X" BTC sofort auf einer Börse verkaufen, die Lightning als Zahlung akzeptiert

Dann könnte man Zahlungen (z.B. Gehalt) per Lightning erhalten und jeweils die Menge "X" weiterleiten, um z.B. Dinge dafür einzukaufen.  Mit dieser Möglichkeit könnten auch ängstlichere Bitcoinuser Lightning nutzen. (Habe ich hoffentlich richtig verstanden.)

Kannst du genauer sein wie das funktioniert? Hat man dann nicht direkte Zahlungskanäle sondern jeweils Zahlungskanäle zum Hub und die rechnen dann, ähnlich wie bei ripple, die Schulden verschiedener User gegen?

Mal angenommen, jemand bekommt einen Bitcoin für eine Signaturkampagne. Den will er jetzt auf einem Exchange verkaufen. Kann LN da eine Rolle spielen?

Bezüglich Hub, klingt nach Zentralisation da je größer der Hub desto effektiver? Oder teilen die sich irgendwie die Verknüpfungen mit allen andereren Hubs? (Ich stell lieber dumme Fragen anstatt es aus falschem Stolz zu unterlassen. :P)

Ich würde sagen, das System wird erst mit möglichst vielen Vernetzten Hubs richtig wertvoll. Mit einem einzigen grossen Hub ist der Nutzwert begrenzt, da nicht jeder mit diesem einen Anbieter zu dessen Konditionen arbeiten möchte. Ich würde es daher bevorzugen, wenn möglichst viele Nutzer Hubs anbieten und sich mit anderen Nutzern bzw. deren Hubs vernetzen. Wie auch bei Bitcoin selbst, steigt der Wert des Systems mit der Nutzung. Nebenbei kann so eine hohe Transaktionslast, verteilt auf viele Schultern, abgedeckt werden. Ausserdem vermeidet man damit einen Single-Point of Failure. Als Nebeneffekt werden die einzelnen Zahlungen einer zentralen Überwachung entzogen und Zensuransätze werden praktisch unmöglich gemacht.

Ich habe gerade folgendes aus dem englischen Forum gefischt:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html

Es geht um Angriffs-Szenarien, in denen der Angreifer mit Transaktionen über viele Nodes hinweg einen DOS auf das Netzwerk auslösen kann. Als Lösung wird die Zahlung einer recht hohen Gebühr durch den Sender einer Lightning-Transaktion vorgeschlagen. Das wäre natürlich wieder ein Nachteil bei Micropayments.

Den Link habe ich allerdings von einem bekannten Gegner von Segwit/Lightning, und hundertprozentig verstehe ich das technische Prinzip dahinter nicht. Wenn jemand sich auskennt: Ist das nur Propaganda bzw. das Problem schon gelöst oder tatsächlich ein möglicher Nachteil?

Franky ist - vermute ich - nicht unbedingt gegen SegWit (+LN) sondern gegen die Art und Weise wie es umgesetzt wird.

Zum Angriff. Die höheren Gebühren fall nur beim öffnen eines Channels an, micro payments sind davon also nur indirekt betroffen. Es erzeugt aber einen (weiteren) Anreiz einen Channel möglichst lange offen zu halten. Ob das überhaupt eine brauchbare Lösung ist scheint weiterhin noch gar nicht klar zu sein.[1] Die Verteilung der Extra-Fee Bedarf zusätzlicher Informationen die wohl so erstmal gar nicht anfallen würden.

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000650.html

Relevant ist einzig und allein die Gesamtmenge der für den Channel reservierten Bitcoins. Wer diese Bitcoins einbringt ist erstmal egal. Einen Anreiz zu betrügen gibt es in keinem Fall, da im Betrugsfall alle Bitcoins im Channel an die andere Partei ausgezahlt werden (egal wer ursprünglich mal wieviel eingezahlt hat).

Wer nichts einzahlt, kann erstmal nur empfangen und selbst keine Zahlungen senden. Damit ein Channel in beide Richtungen funktioniert müssen also beide Parteien etwas eingezahlt haben. Netto(!) kann man in einem Channel maximal soviel versenden, wie man ursprünglich mal eingezahlt hat. Wer über den Channel regelmäßig Zahlungen erhält kann immer wieder Etwas versenden. Wenn die Zahlungen aber immer nur in eine Richtung laufen, wird der Channel irgendwann "leerlaufen", weil alle Coins (gedanklich) auf der anderen Seite sind. Dann sind keine weiteren Zahlungen möglich.

Ne, das kann so nicht funktionieren! Die echten BTC sind fix für einen Channel reserviert und können demnach nicht gleichzeitig auch noch zur Deckung eines anderen Channels verwendet werden. Sowas geht nur beim Fractional-Reserve-Banking  ;)

Wenn man die Bitcoins aus einem Channel über einen anderen Channel weiterleiten will muss man das über die Blockchain machen. Also Channel schließen und neuen Channel aufmachen.

Klingt erstmal gut, wird in der Praxis aber kaum so kommen!

Für jeden eröffneten Channel müssen eine bestimmte Menge Bitcoins geblockt werden. Die Anzahl an Coins bestimmt die maximale Kapazität des Channels. Für den einfachen Endnutzer wäre es also am Besten genau einen Channel zu einem gut-vernetzten Hub zu haben. Weitere Channels bringen keine Vorteile, blockieren aber zusätzliche Bitcoins.

Gleichzeitig besteht für Normalnutzer wenig Anreiz einen Hub zu eröffnen. Für einen funktionierenden Hub muss man noch deutlich mehr Bitcoins blocken, als für einen Channel. Und das Betreiben eines Hubs ist gefährlich, man muss z.B. die Schlüssel 'online' vorhalten um Transaktionen automatisch signieren zu können. Das Lightning-Paper enthält eine lange Liste von Möglichkeiten, wie man die Coins in einem Channel verlieren kann. Und als Hub mach man sich direkt zur Zielscheibe. Das Betreiben eines Hubs wäre was für Profis, die ihre Systeme entsprechend absichern können.

Im Endeffekt dürfte es auf eine Struktur hinauslaufen, die unserem jetzigen Bankensystem nicht unähnlich ist: Wenige sehr große, untereinander vernetzte, Hubs und sehr viele einfache User mit oft nur einem Channel!

@shorena, danke für die Klarstellung. Es wäre natürlich zu prüfen ob dieser DOS-Angriff überhaupt eine reale Gefahr darstellt, da der Angreifer ja keinen direkten monetären Vorteil draus ziehen kann, ich könnte mir es aber schon vorstellen - z.B. um bestimmten Hubs oder Bitcoin allgemein zu schaden.

@Danton, danke, das deckt sich mit meinen Einschätzungen. Das Problem des mangelnden Anreizes einen Hub zu betreiben, wenn man kein "Profi" mit entsprechenden Ressourcen ist, sehe ich auch. Deshalb denke ich, dass eine relativ starke Zentralisierung leider wahrscheinlich ist.

Für echte Micropayments (alles unter 10-20 USD) wäre das für mich aber trotzdem eine akzeptable Lösung - eine Art Paypal, bei dem der Hub nicht betrügen kann. Ich denke weiterhin, man sollte nicht alles auf eine Karte setzen, sondern mehrere Lösungen nebeneinander für das Skalierungsproblem anbieten. Insgesamt bin ich optimistisch.

So nach 10 Minuten lesen merkt ihr hier was ???


Nichtmal Die BTC Experten die Jahrelange in der Materie sind  CHECKEN wie dieses LN Dingsbums Funktionieren soll ?`


was schreibt Ihr hier für Abhandlungen ????


Für Normale user ist Normal BTC Zahlung schon viel zu viel ??


Meint ihr Ehrlich Ein normaler Mensch macht was Ihr hier diskutiert ?????


Iwelche Channel Ersteller und iwas beachten das die nicht geblockt und geclost usw werden ???


Auf Welchen Planeten Lebt Hier


Das ist ist die Reinste Verarsche was die Blockstream Core Devs euch hier Als Massen Scaling verkaufen sollen und ihr

Wasted Eure Zeit mit so einen Schwachsinn ^^


Keiner wird sowas nutzen.

Wenn nichtmal ein Sebastiuon mit 1600 Posting das Checkt wer soll sowas  Nutzen ??


Da nutzt selbst ich lieber dann eine Vcc oder Paypal oder eher Dash etc



zeigt mal eure Diskussion hier eine " normale " Person !


Wer Soll sowas dann nutzen erstmal CryptoCurrency Fach studieren muss  ?


Blocksteam und Core Devs sind gefunded von Axa Ventures deren Ceo bei BIlderberger rumläuft haben die leute hier das immernoch nicht begriffen .

Das sind genau die gleichen leute die Merkel und Co befehlen Europa zu zerstören und USA Chaos mit den aufgebauten Trump schauspieler zu machen.  


Die Lösung ist BU oder Bitcoin ist bald Nr 2.

Naja, wenn jeder Neuling wissen müsste, was ein "Script" und ein "Output" ist, um eine Überweisung zu tätigen, hätten wir auch bei Bitcoin höchstens 0,1 % der aktuellen Nutzer.

Auch bei LN werden die Details natürlich vor dem User versteckt werden. Wobei du in einem recht hast: Bei LN müssen die Nutzer - soweit ich es bisher verstanden habe - schon einiges wissen, wenn sie das Risiko auf sich nehmen wollen, LN auch für große Zahlungen zu nutzen. Daher bleibe ich dabei: Das ganze ist als Alternative zur Prepaid/Giftcard interessant und wird da auch wohl seine Nische finden, aber nicht für die wichtigen Dinge wie Gehalt oder größere Einkäufe.

Da muss ich commander11 recht geben, das muss "idiotensicher" sein, sonst bleibts Spielzeug für Nerds. Was interessiert es mich, was z.B. meine Bank bei einer Überweisung alles anstellt?

No shit, aber wie d5000 schon schrieb das gilt schon Bitcoin selbst. Niemand muss wissen wie Bitcoin im Detail funktioniert um es zu nutzen. Gilt auch für Autos, scheinen trotzdem irgendwie benutzt zu werden, obwohl viele schon mit Reifenwechseln überfordert sind.

---

Kommt wohl auf deine Definition von "normal" an.


Ja.


Venus, manchmal Mars, je nach Wetterlage auch mal Erde.


DAS ist mal ne Referenz, das muss man sich mal auf der Zunge zergehen lassen: 'Ich bin kriminell, ich hab Ahnung'


Du kannst also z.B. CoinJoin und die unterschiede die in DASH daran vorgenommen erklären? Wieso verstehst du dann LN nicht?


Wer soll bloß diese 'Automobile' fahren wenn man dafür ein Maschinenbaustudium absolvieren muss?


Aah, natürlich. "Die anderen sind alle böse, nur bei uns gibts Sonnenschein".

+ Elektrotechnik + Informatik + Physik + ...  ;)

Sehr kompliziert so ein aktuelles KFZ.

zumindest braucht jeder Fahrzeugführer eine Fahrerlaubnis, ...

Beim LN würde sich das Problem etwa so darstellen:

Es gibt ja die Möglichkeit, wenn zwei Parteien einen Payment-Channel offen haben, dass einer von beiden versucht, den Channel auf einen alten "Status" zurückzusetzen und dadurch einen Vorteil zu erlangen. Beispiel: Kunde hat dem Händler fünfmal etwas für je 1 BTC gekauft und versucht jetzt den Channel ganz zurückzusetzen - er hätte dann 5 BTC gespart und trotzdem die Leistungen erhalten.

Um das zu verhindern, muss die Gegenpartei (also hier: der Händler) in einer bestimmten Zeit (die nicht allzu lange ist, z.B. 72 Stunden) den in das System eingebauten "Straf-Mechanismus" nutzen: er kann im Fall eines Zurücksetzens der BTC durch die Gegenpartei alle BTC aus dem Channel für sich selbst reklamieren.

Was ist aber jetzt, wenn der Händler z.B. im Urlaub ist und den Payment-Channel vergisst? Klar, man kann eine Art Alarmsystem einrichten, aber trotzdem ist es für den Händler mühsamer, dieses tatsächlich ständig im Blick zu behalten (schließlich hat er im Normalfall ja eine Vielzahl offener Channels). Theoretisch kann die Wallet selbstständig den "Strafmechanismus" auslösen, aber das wäre wieder sicherheitstechnisch riskanter.

Das nur mal als Beispiel in die Runde geworfen, was die Nachteile gegenüber On-Chain-Transaktionen sind und weshalb ich persönlich LN nur für kleinere Micropayments benutzen würde - egal ob als "Händler" oder als "Kunde". Man muss also noch mehr als bei On-Chain-Transaktionen ständig wachsam sein und sein System unbedingt virenfrei halten.

Da eine Transaktion üblicherweise in Sekunden über die gesammte Kette geht und der Hub-Betreiber garantiert nicht in dieser Sekunde in den Urlaub geht, sehe ich dabei kein grosses Problem. Daneben habe ich die Protokolle so verstanden, dass die Strafmechanismen automatisch ablaufen müssen, da diese der ökonomischen Absicherung dienen. Es wäre wenig sinnvoll, wenn man darauf verzichten würde.

Sicherlich wird man aber bei keinem neuen System mit grossen Geldbeträge starten. Neben möglichen Lücken im Protokoll muss man auch mit Implementierungsfehlern rechnen. Es wäre dämlich einem komplett neuen System sofort sein Vermögen anzuvertrauen (OK, für die Altcoiner nicht - die machen sowas regelmässig. Hat jemand DAO gesagt?). Micropayments sind daher logischerweise die erste Wahl für ein solches System.

Beides würde meines Erachtens dann doch auf das eher zentralisierte Hub-Modell herauslaufen, nicht auf das dezentrale "Six degrees of separation" - Modell. Jeder Hub müsste sozusagen "hauptberuflich" oder zumindest "professionell" arbeiten, da er die Strafmechanismen automatisch durchführen müsste und damit ein extrem sicheres System bräuchte.

Wie gesagt, das wäre für mich für Micropayments kein Drama, aber doch, wenn es die Haupt-Transaktionsmethode bei Bitcoin werden soll.

Es ist genauso zentralisiert wie die heutigen Full-Nodes bei denen ebenfalls komplexe Abläufe automatisiert durchgeführt werden.

Im Prinzip ist das ganze, wie überall, ein soziales Problem. Nur hinsitzen, sich über Zentralisierung beklagen und dann den grossen zentralisierten Anbieter nutzen, weil man ja sonst seinen Arsch um den Bruchteil eines
Millimeters bewegen müsste, wird mit absoluter Sicherheit kein Problem lösen.

Man kann es nicht oft genug Schreiben: Eigenes Geld - eigene Verantwortung!

Bei der On-Chain-Nutzung hat man aber als Normalsterblicher zumindest die Chance, selbst ein halbwegs sicheres System aufzusetzen - man braucht also nicht zwangsläufig auf Blockchain.info und Co. zurückzugreifen. Große Geldmengen in Paperwallets, eine eigene Partition mit einer Wallet für kleine Zahlungen - und es bleibt alles dezentral, selbst wenn man keinen Full Node betreiben möchte sondern z.B. Electrum nutzt, hat man kaum Abhängigkeiten von einem zentralen Provider (da der Blockchain-Server ja dir allerhöchstens fehlerhafte Daten liefern kann aber nie Zugriff auf dein Geld hat).

Bei einem LN nach dem "Hub and Spoke"-Modell entstehen dagegen neue Abhängigkeiten, und die will ich nur für kleine Beträge dulden, wenn ich schon ein dezentrales System wie Bitcoin nutze.

Deshalb würde ich dezentrale Hubs bevorzugen, auch wenn dies nicht realistisch ist, da die WhatsApp Generation - wie jeder weiss - mit massiver Gewalt zur Nutzung der zentralen Services gezwungen wird.  :-\

Jammern muss aber keiner. Eigenes Geld - eigene Verantwortung. Anders ausgedrückt: Jeder ist in diesem Fall seines eigenen Unglückes Schmied!

An die Lightning-Experten: Was meint Gmaxwell hiermit:


Heißt das, LN kann (zum Zahlen oder Weiterleiten von BTC) genutzt werden, ohne einen Channel aufzumachen (also ohne BTC in einer Transaktion zu "reservieren")? Das verstehe ich (auf Basis des Designs, das ich am Anfang gepostet habe (https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/)) überhaupt nicht. Gibt es da ein völlig neues Design?

Oder geht es hier nur um die Nutzung von LN als Zahlungsempfänger, den wir vorher diskutiert haben, bei dem tatsächlich kein Locking notwendig ist, man aber das Geld erstmal nicht für Zahlungen verwenden kann (bis man tatsächlich einen Channel aufmacht)?

Stammt übrigens aus einer Diskussion über diesen Artikel (http://www.deadalnix.me/2017/02/27/segwit-and-technologies-built-on-it-are-grossly-oversold/).

Ohne Channel können über LN definitiv keine Zahlung erfolgen. Es ist auch zwingend erforderlich, dass zumindest die zahlende Partei im Channel ausreichend BTC reserviert/gelockt hat. Anders geht es auf keinen Fall!

Ich werde auch nicht 100% schlau aus der Aussage, aber ich denke Gmaxwell will darauf hinaus, dass das LN-Netzwerk nicht zwingend eine Hub-Topologie/Struktur benötigt. LN ermöglicht Zahlungen über mehrere Zwischenstationen (Hops), auch ohne, dass sich alle Hops auf dem Weg kennen müssen. Es sind daher beliebige Netzwerkstruren, insbesondere auch gleichmäßig vermaschte Netze ohne zentrale Knoten denkbar. LN sieht vor, im Moment der Zahlung, über Routingverfahren einen Pfad durch das LN-Netzwerk zum Zahlungsempfänger zu finden und die Zahlung darüber abzuwickeln. Der Pfad kann auch vorher unbekannte Zwischenstationen beinhalten. Zahlungen würden dann ggf. jedes mal einen anderen Weg gehen, je nachdem wo Kapazitäten verfügbar sind. Falls kein Pfad verfügbar ist, könnte ad hoc ein neuer Channel eröffnet werden (der dann später ggf. auch für andere Zahlungen zur Verfügung steht).

Idealerweise würde man LN so implementieren, dass der Nutzer davon überhaupt nichts mitbekommt. Also, dass der Client eigenständig Channels zu irgendwelchen anderen Nutzern aufbaut, nach Möglichkeit nutzt, neue Pfade findet und Channel auch wieder abbaut. Der Nutzer sollte sich darum nicht kümmern müssen.

Es wäre spannend zu sehen, ob ein LN-Netzwerk ganz ohne zentrale Hubs in der Realität funktionieren würde. Ich habe da gewisse Zweifel... Fraglich auch, ob die Nutzer es überhaupt akzeptieren würden, dass ihr Bitcoin-Client ihre Bitcoin eigenmächtig in irgendwelche Channels steckt und (auch) für die Abwicklung fremder Transaktionen benutzt. Cold Storage oder Paper Wallet wären dann jedenfalls nicht mehr möglich.

Danke für die Einschätzung. Ja, das habe ich so schon mehr oder weniger gewusst, bis auf das:


Aber nur vom Ausgangs-Client aus, oder? Das heißt, mein Client eröffnet für mich einen Channel, wenn ich selber etwas zahlen will, aber nicht, wenn ich eine Zwischenstation bin? Zweiteres würde ich nämlich strikt ablehnen ...

.

Diese Zweifel teile ich, zumal die Clients der Zwischenstationen ja dauerhaft online sein müssen. Es kann natürlich sein, dass LN davon profitiert, dass eh die meisten Blockchain.info oder ähnliche Web-Anbieter nutzen, die ja tatsächlich dauerhaft online sind.

Was passiert eigentlich, wenn ein Pfad gefunden wird, eine Zwischenstation jedoch während der Ausführung des LN-Transfers plötzlich offline geht?


Das glaube ich wiederum nicht ... dafür kann man ja dann eine Funktion im Client einbauen, der es untersagt, bestimmte BTC in Channels zu stecken.

Das ist nicht notwendig. Ich denke nicht, dass es aktzeptabel oder wünschenswert ist, dass ein LN Knoten das komplette Vermögen kontrolliert. Ich gehe davon aus, dass man bei allen Second-Layer Lösungen die dafür genutzte Summe explizit zur Verfügung stellen muss.

Alles Mögliche ist denkbar... Wie es genau sein wird hängt von der Umsetzung des Protokolls in Anwendersoftware ab!

Es könnte eine separate LN-Wallet-Software geben, die man explizit herunterladen muss, explizit Bitcoins in LN-Netzwerk verschieben muss und bei jeder Transaktion explizit entscheidet, ob sie über LN laufen soll. LN könnte als anderer Extremfall aber auch nahtlos/unsichtbar in Bitcoin Core integriert werden. So das es für den Nutzer keinen sichtbaren Unterschied zwischen "normalen BTC" und "LN-BTC" gibt. Er hat dann natürlich auch keinen Einfluss darauf, was im Hintergrund passiert.

So absurd ist letztere Variante auch nicht: Eine Bitcoin-Wallet ist auch jetzt schon eine ziemlich starke Abstraktion, die die ganzen technischen Details vom Nutzer verbirgt und sich "eigenmächtig" um Inputs, Outputs,  Change-Adressen, u.s.w. kümmert. Mit LN würde sich die Wallet dann halt zusätzlich auch noch darum kümmern über welches Protokoll die Transaktionen abgewickelt werden. Ebenfalls ein technisches Detail, was man von den Nutzern verstecken könnte (sollte?).

Wenn LN als Lösung des Scalability-Problems von Bitcoin gedacht ist, läuft das tendentiell eher auf letztere Variante hinaus. Andernfall wäre es mehr eine zusäzliche Anwendung. Aufgrund der höheren Anforderungen an einen LN-Client (24/7 online) und der höheren Risiken erwarte ich aber auch, dass die Nutzung von LN zumindest einmalig eine bewusste Entscheidung des Nutzer voraussetzten wird.

Ich glaube auch dass es vollkommen inakzeptiert sein wird wenn es eine extra Wallet gibt. Die Verbreitung wird vernachlässigbar sein.

Integriert in bitcoin core wird vermutlich die Lösung werden, natürlich gegen den Widerstand der halben Bitcoincommunity. Das Thema hat sicher nicht an Kontroversität verloren.

Was ich aber nicht sehe ist wie das Wallet selbst entscheiden soll welche Transaktionen über LN laufen sollen. Es müsste Bitcoins in Kanälen sperren und das würde besonders bei Usern die nicht ständig über ein Vermögen verfügen sicher ziemlich schlecht ankommen.

Ziemlich unangenehm das ganze Thema, besonders die permanent steigenden Gebühren.

Die Kanäle sind ja nur N/N (meist 2/2) Multisig Wallets.
Bitcoin-QT ist ja sowieso nicht gerade das meist genutzte Wallet, von daher wäre das wohl eher wichtig, wenn das zunächst mal direkt bei Coinbase, Kraken, Blockchain.info, Breadwallet & Co reinkommt.

Die Benutzererfahrung ist allerdings schon etwas seltsam, da man nie weiß, ob der andere gerade online ist oder nicht und man die BTC nutzen kann.
Wird etwas schwierig das einem Neuling zu erklären und den zu überzeugen einzusteigen.
Und wird sicher genauso schwer ein Wallet zu entwickeln, was das so abstrahiert, dass der Nutzer nicht zu viel einstellen muss, aber auch nicht enttäuscht/sauer ist, weil er nicht verstanden hat, was er da eingestellt hat oder das Wallet dem Nutzer die Entscheidung abgenommen hat und er dann 30 Tage oder mehr nicht an seine bitcoins rankommt.

Wenn man jetzt seine BTC in einem Kanal gebunden hat, über den man eine dritte Person leider nicht erreicht (z.B. weil irgendwo die Kanäle auf dem weg nicht genug freie Kapazität haben), könnte man natürlich einen weiteren Kanal aufmachen, aber nicht jeder hat so viel zusätzliche freie bitcoins/Geld, dass er einfach noch einen zusätzlichen Kanal aufmachen kann.
Was die Verfügbarkeit des Kanals angeht muss man "Vertrauen" in den Partner haben, was wohl auch nicht der Dezentralisierung hilft.

So einen Hub abzusichern ist sicher auch nicht ganz ohne, denn in der einfachen Ausprägung handelt es sich da ja um ein Hot-Wallet, was auf einem Online Gerät ist. Und selbst mit zusätzlichem Multisig kann man es leicht vermasseln, wie man bei Bitgo/Bitfinex gesehen hat.

Meine Meinung: Hilfe gegen volle Blöcke ja, aber es wird eine ganze Zeit dauern, bis das notwendige Software gereift ist. Und nutzbar wird das sicherlich nicht für alle Anwendungsfälle, Lösung also nein.

Hatte überlegt an Wallet Software bzw. Security Verbesserungen für Lightning mitzuentwickeln, aber bis die malleability gefixt wird durch segwit, oder was auch immer, wird wohl noch einige Zeit verstreichen und solange wird das sowieso nichts mit LN.
Extension Blocks wäre ja toll, aber die Antwort von Matt Corallo auf der Mailingliste ist nicht gerade ermutigend:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510.html

Und es gibt ja noch andere Entwicklungen. Werde mich selbst jetzt mal stärker mit Rootstock und Lumino befassen.
Das ist momentan mein Favorit zur Skalierung, auch wenn man sich mit der Federated Sidechain als Übergangslösung für den 2-way peg zwischen BTC und SBTC erstmal anfreunden muss.
Aber es hat den riesen Vorteil, dass es keine "Erlaubnis" / Konsens braucht um implementiert zu werden, woran segwit und BU momentan ja scheitern.
Immerhin sieht es so aus, als ob da schon viele dabei (und wohl auch mehr Miner, als bei segwit oder Unlimited) sind und man so der Federation "vertrauen" kann, weil die im eigenen Interesse handeln nicht zu schummeln.
Mal abwarten bis Ende Mai, bis das Live Netzwerk online seien soll.

Und es gefällt mir 1000 mal besser, als über Altcoins oder Coinbase-Style zentrale Datenbanken / SQL offchain zu skalieren, was momentan passiert.

@MoinCoin: Guter Post, stimme dem meisten zu (außer dem Teil, das ich Altcoins ebenfalls für eine valide Skaliermöglichkeit halte).

Rootstock hört sich als 2-way-pegged-Sidechain mit Merged Mining schon auf den ersten Blick sehr gut an. Werde mal weiter drüber nachforschen, insbesondere wie dezentral es ist.

Danke für die Blumen.

Natürlich sind Altcoins auch eine valide Skalierungsmöglichkeit, aber die müssen dann eben ihren eigenen Netzwerk-Effekt aufbauen.
Mit vielen Altcoins kann man aktuell nicht besonders viel machen.
Mich persönlich macht das auch etwas unglücklich, weil das meiner Meinung nach den Netzwerk-Effekt von Bitcoin untergräbt.
Ein paar Altcoins hab ich mittlerweile auch wieder, da mir die Transaktionsgebühren bei bitcoin für kleinere Beträge zu hoch sind. Halte etwa 99% bitcoin und 1% Altcoins, somit bleibt mein persönliches Risiko durch Altcoins für mich überschaubar.
Ist schon traurig, so können die sich z.B. bei ETH und Dash schon ganz schön viel Mist erlauben und sind trotzdem aktuell wieder im Aufwind.


Und um den Bogen zurück zu schlagen, was hat das mit dem Lightning-Network zu tun?
Das schöne an einem Lightning-Network wäre ja, dass es auf dem Netzwerk-Effekt aufbauen könnte, den bitcoin als Währung schon hat.

Hier ein Post eines Lightning-Devs auf Medium, der ganz interessant ist, weil er zeigt, dass die Implementation tatsächlich (zumindest vorläufig) auf Micropayments beschränkt werden soll:

https://medium.com/@rusty_lightning/miners-and-bitcoin-lightning-a133cd550310#.kv57bat2n

Einige interessante Dinge:

- Lightning-Payments werden erstmal auf 0.042 BTC begrenzt
- Der Dev glaubt nicht, dass LN für große Zahlungen nützlich ist, da bei größeren Transaktionen BTC-Onchain billiger bleibt (weil Routing schwieriger wird und man wohl dann den "Durchgangshubs" eine Fee zahlen muss)
- Wenn jeder Mensch auf der Welt einen LN-Channel betreiben würde, würde es 63 Jahre dauern - zumindest bei der derzeitigen Begrenzung auf 1 MB ;)

Sein Fazit ist, dass die Miner-Furcht vor LN unbegründet ist.

Damit scheint aber auch die Hoffnung, dass LN eine Lösung für das Scaling-Problem darstellt irgendwie unbegründet...  :(

Mikrotransaktionen spielen beim Bitcoin derzeit keine Rolle. Das Scaling-Problem besteht bei normalen Transaktionen. Und wenn LN dafür 1) nicht geeignet ist und 2) für den Auf- und Abbau von Channels selbst Blockchain-Kapazität verbraucht, wird die Scaling-Problematik durch LN eher noch verschärft als gelöst!

Die Grenze ist tatsächlich etwas niedrige, kann aber einfach angehoben werden. Es ist aber trotzdem sinnvoll klein anzufangen, da Probleme bei einem neuen System nicht auszuschliessen sind. Es ist nicht sinnvoll einem neuen Protokoll sofort grössere Beträge anzuvertrauen - ich würde es zumindest nicht machen. Erst mal muss sich sowas im realen Einsatz stabilisieren.

Daneben sollte LN nicht die einzige Applikation bleiben. Side-Chains/Sub-Chains stellen ebenfalls eine Skalierungsmöglichkeit bereit und sollten daher nicht ignoriert werden.

LN ist aktuell noch Alpha. Soweit ich weiß ist der Standard (BOLT) noch nicht mal fertig.
Da ist es schon okay den Betrag als Sicherheitsmaßnahme erstmal niedrig anzusetzen..

An sich sind die 0.042 BTC kein Problem, da man ja praktisch beliebig viele 0.042 BTC Transaktionen auf einmal senden kann.
Eine Wallet-Software kann das ja vor dem Benutzer verstecken.
Dauert dann eben 10 Sekunden, statt 1 Sekunde, weil mehr Daten auszutauschen sind.

Wenn LN erstmal Beta ist, wird das sicherlich angehoben.

Es gibt da noch ganz andere Baustellen.
Bei der letzten Demo von Eclair diese Woche, ist mir aufgefallen, dass die Node id und dann IP+Port als URI angeben. Das hat mich etwas verwirrt, weil es so unpraktisch erscheint (NAT, Firewall, DSLite), zeigt aber auch nur, dass alles noch in einem sehr frühen Stadium ist.

Aktuell läuft das Discovery wohl sogar noch per IRC
https://github.com/lightningnetwork/lightning-rfc/blob/c5ca57b853a77256cbdc96dd676c01fda5aec126/06-irc-announcements.md

Da müssen die sich auch noch einigen - mit DHT, TURN (Traversal Using Relays around NAT) etc. gibt es dafür aber immerhin potentielle Lösungen . :) Und ohne direkte Protokollunterstützung geht es ja auch mit einem Proxy, der den offenen Port vorhält.

Node ID sollte aber hoffentlich reichen als Ziel, alles andere da sollen sich bitte die Programme drum kümmern.

Achja... dauert alles noch eine ganze Weile

Naja, ~40 Dollar ist schon OK als Grenze. Die Autoren argumentieren ja auch, dass durch LN neue Use Cases möglich werden, wie eben der vielzitierte Kaffee. Langfristig könnten die 0.042 auch eher 100 Dollar entsprechen, wenn der jetzige Dip überwunden ist ;)

Es stimmt allerdings, dass die durchschnittliche Transaktion deutlich größer ist. Wenn ich diese beiden Charts kombiniere:

- https://blockchain.info/charts/n-transactions (~300.000 Transaktionen pro Tag)
- https://blockchain.info/charts/estimated-transaction-volume (~300-350.000 BTC pro Tag)

erhalte ich etwa 1-1,2 BTC pro Transaktion. Interessant wäre eine Aufteilung z.B. in Quartile oder auch der Median, da sehr große Transaktionen (z.B. von Exchanges) diesen Mittelwert verzerren könnten. Weiß nicht, ob es so einen Chart irgendwo gibt oder man den selber ausrechnen müsste.

Um nochmal darauf zurück zu kommen.

Ich freunde mich mehr und mehr mit der Idee an, dass 1 MB auf Layer 1 trotzdem langfristig reichen könnte.
Ich halte es zwar nicht für die technisch beste Lösung, aber wahrscheinlich die beste technische Lösung die erreichbar ist.

LN als Layer 2 direkt auf Layer 1 bleibt damit allerdings nur eine Übergangslösung.

Wie auch schon bei RSK Lumino erst Layer 4 ist, wäre es wohl sinnvoll für das LN noch mal ebenso eine Zwischenschicht einzuführen, wenn man keinen Konsens für größere Blöcke auf Layer 1 findet.

LN als Layer 3 und ein Layer 2 für LN Settlements könnte ich mir als Lösung vorstellen.
Layer 2 könnten zum Beispiel Extension Blocks (über Softfork möglich) oder Sidechains (mit Softfork oder ohne Fork als Federated Sidechain) sein.
Extension blocks könnte man so designen, das aus der Benutzererfahrung Layer 1 und 2 praktisch verschmelzen, wenn der Nutzer einen bestimmten Extension Block unterstützen möchte.

Unterschiedliche Extension Blocks könnten unterschiedliche Eigenschaften aufweisen.
Man könnte einen Extension Block mit Segwit haben, auf dem dann Layer3-LN aufsetzt und gleichzeitig einen anderen Extension Block mit
Big Blocks (EC / BIP 100 / BU), ohne das Risiko eines currency splits zu haben. Wäre das ein tragfähiger Kompromiss?
Geht natürlich auch direkt als Extension Block mit Segwit und BigBlocks.

Node-Dezentralisierung auf Layer 1 könnte somit erhalten bleiben.
Hardforks auf Layer 2 haben dann auch kein Risiko mehr die Basis-Währung BTC zu splitten.
Bei BU und bei UASF mit counter hardfork sehe ich das Momentan als ziemlich sicher, dass nicht nur das Netzwerk, sondern auch die Währung gesplittet wird.

LN auf Layer 2 als Übergangslösung könnte wie gesagt grundsätzlich aber erstmal funktionieren. Es muss also gar nicht unendlich skalieren.

Es könnte hart werden für Bitcoin, aber langfristig sollte das trotzdem noch lösbar sein.
Als nächstes kommt am 22.05. RSK Ginger :)

Edit:
LN geht natürlich auch gleichzeitig auf Layer 1 und Layer 2 Blocks ;)

Layer 2 kann weit mehr als nur ein einziges LN sein! Dort könnten durchaus verschiedene Off-Chain/Side-Chain/Sub-Chain Lösungen koexistieren und nach Bedarf (auch gleichzeitig) genutzt werden.

Was meinst du mit mehr als ein einziges LN?
Folgendes Beispiel würde ich eher als ein gemeinsames großes LN sehen:
Alice ---(Layer-1-BTC Channel)---> Bob ---(Layer-2-BTC Channel)---> Charlie ---(Layer-1-BTC Channel)---> Dave

Notiz am Rande:
Ich glaub ich habe zuletzt zu viel /r/bitcoin gelesen.
Wenn man das zu viel liest, sollte man meinen, dass es keine Alternativen zu segwit + LN als Layer 2 gibt und auch nichts anderes benötigt wird.
/r/bitcoin ist für mich die schlimmste Anti-Werbung für Bitcoin und der Grund, warum ich lange Zeit Bitcoin Unlimited für "die bessere Lösung" gehalten habe.

Insbesondere wenn ich sowas lese, was ein bestimmter Core-Dev schreibt, denke ich manchmal das ist praktisch wie Propaganda für Bitcoin Unlimited
https://www.reddit.com/r/Bitcoin/comments/61wdqc/the_most_compelling_reason_why_segwit_lightning/

Segwit ist nur der allererste Schritt.

RSK hat ja (noch) den Nachteil, dass noch ein Opcode für die "Rückumwandlung" der Sidechain-BTC in normale BTC fehlt und somit die vorläufige Lösung des Pegs erstmal recht zentralisiert ist. Ich glaube, damit holt man keinen echten Bitcoin-Fan auf den 2. Layer.

Danke übrigens für den Hinweis auf Extension Blocks. Gibt es da irgendwo eine Beschreibung für technische Laien? Ich finde da nur sehr technische Beiträge (Dev-Mailingliste ...) die für mich als Nichtinformatiker doch recht schwierig zu verdauen sind ;)

Es gibt jetzt schon mehr als eine LN Implementierung. Die meisten haben kompatible Schnittstellen, was aber nicht zwingend so sein muss.

Genau - der Vorteil ist aber, dass man es aber eben trotzdem funktioniert und man nicht warten muss, bis der Softfork in Core implementiert und dann im Netzwerk aktiviert wird. Bis segwit implementiert und getestet war hat es ja auch ewig gedauert und jetzt ist nicht mal klar ob/wann segwit aktiviert werden kann.
So geht es immerhin trotzdem vorwärts. Und niemand kann etwas dagegen machen ohne Bitcoin zu zerstören.
Es ist bei weitem nicht perfekt, aber ich werde es lieber nutzen als Altcoins.

Ehrlich gesagt bin ich wirklich erstaunt, wie wenig Entwicklung es im Bereich Extension Blocks gibt und das der so selten erwähnt wird, die Idee ist ja nicht gerade neu.
Leider gibt ja nicht mal ein BIP oder eine wirklich fertige Spezifikation.

Ich versuch mich mal an einem ELI5: Extension Blocks sind die Softfork Variante von größeren Blocks, die viele ja wollen und man sonst über Hardforks erreicht.
Extension Blocks sind eine Layer 2 Technologie und lassen so also Layer 1 in Ruhe, während Projekte wie BU versuchen das direkt alles in Layer 1 zu ändern, ohne jedoch Konsens zu erreichen, weil es eben sehr unterschiedliche Interessen auf Layer 1 gibt.

Die Cornell Universität hatte vor 2 Jahren eine Studie herausgegeben in der Stand, dass wir mit 4 MB Blöcken ca. 10% aller Full Nodes verlieren würden. Da die Basis Blöcke bei Nutzung von Extension Blocks unabhängig von der Größe der Extension BLocks weiterhin maximal nur 1 MB hätten wäre es wohl möglich mit Extension Blocks sogar deutlich weit über die 4 MB zu gehen ohne direkt Nodes zu verlieren, die nur auf Layer 1 arbeiten.

Ich wüsste nicht, warum es einen Counter Hardfork in diesem Szenario geben sollte der Erfolg haben könnte, deswegen besteht auch kein Risko, dass die Währung BTC gesplittet wird.

Um die erweiterte Kapazität nutzen zu können braucht man wie auch bei segwit oder einem Hardfork einen neuen Client, der die extension blocks unterstützt. Aber der neue Client kann den Benutzer fragen, ob er die zusätzlichen ressourcen aufwenden will um auch den extension block zu unterstützen. Man könnte gleichzeitig Layer 1 als Archival Full Node nutzen und Layer 2 Extension Blocks als Pruned Full Node oder sogar als SPV Node.

Die tatsächliche Spezifikation von Extension Blocks könnte sehr unterschiedlich ausfallen
Auf jeden Fall erstellen Alle Miner weiter die normalen Blöcke und wenn er will, eben zusätzlich einen extension Block.
Praktisch ist es so, dass von einem Miner im Main Block auch eine Referenz auf den Extension Block abgelegt werden muss, könnte man genauso machen, wie das bei segwit gemacht wird. Theymos hatte segwit letztens als speziellen extension block beschrieben in einem Artikel auf /r/bitcoin, ich halte das jedoch für eher unglücklich, da segwit eine Layer 1 Technologie ist und ich extension blocks als Layer 2 Technologie sehe.

Alte Clients sehen zwar die Referenz, aber für die ist das nur Text und hat keine Bedeutung.
Der Basis Block ist deswegen unter den alten Regeln weiterhin voll gültig und alle Transaktionen im Block können vollständig von alten Clients verifiziert werden.

Es wäre also Rückwärtskompatibel und der Client könnte jederzeit noch überprüfen, ob alle Regeln in den Basis Blockhain (z. B. 21M Limit von Basis Bitcoins) eingehalten werden. Ist sogar besser als bei segwit, denn da haben alte Clients das Problem, dass sie in der Basis Blockchain nicht überprüfen können, ob jetzt eine Segwit Transaktion wirklich mit einer gültigen Signatur ausgestattet war oder nicht.
Und wenn es zu einem UASF bei segwit besteht die Gefahr, dass alte Clients und SPV Clients ggf. auf dem counter hardfork landen (dazu braucht ja nur ein miner sich selbst eine segwit transaktion schicken und diese dann ohne gültige signatur wieder ausgeben, also ohne BTCs zu klauen).

Alte Clients haben also nur einen indirekten Nutzen durch die höhere Übertragungskapazität im Extension Block, wenn andere statt des Basis Blocks den Extension Block nutzen, aber es ist freiwillig.

Wenn man jetzt ein Ultra-HODLer ist, der an Bitcoin nur als Digitales Gold interessiert ist kann man die Extension Blocks ohne Sicherheitsverlust ignorieren, das ist der große Unterschied zu einem Hardfork mit größeren Blöcken, wo man nun den gesamten großen Block untersuchen müsste um sicher zu sein, dass alles mit den eigenen bitcoins in Ordnung ist.

Wenn man Bitcoin für regelmäßige Zahlungen nutzen will, oder öfter LN Channel öffnen möchte, und genug Rechenleistung und Bandbreite hat, ist es wahrscheinlich sinnvoll primär in den Extension Blocks Transaktionen durchzuführen, denn die Transaktionskosten sind wahrscheinlich geringer.

Für Miner wäre das auch interessant, da sich neue Möglichkeiten ergeben Transaktionsgebühren zu bekommen - und ggf. wäre das auch ein Kompromiss um aus dem segwit vs. Big Blocks Dilemma rauszukommen.

Wie der Mechanismus aussieht um die BTCs vom Main Block in den Extension Block zu bekommen und zurück müsste festgelegt werden, da gibt es mehrere Möglichkeiten.

Ob der Mechanismus ohne Wartezeit oder mit Wartezeit funktioniert ist wieder eine Sache, die man abwägen müsste.
Selbst wenn die Coins im Transfer gesperrt werden, wäre das aber immer noch viel besser als bei einem Chain-Split, denn da kann man die alleine überhaupt nicht zwischen den Blockchains bewegen, falls wir also tatsächlich einen Hardfork hätten, wäre das so, als ob man seine Bitcoins mit unendlich Wartezeit zum Transfer in die die andere Blockchain sperrt ;D

Davon hängt dann ab, wie die Nutzererfahrung ist, wenn man eine Transaktion von BTCs aus dem Main Block zu einer Adresse machen will, die im Extension Block gespeichert wird. Das könnte etwas länger dauern. Je mehr Miner einen speziellen extension Block unterstützen, desto mehr Freiheiten hat man, da die Miner auch den Extension Block absichern. Wenn alle Miner auch den extension Block minen, könnte man die coins natürlich ohne Wartezeit hin und her transferieren.

Eine Transaktion innerhalb des Extensionblocks würde ungefähr so funktionieren, wie wir das aktuell gewohnt sind mit den normalen Blöcken. Schlechter wird es wohl kaum, man könnte es auch so designen, dass es schneller als auf Layer 1 geht.

Der Extension Block kann praktisch ein beliebiges Format haben - aber zur Einfachheit kann man den am Anfang natürlich genauso aufbauen, wie einen "normalen" Bitcoin Block. Dann wäre die Arbeit das mit SPV Wallets auf dem Smartphone zu unterstützen sehr gering.

Extension Blocks haben ähnliche Nachteile für Nutzer, die diese nutzen, wie größere Standardblöcke, also erhöhter Speicherbedarf, CPU-Verbrauch und das alle alles speichern müssen. Aber keiner zwingt einen die extension blocks zu nutzen, man kann also auch weiterhin mit seinem Raspi Bitcoin nutzen und hat den alten geringeren Ressourcenbedarf.
Extension blocks können wohl kaum eine höhere Sicherheit haben, als die Hauptblöcke, dafür bezahlt man ja aber auch weniger Transaktionsgebühren als Nutzer.

The Blue Matt (Core-Dev) hat sich in der Mailing List darüber beschwert, dass Miner ja aus ökonomischen Gründen gezwungen wären dabei mitzumachen, aber ich sehe das anders. Es ist wie bei LN - es finden zusätzliche Transaktionen statt, die vorher niemals hätten stattfinden können. Dem Miner der nicht mitmacht, entgehen also überwiegend Transaktionsgebühren, die sonst bei Paypal oder bei einer Altcoin gelandet wären.

Eins frage ich mich allerdings doch, welche Effekte aufgrund dieses ökonomischen Aspekts auf Miner Zentralisierung zu erwarten sind. Andererseits funktionieren FIBRE,das Cornell Falcon Network und Thinblock Technologien schon jetzt ziemlich gut und erlauben es auch wieder kleineren Pools mitzumachen, ohne das ein größeres Orphan Risiko besteht.

Andererseits könnte es genau das sein, was die Miner wollen - mehr Blockspace zu verkaufen. Ich kann nämlich verstehen, dass viele Miner nicht unbedingt LN Hub Operatoren werden wollen, weil das komplett andere Fähigkeiten verlangt und einige Miner aktuell nicht ganz zu unrecht sauer sind. Und so hätten wir wieder eine Chance das Bitcoin-Ökoystem zusammenzuführen.


Ich denke das löst sich ganz einfach. Wer nicht kompatibel zum BOLT Standard ist wird Schwierigkeiten haben, weil keiner die Software benutzen werden will wegen dem fehlenden Netzwerkeffekt und glaube eher, dass es deswegen ein gemeinsames LN geben wird.
Ggf. wird es zwischendrin irgendwelche Clients geben, die zwischen den inkompatiblen Standards eine Bridge bauen werden und das Netzwerk so wieder vereinen.
Problem bleibt weiterhin die Routenfindung

Edit: Satzbau
Edit 2: Im Gegensatz zu Segwit bleibt die Teilnahme an Extension Blocks, wie bei allen Layer 2 Technologien, auch für neue Clients freiwillig

Danke MoinCoin! Also im Prinzip sind dann Extension Blocks ähnlich wie Sidechains, nur dass jeder Block direkt von einem Hauptchain-Block referenziert wird (also sozusagen eine "in die Hauptchain integrierte Sidechain"). Wird dadurch der Prozess des Transfers von Coins zwischen Hauptchain und Extension Blocks einfacher? Können mehrere "Extension Blocks" auf einen Hauptchain-Block folgen? Erstmal nur die beiden Fragen, um hier nicht zu weit OT zu gehen ;)

Hab die PM erhalten, danke. Von mir aus können wir einen Extension-Block-Thread aufmachen, interessiert sicherlich auch andere. Wobei, da ich den Thread hier ja gestartet hatte, ist es kein Problem das auch hier zu diskutieren. Vielleicht nenne ich den Thread dann einfach in "2nd layer-Technologien" um ...

Hatte mich auch kurz gefragt, ob das OT geht, aber selbst mit LN brauchen wir ja mehr Blockspace zum öffnen und schließen der LN Kanäle - sehe das einfach als mittelfristig notwendige Basistechnologie, damit LN seine Aufgabe erfüllen kann.

Ist sonst ziemlich unfair gegenüber den Entwicklern und der Technologie LN, weil LN als Layer 2 nicht alles alleine lösen kann und sollte.

Ja das Prinzip ist dem der Sidechains sehr ähnlich.
Die Kopplung zwischen den Mainblocks und Extension Blocks ist jedoch enger, als bei Mainchain und Sidechain.

Sagen wir mal so: Man könnte den Transfer von Coins zwischen Hauptchain und Extension Blocks einfacher und sicherer gestalten, als den zwischen Hauptchain und einer Sidechain.

Hinter den bekannten Bitcoin Adressen steckt ja implizit eine Anweisung, wie die Transaktion zu erstellen ist. Also welche ScriptSig zu verwenden ist, zum Beispiel bei P2KH Adressen (die einfachen 1er Adressen) mit einem PubkeyHash, sowie das zugehörige Main-Netzwerk und eine Prüfsumme um sicher zu stellen, dass die Adresse korrekt ist.
Es wäre also möglich ein andere Adresse oder ein anderes Adressformat für den Extension Block zu nutzen, so das dein Wallet wie bisher die notwendige Transaktion aus der Empfängeradresse erstellen kann.

Hypothetisch könnte dich dein Bitcoin Wallet fragen, ob du einen jeweilige Extension-Blockchain benutzen willst, und ob du die als Full-Archival-Node, Pruned-Node oder SPV-Node nutzen willst. Weiterhin sollte man einstellen können, ob dein Wallet automatisch die Bitcoins Up und Downgraden darf zwischen der Hauptchain (Haupt Utxo) und dem Extension Block (Extended Utxo).

Wenn man das auf automatisch stellt, würde ein einfacher Nutzer keinen Unterschied merken bei der Benutzung von Extension Blocks und Main Blocks. Bei den meisten Wallets sieht man ja auch nur, was für aktuelle Utxos man nutzt, wenn man etwas unter die Haube schaut oder Funktionen wie CoinControl nutzt.

Nachteil ist eben, dass zunächst jeder wohl auch weiterhin seine Adresse für Main Blocks und Extension Blocks angeben müsste, weil die Benutzung von den Extension Blocks ja freiwillig ist.
Aber das gleiche haben wir aktuell auch, wenn man Altcoins nutzt, weil einem die Transaktionsgebühren zu hoch sind.
Ich hoffe langfristig werden wir sowieso wegkommen den Nutzer mit den bekannten Bitcoin-Adressen zu quälen, sondern stärker auf andere Dinge setzen, so das Wallet sich die Empfängeradresse zum Beispiel über ein Payment Protocol selbst erzeugt. Das Payment Protocol würde dann erkennen, dass es auch die Extension Blocks benutzen kann und eine entsprechende Adresse wählen. Payment Protocols haben ja auch andere Vorteile, zum Beispiel eine höhere Anonymität gegenüber Dritten. Somit wäre das nur ein Problem für die Übergangsphase.


Und zu deiner zweiten Frage:
Grundsätzlich sollten auch mehrere Extension Blocks auf einen Hauptchain Block folgen können. Das ist immer alles eine Frage, wie eng man das Koppeln will und was für Vor und Nachteile sich daraus ergeben. Irgendwo verwischt auch die Grenze zwischen bestimmten Arten von Sidechains und Extension Blocks.

Man könnte die Extension Blocks auch mit Bitcoin-NG verknüpfen und den letzten Extension Block in dem aktuellen Main Block, sowie eintragen - derjenige Miner, der den Main Block gemined hat ist dann sozusagen auch der Gewinner, der die nächsten Extension Blöcke minen dürfte, bis der nächste Miner einen Main Block mined, der auch diese Extension Blocks minen will.

Es gibt extrem viele Freiheiten, aber ich denke es wäre sinnvoll am Anfang das ganze erstmal möglichst einfach zu machen, damit das ganze einfach zu verstehen, kurzfristig zu implementieren und zu testen ist und am wichtigsten: sicher funktioniert.

Wenn man dann einen besonders fortschrittliche Idee hat, lässt sich das sowieso deutlich leichter einbinden, als in Main Blocks.
Innerhalb des Extension Blocks kann man immer Hardforken (also den Aufbau und die Fähigkeiten des Extension Blocks komplett ändern), ohne das Risiko zu haben zusätzliche BTCs zu erzeugen oder die Chain zu splitten.
Die Frage ist da eher immer, ob man die Rückwärtskompatibilität trotzdem haben will. Ich denke, wenn man das so macht, wie viele Altcoins, und frühzeitig ankündigt, dass es Hardforks geben wird (z.B. Monero), dann ist das akzeptabel.

Alternativ hat man sowieso immer die Möglichkeit einen zusätzlichen Extension Block einzuführen.

Danke! Ich hab den Threadname jetzt mal geändert, damit man hier auch über andere 2nd-Layer-Techniken diskutieren kann.

Jedenfalls sehen Extension Blocks sehr interessant aus.

Bei den Extension Blocks stellt sich mir jetzt noch die selbe Frage wie bei den Sidechains: Wie funktioniert der Mechanismus, um Bitcoins "zurückzuüberweisen"? Also Main Block -> Extension Block sollte recht einfach sein über ein spezielles Script, das Problem ist aber das Tauschen der "Extension-Bitcoins" in die "Hauptchain-Bitcoins", da diese ja in der Hauptchain nicht existieren bzw. "entsperrt" werden müssten. Du hast es ja schon kurz angesprochen, dass es da mehrere Möglichkeiten gibt. Kennst du da bestimmte Vorgehensweisen, welche diskutiert werden? Kannst mir gerne auch einen Link dazu geben ...

Lightning Network ist nur eine Ablenkung before das Kommt hat Bitcoin schon längst die Nr 1 position verloren.

Wer will dann Channel aufmachen für einmalige bezahlungen das ist einfach nur Ablenkung und Ihr glaubt das ist eine Scaling Lösung.  ???

Blockstream verarscht euch und ihr checkt das nicht mal LN ist never ever für massen scaling nur für Banken zu Banken zahlungen gut .

Gilt das deiner Meinung nach auch für andere Scaling Lösungen auf 2nd Layer Basis? Was denkst du über z.B. über Rootstock, Sidechains/Drivechains oder die hier gerade erwähnten Extension Blocks? Würde mich echt interessieren.

Meine Meinung dazu: Eine (z.B. LN) alleine wirds nicht bringen, die Mischung machts.

Einen Vorschlag den ich kenne ist von Core Entwickler Dr. Johnson Lau.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html

Ist etwas technisch geschrieben, setzt darauf, dass Segwit bereits aktiviert ist und das nur ein einziger Extension Block vorhanden sein darf.

Danke. Muss aber zugeben, dass ich noch nicht viel verstehe, vor allem was ein "witness program" ist (wird was mit Segwit zu tun haben).

Jetzt gibt es ja auch den Vorschlag von Purse (http://www.coindesk.com/purse-proposal-touts-extension-blocks-bitcoin-scaling-solution/). Die Spezifikation (https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md) und Code wurde auch schon veröffentlicht. Sogar ViaBTC (BU-Unterstützer) hat angeblich Unterstützung zugesagt.

Witness program... Ja technische Details...

Das mit dem Vorschlag von Purse fand ich recht interessant.
Einige Core Entwickler fühlen sich glaube ich ziemlich auf den Schlips getreten, dabei ist das soweit ich das verstehe nur der erste überhaupt präsentierbare Entwurf.

Und wenn ich JJ (der das hauptsächlich programmiert hat) richtig verstehe ist es aktuell nur zu Segwit auf Layer 1 inkompatibel, weil es erstmal nur ein Proof of Concept ist, aber es gibt kein Grund, warum das so bleiben müsste.

Siehe auch:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013992.html

Mein lieblings Troll Samson Mow hat auf Twitter so getan, als ob ein geheimer Softfork ausgerollt werden würde.
https://twitter.com/Excellion/status/849036493381181440
Auch die Reaktionen von Maxwell, Luke-Jr, Matt, Adam Back fand ich ein bisschen seltsam.

Für eine weite Verbreitung bräuchte man sicherlich auch wieder eine Software, die auf Bitcoin Core aufbaut.
Und da gibt es aktuell einfach niemand der dazu technisch in der Lage ist außer Core. BU - denen ist ja Segwit schon zu kompliziert.

Manche tun so, als ob alles, was nicht von Core kommt oder frühzeitig öffentlich besprochen wurde an Softforks automatisch böse sei.

Es wäre schön, wenn alle Seiten die Dinge mehr von einer technischen Seite sehen würde, denn von einer politischen.
Ich kann auch einige Argumente nicht verstehen. Ich halte zum Beispiel Segwit nicht für einen sicheren Opt-In, Extension Blocks aber schon, während das Core einige anders sehen (insbesondere Matt Corallo).

Bei Segwit sehe ich das so, um die volle Sicherheit im Basis-Block zu haben muss man nun mal seine Software upgraden um sicher zu stellen, dass der Block valide ist und keinem Bitcoins im Basis-Block geklaut wurde. Auch hab ich mit Bitcoin Core ab 0.13.1 zurecht keine Möglichkeit auszustellen, dass die witness Teile bei Segwit nach Aktivierung überprüft werden.

Bei Extension Blocks kann es einem ziemlich egal sein, was mit und im Extension Block passiert, wenn man seine Bitcoins nur im Basis Block hat. Auch wenn man eine neuere Software hat, die Extension-Blocks grundsätzlich unterstützen würde könnte man den Benutzer dann immer noch wählen lassen, ob er die Extension Blöcke verarbeiten will oder nicht. Das ist auch der große Vorteil, den ich gegenüber einem einfachen Blocksize Hardfork sehe, selbst wenn dieser nicht kontrovers wäre. Mit einem Hardfork kann man nämlich nicht mehr einfach mit einem Raspi eine Full Node laufen lassen.

Ich freue mich auf jeden Fall, dass es wieder etwas Entwicklung gibt, da hab ich mich wohl umsonst gewundert.
Bis das nutzbar ist vergehen aber sicherlich auch noch mal 6-12 Monate.

Hoffe bis dahin haben wir zur Überbrückung Segwit :)
Vielleicht zeigt die Aktivierung von Segwit und wahrscheinlich daraus resultierende Preisanstieg bei Litecoin ein bisschen Wirkung bei Minern, die Segwit aktuell blockieren.

Und wenn nicht, dann können wir eben mit Rootstock ein bisschen spielen ;oD

Extrem interessante Entwicklung mit ASICBOOST und Segwit Blockade.

Es passt schon ziemlich gut zusammen, dass das der Hauptgrund für Bitmain / Antpool Segwit zu blocken.

Ein Dev für den Purse Extension Block, Joseph Poon hat bereits geantwortet auf Gmax Entdeckung und vorgeschlagen etwas in die Purse Extensionblock Spec einzubauen, was es wieder fairer macht für Miner und zusätzlich bekräftigt., dass Segwit im kanonischen 1 MB Block in die Extensionblock Spec mitaufgenommen werden kann.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013998.html

Die nächsten Tage werden interessant :oD
Bitcoin wird eben nie langweilig.

Was ist eigtl. der große Unterschied zwischen Bit 4 und Bit 1 bei Segwit ?
Warum wird da so ein Drama draus gemacht ?

Wenn es wirklich nur um 80% statt 95% geht , wo ist das Problem?
Sind die 95% von core vorgeschlagen wirklich wichtig oder ist das nur eine extreme Vorsichtsmaßnahme?


Gibt es eigtl. noch komplett andere Skalierungsmethoden außer Segwit und BU die derzeit im Raum stehen ?
Ich mein andere Coins können ja vielleicht sowieso viel besser skalieren, evtl. sollte man doch einfach nur erstmal auf 2MB erhöhen oder nur Segwit und dann langfristig weiter forschen, was wirklich 100% skalieren kann ?

Weil es schon lange nicht mehr um Technik geht, sondern um Drama. Viele der Vorschläge werden auch nur zur Ablenkung auf "den Markt" geworfen. Eine Implementierung ist weder geplant noch in diesem Stadium möglich.

Warum nur Altcoin Herrscher werden, wenn man auch Bitcoin Herrscher werden könnte?

Die Bits beziehen sich auf BIP9[1]. Dort ist geklärt wie anhand solcher Bits Regeln geändert werden können. Diverse SegWit BIP's laufen über Bit 1, u.a. auch 'UASF'. Bit 4 sagt mir gerade nichts, war aber auch ein bisschen weg.

Zur Skalierung. Jede Variante hat Vor- und Nachteile.

#2MB, sofort mehr Platz, ermöglicht aber neue Angriff, da die Bestätigung eines Blocks nur quadratisch Skaliert. Einen 2MB Block zu verifizieren dauert im schlimmsten Fall länger als den nächsten zu finden. Weiterhin nur mit Hard-Fork möglich, also werden alle alten Clients und Knoten aus dem Netz getreten und müssen auf neue Versionen updaten.
#SegWit, als Soft-Fork möglich, alte Clients können bleiben. Bringt aber nur langsam was, nur wer auf eine neue Wallet (Version) umsteigt und auf speziellen SegWit-Adressen Coins empfangen hat profitiert von dem zusätzlichen Platz. Bildet eine gute Grundlage für Probleme beim Skalieren der Verifizierungszeiten sowie "2nd Layer Lösungen".
#2nd Layer, also Transaktionen werden außerhalb der Blockchain geklärt und nur in mehr oder weniger großen Abständen wird eine Transaktion auf der Blockchain selbst durchgeführt. Bekannste Varianten sind wohl Lightning und Thunder (Lightning von bc.i)

Ich persönlich denke wir brauchen alles. 2 MB um sofort Platz zu schaffen, SegWit damit uns die 2MB nicht per DoS unterm Arsch weggeschossen werden und LN (o.ä.) um dauerhaft Transkationen aus der Blockchain abzuziehen.

---

Ach ja, theoretisch sind alts ja auch ne Lösung. Ich seh da aber nicht das Netzwerk der Akzeptanzstellen, deswegen taucht das in meinen Überlegungen oben nicht auf.

[1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

Bitcoin braucht im Moment keinen HF zu 2MB.

https://www.weusecoins.com/uasf-guide/

Da steht auch noch ein Vorschlag im Raum, 2MB basierend auf segwit als Soft-Fork umzusetzen. Der Vorteil wäre, dass damit das Skalierungsproblem gar nicht erst auftritt.

Letztendlich führt an 2. Layer kein Weg vorbei. Es ist nicht sinnvoll dauernd am Basissystem herumzuschrauben.


Solange Altcoins nicht entsprechend ihrer Funktion genutzt (Handel an der Börse ist keine Primärfunktion / IOU, Contracts etc. sind kein Geldsystem) werden oder kein freies System (wegen Pre-Mining / Führungsgremium) dahintersteht, sind sie keine Alternative zu Bitcoin.

wie soll das funktionieren? ein SF ist ein optionales akzeptieren einer veränderung der netzwerk regeln. ein HF ist ein notwendiges akzeptieren einer veränderung der netzwerk regeln.

wenn man neue regeln (features) hinzufügt kann eine "alte" node diesen block trotzdem akzeptieren weil sie von den neuen regeln (noch) nichts weiss. wenn man bestehende regeln (hartes limit der blockgrösse) ändert kann man das nur mit einem HF umsetzen.

Der Soft-Fork funktioniert über einen anderen Transaktionstyp. Die alten Knoten können die neue Funktion nicht nutzen und ignorieren die entsprechenden Transaktionen. Die Miner und alle neuen Clients kennen diesen Transaktionstyp und verifizieren ihn auch.

Klingt unnötig komplex, wenn der einzige Vorteil Abwärtskompatibilität ist. Zumal alte Full Nodes dann keine Full Nodes mehr sind, ist mir nicht klar wieso das nicht als Hard-Fork umgesetzt wird. Hast du dazu mehr Infos? Gern auch n Link zum BIP oder sowas.

die alten full nodes sehen einen teil der transaktionen nicht und somit ist für sie die blockgrösse <1MB. somit ist das keine verletzung der bestehenden netzwerk regeln und damit ein SF. klingt für mich nachvollziehbar.

was ist das für ein neuer tx typ? nur einer für off-chain? wo wird das diskutiert?

EDIT: so funktioniert segwit. willst du testen wer segwit wirklich versteht?

Ich habe vor ein paar Tagen im englischen Forum erfahren, dass bei Segwit2MB  - darauf soll ja die auf der Consensus-Konferenz von Minern+Bitpay+RSK usw. angedachte Lösung basieren - das "quadratic hashing time"-Problem dadurch gelöst wird, indem die Maximalgröße für Transaktionen auf 1 MB festgelegt wird.*

Seitdem ich das erfahren habe, unterstütze ich tendenziell den 2MB+Segwit-Fork statt den UASF - der ist mir zu gefährlich, ich mag keinen Chainsplit (und eine endgültige Community-Spaltung) riskieren. Da meine Haus-Exchange beim Agreement dabei ist, müsste ich wohl eh den 2MB+Segwit-Coin nutzen. Ich möchte aber für eine endgültige Bewertung erst mal den endgültigen Code (und Expertenbewertungen dazu) sehen. Es geistern einfach noch viel zu viele Halbwahrheiten dazu im Netz herum.

*Noch besser wäre es, wenn die 1MB-Grenze nur für "alte" Transaktionen gültig wäre, um zukünftige "legitime" Use Cases für 1MB+Transaktionen mit Segwit-Keys nicht zu blockieren. Das ist ja das Gegenargument zur 1-MB-Transaktions-Limitierung: dass man sich zukünftige Use Cases offenhalten möchte.

PS: Wobei die von Mezzomix angesprochene Softfork-2MB-Variante auch interessant klingt und für mich auch nachvollziehbar. Könnte man darauf basierend nicht ein endgültiges Agreement mit 100% Zustimmung hinbekommen? (Rhetorische Frage, da die Antwort bekannt ist)

denkst du den chinesen ist die community wichtig? die einzige sprache die sie verstehen ist UASF.

http://uasf.saltylemon.org/uasf_percent_all.png

man aktiviert jetzt SegWit so wie es Core ausgerollt hat. dann guckt man ob man überhaupt noch die blockgrösse erhöhen muss. und wenn ja, hat man bis dahin eine sehr gute lösung gefunden welche man eventuell auch als SF aktivieren kann.

EDIT: die referenzimplementation ist das erbe Nakamotos. Core verwaltet dieses erbe sehr gut. die miner sind dienstleister für das netzwerk. dafür erhalten sie eine vergütung (blockreward+fees). aber sie bestimmen niemals die strategische richtung. das ist machtmissbrauch ihrerseits welchen sie lustigerweise Core vorwerfen.

EDIT2:
https://i.imgur.com/1dO4GGn.png

ja please ich hoffe Core macht USAF und Baut das Protocol dann in Proof Of Nodes um  ;D

Dann werd ich mal meine letzten 10 % Bitcoin auch noch mal schnell in ETH machen bevor das Ratio noch weiter hochgeht sind ja schon fast wieder All time Low von ETH/BTC . Bitcoin verliert jede woche mehr und mehr wert gegen ETH ..woran das wohl liegt  ??? :o ;D


" die miner sind dienstleister für das netzwerk. dafür erhalten sie eine vergütung (blockreward+fees). aber sie bestimmen niemals die strategische richtung. das ist machtmissbrauch ihrerseits welchen sie lustigerweise Core vorwerfen.
"



Und wer bestimmt dann die Richtung ?   2,3 Core Devs die von einer Private Company bezahlt werden um Bitcoin umzucoden damit es
nur noch blockstreams Banking Hubs used ? 

Ist natürlich viel Besser alle Macht Luke& Maxwell zu geben anstatt es auf 1000 miner zu verteilen ist klar  ;D


GOGOGO Core weiter so mit USAF ...das flipping ist ja erst bei 50 % ....

Nach chainsplit sind wir dann geflippt weil beide Bitcoin versionen jeweils weniger wert sind als die 20 Billion die ETH dann schon hat  ;D


Proof of Node  - I Love Core <3

Vermutlich weil manchen Leuten der Unterschied zwischen Geld und Wertmarken für Verträge nicht klar ist. Und weil den Leuten nicht bekannt ist was Limited Supply und Unlimited Supply bedeutet. Und weil den Leuten nicht klar ist, was Pre-Mining bedeutet. Und weil Fundamentaldaten den Leuten egal sind - zumindest bis es schief geht und sie eine sozialisierung ihrer Verluste fordern.

Aber wenn diese Leute damit glücklich sind, dann sollen sie das ruhig machen. Eigenes Geld und eigene Verantwortung!

Was Du hier noch machst frage ich mich allerdings schon manchmal. Bitcoin abzulehnen und dann hier rumzuhängen ist schon ziemlich Schizophren. Warum gehst Du nicht zu Deinen Smart Contracts, die Dir soviel bedeuten, und vergisst Bitcoin einfach?

Genau so sehe ich das auch. Jihan Wu und Roger Ver sind Personen, die Wert in Fiat messen und Bitcoin ohne mit der Wimper zu zucken zerstören werden, wenn es ihren Zwecken dient (eigene Altcoin-Investments pushen). Bei Jihan Wu kann man außerdem noch die Möglichkeit in Betracht ziehen, dass er zum Aufbau seines Mining-Imperiums im großen Stil Kredite aufgenommen hat...



commander11 ist der Prototyp des Bezahl-Trolls, den man schon seit Jahrzehnten aus Börsenforen kennt. Ich behandle seine Beiträge eher als bizarre ASCII-Werbeblöcke.

Das sind nicht nur Chinesen, und überhaupt, was ist an denen anders als an US-Amerikanern, Deutschen usw? Sind alles einfach Kapitalisten, die von Bitcoin profitieren wollen. Lies dir nochmal die Liste der Unterstützer des Agreements durch. RSK Labs z.B. (die übrigens an einer interessanten 2nd Layer Lösung arbeiten) - pöse Chinesen?


Und riskiert damit einen Split. Super. Im Grunde genommen habe ich ja nichts gegen die UASF-Vorgehensweise an sich. Nur gehören die Miner eben zur Bitcoin-Machtstruktur dazu. Ist es dann verwerflich, auf die Miner zuzugehen um mehr von ihnen für den Softfork an Bord zu bekommen? Die Miner haben Segwit inzwischen akzeptiert, das ist doch das Wichtigste.

Und ich frage mich weiterhin, wie der UASF ohne wirtschaftliche Schwergewichte wie Bitpay und Coinbase funktionieren soll.

Ich bin aber inzwischen wieder optimistischer, dass bei der ganzen Sache doch noch ein brauchbarer Kompromiss herauskommt.

(Wie man in der Grafik sieht, war der UASF-Spike wohl ein Bug oder so. ;) )


Wer hat den Minern denn die Macht gegeben? Bitcoin basiert stark auf spieltheoretischen Überlegungen. Hätte man einen solchen "Machtmissbrauch" nicht voraussehen können? Wenn ja, dann ist das schon (von Satoshi?) so gewollt - um die Stabilität des Systems zu erhöhen, vielleicht.

Wenn man den Minern überhaupt keine Macht zugestehen will, muss man eben auf PoS und ähnliche Systeme setzen.

Nochmal: Was mich stört ist nicht der UASF, sondern der Umstand dass man lieber einen Chainsplit riskiert, als einen Millimeter auf die andere Seite zuzugehen.

Niemand hat ihnen die Macht gegeben. Sie nehmen sie sich einfach - falls die Nutzer ihnen die Chance dazu geben!

Ein Machtergreifung ist vorhersehbar, wenn der die entsprechende Person einen persönlichen Vorteil erlangen kann ohne irgendwelche Konsequenzen befürchten zu müssen. Es ist die Aufgabe der Nutzer, für die Konsequenzen zu sorgen. Das Bitcoin-System bietet dafür die Möglichkeiten (Select Longest Chain, UASF, Mining Algorithm Change, ...).


Den Archiven kann man entnehmen, dass bereits das Pool-Mining eine ungeplante Überraschung war. Die Ursprüngliche Idee war nur, dass sich Mining-Firmen herausbilden könnten, aber nicht, dass diese die Mining-Leistung von rechtlosen Hashrechner-Besitzern "geschenkt" bekommen.


PoS Systeme haben ihre eigenen Schwächen. Übrigens haben die Miner die absolute Macht über ihren eigenen Block. Daran hat auch niemand gezweifelt. Die Bestrebungen die Macht darüber hinaus auszudehnen muss und sollte allerdings niemand aktzeptieren.


Tatsächlich gibt es genug Kompromissvorschläge. Genau genommen ist bereits segwit ein Kompromiss. Allerdings gehören zu einem Kompromiss immer zwei Seiten.

+++


Und wie wir gut in der Informatik oft gelernt haben, ist der erste Wurf selten der beste. Meist benötigt man mehrere Iterationen / agile Methoden, um dem Ziel näher zu kommen. Zäh - insbesondere bei open source -  aber hoffentlich erfoglreich, solange das gemeinsame Ziel nicht z.B.  durch Ego-Kämpfe aus den Augen verloren geht....

Naja, in einem operativ genutzten Geldsystem sind iterative Regeländerungen und agile Entwicklung (betreffend der Konsensregeln) - zurecht! - absolut unerwünscht.

Vergleiche:

Alter

Anzahl Nutzer

Anzahl Konkurrenten

Anzahl Leader

Problemcocktail

...

Im Verglich zu historischen Geldsystemen ( Muscheln, Bohnen, Gold,...)


Das klärt etwas eine zu enge Perspektive.

Mir scheint langsam wird Ethereum Bitcoin den Rang ablaufen. Die Bitcoinproblemchen sind langsam zu Problemen geworden und eine Lösung scheint weiter entfernt als je zuvor je mehr Bitcoin benutzt wird.

Die hartnäckige Spaltung ohne aufeinander zuzugehen und dabei oftmals Argumente zu nutzen die schon lange widerlegt oder behebbar sind ist auch nicht hilfreich.

Die Coredevs haben große Macht einfach dadurch dass automatisch ein sehr großer Teil der User bei Core bleiben werden. Die Miner haben Macht weil sie forken können wenn sie wollen und die verlierende Chain wird mit heftigem Delay bei neuen Blocks rechnen müssen.

Und Lösung? Ich seh echt noch keine die man wirklich so nennen könnte und bei der entsprechende Effekte zu erwarten sind die alles wieder locker funktionieren lassen würden so dass alle zufrieden sind mit Geschwindigkeit, Preis und Verlässlichkeit.

Und warum? Weil einzelne dort (zwar nicht formal, aber faktisch) die Entscheidungsgewalt haben? Weil es Pre-Mining gibt? Weil das System gar kein Geldsystem ist sondern ein Smart-Contract-System? Weil die Nutzer tatsächlich Contracts erstellen statt Geld zu nutzen? Weil es Unlimited Supply gibt?

Oder ist es nur "keine Ahnung aber ich laufe mal der Herde nach" und Fakten waren gestern?

Man sucht ja immer irgendwie Vergleiche um zu deuten:


Bitcoin <-> Gold

ETH    <-> Methan

Wenn wir das mal so hinstellen, dann ist klar, dass es es einfach mehr Methan als Gold gibt, denn z.B. Methan furzt jede Kuh.

 ;D

Auch der Handel / MarketCap usw ist sicher bei Methan höher + volatiler, aber wie sieht's mit der Sicherheit aus? Wer will was wozu?

Die Banken-Industrie / Lobby will ja auch lieber viel Furz handeln (Vola = geil + hoher Spread)  und Gold drücken (damit z.B. die eigene fiat Währung nicht so mies aussieht) . JP Morgan usw wollen m.M. nach lieber ETH hoch traden + Bitcoin dabei kaputt machen. Das sehe ich auch so und es fruchtet auch schon.

Ich frage mich nur, wann der erste Funke fliegt und das Methan ..??? ..  

Dann freut sich wieder jeder Bitcoin zu haben.

Technisch ist es einfach ein anderer Einsatzzweck. Also Hammer und Schraubendreher. Mit dem Hammer klopft man Nägel hinein und mit dem Schraubendreher dreht man Schrauben ein. Natürlich kann man auch mit dem Schraubendreher Nägel einschlagen und mit dem Hammer Schrauben hineinklopfen. Das ist aber nicht der sinnvolle Einsatzzweck des jeweiligen Systems.


Sehe ich anders. Das sind zwei komplett unterschiedliche Systeme. Der Erfolg oder Misserfolg des einen hängt nicht direkt mit dem anderen zusammen. Ein Zocker der ohne Systemkentnisse und ohne Nutzen aus dem System zu ziehen einfach sein Geld auf ein System wirft, ist letztendlich für dieses System wertlos. Die Schweinebauchspekulanten gefärden auch nicht das Goldsystem. Die Folge sind lediglich kurzfristige Kurseffekte.

Mir geht es dabei auch weniger um den Marketcap als die Technik. Ethereum scheint viel vielseitiger zu sein weshalb wohl auch große Firmen eher auf Ethereum als auf Bitcointechnik setzen.

Ich bin nicht sicher wie Ethereum mit einem ähnlich hohen Transaktionvolumen klarkommen würde. Insgesamt tendiere ich aber dazu zu glauben dass ETH eine bessere Technik ist und Bitcoin überholen könnte.

Welche Performance hat Segwit denn jetzt eigentlich für LTC gezeigt? Segwit erscheint mir ein Schritt in die Zukunft da es automatisch skaliert.

Es mag für Smart Contracts die bessere Technik sein, für Geld ist es das alleine aufgrund der Parameter nicht. Undendlich verfügbares Fuel / Wertmarken als Spekulationsobjekt einzusetzen ist möglich, aber es ist sinnlos (nach Loriot).  ;)

Bei Litecoin hat segwit nichts gezeigt, weil dort gar kein nennenswertes Transaktionsvolumen vorhanden ist und ausserdem segwit alleine gar nicht soviel bringt. Bei Bitcoin würde segwit dagegen schnell eine kleine Entlastung bringen, der Mehrwert bezüglich 2. Layer und Erweiterungen stellt sich dagegen nicht sofort ein.

Es wird glaube ich noch etwas dauern, bis auch die ETH-Jünger zu begreifen beginnen, dass die eigentlichen "Killer-Apps" der Kryptowährungen, inflationsgeschützte Wertaufbewahrung (= virtuelles Gold) und dezentraler Werttransfer (= virtuelles Bargeld) sind.

Smartcontracts sind schön und gut und ich will auch nicht bestreiten, dass es Anwendungsfälle dafür gibt. Jedoch erfordern die meisten dieser Verträge, egal wie "smart" sie sind, letztendlich eine realweltliche Durchsetzung der Vetragsbedingungen.

Davon abgesehen ist ETH aufgrund seiner Konstruktion als Wertaufbewahrungs- und Transfersystem ungeeignet und wegen seiner auf Smartcontracts ausgelegten Komplexität Bitcoin unterlegen. Die Bewertung von ETH ist eine Spekulationsblase (von Ripple wollen wir erst gar nicht reden...).

Wenn das neue EOS von Larimer so funktioniert, wie angepriesen bei Consensus 2017, dann muss sich ETH, Tokenbums aber auch LN warm anziehen... Spannung!

@mezzomix: Noch kurz was zum Thema Miner/Macht. Ich sehe es so, dass die Miner als "Sicherheitsgaranten" ein Teil des Bitcoin-Ökosystems sind, die in einigen technischen Details andere Interessen als Exchanges und Payment-Prozessoren (die anderen "Großen" des Ökosystems) besitzen.

Dadurch wird das System stabiler, da eben die andere große Gruppe ("the Economy ^TM") ihre Regeln nicht einfach durchsetzen kann, sondern im Zweifel ein mächtiger Gegenspieler da ist. Das ist auch imho die größte Schwäche von Proof of Stake, dass dort quasi die "Economy" alleine das Sagen hat.

Ein Mining Algorithm Change, UASF und ähnliches funktioniert nur, falls wirklich die Interessen beider Gruppen (Miner / Economy) diametral entgegengesetzt sind. Ich glaube aber, dass den meisten Nutzern und auch dem größten Teil der "Wirtschaft" es reichlich egal ist, welche Technik jetzt hinter Bitcoin steckt - Hauptsache, es funktioniert, d.h. im derzeitigen Fall: es wird eine Lösung für die vollen Blöcke gefunden. Das sieht man ja jetzt auch beim Barry Silbert Agreement, da ist u.a. Bitpay dabei.

Hätten die Miner dagegen weiterhin Segwit vollständig blockiert, wäre die Situation einer Polarisierung zwischen Wirtschaft und Minern tatsächlich eingetreten, und dann wäre auch ein UASF oder gar die "nuclear option" sinnvoll gewesen, zumindest als Drohung im Hintergrund.

Jetzt ist aber die Situation so, dass es eigentlich nur noch um Details geht - wann HF, wann Segwit - und da ist eine künstliche Polarisierung via BIP148 imho fehl am Platz.

Trotzdem, mir gefällt das von dir irgendwo vorgeschlagene 2MB+Segwit als Softfork-Konzept am besten. Aber selbst das Original-Agreement ist noch besser als der Status quo und weit besser als ein Chainsplit.


Die rechtlosen Hashrechner-Besitzer haben aber die Wahl, für wen sie den Sklaven spielen wollen. Und bei den meisten Mining-"Pools" stehen ja Mining-Firmen dahinter, die tatsächlich einen Großteil der Hashrate selbst stellen - gerade beim kontroversen Bitmain-Konglomerat, wenn ich das richtig sehe.

Wieviel Investition die Pools selber stellen ist nicht bekannt. Ungeplant ist hingegen der Anteil an Hash-Power, der nicht mehr im eigenen Interesse, sondern im Ernstfall (aus Dummheit/Bequemlichkeit) sogar gegen die eigenen Interessen handelt.

Wenn eine Gruppe im System die eigenen Interessen einfach aufgibt, dann führt das im gesammten System zu Problemen. Das hat schon viel früher angefangen und das Ergebnis sehen wir jetzt. Will nur kaum einer wahrhaben, also wird einfach da weitergemacht wo man die Karre in den Dreck gefahren hat. Andere sollen/werden das Problem schon lösen.

Bitrefill hat im Testnet eine erfolgreiche Lightning Transaktion durchgeführt.
Es passiert als etwas
https://blog.bitrefill.com/test-instructions-lightning-on-bitrefill-ef6db8714b00

Was glaubt Ihr? Wann gibt es die erste Livetransaktion?
Was ist dafür noch erforderlich?

Falls Du das Produktionsnetz meinst, ist bereits geschehen:
http://www.livebitcoinnews.com/first-lightning-network-transaction-bitcoins-mainnet-success/ (http://www.livebitcoinnews.com/first-lightning-network-transaction-bitcoins-mainnet-success/)


Stabilisierung, Stabilisierung und nochmals Stabilisierung. Es bringt nichts, eine Lösung auf den Markt zu werfen, bei der die Leute danach ihr Geld wegen Fehlern in den Applikationen verlieren. Danach Tests mit kleineren Summen. Daneben müssen die Schnittstellen passen. Ein Bündel inkompatibler LN Applikationen bringt nicht soviel, wie wenn die verschiedenen Lösungen alle zusammenarbeiten.

Es geht bei den "100 New Shitcoins per Day" etwas unter, dass man funktionierende(!) technische Lösungen nicht durch Marketingkampagnen und schnelle Börsenplatzierungen bekommt, sondern durch solide unspektakuläre Arbeit, Kooperation und Tests.

Eine Frage, die nur indirekt was mit den Second Layer Lösungen zu tun hat.
Wie sieht es nun mit dem theoretischen Maximum für die On-chain Skalierung aus und was für weitere Optimierungen sind da geplant oder im Gespräch? (Sowas wie Schnorr-Signatur)
Da das meiner Meinung nach auch zu einem gewissen Grad entscheidend sein wird wie effektiv die Second Layer sein werden, da es ja auch zu einem Punkt beeinflusst wie schnell und kostspielig sich z.B. beim Lightning Network Payment Channels öffnen lassen oder bei Rootstock auf die Sidechain wechseln kann bzw. zurück auf die BTC-Chain.

Aktuell liest man ja überall, dass Bitcoin nur 7 Tx/s schafft usw.

Wenn ich jetzt mal sehr vereinfacht nur wissen was im Idealfall (1 Input, 1 Output, SegWit usw.) theoretisch an Transaktionen in einen Block passen würde. Wenn ich das mit einer meiner Electrum Adressen mache (Bech32 in dem Fall), dann ist diese Transaktion 110 bytes groß. Alleine so würden bei bspw. einer Blockgröße von 1 MB 9090 Tx reinpassen und das wären schon 15 Tx/s. Dass es in der Realität nicht so ist, weil 1 Input & 1 Output einfach nicht der Normalfall sind, ist mir natürlich auch klar.

Jedoch würde mich trotzdem interessieren was man für weitere Ziele bezüglich der On-Chain Skalierung hat. Schnorr Sig soll ja, sofern ich das richtig verstanden habe, unter anderem dafür sorgen, dass eben aus mehreren Inputsignaturen eine "übergreifende" Signatur erstellt wird, die dafür sorgt, dass man nicht alle in der Transaktion benötigt. Gibt es noch andere Sachen, die im Gespräch sind, von denen ich nichts weiß?

Ich buddle den Thread mal wieder aus, da ich gerade auf ein interessantes Whitepaper aufmerksam gemacht wurde. Es geht um sogenannte "Channel Factories". Dies ist eine im November 2017 vorgeschlagene Technik, mit der Lightning-Kanäle einfacher aufgemacht werden können sollen.

Das Paper dazu findet ihr hier (https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf).

Da alle Dokumente die ich kenne dazu auf Englisch und entweder sehr trivial oder in technischer Sprache  sind (wenn jemand was auf Deutsch oder auch Spanisch kennt, nur her damit!) habe ich bisher nur den Ansatz verstanden (hoffentlich richtig).

Und zwar geht es um folgendes:

Normalerweise macht man ja in LN jeweils einen "Payment-Kanal" zu einem anderen User/Node auf, der sich dann mit anderen Payment-Kanälen zu einem Netzwerk kombinieren läss. Der Nachteil: Um jeden Kanal zu öffnen und zu schließen, brauche ich eine On-Chain-Transaktion.

Nun gäbe es aber dank dieses neuen Konzepts auch die Möglichkeit, sich zu einer Gruppe zusammen zu tun und einen speziellen Channel (z.T. als "Superchannel" oder "Masterchannel" bezeichnet) mit allen anderen zusammen aufzumachen.

Wenn ich es richtig verstanden habe, kann man innerhalb dieser Gruppe dann beliebig viele "Unterkanäle" aufmachen, ohne eine weitere Transaktion zu "verschwenden". Das heißt: Eine Gruppe von 10 Personen kann etwa 90% Blockchain-Platz bzw. Transaktionsgebühren sparen (siehe Tabelle hier (https://bitcoin.stackexchange.com/questions/67158/what-are-channel-factories-and-how-do-they-work)).

Für mich wäre es interessant, ob diese "Superchannels" auch einfach "erweitert" werden können, d.h. sich neue Personen dazugesellen können. Ich meine es so verstanden zu haben, dass dies geht, aber dann jeweils eine neue On-Chain-TX fällig wird (der "Superchannel" wird also geschlossen und ein neuer mit den neuen Mitgliedern aufgemacht).

Je größer die Gruppe, um so besser, d.h. um so mehr Platz wird gespart. Eine Limitierung scheint es aber zu geben: Es können wohl beim derzeitigen Bitcoin-Code maximal 15 User mitmachen - bei Einführung der Schnorr-Signaturen dagegen mehr.

Meinungen und Korrekturen wie immer erwünscht :)

Auf unserer Trading Plattform kann man seit heute Bitcoin über LN (Mainnet) einzahlen.
Sowohl c-lightning als auch das Eclair Wallet für Android funktionieren einwandfrei.

Das Feature befindet sich noch im Beta-Stadium. Es sind noch keine Auszahlungen über das LN möglich. Safety first :)


http://blog.vaultoro.com/2018/05/04/vaultoro-first-exchange-to-implement-bitcoin-lightning-network/