Sjors Provoost

North Korea’s “Cryptocurrency-1”

Cryptocurrency developer Virgil F. was arrested a few days ago at Los Angeles International Airport. Arresting travelers at the airport right before they leave appears to be a thing for the FBI, e.g. a OneCoin founder was arrested at the same airport on his way out, and Malware Tech was arrested at Vegas airport after a conference. Is it the free coffee for law enforcement?

He traveled to North Korea, gave a talk there entitled “Blockchain and Peace” and then allegedly tried to organize a symbolic 1 ETH payment to South Korea ($216 at the time). Here’s the full inditement: https://www.justice.gov/usao-sdny/press-release/file/1222646/download

There’s serious concern that although the case may have some merit, the real goal of the FBI is set a dangerous precedent about a specific aspect of this case: providing education about publicly available information.

(update: Peter Todd points out his description “doesn’t appear to be completely correct. The FBI did mysteriously cut off one of their options to getting the data off the phone. But it seems that was in changing the iCloud password, disabling unencrypted backups, not the pin.”)

So it’s important to critically analyse this case. This means keeping an eye out on new information being released, as the inditment only contains information needed to show Probable Cause:

In my opinion there are four distinct accusations, but since they’re all covered by the same broad law, the inditement makes no effort to keep them cleanly separated:

1. Traveling to North Korea after being explicitly denied permission
2. Providing any kind of service to North Korea without permission (banned by Trumps executive order 13722)
3. Giving a presentation about “blockchain technology”, emphasising its hypothetical usefulness for sanctions evasion, based solely on publicly known information
4. Organizing a symbolic transfer as a proof-of-concept for said evasion

I find (3) and (4) particularly problematic.

Giving a presentation

Regarding (3) one should ask the following question: what if he had given the same presentation on US soil, recorded it on Youtube and tweeted it out with “Hey Kim, check this out, you’ll find this useful when @realDonalTrump racks up sanctions again”? Would this be covered by the First Amendment? If so, does it really matter that he gave the speech while physically in North Korea?

The inditement seems to admit that only publicly available knowledge was shared. If they actually had a case for sharing non-public information I assume they would have made it here:

An example of such non-publicly available information would be if he audited a US based exchange and then divulged technical details that North Korea could use, e.g. to create fake accounts and bypass KYC controls. That’s not at all what he’s being accused of here.

Symbolic transfers

Regarding both (3) and (4), the inditement goes to great lengths to accuse him of actually assisting in transferring funds out of North Korea:

This if anything shows that he hadn’t prepared a presentation with the topic of sanction evasion in mind, but was just spurred in the heat of the moment to mention that.

One could also argue that refusing a “suggestion” from a North Korean government official while in North Korea is unwise. Of course he could have dropped the idea later, rather than organise a demo:

For some reason the name of the cryptocurrency is redacted and replaced with “Cryptocurrency-1”. Is this then finally The Flippening? Or is this how the FBI wants avoid mentioning that this isn’t Bitcoin ($17.000 at its peak, which is probably what judge and jury will remember), but Ethereum ($216 at the time).

I find it a complete stretch to call such a demo, that they could have found on Youtube, a serious effort to evade sanctions. It takes a lot more to really move money. I won’t go into details, partly because I actually don’t know, partly because I don’t want my name on the next inditement. The FBI knows better than to drink the crypto-trivially-beats-government kool-aid.

Morality

There is of course also the moral question of whether one should go to North Korea (or China for that matter) to educate the government on this technology:

But his actions seemed more naive than malicious. It was also around the same time when the guy who signed the executive order was going on photo shoots and openly praising Kim:

Cargo Cult veldexperiment

NRC schreef onlangs in hun redactioneel commentaar:

Interessanter is de benadering die de Nederlandse denktank Sustainable Finance Lab (SFL) deze maand suggereerde. Nederland is volgens het SFL bij uitstek een geschikt land om te experimenteren met een door de centrale bank gecontroleerde digitale munt, omdat het gebruik van cash in ons land sneller terugloopt dan in veel andere landen. De Nederlandsche Bank zou volgens de denktank bijvoorbeeld een „gecontroleerd veldexperiment” kunnen opstarten.

Dit soort artikelen doen mij altijd denken aan een Cargo Cult. Volgens Wikipedia:

Met eenvoudige materialen als hout en riet bouwden de eilandbewoners er een compleet vliegveld na, inclusief verkeerstoren met antennes, radio’s en koptelefoons. Ze hoopten de voorouders daarmee te overreden hun lading bij hen te droppen; van de techniek die achter de nagebouwde installaties schuilging hadden ze echter geen besef.

Zowel Libra zelf als centrale bank “Cryptovaluata” hebben een hoog cargo cult gehalte. Bitcoin is de cargo. Men lijkt te denken dat door elementen uit Bitcoin na te bootsen wonderen verricht kunnen worden. De individuele ingrediënten zijn echter helemaal niet zo interessant. Het is de combinatie die (hopelijk) leidt tot een gedecentraliseerde, niet censureerbare munt, met een voorspelbaar monetair beleid. Een aantal ingrediënten:

1. Een database met transacties: bestaat al sinds de oudste kleitabletten. Mocht iemand ergens een kleitablet vinden wat verwijst naar het vorige kleitablet, dan is dat de oudste blockchain ter wereld.
2. Een torrent achtig netwerk van nodes die allemaal een volledig kopie bewaren: in 1999 kon iedereen dankzij Napster een kopie van alle mp3’s bewaren. Nog nooit een bankier enthousiast over gezien.
3. Proof-of-Work: de enige bekende manier om anoniem te kunnen bewijzen dat je werk verricht hebt, in 1997 bedacht door Adam Back als middel tegen email spam. Om een transactie ongedaan te maken, moet je meer werk verrichten dan de vorige miner. Dit is totaal onnodig bij een valuta zoals de euro: om een transactie ongedaan te maken, bel je de ECB.

Niet alleen zijn de individuele onderdelen van Bitcoin niet nuttig voor centrale banken, de combinatie is zeer onwenselijk voor ze. Een centrale bank wil graag hun monetaire beleid kunnen aanpassen, transacties kunnen monitoren en censureren; de ECB wil bv. witwassen tegengaan, de Chinese overheid wil goed gedrag aanmoedigen.

Het is mij dus volstrekt onduidelijk wat een centrale bank opschiet met een veldexperiment om de eigen ondergang nader te bestuderen.

Privacy, proportionaliteit en subsidiariteit

Onderstaande is een fragment uit de brief die ik in januari 2019 gestuurd heb naar Minister Hoekstra (Financiën) via de internet consultatie Implementatiewet Wijziging Vierde Anti-Witwasrichtlijn. De gehele brief is hier te lezen. De voorgestelde wet is nog steeds in behandeling.

Uit recente voorstellen zoals het delen van identiteitsgegevens van cryptocurrency gebruikers onder exchanges (FATF), en het verbod op contante betalingen boven de €3.000, vermoed ik helaas dat hij de brief niet gelezen heeft.

Update 2 juli 2019, 17:40: er kwam zojuist een nieuwe versie van voorstel uit, alsmede advies van de Raad van State en de AVG. Onderstaande tekst gaat over de versie uit december.

De toelichting van de richtlijn noemt in haar 40 pagina’s nul keer het woord “privacy”. De gehele tekst heeft een vrij negatieve ondertoon als het gaat om zowel privacy als cryptovaluta. Wellicht omdat het vanuit de handhavende hoek geschreven is en zij beroepsmatig nou eenmaal alleen met de duistere aspecten te maken krijgen, en niet de positieve. Deze negatieve houding blijkt nog het meest uit de volgende zin:

“De richtlijn beoogt dan ook de anonimiteit die is verbonden aan transacties in virtuele valuta, en het verhullen van dergelijke transacties, zoveel mogelijk tegen te gaan.”

Dit staat in schril contrast met Artikel 8 van het Europees Verdrag voor de Rechten van de Mens: “Recht op eerbiediging van privé familie- en gezinsleven

1. Een ieder heeft het recht op respect voor zijn privé leven, zijn familie- en gezinsleven, zijn woning en zijn correspondentie.”

Er vindt mijns inziens te weinig maatschappelijke discussie plaats over privacy in het financiële systeem in het algemeen. Hoewel ik begrijp dat er niet zomaar voor Bitcoin een uitzondering gemaakt kan worden, vind ik het toch noodzakelijk om hier iets over te zeggen.

Witwaswetgeving lijkt over het algemeen slechts een hamerstuk. Logisch, want “Wet ter voorkoming van witwassen en financieren van terrorisme” klinkt nou eenmaal niet heel spannend en de meeste mensen zijn het eens dat witwassen en terrorisme slecht zijn. Maar daardoor ziet men niet de consequenties, en die zijn op privacy gebied zeer ernstig.

Inbreuk op een grondrecht als privacy mag alleen indien dit noodzakelijk is, en binnen de grenzen van proportionaliteit en subsidiariteit (zie Arrest Sunday Times EHRM 26 april 1979, NJ 1980/146). De noodzaak staat met onderwerpen als witwassen en terrorismefinanciering niet ter discussie. De beginselen van proportionaliteit en subsidiariteit echter des te meer, gezien de digitale (bewaar)mogelijkheden die er ondertussen zijn. Ik geef een voorbeeld.

Als ik een openbaar toilet bezoek op Utrecht Centraal, ga ik eerst door een OV poortje, loop dan langs pakweg 100 camera’s naar de ingang van het toilet, alwaar ik mijn contactloze pinpas gebruik. De cameragegevens worden binnen enkele dagen verwijderd. Het inchecken en annuleren van dat inchecken met mijn OV chip kaart wordt binnen 18 maanden verwijderd. De pintransactie wordt echter afhankelijk van de bank soms meer dan 10 jaar bewaard.

Ik zie niet hoe mijn WC bezoek tien jaar geleden van belang is voor het voorkomen van terrorisme. Dit is een probleem met subsidiariteit en proportionaliteit waar de wet m.i. te weinig nuance in toont.

De barre toestand en achteruitgang van privacy in het financiële systeem is voor veel cryptovaluta enthousiastelingen een belangrijke drijfveer om een alternatief te bouwen. Peter Van Valkenburgh van het Amerikaanse Coin Center gebruikt vaak de term Financiële Surveillance: het volgen van mensen middels de bankrekening in plaats van met camera’s of schaduwen.

Gezien het bovenstaande, is wellicht is volgende formulering beter:

De richtlijn beoogt dan ook de anonimiteit die is verbonden aan transacties in virtuele valuta, en het verhullen van dergelijke transacties, zo veel mogelijk te beschermen in lijn met Artikel 8 van het Europees Verdrag voor de Rechten van de Mens, en slechts gericht en proportioneel de anonimiteit te doorbreken waar er een zwaarwegend belang is in het voorkomen van witwassen en terrorismefinanciering.

Vanuit een nieuwe doelstelling die privacy een gelijkwaardige prioriteit geeft, kunnen we dan vervolgens proportionaliteit aanbrengen in de uitvoering door te waken dat de inbreuk niet verder gaat dan nodig en subsidiariteit door de inbreuk te beperken tot de lichtste middelen.

In de toelichting onder §7.1 “Persoonsgegevens in het kader van het cliëntenonderzoek” staat:

“Er geldt een bewaartermijn van vijf jaar vanaf het moment dat een zakelijke relatie is beëindigd of een transactie is verricht, voor de persoonsgegevens die uit hoofde van het cliëntenonderzoek worden verzameld.

Zonder het verrichten van cliëntenonderzoek zou een effectieve bestrijding van witwassen en financieren van terrorisme niet mogelijk zijn. Ten einde signalen die duiden op onder meer witwassen of terrorismefinanciering te kunnen herkennen, is het verwerven van kennis en informatie over de identiteit van een cliënt onmisbaar. Ook voor het functioneren van de (Nederlandse) opsporingsautoriteiten is deze informatie essentieel.”

Hier wordt een valse tegenstelling gecreëerd. Aan de ene kant is er de GDPR die het mensenrecht op privacy probeert waar te borgen. Aan de andere is er de noodzaak om witwassen te bestrijden. Er wordt gedaan alsof het volledig opheffen van het recht op privacy de enige optie is.

Het is belangrijk om het contrast goed in beeld te krijgen. Als alléén het recht op privacy van belang zou zijn, dan moet iedere wisseldienst van cryptovaluta alle gegevens van hun klanten verwijderen zodra een transactie compleet is. Ze moeten dus vrijwel onmiddellijk het rekeningnummer waar vandaan betaald is verwijderen, het bitcoin adres waar de coins naar verzonden zijn vergeten, de naam en adresgegevens van de klant wissen, etc, etc. Die gegevens hebben namelijk totaal geen bedrijfsmatig nut. Daarnaast zou het absoluut verboden zijn om de bitcoins van een klant na aankoop te volgen.

Als alléén het bestrijden van witwassen van belang is, dan mogen gegevens nooit gewist worden en moet iedere klant maximaal bespioneerd worden, vooral ook na de aankoop.

Het enige compromis wat de wet hier doet is de termijn op 5 jaar na beëindiging van de relatie zetten. Dit werkt misschien bij bankrekeningen waarbij men jaarlijks voor de service moet betalen, maar sluit niet aan bij de praktijk rond cryptovaluta. Mensen sluiten vrijwel nooit online accounts en dus eindigt de relatie feitelijk nooit. In de praktijk zouden deze gegevens daardoor onbeperkt bewaard moeten worden.

Daarnaast is de blockchain voor iedereen in te zien, waardoor de gevolgen van een eventueel datalek veel ingrijpender zijn. Kwaadwillenden kunnen dan zien welke personen veel Bitcoin bezitten. Dit leidt nu soms al tot berovingen en ontvoeringen.

Waarom kan de wet hier geen subsidiariteit en proportionaliteit toepassen? Moet iedere Nederlander in al zijn financiële doen en laten dag en nacht bespioneerd worden voor het geval dat? Moet elk met de pin betaalde WC bezoek tot het einde der tijden digitaal bewaard worden? Als er X dagen na een transactie geen grond van verdenking is, waarom moeten transactiegegevens dan niet verwijderd worden?

Voor zover het verwijderen van transactiegegevens wel degelijk verplicht is, kan de wet dit wellicht expliciet vermelden. Denk daarbij ook aan het verwijderen van het Bitcoin adres waar de klant op betaald is. Dit verwijderen is mogelijk technisch ingewikkeld, maar bij cryptovaluta van extra belang vanwege o.a. het bovengenoemde verhoogde risico op beroving.

Daarnaast dient opgemerkt te worden dat wisseldiensten en bewaarportemonnees vaak gebruik maken van zogenaamde cluster analyse, waarmee ze inzicht krijgen in de transacties van hun klanten en bv. de herkomst van coins kunnen natrekken. De aanbieders deze diensten zijn vaak buiten Nederland en zelfs buiten de EU gevestigd. Dit kan ertoe lijden dat gevoelige informatie van alle ​klanten buiten de landsgrenzen terecht komt, en mogelijk in handen valt van buitenlandse inlichtingendiensten die daar weer hun voordeel mee kunnen doen.

Onschuldpresumptie

Tevens wordt in dit wetsvoorstel m.i. de onschuldpresumptie in gevaar gebracht. Dit gezien de deels omgekeerde bewijslast in witwaszaken. Uiteraard zijn daar in de jurisprudentie beperkingen in aangebracht ter bescherming van een verdachte. Echter op het gebied van cryptovaluta bestaat momenteel zo bar weinig kennis en expertise binnen de rechterlijke macht en de advocatuur, dat een situatie ontstaan is waarin ik sterk vermoed dat sommige verdachten geen eerlijk proces krijgen.

Met name het gebruik van voor de verdediging oncontroleerbare clusteranalyse als black box bewijsmateriaal is zeer zorgwekkend. Als aanbieders van wisseldiensten en bewaar portefeuilles door deze wet ook (meer) clusteranalyse gaan toepassen en die vervolgens delen met handhavers, wordt dit probleem verergerd.

Met dank aan mr.drs. A.G. Haasnoot en enkele Twitter gebruikers voor feedback op de conceptversie van dit hoofdstuk en brief als geheel.

Van wie is deze bitcoin? — Deel II

Ik hou rechtspraak.nl in de gaten op uitspraken die iets met Bitcoin te maken hebben. De site publiceert slechts een selectie van alle zaken, waar ik in september 2018 al eens over schreef in het artikel Van wie is deze bitcoin?

Een van de dingen die me opvalt is het gebruik van cluster- en taint-analyse. Cluster analyse heeft als doel groepen adressen aan te wijzen die bij elkaar lijken te horen, bijvoorbeeld omdat het om één Bitcoin wallet gaat. Hoe dit werkt illustreerde ik eerder aan de hand van een fictief voorbeeld in A Crime on Testnet. Taint analyse kijkt op de blockchain naar de herkomst van coins en is te vergelijken met het ruiken aan contant geld om te zien of het ooit in een coffeeshop is geweest.

Op zowel cluster als taint analyse valt het nodige aan te merken, en ze lijken nogal klakkeloos te worden gecombineerd. Maar uit de openbare stukken is volstrekt onduidelijk hoe ze precies worden toegepast. Wat is de bron data (los van de blockhain), welke software wordt gebruikt en hoe verwerkt die software de data? Daarvoor moet je waarschijnlijk de strafdossiers zelf bestuderen.

Ik hou het dus maar bij een bloemlezing van wat wél af te leiden is uit openbare informatie.

In februari werd iemand in hoger beroep opnieuw veroordeeld voor onder andere witwassen. Twee opmerkelijke observaties:

1. HODL’n van je eigen criminele inkomsten kan niet tot een veroordeling voor witwassen leiden:

Voor zover er slechts sprake is van het voorhanden hebben van geld kan witwassen weliswaar bewezen worden, maar kan slechts worden gekomen tot een veroordeling te dier zake indien er sprake is van een handeling die erop is gericht de criminele opbrengst veilig te stellen. Zo van dat laatste geen sprake is zal moeten worden gekomen tot ontslag van alle rechtsvervolging. Dit laatste geldt ook indien het geld op een op eigen naam staande bankrekening in Nederland wordt gestort, omdat dit niet wordt aangemerkt als omzetten in de zin van artikel 420bis onder b Wetboek van Strafrecht. Worden met uit misdrijf verkregen geld goederen gekocht dan kan (wel) tot een veroordeling ter zake van witwassen worden gekomen. Dit laatste geldt vanzelfsprekend ook indien met bitcoins goederen worden betaald dan wel indien bitcoins worden overgedragen.

2. Als je naast criminele werkzaamheden ook legitiem verkregen Bitcoin hebt, moet je dat wel aannemelijk kunnen maken, en kan je beter niet op LocalBitcoins gaan handelen met diezelfde coins. Niet HODL’n leidde in dit geval alsnog tot een veroordeling voor witwassen.

Bitcoincluster #4

De verdachte heeft verklaard dat bitcoincluster #4 zijn privéwallet betrof. Met die wallet heeft hij gespeculeerd in bitcoins en heeft hij bitcoins voor derden omgezet in contant geld. Daarvoor ontving hij een commissie. Op Localbitcoins.com heeft hij geadverteerd met de dienst om bitcoins met contant geld te kopen. Hij werd benaderd door mensen die bitcoins wilden kopen en verkopen en bereid waren daarvoor een fee van zes tot tien procent te betalen. Hij maakte een afspraak met de verkoper om elkaar in het echt te ontmoeten. De bitcoins liet hij direct naar een exchanger sturen of naar zijn eigen wallet.

Het hof stelt in dit verband het volgende voorop. Voor een bewezenverklaring van het in artikel 420ter, eerste lid, onder b van het Wetboek van Strafrecht (hierna: Sr) opgenomen bestanddeel “afkomstig uit enig misdrijf”, is niet vereist dat uit de bewijsmiddelen moet kunnen worden afgeleid dat het desbetreffende voorwerp afkomstig is uit een nauwkeurig aangeduid misdrijf. Wel is vereist dat vaststaat dat het voorwerp afkomstig is uit enig misdrijf.

Indien op grond van de beschikbare bewijsmiddelen geen rechtstreeks verband valt te leggen tussen een voorwerp en een bepaald misdrijf, kan niettemin bewezen worden geacht dat een voorwerp “uit enig misdrijf” afkomstig is, indien het op grond van de vastgestelde feiten en omstandigheden niet anders kan zijn dan dat het in de tenlastelegging genoemde voorwerp uit enig misdrijf afkomstig is.

Het hof stelt vast dat uit de voorhanden zijnde bewijsmiddelen niet direct bewijs kan worden afgeleid dat de bitcoins die de verdachte met contant geld van derden heeft gekocht uit enig misdrijf afkomstig zijn.

Het hof is evenwel van oordeel dat het feitelijk handelen van de verdachte ten aanzien van het cashen voor derden, zoals ook omschreven in de zogenaamde witwastypologieën, een sterke aanwijzing oplevert voor het vermoeden van witwassen. De verdachte bood zijn diensten aan via internet op een vraag- en aanbodsite, rekende af in contanten en vroeg daarvoor een veel hogere commissie (8 tot 10 procent) dan de reguliere bitcoinexchanger Bitonic B.V. (0,5 tot 1 procent). Tijdens een voertuigcontrole in december 2014 is de verdachte staande gehouden. De verdachte heeft verklaard dat hij daardoor in paniek was geraakt en daarom zijn bitcoinadministratie van de hand heeft gedaan teneinde de anonimiteit te kunnen waarborgen.

Nu sprake is van een gerechtvaardigd vermoeden van witwassen, mag van de verdachte worden verlangd dat hij een concrete, min of meer verifieerbare en niet op voorhand hoogst onwaarschijnlijke verklaring geeft voor de legale herkomst van de bitcoins. Daarin is de verdachte niet geslaagd. Hij heeft verklaard dat hij onderkende dat het risico bestond dat hij bitcoins kreeg die geen legale herkomst hadden en dat het een grijs gebied betrof, maar dat zijn bitcoinhandel niettemin legaal was.

Het hof overweegt hieromtrent dat nu de verdachte een substantieel hogere marge hanteerde dan het door wisselkantoren als Bitonic gehanteerde tarief en zijn klanten desondanks bereid waren dit veel hogere tarief te betalen de enige logische verklaring daarvoor is dat zijn klanten anoniem wilden blijven. De verdachte heeft deze anonimiteit ook willen waarborgen, onder andere door (zoals hiervóór beschreven, na de voertuigcontrole) zijn bitcoinadministratie van de hand te doen. Hij heeft om dezelfde reden geen persoonlijke gegevens van zijn klanten kenbaar willen maken. Zijn verklaring kan dan ook niet worden aangemerkt als een concrete, min of meer verifieerbare verklaring over een alternatieve — legale — herkomst van de bitcoins. Een en ander klemt temeer indien daarbij in beschouwing wordt betrokken dat de verdachte zelf op de Darknet Market Silk Road verdovende middelen verkocht waarbij hetzij in contanten hetzij in bitcoins werd betaald.

Dit brengt mee dat ook ten aanzien van de bitcoins in cluster #4 bewezen kan worden dat de verdachte zich schuldig heeft gemaakt aan witwassen, waarbij — nu het niet gaat om uit eigen misdrijf afkomstige vermogensbestanddelen — de kwalificatieuitsluitingsgrond niet van toepassing is. Overwogen wordt nog dat voor zover in deze wallet bitcoins zitten met een legale herkomst er sprake is van vermenging, omdat niet meer met voldoende precisie kan worden vastgesteld welk aandeel zij vertegenwoordigen. In dit kader wordt nog verwezen naar hetgeen hiervoor over vermenging is opgemerkt.

Ik bespeur hier helaas nog wel de hardnekkige “mensen die voor privacy betalen zijn criminelen” gedachtengang. Het wordt wat verbloemd met termen als “witwastypologie”. Met andere woorden, iemand die voor privacy beaalt is weliswaar niet per definitie een criminineel, maar dient daar wel van verdacht te worden en moet zich dus verantwoorden. Als jij zaken doet met zo iemand, dan wordt je geacht hem te verdenken en om verantwoording te vragen. Zo niet, dan wordt jijzelf als verdachte gezien. Dit is ongetwijfeld heel effectief tegen misdaad, maar ook heel effectief tegen de geest van Artikel 10, lid 1 van de grondwet:

Ieder heeft, behoudens bij of krachtens de wet te stellen beperkingen, recht op eerbiediging van zijn persoonlijke levenssfeer.

Die “beperkingen” komen in het geval van geld neer op een de-facto totaalverbod op anonimiteit, dus géén persoonlijke levenssfeer. Er is altijd minimaal één bedrijf of instantie die iedere transactie moet monitoren en kan melden. Er is geen manier om daaraan te ontsnappen. De enige uitzondering is kleine hoeveelheden contant geld, maar daar kan je ook steeds minder mee.

Briefgeld kan overigens in principe via serienummers ook zeer goed getraceerd worden van pinautomaat (die weet wie je bent) tot winkel (voor zover ze geld afstorten en niet als wisselgeld teruggeven). Het is vreemd dat bij blockchains die traceerbaarheid steeds meer afgedwongen wordt, terwijl bij contant geld dat niet gebeurt. Waarom worden winkeliers niet verplicht om kassa-apparatuur aan te schaffen die briefgeld serienummers aan de klant koppelt?

On a warm summer day I crave a frappuccino. Unfortunately drugs such as caffeine, sugar and cacao were declared illegal decades ago. This happened because young unemployed college graduates often felt triggered by loud caffeinated rich people. Sugar was causing mass obesity and was also a carcinogen. Cacao was too clearly associated with oppression. These days hardly anyone remembers the reasons, they’re just shown pictures of cocaine addicts and are told cacao is a gateway drug to that.

Fortunately I know a guy, and he charges 0.002,000, — bitcoin. I spin up my Bitcoin Core wallet, because I like the retro look. It doesn’t even use comma’s after the decimal separator, something we all got used to during the hyper-deflation era. Some people would just say 2,000 Bitcoin, but don’t say that anywhere near a Core church!

Van wie is deze bitcoin?

This post is in Dutch. The short English version is in this Twitter thread:

Ik hou rechtspraak.nl in de gaten op uitspraken die iets met Bitcoin te maken hebben. De site publiceert slechts een selectie van alle zaken, maar er zitten juweeltjes tussen. Zo was er een systeembeheerder die, volgens de rechter onterecht, ontslagen werd omdat hij een Bitcoin mijn op kantoor gebouwd had. De meeste zaken gaan echter over witwassen.

Vaak is witwassen slechts een klein onderdeel van de zaak, en bitcoin een nog kleiner onderdeel. Dan wordt er bijvoorbeeld een bitcoin miner in een drugspand gevonden en 0.18 BTC, naast honderd kilo coke en oneindig veel contant geld. Omdat het slechts bijzaak is, wordt er soms niet scherp over nagedacht:

Verdachte zal worden vrijgesproken van het witwassen van 0,18 bitcoin. Weliswaar is dat bedrag aangetroffen in een bitcoinwallet die was gekoppeld aan de bitcoinminer die in hetzelfde drugspand stond, maar daarmee is niet gegeven dat het geld afkomstig is uit enig misdrijf. Sterker nog, het is juist aannemelijker dat het bedrag afkomstig is uit bitcoinmining en dat is een legale manier van bitcoins vergaren. Het enkele voorhanden hebben van een kleine hoeveelheid bitcoins levert evenmin een witwasvermoeden op. Dat betekent dat verdachte partieel zal worden vrijgesproken van feit 4, namelijk ten aanzien van 0,18 bitcoin.

Wat de rechter hier over het hoofd ziet, is de vraag hoe de electriciteit en de miner verkregen zijn.

Welke bitcoins […] heeft de verdachte daadwerkelijk voorhanden gehad?

Wanneer een bitcoinhandelaar verdacht wordt van witwassen, is een belangrijke vraag hoeveel bitcoins er zijn witgewassen. Dat roept de vraag op hoe je bewijst dat iemand bitcoins in handen heeft gehad.

Een zaak van 30 mei 2018 in Rotterdam ging ongebruikelijk gedetailleerd in op deze vraag, zie onderdeel 4.2.2 en 4.2.3 van de uitspraak.

4.2.2.1. Welke transacties vormen het verwijt dat aan de verdachte wordt gemaakt?

Het verwijt dat de verdachte wordt gemaakt, betreft het witwassen van bitcoins en de waarde die deze bitcoins vertegenwoordigen. Het dossier bevat […] de oorspronkelijke analyse. Daarin wordt ingegaan op alle bitcoins die de verdachte in de periode van 1 januari 2013 tot 19 januari 2016 gekocht zou hebben. AMB-197 met daarbij de documenten DOC-721 t/m DOC-724 bevat een hernieuwde analyse. [….] In de nieuwe analyse is door de FIOD gekeken welke bitcoinadressen van de verdachte […] welke bitcoins de verdachte heeft ontvangen […].

Er was dus een eerdere analyse die opnieuw gedaan is. Helaas zijn DOC-721 t/m DOC-724 niet gepubliceerd, dus er valt niks te zeggen over de kwaliteit van die analyse. Wellicht zijn die documenten via de WOB boven tafel te krijgen?

Ik concentreer me in dit artikel op één vraag, namelijk welke Bitcoin addressen bewijsbaar van de verdachte waren. De FIOD gaat tegelijk in op de vraag of de bitcoins op die adressen kosher waren. Dat is een totaal andere vraag waar ik een andere keer evt. op in kan gaan, vandaar de […] in diverse citaten. Ook de rechtbank behandelt deze vraag apart:

4.2.3.1. Aanpak van de rechtbank

De volgende stap van de beoordeling betreft de vraag welke bitcoins de verdachte heeft verkregen, voorhanden gehad, vervreemd etc, zoals de tekst van de tenlastelegging luidt. Daarvoor wordt eerst vastgesteld welke bitcoinadressen aan de verdachte toebehoren. Daarna zal binnen de hiervoor in § 4.2.2 aangegeven omlijning beoordeeld worden welke bitcointransacties met die adressen hebben plaatsgevonden.

Zowel voor het ontnemen van crimineel geld als het bepalen van de straf is het belangrijk om een correcte schatting te hebben van de hoeveelheid bitcoin (en welk deel daarvan criminele herkomst had, waar ik hier dus niet op in ga).

De bitcoins en geldbedragen die worden genoemd […] betreft dus alle bitcoins die de verdachte in de pleegperiode zou hebben gekocht. Het betreft dus ook bitcoins die […] een niet-criminele herkomst hebben. […] In de ontnemingszaak vordert de officier van justitie ook een bedrag dat daarop is gebaseerd.

Als het bedrag overschat wordt, gaat een verdachte te lang de bak in. Bij verkeerd gebruik van de beschikbare opsporingstools, met name zogenaamde clusteranalyse, is het vrij makkelijk om het bedrag te overschatten. Bitcoin is meestal ook niet gelijk verdeeld over alle adressen, dus één fout kan een totaal verkeerd beeld geven.

Gelet op het voorgaande zal de rechtbank er vanuit gaan dat bitcointransacties die niet voorkomen in DOC-724 niet (langer) door de officier van justitie en de FIOD als witwassen worden gezien en geen onderdeel uitmaken van het verwijt dat de verdachte wordt gemaakt. Het te beoordelen verwijt betreft dus 43.977,85923 bitcoins met een (gestelde) beurskoerswaarde van € 5.906.758,50 (DOC-724).

Dit bedrag is groot genoeg om een grondige analyse te rechtvaardigen, waardoor deze zaak dus erg interessant is.

Welke bitcoins uit DOC-724 heeft de verdachte daadwerkelijk voorhanden gehad?

Standpunt officier van justitie en FIOD

De FIOD heeft in DOC-680 een lijst opgenomen van bitcoinadressen die aan de verdachte worden toegeschreven. Het gaat in totaal om 98 adressen. In DOC-680 wordt steeds per adres aangeven op welke bron (bewijsmiddel) dit is gebaseerd en er wordt aangeven tot welke wallet het behoort. De adressen #1–66 hebben volgens de FIOD als bron DOC-218. Dat betreft gegevens afkomstig uit de telefoon van de verdachte. De adressen #67–81 zijn volgens de FIOD bitcoinadressen die de verdachte heeft aangeleverd aan de FIOD in het onderzoek IJsberg danwel aan de politie in verband met een aangifte van de verdachte tegen medeverdachte [naam medeverdachte 3] . Adres #82 heeft als bron DOC-679, een screenshot dat hierna nader wordt besproken. De adressen #83–98 zijn volgens de FIOD door middel van clusteranalyse aan de verdachte te koppelen.

DOC-680 zou ik uiteraard graag willen zien, maar indirect komen we wel wat te weten dankzij de tekst van de uitspraak.

De verdachte heeft […] een reactie per adres gegeven. Hij erkent dat de adressen 1, 2, 65–71, 73, 74, 76–81 van hem zijn. Van de overige adressen heeft hij aangegeven ofwel dat deze niet van hem zijn ofwel dat deze van hem zouden kunnen zijn.

Probeer even stil te staan bij wat je zelf zou doen als je — al dan niet in voorlopige hechtenis — een lijst met (minimaal) 98 addressen voorgeschoteld krijgt met de vraag of ze van jou zijn. Dan heb je wel een aantal geheugensteuntjes nodig.

Bitcoinadressen genoemd in emails

Sommige wallets sturen je een email bericht als je Bitcoin ontvangen of verzonden hebt. Handig, of niet?

Het leeuwendeel van de bitcoinadressen die blijkens DOC-680 zijn gevonden in de telefoon van de verdachte, betreft adressen genoemd in betalingsbevestigingen. Het gaat om e-mails afkomstig van blockchain.info en gericht aan [naam e-mailadres 1] en aan [naam e-mailadres 2] . Deze laatste twee e-mailadressen zijn van de verdachte. Die e‑mails bevatten bevestigingen van gedane danwel ontvangen bitcoin-betalingen. Onderdeel van die bevestiging zijn het nummer van een transactie, diverse bitcoinadressen en de vermelding van het aantal bitcoins.

Taalpurisme: het is “de hoeveelheid bitcoin” of “het bedrag in bitcoin”, niet “het aantal bitcoins”.

Anders dan de verdediging, is de rechtbank van oordeel dat verzendende bitcoinadressen, genoemd in verzendbevestigingen, en ontvangende bitcoinadressen genoemd in ontvangstbevestigingen, in beginsel aan de verdachte kunnen worden toegerekend. In zijn telefoon zijn immers aan hem gerichte bevestigingen aangetroffen dat vanuit danwel naar die adressen bitcoins zijn overgemaakt. Dat er geen bewijs is dat de verdachte ook beschikte over de private keys om die bitcoinadressen daadwerkelijk te kunnen beheren, doet daaraan niet af. Tegenover het vinden van de bevestigingen op zijn telefoon, mag van de verdachte een niet onaannemelijke alternatieve verklaring worden verwacht waarom die bevestigingen aan hem zijn verzonden.

Bovenstaande komt mij vrij redelijk over.

Adres #7 is een bitcoinadres dat afkomstig is uit DOC-218–053. Dit betreft een email van de verdachte aan zichzelf. De verdachte heeft in bijlage 6 bij de pleitnota aangegeven dat er meerdere redenen kunnen zijn waarom hij aan zichzelf deze mail heeft gestuurd, maar hij geeft geen concrete uitleg. Nu dit adres in de telefoon van de verdachte is aangetroffen, rekent de rechtbank dit aan hem toe.

Dit stond onder het kopje “uit telefoon of door de verdachte aangeleverd”, maar het gaat om email, dus ik noem het hier. Voor boekhouding kan ik spreadsheets van harte aanbevelen 🙂

Denk er overigens aan dat de politie niet de enige is die bij je email kan. Als iemand je mailbox gehackt heeft, treft hij een schat van informatie aan in de vorm van tienduizenden notificatie emails van allerlei bedrijven en instanties. Probeer de gewoonte te ontwikkelen die dingen te verwijderen i.p.v. te archiveren. Het zou mailprogrammamakers sieren om dat semi automatisch te doen.

Slordigheidsfoutje?

Adres #24–26

De verdachte stelt dat de adressen #24–26 ten onrechte aan hem zijn toegerekend. Hij stelt dat in de verzend- en ontvangstbevestigingen de verzendende adressen steeds links en de ontvangende adressen steeds rechts staan. De rechtbank stelt vast dat de FIOD de bevestigingen ook zo leest. De adressen #24–26 komen uit DOC-218–184. Dat betreft een ontvangstbevestiging. De adressen #24–26 staan in deze bevestiging aan de linkerzijde en het betreft dus verzendende adressen. Uit dit document kan dus niet afgeleid worden dat deze drie adressen van de verdachte zijn. De rechtbank vond in het dossier geen andere ontvangst- of verzendbevestiging op grond waarvan vastgesteld kan worden dat deze adressen (toch) aan de verdachte toebehoren. Deze adressen kunnen daarom niet aan hem worden toegerekend.

De kritiek dat ontvangende en verzendende adressen door elkaar gehaald zijn, geldt ook voor 18 andere adressen uit DOC-680. Voor 10 van die 18 adressen vond de rechtbank in het dossier een andere verzend- of ontvangstbevestiging waarmee dit adres alsnog met de verdachte in verband gebracht kon worden.

Het loont dus om goed te kijken of er geen slordigheidsfouten zitten in het bewijsmateriaal wat tegen je gebruikt wordt. Dit is ook een argument om i.i.g. sommige van deze documenten openbaar te maken, i.i.g. zolang dit soort onderzoek nog in de kinderschoenen staat. Vergeet niet dat de experts die dit soort fouten kunnen vinden disproportioneel voor de FIOD werken— en voor hun leveranciers zoals Chainalysis, niet voor de verdediging.

Adressen uit telefoon

Adres #82 betreft een adres afkomstig uit DOC-679. Het betreft een screenshot van blockchain.info . Blijkens de getuigenverklaring op zitting van twee FIOD medewerkers is tijdens de doorzoeking van de woning van de verdachte diens telefoon gevonden.

Een telefoon zonder encryptie?

Daarop is, zo hebben zij verklaard, een bitcoinadres gevonden dat door een van hen is overgetypt naar zijn eigen telefoon en daarvan is de betreffende screenshot gemaakt. Hoewel dit niet is geverbaliseerd, heeft de rechtbank er geen twijfel over dat het op deze manier is gegaan.

Of er hierbij mogelijk een typefout is gemaakt, zoals de verdediging als optie heeft geopperd, kan verder in het midden blijven.

Bitcoin adressen hebben een checksum. Een typefout lijdt vrijwel zeker tot een ongeldig adres en astronomisch onwaarschijnlijk tot een gebruikt adres.

Wat er ook zij van de vraag of dit adres van de verdachte was […]

(adres werd gebruikt in periode dat verdachte geimigreerd was en telt daarom niet mee voor deze zaak)

Watch-Only adressen

Een watch-only adres suggereert dat je interesse hebt in dat adres. Wellicht is het een cold storage adres van jezelf, waarvan je graag wil weten wanneer het gestolen wordt 🙂

In het stuk over de aangetroffen email meldingen:

De verklaring dat bepaalde adressen alleen door de verdachte werden bekeken, zogeheten watch only adressen, is geen geloofwaardige alternatieve uitleg voor de aanwezigheid van de bevestigingen op zijn telefoon. Het is weliswaar gebleken dat het technisch inderdaad mogelijk is om adressen te volgen op de wijze zoals door de verdachte beschreven. Echter, op 30 maart 2015 heeft de verdachte een e-mail gezonden aan de Duitse douane (DOC-675–005). In die e-mail schrijft de verdachte dat hij een screenshot toezendt van een bitcoin wallet ‘with overview of the addresses and their balances that I currently possess. Total balance is 52.7621 Bitcoins’. In het betreffende screenshot staan diverse bitcoinadressen, met een totaal aantal van 52,7621 bitcoins. Twee van die adressen zijn de adressen #72 en 75, waarvan de verdachte in deze procedure zegt dat het watch only adressen betreft. De uitleg die de verdachte op zitting hieraan heeft gegeven, heeft de rechtbank niet overtuigd. Feit is dat de verdachte tegenover de Duitse douane heeft bevestigd dat de adressen #72 en 75 van hem zijn. In deze strafzaak verklaart hij dat ze niet van hem zijn. Dat maakt dat zijn verklaring over watch only adressen geen geloofwaardige alternatieve verklaring vormt.

Adres #13, 29, 72 en 75

De verdachte heeft van deze adressen gesteld dat deze niet van hem zijn maar dat het watch only adressen betreft. Dit verweer slaagt niet om de redenen die hiervoor uiteengezet zijn [..]

Over #72 en #75 werd tegenstrijdige informatie gevonden in de correspondentie met de Duitse douane. Ik neem aan dat van #13 en #29 dus ook maar aangenomen wordt dat het geen watch-only adressen waren, omdat ze uit dezelfde bron komen als #72 en #75. Om te weten of dat een redelijke aanname is, zou ik DOC-680 moeten zien. Waren het bijvoorbeeld vergelijkbare email berichten van dezelfde wallet in dezelfde periode?

Bitcoin banken en beurzen

Andreas Antonopoulos zegt altijd: “not your private keys, not your bitcoin”

In principe ben je zelf veranwoordelijk voor het veilig bewaren van Bitcoin. Daarvoor gebruik je een wallet, bij voorkeur zelfs een full node. Nadeel is dat als je geen backup hebt, je coins echt kwijt zijn. Daarom laten mensen nog te vaak hun coins staan op de plek waar ze ze hebben aangekocht.

Dat zegt echter niks over eigendom, dus het volgende is vreemd:

Adres #64

De verdachte stelt van adres #64 dat deze niet van hem is, maar dat deze toebehoort aan [naam internetsite] van het bedrijf [naam bedrijf] . Adres #64 is blijkens DOC-680 afkomstig uit DOC-218–361, een lijst van bitcoinadressen (het adres staat op positie 349). Uit het dossier blijkt dat [naam bedrijf] een bestaande rechtspersoon is. De uitleg van de verdachte wordt niet weersproken door het dossier en de rechtbank sluit dit adres daarom uit.

“[naam bedrijf]” is net iets te vaag geanomiseerd; beter was bijvoorbeeld geweest “[naam Bitcoin beurs]” of “[naam webwinkel]”.

Als [naam bedrijf] een beurs is zoals Kraken en de verdachte daar zijn coins gestort heeft, dan zijn het nog steeds zijn coins. Een beurs kan echter één adres voor meerdere klanten gebruiken. Dat is bij het storten van geld niet handig, omdat er dan verwarring kan ontstaan over welke klant wat gestort heeft. Na de storting kan een beurs coins van klanten intern verplaatsen, en daarbij worden ze wel gecombineerd. Uitbetalingen kunnen probleemloos vanaf één adres aan meerdere klanten gedaan worden, sterker nog, dit scheelt transactiekosten. Wellicht werd dus bedoeld dat adres #64 een intern adres van een beurs was. Zonder DOC-218–361 is dat niet duidelijk.

Verderop stelt de rechtbank zich de vraag of de overige adressen mogelijk ook van iemand anders kunnen zijn:

Voor het verweer aangaande adres #64 geldt dat de rechtbank niet kan controleren of dit ook voor andere adressen zou kunnen gelden, de kennis die daarvoor nodig is zou van de verdachte moeten komen. Het had dan ook op zijn weg gelegen om zich hierover nader uit te laten.

Dit lijkt me omgekeerde bewijslast, en ook erg lastig om je tegen te verdedigen. Een verdachte moet dan voor elk adres zijn email archief en alle online accounts controleren om te zien of dat adres wellicht een storting- of opname adres van een beurs was. Maar wat als het een intern adres van een beurs was? Of wat als het adres helemaal niks met de verdachte te maken heeft?

Het lijkt mij dat de officier van justitie aannemelijk hoort te maken dat een adres niet van een derde partij, zoals een beurs, is. Dat kan bijvoorbeeld a.h.v. de email meldingen of een aangetroffen private key.

Clusteranalyse

Het basisidee achter clusteranalyse is als volgt: stel dat je weet dat adres A van de verdachte is, en dat A onderdeel is van een cluster adressen C, dan zijn alle adressen in C van de verdachte. Dat scheelt een hoop bewijslast voor individuele adressen. Er wordt royaal gebruik van gemaakt in de opsporing en in meerdere uitspraken worden “adres” en “cluster” bijna als synoniem gebruikt. Helaas deugt het niet.

Wat is een cluster? Daar is geen standaard definitie van, i.t.t. adressen waar wel een heldere definitie van is. Het hangt er vanaf wie je het vraagt. Bedrijven als Chainalysis en WalletExplorer beweren clusters te kunnen vinden a.d.h.v. hun geheime algoritmes.

Er is zover mij bekend geen enkel empirisch onderzoek waaruit blijkt in hoeverre gevonden clusters daadwerkelijk overeenkomen met adressen van een verdachte. Ook is mij geen enkel onderzoek bekend over de false positive rate, hoeveel bitcoin onterecht aan verdachten wordt toerekend door fouten. Het is ook niet makkelijk daar goed onderzoek naar te doen op een manier die de belangen van de verdachte niet schaadt.

Zelfs als cluster analyse werkt, is het maar de vraag of het juist toegepast wordt. Het is bijvoorbeeld belangrijk om van een cluster na te gaan of de adressen van de verdachte zelf of van een derde partij zijn. Als het om een wallet van de verdachte zelf dan zijn de overige adressen wellicht onderdeel van die wallet en daarmee ook eigendom van de verdachte. Maar een adres op een beurs als Kraken gaat of een custodial wallet als Coinbase, is onderdeel van een cluster van Kraken respectivelijk Coinbase, niet van de verdachte. Mixers kunnen ook roet in het eten gooien, doordat het kan lijken of meerdere wallets één wallet zijn. Het is niet publiek bekend in hoeverre de gebruikte tools hier goed rekening mee houden.

Het goede nieuws is dat i.t.t. eerdere zaken clusteranalyse hier slechts voor een beperkt deel van de adressen als (enige) bewijs gebruikt wordt.

De adressen #83–98 zijn afkomstig uit een clusteranalyse van de FIOD. De FIOD heeft met het programma Walletexplorer alle bekende (door de FIOD aan de verdachte toegerekende) adressen bekeken. Bekeken is steeds tot welke wallet een adres behoort en welke overige bitcoinadressen zich in die wallets bevonden. Dit heeft volgens DOC-680 geleid tot de adressen #83–98. Daaruit blijkt het volgende:

– de adressen 83–86 zouden onderdeel zijn van wallet [naam wallet 1] , welke wallet volgens DOC-680 ook de adressen #71 en 72 bevat;

– de adressen 87–90 zouden onderdeel zijn van wallet [naam wallet 2] , welke wallet volgens DOC-680 ook de adressen 39, 42 en 49 bevat;

– de adressen 91–98 zouden onderdeel zijn van wallet- [naam wallet 3] , welke wallet volgens DOC-680 ook de adressen 65 en 66 bevat.

Hier zie je dus hoe eerder bewezen adressen via een magische formule geassocieerd worden met nog niet bewezen adressen. Het bewijs ontbreekt dat [wallet 1] de adressen #71 en 72 bevat, maar een black box tool zegt dat het zo is, dus zal het wel zo zijn. Het is onmogelijk je hier tegen te verdedigen, maar men doet een dappere poging.

De verdediging heeft de clusteranalyse betwist op grond van de volgende argumenten:

A. Verschillende analysewebsites geven verschillende uitkomsten en dus werkt clusteranalyse kennelijk niet goed.

Dit is helaas niet de meest effectieve verdediging, zoals zal blijken. Clusteranalyse is namelijk onbewezen, maar dat betekent nog niet dat je altijd inconsistente resultaten krijgt. Iemand die geen heks is verdrinkt altijd.

(1) Wanneer adres #2 wordt bekeken met chainz.crytoid.info dan blijkt die website adres #2 niet toerekent aan een wallet. Bitcoin analyse website http://bitcoinwhoswho.com zegt daarentegen dat dit adres toebehoort aan de wallet MtGoxAndOthers .18 (2) Volgens DOC-680 behoort adres # 71 tot wallet [naam wallet 4] (net als de adressen #83–86), maar ook volgens Walletexplorer behoort dit adres niet toe tot deze wallet. (3) chainz.cryptoid.info legt geen verband tussen adres #83 en enige wallet. Van de adressen #83–86 staat volgens de verdediging daarom niet vast dat deze de verdachte toebehoren en hij ontkent dat ook.

In DOC-680 worden 14 adressen gekoppeld aan de wallet MtGoxAndOthers . Echter: Walletexplorer clustert meer dan drie miljoen adressen aan die wallet. Wanneer de logica van de FIOD wordt gevolgd dat een wallet aan één persoon of identiteit zou behoren, dan zouden al die adressen dus aan de verdachte moeten toebehoren. Dat toont volgens de verdediging aan dat Walletexplorer niet in staat is om op een juiste wijze de wallets en hun ID te clusteren en dat niet aangenomen kan worden dat de verdachte alle adressen bezit die in een door Walletexplorer gekoppelde wallet zitten.

Walletexplorer kan adressen vaak niet groeperen en geeft deze dan de wallet-ID “multiple”. Walletexplorer wordt toch door de FIOD gebruikt.

Walletexplorer is geen bekende analysetool. Blockchain.info wordt veel meer bezocht en is dus betrouwbaarder.

Deze zin slaat absoluut nergens op. Populariteit als maat voor kwaliteit? Zal de medische gemeenschap leuk vinden. Nog even los van dat voor zover ik weet blockchain.info geen cluster analyse aanbiedt.

In reactie op het verweer van de verdediging over de clustering van de adressen #83–86 heeft de FIOD in AMB-209 aangegeven dat deze adressen ook geclusterd worden met adres #72 door de tool Reactor, ontwikkeld door Chainalysis.

Dit geschilpunt wordt als volgt beoordeeld.

Deskundige Van Wegberg heeft over clusteranalyses in het algemeen gezegd dat dit een betrouwbare methode is om een gemeenschappelijke herkomst van bitcoinadressen vast te stellen. Hij kan niet zeggen 100%, maar wel zeer betrouwbaar. De analyse als zodanig wordt op dit moment volgens Wegberg door geen enkele wetenschapper betwist en hij noemt Walletexplorer en Chainalysis als mogelijke platformen.De rechtbank gaat uit van de juistheid van de verklaring van de deskundige en trekt hieruit de conclusie dat clusteranalyse als zodanig gebruikt kan worden, zij het dat er kennelijk een (beperkte) foutmarge in zit.

Het is mij een volstrekt raadsel waarom Van Wegberg dit zegt.

Ten eerste, zoals ik hierboven al aangaf, er is er geen emprisch onderzoek naar de effectiviteit en false positive rate.

Ten tweede, zoals ik ook al aangaf, kan een wetenschappelijk ondersteunde techniek verkeerd worden toegepast. Legio voorbeelden van onterechte veroordelingen a.h.v. vingerafdrukken en DNA analyse.

Ten derde is dit niet hoe wetenschap werkt. De reden dat we vertrouwen in relativiteitstheorie hebben is niet dat “geen enkele wetenschapper [het] betwist”, maar juist dat veel wetenschappers het fel betwist hebben. Keer op keer bedachten ze experimenten om te bewijzen dat de theorie niet klopt, en keer op keer was de uitslag van het experiment in lijn met wat Einstein verwachtte.

In het verlengde van het voorgaande is onvoldoende aangevoerd om te concluderen dat Walletexplorer als zodanig niet betrouwbaar is. De opmerkingen over de wijze waarop Walletexplorer omgaat met MtGoxAndOthers , zijn — zonder een nadere toelichting, die ontbreekt — niet relevant voor de adressen #83 e.v. MtGox was immers een bitcoinbeurs en uit de verklaring van [naam ontwikkelaar Walletexplorer] , de ontwikkelaar van Walletexplorer, blijkt dat MtGox was gehackt. Om dat te verhullen heeft de hacker adressen van MtGox samengevoegd met de adressen van gebruikers van SharedSend. Dit heeft ertoe geleid dat adressen van MtGoxAndOthers in Walletexplorer werden gecombineerd in één wallet. Zoals de FIOD en de verdediging het aanduiden: het is een vergaarbak. Mede gelet op de hiervoor bedoelde verklaring van Van Wegberg betekent dit niet dat alle andere wallets in Walletexplorer dus niet betrouwbaar zijn. Dat Walletexplorer de aanduiding ‘Multiple’ gebruikt, komt blijkens de verklaring van [naam ontwikkelaar Walletexplorer] doordat adressen van verschillende afzenders bij één transactie niet worden geclusterd.Ook dat doet dus geen afbreuk aan adressen die wel geclusterd kunnen worden door Walletexplorer.

MtGoxAndOthers was niet het handigste voorbeeld voor de verdediging, aangezien de fout van de website daar vrij redelijk te verklaren is. Sommige niet-heksen verdrinken nou eenmaal niet, soms.

Wat opvalt is dat zo’n verklaring altijd aanvullend bewijs vereist. Dat is precies mijn punt: je kan cluster analyse best voor een eerste indruk gebruiken, maar vervolgens moet je gewoon voor elk adres bewijs leveren. I.g.g. totdat er betrouwbare cijfers zijn over false positives.

De vraag is wat dit betekent voor de adressen #83–98.

Voor de adressen 83–86 geldt dat deze door Walletexplorer en Chainalysis, worden geclusterd met adres # 72, en door chainz.cryptoid.info niet. Walletexplorer en Chainalysis kunnen niet gezien worden als twee separate bevestigingen van de juistheid van de clustering. Immers, deze twee programma’s maken gebruik van hetzelfde kern-algoritme.

Wat wordt bedoeld met “kern-algoritme”? Beide programma’s gebruiken een geheim algoritme. Voor zover ze een “kern” gemeenschappelijk hebben, wie zegt dat de overeenkomsten daaruit volgt?

Nu het dossier geen inzicht geeft in de vraag waarom chainz.cryptoid.info voor deze adressen een andere uitkomst geeft en er geen andere link is tussen de verdachte en deze adressen, gaat de rechtbank in het voordeel van de verdachte ervan uit dat de adressen #83–86 niet van hem zijn.

Volgens deze logica kan een seriemoordenaar vrijspraak krijgen door een amateur DNA test op eBay te kopen die afwijkt van wat de NFI vond. Wat houdt iemand tegen om een super conservatieve block explorer website te runnen die van vrijwel alle addressen beweert dat ze niks met elkaar te maken hebben? Dit hele ritueel van black boxes met elkaar vergelijken door er willekeurig tegenaan te schoppen is belachelijk.

De adressen #91–98 […]. Voor deze adressen geldt dat het op de weg van de verdachte had gelegen om zich hierover nader uit te laten en niet te volstaan met de (voor hem gunstige) uitkomst op adres #83. Dit geldt te meer, zo overweegt de rechtbank ten overvloede, nu blijkens de publiek toegankelijke websites van Walletexplorer en chainz.cryptoid.info deze adressen door beide tools worden geclusterd.28,29

Publiek toegankelijk is een grote verbetering t.o.v. het geheime Chainanlysis, waar alleen de FIOD toegang tot heeft. Maar ze zijn niet open source, dus daarmee nog steeds een black box. Een openbare black box is beter dan een geheime blockbox, maar dat zegt niks over de betrouwbaarheid. En nogmaals, ook al was het open source, dan nog weten we niet wat de betrouwbaarheid is, want er is geen empirisch onderzoek naar gedaan.

De conclusie is dat het verweer tegen de clusteranalyse alleen slaagt wat betreft de adressen #83–86.

Nouja, da’s in ieder geval wat.

You may also want to use Tor for outbound connections:

proxy=127.0.0.1:9050

This disables listening, so you have turn that back on again:
listenonion=1
bind=127.0.0.1:8333

I agree with Scientastic’s privacy concern regarding bitnodes.com, but you can delete ~/.bitcoin/onion_private_key and restart bitcoind. A safer approach would be to start a node on another machine and try to add it as a peer, or just wait until inbound connects show up.

Bitcoin on an Orange Pi (using Armbian)

There are some good articles on how to run a Bitcoin Core full node on a Raspberry Pi. But there are other pies, some of which have better performance. That’s great news, because the Bitcoin blockchain has grown a lot recently, so any extra CPUs, RAM and storage are most welcome.

Step 1 — Buy a pi

Of the dozends of brands and hundreds of configurations out there, I bought the following three pies:

1. NanoPi Neo Plus2 (64-bit quad-core, 1 GB RAM, 8GB eMMC)
2. Orange Pi Plus 2E (32-bit quad core, 2 GB RAM, 16 GB eMMC, HDMI)
3. Khadas VIM2 Max (64-bit octa-core, 3 GB RAM, 64GB eMMC, HDMI)

This guide focusses on the Orange Pi because it supports an HDMI display, has a comfortable 16 GB of eMMC storage and appears to be much faster than than the NanoPi. It’s less than half the price of the Khadas. Finally, it works well with Armbian — see below.

I recommend a device with eMMC rather than just microSD. Bitcoin Core maintains a database of unspent transactions (UTXO). Every time a new block comes in, it needs to check if the coins spent in that block are actually spendable and then update which coins have been spent. That involves a lot of reading and writing, which is faster on an eMMC.

I also recommend at least 16 GB of (eMMC) storage. That’s not because of the blockchain — which can be pruned to as little as 500 MB by throwing away old blocks we no longer need. The UTXO set is several gigabytes and can’t be pruned, because without it you can’t verify if the transactions in a new block spend from existing outputs. Future UTXO set growth might crash your node if it only has 8 GB storage.

The more RAM the better, especially if you want to do more things with the device, though 1 GB might still work.

Be sure to check what’s in the box.

• connectivity: they all have wifi, but I wouldn’t count on that working immediately, so I suggest buying a UTP network cable, and make sure you can actually plug that into your model / router.
• keyboard interaction: some models have an HDMI port, so you can connect it to a monitor, in which case make sure you have an HDMI cable. You can then plugin any USB keyboard (e.g. the bluetooth Apple Magic Keyboard becomes a regular USB keyboard when you plug in a lightning cable).
• USB mouse (if you want a desktop)
• SD card writer (confusingly named “reader”); your computer might already have one, you’d be suprised…
• Power source: some devices need a 5V DC plug (of sufficient power), others use micro USB (usually 2A).
• Heat sink, probably… if the CPU gets too hot, it slows itself down (or worse). Bitcoin isn’t very CPU intense though , especially if you always leave it on— disk and memory speed is more often a bottleneck. A heat sink is sometimes included, e.g. the NanoPi-NEO heat sink.

Pretty much everything is made in Shenzhen and shipped from Hong Kong. If you live in the EU you may get slapped with VAT plus whatever arbitrary fee your local post monopoly charges to perform the admirable service of taking your money. Some companies ship from within Europe, which is faster and might end up cheaper.

Step 2 — Assemble a pi

IKEA time! Although the packaging material is plenty large enough to ship the device fully assembled, that wouldn’t be fun, would it?

In case of the NanoPi the manual didn’t explain how to assemble it, but there are plenty tutorials out there.

For the Orange Pi you just need to attach the casing using a screws.

Khadas comes completely assembled:

Step 3— Create an image for your pi

It takes 3 weeks for the Nanopi to download the blockchain, 5 days for the Orange Pi, slightly less for Khadas. Rather than wait for that, we’re going to do all the initial heavy lifiting on your main computer. That computer uses more electricity for a reason.

First we’ll download the blockchain and reduce its size from 200 GB to about half a gigabyte so it fits.

We then use Armbian to (automagically) compile Linux for your device, install Bitcoin Core and optionally add a desktop. It then copies the blockchain and creates an image for your SD card.

Armbian needs a specific version of Ubuntu to work so — unless you already use Ubuntu 18.04 — we’ll make a virtual machine using Virtual Box. You could also use a machine in the cloud like Amazon AWS.

Finally we burn the image on an SD card, boot the pi, copy it to the eMCC memory, restart, and presto!

Before you complain this is too much work, just remember:

“If you wish to make an apple pie from scratch, you must first invent the universe” — Carl Sagan

Bitcoin Core
Download and install Bitcoin Core on your computer and wait for the full blockchain to sync. A few hints, if you open the Preferences:

• set “Size of database cache” to 1 GB less than your RAM (though no more than 10 GB). This makes things a lot faster.
• click Open Configuration File and enter `prune=1`
• if you have less than 200 GB of free disk space, use`prune=...` instead, with the amount in megabytes (UI coming soon). Make it as large as possible, but leave at least 50 GB free space. When you’re done, you can reduce it all the way to 2 GB .Unfortunately pruning does slow down the initial sync.
• if you have an existing installation, make a copy of your bitcoin data directory (see below). Delete your wallet from the copy. If you don’t have space for a fully copy, you can also put this copy on a USB drive.

When it’s done, open Help -> Debug Window. Note the current block height, 529590 at the time of writing. Click on the console tab and enter: pruneblockchain 529590 . This deletes all earlier blocks.

Virtual box

Install Virtual Box for your operating system. If asked if you want Guest Editions, say yes. Download Ubuntu Server 18.04. In Virtual Box, click new, enter Armbrian as the name, select Linux from the list of operating systems and Ubuntu (64 bit) should already be selected.

Press next, skip the question about RAM (we’ll change that later), click next again to create a new virtual disk, select Fixed Size when asked and give it 30 GB.

Once the machine is created, right click on it and choose settings. In the System tab under Processor, give it as many CPU’s as you have, but limit them to 90% so your machine doesn’t freeze.

Under Motherboard, give it at least 4 GB RAM, or 2 GB for every CPU you have, whichever is more. Leave enough for the rest of your computer, bearing in mind that until the blockchain finishes downloading, Bitcoin Core also needs RAM.

In the Storage tab, it should show a CD icon that says “empty”. Click on it and select the other CD icon on the right, “choose virtual disk image” and look for the Ubuntu file you downloaded.

Now start the virtual machine and follow the installation, which is mostly a matter of hitting Enter, but there may be a few places where the default is No, to keep you alert. For your name, the hostname, username I suggest armbrian. After a reboot you should be good to go and you’ll see a login prompt.

Go to Devices menu -> Insert Guest Additions CD image. The script in the next section will need this.

If you prefer to login to your virtual machine via SSH, see this. Also note that you can right click on a machine to launch it headless, just don’t forget to turn it off (and you can’t insert the guest editions CD).

Armbian

Now it’s time for the good stuff. I created armbian-bitcoin-core to make things a lot easier. It also has a README, which should be kept more up to date than this blog post.

On the virtual machine:

git clone https://github.com/Sjors/armbian-bitcoin-core.git
./armbian-bitcoin-core/prepare-build.sh -g -b 32 v0.16.1

Select your pi device from the list, sit back and relax. This will take a while (add -j N where N is the number of CPUs). If all goes well, you’ll see something like:

[ o.k. ] Done building [ /home/armbian/build/output/images/Armbian_5.46_Nanopineoplus2_Ubuntu_bionic_next_4.14.48.img ]

[ o.k. ] Runtime [ 113 min ]

Put image on SD card

Use Etcher to put the resulting .img file on an SD card.

Copy from SD card to pi

Both the Nanopi and Orange Pi will boot from an SD card if one is inserted. The Khadas has a more complicated process involving a USB cable and potentially also a Windows (virtual) machine.

After boot, you’ll be greeted by a login screen. Your password is “bitcoin” and you’ll be required to pick a new one immediately. You can already enjoy Bitcoin Core, but it’s much faster to copy everything to eMMC memory first. Click on Applications -> Terminal Emulator.

Enter: sudo nand-sata-install and say yes a few times. It will offer to shut down the machine when it’s done. Remove eMMC card from device and reboot (you may need to unplug the device).

Profit

Login again, double click on the Bitcoin Core icon and enjoy! I suggest leaving it running permanently as it will take quite long to catch up once it falls behind.

Bonus — Lightning

Add -l c to the prepare-build.sh command to install c-lightning. There’s no desktop app for that though and it still has some issues with pruned nodes, so this is quite experimental.

Bitcoin Core + Lightning + Rails on AWS

Recently I’ve been working on a project code-named Matreon. It’s like Patreon, but for the matriarchy. In a world of increasing online censorship, being able to host your own website and process your own payments really helps.

Matreon is self-hosted, which means you’re no longer dependent on the whims of one CEO or some untransparant content. It uses Bitcoin and the Lightning network, so you no longer have to worry about demonetization policies. I’m working on making it as easy as possible to deploy on AWS, the steps are described below.

Hosting is complicated. It’s always been that way, which explains the success of SAAS companies. Other than WordPress, very few people run anything on their own server. I think that created a bit of chicken-egg problem, where pretty much only the WordPress comunity worked on making that process easier. There are great tools out there, but they’re mostly optimized to make life easier for devops folks or for software developers to deploy their own application. There’s not really a generic easy to use host-your-own SAAS tool.

Current status: quite experimental, you might still lose all your money!

Step 1: Create an Amazon account and obtain a login key

Go to the KeyPairs page of the Amazon Web Services management console. If you don’t have an AWS account yet, click the Create a new AWS account button. You’ll get some free credits, which may or may not be useful here; otherwise expect to spend approximately $25 per month (unless someone helps reduce that).

Only you have access to your server. Amazon will create a key for you that you should download and backup. Without that key you’ll lose access to both your money and your fan database.

Enter “Matreon” as the name. Your browser should automatically download and open a text file like this:

For now, keep this somewhere save. You won’t need it until there’s money on the machine that you need to take out. Or until you can’t resist curiousity to see what the machine is doing. Or until something breaks.

Step 2: Start the Amazon Cloud Formation wizard

I created an Amazon Cloud Formation template which automates the steps of spinning up a server and installing all the required software. You just need to fill out a small form and perform a few manual steps. It should be about as easy as installing your own WordPress, which people still do.

Click the launch button above and fill out the following form:

• KeyName: the key you just created in Step 1
• Bugs Email: if anything goes wrong on the server, more detailed debug information is sent to the bugs address you should provide. Don’t even think about entering my email there 🙂
• Network: Switch the network from testnet to bitcoin (mainnet) if you’re feeling lucky.
• Prefix: if you really don’t want an https certificate, or if that fails, switch to http.
• Domain: the name of your (sub)domain that you intend to point to this server. It’s used in the emails your server sends out.
• From Email: enter an email address that’s used as the sender for emails sent by your server, such as the montly invoices to your fans.
• SMTP: in order to send email you’ll need to provide SMTP server details. One approach is to get those from your own email provider, but be very careful if the password for that is the same as your email login; if your server is ever compromised, the hacker would be able to get into your inbox. A service like Fastmail lets you generate a password specifically for SMTP, which can therefor only be used to send email, not to read it:

Alternatively, and perhaps better, is to use Amazon’s SES SMTP service. They require you to go through a number of verification steps in order to prevent spam.

Click Create, which takes you to CloudFormation management console where you can follow the progress:

Click on “Matreon” to see more details of the work in progress.

Step 3: Wait… then eat your brain

Downloading the blockchain takes about 25 minutes on testnet and about 4 hours on mainnet. The status should change from CREATE_IN_PROGRESS to CREATE_COMPLETE.

In order to download the blockchain in hours rather than weeks, we use a high performance virtual machine*. Similar to how a sea squirt eats its own brain when it finds a place to stay and no longer needs to swim, you should downgrade to a cheaper machine once the blockchain has been downloaded.

Click on Matreon (the stack name) and look under resources. Click the link next to WebServer i-xxxxxxxxxx which takes you to the EC2 instance management page. You’ll notice the instance type is m5.4xlarge.

Click on the Actions button -> Instance State -> Stop. Wait until the instance is stopped. Click on the Actions button again -> Instance Settings -> Change instance type and choose t2.small.

Finally, start the instance. A few minutes later the hour glass and Initializing under Status Checks should change into a nice green check mark. It may still take few minutes after that before the site is live.

Step 4 — Configure HTTPS (by doing very little)

Configuring HTTPS has always been a major pain. It still is, but for you. For you it just works*. All you need to do is add a single DNS entry, sit back and wait.

Add an A record to point your subdomain to the server. You’ll find the IP address under Outputs.

matreon.example.com.  A  18.194.87.12

Behind the scenes the server is waiting until it sees this record. It then instructs EFF’s Certbot to request a certificate, using the domain and email address you filled out before. It also makes sure it gets renewed on time.

*=unless it doesn’t work 🙂

Step 5: Tell the world, profit!

It’s still pretty bare bones, but your fans can now sign up:

If you have your own lightning node somewhere, it helps to connect to your Matron Lightning node. That way your fans hopefully immedidately have a route to the node and don’t need to open a channel first.

The problem with manual invoice payments is that it leads to high churn. Apart from email delivery problems, every time a user makes a manual payment they’re rethinking their commitment. There’s currently no protocol for repeating payments in either Bitcoin or Lightning. I’d like to work on potential solutions.

One simple approach I have in mind is a direct debit system, where the user’s wallet gives another node permission to withdraw up to N satoshi each time period. A merchant would send a message with a payment request (via similar onion-like routing as regular payments, trying again later if the user can’t be reached). The user’s wallet would then wait a certain number of days, where the user can still cancel it, before making the payment.

This is potentially much easier to do in Lightning than with regular Bitcoin, because nodes have public keys and there is a routing mechanism in place. Being behind a NAT might make this more difficult, but that’s another good reason for more people to use Tor.

Login to your machine

First, you need to save that key you downloaded in Step 1. On on macOS, you would open a terminal window (hit Command + Space and type “terminal”). Assuming it’s in your download folder, move the key to the right place and limit access to it:

mv ~/Downloads/Matreon.pem.txt ~/.ssh/matreon.pem
chmod 400 ~/.ssh/matreon.pem

If you get an error that the .ssh doesn’t exist, then you first need to generate an SSH key. Github has good instructions (you can skip the SSH agent bit for now).

Go to the Instances list in the EC2 Management console:

Copy the value next to Public DNS (IPv4). Your username will be ec2-userand you need to tell SSH to use the right key:

ssh ec2-user@ec2-18-194-87-12.eu-central-1.compute.amazonaws.com -i ~/.ssh/matreon.pem

To follow installation progress:

tail -f /var/log/cfn-init-cmd.log

After about ten minutes it will be waiting for the blockchain to download, which you monitor here:

sudo -s
tail -f /mnt/ssd/bitcoin/testnet3/debug.log

After installation and reboot, you can monitor all services:

journalctl -xe -f

Take your profits

So how do you get your money out? I’d like to find a better solution for this, but for now you just have to login to the machine and issue some commands to the Lightning wallet.

You’ll need a Bitcoin wallet to receive the funds with. Have it generate a fresh address and have that at hand.

Let’s see how much money you have:

sudo -s
su - bitcoin
lightning-cli listfunds

{
"outputs": [],
"channels": [{
"peer_id": "020275fd0dea2354e40f6ed789fb5bb9bcad54944e4193315b7166ba6d24e416bf",
"short_channel_id": "1297288:77:0",
"channel_sat": 1,
"channel_total_sat": 100000,

outputs lists bitcoin that is not in a channel. Sending those on-chain funds works like any other bitcoin transfer (with ditto fees):

lightning-cli withdraw DESTINATION_ADDRESS all

For each channel, channel_sat is the number of satoshi on your side of the channel. For the time being, you can’t combine funds from multiple channels, although there are proposals. In order to move those off-chain funds you need to have a Lightning wallet that can receive payments (e.g. Eclair for Android can only send payments at the moment). Use that other wallet to create an invoice with the amount slightly below your balance. Then pay it by copy-pasting:

lightning-cli pay INVOICE

You can’t specificy which channel to spend from, so it’s best to start with the largest amount.

In order to pay you, at least one person must have opened a channel to your server, possibly one of your fans but it could have been anyone. Others would then reuse that connection (i.e. their payment “just works”) or they might open a channel to you as well. Eventually one or more of these channels may end up closed, causing your bitcoin to be split between so called on-chain and off-chain funds.

Automating this would require similar, but simpler, changes than those needed for recurring payments. The assumption is that you have your own Lightning wallet somewhere safe, though not necessarily online 24/7 and not necessarily on a fixed IP. The server would regularly forward off-chain payments to your other wallet. All that’s needed for that is a protocol to route a message to an arbitrary node with “please take my money”.

In addition I set up an ad hoc way to financially support the project: send bitcoin to bc1qcpersad0kxwt8s83uuhrp5rtufllxq77mugj08 and use last 5 digits to indicate a Github issue number. E.g. if you send 100004 satoshi then that goes towards whoever — which could be me — fixes GPG mail support. Please get in touch before sending huge amounts, because that might open a can of worms regarding taxation and such.

Initial Blockchain Download machine

*=i3.2xlarge with 8 CPUs, 61 GB of RAM and a 1.9 TB SSD drive. Three things seem to matter:

1. 10 GB of RAM which allows the UTXO set and some indexes to be held in RAM throghout the entire process.
2. Enough storage to store the entire blockchain. In order to save long term storage cost ($20 / month for 200 GB), we prune the blockchain to 2 GB. However pruning during the initial download seriously hurts performance (at least a factor two). This is because every time blocks are pruned there’s disk I/O. Worse, the cache is flushed to a few hundred MB, so you’re not taking advantage of RAM. The trick is to download and process the entire chain, then prune and copy the remaining few GB to the regular disk. The SSD drive nicely disappears after you downgrade the machine.
3. 8 CPU’s. These don’t really do much until you reach recent blocks; Bitcoin Core skips signature verification for blocks before the last release date. Also apparantly adding more doesn’t help.

Four hours, at a cost of about $4, seems to be about as good as it gets on cloud machines. You might be able to speed it up a bit, without adding trust, by:

• downloading block files from S3 storage instance; if verification fails, the node will just fall back to the P2P network. But who pays for that?
• downloading an already processed database and merely verify it (again, if verification fails, it falls back to downloading and/or processing from scratch)
• split the task in N chunks, one for each machine, e.g. block 0 — 350,000, block 350,000–400,000, block 400,000–450,000, etc. Each node starts with a pre-loaded blockchain synced to the start of their chunk, and then sync to the end of their chunk and then compare checksums. Again, if that fails, fall back to downoading and processing the whole thing.

Bitcoin Core Wishlist

I started to contribute code and reviews to Bitcoin Core a few months ago and gradually accumulated lists of stuff I’d like to see. Some of these I can do myself, others are still beyond my level of expertise, still others might be terrible ideas and never happen.

A note on process

Just to make it abundantly clear: this is my personal wish list, not anyone’s roadmap. There is no roadmap, there’s just stuff in progress. Every contributor has their own things they’re working on, their own set of priorities.

A pull request generally gets merged if and only if:
1. it has received enough review, by relevant experts; and
2. there are no unresolved objections, e.g.
 a) it is of sufficient quality;
 b) it doesn’t break things;
 c) it doesn’t cause more problems than it solves

Criterion (2) is easiest to deal with as a developer: if someone reviews your code and they find a problem, either fix it or explain why it’s not actually a problem. There are also automated tests and other (e.g. formatting) checks that save reviewers time. It’s not uncommon to revise a pull request a dozen times until it’s good enough.

Criterion (1) can be a bottleneck. If helps to work on stuff you know other developers care about. Hence this list; if you work on anything on this list, or stuff that indirectly makes this list more likely to move forward, your chances of me reviewing your code increase.

There’s other ways to increase the chance of getting your code reviewed. Keep changes small and focussed. The more stuff you change in a single pull request, the more difficult it becomes to review and the fewer developers even have the prerequisite knowledge to understand all of it. Use a clear title and description, add a screenshot if it’s a UI change, and keep these up to date when you change things.

In order to keep things moving after the first feedback you receive, it helps to actually address that feedback and to do so quickly, as this motivates reviewers. Even the most experience Core developers sometimes have to wait up to a year to get stuff merged, so patience is useful.

Anyway, here’s my list:

Better Replace-By-Fee UI

• Github issues: #11717, #12676, #12271, #12096, #12565, mailinglist

People may forgotten the days of high fees, but those days will probably return some day. If you’re not in a hurry to send a transaction it’s a good idea to set a low fee. However, that may cause it to get stuck, especially if fees rise after you send it.

If a transaction gets stuck, you can replace it with a transacion that pays a higher fee. Just right-click on it and select Increase Transaction Fee, et voila:

Unfortuately this UI is rather inflexible. It doesn’t let the user specify the new fee, nor provide any hint what a good amount would be. Due to implementation details the fee can’t be more than the change amount of the original transaction (and doesn’t work if the original transaction doesn’t have a change address), a restriction that’s hard to explain to the user.

The solution probably consists of automatically adding new inputs to the transaction as needed, as well as reusing the existing fee recommendation UI.

We could go beyond that, e.g.

• pre-generate a series of transactions with escalating fees, so that a user can specificy a deadline and maximum fee. The wallet would then broadcast these as the deadline approaches
• append new transactions to existing unconfirmed transactions
• peer2peer mixing, i.e. mempool compression (kidding… or am I?)

Needless to say, all the above is surprisingly non-trivial and there’s some privacy issues and safety gotcha’s as well.

An additional complexity here is that the GUI and RPC have different ways of composing a transaction, which could lead to duplicate work.

Hardware Wallet

Hardware wallets like the Ledger Nano S keep your private keys very safe, but they rely on a web based backend to show your balance and compose transactions. Only signing happens on the device. This is not ideal for privacy and if their servers disappear you most likely have to fall back to paper backups.

At the same time, Bitcoin Core saves your private keys on your machine

So I’d like to be able to use a hardware wallet directly with Bitcoin Core.

User friendly backup and recovery

Most consumer wallets nowadays tell the user to write down a 12–24 word phrase and keep it somewhere save. They also tend to strongly remind users to do so. Bitcoin Core does have backup functionality and it’s present in the UI, but I’m not sold on it. I haven’t had a chance to really dig into this topic, so I’ll keep this section vague.

More broadly, I have a seperate wish list of stuff I’d like to see improved around recovery phrases and hierarchical deterministic wallets.

Prune UI

Github issues: #6461, #12404

I suspect more people would run a full node if they knew it didn’t eat 180 GB of their precious hard disk space. It’s trivial to enable pruning, i.e. just open bitcoin.conf, add prune=10000 and restart to prune to ~10 GB. However I’d like to lower that barrier even further, e.g. by having the wallet check the users disk space on first launch. If it’s not huge, propose some reasonable number.

A related issue is that pruned nodes currently are quite slow to sync due to implementaiton details, but that should be easy to solve.

Somewhat related, performance is still not great for non-SSD drives: #12058.

Run full node on iPhone X

• Github issue #11720 iOS Deployment Target for RPC, $200 bounty

Whether or not it’s useful remains to be determined, but I bought an iPhone X with 256 GB of storage, which means it fits the entire blockchain. That’s enough reason for me to want to run a full node on it, but I need some help figuring out build pipeline magic and getting it to interact with an iOs app.

Fiat amounts

This is probably a bit controversial, but I as long as other people in the real world use things like euros, I’d like to be able to see how much I’m about to send in fiat terms. However you can’t just fetch a price feed from an external website. For example that would reveal the users IP, which combined with the timing of requests could be enough to reveal a users addresses. Then there’s the issue of which price to trust. But now I find myself googling conversion rates for the exact amount I’m about to send, which can’t possibly be good for my privacy. 🙂 Any creative solutions out there?

Easier deterministic (Gitian) builds and verification

How do you know the program you downloaded is actually based on the Bitcoin Core source code? Every release a number of developers make a deterministic build and publicly attest to it. It’s getting easier for more developers to do so. There’s probably enough eyes on this to make that any funny business with the public release would be caught, but perhaps not for indiduals to see if they’re indivually targetted.

This is already a huge improvement over the pervasive App Store model where you just blindly trust Apple, Google or Microsoft to not mess with the software, which they automatically update, while you’re logged into an account with them that has all your personal details. However I think this process — of developers publicly comitting to specific source code for every update, and each computer verifying this — should be the norm for all software, and for that it needs to be made much easier.