Gavin Andresen

Writings about geeky stuff

Read this first

tornado

tornado is a smart contract running on Ethereum.

When I say smart, I mean really wicked-smart; it uses “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge” cryptography (ZkSNARK) so the ether (or tokens) deposited into the contract can’t be linked to those that are withdrawn.

But… I won’t be surprised if there is a paper at the Financial Cryptography 2023 conference showing that 85% of tornado usage was not private; not because the cryptography is broken, but because it is really hard for mere mortals to use something like tornado (or CoinJoin or other similar technologies) in a way that doesn’t leak information about their wallet. The tornado developers wrote an article with tips to help maintain privacy, but I think 62% of their users won’t read it and another 25% will read it and then immediately do something the article says you shouldn’t do.

I think the mistake most...

Continue reading →


A more private ETH wallet?

In my last blog post, I said that tornado is a fantastic building block that will let some clever developers build a much more private Ethereum wallet. In this post I’m going to describe the wallet I’d like to use.

I’ll sacrifice a little privacy for lots of convenience

I don’t want to have to think about anonymity sets or unspent transaction outputs, and I’m not going to keep track of separate ‘accounts’ for everyone I interact with financially. I want an opinionated wallet that doesn’t ask me a lot of questions, but is easy to use and makes it a lot harder for somebody to see what I’m doing by tracking transactions on the blockchain.

Setup

Ideally, setting up / backing up the wallet is just “write down these twelve words…” and that master private key is used to generate (or re-generate if I’m restoring the wallet) all the secrets needed.

If data has to be backed up somewhere other...

Continue reading →


Not as rich as you think…

People assume that the people who worked on Bitcoin in the early years are fabulously wealthy.

That’s a bad assumption, for lots of reasons:

It was easy to lose coins. They weren’t worth much, so people didn’t bother to take the time to keep them secure and back them up.

Many of the early developers didn’t have extra money to buy coins; they were still in school, or were pouring all of their money into a startup. Venture capitalists were NOT throwing money at Bitcoin startups back in 2010 and 2011.

“HODL” wasn’t a thing– instead, bootstrapping the community by purchasing things (like 50BTC alpaca socks or 10,000BTC pizzas) or giving away Bitcoin was encouraged.

Even if an early developer had the free cash and foresight to purchase a bunch of coins, they might be level-headed and follow tried and true investment advice to:

1) Make a long-term plan and stick to it, ignoring...

Continue reading →


Practice Safe Signing

Are you holding some cryptocurrency secured by a paper wallet in a safe deposit box? Good for you! That’s an excellent way to keep it safe.

But then your currency splits. Last week that piece of paper was worth 100 FooCoins, and this week it is worth 100 FooCoins and 100 BarCoins.

If you think one side of the split is a terrible idea, doomed to fail, you might be tempted to go get your paper wallet, “sweep” the coins into a wallet that supports the bad coin, and move them to an exchange to cash out (or maybe buy more of the good coin).

Great! I don’t give investment advice. But I will encourage you to sweep the “good” coins, first, and move them to a new wallet. Don’t be lazy and just write “BadCoins swept Nov 11, 2017” on the paper wallet and put it back in the vault.

Why?

Because sooner or later I think somebody will create a BadCoin (or a wallet) with a transaction signature...

Continue reading →


Keeping it simple

Let’s say you’re the leader of an open source implementation of Bitcoin, and you decide to follow my advice and Know Your Customer.

And you decide your customer is primarily big mining pools and businesses that just want a “full node” that runs on the network. Immediately after making that big decision, you can make your life much simpler by doing a lot less.

You can drop any code related to maintaining a wallet; big businesses and mining pools will have their own multisignature-secure wallets and will have somebody who’s job it is to make sure they stay secure.

You can drop (or drastically cut back) any graphical user interface code, and can drop support for Windows and Mac. Your customers will almost certainly tell you they run Linux boxes maintained by sysadmins who aren’t afraid of terminal windows.

You can drop “deterministic builds” – in fact, you can probably drop packaging...

Continue reading →


Know your customer

When Satoshi released the first windows-only Bitcoin binaries to the world, it had to do everything. It was a wallet and a miner and every running node was precious, because with only a handful of nodes the network was fragile.

While I was lead developer even more functionality was added– mostly developer-friendly hooks (additions to the JSON-RPC programming interface) to make it easier for people to build stuff for what was then a tiny community.

I was the only full-time Bitcoin developer for a couple of years, and I tried to write code for things I thought would have the highest impact that other people weren’t already doing. Usually that was something boring but really important (like the testnet, the unit testing framework, or the regression testing framework; my last major code contribution was a performance benchmarking framework). But sometimes I had time to work on new stuff...

Continue reading →


Ask a simple question…

This is a conversation with Matt Corallo (Bitcoin Core contributor) that started on twitter and migrated into email:

Matt Corallo @TheBlueMatt - Mar 19
Bitcoin Core does not want to and does not make decisions on Bitcoin’s consensus rules

Gavin Andresen @gavinandresen - Mar 23
Might a small, well-tested patch that added a default-false option to disable block-size checks be accepted by Core?

Matt Corallo
if it a) took HF risks seriously and had protections for then and b) had community consensus to do a HF, sure!

Gavin Andresen
I’ll email you– if you really don’t want to dictate consensus rules, give your users a choice!

Matt Corallo
cool. You may also want to check out some of the HF proposals at https://bitcoinhardforkresearch.github.io

From: Gavin
To: Matt
Subject: Expanding an idea from Twitter…

If Core really wants to avoid taking sides in the Great Scaling Debate, why not...

Continue reading →


Other definitions of Bitcoin

Yesterday’s post triggered some interesting discussion on reddit and twitter.

I realize now I should have been more specific– when I said “technical definition of Bitcoin” I meant a couple of things:

I am thinking of what Bitcoin is today and in the near future, not what it might eventually evolve into. While it is fun to talk about what Bitcoin will be in 100 years, that wasn’t the point of my blog post. I didn’t mean to imply that any definition of what Bitcoin is today and in the near future would somehow be iron-clad and binding and never change; thinking you can control how a technology evolves is even sillier than thinking you’ll be able to predict beyond a decade or maybe two.

I also want a definition that could be useful in determining which of two competing ledgers a neutral geek would point at and say “that one is Bitcoin as described in the original Bitcoin whitepaper”. It...

Continue reading →


A definition of “Bitcoin”

Engineers are great at not seeing the forest for the trees. They get stuck on details and lose track of the bigger picture.

I’ve seen it most often (and have been guilty myself) when they’re optimizing something to make it faster. They’ll start out OK– “it is taking eleven seconds to agitate the snarks, and seven seconds of that is just precomputing the eigenwidgets!”

So they’ll take a day and make precomputing the eigenwidgets ten times faster.

And then realize with just a little tweaking and a really nifty algorithm and two hundred more lines of code they can make it one hundred times faster!

So they spend a few days making snark agitation take 0.63 seconds faster (4.07 seconds instead of 4.7 seconds), instead of moving on to the next performance bottleneck. They can become focused on one little thing (Performance of this routine! or Security! or Decentralization! or...

Continue reading →


Either/or : ignore!

Now that six months have gone past, I’m being asked if I still think Craig Wright was Satoshi.

I think there are two possibilities.

Either he was Satoshi, but really wants the world to think he isn’t, so he created an impossible-to-untangle web of truths, half-truths and lies. And ruined his reputation in the process.

If he was Satoshi, we should respect his wish to remain anonymous, and ignore him.

The other possibility is he is a master scammer/fraudster who managed to trick some pretty smart people over a period of several years.

In which case everybody except the victims of his fraud and law enforcement working on behalf of those victims should ignore him.

So, either he was or he wasn’t. In either case, we should ignore him. I regret ever getting involved in the “who was Satoshi” game, and am going to spend my time on more fun and productive pursuits.

Continue reading →