12018-12-14T00:07:56  *** promag_ has joined #bitcoin-core-dev
  22018-12-14T00:09:11  *** promag has quit IRC
  32018-12-14T00:12:58  *** _cryptodesktop_i has joined #bitcoin-core-dev
  42018-12-14T00:17:50  <harding> lopp: under the default GitHub settings, anyone with commit access can push anything they want, so they could pull a PR into a private branch, modify it, merge it locally, and push it.  Some projects enable GitHub settings that prevent  direct pushes like that to the master branch, but I'm not sure whether Bitcoin Core uses them.  Alternatively, when you open a GitHub PR, a box is checked by default that allows people with commit
  52018-12-14T00:17:50  <harding> access to the target repository to push to the branch, which is another way comitters could modify the code.  What comitter Mallory can't do is change contributor Alice's commits without removing any PGP signature she put on them, so if you trust Alice's key (and if she always signs her commits), you can confirm she provided those commits.
  62018-12-14T00:18:53  *** miknotauro has joined #bitcoin-core-dev
  72018-12-14T00:21:03  <midnightmagic> code review would need to be compromised; and all the people who build it would have to miss it; and then following that the users upgrading would similarly have to miss it. wumpus does some weird things to double-check the merge process including comparing self-made branches with the PR results and so on.
  82018-12-14T00:23:01  <midnightmagic> lopp: anything not attached to an actual process including PR and discussion would be noticed (IMO) fairly rapidly and examined more closely.
  92018-12-14T00:23:55  <lopp> midnightmagic: it's mainly the "maintainer slips in a few lines to a PR" vector I'm trying to better understand
 102018-12-14T00:28:20  <midnightmagic> lopp: If I were a PR submitter, I would notice that. And the commits are tracked well, so even e.g. push -f could be easily forensically examined. Many of us keep full history immune to push -f tip disconnection.. A PR mod would be an obvious slip.
 112018-12-14T00:32:46  <midnightmagic> lopp: external verification of correct merging would likely be welcome though, if you have a script or something that you want to implement. Well. I mean I'd run it anyway.
 122018-12-14T00:35:11  <sipa> midnightmagic: i think a force push to the repo would be easily noticed yes
 132018-12-14T00:35:23  <sipa> i'm not so sure about a PR being modified by the maintained
 142018-12-14T00:36:08  <midnightmagic> Maybe that's just me then. But authorship would be contaminated at that point. I as a PR submitter would have noticed instantly if you guys committed something other than what I PR'd.
 152018-12-14T00:46:01  *** rh0nj has quit IRC
 162018-12-14T00:46:05  <promag_> midnightmagic: how?
 172018-12-14T00:46:29  *** promag_ is now known as promag
 182018-12-14T00:46:50  *** _cryptodesktop_i has quit IRC
 192018-12-14T00:47:08  *** rh0nj has joined #bitcoin-core-dev
 202018-12-14T00:47:28  *** _cryptosignal_me has joined #bitcoin-core-dev
 212018-12-14T00:50:56  <gmaxwell> midnightmagic: I'm fairly confident that almost no submitters would notice a subtly different version.
 222018-12-14T00:51:05  <gmaxwell> A grossly different version, sure.
 232018-12-14T00:51:27  <gmaxwell> Esp since we don't force PRs to be rebased by the submitter before merging them.
 242018-12-14T00:51:37  <midnightmagic> weird.
 252018-12-14T00:51:54  <gmaxwell> (I mean, they usually have to apply cleanly, but thats it)
 262018-12-14T00:52:09  *** spinza has quit IRC
 272018-12-14T00:52:21  <gmaxwell> many reviewers ack the specific merged commit, but that data is just lost in github land.
 282018-12-14T00:52:42  <promag> gmaxwell: never saw that (I think)
 292018-12-14T00:52:42  <gmaxwell> At least if the modified the change inside the merge commit, that would be apparent in the git history.
 302018-12-14T00:53:06  <midnightmagic> thus authorship contamination.
 312018-12-14T00:53:25  <sipa> no, changes in the merge commit wouldn't change the commit that comes from the author
 322018-12-14T00:53:43  <sipa> the commit id would be exactly the expected value
 332018-12-14T00:53:48  <gmaxwell> promag: never saw people ack specific commits? a lotof people do it consistently.  e.g. first merged commit of yours I clicked on https://github.com/bitcoin/bitcoin/pull/14885#issuecomment-445561532
 342018-12-14T00:54:15  <gmaxwell> sipa: right, but it would be apparent in the git history that the merge wasn't faithful, if anyone looked.
 352018-12-14T00:54:23  <gmaxwell> (I'm not saying that anyone looks)
 362018-12-14T00:54:24  <midnightmagic> the commit of the submitter could but the merge commit wouldn't.
 372018-12-14T00:54:32  <promag> gmaxwell: you said "many reviewers ack the specific merged commit"
 382018-12-14T00:54:56  <sipa> midnightmagic: i'm confused what you're referring to
 392018-12-14T00:54:58  <promag> I thought you meant the merge commit
 402018-12-14T00:55:11  <gmaxwell> promag: sorry, I didn't make the clear, no not the merge commit unfortunately that can't really happen logistically. :(
 412018-12-14T00:55:28  <gmaxwell> promag: but the commit that is eventually merged, not the merge commit itself.
 422018-12-14T00:55:30  <sipa> we actually could very reasonable verify that merge commits are faithful and conflictless
 432018-12-14T00:55:36  <sipa> but we don't have infrastructure for that
 442018-12-14T00:55:58  <sipa> it would be kinda pointless without also verifying e.g. that the author commit matches the value that was ACKed by reviewers etc
 452018-12-14T00:56:01  <gmaxwell> Someone could write automation that checks that merge commits are faithful, but I would WAG that not 100% of them are.
 462018-12-14T00:56:04  <midnightmagic> sipa: those commitids which are added to git history as a result of the merge would include a change by the maintainer, assuming we have a commit in the history which the PR submitter actually intended to be committed. Changes would be visible via git log and other historical examination
 472018-12-14T00:56:24  <gmaxwell> sipa: well the merge commit could copy existant acks from the github into the commit message.
 482018-12-14T00:56:47  <gmaxwell> The point I was trying to make and midnightmagic is making is that at least if it's the merge commit that screws it up there is a clear record.
 492018-12-14T00:56:51  <sipa> midnightmagic: yeah, it would be - i'm just doubtful that there is any infrasturcture or reviewer policy that would notice that
 502018-12-14T00:56:52  <promag> midnightmagic: do you periodically check history and merge commits?
 512018-12-14T00:57:00  <sipa> midnightmagic: because git doesn't tell you unless you go out of your way
 522018-12-14T00:57:10  <gmaxwell> vs editing the commit that gets merged itself, which would actually not leave a good record.
 532018-12-14T00:57:35  <promag> the same regarding merge os backports
 542018-12-14T00:57:38  <midnightmagic> sipa: I accept that. I'm just saying I would definitely notice contamination of any PR I submitted. And I think it's weird that other submitters don't verify. :(
 552018-12-14T00:57:40  <promag> s/os/of
 562018-12-14T00:57:51  <gmaxwell> midnightmagic: how would you even go check?
 572018-12-14T00:58:10  <gmaxwell> I guess do the merge yourself and compare the resulting trees?
 582018-12-14T00:58:27  <sipa> git show on the merge commit will show you the conflicts, i think
 592018-12-14T00:58:59  <sipa> (but it does depend on your local diff/conflict resolving strategy, which is a config setting)
 602018-12-14T00:59:10  <midnightmagic> git log, diffs, looking at the merge points and reverifying actual code committed. I don't really trust git either, after watching superior commercial systems screw up their merging in corner cases that wrecked large corp IP.
 612018-12-14T00:59:25  <gmaxwell> I'm no longer a commiter on bitcoin, I'd be interested in knowing how often commiters are manually resolving conflicts on master. I believe the answer is rarely but not never.
 622018-12-14T00:59:40  <sipa> gmaxwell: i think the answer is almost never
 632018-12-14T00:59:52  <gmaxwell> I think I recall doing so... but only like ... once.
 642018-12-14T00:59:58  <promag> gmaxwell: never noticed one in almost 2 years
 652018-12-14T01:00:13  <sipa> promag: how would you notice?
 662018-12-14T01:00:19  *** spinza has joined #bitcoin-core-dev
 672018-12-14T01:00:43  <gmaxwell> because our history is not linear there is virtually always conflict resolution, but it's automated.
 682018-12-14T01:00:44  <promag> right, I mean, it wasn't discuessed here at least XD
 692018-12-14T01:01:16  <gmaxwell> promag: yea, it wouldn't get discussed. like as a commiter I would have only done a manual resoution if it was utterly trivial and obvious, and otherwise I would have nagged someone to rebase.
 702018-12-14T01:01:23  <sipa> i personally would always ask for rebasing instead of merging something with conflicts, but i'm not using my merge power frequently
 712018-12-14T01:01:35  <sipa> and if that doesn't happen, submit a PR myself with the rebase
 722018-12-14T01:01:42  <gmaxwell> sipa: even if the PR author had been gone for two months ?
 732018-12-14T01:01:46  <gmaxwell> okay fair enough.
 742018-12-14T01:02:10  <sipa> i think in backport branches maintainer changes may be more common, but i shouldn't speak for others
 752018-12-14T01:02:19  * midnightmagic discovers taking something for granted.
 762018-12-14T01:02:22  <gmaxwell> Actually I think I've seen you do exactly that, open a rebase basically right before something gets merged.
 772018-12-14T01:02:26  *** _cryptosignal_me has quit IRC
 782018-12-14T01:02:41  <gmaxwell> sipa: yea, backports are a mess of manual resolution, thats why I was specific about master.
 792018-12-14T01:03:48  <gmaxwell> In any case, I expect we could pretty easily have a 'no manual resolution in merges' standard, but its kinda pointless without validation.
 802018-12-14T01:04:07  <gmaxwell> and I wouldn't be surprised if validation might be complicated by git version differences. :(
 812018-12-14T01:04:49  <promag> I think backports are more attractive to tamper, are on the verge of release
 822018-12-14T01:05:16  <gmaxwell> maybe. but they inherently get a lot less attention in a lot of regards.
 832018-12-14T01:06:47  <gmaxwell> Tampering in general is not the most attractive attack vector because its conspicuous. I think in general when we think about process improvements, it's best to think in terms of beneficial changes that make tampering harder as a side effect, rather than targeted changes against tampering.
 842018-12-14T01:23:22  *** bitcoin-git has joined #bitcoin-core-dev
 852018-12-14T01:23:23  <bitcoin-git> [bitcoin] MeshCollider pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a5aea9654f36...7a30e0f6c544
 862018-12-14T01:23:23  <bitcoin-git> bitcoin/master 0e75f44 Pieter Wuille: Replace CAffectedKeysVisitor with descriptor based logic
 872018-12-14T01:23:24  <bitcoin-git> bitcoin/master 7a30e0f MeshCollider: Merge #14821: Replace CAffectedKeysVisitor with descriptor based logic...
 882018-12-14T01:23:24  *** bitcoin-git has left #bitcoin-core-dev
 892018-12-14T01:24:02  *** bitcoin-git has joined #bitcoin-core-dev
 902018-12-14T01:24:02  <bitcoin-git> [bitcoin] MeshCollider closed pull request #14821: Replace CAffectedKeysVisitor with descriptor based logic (master...201810_die_caffectedkeysvisitor_die) https://github.com/bitcoin/bitcoin/pull/14821
 912018-12-14T01:24:02  *** bitcoin-git has left #bitcoin-core-dev
 922018-12-14T01:25:53  *** luke-jr has quit IRC
 932018-12-14T01:26:10  <midnightmagic> lopp: check the merge commits. unclean commits result in diffs of the merging commit and the topmost merge point; clean merges result in a pure list of commits between the branchpoint of the PR branch and the topmost commit. Alternatively, for a forced merge commit (like what github does) you can diff the base of the merge and the commitid of the merging commit and the results should be
 942018-12-14T01:26:17  <midnightmagic> identical. example;
 952018-12-14T01:26:43  <midnightmagic> er..  example:  git diff 4b4e9486af..86eddd466e, vs. git diff 4b4e9486af..4ad560dba9b3362b6639e1a1c7898ea9ca946af5
 962018-12-14T01:27:05  <gmaxwell> midnightmagic: there are no clean commits.
 972018-12-14T01:27:09  <gmaxwell> or almost none.
 982018-12-14T01:27:10  *** Murch has quit IRC
 992018-12-14T01:27:19  <midnightmagic> good then. they're harder to detect.
1002018-12-14T01:27:41  <gmaxwell> the only time the merge does nothing is if the history was linear... which it usually isn't except for quick fixes.
1012018-12-14T01:28:13  <gmaxwell> like #14953 probably was merged clean, but few things are because there is just too much activity.
1022018-12-14T01:28:15  <midnightmagic> corner case.  So github doesn't force a merge commit?
1032018-12-14T01:28:16  <gribble> https://github.com/bitcoin/bitcoin/issues/14953 | test: Make g_insecure_rand_ctx thread_local by MarcoFalke · Pull Request #14953 · bitcoin/bitcoin · GitHub
1042018-12-14T01:28:31  <gmaxwell> midnightmagic: there is always a merge commit, nothing goes in without a merge commit.
1052018-12-14T01:29:19  <midnightmagic> You mean in github?
1062018-12-14T01:29:43  <gmaxwell> In the bitcoin project. We never commit directly to master. (I believe that no adays that is an absolute never)
1072018-12-14T01:29:52  <sipa> gmaxwell: indeed
1082018-12-14T01:29:58  <midnightmagic> Ah -- yes, good then.
1092018-12-14T01:29:59  <gmaxwell> For master there is always a PR and a merge.
1102018-12-14T01:29:59  <sipa> verify-commits would fail if you didn't
1112018-12-14T01:30:12  <sipa> so that's not just policy, it's actually enforced by CI
1122018-12-14T01:31:12  <promag> is this used contrib/devtools/github-merge.py ?
1132018-12-14T01:31:29  <meshcollider> I'm not sure thats true, I think wumpus sometimes pushes release note changes directly without a PR?
1142018-12-14T01:31:48  <gmaxwell> meshcollider: not on master, AFAIK
1152018-12-14T01:32:08  <sipa> promag: yes, all merges are done through that script
1162018-12-14T01:32:20  <meshcollider> https://github.com/bitcoin/bitcoin/commit/825f779dc715f0f006ce0f196dc834355d2e0a5a
1172018-12-14T01:32:30  <meshcollider> for example ^
1182018-12-14T01:33:03  <sipa> midnightmagic: still a merge commit above it; 024816d6cfc719c7109cf5f1aa02d41056df848d
1192018-12-14T01:33:11  <sipa> no?
1202018-12-14T01:33:18  <sipa> oh no
1212018-12-14T01:33:27  <aj> contrib/verify-commits.py has code to check merge commits are clean... there's an explicit list of non-clean merge commits as well (contrib/verify-commits/allow-unclean-merge-commits)
1222018-12-14T01:33:29  <sipa> you're right; hmm
1232018-12-14T01:33:39  <meshcollider> historical release notes are the only time I've seen a direct push to master IIRC
1242018-12-14T01:33:51  <sipa> ah, yes, there can be direct commits in masters, but they need to be signed by a maintainer
1252018-12-14T01:33:58  <sipa> and merge commits, which also need to be signed
1262018-12-14T01:34:14  <gmaxwell> aside, github output on the commit is weird, look what PR it attributes it to
1272018-12-14T01:34:18  <sipa> and merge commits cannot merge more than 2 branches
1282018-12-14T01:34:30  <gmaxwell> no octopus merges? aww
1292018-12-14T01:34:47  <midnightmagic> :-o
1302018-12-14T01:35:06  <meshcollider> yep thats enforced by verify-commits
1312018-12-14T01:35:55  <gmaxwell> I wonder if we shouldn't just have the verify also disallow direct commits on master. It doesn't much matter one way or another, since by norm they're not used (except for trivial things).
1322018-12-14T01:36:10  <gmaxwell> also not terribly important one way or another, I guess.
1332018-12-14T01:36:29  <gmaxwell> but the fact that sipa and I thought they weren't allowed maybe suggests that they shouldn't be.
1342018-12-14T01:36:34  <midnightmagic> "you man. don't eat those."
1352018-12-14T01:37:02  <meshcollider> its exactly the same as opening a PR and then merging it straight away, I don't think there is any security difference
1362018-12-14T01:37:17  <meshcollider> both will be alerted on IRC by the commit bot for example
1372018-12-14T01:39:34  <gmaxwell> meshcollider: indeed, but in terms of process flow, it's one fewer things to watch out for.
1382018-12-14T01:39:42  *** luke-jr has joined #bitcoin-core-dev
1392018-12-14T01:39:57  <gmaxwell> ::shrugs:: I don't have a strong opinion, but given that we almost never do it, it might be better to never do it.
1402018-12-14T01:40:51  <gmaxwell> If nothing else, it helps draw a stronger line between our practices and common but bad practices (lots of cryptocurrency projects commit everything directly to their repo with no review or oppturnity for review at all)
1412018-12-14T01:41:01  <gmaxwell> obviously its up to the people who do it. :)
1422018-12-14T01:42:19  <sipa> yeah, it's easy to discuss policies when you're not the person affected by them :)
1432018-12-14T01:43:47  <gmaxwell> Well, I am affected by them, at least in theory. I give at least a glance over look at _every_ commit in a release.  If I were doing that by going through the list on github, then I'd miss some.
1442018-12-14T01:43:58  <gmaxwell> In actuality, I do it via git, so I wouldn't ... but I could have been! :P
1452018-12-14T01:44:10  <midnightmagic> ha
1462018-12-14T01:44:30  <gmaxwell> (looking at changes on github is kind of a lost cause because of the automatic file hiding, among other things)
1472018-12-14T01:44:55  <meshcollider> gmaxwell: do you mean the list of PRs merged, or the list of commits itself
1482018-12-14T01:45:03  <meshcollider> because of course direct commits to master will be in the latter
1492018-12-14T01:45:28  *** shesek has joined #bitcoin-core-dev
1502018-12-14T01:45:35  *** shesek has joined #bitcoin-core-dev
1512018-12-14T01:45:44  <gmaxwell> meshcollider: If I had moved to doing the review via github, I would have been doing it on PRs.
1522018-12-14T01:45:58  <meshcollider> fair enough
1532018-12-14T01:45:58  <gmaxwell> also with the mistaken impression that there was a Pr for everything.
1542018-12-14T01:46:04  <meshcollider> because you can still look at https://github.com/bitcoin/bitcoin/commits/master
1552018-12-14T01:46:15  <gmaxwell> Indeed.
1562018-12-14T01:46:17  <aj> if nothing else, doing everything via a PR provides an easy place to capture comments on commits
1572018-12-14T01:46:32  <gmaxwell> aj: right thats why I would use PRs if I were doing it via the web.
1582018-12-14T01:46:38  <gmaxwell> In reality, I prefer to not see the comments.
1592018-12-14T01:46:56  <gmaxwell> because they can be misleading.
1602018-12-14T01:47:25  <gmaxwell> (A lesson I learned on this project a couple years back...)
1612018-12-14T01:47:30  <aj> gmaxwell: comments are helpful if you're looking at code that was merged a while ago, and want to understand some of the choices. in theory, anyway...
1622018-12-14T01:47:53  <gmaxwell> aj: what I like to do is look just at git, and then if I can't understand it, go look at the PR.
1632018-12-14T01:48:00  <aj> gmaxwell: yeah, exactly
1642018-12-14T01:48:14  <gmaxwell> less loading of expectations.
1652018-12-14T01:48:18  <aj> gmaxwell: (then find i can't understand it after reading the PR, then ask on irc :)
1662018-12-14T01:48:47  <gmaxwell> I couple times I've caught bugs by reading the change instead of the PR that I'm confident that I wouldn't have caught if I read the PR first.
1672018-12-14T01:49:39  <gmaxwell> (though for unmerged things I still end up always reading the PR first, ... lazy oh well)
1682018-12-14T01:53:49  <luke-jr> (#11082 is rebased btw)
1692018-12-14T01:53:53  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
1702018-12-14T01:54:03  <luke-jr> (if someone wants to add it to the high-prio list..)
1712018-12-14T01:54:47  <meshcollider> luke-jr: done
1722018-12-14T01:58:47  *** Tralfaz has quit IRC
1732018-12-14T02:02:53  *** Murch has joined #bitcoin-core-dev
1742018-12-14T02:04:30  *** Murch has quit IRC
1752018-12-14T02:08:49  <lopp> sipa: so is it accurate to say that maintainers can't alter commits that they merge because it would cause the verify-commits script to fail?
1762018-12-14T02:10:48  <promag> lopp: what if they change verify commits or related?
1772018-12-14T02:11:06  <gmaxwell> lopp: no that isn't the case at all.
1782018-12-14T02:11:30  <gmaxwell> lopp: they can change the commits they merge, but it won't agree with the commit ids that people ack on PRs.  Nothing automated checks this.
1792018-12-14T02:11:47  <gmaxwell> lopp: parties other than the maintainers (e.g. github) can't do that though, because merge commits are signed and verify commits checks the signatures.
1802018-12-14T02:12:42  <gmaxwell> promag: instructions on verify commits has you use it in a way where you fetch changes and then verify them before merging into your local tree.
1812018-12-14T02:12:46  *** Giszmo has quit IRC
1822018-12-14T02:12:51  <lopp> gotcha; I know there is a trust issue with the verify-commits script itself though I'm not familiar with how the CI runs it... hopefully it doesn't run whatever version is at HEAD
1832018-12-14T02:13:50  <gmaxwell> see the readme on verify commits "Using verify-commits.py safely"
1842018-12-14T02:17:29  <promag> gmaxwell: still don't understand.. a merge commit could remove/skip the check in travis right?
1852018-12-14T02:18:40  <gmaxwell> I have no idea what travis does. verify-commits is run by users (and should be run by you too), and if run like the readme says, no commit can defeat it.
1862018-12-14T02:19:25  <sipa> promag: if you mean that someone can modify the verify-commits script to be neutered... sure, but i'm sure that would be noticed by review
1872018-12-14T02:19:52  <promag> gmaxwell: thanks, will do!
1882018-12-14T02:20:22  <promag> meh, trust in maintainers \o/
1892018-12-14T02:21:56  *** ghost43 has quit IRC
1902018-12-14T02:22:17  *** ghost43 has joined #bitcoin-core-dev
1912018-12-14T02:24:37  <sipa> promag: s/maintainers/reviewers/
1922018-12-14T02:28:14  <luke-jr> lopp: don't trust CI
1932018-12-14T02:30:42  *** Giszmo has joined #bitcoin-core-dev
1942018-12-14T02:34:50  *** otoburb has quit IRC
1952018-12-14T02:45:52  *** fanquake has joined #bitcoin-core-dev
1962018-12-14T02:58:52  <meshcollider> sipa: in #14565 is there a reason you moved pubkey_map and privkey_map outside of import_data
1972018-12-14T02:58:56  <gribble> https://github.com/bitcoin/bitcoin/issues/14565 | Overhaul importmulti logic by sipa · Pull Request #14565 · bitcoin/bitcoin · GitHub
1982018-12-14T02:59:28  <sipa> meshcollider: yes, ryanofsky asked for it
1992018-12-14T02:59:41  <sipa> :)
2002018-12-14T02:59:50  <meshcollider> oh
2012018-12-14T03:00:03  <sipa> after noticing that the recursive function doesn't use them, it felt cleaner to have it out of it
2022018-12-14T03:00:04  <meshcollider> its making my rebase more annoying :)
2032018-12-14T03:00:10  <meshcollider> all good
2042018-12-14T03:03:13  *** bitcoin-git has joined #bitcoin-core-dev
2052018-12-14T03:03:13  <bitcoin-git> [bitcoin] sipa opened pull request #14955: Switch all RNG code to the built-in PRNG (master...201812_generic_rand) https://github.com/bitcoin/bitcoin/pull/14955
2062018-12-14T03:03:13  *** bitcoin-git has left #bitcoin-core-dev
2072018-12-14T03:05:33  *** jhfrontz has joined #bitcoin-core-dev
2082018-12-14T03:09:08  <gmaxwell> sipa: re 14955 on the strenghtening in the scheduler, do you hold exclusive access the whole time, or do you get randomness, strenghten and then mix back?
2092018-12-14T03:10:17  <sipa> gmaxwell: nope!
2102018-12-14T03:10:20  <sipa> only at the end
2112018-12-14T03:10:59  <sipa> the process is [gather entropy externally] [get entropy from local RNG] [strengthen] [feed back into local RNG]
2122018-12-14T03:11:52  <gmaxwell> but it isn't holding any locks during strengthen? right?
2132018-12-14T03:12:42  <gmaxwell> lol maybe you should use sha256d64 as the strengthening function. :P
2142018-12-14T03:13:09  <gmaxwell> lot more strenghtening per unit time to do 4-parallel sha256d64. :)
2152018-12-14T03:13:24  <sipa> gmaxwell: no, just when reading the local RNG, and when mixing back in
2162018-12-14T03:13:44  <sipa> gmaxwell: perhaps!
2172018-12-14T03:14:50  *** AaronvanW has quit IRC
2182018-12-14T03:16:50  <gmaxwell> sipa: is there any way to arrange things so that no strong randomness will get gotten until one strengthening pass has happened?
2192018-12-14T03:17:28  <sipa> gmaxwell: yes, already done
2202018-12-14T03:17:40  <gmaxwell> sweet.
2212018-12-14T03:17:46  <sipa> the first invocation will run with 'startup' seed level, which includes everything else
2222018-12-14T03:18:40  <gmaxwell> we should like serialize out a random number on stop, and read it back in on start. (is there an existing dat file we could abuse for this, like peers or mempool :P ) so as to conserve our strenghtening efforts.
2232018-12-14T03:46:07  *** rh0nj has quit IRC
2242018-12-14T03:48:27  *** miknotauro has quit IRC
2252018-12-14T03:48:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2262018-12-14T03:50:42  *** dviola has quit IRC
2272018-12-14T03:54:08  *** rh0nj has joined #bitcoin-core-dev
2282018-12-14T04:00:36  *** profmac has quit IRC
2292018-12-14T04:13:23  *** miknotauro has joined #bitcoin-core-dev
2302018-12-14T04:13:25  *** profmac has joined #bitcoin-core-dev
2312018-12-14T04:32:34  *** Giszmo has quit IRC
2322018-12-14T04:33:55  *** Chris_Stewart_5 has quit IRC
2332018-12-14T04:59:20  <gmaxwell> Anyone heard any feedback on 0.17.1rc1?
2342018-12-14T04:59:52  <gmaxwell> BlueMatt: ^ have you tested it to make sure it's all happy on ubuntu?
2352018-12-14T05:00:01  *** SirPNut19 has joined #bitcoin-core-dev
2362018-12-14T05:00:04  <gmaxwell> warren: ^ have you tested it to make sure its all happy on the latest fedora?
2372018-12-14T05:00:11  *** SirPNut19 has quit IRC
2382018-12-14T05:06:25  *** grubles has quit IRC
2392018-12-14T05:12:34  *** bitcoin-git has joined #bitcoin-core-dev
2402018-12-14T05:12:34  <bitcoin-git> [bitcoin] bpay opened pull request #14956: [qt] Ensure tx send error highlight is visible (master...show-highlighted-field) https://github.com/bitcoin/bitcoin/pull/14956
2412018-12-14T05:12:34  *** bitcoin-git has left #bitcoin-core-dev
2422018-12-14T05:20:07  *** grubles has joined #bitcoin-core-dev
2432018-12-14T05:29:00  <fanquake> gmaxwell trying to collect test feedback in #14902
2442018-12-14T05:29:02  <gribble> https://github.com/bitcoin/bitcoin/issues/14902 | v0.17.1 testing · Issue #14902 · bitcoin/bitcoin · GitHub
2452018-12-14T06:27:32  <kallewoof> Now that GetType() is gone in the source code, I'm not sure how to detect whether a serialization op is a hash operation or not. I need this for the block header in signet. Is there a new way to determine operation type somehow?
2462018-12-14T06:34:49  <sipa> kallewoof: i don't see what you need it for
2472018-12-14T06:35:19  <sipa> the hash should generally be the same as the network serialization
2482018-12-14T06:35:42  <kallewoof> sipa: I include the signature when (de)serializing, but not when getting the hash. The signature is a payload of the block header, by necessity
2492018-12-14T06:36:31  <kallewoof> I may be able to exclude the signature part when doing the actual sig check though. *checks*
2502018-12-14T06:36:41  <sipa> kallewoof: that seems ugly
2512018-12-14T06:36:53  <sipa> you can use a flag like the ones used for witness serialization
2522018-12-14T06:37:01  <sipa> actually, you can use exactly the same flag
2532018-12-14T06:37:09  <kallewoof> Oh!
2542018-12-14T06:51:02  *** Zenton has quit IRC
2552018-12-14T06:54:05  *** aelxsam has joined #bitcoin-core-dev
2562018-12-14T07:19:42  *** Murch has joined #bitcoin-core-dev
2572018-12-14T07:22:18  *** bitcoin-git has joined #bitcoin-core-dev
2582018-12-14T07:22:18  <bitcoin-git> [bitcoin] Empact opened pull request #14957: wallet: Initialize stop_block to nullptr in CWallet::ScanForWalletTransactions (master...stop-block-null) https://github.com/bitcoin/bitcoin/pull/14957
2592018-12-14T07:22:18  *** bitcoin-git has left #bitcoin-core-dev
2602018-12-14T07:55:01  *** rh0nj has quit IRC
2612018-12-14T07:56:07  *** rh0nj has joined #bitcoin-core-dev
2622018-12-14T08:00:48  *** chenpo has joined #bitcoin-core-dev
2632018-12-14T08:09:08  <fanquake> Is anyone able to successfully compile on macOS with --with-sanitizers=thread ?
2642018-12-14T08:11:52  <fanquake> Seeing issues when compiling libbitcoinconsensus.la, output here: https://gist.github.com/fanquake/79a9a12286d3cd2e4cb961c32a32dee3
2652018-12-14T08:13:40  <fanquake> Also sipa, the new RNG changes build on macOS, but are failing on the thread sanitizer travis job: https://travis-ci.org/bitcoin/bitcoin/jobs/467863069
2662018-12-14T08:13:45  *** TheCharlatan has quit IRC
2672018-12-14T08:14:40  *** TheCharlatan has joined #bitcoin-core-dev
2682018-12-14T08:19:06  *** EagleTM has joined #bitcoin-core-dev
2692018-12-14T08:20:00  *** jungly has joined #bitcoin-core-dev
2702018-12-14T08:22:22  *** TheCharlatan has quit IRC
2712018-12-14T08:22:51  *** TheCharlatan has joined #bitcoin-core-dev
2722018-12-14T08:23:56  <gwillen> fanquake: I ran into something like this, it's hard to recall the details but I think they may be in scrollback here
2732018-12-14T08:24:44  <gwillen> IIRC, the resolution in my case is that OS X libtool is somewhat elderly and was stripping linker flags it didn't recognize, inappropraitely
2742018-12-14T08:27:05  *** bitcoinjunior has quit IRC
2752018-12-14T08:27:08  *** justanotheruser has quit IRC
2762018-12-14T08:27:51  <gwillen> you can force libtool to pass through a flag by changing "-fblahblah" to "-XCClinker -fblahblah", or something to that effect
2772018-12-14T08:27:58  <gwillen> (see https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html)
2782018-12-14T08:28:14  <gwillen> I think you have to do that with -fsanitizer, assuming you're hitting the same issue I was
2792018-12-14T08:28:47  <gwillen> which I faintly suspect you are because it's awfully similar
2802018-12-14T08:29:29  <wumpus> so the reason that historical release notes are committed directly is that it is part of a long list of steps around a release, and other steps rely on it, for example creating a release on github has a link to the historical release notes in git which then need to have been committed; it's also simply a copy operation
2812018-12-14T08:29:44  <fanquake> gwillen thanks, I'll check it out this arvo
2822018-12-14T08:30:06  <gwillen> np, good lfuck
2832018-12-14T08:30:11  <gwillen> er... luck*
2842018-12-14T08:30:18  *** ppisati has quit IRC
2852018-12-14T08:30:24  <wumpus> doesn't seem very useful to create a PR then as there's nothing to review, it's simply more work
2862018-12-14T08:34:29  *** JackH has quit IRC
2872018-12-14T08:37:46  *** bitcoin-git has joined #bitcoin-core-dev
2882018-12-14T08:37:47  <bitcoin-git> [bitcoin] kallewoof closed pull request #13430: use IsBlockPruned() where appropriate (master...use-isblockpruned) https://github.com/bitcoin/bitcoin/pull/13430
2892018-12-14T08:37:47  *** bitcoin-git has left #bitcoin-core-dev
2902018-12-14T08:38:19  *** ppisati has joined #bitcoin-core-dev
2912018-12-14T08:38:44  *** EagleTM has quit IRC
2922018-12-14T08:41:49  *** miknotauro has quit IRC
2932018-12-14T08:42:10  *** bitcoin-git has joined #bitcoin-core-dev
2942018-12-14T08:42:11  <bitcoin-git> [bitcoin] kallewoof closed pull request #14774: interface/wallet: get rid of missing initializer warnings (master...suppwarn-empty-constructor) https://github.com/bitcoin/bitcoin/pull/14774
2952018-12-14T08:42:11  *** bitcoin-git has left #bitcoin-core-dev
2962018-12-14T08:42:43  *** justanotheruser has joined #bitcoin-core-dev
2972018-12-14T08:44:16  *** rex4539 has quit IRC
2982018-12-14T08:50:39  *** belcher has quit IRC
2992018-12-14T08:51:53  *** Murch has quit IRC
3002018-12-14T08:53:27  *** rockhouse has joined #bitcoin-core-dev
3012018-12-14T08:53:28  *** victorSN has joined #bitcoin-core-dev
3022018-12-14T09:00:41  *** chenpo has quit IRC
3032018-12-14T09:03:40  *** belcher has joined #bitcoin-core-dev
3042018-12-14T09:07:45  *** bitcoin-git has joined #bitcoin-core-dev
3052018-12-14T09:07:45  <bitcoin-git> [bitcoin] laanwj reopened pull request #14919: test: Prevent "Duplicate-wallet filename specified" (master...confirm_unloadwallet_done) https://github.com/bitcoin/bitcoin/pull/14919
3062018-12-14T09:07:45  *** bitcoin-git has left #bitcoin-core-dev
3072018-12-14T09:09:07  *** promag has quit IRC
3082018-12-14T09:10:56  *** booyah has quit IRC
3092018-12-14T09:11:40  *** belcher has quit IRC
3102018-12-14T09:19:39  *** JackH has joined #bitcoin-core-dev
3112018-12-14T09:30:40  *** spinza has quit IRC
3122018-12-14T09:33:34  *** rex4539 has joined #bitcoin-core-dev
3132018-12-14T09:34:26  *** rex4539 has quit IRC
3142018-12-14T09:34:49  *** aelxsam has quit IRC
3152018-12-14T09:35:32  *** Zenton has joined #bitcoin-core-dev
3162018-12-14T09:35:37  *** rex4539 has joined #bitcoin-core-dev
3172018-12-14T09:37:47  *** booyah has joined #bitcoin-core-dev
3182018-12-14T09:41:08  *** timothy has joined #bitcoin-core-dev
3192018-12-14T09:47:01  *** miknotauro has joined #bitcoin-core-dev
3202018-12-14T09:58:09  <fanquake> wumpus I've used GH's new (beta) issue "pinning" feature to pin #14902 & #14438 to the top of the issues page. Let me know if you object/can think of a third issue to add.
3212018-12-14T09:58:11  <gribble> https://github.com/bitcoin/bitcoin/issues/14902 | v0.17.1 testing · Issue #14902 · bitcoin/bitcoin · GitHub
3222018-12-14T09:58:12  <gribble> https://github.com/bitcoin/bitcoin/issues/14438 | Release schedule for 0.18.0 · Issue #14438 · bitcoin/bitcoin · GitHub
3232018-12-14T09:58:43  *** spinza has joined #bitcoin-core-dev
3242018-12-14T09:58:59  <fanquake> I feel having the current testing issue, and release schedule pinned at the top can makes sense
3252018-12-14T09:59:49  <fanquake> If anything maybe it'll draw more attention to testing rc1
3262018-12-14T10:05:05  *** ChA1NsAw has joined #bitcoin-core-dev
3272018-12-14T10:12:12  *** rex4539 has quit IRC
3282018-12-14T10:13:19  *** belcher has joined #bitcoin-core-dev
3292018-12-14T10:15:27  *** spinza has quit IRC
3302018-12-14T10:21:00  *** ChA1NsAw has quit IRC
3312018-12-14T10:23:35  *** spinza has joined #bitcoin-core-dev
3322018-12-14T10:24:24  <wumpus> fanquake: makes sense, I think this is enough
3332018-12-14T10:24:55  *** promag has joined #bitcoin-core-dev
3342018-12-14T10:36:54  *** CodeBlue1776 has quit IRC
3352018-12-14T10:37:25  *** CodeBlue1776 has joined #bitcoin-core-dev
3362018-12-14T10:44:21  *** wxss has joined #bitcoin-core-dev
3372018-12-14T10:45:03  *** wxss has quit IRC
3382018-12-14T10:47:12  <wumpus> so effectively (#14948), the unit tests can only run now with a filesystem locale that supports fancy unicode characters, which is not the default on BSD; this wa already the case for the Python tests
3392018-12-14T10:47:13  <gribble> https://github.com/bitcoin/bitcoin/issues/14948 | Error when running gmake check on NetBSD 8.0 · Issue #14948 · bitcoin/bitcoin · GitHub
3402018-12-14T10:49:34  *** laurentmt has joined #bitcoin-core-dev
3412018-12-14T10:49:49  <wumpus> it's somewhat annoying but also understandable, I don't think anyone *intends* to run a pure ASCII locale and only support ASCII filenames on the other hand the assumption that the locale always matches UTF-8 might be incorrect
3422018-12-14T10:52:06  <wumpus> (or is always able to represent all unicode characters)
3432018-12-14T10:55:51  *** laurentmt has quit IRC
3442018-12-14T10:59:11  *** laurentmt has joined #bitcoin-core-dev
3452018-12-14T11:04:13  <fanquake> wumpus got to have wallet names/dirs full of emojis
3462018-12-14T11:08:10  <wumpus> U+1F45B.dat
3472018-12-14T11:08:44  <fanquake> heh
3482018-12-14T11:08:46  <wumpus> that makes me wonder, though, how does git handle filenames with emojis, would it refuse to check out the tree on those platforms?
3492018-12-14T11:11:07  <wumpus> or what about programs such as firefox? is "ignore the filesystem locale and assume it's always UTF-8" valid behavior for modern software?
3502018-12-14T11:14:09  <fanquake> wumpus we shall know shortly https://github.com/fanquake/fictional-giggle
3512018-12-14T11:16:04  <promag> nice wallet fanquake
3522018-12-14T11:17:38  *** bitcoin-git has joined #bitcoin-core-dev
3532018-12-14T11:17:39  <bitcoin-git> [bitcoin] AkioNak closed pull request #14919: test: Prevent "Duplicate-wallet filename specified" (master...confirm_unloadwallet_done) https://github.com/bitcoin/bitcoin/pull/14919
3542018-12-14T11:17:39  *** bitcoin-git has left #bitcoin-core-dev
3552018-12-14T11:17:56  <fanquake> promag thanks
3562018-12-14T11:18:05  <fanquake> wumpus this is the result of a clone https://gist.github.com/fanquake/4bcd4c3b09958d1a709f97084fbda329
3572018-12-14T11:18:24  *** wxss has joined #bitcoin-core-dev
3582018-12-14T11:18:43  <promag> not so pretty now
3592018-12-14T11:19:56  *** wxss has quit IRC
3602018-12-14T11:36:38  <wumpus> it changes the unknown unicode character to literal '????' oh my
3612018-12-14T11:38:43  <wumpus> at least that's different from boost's handling which is to fail the conversion, not sure what's better...
3622018-12-14T11:48:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3632018-12-14T11:51:18  <promag> disallow that madness?
3642018-12-14T11:52:20  <wumpus> like what? reject non-utf locales at startup?
3652018-12-14T11:53:14  <wumpus> I mean, I guess ASCII file system locale simply works as long as you don't try to use non-ASCII characters in filenames
3662018-12-14T11:53:31  <wumpus> which might be fine for English/US people
3672018-12-14T11:54:33  <promag> I don't know, but it's a headache having wallet names from the filename
3682018-12-14T11:55:15  <wumpus> that's why I wondered how other software handles this, but replacing iwht ???? doesn't seem that useful either...
3692018-12-14T11:57:01  *** rh0nj has quit IRC
3702018-12-14T11:58:04  <promag> yeah, comes from "what the heck???? are you mad?"
3712018-12-14T11:58:07  *** rh0nj has joined #bitcoin-core-dev
3722018-12-14T12:01:42  *** bitcoin-git has joined #bitcoin-core-dev
3732018-12-14T12:01:42  <bitcoin-git> [bitcoin] promag opened pull request #14958: qa: Remove race between conneting and shutdown on separate connections (master...2018-12-improve-shutdown-test) https://github.com/bitcoin/bitcoin/pull/14958
3742018-12-14T12:01:42  *** bitcoin-git has left #bitcoin-core-dev
3752018-12-14T12:05:26  <wumpus> seems the options are https://github.com/bitcoin/bitcoin/issues/14948#issuecomment-447305576
3762018-12-14T12:14:51  *** laurentmt has quit IRC
3772018-12-14T12:22:07  *** AaronvanW has joined #bitcoin-core-dev
3782018-12-14T12:46:38  *** Giszmo has joined #bitcoin-core-dev
3792018-12-14T12:50:59  *** Chris_Stewart_5 has quit IRC
3802018-12-14T13:04:26  *** promag has quit IRC
3812018-12-14T13:10:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3822018-12-14T13:20:05  *** Chris_Stewart_5 has quit IRC
3832018-12-14T13:20:09  *** ChA1NsAw has joined #bitcoin-core-dev
3842018-12-14T13:52:05  *** CodeBlue1776 has quit IRC
3852018-12-14T13:52:38  *** CodeBlue1776 has joined #bitcoin-core-dev
3862018-12-14T14:02:24  *** riemann_ has joined #bitcoin-core-dev
3872018-12-14T14:05:38  *** riemann has quit IRC
3882018-12-14T14:23:53  *** bralyclow2 has joined #bitcoin-core-dev
3892018-12-14T14:23:53  *** bralyclow2 has quit IRC
3902018-12-14T14:24:47  *** Giszmo has quit IRC
3912018-12-14T14:27:28  *** Guyver2 has joined #bitcoin-core-dev
3922018-12-14T14:29:34  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3932018-12-14T14:57:57  *** TheRec has quit IRC
3942018-12-14T14:58:23  *** justanotheruser has quit IRC
3952018-12-14T15:00:02  *** fanquake has quit IRC
3962018-12-14T15:01:24  *** Tralfaz has joined #bitcoin-core-dev
3972018-12-14T15:06:37  *** TheRec has joined #bitcoin-core-dev
3982018-12-14T15:06:38  *** TheRec has joined #bitcoin-core-dev
3992018-12-14T15:07:48  *** promag has joined #bitcoin-core-dev
4002018-12-14T15:13:07  *** TheRec has quit IRC
4012018-12-14T15:24:03  *** schmidty_ has quit IRC
4022018-12-14T15:24:54  *** rex4539 has joined #bitcoin-core-dev
4032018-12-14T15:40:46  *** TheRec has joined #bitcoin-core-dev
4042018-12-14T15:40:46  *** TheRec has joined #bitcoin-core-dev
4052018-12-14T15:44:57  *** bitcoin-git has joined #bitcoin-core-dev
4062018-12-14T15:44:57  <bitcoin-git> [bitcoin] luke-jr opened pull request #14960: lint/format-strings: Correctly exclude escaped percent symbols (master...bugfix_lint_fmtstr) https://github.com/bitcoin/bitcoin/pull/14960
4072018-12-14T15:44:57  *** bitcoin-git has left #bitcoin-core-dev
4082018-12-14T15:47:19  *** shesek has quit IRC
4092018-12-14T15:47:36  *** shesek has joined #bitcoin-core-dev
4102018-12-14T15:47:36  *** shesek has joined #bitcoin-core-dev
4112018-12-14T15:53:35  *** Giszmo has joined #bitcoin-core-dev
4122018-12-14T15:54:23  <jnewbery> luke-jr: https://github.com/bitcoin/bips/pull/745 is ready for merge
4132018-12-14T15:59:01  *** rh0nj has quit IRC
4142018-12-14T16:00:08  *** rh0nj has joined #bitcoin-core-dev
4152018-12-14T16:03:48  *** michaelsdunn1 has joined #bitcoin-core-dev
4162018-12-14T16:12:03  *** Chris_Stewart_5 has quit IRC
4172018-12-14T16:13:21  *** TX1683 has quit IRC
4182018-12-14T16:18:01  *** TX1683 has joined #bitcoin-core-dev
4192018-12-14T16:26:14  *** reardencode has quit IRC
4202018-12-14T16:28:28  *** JackH has quit IRC
4212018-12-14T16:40:17  *** reardencode has joined #bitcoin-core-dev
4222018-12-14T16:46:00  *** promag has quit IRC
4232018-12-14T17:08:53  *** JackH has joined #bitcoin-core-dev
4242018-12-14T17:12:08  <BlueMatt> gmaxwell: I will do that today, that is a good point
4252018-12-14T17:14:16  <BlueMatt> errr, or make ryanofsky do it
4262018-12-14T17:14:47  *** Zenton has quit IRC
4272018-12-14T17:16:57  *** bitcoin-git has joined #bitcoin-core-dev
4282018-12-14T17:16:58  <bitcoin-git> [bitcoin] ch4ot1c closed pull request #14601: [rpc] Descriptions: Consistent arg labels for types 'object', 'array', 'boolean', and 'string' (master...fix/rpc-arg-types) https://github.com/bitcoin/bitcoin/pull/14601
4292018-12-14T17:16:58  *** bitcoin-git has left #bitcoin-core-dev
4302018-12-14T17:25:53  *** promag has joined #bitcoin-core-dev
4312018-12-14T17:30:26  *** promag has quit IRC
4322018-12-14T17:35:28  *** riemann_ has quit IRC
4332018-12-14T17:46:34  *** riemann_ has joined #bitcoin-core-dev
4342018-12-14T17:52:26  *** EagleTM has joined #bitcoin-core-dev
4352018-12-14T17:59:02  *** TX1683_ has joined #bitcoin-core-dev
4362018-12-14T18:01:15  *** TX1683 has quit IRC
4372018-12-14T18:01:16  *** TX1683_ is now known as TX1683
4382018-12-14T18:01:16  *** Eagle[TM] has joined #bitcoin-core-dev
4392018-12-14T18:02:58  *** EagleTM has quit IRC
4402018-12-14T18:03:12  *** bitcoin-git has joined #bitcoin-core-dev
4412018-12-14T18:03:13  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/7a30e0f6c544...b53573e5c6c7
4422018-12-14T18:03:13  <bitcoin-git> bitcoin/master faa8311 MarcoFalke: Revert "tests: Support calling add_nodes more than once"...
4432018-12-14T18:03:14  <bitcoin-git> bitcoin/master fa4b8c9 MarcoFalke: test: add_nodes can only be called once after set_test_params
4442018-12-14T18:03:14  <bitcoin-git> bitcoin/master b53573e MarcoFalke: Merge #14951: Revert "tests: Support calling add_nodes more than once"...
4452018-12-14T18:03:15  *** bitcoin-git has left #bitcoin-core-dev
4462018-12-14T18:03:57  *** bitcoin-git has joined #bitcoin-core-dev
4472018-12-14T18:03:57  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14951: Revert "tests: Support calling add_nodes more than once" (master...Mf1812-TestrevertAddNodes) https://github.com/bitcoin/bitcoin/pull/14951
4482018-12-14T18:03:57  *** bitcoin-git has left #bitcoin-core-dev
4492018-12-14T18:06:22  *** Murch has joined #bitcoin-core-dev
4502018-12-14T18:07:32  *** Eagle[TM] has quit IRC
4512018-12-14T18:14:05  *** jungly has quit IRC
4522018-12-14T18:31:35  *** spinza has quit IRC
4532018-12-14T18:32:21  *** Murch has quit IRC
4542018-12-14T18:34:33  *** Murch has joined #bitcoin-core-dev
4552018-12-14T18:45:44  *** spinza has joined #bitcoin-core-dev
4562018-12-14T18:48:04  *** Murch has quit IRC
4572018-12-14T18:48:57  *** bitcoinjunior has joined #bitcoin-core-dev
4582018-12-14T18:48:59  *** Murch has joined #bitcoin-core-dev
4592018-12-14T18:50:24  *** bitcoinsushi has joined #bitcoin-core-dev
4602018-12-14T18:53:15  *** bitcoinjunior has quit IRC
4612018-12-14T18:54:00  <jnewbery> is today a wallet meeting day?
4622018-12-14T18:54:43  <instagibbs> yes
4632018-12-14T18:54:50  <sipa> yes
4642018-12-14T18:56:19  <provoostenator> Indeed, it's that time of the fortnight.
4652018-12-14T18:57:25  *** Giszmo has quit IRC
4662018-12-14T18:58:08  <jnewbery> you're right, it has been fourteen nights since the last wallet meeting
4672018-12-14T18:59:04  <sipa> might i add that in fact 336 hours have passed since our last colloquium on these matters
4682018-12-14T18:59:15  <meshcollider> lol
4692018-12-14T19:01:01  <meshcollider> sipa: want to host it? Or shall I
4702018-12-14T19:01:31  <gwillen> wait wait... is "fortnight" from "fourteen"
4712018-12-14T19:01:36  <gwillen> this feels obvious now but I had no idea
4722018-12-14T19:01:36  <sipa> meshcollider: go ahead
4732018-12-14T19:01:42  <meshcollider> #startmeeting
4742018-12-14T19:01:42  <lightningbot> Meeting started Fri Dec 14 19:01:42 2018 UTC.  The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
4752018-12-14T19:01:42  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4762018-12-14T19:01:49  <sipa> gwillen: i always assumed that it did
4772018-12-14T19:02:02  <jnewbery> feowertyne niht
4782018-12-14T19:02:04  <meshcollider> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
4792018-12-14T19:02:29  <meshcollider> Ok topics?
4802018-12-14T19:02:49  <kanzure> hi.
4812018-12-14T19:02:58  <jnewbery> high priority for review?
4822018-12-14T19:02:59  <sipa> yay, some stuff got merged
4832018-12-14T19:03:07  <instagibbs> yes yay
4842018-12-14T19:03:13  <provoostenator> Probably topics:
4852018-12-14T19:03:18  <jnewbery> #14565 is wallety
4862018-12-14T19:03:19  <provoostenator> 1. progress towards descriptor wallets
4872018-12-14T19:03:23  <gribble> https://github.com/bitcoin/bitcoin/issues/14565 | Overhaul importmulti logic by sipa · Pull Request #14565 · bitcoin/bitcoin · GitHub
4882018-12-14T19:03:26  <provoostenator> 2. progrress towards hardware wallets
4892018-12-14T19:03:46  <jnewbery> #11082 isn't wallety, but is blocking provoostenator's wallety PRs
4902018-12-14T19:03:49  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
4912018-12-14T19:04:07  <achow101> hi
4922018-12-14T19:04:30  <meshcollider> #topic high priority
4932018-12-14T19:04:30  <provoostenator> jnewbery: it's blocking my future walety PR's (once I start on the GUI side of hardware wallets)
4942018-12-14T19:05:18  <meshcollider> jnewbery: they are both already on the list right
4952018-12-14T19:05:36  <provoostenator> Correct
4962018-12-14T19:05:37  <jnewbery> 14565 looks good. It was missing tests, but now looks pretty well covered (thanks sipa!)
4972018-12-14T19:05:47  <jnewbery> yes, both there already: https://github.com/bitcoin/bitcoin/projects/8
4982018-12-14T19:06:10  <provoostenator> Once that's in, I would say #14491 become priority.
4992018-12-14T19:06:13  <meshcollider> Yes 14565 is very nearly ready I think
5002018-12-14T19:06:13  <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
5012018-12-14T19:06:36  <jnewbery> reminder that 14565 blocks PRs from meshcollider and achow101, so it'd be nice to move it towards merge
5022018-12-14T19:07:59  <meshcollider> Yes
5032018-12-14T19:08:08  <meshcollider> I had one last little question on there
5042018-12-14T19:09:23  <meshcollider> Is there anything else wallet related that should go onto high priority list now?
5052018-12-14T19:10:08  <meshcollider> #topic progress towards descriptor wallets (provoostenator)
5062018-12-14T19:10:33  * provoostenator looks as sipa
5072018-12-14T19:10:39  <provoostenator> *at
5082018-12-14T19:10:53  * sipa stares back
5092018-12-14T19:11:21  <instagibbs> various descriptor support, like in listunspent?
5102018-12-14T19:11:22  <meshcollider> sipa: have you thought more about it recently or been mostly focused on the PRNG stuff
5112018-12-14T19:11:43  *** riemann_ has quit IRC
5122018-12-14T19:11:53  <sipa> meshcollider: no, sorry - i've been busy with a few other projects
5132018-12-14T19:12:36  <meshcollider> that's fine of course :) I guess that is your update provoostenator
5142018-12-14T19:12:51  <meshcollider> There was an issue tracking which RPCs to add descriptor support to iirc
5152018-12-14T19:12:53  <provoostenator> Well, I'd like to know what's next, but we do have enough review work already I guess.
5162018-12-14T19:13:00  <sipa> next step is moving IsMine and related functions to be part of the wallet or some other abstraction, rather than free functions
5172018-12-14T19:13:14  <sipa> so they can later be extended to be descriptor based
5182018-12-14T19:13:20  <provoostenator> Ok
5192018-12-14T19:13:27  <provoostenator> Anything about the Keypool we can improve?
5202018-12-14T19:13:58  <meshcollider> I can take a stab at the ismine stuff
5212018-12-14T19:14:01  <sipa> that needs to be part of the same interface, i expect
5222018-12-14T19:14:05  <provoostenator> For example I'm a bit worried about #14075 interacting with the keypool from RPC code.
5232018-12-14T19:14:08  <sipa> but maybe a later step
5242018-12-14T19:14:08  <gribble> https://github.com/bitcoin/bitcoin/issues/14075 | Import watch only pubkeys to the keypool if private keys are disabled by achow101 · Pull Request #14075 · bitcoin/bitcoin · GitHub
5252018-12-14T19:14:39  <sipa> that looks like it may interact, indeed
5262018-12-14T19:14:57  <provoostenator> Though it can be refactored after that, it's nice if we at least have an idea of what the final thing needs to look like.
5272018-12-14T19:15:11  <meshcollider> So instead of the keypool being generated by a single descriptor, it will have imports in it too
5282018-12-14T19:15:48  <provoostenator> Right now the keypool, when it expands itself, makes strong assumptions about the wallet and just uses the HD structure.
5292018-12-14T19:16:14  <provoostenator> Whereas what we want probably is for the keypool (or something like it) to expand a specific descriptor.
5302018-12-14T19:16:27  <sipa> well there won't be a keypool anymore
5312018-12-14T19:16:43  <sipa> it's just a descriptor, which some entries cached, and some not (yet)
5322018-12-14T19:17:04  <sipa> the hard part is integrating the existing logic into such a structure
5332018-12-14T19:17:15  *** bitcoin-git has joined #bitcoin-core-dev
5342018-12-14T19:17:16  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b53573e5c6c7...6723d8e3a694
5352018-12-14T19:17:16  <bitcoin-git> bitcoin/master fa30a0e MarcoFalke: test: mempool_persist: Verify prioritization is dumped correctly
5362018-12-14T19:17:17  <bitcoin-git> bitcoin/master 6723d8e MarcoFalke: Merge #14931: test: mempool_persist: Verify prioritization is dumped correctly...
5372018-12-14T19:17:17  *** bitcoin-git has left #bitcoin-core-dev
5382018-12-14T19:17:52  *** bitcoin-git has joined #bitcoin-core-dev
5392018-12-14T19:17:52  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14931: test: mempool_persist: Verify prioritization is dumped correctly (master...Mf1812-testMempoolPrio) https://github.com/bitcoin/bitcoin/pull/14931
5402018-12-14T19:17:52  *** bitcoin-git has left #bitcoin-core-dev
5412018-12-14T19:18:12  <provoostenator> Any prose or pseudo-code describing how such integration would work is most welcome (in a Github issue).
5422018-12-14T19:18:36  <sipa> i think we'll want to see the existing keypool/keys/... as a special "legacy" descriptor that doesn't really have a text representation
5432018-12-14T19:19:00  <meshcollider> sipa: to cache them, would you expand() them with the cache function during the existin topup function
5442018-12-14T19:19:20  <sipa> meshcollider: right, exactly
5452018-12-14T19:19:43  <provoostenator> Why wouldn't it have a text representation?
5462018-12-14T19:20:10  <sipa> provoostenator: well the text representation is the entire set of keys, pubkeys, scripts, hdpaths, ... that are currently stored in the wallet :)
5472018-12-14T19:20:26  <sipa> i guess you could dump it in hex or something
5482018-12-14T19:20:58  <provoostenator> A migration wizard should be able to, at least for standard wallets, turn that into a series of regular descriptors no?
5492018-12-14T19:21:15  <sipa> that may be possible, but i don't think that's the priority now
5502018-12-14T19:21:50  <meshcollider> It'd be quicker and safer to just move-only the code type of thing into legacy functions
5512018-12-14T19:21:56  <sipa> (because then you have to worry about all existing RPCs, and their effect on those descriptors)
5522018-12-14T19:22:11  <provoostenator> Right, just depends on what's easier in practice. Personally I suspect it'll be easier to make the wallet _only_ have descriptors, just from a writing tests point of view.
5532018-12-14T19:22:22  *** bitcoin-git has joined #bitcoin-core-dev
5542018-12-14T19:22:23  <sipa> i think it's not too much work to just have a legacy subsystem, and a new system - and a wallet can contain just one of them, or both
5552018-12-14T19:22:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6723d8e3a694...9133227298ad
5562018-12-14T19:22:24  <bitcoin-git> bitcoin/master c84c2b8 practicalswift: tests: Test for expected return values when calling functions returning a success code
5572018-12-14T19:22:24  <bitcoin-git> bitcoin/master 9133227 MarcoFalke: Merge #14935: tests: Test for expected return values when calling functions returning a success code...
5582018-12-14T19:22:25  *** bitcoin-git has left #bitcoin-core-dev
5592018-12-14T19:22:33  <provoostenator> But the RPC thing could be a pain yes.
5602018-12-14T19:22:34  <sipa> maybe we even want to forbid mixing them in one wallet
5612018-12-14T19:23:06  *** bitcoin-git has joined #bitcoin-core-dev
5622018-12-14T19:23:06  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14935: tests: Test for expected return values when calling functions returning a success code (master...test-return-values) https://github.com/bitcoin/bitcoin/pull/14935
5632018-12-14T19:23:06  *** bitcoin-git has left #bitcoin-core-dev
5642018-12-14T19:23:07  <sipa> but forced migration may getting it accepted much harder
5652018-12-14T19:23:10  *** michaelsdunn1 has quit IRC
5662018-12-14T19:23:58  <sipa> so my idea is that every record is a descriptor + some metadata (like gap limit, whether it's change or no), plus some cached keys... and there can be a special "legacy" record that's just all the existing keypool/ismine logic
5672018-12-14T19:24:00  <phantomcircuit> the rw config is mostly because the qt stuff writes to random places for settings right?
5682018-12-14T19:24:14  <provoostenator> So then you might end up with two seperate wallet systems and a migration tool, where the old system only gets maintenance updates to be able to read from it.
5692018-12-14T19:24:24  <luke-jr> phantomcircuit: random? not really; just different from bitcoind
5702018-12-14T19:24:27  <sipa> provoostenator: maybe
5712018-12-14T19:24:40  <phantomcircuit> luke-jr, i mean it writes to reg on windows
5722018-12-14T19:24:45  <phantomcircuit> which is super annoying to change
5732018-12-14T19:24:52  <sipa> phantomcircuit: please stick to topic
5742018-12-14T19:24:55  <meshcollider> phantomcircuit: we are in a wallet meeting btw :)
5752018-12-14T19:26:04  <meshcollider> We could open an issue to discuss the alternative approaches, or just discuss which is easier as we start actually writing the code
5762018-12-14T19:26:09  <provoostenator> A new wallet subsystem might also let us cleanly long-term deprecate some wallet RPC methods and replace them with clean ones, that happen to support descriptors?
5772018-12-14T19:26:18  <sipa> provoostenator: yup
5782018-12-14T19:26:19  <provoostenator> And maybe move to Sqlite3 at the same time.
5792018-12-14T19:26:36  <sipa> i think that's completely orthogonal
5802018-12-14T19:26:49  <provoostenator> Could be, yes.
5812018-12-14T19:27:11  <luke-jr> phantomcircuit: I answered in #bitcoin fyi
5822018-12-14T19:28:05  <provoostenator> Anyway, we have some next actions now to continue progress, maybe next topic?
5832018-12-14T19:28:37  <meshcollider> #topic progress towards hardware wallets (provoostenator)
5842018-12-14T19:28:46  <jnewbery> IsMine moved from wallet to common here: https://github.com/bitcoin/bitcoin/commit/a25a4f5b04c3e045557e9e7e807b2af74ad75128 . Was that just because of the way the multisig and P2SH tests are constructed (ie could those tests just be rewritten)?
5852018-12-14T19:28:54  <provoostenator> Now that #14491 has been rebased, the `hww` branch I'm building off should also soon be rebased.
5862018-12-14T19:28:57  <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
5872018-12-14T19:29:02  <provoostenator> #14912
5882018-12-14T19:29:04  <gribble> https://github.com/bitcoin/bitcoin/issues/14912 | [WIP] External signer support (e.g. hardware wallet) by Sjors · Pull Request #14912 · bitcoin/bitcoin · GitHub
5892018-12-14T19:29:27  <provoostenator> I'll do some cleaning up of my ugly string concatenation descriptor code after rebase.
5902018-12-14T19:29:54  <provoostenator> People can already test it though. It compiles and actually works (at your own risk, so use testnet).
5912018-12-14T19:30:14  <meshcollider> jnewbery: looks like it?
5922018-12-14T19:30:47  <provoostenator> As in, you can create a new wallet, put read-only keys in it, show address on the device and spend coins. Using achow101's HWI library to talk to the device.
5932018-12-14T19:31:28  <provoostenator> So the idea is that users would download that library seperately and just launch bitcoind -signer=../HWI/hwi.py (or some other tool). That way we don't ahve to review individual hardware wallet code.
5942018-12-14T19:31:49  <meshcollider> provoostenator: cool \o/
5952018-12-14T19:32:30  <provoostenator> With very little code changes this could also work against a gRPC server, but there's some security trade-offs compared to calling commands. We talked about that a few weeks ago.
5962018-12-14T19:33:11  <provoostenator> I am trying to keep it generic enough to keep that possible, so e.g. the -signer= command could later also be a URL. But for now, it just executes a command and parses the JSON that command spits out to stdout.
5972018-12-14T19:34:01  <provoostenator> Next step for me is to work on GUI support for this. But there's already a pile of prerequisite stuff to review, so don't worry too much about that :-)
5982018-12-14T19:34:21  <provoostenator> I personally just like to see the big picture in action.
5992018-12-14T19:34:27  <meshcollider> Yes let's not stack too many PRs at once again ;)
6002018-12-14T19:35:47  <provoostenator> For GUI proof of concept I'd just like to nag promag about #13100, which we want anyway.
6012018-12-14T19:35:50  <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
6022018-12-14T19:36:22  *** jarthur has joined #bitcoin-core-dev
6032018-12-14T19:36:24  <provoostenator> (that's all I have)
6042018-12-14T19:37:52  <MarcoFalke> wget https://bitcointools.jonasschnelli.ch/data/builds/914/    ... failed: Connection refused
6052018-12-14T19:37:53  <meshcollider> that PR hasn't been rebased for 2 months, perhaps you'd like to take it up and rebased it yourself?
6062018-12-14T19:37:55  <MarcoFalke> ^ jonasschnelli
6072018-12-14T19:38:06  <provoostenator> He actually said he's working on it soon.
6082018-12-14T19:38:14  <meshcollider> Oh ok
6092018-12-14T19:38:48  <provoostenator> I think he needs this to go in first #14573, that's almost mergeable.
6102018-12-14T19:38:49  <meshcollider> I'm happy to review it as soon as its ready, its already tagged for 0.18
6112018-12-14T19:38:50  <gribble> https://github.com/bitcoin/bitcoin/issues/14573 | qt: Add Window menu by promag · Pull Request #14573 · bitcoin/bitcoin · GitHub
6122018-12-14T19:39:44  <meshcollider> Are there any other topics?
6132018-12-14T19:40:04  <provoostenator> luke-jr phantomcircuit did you want to discuss rw_config stuff?
6142018-12-14T19:40:31  <provoostenator> I noticed the rabase, so I'll rebase my Settings migration stuff as well.
6152018-12-14T19:40:47  *** bitcoin-git has joined #bitcoin-core-dev
6162018-12-14T19:40:47  <bitcoin-git> [bitcoin] ch4ot1c opened pull request #14961: [docs] Root readme improvements (master...improvements/readme) https://github.com/bitcoin/bitcoin/pull/14961
6172018-12-14T19:40:47  *** bitcoin-git has left #bitcoin-core-dev
6182018-12-14T19:40:56  <provoostenator> But it's not very wallety.
6192018-12-14T19:41:36  <meshcollider> Looks like that might be it for today
6202018-12-14T19:41:43  <meshcollider> Thanks provoostenator :)
6212018-12-14T19:41:51  <meshcollider> #endmeeting
6222018-12-14T19:41:51  <lightningbot> Meeting ended Fri Dec 14 19:41:51 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6232018-12-14T19:41:51  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-12-14-19.01.html
6242018-12-14T19:41:51  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-12-14-19.01.txt
6252018-12-14T19:41:51  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-12-14-19.01.log.html
6262018-12-14T19:42:35  <jnewbery> good colloquium!
6272018-12-14T19:43:02  <provoostenator> By the way, it would be nice if bitcoincore.org and such sites could link to the IRC logs. Many places now point to BotBot and Google can't find these other URLs either.
6282018-12-14T19:43:13  <provoostenator> jnewbery: splendit!
6292018-12-14T19:43:22  <jnewbery> I expect some/most people won't be around for the next scheduled one (Dec 28th)
6302018-12-14T19:43:39  <provoostenator> 35C3
6312018-12-14T19:43:48  <jnewbery> I almost certainly won't be online for it
6322018-12-14T19:44:02  <provoostenator> Maybe bump that, and thus the whole schedule, by one week?
6332018-12-14T19:44:03  <luke-jr> might make sense to cancel meetings during Christmas
6342018-12-14T19:44:06  *** michaelsdunn1 has joined #bitcoin-core-dev
6352018-12-14T19:44:39  <sipa> provoostenator: will you be at 35c3?
6362018-12-14T19:45:42  <jnewbery> provoostenator: aj was looking at uploading the IRC logs onto bitcoincore.org every week. Not sure what the progress is on that.
6372018-12-14T19:45:42  <provoostenator> That also moves closer to new moon.
6382018-12-14T19:45:56  <provoostenator> sipa: I can neither confirm nor deny that :-)
6392018-12-14T19:53:06  *** timothy has quit IRC
6402018-12-14T19:53:22  *** michaelsdunn1 has quit IRC
6412018-12-14T19:54:26  *** michaelsdunn1 has joined #bitcoin-core-dev
6422018-12-14T19:54:51  *** shesek has quit IRC
6432018-12-14T19:55:14  *** shesek has joined #bitcoin-core-dev
6442018-12-14T19:56:55  *** michaelsdunn1 has quit IRC
6452018-12-14T19:57:52  *** michaelsdunn1 has joined #bitcoin-core-dev
6462018-12-14T19:59:35  *** riemann_ has joined #bitcoin-core-dev
6472018-12-14T20:00:03  *** michaelsdunn1 has quit IRC
6482018-12-14T20:01:02  *** rh0nj has quit IRC
6492018-12-14T20:01:03  *** shesek has quit IRC
6502018-12-14T20:01:25  *** shesek has joined #bitcoin-core-dev
6512018-12-14T20:02:07  *** rh0nj has joined #bitcoin-core-dev
6522018-12-14T20:02:51  *** michaelsdunn1 has joined #bitcoin-core-dev
6532018-12-14T20:03:05  *** bitcoinsushi has quit IRC
6542018-12-14T20:09:46  *** shesek has quit IRC
6552018-12-14T20:11:24  *** shesek has joined #bitcoin-core-dev
6562018-12-14T20:11:24  *** shesek has joined #bitcoin-core-dev
6572018-12-14T20:11:57  *** shesek has quit IRC
6582018-12-14T20:13:01  *** shesek has joined #bitcoin-core-dev
6592018-12-14T20:13:57  *** riemann_ has quit IRC
6602018-12-14T20:16:58  *** shesek has quit IRC
6612018-12-14T20:17:21  *** shesek has joined #bitcoin-core-dev
6622018-12-14T20:21:09  *** michaelsdunn1 has quit IRC
6632018-12-14T20:22:40  *** bitcoin-git has joined #bitcoin-core-dev
6642018-12-14T20:22:40  <bitcoin-git> [bitcoin] DrahtBot closed pull request #13200: Process logs in a separate thread (master...2018-05-asynclog) https://github.com/bitcoin/bitcoin/pull/13200
6652018-12-14T20:22:40  *** bitcoin-git has left #bitcoin-core-dev
6662018-12-14T20:23:56  *** michaels_ has joined #bitcoin-core-dev
6672018-12-14T20:28:15  *** michaels_ has quit IRC
6682018-12-14T20:29:35  *** wxss has joined #bitcoin-core-dev
6692018-12-14T20:30:56  *** shesek has quit IRC
6702018-12-14T20:32:27  *** wxss has quit IRC
6712018-12-14T20:32:58  *** shesek has joined #bitcoin-core-dev
6722018-12-14T20:32:58  *** shesek has joined #bitcoin-core-dev
6732018-12-14T20:49:29  *** chenpo has joined #bitcoin-core-dev
6742018-12-14T20:50:38  <instagibbs> how are subtrees updated? The linter logic is looking for a template of a commit style, I presume generated by a script?
6752018-12-14T20:50:55  <instagibbs> Can't find resource in contributor docs
6762018-12-14T20:52:32  <sipa> git subtree update :p
6772018-12-14T20:53:33  <sipa> git subtree merge --squash, actually
6782018-12-14T20:54:04  *** wxss has joined #bitcoin-core-dev
6792018-12-14T20:56:48  <instagibbs> after a few hours of course I find the answer as soon as I ask via google :)
6802018-12-14T20:56:56  <instagibbs> need CSV on my irc questions
6812018-12-14T20:57:53  *** michaelsdunn1 has joined #bitcoin-core-dev
6822018-12-14T20:57:55  *** bitcoinjunior has joined #bitcoin-core-dev
6832018-12-14T21:00:26  *** bitcoinsushi has joined #bitcoin-core-dev
6842018-12-14T21:02:07  *** bitcoinjunior has quit IRC
6852018-12-14T21:05:22  *** michaelsdunn1 has quit IRC
6862018-12-14T21:12:36  *** EagleTM has joined #bitcoin-core-dev
6872018-12-14T21:25:39  *** promag has joined #bitcoin-core-dev
6882018-12-14T21:27:06  *** shesek has quit IRC
6892018-12-14T21:27:58  *** shesek has joined #bitcoin-core-dev
6902018-12-14T21:27:58  *** shesek has joined #bitcoin-core-dev
6912018-12-14T21:29:47  *** promag has quit IRC
6922018-12-14T21:33:12  <sipa> anyone know why https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/21022194 (#14955) is failing?
6932018-12-14T21:33:13  <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
6942018-12-14T21:34:09  <sipa> (i've restarted it 3 times, same error each time)
6952018-12-14T21:35:33  *** chenpo has quit IRC
6962018-12-14T21:50:23  *** Zenton has joined #bitcoin-core-dev
6972018-12-14T21:58:40  *** bitcoinsushi has quit IRC
6982018-12-14T21:59:43  <sipa> gmaxwell: using sha256d4 (or even simple sha256) in the rng code would require the sha256 to auto-initialize on first use rather than using a dedicated initialize function
6992018-12-14T22:01:22  <sipa> that doesn't seem too hard (c++11 has std::call_once for exactly that purpose), but maybe more than we want in one PR
7002018-12-14T22:02:32  <gmaxwell> oh damn, we need some init crap to sniff hardware support.
7012018-12-14T22:02:48  <gmaxwell> sipa: Well it could directly call the C version if not initilized.
7022018-12-14T22:06:56  <sipa> it's not hard to do
7032018-12-14T22:07:23  *** bitcoin-git has joined #bitcoin-core-dev
7042018-12-14T22:07:23  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #14963: doc: Add comment to cs_main and mempool::cs (master...Mf1812-docValLocks) https://github.com/bitcoin/bitcoin/pull/14963
7052018-12-14T22:07:23  *** bitcoin-git has left #bitcoin-core-dev
7062018-12-14T22:07:55  *** fasefwef has joined #bitcoin-core-dev
7072018-12-14T22:10:45  <sipa> std::call_once seems to take 2ns here
7082018-12-14T22:11:06  *** fasefwef has quit IRC
7092018-12-14T22:11:38  <sipa> that seems acceptable as an overhead to the SHA256 functions (it's equivalent to adding less than a byte of input on average)
7102018-12-14T22:11:51  <gmaxwell> well if we care about 2ns we could make the rng state hasher sha256, reduce the chained state size a little and get that time back, ...
7112018-12-14T22:12:35  <sipa> no, i don't mean for the RNG
7122018-12-14T22:12:46  <sipa> this would be overhead added to every invocation of SHA256 functions
7132018-12-14T22:13:31  <gmaxwell> oh. I was thinking you'd just put the call once in the rng functions ahead of the sha256d64 use.
7142018-12-14T22:13:49  <gmaxwell> but right okay, only half paying attention.
7152018-12-14T22:13:57  <sipa> that would... probably work
7162018-12-14T22:14:23  <sipa> an alternative is making sure no global constructors use the RNG
7172018-12-14T22:14:37  <sipa> that would have no overhead at all, but is pretty inconvenient for some things
7182018-12-14T22:14:58  <gmaxwell> it's also unfortunate that we couldn't make that compile-time fail.
7192018-12-14T22:15:10  <sipa> yes
7202018-12-14T22:16:13  <sipa> for the RNG itself, currently it's SHA512(new_entropy || previous_state), which is split into rng_output and next_state
7212018-12-14T22:16:44  <sipa> which means it's reducing to 256 bits of entropy after every extraction, for no go reason
7222018-12-14T22:17:13  <gmaxwell> well I like not keeping around the randomness we just output, it's a liability in memory.
7232018-12-14T22:17:25  <sipa> obviously
7242018-12-14T22:18:09  *** promag has joined #bitcoin-core-dev
7252018-12-14T22:19:48  *** bralyclow has joined #bitcoin-core-dev
7262018-12-14T22:21:02  <gmaxwell> it seems kinda odd to me that we could end up with with two strenghteners going at once, but I think completely harmless.
7272018-12-14T22:21:03  *** bralyclow2 has joined #bitcoin-core-dev
7282018-12-14T22:21:37  *** spinza has quit IRC
7292018-12-14T22:22:11  *** bralyclow2 has quit IRC
7302018-12-14T22:23:14  *** bralyclow2 has joined #bitcoin-core-dev
7312018-12-14T22:23:39  *** bralyclow2 has quit IRC
7322018-12-14T22:30:58  *** ChA1NsAw has quit IRC
7332018-12-14T22:34:44  *** spinza has joined #bitcoin-core-dev
7342018-12-14T22:34:55  *** Guyver2 has quit IRC
7352018-12-14T22:41:47  *** thoreg has joined #bitcoin-core-dev
7362018-12-14T22:42:20  *** thoreg has quit IRC
7372018-12-14T23:07:29  *** bbq has joined #bitcoin-core-dev
7382018-12-14T23:08:13  *** bbq has left #bitcoin-core-dev
7392018-12-14T23:14:30  *** fabianfabian has joined #bitcoin-core-dev
7402018-12-14T23:14:51  *** bitcoin-git has joined #bitcoin-core-dev
7412018-12-14T23:14:51  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #14964: test: Fix race in mempool_accept (master...Mf1812-testRaceMempoolAccept) https://github.com/bitcoin/bitcoin/pull/14964
7422018-12-14T23:14:51  *** bitcoin-git has left #bitcoin-core-dev
7432018-12-14T23:23:13  *** kmels has quit IRC
7442018-12-14T23:27:01  *** bralyclow has quit IRC
7452018-12-14T23:33:58  *** bitcoinjunior has joined #bitcoin-core-dev
7462018-12-14T23:34:59  *** bitcoinsushi has joined #bitcoin-core-dev
7472018-12-14T23:38:31  *** bitcoinjunior has quit IRC
7482018-12-14T23:39:07  *** bitcoinsushi has quit IRC
7492018-12-14T23:45:15  *** Tralfaz has quit IRC
7502018-12-14T23:46:12  *** Tralfaz has joined #bitcoin-core-dev
7512018-12-14T23:48:42  *** jarthur has quit IRC
7522018-12-14T23:51:21  *** Tralfaz has quit IRC
7532018-12-14T23:55:57  *** michaelsdunn1 has joined #bitcoin-core-dev