< bitcoin-git>
bitcoin/master 0ff9320 jonnynewbs: refactor TxToJSON() and ScriptPubKeyToJSON()
< bitcoin-git>
bitcoin/master 9c33ffd Wladimir J. van der Laan: Merge #8824: Refactor TxToJSON() and ScriptPubKeyToJSON()...
<@wumpus>
gmaxwell: sipa: I'm just worried that taking up the concern of doing proper seeding in bitcoin core itself, without anyone else looking at it or using it, will result in a worse outcome for us. Allthe platform specific stuff is a hell to maintain, and it forces us to stay up to date in developments in that area
<@wumpus>
a person can't be a specialist in everything, and neither can a project, I think
< gmaxwell>
someone else writing it doesn't magically make it good however, it can just be a way to launder bad code.
< wumpus>
yes, that is true too
< gmaxwell>
the openssl code smells pretty bad. (in particular, IIRC if it's unable to open any strong random device it keeps on going)-- but it does at least have the benefit of being widely used. I too am not keep on platform specfifc code, we don't want to have a case where someone runs on BeOS and doesn't get randomness at all because /dev/urandom is symlinked ot /dev/zero and how were we so stupid as t
< gmaxwell>
o not know this and account for it. :P
< wumpus>
but someone else cooporating on it outside the context of bitcoin core (which is pretty narrow) isn't necessarily bad
< gmaxwell>
The challenge we have for doing a general RNG library which you suggested before (we tried) is that our needs are pretty different and addressing it in the general case is really really hard. In particular, other applications have strong performance requirements that necessitates lockfree state management, while at the same time handling forced RNG reseeding across forks. The approaches people
< gmaxwell>
have come up with for this are ugly and pretty platform specific. And these are both properties that we don't need.
< wumpus>
yes, defending openssl in that regard is pretty pointless
< gmaxwell>
(they're handling the fork transisition stuff using things like special page flags that cause tagged pages to get zeroed on fork ... and other similar functionality that is different on every OS that implements something like it)
< wumpus>
"In particular, other applications have strong performance requirements that necessitates lockfree state management" then we explicitly exclude those
< wumpus>
the kind of thing I'm thinking of it other wallets
< gmaxwell>
('there' in this case referring to other people attempting general RNG code.)
< wumpus>
usually need low-frequency, but very good entropy
< gmaxwell>
okay we could do something that would perhaps mostly only be used by other bitcoin things.
< gmaxwell>
(or cryptocurrency rather)
< wumpus>
yup other cryptocurrency and things that need strong keys
< wumpus>
it's a growing space at least
< wumpus>
indeed I don't care the least about satisfying any need for randomness for any project in existence
< wumpus>
but improving wallets in general would already be a nice aim
< gmaxwell>
well one thing that was suggested was just doing initial seed generation as a library, which is basically all you need for most wallet keygen things, and has the least concern.
< wumpus>
yup
< wumpus>
then we agree I guess :)
< gmaxwell>
okay, thats a fine scope.
< wumpus>
I sometimes wonder what gpg's key generation does
< wumpus>
this is the only non-wallet example of a long term key, not easy to replace, potential disaster if compromised, that I can think of right now
< kallewoof>
Maybe bitcoin could use libgcrypt (GnuPG uses it for keys, I think; it has a bunch of random things) instead of OpenSSL. Though it seems to be LGPL. Some parts of it are dual MPL-compat though, like random-drbg.c
< kallewoof>
"a bunch of random things" = "a bunch of things related to RNG"
< kallewoof>
Uh, meant MIT, not MPL
< bitcoin-git>
[bitcoin] kallewoof opened pull request #10304: [rpc] Allow a txid param in getrawmempool (master...getrawmempool-include-txid) https://github.com/bitcoin/bitcoin/pull/10304
< bitcoin-git>
bitcoin/master 7c58863 Gregory Sanders: [Wallet] unset change position when there is no change on exact match
< bitcoin-git>
bitcoin/master e2b99b1 Wladimir J. van der Laan: Merge #10294: [Wallet] unset change position when there is no change...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10294: [Wallet] unset change position when there is no change (master...fixchangepos) https://github.com/bitcoin/bitcoin/pull/10294
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #10305: Fix potential NPD introduced in b297426c (master...2017-05-fix-10290-npd) https://github.com/bitcoin/bitcoin/pull/10305
< BlueMatt>
cfields: lol, so I've now got a long branch with a bunch of scripted diffs that make CBlockIndexes outside of validation (and mostly outside of CChainState) all const :p
< BlueMatt>
guess that stuff /is/ useful :p
< SopaXorzTaker>
(on-topic to core dev)
< cfields>
:)
< BlueMatt>
also, yay, const access to validation outside of validation!
< sipa>
SopaXorzTaker: why do you ask me?
< BlueMatt>
crazy, yo
< sipa>
SopaXorzTaker: ask the person who sent that mail
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10307: [tests] allow zmq test to be run in out-of-tree builds (master...fix_zmq_test_out_of_tree) https://github.com/bitcoin/bitcoin/pull/10307
< BlueMatt>
cfields: re: 10189: instead of TRAVIS_COMMIT_RANGE might it make sense to go back until the nearest merge commit?
< cfields>
BlueMatt: why? I believe TRAVIS_COMMIT_RANGE includes the merge commit it creates
< BlueMatt>
well i meant eg for private repo runs
< BlueMatt>
it'd be nice, but i guess doesn't matter /that/ much
< BlueMatt>
it just feels weird that it would only be tested on prs
< cfields>
BlueMatt: ah, I hadn't even considered non-PRs. Yes.
< cfields>
BlueMatt: can probably diff to branch point
< SopaXorzTaker>
the addresses belong to gmaxwell and jgarzik, and one more
< SopaXorzTaker>
let's extort them, muhahah
< SopaXorzTaker>
(offtoipic end)
< BlueMatt>
cfields: i guess doesnt matter for first version in pr
< BlueMatt>
cfields: hmmm, I cant run the script locally
< cfields>
BlueMatt: Well, actually, it may break for simple pushes (not sure, I have those disabled). I assume TRAVIS_COMMIT_RANGE is empty for those.
< BlueMatt>
I get "bash: !b}: event not found"
< SopaXorzTaker>
ROLL, ROT, SWAP
< cfields>
BlueMatt: got a branch I can look at?
< BlueMatt>
cfields: I'm literally just running the command manually
< SopaXorzTaker>
that's a lifetime of a TX script in a nutshell
< BlueMatt>
SopaXorzTaker: thanks, but lets keep this on-topic :) people often read scrollback and its very rude when there is a bunch of chatter that is off-topic in the scrollback that people have to spend time reading later
< SopaXorzTaker>
+
< cfields>
BlueMatt: hmm, unsure. Does it object to the sed syntax?
< BlueMatt>
cfields: yes, I assume its the last part of the sed line (that is the only place with a !b)
< BlueMatt>
but its bash complaining, not sed
< cfields>
BlueMatt: i'm not sure why it would matter in a script, but it sounds like history expansion's kicking in. Does using ' ' instead fix it?
< BlueMatt>
using ' ' where?
< * BlueMatt>
is not fluent in sed
< cfields>
BlueMatt: sec
< cfields>
yea, i can reproduce when running the sed script by hand. Must be some interactive/non-interactive difference