I wanted to get an order of magnitude sense of the utility of non-medical masks. Specifically their usefulness against floating droplets at a reasonable distance, and not from someone coughing loudly; those people can easily be avoided. In addition I focus on short term exposure. In other words, should I worry when waiting in an orderly line to order my take out frappuccino?
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:
- Traveling to North Korea after being explicitly denied permission
- Providing any kind of service to North Korea without permission (banned by Trumps executive order 13722)
- Giving a presentation about “blockchain technology”, emphasising its hypothetical usefulness for sanctions evasion, based solely on publicly known information
- 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?
Regarding both (3) and (4), the inditement goes to great lengths to accuse him of actually assisting in transferring funds out of North Korea:
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:
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.
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:
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.
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.
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.
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:
You may want to turn off transaction email notifications, and ask your favorite wallet provider to use PGP.
— Sjors Provoost (@provoost) September 3, 2018
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.
You may also want to use Tor for outbound connections:
This disables listening, so you have turn that back on again:
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:
- NanoPi Neo Plus2 (64-bit quad-core, 1 GB RAM, 8GB eMMC)
- Orange Pi Plus 2E (32-bit quad core, 2 GB RAM, 16 GB eMMC, HDMI)
- 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
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
- 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.
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).
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.
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).
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
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
- 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
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
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
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.
A record to point your subdomain to the server. You’ll find the IP address under Outputs.
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 firstname.lastname@example.org -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:
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:
su - bitcoin
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:
- 10 GB of RAM which allows the UTXO set and some indexes to be held in RAM throghout the entire process.
- 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.
- 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.