Wenn ich das richtig weiß ist das aber nicht auf dem Consensus-Layer (sonst wäre das ja praktisch ein (UA)SF gewesen) - Heißt, dass die Nodes die Transaktion zwar nicht weiterleiten, aber ein Miner kann natürlich immer Non-Std-Tx in seine Blöcke einbauen, wenn er das will, soweit die consensus rules nicht verletzt werden.

Schlussfolgerung:
Der Miner wollte wahrscheinlich unbedingt diese Transaktion einbauen

Nach dem Anfänger Problem kommt das Fortgeschrittenen Problem:

Einige glauben sie könnten genau vorhersagen, wie lange es dauert mit einer bestimmten Fee eine Transaktion bestätigt zu bekommen.

Man kann aber nie zu 100% vorhersagen kann, ob die Gebühr reicht, außer man setzt die Gebühr so hoch, dass aufgrund der verfügbaren Bitcoins keiner einen überbieten kann  .
Wenn man etwas Pech hat (z.B. nächster Block kommt erst in 1 Stunde) kann es sein, dass man aktuell warten muss, bis dann die Transaktion am Wochenende durchgeht.
Mining ist nunmal ein stochastischer Prozess und man weiß nicht, was alles noch in den Mempool kommt bis zum nächsten Block.

Um mit Sicherheit die "richtige" Gebühr zu finden müsste man wissen, wann die Miner in der Zukunft die Blöcke finden und welche andere Transaktionen in Zukunft alle Teilnehmer mit welcher Gebühr senden würden.

http://bitcoinfees.21.co/ gibt zum Beispiel die Gebühren so an, dass man zu 90% davon ausgehen kann, dass es in der angegeben Zeit durchgeht.

Hat bei mir bisher bis auf eine Transaktion immer geklappt, wenn ich mich an den Vorschlag von 21 gehalten habe - einmal hat es dann eben bis zum Wochenende gedauert.

Ob man jetzt für größere Blöcke ist oder nicht...
Btc.top zeigt für mich damit, dass sie nicht für größere Blöcke bereit sind, weil sie offensichtlich die Technik nicht beherrschen.
Ziemlich peinlich, wenn man berücksichtigt, dass die BU/EC pushen wollen.
Habe auf eine Adresse von mir auch so ein Mist empfangen, den ich wahrscheinlich niemals ausgeben werde.

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.

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.

Das hab ich mich auch gefragt.
Gab es diesen Monat ein Treffen?

Was macht ihr da so?
Würde nächsten Monat vielleicht mal rumkommen - findet da was statt?

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

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

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.

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

Lol yes - Feels a bit like everybody knows, but nobody cares enough or all are just to afraid.
One obvious solution is to not have the debate, but to solve the problem it in a way which does not need permission from everybody, preferably not altcoins  

Edit:
Please compare this to a split chain scenario. Essentially your bitcoins are then locked forever in the other chain ;o)
Of course you can sell them, but with extension blocks you could do this too.

Locking would only be needed, when there are not enough miners mining the specific extension blocks, to be safer against reorgs / double spends / replay attacks on the main chain -> See my post above. This is where the simple idea ends and the engineering starts

Nah you are jumping one step ahead. This is only a raw idea.
If you'd have support from miners and would SF the logic into main blocks, you don't have to lock the bitcoins.

So how would this work without locking bitcoins:
One simple solution would be to hold them in a special address on the main utxo and the user adresses on the extension utxo.

All miners still mine the main blocks.
EC miners additionally mine ec blocks. Segwit miners also mine segwit blocks.
A lot of miners will mine both, because they want to have the fees.

This would require 51% of the miners of an extension block have to be  honest, because only they know the rules.
So having 51% of all miners would be advisable.

When we compare this to a chain split scenario this is not worse, because there we also need 51% of the complete hashing power, to be safe against reorgs.

Sidenote:
I think a reorg on the main chain would only induce the same reorg to the extended blocks, because they are completely synchronized, if the logic of utxo selection for the downgrades is deterministic (think replay attacks) - this is where extension blocks differ from sidechains, where reorgs on the main chain are a huge problem.

Not entirely of course, but the relationship can be weakened

Lol sapeggitt ;oD
Yeah the beauty is that you only have to softfork once if you prefer hardforks and than can hardfork the extension blocks chain all you want without having the danger to double the BTC amount.

While segwit may be a compromise beetween small blockers and normal blockers, it completely disregards big blockers and as we can see through segwit readyness signaling also provides little incentive (or even negative) to miners.

I don't think core devs would love this. They would have to compromise too...
Devs are pretty smart - it would be no problem to implement this, the question is do they want to and if this is an acceptable compromise.
Unless devs for one extension block don't fuck everything up, they should always be fungible with real BTC through the main block.

The overall fungibility might even improve because downgrading the bitcoins back into main blocks could (would likely?) be implemented with free mixing.

In essence you could upgrade your bitcoins from the main block utxo to an extension block utxo.
Downgrading of course is also possible, although technically slightly more difficult.

Of course to send btc from a therotical EC extension block to a theoretical segwit extension block this could take some time, but this should be alot faster than if we split into two chains and you would'nt even be able to do this, no, you'd have to go through an exchange.
And than you'd of course have services like we have today with shapeshift, which would reduce the number of needed downgrade/upgrade to other extension block chain alot.

As a normal user your wallet could do that for you automatically.
The complexity could be wrapped through different adresses for the different extension blocks.

Its a bit like Lightning BTCs. When you have locked up your BTC in a channel you cannot use them otherwise. But the other party may not accept Lightning so you may find yourself in a dilemma.

So we would be better here from a user experience too compared to a split - and most settled transactions would be intra extension block.

You could design the basic idea of extension blocks in a numerous ways.
The most advanced document I found so far is this, though the document may slightly differ from my idea
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html



It is not ideal, but it I like it far better than status quo, contentious HF or UASF, which are the most popular ideas atm.

Thinking further ahead, I don't think we will end up with endless different extension blocks.
Each extension block has to provide clear advantages over what we already have.
Segwit and EC blocksize should both have enough interested people.

For the digital gold people, who only want to HODL this would be completely opt-in.
You could still use plain bitcoin 0.12 and receive bitcoins, completely ignoring the extension blocks.
Nobody would force you to use segwit or submit to EC.

It is not a perfect solution, but the best I currently can see. I think it is feasable, morally acceptable, makes HFs easier within the extsion blocks, preserves node decentrailization, allows miners to let onchain compete with offchain and most importantly does not split the currency bitcoin.

It does not need the permission from every development team. BU could go ahead, team up with Classic and do this without Core, if they would get support from the miners.

On the negative side i would create a little technical debt in the beginning, because you'd have to support extension blocks.
But later you would be saved from additional technical debt and could even pay off some.
E.g. if EC extension blockers deem segwit technical debt they do not need to support segwit.

Of course - an uncontentious HF would be cleaner, but due to politics from all sides will not happen in the next years.
For me this is so much more appealing than a chain split.

Funny thing is - because they use a completely seperate blockchain (which is merge mined with bitcoin) i suspect the oposite.
The higher the fees on the main chain - the more incentive for users to go to the sidechain, where we can easily have 100 tps onchain.
RSK will have a two way peg -> 1 Smart Bitcoin (SBTC) equals 1 Bitcoin
But atleast initially RSK has a very different (trust-) model than plain BTC and will need completly new software.

Yeah.. I don't even know which side you are referring to
Seems to me that this is true for extremist on both sides.
I'm more or less comfortable in the middle of this mess.

Do we really need to split bitcoin the currency?
A compromise with the Bitcoin Network/Blockchain would be better IMHO.

As far as i can tell, the majority is not comfortable with EC blocksize let alone BU.
On the other side I think UASF without 51% miner support is dangerous, because miners could just fake support for UASF and just orphan all blocks, which would actually include segwit transactions, while still adhering to the rules of the UASF/segwit.

So IMHO UASF does not safely work under given circumstances and EC has not enough economic support to do a safe HF.

An incomplete thought:
Why not add emergent consensus on blocksize through soft forked extension blocks and 1MB+segwit on the main blocks?

Another compromise could be main block 1 MB, extension block Core with segwit and max 2.7 MB blockweight and extensionblock with EC blocksize.
So when you'd run core, you'd have the same spam attack surface as with segwit now.
Of course this would mean more work for devs, which want EC, but the potential reward is higher.

The beauty for BU would be that afterwards you could hard-fork on that extension blocks all you want, without having the risk to split the base BTC currency.

P.S. my personal favorite is SBTC with RSK ;oD

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

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.

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.

Thank you for your reply.
I still think LN is the best solution out there, but I'm not able to completely follow your train of thought.
For which transaction multisig?

https://lightning.network/lightning-network-paper.pdf
Page 26 and 27

A hacker of Alice could change PAliceD to PHackerD.
Of course he would have access to KHackerD
So having a multisig address (PAliceD + PAliceDOffline) instead of simple PAliceD would not suffice.
Would you have to trust the other party, that they would not accept a change of the delivery address?

Meaning a hacker of Alice would have access to KAliceF, the private key of the funding transaction and KAliceRSMCn.

How would that work with 2 factor?
Do you have to 2 factor sign every msathoshi sent and received?

I see a possible solution by having 2 LN channels:
- channel for micropayments with online singlesig which is as hackable as a normal hot wallet
- channel with 2 factor for higher amounts, where it would be acceptable to manually do the 2 factor signing? What do we gain by multisig ? Wouldn't it suffice to just keep your funding private key offline / on another device? (I still have to think about the RSMC keys, but even  if you want to keep the RSMC keys offline too, that would be also feasible), which would be as (un-) hackable as a traditional cold wallet


Edit: Having access to the RSMC keys in a timely fashion (e.g. 1000 Blocks, or whatever is agreed upon in the channel) is critical if someone would cheat.

But how can you then sign the punishment transaction, when you received and sent money through the same channel?
Do you have some link?

To revoke the previous state of the channel both participants have to sign the spending of the outputs of the previous state of the channel to prevent cheating don't you? (or give your private key to the other party)

https://lightning.network/lightning-network-paper.pdf
Page 24

What i called punishment transaction is called Breach Remedy in the paper?

Edit: Do we even need segwit / malleability fix for LN, if you could instead just hand over your private key for the Breach Remedy? It does not matter that much if the commitment transaction gets malleated, does it?

Yeah 1 GB was a pretty high number.

So then lets guess what we'd actually need in the foreseeable future.
In the last 2 years transactions per day have more than tripled, and IMHO would have quadrupled, if we had increased the block size.
https://blockchain.info/charts/n-transactions?daysAverageString=7&timespan=all

Thats about x2 per year. So 8 MB would give us 3 years, if we'd continue on this path.
Even if adoption would slow down, so we'd double every 2 years, thats only 6 years.

But i think the adoption rate would even increase if we'd have bigger blocks, so this may give us only 1.5 years.

8 MB would be about 250,000 * 8 = 2 million transactions per day, or 60 million transactions per month
Today i rarely use on-chain transactions, because I think they are already to expensive.

If I use EUR, I can send any amount for free (SEPA, CASH) or even get money as a consumer.
I'd change my behaviour, if bitcoin transactions would be cheaper and also if there be more counterparties, which would accept bitcoin.

If cheaper, I'd do somewhere between 10 and 30 transactions per month.
Lets say everyone do just 5 transactions per month, then the network would cap at 60 million / 5 = 12 million users on 8 MB.

With schnorr and other engineering that even may double to 24 million.
So with 32 MB we could support about 100 million users.

8 MB is only 400 GB / year, which i think is acceptable with current technology, therefore I run Bitcoin Unlimited with EB 8 / AD 6, which does not make me totally happy, but would be the best compromise for me personally.
Because we'd have a bigger user base if those blocks were fully utilized, some new nodes would appear, some old would disappear, because they deem it to expensive to run, but overall decentralization could stay roughly the same with 8 MB.

8 MB would give us enough time to deploy the LN without forcing people off the network, where as I'm not convinced segwit and schnorr would be enough.

I'm personally even okay with 32 MB, if I could use bitcoin for virtually anything. I'd probably run a pruned node then. If we'd adopt a well used layer two solution, than it would take some time to fill up more than 8 MB blockspace and even running an unpruned node may be cheap in 10-20 years with 32 MB blocksize / blockweight to stay decentralized.

I don't even think 32 MB will be a high a risk for miners, regarding orphanage, because there is still a lot of progress in onchain scaling (Xthin, weak blocks, pre-verified transactions). When time comes I'm optimistic that today's problems would be solved.

But to use it in your everyday live, you'd probably need at least 1 tx per day.
With 100 million users (which is what I think is reasonable number for mass adoption) that would give us 3 billion transactions per month, or 400 MB standard blocks (7.5 milion transactions per month on 1 MB), not far off from 1 GB, which I don't think would be unrealistic in 30+ years.

And If you don't want to convert bitcoin into a banking like centralized, trust based system, we will still need a decentralized layer on top of the blocks. LN is currently the most promising IMHO.
E. g. XAPO charges about 2.5 to 3.5% (via low sell price) on its EUR debit card, and I don't know any cheaper solutions for everyday shopping.

That said:
Segwit is currently dead
We need more blockspace anyway
And we need a malleability fix to enable bidirectional payment channels to use bitcoin in everyday transactions