Hoe snel is bliksemsnel?

Miljoenen transacties per seconde

We weten inmiddels allemaal dat de transactiecapaciteit van het bitcoinnetwerk zelf beperkt is tot enkele honderdduizenden transacties per dag, nog geen 10 per seconde. Maar hoeveel meer transacties per seconde zijn mogelijk met het lightning netwerk?

Volgens onderzoek van Christian Decker, Core Tech Engineer bij Blockstream, kan elk payment channel in het lightning netwerk zo’n 500 transacties per seconde afhandelen. Op dit moment bestaat het lightning netwerk uit ongeveer 11.000 payment channels. Dit betekent dat het netwerk nu al ongeveer 5,5 miljoen transacties per seconde kan verwerken, terwijl het nog in zijn kinderschoenen staat!

Toch? Oké, misschien nog niet helemaal.

Het vermenigvuldigen van de transactiecapaciteit met het aantal payment channels geeft misschien geen geheel eerlijk beeld van hoeveel transacties er per seconde mogelijk zijn. Mede omdat elke transactie die gedaan wordt invloed heeft op de staat van het netwerk, niet elke node in het netwerk optimaal presteert, elk payment channel voldoende bitcoins beschikbaar moet hebben om daadwerkelijk transacties te kunnen uitvoeren en variabele netwerklatentie ook nog wel eens roet in het eten kan gooien.

trujillopuntnlsuperfastlightingnetwork

Het daadwerkelijke aantal transacties per seconde zal dus waarschijnlijk lager liggen dan de schatting hierboven, maar nog steeds in de miljoenen. Helaas is het lastig om te meten hoeveel transacties per seconde er daadwerkelijk gedaan worden op het lightning netwerk, omdat niet elke transactie publiek verzonden wordt. De daadwerkelijke capaciteit in de praktijk zal moeten blijken uit betrouwbare verslagen over werkelijk gebruik.

Op dit moment is de netwerklatentie een van de grote bottlenecks voor het aantal transacties per seconde. Er moet voor elke transactie nu eenmaal tussen twee partijen heen en weer gecommuniceerd worden. Elk bericht over en weer kost een aantal milliseconden.

De uiteindelijke capaciteit van het lightning netwerk is ongekend groot, groter dan elk ander betaalmiddel dat we kennen, en zal ergens in de miljoenen en misschien wel miljarden transacties per seconde liggen. En dit is ook wel nodig. Het lightning netwerk zal namelijk niet alleen dienen voor dagelijkse transacties van menselijke gebruikers, maar ook voor miljarden kleine transacties tussen machines zelf.

Bliksemsnelle groei

Nog maar een paar maanden geleden schreven we over de snelle groei van het lightning netwerk. Deze groei zet zich voort en het lightning netwerk bestaat inmiddels al uit ruim 10.000 payment channels!

Een mijlpaal

Het lightning netwerk bestaat inmiddels uit ruim 10.000 payment channels met een totale capaciteit van meer dan 110 bitcoins. Deze capaciteit toont aan dat er meer vertrouwen in het netwerk begint te komen; mensen vertrouwen meer bitcoins aan de payment channels toe en meer mensen beginnen met experimenteren. Het grootste deel van de deelnemers bestaat echter nog wel uit ontwikkelaars en hobbyisten.

Het volgen van de groei en ontwikkeling van het lightning netwerk is alsof je de geboorte van bitcoin opnieuw meemaakt - een groot deel van het toekomstige betalingsverkeer zal immers via deze laag verlopen. Je kunt de groei van het lightning netwerk hier zelf bijhouden. Wie weet hoeveel van de 21 miljoen bitcoins uiteindelijk onderdeel van het lightning netwerk zullen zijn en hoe het netwerk eruitziet bij brede adoptie. Spannend!

channels

Wanneer mobiele apps voor iedereen?

Mobiele wallets, met name voor iOS, laten nog op zich wachten vanwege de ontwikkeling van het protocol en watchtowers. Voor Android zijn al wel enkele lightning wallets beschikbaar, maar ook deze zijn nog wat ruw. De ontwikkelaars richten zich op het bouwen van een robuuste fundering zodat het potentieel van het lightning netwerk in de toekomst maximaal benut kan worden. Dit is tijd waard. Net als bij het bouwen van een nieuw huis begint men met de fundering en komen de mooie gordijnen pas op het laatst, zo ook voor de gepolijste apps voor de eindgebruikers.

lnjanvsjul

De brug tussen fysiek en digitaal

De term proof-of-work wordt vaak geïnterpreteerd als "computers die rekensommetjes maken". Hoewel deze omschrijving niet onjuist is, omvat het niet geheel de kracht van proof-of-work. Proof-of-work zorgt namelijk voor een brug tussen de fysieke en de digitale wereld.

Block als representatie voor verricht werk

Proof-of-work draait niet om het kiezen van een gelukkige winnende miner die vers aangemaakte bitcoins in ontvangst mag nemen; dit stukje van proof-of-work, hoewel essentieel, dient slechts als motivatie voor miners om het werk te leveren. Krijgen zij geen beloning, dan wordt er ook geen werk geleverd.

De werkelijke functie van proof-of-work is het omzetten van elektriciteit in een digitaal block als onderdeel van de blockchain. Miners voeren continue hash-operaties uit totdat zij de cryptografische puzzel die dient als loterij voor de miners oplossen. Alle operaties die zij uitvoeren, al het werk dat zij leveren, doet er niet meer toe op het moment dat de oplossing is gevonden.

Een hashfunctie is een algoritme dat, gegeven een bepaalde input, een unieke output genereert. Vanuit de gegenereerde output kan niet terug berekend worden wat de input was, maar het is wel mogelijk om, gegeven de input, te controleren dat de eerder getoonde output klopt door het algoritme nogmaals uit te voeren met de input.

Die éne oplossing is representatief voor de enorme hoeveelheid energie die nodig was om deze oplossing te produceren. Dit is het "bewijs" van het werk dat is geleverd: proof-of-work. Deze oplossing wordt omgezet in een block en aan de blockchain toegevoegd, waardoor een aanvaller dezelfde hoeveelheid werk zou moeten leveren om de oplossing succesvol na te maken. Hiermee wordt de transactiegeschiedenis die aan de blockchain wordt toegevoegd hard; bijna alsof in het in steen geschreven is.

Digitaal en toch fysiek

Wanneer we een digitaal bestand van iemand ontvangen dan 'voelt' dat niet hetzelfde als wanneer we een geldmunt ontvangen. Bij het ontvangen van een geldmunt, bijvoorbeeld een euro, weten we zeker dat er waarde is overgedragen van de tegenpartij naar ons; we weten zeker dat de tegenpartij in ieder geval niet meer over die waarde beschikt.

De enorme hoeveelheid energie die geleverd is en gepresenteerd wordt door die ene oplossing, een oplossing die met heel weinig energie te verifiëren is, geeft ons deze zelfde zekerheid. Deze cumulatie van verbruikte energie geeft aan hoe moeilijk het is om de waardeoverdracht tussen twee partijen te vervalsen, waar dit bij het versturen van een gewoon digitaal bestand zo makkelijk is.

tekbcbrug

Het ontvangen van bitcoins 'voelt' en is daardoor net zo fysiek, misschien wel fysieker, als het ontvangen van een geldmunt. De bitcoin-transactie die wij ontvangen hebben is niet vervalsbaar. Deze onvervalsbaarheid is gevangen door de reeks van gekoppelde oplossingen die elk representatief zijn voor de praktisch onmogelijke opgave om sneller te rekenen dan alle miners bij elkaar. Proof-of-work maakt dat onze digitale bitcoins eigenschappen hebben die we normaal alleen terugzien in de fysieke wereld. Het is de brug tussen fysiek en digitaal.

Building on Bitcoin: Lissabon

Begin juli werd Building on Bitcoin georganiseerd. Voor het vervolg op de eerdere Breaking Bitcoin in Parijs, kwam een grote groep ditmaal bij elkaar in Lissabon. Building on Bitcoin, ofwel BoB, legt de focus op het ontwikkelen van het Bitcoin protocol en het bouwen van nieuwe applicaties hier boven op. Er zal een overzicht worden geschetst van deze tweedaagse conferentie.

Building on Bitcoin is een evenement voor de technische bitcoingemeenschap en focust zich dus vooral op het protocol en nieuwe ontwikkelingen die hierop gemaakt kunnen worden. De presentaties van verschillende sprekers zullen hierom ook technisch van aard zijn. Hierin worden praktische en theoretische ontwikkelingen of nieuwe ideeën voor het netwerk en de gebruikers gedeeld.

Dag één

Een solide basiskennis over de werking van Bitcoin was geen overbodige luxe, zo bleek al snel gedurende de eerste dag. De presentaties waren veelal gefocust op de privacy aspecten van Bitcoin, of beter gezegd het ontbreken hiervan. Er werden onder meer ontwikkelingen getoond omtrent privacy bevorderende wallets en mixing methoden zoals CoinShuffle en CoinJoinXT.

Ook de huidige status van (lightning)wallets komen aan bod, waarbij vooral gekeken wordt naar de privacy, vertrouwelijkheid, veiligheid en gebruikerservaring. Twee pannels buigen zich over de onderwerpen privacy en welke tooling er benodigd zijn om goed te kunnen bouwen op het bitcoinprotocol. Nieuwe ideeën over blind signatures, scriptless scripts en blind coin swaps worden gedeeld.

Dag twee

De tweede dag stond meer in het teken van het bouwen op Bitcoin. Zo kwamen sidechains aan bod en werden ontwikkelingen omtrent "assets on Bitcoin" gepresenteerd. Hierbij is het idee dat een asset, een bezit of tegoed, geregistreerd en bijgehouden kan worden door gebruik te maken van de bitcoinblockchain. Daarnaast werden ervaringen en toekomstvisie's voor Lightning besproken en bediscussieerd doormiddel van een panel.

De volledige lijst van sprekers, hun onderwerpen en de presentaties kunnen hier worden bekeken.

Atomic Multi-Path Payments

In het vorige artikel over het lightning netwerk gingen we in op het bijvullen van een payment channel op het lightning netwerk middels splicing. Het is echter niet altijd nodig een payment channel bij te vullen, we kunnen ook slim gebruik maken van meerdere open channels voor een betaling.

Vele wegen leiden naar Rome

Zie 1 - 2 voor achtergrond en 3 - 4 voor aanvullende informatie.

Herinner je dat het lightning netwerk bestaat uit een netwerk van payment channels tussen gebruikers. Een gebruiker kan meerdere payment channels open hebben met verschillende partijen. Een betaling van Alice naar Dave wordt gedaan door één van de mogelijke routes die Alice uiteindelijk met Dave linkt te gebruiken.

ampath

Stel nu dat Alice een betaling van 0,006 BTC wil gaan doen naar Dave, maar Alice niet voldoende bitcoins in haar payment channel met Bob heeft om deze betaling te kunnen uitvoeren. Of, stel nu, dat Bob niet voldoende bitcoins in zijn channel met Carol heeft, of dat er niet voldoende bitcoins tussen Carol en Dave beschikbaar zijn. Hoe kunnen we deze betaling dan alsnog uitvoeren zonder bitcoins bij te laden door middel van splicing én zonder het openen van een nieuw payment channel tussen Alice en Dave?

We kunnen gebruik maken van de andere payment channels die Alice open heeft om de betaling "op te splitsen" en via meerdere routes te laten verlopen. Het gehele netwerk van payment channels tussen Alice en andere partijen kan er bijvoorbeeld zo uitzien:

ampath


Gegeven dat Alice in totaal wel voldoende bitcoins in haar payment channels met Bob, Eve en Victor heeft, kan de betaling plaatsvinden door gebruik te maken van deze routes. Stel dat Alice in elk kanaal met Bob, Eve en Victor 0,002 BTC beschikbaar heeft en een betaling van 0,006 BTC naar Dave wil doen. Hoe kunnen we dit uitvoeren op zo’n manier dat de gehele betaling op hetzelfde moment aankomt en er niet delen van de betaling per ongeluk niet doorgaan?

We kunnen de betalingen zo inrichten dat Dave de gehele betaling pas kan claimen op het moment dat Dave alle onderdelen van de betaling ontvangen heeft. Herinner je uit het artikel over Hashed Time-Lock Contracts (HTLCs) het delen van een geheim voor het succesvol uitvoeren van een betaling via tussenpartijen. We gaan hier een soortgelijk trucje gebruiken genaamd Atomic Multi-Path Payments (AMP), een idee van Olaoluwa "roasbeef" Osuntokun.

De verzender, Alice, maakt in dit geval het geheime getal P aan en maakt drie verschillende betalingen aan waarvoor P nodig is om deze te claimen. Vervolgens splitst Alice P op in drie verschillende delen: P1 , P2 en P3 . Vervolgens voegt Alice P1 , P2 en P3 aan de verschillende betalingen die zij gaat versturen. Voor de betalingen maakt Alice gebruik van de payment channels die zij open heeft met Bob, Eve en Victor.

ampath

Wanneer alle betalingen zijn aangekomen bij Dave is hij in staat om de originele P te herconstrueren, welke nodig is om de betalingen te claimen. Dit doet Dave door P1 , P2 en P3 te combineren. Vervolgens kan Dave direct alle betalingen tegelijk claimen, waardoor de betaling in zijn geheel doorgaat. Zo is er succesvol een betaling van 0,006 BTC van Alice naar Dave verstuurd, zonder het openen van nieuwe payment channels en extra on-chain transacties.

ampath

De voordelen

Het op deze manier inrichten van een betaling via meerdere routes heeft als duidelijk voordeel dat we niet langer gebonden zijn aan een enkele route van verzender naar ontvanger. Hierdoor is niet noodzakelijk om payment channels met daarin grote bedragen open te hebben. Dit komt de decentraliteit ten goede, omdat er voorkomen kan worden dat iedereen via een paar grote hubs betalingen doet. Daarnaast helpt AMP voorkomen dat sommige payment channels een te kleine hoeveelheid bitcoins bevatten, terwijl andere payment channels een overschot hebben, waardoor een ongelijke liquiditeit ontstaat.

Ook heeft AMP effect op de hoeveelheid fee die betaald zal moeten worden voor een dergelijke betaling. Hoewel de fees voor lightning-transacties al laag zullen zijn, zorgt het vermijden van grote hubs er ook voor dat de fees voor een dergelijke betaling niet hoger dan normaal zijn.

Tot slot bevordert AMP de privacy. Bij een normale lightning-betaling weten de tussenpersonen hoeveel er verstuurd wordt, maar niet wie de afkomst en eindbestemming zijn. Het toepassen van AMP heeft het effect dat de tussenpersonen ook niet meer weten hoeveel bitcoins er precies van A naar B verstuurd worden, omdat zij niet weten hoe groot de totale betaling is. Daarnaast is er een groter aantal routes beschikbaar voor het doen van kleine betalingen, waardoor het moeilijker is om de geldstroom tussen payment channels te analyseren.

Lightning Netwerk: Splicing

Wanneer we kijken naar de werking van het lightning netwerk in de praktijk komen er allerlei interessante vraagstukken naar boven. Hoe zit het bijvoorbeeld met het toevoegen van bitcoins aan een lightning channel wanneer een channel bijna leeg is?

Even opfrissen

We hebben in het verleden in een serie artikelen de basisprincipes van het lightning netwerk doorgenomen. Deze kun je hier lezen: 1 - 2. Het is verstandig in ieder geval even het eerste artikel te lezen, voordat je verder gaat met dit artikel.

Herinner je uit het eerste artikel over de basisprincipes van payment channels dat het opzetten van een payment channel op het lightning netwerk gebeurt door het uitvoeren van een aantal speciale transacties. Deze transacties zorgen ervoor dat Alice en Bob elkaar kunnen gaan betalen, zonder transacties via de blockchain te laten gaan én zonder het risico op verlies van bitcoins door een kwaadwillende tegenpartij.

channel

Via deze constructie kunnen Alice en Bob elkaar over en weer betalen, maar niet voor meer dan het initieel ingezette bedrag (in dit voorbeeld 1 BTC) en in eerste instantie alleen van Alice naar Bob. Alle transacties die vanuit het multi-signature adres tussen Alice en Bob gedaan worden zijn off-chain en worden dus pas definitief na het sluiten van het payment channel.

Herinner je ook dat het payment channel tussen Alice en Bob slechts een onderdeel is van het gehele lightning netwerk: dit bestaat uit een netwerk van payment channels. Alice kan dus gebruik maken van haar channel met Bob om betalingen naar Carol of Dave uit te voeren.

htlc

Het kan voorkomen dat Alice onvoldoende bitcoins in haar payment channel met Bob heeft om succesvol betalingen naar andere partijen uit te voeren via hetzelfde channel. Dit kan gebeuren doordat Alice haar volledige 1 BTC heeft verstuurd naar andere partijen.

Beeld je een rekenrek in; alle bitcoins in het channel zitten dan aan de "rechter-" kant. Alice zou dus een nieuw payment channel op moeten zetten (direct naar Carol of Dave) of eerst betalingen moeten ontvangen om verdere betalingen uit te kunnen voeren. Het opzetten van een nieuw payment channel doen we echter liever niet, want hiervoor zijn dure transacties en kostbare blockchain-ruimte nodig. Het liefst "laden" we het payment channel tussen Alice en Bob met nieuwe bitcoins zonder het channel te sluiten of een nieuw channel te openen.

Splice in, splice out

Door slim gebruik te maken van de mogelijkheden die de scripting functionaliteit van bitcoin ons biedt is gelukkig ook hier een oplossing voor: splicing. Bij splicing wordt gebruik gemaakt van het reeds bestaande multi-signature adres tussen Alice en Bob. Met het "splicen" van deze transactie worden er van buiten het payment channel nieuwe bitcoins toegevoegd aan het payment channel, zonder dat het payment channel gesloten wordt en er dus onnodig veel on-chain transacties gedaan worden.

De nieuwe bitcoins worden in dit voorbeeld alleen toegevoegd door Alice, maar dit kan ook door Bob of door beide partijen gedaan worden. Dit doet Alice door een transactie aan te maken vanuit het oude multi-signature adres voor het volledige aantal bitcoins, waaraan zij een nieuwe input toevoegt vanuit haar eigen bitcoin-voorraad, naar een nieuw multi-signature adres.

splice

Dit nieuwe multi-signature adres dient vervolgens als de nieuwe basis van het payment channel; Alice en Bob sturen vanaf nu vanuit dit nieuwe multi-signature adres transacties naar elkaar. Alice tekent haar deel van de transactie: haar nieuwe input en haar deel van de multi-signature output, en laat de transactie vervolgens ondertekenen door Bob. Deze transactie wordt vervolgens wél gepubliceerd en bevestigd op de blockchain, maar door deze constructie is het aanvullen van een payment channel mogelijk met één enkele on-chain transactie in plaats van meerdere.

Tijdens het wachten op een bevestiging van de transactie naar het nieuwe multi-signature adres kan de oude versie van het payment channel gewoon bijgehouden worden. Op het moment dat de nieuwe transactie bevestigd is kan overgeschakeld worden naar het nieuwe multi-signature adres met een hoger saldo.

splice

Het is op deze manier ook mogelijk om bitcoins uit het payment channel te versturen naar een regulier bitcoinadres, zoals te zien in de afbeelding hierboven. In plaats van het toevoegen van een input met nieuwe bitcoins voegt Alice een output naar een adres van zichzelf toe aan de splicing-transactie. Op deze manier kan een deel van de bitcoins opgenomen worden uit het payment channel door Alice of Bob, of naar een derde partij verstuurd worden.

Zo wordt het mogelijk om willekeurig transacties van 'gewone' bitcoinadressen naar lightning channels te versturen, en andersom. Dit zorgt ervoor dat er naadloos overgeschakeld kan worden tussen het doen van een snelle lightning-transactie vanuit een lightning-wallet voor dagelijks gebruik en het 'opnemen' van bitcoins vanuit een normale bitcoin-wallet die dient als spaarrekening. Zie het als het heen en weer schuiven van geld tussen je bankrekening voor alledaagse zaken en je spaarrekening.

Lees ook hoe lightning-transacties de privacy verhogen.

De voorgeschiedenis van bitcoin

In tegenstelling tot wat velen denken, is Bitcoin niet zomaar uit de lucht komen vallen. Op nakamotoinstitute.org is een uitgebreid overzicht te vinden van alle literatuur die bijgedragen heeft aan de uitvinding van Bitcoin, de verschillende teksten geven veel inzicht in het gedachtegoed achter de ontwikkeling van digitaal geld.

Meer dan een spontaan hobbyproject

De voorgeschiedenis van Bitcoin is voor velen onbekend, maar wel erg interessant wanneer men geïnteresseerd is in hoe dit alles is ontstaan. De uitvinding van bitcoin kwam op een moment waarop alle puzzelstukjes op zijn plek vielen. Er was al vaker geprobeerd digitale schaarste in de vorm van een digitale munteenheid te creëren, zo vroeg als de jaren 80, maar pas in 2008-2009 werd het idee succesvol uitgevoerd met de implementatie van Bitcoin.

Satoshi Nakamoto geeft in een forumpost op bitcointalk.org aan dat Bitcoin een implementatie is van het "b-money" van Wei Dai uit 1998 en het "bitgold" van Nick Szabo uit 2005. Beide voorstellen dateren van jaren voor de aankondiging van Bitcoin en zijn op vele vlakken vergelijkbaar met Bitcoin in ontwerp en filosofie.

Zo beschrijft het voorstel van Wei Dai bijvoorbeeld het verspreiden van het grootboek over alle deelnemers in een distributed netwerk, waarbij iedereen de huidige versie aanpast wanneer er een nieuwe transactie gedaan wordt. Daarnaast zou b-money, net als Bitcoin, gebruik moeten maken van publieke sleutels om bedragen aan te koppelen. Het voorstel van Nick Szabo beschrijft al het gebruik van proof-of-work, vergelijkbaar met het hashcash principe van Adam Back, voor het onvervalsbaar maken van de transactiegeschiedenis.

De verschillende teksten (ruim 80+) op nakamotoinstitute.org geven veel inzicht in het gedachtegoed achter de ontwikkeling van digitaal geld en hoe het over de jaren heen samen is gekomen tot het systeem dat we vandaag de dag kennen als Bitcoin. Absoluut het lezen waard wanneer men meer wil weten over de voorgeschiedenis van Bitcoin. Begin met de teksten van Nick Szabo, Wei Dai, David Chaum en Adam Back en je zult snel genoeg verdwaald raken in een leestocht over de oorsprong van het geld. Naast een overzicht van literatuur geeft nakamotoinstitute.org ook een overzicht van alle forumposts die gemaakt zijn door Satoshi Nakamoto na de aankondiging van Bitcoin.

Bitcoin was not forged in a vacuum. These works serve to contextualize Bitcoin into the broader story of cryptography and freedom. nakamotoinstitute.org

Scaling Bitcoin 2018: "Kaizen"

Er vindt dit jaar wederom een nieuwe editie van de Scaling Bitcoin workshops plaats, dit maal in Tokyo met als thema: "Kaizen". Scaling Bitcoin is dé conferentie waar ontwikkelaars, academici en onderzoekers samenkomen om de problemen en oplossingen rondom de schaalbaarheid van Bitcoin te bespreken.

Een fase van continue verbetering

De workshops vinden plaats op 6 en 7 oktober aan de Keio Universiteit in Tokyo, Japan. Het thema van de bijeenkomst is dit jaar "Kaizen", wat staat voor continue verbetering. Op dit moment staat de call for proposals open, waarbij onderzoekers hun bevindingen kunnen aanmelden om deze te bespreken tijdens de conferentie.

Scaling Bitcoin ‘Kaizen’, focuses on the systematic identification of portions of the Bitcoin protocol that best lend themselves to continuous, non-’consensus layer’ improvement. ‘Kaizen’ focuses on the refinement of Bitcoin’s existing impressive security, integrity and performance properties by identifying opportunities to drive further algorithmic efficiency and rigorous testing.

Het thema is representatief voor de huidige staat van de ontwikkeling van bitcoin; er wordt continu doorontwikkeld en bitcoin wordt daarmee op alle vlakken verbeterd en robuuster gemaakt. Op de voorgrond steelt vooral het lightning netwerk de show, maar op de achtergrond gebeurt er veel meer. De onmiddellijke capaciteitscrisis is voor nu verholpen en het aantal actieve ontwikkelaars neemt met de tijd toe, daarmee is er ruimte voor algehele optimalisering.

De organisatoren geven dan ook aan dat de focus van de presentaties dit jaar met name op de volgende onderwerpen moet liggen: het simuleren, modelleren en testen van verschillende aanpassingen aan het netwerk, methodes en tools die gebruikt kunnen worden voor het modelleren en simuleren, de onderliggende game theory en het economisch mechanisme dat voor de juiste prikkels binnen het netwerk zorgt en het verbeteren van de scripting mogelijkheden.

Inschrijven

In 2015 was Bitonic aanwezig in zowel Montreal als Hong Kong, in 2016 was een grote groep Nederlanders aanwezig op de internationale bijeenkomst in Milaan en ook in 2017 werd de conferentie nauw gevolgd. 
De verkoop van kaarten voor de bijeenkomst van dit jaar zal binnenkort van start gaan, een aankondiging zal volgen op de Scaling Bitcoin Twitter. Let wel dat de conferentie bedoeld is voor ontwikkelaars, academici en journalisten.

Op het Scaling Bitcoin Youtube kanaal kun je de bijeenkomsten van vorige jaren terugkijken.