Bitcoin Forum

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)

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.

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

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.

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

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.

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.

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.

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.

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....).

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 :-)

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.

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.

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."
 

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.

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.

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.

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.

Should click-to-pay auto fill the amount as well as the address?

If it does I think it would be a good idea to have a setting for "Require password for payments larger than X". Mainly just to slow the process down and give people a moment to sanity check the amount.

Another feature we need IMO is the ability to reclaim payments that aren't going through, and/or to reissue payments with a higher transaction fee. (We also need basic support for transaction fees.) As the network gets busier this will become important.

Yes, that's definitely higher priority than other nice-to-haves as it's possible to get yourself stuck currently with transactions that won't commit but that you can't reclaim.

It's the (currently disabled) sequence numbers feature, right? That lets you broadcast new versions of a transaction, presumably with a higher fee than before. For reasons I don't fully understand seqnos are on the tx inputs, not the tx itself.

+1

+100 agreed.  This should be a high priority, IMO.  Here's my own, off-the-cuff, probably-wrong theory:

Create transactions with a specified lifetime, either in wall clock time or number of confirmed blocks.

If the transaction is not recorded in a block by the deadline (24 hours or 144 blocks?), all nodes will refuse to relay it and miners refuse to incorporate it, thus giving the user the opportunity to resend it with a proper fee.

In general, transaction fees -- from a user perspective -- is still a bit opaque, and easy to get wrong.

It would be nice to have deterministic behavior for transactions that are not incorporated immediately.

Should wallet encryption be done using GPG or RSA + AES?

With RSA + AES you'd still have to store the private key somewhere. My inclination would be to store them inside the wallet but now that means you're only protected by a password.

two cases. 1. user has the client: client installation adds handler to browsers for certain URIs to launch bitcoin sendtoaddress <parameter>. Depends on standard ways to add handlers to browsers and also on setting up RPC by default and the password in bitcoin.conf.  This depends on actually having a client installer, that doesn't exist yet, AFAIK.  When there is an installer, it can offer the option to setup the URI handler in various browsers and clearly inform the user of the newly enabled listening localhost port 8332 and random password written to bitcoin.conf (similar to vidalia setting up a cookie to talk to the tor daemon). For security, the bitcoin client GUI should by default require confirmation before sending payment, if GUI is active and a sendtoaddress RPC is given. Advanced users should be able to turn off the confirmation. [EDIT: this was hastily thrown together and it needs more thought to get security right]

2. user has no client and uses an online service (mybitcoin or vekja) for the wallet. Each site will need to publish a bookmarklet (javascript code) the user can click to enable mapping bitcoin: URIs to be handled by their site. If this is not possible each site will need to publish a browser addon.  Either way, case 2 has nothing to do with the bitcoin client program, but both cases should use a standardized URI, we just need to choose bitcoin:, bitcoin://, btc: or btc:// - I vote for the first one.

Just giving my two cents, I agree that the DNS-like feature is not high priority, but resending and reclaiming transactions is (should be in a 1.0)

Transaction date-stamp appearing in client to be in international standard format DD-MM-YY not MM-DD-YY, or selectable in options.

In case anyone hasn't seen it yet, there is already Bitcoin URI scheme developed, though I'm not sure to what extent: https://en.bitcoin.it/wiki/URI_Scheme

There is a discussion on github about this. Jeff Welling had suggested the possibility of using a GPG public key with the secret key stored externally.

My inclination aligns with yours - keep it self-contained. I was thinking the simplest way would be to hash the user's pass phrase and use that as a symmetric key to encrypt the private keys (or any other sensitive information that needs to be stored in the wallet). As an advanced option, we could allow the user to specify a GPG public key from their existing GPG keyring.

As far as only being protected by a password... well, the knowledgeable users will either choose a very long pass phrase, or use an external GPG key. It's the users who choose weak passwords who would be the most at risk.

Next time you're using an ATM or POS PINpad that has the numbers silk-screened on the keys (as opposed to being molded into the keys), you'll notice that the "1" is almost obliterated, "2" is mostly obliterated, and "3" and "4" are quite well worn. That pretty much tells you how many peoples use 1234 or 1111 for their PINs. Those are the people who would also choose weak passwords for their wallets. And I don't see any technical way to shield them from the risks they are opening themselves up to.

On the lighter side of bad passwords: http://www.youtube.com/watch?v=K95SXe3pZoY

If you don't mind, i was planning on extending my dumpprivkey/importprivkey patch (see other thread) a bit so it can export and import whole wallets, one of the next days.

True! This thing of putting months before days is damn confusing... when will you english folks learn to use proper formats and the metric system?  :D

Oh FFS...

1. The ISO standard date format is YYYY-MM-DD.
2. The current client uses the local date format, at least on Windows.
3. The English do put the day before the month, you are talking about Americans.

I was going to keep quiet, but... http://xkcd.com/386/  ;)

I like the finite lifetime transaction rule.

I was thinking it would be nice if when a user is entering a transaction, the fee could be adjusted from within the same window while giving a concomitant estimate of the expected time for the transaction to clear (to have, say, 6 confirmations), based on the parameters of the proposed transaction, and the block chain data from the past, say, 24 hours.  This would help to make the purpose of transaction fees more transparent to users, and the fees would be set closer to where they actually need to be.

It's pretty much finalized, and in real world use (IIRC, mainly in phone UIs)

i kinda like the idea of using AES with a password/passphrase, though i understand the issues with passwords and especially users that choose really bad weak passwords.

How about we make brute forcing the password more difficult by making it more computationally expensive... maybe by taking the password... hashing it with a short random salt of maybe 20bits.... with 1,048,575 possibilities, that salt would take maybe a second for a standard computer to guess, but would greatly slow down any attempt at brute forcing a password.

secondly a short blacklist of the most common passwords like "password" and encouraging people to use a pass-phrase rather than a password would probably be a good idea.

It's pretty much finalized, and in real world use (IIRC, mainly in phone UIs)
[/quote]
Ok. I'm playing around implementing this into WalletBuddy right now... When a bitcoin: URL is clicked, I'm queuing the payment and allowing the user to send queued payments when a wallet is open. Think it will be cool in the mean time.

Any idea how Linux registers URL handling?

I was talking with ArtForz about the making a new tx with a higher fee a week or so ago.  He mentioned that nodes never broadcast new txes unless they are just receiving it for the first time and nodes do not save txes that haven't been confirmed to disk.  Thus, when a node restarts, all of the txes which it previously had in its memory pool will be lost and one can resubmit a tx to the network once enough nodes have forgotten the previous tx.  ArtForz mentioned that he reboots his mining bitcoind once every 24 hours for dynamic ip reasons and in his tests he could resubmit a new tx after only around 24 hours due to network turnover.  Thus, if we make sure the major mining nodes restart on a regular basis, we could simply make a new tx with the same inputs but a higher fee very easily without any major changes to the network.  Just my 2 cents.

Also, the URI sceme needs to be included better in the client.  Maybe make it default for opening bitcoin:// URIs? Or maybe just a ff/chrome/safari/etc plugin which grabs bitcoin: URIs and connects to a local rpc daemon to send the funds?

It does not seem prudent to enshrine a "reboot it frequently!" policy as part of standard operating procedure.

I agree, but if one large miner does it, resubmitting txes becomes possible.  ArtForz already does...I was just pointing out that it already is possible, but true, it is not reasonable to depend on it in the future. 

http://kb.mozillazine.org/Register_protocol