1 2017-04-29 12:50:15	0|bitcoin-git|13bitcoin/06master 14dd1ea59 15Jimmy Song: [test] Add gettxout call...
 2 2017-04-29 12:50:15	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4c924011f535...80c3a734298e
 3 2017-04-29 12:50:16	0|bitcoin-git|13bitcoin/06master 1480c3a73 15MarcoFalke: Merge #10256: [test] Add test for gettxout to wallet.py...
 4 2017-04-29 12:50:31	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10256: [test] Add test for gettxout to wallet.py (06master...06test_gettxout) 02https://github.com/bitcoin/bitcoin/pull/10256
 5 2017-04-29 17:58:51	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10299: Remove OpenSSL (06master...06simplerandom) 02https://github.com/bitcoin/bitcoin/pull/10299
 6 2017-04-29 18:35:44	0|gmaxwell|wumpus: your comment is needed at https://github.com/bitcoin-core/secp256k1/pull/440
 7 2017-04-29 18:55:09	0|BlueMatt|sipa: re: 10299: I dont think thats 100% true? doesn't openssl's rng also pull other random things on some oses?
 8 2017-04-29 18:55:16	0|BlueMatt|at least win used to take a screenshot or something like that, no?
 9 2017-04-29 18:56:08	0|gmaxwell|look at the code sipa is removing, -- it has the screenshot addition stuff.
10 2017-04-29 18:56:25	0|gmaxwell|I don't care how things are split into PRs however.
11 2017-04-29 18:57:20	0|BlueMatt|ah, apologies
12 2017-04-29 18:57:48	0|sipa|BlueMatt: for windows, yes, it removes all that. i can't imagine it's useful these days
13 2017-04-29 18:58:28	0|sipa|but i don't know what openssl is using on netbsd that would still result in much useful entropy, if dev/urandom etc are broken
14 2017-04-29 18:59:07	0|BlueMatt|are y'all gonna revive the librng idea?
15 2017-04-29 18:59:10	0|BlueMatt|(please do)
16 2017-04-29 18:59:41	0|gmaxwell|BlueMatt: concurrency makes it too hard.
17 2017-04-29 19:00:02	0|BlueMatt|ok, so librng-no-concurrency?
18 2017-04-29 19:00:08	0|sipa|gmaxwell: if it's purely gathering entropy, it's mucb easier
19 2017-04-29 19:00:12	0|gmaxwell|sipa: IIRC openssl also adds a number of system things into the entropy pool. Not as extensive as what we did before.
20 2017-04-29 19:00:15	0|BlueMatt|or that
21 2017-04-29 19:00:29	0|BlueMatt|libgivemeentropy
22 2017-04-29 19:00:30	0|gmaxwell|well. I posted code before, sipa extended in and C++ ified it.
23 2017-04-29 19:00:41	0|BlueMatt|yes, my question was if y'all were gonna pull that back in
24 2017-04-29 19:00:43	0|BlueMatt|(please do!)
25 2017-04-29 19:00:50	0|gmaxwell|s/in/it/
26 2017-04-29 19:00:56	0|sipa|yes, i'm all for that, but i think it's pretty orthogonal to getting rid of openssl
27 2017-04-29 19:01:26	0|BlueMatt|orthogonal, maybe, but I'd prefer to see them in the same release
28 2017-04-29 19:02:06	0|gmaxwell|next we will suggest storing that state in a memory map of its own, so its not contiguous with other variables that could bleed. :P
29 2017-04-29 19:02:18	0|jonasschnelli|Would unpack stuff from #5885 (https://github.com/bitcoin/bitcoin/pull/5885/files#diff-35f8a407f8c21cda300a45f50b6e9c74L5) make sense?
30 2017-04-29 19:02:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/5885 | [WIP] Replace OpenSSL PRNG with built-in Fortuna implementation by sipa · Pull Request #5885 · bitcoin/bitcoin · GitHub
31 2017-04-29 19:02:35	0|BlueMatt|gmaxwell: if you think I'm asking too much, feel free to shoot it down....
32 2017-04-29 19:02:43	0|BlueMatt|i have no idea how much work there is there
33 2017-04-29 19:03:28	0|gmaxwell|BlueMatt: no I agree with you.
34 2017-04-29 19:03:51	0|gmaxwell|I don't care if its in this PR however, but it should be in the same release.
35 2017-04-29 19:04:17	0|sipa|gmaxwell: i think it's (fun) overkill
36 2017-04-29 19:04:27	0|gmaxwell|what I'd proposed before is we do the seeder first, feed its output into OpenSSL...
37 2017-04-29 19:05:07	0|gmaxwell|sipa: there have been two OS releases with the OS rng returning nothing useful while we've been working on this project... I don't think making extra effort to not be completely insecure in that case is overkill.
38 2017-04-29 19:05:48	0|sipa|gmaxwell: my assumption is that the (barely maintained) openssl code can't be guaranteeing much in such a broken state either
39 2017-04-29 19:06:12	0|sipa|i agree it's a useful goal to attempt to be secure in that case, but i do see it as a separate improvement
40 2017-04-29 19:06:35	0|gmaxwell|which was why I previously suggested doing it first. :)
41 2017-04-29 19:06:41	0|sipa|this is trivial
42 2017-04-29 19:06:54	0|sipa|librng will be a pain to make production ready
43 2017-04-29 19:07:06	0|gmaxwell|I have no interest in a "librng" I don't think its tractable.
44 2017-04-29 19:07:08	0|BlueMatt|sipa: making it a library yes, making it libgivemeentropy, I'd hope a bit less so
45 2017-04-29 19:07:23	0|gmaxwell|handling concurrency is too hard if you also care a lot about performance.
46 2017-04-29 19:07:26	0|sipa|BlueMatt: wumpus did not feel like pulling all that code into core without making it reusable
47 2017-04-29 19:07:49	0|BlueMatt|sipa: isnt libgivemeentropy reuseable?
48 2017-04-29 19:07:54	0|gmaxwell|I am going to NAK this PR, since it seems unlikely that we'll get improved seeding at all.
49 2017-04-29 19:07:57	0|BlueMatt|(and easier than librng)
50 2017-04-29 19:08:05	0|sipa|gmaxwell: i don't understand
51 2017-04-29 19:08:39	0|sipa|why should improved seeding be a requirement to drop openssl?
52 2017-04-29 19:09:07	0|gmaxwell|You are busy arguing now that we're unlikely to get improved seeding, because wumpus wanted a reusable library, and we've evaluated it and determined that making something fast and fork tolerant while handling concurrency and being portable is more or less too hard.
53 2017-04-29 19:09:17	0|gmaxwell|Because the change is worse than what openssl does!
54 2017-04-29 19:09:32	0|sipa|we don't need the performance requirement anymore
55 2017-04-29 19:09:57	0|gmaxwell|I know we don't, but an external library does if anyone else is ever going to use it. Which is why we haven't done that.
56 2017-04-29 19:10:16	0|sipa|as all needs for randomness are split into high-performance or high-entropy, with no overlap
57 2017-04-29 19:10:32	0|sipa|so a libuserentropy or whatever should become a lot easier to do
58 2017-04-29 19:11:01	0|sipa|which makes it tractable to do
59 2017-04-29 19:11:06	0|sipa|but it's still a lot of work
60 2017-04-29 19:11:18	0|sipa|which i think shouldn't be blocking this
61 2017-04-29 19:12:16	0|gmaxwell|This is obviously weaker than the initilization with openssl. You're basically arguing that this should go first because doing other things won't happen soon. Don't you see why I can't support that?
62 2017-04-29 19:12:48	0|gmaxwell|Seperate PRs fine, but a change that I think is only acceptable with another change that you're saying won't happen soon?
63 2017-04-29 19:13:12	0|sipa|my view is that we currently have no guarantees about security if OS entropy is broken
64 2017-04-29 19:13:27	0|sipa|this makes it stronger, because all randomness queries no go to the OS
65 2017-04-29 19:13:30	0|sipa|*now
66 2017-04-29 19:14:09	0|sipa|if we want security in the assumotion of a broken OS, that is something that can be done independently (and more easily after this PR)
67 2017-04-29 19:14:14	0|sipa|*assumption
68 2017-04-29 19:15:15	0|gmaxwell|It's stronger because it goes straight to something which we've known to be insecure in recent memory?
69 2017-04-29 19:15:44	0|sipa|go find me what openssl would do in those cases
70 2017-04-29 19:16:12	0|sipa|do we even know?
71 2017-04-29 19:16:22	0|gmaxwell|I posted about it before, rng is seeded based on a collection of different pointers and timestamps. And in Bitcoin on windows, based on a screenshot.
72 2017-04-29 19:18:22	0|sipa|does that guarantee anything?
73 2017-04-29 19:18:46	0|sipa|at least you'd need things like memory latency based measurements
74 2017-04-29 19:19:49	0|BlueMatt|sounds a) doable on a reasonable timeline (unlike, maybe, librng) b) just as good for our usage
75 2017-04-29 19:19:51	0|sipa|BlueMatt: nothing wrong with it, i think it's a great idea
76 2017-04-29 19:20:10	0|sipa|but i think it's orthogonal to chaning the RNG
77 2017-04-29 19:20:18	0|BlueMatt|ok, so lets do both that and removing openssl in the same release and move on with our day?
78 2017-04-29 19:21:32	0|sipa|well if there is a requirement to do it in the same release, we should do it simultaneously
79 2017-04-29 19:21:41	0|gmaxwell|sipa: nothing here guarentees anything; thats a weird ask that you're making.
80 2017-04-29 19:22:06	0|sipa|sigh
81 2017-04-29 19:39:45	0|sipa|gmaxwell: if all the seeding code was something we'd just add in random.cpp, i'll gladly do it even in the same PR
82 2017-04-29 19:40:04	0|sipa|but my assumption is that others wouldn't consider that the right place
83 2017-04-29 19:40:45	0|sipa|and if what is needed is a separate library will autotools and various detection for parts of operating systems, that's not something i want to take on writing and maintaing
84 2017-04-29 19:42:04	0|sipa|and if we both need better seeding code and making it effectively reusable are requirements before making progress on our RNG code, then yes, i fear it won't happen
85 2017-04-29 19:42:06	0|BlueMatt|sipa: I'm happy with it in random.cpp, that sounds like a wumpus question, though
86 2017-04-29 19:42:25	0|sipa|yes
87 2017-04-29 19:43:28	0|sipa|but it's not an unreasonable thing to ask
88 2017-04-29 19:43:39	0|sipa|and neither is requiring better seeding code
89 2017-04-29 19:44:07	0|sipa|in my view, if your OS randomness is broken, you're fucked
90 2017-04-29 19:44:25	0|sipa|maybe the current OpenSSL code helps with it, and maybe it doesn't
91 2017-04-29 19:44:43	0|sipa|it's a cool problem, with a cool solution, to try to protect against that
92 2017-04-29 19:46:50	0|sipa|but i don't feel like working on it when there are too many conflicting demands