Bitcoin Skalierung neben LN

Ich habe mich gefragt, wie kann man Bitcoin neben LN noch skalieren.

Nehmen wir an, wir würden Bitcoins in einer Wallet einschließen. Dann könnte man doch die enthaltenen Bitcoins mithilfe eines Stablecoins 1:1 abbilden. Wichtig, dies ist überprüfbar, weil man die Anzahl der Stablecoins und der eingeschlossenen Bitcoins kennt. Die Stablecoins werden nur erschaffen, wenn man in den Pool Bitcoins einzahlt und zerstört, wenn man auszahlt.

An sich baut man auf dieser Poolwallet ein weiteres Netzwerk als 2nd-Layer, welches eine eigene Chain besitzt und Transaktionen unsichtbar vom Main-Layer validiert. Man würde dann auf seiner Full Node noch eine entsprechende Poolnode betreiben. Es können theoretisch unendlich viele Pools erschaffen werden. Zum Beispiel hat man den Pool Europa und den Pool Nordamerika (Sie müssen nicht geographisch getrennt werden, ist hier nur zwecks Beispiel). Als Nodebetreiber in Europa muss man nicht mehr jede Transaktion in Nordamerika speichern, sondern nur die vom Bitcoin Main-Layer und die des Europapools. Die Pools und der Bitcoin-Main-Layer konkurrieren um die Hashrate der Miner, sodass nur einige wenige Pools sicher genug sind, um eine 51% Attacke standzuhalten und sich durchsetzen werden. Die Hashrate der Miner würde somit auch deutlich effizienter genutzt werden.

Die Regeln der Pools sind unabhängig vom Bitcoin Main-Layer, aber das Netzwerk ist zu 100% durch Bitcoin gedeckt. Man könnte zum Beispiel festlegen, dass die Blockgröße vom Pool bei 8MB liegt und dann in dem Pool deutlich günstigere Transaktionen anbieten ohne dabei eine Hardfork auszulösen. Allgemein kann man neue Feature erst einmal in einem Pool testen und muss den Main-Layer nicht so oft anfassen.

Man sieht ja auch heute schon in Entwicklungs- und Schwellenländern, dass Stablecoins bei den Schwierigkeiten im Bankensystems Abhilfe schaffen können. Ich denke mit Bitcoin wird es möglich sein, einen echten dezentralisierten Stablecoin zu erschaffen mit welchem man die Limitierungen von Bitcoin umgehen kann.

Was meint ihr. Kann dies als Skalierung neben dem LN funktionieren?

1 „Gefällt mir“

Du möchtest ein PoW-Netzwerk mit größeren Blöcken und wahrscheinlich kürzerer Blockzeit als SecondLayer umsetzen?
Das ergibt leider überhaupt keinen Sinn!
Der einzige Grund den du dafür aufführst ist doch, dass dank Sharding (geografische Aufspaltung) die Blockchain weniger schnell wächst. Nun werden 8MB-Blöcke bei weitem nicht genügen, um eine ausreichend schnelle und günstige Transaktion tätigen zu können.

Was genau meinst du mit „Stablecoins“? Wie soll Bitcoin auf dem Mainlayer geblockt und auf einem zweiten Layer als Stablecoin ausgegeben werden? Woher kommt die Umrechnung? Bekomme ich automatisch mehr Stablecoins, wenn der Kurs steigt und ich Bitcoins gelockt habe? Im Umkehrschluss werden mir auch Stablecoins weggenommen, wenn der Kurs fällt?

Nein das macht keinen Sinn.

Hört sich ein wenig nach stablesats.com an, also synthetische USD backed by Bitcoin.

OMG… wer macht sowas?
Börsen und Co. mit ins Spiel bringen?

1 „Gefällt mir“

Ein Stablecoin ist Mmn erstmal nur eine Kryptowährung, welche den darunter liegenden Wert 1:1 abbildet. Zum Beispiel bildet Tether immer genau 1 USD ab. Der US Dollar war ja auch mal sowas wie ein Stablecoin, er bildete damals eine bestimmte menge x an Gold ab. Man konnte dadurch die Schwierigkeiten von Gold, wie hohe Transportkosten, leicht umgehen. Genauso könnte man doch auch einen Stablecoin erschaffen, welcher genau 1 BTC abbildet.

Stell dir vor die Bitcoin Blockchain wäre ein riesiger Tisch und es werden dort die ganze Zeit Bitcoins hin und her transferiert. Jetzt machen wir neben diesem Tisch einen weiteren Tisch auf. Wir legen dann dort unsere Bitcoins ab und handeln am zweiten Tisch, haben aber die Möglichkeit unsere Bestände abzuheben und wieder zum ersten Tisch zurückzukehren. Natürlich kann man nicht die Bitcoins einfach an eine zweite Blockchain schicken. Da kommen jetzt die Stablecoins ins Spiel. Man eröffnet auf der Bitcoin Blockchain eine wallet die niemanden gehört, ich hatte das jetzt hier Pool genannt. Wenn man in den Pool einzahlt bekommt man an dem zweiten Tisch die gleiche Menge an Stablecoins gutgeschrieben und umgekehrt, wenn man auszahlt werden die Stablecoins vernichtet. Jetzt können wir an dem zweiten Tisch bedenkenlos miteinander handeln, weil wir die Menge an BTC in der Poolwallet und die Menge an Stablecoins auf dem zweiten Tisch kennen 1 Stablecoin = 1 BTC. Wir sind jederzeit in der Lage unsere Stablecoins wieder in BTC zu tauschen. Wir können auch beliebig viele Tische um den Bitcoin-Main-Layer aufmachen, mit jeweils eigenen Regeln.

Der Sinn dahinter ist, dass wir den Main-Layer entlasten. Nehmen wir eine Bitcoin Transaktion kostet 1000€ äquivalent. Für eine monatliche Gehaltsauszahlung wäre eine Bitcoin Transaktion zu teuer, aber ein Gehalt wäre jetzt auch keine Kleinausgaben, wie ein Kaffee bezahlen, wo man Lightning einsetzen würde. Ich hätte das doch gerne schon auf der Blockchain gespeichert und da könnten die zweiten Tische Abhilfe schaffen.

Zentralisiert wäre das leicht umzusetzen, z.B. gebt mir eure Bitcoins, ich hinterlege sie und gebe dafür euch meine Stablecoins. Mit diesen könnt ihr frei handeln und sie jederzeit bei mir in BTC wieder umtauschen.

Die Kunst besteht nun darin das zentralisierte Konzept dezentral umzusetzen.

Mir ist das Prinzip und unterschiedliche Ansätze von SecondLayer-Lösungen durchaus bekannt.
Der Sinn deiner Lösung geht jedoch daran zugrunde, dass du weiterhin auf PoW setzt und gleichzeitig Sharding einführst, was die Nutzbarkeit (Sharding) und Langlebigkeit (PoW mit großen Blöcken) innerhalb des Layers stark einschränkt. Ich wäre dann bei den möglichen Adressaten begrenzt. Wenn ich dann doch mal eine Transaktion zu einem Teilnehmer eines anderen Shards durchführen möchte, muss ich entweder teuer über den Mainlayer gehen, eine unsichere Bridge (Ich sag nur Hacks^^) benutzen oder lasse es wegen des Aufwands einfach sein.

Ein Beispiel wäre folgendes:
Ich bin ich ShardA und fühle mich dort wohl, weil ich dort alles erreiche, was ich so brauche.
Nun möchte ich jemanden in ShardB erreichen. Da ich auf jeden Fall in ShardA zurück möchte, muss ich 4 Onchaintransaktionen machen (jeweils 2 davon könnte man eventuell bündeln).

  1. zurück in den MainLayer
  2. in ShardB
  3. zurück in den MainLayer
  4. in ShardA

Ich glaube, ich würde mich allein wegen der Kosten dazu entscheiden, dies einfach sein zu lassen.

Das wäre schon ein immenser Eingriff in ein „free and borderless money“.

Kennst du Liquid?
Das wäre eine viel sinnvollere Alternative zu deiner. Hier hast du „nur“ das Problem, dass du wenigen Entitäten vertrauen musst, da die Nodes an eine handvoll Teilnehmer fest vergeben sind.

Wrapped Bitcoin auf Ethereum

1 „Gefällt mir“

Galoy

Edit: Die weiteren Ausführungen ähneln mMn dem Fedimints Konzept?

1 „Gefällt mir“

Ich verstehe den Usecase des „Stablecoins“ in der Praxis nicht ganz. Wieso sollte Lightning das Problem nicht lösen? Weil es zu Volatil ist und Stablecoins „Stabil“?.
Ich denke das Lightning alles löst wenn Bitcoin in den kommenden Jahrzenten immer weniger stark schwankt. In den Schwellenländern benutzen sie Stablecoins, weil Bitcoin noch zu volatil ist würde ich behaupten - Nehmen wir also an, das Bitcoin konstant jährlich um ca. 10% flach steigt und alle Lightning für jegliche Transaktionen verwenden. Auch Lohnzahlungen. Wäre dann das Problem gelöst?

LG

1 „Gefällt mir“

Wahrscheinlich hätte ich besser nicht den Begriff „Stablecoin“ verwenden sollen. Viele assoziieren es doch mit Kryptowährung welche den US Dollar oder Euro abbilden. Ich meinte in dem Sinne stabil im Vergleich zum Bitcoin 1 BTC = 1 Stablecoin. Eine bessere Analogie wären vielleicht Pokerchips. Egal wie stark der Wert von Euro steigt oder sinkt, du bekommst immer die gleiche menge an Euro für deine Chips. Natürlich ist es so, dass der Stablecoin im Vergleich zum Euro nicht Wertstabil ist und die exakt gleichen Schwankungen vom Bitcoin mitmacht.

Ob Lightning die Silberkugel ist, die in allen Szenarios wirklich alle Skalierungshürden löst, bin ich eher noch skeptisch. Ich sehe halt, dass beim Lightning Network die Liquidität nicht mit skaliert. Was wäre wenn das Lightning Network für monatliche Lohnzahlungen nicht liquide genug ist?

Dazu folgendes Szenario:

Alice 1 BTC <-----> 1 BTC Bob 1BTC <-----> 10 BTC Charlie

Alice macht mit Bob einen Kanal auf und beide legen jeweils 1 BTC in den Kanal
Charlie macht mit Bob einen Kanal auf und legt 10 BTC hinein und Bob 1 BTC

Wenn Charlie jetzt 10 BTC als Lohn an Alice senden möchte, dann ist das über diese Route unmöglich.
Bob hat einfach nicht genügend Liquidität um es Alice zur Verfügung zu stellen. Jetzt hat Charlie 3 Möglichkeiten, entweder

  1. er macht eine on-chain Transaktion zu Alice
  2. er eröffnet einen eigenen Kanal mit Alice
  3. er sucht sich eine liquidere Route

z.B. hat David hat zum Glück noch einen Zahlungskanal mit Alice von 15 BTC

Alice 1 BTC <-----> 15 BTC David 1BTC <-----> 10 BTC Charlie

nach der Lightning Transaktion sieht es so aus:

Alice 11 BTC <-----> 5 BTC David 11BTC <-----> 0 BTC Charlie

Die höhere Liquidität Davids lässt er sich natürlich mit deutlich höheren Gebühren schmecken lassen.
Man könnte es Graphisch ungefähr so skizzieren:

Je mehr Bitcoins ich über Lightning versenden möchte, umso höhere Gebühren muss ich für eine Transaktion blechen, weil die Anzahl an liquiden Routen mit steigender Menge BTC geringer werden.
Bei Bitcoin ist es egal, welche Menge an BTC du versendest. Der Preis für die Transaktion bleibt gleich.
Über dem Schnittpunkt ist es dann sogar günstiger eine on-chain Transaktion durchzuführen.

Jetzt kommt es darauf an, wie teuer werden Bitcoin on-chain Transaktionen in Zukunft werden? Wenn es jetzt nur 50€, 100€ oder 200€ sind, dann wird man wahrscheinlich keinen weiteren Coin erschaffen.
In diesem Bereich wird genügend Liquidität im Lightning Network vorhanden sein.

Was wenn aber eine Bitcoin on-chain Transaktion 1000€, 2000€ oder vielleicht sogar 10.000 € kostet. Je näher wir uns dann dem Schnittpunkt nähern, umso illiquider und teurer werden das Lightning Transaktionen. Dann wird es eine Nachfrage nach alternativen kostengünstigeren Transaktionen geben. Mein Stablecoin könnte hier Abhilfe schaffen, da wir die Transaktionen einfach auf einer Sidechain absolvieren können. Wir können auf dieser sogar die Blocksize erhöhen.

Ich verstehe, dass es keine gute Idee ist, die Blocksize von Bitcoin zu erhöhen. Für Blockchains auf 2nd-Layer ist das mMn kein Problem. Selbst wenn der Pool zu schnell wächst, könntest du einfach dein Bitcoins auszahlen und zum nächsten Pool wechseln. Die Pools sind mit Bitcoin gedeckt sind und dadurch sind die Coins von 2 unterschiedlichen Pools gleich viel Wert.

Du musst dich gar nicht für eine Shard / Pool (whatever) entscheiden. Dadurch das beide durch Bitcoin gedeckt sind, sind die Coins exakt gleich viel Wert. Wie gesagt, wir müssen die beiden Netzwerke nicht geographisch trennen. Als Händler kann man beruhigt beide Coins annehmen. Bei einer Euromünze ist es doch auch egal, ob sie eine deutsche, spanische oder italienische ist.

Wie soll das gehen? Wenn der Händler nicht in deinem Shard ist, kann er deinen Coin nicht annehmen. Wenn er beide Coins annehmen soll, bräuchte er in beiden auch eine Wallet/Adresse. In diesem Fall gehen die „Vorteile“ immer mehr verloren, weil ja doch viele in mehreren Shards vorhanden sein müssten.

Ja gut, die Analogie war vielleicht etwas zu gewagt. Grundsätzlich entstehen aber für den Händler für das Aufsetzen einer weiteren Wallet selbst keine weiteren kosten. Der Vorteil von Pools ist, dass wir mehr Transaktionen in Sidechains auslagern können und dadurch den Main-Layer entlasten. Klar bekommt man nicht, dass gesamte Featurepaket, welches Bitcoin bietet. Dafür ist es eben deutlich günstiger. Für ein neues Handy greifen viele auch nicht zum iPhone Pro, sondern zu einer günstigeren Alternative auch wenn es nicht alle Features hat. Durch Marktmechanismen würden wir uns in einer Mitte treffen bzw. in einer optimalen Anzahl an Pools. Zu viele Pools und wir müssten mehr Transaktionen in verschiedenen Sidechains parallel machen, zu wenige und die Transaktionskosten für eine on-chain Transaktion wären zu hoch. Es würde mMn so vielleicht so 2 bis 4 Pools mit signifikanter Marktdominanz geben.

Ich denke halt, je nachdem wie viel eine Bitcoin Transaktion mal kosten wird, könnte es ökonomisch Sinn machen. Bei Transaktionskosten von ein paar hundert Euros wahrscheinlich nicht, aber bei mehreren tausend Euro vielleicht schon. Ich bin noch nicht ganz davon überzeugt, dass Lightning bei so hohen Transaktionskosten mit skalieren würde. Die Liquidität muss ja auch erst einmal bereitgestellt werden. Wie soll mir denn zum Beispiel jemand über Lightning 5.000€ senden, wenn ich nur einen Kanal mit 1.000€ habe?

Was du hier beschreibst ähnelt sehr dem was das Fedimint Projekt macht. Solltest du dir unbedingt mal ansehen.

Die grundsätzliche Problematik beim Bitcoin Skalieren ist die Menge an UTXO die überhaupt erzeugt werden können über einen gegebenen Zeitraum. Daran ändert leider auch Lightning nichts, es entfernt lediglich die Kaffee Transaktionen von der Blockchain und gibt dadurch etwas Kapazität frei.

Deshalb ist es eigentlich fast unumgänglich das Lösungen die Bitcoin weiter Skalieren Mechanismen bringen wo mehrere User einen UTXO teilen. Die Verwaltung dieser Unterteilung ist der Knackpunkt und das hat halt je nach Ansatz wieder verschiedene Trade-offs.

1 „Gefällt mir“

Die Kunst besteht nun darin das zentralisierte Konzept dezentral umzusetzen.

Genau da sehe ich das Problem.
Wie setzt man das jetzt um, ohne irgendwem vertrauen zu müssen? Wer besitzt die private keys zu der pool wallet auf der main chain?

Der Kommentar über die Fedimints von @ZPE ist da sehr gut. Da wird ansatzweise dein Vorschlag umgesetzt. Aber auch da gibt es Entitäten (wenn auch verschiedene), welche theoretisch die Kontrolle über die Coins haben.

1 „Gefällt mir“

Das interessante an fedimint ist ja dass es mit einer N von M multisig umgesetzt wird. Also wenn du zum Beispiel 4 von 6 hast, dann hast du 6 Parteien welche eine Node und den fedimint betreiben, davon müssten aber 4 kollaborieren um die Funds zu stehlen. Oder 2 können die Keys verlieren oder offline gehen.

Das sind schon recht interessante trade-offs. Zum einen bietet es einen recht krassen Schutz dagegen das du die Keys verlierst wo du bei einem eigenen Setup schon richtig kreativ werden musst dass du was vergleichbares hast. Zum anderen ist diese Sicherheit von der Wahl der Vertrauensparteien abhängig.

Vor allem ist das ganze Konstrukt in beliebigen Dimensionen implementierbar. Vom Haushalt über lokale Vereine bis hin zu Staaten.

Die Guardians die man da wählt welche die Keys haben könnte man zum Beispiel bei einem Staats Konstrukt so wählen dass die Keys über verschiedenste Interessensgruppen verteilt sind, die rein ideologisch nie miteinander kooperieren würden um die Funds zu stehlen.

Oder mehrere Banken könnten gemeinsam einen Fedimint betreiben, wodurch das ungemein sicherer wird als die Legacy Systeme welche die heute betreiben.

Jedenfalls ein komplett eigenes Rabitt Hole wieder zum sich drin verirren :slight_smile:

2 „Gefällt mir“

Interessantes Thema. Was ist mit Taro?
„It further optimizes how UTXOs are used by allowing multiple assets to be controlled by the same output, and aggregate multiple transactions into a single UTXO.“

Ich hatte mir das so vorgestellt, dass man es eventuell über multisig lösen könnte. Man hätte dann eine öffentliche Poolsignatur, die aber alleine nicht ausreicht, um irgendeine Transaktion durchzuführen. Und eine private eigene geheime Signatur. Zusammen verfügt man dann über genau so vielen Bitcoins vom Pool, wie man Stablecoins besitzt.