a pseudo TAN that doesn't affect the block chain but grants pretty good security

[giszmo]

what if i could print out the first n digits of my private keys and those digits get removed from my wallet? wouldn't that be kind of a tan? so if i want to send from address 5 i would need that remainder that i decided to move to dead wood.
* the modification to the client would be minimalistic
* the block chain would be unaffected
* user could decide on the tan length. that would be his level of security vs. effort to use it trade off.
* user would need to type in as many tans as sending addresses there are involved
* the user could decide to put stronger tans on receiving addresses than on pocket money addresses.

downside compared to tans as we know them:
* a trojan on the pc would be able to take over the transactions being done and change both amount and target once it has the tan. some eTAN procedures claim to inhibit that by hashing target and amount.
* a trojan on the pc would not only be able to take over the transactions being done but any further transaction from the same addresses.

thoughts?

[giszmo]

forgot to mention one big benefit:
no strong passwords that can be forgotten.

slight down side:
a wallet stealer would still find out my balance.

[X68N]

LOL, i had the idea before.
Didnt you see it, just come here to dicuss it on the main thread
http://forum.bitcoin.org/index.php?topic=23476.0

[Theo]

It's not a TAN because it isn't unique for one transaction. It's a way of keeping the private key private by not storing it on your computer. It's a good idea if you manage to keep the printed keys in a secure place.

[X68N]

Yes this is a good idea, and a similar idea i posted on the other thread.
maybe you could read my last post there so i did not rewrite it here.

I think also like you that it should be done something like a TAN to improve the secuity,
but a lot of people just think about how a improvement NOT work.
Instead they dont try to help by saying HOW IT WORKS to prevent an attack...
a lot of negative people, just read my thread to get an idea what i am talking about :-)

[Pieter Wuille]

If you just drop a few digits from the private keys, it's trivial to crack, as an exhaustive search will retrieve them easily from a leaked wallet.dat file.

If you drop a lot of digits from the private keys, it's not better than a passphrase-encrypted wallet (as will be supported by 0.4.0), and a whole lot less user-friendly.

[giszmo]

LOL, i had the idea before.
Didnt you see it, just come here to dicuss it on the main thread
http://forum.bitcoin.org/index.php?topic=23476.0

I saw it, was about to comment but thought my concept with its benefits is too far off your idea so I decided to do a new thread. My idea involves no modification on the network layer, no obscure security with mouse coordinates, etc.

If you just drop a few digits from the private keys, it's trivial to crack, as an exhaustive search will retrieve them easily from a leaked wallet.dat file.

If you drop a lot of digits from the private keys, it's not better than a passphrase-encrypted wallet (as will be supported by 0.4.0), and a whole lot less user-friendly.

As described in the OP the user could decide how many digits to use. I think it is a pain to handle several wallet files today but improvements there would at least allow me to have small wallets with a password I can remember and big wallets with a password i keep in a save. else having to type in "the" password would expose all my wallet to the attacker's trojan.

I'm curious how the new client will turn out to be but I doubt that I will feel any saver opening my big wallets with it than I feel now.

Lastly both concepts could be combined.

[theymos]

It would take less than a second to find the code, since all of the used Bitcoin addresses are known. You could just search Bitcoin Block Explorer for the known part.

[giszmo]

It would take less than a second to find the code, since all of the used Bitcoin addresses are known. You could just search Bitcoin Block Explorer for the known part.

didn't know the bitexplorer knows the privat keys

[theymos]

Oh, I missed that you were using private keys. Never mind that, then.

Given all but a few bytes of an ECDSA private key, I would not be surprised if there was some way of getting the remaining bytes without a full brute-force.