1 2015-04-22 04:19:22 <davec> not that it really matters, but https://github.com/bitcoin/bitcoin/blob/7c3fbc34aed578398b3f180a621c671ff3837cec/src/script/script.h#L476-L481 looks redundant
2 2015-04-22 05:06:49 <sipa> davec: agreed
3 2015-04-22 06:23:54 <jonasschnelli> davec: Right. Somebody should remove script.h L479-L481
4 2015-04-22 06:24:57 <sipa> meh :)
5 2015-04-22 06:31:51 <jonasschnelli> or maybe just keep the critical code as it is... :)
6 2015-04-22 06:33:11 <jonasschnelli> sipa: do you see a reason to avoid deriving Bip32 hardened keys on the fly?
7 2015-04-22 06:33:34 <jonasschnelli> just try to understand your bip32-on-the-fly-keystore
8 2015-04-22 06:36:56 <sipa> jonasschnelli: can't remember
9 2015-04-22 06:37:14 <jonasschnelli> no worries... thanks
10 2015-04-22 06:46:26 <gmaxwell> jonasschnelli: whats the greater context? What do you mean on the fly?
11 2015-04-22 06:46:49 <jonasschnelli> gmaxwell: https://github.com/sipa/bitcoin/commit/432820c72421eaab47db9af953dbfd0ddc95a936
12 2015-04-22 06:47:18 <jonasschnelli> Derive keys when they are required
13 2015-04-22 06:47:52 <CodeShark> hmm, what's with compat/endian.h intruding on global macros? I'm getting this issue: http://stackoverflow.com/questions/23079998/error-expected-unqualified-id-before-extension-in-linux-cent-os
14 2015-04-22 06:48:04 <CodeShark> using the #ifdef seems to fix the issue
15 2015-04-22 06:48:22 <gmaxwell> CodeShark: run autogen.sh
16 2015-04-22 06:48:29 <CodeShark> ah, ok
17 2015-04-22 06:48:53 <davec> it was probably intentional since most of the time showing scripts in their parsed form only shows the data, but GetOpName in script.cpp does not handle OP_DATA_X (though it does handle OP_PUSHDATAX which are also typically not shown)
18 2015-04-22 06:50:39 <CodeShark> gmaxwell: something still seems to be screwed up - I did a make clean, then autogen.sh, then configure, then make again
19 2015-04-22 06:50:49 <davec> cout << GetOpName(opcodetype(17)) -> OP_UNKNOWN
20 2015-04-22 06:51:15 <sipa> CodeShark: try git clean -dfx
21 2015-04-22 06:51:25 <sipa> (wipes everything not committed)
22 2015-04-22 06:51:35 <jcorgan> i have that aliased as 'git napalm' :)
23 2015-04-22 06:51:41 <sipa> hahaha
24 2015-04-22 06:52:39 <CodeShark> git nuke would be fewer keystrokes :p
25 2015-04-22 06:53:13 <sipa> agree
26 2015-04-22 06:53:41 <CodeShark> ok, the nuke option worked - thanks, gmaxwell and sipa
27 2015-04-22 07:04:45 <jonasschnelli> Would it make sense to have two levels of wallet encryption, a key (deriven from passphrase) for opening a wallet (let's say you have started the wallet app) and another key for unencrypting privkeys for signing, etc.?
28 2015-04-22 07:05:13 <jonasschnelli> Both levels could be non-mandatory
29 2015-04-22 07:07:39 <gmaxwell> Expirence suggests this will screw people, where they forget one and not the other.
30 2015-04-22 07:08:13 <jonasschnelli> Hmm.. yes. They probably will use the same passphrase...
31 2015-04-22 07:08:14 <gmaxwell> It's not an approach I'd personally recommend (I'd suggest testing it, but it's more hard to test than normal user behavior stuff)
32 2015-04-22 07:08:50 <gmaxwell> You didn't like my suggestion of seperately caching the view key? so that their backups would need to be unlocked but not normal start/stop?
33 2015-04-22 07:09:53 <jonasschnelli> gmaxwell: I really like it. And sorry for not responding yet (still thinking). But even there i'd like to avoid unencrypted data on the disk (even for pubkeys and metadata)
34 2015-04-22 07:10:50 <jonasschnelli> What's the problem of authentification when opening a bitcoin-wallet-app? (like you login to a online bank)
35 2015-04-22 07:13:11 <jonasschnelli> maybe authentification was the wrong term. I mean unencrypting (by passphrase) the chached data into memory.
36 2015-04-22 07:13:45 <gmaxwell> I don't know how to do it in a way that doesn't undermine the security for funds transfer authorization, which is much more important, or make the transfer key more exposed; or require dealing with multiple keys which the user will either reuse or forget. If there was a key recovery mechenism I'd probably worry a bunch less. A realization you should internalize here is that-- and I think everyone a
37 2015-04-22 07:13:51 <gmaxwell> round here is pretty confident that it's true-- its likely that wallet encryption has likely caused a lot more funds to lost keys than it has saved or can ever save from theft. On a net, for most users, it's probably harmful.
38 2015-04-22 07:14:16 <gmaxwell> But its necessary for appearences reasons and because people prefer to feel more control even when the result is worse on average.
39 2015-04-22 07:14:36 <wumpus> well as long as both levels are optional, but I'm not sure the outer level is that useful either, you could always store the wallet on an encrypted volume for example to achieve the same. Encrypted private keys is a feature only the application can give.
40 2015-04-22 07:15:26 <gmaxwell> wumpus: yea, the cached key idea has the useful property that backups onto other media are naturally encrypted; which at least answers the "wouldn't it be nice if your backup were encrypted".
41 2015-04-22 07:15:42 <gmaxwell> (without having to always have it encrypted)
42 2015-04-22 07:16:15 <wumpus> right
43 2015-04-22 07:17:03 <gmaxwell> jonasschnelli: another way to think about it; with bitcoin your computer is the bank; when you log into your computer you're logging into the bank then. Once anyone is to that point they can install backdoors that compromise your wallet privacy (or worse). So having another key right in front of getting to the transaction history is probably not ever a huge save; if you need your transaction histo
44 2015-04-22 07:17:03 <jonasschnelli> Right. But i also think metadata should be covered in the backup.
45 2015-04-22 07:17:09 <gmaxwell> ry private you need your debug logs privacy and really your whole computer.
46 2015-04-22 07:17:37 <wumpus> although to create encrypted backups, wouldn't the obvious thing be to encrypt on backup, like e.g. the android wallet does? or am I missing something
47 2015-04-22 07:17:54 <gmaxwell> Absolutely, it's very important to reliably backup all the metadata. And I agree that it's helpful if the backup files are encrypted... my arguments about your local computer don't extend to backups really.
48 2015-04-22 07:18:51 <gmaxwell> wumpus: would sort of be unfortunate if you had to enter a key to create a backup.
49 2015-04-22 07:18:51 <jonasschnelli> wumpus: right. We could do that. Encrypt the metadata-backup with a key from the encrypted keystore.
50 2015-04-22 07:19:11 <jonasschnelli> But i was thinking if there might be a ways to avoid plaintext storing of metadata on your local datadir
51 2015-04-22 07:19:22 <sipa> gmaxwell: it's what bwfa does
52 2015-04-22 07:20:00 <sipa> seems to work fine for me so far (though i admit i reuse a passphrase for it)
53 2015-04-22 07:20:02 <wumpus> gmaxwell: well, at least then you consciously know that the backup is encrypted
54 2015-04-22 07:20:19 <wumpus> gmaxwell: for automatic backups it indeed wouldn't work
55 2015-04-22 07:20:22 <gmaxwell> sipa: prompts for a key when creating a backup? Bleh, I worry that discourages creating backups; maybe also in using random keys that you'll forget (otoh at least you know the key at that instant...)
56 2015-04-22 07:20:29 <jonasschnelli> gmaxwell: is it not sufficient to encrypt the wallet metadata with a pubkey only? Is there a need to enter a unlocking-passphrase?
57 2015-04-22 07:20:33 <gmaxwell> and right, can't be automated.
58 2015-04-22 07:21:10 <wumpus> but isn't automatically encrypting with the same key every time also a potential danger?
59 2015-04-22 07:21:28 <gmaxwell> In terms of what?
60 2015-04-22 07:21:53 <wumpus> attacker gets lots of data encrypted with the same key
61 2015-04-22 07:22:03 <jonasschnelli> using a bip32 chainpath for encrypting?
62 2015-04-22 07:22:27 <gmaxwell> wumpus: this doesn't compromise the assumptions of any modern ciphersuite (unless you're talking about 2^128 messages. :P )
63 2015-04-22 07:22:46 <wumpus> normally you get around that by encrypting a master key with a passphrase and then using that random master key to encrypt, but that's less useful if you want to do something automatic
64 2015-04-22 07:23:03 <sipa> i don't really like abusing key chains (which are soething inside a wallet) for encryption of the wallet itself
65 2015-04-22 07:23:08 <wumpus> sipa: agreed
66 2015-04-22 07:23:11 <jonasschnelli> ok
67 2015-04-22 07:23:13 <sipa> seems like a layer violation
68 2015-04-22 07:23:19 <jonasschnelli> Agreed.
69 2015-04-22 07:23:20 <gmaxwell> (and in actuality what you'd be doing is encrypting each time with a differet ephemeral key. And encrypting that asymetrically; ... and if that doesn't hold ECDSA is probably also broken)
70 2015-04-22 07:23:25 <wumpus> I'm getting kind of scared here, rolling our own cryptoschemes and such
71 2015-04-22 07:23:36 <sipa> ACTION whistles
72 2015-04-22 07:23:41 <jonasschnelli> ;)
73 2015-04-22 07:23:53 <gmaxwell> wumpus ...
74 2015-04-22 07:23:54 <wumpus> may be worse than not encrypting at all, and leaving encrypting to something like pgp
75 2015-04-22 07:24:13 <sipa> i first read php instead of pgp
76 2015-04-22 07:25:01 <jonasschnelli> wumpus: i though the same. Maybe encrypting is something we should be done outside of the app layer.
77 2015-04-22 07:25:10 <jonasschnelli> (backup as well)
78 2015-04-22 07:25:12 <wumpus> (you store the wallet on a cloud service with the assumption that the encryptions is safe.. poof)
79 2015-04-22 07:25:56 <gmaxwell> wumpus: I keep encouraging /not/ adding more encryption here; but I also think your comment above is demonstrating a lack of perspective; we deal with considerations more difficult and subtle than this on a regular basis. And as you noted (and which I've tried to impress on jonasschnelli but you're now undoing) is that we cannot accomplish the task of key mediated access control inside the wallet wi
80 2015-04-22 07:26:02 <gmaxwell> thout encrypting the private keys internally.
81 2015-04-22 07:26:06 <sipa> i like human-readable and then encrypted formats for backups
82 2015-04-22 07:26:33 <gmaxwell> sipa: if it's encryted whats the use of the human readability?
83 2015-04-22 07:26:51 <sipa> gmaxwell: encrypted using a standard algorithm
84 2015-04-22 07:26:53 <jonasschnelli> How about using https://bitcointalk.org/index.php?topic=258678.0?
85 2015-04-22 07:26:59 <jonasschnelli> (for backups)
86 2015-04-22 07:27:13 <sipa> so that if the software doesn't exist anymore, you can still manually decrypt and recover
87 2015-04-22 07:27:21 <sipa> (with a lot of work, but still)
88 2015-04-22 07:27:55 <gmaxwell> jonasschnelli: that is a scheme for just storing a single root key. (and its development has petered out for a while; though there has been some interest expressed in continuing)
89 2015-04-22 07:27:59 <wumpus> sipa: that's another good reason for using a standard algorithm, not so much for human-readable
90 2015-04-22 07:28:22 <CodeShark> in principle, keys should belong to specific devices and never leave them except for the possible exception of making a backup to another storage tech (i.e. paper backup)
91 2015-04-22 07:28:24 <wumpus> gmaxwell: ok
92 2015-04-22 07:28:35 <gmaxwell> sipa: thats just why you include the source taball with your backups. :)
93 2015-04-22 07:28:46 <CodeShark> if you want to make a backup to a second device, you can create a 1-of-2 multisig
94 2015-04-22 07:28:53 <CodeShark> and have each device keep a separate key
95 2015-04-22 07:29:03 <CodeShark> that way if it ever gets stolen you know which device was hit
96 2015-04-22 07:29:08 <wumpus> android wallet also used to use a standard encryption format (that could be decrypted with the 'openssl' command), I don't think that's still the case though
97 2015-04-22 07:29:25 <sipa> wumpus: oh
98 2015-04-22 07:29:30 <sipa> i should try
99 2015-04-22 07:29:38 <gmaxwell> the stuff that openssl does is only 'standard' in so far as its what openssl does. :)
100 2015-04-22 07:30:10 <sipa> gmaxwell: 8 bytes IV + aes-256-cbc is easy enough to recreate if necessary :)
101 2015-04-22 07:30:13 <wumpus> yes, of course, but it will always be more well-known than something you make yourself
102 2015-04-22 07:30:26 <sipa> or 16 bytes probably
103 2015-04-22 07:30:28 <wumpus> especially if you start using bip32 chains in your encryptions
104 2015-04-22 07:30:37 <gmaxwell> sipa: its uses some key hardening sheme too I thought.
105 2015-04-22 07:30:51 <sipa> hmm, right
106 2015-04-22 07:31:02 <wumpus> yes, there is also some key hardening
107 2015-04-22 07:31:27 <gmaxwell> wumpus: yea, I'm not a super big fan of that; it has an advantage but only when coupled with an extra component: If you couple in some kind of 'cloud' storage; then you can have a single key to recover your wallet backup.
108 2015-04-22 07:32:32 <gmaxwell> of course, doing that also reduces you to single factor security (knoweldge of that one key...)
109 2015-04-22 07:32:40 <wumpus> right
110 2015-04-22 07:33:27 <gmaxwell> though on the balance the risk of data loss is great enough that it still might be a reasonable thing for people to be doing.
111 2015-04-22 07:34:20 <jonasschnelli> Would that be a way: encrypt Bip32 master key with Bip38, derive keys on the fly (only store chainpaths), cache metadata and pubkeys (as gmaxwell proposed) and leave backup and metadata-encryption outside of the app?
112 2015-04-22 07:34:31 <wumpus> but I certainly agree with sipa's concern, about decrypting and recovering later, the backup format should be as self-descriptive and human-readable as possible apart from the encryption layer
113 2015-04-22 07:35:00 <CodeShark> if you want to protect the backup format, split it up into multiple files and store them in different places
114 2015-04-22 07:35:27 <CodeShark> then all you need to remember is where you put them
115 2015-04-22 07:35:35 <wumpus> hehe
116 2015-04-22 07:35:36 <jonasschnelli> :)
117 2015-04-22 07:35:38 <gmaxwell> wumpus: So what good does this backup do for you, when you are assuming you don't have the bitcoin software? Then you're not likely to be able to make useful sense of the information in any case.
118 2015-04-22 07:36:00 <wumpus> gmaxwell: well, assume it may be years later, the current bitcoin software may not exist anymore
119 2015-04-22 07:36:21 <wumpus> gmaxwell: what you need are just the ECDSA keys, assuming ECDSA is still used
120 2015-04-22 07:36:31 <gmaxwell> sure, and what will future bitcoin software do with this data-- no doubt it uses some kind of totally different cryptosystem. :)
121 2015-04-22 07:36:42 <wumpus> you can't know that
122 2015-04-22 07:36:48 <sipa> jonasschnelli: please, no bip38...
123 2015-04-22 07:37:15 <gmaxwell> wumpus: sure, which is why you need to put your bitcoin tarball with your backup! :)
124 2015-04-22 07:37:16 <jonasschnelli> Yes. Just saw that. I more meant to keep a encrypted form (CCryptoKeystore) of the masterkey
125 2015-04-22 07:37:40 <gmaxwell> jonasschnelli: bip38 is a very poor specification which was created without any peer review or public comment at all.
126 2015-04-22 07:38:03 <CodeShark> standardization of key encryption is sorta stupid anyhow
127 2015-04-22 07:38:11 <nsh> is it?
128 2015-04-22 07:38:11 <wumpus> gmaxwell: that does make sense
129 2015-04-22 07:38:19 <gmaxwell> It just falls short of being actively insecure; but a bunch of weird decisions in it make it unusable for many cases.
130 2015-04-22 07:38:39 <CodeShark> nsh: better to leave that flexible, methinks
131 2015-04-22 07:38:58 <CodeShark> write a separate utility to do the encryption and decryption into a standard unencrypted export format
132 2015-04-22 07:39:27 <wumpus> we *are* talking about the export format
133 2015-04-22 07:39:30 <nsh> there's probably a weak law to the effect that for anything where it's possible to make arbitrary choices, there's a way to form a convention that's better than no convention at all
134 2015-04-22 07:39:39 <nsh> (but more ways to do so that are worse)
135 2015-04-22 07:39:50 <CodeShark> key backups shouldn't be encrypted - they should just be split up into multiple pieces
136 2015-04-22 07:40:05 <gmaxwell> nsh: bad conventions are often worse than none; since they inhibit good convetions because mutiple is costly.
137 2015-04-22 07:40:10 <nsh> ACTION nods
138 2015-04-22 07:40:21 <moa> the source tarball is not much use if there has been a hardfork in the intervening years though
139 2015-04-22 07:40:43 <gmaxwell> moa: it means that your future code archeologists can figure out what that old version was doing in order to make sense of your backups.
140 2015-04-22 07:40:53 <sipa> jonasschnelli: perhaps you can read https://bitcointalk.org/index.php?topic=102349.0
141 2015-04-22 07:40:57 <gmaxwell> they shouldn't actually _run_ it.
142 2015-04-22 07:40:58 <CodeShark> if you're encrypting your master key and then storing the encrypted key it means either you're using a weaker decryption key than the ECDSA key's security itself...or you've essentially gained no additional security
143 2015-04-22 07:41:09 <jonasschnelli> sipa: thanks. Will read.
144 2015-04-22 07:41:11 <moa> right so like a core set of functionality
145 2015-04-22 07:41:12 <wumpus> moa: they can analyze it to find out how the wallet encryption works
146 2015-04-22 07:41:46 <gmaxwell> CodeShark: uh. what? no. You're not making sense there. No one is suggesting that encrypting your wallet removes the need to keep the wallet safe and private.
147 2015-04-22 07:41:56 <wumpus> moa: it would be a last ditch effort though, explicit documentation describing the format would of course be more useful
148 2015-04-22 07:42:11 <wumpus> (or a mostly self-documenting format)
149 2015-04-22 07:42:26 <moa> wumpus: maybe a wallet protocol spec doc
150 2015-04-22 07:42:49 <wumpus> huh?
151 2015-04-22 07:43:16 <moa> to be included with the archived backup
152 2015-04-22 07:43:34 <CodeShark> there are two separate things here, though, gmaxwell: 1) the encryption you use locally on the signing device - if the device gets compromised you might still have time to move your funds before the keys get compromised. 2) how you make longterm key backups
153 2015-04-22 07:43:35 <moa> for the archaeologists
154 2015-04-22 07:43:37 <wumpus> oh, right, I was confused at protocol spec
155 2015-04-22 07:43:45 <gmaxwell> CodeShark: you just haved tiered security; you have full ECDSA security against random internet people; and password security against someone who compromised your computer or backups. Absent the encryption you have no security at all against those people.
156 2015-04-22 07:44:13 <CodeShark> in the case of (1) it makes sense to use passphrase encryption as long as it takes more time to crack it than it takes for you to discover the compromise and move the funds
157 2015-04-22 07:44:22 <gmaxwell> moa: really since its a kind of fringe concern; my thought is that code is sufficient and basically costless to include! :)
158 2015-04-22 07:44:27 <CodeShark> more time to crack the passphrase, that is
159 2015-04-22 07:44:31 <moa> yup
160 2015-04-22 07:44:50 <CodeShark> in the case of (2), it's best to split up the key and store different parts in different tamper-evident locations
161 2015-04-22 07:45:07 <moa> a "nice to have" thing
162 2015-04-22 07:46:05 <gmaxwell> CodeShark: has a risk of keys being forgotten/lost to keep in mind; I'm not aware of any long term studies about the recoverability of treasure hunts. It may be that there is no threshold which is unlikely to fall into the wrong hands but robust enough against losing a part.
163 2015-04-22 07:46:35 <gmaxwell> I am aware of some disaster stories involving threshold split keys.
164 2015-04-22 07:46:42 <CodeShark> it's a good idea to rotate keys periodically anyhow
165 2015-04-22 07:46:51 <CodeShark> well before the threshold where you'd forget
166 2015-04-22 07:47:30 <wumpus> gmaxwell: hehe, on the other hand, name one kind of crypto usgae of which you're *not* aware of a disaster story :)
167 2015-04-22 07:47:36 <gmaxwell> Would be a good feature for the spending keys... a reminder if you have entered it within so long, when you go to get a new key it says "hey, you haven't used this key in X months, do you still remember it?"
168 2015-04-22 07:47:50 <CodeShark> I'd love a mechanism for revoking keys in bitcoin
169 2015-04-22 07:47:56 <wumpus> but forcing a scavenger hunt on users seems to be bit out there
170 2015-04-22 07:48:03 <gmaxwell> wumpus: any kind involving a bank, because you cry to them when you've lost your key and they make it all right. :)
171 2015-04-22 07:48:50 <sipa> until, of course, the bank fails
172 2015-04-22 07:48:54 <wumpus> gmaxwell: well, enough disaster stories with banks too, but sure probably not with the crypto.
173 2015-04-22 07:48:58 <gmaxwell> one issue for any of this cryptographic security is that most users have never actually dealt with it; ... users are not normally exposed to things where if they lose the key _no one_ can recover it.
174 2015-04-22 07:49:10 <sipa> but then people blame the bank, and not themselves for using the bank in the first place
175 2015-04-22 07:49:33 <moa> CodeShark: what would that look like "revoking keys in bitcoin"?
176 2015-04-22 07:49:48 <jonasschnelli> Lets say you are using 2of2 multisig with a hardware wallet (for the 2nd signature). How relevant is wallet encryption in that case?
177 2015-04-22 07:49:54 <gmaxwell> sipa: in the US the goverment creates moral hazard^W^Wconfidence in banking by insuring deposits via the FDIC. :)
178 2015-04-22 07:50:13 <CodeShark> p2sh doesn't allow for revocation of individual ECDSA keys, though - you can only revoke the p2sh itself
179 2015-04-22 07:50:17 <sipa> jonasschnelli: if attacking 1 of the 2 keys is trivial, the security is reduced to that of the other key
180 2015-04-22 07:51:07 <CodeShark> but revoking the p2sh itself is probably good enough for all conceivable use cases
181 2015-04-22 07:51:11 <gmaxwell> jonasschnelli: one of the best things the passwords do in Bitcoin Core's wallet today is create clear consent for spending; I know no matter what buttons I press, I will not manage to accidentally spend coins unless I enter my key.
182 2015-04-22 07:51:29 <jonasschnelli> Yes. I like this idea.
183 2015-04-22 07:51:56 <gmaxwell> (otherwise the bitcoin uri stuff seems really kinda scarry to me :) )
184 2015-04-22 07:52:21 <CodeShark> all signing devices intended to be used via GUI should prompt the user before signing and sending anything
185 2015-04-22 07:52:37 <CodeShark> if they don't they are horribly designed and you should not use them
186 2015-04-22 07:52:37 <jonasschnelli> Maybe before adding/improving wallet encryption, improving support for multisig could make more sense.
187 2015-04-22 07:53:26 <gmaxwell> CodeShark: prompts are easiy to accidally pass through, passwords not so much.
188 2015-04-22 07:54:01 <gmaxwell> obviously the bitcoin uri prompts, but if you clicked on it by accident because you were clicking away at something and it popped up....
189 2015-04-22 07:54:12 <CodeShark> if the user is careless enough that they might accidentally pass through the prompt they probably aren't capable of managing crypto keys themselves :p
190 2015-04-22 07:54:36 <sipa> CodeShark: sad truth
191 2015-04-22 07:54:44 <gmaxwell> CodeShark: People who think that shouldn't be writing security criticial software for users.
192 2015-04-22 07:54:53 <gmaxwell> Everyone makes mistakes.
193 2015-04-22 07:55:03 <gmaxwell> You've never clicked twice instead of once? come on.
194 2015-04-22 07:55:22 <CodeShark> I agree that mistakes can occur...but at some point you just can't foolproof a device intended to protect money
195 2015-04-22 07:55:22 <gmaxwell> Or said yes yes yes oops one too many yeses.
196 2015-04-22 07:55:32 <wumpus> the bitcoin URI just adds an entry, you still need to click twice after that
197 2015-04-22 07:55:47 <wumpus> once to send the payment, once to confirm the payment
198 2015-04-22 07:55:52 <sipa> i've ran "rm -rf bin" while root in / once
199 2015-04-22 07:55:53 <gmaxwell> It can't be error proof, of course; but it can be less of a loaded gun. No one is going to accidentally click pass a prompt for a unique spending key password. :)
200 2015-04-22 07:56:01 <CodeShark> you should be more careful when signing and sending transactions - it already requires at least two commands...possibly three if you're really careful
201 2015-04-22 07:56:05 <sipa> am i incapable of protecting my keys/m
202 2015-04-22 07:56:11 <kadoban> CodeShark: A ridiculous percentage of users of just about everything will immediately click through a prompt without reading it. It's pretty much guaranteed. Yeah it kinda sucks, but programmers have taught their users to do that, and it's kinda imposible to change that now.
203 2015-04-22 07:56:11 <sipa> ?
204 2015-04-22 07:56:38 <CodeShark> kadoban: in most situations I might not read a prompt - but when signing transactions I tend to be a little more careful :p
205 2015-04-22 07:56:51 <wumpus> sipa: yes, hand them to me for safekeeping right now *ducks*
206 2015-04-22 07:57:05 <jonasschnelli> ;)
207 2015-04-22 07:57:13 <moa> sipa: sometimes the gunsmith needs to work with the safety off
208 2015-04-22 07:57:26 <CodeShark> at the moment you're signing a transaction you need to be the most vigilant since that's when you're most likely to screw yourself
209 2015-04-22 07:57:41 <CodeShark> it's not the same as clicking through a prompt that chrome throws up at you
210 2015-04-22 07:58:25 <gmaxwell> It's not the users fault, they've been conditioned by useless dialogs constantly. We shouldn't blame people for the very human, very common, easily anticipatable outcomes that arise.
211 2015-04-22 07:58:28 <kadoban> CodeShark: Then wouldn't you say, as a programmer, it'd be best to use something /other/ than what we've trained a generation of two of computer users to blindly ignore?
212 2015-04-22 07:58:58 <CodeShark> kadoban: if this is the thing we should most fear in giving this crypto power to ordinary users I think we've done an amazing job :p
213 2015-04-22 07:59:00 <gmaxwell> CodeShark: people will hit okay before even seeing what the dialog is; part of the problem is all these dialogs that come up after the user has made a conscious decision to taken an action; they become refelx.
214 2015-04-22 07:59:03 <jonasschnelli> CodeShark: but lets say your create a TX in a wallet (bitcoind), seek for a 1st signature over a hardware wallet, check the returned half-signed tx and proceed. Where do you see a need for a display that shows you what to sign? Would anyone understand the information on the hardware wallets screen?
215 2015-04-22 07:59:14 <CodeShark> I think most users will shoot themselves in the foot well before they even get to this point
216 2015-04-22 07:59:49 <gmaxwell> jonasschnelli: this is why the payment protocol has things like the x509 certs; so the message displayed on the wallet can be the actual party that you're paying--- in a perfectly sensible form.
217 2015-04-22 08:01:35 <CodeShark> gmaxwell: always make the cancel button default
218 2015-04-22 08:01:47 <CodeShark> require that they actually click the OK
219 2015-04-22 08:01:48 <wumpus> it's obviously good to make it hard as possible for a usere to shoot themselves in the foot, on the other hand assume a basic level of seriousness and cluefulness with people handling a cryptocurrency application, otherwise it's impossible to do anything and we may as well give up completely
220 2015-04-22 08:01:50 <moa> maybe just a radically different OK prompt to break out of the conditioning, instead of small grey box with OK button ... a full screen red window
221 2015-04-22 08:02:12 <CodeShark> add a checkbox that says "I have read this prompt and agree..."
222 2015-04-22 08:02:15 <gmaxwell> Here is a little writup when I fell pray to click-click blindness once http://people.xiph.org/~greg/roadkill/roadkill.html
223 2015-04-22 08:02:20 <CodeShark> and disable clicking OK until the user checks the box
224 2015-04-22 08:02:27 <CodeShark> if you're really paranoid
225 2015-04-22 08:02:45 <sipa> gmaxwell: often see that with my dad; he complains about a program not working, i ask what is wrong and he says "a window popped up that i had to click away, and then..."; he is not even aware of the fact that that window is there to warn him about something. to him, the window itself is the manifestation of the problem
226 2015-04-22 08:02:50 <gmaxwell> "Drag the little dollar bill income into the paper shredder icon"
227 2015-04-22 08:02:54 <wumpus> CodeShark: HAH, as if people haven't been trained to ignore those
228 2015-04-22 08:03:14 <wumpus> CodeShark: 'yes I agree with these terms of conditions, what, I have to sacrifice my firstborn well it's ok check click'
229 2015-04-22 08:03:18 <CodeShark> lol
230 2015-04-22 08:03:41 <sipa> "meh, i won't have kids anyway"
231 2015-04-22 08:03:46 <wumpus> hehe
232 2015-04-22 08:03:48 <jonasschnelli> ;)
233 2015-04-22 08:04:21 <CodeShark> I guess people have even been trained to enter captchas without reading
234 2015-04-22 08:04:24 <CodeShark> *sigh*
235 2015-04-22 08:05:10 <moa> h/w wallets are good beacuse they require a physically separate action on a known "scary to use" device
236 2015-04-22 08:05:12 <CodeShark> anyhow, the default cancel with an extra checkbox at least reduces the risk of accidentally clicking or hitting a key
237 2015-04-22 08:05:31 <CodeShark> it won't stop users determined to click through from clicking through
238 2015-04-22 08:05:42 <moa> like puttinng key in the ignition
239 2015-04-22 08:05:56 <CodeShark> hw signing devices are ultimately the way to go
240 2015-04-22 08:05:58 <wumpus> what do vendors of dangerous tools and machines do to keep people from making deadly mistakes, these days?
241 2015-04-22 08:06:00 <CodeShark> but they shouldn't be called wallets
242 2015-04-22 08:06:11 <CodeShark> because the account management will most likely happen in software
243 2015-04-22 08:06:18 <CodeShark> the hw just signs
244 2015-04-22 08:06:19 <sipa> my father considers the hardware device he has to use to access his bank to be "torture"
245 2015-04-22 08:06:28 <moa> big red buttons on physically seperate panels
246 2015-04-22 08:06:33 <wumpus> yes I don't care about the 'warning - your leg is under the blade' warning, I want to start this saw right now click clcik
247 2015-04-22 08:06:36 <sipa> he vaguely understands it is more secure
248 2015-04-22 08:07:32 <moa> wumpus: nuclear missile launch requires two keys in switches separated by more than two arms lengths :)
249 2015-04-22 08:07:46 <moa> to be turned simultaneously
250 2015-04-22 08:07:53 <wumpus> oh shit, this incinerator doesn't come with an undo function?
251 2015-04-22 08:08:39 <gmaxwell> moa: and a gun to threaten the other guy with when he won't turn the key (wargames)
252 2015-04-22 08:09:03 <kadoban> moa: I remember seeing some documentary once, where they replaced that with a computer instead. Yeah wargames it was called ;)
253 2015-04-22 08:09:24 <moa> i think it's just codes in the "football" bag that one of the president's men carry around (at least last time i heard the official line)
254 2015-04-22 08:09:31 <gmaxwell> moa: so, ... all that key stuff got replaced with computer control; and they had so many problems managing the keys in the US that for years they were all just set to 0,0,0,0 .. or something innane like that.
255 2015-04-22 08:10:37 <moa> it's the "do you really want to do this?" problem
256 2015-04-22 08:11:07 <gmaxwell> moa: https://en.wikipedia.org/wiki/Permissive_Action_Link search for 0000 :)
257 2015-04-22 08:11:41 <wumpus> maybe they thought the nuclear missiles also have an undo function
258 2015-04-22 08:11:56 <wumpus> git revert world
259 2015-04-22 08:12:10 <gmaxwell> (the citation there is fun reading)
260 2015-04-22 08:12:12 <moa> ta
261 2015-04-22 08:13:08 <sipa> wumpus: this is why haskell has an IO monad, which is defined as a state monad modifying an implicit object of type World
262 2015-04-22 08:13:13 <gmaxwell> man should have thought of that example to use in my presentation; how can we hope to get this stuff right when they made the nuclear missile launch code OOOOOOOO and documented it in the install manuals. :)
263 2015-04-22 08:13:21 <wumpus> sipa: HAH wonderful
264 2015-04-22 08:14:13 <kadoban> I read down a bit ⦠in 1997 they upgraded to some new fancy system ⦠which had a y2k issue. Wow. How are we all not dead?
265 2015-04-22 08:14:55 <sipa> kadoban: we are; this is the afterlife
266 2015-04-22 08:15:04 <kadoban> sipa: Oh good
267 2015-04-22 08:15:16 <sipa> did you really think cryptocurrencies were something viable in reality?
268 2015-04-22 08:15:19 <moa> sipa: that's dark
269 2015-04-22 08:15:28 <wumpus> we terraformed it and called it earth again, because we like the suffering too much
270 2015-04-22 08:17:01 <CodeShark> were those cryptographic processors with the potential y2k problem programmed in COBOL?
271 2015-04-22 08:17:27 <wumpus> ADA
272 2015-04-22 08:17:38 <moa> nup "git revert world" not implemented yet
273 2015-04-22 08:18:15 <moa> git revert --abort might be your best hope at that point
274 2015-04-22 08:20:08 <wumpus> git pray --veryhard
275 2015-04-22 08:21:47 <moa> intermediate reversible steps are an option but maybe encourage click-through desensitising
276 2015-04-22 08:22:45 <CodeShark> apply different policies for different levels of risk - and be aware of what risk level you're at
277 2015-04-22 08:22:56 <CodeShark> i.e. limit your losses to something small if you click through
278 2015-04-22 08:23:05 <CodeShark> if you want to send more, require a passphrase
279 2015-04-22 08:23:10 <CodeShark> if you want to send even more, require 2fa
280 2015-04-22 08:23:11 <CodeShark> etc...
281 2015-04-22 08:23:15 <cfields_> jonasschnelli: mm, looks like i missed the discussion earlier, but my aes-wallet branch re-works our wallet passphrase to use openssl's mechanism. As a side-effect, it allows for easy use of aes-cbc without padding
282 2015-04-22 08:23:29 <cfields_> (sorry if i'm re-hashing a dead argument, i just skimmed the beginning of the discussion)
283 2015-04-22 08:23:37 <moa> manually operated local payment channels, each click commits 1 bit to cold storage
284 2015-04-22 08:23:59 <moa> you now have only 9,999 clicks remainf
285 2015-04-22 08:24:31 <CodeShark> by not requiring the passphrase or 2fa step every single time even for tiny transactions the user doesn't become desensitized