Gavin Andresen

Bitcoin developer. All-around geek.

Read this first

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 →


Bitcoin Protocol Role Models

A couple of months ago, I was having Yet Another Argument with a Bitcoin Core contributor about the one megabyte block size limit.

I had asked: “what other successful Internet protocols impose arbitrary limits on themselves similar to the one-megabyte limit?”

His answer was “there are limits on the size of the global routing table in the Border Gateway Protocol (BGP) protocol.”

BGP is the protocol routers use to decide what to do when they get a data packet bound for an IP address like “111.12.1.1” – they send it to China (111.12.1.1 belongs to the China Mobile Communications Corporation right now).

So I went and skimmed through the BGP protocol documents. Then read the wikipedia page on BGP. And had the opportunity to talk with Justin Newton, who participated in the debates on Internet scalability fifteen years ago.

And found that there are no protocol-level limits on the size of

Continue reading →


Satoshi

I believe Craig Steven Wright is the person who invented Bitcoin.

I was flown to London to meet Dr. Wright a couple of weeks ago, after an initial email conversation convinced me that there was a very good chance he was the same person I’d communicated with in 2010 and early 2011. After spending time with him I am convinced beyond a reasonable doubt: Craig Wright is Satoshi.

Part of that time was spent on a careful cryptographic verification of messages signed with keys that only Satoshi should possess. But even before I witnessed the keys signed and then verified on a clean computer that could not have been tampered with, I was reasonably certain I was sitting next to the Father of Bitcoin.

During our meeting, I saw the brilliant, opinionated, focused, generous – and privacy-seeking – person that matches the Satoshi I worked with six years ago. And he cleared up a lot of mysteries

Continue reading →


Satoshi Roundtable Thoughts

I participated in the “Satoshi Roundtable” event in Florida last weekend on my way home from the Financial Cryptography conference.

The Roundtable is an invitation-only event organized by Bruce Fenton (current Executive Director of the Bitcoin Foundation, but it is not a Foundation event), and I’m told that in past years it was mostly a relaxed networking/socializing event.

This year, discussion of the the block size limit dominated the entire weekend.

All of that discussion happened under the “Chatham House Rule” – “…participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed” – so for the rest of this blog post I will talk about what happened and what was said, but won’t mention any names or affiliations. You can see who attended at the event’s website.

There were a couple

Continue reading →


One-dollar lulz

A couple of months ago, Paul Sztorc published a blog post asking two very good questions:

  1. “Why do you think we have a [maximum] blocksize?”
  2. “What has changed, between the time that the [maximum] blocksize was introduced (July 15th, 2010), and today, which motivates us to make a corresponding change in the constraint?”

For me, personally, the answers are simple. First, the limits were added to prevent a ‘poisonous block’ network denial-of-service attack. We have to worry about denial-of-service attacks if they are inexpensive to the attacker. 'Amplification’ attacks are the worst, where the attacker sends a little bit of information that causes lots of traffic on the network or causes lots of wasted CPU processing.

Second, a couple of key things have changed since Satoshi made the change.

The attack the limit is meant to prevent is much more expensive today. I have a spreadsheet

Continue reading →


Seventy-five, twenty-eight…

I don’t like arbitrarily chosen constants in code.

Sometimes they’re unavoidable and harmless. I use 11 in code I write when the number doesn’t matter (because eleven is my favorite number).

I like arbitrarily chosen constants in protocols even less, but sometimes they’re unavoidable. The 2mb block limit proposal has a few ‘magic’ numbers, but the 75% hash-rate threshold and the 28-day grace period generate the most discussion and debate.

Some people would rather the 75% be 95% or 99%. I think that is too high because it gives “veto power” to a single big solo miner or mining pool. Holding veto power is dangerous– somebody who disagrees with the change or just wants to disrupt Bitcoin might use extortion, bribery, or blackmail against a miner to try to prevent the change.

Other people think 75% is too high; after all, if 51% of hash power got together they could just choose to ignore

Continue reading →


A Guided Tour of the 2mb Fork

Increasing the block size limit from 1 million bytes to 2 million bytes sounds so simple: just change the “1” to a “2” in the source code and we’re done, right?

If we didn’t care about a smooth upgrade, then it could be that simple. Just change this line of code (in src/consensus/consensus.h):

... MAX_BLOCK_SIZE=1000000

to:

... MAX_BLOCK_SIZE=2000000

If you make that one-byte change then recompile and run Bitcoin Core, it will work. You computer will download the blockchain and will interoperate with the other computers on the network with no issues.

If your computer is assembling transactions into blocks (you are a solo miner or a mining pool operator), then things get more complicated. I’ll walk through that complexity in the rest of this blog post, hopefully giving you a flavor for the time and care put into making sure consensus-level changes are safe.

Github has a handy

Continue reading →


Minority Branches

What would happen if some minority of mining hash power and maybe a merchant or exchange decided to stay with, or move to, different consensus rules than everybody else?

Would there be two different flavors of Bitcoin? Would it cause massive disruptions to the Bitcoin economy? Would your coins be safe?

(spoiler alert if you’re in a hurry: no, no, and yes)

I’ll start with the assumption that there is a supermajority (two-thirds or more– comfortably over 50%) that wants one set of consensus rules, and a minority that wants another set of consensus rules. This analysis doesn’t work if there is an even split in opinion about the rules. I’m also assuming that there is a supermajority of both hash power and transaction creators (the ‘economic majority’) on the same side; the analysis is different if miners and exchanges/merchants/users disagree about what the rules should be.

So, if there

Continue reading →


Classic? Unlimited? XT? Core?

Almost two years ago, when I stepped down as lead maintainer for Bitcoin Core, I wrote:

I’m pleased to be able to focus more on protocol-level, cross-implementation issues and less on issues specific to the Bitcoin Core software.

I’d still like to focus on protocol-level, cross-implementation issues but lately I’ve been distracted and have generated a lot of controversy (and hurt feelings) by helping out with some other implementations (first XT, lately Bitcoin Classic, maybe Bitcoin Unlimited soon.

Madness! Chaos! ANARCHY! … I hear some people say, but there is a method to my madness. When I was lead maintainer of Core I had the following top-three priorities:

1) Keep the system secure.
2) Keep the network reliably processing transactions.
3) Eliminate single points of failure.

Those are still my top priorities, but I try to take a higher-level view, looking at the entire Bitcoin

Continue reading →


Segregated Witness is cool

Pieter Wuille gave a fantastic presentation on “Segregated Witness” in Hong Kong. It’s a great idea, and should be rolled into Bitcoin as soon as safely possible. It is the kind of fundamental idea that will have huge benefits in the future. It also needs a better name (“segregated” has all sorts of negative connotations…).

You should watch Pieter’s presentation, but I’ll give a different spin on explaining what it is (I know I often need something explained to me a couple different ways before I really understand it).

So… sending bitcoin into a segregate witness-locked output will look like a weird little beastie in today’s blockchain explorers– it will look like an “anyone can spend” transaction, with a scriptPubKey of:

PUSHDATA [version_byte + validation_script]

Spends of segregated witness-locked outputs will have a completely empty scriptSig.

The reason that is not insane is

Continue reading →

Subscribe to Gavin Andresen

Don’t worry; we hate spam with a passion.
You can unsubscribe with one click.

UhUUz8YWUky9fDevq83