Bitcoin Cash: Hardfork im Mai wird Schnorr-Signaturen aktivieren

Kaum hat sich der Staub um die Hardfork im vergangenen November gelegt, stellt Bitcoin ABC die nächste Hardfork für Bitcoin Cash vor: Am 15. Mai werden Schnorr-Signaturen aktiviert und es wird ein Bug der letzten Hardfork ausgemerzt. Anders als im vergangenen Jahr gibt es nicht nur keinen Streit um die Fork, sondern nicht einmal eine Diskussion.

Es ist herrlich, wenn all die Neinsager und Querköpfe weg sind. Die Entwickler von ABC, die noch im vergangenen November wegen ihrer Hardfork-Pläne unter erheblichen Druck geraten sind, konnten sich nun in Ruhe und Frieden auf einen Weg vorwärts einigen und diesen auch ohne Geschrei und Diskussion umsetzen. Am 15. Mai wird Bitcoin Cash (BCH) erneut eine Hardfork aktivieren. Diese wird allerdings nur zwei Features enthalten: Schnorr-Signaturen und die Rettung von Coins, die versehentlich an SegWit-Adressen gesendet worden sind.

Schnorr als Alternative

Der aufregendste, aber auch komplizierteste Teil der Hardfork sind Schnorr-Signaturen. Der Schnorr-Algorithmus gilt weithin als Verbesserung des von Bitcoin verwendeten ECDSA-Signaturalgorithmus. Wie dieser beruht er auf einer elliptischen Kurve. Er wurde Anfang der 90er vom deutschen Mathematiker Claus-Peter Schnorr entwickelt und patentiert. Das Patent lief jedoch 2008 ab, womit Schnorr rechtlich unbedenklich benutzt werden kann.

Die Firma Blockstream plant schon seit einigen Jahren, Schnorr für Bitcoin zu aktivieren. Nun scheint es jedoch, als käme (ausgerechnet) Bitcoin Cash ihnen zuvor. Es gibt einige Gründe, weshalb Schnorr-Signaturen für Kryptowährungen reizvoll sind: Erstens sind sie ein Stückchen schneller. Zweitens erlauben sie es nativ, mit mehreren Schlüsseln zu signieren, womit sich Multisig-Adressen nicht länger durch die verdächtige „3“ am Anfang verraten. Drittens sind sie von Natur aus resistent gegen Malleabilität. Und viertens ist es möglich, mit Schnorr Signaturen zu verschmelzen, womit eine Transaktion, die aus mehreren Inputs besteht, nicht mehr jede Signatur von jedem einzelnen Input separat mitführen muss. Kurzum: Schorr kann die Skalierbarkeit und die Privatsphäre verbessern, während die Beseitigung der Malleabilität für Bitcoin Cash den Weg zum Lightning-Netzwerk freimacht.

Bei der Implementierung übernimmt Bitcoin ABC im Kern die kryptographische Spezifizierung und Arbeit des Bitcoin-Core-Entwicklers Pieter Wuille. In der konkreten Umsetzung unterscheidet sich die Version von ABC aber stark von der, die Bitcoin Core plant. Ein Vorteil von Schnorr ist dabei, dass es gar nicht so viel anders ist als das bisher verwendete ECDSA: Indem man dieselbe elliptische Kurve secp256k1 benutzt, ist ein ECDSA-Schlüsselpaar auch ein Schnorr-Schlüsselpaar. Privater Schlüssel und Adresse können also gleich bleiben, es ändert sich nur der Vorgang, eine Signatur zu erstellen und zu prüfen. Der Code, um Signaturen zu prüfen, wird dabei so modifiziert, dass er erkennt, welche Art von Signatur vorliegt.

Damit wird es möglich, die neuen Signaturen langsam und relativ undisruptiv einzuführen. Wallets können bleiben, wie sie sind, aber haben auch die Möglichkeit, Schnorr-Signaturen zu benutzen. Langfristig wird es, so die Spezifizierung, sogar möglich, ECDSA vollständig zu entfernen, ohne dass dabei Adressen und Schlüssel blockiert werden. Diesen Vorteilen steht ein theoretischer Nachteil gegenüber – wenn einer der beiden Algorithmen gebrochen wird, sind auch Schlüssel, die diesen nie verwendet haben, kompromitiert.

Zunächst wird Schnorr nur als einfache Signaturoperation eingeführt. Das Verschmelzen der Input-Signaturen wird soweit ich es sehe nicht unterstützt, wie auch Multisig noch nicht Schorr-fähig ist. Damit sind die beiden stärksten Vorteile von Schnorr auch nach der Hardfork noch nicht verfügbar. Was bleibt ist eine geringe Reduktion der Signaturgröße sowie die Beseitigung von „Third-Party-Malleability“, was es möglich macht, Bitcoin Cash ans Lightning-Netzwerk anzubinden.

Rettung für verlorene Coins

Das zweite Element der Mai-Hardfork ist die Bergung von Coins, die an SegWit-Adressen gesendet wurden. Auch dieses Problem ist relativ komplex zu beschreiben. SegWit-Adressen sind ja P2SH (Pay-to-Script-Hash)-Adressen, die offiziell unter „Anyone can spend“ laufen: Jeder kann die Coins auf ihnen ausgeben. Hinter diesem Skript erkennen Nodes und Miner, die das SegWit-Update mitgemacht haben, jedoch ein Skript, das weiterhin eine Signatur verlangt. Wenn eine Kryptowährung wie Bitcoin Cash allerdings kein SegWit kennt, und ein User versehentlich Coins auf eine SegWit-Adresse sendet – etwa weil er die Wallet verwechselt – dann können die Coins quasi von jedem, der sie erkennt, ausgegeben werden.

Bisher war es in solchen Fällen möglich, einen Miner zu bitten, die Coins zu bergen, indem er eine „Nicht-Standard-Transaktion“ gemacht hat. Das war aufwändig und hatte seinen Preis – aber brachte immerhin die Coins zurück. Seit der November-Hardfork ist dies aber nicht mehr möglich. Die ABC-Entwickler haben versehentlich einen Bug eingeführt, der die Transaktion der Miner vollständig ungültig gemacht hat, womit alle Bitcoin Cash, die an SegWit-Adressen gesendet wurden, effektiv eingefroren sind. Mit der Hardfork im Mai soll es nun wieder möglich werden, solche Transaktionen zu bilden.

Es ist zu erwarten, dass die Hardfork reibungslos über die Bühne geht. Eine Diskussion der Features, die diesen Namen verdient, fand und findet nicht statt. Jeder scheint einverstanden zu sein und zu akzeptieren, dass der Release von Bitcoin ABC, der die Hardfork aktiviert, definiert, was Bitcoin Cash ist. Bitcoin Unlimited, im November noch hin- und hergerissen zwischen den beiden Fronten ABC und SV, scheint bereit zu sein, ABC widerspruchslos zu folgen.

Über Christoph Bergmann (1874 Beiträge)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Christoph hat vor kurzem ein Buch geschrieben: Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes. Das Buch stellt Bitcoin in seiner ganzen Pracht dar. Ihr könnt es direkt auf der Webseite Bitcoin-Buch.org bestellen - natürlich auch mit Bitcoin - oder auch per Amazon. Natürlich freuen wir uns auch über Spenden in Bitcoin, Bitcoin Cash oder Bitcoin SV an die folgende Adresse: 1BergmanNpFqZwALMRe8GHJqGhtEFD3xMw. Wer will, kann uns auch Hier mit Lightning spenden. Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Wer dies privat machen möchte, sollte meinen PGP-Schlüssel verwenden.

12 Kommentare zu Bitcoin Cash: Hardfork im Mai wird Schnorr-Signaturen aktivieren

  1. BCash + Lightning ist doch hoffentlich eine Erfindung von dir?

      • Das kommt jetzt überraschend, hast du eine Quelle?

      • Two new features are coming to Bitcoin Cash soon, hopefully in the May 2019 upgrade. I’d like to take the time to explain why I’m so excited about them. In short, we will be able to do:

        • Payment channels hidden as ordinary payments.
        • Atomic swaps hidden as ordinary payments.
        • Lightning-style payment channel networks too, if we want.
        • Secure chains of unconfirmed transactions involving multiple parties (layer 2).

        That all may sound incredible, and I’m going to explain in this document how it is so.

        Mark B. Lundeberg, 2019 Jan 29 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

        Contents

        The upgrades

        The two important planned features for the May 2019 upgrade are: 1) complete the BIP62 malleability restrictions, and 2) allow users to spend using Schnorr signatures in place of ECDSA signatures. Why is this a big deal?

        • No more third-party malleability: By completing the BIP62 malleability fixes, it will be possible to make P2PKH-spending transactions that cannot be malleated by any third party (miners, relay nodes, etc.). This removes the need for OP_CHECKLOCKTIMEVERIFY timeout clauses. We can also engineer smart contracts to be immune from malleability.
        • Hiding as P2PKH: Schnorr signatures allow very simple multi-party aggregation schemes, where multiple parties collaborate to produce one aggregated signature under one aggregated pubkey, checked with OP_CHECKSIG as in pay-to-public-key-hash (P2PKH) addresses.
        • Avoid second-party malleability: Schnorr signatures cannot be malleated at all, even in the aggregated case, except when all signers collaborate to create a new signature from scratch.

        Each of these three aspects is a significant upgrade. Together, however, they make up a massive upgrade: we will be able to make multi-signature transactions, which are not malleable by third parties or unilaterally by a subset of signing parties. This creates the perfect conditions for doing complex off-chain smart contracting. And best of all, those multi-signatures will appear on the blockchain as P2PKH, i.e., indistinguishable from regular payments. Altogether, it’s a simpler and more private replacement for complicated ‚malleability fix‘ transaction formats like segwit.

        Better payment channels

        Review – OP_CLTV payment channels:
        One of the most basic smart contracts possible on Bitcoin Cash right now is the standard monodirectional payment channel from Alice->Bob, where Alice funds a script with the following pseudocode:

        Unlock if Alice and Bob both sign, or,
        Unlock if only Alice signs, but provided the transaction is mined after a certain minimum refund timeout.
        

        Alice and Bob can collaborate together so that Bob can create a ‚channel update‘ transaction under the first condition, which sends some funds to Bob, and some funds back to Alice as change. They can make an unlimited number of updates, increasing the payment to Bob every time. When they’re done, Bob just publishes the last update. If Bob becomes unresponsive, Alice knows she can get a refund after a certain timeout period, using the refund clause. The refund clause requires OP_CHECKLOCKTIMEVERIFY (OP_CLTV), activated in 2015, and so these are called OP_CLTV payment channels.

        Unfortunately the above custom script is very obvious on the blockchain. While the two parties involved may be pseudonymous, it is obvious to any blockchain analyst that a payment channel was created and closed.

        Review – Spilman payment channels:
        Prior to the introduction of OP_CLTV, a simpler approach called Spilman payment channels was considered. This simply used a 2-of-2 OP_CHECKMULTISIG between Alice and Bob, but where Alice and Bob signed a time-locked refund transaction ahead of time, before Alice funded the channel. Unfortunately, Spilman channels are currently insecure on BCH due to malleability: Bob can ask a miner to change the txid of Alice’s funding, which would then invalidate the refund and allow Bob to hold all the payment channel funds ransom, indefinitely.

        New hidden payment channels:
        The BCH upgrades change this story. Not only can we use Spilman channels, but they don’t even need to use OP_CHECKMULTISIG and can instead be done with regular P2PKH addresses:

        • Spilman channels will be secure due to BIP62 malleability restrictions. Only Alice can malleate her funding transaction, and this would only hurt herself.
        • The Spilman channel’s 2-of-2 multisignature (OP_CHECKMULTISIG) can be done using an aggregated signature (OP_CHECKSIG).

        I’ll repeat that for emphasis: we will be able to do payment channels which merely use P2PKH — completely indistinguishable from ordinary transactions.

        Schnorr-Spilman payment channels protocol

        The process in detail:

        • Setup:
          • Alice and Bob generate private keys and an aggregated public key (A+B) with some P2PKH address.
          • Alice creates and signs a funding transaction that creates a coin C at the above address. Alice withholds the signed transaction, but she shares the parameters of coin C (txid, value, and scriptPubKey) with Bob.
          • Alice now creates a refund transaction which spends C back to herself, with nLockTime set to a future date.
          • Alice and Bob work together to sign the refund transaction. Alice keeps a backup of this refund transaction, and Bob makes a note of its refund time (nLockTime).
          • Alice now publishes the funding transaction.
          • Alice and Bob now wait for the funding transaction to confirm on chain.
        • Payments:
          • Alice and Bob create an unsigned transaction that spends C, with part sent to an address controlled by Bob, and the remainder refunded to Alice.
          • Alice and Bob interactively generate a signature, but crucially at the last step, Bob does not share the final signature with Alice and keeps it secret.
          • This can be repeated an unlimited number of times, provided the amount sent to Bob increases monotonically.
        • Closure (normal):
          • Bob chooses the most recent payment transaction (the one with most funds sent to him) and publishes it.
        • Closure (abnormal):
          • Once nLockTime is reached, Alice can publish the refund transaction, which sends all funds back to her.

        Graphical illustration

        To illustrate the distinction between CLTV payment channels and Schnorr-Spilman channels, I’ve created the following figures.
        In these figures,

        • dashed transactions and addresses show paths that are prepared off-chain, but normally do not get published;
        • solid lines show the normal path of transactions that does get published on-chain; and
        • I’ve highlighted P2SH outputs in pink since they stand out so obviously, i.e., they have a low anonymity set.
        • For simplicity, I’ve just put „A“ and „B“ for Alice and Bob however it should be understood that they use a new public key for every step of the process, both for security and privacy reasons.

        In the normal CLTV payment, the payment channel coin (the pink box) itself is obvious.

        CLTV payment channels

        Fig 1: CLTV payment channels.

        With a regular Spilman channel, this gets a bit better but the payment channel coin is still locked in a P2SH script, for a 2-of-2 multisignature. I didn’t illustrate this, but you can imagine the above but „A & B“ inside the pink box.

        When we move to Schnorr-Spilman channels, the payment channel coin is now an aggregated signature on Alice and Bob’s public key, represented here as „A+B“. Instead of the refund transaction being created by Alice alone, it is instead arranged ahead of time by Alice and Bob together.

        Schnorr-Spilman channels

        Fig 2: Schnorr-Spilman channels.

        Hidden atomic swaps (+ high frequency microswapping)

        In a previous gist, I described how trustless cross-chain atomic swaps can be hidden inside payment channels. They have an additional advantage over normal swaps in that they are faster to set up, and allow for instant high frequency trades between the involved parties.
        The same thing can be done with Schnorr-Spilman payment channels, at least on the BCH side of the swap.
        I’ve continued the illustration theme from above with Fig 3 below, to show how this works.

        On the top you can see a Schnorr-Spilman channel on BCH. On the bottom is a CLTV payment channel on OtherChain (this could also be a 2-of-2 Lightning, Taproot, or Raiden channel).

        In the case of a normal closure, the dashed objects do not land on chain, and so the BCH atomic swaps are entirely hidden behind P2PKH transactions on the BCH chain. In the case of abnormal closure, the fancy smart contracts do land on chain.

        Ideally, both chains should use such concealed P2PKH payment channel, but this is not absolutely needed for privacy. Even if the other chain uses a more obvious form of payment channel, it is very difficult to find the corresponding BCH transaction.

        Atomic swaps in Schnorr-Spilman channels

        Fig 3: atomic swaps can be concealed in Schnorr-Spilman channels.

        Hidden bidirectional payment channels

        It should also be possible to do Poon-Dryja (i.e., Lightning-style) payment channels that rely on punishment-style refund transactions. Chris Pacia hinted on Medium about how this will be secure once BIP62 activates. Note that there is a limitation, insofar that these payment channels have to be unilaterally funded (see Caveat section below).

        Again, there is an advantage with Schnorr signatures in that the initial 2-of-2 multisignature can be hidden as a 2-of-2 Schnorr aggregate signature. The refund smart contracts will only land on chain in the case of an uncooperative closure.

        I’ll skip showing a figure of this setup as it gets quite a bit more complex than regular payment channels, and it is not the point of this article.

        Layer 2

        In the preceding sections we have only exploited the BIP62’s third-party malleability fixes and the possibility to hide multisignatures through aggregation. If you recall however, the introduction mentioned a third point: Schnorr signatures cannot be malleated, except when the all signers involved collaborate to create a new signature.

        The fact that an aggregated Schnorr signature cannot be malleated by any strict subset of the parties means that we can build layer 2 (e.g., lightning network) on BCH.

        Securing unconfirmed transaction chains

        With third party malleability fixes alone, regular OP_CHECKMULTISIG multisignatures are unfortunately still malleable by any of the involved parties. They can simply create a new signature using a new nonce value, varying the sighash type, and so on. This is a problem for chains of unconfirmed transactions, such as in the following example.

        Alice enters into a two-stage smart contract with Bob, for simplicity shown here as simple „A&B“ which represents a 2-of-2 OP_CHECKMULTISIG. Let’s say she builds tx2 and tx3 together with Bob, before she reveals tx1. Bob cannot malleate tx1 (due to BIP62 protection) and Alice has no motive to malleate her own transaction. So, tx1 is safe. With tx2 it is different: one of the signatures (from Bob) can be manipulated. This creates a new transaction (tx2′), whose output Y‘ is now distinct in transaction ID from the original intended output Y. If tx2′ is confirmed instead of tx2, then the tx3 that Alice and Bob created is now useless since it spends a nonexistent coin Y, and it cannot spend Y‘. Unfortunately, Bob does have an incentive to do this: he can hold Alice’s funds (Y‘) ransom indefinitely.

        Insecure transaction chains using multiple signatures

        Fig 4: long transaction chains involving multiple signatures can be malleated by any of the involved parties.

        With Schnorr aggregate signatures, Bob can’t make that crucial step of changing the signature on his own. The reason has to do with the strong mathematical structure of Schnorr signatures (r, s):

        • For every r there is a unique s value that produces a valid signature.
        • Therefore, the creation of a new signature (distinct r or s) requires changing r to some other r‘.
        • The r value is hash-committed into e=H(r|m) which is necessary to check the validity of s. The new value is e‘.
        • With a new e‘, Alice’s contribution to s is now useless in calculating the correct new s‘.
        • Bob therefore would have to create a new contribution from Alice, which would be equivalent to forging a signature from her key.
        • Thus, a distinct signature can only be created by starting the entire signing process over again, including Alice’s cooperation. Alice would of course only want do this if she has first secured a new tx3′.

        Secure transaction chains using aggregate signatures

        Fig 5: long transaction chains involving aggregate Schnorr signatures are unmalleable.

        Making unmalleable smart contracts

        Once BIP62 activations are done, it’s possible to write smart contracts whose scriptSig inputs cannot be malleated. This may require some care, for example with OP_IF clauses, however I’d node that additional restrictions like SCRIPT_VERIFY_MINIMALIF are not necessary to make non-malleable clauses. I strongly suspect that in all cases, it is easy to convert complex smart contracts into a non-malleable form under BIP62+Schnorr alone. This can be done with input sanitization or script tweaks to take advantage of NULLFAIL (see link).

        Caveat: difficulties with order-of-signing and backup transactions

        One of the difficulties with BIP62+Schnorr is the order of signing. Consider the following order of operations necessary in BIP62+Schnorr to create a new transaction spending from the Alice+Bob pubkey, along with its backup transaction:

        1. Alice creates unsigned tx1 and gives to Bob.
        2. Alice and Bob sign tx1 but at the end, Alice withholds her s value. She keeps tx1 secret but calculates and shares txid1.
        3. Alice creates unsigned tx2 — the backup transaction which spends from txid1.
        4. Alice and Bob sign tx2.
        5. Once Alice has tx2, she can reveal tx1 to Bob.

        The problem here is that at the end of step 2, Alice is in possession of a fully signed tx1 before Bob has tx2. It’s not possible to reverse the ordering since tx2 must include the txid of the fully signed tx1. Thus, tx1 and the order of signing have to be carefully designed, so that the party holding the fully signed tx1 (Alice in this case) cannot harm other parties by publishing it before tx2 is created. This a particularly serious concern for smart contracts involving more than two parties.

        A simple tweak like SIGHASH_NOINPUT would be an elegant fix to this problem, as it allows tx2 to be signed before a fully signed tx1 exists. SIGHASH_NOINPUT has other advantages too, for example it would also allow simplified Layer 2 structures like Eltoo’s floating transaction mechanism, which doesn’t have punishments and doesn’t accumulate toxic information. But, that is a topic for another article…

        Differences from segwit

        The BIP62 + Schnorr approach to layer 2 has some advantages and disadvantages compared to segwit:

        • Our Schnorr signatures require only a very tiny change in wallet code, which means wallet developers can rapidly transition to Schnorr and drop support for ECDSA entirely.
        • With BIP62+Schnorr, smart contract authors must take a more thoughtful approach to prevent malleability, but this is easily accomplished.
        • Segwit makes a total of 66 different kinds of address — besides the two legacy address types (p2pkh, p2sh), each of the 16 segwit versions has 4 address types (p2wpkhv0, p2sh-p2wpkhv0, p2wshv0, p2sh-p2wshv0, p2wpkhv1, p2sh-p2wpkhv1, p2wshv1, p2sh-p2wshv1, … p2wpkhv15, p2sh-p2wpkhv15, p2wshv15, p2sh-p2wshv15). Our Schnorr approach only modifies one legacy address class (p2pkh). For privacy reasons, it is desirable to have as few address types in use as possible, so as to not fracture the anonymity set.
        • Backup transactions are easier to set up with segwit, especially in the multi-party case.

        Lightning network

        Since BIP62 + Schnorr allows Layer 2 constructions, this means a Lightning network should be possible on BCH. Although direct peer-to-peer on-chain transactions and direct payment channels are the primary use case for bitcoin cash, it wouldn’t hurt to have a low-value Lightning network for micropayments in situations where direct payment channels could not be set up ahead of time.

        view raw
        bip62_and_schnorr.md
        hosted with ❤ by GitHub

      • Also keine Quelle oder wie ist der leere Post zu interpretieren?

      • erscheint der Post bei dir leer?
        Hier der Text von Mark Lundenberg auf Github: https://gist.github.com/markblundeberg/a3aba3c9d610e59c3c49199f697bc38b

        Falls du ihn (warum auch immer) nicht siehst, die Route vor und hinter dem Link entfernen: #https://gist.github.com/markblundeberg/a3aba3c9d610e59c3c49199f697bc38b#

      • Den Link aus deinem 2. Post kann ich sehen, Danke dafür.

  2. Gut zu sehen, dass es dieses Mal kein Drama mehr um die Hard Fork gibt und dass zumindest Schnorr implementiert werden konnte.
    Dass Core Schnorr noch nicht aktiviert hat, liegt meines Erachtens an den „Never Hard Fork“ Statements diverser involvierter Personen zum Blocksize Drama und für jedes Feature, welches man nun implementieren möchte, müssen Umwege gefunden werden, wie man dieses vielleicht doch auch per Soft-Fork machen könnte, ohne dass es zu große Einbußen an anderen Stellen gibt. Das gilt zum Beispiel an das vor ein paar Monaten veröffentlichte Paper zu „Forward Blocks“, welches mindestens waghalsig klingt, da es mit fast allen Regeln des Consensus bricht, allerdings per Soft-Fork…

    Zunächst wird Schnorr nur als einfache Signaturoperation eingeführt. Das Verschmelzen der Input-Signaturen wird soweit ich es sehe nicht unterstützt, wie auch Multisig noch nicht Schorr-fähig ist.

    Beides übrigens bei Monero bereits implementiert, allerdings mussten die Schnorr-Signaturen für Bulletproofs leicht angepasst werden, da es immer mehrere Inputs gibt. Monero hatte Schnorr übrigens schon vor RingCT, musste dann aber für RingCT auf Borromean Signaturen umsteigen, da RingCT mit Schnorr nicht machbar war, aber mit Bulletproofs wurde die Implementierung wieder möglich.

    Auch Multisig ist bereits verfügbar, allerdings muss ich zugeben, dass es aus User-Sicht noch alles andere als trivial funktioniert. Es gibt Bestrebungen, dies mit „MMS“ zu vereinfachen, allerdings ist auch das weiterhin komplizierter als Multisig bei Bitcoin.

    Ach ja, wer einen Monero Node betreibt, unbedingt auf 0.14 updaten! Derzeit nur als CLI Version verfügbar, die GUI kommt aber wohl heute oder morgen. 9. März ist auch Hard Fork und anders als bei Bitcoin Cash kann man neue Blöcke nicht mehr mit der alten Version verifizieren, da der Hash-Algo zu CryptonightR geändert werden musste, um die wieder aufgetauchten ASICs auszubooten. Dieses Mal wurde er aber deutlich stärker abgeändert als zuvor, hat nicht mehr viel mit dem ursprünglichen Cryptonight zu tun und hoffentlich reicht diese Resistenz gegen ASIC Hardware Development bis der neue Algorithmus RandomX eingesetzt werden kann.

    Happy Fork Days!

    • Paul, danke für den Kommentar, aber warum muss hier wieder ein Block über Monero rein? Ist ja nett, dass du erwähnst, dass Monero auch eine Hardfork macht. Aber vielleicht ein wenig zuviel des Guten. Das nimmt langsam ein wenig überhand, wenn unter (gefühlt) jedem zweiten Artikel von mir eine „Werbeeinblendung“ für Monero steht …

      • Ich war schon lange nicht hier weil ich aktuell wieder viel zu tun habe, aber hab auch Erwähnungen von Monero zurückgefahren in letzter Zeit. Da es aber meiner Meinung nach relevant war über Schnorr, habe ich das erwähnt.
        Vor allem haben einige Kommentatoren geschrieben, dass sie es interessant finden, über den Tellerrand zu schauen. Okay, den letzten Block hätte ich mir sparen können, aber fand ich persönlich wichtig wegen dem Hard Fork, da er auch so kurzfristig angekündigt wurde…

        Ich finde es wie gesagt gut, dass BCH hard forked, um neue Features einzubringen, denn das ist eigentlich der einzige Weg, das Protokoll weiterzubringen. Soft-Forks sind meist eher Herumdoktorn am Problem vorbei und erfordern von den Akteuren trotzdem ein Upgrade ihrer Software / Implementierung, wenn man weiterhin mit dem Netzwerk interagieren möchte (siehe Segwit).

        Das einzige, was aus meiner Sicht der verbleibende Vorteil eines Soft-Forks ist die User-Perspektive, wenn man es tatsächlich verpasst und dann irgendwie ausgebootet ist. Da macht Bitcoin Cash auch einen besseren Job als Monero, denn der Hard Fork ist knapp 3 Monate vorher angekündigt, mit Feature Freeze und das klappte bei ersterem die letzten drei oder vier Mal nicht einmal mit 1-Monats Frist, da man bedingt der Sicherheit des Netzwerks mehr oder weniger immer zu schnellen Reaktionen gezwungen war.

        BCH hat jedenfalls aktuell mit breit angenommenen Hard Forks ohne Konflikte auch Privacy auf dem Base Layer einzuführen, wenn das von der Community gewollt ist. Mir ist es am Ende egal, welchen Coin ich nutzen kann um meine Privatsphäre zu wahren, ich bin kein Whale und somit nicht wirklich privat vom Kurs abhängig.

        „Kurzer“ Disclaimer
        Ich bin schon seit meinen Anfängen im Internet um 1998 herum an Privacy interessiert und auch Aktivist, habe die P2P Revolution miterlebt und aktiv mitgestaltet (damals hat das im Gulli Board angefangen, da das eine der ältesten deutschsprachigen Ressourcen zu diesen Themen war). Direct Connect, eDonkey2000, Audiogalaxy, Bearshare, XDCC, Soulseek Gnutella/LimeWire dürften den meisten im Gegensatz zu den späteren/heute noch aktiven Torrents keine Begriffe mehr sein. Diese waren aber zusammen mit TOR / I2P / Freenet oder Messengern wie Jabber&OTR Bestrebungen einer freien, dezentralen Kommunikation aufbauend auf den zentralisierten (und später kommerzialisierten) Protokollen, die auf einer Client-Server „Beziehung“ basieren und sich noch besser zur Massenüberwachung eignen als vorige Kanäle wie Brief, Telefon oder Funk. Auch die Open Source Software Bewegung hat mich stark beeindruckt mit Projekten wie Linux, BSD, GnuPG, OpenSSL, Mozilla oder OpenOffice, welche die kommerziellen Closed Source Blackboxes ersetzen wollte. Mittlerweile begeistert mich auch die Open Source Hardware Bewegung, denn irgendwann kommt die Einsicht, auf Hardwareebene kann man noch mehr Kontrolle gewinnen als auf Software-Ebene. Auch OpenWRT war damals großes Thema, womit man die Kontrolle über seinen Router und seine Einstellungen zurückgewinnen konnte.

        Damals fehlte noch ein dezentrales und privates Zahlungsmittel basierend auf diesem kommerzialisiertem Internet und Bitcoin war dann die nächste Revolution, bis ich zur Einsicht kommen musste, dass so ein öffentliches Kassenbuch noch schlimmer ist als simple Banküberweisungen und mit Tumblern/Mixern experimentiert habe, die allerdings wieder zentralisiert waren. Dann kamen mir die ersten Methoden wie Coinjoin oder Multisig über den Weg und irgendwann war ich dann bei Monero… TOR / I2P interessieren mich immer noch und ich bin in ab und zu in deren Communities, auch IPFS und andere Open Source Bestrebungen, aber das passt gar nicht in die Kommentarspalte hier. Zum Glück geht es dort nicht direkt um geldwerte Vorteile und die Diskussion ist entspannter, die „Gegner“ lassen sich klar abgrenzen und im David gegen Goliath Spiel diskutieren diese meist erst gar nicht mit der „Basis“.

        Ich wäre froh, wenn es bei Bitcoin und bei anderen „Crypto“-Projekten 99% der involvierten Menschen um die Idee und nicht persönlichen Profit gehen würde und die jeweiligen Entwicklercommunities sich gegenseitig mehr austauschen würden. Viele der Monero Entwicklungen basieren auf grundlegender Arbeit aus (frühen) Bitcoin Diskussionen, zk-Snarks sind Ring Signaturen in der Theorie auch überlegen, allerdings ist die (meist feindliche) Rivalität ein Hindernis für konstruktiven Austausch.

      • Ich habe bei der Kürze (sic!) meines Beitrags offensichtlich die Open Source Projekte Bisq und OpenBazaar vergessen, die ich auch unterstütze (obwohl sie nativ noch kein XMR beherrschen). Die sind immerhin sehr Bitcoin-relevant aber vor Allem gefällt mir deren Arbeit 😉
        Beide haben einen komplett anderen Ansatz, Bisq wird von einigen Leuten in ihrer Freizeit entwickelt und wo notwendig von Gründer Manfred Karrer gebootstrappt, OpenBazaar hat ein VC Funding und eigentlich noch kein Geschäftsmodell, aber sind Open Source und hoffen mit zukünftigen Entwicklungen irgendetwas zu monetarisieren (wie z.B. Multi-Currency Wallets wie Exodus oder Coinomi an den Exchange-Fees mitverdienen). Beide ganz ohne scammy ICO und mit tatsächlicher (und offener) Technologie und Entwicklung für mehr Dezentralisierung!

  3. Schön zu sehen, wie sich meine frühzeitige KryptoInvestion durch die Forkerei nicht verringert, sondern parallel weiter vermehrt.

    Irgendwann kauf ich mir mit BTC eine Villa, bezahle die Bediensteten in BCH, surfe mit BSV im Web 5.0 und für meine Enkel gibt es BTG. Die zahllosen anderen Coins spende ich an Bedürftige wie J.P. Morgan oder Warren Buffet.

    🙂

Schreiben Sie einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Wechseln )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Wechseln )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Wechseln )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Wechseln )

Verbinde mit %s