Zahlungskanäle mit dynamischen Signaturen

Es ist möglich, dass Alice und Bob untereinander vereinbaren, Carol und eine beliebige Anzahl anderer Empfänger zu bezahlen (vorbehaltlich der Beschränkungen der Transaktionsgröße). Es ist Carol und anderen zusätzlichen Empfängern jedoch nicht möglich, diese Zahlungen mit der gleichen vertrauenswürdigen Sicherheit zu erhalten, die Alice und Bob über das Zahlungskanalkonstrukt zur Verfügung steht.

Alice und Bob eröffnen einen Kanal, indem sie Gelder an eine Multisig-Adresse überweisen, die Unterschriften von beiden erfordert, um sie ausgeben zu können. Für Alice garantiert dies, dass ihre Zustimmung erforderlich ist, damit jede Transaktion, bei der das Geld ausgegeben wird, gültig ist. Bob erhält die gleiche Garantie, dass seine Zustimmung erforderlich ist.

Die Innovation bidirektionaler Zahlungskanäle (einschließlich, aber nicht ausschließlich der von Lightning Network verwendeten) besteht darin, dass jede Zahlung im Kanal von den Empfängern widerrufen werden kann, sodass eine nachfolgende Zahlung an ihre Stelle treten kann.

Die Belastung (Einlöseskript), die eine widerrufliche Zahlung schützt, ist größer als eine normale Bitcoin-Belastung, daher ist das wünschenswerteste Ende eines Zahlungskanals ein gegenseitiges Schließen, bei dem die letzte widerrufliche Zahlung widerrufen und in eine nicht widerrufliche Zahlung umgewandelt wird, die aussieht wie eine normale Bitcoin 2-von-2-Multisig-Ausgabe.

Der einzige bekannte Weg, wie widerrufliche Zahlungen funktionieren, besteht darin, dass jede Partei eine vollständige Liste aller jemals geleisteten Zahlungen hat und (falls sie widerrufen wurde), welche Daten zum Widerruf erforderlich sind. Dies verhindert, dass Carol die volle Sicherheit des Zahlungskanals hat.

Alice und Bob können sich gegenseitig darauf einigen, Carol zu bezahlen, und sie können Carol über diese Zahlung informieren. Wenn die Transaktion mit dieser Zahlung übertragen wird, erhält Carol ihr Geld. Aber da die Multisig-Adresse, an die die Gelder ursprünglich eingezahlt wurden, nur die gegenseitige Zustimmung von Alice und Bob erfordert, um andere Zahlungen zu erstellen, können sie andere Zahlungen im Geheimen von Carol erstellen.

Wenn eine der geheimen Zahlungen, die zwischen Alice und Bob erstellt wurden, übertragen wird, hat Carol nicht die notwendigen Daten, um auf der Blockchain zu beweisen, dass sie in betrügerischer Absicht getätigt wurde. Alice und Bob können somit im gegenseitigen Einvernehmen Carols Geld stehlen.

Eine konzeptionellere Betrachtungsweise besteht darin, sich die Blockchain als Vertrauensanker für Zahlungskanäle vorzustellen. Sie müssen ein gewisses Maß an Kontrolle über diesen Anker haben, damit Sie dem resultierenden Kanal vertrauen können. Alice und Bob haben das, weil ihre Zustimmung erforderlich ist, um den Anker zu verwenden; Carol hat keine Kontrolle über den Anker und kann ihm daher nicht vertrauen.

Das Hauptproblem, das ich dabei sehe, ist die erhöhte Komplexität und mögliche Absprachen zwischen 2 der 3 Parteien. Wenn Carol jetzt Aktualisierungen signieren muss, was tut Alice, wenn Carol nicht reagiert? Übertragen Sie ihre Rettungstransaktion, obwohl Bob ein reaktionsschneller Teilnehmer ist? Hat sie Rettungstransaktionen für Fehlverhalten von Bob und Carol? Was, wenn Bob und Carol konspirieren? Jetzt braucht sie Rettungen für jeden von ihnen, plus für dann kombiniert. Was passiert, wenn du Dave hinzufügst?

Alle diese Szenarien müssten abgedeckt werden, um das System vertrauenswürdig zu halten. Wenn Sie die Komplexität eines einzelnen Kanals erhöhen, skalieren Sie die potenziellen Probleme noch weiter. Es ist wahrscheinlich besser, die Kanäle selbst so einfach wie möglich zu halten und zu versuchen, über das Routing zu skalieren.