1 2016-09-22T00:46:52  <GitHub154> [bitcoin] instagibbs opened pull request #8785: Comment on CNode::nLocalServices meaning (master...nlocalservisme) https://github.com/bitcoin/bitcoin/pull/8785
   2 2016-09-22T00:56:55  *** Ylbam has quit IRC
   3 2016-09-22T01:05:05  *** xinxi has quit IRC
   4 2016-09-22T01:05:14  *** jnewbery has quit IRC
   5 2016-09-22T01:06:52  *** xinxi has joined #bitcoin-core-dev
   6 2016-09-22T01:14:13  *** xinxi has quit IRC
   7 2016-09-22T01:15:16  *** Alopex has quit IRC
   8 2016-09-22T01:16:21  *** Alopex has joined #bitcoin-core-dev
   9 2016-09-22T01:22:01  *** xinxi has joined #bitcoin-core-dev
  10 2016-09-22T01:22:46  *** jl2012 has joined #bitcoin-core-dev
  11 2016-09-22T01:26:55  *** xinxi has quit IRC
  12 2016-09-22T01:27:10  *** shesek has quit IRC
  13 2016-09-22T01:27:14  *** xinxi has joined #bitcoin-core-dev
  14 2016-09-22T01:27:22  *** arubi has quit IRC
  15 2016-09-22T01:28:11  *** xinxi has quit IRC
  16 2016-09-22T01:28:44  *** xinxi has joined #bitcoin-core-dev
  17 2016-09-22T01:30:21  *** echonaut has quit IRC
  18 2016-09-22T01:30:40  *** echonaut has joined #bitcoin-core-dev
  19 2016-09-22T01:32:30  *** arubi has joined #bitcoin-core-dev
  20 2016-09-22T01:34:06  *** shesek has joined #bitcoin-core-dev
  21 2016-09-22T01:38:47  <wumpus> can we please stop doing the copyright pulls where half of github is highlightes
  22 2016-09-22T01:42:52  <wumpus> if you really think it is necessary to add everyone that ever fixed a typo in a build script before adding a header to each individual file, ask yourself whether this is really worth it, you're generalling ten gezillion notification mails
  23 2016-09-22T01:45:21  <achow101> by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant.
  24 2016-09-22T01:45:31  <gmaxwell> Why is that kind of thing being done by indivigual PRs rather than e.g. sending a mass email to all past contributors saying we're normalizing files in this and that way?
  25 2016-09-22T01:45:40  *** Chris_Stewart_5 has quit IRC
  26 2016-09-22T01:45:44  <gmaxwell> achow101: that is unlear though it could be made clear.
  27 2016-09-22T01:46:15  <wumpus> I don't know, but this getting out of hand
  28 2016-09-22T01:46:42  <achow101> I though that was just kind of "in general" for all OSS projects
  29 2016-09-22T01:46:43  <wumpus> achow101: that is what I always thought too
  30 2016-09-22T01:46:50  <wumpus> there is a COPYING file in the rot of the repository
  31 2016-09-22T01:46:54  <wumpus> root*
  32 2016-09-22T01:47:07  <wumpus> if you don't put an explicit license in a file, that is what it is bound to
  33 2016-09-22T01:47:30  <wumpus> but apparantly this is turning into a frigging zoo now, what's next, ahving to ask permision for every source line?
  34 2016-09-22T01:47:57  <wumpus> what is this accomplishing?
  35 2016-09-22T01:48:44  <wumpus> and yes, asking per email would have been preferable. Asking once per contributor, too. If that is really necessary.
  36 2016-09-22T01:48:50  <wumpus> but we're not relicencing the project
  37 2016-09-22T01:48:58  <wumpus> it has ALWAYS been MIT
  38 2016-09-22T01:49:03  <wumpus> satoshi made it MIT
  39 2016-09-22T01:49:57  <wumpus> I've been contributing to open source for 20 years and I've never, once had a mail whether I gave permission to add a license header (license of the project) to the top of some file
  40 2016-09-22T01:50:13  <wumpus> I've been mailed a few times to approve of license changes, but that's a whole different and more serious thing
  41 2016-09-22T01:50:53  <wumpus> and that was for real contributions not changing the case of one letter in one file
  42 2016-09-22T01:55:59  <achow101> So what about adding this to the contributing.md: "By contributing to this repository, you agree to license your work under the MIT license and any subsequent licensing changes"
  43 2016-09-22T01:56:49  <wumpus> not the last part
  44 2016-09-22T01:57:09  <wumpus> only "By contributing to this repository, you agree to license your work under the MIT license"
  45 2016-09-22T01:57:18  <achow101> ok.
  46 2016-09-22T01:58:36  <wumpus> future license changes are absolutely out of scope, I wouldn't agree to that - who decides? changing licenses is a serious issue. Adding the existing copyright header that has been the project's license since 2009 isn't.
  47 2016-09-22T01:59:27  <wumpus> I wouldn't be surprised with all this polling that people are starting to think we're changing licenses though ...
  48 2016-09-22T02:00:25  <GitHub82> [bitcoin] achow101 opened pull request #8786: Mandatory copyright agreement (master...copyright-contributing) https://github.com/bitcoin/bitcoin/pull/8786
  49 2016-09-22T02:02:24  *** DigiByteDev has joined #bitcoin-core-dev
  50 2016-09-22T02:13:17  *** midnightmagic has quit IRC
  51 2016-09-22T02:29:58  <luke-jr> [01:45:21] <achow101> by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant. <-- not with the MIT license
  52 2016-09-22T02:30:16  <wumpus> yes we should make it explicitl
  53 2016-09-22T02:30:27  <wumpus> see https://github.com/bitcoin/bitcoin/pull/8786
  54 2016-09-22T02:30:30  <achow101> well my PR makes it explicit
  55 2016-09-22T02:30:34  <wumpus> yes
  56 2016-09-22T02:32:35  <luke-jr> and hopefully people will stop submitting non-licensed code without getting permission first <.<
  57 2016-09-22T02:32:51  <wumpus> such as?
  58 2016-09-22T02:32:57  <luke-jr> wumpus: l_atomic.m4 until today
  59 2016-09-22T02:33:28  <wumpus> let's revert it then?
  60 2016-09-22T02:33:31  <luke-jr> came from a GPL-licensed project, with no license on the build stuff
  61 2016-09-22T02:33:33  <luke-jr> nah
  62 2016-09-22T02:33:39  <luke-jr> already got an ACK from the author for MIT terms
  63 2016-09-22T02:34:32  <luke-jr> just something to keep in mind when stuff gets contributed by someone other than the original author
  64 2016-09-22T02:36:43  <wumpus> maybe we should add that to #8786, that if you submit something from another source it is important to mention that source as well as the license it is under
  65 2016-09-22T02:36:53  <luke-jr> +1
  66 2016-09-22T02:39:14  <wumpus> hey, github review comments don't show as comments in the pull list
  67 2016-09-22T02:39:26  <luke-jr> O.o
  68 2016-09-22T02:39:29  <wumpus> I've approved https://github.com/bitcoin/bitcoin/pull/8783 but it still shows as 0
  69 2016-09-22T02:40:04  <wumpus> unless I have an unrelated web caching issue, that happens
  70 2016-09-22T02:40:11  <kanzure> ouch is "approved" github's terminology? ok.
  71 2016-09-22T02:40:21  <achow101> How about "Any code contributed where you are not the original author must contain its license header"
  72 2016-09-22T02:40:45  <wumpus> yes makes sense achow101
  73 2016-09-22T02:40:57  <achow101> wumpus: I see your approval on 8783
  74 2016-09-22T02:41:02  <wumpus> kanzure: indeed, I wouldn't have used that word myself
  75 2016-09-22T02:41:16  <achow101> I think it's your browser
  76 2016-09-22T02:41:21  <kanzure> wumpus: that's going to cause confusion. oh well.
  77 2016-09-22T02:41:32  <luke-jr> can we get Travis to check for a copyright line on new files maybe?
  78 2016-09-22T02:42:02  <wumpus> achow101: yes I see it too in the topic itself, but do you see it in the overview list?
  79 2016-09-22T02:42:34  <wumpus> there's this comment icon and then a count, there's no count for #8783 here. Ohwell.
  80 2016-09-22T02:43:09  <achow101> oh that. No I don't see that
  81 2016-09-22T02:44:40  <wumpus> luke-jr: that's certainly possible
  82 2016-09-22T02:45:27  <wumpus> just paste the script from https://github.com/bitcoin/bitcoin/pull/8674 somewhere into the test process in travis.yml
  83 2016-09-22T02:45:30  <wumpus> +report
  84 2016-09-22T02:46:27  <wumpus> it's a pretty good suggestion, could even parse debian/copyright for the copyright metadata on binary files
  85 2016-09-22T02:46:37  <wumpus> I don't have time for those things though :)
  86 2016-09-22T02:50:16  *** xinxi has quit IRC
  87 2016-09-22T03:09:04  *** crudel has joined #bitcoin-core-dev
  88 2016-09-22T03:19:03  <GitHub131> [bitcoin] AmirAbrams opened pull request #8787: [Doc] Add missing autogen to example builds (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8787
  89 2016-09-22T03:23:47  <wumpus> how does this new 'project' functionality work? can I add a project, say 'Ubuntu 16.04 windows cross-build' and group issues under that?
  90 2016-09-22T03:27:21  <achow101> wumpus: watch https://www.youtube.com/watch?v=C6MGKHkNtxU
  91 2016-09-22T03:28:06  <roasbeef> it's basically like trello embedded within github
  92 2016-09-22T03:29:13  <achow101> also read https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects/
  93 2016-09-22T03:29:50  <wumpus> but can I use it for that? the problem is that I have to manually keep track of groups of issues right now, but they don't warrant a new label
  94 2016-09-22T03:33:13  <achow101> AFAICT, yes, you can use it for grouping related issues and PR's
  95 2016-09-22T03:33:34  <achow101> although it seems that actually doing it might be a bit of a pain with the drag and drop interface
  96 2016-09-22T03:35:28  <achow101> Stuff can be in multiple projects, and within projects are additional sub groupings (called columns)
  97 2016-09-22T03:39:36  <wumpus> thanks, looks somewhat like hwat I'm looking for then, I'll read on about it
  98 2016-09-22T03:47:13  *** randy-waterhouse has joined #bitcoin-core-dev
  99 2016-09-22T03:48:18  *** randy-waterhouse has joined #bitcoin-core-dev
 100 2016-09-22T03:48:48  *** YOU-JI has joined #bitcoin-core-dev
 101 2016-09-22T03:49:15  *** YOU-JI has joined #bitcoin-core-dev
 102 2016-09-22T03:50:49  * luke-jr wonders if projects are accessible to non-committers
 103 2016-09-22T03:50:54  *** xinxi has joined #bitcoin-core-dev
 104 2016-09-22T03:51:30  <achow101> luke-jr: can you access the projects here: https://github.com/achow101/ProtectedBranchTest/projects ?
 105 2016-09-22T03:52:32  <luke-jr> I can see them, but it seems I cannot submit an issue to a specific project
 106 2016-09-22T03:54:05  *** YOU-JI has quit IRC
 107 2016-09-22T03:54:21  <achow101> right, I think it's more for internal organization for the committers
 108 2016-09-22T03:54:53  <achow101> just like how you can't do labels or milestones if you aren't part of the group
 109 2016-09-22T03:58:03  *** xinxi has quit IRC
 110 2016-09-22T04:00:44  <sipa_> wumpus: you're up early
 111 2016-09-22T04:01:21  <sipa_> i briefly feared i was in the wrong timezone
 112 2016-09-22T04:05:19  <wumpus> achow101: seems to work fairly well https://github.com/bitcoin/bitcoin/projects/1
 113 2016-09-22T04:05:23  <wumpus> sipa_: hah yes couldn't sleep
 114 2016-09-22T04:06:22  <achow101> :D
 115 2016-09-22T04:16:06  *** moli has quit IRC
 116 2016-09-22T04:21:07  *** sipa_ has quit IRC
 117 2016-09-22T04:23:31  *** sipa has joined #bitcoin-core-dev
 118 2016-09-22T04:23:42  <sipa> wumpus: those projects look useful
 119 2016-09-22T04:23:52  <wumpus> indeed!
 120 2016-09-22T04:24:06  <sipa> especially if we'd actually maintain them, it could simplify things like writinf release notes as well
 121 2016-09-22T04:25:08  <sipa> "PRs #1234, #2345, #3456, #4567 and #5678 together replaced the outdated PoW system"
 122 2016-09-22T04:26:36  <wumpus> yes, that could be an advantage as well
 123 2016-09-22T04:33:37  *** moli has joined #bitcoin-core-dev
 124 2016-09-22T04:55:12  *** xinxi has joined #bitcoin-core-dev
 125 2016-09-22T04:59:54  *** xinxi has quit IRC
 126 2016-09-22T05:01:37  *** DigiByteDev has quit IRC
 127 2016-09-22T05:04:18  *** DigiByteDev has joined #bitcoin-core-dev
 128 2016-09-22T05:06:11  *** Alopex has quit IRC
 129 2016-09-22T05:07:03  *** DigiByteDev has joined #bitcoin-core-dev
 130 2016-09-22T05:07:17  *** Alopex has joined #bitcoin-core-dev
 131 2016-09-22T05:11:37  *** DigiByteDev has quit IRC
 132 2016-09-22T05:15:31  <wumpus> cfields: I've created a project for your P2P refactor, please add if I missed anything: https://github.com/bitcoin/bitcoin/projects/4
 133 2016-09-22T05:23:27  *** amiller has quit IRC
 134 2016-09-22T05:28:15  *** Guest75206 has joined #bitcoin-core-dev
 135 2016-09-22T05:28:33  *** Guest75206 has joined #bitcoin-core-dev
 136 2016-09-22T05:28:33  *** Guest75206 is now known as amiller
 137 2016-09-22T05:40:45  *** davec has quit IRC
 138 2016-09-22T05:41:39  *** davec has joined #bitcoin-core-dev
 139 2016-09-22T05:44:37  <GitHub21> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf5ebaa921a9...ca69ef4880d1
 140 2016-09-22T05:44:37  <GitHub21> bitcoin/master faf87af MarcoFalke: [contrib] delete qt_translations.py...
 141 2016-09-22T05:44:38  <GitHub21> bitcoin/master ca69ef4 Wladimir J. van der Laan: Merge #8781: [contrib] delete qt_translations.py...
 142 2016-09-22T05:44:52  <GitHub172> [bitcoin] laanwj closed pull request #8781: [contrib] delete qt_translations.py (master...Mf1609-deleteQtTrans) https://github.com/bitcoin/bitcoin/pull/8781
 143 2016-09-22T05:45:07  <GitHub146> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca69ef4880d1...64dc6457454a
 144 2016-09-22T05:45:07  <GitHub146> bitcoin/master fa13c5c MarcoFalke: [share] remove qt/protobuf.pri...
 145 2016-09-22T05:45:08  <GitHub146> bitcoin/master 64dc645 Wladimir J. van der Laan: Merge #8783: [share] remove qt/protobuf.pri...
 146 2016-09-22T05:45:22  <GitHub166> [bitcoin] laanwj closed pull request #8783: [share] remove qt/protobuf.pri (master...Mf1609-deleteqtProto) https://github.com/bitcoin/bitcoin/pull/8783
 147 2016-09-22T05:48:57  <GitHub28> [bitcoin] laanwj closed pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186
 148 2016-09-22T05:54:33  *** Ylbam has joined #bitcoin-core-dev
 149 2016-09-22T05:55:03  <GitHub16> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/64dc6457454a...3166dff48f35
 150 2016-09-22T05:55:04  <GitHub16> bitcoin/master 6b6cbdd fanquake: [depends] expat 2.2.0
 151 2016-09-22T05:55:04  <GitHub16> bitcoin/master 9616ac8 fanquake: [depends] ccache 3.3.1
 152 2016-09-22T05:55:05  <GitHub16> bitcoin/master 86d410d fanquake: [depends] fontconfig 2.12.1
 153 2016-09-22T05:55:07  <GitHub4> [bitcoin] laanwj closed pull request #8423: [depends] expat 2.2.0, ccache 3.3.1, fontconfig 2.12.1 (master...expat-ccache-jul) https://github.com/bitcoin/bitcoin/pull/8423
 154 2016-09-22T05:56:35  *** xinxi has joined #bitcoin-core-dev
 155 2016-09-22T05:56:54  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3166dff48f35...7008e28136b5
 156 2016-09-22T05:56:54  <GitHub101> bitcoin/master fa81d09 MarcoFalke: [contrib] Delete spendfrom
 157 2016-09-22T05:56:55  <GitHub101> bitcoin/master 7008e28 Wladimir J. van der Laan: Merge #8779: [contrib] Delete spendfrom...
 158 2016-09-22T05:57:06  <GitHub19> [bitcoin] laanwj closed pull request #8779: [contrib] Delete spendfrom (master...Mf1609-deleteAllTheThings) https://github.com/bitcoin/bitcoin/pull/8779
 159 2016-09-22T06:01:02  *** xinxi has quit IRC
 160 2016-09-22T06:08:36  *** Alopex has quit IRC
 161 2016-09-22T06:09:41  *** Alopex has joined #bitcoin-core-dev
 162 2016-09-22T06:12:08  *** xinxi has joined #bitcoin-core-dev
 163 2016-09-22T06:19:03  *** Giszmo has quit IRC
 164 2016-09-22T06:22:46  *** DigiByteDev has joined #bitcoin-core-dev
 165 2016-09-22T06:24:19  *** xinxi has quit IRC
 166 2016-09-22T06:24:36  *** xinxi has joined #bitcoin-core-dev
 167 2016-09-22T06:28:42  *** Evel-Knievel has quit IRC
 168 2016-09-22T06:42:45  *** AaronvanW has quit IRC
 169 2016-09-22T06:44:51  *** xinxi has quit IRC
 170 2016-09-22T06:45:05  <cfields> wumpus: ooh, neat
 171 2016-09-22T06:45:15  <jonasschnelli> cfields: do you see a/the reason why this fails on gcc but not on clang? https://github.com/bitcoin/bitcoin/pull/8745/files#diff-480477e89f9b6ddafb30c4383dcdd705R407
 172 2016-09-22T06:45:20  <jonasschnelli> Seems to cause linking errors...
 173 2016-09-22T06:45:33  <wumpus> yes. I like this feature
 174 2016-09-22T06:46:06  *** xinxi has joined #bitcoin-core-dev
 175 2016-09-22T06:46:08  <jonasschnelli> Linking errors are here: https://travis-ci.org/bitcoin/bitcoin/jobs/160477991#L1567
 176 2016-09-22T06:46:52  <cfields> wumpus: I'll have a look in the morning. I've been distracted this week from the net stuff by the win32 toolchain crap. Got some neat stuff coming up as a result, though
 177 2016-09-22T06:47:17  <btcdrak> I quite like the projects tab, much easier to see a project progress potentially over more than one release
 178 2016-09-22T06:47:29  *** xinxi_ has joined #bitcoin-core-dev
 179 2016-09-22T06:47:43  <cfields> jonasschnelli: heh, I just fixed the same thing for "bench" a few days ago, I need to PR it
 180 2016-09-22T06:47:46  <cfields> jonasschnelli: sec for link
 181 2016-09-22T06:47:57  <jonasschnelli> cfields: thanks!
 182 2016-09-22T06:48:00  <cfields> jonasschnelli: fyi, link-order doesn't matter for apple's linker, but it does for gnu ld/gold
 183 2016-09-22T06:48:24  <jonasschnelli> Yeah. I thought so and tried different orders,.. used the same the bitcoid does...
 184 2016-09-22T06:48:33  <jonasschnelli> *then
 185 2016-09-22T06:48:37  <cfields> jonasschnelli: https://github.com/theuni/bitcoin/commit/a3786f1aeebf6455acec50926c3b27ea5c060f02
 186 2016-09-22T06:49:06  <jonasschnelli> cfields: Thanks.. Let me try something..
 187 2016-09-22T06:49:08  <cfields> jonasschnelli: should be pretty much copy/paste for you
 188 2016-09-22T06:49:14  <jonasschnelli> okay.
 189 2016-09-22T06:49:26  <jonasschnelli> btcdrak: A nice! We have projects now.
 190 2016-09-22T06:49:28  <btcdrak> international standards for copyright is "belongs to author" by default unless employed by a company, then it belongs to the employer by default, unless there is a prior agreement. Licensing is not implicit however. You do need to be careful about code copied from other projects that have incompatible licenses. Since we use MIT that's generally not a problem
 191 2016-09-22T06:49:28  <btcdrak> since MIT is generally quite permissive and compatible with just about anything.
 192 2016-09-22T06:50:28  <cfields> jonasschnelli: note that if something is disabled (zmq for example), it'll just be blank, so skipped. No need to try to if/endif around them anymore
 193 2016-09-22T06:50:31  <btcdrak> But in any case, users should be told the terms of submitting patches is that they license their work as MIT or if there is another license attached, they state that, and it is up to us to accept or refuse the patch (for example if the license was incompatible with our distribution).
 194 2016-09-22T06:50:39  *** xinxi has quit IRC
 195 2016-09-22T06:50:45  <btcdrak> Contributing should have a line about this.
 196 2016-09-22T06:50:47  <jonasschnelli> cfields: okay
 197 2016-09-22T06:51:21  <wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/8786
 198 2016-09-22T06:52:37  *** jtimon has quit IRC
 199 2016-09-22T06:53:58  <cfields> jonasschnelli: sigh, sorry. I took a quick look at the failure and assumed it was the same problem. Obviously looking more closely, it's something different.
 200 2016-09-22T06:54:42  <jonasschnelli> cfields: ah.. okay. But the amount of missing symbols should also point out that the linking order is wrong.. not?
 201 2016-09-22T06:55:00  <cfields> jonasschnelli: yes, either busted link order or circular dependency
 202 2016-09-22T06:55:08  *** murch has joined #bitcoin-core-dev
 203 2016-09-22T07:05:37  *** rubensayshi has joined #bitcoin-core-dev
 204 2016-09-22T07:06:30  *** blaker has joined #bitcoin-core-dev
 205 2016-09-22T07:08:01  <murch> gmaxwell: Re "selecting by taint": I've always been discounting that because I wouldn't be able to discern change and target outputs. I wouldn't get the behavior of one wallet, but rather incoming and outgoing payments from different users. You just made me realize that this might still be a useful dataset. Thanks
 206 2016-09-22T07:08:05  <cfields> jonasschnelli: oh, i might know
 207 2016-09-22T07:09:48  <cfields> jonasschnelli: as a kludgy test, try adding a convenience lib for the tool, containing most of the functions. Move main() to a separate file, and have that be the only source listed for bitcoin_wallet_tool_SOURCES. Then add the convenience lib to bitcoin_wallet_tool_LDADD
 208 2016-09-22T07:10:24  <jonasschnelli> cfields: Okay. I'll try that.
 209 2016-09-22T07:10:35  <cfields> jonasschnelli: see bitcoind as an example
 210 2016-09-22T07:10:48  <phantomcircuit> jonasschnelli: any idea why we're asseting that locks are held instead of acquiring the lock in cwallet?
 211 2016-09-22T07:11:00  <phantomcircuit> the locks recursive so it should be fine to just acquire it again
 212 2016-09-22T07:11:16  <cfields> jonasschnelli: i can play around with it tomorrow (later) if it's still not working
 213 2016-09-22T07:11:31  <jonasschnelli> phantomcircuit: Is there no overhead in acquiring the lock again? Couple of CPU ticks consumed?
 214 2016-09-22T07:11:54  <jonasschnelli> cfields: Okay. I may try to play with it... but I guess I will fail. :) But no hurry
 215 2016-09-22T07:12:24  <cfields> jonasschnelli: you should know by now that telling me "no hurry" guarantees it will never happen :)
 216 2016-09-22T07:12:29  <phantomcircuit> wumpus: any idea if it costs more to acquire an already held lock than asserting the lock is held?
 217 2016-09-22T07:12:35  <jonasschnelli> cfields: hurry up then! :)
 218 2016-09-22T07:13:04  <wumpus> phantomcircuit: asserting that the lock is held is only enabled when log debugging is enabled, so that is the cheaper option
 219 2016-09-22T07:13:28  <wumpus> it's really a sanity assertion
 220 2016-09-22T07:13:47  <cfields> also, asserting means that you're not depending on the recursive lock and may be able to rip it out at some point :)
 221 2016-09-22T07:28:15  *** blaker has quit IRC
 222 2016-09-22T07:32:52  *** AaronvanW has joined #bitcoin-core-dev
 223 2016-09-22T07:33:19  *** AaronvanW has quit IRC
 224 2016-09-22T07:33:19  *** AaronvanW has joined #bitcoin-core-dev
 225 2016-09-22T07:39:07  *** MarcoFalke has joined #bitcoin-core-dev
 226 2016-09-22T07:39:45  *** xinxi_ has quit IRC
 227 2016-09-22T07:42:47  *** murch has quit IRC
 228 2016-09-22T07:47:51  *** assder has joined #bitcoin-core-dev
 229 2016-09-22T07:51:08  *** laurentmt has joined #bitcoin-core-dev
 230 2016-09-22T07:52:13  *** laurentmt has quit IRC
 231 2016-09-22T07:52:53  <gmaxwell> murch: it would be approximate for sure.
 232 2016-09-22T07:53:04  <gmaxwell> but I think worth analizing.
 233 2016-09-22T07:54:22  *** xinxi has joined #bitcoin-core-dev
 234 2016-09-22T07:56:10  *** xinxi has quit IRC
 235 2016-09-22T07:58:14  *** xinxi has joined #bitcoin-core-dev
 236 2016-09-22T07:59:31  *** xinxi has quit IRC
 237 2016-09-22T08:01:24  *** AaronvanW has quit IRC
 238 2016-09-22T08:04:46  <GitHub79> [bitcoin] jonasschnelli opened pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788
 239 2016-09-22T08:07:45  <phantomcircuit> wumpus: hmm
 240 2016-09-22T08:07:56  <phantomcircuit> how expensive is it to acquire a lock when you already have it?
 241 2016-09-22T08:08:03  <phantomcircuit> should just be a thread local check
 242 2016-09-22T08:10:13  <jonasschnelli> phantomcircuit: Is there a reason for re-acquiring the lock? Why not acquire the lock from the caller instead in the called function?
 243 2016-09-22T08:10:41  <jonasschnelli> But meh,.. depends on your layering.
 244 2016-09-22T08:15:11  <luke-jr> even if we have recursive locks in some places, it's still not a good idea to use it recursively :/
 245 2016-09-22T08:15:46  *** Yogh has quit IRC
 246 2016-09-22T08:16:41  *** Yogh has joined #bitcoin-core-dev
 247 2016-09-22T08:20:54  *** assder has quit IRC
 248 2016-09-22T08:20:55  *** xinxi has joined #bitcoin-core-dev
 249 2016-09-22T08:29:03  *** Bootvis has quit IRC
 250 2016-09-22T08:29:13  *** Bootvis has joined #bitcoin-core-dev
 251 2016-09-22T08:30:10  *** DigiByteDev has quit IRC
 252 2016-09-22T08:32:22  <luke-jr> jonasschnelli: your travis failed
 253 2016-09-22T08:32:44  <jonasschnelli> Luke-Jr: thanks... looking..
 254 2016-09-22T08:33:25  <jonasschnelli> It broke rest
 255 2016-09-22T08:34:01  <luke-jr> jonasschnelli: part of the reason I didn't like that approach FWIW, was that now we need to look up the user twice :p
 256 2016-09-22T08:34:32  <jonasschnelli> Luke-Jr: depends how you make the user<->wallet mapping..
 257 2016-09-22T08:34:48  <jonasschnelli> But I think user-wallet-mapping is a different thing then RPC auth
 258 2016-09-22T08:35:22  <jonasschnelli> But I would prefer selecting the wallet based on the endpoint or something within the RPC request
 259 2016-09-22T08:35:40  <jonasschnelli> Selecting based on the -rpcuser makes it relatively complex to setup
 260 2016-09-22T08:35:43  <luke-jr> even if we do so, most likely users should be restricted to only some wallet(s)
 261 2016-09-22T08:36:03  <jonasschnelli> We could still do this... but multiwallet is probably simpler then multiwallet-multiuser
 262 2016-09-22T08:36:13  <luke-jr> we already have multiuser :p
 263 2016-09-22T08:36:41  <jonasschnelli> Yes. I meant simpler to not do mutliuser-multiwallet in the first step
 264 2016-09-22T08:37:20  *** assder has joined #bitcoin-core-dev
 265 2016-09-22T08:37:21  <jonasschnelli> If we would select the wallet depending on the endpoint, we could just use something like bitcoin-cli --wallet=<walletid> getbalance
 266 2016-09-22T08:37:52  <jonasschnelli> where the bitcoin-cli tools would use --wallet=<walletid> to pass the request to /<walletid>
 267 2016-09-22T08:38:04  <luke-jr> can do it with mu-mw already today - plus the code for it is written already *shrug*
 268 2016-09-22T08:38:22  <jonasschnelli> Yes. But what if you want to wallet with a single user?
 269 2016-09-22T08:38:30  <jonasschnelli> How would you select?
 270 2016-09-22T08:38:37  <luke-jr> can't with the current implementation
 271 2016-09-22T08:38:39  <jonasschnelli> *want two
 272 2016-09-22T08:38:50  <luke-jr> doing that is more complicated IMO
 273 2016-09-22T08:39:06  <jonasschnelli> I think its the more obvious use case (single user, multiple wallet=
 274 2016-09-22T08:39:10  <luke-jr> I'm all for /?wallet=<walletid>, just don't think it's the ideal first-step
 275 2016-09-22T08:39:42  <luke-jr> since we already have multiuser and even with wallet-selection-by-endpoint would want to lock it down
 276 2016-09-22T08:39:43  <jonasschnelli> I'm also happy with /?wallet=<walleid> ... AFAIK it's simpler to parse /<walletid>
 277 2016-09-22T08:39:51  <jonasschnelli> or /wallet/<walletid>
 278 2016-09-22T08:40:37  <luke-jr> as I see it, endpoint wallet selection is an additional step beyond user permissions
 279 2016-09-22T08:41:21  <jonasschnelli> Yes. But I think we need to solve singleuser-multiwallet
 280 2016-09-22T08:41:36  <jonasschnelli> Either with ?wallet=<walletid> in request or /<walletid>
 281 2016-09-22T08:43:08  <btcdrak> luke-jr why ?wallet=
 282 2016-09-22T08:43:31  <luke-jr> btcdrak: doesn't step on REST stuff, and unlikely to conflict with future extensions
 283 2016-09-22T08:44:03  <btcdrak> well thats not how to build  REST interface
 284 2016-09-22T08:44:15  <jonasschnelli> REST does not support wallet
 285 2016-09-22T08:47:07  <btcdrak> query strings in REST are considered a very poor practice
 286 2016-09-22T08:48:23  <jonasschnelli> query-string are in the same HTTP element (path)
 287 2016-09-22T08:48:53  <jonasschnelli> Modern designs mostly use /<key>/<value> instead or ?<key>=<value>
 288 2016-09-22T08:49:01  <jonasschnelli> Parsing is simpler, browser support better AFAIK
 289 2016-09-22T08:53:58  *** midnightmagic has joined #bitcoin-core-dev
 290 2016-09-22T08:58:19  *** xinxi has quit IRC
 291 2016-09-22T08:58:24  <GitHub84> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7008e28136b5...26b370a93700
 292 2016-09-22T08:58:24  <GitHub84> bitcoin/master 482f852 Johnson Lau: Implement NULLDUMMY softfork
 293 2016-09-22T08:58:25  <GitHub84> bitcoin/master 26b370a Wladimir J. van der Laan: Merge #8636: Implement NULLDUMMY softfork (BIP147)...
 294 2016-09-22T08:58:34  <GitHub156> [bitcoin] laanwj closed pull request #8636: Implement NULLDUMMY softfork (BIP147) (master...nulldummy) https://github.com/bitcoin/bitcoin/pull/8636
 295 2016-09-22T08:59:22  *** xinxi has joined #bitcoin-core-dev
 296 2016-09-22T08:59:29  *** MarcoFalke has left #bitcoin-core-dev
 297 2016-09-22T09:06:29  *** xinxi has quit IRC
 298 2016-09-22T09:10:18  *** Guyver2 has joined #bitcoin-core-dev
 299 2016-09-22T09:12:34  <luke-jr> jonasschnelli: pretty sure that violates the URI RFCs :p
 300 2016-09-22T09:50:55  *** DigiByteDev has joined #bitcoin-core-dev
 301 2016-09-22T09:53:18  *** DigiByteDev has quit IRC
 302 2016-09-22T09:57:46  *** luke-jr has quit IRC
 303 2016-09-22T10:04:40  *** cryptapus has joined #bitcoin-core-dev
 304 2016-09-22T10:07:02  *** xinxi has joined #bitcoin-core-dev
 305 2016-09-22T10:08:11  *** MarcoFalke has joined #bitcoin-core-dev
 306 2016-09-22T10:14:01  *** xinxi has quit IRC
 307 2016-09-22T10:20:57  *** arowser has quit IRC
 308 2016-09-22T10:22:23  *** arowser has joined #bitcoin-core-dev
 309 2016-09-22T10:44:20  <GitHub101> [bitcoin] MarcoFalke opened pull request #8789: [qa] pull-tester: Only print output when failed (master...Mf1609-qaPrintFailedOnly) https://github.com/bitcoin/bitcoin/pull/8789
 310 2016-09-22T10:52:47  <GitHub35> [bitcoin] MarcoFalke opened pull request #8790: [test] Remove redundant debug print in addrman_tests (master...Mf1609-testsDeletePrint) https://github.com/bitcoin/bitcoin/pull/8790
 311 2016-09-22T10:55:30  *** luke-jr has joined #bitcoin-core-dev
 312 2016-09-22T10:56:01  <btcdrak> Reminder of last weeks' action points before meeting tonight: review #8634 and #8499 and #8526
 313 2016-09-22T11:00:26  *** xinxi has joined #bitcoin-core-dev
 314 2016-09-22T11:01:27  *** xinxi has quit IRC
 315 2016-09-22T11:01:46  *** randy-waterhouse has quit IRC
 316 2016-09-22T11:03:56  <GitHub99> [bitcoin] MarcoFalke opened pull request #8791: [travis] cross-mac: explicitly enable gui (master...Mf1609-travisGui) https://github.com/bitcoin/bitcoin/pull/8791
 317 2016-09-22T11:04:50  *** AaronvanW has joined #bitcoin-core-dev
 318 2016-09-22T11:05:50  *** xinxi has joined #bitcoin-core-dev
 319 2016-09-22T11:09:07  *** MarcoFalke has left #bitcoin-core-dev
 320 2016-09-22T11:28:38  *** JackH has joined #bitcoin-core-dev
 321 2016-09-22T11:29:23  *** assder has quit IRC
 322 2016-09-22T11:29:32  *** assder has joined #bitcoin-core-dev
 323 2016-09-22T11:49:25  *** cdecker has quit IRC
 324 2016-09-22T12:01:40  *** cdecker has joined #bitcoin-core-dev
 325 2016-09-22T12:16:17  *** murch has joined #bitcoin-core-dev
 326 2016-09-22T12:16:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 327 2016-09-22T12:16:56  <jonasschnelli> Luke-Jr: why would that violate the URI RFC?
 328 2016-09-22T12:17:15  <jonasschnelli> IMO something like /wallet/<walletid>/getbalance would be perfectly fine.
 329 2016-09-22T12:17:33  <jonasschnelli> though the method in the URI would be against JSONRPC
 330 2016-09-22T12:18:11  <jonasschnelli> but speaking JSONRPC against different URI endpoints looks after a feasible design
 331 2016-09-22T12:20:20  *** MrHodl has joined #bitcoin-core-dev
 332 2016-09-22T12:25:49  *** arowser has quit IRC
 333 2016-09-22T12:27:05  *** arowser has joined #bitcoin-core-dev
 334 2016-09-22T12:30:15  <wumpus> another day, another bunch of OpenSSL advisories https://www.openssl.org/news/secadv/20160922.txt
 335 2016-09-22T12:30:57  <jonasschnelli> *sigh*
 336 2016-09-22T12:31:03  <phantomcircuit> jonasschnelli: optimally cs_wallet would be private
 337 2016-09-22T12:31:14  <jonasschnelli> Happy that our p2p encryption plans and not based on SSL
 338 2016-09-22T12:31:22  <jonasschnelli> phantomcircuit: agree
 339 2016-09-22T12:31:41  <phantomcircuit> the only way for that to happen is for the public methods to acquire the lock
 340 2016-09-22T12:31:46  <jonasschnelli> I think its a bad design that cs_wallet can be (and will) accessed from the outside
 341 2016-09-22T12:31:53  <wumpus> yes, the lock should be private
 342 2016-09-22T12:33:28  <wumpus> "Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations." happy we use secp256k1 instead
 343 2016-09-22T12:34:04  *** Chris_Stewart_5 has quit IRC
 344 2016-09-22T12:37:28  <sipa> wumpus: note that this is about DSA, not ECDSA
 345 2016-09-22T12:37:47  <wumpus> oh that's a different code path? I don't know openssl internals
 346 2016-09-22T12:38:25  *** AaronvanW has quit IRC
 347 2016-09-22T12:38:54  <wumpus> I mean it's the same operation on a different group, but they probably made a parallel implementation, okay
 348 2016-09-22T12:40:51  <sipa> yeah, the ecdsa code is separate
 349 2016-09-22T12:40:52  <phantomcircuit> CWalletTx::InMempool
 350 2016-09-22T12:40:57  <phantomcircuit> wtf
 351 2016-09-22T12:41:19  <phantomcircuit> jonasschnelli: why
 352 2016-09-22T12:41:20  <phantomcircuit> WHYY
 353 2016-09-22T12:41:29  <wumpus> which doesn't mean they don't have the same bug there , just waiting to be found :)
 354 2016-09-22T12:41:33  <sipa> phantomcircuit: ?
 355 2016-09-22T12:41:56  <jonasschnelli> phantomcircuit: The current wallet logic need to know that
 356 2016-09-22T12:42:01  <phantomcircuit> sipa: abstraction violation to the max
 357 2016-09-22T12:42:06  <jonasschnelli> But I agree,... couping the wallet with the mempool is bad!
 358 2016-09-22T12:42:18  <wumpus> the wallet is allowed to communicate with the mempool in our case
 359 2016-09-22T12:42:33  <wumpus> this is used for some things such as showing conflicts
 360 2016-09-22T12:42:35  <sipa> phantomcircuit: we can't avoid that without breaking semantics
 361 2016-09-22T12:42:47  <wumpus> I mean: this is a full node wallet, you have the mempool information, why not use it
 362 2016-09-22T12:43:01  <sipa> it can be abstracted more cleanly (install a callback, etc), but functionally we need it, unfortunately
 363 2016-09-22T12:43:03  <jonasschnelli> Yes. But maybe not directly accessing the mempool object. :)
 364 2016-09-22T12:43:05  <wumpus> *the way* of communicating with the mempool may be wrong, that'sa another thing
 365 2016-09-22T12:43:11  <wumpus> right.
 366 2016-09-22T12:43:47  <jonasschnelli> We need to make this more flexible if we once like to have the hybrid SPV mode.
 367 2016-09-22T12:44:15  <jonasschnelli> Which is – sadly – probably far away from being implemented. :)
 368 2016-09-22T12:44:41  <sipa> we use the mempool as an estimation for whether a transaction may still confirm (and for example, refuse to spend unconfirmed output that is not in the mempool)
 369 2016-09-22T12:44:43  <wumpus> yes sure, it would need a fallback with the information missing . Like not show unconfirmed transactions at all.
 370 2016-09-22T12:45:18  <wumpus> that's essentially what is the case already during initial sync
 371 2016-09-22T12:47:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 372 2016-09-22T12:47:01  *** assder has quit IRC
 373 2016-09-22T12:47:02  *** AndChat|206976 has joined #bitcoin-core-dev
 374 2016-09-22T12:51:52  <wumpus> doesn't seem like any of the SSL issues are a serious problem for us
 375 2016-09-22T12:52:15  *** jnewbery has joined #bitcoin-core-dev
 376 2016-09-22T12:56:08  *** cryptapus_ has joined #bitcoin-core-dev
 377 2016-09-22T12:56:09  *** cryptapus_ has joined #bitcoin-core-dev
 378 2016-09-22T12:59:06  *** Chris_Stewart_5 has quit IRC
 379 2016-09-22T12:59:54  *** cryptapus has quit IRC
 380 2016-09-22T13:01:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 381 2016-09-22T13:02:17  *** cryptapus_ is now known as cryptapus
 382 2016-09-22T13:15:59  <wumpus> I guess "SSL_peek() hang on empty record (CVE-2016-6305)" can apply to qt's usage of SSL, then again, the server hanging the connection isn't really that interesting
 383 2016-09-22T13:20:41  *** Chris_Stewart_5 has quit IRC
 384 2016-09-22T13:22:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 385 2016-09-22T13:30:47  *** jl2012 has quit IRC
 386 2016-09-22T13:37:09  *** [Author] has quit IRC
 387 2016-09-22T13:41:12  *** [Author] has joined #bitcoin-core-dev
 388 2016-09-22T13:41:56  *** Giszmo has joined #bitcoin-core-dev
 389 2016-09-22T13:42:23  *** jl2012 has joined #bitcoin-core-dev
 390 2016-09-22T13:44:03  *** Chris_Stewart_5 has quit IRC
 391 2016-09-22T13:48:41  *** To7 has joined #bitcoin-core-dev
 392 2016-09-22T13:49:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 393 2016-09-22T13:52:48  *** xinxi has quit IRC
 394 2016-09-22T13:54:57  *** xinxi has joined #bitcoin-core-dev
 395 2016-09-22T14:04:24  *** cryptapus has quit IRC
 396 2016-09-22T14:04:44  *** cryptapus has joined #bitcoin-core-dev
 397 2016-09-22T14:04:45  *** cryptapus has joined #bitcoin-core-dev
 398 2016-09-22T14:14:31  *** xinxi has quit IRC
 399 2016-09-22T14:15:49  <GitHub97> [bitcoin] paveljanik opened pull request #8793: Do not shadow in src/qt (master...20160922_Wshadow_qt) https://github.com/bitcoin/bitcoin/pull/8793
 400 2016-09-22T14:16:33  *** xinxi has joined #bitcoin-core-dev
 401 2016-09-22T14:17:49  *** xinxi has quit IRC
 402 2016-09-22T14:28:31  *** xinxi has joined #bitcoin-core-dev
 403 2016-09-22T14:33:12  *** xinxi has quit IRC
 404 2016-09-22T14:41:27  <GitHub41> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26b370a93700...2b514aa2eae6
 405 2016-09-22T14:41:28  <GitHub41> bitcoin/master b5ccded instagibbs: Comment on CConnman::nLocalServices meaning
 406 2016-09-22T14:41:28  <GitHub41> bitcoin/master 2b514aa Wladimir J. van der Laan: Merge #8785: Comment on CNode::nLocalServices meaning...
 407 2016-09-22T14:41:44  <GitHub82> [bitcoin] laanwj closed pull request #8785: Comment on CNode::nLocalServices meaning (master...nlocalservisme) https://github.com/bitcoin/bitcoin/pull/8785
 408 2016-09-22T14:42:24  <GitHub168> [bitcoin] paveljanik opened pull request #8794: Enable -Wshadow by default (master...20160922_Wshadow_enable) https://github.com/bitcoin/bitcoin/pull/8794
 409 2016-09-22T14:43:41  *** jnewbery has quit IRC
 410 2016-09-22T14:44:18  *** jnewbery has joined #bitcoin-core-dev
 411 2016-09-22T14:44:33  *** AndChat|206976 has quit IRC
 412 2016-09-22T14:48:31  *** AaronvanW has joined #bitcoin-core-dev
 413 2016-09-22T14:48:39  *** jnewbery has quit IRC
 414 2016-09-22T14:48:58  *** AaronvanW has quit IRC
 415 2016-09-22T14:48:59  *** AaronvanW has joined #bitcoin-core-dev
 416 2016-09-22T14:53:53  *** Chris_Stewart_5 has quit IRC
 417 2016-09-22T15:00:21  <wumpus> it really should be possible to un-approve pulls, right after pushing submit on #8793 I realized the mistake I made
 418 2016-09-22T15:00:36  <wumpus> it's not even possible to *edit* the approval message
 419 2016-09-22T15:00:54  <paveljanik> I think this functionality is not ready yet...
 420 2016-09-22T15:01:13  <paveljanik> There is no Preview on the approval message etc.
 421 2016-09-22T15:01:47  <wumpus> right, it's more of a public beta
 422 2016-09-22T15:02:01  <wumpus> maybe I should just stop using 'approve'
 423 2016-09-22T15:02:29  <paveljanik> we are all "testing rabbits" - is it the same in English? ;-)
 424 2016-09-22T15:02:58  <achow101> I think you're looking for "lab rats"
 425 2016-09-22T15:03:18  <wumpus> in english it's guinea pigs
 426 2016-09-22T15:03:19  <wumpus> or that
 427 2016-09-22T15:03:44  <wumpus> in dutch it's "proefkonijnen", "testing rabbits"
 428 2016-09-22T15:04:13  <instagibbs> lab rats works in english too :) also easier to spell
 429 2016-09-22T15:05:39  <paveljanik> :-)
 430 2016-09-22T15:06:04  <bsm117532> I think of lab rats as grad students who do the experimentation.  Guinea pigs get experimented upon, as far as colloquial usage goes. ;-)
 431 2016-09-22T15:09:33  <GitHub162> [bitcoin] laudaa opened pull request #8795: [doc] Mention Gitian building script in documents. (master...master) https://github.com/bitcoin/bitcoin/pull/8795
 432 2016-09-22T15:10:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 433 2016-09-22T15:10:26  <wumpus> paveljanik: curious, almost all of the functions that are changes change in the binary
 434 2016-09-22T15:10:42  <wumpus> looking at WalletModel::WalletModel now
 435 2016-09-22T15:12:07  *** nickler has quit IRC
 436 2016-09-22T15:12:24  <paveljanik> interesting
 437 2016-09-22T15:13:00  <paveljanik> I still have to investigate's Marco's finding about reverselock's change changing the binary. It was only lock -> _lock...
 438 2016-09-22T15:13:32  <wumpus> looks like some ebp relative local variables change address, but I don't understand, it's really just a variable renaming
 439 2016-09-22T15:14:13  <paveljanik> but only in QT binary
 440 2016-09-22T15:14:18  <paveljanik> bitcoind untouched...
 441 2016-09-22T15:14:18  <wumpus> yes
 442 2016-09-22T15:14:30  <paveljanik> do we compile Qt somehow different?
 443 2016-09-22T15:14:49  <wumpus> I use the same build and comparison process that I use to cmpare bitcoind binaries
 444 2016-09-22T15:15:16  <wumpus> well qt has qrc passes
 445 2016-09-22T15:15:27  <wumpus> moc, I mean
 446 2016-09-22T15:16:00  <wumpus> which automatically generates some code for signal/slot dispatch, property setting, and such
 447 2016-09-22T15:16:10  <wumpus> that may be what happens here, I don't know
 448 2016-09-22T15:16:40  <wumpus> I'll check if this is restricted to consturctors
 449 2016-09-22T15:22:12  <wumpus> paveljanik: in the case of void WalletView::setClientModel(ClientModel *_clientModel)  I think I know why: you haven't changed the latter two statements to refer to the new parameter name
 450 2016-09-22T15:22:27  <wumpus> paveljanik: they now refer to the memner variable
 451 2016-09-22T15:22:38  <wumpus> member*
 452 2016-09-22T15:22:49  <wumpus> same for WalletView::setWalletModel
 453 2016-09-22T15:23:01  <wumpus> the otherwise-empty constructors remain a mystery though
 454 2016-09-22T15:24:00  <paveljanik> will fix both...
 455 2016-09-22T15:26:06  <wumpus> ok let me know when you pushed then I'll redo the binaries check
 456 2016-09-22T15:26:12  <paveljanik> done
 457 2016-09-22T15:28:20  <wumpus> building
 458 2016-09-22T15:29:33  <paveljanik> coffee ;-)
 459 2016-09-22T15:36:12  <wumpus> good idea
 460 2016-09-22T15:36:23  <sipa> just had one
 461 2016-09-22T15:37:22  <paveljanik> Kenya AA Top Superstar - macchiato :-)
 462 2016-09-22T15:39:31  *** xinxi has joined #bitcoin-core-dev
 463 2016-09-22T15:42:23  <wumpus> paveljanik: that worked, those two functions are gone from the list now - only constructors left
 464 2016-09-22T15:42:43  *** AaronvanW has quit IRC
 465 2016-09-22T15:43:43  <wumpus> I'll just say this is fine, I don't have time to investigate the assembly and data in detail now, and I don't think this can be avoided
 466 2016-09-22T15:44:44  *** jnewbery has joined #bitcoin-core-dev
 467 2016-09-22T15:47:51  <paveljanik> wumpus, yes, thanks for investigation!
 468 2016-09-22T15:50:40  *** jnewbery has quit IRC
 469 2016-09-22T15:51:31  <paveljanik> I'll double check the rest of the functions in the list
 470 2016-09-22T15:53:12  <paveljanik> Hmm, in WalletView::WalletView, I use platformStyle and not _ platformStyle...
 471 2016-09-22T15:54:05  *** jnewbery has joined #bitcoin-core-dev
 472 2016-09-22T15:54:19  <paveljanik> https://github.com/bitcoin/bitcoin/pull/8793/files#diff-0945de3e3345c5e5c9b39feef7843574R39
 473 2016-09-22T15:55:22  *** AaronvanW has joined #bitcoin-core-dev
 474 2016-09-22T15:55:50  *** AaronvanW has quit IRC
 475 2016-09-22T15:55:50  *** AaronvanW has joined #bitcoin-core-dev
 476 2016-09-22T15:56:17  *** laurentmt has joined #bitcoin-core-dev
 477 2016-09-22T15:56:28  *** laurentmt has quit IRC
 478 2016-09-22T16:00:07  <wumpus> paveljanik: yes, it looks like a similar thing
 479 2016-09-22T16:00:27  <wumpus> I've ruled out moc at least
 480 2016-09-22T16:00:42  <wumpus> compiled the file individually with gcc -S and still see the difference
 481 2016-09-22T16:04:00  <wumpus> paveljanik: this seems to make the differences in AddressBookPage::AddressBookPAge go away http://www.hastebin.com/jixoyufuxu.php
 482 2016-09-22T16:04:52  <paveljanik> I have to say I prefer the usage of member-initialized member variable to an argument in the body of the functions...
 483 2016-09-22T16:05:03  <wumpus> yes, I don't think it's an improvement
 484 2016-09-22T16:05:08  <wumpus> let's just leave it at this
 485 2016-09-22T16:05:10  <wumpus> it's explained
 486 2016-09-22T16:05:32  <paveljanik> well, but this means that binaries will be different :-(
 487 2016-09-22T16:06:06  <wumpus> yes, but we are capable of creating a patch that won't change the binaries, it's just ugly
 488 2016-09-22T16:06:18  <wumpus> +larger
 489 2016-09-22T16:06:49  <paveljanik> but its correct (QED)
 490 2016-09-22T16:07:08  <sipa> i think having a patch available to removes the differences is enough
 491 2016-09-22T16:07:19  <sipa> the changes are trivial anyway
 492 2016-09-22T16:07:22  <wumpus> well I've also reviewed the changes and they look ok, this is just qt anyhow and not consensus code
 493 2016-09-22T16:07:28  <wumpus> right sipa
 494 2016-09-22T16:07:33  <paveljanik> yup
 495 2016-09-22T16:11:34  *** rubensayshi has quit IRC
 496 2016-09-22T16:13:45  *** bsm117532 has quit IRC
 497 2016-09-22T16:14:14  *** bsm117532 has joined #bitcoin-core-dev
 498 2016-09-22T16:20:00  <JackH> Is there any reason to think that Bitcoin wont eventually be taken over in terms of usage by Ethereum (serious question)
 499 2016-09-22T16:20:42  <JackH> Since it seems as if it has become the darling of the current payments industry, despite its failures. The "best" or most "safe" solution does not always take the prize
 500 2016-09-22T16:21:12  <JackH> I am just thinking in terms of opening up Bitcoin, beside fixing malleability, if there is anything on the table?
 501 2016-09-22T16:21:49  <wumpus> #bitcoin
 502 2016-09-22T16:22:42  <JackH> #futureofbitcoin in here? (conceptually)
 503 2016-09-22T16:22:48  <JackH> ah shit
 504 2016-09-22T16:22:50  <JackH> I am not in wizards
 505 2016-09-22T16:22:53  <JackH> sorry
 506 2016-09-22T16:23:15  <JackH> this is akward...
 507 2016-09-22T16:23:20  <wumpus> wizards is about cryptography and moonmath, it's also not the place to discuss comparison to altcoins
 508 2016-09-22T16:29:35  *** AaronvanW has quit IRC
 509 2016-09-22T16:30:53  *** AaronvanW has joined #bitcoin-core-dev
 510 2016-09-22T16:31:20  *** AaronvanW has quit IRC
 511 2016-09-22T16:31:20  *** AaronvanW has joined #bitcoin-core-dev
 512 2016-09-22T16:34:09  *** Guyver2 has quit IRC
 513 2016-09-22T16:34:21  *** Guyver2 has joined #bitcoin-core-dev
 514 2016-09-22T16:34:24  *** jnewbery has quit IRC
 515 2016-09-22T16:48:03  *** xinxi has quit IRC
 516 2016-09-22T17:10:21  *** nickler has joined #bitcoin-core-dev
 517 2016-09-22T17:13:55  *** AaronvanW has quit IRC
 518 2016-09-22T17:22:41  *** achow101 has quit IRC
 519 2016-09-22T17:23:55  <haakonn> JackH:  eth is the darling of the "blockchain industry", not the payments industry (what can you pay for with ethers?)
 520 2016-09-22T17:24:19  <haakonn> agh, sorry for the noise, thought this was #bitcoin
 521 2016-09-22T17:26:06  <helo> you had me convinced :P
 522 2016-09-22T17:26:19  *** jtimon has joined #bitcoin-core-dev
 523 2016-09-22T17:29:01  *** MarcoFalke has joined #bitcoin-core-dev
 524 2016-09-22T17:35:14  *** jnewbery has joined #bitcoin-core-dev
 525 2016-09-22T17:36:12  *** achow101 has joined #bitcoin-core-dev
 526 2016-09-22T17:43:39  *** MarcoFalke has quit IRC
 527 2016-09-22T17:49:52  <instagibbs> when running make check is there a way to get a stack trace on failure
 528 2016-09-22T17:50:34  <instagibbs> error is happening in some helper function, and no useful info about when it's happening
 529 2016-09-22T17:52:01  *** jnewbery has quit IRC
 530 2016-09-22T17:52:14  *** jnewbery has joined #bitcoin-core-dev
 531 2016-09-22T17:54:56  <GitHub197> [bitcoin] jonnynewbs opened pull request #8796: [trivial] fix mempool comment (outdated by BIP125) (master...trivial_comment) https://github.com/bitcoin/bitcoin/pull/8796
 532 2016-09-22T17:59:00  *** jtimon has quit IRC
 533 2016-09-22T17:59:51  <btcdrak> meeting time?
 534 2016-09-22T18:00:01  <instagibbs> in an hour?
 535 2016-09-22T18:00:04  <achow101> you're an hour early
 536 2016-09-22T18:00:18  <btcdrak> oh woops
 537 2016-09-22T18:13:22  *** achow101 has quit IRC
 538 2016-09-22T18:16:23  *** stan_ has joined #bitcoin-core-dev
 539 2016-09-22T18:18:40  *** achow101 has joined #bitcoin-core-dev
 540 2016-09-22T18:25:53  *** Yogh has quit IRC
 541 2016-09-22T18:27:37  *** Yogh has joined #bitcoin-core-dev
 542 2016-09-22T18:36:33  *** gabridome has joined #bitcoin-core-dev
 543 2016-09-22T18:45:18  *** jcorgan has joined #bitcoin-core-dev
 544 2016-09-22T18:48:04  *** CIS has joined #bitcoin-core-dev
 545 2016-09-22T18:48:41  *** CIS has joined #bitcoin-core-dev
 546 2016-09-22T18:52:37  *** CIS is now known as cis
 547 2016-09-22T18:53:52  *** gabridome has quit IRC
 548 2016-09-22T18:58:20  <kanzure> btcdrak: i propose we deprecate timezones
 549 2016-09-22T18:58:46  <jcorgan> and DST
 550 2016-09-22T18:58:56  <btcdrak> yes
 551 2016-09-22T18:58:58  <achow101> kanzure: ask IANA
 552 2016-09-22T18:59:00  <murch> kanzure: Yes, let's all just use UTC all year long.
 553 2016-09-22T18:59:12  <btcdrak> achow101: more like ask Trump
 554 2016-09-22T18:59:24  <achow101> Hah!
 555 2016-09-22T18:59:25  <gmaxwell> shh.
 556 2016-09-22T18:59:30  <sipa> murch: another thing we should learn from icelanders
 557 2016-09-22T18:59:39  <cfields> here for meeting, but dog's pacing at the door. Back in ~5.
 558 2016-09-22T18:59:43  <gmaxwell> Don't start a big OT discussion right before the meeting.
 559 2016-09-22T18:59:48  <wumpus> #startmeeting
 560 2016-09-22T18:59:48  <lightningbot> Meeting started Thu Sep 22 18:59:48 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 561 2016-09-22T18:59:48  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 562 2016-09-22T18:59:54  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
 563 2016-09-22T18:59:55  <CodeShark> Here
 564 2016-09-22T18:59:58  <jonasschnelli> here
 565 2016-09-22T19:00:04  <btcdrak> jl2012 ping
 566 2016-09-22T19:00:11  <murch> hello
 567 2016-09-22T19:00:15  <sipa> pyng
 568 2016-09-22T19:00:17  <kanzure> hi.
 569 2016-09-22T19:00:21  <sdaftuar> hi
 570 2016-09-22T19:00:22  <wumpus> jl2012 probably won't be here this meeting
 571 2016-09-22T19:00:22  <paveljanik> peng
 572 2016-09-22T19:00:53  <michagogo> May show up in a bit - at dinner with my grandmother atm
 573 2016-09-22T19:00:54  <btcdrak> 01110000 01101001 01101110 01100111
 574 2016-09-22T19:01:06  <gmaxwell> our meeting is at an unfriendly time for our contributors in asia/au/nz/etc. Alas.
 575 2016-09-22T19:01:10  <wumpus> <jl2012> I may not join the meeting today but I suggest not to do https://github.com/bitcoin/bitcoin/pull/8654 in 0.13.1
 576 2016-09-22T19:01:10  <wumpus> <jl2012> It seems the risks is too much comparing with the benefit
 577 2016-09-22T19:01:52  <wumpus> yes what ever time you pick it's always unfriendly to someone
 578 2016-09-22T19:01:54  <btcdrak> I was discussing this with him yesterday. I also think it should be dropped.
 579 2016-09-22T19:02:38  <btcdrak> wumpus: we should find a time that is unfriendly to everyone :)
 580 2016-09-22T19:02:56  <wumpus> #topic Drop reuse sighash computations across evaluation  #8654 from 0.13.1?
 581 2016-09-22T19:02:58  <gmaxwell> wumpus: wasn't a complaint, just reminding people of it. :) (and we can all make an effort to stand in for people who can't make it)
 582 2016-09-22T19:03:26  <wumpus> gmaxwell: something else we could do is have e.g. alternating times every week
 583 2016-09-22T19:03:48  <sipa> yes, i'm in favor of dropping it. i believed the advantages were larger first
 584 2016-09-22T19:03:49  <wumpus> but given that people already have a hard time being there intime for a meeting with a fixed time... :-)
 585 2016-09-22T19:04:03  <sipa> but it seems we'll need more changes anyway than we can tolerate for 0.13.1
 586 2016-09-22T19:04:07  *** yep5555 has joined #bitcoin-core-dev
 587 2016-09-22T19:04:07  <gmaxwell> So re: that PR. We can do it later. We've survived thus far without it.
 588 2016-09-22T19:04:13  <btcdrak> yes.
 589 2016-09-22T19:04:16  <wumpus> ok
 590 2016-09-22T19:04:38  <wumpus> removing 0.13.1 milestone from it
 591 2016-09-22T19:04:55  <petertodd> how much worse is the maximum O(n^2) time for segwit? my understanding is that w/o segwit in theory even dozens of minutes are possible anyway
 592 2016-09-22T19:05:12  *** jtimon has joined #bitcoin-core-dev
 593 2016-09-22T19:05:19  <sipa> petertodd: the same
 594 2016-09-22T19:05:23  *** Alina-malina is now known as Samsepiol
 595 2016-09-22T19:05:39  *** Samsepiol is now known as Alina-malina
 596 2016-09-22T19:05:43  <petertodd> sipa: but can't you get more checksig ops w/ segwit?
 597 2016-09-22T19:05:45  <sipa> petertodd: as segwit inputs only hash the entire transaction at most once
 598 2016-09-22T19:05:57  <sipa> see bip143
 599 2016-09-22T19:06:02  <gmaxwell> petertodd: IIRC. this change is primarily fixing the non-segwit case. The plain hashcache in segwit already optimizes segwit so its basically solved under segwit.
 600 2016-09-22T19:06:23  <jtimon> hi
 601 2016-09-22T19:06:57  <sipa> petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block
 602 2016-09-22T19:07:04  <gmaxwell> so the non-segwit cases are the worst case, but we have determined that exploiting some additional caching oppturnities radically reduces that worst case when coupled with a few inconsequential additional limits.
 603 2016-09-22T19:07:06  <petertodd> gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior
 604 2016-09-22T19:07:22  <sipa> petertodd: all sighashing is changed in segwit
 605 2016-09-22T19:07:24  <petertodd> alright, I'm ACK to remove that for 0.13.1
 606 2016-09-22T19:07:33  <wumpus> great
 607 2016-09-22T19:07:39  <petertodd> sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :)
 608 2016-09-22T19:07:48  *** laurentmt has joined #bitcoin-core-dev
 609 2016-09-22T19:08:09  <gmaxwell> petertodd: right but the reason segwit doesn't have the n^2 blowup anymore is the general change so that the hashing work across inputs can be shared.
 610 2016-09-22T19:08:14  <sipa> petertodd: hmm? they're all changed in a very similar way, with the whole-transaction parts precomputed rather than inlined
 611 2016-09-22T19:09:10  *** jnewbery has quit IRC
 612 2016-09-22T19:09:15  <achow101> are #8634 and #8499 and #8526 ready for merge?
 613 2016-09-22T19:09:34  <wumpus> that's a new topic proposal achow101?
 614 2016-09-22T19:09:58  <achow101> just a question
 615 2016-09-22T19:10:00  <gmaxwell> related topic at least.
 616 2016-09-22T19:10:28  <btcdrak> well they were part of last week's homework
 617 2016-09-22T19:10:34  <wumpus> Add policy: null signature for failed CHECK(MULTI)SIG https://github.com/bitcoin/bitcoin/pull/8634
 618 2016-09-22T19:10:54  <wumpus> Check bad witness and implement several policy limits for segwit scripts https://github.com/bitcoin/bitcoin/pull/8499
 619 2016-09-22T19:11:19  <wumpus> Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH https://github.com/bitcoin/bitcoin/pull/8526
 620 2016-09-22T19:11:43  <CodeShark> The first and last commits for 8634 should be squashed together, have only done limited testing, but the code changes look good
 621 2016-09-22T19:12:20  <CodeShark> Still reviewing 8499
 622 2016-09-22T19:13:28  <wumpus> ok, anyone else with opinion about those pulls?
 623 2016-09-22T19:13:43  *** jnewbery has joined #bitcoin-core-dev
 624 2016-09-22T19:14:47  <gmaxwell> 8634 needs a squash. LGTM.
 625 2016-09-22T19:14:56  <sipa> 8499 is a blocker for 0.13.1 for sure
 626 2016-09-22T19:15:02  <achow101> wasn't it decided that 8393 was ready, or just about ready
 627 2016-09-22T19:15:04  <sdaftuar> fyi i'm just starting my review of 8499 now
 628 2016-09-22T19:15:06  <wumpus> looks like #8634 has quite a lot of (u)tACKs
 629 2016-09-22T19:15:30  <sdaftuar> (but don't let me hold thigns up!)
 630 2016-09-22T19:16:19  <wumpus> #action merge #8634 after squashing
 631 2016-09-22T19:16:35  <wumpus> 8499 is still very much in progress
 632 2016-09-22T19:17:18  <instagibbs> 8393 isn't that hard to review but only a couple people have given acks
 633 2016-09-22T19:17:44  <gmaxwell> reminder on milestone 22, https://github.com/bitcoin/bitcoin/milestone/22  (and if there are 0.13 things in that, which aren't tagged, make sure they get tagged)
 634 2016-09-22T19:19:56  <sipa> i'll address the latest nits in 8393
 635 2016-09-22T19:20:00  <wumpus> so anything between those that is ready for merge?
 636 2016-09-22T19:20:37  *** laurentmt has quit IRC
 637 2016-09-22T19:20:43  <btcdrak> We need a few more acks on 8526 but it looks harmless enough as is.
 638 2016-09-22T19:21:23  <wumpus> there seems to be disagreement on the RPC behavior change in Fix issue with conflicted mempool tx in listsinceblock https://github.com/bitcoin/bitcoin/pull/8757
 639 2016-09-22T19:21:35  <wumpus> this probably means it should be untagged for 0.13.1
 640 2016-09-22T19:21:38  <btcdrak> sipa: I think there are a couple of niggles on the BIP also https://github.com/bitcoin/bips/pull/423
 641 2016-09-22T19:21:47  <jonasschnelli> Yes. No need for 0.13.1
 642 2016-09-22T19:21:57  <sipa> btcdrak: yes, i'm aware
 643 2016-09-22T19:22:17  <wumpus> jonasschnelli: right, if we do that it should be something documented in the release notes of a major release
 644 2016-09-22T19:22:23  <jonasschnelli> ack
 645 2016-09-22T19:22:41  <jonasschnelli> People probably built apps on the "strange" listsinceblock behavior.
 646 2016-09-22T19:22:48  <wumpus> exactly
 647 2016-09-22T19:22:53  *** gabridome has joined #bitcoin-core-dev
 648 2016-09-22T19:23:12  <jonasschnelli> remved the 0.13.1 ms from 8757
 649 2016-09-22T19:23:17  <wumpus> okay that leaves four to go
 650 2016-09-22T19:23:27  <BlueMatt> wumpus: wait, we're unmarking compact blocks for 0.13.1?
 651 2016-09-22T19:23:32  <BlueMatt> (you just did)
 652 2016-09-22T19:23:32  <gmaxwell> re the listsince blocks The complaint is that conflicts are always shown and the proposed change made them never shown?
 653 2016-09-22T19:23:34  <btcdrak> regarding segwitcb, roasbeef's scripts are running spamming testnet. If there are any miners pointing hash at testnet, can they set "-blockmaxweight=4000000", leaving off any other related params so we get more bigger blocks.
 654 2016-09-22T19:23:43  <wumpus> BlueMatt: uh
 655 2016-09-22T19:23:47  <gmaxwell> BlueMatt: wat?
 656 2016-09-22T19:23:54  <BlueMatt> @laanwj laanwj removed this from the 0.13.1 milestone a minute ago
 657 2016-09-22T19:23:55  <instagibbs> er did someone remove the segwit cb?
 658 2016-09-22T19:23:56  <wumpus> that was a mistake
 659 2016-09-22T19:23:57  <BlueMatt> I assume that was accidental
 660 2016-09-22T19:24:00  <wumpus> please readd
 661 2016-09-22T19:24:05  <BlueMatt> #8393
 662 2016-09-22T19:24:15  <gmaxwell> unclick
 663 2016-09-22T19:24:27  <BlueMatt> ok, so 5 to go
 664 2016-09-22T19:24:32  <jonasschnelli> readded
 665 2016-09-22T19:24:47  <instagibbs> 4 PRs, one related issue
 666 2016-09-22T19:24:52  <sipa> you take one down, pass it around, 5 PR to g
 667 2016-09-22T19:25:19  * BlueMatt is not sure how to feel about #8526...it'll surely end up merged onto master before segwit activates...agree its nice to have things "clean from the start", but do we define clean as policy in 0.13.1 or policy on master/0.14?
 668 2016-09-22T19:25:20  <Chris_Stewart_5> exponential PR blow up
 669 2016-09-22T19:25:22  <btcdrak> There is also this nice project https://github.com/bitcoin/bitcoin/projects/5
 670 2016-09-22T19:25:26  <gmaxwell> if you just want the percentage to go up, feel free to add tags to closed prs that got backported but were never tagged 0.13.1... There are many. :P
 671 2016-09-22T19:26:13  <wumpus> yes good point btcdrak PSA: I've started using the new feature of github projects for tracking a few longer-running projects: https://github.com/bitcoin/bitcoin/projects
 672 2016-09-22T19:26:14  <BlueMatt> same with 8634
 673 2016-09-22T19:26:55  <paveljanik> wumpus, nice!
 674 2016-09-22T19:27:08  <BlueMatt> or, really, what about ignoring #8634 and #8526 and going to solicit feedback for segwit dates after the other ones are in, and then if they make it in before we get date consensus, then they go in, otherwise no
 675 2016-09-22T19:27:13  <gmaxwell> minor meta aside, is there any facility for backing up and retaining all this new github stuff?
 676 2016-09-22T19:27:33  <BlueMatt> gmaxwell: havent looked, but the github api has historically been very, very complete
 677 2016-09-22T19:27:39  <BlueMatt> so i ass-u-me so?
 678 2016-09-22T19:27:42  <wumpus> gmaxwell: that's iwilcox's department (but he's not here)
 679 2016-09-22T19:28:17  <wumpus> but yes I guess it's available on the API if you know where to look, or it will become available, as BlueMatt says
 680 2016-09-22T19:28:21  <gmaxwell> BlueMatt: 8526 when it goes SF could plausably conficate coins, so it's more important to have it non-standard from the getgo.
 681 2016-09-22T19:28:53  <gmaxwell> and 8634 is done but for a squash as far as I can tell.
 682 2016-09-22T19:29:24  <wumpus> already created an action for #8634, we're repeating ourselves
 683 2016-09-22T19:29:26  <BlueMatt> gmaxwell: I'm not sold on it needing to be in anything but master before release, but, ok, in any case, i'd propose we start looking for date-consensus after #8279 and #8499 are in
 684 2016-09-22T19:29:26  <btcdrak> gmaxwell: the github API supports all this new stuff https://developer.github.com/v3/repos/projects/
 685 2016-09-22T19:29:44  *** Chris_St1 has joined #bitcoin-core-dev
 686 2016-09-22T19:29:45  <BlueMatt> (ie lets start looking for date consensus like...soon)
 687 2016-09-22T19:29:55  <achow101> like.. now?
 688 2016-09-22T19:30:01  <sipa> no, not now
 689 2016-09-22T19:30:05  <instagibbs> achow101: no, after critical updates are merged
 690 2016-09-22T19:30:11  <sipa> first know when we can possibly have a release
 691 2016-09-22T19:30:14  <BlueMatt> like...in a few days after the non-critical ones are merged
 692 2016-09-22T19:30:14  <btcdrak> BlueMatt: well we need #8393 merged too before we can be sure to set dates
 693 2016-09-22T19:30:37  <BlueMatt> btcdrak: sure, fine, #8393, #8279, and #8499, then dates?
 694 2016-09-22T19:30:50  <btcdrak> ack
 695 2016-09-22T19:30:55  <sdaftuar> i believe 8279 is sufficiently resolved for 0.13.1
 696 2016-09-22T19:31:11  <wumpus> let's try to finish those pulls this week then we can talk about the release next meeting
 697 2016-09-22T19:31:11  <gmaxwell> BlueMatt: do we know what the status of btcd's SW support is?
 698 2016-09-22T19:31:22  <BlueMatt> gmaxwell: thats part of soliciting consensus on dates :p
 699 2016-09-22T19:31:24  <btcdrak> ping roasbeef
 700 2016-09-22T19:31:30  <BlueMatt> (ie reaching out to non-bitcoin core people)
 701 2016-09-22T19:31:46  <gmaxwell> BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs.
 702 2016-09-22T19:31:46  <instagibbs> wumpus: ack
 703 2016-09-22T19:32:02  <wumpus> sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it
 704 2016-09-22T19:32:12  <sdaftuar> wumpus: sounds good to me
 705 2016-09-22T19:32:17  *** Chris_Stewart_5 has quit IRC
 706 2016-09-22T19:32:28  <sipa> wumpus: sounds good
 707 2016-09-22T19:32:55  <gmaxwell> btcd is the only active alt implementation that I'm aware of that didn't respond to my "when do you think you'll work on this" with a "only after it's locked in on the network".
 708 2016-09-22T19:34:59  <gmaxwell> BlueMatt: in any case, out of meeting lets try to work on a list of required actions for the activation.
 709 2016-09-22T19:35:13  <wumpus> makes sense to reach out to them then
 710 2016-09-22T19:35:21  <btcdrak> well in terms of wallet code and supporting libraries, there are many which are SW ready, or have it almost ready to go.
 711 2016-09-22T19:35:33  <gmaxwell> yes.
 712 2016-09-22T19:35:34  <petertodd> python-bitcoinlib has a fairly good pull-req for segwit
 713 2016-09-22T19:35:45  <wumpus> awesome
 714 2016-09-22T19:36:08  <gmaxwell> mining software was in a sad state last time I checked, but I know things have improved a lot.
 715 2016-09-22T19:37:03  <gmaxwell> in any case, many things to discuss there that don't need everyone. :)
 716 2016-09-22T19:37:07  <roasbeef> will be starting to finalize my segwit stuff for btcd starting tomorrow, have been busy with lightning stuff and getting btcd up-to-date with past recent soft-forks (CSV, etc)
 717 2016-09-22T19:37:32  <petertodd> roasbeef: +1
 718 2016-09-22T19:37:33  *** JackH has quit IRC
 719 2016-09-22T19:37:34  <roasbeef> primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff
 720 2016-09-22T19:37:36  <gmaxwell> roasbeef: fantastic.
 721 2016-09-22T19:38:00  <cfields> i keep meaning to return to patching miners but getting distracted. Feel free to ponk me if there's some mining software that actually gets used that needs to be updated.
 722 2016-09-22T19:39:15  <achow101> armory is.. getting there. We're aiming for the release after the next to have full segwit support
 723 2016-09-22T19:39:44  <petertodd> achow101: thanks!
 724 2016-09-22T19:39:47  <gmaxwell> achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing.
 725 2016-09-22T19:40:03  <btcdrak> oh I didnt know you work on Armory achow101 +1
 726 2016-09-22T19:40:22  <CodeShark> my stuff is almost 100% segwit ready, just need merkle proofs for witnesses in filtered blocks or some better SPV solution
 727 2016-09-22T19:40:27  *** luke-jr has quit IRC
 728 2016-09-22T19:40:47  <petertodd> gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :)
 729 2016-09-22T19:40:57  <gmaxwell> It's just good to hear that more things are almost read, as it's another angle of testing.
 730 2016-09-22T19:41:25  <Chris_St1> CodeShark: What BIP is that related to?
 731 2016-09-22T19:41:50  <CodeShark> We don't have a BIP yet, I don't think
 732 2016-09-22T19:41:52  <sipa> Chris_St1: that will need a new bip
 733 2016-09-22T19:42:26  <sipa> it's trivial (just combine bip37 with bip141 wtxids)
 734 2016-09-22T19:42:32  <Chris_St1> ok, gotcha.
 735 2016-09-22T19:42:34  <gmaxwell> Chris_St1: he wants something like the filtered block messages that provide witnesses too. (the opposite of what most SPV wallets do, but codeshark extracts participant data from witnesses)
 736 2016-09-22T19:42:49  <sipa> but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further
 737 2016-09-22T19:43:12  <CodeShark> I'd prefer a replacement to bip37, but that's more involved
 738 2016-09-22T19:43:14  <Chris_St1> BIP37 is definitely a monster in terms of implementation... or atleast it was for me
 739 2016-09-22T19:43:14  <gmaxwell> We could probably do better.
 740 2016-09-22T19:43:55  <sipa> at least we could propose to drop some of the auto-inserting that causes false positive rate blowup
 741 2016-09-22T19:43:56  <petertodd> note that it's reasonable to ask for a full block even if you are a lite-client in many cases
 742 2016-09-22T19:44:28  <BlueMatt> CodeShark: uhhhhhhhhh, that sounds like a blocker
 743 2016-09-22T19:44:32  <gmaxwell> petertodd: Satoshi's vision.
 744 2016-09-22T19:44:34  <btcdrak> petertodd: such as?
 745 2016-09-22T19:44:49  <jtimon> I guess he means as a way to get more privacy?
 746 2016-09-22T19:44:53  <sipa> BlueMatt: how so?
 747 2016-09-22T19:45:02  *** luke-jr has joined #bitcoin-core-dev
 748 2016-09-22T19:45:05  <BlueMatt> it seems to me it is impossible to use the bloom-filtered connection stuff in segwit....I mean we can decide to not support it because its bad, but we need to actively decide that
 749 2016-09-22T19:45:06  <petertodd> no, I just mean that the data increase is relatively low
 750 2016-09-22T19:45:07  <gmaxwell> BlueMatt: wut? hell no. I am aware of no other SPV client than codeshark's that does _anything_ with the witness data right now.
 751 2016-09-22T19:45:07  <jtimon> no tevealing which txs you care about? just thinking out loud...
 752 2016-09-22T19:45:22  <sipa> BlueMatt: spv wallets shouldn't care about the witness data
 753 2016-09-22T19:45:55  <sipa> hell, it's an advantage that their bandwidth will drop
 754 2016-09-22T19:45:57  <petertodd> sipa: indeed, they can't verify that the witness is valid
 755 2016-09-22T19:46:09  <gmaxwell> BlueMatt: it works fine, you just don't get witnesses, which is an intentional and desirable outcome thats actually listed on the segwit advantage sheets. For the most part they can't do anything with the data.
 756 2016-09-22T19:46:09  <CodeShark> wallets that don't tell you who signed a multisig are incomplete ;)
 757 2016-09-22T19:46:34  <gmaxwell> There should be some option for those who want it, sure. Though they can also fetch the whole block, so its not a big deal even there.
 758 2016-09-22T19:46:37  <petertodd> CodeShark: well, that's an example where you can request a full block - not many wallets need to actually know that
 759 2016-09-22T19:46:53  <petertodd> CodeShark: as an example, I don't think GreenAddress will tell you who actually signed txs in a GA wallet
 760 2016-09-22T19:47:12  <CodeShark> it's critical for enterprise applications
 761 2016-09-22T19:47:20  <CodeShark> Accountability is important
 762 2016-09-22T19:47:22  <petertodd> CodeShark: enterprise can afford some extra bandwidth I'm sure :)
 763 2016-09-22T19:47:29  <achow101> I think we're getting OT
 764 2016-09-22T19:47:32  <petertodd> CodeShark: this isn't a blocker is all I'm saying
 765 2016-09-22T19:47:45  <CodeShark> we can revisit this after 0.13.1
 766 2016-09-22T19:47:48  <gmaxwell> It's also not news or an accident.
 767 2016-09-22T19:48:00  <wumpus> no one is considering it is a blocker except for BlueMatt
 768 2016-09-22T19:48:03  <petertodd> CodeShark: ack
 769 2016-09-22T19:48:28  <BlueMatt> gmaxwell: sure, I'm saying that you cant use segwit as an spv client
 770 2016-09-22T19:48:36  <sipa> BlueMatt: of course you can?
 771 2016-09-22T19:48:38  <gmaxwell> BlueMatt: thats not true.
 772 2016-09-22T19:49:00  <petertodd> BlueMatt: note how with segwit, your txids aren't malleable, therefore you can add the txids of outputs in your wallet to your bloom filter and be sure you'll know if they get spent
 773 2016-09-22T19:49:05  <BlueMatt> gmaxwell: however, in cases like a scripthash, you previously are able to see things that were to your public, or partially to your pubkey
 774 2016-09-22T19:49:08  <BlueMatt> which you might want to
 775 2016-09-22T19:49:21  <BlueMatt> petertodd: you already do that, the malleability doesnt help
 776 2016-09-22T19:49:31  <Chris_St1> May be a stupid question, but are we refering to 'blocker' in the context of blocking 0.13.1 or downloading a full block?
 777 2016-09-22T19:49:36  * BlueMatt isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that
 778 2016-09-22T19:49:38  <petertodd> BlueMatt: true, once confirmed
 779 2016-09-22T19:49:52  <wumpus> Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1
 780 2016-09-22T19:49:52  <jtimon> Chris_St1: the former
 781 2016-09-22T19:49:53  <petertodd> BlueMatt: I take back that comment
 782 2016-09-22T19:50:21  <petertodd> anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1
 783 2016-09-22T19:50:24  <gmaxwell> BlueMatt: I carefully went through the code base of some three different wallets to confirm there were no complications there.  Of course, it also does nothing to _existing_ software.
 784 2016-09-22T19:50:48  <BlueMatt> gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to
 785 2016-09-22T19:51:03  <sipa> i think there was no reason for that, indeed
 786 2016-09-22T19:51:07  <BlueMatt> but it is the case that you lose this property of matching pubkeys which were used
 787 2016-09-22T19:51:10  <sipa> and if there is, we can still add it back
 788 2016-09-22T19:51:17  <BlueMatt> sipa: well, you might want it, but not a ton
 789 2016-09-22T19:51:19  <gmaxwell> which all works fine. And so even where there are things that want that data (which appear to be almost none of them), they can be accomidated later. The most common case (of not needing it) is already accomidated. And all existing things are unchanged as well.
 790 2016-09-22T19:51:21  <petertodd> I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority
 791 2016-09-22T19:51:23  <wumpus> at this point we should be careful to only let critical problems block 0.13.1, not everything that would be nice for some applications
 792 2016-09-22T19:51:36  <Chris_St1> BlueMatt: Matching scriptSig constants in BIP37 right?
 793 2016-09-22T19:51:44  *** cryptapus has quit IRC
 794 2016-09-22T19:52:00  <BlueMatt> wumpus: well, if it were the case that you couldnt match properly in segwit it would be bad, but it seems that you're fine
 795 2016-09-22T19:52:01  <wumpus> BIP37 can be extended, sure
 796 2016-09-22T19:52:17  <BlueMatt> Chris_St1: bip37 only ever matches constants
 797 2016-09-22T19:52:17  <wumpus> but that's not yet another reason to move forward the release
 798 2016-09-22T19:52:28  <BlueMatt> agreed
 799 2016-09-22T19:52:33  <achow101> topic proposal: alert system retirement
 800 2016-09-22T19:52:43  <gmaxwell> AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P
 801 2016-09-22T19:52:44  <instagibbs> 8 minutes left
 802 2016-09-22T19:52:47  <BlueMatt> we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting
 803 2016-09-22T19:53:00  <BlueMatt> gmaxwell: yup
 804 2016-09-22T19:53:00  <gmaxwell> BlueMatt: yup.
 805 2016-09-22T19:53:12  <CodeShark> I want a good fairly secure quick sync solution. BIP37 sucks :p
 806 2016-09-22T19:53:25  <gmaxwell> second on achow101's topic.
 807 2016-09-22T19:53:28  <petertodd> CodeShark: sure, fiber-to-the-home :)
 808 2016-09-22T19:53:33  <CodeShark> But we'll do that after 0.13.1
 809 2016-09-22T19:53:33  <wumpus> #topic  alert system retirement
 810 2016-09-22T19:53:34  <petertodd> gmaxwell: ack
 811 2016-09-22T19:54:11  <gmaxwell> Okay I sent out an email on this. Mostly well recieved (at least in public). I went and bludgenoned alt implementations into removing the alert key and only got mildly bloodied in the process.
 812 2016-09-22T19:54:20  *** davec has quit IRC
 813 2016-09-22T19:54:39  <petertodd> gmaxwell: sounds like it's time to set dates
 814 2016-09-22T19:54:41  <gmaxwell> My view on the next steps:
 815 2016-09-22T19:54:45  *** davec has joined #bitcoin-core-dev
 816 2016-09-22T19:54:54  <gmaxwell> (1) Create a bitcoincore.org or bitcoin.org announcement message.
 817 2016-09-22T19:55:16  <gmaxwell> (2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it.
 818 2016-09-22T19:55:26  <gmaxwell> (3) much later, send final alert.
 819 2016-09-22T19:55:46  <wumpus> I'd say we send the final alert with the 0.14 release
 820 2016-09-22T19:55:50  *** Chris_St1 has quit IRC
 821 2016-09-22T19:55:57  <gmaxwell> (4) hardcode nodes to send the final alert to peers to overcome the lack of propagation. (just using the one or two lines of code needed to send a static message, not pulling back any alert code)
 822 2016-09-22T19:55:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 823 2016-09-22T19:56:09  <wumpus> then include code in there to send it to old peers that connect, as gmaxwell says
 824 2016-09-22T19:56:28  <BlueMatt> gmaxwell: ACK
 825 2016-09-22T19:56:35  <BlueMatt> wumpus: ACK final alert with 0.14
 826 2016-09-22T19:56:48  <jtimon> ack
 827 2016-09-22T19:56:49  <achow101> ack
 828 2016-09-22T19:56:51  <petertodd> gmaxwell: and release the privkey for the alert key w/ the final alert?
 829 2016-09-22T19:56:54  <btcdrak> ack
 830 2016-09-22T19:57:03  <gmaxwell> I think we can do 1/2 in the next week. I'm not aware of any reason to delay, and there are propagation advantages to doing it earlier rather than later.
 831 2016-09-22T19:57:08  <sipa> i'd release the key later even
 832 2016-09-22T19:57:09  <petertodd> gmaxwell: ack
 833 2016-09-22T19:57:16  <instagibbs> make sure to sweep the funds people have sent to the key :P
 834 2016-09-22T19:57:19  *** yep5555 has quit IRC
 835 2016-09-22T19:57:26  <petertodd> instagibbs: ha
 836 2016-09-22T19:57:28  <roasbeef> btcd still has the code in place to parse the alert messages, but we simply drop-it-like-its-hot once recv of the message without any further processing (and have since early last year)
 837 2016-09-22T19:57:36  <BlueMatt> sipa: ack
 838 2016-09-22T19:57:52  <sipa> there may be alternate codebases that use the key who want to do something similar to (3) and (4)
 839 2016-09-22T19:58:10  <sipa> oh, wait
 840 2016-09-22T19:58:16  <sipa> they need the key for that
 841 2016-09-22T19:58:17  *** timothy has quit IRC
 842 2016-09-22T19:58:20  *** drizztbsd has joined #bitcoin-core-dev
 843 2016-09-22T19:58:24  <BlueMatt> 2 min
 844 2016-09-22T19:58:31  <instagibbs> any pressing topics
 845 2016-09-22T19:58:36  <wumpus> well after the final alert is sent, the key is only historical curiosity
 846 2016-09-22T19:58:42  <gmaxwell> okay, I'll send a message to the list.
 847 2016-09-22T19:58:47  <luke-jr> can the final alert match all clients?
 848 2016-09-22T19:58:56  *** drizztbsd is now known as timothy
 849 2016-09-22T19:59:05  <wumpus> luke-jr: you mean the pre-final alert, and yes
 850 2016-09-22T19:59:07  <petertodd> wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm
 851 2016-09-22T19:59:14  <gmaxwell> It cann't not match all clients.
 852 2016-09-22T19:59:30  <wumpus> gmaxwell: I think he means the penultimate alert
 853 2016-09-22T19:59:44  <wumpus> obviously the final alert matches all clients, at least those that still parse alerts
 854 2016-09-22T20:00:00  <gmaxwell> petertodd: if I can parition your network I can make your client show "Your bitcoin is outdated and vulnerable. You MUST download an update to continue. http://bitcoinscam.eu/"
 855 2016-09-22T20:00:22  <wumpus> gmaxwell: wasn't that the point in adding it to the client?
 856 2016-09-22T20:00:29  <gmaxwell> I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions.
 857 2016-09-22T20:00:40  <petertodd> gmaxwell: sure, but that'll have been after months of alert - I'm not worried there
 858 2016-09-22T20:00:51  <wumpus> it applies to everyone using the key, not just users of bitcoin core
 859 2016-09-22T20:00:53  <gmaxwell> in any case, can continue after, we should wrap the meeting. :)
 860 2016-09-22T20:00:58  <petertodd> gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert
 861 2016-09-22T20:00:59  <instagibbs> ding ding
 862 2016-09-22T20:01:01  <btcdrak> ding ding ding
 863 2016-09-22T20:01:02  <wumpus> yes it's time
 864 2016-09-22T20:01:03  <wumpus> #endmeeting
 865 2016-09-22T20:01:03  <lightningbot> Meeting ended Thu Sep 22 20:01:03 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 866 2016-09-22T20:01:03  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.html
 867 2016-09-22T20:01:03  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.txt
 868 2016-09-22T20:01:03  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.log.html
 869 2016-09-22T20:01:05  <sipa> bye
 870 2016-09-22T20:01:20  <wumpus> agree petertodd
 871 2016-09-22T20:01:43  <wumpus> this is not bitcoin core specific but everyone-that-embeds-that-pubkey specific
 872 2016-09-22T20:01:50  <Chris_Stewart_5> CodeShark: Did you have any concrete ideas for improving on BIP37?
 873 2016-09-22T20:01:57  <gmaxwell> petertodd: the reasoning I had for that thought is I think it should provide upgrade advice. And I don't want to give update advice to people who insist on running software I consider broken and dangerous.
 874 2016-09-22T20:02:20  <petertodd> gmaxwell: I think the upgrade advice can be general "whatever you are running, upgade"
 875 2016-09-22T20:02:38  <petertodd> gmaxwell: equally, it can just be a warning that you will soon see a final alert, as the alert system is being depreciated
 876 2016-09-22T20:02:49  <wumpus> yes, it can just be a warning about the alert
 877 2016-09-22T20:02:57  <wumpus> it doesn't really have to tell to upgrade
 878 2016-09-22T20:03:05  <wumpus> just make sure peopel are aware
 879 2016-09-22T20:03:09  <btcdrak> that's a good idea
 880 2016-09-22T20:03:16  <gmaxwell> Chris_Stewart_5: there is a proposal on the list for a replacement using commited filters. that coupled with a CB like getblocktxn that provides hashproofs would be the replacement.
 881 2016-09-22T20:03:20  <CodeShark> Chris_Stewart_5: proposals to put the filters in the blocks themselves seem at least slightly more promising
 882 2016-09-22T20:03:56  <gmaxwell> the commited filter thing can also be done without the commitment and still have the same security as BIP37 but without the consensus change.
 883 2016-09-22T20:05:16  <petertodd> gmaxwell: re: committed filter, you can make the consensus rule be it has to be a superset of what actually matches re: soft-forks
 884 2016-09-22T20:05:21  *** timothy has quit IRC
 885 2016-09-22T20:05:24  *** drizztbsd has joined #bitcoin-core-dev
 886 2016-09-22T20:05:26  <petertodd> gmaxwell: otherwise if we add another segwit-like thing we need a new filter
 887 2016-09-22T20:05:33  <gmaxwell> petertodd: bandwidth overhead in that however.
 888 2016-09-22T20:05:46  <gmaxwell> because then you have to send the filter between full nodes. yuck.
 889 2016-09-22T20:05:52  <CodeShark> UTXO commitments + getutxos would probably be the quickest sync option that isn't totally insecure
 890 2016-09-22T20:05:53  <instagibbs> is the bitcoin wiki down for others for the last few days?
 891 2016-09-22T20:05:57  <petertodd> gmaxwell: true, though wasn't it only a few KB?
 892 2016-09-22T20:05:59  *** drizztbsd is now known as timothy
 893 2016-09-22T20:06:25  <CodeShark> Privacy issues are still a problem, though
 894 2016-09-22T20:06:38  <petertodd> CodeShark: I don't think we can reasonably implement UTXO commitments
 895 2016-09-22T20:07:05  <gmaxwell> there are also many other options for scanning, including ones that are private, like via PIR lookup.
 896 2016-09-22T20:07:23  <Chris_Stewart_5> Thanks gmaxwell, CodeShark, will read.
 897 2016-09-22T20:07:34  <petertodd> and it'd be good for some of those options to be implemented via central services first to prototype
 898 2016-09-22T20:08:27  <gmaxwell> the commited maps thing would let us do several non-commited revisions the only thing you lose without the commitment is security against censorship, which BIP37 has none of already.
 899 2016-09-22T20:09:18  <petertodd> and a central service can be audited easily enough to detect censorship (assuming clients connect anonymously)
 900 2016-09-22T20:09:34  <gmaxwell> petertodd: re-size it may be interesting to have several sizes, so clients could probe at the smallest and then only probe the larger if they have a hit... so perhaps they're larger than you might think. this would also all be unpredictable uncached validation.  and 4kb would add about 1/3rd to a CB transmission.
 901 2016-09-22T20:09:37  <petertodd> or actually, commit to the contents of the filter, and then provide the filter
 902 2016-09-22T20:09:54  <petertodd> gmaxwell: true
 903 2016-09-22T20:09:57  <gmaxwell> petertodd: right you could talk to N hosts, and find that they all give the same commitment value.
 904 2016-09-22T20:10:11  <gmaxwell> without having to fetch the filter N times.
 905 2016-09-22T20:10:35  <gmaxwell> or even connect to one host and get a commitment signed by N parties.
 906 2016-09-22T20:10:36  <petertodd> gmaxwell: add a signature on the commitment and that should be enough
 907 2016-09-22T20:10:59  <gmaxwell> right.
 908 2016-09-22T20:11:18  <CodeShark> Thing is all these proposals significantly complicate client implementations
 909 2016-09-22T20:11:35  <petertodd> CodeShark: well, privacy is hard :)
 910 2016-09-22T20:11:41  <gmaxwell> checking a signature is not complex. :P
 911 2016-09-22T20:12:03  <gmaxwell> in any case, it's foolish to think we can design for forever in a single step; we must have incremental stepping stones.
 912 2016-09-22T20:12:05  <CodeShark> Ultimately, we need client implementations to be relatively simple or centralized API services will domimate
 913 2016-09-22T20:12:12  <CodeShark> *dominate
 914 2016-09-22T20:12:28  <petertodd> gmaxwell: I found it interesting how the Roughtime spec says that they will depreciate servers on a regular basis to force clients to keep up-to-date
 915 2016-09-22T20:13:16  <petertodd> CodeShark: well, if we don't do a good enough job, centralized API services may be better for privacy... I'd trust a centralized API over bloom filters
 916 2016-09-22T20:13:50  <CodeShark> or at the least we need some solid client-side libraries with multiple language bindings
 917 2016-09-22T20:14:09  <petertodd> CodeShark: does bloom filters even have that? :)
 918 2016-09-22T20:14:35  <petertodd> CodeShark: python-bitcoinlib *still* doesn't have a full bloom filter implementation - I've never had anyone interested in using it
 919 2016-09-22T20:14:49  <CodeShark> petertodd: only the true diehards even attempt to use bloom filters rather than, say, bc.i :p
 920 2016-09-22T20:15:10  <petertodd> CodeShark: indeed - python-bitcoinlib is likely used 99% of the time with a local copy of Bitcoin Core
 921 2016-09-22T20:15:27  <gmaxwell> bc.i has better privacy than bloomfilters, IMO.
 922 2016-09-22T20:16:04  <CodeShark> but it's still a single point of failure
 923 2016-09-22T20:16:28  <petertodd> CodeShark: then use the Electrum servers! :)
 924 2016-09-22T20:16:38  <CodeShark> Argh - lol
 925 2016-09-22T20:17:09  * petertodd runs two OpenTimestamps public calendar servers and thinks that's good enough. :)
 926 2016-09-22T20:17:18  *** gabridome has quit IRC
 927 2016-09-22T20:17:56  <petertodd> CodeShark: honestly, I think Electrum would be interested in better privacy too - they've been open to discussing this in the past, and IIRC implemented prefix filters for that purpose
 928 2016-09-22T20:18:10  <CodeShark> I run multiple bitcoin core instances and reluctantly use bip37
 929 2016-09-22T20:18:13  <luke-jr> http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf
 930 2016-09-22T20:18:58  <CodeShark> I get around the privacy and censorship issues by running my own instances
 931 2016-09-22T20:19:30  <CodeShark> Electrum is just an additional dependency I don't want
 932 2016-09-22T20:24:21  <CodeShark> Hell, if I wanted to go that route I could probably write a much thinner custom server - or a custom build of bitcoin core, even
 933 2016-09-22T20:24:57  <luke-jr> if we merge script indexes, should probably do some p2p replacement for Electrum's protocol <.<
 934 2016-09-22T20:25:37  *** laurentmt has joined #bitcoin-core-dev
 935 2016-09-22T20:27:12  <CodeShark> fwiw I'd like to work with all interested parties, including the electrum folks, in figuring out a good long-term solution to this
 936 2016-09-22T20:28:03  <gmaxwell> The model that many application prefer where you have some random access query by address is inherently unscalable and probably lacks a non-centeralized future.
 937 2016-09-22T20:29:42  <CodeShark> Then perhaps we need a different application model as well
 938 2016-09-22T20:33:51  <morcos> cfields: what happened to: https://github.com/theuni/bitcoin/tree/copy-move ?
 939 2016-09-22T20:34:11  <CodeShark> it won't be simple to implement - but with the right abstractions it could be well-encapsulated, providing app developers with a reasonably simple model
 940 2016-09-22T20:35:17  <cfields> morcos: started there, and got side-tracked optimizing prevector. the top commit is probably good as-is, though it won't change much without making prevector movable.
 941 2016-09-22T20:36:20  *** laurentmt has quit IRC
 942 2016-09-22T20:36:41  <luke-jr> always annoying when people hear "I'm running Bitcoin Core" and their immediate reply is "you should switch to Electrum!"
 943 2016-09-22T20:37:00  <gmaxwell> more than a little frightening too.
 944 2016-09-22T20:38:46  <gmaxwell> wumpus: what happened with the work on SSE sha2 and asm for the CRC32?
 945 2016-09-22T20:39:10  <morcos> cfields: i've been using that commit in my benchmarks for a while..  and today while trying to update everything i left it out..  and i'm thinking that explains some inconsitencies.  i'll confirm, but i think its worth getting in
 946 2016-09-22T20:39:50  <gmaxwell> wumpus: if you were disappointed at the fairly modest improvement, I expect it will be much better post the checkqueue changes.
 947 2016-09-22T20:40:07  <cfields> morcos: sure. If you'd like to double-down, I can give you a quick commit that just adds move to prevector. It should be quite significant if you're seeing a difference already
 948 2016-09-22T20:46:06  *** jnewbery has quit IRC
 949 2016-09-22T20:48:51  *** cryptapus_afk is now known as cryptapus
 950 2016-09-22T20:50:04  <Chris_Stewart_5> Back when pay to public key and raw multisig were used on the network, how were addresses generated? Did you just hash the entire scriptPubKey?
 951 2016-09-22T20:51:19  <luke-jr> that was before addresses
 952 2016-09-22T20:51:33  <luke-jr> (and raw multisig was never common use)
 953 2016-09-22T20:52:02  <luke-jr> if you wanted to pay someone, you put in their IP and your client connected to them for a script
 954 2016-09-22T20:53:32  <Chris_Stewart_5> Interesting, I guess i'm conflating addresses and actually spending scriptPubKeys.
 955 2016-09-22T20:55:29  <Chris_Stewart_5> luke-jr: Was that functionality inside of Bitcoin Core? Inputing their ip address?
 956 2016-09-22T20:55:57  <luke-jr> Chris_Stewart_5: this was before Bitcoin Core's time, and also before my time :p
 957 2016-09-22T20:56:31  <luke-jr> Bitcoin started off with a wxWidgets Windows-only GUI client which was abandoned a long time ago
 958 2016-09-22T20:56:52  <Chris_Stewart_5> Haha fair enough, guess i'm getting more into history instead of development any way
 959 2016-09-22T20:59:38  <morcos> cfields: i'd love to double down, but will have to wait til tomorrow
 960 2016-09-22T21:01:55  <cfields> morcos: ok, will push there later. sanity checking now.
 961 2016-09-22T21:02:48  *** cis has quit IRC
 962 2016-09-22T21:05:01  *** sokei has joined #bitcoin-core-dev
 963 2016-09-22T21:10:31  *** crudel has quit IRC
 964 2016-09-22T21:15:33  *** Guyver2_ has joined #bitcoin-core-dev
 965 2016-09-22T21:17:41  *** Guyver2 has quit IRC
 966 2016-09-22T21:17:46  *** Guyver2_ is now known as Guyver2
 967 2016-09-22T21:25:54  *** achow101 has quit IRC
 968 2016-09-22T21:25:54  *** achow101 has joined #bitcoin-core-dev
 969 2016-09-22T21:30:01  *** jcorgan has quit IRC
 970 2016-09-22T21:36:39  <luke-jr> FWIW, C++11 is de facto causing ABI issues on Gentoo (but probably not significant enough to regret the move)
 971 2016-09-22T21:36:59  *** Chris_Stewart_5 has quit IRC
 972 2016-09-22T21:36:59  *** midnightmagic has quit IRC
 973 2016-09-22T21:36:59  *** mn3monic has quit IRC
 974 2016-09-22T21:36:59  *** jannes has quit IRC
 975 2016-09-22T21:36:59  *** dgenr8 has quit IRC
 976 2016-09-22T21:36:59  *** owowo has quit IRC
 977 2016-09-22T21:36:59  *** Magma has quit IRC
 978 2016-09-22T21:37:00  *** bsm117532 has quit IRC
 979 2016-09-22T21:37:00  *** LeMiner has quit IRC
 980 2016-09-22T21:37:00  *** d4de has quit IRC
 981 2016-09-22T21:37:00  *** TD-Linux has quit IRC
 982 2016-09-22T21:37:00  *** PatBoy has quit IRC
 983 2016-09-22T21:37:01  *** gluytium has quit IRC
 984 2016-09-22T21:37:01  *** jtimon has quit IRC
 985 2016-09-22T21:37:01  *** aalex has quit IRC
 986 2016-09-22T21:37:01  *** paveljanik has quit IRC
 987 2016-09-22T21:37:01  *** tadasv has quit IRC
 988 2016-09-22T21:37:01  *** jeremyrubin has quit IRC
 989 2016-09-22T21:37:01  *** blkdb has quit IRC
 990 2016-09-22T21:37:01  *** Lightsword has quit IRC
 991 2016-09-22T21:37:01  *** CyrusV has quit IRC
 992 2016-09-22T21:37:02  *** zxzzt has quit IRC
 993 2016-09-22T21:37:02  *** michagogo has quit IRC
 994 2016-09-22T21:37:02  *** zmanian__ has quit IRC
 995 2016-09-22T21:37:02  *** aspect_ has quit IRC
 996 2016-09-22T21:37:03  *** jouke_ has quit IRC
 997 2016-09-22T21:37:03  *** warren has quit IRC
 998 2016-09-22T21:37:03  *** CodeShark has quit IRC
 999 2016-09-22T21:37:03  *** echonaut has quit IRC
1000 2016-09-22T21:37:03  *** BlueMatt has quit IRC
1001 2016-09-22T21:37:04  *** Madars has quit IRC
1002 2016-09-22T21:37:04  *** lclc has quit IRC
1003 2016-09-22T21:37:04  *** ryan-c has quit IRC
1004 2016-09-22T21:37:04  *** andytoshi has quit IRC
1005 2016-09-22T21:37:04  *** BonyM1 has quit IRC
1006 2016-09-22T21:37:05  *** paracyst has quit IRC
1007 2016-09-22T21:37:05  *** achow101 has quit IRC
1008 2016-09-22T21:37:05  *** MrHodl has quit IRC
1009 2016-09-22T21:37:05  *** Ylbam has quit IRC
1010 2016-09-22T21:37:05  *** rogerwilco has quit IRC
1011 2016-09-22T21:37:05  *** berndj has quit IRC
1012 2016-09-22T21:37:05  *** limpkin has quit IRC
1013 2016-09-22T21:37:05  *** cfields has quit IRC
1014 2016-09-22T21:37:06  *** lesderid has quit IRC
1015 2016-09-22T21:37:06  *** ghtdak has quit IRC
1016 2016-09-22T21:37:06  *** morcos has quit IRC
1017 2016-09-22T21:37:06  *** mturquette has quit IRC
1018 2016-09-22T21:37:06  *** wallet42 has quit IRC
1019 2016-09-22T21:37:06  *** asoltys has quit IRC
1020 2016-09-22T21:37:06  *** trippysalmon has quit IRC
1021 2016-09-22T21:37:07  *** [b__b] has quit IRC
1022 2016-09-22T21:37:07  *** waxwing has quit IRC
1023 2016-09-22T21:37:07  *** wolfspraul has quit IRC
1024 2016-09-22T21:37:54  <luke-jr> mostly due to GCC 4.9 vs 5 mixing it seems
1025 2016-09-22T21:38:39  *** jtimon has joined #bitcoin-core-dev
1026 2016-09-22T21:38:39  *** aalex has joined #bitcoin-core-dev
1027 2016-09-22T21:38:39  *** paveljanik has joined #bitcoin-core-dev
1028 2016-09-22T21:38:39  *** tadasv has joined #bitcoin-core-dev
1029 2016-09-22T21:38:39  *** jeremyrubin has joined #bitcoin-core-dev
1030 2016-09-22T21:38:39  *** blkdb has joined #bitcoin-core-dev
1031 2016-09-22T21:38:39  *** aspect_ has joined #bitcoin-core-dev
1032 2016-09-22T21:38:39  *** Lightsword has joined #bitcoin-core-dev
1033 2016-09-22T21:38:39  *** CyrusV has joined #bitcoin-core-dev
1034 2016-09-22T21:38:39  *** zxzzt has joined #bitcoin-core-dev
1035 2016-09-22T21:38:39  *** michagogo has joined #bitcoin-core-dev
1036 2016-09-22T21:38:39  *** zmanian__ has joined #bitcoin-core-dev
1037 2016-09-22T21:38:39  *** jouke_ has joined #bitcoin-core-dev
1038 2016-09-22T21:38:39  *** warren has joined #bitcoin-core-dev
1039 2016-09-22T21:38:39  *** CodeShark has joined #bitcoin-core-dev
1040 2016-09-22T21:38:48  <sipa> i would expect to be the one distro that doesn't suffer from such issues :)
1041 2016-09-22T21:38:48  <sipa> *gentoo
1042 2016-09-22T21:39:23  *** michagogo has quit IRC
1043 2016-09-22T21:40:18  <luke-jr> sipa: tends to be the most likely to hit issues; binary distros just rebuild everything when ABIs change :p
1044 2016-09-22T21:40:42  *** achow101 has joined #bitcoin-core-dev
1045 2016-09-22T21:40:42  *** MrHodl has joined #bitcoin-core-dev
1046 2016-09-22T21:40:42  *** Ylbam has joined #bitcoin-core-dev
1047 2016-09-22T21:40:42  *** rogerwilco has joined #bitcoin-core-dev
1048 2016-09-22T21:40:42  *** berndj has joined #bitcoin-core-dev
1049 2016-09-22T21:40:42  *** cfields has joined #bitcoin-core-dev
1050 2016-09-22T21:40:42  *** lesderid has joined #bitcoin-core-dev
1051 2016-09-22T21:40:42  *** ghtdak has joined #bitcoin-core-dev
1052 2016-09-22T21:40:42  *** morcos has joined #bitcoin-core-dev
1053 2016-09-22T21:40:42  *** mturquette has joined #bitcoin-core-dev
1054 2016-09-22T21:40:42  *** trippysalmon has joined #bitcoin-core-dev
1055 2016-09-22T21:40:42  *** asoltys has joined #bitcoin-core-dev
1056 2016-09-22T21:40:42  *** [b__b] has joined #bitcoin-core-dev
1057 2016-09-22T21:40:42  *** waxwing has joined #bitcoin-core-dev
1058 2016-09-22T21:40:42  *** wolfspraul has joined #bitcoin-core-dev
1059 2016-09-22T21:40:46  *** Expanse has quit IRC
1060 2016-09-22T21:40:51  *** zmanian__ has quit IRC
1061 2016-09-22T21:41:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1062 2016-09-22T21:41:01  *** midnightmagic has joined #bitcoin-core-dev
1063 2016-09-22T21:41:01  *** mn3monic has joined #bitcoin-core-dev
1064 2016-09-22T21:41:01  *** jannes has joined #bitcoin-core-dev
1065 2016-09-22T21:41:01  *** dgenr8 has joined #bitcoin-core-dev
1066 2016-09-22T21:41:01  *** owowo has joined #bitcoin-core-dev
1067 2016-09-22T21:41:17  *** Magma has joined #bitcoin-core-dev
1068 2016-09-22T21:41:33  *** bsm117532 has joined #bitcoin-core-dev
1069 2016-09-22T21:41:33  *** LeMiner has joined #bitcoin-core-dev
1070 2016-09-22T21:41:33  *** d4de has joined #bitcoin-core-dev
1071 2016-09-22T21:41:33  *** TD-Linux has joined #bitcoin-core-dev
1072 2016-09-22T21:41:33  *** PatBoy has joined #bitcoin-core-dev
1073 2016-09-22T21:41:33  *** gluytium has joined #bitcoin-core-dev
1074 2016-09-22T21:42:48  *** echonaut has joined #bitcoin-core-dev
1075 2016-09-22T21:42:48  *** BlueMatt has joined #bitcoin-core-dev
1076 2016-09-22T21:42:48  *** andytoshi has joined #bitcoin-core-dev
1077 2016-09-22T21:42:48  *** Madars has joined #bitcoin-core-dev
1078 2016-09-22T21:42:48  *** lclc has joined #bitcoin-core-dev
1079 2016-09-22T21:42:48  *** ryan-c has joined #bitcoin-core-dev
1080 2016-09-22T21:42:48  *** BonyM1 has joined #bitcoin-core-dev
1081 2016-09-22T21:42:48  *** paracyst has joined #bitcoin-core-dev
1082 2016-09-22T21:47:32  *** Expanse has joined #bitcoin-core-dev
1083 2016-09-22T21:49:15  *** MarcoFalke has joined #bitcoin-core-dev
1084 2016-09-22T21:51:04  *** Frederic94500 has joined #bitcoin-core-dev
1085 2016-09-22T21:54:37  *** Frederic94500 has quit IRC
1086 2016-09-22T22:05:52  *** wallet42 has joined #bitcoin-core-dev
1087 2016-09-22T22:12:34  *** limpkin has joined #bitcoin-core-dev
1088 2016-09-22T22:16:11  *** Alopex has quit IRC
1089 2016-09-22T22:16:45  *** zmanian__ has joined #bitcoin-core-dev
1090 2016-09-22T22:17:16  *** Alopex has joined #bitcoin-core-dev
1091 2016-09-22T22:19:12  *** michagogo has joined #bitcoin-core-dev
1092 2016-09-22T22:22:32  *** jnewbery has joined #bitcoin-core-dev
1093 2016-09-22T22:28:28  *** cryptapus is now known as cryptapus_afk
1094 2016-09-22T22:36:22  *** murch has quit IRC
1095 2016-09-22T22:43:41  *** justan0theruser has joined #bitcoin-core-dev
1096 2016-09-22T22:44:14  *** Guyver2 has quit IRC
1097 2016-09-22T22:46:33  *** justanotheruser has quit IRC
1098 2016-09-22T22:55:19  <gmaxwell> Re PR #8661 is there a reason that this isn't getting merged?
1099 2016-09-22T22:58:28  *** MarcoFalke has left #bitcoin-core-dev
1100 2016-09-22T22:58:30  *** jnewbery has quit IRC
1101 2016-09-22T23:02:36  *** crudel has joined #bitcoin-core-dev
1102 2016-09-22T23:16:40  *** rogerwilco has quit IRC
1103 2016-09-22T23:17:26  *** rogerwilco has joined #bitcoin-core-dev
1104 2016-09-22T23:23:38  *** d4de has quit IRC
1105 2016-09-22T23:39:05  *** jnewbery has joined #bitcoin-core-dev
1106 2016-09-22T23:41:54  *** jnewbery has quit IRC
1107 2016-09-22T23:42:51  *** randy-waterhouse has joined #bitcoin-core-dev
1108 2016-09-22T23:43:12  *** randy-waterhouse has joined #bitcoin-core-dev