1 2012-03-19 00:03:05 <jrmithdobbs> wtf, thx theo
 2 2012-03-19 00:03:06 <jrmithdobbs> $ apropos EVP_CIPHER_CTX_init
 3 2012-03-19 00:03:11 <jrmithdobbs> EVP_CIPHER_CTX_init, EVP_EncryptInit_ex, EVP_EncryptUpdate, EVP_EncryptFinal_ex, EVP_DecryptInit_ex, EVP_DecryptUpdate, EVP_DecryptFinal_ex, EVP_CipherInit_ex, EVP_CipherUpdate, EVP_CipherFinal_ex, EVP_CIPHER_CTX_set_key_length, EVP_CIPHER_CTX_ctrl, EVP_CIPHER_CTX_cleanup, EVP_EncryptInit, EVP_EncryptFinal, EVP_DecryptInit, EVP_DecryptFinal, EVP_CipherInit, EVP_CipherFinal, EVP_get_cipherbyname, EVP_get_cipherbynid, EVP_get_cipherbyobj, EVP_C
 4 2012-03-19 00:03:34 <jrmithdobbs> $ man 3 EVP_CIPHER_CTX_init
 5 2012-03-19 00:03:37 <jrmithdobbs> man: no entry for EVP_CIPHER_CTX_init in section 3 of the manual.
 6 2012-03-19 00:03:38 <jrmithdobbs> lol
 7 2012-03-19 00:05:11 <jrmithdobbs> oddly, it works on the linux box but not the openbsd one, lol
 8 2012-03-19 00:06:22 <jrmithdobbs> sipa: it has an option to turn off padding
 9 2012-03-19 00:06:43 <sipa> jrmithdobbs: yes, already found, reported here, implemented, tested and pull requested ;)
10 2012-03-19 00:06:59 <jrmithdobbs> sipa: teach me to only read half the conversation, haha
11 2012-03-19 00:08:10 <gribble> New news from bitcoinrss: sipa opened pull request 950 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/950>
12 2012-03-19 00:08:21 <jrmithdobbs> still wondering how to get to that manpage on the openbsd box
13 2012-03-19 00:08:24 <jrmithdobbs> that bothers me
14 2012-03-19 00:10:04 <jrmithdobbs> there it is, EVP_EncryptInit(3) retarded
15 2012-03-19 00:10:29 <BlueMatt> sipa: why is fPad optional, why not just force it?
16 2012-03-19 00:10:41 <BlueMatt> or will it not decrypt if you dont tell it properly to pad or not?
17 2012-03-19 00:10:50 <sipa> BlueMatt: because we also use it for master keys, where we cannot use it
18 2012-03-19 00:10:58 <BlueMatt> why not?
19 2012-03-19 00:11:08 <BlueMatt> why do we have to pad on mkeys?
20 2012-03-19 00:11:14 <sipa> it's not guaranteed to be a multiple of 16 bytes
21 2012-03-19 00:11:21 <BlueMatt> yea it is
22 2012-03-19 00:11:38 <BlueMatt> in fact, is it not guaranteed to be 32 bytes?
23 2012-03-19 00:12:08 <BlueMatt> and if we do pad mkeys, dont fix 933, do we?
24 2012-03-19 00:12:30 <jrmithdobbs> forever and ever? there will never ever be a reason to change ciphers/keysize for the wallet crypto?
25 2012-03-19 00:12:43 <jrmithdobbs> or have multiple options for it?
26 2012-03-19 00:13:22 <jrmithdobbs> you're right so long as it stays aes256 though
27 2012-03-19 00:13:26 <jrmithdobbs> key will always be 32 bytes
28 2012-03-19 00:13:48 <BlueMatt> then you can easily increment the nDerivationMethod or smth
29 2012-03-19 00:14:10 <BlueMatt> as long as nDerivationMethod = EVP_sha512, then yea it is 32 bytes
30 2012-03-19 00:14:34 <sipa> hmm, padding the encryption of the master key is actually even worse
31 2012-03-19 00:14:40 <sipa> as a leak
32 2012-03-19 00:14:54 <sipa> because an attacker doesn't even need to check any wallet key at all anymore
33 2012-03-19 00:15:01 <BlueMatt> yep
34 2012-03-19 00:15:03 <sipa> (though again, we don't rely on that for security)
35 2012-03-19 00:15:11 <BlueMatt> yea, but its nice to have
36 2012-03-19 00:15:40 <jrmithdobbs> sipa: i think a 16 byte multiple is a fine req for keysize, even if something that isn't ends up being used can just manually pad with random data
37 2012-03-19 00:16:50 <jrmithdobbs> (it also holds true for most non-toy ciphers anyways)
38 2012-03-19 00:17:47 <BlueMatt> Id say, add a comment above nDerivationMethod that says it can be used as either nDerivationMethod or nEncryptionMethod and say that nDerivationMethod == 0 means AES... and 32-byte mkey and sha512, etc, etc
39 2012-03-19 00:17:52 <BlueMatt> then you are safe
40 2012-03-19 00:18:11 <sipa> BlueMatt: i'm still going to keep CCrypter::Encrypt/Decrypt have a padding that defaults to true; people may use it for other things than keys as well
41 2012-03-19 00:18:21 <BlueMatt> thats fine
42 2012-03-19 00:19:46 <sipa> seems to work
43 2012-03-19 00:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
44 2012-03-19 01:27:42 <Samuel> Hello.
45 2012-03-19 01:28:58 <BlueMatt> hi
46 2012-03-19 01:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
47 2012-03-19 01:36:59 <Joric> does reference client send change back to the source address? how does it choose the return address?
48 2012-03-19 01:37:22 <sipa> simple: the next address is used
49 2012-03-19 01:37:30 <sipa> from the key pool
50 2012-03-19 01:37:50 <sipa> it never sends back to the source address, unless the key pool is empty
51 2012-03-19 01:38:05 <BlueMatt> no, it never sends back to the source address
52 2012-03-19 01:38:11 <BlueMatt> the keypool cant be empty at send time
53 2012-03-19 01:38:17 <sipa> oh, of course
54 2012-03-19 01:40:07 <Joric> so basically almost every transaction you increase a number of addresses in the blockchain
55 2012-03-19 01:40:18 <Joric> doesn't seem very rational
56 2012-03-19 01:40:34 <sipa> a new address in the blockchain doesn't use more space than an old one
57 2012-03-19 01:42:03 <BlueMatt> bugs blockchain.info, but doesnt bug any regular bitcoin use...
58 2012-03-19 01:42:42 <Joric> yeah index gets bigger and bigger all the time
59 2012-03-19 01:42:51 <BlueMatt> that is from txes, not from addresses
60 2012-03-19 01:43:08 <sipa> there is no address index anywhere in the bitcoin core
61 2012-03-19 01:43:13 <sipa> nor should there be
62 2012-03-19 01:43:30 <sipa> (it could be useful in some cases, but optional)
63 2012-03-19 01:51:16 <luke-jr> Joric: the Bitcoin protocol is ignorant of addresses
64 2012-03-19 01:52:13 <sipa> yes, they only exist in the wallet/ledger-view built on top of it
65 2012-03-19 01:52:38 <BlueMatt> sipa: what needs to go in 0.6, aside from #950 and #948?
66 2012-03-19 01:53:46 <BlueMatt> gmaxwell: have a minute and a half to ack 950 and 948, also what do you think needs to go in 0.6?
67 2012-03-19 01:54:25 <luke-jr> pulls pending for 0.6 final: 947, 946, 936, 928, and it'd be nice to see 931 in
68 2012-03-19 01:54:40 <BlueMatt> oh, yea and 947
69 2012-03-19 01:54:46 <sipa> 947 probably doesn't harm, though it hardly helps anyway
70 2012-03-19 01:55:16 <sipa> when was getmemorypool introduced?
71 2012-03-19 01:55:22 <BlueMatt> nack on 936 for 0.6, seriously its not a bugfix, its a new feature, there is no reason to add it to 0.6...
72 2012-03-19 01:55:27 <luke-jr> sipa: 0.5; the BIP was written to be compatible
73 2012-03-19 01:55:34 <BlueMatt> 928, whatever
74 2012-03-19 01:55:54 <BlueMatt> 931 whatever
75 2012-03-19 01:56:05 <sipa> indeed, 936 for 0.7 looks fine
76 2012-03-19 01:56:20 <sipa> (which hopefully doesn't take as long as 0.6)
77 2012-03-19 01:56:57 <sipa> 928 can go in 0.6 if wumpus acks it
78 2012-03-19 01:57:27 <luke-jr> sipa: "coinbaseflags" added during 0.6 isn't compatible, and was replaced by "coinbaseaux" early on - the bitcoind code just hasn't been fixed for it yet
79 2012-03-19 01:57:44 <sipa> compatible with what?
80 2012-03-19 01:57:47 <luke-jr> the BIP
81 2012-03-19 01:58:04 <BlueMatt> how much discussion of the bip has there been on the mailing list?
82 2012-03-19 01:58:19 <gmaxwell> sipa: How did you test 948?
83 2012-03-19 01:58:29 <luke-jr> BlueMatt: quite a bit; but coinbaseaux was changed pre-BIP with consensus from people using getmemorypool
84 2012-03-19 01:59:14 <luke-jr> (Jan 20)
85 2012-03-19 01:59:35 <sipa> gmaxwell: i merged with loadblocks and did an import of a previous testnet blk0001.dat file, which causes some reorganisations
86 2012-03-19 01:59:43 <sipa> gmaxwell: i didn't test that it actually solves the issue, though
87 2012-03-19 02:00:28 <BlueMatt> I thought you said you tested it with mcorlett
88 2012-03-19 02:00:39 <gmaxwell> Are we planning on cutting another 0.6 rc?