Author: Arman The Parman | Original Date: 3/03/23 | Translated by: Leon A. Wankum | What’s SegWit?
SegWit war ein Soft Fork, der 2017 eingeführt wurde. Damals gab es einen riesigen Krieg zwischen „großen Blockern“ und „kleinen Blockern“, aber darauf werde ich hier nicht eingehen. Für Interessierte siehe das Buch „The Block Size War“ von Jonathan Bier, eine faszinierende Geschichte.
Technisch gesehen war das Problem vor SegWit die Signature Malleability. Dies ist eine Eigenschaft einer Signatur, bei der eine geringfügige Änderung sie nicht von Natur aus ändert, z. B. das Hinzufügen führender Nullen. Das Problem dabei ist, dass es die Erstellung anderer Versionen derselben gültigen Transaktion ermöglicht. Die Identität einer Transaktion in der Blockchain stammt aus dem Hash der Transaktion, sodass zwei gleiche (aber unterschiedliche) Signaturen es ermöglichen, zwei verschiedene Transaktions-IDs für denselben UTXO zu erstellen, der ausgegeben wird.
Es kann nur einer in die Blockchain aufgenommen werden, denn wenn der andere nachträglich in einen Block aufgenommen wird, wäre dies eine doppelte Ausgabe und macht den Block ungültig. Das scheint kein großes Problem zu sein, da doppelte Ausgaben nicht vorkommen können, aber es ist ein Problem für die Funktionsfähigkeit des Lightning-Netzwerks. LN basiert auf einem Netzwerk von unveröffentlichten, von der Gegenpartei vorsignierten, gemeinsam genutzten Multisignatur-Rückerstattungstransaktionen (Lightning Channels), und doppelte Ausgaben (Rückerstattungen) machen die Salden im Netzwerk unsicher (einfach ausgedrückt). Dies erforderte eine Lösung, und die SegWit Soft Fork entstand. Und so entstand das Lightning Network.
SegWit steht für Segregated Witness, und „Witness“ auf Kryptographie-Cocktailpartys und in der Wissenschaft bedeutet Unterschrift. Aus dem Namen erhalten wir also einen Hinweis darauf, was es tut: Es „trennt“ den „Zeugen“ (dh die Unterschrift) von der Transaktion. Durch das Entfernen der Signatur wirken sich Anpassungen (Formbarkeit) nicht auf den Transaktions-Hash aus und es werden keine doppelten Transaktions-IDs für dieselben UTXO-Ausgaben erstellt.
Die Signatur wird jedoch nicht genau eliminiert, sie wird nur aus der Transaktion und der Blockchain entfernt. Es ist immer noch erforderlich. Wenn für diese Daten ein neuer Abschnitt auf dem Block zugewiesen würde, wäre dies in den Augen von Pre-SegWit-Bitcoin-Nodes ungültig. Das ist eine andere Art, rückwärts inkompatibel oder eine „Hard Fork“ zu sagen – dass ist ein großes Nein-Nein. Ein Teil des Bitcoin-Ethos ist, dass es nicht nötig ist, Veränderungen anzunehmen; alles ist optional.
Um diese Änderung optional zu machen und nicht inkompatibel mit älteren Nodes, dh einem „Soft Fork“, wurde ein cleverer „Trick“ verwendet. Ich werde es erklären, aber entschuldigen Sie bitte, wenn ich einige Ungenauigkeiten einschließe – ich bin kein Kryptograph, habe den Code nicht gelesen und ich erkläre, was ich aus einer Online- MIT-Vorlesung gelernt habe, aus der Erinnerung. Bei einer SegWit-Transaktion platziert ein Wallet eine „0“, wo alte Bitcoin-Nodes eine Signatur erwarten. Die älteren Nodes betrachten diese „0“ als gültige Signatur und lehnen die Transaktion nicht ab ('backwards compatibility' erreicht). Für die Segwit-Nodes ist dies ein Flagge, um zu signalisieren, dass sich die tatsächliche Signatur woanders befindet (getrennt). Für neuere Nodes ist ein weiterer Nachweis der Transaktionsgültigkeit erforderlich. Diese Daten werden in den Segwit-Daten gespeichert und von den Segwit-Nodes gemeinsam genutzt. Die Nodes prüfen hier Signaturen, bevor Transaktionen als gültig gelten. Die Blockchain-Größenbeschränkung bleibt bei 1 MB, aber die Segwit-Daten können bis zu 3 MB Daten für jeden zugehörigen Block enthalten.
Man könnte gegen diese „Trickserei“ Einwände erheben und behaupten, dass ältere Nodes tatsächlich „in Änderungen gezwungen“ werden – Auch wenn es potenziell unangenehm klingt, benachteiligt es tatsächlich nicht die älteren Nodes, die nicht an der Art und Weise teilnehmen möchten, wie Sie vielleicht denken. Es gab eine schleichende Zunahme der Datenmenge, die auf einer Node pro Block zu speichern ist (nicht die Blockchain an sich), aber ich verstehe, dass dies ein Kompromiss war, der gemacht wurde, um den Block Size War zu gewinnen und ein erhöhtes Risiko einer Hard Fork zu vermeiden.
Ein ältere Node kann weiterhin Legacy-Zahlungen (Adressen, die mit 1 beginnen) von jedem an seine eigene Legacy-Wallet akzeptieren, selbst wenn die Zahlung von einem Segwit UTXO (Adressen, die mit bc1q beginnen) stammt. Wenn die Zahlung ihre Adresse erreicht, betrachtet ihre eigene Legacy-Wallet dieses Guthaben als gültig. Beachten Sie jedoch, dass nie überprüft wurde, ob die UTXO-Kette Upstream wirklich gültig war (es wurden nur „0“-Signaturen geprüft, keine tatsächlichen Signaturen im SegWit-Datenblock). Auf diese Weise bleibt der Besitzer/in eine alten Node in der Sicherheit seiner/ihrer eigenen Regeln, kann aber andere nicht davon abhalten, dass zu tun, was sie wollen.
Value 4 Value | Tips:
Wenn Ihnen diese Übersetzung gefallen hat, würde ich mich über eine Wertschätzung in Form von Satoshi an law@getalby.com freuen.
Sie können mir ausserdem auf Twitter folgen oder meine Homepage besuchen.
Nostr: npub1v5k43t905yz6lpr4crlgq2d99e7ahsehk27eex9mz7s3rhzvmesqum8rd9
Leon A. Wankum
Bitcoin. Real Estate. Philosophy & Ethics. ⚡law@getalby.com npub1v5k43t905yz6lpr4crlgq2d99e7ahsehk27eex9mz7s3rhzvmesqum8rd9
follow me :
Related Posts
Rabbit fragt #17
Aug 28, 2024
Der Bitcoiner in der Midlife-Crisis
Jun 14, 2024
Rabbit fragt...#16...Was ist eine Hardware Wallet?
May 26, 2024