< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4c924011f535...80c3a734298e
< bitcoin-git> bitcoin/master dd1ea59 Jimmy Song: [test] Add gettxout call...
< bitcoin-git> bitcoin/master 80c3a73 MarcoFalke: Merge #10256: [test] Add test for gettxout to wallet.py...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10256: [test] Add test for gettxout to wallet.py (master...test_gettxout) https://github.com/bitcoin/bitcoin/pull/10256
< bitcoin-git> [bitcoin] sipa opened pull request #10299: Remove OpenSSL (master...simplerandom) https://github.com/bitcoin/bitcoin/pull/10299
< gmaxwell> wumpus: your comment is needed at https://github.com/bitcoin-core/secp256k1/pull/440
< BlueMatt> sipa: re: 10299: I dont think thats 100% true? doesn't openssl's rng also pull other random things on some oses?
< BlueMatt> at least win used to take a screenshot or something like that, no?
< gmaxwell> look at the code sipa is removing, -- it has the screenshot addition stuff.
< gmaxwell> I don't care how things are split into PRs however.
< BlueMatt> ah, apologies
< sipa> BlueMatt: for windows, yes, it removes all that. i can't imagine it's useful these days
< 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
< BlueMatt> are y'all gonna revive the librng idea?
< BlueMatt> (please do)
< * jonasschnelli> thinks of someone who gives out recommendation to open minesweeper before starting Core.
< gmaxwell> BlueMatt: concurrency makes it too hard.
< BlueMatt> ok, so librng-no-concurrency?
< sipa> gmaxwell: if it's purely gathering entropy, it's mucb easier
< gmaxwell> sipa: IIRC openssl also adds a number of system things into the entropy pool. Not as extensive as what we did before.
< BlueMatt> or that
< BlueMatt> libgivemeentropy
< gmaxwell> well. I posted code before, sipa extended in and C++ ified it.
< BlueMatt> yes, my question was if y'all were gonna pull that back in
< BlueMatt> (please do!)
< gmaxwell> s/in/it/
< sipa> yes, i'm all for that, but i think it's pretty orthogonal to getting rid of openssl
< BlueMatt> orthogonal, maybe, but I'd prefer to see them in the same release
< 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
< jonasschnelli> Would unpack stuff from #5885 (https://github.com/bitcoin/bitcoin/pull/5885/files#diff-35f8a407f8c21cda300a45f50b6e9c74L5) make sense?
< 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
< BlueMatt> gmaxwell: if you think I'm asking too much, feel free to shoot it down....
< BlueMatt> i have no idea how much work there is there
< gmaxwell> BlueMatt: no I agree with you.
< gmaxwell> I don't care if its in this PR however, but it should be in the same release.
< sipa> gmaxwell: i think it's (fun) overkill
< gmaxwell> what I'd proposed before is we do the seeder first, feed its output into OpenSSL...
< 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.
< sipa> gmaxwell: my assumption is that the (barely maintained) openssl code can't be guaranteeing much in such a broken state either
< 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
< gmaxwell> which was why I previously suggested doing it first. :)
< sipa> this is trivial
< sipa> librng will be a pain to make production ready
< gmaxwell> I have no interest in a "librng" I don't think its tractable.
< BlueMatt> sipa: making it a library yes, making it libgivemeentropy, I'd hope a bit less so
< gmaxwell> handling concurrency is too hard if you also care a lot about performance.
< sipa> BlueMatt: wumpus did not feel like pulling all that code into core without making it reusable
< BlueMatt> sipa: isnt libgivemeentropy reuseable?
< gmaxwell> I am going to NAK this PR, since it seems unlikely that we'll get improved seeding at all.
< BlueMatt> (and easier than librng)
< sipa> gmaxwell: i don't understand
< sipa> why should improved seeding be a requirement to drop openssl?
< 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.
< gmaxwell> Because the change is worse than what openssl does!
< sipa> we don't need the performance requirement anymore
< 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.
< sipa> as all needs for randomness are split into high-performance or high-entropy, with no overlap
< sipa> so a libuserentropy or whatever should become a lot easier to do
< sipa> which makes it tractable to do
< sipa> but it's still a lot of work
< sipa> which i think shouldn't be blocking this
< 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?
< gmaxwell> Seperate PRs fine, but a change that I think is only acceptable with another change that you're saying won't happen soon?
< sipa> my view is that we currently have no guarantees about security if OS entropy is broken
< sipa> this makes it stronger, because all randomness queries no go to the OS
< sipa> *now
< 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)
< sipa> *assumption
< gmaxwell> It's stronger because it goes straight to something which we've known to be insecure in recent memory?
< sipa> go find me what openssl would do in those cases
< sipa> do we even know?
< 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.
< sipa> does that guarantee anything?
< sipa> at least you'd need things like memory latency based measurements
< * BlueMatt> is so confused, what was wrong with taking just the entropy-generating parts, pulling those out into a libgivemeentropy, and using that as an entropy source?
< BlueMatt> sounds a) doable on a reasonable timeline (unlike, maybe, librng) b) just as good for our usage
< sipa> BlueMatt: nothing wrong with it, i think it's a great idea
< sipa> but i think it's orthogonal to chaning the RNG
< BlueMatt> ok, so lets do both that and removing openssl in the same release and move on with our day?
< sipa> well if there is a requirement to do it in the same release, we should do it simultaneously
< gmaxwell> sipa: nothing here guarentees anything; thats a weird ask that you're making.
< sipa> sigh
< * sipa> weekend
< 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
< sipa> but my assumption is that others wouldn't consider that the right place
< 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
< 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
< BlueMatt> sipa: I'm happy with it in random.cpp, that sounds like a wumpus question, though
< sipa> yes
< sipa> but it's not an unreasonable thing to ask
< sipa> and neither is requiring better seeding code
< sipa> in my view, if your OS randomness is broken, you're fucked
< sipa> maybe the current OpenSSL code helps with it, and maybe it doesn't
< sipa> it's a cool problem, with a cool solution, to try to protect against that
< sipa> but i don't feel like working on it when there are too many conflicting demands