Description should be obvious: anything related to computers and/or information and communication technology.

Ethereum - A tale of two hacks nl

Door Rannasha op donderdag 20 juli 2017 10:00 - Reacties (10)
CategorieŽn: Computers/ICT, Cryptocurrency, Views: 7.025

Het was ongeveer een jaar geleden toen ik op een zonnige maar, zoals meestal het geval is, te warme zomerdag een wandeling maakte in het gebied aan de voet van het Franse Jura-gebergte met mijn vrouw en jongste dochter. Ik heb ook een oudere dochter, die zeker nog niet in staat is om alleen thuis te blijven, maar zij was er niet bij. Ik weet eigenlijk niet precies waar ze wel was. Maar ze was ongetwijfeld ergens en het heeft hoe dan ook geen problemen opgeleverd.

Niet lang voor die wandeling had ik een kleine long-positie geopend in Ethereum, want ik was van mening dat de koers na een sterke daling wat terug zou veren. Zoals gebruikelijk, bewoog de koers in eerste instantie de verkeerde kant op, wat mij enigszins frustreerde gezien ik niet van verliezende posities hou (wat een van de redenen is waarom ik nauwelijks handel in cryptocurrencies). Gelukkig draaide de wind en kon ik de positie nadat ik weer thuis was met een kleine winst sluiten.

TheDAO

De achterliggende reden voor de eerder genoemde sterke daling was de hack van TheDAO. Voor wie het allemaal niet meer zo goed weet: Ethereum biedt de mogelijkheid om "smart contracts" te maken, stukjes code die bepalen onder welke voorwaarden crypto-tokens worden verstuurd en die geheel onafhankelijk en decentraal draaien. Het bekendste smart contract destijds was TheDAO, waar DAO staat voor "decentralized autonomous organization".

TheDAO zou een decentraal investeringsfonds moeten worden. Investeerders konden met hun Ethers aandelen (tokens) van TheDAO kopen en deze tokens konden worden gebruikt om te stemmen op investeringsvoorstellen. Als een voorstel voldoende stemmen zou krijgen, dan volgde automatisch een overboeking van de juiste hoeveelheid Ether naar de ontvanger, met natuurlijk de hoop dat op een later moment het bedrijf waar zojuist in was geinvesteerd een deel van een forse winst terug zou storten. Het geheel was opgezet in de vorm van een aantal smart contracts en draaide volledig zonder inmenging van mensen.

Er werd voor zo'n $150.000.000 in TheDAO geinvesteerd, wat op dat moment ongeveer 15% van alle Ether was. Veel grote namen in de Ethereum gemeenschap deden mee.

Hack

Helaas mocht het allemaal niet zo mooi zijn en werd TheDAO gehacked, waarbij er zo'n $50.000.000 aan Ether werd gestolen. Althans, is dat wel zo? In de tijd dat dit speelde was een van de slogans die het team achter Ethereum vaak gebruikte "Code is Law", oftewel: de code is de wet. Wat er geprogrammeerd is, bepaalt wat er moet gebeuren.

De code van TheDAO maakte het mogelijk voor een gebruiker om Ether uit de set van smart contracts weg te halen. De hacker maakte gebruik van een mogelijkheid die geboden werd door de code van TheDAO. En als de code de wet is binnen Ethereum, was dit dan diefstal of een legitieme, maar onvoorziene, transactie?

Het staat buiten kijf dat voor de meeste mensen deze actie moreel gezien fout was. Het is nooit de bedoeling geweest van de ontwikkelaars van TheDAO om de mogelijkheid te bieden om zomaar het geld uit de smart contracts weg te halen. De hacker heeft een foutje in de code gevonden en dit gebruikt om zich de Ether toe te eigenen.

Fork

Direct nadat de hack begon, werd deze opgemerkt door Ethereum-gebruikers. Een groep white hat hackers is vervolgens aan de slag gegaan om het overgebleven geld uit TheDAO weg te halen en veilig te stellen.

Vervolgens begon de onvermijdelijke discussie over de vraag: Wat nu? Na stevige discussie en mislukte tijdelijke oplossingen, kwam de conclusie om een zogenaamde hard fork uit te voeren: Een wijziging in de regels van het protocol waardoor het contract van TheDAO werd aangepast zodat de oorspronkelijke investeerders, niet de hacker, het geld konden weghalen.

Opeens was de code geen wet meer, want hij werd overruled door een hogere autoriteit. Hoewel de hard fork de steun had van een groot deel van de Ethereum community, was het zeker geen unanieme beslissing. Tegenstanders spraken erover dat de keuze om deze hack terug te draaien enigszins arbitrair was, want er waren wel eerder hacks geweest op smart contracts, al waren die veel kleinschaliger in omvang. Toen is er niet ingegrepen, maar hebben er mensen alsnog geld verloren.

Ook zou het een slecht precedent zetten, want een grote hack zou in de toekomst mogelijk weer kunnen plaatsvinden (bedenk zelf even wat dreigende muziek die op de achtergrond op komt zetten bij het lezen van die laatste zin). Bovendien werden er beschuldigingen van belangenverstrengeling geuit aan het adres van belangrijke personages binnen Ethereum, die voor de fork betoogden, maar zelf een flinke hoeveelheid geld in TheDAO hadden geinvesteerd.

Maar goed, ondanks de oppositie, was de meerderheid voor dit plan en zo gezegd, zo geforked. TheDAO investeerders kregen hun geld terug. Een klein gedeelte van de gebruikers deed niet mee en splitste zich af naar een andere tak, die tegenwoordig Ethereum Classic heet, maar de rest van Ethereum ging rustig verder, met afgelopen maanden een forse prijsstijging.

Alles was vergeten en vergeven. Tot dat ...

De "Parity hack"

Je voelde hem aankomen. Toch? Ik bedoel, de titel van de blogpost en de met dreigende muziek ondersteunde "foreshadowing" een paar alinea's terug zouden voldoende aanwijzing moeten zijn geweest.

Gisteren, bijna 1 jaar na de hard fork om TheDAO, heeft een hacker zo'n $30.000.000 aan Ether buitgemaakt dankzij een bug in de Parity wallet software, die blijkbaar al maanden aanwezig is. Dan vind ik dat de hacker best 2 dagen had kunnen wachten om zijn aanval op de verjaardag van de hard fork uit te voeren. Dat zijn de dingen waar ik me dan weer aan kan ergeren.

Nu zul je wellicht zeggen: "Parity is een wallet-app en een bug in een wallet is toch heel anders dan een smart contract met code die onbedoelde gevolgen heeft?" Op zich wel, maar de twee hebben meer gemeen dan je op het eerste gezicht zou zeggen.

De bug in Parity heeft te maken met zogenaamde "multi-sig" accounts. Multi-sig is een methode waarbij meerdere mensen (of autonome blockchain-entiteiten) moeten tekenen voor een transactie. Het heeft allerlei handige toepassingen die met gewoon geld een stuk lastiger zijn om uit te voeren. Multi-sig bestaat voor vrijwel iedere cryptocurrency, al werkt het in Ethereum wat anders dan in op Bitcoin gebaseerde cryptocurrencies.

Parity maakte voor multi-sig accounts speciale smart contracts aan die vervolgens op het netwerk werden gezet. Deze smart contracts zijn te activeren door de juiste set aan digitale handtekeningen te versturen, waarna het geld doorgestuurd wordt. De bug in Parity zorgde er echter voor dat deze smart contract een mogelijkheid hadden voor een willekeurige gebruiker om de inhoud van deze multi sig smart contracts naar een adres naar keuze door de sturen.

Er is voor zo'n $30.000.000 uit diverse multi-sig accounts weggehaald door de aanvaller, waarna er wederom een groep white hat hackers opgestaan is om alle andere multi sig accounts gemaakt door Parity te legen en het geld veilig te stellen.

To fork or not to fork?

En nu komen we weer terug bij de vraag: Is de code de wet? De hacker heeft gebruik gemaakt van de smart contract code zoals deze op het netwerk stond. Voor zover bekend is er geen gebruik gemaakt van malware, phishing, social engineering of dergelijke zaken. De hacker heeft de code van het smart contract bekeken en deze op een zeer specifieke, maar geldige manier gebruikt.

Hoewel het nieuws nog vrij vers is, zie ik deze keer veel minder oproepen om de boel terug te draaien met een hard fork. Maar waarom is dat? Feitelijk is deze hack niet fundamenteel anders dan de hack op TheDAO. De hoeveelheid geld die in eerste instantie is buitgemaakt is vergelijkbaar.

Je kunt het argument maken dat dankzij de stijging van de koers van Ethereum, de relatieve schade ten opzichte van de totale waarde van het netwerk deze keer een stuk lager is dan vorig jaar. Dat is zeker waar, maar tegen de groep mensen die geld zijn verloren zeggen "hoewel jullie verlies niet veel minder groot is, is het nu een stuk minder relevant" is nogal cru.

Vertrouwen in het vertrouwenloze

Een belangrijk argument voor cryptocurrencies en smart contract platforms is dat ze "vertrouwenloos" ("trustless") zijn. Dat is niet hetzelfde als "niet te vertrouwen", maar het betekent dat je als gebruiker niet hoeft te vertrouwen in een persoon, groep personen of organisatie om de juiste beslissingen te maken. Het draait onafhankelijk door volgens de regels van het protocol.

De hard fork na TheDAO was een breuk hiermee. Een geldig smart contract werd ongedaan gemaakt omdat een groep mensen de uitkomst onwenselijk of zelfs moreel verwerpelijk vond. Ik verwacht niet dat de Parity hack op dezelfde manier ongedaan gemaakt wordt. In dat geval moeten de slachtoffers de verliezen slikken.

Maar wat betekent het voor de toekomst als een gebruiker niet meer kan vertrouwen op de vertrouwenloosheid van het systeem? Stel dat ik een serie smart contracts maak voor iets dat volkomen legaal is, maar dat ieder logisch dekend mens totaal onwenselijk vindt (bijvoorbeeld: de financiele administratie van een decentrale Heineken-fanclub). Kan ik er dan op rekenen dat mijn smart contracts blijven bestaan?

Of als er een zakelijk conflict is tussen twee partijen om een zeer grote hoeveelheid geld. Als de smart contracts geprogrammeerd zijn om de kant van A te kiezen, terwijl de meeste gebruikers de kant van B kiezen. Kan er dan op worden gerekend dat A z'n contractuele gelijk krijgt? Zelfs als A gebruik heeft gemaakt van een loophole in het contract?

Tot slot

Het is weer een zonnige, te warme, zomerdag hier in het Frans-Zwitserse grensgebied. Net als een jaar geleden maakt Ethereum groeipijnen door, in de schaduw van de potentiele ontknoping van de Bitcoin-burgeroorlog. Decentrale, vertrouwenloze systemen zoals Bitcoin en Ethereum zijn nog heel erg nieuw. En er zijn nog talloze vraagstukken die moeten worden opgelost. Voor een smart contract platform zoals Ethereum is de mate waarin "Code is Law" een werkbaar principe is, een van de belangrijkste vraagstukken.

Bitcoin op 1 augustus: UASF & SegWit2X - Wat, wanneer & waarom

By Rannasha on Thursday 6 July 2017 13:17 - Comments (26)
Categories: Computers/ICT, Cryptocurrency, Views: 16.333

1 augustus wordt mogelijk een interessante dag. Niet alleen omdat het de Zwitserse nationale feestdag is en ik dus een dagje vrij ben, maar ook omdat een deel van de Bitcoin-gebruikers dan middels BIP148 een UASF zal proberen af te dwingen om hier mee miners er toe te zetten om SegWit te signalleren. De miners zetten echter in de op New York Agreement, oftewel SegWit2X, om voor de UASF al een SegWit lock-in te bewerkstelligen en zo een potentiele chain-split te vermijden.

Ehm? Wat?

Er is veel onduidelijkheid over wat er precies aan de hand is rondom de schalingsproblematiek van Bitcoin, de diverse oplossingen en het tijdsschema waarop deze mogelijk worden geimplementeerd. En over de gevolgen die het heeft voor gebruikers. Moet je je software updaten? Hoe voorkom je dat je geld verliest?

Daarom: Een niet-zo-korte uitleg over het wat, hoe en waarom van SegWit, UASF, 1 augustus en aanverwante zaken.

Beginnen bij het begin: Wat is nu eigenlijk het probleem?

Vroeger, toen de Aarde nog plat was en het minen van Bitcoins nog door mannen met pikhouwelen werd gedaan, mochten Bitcoin blocks maximaal 32 MB groot zijn. Toen vond een of andere grapjas het leuk om het netwerk vol te spammen met transacties, waardoor de grootte van de blockchain snel toenam zonder dat er nuttige transacties werden verstuurd. Toen is besloten om de block-grootte te limiteren tot 1 MB. Bitcoin was toen nog erg onbekend en weinig waard en 1 MB was meer dan genoeg. Het verhogen van die limiet was een kwestie voor een later moment.

Tijdens de rally van eind 2013 begon het transactievolume sterk toe te nemen en begonnen de eerste discussies over het verhogen van de block-grootte limiet. Er was echter geen consensus. Er was ook geen urgentie.

De getuige wordt afgescheiden

In de loop van de tijd werd door Bitcoin Core ontwikkelaars de uitbreiding "SegWit" ontwikkeld. SegWit staat voor "Segregated Witness" en is een set aan features die draait om een nieuw type transactie waarbij de digitale handtekening niet per se bewaard hoeft te worden samen met de rest van de transactie-details nadat deze gecontroleerd is. Deze handtekening (de "witness") kan van de rest worden gescheiden ("segregate").

SegWit heeft een aantal voordelen. Zo voorkomt het een verschijnsel dat "transaction malleability" wordt genoemd, waarbij de identifier van een transactie gewijzigd kan worden zolang de transactie nog niet in een block is opgenomen. Transaction malleability (samen met een flinke dosis slecht beleid) lijkt de oorzaak te zijn van de beruchte MtGox hack die deze ooit populaire exchange naar de afgrond heeft gebracht.

Daarnaast maakt SegWit een aantal verdere ontwikkelingen mogelijk, waarvan een van de belangrijkste het zogenaamde "lightning network" is. Dit systeem, ook wel bekend als "payment channels", maakt het mogelijk om transacties uit te wisselen die niet allemaal in de blockchain opgenomen moeten worden. Hierdoor is in sommige gevallen een forse verhoging van de transactie snelheid en capaciteit mogelijk.

Tot slot bevat de SegWit patch ook een wijziging in de manier waarop de block grootte gemeten wordt, wat effectief een verhoging van het aantal transacties dat in een block past betekent. Hoe groot deze verhoging is, is variabel, dit hangt namelijk af van het aantal SegWit-transacties. Als een block enkel normale transacties bevat, dan verandert er niets. Maar bevat deze veel SegWit transacties, waar de digitale handtekeningen niet meegeteld worden in de block-grootte, dan past er een stuk meer in.

De uitrol van SegWit en verzet ertegen

Het uiteindelijk plan van de Bitcoin Core ontwikkelaars was om SegWit in te voeren zodra een overgrote meerderheid van de miners gereedheid zou signalleren. In blocks is er ruimte om bepaalde versie-flags toe te voegen en dit kan gebruikt worden als een manier om te stemmen of te signalleren dat je ergens klaar voor bent.

Het idee was om te wachten tot 95% van de blocks gedurende een periode van 2 weken de zogenaamde "bit 1" flag bevatten. Deze flag signalleert dat de miner van het block klaar is voor SegWit. Zodra 95% van de blocks deze flag bevatten dan zeggen we dat de wijziging "locked in" is. Dat betekent dat de wijziging nog niet actief is, maar wel vastligt wanneer deze activatie plaats zal vinden. In het geval van SegWit is dit 2 weken na het lock-in moment.

Dat was de theorie, maar zoals wel vaker het geval, liepen dingen in de praktijk anders. Slechts 30-40% van miners (gewogen naar rekenkracht) schaarde zich achter SegWit en signalleerde gereedheid.

Maar hoe komt dat deze uitbreiding relatief weinig steun kreeg van de miners? Er zijn meerdere redenen. Ten eerste vrezen sommige miners dat de lightning networks die door SegWit mogelijk worden gemaakt hun inkomsten uit transactiefees zullen verlagen. Dergelijke transacties worden veelal niet opgenomen in blocks en daarom worden er geen fees and de miners betaald.

Daarnaast zijn sommigen van mening dat de motivaties van de Bitcoin Core ontwikkelaars niet zuiver zijn. Een aantal van de prominente ontwikkelaars zijn in dienst van het bedrijf Blockstream, dat een product op basis van lightning networks op de markt wil brengen.

De miners die SegWit niet signaleerden, geleid door hardware-fabrikant en miner Bitmain, zagen meer heil in het verhogen van de maximale block-grootte. Dit zou leiden tot een uitbreiding van de transactiecapaciteit, op een manier die alle transacties "on-chain" houdt. SegWit voorstanders beweren dat de belangrijkste reden dat Bitmain tegenstribbelt voortkomt uit het feit dat Bitmain een mining-optimalisatie, die ASICBOOST genoemd wordt, gebruikt. Dit levert Bitmain een fors efficientie-voordeel op en dus meer inkomsten. SegWit verandert de structuur van een block waardoor ASICBOOST niet meer toepasbaar is. Het is overigens niet bewezen dat Bitmain ASICBOOST toepast.

De onenigheid tussen beide kanten van dit debat heeft de Bitcoin gemeenschap behoorlijk gespleten. Vanuit beide kanten wordt er vrij met allerlei negatieve uitlatingen over de andere kant gestrooid. Er is het een en ander geprobeerd door beide groepen om danwel hun voorkeur door te drukken of tot iets van een compromis te komen. Deze blogpost is al lang genoeg zonder die geschiedenis, dus die slaan we dan maar over.

UASF: Lekker forken, maar dan zachtjes

Zonder uitzicht op een einde aan de "Bitcoin burgeroorlog", besloten sommige gebruikers en ontwikkelaars dat het wachten op medewerking van de miners zinloos was en het tijd werd om het heft in eigen handen te nemen. Zij zijn gaan inzetten op een zogenaamde User Activated Soft Fork (UASF). Een "soft fork" is een wijziging in de regels van het protocol, waarbij de regels na de wijziging strenger zijn dan ervoor. In dit geval een wijziging die door gebruikers (en niet miners) geactiveerd zou moeten worden. UASF is ook wel bekend als BIP148. BIP staat voor "Bitcoin Improvement Proposal" en voorstellen om wijzigingen aan te brengen worden meestal in de vorm van een "BIP" uitgebracht, zo ook UASF.

De regelwijziging waar de UASF om draait is simpel: Vanaf middernacht op 1 augustus weigert de UASF-client alle blocks die geen SegWit-gereedheid signalleren met de bit 1 flag. Het achterliggende idee is dat als voldoende gebruikers de UASF software draaien, waaronder economisch belangrijke spelers zoals exchanges, het voor de miners ongunstig is om geen SegWit te signalleren. Hun blocks worden in dat geval geweigerd door een deel van het netwerk, terwijl de miners die wel SegWit signalleren verder kunnen bouwen aan een langere keten die wel door iedereen geaccepteerd wordt (het is belangrijk om te beseffen dat hoewel UASF gebruikers blocks zonder SegWit signallering weigeren, alle andere gebruikers alle blocks accepteren, waardoor blocks met SegWit signallering door het hele netwerk geaccepteerd worden).

De miners zullen dan moeten kiezen tussen het verder gaan op hun niet-SegWit tak of overstappen op de SegWit tak. Afhankelijk van de hoeveelheid gebruikers die de UASF-client draaien, zal die afweging anders uitpakken. Als slechts een enkeling de UASF-client draait, dan kunnen de miners het hele gebeuren gerust negeren. Is de groep echter groter, dan moet er een keuze worden gemaakt tussen overstappen naar SegWit of de eigen tak voort te zetten (desnoods met een kunstgreep om een definitieve splitsing met de SegWit-tak te forceren).

SegWit2X: Polderen in Nieuw Amsterdam

Met de dreiging van de UASF in het achterhoofd, kwamen veel miners en Bitcoin-bedrijven bijeen in New York om een compromis te sluiten. Deze bijeenkomst is opgezet door investeerder Barry Silbert, die vooraf voldoende steun bij elkaar had geraapt om de bijeenkomst de moeite waard te maken.

Het compromis wordt meestal SegWit2X genoemd. De basisgedachte is dat de miners eerst SegWit invoeren en dat er later dit jaar een hardfork plaatsvindt waarmee de block-grootte verdubbeld wordt. Miners die samen ruim 80% van de rekenkracht vertegenwoordigen hebben zich aangesloten bij dit compromis, net als een vrij groot aantal Bitcoin-bedrijven.

Het probleem, dat de wiskundig begaafden onder jullie reeds hebben opgemerkt, is dat 80% kleiner is dan de 95% rekenkracht die nodig is voor de lock-in en activatie van SegWit. De eerste stap van SegWit2X was daarom niet zo simpel als het signalleren van SegWit door alle deelnemers aan het compromis. Daar komt bij dat de tijd krap was, want het compromis is eind mei gesloten en de 1 augustus deadline waarop UASF activeert naderde rap.

Daarom is als onderdeel van de zogenaamde "New York Agreement" een nieuw uitrolproces gedefinieerd. De eerste stap is reeds gezet: Alle deelnemende miners plaatsen de boodschap "NYA" in een tekstveld in de blocks die ze minen, zodat bijgehouden kan worden hoe groot de steun is. Inmiddels zit het "NYA" percentage al een tijdje boven de 80%.

Stap twee is dat er een nieuwe versie van de Bitcoin Core software wordt ontwikkeld waarin miners een signallerings-bit inzetten. Alleen is dit niet bit 1 die voor SegWit activatie wordt gebruikt, maar bit 4. De software houdt vervolgens bij welk percentage van de blocks over een periode van ruim 2 dagen bit 4 signalleert. Zodra dit percentage de 80% overschrijdt, begint de volgende fase.

Want op dat moment zullen de SegWit2X / NYA clients alle blocks weigeren die geen SegWit signalleren op bit 1. Klinkt dit als iets dat je al eerder hebt gehoord? Dat kan kloppen, want dit is dezelfde aanpak die de UASF toepast. De miners die niet mee doen zullen zich in dit geval gedwongen voelen om alsnog over te stappen. Maar doen ze dat niet, dan tellen hun blocks simpelweg niet meer mee. En als alle SegWit2X miners zelf ook bit 1 signalleren (wat natuurlijk de logische gang van zaken is), dan levert dit automatisch een blockchain op waarbij 100% van de blocks SegWit signalleert.

Dan volgt hieruit de SegWit lock-in en later de activatie en dan is het feest en kan iedereen de strijdbijl begraven.

Of toch niet?

Niet iedereen is even blij met SegWit2X. Of liever gezegd, veel mensen zijn er niet heel blij mee, om diverse redenen. Wat dat betreft is het een echt compromis dus.

Een van de redenen die vaak wordt aangehaald is dat de afspraken achter gesloten deuren gemaakt zijn door een groep "belangrijke mensen" en veel gebruikers zijn van mening dat dit in conflict is met de geest van Bitcoin.

Daarnaast wordt de korte tijdschaal als kritiekpunt aangehaald. De SegWit2X software moet in korte tijd ontwikkeld worden. En hoewel SegWit zelf al uitgebreid is getest o het Bitcoin-testnet en bij diverse van Bitcoin afgeleide altcoins waar het al is geactiveerd (o.a. Litecoin), is het activatie-mechanisme via bit 4 signallering compleet nieuw en er is weinig tijd om te testen, want 1 augustus wacht niet.

Tot slot zijn veel mensen wel voor SegWit, maar niet per se voor de verdubbeling van de maximale block-grootte. De vrees is dat de grotere blocks en de daar bij horende hogere bandbreedte en opslag vereisten het moeilijker maken voor kleine spelers om te minen of een een node te draaien, waardoor de controle steeds meer in handen komt van grote spelers met hun datacentra.

Ondanks de kritieken, zijn veel mensen toch gematigd positief over SegWit2X, voornamelijk omdat het eindelijk een einde lijkt te brengen aan het langdurige schalingsconflict.

Ondertussen blijft de steun voor UASF nog steeds stijgen, ondanks dat bij een succesvolle invoering van SegWit2X, de UASF overbodig is. UASF aanhangers zien de UASF als een methode om de miners eerlijk te houden. Het is immers nog steeds mogelijk voor miners om zich terug te trekken uit de New York Agreement. UASF gebruikers proberen daarom de boodschap "als jullie het niet doen, dan doen wij het wel" luid en duidelijk over te brengen. Er bevinden zich ook steeds meer SegWit2X-aanhangers onder de UASF gebruikers, die de UASF puur gebruiken als dwangmiddel om miners zich aan de NYA te laten houden.

Maar wat gaat er nu precies gebeuren?

Dat is de grote vraag... Het "simpelste" scenario is dat alle miners zich aan de New York Agreement houden, de SegWit2X software installeren en SegWit activeren. UASF zal in dit geval niets doen, want de miners zijn al bezig met het weigeren van niet-SegWit blocks op het moment dat de UASF actief wordt.

Wat onzeker is, is hoe men gaat denken over de verdubbeling van de block-grootte die later ingevoerd moet worden. Hier zijn voldoende mensen skeptisch over, maar als een overgrote meerderheid van de miners er achter staat, dan wordt het moeilijk om tegen te houden. Een nieuwe variant van UASF, die zeer veel gebruiker-steun heeft, zou hiervoor nodig zijn.

Als een deel van de miners zich terugtrekt uit de New York Agreement, dan wordt het spannender, want dan gaat de UASF activeren in de nacht van 1 augustus. Wat er dan gebeurt, zal zeer sterk afhangen van de steun die UASF heeft. Als er weinig aanhangers zijn, dan gebeurt er eigenlijk niets en gaat alles door zoals het was: zonder SegWit, met 1 MB blocks.

Is er veel steun voor UASF, dan staan miners voor een keuze: Meedoen of niet? Als genoeg miners besluiten om toch mee te doen en SegWit te signalleren, dan is er goede kans dat SegWit geactiveerd gaat worden. Hoeveel miners precies nodig zijn, hangt van een heel aantal factoren af.

Miners die alsnog niet mee doen, kunnen er voor kiezen om bewust een wijziging in het protocol dat zijn volgen aan te brengen om zo hun tak volledig incompatibel te maken met de UASF-tak. Standaard zal mining-software verder proberen te bouwen op de langste geldige tak die hij ziet. En miners die niet met UASF mee doen zien de UASF tak nog wel als geldig, dus als deze voldoende steun krijgt en de langste wordt, dan zullen niet-deelnemende miners proberen verder te bouwen op deze tak, terwijl elk block dat ze minen geweigerd wordt door de UASF-gebruikers. Er onstaat dan een rommelige situatie.

Om dit te voorkomen zouden miners die geen SegWit willen signalleren dus een definitieve splitsing kunnen forceren.

Wat betekent het voor mij als gebruiker?

Je hoort allerlei adviezen over wat je met je Bitcoins moet doen voor 1 augustus. Vooral niet op een exchange bewaren, vooral wel op een exchange bewaren, gewoon alles verkopen, enz... Maar wat is nu precies het effect van de huidige ontwikkelingen op de gewone gebruiker en hoe kun je je het beste voorbereiden?

Wat het beste is, hangt af van wat er gaat gebeuren. Als er geen daadwerkelijke splitsing van de blockchain plaatsvindt (of een dergelijke splitsing is van korte duur omdat vrijwel direct duidelijk is wat de winnende tak is), dan maakt het eigenlijk allemaal niet zoveel uit. Als er gewoon slechts 1 blockchain is waar iedereen aan mee doet, dan zal ook jouw favoriete wallet-software of exchange dat doen.

Als er echter wel een chain-split optreedt en beide takken houden een niet verwaarloozbare waarde, dan wordt het wel belangrijk wat je doet. Jouw private keys geven in dat geval toegang tot Bitcoins op beide takken (die ik even A en B noem). Een transactie die je maakt zal (waarschijnlijk) ook geldig zijn op beide takken. Maar als je een transactie op tak A wil sturen naar een bedrijf dat tak A coins verwacht, dan is het mogelijk dat deze transactie ook door tak B wordt gezien. En als de transactie geldig is op tak B, dan zal hij daar ook worden uitgevoerd. Maar de ontvanger is mogelijk niet in staat of bereid om de transactie op tak B te verwerken en de tak B coins naar jou terug te sturen.

Dit verschijnsel wordt een "replay attack" genoemd. Er wordt gesproken van een aanval, omdat een partij bewust transacties van de ene tak naar de andere kan overzetten. Iemand die zelf tak A steunt, kan er voor kiezen om door middel van een replay attack alle tak A transacties ook op tak B rond te sturen, om zo chaos te scheppen op tak B.

Er zijn diverse manieren om je te beschermen tegen een replay attack. De aanval werkt namelijk alleen als de transactie op beide takken geldig is. Een manier om je te beschermen tegen een replay attack is dan ook om een transactie te versturen die geldig is op tak A, maar niet op tak B. Bijvoorbeeld door een transactie op tak A te maken die onder andere coins gebruikt die na de splitsing gemined zijn. Op tak B is het block waar deze coins uit afkomstig zijn nooit gemined, dus iedere transactie die deze coins verstuurt, zal worden geweigerd op tak B.

Naarmate de tijd vordert, zal een steeds groter gedeelte van alle transacties geldig zijn op slechts 1 tak. Een transactie is immers pas geldig als alle coins die in de transactie worden besteed voortkomen uit eerdere, geldige transacties. De coins uit een transactie die geldig is op tak A, maar niet op tak B, kunnen daarom worden gebruikt (bewust of onbewust) om andere coins te "besmetten", zodat transacties met deze coins op tak A niet meer op tak B afgespeeld kunnen worden. Hoe langer je wacht, hoe meer coins er op deze manier gesplitst zijn.

Een oplossing is dus om simpelweg niets te doen als je jouw Bitcoins in je eigen wallet hebt zitten. Dit heeft het voordeel dat je rustig kunt aanzien hoe de situatie zich ontwikkelt en geeft ontwikkelaars de tijd om goede wallet-software te ontwikkelen die goed om kan gaan met de ontstane situatie. Zo zou je kunnen denken aan een wallet-applicatie waar je kunt schakelen tussen tak A en tak B. Ben je wel van plan om kort na een chain-splitsing transacties te versturen, let dan goed op.

En de exchanges?

Als er een chain-splitsing dreigt, dan zullen exchanges waarschijnlijk de storting en opname van Bitcoin tijdelijk opschorten (en mogelijk de handel ook) tot er duidelijkheid is. Wederom, als er slechts een enkele overlevende blockchain is, dan zullen exchanges gewoon hier mee verder gaan en is het alsof er niets is gebeurd.

Blijven er twee functionerende takken over, dan zijn er dus feitelijk twee aparte versies van Bitcoin die los van elkaar verhandeld kunnen worden. Het is dan aan de exchange om te kiezen welke van de twee ze gaan aanbieden. Of beiden natuurlijk. Een bijkomende vraag is of een exchange die slechts een tak gaat aanbieden z'n gebruikers de Bitcoins op de andere tak laat opnemen of niet. De exchange kan er voor kiezen om deze zelf te houden. Exchanges die beide versies gaan aanbieden, zullen zeer waarschijnlijk alle gebruikers een saldo in beide coins geven dat gelijk is aan het Bitcoin-saldo voor de splitsing.

Als je Bitcoins op een exchange laat staan tijdens een splitsing, moet je dus vantevoren weten wat het beleid is van de exchange. Zal de exchange hoe dan ook gebruikers toegang geven tot coins op beide takken? Daarnaast moet je je ook afvragen of je vertrouwen hebt in de technische competentie van de exchange om zaken als replay attacks te voorkomen. Voor bedrijven met complexe wallet-configuraties, zoals exchanges, is dit geen triviale kwestie.

Maar als jouw exchange of web-wallet-dienst een beleid heeft waar je je in kunt vinden en je vertrouwt in de competentie van hun ontwikkelaars, dan kun je je Bitcoins op de exchange laten staan tijdens een splitsing.

Tot slot & Een kijkje in de kristallen bal

Het zijn spannende tijden in Bitcoin-land. De langlopende "burgeroorlog" lijkt een conclusie, of in ieder geval een belangrijke omslagpunt, te naderen. Maar de dreiging van UASF heeft de ontwikkelingen noodgedwongen in een stroomversnelling gebracht, waardoor SegWit2X snel moet worden uitgerold.

Een belangrijke datum om naar uit te kijken is 21 juli. Dit is de geplande datum waarop de SegWit2X software uitgerold wordt en het signalleren van bit 4 begint. Zodra dit gebeurt, wordt echt duidelijk of iedere deelnemers aan de New York Agreement nog steeds mee doet.

De lock-in van bit 4 vereist een 80% meerderheid gedurende iets meer dan 2 dagen (336 blocks), waarna een periode van diezelfde lengte volgt voordat activatie van bit 4 begint (en niet SegWit-signallerende blocks geweigerd worden). Om een potentiele chain-split te voorkomen moet de activatie plaats vinden voor 1 augustus. Dus als de streefdatum van 21 juli niet gehaald wordt, dan heeft men nog een paar dagen marge, maar veel is het niet.

Vooralsnog lijkt het erop dat SegWit2X ingevoerd gaat worden. Hoewel voldoende mensen niet heel blij zijn met dit compromis, is er weinig actief verzet. Het verzet dat er wel is bevindt zich voornamelijk onder UASF-aanhangers, maar daar is een steeds groter wordende groep die UASF wil gebruiken om er voor te zorgen dat miners niet terugstribbelen en zich aan de New York Agreement houden.

Ondanks dit vooruitzicht, is de kans op een splitsing van de blockchain zeker aanwezig. Voor gebruikers betekent dat dat ze voorzichtig moeten zijn. De Bitcoins in eigen beheer houden en rustig afwachten is de simpelste oplossing. Maar ondanks wat paniekerige statements hier en daar, is het niet per definitie een probleem als je Bitcoins op een exchange hebt staan in deze periode, mits je je huiswerk doet en weet wat de exchange van plan is.

Wat de koers gaat doen kan niemand voorspellen, maar het is aannemelijk dat we volatiele tijden tegemoet gaan. De meeste mensen verwachten dat een soepele invoering van SegWit2X in ieder geval op de korte termijn op z'n minst gematigd positief is. Daarentegen is een rommelige blockchain-splitsing zeker geen goed nieuws op korte termijn en kan dit een forse koersval betekenen.

Maar het zou niet de eerste keer zijn dat Bitcoin precies datgene doet dat je niet had verwacht. We zullen het zien...

Let op: Trolls ahead!

Een kleine toevoeging direct na publicatie van deze post:

In online discussies en artikelen over UASF, SegWit, SegWit2X, enz... zul je vaak een eenzijdige blik op de zaak tegenkomen. Soms is die meteen evident (wanneer er allerlei negatieve termen worden gebruikt voor de "andere kant"), maar dat is lang niet altijd het geval. Er zijn veel mensen met een hele sterke mening over dit onderwerp en objectiviteit is vaak ver te zoeken.

Pas daarom enigszins op wanneer je informatie probeert in te winnen over dit onderwerp, want je kunt zo een verkeerd beeld krijgen van de zaak als je eenzijdige artikelen of discussies leest. Ik heb geprobeerd om mijn blogpost zo neutraal mogelijk te houden, waar nodig beide kanten te belichten en mijn eigen mening niet te laten doorschemeren (het helpt dat ik geen hele sterke mening heb over deze kwestie), maar dat neemt niet weg dat een volledig objectieve tekst niet bestaat. :)

Lightroom, Linux and networks

By Rannasha on Monday 15 June 2009 17:30 - Comments (9)
Categories: Computers/ICT, Photography, Views: 11.052

I like Lightroom for managing my digital photos and performing minor edits. It has, however, some major flaws, that will not be very important to most people, but that do annoy me. These flaws are:
• Lightroom only comes in Windows and MacOS flavors.
• Lightroom refuses to load catalog-files from a network share.

The second point merits a little extra information: Lightroom stores all the info about your pictures, their locations, the tweaks you've made, the keywords and whatnot in a big catalog-file. The pictures themselves may be located anywhere, on a local harddisk, a network share, a USB stick or disk, it doesn't matter. However, it won't let you store the catalog file on a network share. The reason for this (as found by Googleing) is that several users may be accessing files on the network share and Lightroom is not designed to have more than one person working with a catalog file at the same time.

Fair enough, but being the only LR user in my private network at home, I'd like to think that I'm able to restrain myself from making modifications from more than one computer at a time. The solution for this problem lies with the simple Windows command of "subst". Using the syntax

code:
1
subst Z: \\networkcomputer\share


Windows (from 2000 and up, according to Wikipedia) will create a new virtual disk called "Z:" and it will lead to the network share called "share" on "networkcomputer". And with this little bit of trickery, Lightroom will, without complaining, agree to load and use catalog files located on this network share. One word of warning though: I suppose that the reason behind the inability to load catalog files from network shares is valid and that the file may become damaged and corrupted if altered by more than one computer at the same time.

Sadly, the subst-trick goes away when the computer is rebooted. To solve this, I've used the ultimate tool for automation in these modern days of 2009: The .bat file. I created a bat-file with the single subst-line and in order to make it start when I start my computer, I simply dropped it in the "Startup" folder of the Start menu in Windows XP. Since I couldn't find a similar folder in the Windows 7 RC, I made a registry-line (in the HKLM->Software->Microsoft->Windows->CurrentVersion->Run branch, details may differ as I don't remember the precise path) in the auto-start section that points to the file. Problem 2 solved!

Back to problem 1. The initial response is to privately curse the developers for not making a Linux version of the program. Did that, didn't help. Secondly, one tries Wine. Now, I didn't try it myself, but results from a Google search didn't inspire me with much confidence that it'd work. The final option was the one that did work: A virtual machine.

I had no previous experience with VMs, so I just went for the name I knew: VMware. They make a program called "VMPlayer" that is free to use. After installing it, I went to www.easyvmx.com where they provide you with custom virtual machines based on some parameters you can input, such as number of processor-cores to use, memory available to the VM, diskspace, etc... I clicked through it and was offered a file to download. Armed with the file and the new VMPlayer installation, I loaded the program, opened the file and lo and behold: it was starting up. I scrambled for my Windows XP disc and installed Windows XP on it. After installing, XP started nicely. So far so good.

The next hurdle is the fact that the VM knows nothing of the host environment, so I can't access any disks from the VM other than its own virtual disk. I read that the "Shared Folders" tool that VMware offers isn't available for the free VMPlayer, so that wasn't an option. However, the VM can communicate with the host environment through a virtual network interface. So I downloaded and installed Samba and altered the configuration file (/samba/smb.conf) to create a new share on my laptop (where the entire story takes place). This did the trick, I was able to access the share from within the VM (Do a cmd -> ipconfig and pick the address listed at "Default gateway" (or something similar): this is the IP that the host environment has).

Now I could install Lightroom and it works quite well, despite the VM only having 1GB of RAM and 1 core of a Core2Duo T7300 to work with.

The conclusion of a, for me, exciting weekend of learning new computer stuff is that I can now manage my pictures both from my Win7 desktop and from my Ubuntu 8.10 (with WinXP in a VM) laptop, while both the pictures and the catalog file are located on my Ubuntu 8.04 server.