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?
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:
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.
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.
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!
You may also want to use Tor for outbound connections:
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.
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.
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.
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.
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 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.
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.
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.
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.