1 2016-09-22 00:46:52	0|GitHub154|[13bitcoin] 15instagibbs opened pull request #8785: Comment on CNode::nLocalServices meaning (06master...06nlocalservisme) 02https://github.com/bitcoin/bitcoin/pull/8785
  2 2016-09-22 01:38:47	0|wumpus|can we please stop doing the copyright pulls where half of github is highlightes
  3 2016-09-22 01:42:52	0|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
  4 2016-09-22 01:45:21	0|achow101|by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant.
  5 2016-09-22 01:45:31	0|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?
  6 2016-09-22 01:45:45	0|gmaxwell|achow101: that is unlear though it could be made clear.
  7 2016-09-22 01:46:16	0|wumpus|I don't know, but this getting out of hand
  8 2016-09-22 01:46:43	0|achow101|I though that was just kind of "in general" for all OSS projects
  9 2016-09-22 01:46:43	0|wumpus|achow101: that is what I always thought too
 10 2016-09-22 01:46:51	0|wumpus|there is a COPYING file in the rot of the repository
 11 2016-09-22 01:46:55	0|wumpus|root*
 12 2016-09-22 01:47:08	0|wumpus|if you don't put an explicit license in a file, that is what it is bound to
 13 2016-09-22 01:47:30	0|wumpus|but apparantly this is turning into a frigging zoo now, what's next, ahving to ask permision for every source line?
 14 2016-09-22 01:47:58	0|wumpus|what is this accomplishing?
 15 2016-09-22 01:48:44	0|wumpus|and yes, asking per email would have been preferable. Asking once per contributor, too. If that is really necessary.
 16 2016-09-22 01:48:51	0|wumpus|but we're not relicencing the project
 17 2016-09-22 01:48:58	0|wumpus|it has ALWAYS been MIT
 18 2016-09-22 01:49:04	0|wumpus|satoshi made it MIT
 19 2016-09-22 01:49:57	0|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
 20 2016-09-22 01:50:14	0|wumpus|I've been mailed a few times to approve of license changes, but that's a whole different and more serious thing
 21 2016-09-22 01:50:53	0|wumpus|and that was for real contributions not changing the case of one letter in one file
 22 2016-09-22 01:56:00	0|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"
 23 2016-09-22 01:56:49	0|wumpus|not the last part
 24 2016-09-22 01:57:09	0|wumpus|only "By contributing to this repository, you agree to license your work under the MIT license"
 25 2016-09-22 01:57:18	0|achow101|ok.
 26 2016-09-22 01:58:36	0|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.
 27 2016-09-22 01:59:27	0|wumpus|I wouldn't be surprised with all this polling that people are starting to think we're changing licenses though ...
 28 2016-09-22 02:00:26	0|GitHub82|[13bitcoin] 15achow101 opened pull request #8786: Mandatory copyright agreement (06master...06copyright-contributing) 02https://github.com/bitcoin/bitcoin/pull/8786
 29 2016-09-22 02:29:59	0|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
 30 2016-09-22 02:30:17	0|wumpus|yes we should make it explicitl
 31 2016-09-22 02:30:27	0|wumpus|see https://github.com/bitcoin/bitcoin/pull/8786
 32 2016-09-22 02:30:30	0|achow101|well my PR makes it explicit
 33 2016-09-22 02:30:34	0|wumpus|yes
 34 2016-09-22 02:32:35	0|luke-jr|and hopefully people will stop submitting non-licensed code without getting permission first <.<
 35 2016-09-22 02:32:51	0|wumpus|such as?
 36 2016-09-22 02:32:58	0|luke-jr|wumpus: l_atomic.m4 until today
 37 2016-09-22 02:33:29	0|wumpus|let's revert it then?
 38 2016-09-22 02:33:32	0|luke-jr|came from a GPL-licensed project, with no license on the build stuff
 39 2016-09-22 02:33:33	0|luke-jr|nah
 40 2016-09-22 02:33:39	0|luke-jr|already got an ACK from the author for MIT terms
 41 2016-09-22 02:34:33	0|luke-jr|just something to keep in mind when stuff gets contributed by someone other than the original author
 42 2016-09-22 02:36:44	0|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
 43 2016-09-22 02:36:54	0|luke-jr|+1
 44 2016-09-22 02:39:14	0|wumpus|hey, github review comments don't show as comments in the pull list
 45 2016-09-22 02:39:26	0|luke-jr|O.o
 46 2016-09-22 02:39:29	0|wumpus|I've approved https://github.com/bitcoin/bitcoin/pull/8783 but it still shows as 0
 47 2016-09-22 02:40:04	0|wumpus|unless I have an unrelated web caching issue, that happens
 48 2016-09-22 02:40:12	0|kanzure|ouch is "approved" github's terminology? ok.
 49 2016-09-22 02:40:22	0|achow101|How about "Any code contributed where you are not the original author must contain its license header"
 50 2016-09-22 02:40:46	0|wumpus|yes makes sense achow101
 51 2016-09-22 02:40:57	0|achow101|wumpus: I see your approval on 8783
 52 2016-09-22 02:41:02	0|wumpus|kanzure: indeed, I wouldn't have used that word myself
 53 2016-09-22 02:41:17	0|achow101|I think it's your browser
 54 2016-09-22 02:41:21	0|kanzure|wumpus: that's going to cause confusion. oh well.
 55 2016-09-22 02:41:33	0|luke-jr|can we get Travis to check for a copyright line on new files maybe?
 56 2016-09-22 02:42:02	0|wumpus|achow101: yes I see it too in the topic itself, but do you see it in the overview list?
 57 2016-09-22 02:42:35	0|wumpus|there's this comment icon and then a count, there's no count for #8783 here. Ohwell.
 58 2016-09-22 02:43:09	0|achow101|oh that. No I don't see that
 59 2016-09-22 02:44:40	0|wumpus|luke-jr: that's certainly possible
 60 2016-09-22 02:45:27	0|wumpus|just paste the script from https://github.com/bitcoin/bitcoin/pull/8674 somewhere into the test process in travis.yml
 61 2016-09-22 02:45:31	0|wumpus|+report
 62 2016-09-22 02:46:27	0|wumpus|it's a pretty good suggestion, could even parse debian/copyright for the copyright metadata on binary files
 63 2016-09-22 02:46:37	0|wumpus|I don't have time for those things though :)
 64 2016-09-22 03:19:03	0|GitHub131|[13bitcoin] 15AmirAbrams opened pull request #8787: [Doc] Add missing autogen to example builds (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8787
 65 2016-09-22 03:23:48	0|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?
 66 2016-09-22 03:27:22	0|achow101|wumpus: watch https://www.youtube.com/watch?v=C6MGKHkNtxU
 67 2016-09-22 03:28:06	0|roasbeef|it's basically like trello embedded within github
 68 2016-09-22 03:29:13	0|achow101|also read https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects/
 69 2016-09-22 03:29:51	0|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
 70 2016-09-22 03:33:13	0|achow101|AFAICT, yes, you can use it for grouping related issues and PR's
 71 2016-09-22 03:33:35	0|achow101|although it seems that actually doing it might be a bit of a pain with the drag and drop interface
 72 2016-09-22 03:35:29	0|achow101|Stuff can be in multiple projects, and within projects are additional sub groupings (called columns)
 73 2016-09-22 03:39:36	0|wumpus|thanks, looks somewhat like hwat I'm looking for then, I'll read on about it
 74 2016-09-22 03:51:30	0|achow101|luke-jr: can you access the projects here: https://github.com/achow101/ProtectedBranchTest/projects ?
 75 2016-09-22 03:52:32	0|luke-jr|I can see them, but it seems I cannot submit an issue to a specific project
 76 2016-09-22 03:54:21	0|achow101|right, I think it's more for internal organization for the committers
 77 2016-09-22 03:54:53	0|achow101|just like how you can't do labels or milestones if you aren't part of the group
 78 2016-09-22 04:00:44	0|sipa_|wumpus: you're up early
 79 2016-09-22 04:01:21	0|sipa_|i briefly feared i was in the wrong timezone
 80 2016-09-22 04:05:19	0|wumpus|achow101: seems to work fairly well https://github.com/bitcoin/bitcoin/projects/1
 81 2016-09-22 04:05:23	0|wumpus|sipa_: hah yes couldn't sleep
 82 2016-09-22 04:06:22	0|achow101|:D
 83 2016-09-22 04:23:42	0|sipa|wumpus: those projects look useful
 84 2016-09-22 04:23:53	0|wumpus|indeed!
 85 2016-09-22 04:24:07	0|sipa|especially if we'd actually maintain them, it could simplify things like writinf release notes as well
 86 2016-09-22 04:25:09	0|sipa|"PRs #1234, #2345, #3456, #4567 and #5678 together replaced the outdated PoW system"
 87 2016-09-22 04:26:37	0|wumpus|yes, that could be an advantage as well
 88 2016-09-22 05:15:32	0|wumpus|cfields: I've created a project for your P2P refactor, please add if I missed anything: https://github.com/bitcoin/bitcoin/projects/4
 89 2016-09-22 05:44:37	0|GitHub21|13bitcoin/06master 14faf87af 15MarcoFalke: [contrib] delete qt_translations.py...
 90 2016-09-22 05:44:37	0|GitHub21|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cf5ebaa921a9...ca69ef4880d1
 91 2016-09-22 05:44:38	0|GitHub21|13bitcoin/06master 14ca69ef4 15Wladimir J. van der Laan: Merge #8781: [contrib] delete qt_translations.py...
 92 2016-09-22 05:44:52	0|GitHub172|[13bitcoin] 15laanwj closed pull request #8781: [contrib] delete qt_translations.py (06master...06Mf1609-deleteQtTrans) 02https://github.com/bitcoin/bitcoin/pull/8781
 93 2016-09-22 05:45:07	0|GitHub146|13bitcoin/06master 14fa13c5c 15MarcoFalke: [share] remove qt/protobuf.pri...
 94 2016-09-22 05:45:07	0|GitHub146|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ca69ef4880d1...64dc6457454a
 95 2016-09-22 05:45:08	0|GitHub146|13bitcoin/06master 1464dc645 15Wladimir J. van der Laan: Merge #8783: [share] remove qt/protobuf.pri...
 96 2016-09-22 05:45:22	0|GitHub166|[13bitcoin] 15laanwj closed pull request #8783: [share] remove qt/protobuf.pri (06master...06Mf1609-deleteqtProto) 02https://github.com/bitcoin/bitcoin/pull/8783
 97 2016-09-22 05:48:57	0|GitHub28|[13bitcoin] 15laanwj closed pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (060.12...06Mf1606-rpcBip9Backport) 02https://github.com/bitcoin/bitcoin/pull/8186
 98 2016-09-22 05:55:03	0|GitHub16|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/64dc6457454a...3166dff48f35
 99 2016-09-22 05:55:04	0|GitHub16|13bitcoin/06master 146b6cbdd 15fanquake: [depends] expat 2.2.0
100 2016-09-22 05:55:04	0|GitHub16|13bitcoin/06master 149616ac8 15fanquake: [depends] ccache 3.3.1
101 2016-09-22 05:55:05	0|GitHub16|13bitcoin/06master 1486d410d 15fanquake: [depends] fontconfig 2.12.1
102 2016-09-22 05:55:08	0|GitHub4|[13bitcoin] 15laanwj closed pull request #8423: [depends] expat 2.2.0, ccache 3.3.1, fontconfig 2.12.1 (06master...06expat-ccache-jul) 02https://github.com/bitcoin/bitcoin/pull/8423
103 2016-09-22 05:56:54	0|GitHub101|13bitcoin/06master 14fa81d09 15MarcoFalke: [contrib] Delete spendfrom
104 2016-09-22 05:56:54	0|GitHub101|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3166dff48f35...7008e28136b5
105 2016-09-22 05:56:55	0|GitHub101|13bitcoin/06master 147008e28 15Wladimir J. van der Laan: Merge #8779: [contrib] Delete spendfrom...
106 2016-09-22 05:57:06	0|GitHub19|[13bitcoin] 15laanwj closed pull request #8779: [contrib] Delete spendfrom (06master...06Mf1609-deleteAllTheThings) 02https://github.com/bitcoin/bitcoin/pull/8779
107 2016-09-22 06:45:05	0|cfields|wumpus: ooh, neat
108 2016-09-22 06:45:15	0|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
109 2016-09-22 06:45:20	0|jonasschnelli|Seems to cause linking errors...
110 2016-09-22 06:45:34	0|wumpus|yes. I like this feature
111 2016-09-22 06:46:08	0|jonasschnelli|Linking errors are here: https://travis-ci.org/bitcoin/bitcoin/jobs/160477991#L1567
112 2016-09-22 06:46:53	0|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
113 2016-09-22 06:47:17	0|btcdrak|I quite like the projects tab, much easier to see a project progress potentially over more than one release
114 2016-09-22 06:47:43	0|cfields|jonasschnelli: heh, I just fixed the same thing for "bench" a few days ago, I need to PR it
115 2016-09-22 06:47:47	0|cfields|jonasschnelli: sec for link
116 2016-09-22 06:47:58	0|jonasschnelli|cfields: thanks!
117 2016-09-22 06:48:01	0|cfields|jonasschnelli: fyi, link-order doesn't matter for apple's linker, but it does for gnu ld/gold
118 2016-09-22 06:48:24	0|jonasschnelli|Yeah. I thought so and tried different orders,.. used the same the bitcoid does...
119 2016-09-22 06:48:33	0|jonasschnelli|*then
120 2016-09-22 06:48:38	0|cfields|jonasschnelli: https://github.com/theuni/bitcoin/commit/a3786f1aeebf6455acec50926c3b27ea5c060f02
121 2016-09-22 06:49:06	0|jonasschnelli|cfields: Thanks.. Let me try something..
122 2016-09-22 06:49:09	0|cfields|jonasschnelli: should be pretty much copy/paste for you
123 2016-09-22 06:49:15	0|jonasschnelli|okay.
124 2016-09-22 06:49:27	0|jonasschnelli|btcdrak: A nice! We have projects now.
125 2016-09-22 06:49:29	0|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
126 2016-09-22 06:49:29	0|btcdrak|since MIT is generally quite permissive and compatible with just about anything.
127 2016-09-22 06:50:28	0|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
128 2016-09-22 06:50:31	0|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).
129 2016-09-22 06:50:46	0|btcdrak|Contributing should have a line about this.
130 2016-09-22 06:50:47	0|jonasschnelli|cfields: okay
131 2016-09-22 06:51:21	0|wumpus|btcdrak: https://github.com/bitcoin/bitcoin/pull/8786
132 2016-09-22 06:53:58	0|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.
133 2016-09-22 06:54:42	0|jonasschnelli|cfields: ah.. okay. But the amount of missing symbols should also point out that the linking order is wrong.. not?
134 2016-09-22 06:55:00	0|cfields|jonasschnelli: yes, either busted link order or circular dependency
135 2016-09-22 07:08:01	0|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
136 2016-09-22 07:08:05	0|cfields|jonasschnelli: oh, i might know
137 2016-09-22 07:09:48	0|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
138 2016-09-22 07:10:25	0|jonasschnelli|cfields: Okay. I'll try that.
139 2016-09-22 07:10:35	0|cfields|jonasschnelli: see bitcoind as an example
140 2016-09-22 07:10:48	0|phantomcircuit|jonasschnelli: any idea why we're asseting that locks are held instead of acquiring the lock in cwallet?
141 2016-09-22 07:11:00	0|phantomcircuit|the locks recursive so it should be fine to just acquire it again
142 2016-09-22 07:11:16	0|cfields|jonasschnelli: i can play around with it tomorrow (later) if it's still not working
143 2016-09-22 07:11:31	0|jonasschnelli|phantomcircuit: Is there no overhead in acquiring the lock again? Couple of CPU ticks consumed?
144 2016-09-22 07:11:54	0|jonasschnelli|cfields: Okay. I may try to play with it... but I guess I will fail. :) But no hurry
145 2016-09-22 07:12:25	0|cfields|jonasschnelli: you should know by now that telling me "no hurry" guarantees it will never happen :)
146 2016-09-22 07:12:30	0|phantomcircuit|wumpus: any idea if it costs more to acquire an already held lock than asserting the lock is held?
147 2016-09-22 07:12:36	0|jonasschnelli|cfields: hurry up then! :)
148 2016-09-22 07:13:04	0|wumpus|phantomcircuit: asserting that the lock is held is only enabled when log debugging is enabled, so that is the cheaper option
149 2016-09-22 07:13:28	0|wumpus|it's really a sanity assertion
150 2016-09-22 07:13:47	0|cfields|also, asserting means that you're not depending on the recursive lock and may be able to rip it out at some point :)
151 2016-09-22 07:52:54	0|gmaxwell|murch: it would be approximate for sure.
152 2016-09-22 07:53:04	0|gmaxwell|but I think worth analizing.
153 2016-09-22 08:04:46	0|GitHub79|[13bitcoin] 15jonasschnelli opened pull request #8788: [RPC] Give RPC commands more information about the RPC request (06master...062016/09/rpc_container) 02https://github.com/bitcoin/bitcoin/pull/8788
154 2016-09-22 08:07:45	0|phantomcircuit|wumpus: hmm
155 2016-09-22 08:07:56	0|phantomcircuit|how expensive is it to acquire a lock when you already have it?
156 2016-09-22 08:08:04	0|phantomcircuit|should just be a thread local check
157 2016-09-22 08:10:13	0|jonasschnelli|phantomcircuit: Is there a reason for re-acquiring the lock? Why not acquire the lock from the caller instead in the called function?
158 2016-09-22 08:10:41	0|jonasschnelli|But meh,.. depends on your layering.
159 2016-09-22 08:15:11	0|luke-jr|even if we have recursive locks in some places, it's still not a good idea to use it recursively :/
160 2016-09-22 08:32:23	0|luke-jr|jonasschnelli: your travis failed
161 2016-09-22 08:32:45	0|jonasschnelli|Luke-Jr: thanks... looking..
162 2016-09-22 08:33:25	0|jonasschnelli|It broke rest
163 2016-09-22 08:34:01	0|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
164 2016-09-22 08:34:32	0|jonasschnelli|Luke-Jr: depends how you make the user<->wallet mapping..
165 2016-09-22 08:34:48	0|jonasschnelli|But I think user-wallet-mapping is a different thing then RPC auth
166 2016-09-22 08:35:23	0|jonasschnelli|But I would prefer selecting the wallet based on the endpoint or something within the RPC request
167 2016-09-22 08:35:40	0|jonasschnelli|Selecting based on the -rpcuser makes it relatively complex to setup
168 2016-09-22 08:35:44	0|luke-jr|even if we do so, most likely users should be restricted to only some wallet(s)
169 2016-09-22 08:36:03	0|jonasschnelli|We could still do this... but multiwallet is probably simpler then multiwallet-multiuser
170 2016-09-22 08:36:13	0|luke-jr|we already have multiuser :p
171 2016-09-22 08:36:41	0|jonasschnelli|Yes. I meant simpler to not do mutliuser-multiwallet in the first step
172 2016-09-22 08:37:21	0|jonasschnelli|If we would select the wallet depending on the endpoint, we could just use something like bitcoin-cli --wallet=<walletid> getbalance
173 2016-09-22 08:37:53	0|jonasschnelli|where the bitcoin-cli tools would use --wallet=<walletid> to pass the request to /<walletid>
174 2016-09-22 08:38:05	0|luke-jr|can do it with mu-mw already today - plus the code for it is written already *shrug*
175 2016-09-22 08:38:23	0|jonasschnelli|Yes. But what if you want to wallet with a single user?
176 2016-09-22 08:38:31	0|jonasschnelli|How would you select?
177 2016-09-22 08:38:37	0|luke-jr|can't with the current implementation
178 2016-09-22 08:38:39	0|jonasschnelli|*want two
179 2016-09-22 08:38:50	0|luke-jr|doing that is more complicated IMO
180 2016-09-22 08:39:07	0|jonasschnelli|I think its the more obvious use case (single user, multiple wallet=
181 2016-09-22 08:39:11	0|luke-jr|I'm all for /?wallet=<walletid>, just don't think it's the ideal first-step
182 2016-09-22 08:39:42	0|luke-jr|since we already have multiuser and even with wallet-selection-by-endpoint would want to lock it down
183 2016-09-22 08:39:44	0|jonasschnelli|I'm also happy with /?wallet=<walleid> ... AFAIK it's simpler to parse /<walletid>
184 2016-09-22 08:39:51	0|jonasschnelli|or /wallet/<walletid>
185 2016-09-22 08:40:37	0|luke-jr|as I see it, endpoint wallet selection is an additional step beyond user permissions
186 2016-09-22 08:41:21	0|jonasschnelli|Yes. But I think we need to solve singleuser-multiwallet
187 2016-09-22 08:41:37	0|jonasschnelli|Either with ?wallet=<walletid> in request or /<walletid>
188 2016-09-22 08:43:09	0|btcdrak|luke-jr why ?wallet=
189 2016-09-22 08:43:31	0|luke-jr|btcdrak: doesn't step on REST stuff, and unlikely to conflict with future extensions
190 2016-09-22 08:44:03	0|btcdrak|well thats not how to build  REST interface
191 2016-09-22 08:44:15	0|jonasschnelli|REST does not support wallet
192 2016-09-22 08:47:07	0|btcdrak|query strings in REST are considered a very poor practice
193 2016-09-22 08:48:23	0|jonasschnelli|query-string are in the same HTTP element (path)
194 2016-09-22 08:48:53	0|jonasschnelli|Modern designs mostly use /<key>/<value> instead or ?<key>=<value>
195 2016-09-22 08:49:02	0|jonasschnelli|Parsing is simpler, browser support better AFAIK
196 2016-09-22 08:58:24	0|GitHub84|13bitcoin/06master 14482f852 15Johnson Lau: Implement NULLDUMMY softfork
197 2016-09-22 08:58:24	0|GitHub84|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7008e28136b5...26b370a93700
198 2016-09-22 08:58:25	0|GitHub84|13bitcoin/06master 1426b370a 15Wladimir J. van der Laan: Merge #8636: Implement NULLDUMMY softfork (BIP147)...
199 2016-09-22 08:58:34	0|GitHub156|[13bitcoin] 15laanwj closed pull request #8636: Implement NULLDUMMY softfork (BIP147) (06master...06nulldummy) 02https://github.com/bitcoin/bitcoin/pull/8636
200 2016-09-22 09:12:34	0|luke-jr|jonasschnelli: pretty sure that violates the URI RFCs :p
201 2016-09-22 10:44:20	0|GitHub101|[13bitcoin] 15MarcoFalke opened pull request #8789: [qa] pull-tester: Only print output when failed (06master...06Mf1609-qaPrintFailedOnly) 02https://github.com/bitcoin/bitcoin/pull/8789
202 2016-09-22 10:52:48	0|GitHub35|[13bitcoin] 15MarcoFalke opened pull request #8790: [test] Remove redundant debug print in addrman_tests (06master...06Mf1609-testsDeletePrint) 02https://github.com/bitcoin/bitcoin/pull/8790
203 2016-09-22 10:56:01	0|btcdrak|Reminder of last weeks' action points before meeting tonight: review #8634 and #8499 and #8526
204 2016-09-22 11:03:57	0|GitHub99|[13bitcoin] 15MarcoFalke opened pull request #8791: [travis] cross-mac: explicitly enable gui (06master...06Mf1609-travisGui) 02https://github.com/bitcoin/bitcoin/pull/8791
205 2016-09-22 12:16:56	0|jonasschnelli|Luke-Jr: why would that violate the URI RFC?
206 2016-09-22 12:17:16	0|jonasschnelli|IMO something like /wallet/<walletid>/getbalance would be perfectly fine.
207 2016-09-22 12:17:33	0|jonasschnelli|though the method in the URI would be against JSONRPC
208 2016-09-22 12:18:11	0|jonasschnelli|but speaking JSONRPC against different URI endpoints looks after a feasible design
209 2016-09-22 12:30:15	0|wumpus|another day, another bunch of OpenSSL advisories https://www.openssl.org/news/secadv/20160922.txt
210 2016-09-22 12:30:57	0|jonasschnelli|*sigh*
211 2016-09-22 12:31:04	0|phantomcircuit|jonasschnelli: optimally cs_wallet would be private
212 2016-09-22 12:31:14	0|jonasschnelli|Happy that our p2p encryption plans and not based on SSL
213 2016-09-22 12:31:23	0|jonasschnelli|phantomcircuit: agree
214 2016-09-22 12:31:42	0|phantomcircuit|the only way for that to happen is for the public methods to acquire the lock
215 2016-09-22 12:31:47	0|jonasschnelli|I think its a bad design that cs_wallet can be (and will) accessed from the outside
216 2016-09-22 12:31:54	0|wumpus|yes, the lock should be private
217 2016-09-22 12:33:29	0|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
218 2016-09-22 12:37:28	0|sipa|wumpus: note that this is about DSA, not ECDSA
219 2016-09-22 12:37:47	0|wumpus|oh that's a different code path? I don't know openssl internals
220 2016-09-22 12:38:54	0|wumpus|I mean it's the same operation on a different group, but they probably made a parallel implementation, okay
221 2016-09-22 12:40:52	0|sipa|yeah, the ecdsa code is separate
222 2016-09-22 12:40:53	0|phantomcircuit|CWalletTx::InMempool
223 2016-09-22 12:40:58	0|phantomcircuit|wtf
224 2016-09-22 12:41:19	0|phantomcircuit|jonasschnelli: why
225 2016-09-22 12:41:21	0|phantomcircuit|WHYY
226 2016-09-22 12:41:30	0|wumpus|which doesn't mean they don't have the same bug there , just waiting to be found :)
227 2016-09-22 12:41:33	0|sipa|phantomcircuit: ?
228 2016-09-22 12:41:57	0|jonasschnelli|phantomcircuit: The current wallet logic need to know that
229 2016-09-22 12:42:01	0|phantomcircuit|sipa: abstraction violation to the max
230 2016-09-22 12:42:07	0|jonasschnelli|But I agree,... couping the wallet with the mempool is bad!
231 2016-09-22 12:42:18	0|wumpus|the wallet is allowed to communicate with the mempool in our case
232 2016-09-22 12:42:34	0|wumpus|this is used for some things such as showing conflicts
233 2016-09-22 12:42:36	0|sipa|phantomcircuit: we can't avoid that without breaking semantics
234 2016-09-22 12:42:47	0|wumpus|I mean: this is a full node wallet, you have the mempool information, why not use it
235 2016-09-22 12:43:01	0|sipa|it can be abstracted more cleanly (install a callback, etc), but functionally we need it, unfortunately
236 2016-09-22 12:43:03	0|jonasschnelli|Yes. But maybe not directly accessing the mempool object. :)
237 2016-09-22 12:43:05	0|wumpus|*the way* of communicating with the mempool may be wrong, that'sa another thing
238 2016-09-22 12:43:11	0|wumpus|right.
239 2016-09-22 12:43:47	0|jonasschnelli|We need to make this more flexible if we once like to have the hybrid SPV mode.
240 2016-09-22 12:44:16	0|jonasschnelli|Which is – sadly – probably far away from being implemented. :)
241 2016-09-22 12:44:41	0|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)
242 2016-09-22 12:44:44	0|wumpus|yes sure, it would need a fallback with the information missing . Like not show unconfirmed transactions at all.
243 2016-09-22 12:45:19	0|wumpus|that's essentially what is the case already during initial sync
244 2016-09-22 12:51:52	0|wumpus|doesn't seem like any of the SSL issues are a serious problem for us
245 2016-09-22 13:15:59	0|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
246 2016-09-22 14:15:49	0|GitHub97|[13bitcoin] 15paveljanik opened pull request #8793: Do not shadow in src/qt (06master...0620160922_Wshadow_qt) 02https://github.com/bitcoin/bitcoin/pull/8793
247 2016-09-22 14:41:28	0|GitHub41|13bitcoin/06master 14b5ccded 15instagibbs: Comment on CConnman::nLocalServices meaning
248 2016-09-22 14:41:28	0|GitHub41|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/26b370a93700...2b514aa2eae6
249 2016-09-22 14:41:29	0|GitHub41|13bitcoin/06master 142b514aa 15Wladimir J. van der Laan: Merge #8785: Comment on CNode::nLocalServices meaning...
250 2016-09-22 14:41:44	0|GitHub82|[13bitcoin] 15laanwj closed pull request #8785: Comment on CNode::nLocalServices meaning (06master...06nlocalservisme) 02https://github.com/bitcoin/bitcoin/pull/8785
251 2016-09-22 14:42:24	0|GitHub168|[13bitcoin] 15paveljanik opened pull request #8794: Enable -Wshadow by default (06master...0620160922_Wshadow_enable) 02https://github.com/bitcoin/bitcoin/pull/8794
252 2016-09-22 15:00:21	0|wumpus|it really should be possible to un-approve pulls, right after pushing submit on #8793 I realized the mistake I made
253 2016-09-22 15:00:37	0|wumpus|it's not even possible to *edit* the approval message
254 2016-09-22 15:00:54	0|paveljanik|I think this functionality is not ready yet...
255 2016-09-22 15:01:13	0|paveljanik|There is no Preview on the approval message etc.
256 2016-09-22 15:01:47	0|wumpus|right, it's more of a public beta
257 2016-09-22 15:02:01	0|wumpus|maybe I should just stop using 'approve'
258 2016-09-22 15:02:29	0|paveljanik|we are all "testing rabbits" - is it the same in English? ;-)
259 2016-09-22 15:02:59	0|achow101|I think you're looking for "lab rats"
260 2016-09-22 15:03:18	0|wumpus|in english it's guinea pigs
261 2016-09-22 15:03:20	0|wumpus|or that
262 2016-09-22 15:03:44	0|wumpus|in dutch it's "proefkonijnen", "testing rabbits"
263 2016-09-22 15:04:14	0|instagibbs|lab rats works in english too :) also easier to spell
264 2016-09-22 15:05:39	0|paveljanik|:-)
265 2016-09-22 15:06:05	0|bsm117532|I think of lab rats as grad students who do the experimentation.  Guinea pigs get experimented upon, as far as colloquial usage goes. ;-)
266 2016-09-22 15:09:34	0|GitHub162|[13bitcoin] 15laudaa opened pull request #8795: [doc] Mention Gitian building script in documents. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/8795
267 2016-09-22 15:10:27	0|wumpus|paveljanik: curious, almost all of the functions that are changes change in the binary
268 2016-09-22 15:10:42	0|wumpus|looking at WalletModel::WalletModel now
269 2016-09-22 15:12:24	0|paveljanik|interesting
270 2016-09-22 15:13:00	0|paveljanik|I still have to investigate's Marco's finding about reverselock's change changing the binary. It was only lock -> _lock...
271 2016-09-22 15:13:33	0|wumpus|looks like some ebp relative local variables change address, but I don't understand, it's really just a variable renaming
272 2016-09-22 15:14:13	0|paveljanik|but only in QT binary
273 2016-09-22 15:14:18	0|paveljanik|bitcoind untouched...
274 2016-09-22 15:14:19	0|wumpus|yes
275 2016-09-22 15:14:31	0|paveljanik|do we compile Qt somehow different?
276 2016-09-22 15:14:50	0|wumpus|I use the same build and comparison process that I use to cmpare bitcoind binaries
277 2016-09-22 15:15:16	0|wumpus|well qt has qrc passes
278 2016-09-22 15:15:27	0|wumpus|moc, I mean
279 2016-09-22 15:16:00	0|wumpus|which automatically generates some code for signal/slot dispatch, property setting, and such
280 2016-09-22 15:16:10	0|wumpus|that may be what happens here, I don't know
281 2016-09-22 15:16:41	0|wumpus|I'll check if this is restricted to consturctors
282 2016-09-22 15:22:13	0|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
283 2016-09-22 15:22:28	0|wumpus|paveljanik: they now refer to the memner variable
284 2016-09-22 15:22:38	0|wumpus|member*
285 2016-09-22 15:22:49	0|wumpus|same for WalletView::setWalletModel
286 2016-09-22 15:23:01	0|wumpus|the otherwise-empty constructors remain a mystery though
287 2016-09-22 15:24:01	0|paveljanik|will fix both...
288 2016-09-22 15:26:06	0|wumpus|ok let me know when you pushed then I'll redo the binaries check
289 2016-09-22 15:26:12	0|paveljanik|done
290 2016-09-22 15:28:20	0|wumpus|building
291 2016-09-22 15:29:33	0|paveljanik|coffee ;-)
292 2016-09-22 15:36:13	0|wumpus|good idea
293 2016-09-22 15:36:23	0|sipa|just had one
294 2016-09-22 15:37:22	0|paveljanik|Kenya AA Top Superstar - macchiato :-)
295 2016-09-22 15:42:23	0|wumpus|paveljanik: that worked, those two functions are gone from the list now - only constructors left
296 2016-09-22 15:43:43	0|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
297 2016-09-22 15:47:52	0|paveljanik|wumpus, yes, thanks for investigation!
298 2016-09-22 15:51:31	0|paveljanik|I'll double check the rest of the functions in the list
299 2016-09-22 15:53:13	0|paveljanik|Hmm, in WalletView::WalletView, I use platformStyle and not _ platformStyle...
300 2016-09-22 15:54:19	0|paveljanik|https://github.com/bitcoin/bitcoin/pull/8793/files#diff-0945de3e3345c5e5c9b39feef7843574R39
301 2016-09-22 16:00:08	0|wumpus|paveljanik: yes, it looks like a similar thing
302 2016-09-22 16:00:27	0|wumpus|I've ruled out moc at least
303 2016-09-22 16:00:42	0|wumpus|compiled the file individually with gcc -S and still see the difference
304 2016-09-22 16:04:01	0|wumpus|paveljanik: this seems to make the differences in AddressBookPage::AddressBookPAge go away http://www.hastebin.com/jixoyufuxu.php
305 2016-09-22 16:04:52	0|paveljanik|I have to say I prefer the usage of member-initialized member variable to an argument in the body of the functions...
306 2016-09-22 16:05:03	0|wumpus|yes, I don't think it's an improvement
307 2016-09-22 16:05:08	0|wumpus|let's just leave it at this
308 2016-09-22 16:05:10	0|wumpus|it's explained
309 2016-09-22 16:05:33	0|paveljanik|well, but this means that binaries will be different :-(
310 2016-09-22 16:06:07	0|wumpus|yes, but we are capable of creating a patch that won't change the binaries, it's just ugly
311 2016-09-22 16:06:18	0|wumpus|+larger
312 2016-09-22 16:06:50	0|paveljanik|but its correct (QED)
313 2016-09-22 16:07:09	0|sipa|i think having a patch available to removes the differences is enough
314 2016-09-22 16:07:19	0|sipa|the changes are trivial anyway
315 2016-09-22 16:07:22	0|wumpus|well I've also reviewed the changes and they look ok, this is just qt anyhow and not consensus code
316 2016-09-22 16:07:28	0|wumpus|right sipa
317 2016-09-22 16:07:33	0|paveljanik|yup
318 2016-09-22 16:20:00	0|JackH|Is there any reason to think that Bitcoin wont eventually be taken over in terms of usage by Ethereum (serious question)
319 2016-09-22 16:20:42	0|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
320 2016-09-22 16:21:12	0|JackH|I am just thinking in terms of opening up Bitcoin, beside fixing malleability, if there is anything on the table?
321 2016-09-22 16:21:49	0|wumpus|#bitcoin
322 2016-09-22 16:22:42	0|JackH|#futureofbitcoin in here? (conceptually)
323 2016-09-22 16:22:48	0|JackH|ah shit
324 2016-09-22 16:22:51	0|JackH|I am not in wizards
325 2016-09-22 16:22:53	0|JackH|sorry
326 2016-09-22 16:23:16	0|JackH|this is akward...
327 2016-09-22 16:23:20	0|wumpus|wizards is about cryptography and moonmath, it's also not the place to discuss comparison to altcoins
328 2016-09-22 17:23:56	0|haakonn|JackH:  eth is the darling of the "blockchain industry", not the payments industry (what can you pay for with ethers?)
329 2016-09-22 17:24:19	0|haakonn|agh, sorry for the noise, thought this was #bitcoin
330 2016-09-22 17:26:07	0|helo|you had me convinced :P
331 2016-09-22 17:49:52	0|instagibbs|when running make check is there a way to get a stack trace on failure
332 2016-09-22 17:50:34	0|instagibbs|error is happening in some helper function, and no useful info about when it's happening
333 2016-09-22 17:54:57	0|GitHub197|[13bitcoin] 15jonnynewbs opened pull request #8796: [trivial] fix mempool comment (outdated by BIP125) (06master...06trivial_comment) 02https://github.com/bitcoin/bitcoin/pull/8796
334 2016-09-22 17:59:51	0|btcdrak|meeting time?
335 2016-09-22 18:00:01	0|instagibbs|in an hour?
336 2016-09-22 18:00:05	0|achow101|you're an hour early
337 2016-09-22 18:00:18	0|btcdrak|oh woops
338 2016-09-22 18:58:20	0|kanzure|btcdrak: i propose we deprecate timezones
339 2016-09-22 18:58:46	0|jcorgan|and DST
340 2016-09-22 18:58:56	0|btcdrak|yes
341 2016-09-22 18:58:59	0|achow101|kanzure: ask IANA
342 2016-09-22 18:59:00	0|murch|kanzure: Yes, let's all just use UTC all year long.
343 2016-09-22 18:59:13	0|btcdrak|achow101: more like ask Trump
344 2016-09-22 18:59:24	0|achow101|Hah!
345 2016-09-22 18:59:25	0|gmaxwell|shh.
346 2016-09-22 18:59:30	0|sipa|murch: another thing we should learn from icelanders
347 2016-09-22 18:59:40	0|cfields|here for meeting, but dog's pacing at the door. Back in ~5.
348 2016-09-22 18:59:43	0|gmaxwell|Don't start a big OT discussion right before the meeting.
349 2016-09-22 18:59:48	0|lightningbot|Meeting started Thu Sep 22 18:59:48 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
350 2016-09-22 18:59:48	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
351 2016-09-22 18:59:48	0|wumpus|#startmeeting
352 2016-09-22 18:59:54	0|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
353 2016-09-22 18:59:56	0|CodeShark|Here
354 2016-09-22 18:59:58	0|jonasschnelli|here
355 2016-09-22 19:00:04	0|btcdrak|jl2012 ping
356 2016-09-22 19:00:11	0|murch|hello
357 2016-09-22 19:00:15	0|sipa|pyng
358 2016-09-22 19:00:17	0|kanzure|hi.
359 2016-09-22 19:00:21	0|sdaftuar|hi
360 2016-09-22 19:00:23	0|paveljanik|peng
361 2016-09-22 19:00:23	0|wumpus|jl2012 probably won't be here this meeting
362 2016-09-22 19:00:54	0|michagogo|May show up in a bit - at dinner with my grandmother atm
363 2016-09-22 19:00:55	0|btcdrak|01110000 01101001 01101110 01100111
364 2016-09-22 19:01:06	0|gmaxwell|our meeting is at an unfriendly time for our contributors in asia/au/nz/etc. Alas.
365 2016-09-22 19:01:10	0|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
366 2016-09-22 19:01:10	0|wumpus|<jl2012> It seems the risks is too much comparing with the benefit
367 2016-09-22 19:01:53	0|wumpus|yes what ever time you pick it's always unfriendly to someone
368 2016-09-22 19:01:54	0|btcdrak|I was discussing this with him yesterday. I also think it should be dropped.
369 2016-09-22 19:02:38	0|btcdrak|wumpus: we should find a time that is unfriendly to everyone :)
370 2016-09-22 19:02:56	0|wumpus|#topic Drop reuse sighash computations across evaluation  #8654 from 0.13.1?
371 2016-09-22 19:02:59	0|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)
372 2016-09-22 19:03:27	0|wumpus|gmaxwell: something else we could do is have e.g. alternating times every week
373 2016-09-22 19:03:48	0|sipa|yes, i'm in favor of dropping it. i believed the advantages were larger first
374 2016-09-22 19:03:49	0|wumpus|but given that people already have a hard time being there intime for a meeting with a fixed time... :-)
375 2016-09-22 19:04:04	0|sipa|but it seems we'll need more changes anyway than we can tolerate for 0.13.1
376 2016-09-22 19:04:08	0|gmaxwell|So re: that PR. We can do it later. We've survived thus far without it.
377 2016-09-22 19:04:13	0|btcdrak|yes.
378 2016-09-22 19:04:17	0|wumpus|ok
379 2016-09-22 19:04:38	0|wumpus|removing 0.13.1 milestone from it
380 2016-09-22 19:04:55	0|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
381 2016-09-22 19:05:19	0|sipa|petertodd: the same
382 2016-09-22 19:05:44	0|petertodd|sipa: but can't you get more checksig ops w/ segwit?
383 2016-09-22 19:05:45	0|sipa|petertodd: as segwit inputs only hash the entire transaction at most once
384 2016-09-22 19:05:57	0|sipa|see bip143
385 2016-09-22 19:06:02	0|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.
386 2016-09-22 19:06:23	0|jtimon|hi
387 2016-09-22 19:06:58	0|sipa|petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block
388 2016-09-22 19:07:04	0|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.
389 2016-09-22 19:07:06	0|petertodd|gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior
390 2016-09-22 19:07:22	0|sipa|petertodd: all sighashing is changed in segwit
391 2016-09-22 19:07:25	0|petertodd|alright, I'm ACK to remove that for 0.13.1
392 2016-09-22 19:07:33	0|wumpus|great
393 2016-09-22 19:07:39	0|petertodd|sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :)
394 2016-09-22 19:08:10	0|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.
395 2016-09-22 19:08:15	0|sipa|petertodd: hmm? they're all changed in a very similar way, with the whole-transaction parts precomputed rather than inlined
396 2016-09-22 19:09:15	0|achow101|are #8634 and #8499 and #8526 ready for merge?
397 2016-09-22 19:09:35	0|wumpus|that's a new topic proposal achow101?
398 2016-09-22 19:09:58	0|achow101|just a question
399 2016-09-22 19:10:01	0|gmaxwell|related topic at least.
400 2016-09-22 19:10:28	0|btcdrak|well they were part of last week's homework
401 2016-09-22 19:10:34	0|wumpus|Add policy: null signature for failed CHECK(MULTI)SIG https://github.com/bitcoin/bitcoin/pull/8634
402 2016-09-22 19:10:54	0|wumpus|Check bad witness and implement several policy limits for segwit scripts https://github.com/bitcoin/bitcoin/pull/8499
403 2016-09-22 19:11:19	0|wumpus|Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH https://github.com/bitcoin/bitcoin/pull/8526
404 2016-09-22 19:11:43	0|CodeShark|The first and last commits for 8634 should be squashed together, have only done limited testing, but the code changes look good
405 2016-09-22 19:12:21	0|CodeShark|Still reviewing 8499
406 2016-09-22 19:13:29	0|wumpus|ok, anyone else with opinion about those pulls?
407 2016-09-22 19:14:47	0|gmaxwell|8634 needs a squash. LGTM.
408 2016-09-22 19:14:57	0|sipa|8499 is a blocker for 0.13.1 for sure
409 2016-09-22 19:15:03	0|achow101|wasn't it decided that 8393 was ready, or just about ready
410 2016-09-22 19:15:05	0|sdaftuar|fyi i'm just starting my review of 8499 now
411 2016-09-22 19:15:07	0|wumpus|looks like #8634 has quite a lot of (u)tACKs
412 2016-09-22 19:15:30	0|sdaftuar|(but don't let me hold thigns up!)
413 2016-09-22 19:16:19	0|wumpus|#action merge #8634 after squashing
414 2016-09-22 19:16:36	0|wumpus|8499 is still very much in progress
415 2016-09-22 19:17:19	0|instagibbs|8393 isn't that hard to review but only a couple people have given acks
416 2016-09-22 19:17:45	0|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)
417 2016-09-22 19:19:56	0|sipa|i'll address the latest nits in 8393
418 2016-09-22 19:20:00	0|wumpus|so anything between those that is ready for merge?
419 2016-09-22 19:20:43	0|btcdrak|We need a few more acks on 8526 but it looks harmless enough as is.
420 2016-09-22 19:21:24	0|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
421 2016-09-22 19:21:36	0|wumpus|this probably means it should be untagged for 0.13.1
422 2016-09-22 19:21:38	0|btcdrak|sipa: I think there are a couple of niggles on the BIP also https://github.com/bitcoin/bips/pull/423
423 2016-09-22 19:21:47	0|jonasschnelli|Yes. No need for 0.13.1
424 2016-09-22 19:21:57	0|sipa|btcdrak: yes, i'm aware
425 2016-09-22 19:22:17	0|wumpus|jonasschnelli: right, if we do that it should be something documented in the release notes of a major release
426 2016-09-22 19:22:24	0|jonasschnelli|ack
427 2016-09-22 19:22:42	0|jonasschnelli|People probably built apps on the "strange" listsinceblock behavior.
428 2016-09-22 19:22:48	0|wumpus|exactly
429 2016-09-22 19:23:13	0|jonasschnelli|remved the 0.13.1 ms from 8757
430 2016-09-22 19:23:18	0|wumpus|okay that leaves four to go
431 2016-09-22 19:23:27	0|BlueMatt|wumpus: wait, we're unmarking compact blocks for 0.13.1?
432 2016-09-22 19:23:32	0|BlueMatt|(you just did)
433 2016-09-22 19:23:32	0|gmaxwell|re the listsince blocks The complaint is that conflicts are always shown and the proposed change made them never shown?
434 2016-09-22 19:23:34	0|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.
435 2016-09-22 19:23:44	0|wumpus|BlueMatt: uh
436 2016-09-22 19:23:47	0|gmaxwell|BlueMatt: wat?
437 2016-09-22 19:23:54	0|BlueMatt|@laanwj laanwj removed this from the 0.13.1 milestone a minute ago
438 2016-09-22 19:23:56	0|instagibbs|er did someone remove the segwit cb?
439 2016-09-22 19:23:56	0|wumpus|that was a mistake
440 2016-09-22 19:23:58	0|BlueMatt|I assume that was accidental
441 2016-09-22 19:24:00	0|wumpus|please readd
442 2016-09-22 19:24:06	0|BlueMatt|#8393
443 2016-09-22 19:24:16	0|gmaxwell|unclick
444 2016-09-22 19:24:27	0|BlueMatt|ok, so 5 to go
445 2016-09-22 19:24:33	0|jonasschnelli|readded
446 2016-09-22 19:24:47	0|instagibbs|4 PRs, one related issue
447 2016-09-22 19:24:52	0|sipa|you take one down, pass it around, 5 PR to g
448 2016-09-22 19:25:20	0|Chris_Stewart_5|exponential PR blow up
449 2016-09-22 19:25:22	0|btcdrak|There is also this nice project https://github.com/bitcoin/bitcoin/projects/5
450 2016-09-22 19:25:27	0|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
451 2016-09-22 19:26:13	0|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
452 2016-09-22 19:26:15	0|BlueMatt|same with 8634
453 2016-09-22 19:26:56	0|paveljanik|wumpus, nice!
454 2016-09-22 19:27:08	0|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
455 2016-09-22 19:27:13	0|gmaxwell|minor meta aside, is there any facility for backing up and retaining all this new github stuff?
456 2016-09-22 19:27:33	0|BlueMatt|gmaxwell: havent looked, but the github api has historically been very, very complete
457 2016-09-22 19:27:40	0|BlueMatt|so i ass-u-me so?
458 2016-09-22 19:27:42	0|wumpus|gmaxwell: that's iwilcox's department (but he's not here)
459 2016-09-22 19:28:18	0|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
460 2016-09-22 19:28:21	0|gmaxwell|BlueMatt: 8526 when it goes SF could plausably conficate coins, so it's more important to have it non-standard from the getgo.
461 2016-09-22 19:28:53	0|gmaxwell|and 8634 is done but for a squash as far as I can tell.
462 2016-09-22 19:29:24	0|wumpus|already created an action for #8634, we're repeating ourselves
463 2016-09-22 19:29:26	0|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
464 2016-09-22 19:29:27	0|btcdrak|gmaxwell: the github API supports all this new stuff https://developer.github.com/v3/repos/projects/
465 2016-09-22 19:29:45	0|BlueMatt|(ie lets start looking for date consensus like...soon)
466 2016-09-22 19:29:55	0|achow101|like.. now?
467 2016-09-22 19:30:01	0|sipa|no, not now
468 2016-09-22 19:30:06	0|instagibbs|achow101: no, after critical updates are merged
469 2016-09-22 19:30:11	0|sipa|first know when we can possibly have a release
470 2016-09-22 19:30:14	0|BlueMatt|like...in a few days after the non-critical ones are merged
471 2016-09-22 19:30:14	0|btcdrak|BlueMatt: well we need #8393 merged too before we can be sure to set dates
472 2016-09-22 19:30:37	0|BlueMatt|btcdrak: sure, fine, #8393, #8279, and #8499, then dates?
473 2016-09-22 19:30:50	0|btcdrak|ack
474 2016-09-22 19:30:56	0|sdaftuar|i believe 8279 is sufficiently resolved for 0.13.1
475 2016-09-22 19:31:11	0|gmaxwell|BlueMatt: do we know what the status of btcd's SW support is?
476 2016-09-22 19:31:11	0|wumpus|let's try to finish those pulls this week then we can talk about the release next meeting
477 2016-09-22 19:31:23	0|BlueMatt|gmaxwell: thats part of soliciting consensus on dates :p
478 2016-09-22 19:31:24	0|btcdrak|ping roasbeef
479 2016-09-22 19:31:31	0|BlueMatt|(ie reaching out to non-bitcoin core people)
480 2016-09-22 19:31:46	0|gmaxwell|BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs.
481 2016-09-22 19:31:46	0|instagibbs|wumpus: ack
482 2016-09-22 19:32:03	0|wumpus|sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it
483 2016-09-22 19:32:13	0|sdaftuar|wumpus: sounds good to me
484 2016-09-22 19:32:28	0|sipa|wumpus: sounds good
485 2016-09-22 19:32:56	0|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".
486 2016-09-22 19:34:59	0|gmaxwell|BlueMatt: in any case, out of meeting lets try to work on a list of required actions for the activation.
487 2016-09-22 19:35:14	0|wumpus|makes sense to reach out to them then
488 2016-09-22 19:35:22	0|btcdrak|well in terms of wallet code and supporting libraries, there are many which are SW ready, or have it almost ready to go.
489 2016-09-22 19:35:34	0|gmaxwell|yes.
490 2016-09-22 19:35:35	0|petertodd|python-bitcoinlib has a fairly good pull-req for segwit
491 2016-09-22 19:35:45	0|wumpus|awesome
492 2016-09-22 19:36:08	0|gmaxwell|mining software was in a sad state last time I checked, but I know things have improved a lot.
493 2016-09-22 19:37:03	0|gmaxwell|in any case, many things to discuss there that don't need everyone. :)
494 2016-09-22 19:37:07	0|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)
495 2016-09-22 19:37:33	0|petertodd|roasbeef: +1
496 2016-09-22 19:37:34	0|roasbeef|primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff
497 2016-09-22 19:37:36	0|gmaxwell|roasbeef: fantastic.
498 2016-09-22 19:38:00	0|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.
499 2016-09-22 19:39:15	0|achow101|armory is.. getting there. We're aiming for the release after the next to have full segwit support
500 2016-09-22 19:39:44	0|petertodd|achow101: thanks!
501 2016-09-22 19:39:47	0|gmaxwell|achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing.
502 2016-09-22 19:40:04	0|btcdrak|oh I didnt know you work on Armory achow101 +1
503 2016-09-22 19:40:22	0|CodeShark|my stuff is almost 100% segwit ready, just need merkle proofs for witnesses in filtered blocks or some better SPV solution
504 2016-09-22 19:40:47	0|petertodd|gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :)
505 2016-09-22 19:40:57	0|gmaxwell|It's just good to hear that more things are almost read, as it's another angle of testing.
506 2016-09-22 19:41:26	0|Chris_St1|CodeShark: What BIP is that related to?
507 2016-09-22 19:41:51	0|CodeShark|We don't have a BIP yet, I don't think
508 2016-09-22 19:41:53	0|sipa|Chris_St1: that will need a new bip
509 2016-09-22 19:42:27	0|sipa|it's trivial (just combine bip37 with bip141 wtxids)
510 2016-09-22 19:42:33	0|Chris_St1|ok, gotcha.
511 2016-09-22 19:42:34	0|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)
512 2016-09-22 19:42:50	0|sipa|but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further
513 2016-09-22 19:43:12	0|CodeShark|I'd prefer a replacement to bip37, but that's more involved
514 2016-09-22 19:43:14	0|Chris_St1|BIP37 is definitely a monster in terms of implementation... or atleast it was for me
515 2016-09-22 19:43:15	0|gmaxwell|We could probably do better.
516 2016-09-22 19:43:56	0|sipa|at least we could propose to drop some of the auto-inserting that causes false positive rate blowup
517 2016-09-22 19:43:57	0|petertodd|note that it's reasonable to ask for a full block even if you are a lite-client in many cases
518 2016-09-22 19:44:29	0|BlueMatt|CodeShark: uhhhhhhhhh, that sounds like a blocker
519 2016-09-22 19:44:33	0|gmaxwell|petertodd: Satoshi's vision.
520 2016-09-22 19:44:35	0|btcdrak|petertodd: such as?
521 2016-09-22 19:44:50	0|jtimon|I guess he means as a way to get more privacy?
522 2016-09-22 19:44:54	0|sipa|BlueMatt: how so?
523 2016-09-22 19:45:06	0|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
524 2016-09-22 19:45:07	0|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.
525 2016-09-22 19:45:07	0|petertodd|no, I just mean that the data increase is relatively low
526 2016-09-22 19:45:08	0|jtimon|no tevealing which txs you care about? just thinking out loud...
527 2016-09-22 19:45:23	0|sipa|BlueMatt: spv wallets shouldn't care about the witness data
528 2016-09-22 19:45:55	0|sipa|hell, it's an advantage that their bandwidth will drop
529 2016-09-22 19:45:57	0|petertodd|sipa: indeed, they can't verify that the witness is valid
530 2016-09-22 19:46:09	0|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.
531 2016-09-22 19:46:10	0|CodeShark|wallets that don't tell you who signed a multisig are incomplete ;)
532 2016-09-22 19:46:34	0|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.
533 2016-09-22 19:46:38	0|petertodd|CodeShark: well, that's an example where you can request a full block - not many wallets need to actually know that
534 2016-09-22 19:46:54	0|petertodd|CodeShark: as an example, I don't think GreenAddress will tell you who actually signed txs in a GA wallet
535 2016-09-22 19:47:12	0|CodeShark|it's critical for enterprise applications
536 2016-09-22 19:47:21	0|CodeShark|Accountability is important
537 2016-09-22 19:47:23	0|petertodd|CodeShark: enterprise can afford some extra bandwidth I'm sure :)
538 2016-09-22 19:47:29	0|achow101|I think we're getting OT
539 2016-09-22 19:47:32	0|petertodd|CodeShark: this isn't a blocker is all I'm saying
540 2016-09-22 19:47:46	0|CodeShark|we can revisit this after 0.13.1
541 2016-09-22 19:47:49	0|gmaxwell|It's also not news or an accident.
542 2016-09-22 19:48:01	0|wumpus|no one is considering it is a blocker except for BlueMatt
543 2016-09-22 19:48:04	0|petertodd|CodeShark: ack
544 2016-09-22 19:48:28	0|BlueMatt|gmaxwell: sure, I'm saying that you cant use segwit as an spv client
545 2016-09-22 19:48:36	0|sipa|BlueMatt: of course you can?
546 2016-09-22 19:48:39	0|gmaxwell|BlueMatt: thats not true.
547 2016-09-22 19:49:01	0|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
548 2016-09-22 19:49:05	0|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
549 2016-09-22 19:49:09	0|BlueMatt|which you might want to
550 2016-09-22 19:49:22	0|BlueMatt|petertodd: you already do that, the malleability doesnt help
551 2016-09-22 19:49:31	0|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?
552 2016-09-22 19:49:38	0|petertodd|BlueMatt: true, once confirmed
553 2016-09-22 19:49:52	0|jtimon|Chris_St1: the former
554 2016-09-22 19:49:52	0|wumpus|Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1
555 2016-09-22 19:49:53	0|petertodd|BlueMatt: I take back that comment
556 2016-09-22 19:50:22	0|petertodd|anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1
557 2016-09-22 19:50:25	0|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.
558 2016-09-22 19:50:48	0|BlueMatt|gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to
559 2016-09-22 19:51:03	0|sipa|i think there was no reason for that, indeed
560 2016-09-22 19:51:07	0|BlueMatt|but it is the case that you lose this property of matching pubkeys which were used
561 2016-09-22 19:51:10	0|sipa|and if there is, we can still add it back
562 2016-09-22 19:51:17	0|BlueMatt|sipa: well, you might want it, but not a ton
563 2016-09-22 19:51:19	0|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.
564 2016-09-22 19:51:22	0|petertodd|I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority
565 2016-09-22 19:51:23	0|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
566 2016-09-22 19:51:37	0|Chris_St1|BlueMatt: Matching scriptSig constants in BIP37 right?
567 2016-09-22 19:52:00	0|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
568 2016-09-22 19:52:02	0|wumpus|BIP37 can be extended, sure
569 2016-09-22 19:52:17	0|BlueMatt|Chris_St1: bip37 only ever matches constants
570 2016-09-22 19:52:18	0|wumpus|but that's not yet another reason to move forward the release
571 2016-09-22 19:52:28	0|BlueMatt|agreed
572 2016-09-22 19:52:34	0|achow101|topic proposal: alert system retirement
573 2016-09-22 19:52:43	0|gmaxwell|AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P
574 2016-09-22 19:52:45	0|instagibbs|8 minutes left
575 2016-09-22 19:52:48	0|BlueMatt|we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting
576 2016-09-22 19:53:00	0|BlueMatt|gmaxwell: yup
577 2016-09-22 19:53:01	0|gmaxwell|BlueMatt: yup.
578 2016-09-22 19:53:12	0|CodeShark|I want a good fairly secure quick sync solution. BIP37 sucks :p
579 2016-09-22 19:53:25	0|gmaxwell|second on achow101's topic.
580 2016-09-22 19:53:28	0|petertodd|CodeShark: sure, fiber-to-the-home :)
581 2016-09-22 19:53:33	0|CodeShark|But we'll do that after 0.13.1
582 2016-09-22 19:53:34	0|petertodd|gmaxwell: ack
583 2016-09-22 19:53:34	0|wumpus|#topic  alert system retirement
584 2016-09-22 19:54:11	0|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.
585 2016-09-22 19:54:39	0|petertodd|gmaxwell: sounds like it's time to set dates
586 2016-09-22 19:54:41	0|gmaxwell|My view on the next steps:
587 2016-09-22 19:54:55	0|gmaxwell|(1) Create a bitcoincore.org or bitcoin.org announcement message.
588 2016-09-22 19:55:16	0|gmaxwell|(2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it.
589 2016-09-22 19:55:27	0|gmaxwell|(3) much later, send final alert.
590 2016-09-22 19:55:46	0|wumpus|I'd say we send the final alert with the 0.14 release
591 2016-09-22 19:55:58	0|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)
592 2016-09-22 19:56:09	0|wumpus|then include code in there to send it to old peers that connect, as gmaxwell says
593 2016-09-22 19:56:29	0|BlueMatt|gmaxwell: ACK
594 2016-09-22 19:56:36	0|BlueMatt|wumpus: ACK final alert with 0.14
595 2016-09-22 19:56:48	0|jtimon|ack
596 2016-09-22 19:56:49	0|achow101|ack
597 2016-09-22 19:56:52	0|petertodd|gmaxwell: and release the privkey for the alert key w/ the final alert?
598 2016-09-22 19:56:54	0|btcdrak|ack
599 2016-09-22 19:57:03	0|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.
600 2016-09-22 19:57:08	0|sipa|i'd release the key later even
601 2016-09-22 19:57:10	0|petertodd|gmaxwell: ack
602 2016-09-22 19:57:17	0|instagibbs|make sure to sweep the funds people have sent to the key :P
603 2016-09-22 19:57:26	0|petertodd|instagibbs: ha
604 2016-09-22 19:57:28	0|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)
605 2016-09-22 19:57:36	0|BlueMatt|sipa: ack
606 2016-09-22 19:57:52	0|sipa|there may be alternate codebases that use the key who want to do something similar to (3) and (4)
607 2016-09-22 19:58:10	0|sipa|oh, wait
608 2016-09-22 19:58:17	0|sipa|they need the key for that
609 2016-09-22 19:58:24	0|BlueMatt|2 min
610 2016-09-22 19:58:32	0|instagibbs|any pressing topics
611 2016-09-22 19:58:37	0|wumpus|well after the final alert is sent, the key is only historical curiosity
612 2016-09-22 19:58:42	0|gmaxwell|okay, I'll send a message to the list.
613 2016-09-22 19:58:47	0|luke-jr|can the final alert match all clients?
614 2016-09-22 19:59:05	0|wumpus|luke-jr: you mean the pre-final alert, and yes
615 2016-09-22 19:59:07	0|petertodd|wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm
616 2016-09-22 19:59:15	0|gmaxwell|It cann't not match all clients.
617 2016-09-22 19:59:30	0|wumpus|gmaxwell: I think he means the penultimate alert
618 2016-09-22 19:59:45	0|wumpus|obviously the final alert matches all clients, at least those that still parse alerts
619 2016-09-22 20:00:01	0|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/"
620 2016-09-22 20:00:23	0|wumpus|gmaxwell: wasn't that the point in adding it to the client?
621 2016-09-22 20:00:30	0|gmaxwell|I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions.
622 2016-09-22 20:00:40	0|petertodd|gmaxwell: sure, but that'll have been after months of alert - I'm not worried there
623 2016-09-22 20:00:52	0|wumpus|it applies to everyone using the key, not just users of bitcoin core
624 2016-09-22 20:00:53	0|gmaxwell|in any case, can continue after, we should wrap the meeting. :)
625 2016-09-22 20:00:58	0|petertodd|gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert
626 2016-09-22 20:01:00	0|instagibbs|ding ding
627 2016-09-22 20:01:01	0|btcdrak|ding ding ding
628 2016-09-22 20:01:02	0|wumpus|yes it's time
629 2016-09-22 20:01:04	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.log.html
630 2016-09-22 20:01:04	0|lightningbot|Meeting ended Thu Sep 22 20:01:03 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
631 2016-09-22 20:01:04	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.html
632 2016-09-22 20:01:04	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.txt
633 2016-09-22 20:01:04	0|wumpus|#endmeeting
634 2016-09-22 20:01:05	0|sipa|bye
635 2016-09-22 20:01:20	0|wumpus|agree petertodd
636 2016-09-22 20:01:43	0|wumpus|this is not bitcoin core specific but everyone-that-embeds-that-pubkey specific
637 2016-09-22 20:01:51	0|Chris_Stewart_5|CodeShark: Did you have any concrete ideas for improving on BIP37?
638 2016-09-22 20:01:57	0|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.
639 2016-09-22 20:02:21	0|petertodd|gmaxwell: I think the upgrade advice can be general "whatever you are running, upgade"
640 2016-09-22 20:02:39	0|petertodd|gmaxwell: equally, it can just be a warning that you will soon see a final alert, as the alert system is being depreciated
641 2016-09-22 20:02:49	0|wumpus|yes, it can just be a warning about the alert
642 2016-09-22 20:02:58	0|wumpus|it doesn't really have to tell to upgrade
643 2016-09-22 20:03:05	0|wumpus|just make sure peopel are aware
644 2016-09-22 20:03:10	0|btcdrak|that's a good idea
645 2016-09-22 20:03:16	0|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.
646 2016-09-22 20:03:21	0|CodeShark|Chris_Stewart_5: proposals to put the filters in the blocks themselves seem at least slightly more promising
647 2016-09-22 20:03:56	0|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.
648 2016-09-22 20:05:16	0|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
649 2016-09-22 20:05:26	0|petertodd|gmaxwell: otherwise if we add another segwit-like thing we need a new filter
650 2016-09-22 20:05:34	0|gmaxwell|petertodd: bandwidth overhead in that however.
651 2016-09-22 20:05:47	0|gmaxwell|because then you have to send the filter between full nodes. yuck.
652 2016-09-22 20:05:52	0|CodeShark|UTXO commitments + getutxos would probably be the quickest sync option that isn't totally insecure
653 2016-09-22 20:05:53	0|instagibbs|is the bitcoin wiki down for others for the last few days?
654 2016-09-22 20:05:58	0|petertodd|gmaxwell: true, though wasn't it only a few KB?
655 2016-09-22 20:06:25	0|CodeShark|Privacy issues are still a problem, though
656 2016-09-22 20:06:38	0|petertodd|CodeShark: I don't think we can reasonably implement UTXO commitments
657 2016-09-22 20:07:05	0|gmaxwell|there are also many other options for scanning, including ones that are private, like via PIR lookup.
658 2016-09-22 20:07:24	0|Chris_Stewart_5|Thanks gmaxwell, CodeShark, will read.
659 2016-09-22 20:07:34	0|petertodd|and it'd be good for some of those options to be implemented via central services first to prototype
660 2016-09-22 20:08:28	0|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.
661 2016-09-22 20:09:18	0|petertodd|and a central service can be audited easily enough to detect censorship (assuming clients connect anonymously)
662 2016-09-22 20:09:34	0|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.
663 2016-09-22 20:09:38	0|petertodd|or actually, commit to the contents of the filter, and then provide the filter
664 2016-09-22 20:09:54	0|petertodd|gmaxwell: true
665 2016-09-22 20:09:57	0|gmaxwell|petertodd: right you could talk to N hosts, and find that they all give the same commitment value.
666 2016-09-22 20:10:11	0|gmaxwell|without having to fetch the filter N times.
667 2016-09-22 20:10:35	0|gmaxwell|or even connect to one host and get a commitment signed by N parties.
668 2016-09-22 20:10:36	0|petertodd|gmaxwell: add a signature on the commitment and that should be enough
669 2016-09-22 20:10:59	0|gmaxwell|right.
670 2016-09-22 20:11:18	0|CodeShark|Thing is all these proposals significantly complicate client implementations
671 2016-09-22 20:11:36	0|petertodd|CodeShark: well, privacy is hard :)
672 2016-09-22 20:11:41	0|gmaxwell|checking a signature is not complex. :P
673 2016-09-22 20:12:04	0|gmaxwell|in any case, it's foolish to think we can design for forever in a single step; we must have incremental stepping stones.
674 2016-09-22 20:12:05	0|CodeShark|Ultimately, we need client implementations to be relatively simple or centralized API services will domimate
675 2016-09-22 20:12:12	0|CodeShark|*dominate
676 2016-09-22 20:12:28	0|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
677 2016-09-22 20:13:16	0|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
678 2016-09-22 20:13:51	0|CodeShark|or at the least we need some solid client-side libraries with multiple language bindings
679 2016-09-22 20:14:09	0|petertodd|CodeShark: does bloom filters even have that? :)
680 2016-09-22 20:14:35	0|petertodd|CodeShark: python-bitcoinlib *still* doesn't have a full bloom filter implementation - I've never had anyone interested in using it
681 2016-09-22 20:14:50	0|CodeShark|petertodd: only the true diehards even attempt to use bloom filters rather than, say, bc.i :p
682 2016-09-22 20:15:10	0|petertodd|CodeShark: indeed - python-bitcoinlib is likely used 99% of the time with a local copy of Bitcoin Core
683 2016-09-22 20:15:27	0|gmaxwell|bc.i has better privacy than bloomfilters, IMO.
684 2016-09-22 20:16:05	0|CodeShark|but it's still a single point of failure
685 2016-09-22 20:16:28	0|petertodd|CodeShark: then use the Electrum servers! :)
686 2016-09-22 20:16:38	0|CodeShark|Argh - lol
687 2016-09-22 20:17:56	0|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
688 2016-09-22 20:18:11	0|CodeShark|I run multiple bitcoin core instances and reluctantly use bip37
689 2016-09-22 20:18:13	0|luke-jr|http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf
690 2016-09-22 20:18:58	0|CodeShark|I get around the privacy and censorship issues by running my own instances
691 2016-09-22 20:19:30	0|CodeShark|Electrum is just an additional dependency I don't want
692 2016-09-22 20:24:22	0|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
693 2016-09-22 20:24:58	0|luke-jr|if we merge script indexes, should probably do some p2p replacement for Electrum's protocol <.<
694 2016-09-22 20:27:13	0|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
695 2016-09-22 20:28:03	0|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.
696 2016-09-22 20:29:43	0|CodeShark|Then perhaps we need a different application model as well
697 2016-09-22 20:33:52	0|morcos|cfields: what happened to: https://github.com/theuni/bitcoin/tree/copy-move ?
698 2016-09-22 20:34:12	0|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
699 2016-09-22 20:35:17	0|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.
700 2016-09-22 20:36:41	0|luke-jr|always annoying when people hear "I'm running Bitcoin Core" and their immediate reply is "you should switch to Electrum!"
701 2016-09-22 20:37:01	0|gmaxwell|more than a little frightening too.
702 2016-09-22 20:38:46	0|gmaxwell|wumpus: what happened with the work on SSE sha2 and asm for the CRC32?
703 2016-09-22 20:39:10	0|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
704 2016-09-22 20:39:50	0|gmaxwell|wumpus: if you were disappointed at the fairly modest improvement, I expect it will be much better post the checkqueue changes.
705 2016-09-22 20:40:07	0|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
706 2016-09-22 20:50:04	0|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?
707 2016-09-22 20:51:20	0|luke-jr|that was before addresses
708 2016-09-22 20:51:33	0|luke-jr|(and raw multisig was never common use)
709 2016-09-22 20:52:02	0|luke-jr|if you wanted to pay someone, you put in their IP and your client connected to them for a script
710 2016-09-22 20:53:33	0|Chris_Stewart_5|Interesting, I guess i'm conflating addresses and actually spending scriptPubKeys.
711 2016-09-22 20:55:29	0|Chris_Stewart_5|luke-jr: Was that functionality inside of Bitcoin Core? Inputing their ip address?
712 2016-09-22 20:55:58	0|luke-jr|Chris_Stewart_5: this was before Bitcoin Core's time, and also before my time :p
713 2016-09-22 20:56:31	0|luke-jr|Bitcoin started off with a wxWidgets Windows-only GUI client which was abandoned a long time ago
714 2016-09-22 20:56:52	0|Chris_Stewart_5|Haha fair enough, guess i'm getting more into history instead of development any way
715 2016-09-22 20:59:39	0|morcos|cfields: i'd love to double down, but will have to wait til tomorrow
716 2016-09-22 21:01:56	0|cfields|morcos: ok, will push there later. sanity checking now.
717 2016-09-22 21:36:39	0|luke-jr|FWIW, C++11 is de facto causing ABI issues on Gentoo (but probably not significant enough to regret the move)
718 2016-09-22 21:37:54	0|luke-jr|mostly due to GCC 4.9 vs 5 mixing it seems
719 2016-09-22 21:38:47	0|sipa|*gentoo
720 2016-09-22 21:38:47	0|sipa|i would expect to be the one distro that doesn't suffer from such issues :)
721 2016-09-22 21:40:18	0|luke-jr|sipa: tends to be the most likely to hit issues; binary distros just rebuild everything when ABIs change :p
722 2016-09-22 22:55:20	0|gmaxwell|Re PR #8661 is there a reason that this isn't getting merged?