Roadmap to 1.0?

[deepceleron]

+ past the December block-reward-drops-to-25

 

I'm kind of surprised that even Gavin worries a bit about this.

It's not that he worries, it's just something that we need to prove as working in production.
There's a difference between testing something in a lab (testnet) and making it work in production ... we need to get this level of confidence.

You could make a 25BTC generate now and see if it crashes the network.... Testing is worth 25BTC, isn't it?
You'll have to wait to December to test that everybody orphans your 50BTC generate hack block though.

and also...

After we decide that it's out of beta, feature complete and tested, and we won't have any need to reset the blockchain back to block 0?

[1715126006]

1715126006

[1715126006]

1715126006

[AsymmetricInformation]

The things on my "good enough to be called 1.0" list are:

+ easy enough for my grandma to use
+ secure enough that it'd be hard for my grandma to lose her bitcoins, even if her computer is infected by 11 bitcoin-stealing trojans and then catches fire and explodes.
+ past the December block-reward-drops-to-25

To solve 'security' for non-computer people, you'd likely need non-computer wallets (paper wallets...grandparents are already familiar with important documents, or so I read).

For a "user-friendly-version install":
1) Test the user's printer.
2) Load some bootable image onto a flash drive.
3) Restart and boot into the flash drive.
4) Have this pristine world generate and print paper wallets.
5) After it reboots back into mac/windows, (on the paper wallets can be instructions for making the equivalent "watch-only" wallet, and something like *ONLY LET THOSE YOU TRUST SEE OR COPY THIS PART OF THE DOCUMENT* for the private keys).

Obviously the "spend problem" is more complicated...funds could be spent:
Within tiny-Linux again, or via a version of "offline transactions", or you could make every transaction immediately dump the remaining/unspent BTC into the "next" paper wallet...needs lots of wallets and not as user friendly, but good for large transactions.
OR, maybe they NEVER spend the BTC...since banks/lenders can use the blockchain to see how much BTC is in a wallet, normies can just borrow USD against the paper-"savings" BTC wallet as collateral (what Zuckerberg does with his FB shares...tax free!). For smaller transactions this would be ideal. (In fact, a BTC payable credit/debit card would make a month's worth of transactions into one transaction...[for transactions that don't need to be anonymous]).

...clearly it depends, to some extent, on new BTC innovations.

[Realpra]

@Gavin

BTW could the way passwords are punched in on the main client to unlock wallets be changed?

What I am thinking about is an on screen keyboard with these features:
1. Keys are shuffled each press.
2. Screen-keyboard window is placed randomly on screen.
(Saw it back when I played MapleStory - never in my online bank  )

That way future BTC key loggers will be out of luck.

[westkybitcoins]

@Gavin

BTW could the way passwords are punched in on the main client to unlock wallets be changed?

What I am thinking about is an on screen keyboard with these features:
1. Keys are shuffled each press.
2. Screen-keyboard window is placed randomly on screen.
(Saw it back when I played MapleStory - never in my online bank  )

That way future BTC key loggers will be out of luck.

Thing is, that's not very user-friendly for grandma.

Honestly, the usable-by-grandma goal and the grandma-wont-lose-coins goal are mutually contradicting. I'm beginning to wonder if it's even worth trying to achieve both, and frankly if it's not, I'd vote for choosing the coins-are-hard-to-lose goal. Let someone besides the Satoshi client developers worry about how simple and accessible the technology is for grandma--I'm sure other client developers and companies can handle that just fine.

[Realpra]

Thing is, that's not very user-friendly for grandma.

In defense of the screen keyboard: Maplestory is played by pretty young kids - if they can do it, surely an un-demented grandmother could.

[ripper234]

Thing is, that's not very user-friendly for grandma.

In defense of the screen keyboard: Maplestory is played by pretty young kids - if they can do it, surely an un-demented grandmother could.

How hard would it be to screen-scrape the password screen?
Sure, it's an extra measure of security, no reason not to implement it ... but it won't protect against capable trojan writers.

[Foxpup]

How hard would it be to screen-scrape the password screen?
Sure, it's an extra measure of security, no reason not to implement it ... but it won't protect against capable trojan writers.

Not hard at all. In fact, I think a few (possibly even most) keyloggers take a screenshot on every mouseclick for exactly this reason. The reason not to implement a randomly-changing on-screen keyboard is that it's damn annoying and doesn't really provide much (if any) improved security, and in fact will probably reduce security substantially as it encourages users to use short passwords, due to how damn annoying it is to click a huge number of buttons when the buttons keep shifting positions randomly every time you click one.

Seriously, security features that are annoying are as bad as no security at all because users will actively try to avoid using them properly: people would rather be insecure than annoyed. They may not admit it, but it's the truth. All security features must be designed with non-annoyingness in mind.

[dooglus]

I assume the next major release will be 0.7, we'll be running out of 0.x headroom pretty soon

After 0.9 come 0.10 and 0.11; they're not decimals.

When a period is used to separate sequences, it does not represent a decimal point, and the sequences do not have positional significance. An identifier of 2.5, for instance, is not "two and a half" or "half way to version three"

Most free software packages treat numbers as a continuous stream, therefore a free software or open source product may have version numbers 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, etc.