Development roadmap

[Gavin Andresen]

Crashing bugs, any bug that might result in loss of bitcoins, and security fixes are always highest priority, but here are the big things I think are very high priority that, as far as I know, nobody is working on.  I think they all need to be done before we can say we have a "Bitcoin 1.0" :

• finish download-only-blockheaders client mode
• password-protect the wallet private keys (mitigate the steal wallet.dat problem: see https://gist.github.com/803170 )
• import a backed-up wallet
• figure out how to do click-to-pay
• design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "gavin@acm.org")
• export+encrypt part of your balance (for long-term storage; I still waffle on whether we want to encourage that right now)

[JollyGreen]

I like the roadmap, and think the wallet backup/restore feature needs to be integrated quickly.  Right now, everyone has to be fairly computer savvy to backup and restore a wallet, seems like this is a feature everyone wants and should just take a couple clicks.  Password protecting everything would be a great idea too.

Has anyone else noticed the load time on at least Mac OSX is sometimes incredibly long?  30-60 seconds + before any sort of a GUI pops up?  Can whatever is being done be moved to happen after the GUI has loaded?  Maybe a progress bar?  I've almost force quit the application before, thinking it was locked up.

[Hal]

Is there anything we need to do for robustness against spam/flooding attacks? I thought [mike] had some ideas.

[Mike Hearn]

I'm still thinking DoS resistance through. Gavin and Satoshi have pondered that the most so for now I'm happy to just sit back and let them figure it out :-)

I like the roadmap, though I agree it's somewhat arbitrary. The client mode will need a lot of work even after it's implemented, we don't really want to force users to choose when they start the software as 99% will have no way to understand what that choice means. A Skype/Kazaa type approach in which all nodes start as "clients" and then later choose themselves whether to become supernodes with full block chain copies would be better (as long as there's a semi-obscure way to force it for miners).

Client mode and DoS resistance are closely related anyway. One reason the current network has so many problems with "spam" is that the network is constrained to the capabilities of its worst nodes so we need all these artificial limits followed by systems to try and handle the artificially constrained capacity. Introducing a concept of self-selecting supernodes will allow the network to scale up significantly further - until it starts hitting natural hardware limits, most likely cpu or disk iops. At that point we'll hopefully have at least prototype versions of distributed supernodes.

[Only-One Bit Coiner]

any bug are always highest priority

Marketing and education are highest priority. We need more docs to be translated into different languages.

[Mike Hearn]

To clarify, this is a code development roadmap, not project development. Translated docs and better marketing materials would be great but it's not relevant to v1 of the software.

[m0mchil]

Perhaps really really low priority, but I want to remind you about redundant transmission of transactions with each block. May be it's better to solve this sooner rather than later.

My proposal is to modify 'block' message to contain only transaction hashes. After that, 'getdata' can be used to further acquire missing transactions from block's sender.

Unfortunately I don't see how this can be done without breaking current protocol.

[Mike Hearn]

It's easy to evolve the protocol. Just change the format if the peer reports its protocol version as >whatever number.

And yes that would be a good improvement. A getmerklebranch message would also be very useful for client mode as that'd let you see 0/unconfirmed transactions like today. Otherwise in client mode you'd have to wait for a block to see you received coins.

[Hal]

design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "gavin@acm.org")

This might be nice but I don't see it as a prerequisite for 1.0.

In the discussion on BitDNS, there was resistance to overloading the main chain as a title registry. Another chain a la BitDNS could be used to map general strings to btc addresses, as well as domain names.

One issue is it pretty much has to be first come first served. Whoever grabs gavin@acm.org first, gets it. There wouldn't be any way to verify ownership of the address.

[Gavin Andresen]

design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "gavin@acm.org")

This might be nice but I don't see it as a prerequisite for 1.0.

I suppose if we figure out how to make click-to-pay work for both the "I'm using an online wallet service" and the "I'm using the client" cases, then users won't have to know how to copy&paste addresses and human-type-able addresses won't be critical.

RE: DoS resistance:  please DO keep thinking about it; I'm not a networking expert (in fact, if you know any networking experts, see if you can get them thinking about it....).

[Mike Hearn]

I think glueing the browser to the node software is a lot easier than coming up with some complicated address mapping scheme.

I'm pretty familiar with how we do DoS resistance at work, but traditional DoS and BitCoin DoS are very different problems. There are just so many ways to do it, and best of all, nobody really knows what the capacity of the network is :-)

[JollyGreen]

What about adding the public/private mode like chrome/firefox?  It could default to privacy mode which would be the current setup, but could be toggled to public mode where you can have accounts where an address in that account can be used for both sending and receiving.  I think this would really simplify a lot of bitcoin, open it up to a much broader audience, and make room for a lot more services to build on top.

[Mike Hearn]

By the way, one way to let me send coins to gavin@acm.org is to leverage the old direct-to-IP mechanism. Example:

1) Download EC public key from http://acm.org/bitcoin-transact/gavin. Optionally, if that results in a 404, fall back to http://directory.bitcoin.org/acm.org/gavin

2) Create a transaction with <pubkey> OP_CHECKSIG as the output, broadcast

3) Gavin claims it by sending a tx with just a signature in the scriptSig.

All clients should still be able to recognize these sorts of transactions. All we've done is replace the direct IP-to-IP connectivity with a well-known HTTP endpoint. Supporting this scheme is as simple as creating a directory on a web server.

It can be extended to include not just an EC key but an RSA key in the downloaded file too. Then you can send a message by encrypting it, POSTing it somewhere (like back to the acm.org server if the downloaded file advertises that it supports that), and including the hash in the transaction before an OP_DROP. This way even though you only advertise a single key, you can still find out who sent you coins.

I'm not claiming this is easier or better than having some simple web browser integration mind you. It'd still require some setup and ultimately copy/pasting a BitCoin address isn't much different to copy/pasting an email address.

I suspect there's various interesting ways you can avoid relying on base58 addresses using the scripting language.

[bitcool]

I suppose if we figure out how to make click-to-pay work for both the "I'm using an online wallet service" and the "I'm using the client" cases, then users won't have to know how to copy&paste addresses and human-type-able addresses won't be critical.

Maybe a little bit off-topic, but I think better usability is essential to bitcoin's success.

Highly recommend this book: http://www.amazon.com/Change-Function-Technologies-Others-Crash/dp/B000NA6U2O/ref=sr_1_1

Book description:
"After years of studying countless winners and losers, Coburn has come up with a simple idea that explains why some technologies become huge hits (iPods, DVD players, Netflix), but others never reach more than a tiny audience (Segways, video phones, tablet PCs). He says that people are only willing to change when the pain of their current situation outweighs the perceived pain of trying something new."

"In other words, technology demands a change in habits, and that’s the leading cause of failure for countless cool inventions. Too many tech companies believe in "build it and they will come"— build something better and people will beat a path to your door. But, as Coburn shows, most potential users are afraid of new technologies, and they need a really great reason to change."
 

[joe]

• design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "gavin@acm.org")

The solution for sending coins to people is at http://bitcointalk.org/index.php?topic=3427.0
I envision adding a "wallet" tab to the client, which lists every bitcoin bundle in wallet.dat, and if you double click any bundle you can: (1) copy the private key for that bundle so you can email it to someone, (2) split out a different amount, (3) combine with another bundle, (4) reissue. Very similar to that other digital currency ecache.

[Gavin Andresen]

The solution for sending coins to people is ...

Cool... but Hal just convinced me we don't need that feature for bitcoin 1.0.

Is anybody willing to commit to actually implementing any of these?

I know the bitcoin<->Berkeley DB code pretty well, so I'll volunteer to do the "Import a backed up wallet" feature.

[BitterTea]

For click-to-pay, what about finalizing details for a bitcoin:// uri scheme, and letting the client handle those requests? Any idea of an easy way to get that to work with an online wallet, though?

[Dude65535]

For click-to-pay, what about finalizing details for a bitcoin:// uri scheme, and letting the client handle those requests? Any idea of an easy way to get that to work with an online wallet, though?

If I recall right mailto:// works both for a separate email program or web based email. So I would imagine however that is accomplished might solve that problem.

[Tril]

define click-to-pay?

[Gavin Andresen]

define click-to-pay?

You're browsing the web and see a link or button that says "Pay now with Bitcoin"-- you click it, and... stuff happens.  Where that stuff does NOT involve copying and pasting anything (I know WE all know how to copy and paste, but a surprising number of computer users don't) and certainly doesn't involve trying to type in a 35-character bitcoin address.