-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Sent: Monday, July 11, 2011 at 8:52 PM

From: "Mike Hearn" <mike@plan99.net>

To: "Satoshi Nakamoto" <satoshin@gmx.com>

Subject: News, etc

Hi Satoshi,

I hope you are well, and enjoying the success of your baby. I don't know if you still read this mailbox, but figured I'd send you occasional updates about Bitcoin[J] regardless, you did request them after all ;)

You'll be pleased to hear that the first smartphone clients are now available, utilizing SPV mode. I sent coins to and from my phone only last week. The apps are easy to use, you can just scan a QR code to send coins between phones. The software is buggy and it's still early days, but how person-to-person payments will work is becoming clearer. People are exploring all design spaces, not just SPV but pure RPC to remote "banks" and a hybrid where only the keys and signing are done locally.

The primary challenges have been resource constraints: Android apps only get 16mb of RAM and there is no swap, so loading chain headers in RAM does not work. I wrote a block store that has low/constant memory usage and startup time, traded off against flexible access patterns. At ~16mb the storage costs are good compared to a full node, but still too high. The next step is probably to use an on-disk ring buffer and refuse to accept re-orgs more than a few thousand blocks deep. At over 10 terahashes/second it won't be an issue.

The other problem is that the cost of parsing and scanning the full blocks is quite high in recent times. I think the right way to go is (as you suggested) for nodes to support a mailserver type mode where filters are supplied and matching transactions+merkle branches are supplied. I hope to do that this autumn.

There are lots of people contributing to BitCoinJ - nearly as many as the main C++ client. It's also been transcribed into C# for Windows developers. So it's a successful project and that's great. There are people working on things like wallet encryption for both implementations. There have also been some neat proposals for using script to implement a decentralized form of 2-factor authentication. I wrote up a bunch of possible transaction types here:

http://en.bitcoin.it/wiki/Contracts

it includes escrow, anti-spam deposits, assurance contracts and using oracles to connect transactions to the outside world. I suppose you designed quite a few others, we will rediscover them eventually.

Clouds on the horizon:

1) legal uncertainties will be an ongoing issue for a long time. There's a ton of bitcoin interest inside Google - the internal mailing list has over 100 people on it, there are at least 5 or 6 engineers developing Bitcoin related software and we also have a regulatory compliance expert on board. But some of it is being held up by lawyers who are uncomfortable with the general philosophy of the project. Ultimately, Bitcoin is sailing against the prevailing political winds and it's unclear whether Google has the energy for (yet another) argument with lawmakers and regulators.

2) I still struggle to convince everyone about the economics of post inflation security. Votes in the chain are a public good, so economic theory says pure fees aren't enough. Assurance contracts seem like one way forward - it's unclear how well they will work.

A questions, if/when you find the time or energy to answer: what do you think of votes-by-stake rather than by cpu power? Before settling on proof of work, did you explore having keys both hold value and vote on block contents by signing them?

thanks

- -mike

Sent: Wednesday, July 23, 2014 at 2:42 PM

From: "Mike Hearn" <mike@plan99.net>

To: "Satoshi Nakamoto" <satoshin@gmx.com>

Subject: Thinking about a fork

I don't expect a reply, just getting some thoughts off my chest. Writing them down helps.

Forking Bitcoin-Qt/Core has been coming up more and more often lately in conversation (up from zero not that long ago). Gavin even suggested me and him fork it ... I pointed out that maintainers don't normally fork their own software :)

The problem is that the current community of developers has largely lost interest in supporting SPV wallets. Indeed any protocol change that might mean any risk at all, for anyone, is now being bogged down in endless circular arguments that never end. The Bitcoin developers have effectively become the new financial regulators: restricting options within their jurisdiction with "someone might do something risky" being used as the justification.

If alternative low-risk protocols were always easily available this would be no problem, but often they require enormous coding and deployment effort or just don't exist at all. Yet, wallets must move forward. If we carry on as now there simply won't be any usable decentralised wallets left and Bitcoin will have become an energy-wasting backbone for a bunch of banks and payment processors. That's so far from your original vision, it's sad.

I know you won't return and that's wise, but sometimes I wish you'd left a clearer design manifesto before handing the reigns over to Gavin, who is increasingly burned out due to all the arguments (as am I).

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJUE607AAoJEEb2BNUci3vzYvcP/0mZOXkxlQ7gMwwUkLnLGAvl

aygSzZ1QJAp35aYyHhhWFBBEOBhrY9vOtOqxmLy+nlU+85eOfKOH7MyO+vtcp4vt

vNAL0JMYBBuHzZ6gkbv/FAZkAbZU5kr5AiDYX+N48YC/G7HdFQtqY4zalL/7P7aF

CHwzL9dB78Ptvtd41QWyU0WTx2RpMRpJiYgZ6p7uj+5Ic6rZxw4pxXJDd2TdLsjT

V/r5h9y7H5N1xXpjMtmv+2YZdtUxP6IB1RKP0hujrAi2nOqRIPT+VYhIBW1KOx/l

ZdAXurJyZtYUvsgn+yoRebse1eudATO6bYEsS1BpecssRqLzHQg7YWTxQd3AZxrU

mBywwQoa/0brYfZWLMjnOZl98AoWJAw66wZiNdVlPzTi2bjj469gYTlXOxWcYcU+

sN946liKSVsmUXEqWPM+kV4S+NhfChWsY5/sEFn9Rn5FDQs4gmkBkDDYpgyZxNE9

P8T8a67wQ3pMayjl0kXd9Ert5IsSHdMB5GBdNCf4HtU4yJ1JiDIC3YeeEKR/kOmk

n/tM4VXJdOISsqZDTvWusfzF+w0se9Ts8A/oPI1AiK59V62hu6ia+e7DvVKuRsSy

sqk1tzqnfUcvvFl2XNMVETDLgQQTD9VhfhLgnBuXa2UnoQa3fmnumDHLNBrXyXM+

H2vZNVuINnW07sWTCc6h

=Ch7I