Development roadmap

[Dude65535]

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.

[1715098270]

1715098270

[1715098270]

1715098270

[1715098270]

1715098270

[1715098270]

1715098270

[Hal]

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.

[Mike Hearn]

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.

[chaord]

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.

+1

[jgarzik]

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.

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

[genjix]

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.

[Tril]

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.

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.

[caveden]

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)

[marcus_of_augustus]

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

[BitterTea]

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

[Jim Hyslop]

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.

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

[Pieter Wuille]

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

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.

[caveden]

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

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? 

[foo]

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

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? 

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/ 

[QuantumMechanic]

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.

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

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.

[Luke-Jr]

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

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

[batfink]

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.

[BitterTea]

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

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?

[Matt Corallo]

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?

[jgarzik]

Thus, if we make sure the major mining nodes restart on a regular basis, we could simply [...]

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