Programmierbares Geld: CSV per Softfork aktiviert

In Block 419.328 wurde Check Sequence Verify (CSV) per Softfork aktiviert. CSV erlaubt es, Bitcoins für einen bestimmten Zeitraum “einzufrieren” und ermöglicht damit ganz neue Arten von Verträgen. Die Kryptowährung wurde damit ein Stückchen smarter.

Bitcoin Core 12.1 war und ist ein sehr spezielles Update. Nach dem “Mega-Release” Core 12.0, der unter anderem eine neue Library für die Signaturen sah, wartete 12.1 mit unscheinbaren, aber komplexen Änderungen und gleich mehreren Softforks auf. Eine Softfork bedeutet, dass die Konsens-Regeln geändert werden, jedoch in einer Weise, die für Nicht-Miner abwärtskompatibel ist. Das bedeutet, dass nur die Miner zustimmen müssen, damit die Änderung aktiviert wird, und Knoten nur updaten müssen, wenn sie die Änderung benutzen wollen.

Den Anfang machte BIP9 – eine Softfork, die es erlaubt, dass die Miner über die Version Fields der Blöcke künftig nicht mehr nur noch über eine, sondern über 28 Softforks gleichzeitig abstimmen können. Dies soll Bitcoin eine deutlich größere Flexibilität geben, um in Zukunft mehr neue Features freizuschalten. “Mit Soft Forks kann alte und neue Software im Netzwerk koexistieren,” so die Core-Entwickler auf ihrer Webseite, “Soft forks können neue Features ohne Disruption einführen, weil die User, die upgraden wollen, upgraden können, während es den anderen freisteht, wie bisher weiter zu machen.” Aus diesen Gründen bevorzugt Core bis auf wenige Ausnahmen Softforks vor Hardforks.

Während BIP9 dieses Instrument der Softforks also flexibler gemacht hat, stellt Check Sequence Verify (CSV) die erste Softfork dar, die durch BIP9 aktiviert wurde. Die CSV-Softfork ändert dabei nicht nur eine, sondern drei Konsens-Regeln und beruht dementsprechend auf den drei Bitcoin Improvement Proposals (BIP) 68, 112 und 113. Nachdem bereits vor 13 Tagen genügend Miner zugestimmt haben, dass die Softfork aktiviert wurde, geschah dies nun. Damit ist CSV im Netzwerk aktiv.

Was macht CSV aber nun? Um dies zu verstehen, muss man wissen, dass Bitcoin-Transaktionen eine Skriptsprache benutzen. Eine ganz normale Transaktion überweist oberflächlich Geld an eine bestimmte Adresse, setzt aber unter der Haube in ein Output-Skrip die Regel, dass dieser Output nur durch eine Transaktion ausgegeben werden kann, die mit dem privaten Schlüssel einer bestimmten Adresse signiert ist. CSV erweitert nun diese Skriptsprache und ermöglicht es, das Sequenz-Feld einer Transaktion zu nutzen, um von Transaktionen ein bestimmtes “Alter” zu fordern, bevor diese ausgegeben werden können. So kann man etwa definieren, dass eine Transaktion 1000 Blöcke – etwa eine Woche – alt sein muss, bevor der Empfänger mit dem empfangenen Geld woanders bezahlen kann.

Und was bringt das? CSV ist ein Instrument, um mit Bitcoins verschiedene Verträge zu bilden, die vorher nicht möglich waren. So ist es beipielsweise möglich, eine Multisig-Transaktion zu bilden, die für die ersten 30 Tage von zwei Personen signiert werden muss und danach nur noch von einer. Dies kann eine Art Rettungsanker sein, um die Bitcoins zu bergen, wenn der Multi-Sig Partner stirbt oder die Schlüssel verliert.

Vor allem aber erlaubt CSV die vom Lightning-Netzwerk vorgeschlagenen Konstruktionen, in denen eine Transaktion zurückgenommen werden kann. Eine ausführliche Erklärung findet ihr in diesem Artikel, hier nur soviel: Indem man mit CSV eine Transaktion für einen bestimmten Zeitraum einfriert, kann es möglich sein, ihren Inhalt unter bestimmten Bedingungen umzubiegen und sie damit rückgängig zu machen. Bidirektionale Payment-Channels können damit Betrug verhindern.

Auch für Sidechains ist CSV wichtig. Sidechains meint, dass man Bitcoins von einer Blockchain auf eine andere überträgt, indem sie auf einer bestimmten Adresse eingefroren werden. Trotz der zahlreichen ungeklärten Fragen rund um Sidechains hat das Konzept das Potenzial, die Skalierbarkeits-Probleme auf andere Chains zu übertragen, Transaktionen zu beschleunigen oder zu anonymisieren und mit den verschiedensten Smart Contracts zu experimentieren, ohne die Mainchain des Bitcoins in Gefahr zu bringen.

Für den “normalen” User wird CSV vorerst vermutlich so gut wie keine Bedeutung haben. Die wenigsten Wallets sind im Allgemeinen dafür gerüstet, mit den erweiterten Skriptoptionen umzugehen, weshalb bislang auch noch eine einfach zu bedienende Implementierung von Multisig und P2SH-Transaktionen fehlt. Es ist aber hoffen, dass die Anbieter von Wallets CSV nutzen, um beispielsweise Adressen bzw. Transaktionen so zu konstruieren, dass Bitcoins im Normalfall nur gesendet werden können, wenn sowohl Wallet-Anbieter als auch User signieren, der User aber die Option hat, nach Ablauf einer bestimmten Zeit seine Guthabe ohne Hilfe der Wallet-Anbieter zu versenden. Dies würde die Sicherheits von etwa Online-Wallets erheblich erhöhen, während es dem Betreiber keinerlei Möglichkeit gibt, Bitcoins zu stehlen oder zu verlieren.

About Christoph Bergmann (959 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Jeder Satoshi wird dazu verwendet, um das Blog besser zu machen. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

9 Comments on Programmierbares Geld: CSV per Softfork aktiviert

  1. Das liest sich ja schonmal nicht schlecht.

    Solange es mit Softfork funktioniert ohne unvorhersehbare Folgen einer Hardfork, um der Skalierbarkeit Herr zu werden.

    mfg

  2. Nattydraddy // 5. July 2016 at 19:33 // Reply

    Es ist ein Softfork mit unvorhersehbaren Folgen.

    Ein Transaktion wird erst in der Zukunft gültig. Wenn in der Zwischenzeit aber die “Skriptsprache” ändert, wird die Transaktion in der Zukunft nicht gültig. Und die “Skriptsprache” ändert sich momentan mit jedem Update.

    Wenn ich z.B. wie vorgesehen einen Kanal im Lightning Network öffne, der für ein halbes Jahr geöffnet bleibt, dann kann es mir passieren, dass innerhalb dieses halbes Jahres die CSV-Transaktion unausführbar wird. Dass heißt, ich bekomme dass Geld aus dem Lightning Network nicht zurück.

  3. Nattydraddy // 5. July 2016 at 20:03 // Reply

    Dank des letzten Softforks können Transaktionen geändert werden, solange sie noch nicht eingeblockt wurden. Macht ja nichts, wartet man halt, bis eine Bestätigung für die Transaktion vorliegt.

    Mit diesem Softfork werden jetzt Transaktionen erstellt, die erst in ferner Zukunft eingeblockt werden. Halt am in der Transaktion angegebenen Zeitpunkt bzw. Blockhöhe. Hört sich unsinnig an, liegt aber daran dass es ein Softfork ist:
    https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
    This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
    Motivation:
    Bitcoin transactions have a sequence number field for each input…
    The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in Hashed Timelock Contracts (HTLCs) and BIP112.

    Das heißt: Ich überweise Geld, dass eingefroren bleibt, bis die Zielkonditionen erreicht sind. Während dieser Zeit ist die Transaktion nicht eingeblockt. Durch den letzen Softwork haben wir gelernt, unbestätigten Transaktionen nicht mehr zu trauen. Jetzt sollen wir andauernd CSV-Transaktionen machen, die lange Zeit unbestätigt bleiben. Pro eröffneten Kanal im Lightning Network steigt mein Blutdruck um 5 mm Hg. Spätestens mit der Eröffnung von Sidechains ist mir der Herzinfakt sicher<3

    • Zu unbestätigten Transaktionen siehe Segregated Witness:
      “Segwit prevents third-party and scriptSig malleability by allowing Bitcoin users to move the malleable parts of the transaction into the transaction witness, and segregating that witness so that changes to the witness does not affect calculation of the txid.”
      https://bitcoincore.org/en/2016/01/26/segwit-benefits/

      Das Lightning Network auf privaten Servern gefällt mir auch nicht… Aber sowas über Sidechains abzuwickeln macht die Sache schon interessanter. Sicherer, entlastet die Bitcoin Blöcke Bitcoin kann (länger mit 1MB Blöcken auskommen – was absolut anzustreben ist). Bitcoin werden eingefroren, und landen in der Sidechain. Dort können Sie munter weitergehandelt werden – kostengünstiger, schneller und auch in kleinen Mengen. Wer will, kann seine Coins in die echte Bitcoin Blockchain zurück übertragen – die eingefroren BitCoins werden wieder freigegeben und auf seine Wallet übertragen. Jetzt nicht mehr so schnell, nur Mittels einer höheren Gebühr zu überweisen, also nicht mehr für Microtransactions geeignet – aber Bombensicher.

      • Hm … ja … was ich mich immer frage ist, wer aus welchen Gründen Sidechains beminen soll … wäre es nicht möglich, Ethereum als Sidechain zu verwenden? Mit den Smart Contracts und der BTCBridge dürfte es möglich sein, es zu erkennen, wenn BTC eingefroren sind …

      • Nattydraddy // 6. July 2016 at 15:19 //

        “Zu unbestätigten Transaktionen siehe Segregated Witness”
        Das regelt aber nur das Problem mit der “malleability”, also das Transkationen eine neue ID bekommen, wenn sich etwas bei den Signaturen ändert.

        “Wer will, kann seine Coins in die echte Bitcoin Blockchain zurück übertragen – die eingefroren BitCoins werden wieder freigegeben und auf seine Wallet übertragen.”

        Eingefroren heißt bei den betroffenden Transaktionen, dass sie im Mempool verbleiben, bis die Bedingungen für ihre Ausführung erfüllt sind. Diese Bedingungen werden dur die Opcodes der “Skriptsprache” bestimmt. Dieses Opcodes werden aber andauernd geändert und neue hinzugefügt. Wenn mit CSV Transaktionen erst in der Zukunft ausgeführt werden, sollten Opcodes nicht mehr geändert werden, damit die Transaktion ausführbar bleibt. Aber wär garantiert mir, dass Opcodes nicht mehr geändert werden?

  4. Ich verstehe nur “Bahnhof”, und habe auch gar keine Lust, mich da groß einzuarbeiten – aber irgendwie hört es sich hier so an, als ob es nur die Möglichkeiten gäbe, dass die Bedingungen erfüllt und die Transaktion ausgeführt wird, oder eben nicht, und dann bleibt sie eingefroren. Aber bleibt die Transaktion dann für immer eingefroren (so hört es sich hier an), oder wird sie rückgängig gemacht und die Bitcoins gehen wieder an den Absender zurück?

    • Nattydraddy // 12. July 2016 at 13:10 // Reply

      “Aber bleibt die Transaktion dann für immer eingefroren (so hört es sich hier an), oder wird sie rückgängig gemacht und die Bitcoins gehen wieder an den Absender zurück?”

      Die Bitcoins stehen wieder denm Absender zur Verfügung, wenn das in der Transaktion so einprogrammiert ist. Und der Programmcode von der aktuell laufenden Bitcionversion akzeptiert wird.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s