Het is al weer even geleden dat deel II van de Scaling Bitcoin workshops heeft plaatsgevonden en in de tussentijd is er veel gebeurd.

Nederlandse Bitcoiners in HonkongVlnr Aaron, Jouke, Corné & Niels

In dit verslag willen we daarom niet alleen terugkomen op Hong Kong, maar ook op deze tussentijdse gebeurtenissen. Hieronder valt de roadmap van een aantal Core developers, het verschil tussen een soft- en een hard fork en de status van een aantal ontwikkelingen zoals Lightning Network.

Ook te lezen via Medium.com, zie hier: medium.com/@Bitonicnl

Scaling Bitcoin Hong Kong

Het was interessant om te zien dat de acht leden van een paneldiscussie over mining ruim 90% van Bitcoins hashpower in handen hebben:

Hashpower op het podiumHet mining-panel van oa AntMiner, Slush, FinalHash, BTCC & BitFury

Vanzelfsprekend geeft dit ook stof tot nadenken wat betreft centralisatie.

Wij zijn tegen allerlei vormen van centralisatie, maar zien in de centralisatie van hashingpower niet een concreet probleem zolang de incentives (economische prikkels) voor miners kloppen. Dat wil zeggen dat het eigenbelang van miners overeenkomt met dat van Bitcoin.

Segregated Witness, door Pieter Wuille

Pieter Wuille over Segregated WitnessPieter Wuille presenteert Segregated Witness

Segregated Witness, oftewel het loskoppelen van de cryptografische handtekening uit bitcointransacties is volgens ons de belangrijkste en beste oplossing voor de schaalbaarheid van Bitcoin op dit moment. De voordelen op een rijtje:

  • Segregated Witness kan door een zogenoemde soft-fork worden geïmplementeerd, later in dit stuk zullen we verder ingaan waarom dit onze voorkeur heeft boven een hard-fork;
  • Segregated Witness lost het probleem van transaction malleability op, een zwakheid in Bitcoin waar tot op heden nog steeds geen goede oplossing voor was;
  • Door middel van Segregated Witness is de implementatie van Lightning Network weer een stuk dichterbij;
  • En als klapper op de vuurpijl kunnen blokken in de bestaande ruimte van 1MB meer transacties aan. Dat effect is zo groot als een blokvergroting van 1.75 tot 4MB.

Maar liefst 60% van de data in de blockchain bestaat uit signatures en door het toenemende gebruik van multisignature-adressen neemt dit alleen maar toe. Onderstaande grafiek geeft dit mooi weer. Door de manier van implementeren is het mogelijk om de signature data te scheiden van de transacties, zonder dat nodes daarvoor hoeven te updaten. Oude nodes kunnen dus blijven functioneren zoals ze al doen, wat betekent dat die oude nodes genoegen zullen nemen met de huidige blockgrootte van 1mb. Nieuwe nodes die ook de nieuwe transacties willen valideren zullen de signatures los ontvangen, waardoor nieuwe nodes wel meer dan 1mb per block aan moeten kunnen.

weergave verschil door Segregated Witness

Doordat de signatures niet langer onderdeel zijn van de transactie wordt ook transaction malleability opgelost; de grootste bron van malleability is namelijk het aanpassen van de signature zodat deze wel geldig blijft, maar een wijziging in de hash van de transactie, ook wel de transactie-id, optreedt. Wanneer de signature buiten de transactie zelf staat heeft deze geen invloed meer op de transactie-id.

Het idee van Segregated Witness was niet nieuw, maar het mooie aan de manier waarop Pieter Wuille het voorstelt, is dat de verandering die nodig is om signatures te scheiden gedaan kan worden middels een soft-fork.

Sheets presentatie Pieter Wuille

Lightning Network

sponsoren van Scaling Bitcoin IIBitonic sponsort Scaling Bitcoin

In het verslag van Scaling Bitcoin Montreal hadden we het al over het Lightning Network.

In het praatje op Scaling Bitcoin in Hong Kong vertelt Tadge Dryja welke functionaliteit er nodig is alvorens het Lightning Network in optima forma kan presteren.

Allereerst was OP_CLTV (CheckLockTimeVerify) nodig voor een basisvorm van het Lightning Network, waarbij de kanalen tussen partijen tijdelijk open zijn voor een periode die bij het openen van het kanaal wordt vastgesteld. Inmiddels is CLTV actief op het huidige Bitcoin netwerk en is deze vorm van het Lightning Netwerk mogelijk.

Ten tweede is OP_CSV (CheckSequenceVerify, ook bekend als OP_MATURITY) wenselijk voor een versie van het Lightning Network waarbij de kanalen tussen partijen oneindig lang open kunnen zijn. Op dit moment wordt er door de miners gestemd om deze nieuwe op-code te implementeren.

Ten derde is Segregated Witness wenselijk voor de beste vorm van Lightning Network. Met Segregated Witness wordt het mogelijk om op een betrouwbare manier nog niet bevestigde transacties uit te geven (door Segregated Witness is signature malleability immers opgelost). Segregated Witness is inmiddels een tijdje bekend en de consensus lijkt dat dit een goede toevoeging is en er niemand echt tegen is. We kunnen dus verwachten dat Segregated Witness uitgerold wordt als de ontwikkeling ervan klaar is.

Soft- & hardfork

Een fork in software development betekent dat de broncode gekopieerd wordt en door een andere partij wordt aangepast.

Stel persoon x maakt een programma met een rode achtergrond, dan kan persoon y de broncode van programma van persoon x forken en er bijvoorbeeld een blauwe achtergrond van maken. Mensen die blauwe achtergrond beter vinden kunnen vervolgens weer verbeteringen op het programma van persoon y ontwikkelen.

Binnen Bitcoin is een fork is het splitsen van het netwerk in 2 of meerdere richtingen, waardoor nieuwe blokken van de ene chain niet meer uitwisselbaar zijn met de andere.

Het verschil tussen een soft- en hardfork

Kort gezegd kan je stellen dat bij een softfork in Bitcoin de regels in het protocol strenger gemaakt worden en bij een hardfork juist versoepeld. Dit klinkt tegenstrijdig, maar het werkt als volgt:

  1. Nodes controleren de regels van het Bitcoin-protocol, bijvoorbeeld dat er niet meer dan 21 miljoen bitcoins in het systeem komen, de snelheid waarmee een hash wordt berekend, de beloning voor een miner, de inputs en outputs van een transactie, enzovoort.
  2. Deze regels kunnen aangepast worden — door (grote) wijzigingen in het protocol creëert men eigenlijk een alternatieve versie van Bitcoin (altcoin) — tenzij alle stakeholders (nodes, miners, gebruikers, wallets, exchanges) in Bitcoin deze nieuwe regels accepteren.
  3. Bij een softfork worden de regels verscherpt, er wordt dus minder toegelaten dan in de situatie daarvoor. Een voorbeeld hiervan is het instellen van de blocksize van 1MB, in 2011. In de situatie hiervoor was er geen blocksize aanwezig en is het dus “strenger” geworden door deze regel.

    Oude nodes, die niet upgraden naar de nieuwe versie hebben geen probleem met de nieuwe situatie. De nieuwe regels conflicteren namelijk niet met hun regels. Dit is een softfork.

  4. Wanneer de regel wordt gewijzigd van 1 naar 2MB is dit een versoepeling van de regels, er is nu namelijk meer mogelijk. Wanneer nodes niet upgraden zullen ze de nieuwe richting van Bitcoin niet kunnen volgen en blijven ze dus in een oude alternatieve versie steken. Dit is een hardfork.
    Uitzonder op bovenstaande is dat hele oude nodes de nieuwe situatie wel aankunnen, maar dat is maar een insignificant aandeel.

Waarom is een softfork wenselijk

Zoals gezegd controleren nodes de regels uit het Bitcoin-protocol en verifiëren dit. Wanneer nodes een transactie of blok tegenkomen met tegenstrijdige regels wordt dit automatisch niet geaccepteerd en daardoor niet in het Bitcoin-netwerk opgenomen. In het geval van een softfork zijn de nieuwe regels strenger en laten nodes dit daarom automatisch toe. Een uitzondering is miners, die met oude software blokken kunnen maken die niet meer geldig zijn na de softfork. Zie ook onderstaande afbeelding.

schematische weergave Afbeelding 1: schematische weergave softfork

Bij een hardfork, dus met aangepaste soepelere regels, laat een node dit niet toe. Dit betekent automatisch dat nodes de “nieuwe” situaties niet accepteren tenzij de software voor een fullnode is geüpdatet. Het effect hiervan is dat een de ene node de nieuwe situatie wel accepteert en de andere node nog op de oude situatie is ingesteld. In andere woorden: hardforks zijn niet backwards-compatible.

Je krijgt daardoor 2 verschillende Bitcoin-netwerken, zie afbeelding 2. Deze situatie is vanzelfsprekend onwenselijk. Naast dat nodes controleren zijn er ook de wallets die transacties in de Blockchain controleren. Ook wallets zullen door het aanpassen van de regels problemen krijgen met het controleren van transacties en dienen ook een update te krijgen. Het is dus belangrijk dat er consensus dient te zijn over één enkele waarheid om dat anders allerlei conflicterende software problemen optreden. In onderstaande afbeelding een schematische weergave van een dergelijk conflict.

schematische weergave Afbeelding 1: schematische weergave hardfork

Bij een softfork is het dus niet noodzakelijk dat nodes worden geüpdatet en daardoor blijven alle nodes functioneel. De hoeveelheid fullnodes is weer erg belangrijk voor de mate van decentraliteit. Hoe meer nodes over de hele wereld, hoe veiliger. In de onderstaande afbeelding is te het verschil te zien dat bij een softfork in de nieuwe situatie de oude en nieuwe regels worden geaccepteerd.

Een bijkomend voordeel van de backward-compatibility van een softfork is dat er minder miners achterblijven. In de het voorgestelde upgrade-protocol treden forks in werking bij 75% miner-support en vanaf 95% is er geen weg terug en worden blokken met oude versies geweigerd. (zie: Github BIP34

In de praktijk houdt dit in dat bij een hardfork vanaf 75% de achterblijvers buiten de boot vallen, bij een softfork is dit pas vanaf 95%. Dat is een 5x zo kleine groep.

De huidige stand van zaken

  • Status Lightning Network
Rusty Russell, werkzaam bij Blockstream en een veteraan als Linux-ontwikkelaar, is onder andere bezig met een testversie van Lightning Network. Zie hier de code: https://github.com/ElementsProject/lightning

Om dat in Bitcoin Testnet al segregated witness functioneert kunnen implementaties van Lightning getest worden.

  • Status Amikopay

Ook Corné Plooij is met zijn Amiko Pay hard bezig om een variant op Lightning network te ontwikkelen. Op deze pagina is een goed overzicht te van de roadmap en de status: https://cornwarecjp.github.io/amiko-pay/

  • Vers van de pers…Thunder, door Blockchain.info

Blockchain.info ook met een variant gekomen waarbij gebruik wordt gemaakt van Payment Channels en is gebaseerd op het concept van Lighting Network: https://blog.blockchain.com/2016/05/16/announcing-the-thunder-network-alpha-release/

  • Segregated witness

Op dit moment is Segregated witness in de laatste testfase. Door verschillende core developers is de afgelopen maanden gewerkt aan de integratie, testen en optimalisatie van BIP141, waarin Segregated Witness beschreven wordt. Aan verschillende noodzakelijke eisen is inmiddels voldaan en integratie ligt dan ook op schema. Zie ook De roadmap van Core. In de tussentijd is er een tweede bijeenkomst geweest in Hong Kong, waar developers de koppen bij elkaar gestoken hebben voor de volgende stappen in Bitcoin: Weak blocks and IBLT, Lightning …

Maar daarover later meer!

COREDEV ZURICH 20–22 MAY 2016

”An invitation only developer event for hacking together on Bitcoin-Core and related projects.” Bitonic levert een bijdrage als sponsor: http://coredev.tech

    Onderwerpen die o.a. op een agenda stonden:
  • Review & improve the p2p net refactor
  • Discuss P2P-layer end to end encryption
  • Review & Test Segregated Witness — “If it’s already merged or ready for production before the meeting, we could focus on improving segwith further, writing wallet adoption guides, etc.”

De volgende Core Developers waren aanwezig:

CoreDevs