Topic: Development roadmap (Read 5425 times)

http://kb.mozillazine.org/Register_protocol

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. 

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

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

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.

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/ 

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? 

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.

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

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

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

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)

two cases. 1. user has the client: client installation adds handler to browsers for certain URIs to launch bitcoin sendtoaddress . 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.

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.

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

+1

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.