Fork this! nl

Door Rannasha op dinsdag 24 april 2018 11:41 - Reacties (4)
Categorie: Cryptocurrency, Views: 3.908

Een wijziging aanbrengen in de regels die een cryptocurrency / blockchain definieren is niet eenvoudig. In een decentraal systeem kun je niet simpelweg op zondagavond een update pushen zodat vanaf maandag het allemaal anders gaat. Een belangrijk concept in de blockchain wereld is dan ook de "fork", of de splitsing van de blockchain in 2 incompatibele regelsets. Vaak wordt onderscheid gemaakt tussen een "softfork" en een "hardfork", waarbij dan gezegd wordt dat die eerste eenvoudig is met beperkte impact en die tweede ingewikkeld met verregaande gevolgen.

De zaken zijn, zoals meestal het geval is, wat genuanceerder dan dat.

In een ideale wereld zullen zowel softforks als hardforks nooit daadwerkelijk leiden tot een splitsing van de blockchain, omdat forks alleen worden uitgevoerd met 100% steun van de gebruikers en met meer dan voldoende voorbereidingstijd zodat iedereen op een degelijke manier kan upgraden voor de fork plaats vindt. Maar goed, de wereld is verre van ideaal.

Het onderscheid tussen soft- en hardfork is vanuit de formele definitie vrij duidelijk, maar als het gaat om de daadwerkelijke consequenties is er, in theorie, meer overlap mogelijk.

De definities. Een softfork is een wijziging in de regels van het protocol die deze regels stricter maakt. Dat wil zeggen: Iets dat eerst wel toegestaan was, is dat na de fork niet meer. Een hardfork is het omgekeerde, het verruimt de regels en laat dingen toe die daarvoor niet toegestaan waren.


Softfork, scenario 1
Het daadwerkelijke effect van een softfork hangt af van welke beperkingen er precise worden geintroduceerd. Een verlaging van de block-size naar 100 kB is een softfork, want de regels worden strenger. Miners die hun software niet updaten zullen alsnog proberen om grotere blocks te minen, die door de miners en nodes die wel geupdate hebben worden geweigerd. Zolang de miners die geupdate hebben in de meerderheid zijn (gemeten aan de hand van hashrate), zullen de niet-upgradende miners alsnog de chain van de upgradende miners volgen. Zo nu en dan produceren de niet-upgraders een tijdelijke aftakking als ze een of meer blocks van >100 kB minen, maar uiteindelijk zal de upgrader-tak de grootste hoeveelheid rekenwerk bevatten en dus worden overgenomen.

Als slechts een minderheid van de miners upgrade, dan ontstaat de situatie dat er 2 aparte takken zijn die ook blijven bestaan. De niet-upgradende meerderheid zal werken aan een chain met grote blocks, maar deze chain wordt pertinent geweigerd door de upgraders, die hun eigen tak hebben met kleine blocks. Omdat deze tak minder rekenwerk bevat dan de chain van de niet-upgraders en dit verschil met de tijd alleen maar toeneemt, zullen de niet-upgraders deze tak met kleine blocks simpelweg negeren. In dit scenario kan een softfork dus leiden tot een permanente splitsing van de blockchain.

Merk op dat ik het hier alleen heb over miners, maar niet over gewone gebruikers. In het hierboven geschetste scenario zullen niet-miner-clients die niet updaten simpelweg de langste tak volgen, omdat voor niet-updaters beide takken geldig zijn. Een wijziging als de verlaging van de block size heeft geen noemenswaardige impact op de gebruikers. Zij kunnen zelf kiezen of en wanneer ze de software updaten.


Softfork, scenario 2
Maar, dat is niet met iedere softfork per se het geval. Stel je hebt een, in mijn ogen zeer redelijke, softfork waarin wordt geeist dat iedere transactie een output bevat die aan mijn adres wordt toegekend met ten minste 10% van de totale waarde van de transactie. Dit is een softfork omdat het een extra restrictie is op de regels waaraan transacties moeten voldoen.

Voor miners geldt het zelfde verhaal als hierboven. Maar voor gewone gebruikers ligt het anders. Gebruikers die enkel transacties ontvangen hoeven nog steeds niets te doen, maar als een gebruiker transacties wil versturen, dan moet deze gebruiker z'n software updaten zodat de Rannasha-belasting op de juiste manier betaald wordt.

Er is hier dus sprake van een softfork, waarbij het toch noodzakelijk is dat alle gebruikers hun software updaten. Omdat dit geen wenselijk scenario is (de Rannasha-belasting wel, de verplichte update niet), is er tot nu toe voor gekozen om vooral scenario 1 softforks toe te passen. Softforks waarbij miners moeten updaten, maar waarbij gebruikers zelfs kunnen kiezen of en wanneer ze de update uitvoeren.

En om de overgang voor miners goed te laten verlopen, wordt er gebruik gemaakt van een signallerings-mechanisme waarmee kan worden aangegeven of men klaar is voor de softfork en bereid is deze te steunen. Is er onvoldoende steun, dan komt de fork er niet.


Hardforks
Een hardfork is, zoals al gezegd, het omgekeerde van een softfork. De regels worden verruimd. Een voorbeeld is het vergroten van de block size. Als een meerderheid van de miners een hardfork volgt, dan zal de blockchain zich splitsen. De minderheid die niet mee doet en de oorspronkelijke software blijft draaien, zal immers de tak met de verruimde regels weigeren ondanks dat deze langer is. Zo ontstaan er dus 2 parallele takken.

Als de minderheid van de miners de hardfork steunt, dan gebeurt er niets. De meerderheid die niet mee doet zal een langere tak produceren die ook door de minderheid als geldig wordt gezien. De minderheid zal deze tak dus ook volgen en blijven volgen, ondanks dat ze zo nu en dan een block produceren dat door de meerderheid als ongeldig wordt gezien.

De oplettende lezer springt nu op uit zijn of haar stoel en roept "Maar Bitcoin Cash en al die andere hardfork-coins hebben een minderheid van de miners, maar blijven alsnog als onafhankelijke takken bestaan. Sup with that?" Hier kom ik straks op terug, wees geduldig!

Hoe zit het met de gebruikers? Hier moet onderscheid gemaakt worden tussen gebruikers die een SPV client draaien en full node gebruikers. Uitgaand van het scenario dat de hardfork een meerderheid achter zich krijgt: Gebruikers die een full node draaien zullen moeten updaten. Doen ze dat niet, dan zullen ze de minderheids-tak gaan volgen. Maar het is goed mogelijk dat (vrijwel) alle miners de hardfork volgen. In dat geval zullen er geen nieuwe blocks meer worden gemined op de minderheids-tak en zullen gebruikers die niet upgraden dus geen gebruik meer kunnen maken van het netwerk.

SPV clients controleren de blockchain niet zelf, maar communiceren met een of meerdere full nodes om enkel de gegevens op te halen die voor de client relevant zijn. Een SPV client is dan ook fork-agnostisch. Zelfs als een hardfork wijzigingen aanbrengt op het gebied van transacties, dan zal een SPV client hier niet om geven, want deze kan gewoon de oude transactie-regels blijven toepassen voor het aanmaken van transacties.

In het geval van een blockchain-splitsing kan het gebruik van een SPV client dan ook gevaar opleveren, omdat het voor de gebruiker niet per se duidelijk is op welke tak de client actief is. Sommige ontwikkelaars van SPV clients hebben inmiddels functionaliteit toegevoegd die detecteert op welke tak de client werkt en/of die de gebruiker zelf laten kiezen.


Hardfork-altcoins
Zoals beloofd, verdere uitleg over hoe Bitcoin Cash en andere hardfork-altcoins ondanks een mining-minderheid toch een werkzame aftakking van de blockchain hebben gemaakt en in stand hebben gehouden.

In het geval van Bitcoin Cash komt dit door de "first must be large" ("de eerste moet groot zijn") regel die zegt dat het eerste block na het gekozen fork-moment verplicht groter moet zijn dan 1 MB. Dit block wordt door niet-forkers geweigerd, terwijl fork-miners de reguliere Bitcoin-tak weigeren omdat deze niet aan deze regel voldoet.

Maar de first must be large regel is eigenlijk een restrictie op de regels van het protocol. En dus een softfork. De Bitcoin Cash fork is dus niet enkel een hardfork, maar een combinatie van een hardfork en een softfork op hetzelfde moment. Dit zorgt ervoor dat het eenvoudiger wordt om te bepalen wat er gebeurt. Ongeacht de hoeveelheid mensen / miners die de fork steunen zal het zo zijn dat miners en gebruikers die de Bitcoin Cash software draaien de Bitcoin Cash tak volgen en zij die dat niet doen blijven op de Bitcoin tak. Gebruikers van SPV clients lopen nog steeds een risico, zolang de client niet expliciet aangeeft welke tak deze volgt (of de gebruiker laat kiezen).

Sommige fork-altcoins die volgden op Bitcoin Cash (bijvoorbeeld Bitcoin Gold) pasten nog weer een ander fork-mechanisme toe. Tot nu toe heb ik enkel gesproken over forks die de regels stricter maken (softforks) en forks die de regels ruimer maken (hardforks). Maar het is ook mogelijk om de regels simpelweg te veranderen, zonder dat deze stricter of ruimer worden.

Zo heeft Bitcoin Gold er voor gekozen om vanaf het fork-block een ander hashing-algoritme te gebruiken. Blocks voor het fork-block worden nog steeds gecontroleerd met het oorspronkelijke hashing-algoritme (SHA256), maar alle volgende blocks moeten met het nieuwe algoritme worden gechecked (en dus ook gemined).

In de praktijk is het effect van zo'n forktype hetzelfde als de hardfork/softfork combinatie van Bitcoin Cash: Gebruikers die overstappen zullen altijd op de fork-tak komen, gebruikers die dat niet doen blijven op de oorspronkelijke tak. SPV gebruikers moeten oppassen.

Ondanks dat de hierboven beschreven forks geen pure verruiming zijn van de regels, beschouwen velen de hierboven genoemde forks als hardforks, omdat deze forks backwards compatibility breken: Gebruikers die de software update niet installeren, kunnen niet deelnemen aan deze forks.


SegWit
Maar hoe zit het dan met SegWit? Deze update voegde een heel nieuw sort transactie toe en maakte het mogelijk om blocks groter dan 1 MB te minen. Dit klinkt heel erg als een hardfork, maar toch is SegWit met een softfork geintroduceerd. Hoe kan dat?

Het antwoord zit verstopt in de slimme manier waarop SegWit is geimplementeerd. Bitcoin heeft een script-taal met daarin een heel aantal functies en mogelijkheden om aan te geven onder welke voorwaarden een transactie-output besteed mag worden. De meest voorkomende voorwaarde is dat de bezitter van een specifiek adres de vervolg-transactie ondertekent. Maar het is ook mogelijk dat meerdere handtekeningen nodig zijn (multi-sig) of de extra voorwaarde dat de vervolg-transactie niet voor een bepaald moment mag worden verstuurd.

Een van de mogelijkheden is simpelweg om geen enkele voorwaarde aan een transactie-output te verbinden. De zogenaamde "any can spend" transactie. Een any-can-spend output kon door iedereen in een willekeurige transactie worden gebruikt. In de praktijk werd deze mogelijkheid nooit gebruikt, omdat er geen use-case voor is.

De SegWit softfork introduceert een hele set extra voorwaarden op het besteden van een any-can-spend output. En deze set extra voorwaarden zijn precies de voorwaarden waar een SegWit transactie aan moet voldoen, dus ze bevatten de gebruikelijke eisen over het hebben van de juiste digitale handtekening. Deze voorwaarden specificeren ook dat de handtekeningen van dergelijke transacties in een aparte datastructuur moeten worden bewaard. Deze datastructuur is een aanvulling op het gebruikelijke block.

Een client of miner die de SegWit update niet heeft uitgevoerd zal SegWit transacties nog steeds als geldig zien. Hij ziet ze immers als any-can-spend transacties en voor dergelijke transacties is alles toegestaan. De extra datastructuur met handtekeningen van SegWit transacties zal een dergelijke client gewoon negeren als irrelevante onzin-data. Een client die niet geupdate is zal dan ook perfect blijven functioneren. Deze client kan gewoon transacties blijven versturen en ontvangen en ook minen is geen probleem. Alleen het versturen van any-can-spend transacties kan problemen opleveren, omdat de meerderheid van het network nu allerlei voorwaarden koppelt aan deze transacties. Maar, voor de SegWit softfork waren any-can-spend transacties al "non-standard", wat wil zeggen dat ze wel toegestaan zijn, maar in de praktijk niet door nodes worden doorgegeven.

Clients die wel zijn geupdate zullen alle any-can-spend transacties controleren aan de hand van de nieuwe voorwaarden. De handtekeningen worden uit de extra datastructuur gehaald en gecontroleerd voordat een dergelijke transactie wordt geaccepteerd. Omdat de extra datastructuur met handtekeningen niet meetelt in de block size van 1 MB, is het dus mogelijk om een effectieve block size (het pure block + de extra datastructuur) te hebben van meer dan 1 MB, afhankelijk van de hoeveelheid SegWit transacties die er in het block zitten.


Conclusie
Het verschil tussen een softfork en een hardfork is minder zwart/wit dan het lijkt. Desalniettemin is de impact op de gebruikers wezenlijk anders. Het doel van een softfork is om zoveel mogelijk backwards compatibility te bieden, zodat iedereen op eigen initiatief kan updaten of de update zelfs kan weigeren. Niet alles kan worden ingevoerd met behulp van een softfork, waardoor een hardfork voor sommige wijzigingen noodzakelijk is. Maar met slim hergebruik van bestaande functies, zoals de any-can-spend transactie, is er behoorlijk veel mogelijk met een softfork.

In het algemeen is een softfork te verkiezen boven een hardfork, omdat de impact voor de gebruikers beter te beheersen is. En hoewel dat in het huidige stadium van acceptatie van cryptocurrency nog niet een groot probleem is, zal het in een hypothetische cryptocurrency-toekomst een groot voordeel zijn als cruciale financiele infrastructuur gebouwd op cryptocurrency-nodes niet regelmatig consensus-veranderende updates hoeft te krijgen.

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.386

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: 17.104

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.169

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.