12016-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
22016-09-22T00:56:55 *** Ylbam has quit IRC
32016-09-22T01:05:05 *** xinxi has quit IRC
42016-09-22T01:05:14 *** jnewbery has quit IRC
52016-09-22T01:06:52 *** xinxi has joined #bitcoin-core-dev
62016-09-22T01:14:13 *** xinxi has quit IRC
72016-09-22T01:15:16 *** Alopex has quit IRC
82016-09-22T01:16:21 *** Alopex has joined #bitcoin-core-dev
92016-09-22T01:22:01 *** xinxi has joined #bitcoin-core-dev
102016-09-22T01:22:46 *** jl2012 has joined #bitcoin-core-dev
112016-09-22T01:26:55 *** xinxi has quit IRC
122016-09-22T01:27:10 *** shesek has quit IRC
132016-09-22T01:27:14 *** xinxi has joined #bitcoin-core-dev
142016-09-22T01:27:22 *** arubi has quit IRC
152016-09-22T01:28:11 *** xinxi has quit IRC
162016-09-22T01:28:44 *** xinxi has joined #bitcoin-core-dev
172016-09-22T01:30:21 *** echonaut has quit IRC
182016-09-22T01:30:40 *** echonaut has joined #bitcoin-core-dev
192016-09-22T01:32:30 *** arubi has joined #bitcoin-core-dev
202016-09-22T01:34:06 *** shesek has joined #bitcoin-core-dev
212016-09-22T01:38:47 <wumpus> can we please stop doing the copyright pulls where half of github is highlightes
222016-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
232016-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.
242016-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?
252016-09-22T01:45:40 *** Chris_Stewart_5 has quit IRC
262016-09-22T01:45:44 <gmaxwell> achow101: that is unlear though it could be made clear.
272016-09-22T01:46:15 <wumpus> I don't know, but this getting out of hand
282016-09-22T01:46:42 <achow101> I though that was just kind of "in general" for all OSS projects
292016-09-22T01:46:43 <wumpus> achow101: that is what I always thought too
302016-09-22T01:46:50 <wumpus> there is a COPYING file in the rot of the repository
312016-09-22T01:46:54 <wumpus> root*
322016-09-22T01:47:07 <wumpus> if you don't put an explicit license in a file, that is what it is bound to
332016-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?
342016-09-22T01:47:57 <wumpus> what is this accomplishing?
352016-09-22T01:48:44 <wumpus> and yes, asking per email would have been preferable. Asking once per contributor, too. If that is really necessary.
362016-09-22T01:48:50 <wumpus> but we're not relicencing the project
372016-09-22T01:48:58 <wumpus> it has ALWAYS been MIT
382016-09-22T01:49:03 <wumpus> satoshi made it MIT
392016-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
402016-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
412016-09-22T01:50:53 <wumpus> and that was for real contributions not changing the case of one letter in one file
422016-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"
432016-09-22T01:56:49 <wumpus> not the last part
442016-09-22T01:57:09 <wumpus> only "By contributing to this repository, you agree to license your work under the MIT license"
452016-09-22T01:57:18 <achow101> ok.
462016-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.
472016-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 ...
482016-09-22T02:00:25 <GitHub82> [bitcoin] achow101 opened pull request #8786: Mandatory copyright agreement (master...copyright-contributing) https://github.com/bitcoin/bitcoin/pull/8786
492016-09-22T02:02:24 *** DigiByteDev has joined #bitcoin-core-dev
502016-09-22T02:13:17 *** midnightmagic has quit IRC
512016-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
522016-09-22T02:30:16 <wumpus> yes we should make it explicitl
532016-09-22T02:30:27 <wumpus> see https://github.com/bitcoin/bitcoin/pull/8786
542016-09-22T02:30:30 <achow101> well my PR makes it explicit
552016-09-22T02:30:34 <wumpus> yes
562016-09-22T02:32:35 <luke-jr> and hopefully people will stop submitting non-licensed code without getting permission first <.<
572016-09-22T02:32:51 <wumpus> such as?
582016-09-22T02:32:57 <luke-jr> wumpus: l_atomic.m4 until today
592016-09-22T02:33:28 <wumpus> let's revert it then?
602016-09-22T02:33:31 <luke-jr> came from a GPL-licensed project, with no license on the build stuff
612016-09-22T02:33:33 <luke-jr> nah
622016-09-22T02:33:39 <luke-jr> already got an ACK from the author for MIT terms
632016-09-22T02:34:32 <luke-jr> just something to keep in mind when stuff gets contributed by someone other than the original author
642016-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
652016-09-22T02:36:53 <luke-jr> +1
662016-09-22T02:39:14 <wumpus> hey, github review comments don't show as comments in the pull list
672016-09-22T02:39:26 <luke-jr> O.o
682016-09-22T02:39:29 <wumpus> I've approved https://github.com/bitcoin/bitcoin/pull/8783 but it still shows as 0
692016-09-22T02:40:04 <wumpus> unless I have an unrelated web caching issue, that happens
702016-09-22T02:40:11 <kanzure> ouch is "approved" github's terminology? ok.
712016-09-22T02:40:21 <achow101> How about "Any code contributed where you are not the original author must contain its license header"
722016-09-22T02:40:45 <wumpus> yes makes sense achow101
732016-09-22T02:40:57 <achow101> wumpus: I see your approval on 8783
742016-09-22T02:41:02 <wumpus> kanzure: indeed, I wouldn't have used that word myself
752016-09-22T02:41:16 <achow101> I think it's your browser
762016-09-22T02:41:21 <kanzure> wumpus: that's going to cause confusion. oh well.
772016-09-22T02:41:32 <luke-jr> can we get Travis to check for a copyright line on new files maybe?
782016-09-22T02:42:02 <wumpus> achow101: yes I see it too in the topic itself, but do you see it in the overview list?
792016-09-22T02:42:34 <wumpus> there's this comment icon and then a count, there's no count for #8783 here. Ohwell.
802016-09-22T02:43:09 <achow101> oh that. No I don't see that
812016-09-22T02:44:40 <wumpus> luke-jr: that's certainly possible
822016-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
832016-09-22T02:45:30 <wumpus> +report
842016-09-22T02:46:27 <wumpus> it's a pretty good suggestion, could even parse debian/copyright for the copyright metadata on binary files
852016-09-22T02:46:37 <wumpus> I don't have time for those things though :)
862016-09-22T02:50:16 *** xinxi has quit IRC
872016-09-22T03:09:04 *** crudel has joined #bitcoin-core-dev
882016-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
892016-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?
902016-09-22T03:27:21 <achow101> wumpus: watch https://www.youtube.com/watch?v=C6MGKHkNtxU
912016-09-22T03:28:06 <roasbeef> it's basically like trello embedded within github
922016-09-22T03:29:13 <achow101> also read https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects/
932016-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
942016-09-22T03:33:13 <achow101> AFAICT, yes, you can use it for grouping related issues and PR's
952016-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
962016-09-22T03:35:28 <achow101> Stuff can be in multiple projects, and within projects are additional sub groupings (called columns)
972016-09-22T03:39:36 <wumpus> thanks, looks somewhat like hwat I'm looking for then, I'll read on about it
982016-09-22T03:47:13 *** randy-waterhouse has joined #bitcoin-core-dev
992016-09-22T03:48:18 *** randy-waterhouse has joined #bitcoin-core-dev
1002016-09-22T03:48:48 *** YOU-JI has joined #bitcoin-core-dev
1012016-09-22T03:49:15 *** YOU-JI has joined #bitcoin-core-dev
1022016-09-22T03:50:49 * luke-jr wonders if projects are accessible to non-committers
1032016-09-22T03:50:54 *** xinxi has joined #bitcoin-core-dev
1042016-09-22T03:51:30 <achow101> luke-jr: can you access the projects here: https://github.com/achow101/ProtectedBranchTest/projects ?
1052016-09-22T03:52:32 <luke-jr> I can see them, but it seems I cannot submit an issue to a specific project
1062016-09-22T03:54:05 *** YOU-JI has quit IRC
1072016-09-22T03:54:21 <achow101> right, I think it's more for internal organization for the committers
1082016-09-22T03:54:53 <achow101> just like how you can't do labels or milestones if you aren't part of the group
1092016-09-22T03:58:03 *** xinxi has quit IRC
1102016-09-22T04:00:44 <sipa_> wumpus: you're up early
1112016-09-22T04:01:21 <sipa_> i briefly feared i was in the wrong timezone
1122016-09-22T04:05:19 <wumpus> achow101: seems to work fairly well https://github.com/bitcoin/bitcoin/projects/1
1132016-09-22T04:05:23 <wumpus> sipa_: hah yes couldn't sleep
1142016-09-22T04:06:22 <achow101> :D
1152016-09-22T04:16:06 *** moli has quit IRC
1162016-09-22T04:21:07 *** sipa_ has quit IRC
1172016-09-22T04:23:31 *** sipa has joined #bitcoin-core-dev
1182016-09-22T04:23:42 <sipa> wumpus: those projects look useful
1192016-09-22T04:23:52 <wumpus> indeed!
1202016-09-22T04:24:06 <sipa> especially if we'd actually maintain them, it could simplify things like writinf release notes as well
1212016-09-22T04:25:08 <sipa> "PRs #1234, #2345, #3456, #4567 and #5678 together replaced the outdated PoW system"
1222016-09-22T04:26:36 <wumpus> yes, that could be an advantage as well
1232016-09-22T04:33:37 *** moli has joined #bitcoin-core-dev
1242016-09-22T04:55:12 *** xinxi has joined #bitcoin-core-dev
1252016-09-22T04:59:54 *** xinxi has quit IRC
1262016-09-22T05:01:37 *** DigiByteDev has quit IRC
1272016-09-22T05:04:18 *** DigiByteDev has joined #bitcoin-core-dev
1282016-09-22T05:06:11 *** Alopex has quit IRC
1292016-09-22T05:07:03 *** DigiByteDev has joined #bitcoin-core-dev
1302016-09-22T05:07:17 *** Alopex has joined #bitcoin-core-dev
1312016-09-22T05:11:37 *** DigiByteDev has quit IRC
1322016-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
1332016-09-22T05:23:27 *** amiller has quit IRC
1342016-09-22T05:28:15 *** Guest75206 has joined #bitcoin-core-dev
1352016-09-22T05:28:33 *** Guest75206 has joined #bitcoin-core-dev
1362016-09-22T05:28:33 *** Guest75206 is now known as amiller
1372016-09-22T05:40:45 *** davec has quit IRC
1382016-09-22T05:41:39 *** davec has joined #bitcoin-core-dev
1392016-09-22T05:44:37 <GitHub21> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf5ebaa921a9...ca69ef4880d1
1402016-09-22T05:44:37 <GitHub21> bitcoin/master faf87af MarcoFalke: [contrib] delete qt_translations.py...
1412016-09-22T05:44:38 <GitHub21> bitcoin/master ca69ef4 Wladimir J. van der Laan: Merge #8781: [contrib] delete qt_translations.py...
1422016-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
1432016-09-22T05:45:07 <GitHub146> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca69ef4880d1...64dc6457454a
1442016-09-22T05:45:07 <GitHub146> bitcoin/master fa13c5c MarcoFalke: [share] remove qt/protobuf.pri...
1452016-09-22T05:45:08 <GitHub146> bitcoin/master 64dc645 Wladimir J. van der Laan: Merge #8783: [share] remove qt/protobuf.pri...
1462016-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
1472016-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
1482016-09-22T05:54:33 *** Ylbam has joined #bitcoin-core-dev
1492016-09-22T05:55:03 <GitHub16> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/64dc6457454a...3166dff48f35
1502016-09-22T05:55:04 <GitHub16> bitcoin/master 6b6cbdd fanquake: [depends] expat 2.2.0
1512016-09-22T05:55:04 <GitHub16> bitcoin/master 9616ac8 fanquake: [depends] ccache 3.3.1
1522016-09-22T05:55:05 <GitHub16> bitcoin/master 86d410d fanquake: [depends] fontconfig 2.12.1
1532016-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
1542016-09-22T05:56:35 *** xinxi has joined #bitcoin-core-dev
1552016-09-22T05:56:54 <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3166dff48f35...7008e28136b5
1562016-09-22T05:56:54 <GitHub101> bitcoin/master fa81d09 MarcoFalke: [contrib] Delete spendfrom
1572016-09-22T05:56:55 <GitHub101> bitcoin/master 7008e28 Wladimir J. van der Laan: Merge #8779: [contrib] Delete spendfrom...
1582016-09-22T05:57:06 <GitHub19> [bitcoin] laanwj closed pull request #8779: [contrib] Delete spendfrom (master...Mf1609-deleteAllTheThings) https://github.com/bitcoin/bitcoin/pull/8779
1592016-09-22T06:01:02 *** xinxi has quit IRC
1602016-09-22T06:08:36 *** Alopex has quit IRC
1612016-09-22T06:09:41 *** Alopex has joined #bitcoin-core-dev
1622016-09-22T06:12:08 *** xinxi has joined #bitcoin-core-dev
1632016-09-22T06:19:03 *** Giszmo has quit IRC
1642016-09-22T06:22:46 *** DigiByteDev has joined #bitcoin-core-dev
1652016-09-22T06:24:19 *** xinxi has quit IRC
1662016-09-22T06:24:36 *** xinxi has joined #bitcoin-core-dev
1672016-09-22T06:28:42 *** Evel-Knievel has quit IRC
1682016-09-22T06:42:45 *** AaronvanW has quit IRC
1692016-09-22T06:44:51 *** xinxi has quit IRC
1702016-09-22T06:45:05 <cfields> wumpus: ooh, neat
1712016-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
1722016-09-22T06:45:20 <jonasschnelli> Seems to cause linking errors...
1732016-09-22T06:45:33 <wumpus> yes. I like this feature
1742016-09-22T06:46:06 *** xinxi has joined #bitcoin-core-dev
1752016-09-22T06:46:08 <jonasschnelli> Linking errors are here: https://travis-ci.org/bitcoin/bitcoin/jobs/160477991#L1567
1762016-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
1772016-09-22T06:47:17 <btcdrak> I quite like the projects tab, much easier to see a project progress potentially over more than one release
1782016-09-22T06:47:29 *** xinxi_ has joined #bitcoin-core-dev
1792016-09-22T06:47:43 <cfields> jonasschnelli: heh, I just fixed the same thing for "bench" a few days ago, I need to PR it
1802016-09-22T06:47:46 <cfields> jonasschnelli: sec for link
1812016-09-22T06:47:57 <jonasschnelli> cfields: thanks!
1822016-09-22T06:48:00 <cfields> jonasschnelli: fyi, link-order doesn't matter for apple's linker, but it does for gnu ld/gold
1832016-09-22T06:48:24 <jonasschnelli> Yeah. I thought so and tried different orders,.. used the same the bitcoid does...
1842016-09-22T06:48:33 <jonasschnelli> *then
1852016-09-22T06:48:37 <cfields> jonasschnelli: https://github.com/theuni/bitcoin/commit/a3786f1aeebf6455acec50926c3b27ea5c060f02
1862016-09-22T06:49:06 <jonasschnelli> cfields: Thanks.. Let me try something..
1872016-09-22T06:49:08 <cfields> jonasschnelli: should be pretty much copy/paste for you
1882016-09-22T06:49:14 <jonasschnelli> okay.
1892016-09-22T06:49:26 <jonasschnelli> btcdrak: A nice! We have projects now.
1902016-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
1912016-09-22T06:49:28 <btcdrak> since MIT is generally quite permissive and compatible with just about anything.
1922016-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
1932016-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).
1942016-09-22T06:50:39 *** xinxi has quit IRC
1952016-09-22T06:50:45 <btcdrak> Contributing should have a line about this.
1962016-09-22T06:50:47 <jonasschnelli> cfields: okay
1972016-09-22T06:51:21 <wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/8786
1982016-09-22T06:52:37 *** jtimon has quit IRC
1992016-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.
2002016-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?
2012016-09-22T06:55:00 <cfields> jonasschnelli: yes, either busted link order or circular dependency
2022016-09-22T06:55:08 *** murch has joined #bitcoin-core-dev
2032016-09-22T07:05:37 *** rubensayshi has joined #bitcoin-core-dev
2042016-09-22T07:06:30 *** blaker has joined #bitcoin-core-dev
2052016-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
2062016-09-22T07:08:05 <cfields> jonasschnelli: oh, i might know
2072016-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
2082016-09-22T07:10:24 <jonasschnelli> cfields: Okay. I'll try that.
2092016-09-22T07:10:35 <cfields> jonasschnelli: see bitcoind as an example
2102016-09-22T07:10:48 <phantomcircuit> jonasschnelli: any idea why we're asseting that locks are held instead of acquiring the lock in cwallet?
2112016-09-22T07:11:00 <phantomcircuit> the locks recursive so it should be fine to just acquire it again
2122016-09-22T07:11:16 <cfields> jonasschnelli: i can play around with it tomorrow (later) if it's still not working
2132016-09-22T07:11:31 <jonasschnelli> phantomcircuit: Is there no overhead in acquiring the lock again? Couple of CPU ticks consumed?
2142016-09-22T07:11:54 <jonasschnelli> cfields: Okay. I may try to play with it... but I guess I will fail. :) But no hurry
2152016-09-22T07:12:24 <cfields> jonasschnelli: you should know by now that telling me "no hurry" guarantees it will never happen :)
2162016-09-22T07:12:29 <phantomcircuit> wumpus: any idea if it costs more to acquire an already held lock than asserting the lock is held?
2172016-09-22T07:12:35 <jonasschnelli> cfields: hurry up then! :)
2182016-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
2192016-09-22T07:13:28 <wumpus> it's really a sanity assertion
2202016-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 :)
2212016-09-22T07:28:15 *** blaker has quit IRC
2222016-09-22T07:32:52 *** AaronvanW has joined #bitcoin-core-dev
2232016-09-22T07:33:19 *** AaronvanW has quit IRC
2242016-09-22T07:33:19 *** AaronvanW has joined #bitcoin-core-dev
2252016-09-22T07:39:07 *** MarcoFalke has joined #bitcoin-core-dev
2262016-09-22T07:39:45 *** xinxi_ has quit IRC
2272016-09-22T07:42:47 *** murch has quit IRC
2282016-09-22T07:47:51 *** assder has joined #bitcoin-core-dev
2292016-09-22T07:51:08 *** laurentmt has joined #bitcoin-core-dev
2302016-09-22T07:52:13 *** laurentmt has quit IRC
2312016-09-22T07:52:53 <gmaxwell> murch: it would be approximate for sure.
2322016-09-22T07:53:04 <gmaxwell> but I think worth analizing.
2332016-09-22T07:54:22 *** xinxi has joined #bitcoin-core-dev
2342016-09-22T07:56:10 *** xinxi has quit IRC
2352016-09-22T07:58:14 *** xinxi has joined #bitcoin-core-dev
2362016-09-22T07:59:31 *** xinxi has quit IRC
2372016-09-22T08:01:24 *** AaronvanW has quit IRC
2382016-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
2392016-09-22T08:07:45 <phantomcircuit> wumpus: hmm
2402016-09-22T08:07:56 <phantomcircuit> how expensive is it to acquire a lock when you already have it?
2412016-09-22T08:08:03 <phantomcircuit> should just be a thread local check
2422016-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?
2432016-09-22T08:10:41 <jonasschnelli> But meh,.. depends on your layering.
2442016-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 :/
2452016-09-22T08:15:46 *** Yogh has quit IRC
2462016-09-22T08:16:41 *** Yogh has joined #bitcoin-core-dev
2472016-09-22T08:20:54 *** assder has quit IRC
2482016-09-22T08:20:55 *** xinxi has joined #bitcoin-core-dev
2492016-09-22T08:29:03 *** Bootvis has quit IRC
2502016-09-22T08:29:13 *** Bootvis has joined #bitcoin-core-dev
2512016-09-22T08:30:10 *** DigiByteDev has quit IRC
2522016-09-22T08:32:22 <luke-jr> jonasschnelli: your travis failed
2532016-09-22T08:32:44 <jonasschnelli> Luke-Jr: thanks... looking..
2542016-09-22T08:33:25 <jonasschnelli> It broke rest
2552016-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
2562016-09-22T08:34:32 <jonasschnelli> Luke-Jr: depends how you make the user<->wallet mapping..
2572016-09-22T08:34:48 <jonasschnelli> But I think user-wallet-mapping is a different thing then RPC auth
2582016-09-22T08:35:22 <jonasschnelli> But I would prefer selecting the wallet based on the endpoint or something within the RPC request
2592016-09-22T08:35:40 <jonasschnelli> Selecting based on the -rpcuser makes it relatively complex to setup
2602016-09-22T08:35:43 <luke-jr> even if we do so, most likely users should be restricted to only some wallet(s)
2612016-09-22T08:36:03 <jonasschnelli> We could still do this... but multiwallet is probably simpler then multiwallet-multiuser
2622016-09-22T08:36:13 <luke-jr> we already have multiuser :p
2632016-09-22T08:36:41 <jonasschnelli> Yes. I meant simpler to not do mutliuser-multiwallet in the first step
2642016-09-22T08:37:20 *** assder has joined #bitcoin-core-dev
2652016-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
2662016-09-22T08:37:52 <jonasschnelli> where the bitcoin-cli tools would use --wallet=<walletid> to pass the request to /<walletid>
2672016-09-22T08:38:04 <luke-jr> can do it with mu-mw already today - plus the code for it is written already *shrug*
2682016-09-22T08:38:22 <jonasschnelli> Yes. But what if you want to wallet with a single user?
2692016-09-22T08:38:30 <jonasschnelli> How would you select?
2702016-09-22T08:38:37 <luke-jr> can't with the current implementation
2712016-09-22T08:38:39 <jonasschnelli> *want two
2722016-09-22T08:38:50 <luke-jr> doing that is more complicated IMO
2732016-09-22T08:39:06 <jonasschnelli> I think its the more obvious use case (single user, multiple wallet=
2742016-09-22T08:39:10 <luke-jr> I'm all for /?wallet=<walletid>, just don't think it's the ideal first-step
2752016-09-22T08:39:42 <luke-jr> since we already have multiuser and even with wallet-selection-by-endpoint would want to lock it down
2762016-09-22T08:39:43 <jonasschnelli> I'm also happy with /?wallet=<walleid> ... AFAIK it's simpler to parse /<walletid>
2772016-09-22T08:39:51 <jonasschnelli> or /wallet/<walletid>
2782016-09-22T08:40:37 <luke-jr> as I see it, endpoint wallet selection is an additional step beyond user permissions
2792016-09-22T08:41:21 <jonasschnelli> Yes. But I think we need to solve singleuser-multiwallet
2802016-09-22T08:41:36 <jonasschnelli> Either with ?wallet=<walletid> in request or /<walletid>
2812016-09-22T08:43:08 <btcdrak> luke-jr why ?wallet=
2822016-09-22T08:43:31 <luke-jr> btcdrak: doesn't step on REST stuff, and unlikely to conflict with future extensions
2832016-09-22T08:44:03 <btcdrak> well thats not how to build REST interface
2842016-09-22T08:44:15 <jonasschnelli> REST does not support wallet
2852016-09-22T08:47:07 <btcdrak> query strings in REST are considered a very poor practice
2862016-09-22T08:48:23 <jonasschnelli> query-string are in the same HTTP element (path)
2872016-09-22T08:48:53 <jonasschnelli> Modern designs mostly use /<key>/<value> instead or ?<key>=<value>
2882016-09-22T08:49:01 <jonasschnelli> Parsing is simpler, browser support better AFAIK
2892016-09-22T08:53:58 *** midnightmagic has joined #bitcoin-core-dev
2902016-09-22T08:58:19 *** xinxi has quit IRC
2912016-09-22T08:58:24 <GitHub84> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7008e28136b5...26b370a93700
2922016-09-22T08:58:24 <GitHub84> bitcoin/master 482f852 Johnson Lau: Implement NULLDUMMY softfork
2932016-09-22T08:58:25 <GitHub84> bitcoin/master 26b370a Wladimir J. van der Laan: Merge #8636: Implement NULLDUMMY softfork (BIP147)...
2942016-09-22T08:58:34 <GitHub156> [bitcoin] laanwj closed pull request #8636: Implement NULLDUMMY softfork (BIP147) (master...nulldummy) https://github.com/bitcoin/bitcoin/pull/8636
2952016-09-22T08:59:22 *** xinxi has joined #bitcoin-core-dev
2962016-09-22T08:59:29 *** MarcoFalke has left #bitcoin-core-dev
2972016-09-22T09:06:29 *** xinxi has quit IRC
2982016-09-22T09:10:18 *** Guyver2 has joined #bitcoin-core-dev
2992016-09-22T09:12:34 <luke-jr> jonasschnelli: pretty sure that violates the URI RFCs :p
3002016-09-22T09:50:55 *** DigiByteDev has joined #bitcoin-core-dev
3012016-09-22T09:53:18 *** DigiByteDev has quit IRC
3022016-09-22T09:57:46 *** luke-jr has quit IRC
3032016-09-22T10:04:40 *** cryptapus has joined #bitcoin-core-dev
3042016-09-22T10:07:02 *** xinxi has joined #bitcoin-core-dev
3052016-09-22T10:08:11 *** MarcoFalke has joined #bitcoin-core-dev
3062016-09-22T10:14:01 *** xinxi has quit IRC
3072016-09-22T10:20:57 *** arowser has quit IRC
3082016-09-22T10:22:23 *** arowser has joined #bitcoin-core-dev
3092016-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
3102016-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
3112016-09-22T10:55:30 *** luke-jr has joined #bitcoin-core-dev
3122016-09-22T10:56:01 <btcdrak> Reminder of last weeks' action points before meeting tonight: review #8634 and #8499 and #8526
3132016-09-22T11:00:26 *** xinxi has joined #bitcoin-core-dev
3142016-09-22T11:01:27 *** xinxi has quit IRC
3152016-09-22T11:01:46 *** randy-waterhouse has quit IRC
3162016-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
3172016-09-22T11:04:50 *** AaronvanW has joined #bitcoin-core-dev
3182016-09-22T11:05:50 *** xinxi has joined #bitcoin-core-dev
3192016-09-22T11:09:07 *** MarcoFalke has left #bitcoin-core-dev
3202016-09-22T11:28:38 *** JackH has joined #bitcoin-core-dev
3212016-09-22T11:29:23 *** assder has quit IRC
3222016-09-22T11:29:32 *** assder has joined #bitcoin-core-dev
3232016-09-22T11:49:25 *** cdecker has quit IRC
3242016-09-22T12:01:40 *** cdecker has joined #bitcoin-core-dev
3252016-09-22T12:16:17 *** murch has joined #bitcoin-core-dev
3262016-09-22T12:16:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3272016-09-22T12:16:56 <jonasschnelli> Luke-Jr: why would that violate the URI RFC?
3282016-09-22T12:17:15 <jonasschnelli> IMO something like /wallet/<walletid>/getbalance would be perfectly fine.
3292016-09-22T12:17:33 <jonasschnelli> though the method in the URI would be against JSONRPC
3302016-09-22T12:18:11 <jonasschnelli> but speaking JSONRPC against different URI endpoints looks after a feasible design
3312016-09-22T12:20:20 *** MrHodl has joined #bitcoin-core-dev
3322016-09-22T12:25:49 *** arowser has quit IRC
3332016-09-22T12:27:05 *** arowser has joined #bitcoin-core-dev
3342016-09-22T12:30:15 <wumpus> another day, another bunch of OpenSSL advisories https://www.openssl.org/news/secadv/20160922.txt
3352016-09-22T12:30:57 <jonasschnelli> *sigh*
3362016-09-22T12:31:03 <phantomcircuit> jonasschnelli: optimally cs_wallet would be private
3372016-09-22T12:31:14 <jonasschnelli> Happy that our p2p encryption plans and not based on SSL
3382016-09-22T12:31:22 <jonasschnelli> phantomcircuit: agree
3392016-09-22T12:31:41 <phantomcircuit> the only way for that to happen is for the public methods to acquire the lock
3402016-09-22T12:31:46 <jonasschnelli> I think its a bad design that cs_wallet can be (and will) accessed from the outside
3412016-09-22T12:31:53 <wumpus> yes, the lock should be private
3422016-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
3432016-09-22T12:34:04 *** Chris_Stewart_5 has quit IRC
3442016-09-22T12:37:28 <sipa> wumpus: note that this is about DSA, not ECDSA
3452016-09-22T12:37:47 <wumpus> oh that's a different code path? I don't know openssl internals
3462016-09-22T12:38:25 *** AaronvanW has quit IRC
3472016-09-22T12:38:54 <wumpus> I mean it's the same operation on a different group, but they probably made a parallel implementation, okay
3482016-09-22T12:40:51 <sipa> yeah, the ecdsa code is separate
3492016-09-22T12:40:52 <phantomcircuit> CWalletTx::InMempool
3502016-09-22T12:40:57 <phantomcircuit> wtf
3512016-09-22T12:41:19 <phantomcircuit> jonasschnelli: why
3522016-09-22T12:41:20 <phantomcircuit> WHYY
3532016-09-22T12:41:29 <wumpus> which doesn't mean they don't have the same bug there , just waiting to be found :)
3542016-09-22T12:41:33 <sipa> phantomcircuit: ?
3552016-09-22T12:41:56 <jonasschnelli> phantomcircuit: The current wallet logic need to know that
3562016-09-22T12:42:01 <phantomcircuit> sipa: abstraction violation to the max
3572016-09-22T12:42:06 <jonasschnelli> But I agree,... couping the wallet with the mempool is bad!
3582016-09-22T12:42:18 <wumpus> the wallet is allowed to communicate with the mempool in our case
3592016-09-22T12:42:33 <wumpus> this is used for some things such as showing conflicts
3602016-09-22T12:42:35 <sipa> phantomcircuit: we can't avoid that without breaking semantics
3612016-09-22T12:42:47 <wumpus> I mean: this is a full node wallet, you have the mempool information, why not use it
3622016-09-22T12:43:01 <sipa> it can be abstracted more cleanly (install a callback, etc), but functionally we need it, unfortunately
3632016-09-22T12:43:03 <jonasschnelli> Yes. But maybe not directly accessing the mempool object. :)
3642016-09-22T12:43:05 <wumpus> *the way* of communicating with the mempool may be wrong, that'sa another thing
3652016-09-22T12:43:11 <wumpus> right.
3662016-09-22T12:43:47 <jonasschnelli> We need to make this more flexible if we once like to have the hybrid SPV mode.
3672016-09-22T12:44:15 <jonasschnelli> Which is – sadly – probably far away from being implemented. :)
3682016-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)
3692016-09-22T12:44:43 <wumpus> yes sure, it would need a fallback with the information missing . Like not show unconfirmed transactions at all.
3702016-09-22T12:45:18 <wumpus> that's essentially what is the case already during initial sync
3712016-09-22T12:47:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3722016-09-22T12:47:01 *** assder has quit IRC
3732016-09-22T12:47:02 *** AndChat|206976 has joined #bitcoin-core-dev
3742016-09-22T12:51:52 <wumpus> doesn't seem like any of the SSL issues are a serious problem for us
3752016-09-22T12:52:15 *** jnewbery has joined #bitcoin-core-dev
3762016-09-22T12:56:08 *** cryptapus_ has joined #bitcoin-core-dev
3772016-09-22T12:56:09 *** cryptapus_ has joined #bitcoin-core-dev
3782016-09-22T12:59:06 *** Chris_Stewart_5 has quit IRC
3792016-09-22T12:59:54 *** cryptapus has quit IRC
3802016-09-22T13:01:05 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3812016-09-22T13:02:17 *** cryptapus_ is now known as cryptapus
3822016-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
3832016-09-22T13:20:41 *** Chris_Stewart_5 has quit IRC
3842016-09-22T13:22:49 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3852016-09-22T13:30:47 *** jl2012 has quit IRC
3862016-09-22T13:37:09 *** [Author] has quit IRC
3872016-09-22T13:41:12 *** [Author] has joined #bitcoin-core-dev
3882016-09-22T13:41:56 *** Giszmo has joined #bitcoin-core-dev
3892016-09-22T13:42:23 *** jl2012 has joined #bitcoin-core-dev
3902016-09-22T13:44:03 *** Chris_Stewart_5 has quit IRC
3912016-09-22T13:48:41 *** To7 has joined #bitcoin-core-dev
3922016-09-22T13:49:35 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3932016-09-22T13:52:48 *** xinxi has quit IRC
3942016-09-22T13:54:57 *** xinxi has joined #bitcoin-core-dev
3952016-09-22T14:04:24 *** cryptapus has quit IRC
3962016-09-22T14:04:44 *** cryptapus has joined #bitcoin-core-dev
3972016-09-22T14:04:45 *** cryptapus has joined #bitcoin-core-dev
3982016-09-22T14:14:31 *** xinxi has quit IRC
3992016-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
4002016-09-22T14:16:33 *** xinxi has joined #bitcoin-core-dev
4012016-09-22T14:17:49 *** xinxi has quit IRC
4022016-09-22T14:28:31 *** xinxi has joined #bitcoin-core-dev
4032016-09-22T14:33:12 *** xinxi has quit IRC
4042016-09-22T14:41:27 <GitHub41> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26b370a93700...2b514aa2eae6
4052016-09-22T14:41:28 <GitHub41> bitcoin/master b5ccded instagibbs: Comment on CConnman::nLocalServices meaning
4062016-09-22T14:41:28 <GitHub41> bitcoin/master 2b514aa Wladimir J. van der Laan: Merge #8785: Comment on CNode::nLocalServices meaning...
4072016-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
4082016-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
4092016-09-22T14:43:41 *** jnewbery has quit IRC
4102016-09-22T14:44:18 *** jnewbery has joined #bitcoin-core-dev
4112016-09-22T14:44:33 *** AndChat|206976 has quit IRC
4122016-09-22T14:48:31 *** AaronvanW has joined #bitcoin-core-dev
4132016-09-22T14:48:39 *** jnewbery has quit IRC
4142016-09-22T14:48:58 *** AaronvanW has quit IRC
4152016-09-22T14:48:59 *** AaronvanW has joined #bitcoin-core-dev
4162016-09-22T14:53:53 *** Chris_Stewart_5 has quit IRC
4172016-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
4182016-09-22T15:00:36 <wumpus> it's not even possible to *edit* the approval message
4192016-09-22T15:00:54 <paveljanik> I think this functionality is not ready yet...
4202016-09-22T15:01:13 <paveljanik> There is no Preview on the approval message etc.
4212016-09-22T15:01:47 <wumpus> right, it's more of a public beta
4222016-09-22T15:02:01 <wumpus> maybe I should just stop using 'approve'
4232016-09-22T15:02:29 <paveljanik> we are all "testing rabbits" - is it the same in English? ;-)
4242016-09-22T15:02:58 <achow101> I think you're looking for "lab rats"
4252016-09-22T15:03:18 <wumpus> in english it's guinea pigs
4262016-09-22T15:03:19 <wumpus> or that
4272016-09-22T15:03:44 <wumpus> in dutch it's "proefkonijnen", "testing rabbits"
4282016-09-22T15:04:13 <instagibbs> lab rats works in english too :) also easier to spell
4292016-09-22T15:05:39 <paveljanik> :-)
4302016-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. ;-)
4312016-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
4322016-09-22T15:10:02 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4332016-09-22T15:10:26 <wumpus> paveljanik: curious, almost all of the functions that are changes change in the binary
4342016-09-22T15:10:42 <wumpus> looking at WalletModel::WalletModel now
4352016-09-22T15:12:07 *** nickler has quit IRC
4362016-09-22T15:12:24 <paveljanik> interesting
4372016-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...
4382016-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
4392016-09-22T15:14:13 <paveljanik> but only in QT binary
4402016-09-22T15:14:18 <paveljanik> bitcoind untouched...
4412016-09-22T15:14:18 <wumpus> yes
4422016-09-22T15:14:30 <paveljanik> do we compile Qt somehow different?
4432016-09-22T15:14:49 <wumpus> I use the same build and comparison process that I use to cmpare bitcoind binaries
4442016-09-22T15:15:16 <wumpus> well qt has qrc passes
4452016-09-22T15:15:27 <wumpus> moc, I mean
4462016-09-22T15:16:00 <wumpus> which automatically generates some code for signal/slot dispatch, property setting, and such
4472016-09-22T15:16:10 <wumpus> that may be what happens here, I don't know
4482016-09-22T15:16:40 <wumpus> I'll check if this is restricted to consturctors
4492016-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
4502016-09-22T15:22:27 <wumpus> paveljanik: they now refer to the memner variable
4512016-09-22T15:22:38 <wumpus> member*
4522016-09-22T15:22:49 <wumpus> same for WalletView::setWalletModel
4532016-09-22T15:23:01 <wumpus> the otherwise-empty constructors remain a mystery though
4542016-09-22T15:24:00 <paveljanik> will fix both...
4552016-09-22T15:26:06 <wumpus> ok let me know when you pushed then I'll redo the binaries check
4562016-09-22T15:26:12 <paveljanik> done
4572016-09-22T15:28:20 <wumpus> building
4582016-09-22T15:29:33 <paveljanik> coffee ;-)
4592016-09-22T15:36:12 <wumpus> good idea
4602016-09-22T15:36:23 <sipa> just had one
4612016-09-22T15:37:22 <paveljanik> Kenya AA Top Superstar - macchiato :-)
4622016-09-22T15:39:31 *** xinxi has joined #bitcoin-core-dev
4632016-09-22T15:42:23 <wumpus> paveljanik: that worked, those two functions are gone from the list now - only constructors left
4642016-09-22T15:42:43 *** AaronvanW has quit IRC
4652016-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
4662016-09-22T15:44:44 *** jnewbery has joined #bitcoin-core-dev
4672016-09-22T15:47:51 <paveljanik> wumpus, yes, thanks for investigation!
4682016-09-22T15:50:40 *** jnewbery has quit IRC
4692016-09-22T15:51:31 <paveljanik> I'll double check the rest of the functions in the list
4702016-09-22T15:53:12 <paveljanik> Hmm, in WalletView::WalletView, I use platformStyle and not _ platformStyle...
4712016-09-22T15:54:05 *** jnewbery has joined #bitcoin-core-dev
4722016-09-22T15:54:19 <paveljanik> https://github.com/bitcoin/bitcoin/pull/8793/files#diff-0945de3e3345c5e5c9b39feef7843574R39
4732016-09-22T15:55:22 *** AaronvanW has joined #bitcoin-core-dev
4742016-09-22T15:55:50 *** AaronvanW has quit IRC
4752016-09-22T15:55:50 *** AaronvanW has joined #bitcoin-core-dev
4762016-09-22T15:56:17 *** laurentmt has joined #bitcoin-core-dev
4772016-09-22T15:56:28 *** laurentmt has quit IRC
4782016-09-22T16:00:07 <wumpus> paveljanik: yes, it looks like a similar thing
4792016-09-22T16:00:27 <wumpus> I've ruled out moc at least
4802016-09-22T16:00:42 <wumpus> compiled the file individually with gcc -S and still see the difference
4812016-09-22T16:04:00 <wumpus> paveljanik: this seems to make the differences in AddressBookPage::AddressBookPAge go away http://www.hastebin.com/jixoyufuxu.php
4822016-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...
4832016-09-22T16:05:03 <wumpus> yes, I don't think it's an improvement
4842016-09-22T16:05:08 <wumpus> let's just leave it at this
4852016-09-22T16:05:10 <wumpus> it's explained
4862016-09-22T16:05:32 <paveljanik> well, but this means that binaries will be different :-(
4872016-09-22T16:06:06 <wumpus> yes, but we are capable of creating a patch that won't change the binaries, it's just ugly
4882016-09-22T16:06:18 <wumpus> +larger
4892016-09-22T16:06:49 <paveljanik> but its correct (QED)
4902016-09-22T16:07:08 <sipa> i think having a patch available to removes the differences is enough
4912016-09-22T16:07:19 <sipa> the changes are trivial anyway
4922016-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
4932016-09-22T16:07:28 <wumpus> right sipa
4942016-09-22T16:07:33 <paveljanik> yup
4952016-09-22T16:11:34 *** rubensayshi has quit IRC
4962016-09-22T16:13:45 *** bsm117532 has quit IRC
4972016-09-22T16:14:14 *** bsm117532 has joined #bitcoin-core-dev
4982016-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)
4992016-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
5002016-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?
5012016-09-22T16:21:49 <wumpus> #bitcoin
5022016-09-22T16:22:42 <JackH> #futureofbitcoin in here? (conceptually)
5032016-09-22T16:22:48 <JackH> ah shit
5042016-09-22T16:22:50 <JackH> I am not in wizards
5052016-09-22T16:22:53 <JackH> sorry
5062016-09-22T16:23:15 <JackH> this is akward...
5072016-09-22T16:23:20 <wumpus> wizards is about cryptography and moonmath, it's also not the place to discuss comparison to altcoins
5082016-09-22T16:29:35 *** AaronvanW has quit IRC
5092016-09-22T16:30:53 *** AaronvanW has joined #bitcoin-core-dev
5102016-09-22T16:31:20 *** AaronvanW has quit IRC
5112016-09-22T16:31:20 *** AaronvanW has joined #bitcoin-core-dev
5122016-09-22T16:34:09 *** Guyver2 has quit IRC
5132016-09-22T16:34:21 *** Guyver2 has joined #bitcoin-core-dev
5142016-09-22T16:34:24 *** jnewbery has quit IRC
5152016-09-22T16:48:03 *** xinxi has quit IRC
5162016-09-22T17:10:21 *** nickler has joined #bitcoin-core-dev
5172016-09-22T17:13:55 *** AaronvanW has quit IRC
5182016-09-22T17:22:41 *** achow101 has quit IRC
5192016-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?)
5202016-09-22T17:24:19 <haakonn> agh, sorry for the noise, thought this was #bitcoin
5212016-09-22T17:26:06 <helo> you had me convinced :P
5222016-09-22T17:26:19 *** jtimon has joined #bitcoin-core-dev
5232016-09-22T17:29:01 *** MarcoFalke has joined #bitcoin-core-dev
5242016-09-22T17:35:14 *** jnewbery has joined #bitcoin-core-dev
5252016-09-22T17:36:12 *** achow101 has joined #bitcoin-core-dev
5262016-09-22T17:43:39 *** MarcoFalke has quit IRC
5272016-09-22T17:49:52 <instagibbs> when running make check is there a way to get a stack trace on failure
5282016-09-22T17:50:34 <instagibbs> error is happening in some helper function, and no useful info about when it's happening
5292016-09-22T17:52:01 *** jnewbery has quit IRC
5302016-09-22T17:52:14 *** jnewbery has joined #bitcoin-core-dev
5312016-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
5322016-09-22T17:59:00 *** jtimon has quit IRC
5332016-09-22T17:59:51 <btcdrak> meeting time?
5342016-09-22T18:00:01 <instagibbs> in an hour?
5352016-09-22T18:00:04 <achow101> you're an hour early
5362016-09-22T18:00:18 <btcdrak> oh woops
5372016-09-22T18:13:22 *** achow101 has quit IRC
5382016-09-22T18:16:23 *** stan_ has joined #bitcoin-core-dev
5392016-09-22T18:18:40 *** achow101 has joined #bitcoin-core-dev
5402016-09-22T18:25:53 *** Yogh has quit IRC
5412016-09-22T18:27:37 *** Yogh has joined #bitcoin-core-dev
5422016-09-22T18:36:33 *** gabridome has joined #bitcoin-core-dev
5432016-09-22T18:45:18 *** jcorgan has joined #bitcoin-core-dev
5442016-09-22T18:48:04 *** CIS has joined #bitcoin-core-dev
5452016-09-22T18:48:41 *** CIS has joined #bitcoin-core-dev
5462016-09-22T18:52:37 *** CIS is now known as cis
5472016-09-22T18:53:52 *** gabridome has quit IRC
5482016-09-22T18:58:20 <kanzure> btcdrak: i propose we deprecate timezones
5492016-09-22T18:58:46 <jcorgan> and DST
5502016-09-22T18:58:56 <btcdrak> yes
5512016-09-22T18:58:58 <achow101> kanzure: ask IANA
5522016-09-22T18:59:00 <murch> kanzure: Yes, let's all just use UTC all year long.
5532016-09-22T18:59:12 <btcdrak> achow101: more like ask Trump
5542016-09-22T18:59:24 <achow101> Hah!
5552016-09-22T18:59:25 <gmaxwell> shh.
5562016-09-22T18:59:30 <sipa> murch: another thing we should learn from icelanders
5572016-09-22T18:59:39 <cfields> here for meeting, but dog's pacing at the door. Back in ~5.
5582016-09-22T18:59:43 <gmaxwell> Don't start a big OT discussion right before the meeting.
5592016-09-22T18:59:48 <wumpus> #startmeeting
5602016-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.
5612016-09-22T18:59:48 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5622016-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
5632016-09-22T18:59:55 <CodeShark> Here
5642016-09-22T18:59:58 <jonasschnelli> here
5652016-09-22T19:00:04 <btcdrak> jl2012 ping
5662016-09-22T19:00:11 <murch> hello
5672016-09-22T19:00:15 <sipa> pyng
5682016-09-22T19:00:17 <kanzure> hi.
5692016-09-22T19:00:21 <sdaftuar> hi
5702016-09-22T19:00:22 <wumpus> jl2012 probably won't be here this meeting
5712016-09-22T19:00:22 <paveljanik> peng
5722016-09-22T19:00:53 <michagogo> May show up in a bit - at dinner with my grandmother atm
5732016-09-22T19:00:54 <btcdrak> 01110000 01101001 01101110 01100111
5742016-09-22T19:01:06 <gmaxwell> our meeting is at an unfriendly time for our contributors in asia/au/nz/etc. Alas.
5752016-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
5762016-09-22T19:01:10 <wumpus> <jl2012> It seems the risks is too much comparing with the benefit
5772016-09-22T19:01:52 <wumpus> yes what ever time you pick it's always unfriendly to someone
5782016-09-22T19:01:54 <btcdrak> I was discussing this with him yesterday. I also think it should be dropped.
5792016-09-22T19:02:38 <btcdrak> wumpus: we should find a time that is unfriendly to everyone :)
5802016-09-22T19:02:56 <wumpus> #topic Drop reuse sighash computations across evaluation #8654 from 0.13.1?
5812016-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)
5822016-09-22T19:03:26 <wumpus> gmaxwell: something else we could do is have e.g. alternating times every week
5832016-09-22T19:03:48 <sipa> yes, i'm in favor of dropping it. i believed the advantages were larger first
5842016-09-22T19:03:49 <wumpus> but given that people already have a hard time being there intime for a meeting with a fixed time... :-)
5852016-09-22T19:04:03 <sipa> but it seems we'll need more changes anyway than we can tolerate for 0.13.1
5862016-09-22T19:04:07 *** yep5555 has joined #bitcoin-core-dev
5872016-09-22T19:04:07 <gmaxwell> So re: that PR. We can do it later. We've survived thus far without it.
5882016-09-22T19:04:13 <btcdrak> yes.
5892016-09-22T19:04:16 <wumpus> ok
5902016-09-22T19:04:38 <wumpus> removing 0.13.1 milestone from it
5912016-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
5922016-09-22T19:05:12 *** jtimon has joined #bitcoin-core-dev
5932016-09-22T19:05:19 <sipa> petertodd: the same
5942016-09-22T19:05:23 *** Alina-malina is now known as Samsepiol
5952016-09-22T19:05:39 *** Samsepiol is now known as Alina-malina
5962016-09-22T19:05:43 <petertodd> sipa: but can't you get more checksig ops w/ segwit?
5972016-09-22T19:05:45 <sipa> petertodd: as segwit inputs only hash the entire transaction at most once
5982016-09-22T19:05:57 <sipa> see bip143
5992016-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.
6002016-09-22T19:06:23 <jtimon> hi
6012016-09-22T19:06:57 <sipa> petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block
6022016-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.
6032016-09-22T19:07:06 <petertodd> gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior
6042016-09-22T19:07:22 <sipa> petertodd: all sighashing is changed in segwit
6052016-09-22T19:07:24 <petertodd> alright, I'm ACK to remove that for 0.13.1
6062016-09-22T19:07:33 <wumpus> great
6072016-09-22T19:07:39 <petertodd> sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :)
6082016-09-22T19:07:48 *** laurentmt has joined #bitcoin-core-dev
6092016-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.
6102016-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
6112016-09-22T19:09:10 *** jnewbery has quit IRC
6122016-09-22T19:09:15 <achow101> are #8634 and #8499 and #8526 ready for merge?
6132016-09-22T19:09:34 <wumpus> that's a new topic proposal achow101?
6142016-09-22T19:09:58 <achow101> just a question
6152016-09-22T19:10:00 <gmaxwell> related topic at least.
6162016-09-22T19:10:28 <btcdrak> well they were part of last week's homework
6172016-09-22T19:10:34 <wumpus> Add policy: null signature for failed CHECK(MULTI)SIG https://github.com/bitcoin/bitcoin/pull/8634
6182016-09-22T19:10:54 <wumpus> Check bad witness and implement several policy limits for segwit scripts https://github.com/bitcoin/bitcoin/pull/8499
6192016-09-22T19:11:19 <wumpus> Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH https://github.com/bitcoin/bitcoin/pull/8526
6202016-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
6212016-09-22T19:12:20 <CodeShark> Still reviewing 8499
6222016-09-22T19:13:28 <wumpus> ok, anyone else with opinion about those pulls?
6232016-09-22T19:13:43 *** jnewbery has joined #bitcoin-core-dev
6242016-09-22T19:14:47 <gmaxwell> 8634 needs a squash. LGTM.
6252016-09-22T19:14:56 <sipa> 8499 is a blocker for 0.13.1 for sure
6262016-09-22T19:15:02 <achow101> wasn't it decided that 8393 was ready, or just about ready
6272016-09-22T19:15:04 <sdaftuar> fyi i'm just starting my review of 8499 now
6282016-09-22T19:15:06 <wumpus> looks like #8634 has quite a lot of (u)tACKs
6292016-09-22T19:15:30 <sdaftuar> (but don't let me hold thigns up!)
6302016-09-22T19:16:19 <wumpus> #action merge #8634 after squashing
6312016-09-22T19:16:35 <wumpus> 8499 is still very much in progress
6322016-09-22T19:17:18 <instagibbs> 8393 isn't that hard to review but only a couple people have given acks
6332016-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)
6342016-09-22T19:19:56 <sipa> i'll address the latest nits in 8393
6352016-09-22T19:20:00 <wumpus> so anything between those that is ready for merge?
6362016-09-22T19:20:37 *** laurentmt has quit IRC
6372016-09-22T19:20:43 <btcdrak> We need a few more acks on 8526 but it looks harmless enough as is.
6382016-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
6392016-09-22T19:21:35 <wumpus> this probably means it should be untagged for 0.13.1
6402016-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
6412016-09-22T19:21:47 <jonasschnelli> Yes. No need for 0.13.1
6422016-09-22T19:21:57 <sipa> btcdrak: yes, i'm aware
6432016-09-22T19:22:17 <wumpus> jonasschnelli: right, if we do that it should be something documented in the release notes of a major release
6442016-09-22T19:22:23 <jonasschnelli> ack
6452016-09-22T19:22:41 <jonasschnelli> People probably built apps on the "strange" listsinceblock behavior.
6462016-09-22T19:22:48 <wumpus> exactly
6472016-09-22T19:22:53 *** gabridome has joined #bitcoin-core-dev
6482016-09-22T19:23:12 <jonasschnelli> remved the 0.13.1 ms from 8757
6492016-09-22T19:23:17 <wumpus> okay that leaves four to go
6502016-09-22T19:23:27 <BlueMatt> wumpus: wait, we're unmarking compact blocks for 0.13.1?
6512016-09-22T19:23:32 <BlueMatt> (you just did)
6522016-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?
6532016-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.
6542016-09-22T19:23:43 <wumpus> BlueMatt: uh
6552016-09-22T19:23:47 <gmaxwell> BlueMatt: wat?
6562016-09-22T19:23:54 <BlueMatt> @laanwj laanwj removed this from the 0.13.1 milestone a minute ago
6572016-09-22T19:23:55 <instagibbs> er did someone remove the segwit cb?
6582016-09-22T19:23:56 <wumpus> that was a mistake
6592016-09-22T19:23:57 <BlueMatt> I assume that was accidental
6602016-09-22T19:24:00 <wumpus> please readd
6612016-09-22T19:24:05 <BlueMatt> #8393
6622016-09-22T19:24:15 <gmaxwell> unclick
6632016-09-22T19:24:27 <BlueMatt> ok, so 5 to go
6642016-09-22T19:24:32 <jonasschnelli> readded
6652016-09-22T19:24:47 <instagibbs> 4 PRs, one related issue
6662016-09-22T19:24:52 <sipa> you take one down, pass it around, 5 PR to g
6672016-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?
6682016-09-22T19:25:20 <Chris_Stewart_5> exponential PR blow up
6692016-09-22T19:25:22 <btcdrak> There is also this nice project https://github.com/bitcoin/bitcoin/projects/5
6702016-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
6712016-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
6722016-09-22T19:26:14 <BlueMatt> same with 8634
6732016-09-22T19:26:55 <paveljanik> wumpus, nice!
6742016-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
6752016-09-22T19:27:13 <gmaxwell> minor meta aside, is there any facility for backing up and retaining all this new github stuff?
6762016-09-22T19:27:33 <BlueMatt> gmaxwell: havent looked, but the github api has historically been very, very complete
6772016-09-22T19:27:39 <BlueMatt> so i ass-u-me so?
6782016-09-22T19:27:42 <wumpus> gmaxwell: that's iwilcox's department (but he's not here)
6792016-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
6802016-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.
6812016-09-22T19:28:53 <gmaxwell> and 8634 is done but for a squash as far as I can tell.
6822016-09-22T19:29:24 <wumpus> already created an action for #8634, we're repeating ourselves
6832016-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
6842016-09-22T19:29:26 <btcdrak> gmaxwell: the github API supports all this new stuff https://developer.github.com/v3/repos/projects/
6852016-09-22T19:29:44 *** Chris_St1 has joined #bitcoin-core-dev
6862016-09-22T19:29:45 <BlueMatt> (ie lets start looking for date consensus like...soon)
6872016-09-22T19:29:55 <achow101> like.. now?
6882016-09-22T19:30:01 <sipa> no, not now
6892016-09-22T19:30:05 <instagibbs> achow101: no, after critical updates are merged
6902016-09-22T19:30:11 <sipa> first know when we can possibly have a release
6912016-09-22T19:30:14 <BlueMatt> like...in a few days after the non-critical ones are merged
6922016-09-22T19:30:14 <btcdrak> BlueMatt: well we need #8393 merged too before we can be sure to set dates
6932016-09-22T19:30:37 <BlueMatt> btcdrak: sure, fine, #8393, #8279, and #8499, then dates?
6942016-09-22T19:30:50 <btcdrak> ack
6952016-09-22T19:30:55 <sdaftuar> i believe 8279 is sufficiently resolved for 0.13.1
6962016-09-22T19:31:11 <wumpus> let's try to finish those pulls this week then we can talk about the release next meeting
6972016-09-22T19:31:11 <gmaxwell> BlueMatt: do we know what the status of btcd's SW support is?
6982016-09-22T19:31:22 <BlueMatt> gmaxwell: thats part of soliciting consensus on dates :p
6992016-09-22T19:31:24 <btcdrak> ping roasbeef
7002016-09-22T19:31:30 <BlueMatt> (ie reaching out to non-bitcoin core people)
7012016-09-22T19:31:46 <gmaxwell> BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs.
7022016-09-22T19:31:46 <instagibbs> wumpus: ack
7032016-09-22T19:32:02 <wumpus> sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it
7042016-09-22T19:32:12 <sdaftuar> wumpus: sounds good to me
7052016-09-22T19:32:17 *** Chris_Stewart_5 has quit IRC
7062016-09-22T19:32:28 <sipa> wumpus: sounds good
7072016-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".
7082016-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.
7092016-09-22T19:35:13 <wumpus> makes sense to reach out to them then
7102016-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.
7112016-09-22T19:35:33 <gmaxwell> yes.
7122016-09-22T19:35:34 <petertodd> python-bitcoinlib has a fairly good pull-req for segwit
7132016-09-22T19:35:45 <wumpus> awesome
7142016-09-22T19:36:08 <gmaxwell> mining software was in a sad state last time I checked, but I know things have improved a lot.
7152016-09-22T19:37:03 <gmaxwell> in any case, many things to discuss there that don't need everyone. :)
7162016-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)
7172016-09-22T19:37:32 <petertodd> roasbeef: +1
7182016-09-22T19:37:33 *** JackH has quit IRC
7192016-09-22T19:37:34 <roasbeef> primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff
7202016-09-22T19:37:36 <gmaxwell> roasbeef: fantastic.
7212016-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.
7222016-09-22T19:39:15 <achow101> armory is.. getting there. We're aiming for the release after the next to have full segwit support
7232016-09-22T19:39:44 <petertodd> achow101: thanks!
7242016-09-22T19:39:47 <gmaxwell> achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing.
7252016-09-22T19:40:03 <btcdrak> oh I didnt know you work on Armory achow101 +1
7262016-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
7272016-09-22T19:40:27 *** luke-jr has quit IRC
7282016-09-22T19:40:47 <petertodd> gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :)
7292016-09-22T19:40:57 <gmaxwell> It's just good to hear that more things are almost read, as it's another angle of testing.
7302016-09-22T19:41:25 <Chris_St1> CodeShark: What BIP is that related to?
7312016-09-22T19:41:50 <CodeShark> We don't have a BIP yet, I don't think
7322016-09-22T19:41:52 <sipa> Chris_St1: that will need a new bip
7332016-09-22T19:42:26 <sipa> it's trivial (just combine bip37 with bip141 wtxids)
7342016-09-22T19:42:32 <Chris_St1> ok, gotcha.
7352016-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)
7362016-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
7372016-09-22T19:43:12 <CodeShark> I'd prefer a replacement to bip37, but that's more involved
7382016-09-22T19:43:14 <Chris_St1> BIP37 is definitely a monster in terms of implementation... or atleast it was for me
7392016-09-22T19:43:14 <gmaxwell> We could probably do better.
7402016-09-22T19:43:55 <sipa> at least we could propose to drop some of the auto-inserting that causes false positive rate blowup
7412016-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
7422016-09-22T19:44:28 <BlueMatt> CodeShark: uhhhhhhhhh, that sounds like a blocker
7432016-09-22T19:44:32 <gmaxwell> petertodd: Satoshi's vision.
7442016-09-22T19:44:34 <btcdrak> petertodd: such as?
7452016-09-22T19:44:49 <jtimon> I guess he means as a way to get more privacy?
7462016-09-22T19:44:53 <sipa> BlueMatt: how so?
7472016-09-22T19:45:02 *** luke-jr has joined #bitcoin-core-dev
7482016-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
7492016-09-22T19:45:06 <petertodd> no, I just mean that the data increase is relatively low
7502016-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.
7512016-09-22T19:45:07 <jtimon> no tevealing which txs you care about? just thinking out loud...
7522016-09-22T19:45:22 <sipa> BlueMatt: spv wallets shouldn't care about the witness data
7532016-09-22T19:45:55 <sipa> hell, it's an advantage that their bandwidth will drop
7542016-09-22T19:45:57 <petertodd> sipa: indeed, they can't verify that the witness is valid
7552016-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.
7562016-09-22T19:46:09 <CodeShark> wallets that don't tell you who signed a multisig are incomplete ;)
7572016-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.
7582016-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
7592016-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
7602016-09-22T19:47:12 <CodeShark> it's critical for enterprise applications
7612016-09-22T19:47:20 <CodeShark> Accountability is important
7622016-09-22T19:47:22 <petertodd> CodeShark: enterprise can afford some extra bandwidth I'm sure :)
7632016-09-22T19:47:29 <achow101> I think we're getting OT
7642016-09-22T19:47:32 <petertodd> CodeShark: this isn't a blocker is all I'm saying
7652016-09-22T19:47:45 <CodeShark> we can revisit this after 0.13.1
7662016-09-22T19:47:48 <gmaxwell> It's also not news or an accident.
7672016-09-22T19:48:00 <wumpus> no one is considering it is a blocker except for BlueMatt
7682016-09-22T19:48:03 <petertodd> CodeShark: ack
7692016-09-22T19:48:28 <BlueMatt> gmaxwell: sure, I'm saying that you cant use segwit as an spv client
7702016-09-22T19:48:36 <sipa> BlueMatt: of course you can?
7712016-09-22T19:48:38 <gmaxwell> BlueMatt: thats not true.
7722016-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
7732016-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
7742016-09-22T19:49:08 <BlueMatt> which you might want to
7752016-09-22T19:49:21 <BlueMatt> petertodd: you already do that, the malleability doesnt help
7762016-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?
7772016-09-22T19:49:36 * BlueMatt isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that
7782016-09-22T19:49:38 <petertodd> BlueMatt: true, once confirmed
7792016-09-22T19:49:52 <wumpus> Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1
7802016-09-22T19:49:52 <jtimon> Chris_St1: the former
7812016-09-22T19:49:53 <petertodd> BlueMatt: I take back that comment
7822016-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
7832016-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.
7842016-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
7852016-09-22T19:51:03 <sipa> i think there was no reason for that, indeed
7862016-09-22T19:51:07 <BlueMatt> but it is the case that you lose this property of matching pubkeys which were used
7872016-09-22T19:51:10 <sipa> and if there is, we can still add it back
7882016-09-22T19:51:17 <BlueMatt> sipa: well, you might want it, but not a ton
7892016-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.
7902016-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
7912016-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
7922016-09-22T19:51:36 <Chris_St1> BlueMatt: Matching scriptSig constants in BIP37 right?
7932016-09-22T19:51:44 *** cryptapus has quit IRC
7942016-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
7952016-09-22T19:52:01 <wumpus> BIP37 can be extended, sure
7962016-09-22T19:52:17 <BlueMatt> Chris_St1: bip37 only ever matches constants
7972016-09-22T19:52:17 <wumpus> but that's not yet another reason to move forward the release
7982016-09-22T19:52:28 <BlueMatt> agreed
7992016-09-22T19:52:33 <achow101> topic proposal: alert system retirement
8002016-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
8012016-09-22T19:52:44 <instagibbs> 8 minutes left
8022016-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
8032016-09-22T19:53:00 <BlueMatt> gmaxwell: yup
8042016-09-22T19:53:00 <gmaxwell> BlueMatt: yup.
8052016-09-22T19:53:12 <CodeShark> I want a good fairly secure quick sync solution. BIP37 sucks :p
8062016-09-22T19:53:25 <gmaxwell> second on achow101's topic.
8072016-09-22T19:53:28 <petertodd> CodeShark: sure, fiber-to-the-home :)
8082016-09-22T19:53:33 <CodeShark> But we'll do that after 0.13.1
8092016-09-22T19:53:33 <wumpus> #topic alert system retirement
8102016-09-22T19:53:34 <petertodd> gmaxwell: ack
8112016-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.
8122016-09-22T19:54:20 *** davec has quit IRC
8132016-09-22T19:54:39 <petertodd> gmaxwell: sounds like it's time to set dates
8142016-09-22T19:54:41 <gmaxwell> My view on the next steps:
8152016-09-22T19:54:45 *** davec has joined #bitcoin-core-dev
8162016-09-22T19:54:54 <gmaxwell> (1) Create a bitcoincore.org or bitcoin.org announcement message.
8172016-09-22T19:55:16 <gmaxwell> (2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it.
8182016-09-22T19:55:26 <gmaxwell> (3) much later, send final alert.
8192016-09-22T19:55:46 <wumpus> I'd say we send the final alert with the 0.14 release
8202016-09-22T19:55:50 *** Chris_St1 has quit IRC
8212016-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)
8222016-09-22T19:55:59 *** Chris_Stewart_5 has joined #bitcoin-core-dev
8232016-09-22T19:56:09 <wumpus> then include code in there to send it to old peers that connect, as gmaxwell says
8242016-09-22T19:56:28 <BlueMatt> gmaxwell: ACK
8252016-09-22T19:56:35 <BlueMatt> wumpus: ACK final alert with 0.14
8262016-09-22T19:56:48 <jtimon> ack
8272016-09-22T19:56:49 <achow101> ack
8282016-09-22T19:56:51 <petertodd> gmaxwell: and release the privkey for the alert key w/ the final alert?
8292016-09-22T19:56:54 <btcdrak> ack
8302016-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.
8312016-09-22T19:57:08 <sipa> i'd release the key later even
8322016-09-22T19:57:09 <petertodd> gmaxwell: ack
8332016-09-22T19:57:16 <instagibbs> make sure to sweep the funds people have sent to the key :P
8342016-09-22T19:57:19 *** yep5555 has quit IRC
8352016-09-22T19:57:26 <petertodd> instagibbs: ha
8362016-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)
8372016-09-22T19:57:36 <BlueMatt> sipa: ack
8382016-09-22T19:57:52 <sipa> there may be alternate codebases that use the key who want to do something similar to (3) and (4)
8392016-09-22T19:58:10 <sipa> oh, wait
8402016-09-22T19:58:16 <sipa> they need the key for that
8412016-09-22T19:58:17 *** timothy has quit IRC
8422016-09-22T19:58:20 *** drizztbsd has joined #bitcoin-core-dev
8432016-09-22T19:58:24 <BlueMatt> 2 min
8442016-09-22T19:58:31 <instagibbs> any pressing topics
8452016-09-22T19:58:36 <wumpus> well after the final alert is sent, the key is only historical curiosity
8462016-09-22T19:58:42 <gmaxwell> okay, I'll send a message to the list.
8472016-09-22T19:58:47 <luke-jr> can the final alert match all clients?
8482016-09-22T19:58:56 *** drizztbsd is now known as timothy
8492016-09-22T19:59:05 <wumpus> luke-jr: you mean the pre-final alert, and yes
8502016-09-22T19:59:07 <petertodd> wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm
8512016-09-22T19:59:14 <gmaxwell> It cann't not match all clients.
8522016-09-22T19:59:30 <wumpus> gmaxwell: I think he means the penultimate alert
8532016-09-22T19:59:44 <wumpus> obviously the final alert matches all clients, at least those that still parse alerts
8542016-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/"
8552016-09-22T20:00:22 <wumpus> gmaxwell: wasn't that the point in adding it to the client?
8562016-09-22T20:00:29 <gmaxwell> I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions.
8572016-09-22T20:00:40 <petertodd> gmaxwell: sure, but that'll have been after months of alert - I'm not worried there
8582016-09-22T20:00:51 <wumpus> it applies to everyone using the key, not just users of bitcoin core
8592016-09-22T20:00:53 <gmaxwell> in any case, can continue after, we should wrap the meeting. :)
8602016-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
8612016-09-22T20:00:59 <instagibbs> ding ding
8622016-09-22T20:01:01 <btcdrak> ding ding ding
8632016-09-22T20:01:02 <wumpus> yes it's time
8642016-09-22T20:01:03 <wumpus> #endmeeting
8652016-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)
8662016-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
8672016-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
8682016-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
8692016-09-22T20:01:05 <sipa> bye
8702016-09-22T20:01:20 <wumpus> agree petertodd
8712016-09-22T20:01:43 <wumpus> this is not bitcoin core specific but everyone-that-embeds-that-pubkey specific
8722016-09-22T20:01:50 <Chris_Stewart_5> CodeShark: Did you have any concrete ideas for improving on BIP37?
8732016-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.
8742016-09-22T20:02:20 <petertodd> gmaxwell: I think the upgrade advice can be general "whatever you are running, upgade"
8752016-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
8762016-09-22T20:02:49 <wumpus> yes, it can just be a warning about the alert
8772016-09-22T20:02:57 <wumpus> it doesn't really have to tell to upgrade
8782016-09-22T20:03:05 <wumpus> just make sure peopel are aware
8792016-09-22T20:03:09 <btcdrak> that's a good idea
8802016-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.
8812016-09-22T20:03:20 <CodeShark> Chris_Stewart_5: proposals to put the filters in the blocks themselves seem at least slightly more promising
8822016-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.
8832016-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
8842016-09-22T20:05:21 *** timothy has quit IRC
8852016-09-22T20:05:24 *** drizztbsd has joined #bitcoin-core-dev
8862016-09-22T20:05:26 <petertodd> gmaxwell: otherwise if we add another segwit-like thing we need a new filter
8872016-09-22T20:05:33 <gmaxwell> petertodd: bandwidth overhead in that however.
8882016-09-22T20:05:46 <gmaxwell> because then you have to send the filter between full nodes. yuck.
8892016-09-22T20:05:52 <CodeShark> UTXO commitments + getutxos would probably be the quickest sync option that isn't totally insecure
8902016-09-22T20:05:53 <instagibbs> is the bitcoin wiki down for others for the last few days?
8912016-09-22T20:05:57 <petertodd> gmaxwell: true, though wasn't it only a few KB?
8922016-09-22T20:05:59 *** drizztbsd is now known as timothy
8932016-09-22T20:06:25 <CodeShark> Privacy issues are still a problem, though
8942016-09-22T20:06:38 <petertodd> CodeShark: I don't think we can reasonably implement UTXO commitments
8952016-09-22T20:07:05 <gmaxwell> there are also many other options for scanning, including ones that are private, like via PIR lookup.
8962016-09-22T20:07:23 <Chris_Stewart_5> Thanks gmaxwell, CodeShark, will read.
8972016-09-22T20:07:34 <petertodd> and it'd be good for some of those options to be implemented via central services first to prototype
8982016-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.
8992016-09-22T20:09:18 <petertodd> and a central service can be audited easily enough to detect censorship (assuming clients connect anonymously)
9002016-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.
9012016-09-22T20:09:37 <petertodd> or actually, commit to the contents of the filter, and then provide the filter
9022016-09-22T20:09:54 <petertodd> gmaxwell: true
9032016-09-22T20:09:57 <gmaxwell> petertodd: right you could talk to N hosts, and find that they all give the same commitment value.
9042016-09-22T20:10:11 <gmaxwell> without having to fetch the filter N times.
9052016-09-22T20:10:35 <gmaxwell> or even connect to one host and get a commitment signed by N parties.
9062016-09-22T20:10:36 <petertodd> gmaxwell: add a signature on the commitment and that should be enough
9072016-09-22T20:10:59 <gmaxwell> right.
9082016-09-22T20:11:18 <CodeShark> Thing is all these proposals significantly complicate client implementations
9092016-09-22T20:11:35 <petertodd> CodeShark: well, privacy is hard :)
9102016-09-22T20:11:41 <gmaxwell> checking a signature is not complex. :P
9112016-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.
9122016-09-22T20:12:05 <CodeShark> Ultimately, we need client implementations to be relatively simple or centralized API services will domimate
9132016-09-22T20:12:12 <CodeShark> *dominate
9142016-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
9152016-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
9162016-09-22T20:13:50 <CodeShark> or at the least we need some solid client-side libraries with multiple language bindings
9172016-09-22T20:14:09 <petertodd> CodeShark: does bloom filters even have that? :)
9182016-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
9192016-09-22T20:14:49 <CodeShark> petertodd: only the true diehards even attempt to use bloom filters rather than, say, bc.i :p
9202016-09-22T20:15:10 <petertodd> CodeShark: indeed - python-bitcoinlib is likely used 99% of the time with a local copy of Bitcoin Core
9212016-09-22T20:15:27 <gmaxwell> bc.i has better privacy than bloomfilters, IMO.
9222016-09-22T20:16:04 <CodeShark> but it's still a single point of failure
9232016-09-22T20:16:28 <petertodd> CodeShark: then use the Electrum servers! :)
9242016-09-22T20:16:38 <CodeShark> Argh - lol
9252016-09-22T20:17:09 * petertodd runs two OpenTimestamps public calendar servers and thinks that's good enough. :)
9262016-09-22T20:17:18 *** gabridome has quit IRC
9272016-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
9282016-09-22T20:18:10 <CodeShark> I run multiple bitcoin core instances and reluctantly use bip37
9292016-09-22T20:18:13 <luke-jr> http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf
9302016-09-22T20:18:58 <CodeShark> I get around the privacy and censorship issues by running my own instances
9312016-09-22T20:19:30 <CodeShark> Electrum is just an additional dependency I don't want
9322016-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
9332016-09-22T20:24:57 <luke-jr> if we merge script indexes, should probably do some p2p replacement for Electrum's protocol <.<
9342016-09-22T20:25:37 *** laurentmt has joined #bitcoin-core-dev
9352016-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
9362016-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.
9372016-09-22T20:29:42 <CodeShark> Then perhaps we need a different application model as well
9382016-09-22T20:33:51 <morcos> cfields: what happened to: https://github.com/theuni/bitcoin/tree/copy-move ?
9392016-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
9402016-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.
9412016-09-22T20:36:20 *** laurentmt has quit IRC
9422016-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!"
9432016-09-22T20:37:00 <gmaxwell> more than a little frightening too.
9442016-09-22T20:38:46 <gmaxwell> wumpus: what happened with the work on SSE sha2 and asm for the CRC32?
9452016-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
9462016-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.
9472016-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
9482016-09-22T20:46:06 *** jnewbery has quit IRC
9492016-09-22T20:48:51 *** cryptapus_afk is now known as cryptapus
9502016-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?
9512016-09-22T20:51:19 <luke-jr> that was before addresses
9522016-09-22T20:51:33 <luke-jr> (and raw multisig was never common use)
9532016-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
9542016-09-22T20:53:32 <Chris_Stewart_5> Interesting, I guess i'm conflating addresses and actually spending scriptPubKeys.
9552016-09-22T20:55:29 <Chris_Stewart_5> luke-jr: Was that functionality inside of Bitcoin Core? Inputing their ip address?
9562016-09-22T20:55:57 <luke-jr> Chris_Stewart_5: this was before Bitcoin Core's time, and also before my time :p
9572016-09-22T20:56:31 <luke-jr> Bitcoin started off with a wxWidgets Windows-only GUI client which was abandoned a long time ago
9582016-09-22T20:56:52 <Chris_Stewart_5> Haha fair enough, guess i'm getting more into history instead of development any way
9592016-09-22T20:59:38 <morcos> cfields: i'd love to double down, but will have to wait til tomorrow
9602016-09-22T21:01:55 <cfields> morcos: ok, will push there later. sanity checking now.
9612016-09-22T21:02:48 *** cis has quit IRC
9622016-09-22T21:05:01 *** sokei has joined #bitcoin-core-dev
9632016-09-22T21:10:31 *** crudel has quit IRC
9642016-09-22T21:15:33 *** Guyver2_ has joined #bitcoin-core-dev
9652016-09-22T21:17:41 *** Guyver2 has quit IRC
9662016-09-22T21:17:46 *** Guyver2_ is now known as Guyver2
9672016-09-22T21:25:54 *** achow101 has quit IRC
9682016-09-22T21:25:54 *** achow101 has joined #bitcoin-core-dev
9692016-09-22T21:30:01 *** jcorgan has quit IRC
9702016-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)
9712016-09-22T21:36:59 *** Chris_Stewart_5 has quit IRC
9722016-09-22T21:36:59 *** midnightmagic has quit IRC
9732016-09-22T21:36:59 *** mn3monic has quit IRC
9742016-09-22T21:36:59 *** jannes has quit IRC
9752016-09-22T21:36:59 *** dgenr8 has quit IRC
9762016-09-22T21:36:59 *** owowo has quit IRC
9772016-09-22T21:36:59 *** Magma has quit IRC
9782016-09-22T21:37:00 *** bsm117532 has quit IRC
9792016-09-22T21:37:00 *** LeMiner has quit IRC
9802016-09-22T21:37:00 *** d4de has quit IRC
9812016-09-22T21:37:00 *** TD-Linux has quit IRC
9822016-09-22T21:37:00 *** PatBoy has quit IRC
9832016-09-22T21:37:01 *** gluytium has quit IRC
9842016-09-22T21:37:01 *** jtimon has quit IRC
9852016-09-22T21:37:01 *** aalex has quit IRC
9862016-09-22T21:37:01 *** paveljanik has quit IRC
9872016-09-22T21:37:01 *** tadasv has quit IRC
9882016-09-22T21:37:01 *** jeremyrubin has quit IRC
9892016-09-22T21:37:01 *** blkdb has quit IRC
9902016-09-22T21:37:01 *** Lightsword has quit IRC
9912016-09-22T21:37:01 *** CyrusV has quit IRC
9922016-09-22T21:37:02 *** zxzzt has quit IRC
9932016-09-22T21:37:02 *** michagogo has quit IRC
9942016-09-22T21:37:02 *** zmanian__ has quit IRC
9952016-09-22T21:37:02 *** aspect_ has quit IRC
9962016-09-22T21:37:03 *** jouke_ has quit IRC
9972016-09-22T21:37:03 *** warren has quit IRC
9982016-09-22T21:37:03 *** CodeShark has quit IRC
9992016-09-22T21:37:03 *** echonaut has quit IRC
10002016-09-22T21:37:03 *** BlueMatt has quit IRC
10012016-09-22T21:37:04 *** Madars has quit IRC
10022016-09-22T21:37:04 *** lclc has quit IRC
10032016-09-22T21:37:04 *** ryan-c has quit IRC
10042016-09-22T21:37:04 *** andytoshi has quit IRC
10052016-09-22T21:37:04 *** BonyM1 has quit IRC
10062016-09-22T21:37:05 *** paracyst has quit IRC
10072016-09-22T21:37:05 *** achow101 has quit IRC
10082016-09-22T21:37:05 *** MrHodl has quit IRC
10092016-09-22T21:37:05 *** Ylbam has quit IRC
10102016-09-22T21:37:05 *** rogerwilco has quit IRC
10112016-09-22T21:37:05 *** berndj has quit IRC
10122016-09-22T21:37:05 *** limpkin has quit IRC
10132016-09-22T21:37:05 *** cfields has quit IRC
10142016-09-22T21:37:06 *** lesderid has quit IRC
10152016-09-22T21:37:06 *** ghtdak has quit IRC
10162016-09-22T21:37:06 *** morcos has quit IRC
10172016-09-22T21:37:06 *** mturquette has quit IRC
10182016-09-22T21:37:06 *** wallet42 has quit IRC
10192016-09-22T21:37:06 *** asoltys has quit IRC
10202016-09-22T21:37:06 *** trippysalmon has quit IRC
10212016-09-22T21:37:07 *** [b__b] has quit IRC
10222016-09-22T21:37:07 *** waxwing has quit IRC
10232016-09-22T21:37:07 *** wolfspraul has quit IRC
10242016-09-22T21:37:54 <luke-jr> mostly due to GCC 4.9 vs 5 mixing it seems
10252016-09-22T21:38:39 *** jtimon has joined #bitcoin-core-dev
10262016-09-22T21:38:39 *** aalex has joined #bitcoin-core-dev
10272016-09-22T21:38:39 *** paveljanik has joined #bitcoin-core-dev
10282016-09-22T21:38:39 *** tadasv has joined #bitcoin-core-dev
10292016-09-22T21:38:39 *** jeremyrubin has joined #bitcoin-core-dev
10302016-09-22T21:38:39 *** blkdb has joined #bitcoin-core-dev
10312016-09-22T21:38:39 *** aspect_ has joined #bitcoin-core-dev
10322016-09-22T21:38:39 *** Lightsword has joined #bitcoin-core-dev
10332016-09-22T21:38:39 *** CyrusV has joined #bitcoin-core-dev
10342016-09-22T21:38:39 *** zxzzt has joined #bitcoin-core-dev
10352016-09-22T21:38:39 *** michagogo has joined #bitcoin-core-dev
10362016-09-22T21:38:39 *** zmanian__ has joined #bitcoin-core-dev
10372016-09-22T21:38:39 *** jouke_ has joined #bitcoin-core-dev
10382016-09-22T21:38:39 *** warren has joined #bitcoin-core-dev
10392016-09-22T21:38:39 *** CodeShark has joined #bitcoin-core-dev
10402016-09-22T21:38:48 <sipa> i would expect to be the one distro that doesn't suffer from such issues :)
10412016-09-22T21:38:48 <sipa> *gentoo
10422016-09-22T21:39:23 *** michagogo has quit IRC
10432016-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
10442016-09-22T21:40:42 *** achow101 has joined #bitcoin-core-dev
10452016-09-22T21:40:42 *** MrHodl has joined #bitcoin-core-dev
10462016-09-22T21:40:42 *** Ylbam has joined #bitcoin-core-dev
10472016-09-22T21:40:42 *** rogerwilco has joined #bitcoin-core-dev
10482016-09-22T21:40:42 *** berndj has joined #bitcoin-core-dev
10492016-09-22T21:40:42 *** cfields has joined #bitcoin-core-dev
10502016-09-22T21:40:42 *** lesderid has joined #bitcoin-core-dev
10512016-09-22T21:40:42 *** ghtdak has joined #bitcoin-core-dev
10522016-09-22T21:40:42 *** morcos has joined #bitcoin-core-dev
10532016-09-22T21:40:42 *** mturquette has joined #bitcoin-core-dev
10542016-09-22T21:40:42 *** trippysalmon has joined #bitcoin-core-dev
10552016-09-22T21:40:42 *** asoltys has joined #bitcoin-core-dev
10562016-09-22T21:40:42 *** [b__b] has joined #bitcoin-core-dev
10572016-09-22T21:40:42 *** waxwing has joined #bitcoin-core-dev
10582016-09-22T21:40:42 *** wolfspraul has joined #bitcoin-core-dev
10592016-09-22T21:40:46 *** Expanse has quit IRC
10602016-09-22T21:40:51 *** zmanian__ has quit IRC
10612016-09-22T21:41:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
10622016-09-22T21:41:01 *** midnightmagic has joined #bitcoin-core-dev
10632016-09-22T21:41:01 *** mn3monic has joined #bitcoin-core-dev
10642016-09-22T21:41:01 *** jannes has joined #bitcoin-core-dev
10652016-09-22T21:41:01 *** dgenr8 has joined #bitcoin-core-dev
10662016-09-22T21:41:01 *** owowo has joined #bitcoin-core-dev
10672016-09-22T21:41:17 *** Magma has joined #bitcoin-core-dev
10682016-09-22T21:41:33 *** bsm117532 has joined #bitcoin-core-dev
10692016-09-22T21:41:33 *** LeMiner has joined #bitcoin-core-dev
10702016-09-22T21:41:33 *** d4de has joined #bitcoin-core-dev
10712016-09-22T21:41:33 *** TD-Linux has joined #bitcoin-core-dev
10722016-09-22T21:41:33 *** PatBoy has joined #bitcoin-core-dev
10732016-09-22T21:41:33 *** gluytium has joined #bitcoin-core-dev
10742016-09-22T21:42:48 *** echonaut has joined #bitcoin-core-dev
10752016-09-22T21:42:48 *** BlueMatt has joined #bitcoin-core-dev
10762016-09-22T21:42:48 *** andytoshi has joined #bitcoin-core-dev
10772016-09-22T21:42:48 *** Madars has joined #bitcoin-core-dev
10782016-09-22T21:42:48 *** lclc has joined #bitcoin-core-dev
10792016-09-22T21:42:48 *** ryan-c has joined #bitcoin-core-dev
10802016-09-22T21:42:48 *** BonyM1 has joined #bitcoin-core-dev
10812016-09-22T21:42:48 *** paracyst has joined #bitcoin-core-dev
10822016-09-22T21:47:32 *** Expanse has joined #bitcoin-core-dev
10832016-09-22T21:49:15 *** MarcoFalke has joined #bitcoin-core-dev
10842016-09-22T21:51:04 *** Frederic94500 has joined #bitcoin-core-dev
10852016-09-22T21:54:37 *** Frederic94500 has quit IRC
10862016-09-22T22:05:52 *** wallet42 has joined #bitcoin-core-dev
10872016-09-22T22:12:34 *** limpkin has joined #bitcoin-core-dev
10882016-09-22T22:16:11 *** Alopex has quit IRC
10892016-09-22T22:16:45 *** zmanian__ has joined #bitcoin-core-dev
10902016-09-22T22:17:16 *** Alopex has joined #bitcoin-core-dev
10912016-09-22T22:19:12 *** michagogo has joined #bitcoin-core-dev
10922016-09-22T22:22:32 *** jnewbery has joined #bitcoin-core-dev
10932016-09-22T22:28:28 *** cryptapus is now known as cryptapus_afk
10942016-09-22T22:36:22 *** murch has quit IRC
10952016-09-22T22:43:41 *** justan0theruser has joined #bitcoin-core-dev
10962016-09-22T22:44:14 *** Guyver2 has quit IRC
10972016-09-22T22:46:33 *** justanotheruser has quit IRC
10982016-09-22T22:55:19 <gmaxwell> Re PR #8661 is there a reason that this isn't getting merged?
10992016-09-22T22:58:28 *** MarcoFalke has left #bitcoin-core-dev
11002016-09-22T22:58:30 *** jnewbery has quit IRC
11012016-09-22T23:02:36 *** crudel has joined #bitcoin-core-dev
11022016-09-22T23:16:40 *** rogerwilco has quit IRC
11032016-09-22T23:17:26 *** rogerwilco has joined #bitcoin-core-dev
11042016-09-22T23:23:38 *** d4de has quit IRC
11052016-09-22T23:39:05 *** jnewbery has joined #bitcoin-core-dev
11062016-09-22T23:41:54 *** jnewbery has quit IRC
11072016-09-22T23:42:51 *** randy-waterhouse has joined #bitcoin-core-dev
11082016-09-22T23:43:12 *** randy-waterhouse has joined #bitcoin-core-dev