< GitHub65>
[bitcoin] sipa opened pull request #7891: Always require OS randomness when generating secret keys (master...betterrng) https://github.com/bitcoin/bitcoin/pull/7891
< nsh>
scary PR is scary...
< sipa>
nsh: mine?
< nsh>
aye, but doesn't look so bad on inspection
< nsh>
had a brief but-for-the-grace-of-god moment
< nsh>
heh, seems nothing else is using RandAddSeedPerfmon anymore
< sipa>
there are calls at first startup, inside processmessages, and before signing in the wallet
< * nsh>
nods
< gmaxwell>
I earlier made the observation to sipa that getting away from openssl's RNG has three parts: A combiner to take OS randomness at the point of key usage; an internal CSPRNG; and a seeding process. The internal CSPRNG has implementation annoyances around things like thread safty. But we can do the other two parts with openssl still there, taking the places of the eventual internal CSPRNG.
< gmaxwell>
And so that would be a good way to make progress on this.
< nsh>
makes sense
< nsh>
what might be thread-unsafe about an internal CSPRNG?
< sipa>
well you need locking on your entropy pool
< sipa>
at the very least
< sipa>
or perhaps per-thread entropy pools (using thread local storage), which only under certain conditions request entropy from the global process-wide one
< sipa>
and these are things you can't easily do in a portable C library (which is something that was requested before in #5885 and #7162)
< Chris_Stewart_5>
With these version bits we could make radical departures to Script as we see it now right? For instance trying to type Script?
< sipa>
yes
< Chris_Stewart_5>
oooh so much potential :-)
< Luke-Jr>
well, that's segwit's witness script versioning more than versionbits..
< sipa>
Luke-Jr: oh, absolutely
< sipa>
though the combination makes it even easier
< Chris_Stewart_5>
I'll have to read up on the difference
< sipa>
versionbits is about being to roll out multiple softforks in parallel
< sipa>
segwit script versioning means every script change can be turned into a softfork
< Chris_Stewart_5>
intuitively I thought the script verisioning just allows for versions similar to other PLs - for instance python 2.7.x is that more or less correct?
< sipa>
right now, we can't for example change checksig to use a different signature type
< sipa>
(that would be a hardfork)
< Chris_Stewart_5>
sure
< sipa>
with script versioning, we can just change checksig's definition
< sipa>
wumpus or any other gitian building, are there any known problems with certain gitian virtualizations? (virtualbox, KVM, LXC, ...) ?
< sipa>
or are they all known to work?
< sipa>
oh, that's the outer layer virtualization
< sipa>
nvm
< Chris_Stewart_5>
What about size requirements? That is vague question but perhaps we decide not to use SHA256 anymore and switch to another hash algorithm that produces a different size of digest compared to SHA256
< sipa>
yes, maybe
< Chris_Stewart_5>
Could this 'bleed' out of the script versioning system into other parts of consensus code?
< Chris_Stewart_5>
if that makes any sense
< sipa>
it can be made not to
< Chris_Stewart_5>
interesting
< MarcoFalke>
re: cpp11
< MarcoFalke>
> wumpus: hopefully we can start supporting it this week then
< MarcoFalke>
Does this mean we have trusty in travis this week?
< wumpus>
yes
< MarcoFalke>
good, so the py3.2 issue is not a blocker for the py3 switch