1 2016-05-26 13:02:36	0|GitHub106|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6fc6325f77ee...c028c7b7557d
  2 2016-05-26 13:02:37	0|GitHub106|13bitcoin/06master 141ab1dc3 15Wladimir J. van der Laan: rpc: Add `relaytxes` flag to `getnetworkinfo`...
  3 2016-05-26 13:02:37	0|GitHub106|13bitcoin/06master 14581ddff 15Wladimir J. van der Laan: net: Add fRelayTxes flag...
  4 2016-05-26 13:02:38	0|GitHub106|13bitcoin/06master 14c028c7b 15Pieter Wuille: Merge #8049: Expose information on whether transaction relay is enabled in `getnetwork`...
  5 2016-05-26 13:02:46	0|GitHub121|[13bitcoin] 15sipa closed pull request #8049: Expose information on whether transaction relay is enabled in `getnetwork` (06master...062016_05_rpc_relaytxes) 02https://github.com/bitcoin/bitcoin/pull/8049
  6 2016-05-26 14:36:57	0|CodeShark|sipa: wumpus: We should disable mining by default on nonrelease branches as discussed earlier. I started working on this idea: https://github.com/CodeShark/bitcoin/commit/34ec9e8af22f40abdcc49c32e7e153a050613ee1
  7 2016-05-26 14:37:38	0|CodeShark|the IsDevelopmentBranch() method should check whether it is a release branch or not rather than just whether it's the master branch
  8 2016-05-26 14:38:44	0|CodeShark|is there a simple way we can determine this?
  9 2016-05-26 15:02:34	0|luke-jr|CodeShark: IMO mining is the least problematic use of dev branches..
 10 2016-05-26 15:02:47	0|luke-jr|miners are used to patching and overriding stuff anyway
 11 2016-05-26 15:03:39	0|luke-jr|might make more sense to disable wallet and/or bloom
 12 2016-05-26 15:04:21	0|CodeShark|luke-jr: the goal is to make it safer to merge consensus changes before releasing
 13 2016-05-26 15:04:35	0|CodeShark|if the changes are merged into master they will get more tested
 14 2016-05-26 15:39:47	0|GitHub162|[13bitcoin] 15CodeShark opened pull request #8101: Disable mining on nonrelease branches. (06master...06disable_mining_on_nonrelease_branches) 02https://github.com/bitcoin/bitcoin/pull/8101
 15 2016-05-26 15:52:10	0|sipa|sdaftuar: what type is 'f' in the deserialize methods in mininode?
 16 2016-05-26 15:52:22	0|sipa|or more specifically, can i test whether there are more bytes to read?
 17 2016-05-26 15:52:34	0|sdaftuar|f?
 18 2016-05-26 15:52:41	0|sdaftuar|oph
 19 2016-05-26 15:53:05	0|sipa|i'm adding a test that fRelayTxes in version is correct (because it's currently broken in master, and no test detected it)
 20 2016-05-26 15:53:15	0|sipa|but fRelayTxes is currently not deserialized
 21 2016-05-26 15:53:21	0|sipa|and it's optional per bip37
 22 2016-05-26 15:53:25	0|sdaftuar|ah ok
 23 2016-05-26 15:54:14	0|sdaftuar|i assume it's possible to tell if there are more bytes to read but i don't know how off the top of my head.  f is a BytesIO i think?
 24 2016-05-26 15:54:39	0|sipa|i am going to guess it has a eof() method
 25 2016-05-26 16:01:40	0|sdaftuar|doesn't seem to?  docs i'm reading suggest you just call read() and see if you don't get anything back
 26 2016-05-26 16:01:58	0|sipa|yup
 27 2016-05-26 16:18:40	0|btcdrak|sipa: it needs feeding.
 28 2016-05-26 16:41:37	0|CodeShark|sipa: throw a mouse at it
 29 2016-05-26 16:43:16	0|sipa|sdaftuar: so the bug is that a connecting node currently never sets fRelayTxes... and it seems we have not a single test for that
 30 2016-05-26 16:43:32	0|sipa|sdaftuar: the p2p tests only connect a testnode to a real node, and not the other way around
 31 2016-05-26 16:47:43	0|GitHub39|[13bitcoin] 15sipa opened pull request #8102: Bugfix: use global ::fRelayTxes instead of CNode in version send (06master...06oopsrelay) 02https://github.com/bitcoin/bitcoin/pull/8102
 32 2016-05-26 16:49:55	0|sipa|sdaftuar: is that possible, or am i missing an extra condition that makes this harder to test?
 33 2016-05-26 17:21:10	0|sdaftuar|sipa: you're right that in the testing framework, testnodes connect out to real nodes and not the other way around.
 34 2016-05-26 17:21:15	0|sdaftuar|i'm taking a look at 8102
 35 2016-05-26 17:22:40	0|btcdrak|sdaftuar: is the list of cfpf related pulls #7600, #7960 and #7292? am i missing any?
 36 2016-05-26 17:23:35	0|sdaftuar|btcdrak: just #7600 and #7598.  7598 is a refactor of CreateNewBlock; 7600 builds off it
 37 2016-05-26 17:27:33	0|sdaftuar|sipa: i'm baffled that this breakage wasn't caught in our existing RPC tests.  surely anywhere we call sync_mempools() we would have seen a test failure?
 38 2016-05-26 17:29:49	0|sipa|sdaftuar: perhaps there are more requirements before this triggers
 39 2016-05-26 17:30:37	0|sipa|i saw this bug when syncing over thr internet... perhaps the rpc tests run fast enough
 40 2016-05-26 17:30:51	0|sipa|it is related to responses to version messages
 41 2016-05-26 17:31:57	0|wumpus|I'm not going to be able to attend the meeting today probably
 42 2016-05-26 17:33:28	0|sipa|wumpus: ok
 43 2016-05-26 17:37:42	0|sdaftuar|sipa: aha, we do have a travis issue.
 44 2016-05-26 17:38:18	0|sdaftuar|check this out: https://travis-ci.org/bitcoin/bitcoin/jobs/129694378
 45 2016-05-26 17:38:44	0|sdaftuar|looks like the tests hung, and then at some much later point the instance shut down(!)
 46 2016-05-26 17:38:47	0|sdaftuar|and no failure was reported
 47 2016-05-26 17:40:05	0|sipa|ugh
 48 2016-05-26 17:41:09	0|sdaftuar|i've been meaning to fix up the sync_() functions in util.py to be more robust for a while now.  we can do that at the least.
 49 2016-05-26 17:41:27	0|sdaftuar|separately we should also figure out what's going on with travis here
 50 2016-05-26 17:44:13	0|btcdrak|sipa: could you please restart the two error jobs on https://travis-ci.org/bitcoin/bitcoin/builds/133144138
 51 2016-05-26 17:45:02	0|sipa|will do when i get home in 15 min
 52 2016-05-26 18:03:06	0|sipa|btcdrak: won't work, master is broken
 53 2016-05-26 18:03:23	0|btcdrak|oh
 54 2016-05-26 18:03:29	0|sipa|merging 8102 now
 55 2016-05-26 18:03:31	0|sdaftuar|sipa:
 56 2016-05-26 18:03:39	0|sdaftuar|8102, you default fRelayTxes to false in mininode
 57 2016-05-26 18:03:41	0|sdaftuar|shouldn't that be true?
 58 2016-05-26 18:03:52	0|sipa|sdaftuar: good point!
 59 2016-05-26 18:03:55	0|sdaftuar|otherwise p2p tests that test receiving tx inv's would break
 60 2016-05-26 18:04:00	0|sdaftuar|we might not have any though (yet)
 61 2016-05-26 18:04:00	0|sipa|let me merge that without the mininode changes
 62 2016-05-26 18:04:04	0|sdaftuar|ok sounds good
 63 2016-05-26 18:15:36	0|GitHub132|13bitcoin/06master 1452b02ec 15Pieter Wuille: Use global ::fRelayTxes instead of CNode one
 64 2016-05-26 18:15:36	0|GitHub132|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c028c7b7557d...425278d17bd0
 65 2016-05-26 18:15:37	0|GitHub132|13bitcoin/06master 14425278d 15Pieter Wuille: Merge #8102: Bugfix: use global ::fRelayTxes instead of CNode in version send...
 66 2016-05-26 18:15:45	0|GitHub160|[13bitcoin] 15sipa closed pull request #8102: Bugfix: use global ::fRelayTxes instead of CNode in version send (06master...06oopsrelay) 02https://github.com/bitcoin/bitcoin/pull/8102
 67 2016-05-26 18:41:07	0|GitHub124|[13bitcoin] 15sdaftuar opened pull request #8104: Tests: add timeout to sync_blocks() and sync_mempools() (06master...06improve-rpc-sync) 02https://github.com/bitcoin/bitcoin/pull/8104
 68 2016-05-26 19:00:28	0|sipa|meetink?
 69 2016-05-26 19:02:10	0|jonasschnelli|Yes.
 70 2016-05-26 19:03:04	0|CodeShark|let's do it
 71 2016-05-26 19:03:12	0|sipa|waiting for some more people
 72 2016-05-26 19:03:26	0|cfields_|here
 73 2016-05-26 19:04:48	0|paveljanik|here
 74 2016-05-26 19:05:12	0|cfields_|sipa: interestingly: on the net refactor branch I'm rebasing, it magically quit working after rebasing to (this morning's) master. after nabbing your fix, all is good now
 75 2016-05-26 19:05:35	0|sdaftuar|here
 76 2016-05-26 19:05:45	0|sipa|kanzure, sdaftuar, luke-jr, morcos, jl2012, gmaxwell, nickler, instagibbs, jtimon, petertodd: ping
 77 2016-05-26 19:05:50	0|gribble|Error: "beginmeeting" is not a valid command.
 78 2016-05-26 19:05:50	0|sipa|!beginmeeting
 79 2016-05-26 19:05:53	0|sipa|!meetingbegin
 80 2016-05-26 19:05:54	0|gribble|Error: "meetingbegin" is not a valid command.
 81 2016-05-26 19:05:56	0|gribble|Error: "meetingstart" is not a valid command.
 82 2016-05-26 19:05:56	0|sipa|!meetingstart
 83 2016-05-26 19:05:57	0|sdaftuar|startmeeting i think?
 84 2016-05-26 19:06:01	0|btcdrak|# startmeeting
 85 2016-05-26 19:06:01	0|gribble|Error: "startmeeting" is not a valid command.
 86 2016-05-26 19:06:01	0|sipa|!startmeeting
 87 2016-05-26 19:06:03	0|btcdrak|without the space
 88 2016-05-26 19:06:07	0|sipa|#startmeeting
 89 2016-05-26 19:06:08	0|lightningbot|Meeting started Thu May 26 19:06:07 2016 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
 90 2016-05-26 19:06:08	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 91 2016-05-26 19:06:12	0|sipa|yay
 92 2016-05-26 19:06:13	0|sipa|topics?
 93 2016-05-26 19:06:17	0|btcdrak|sipa was wardialing
 94 2016-05-26 19:06:17	0|kanzure|zurich transcript coming soon
 95 2016-05-26 19:06:33	0|btcdrak|kanzure: I can push it now if you like
 96 2016-05-26 19:06:36	0|kanzure|we can copy-paste topics from zurich for follow-up
 97 2016-05-26 19:06:40	0|kanzure|btcdrak: sure let's do that
 98 2016-05-26 19:07:12	0|sipa|i have a topic: segwit vs netrefactor
 99 2016-05-26 19:07:27	0|kanzure|i believe the conclusion from zurich was that sipa promised everyone tree sigs and poly sigs within 4 days
100 2016-05-26 19:07:40	0|btcdrak|kanzure: zurich meeting notes https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.txt
101 2016-05-26 19:08:02	0|kanzure|ouch no anchor links. well, okay.
102 2016-05-26 19:08:32	0|kanzure|btw i heard from someone that they were surprised that libconsensus refactoring was considered lower priority than segwit
103 2016-05-26 19:08:37	0|kanzure|just some interesting feedback.
104 2016-05-26 19:08:42	0|btcdrak|kanzure: could be arranged.
105 2016-05-26 19:08:52	0|btcdrak|sipa: ack
106 2016-05-26 19:09:16	0|cfields_|sipa: sure. Though i suspect the (my, anyway) answer will be "segwit comes first, hands-down"
107 2016-05-26 19:09:23	0|sipa|cfields_: ok, settled :)
108 2016-05-26 19:09:45	0|sipa|kanzure: good feedback... i think it's mostly that segwit has much more buy-in as a roadmap (but i'm biased here)
109 2016-05-26 19:09:46	0|btcdrak|was that even a question. segwit first.
110 2016-05-26 19:10:16	0|cfields_|sipa: for sure. I'm working on it in parallel, but I have no desire to slow segwit down for it in any way
111 2016-05-26 19:10:21	0|kanzure|right, right. it's more of a long-term note--- but eventually we will have to bite the bullet and absorb the pain of the refactor impacting everyone's branches.
112 2016-05-26 19:10:22	0|CodeShark|libconsensus is strategically at least as important as segwit - but the coordination issues required are considerable
113 2016-05-26 19:10:32	0|wumpus|what do segwit and net refactor compete on?
114 2016-05-26 19:10:38	0|sipa|wumpus: code :)
115 2016-05-26 19:10:56	0|wumpus|which parts? does net refactor give you significantly more trouble rebasing?
116 2016-05-26 19:10:59	0|CodeShark|also, libconsensus isn't as glitsy :)
117 2016-05-26 19:11:01	0|sipa|probably not
118 2016-05-26 19:11:11	0|kanzure|what is the status of net refactor things?
119 2016-05-26 19:11:29	0|btcdrak|where does compact blocks fit in?
120 2016-05-26 19:11:31	0|sipa|libconsensus refactoring worked well in the 0.10 window, because it seemed there was a clear goal (getting script exposed) and a clear way to do it... further refactors seem to be more one-person shows (not that i blame those people, but if we want them to happen, i think we'll need to agree on a plan beforehand)
121 2016-05-26 19:11:42	0|wumpus|well I can understand how libconsensus conflicts with segwit
122 2016-05-26 19:11:57	0|kanzure|wasn't aware of previous concerns about libconsensus plan synchronization, good to know
123 2016-05-26 19:12:01	0|sipa|libconsensus conflicts with everything :)
124 2016-05-26 19:12:19	0|wumpus|there's also some network changes for segwit, but they're at a message level
125 2016-05-26 19:12:29	0|wumpus|whereas cfields' network refactor is at a lower level
126 2016-05-26 19:12:40	0|cfields_|kanzure: see #8085. I addressed wumpus's notes from Zurich, but that made it rough to read. I'm working on another version of the same thing with a clean history, done by tomorrow for sure
127 2016-05-26 19:12:40	0|sipa|yeah, network refactor probably hurts compact blocks more than it hurts segwit
128 2016-05-26 19:12:47	0|CodeShark|as much as it pains me to sacrifice on architecture, I think holding up segwit right now is much more costly in terms of the public's goodwill
129 2016-05-26 19:13:31	0|jcorgan|+1
130 2016-05-26 19:13:40	0|wumpus|I agree progress in the protocol is more important, I think segwit even affects the proposed libconsensus API
131 2016-05-26 19:13:53	0|sipa|worse, it affects the current libconsensus API :)
132 2016-05-26 19:14:21	0|sipa|ok, other topics?
133 2016-05-26 19:14:37	0|sipa|i have a few more
134 2016-05-26 19:14:56	0|sipa|CPFP will also need to go in at some point, and also conflicts with many in-flight things
135 2016-05-26 19:15:06	0|sipa|and a whole range of relay improvement
136 2016-05-26 19:15:08	0|wumpus|libconsensus feels more like some checkbox people want checked than something that will actually have a lot of users but feel free to prove me wrong
137 2016-05-26 19:15:30	0|sdaftuar|if we think segwit will be backported to 0.12, then probably CPFP should wait until afterward?
138 2016-05-26 19:15:35	0|wumpus|it should be done but unless someone has a clear example of an application using it and contributes to it it has not much priority
139 2016-05-26 19:15:42	0|sdaftuar|to avoid dealing with the CNB refactor in 0.12
140 2016-05-26 19:15:42	0|sipa|when i talk about libconsensus i mean "abstracting out consensus logic"... not so much an actual API exposure
141 2016-05-26 19:16:36	0|wumpus|sipa: that's what I mean right, I'm not sure other people talkinga bout it mean the same thing
142 2016-05-26 19:16:51	0|wumpus|at some point it becomes just a buzzword... :)
143 2016-05-26 19:16:52	0|sipa|maybe i should formulate the question this way: segwit, compact blocks, CPFP... all for 0.13?
144 2016-05-26 19:16:59	0|wumpus|that's a bit much
145 2016-05-26 19:17:19	0|wumpus|for just before the feature freeze
146 2016-05-26 19:17:43	0|sdaftuar|sipa: yes!
147 2016-05-26 19:17:50	0|wumpus|(2016-06-16)
148 2016-05-26 19:18:13	0|sipa|i would very much like to have at least compact blocks in before segwit, to alleviate the extra relay latency
149 2016-05-26 19:18:22	0|wumpus|I don't think we should make a habit of merging such big things just before a release
150 2016-05-26 19:18:48	0|sdaftuar|segwit is clearly the heaviest lift here to review...  i think the otherw two things can be knocked out very quickly
151 2016-05-26 19:18:55	0|wumpus|segwit is obvious
152 2016-05-26 19:19:07	0|sdaftuar|but that's the thing where it's not clear to me if it'll be sufficiently reviewed by 6/16
153 2016-05-26 19:19:18	0|wumpus|yes that'st he thing what counts
154 2016-05-26 19:19:47	0|btcdrak|compact blocks would be good in 0.13
155 2016-05-26 19:19:57	0|wumpus|segwit should be merged soon so that we can do 0.12.1 before 0.13
156 2016-05-26 19:20:04	0|CodeShark|on that topic...
157 2016-05-26 19:20:30	0|sipa|we can merge segwit with no softfork defined for it on mainnet
158 2016-05-26 19:20:51	0|wumpus|we've already moved the release for 0.13 with a month so I'd really like to not move it again
159 2016-05-26 19:20:53	0|sdaftuar|sipa: interesting!  i hadn't considered that
160 2016-05-26 19:20:57	0|CodeShark|sipa: indeed!
161 2016-05-26 19:21:14	0|CodeShark|and even once we do add the segwit softfork we can disable mining on it until release
162 2016-05-26 19:21:15	0|sipa|#idea merge segwit without defined softfork
163 2016-05-26 19:21:35	0|cfields_|hmm
164 2016-05-26 19:22:12	0|wumpus|sure
165 2016-05-26 19:22:23	0|sdaftuar|i guess the thing to worry about is if we have testing gaps, things might break without anyone noticing?
166 2016-05-26 19:22:24	0|wumpus|just to have the code in?
167 2016-05-26 19:22:30	0|luke-jr|need vb gbt before segwit tho..? maybe not if left undefined, unsure
168 2016-05-26 19:22:37	0|sipa|luke-jr: yup
169 2016-05-26 19:22:42	0|sipa|luke-jr: will look at that
170 2016-05-26 19:23:14	0|wumpus|sdaftuar: well the tests need to cover it
171 2016-05-26 19:23:31	0|sipa|all the segwit tests use regtest
172 2016-05-26 19:23:31	0|wumpus|if there's a testing gap it should not be merged in any case
173 2016-05-26 19:23:37	0|wumpus|right
174 2016-05-26 19:23:52	0|wumpus|for that it doesn't matter whether a softfork is defined on mainnet
175 2016-05-26 19:24:01	0|sipa|indeed
176 2016-05-26 19:24:11	0|sipa|and for script/tx tests, the softfork is not relevant
177 2016-05-26 19:24:17	0|luke-jr|sipa: should I look into merging vbgbt w segwit?
178 2016-05-26 19:24:19	0|achow101|what benefit would there be to not define the softfork when mergin segwit
179 2016-05-26 19:24:49	0|sipa|achow101: segwit conflicts with a lot of code, having it in would simplify further development on the branch
180 2016-05-26 19:24:51	0|btcdrak|sipa: we should merge without mainnet, because it will allow people to test on testnet now (it's already been activated in testnet).
181 2016-05-26 19:24:53	0|wumpus|achow101: to have the code in, so that development happens on top
182 2016-05-26 19:25:08	0|wumpus|achow101: and so that people acn use it on the regtest/testnet network
183 2016-05-26 19:25:12	0|sipa|btcdrak: another good reason, indeed
184 2016-05-26 19:25:28	0|wumpus|btw: should we keep the segnet?
185 2016-05-26 19:25:35	0|sipa|no, i want to drop it
186 2016-05-26 19:25:38	0|btcdrak|wumpus: no segnet should go
187 2016-05-26 19:25:42	0|sipa|unless there is a good reason to keep it
188 2016-05-26 19:25:43	0|wumpus|ok
189 2016-05-26 19:25:55	0|wumpus|(no opinion either way just wondering whether that's supposed to end up in master)
190 2016-05-26 19:26:13	0|btcdrak|sipa: there's no need to drop it in merge to master right away imo, but certainly before we add parameters to mainnet.
191 2016-05-26 19:26:14	0|wumpus|yes as it has been triggered on testnet
192 2016-05-26 19:26:39	0|sipa|i will prioritize the testnet dns seed filtering, vb/gbt changes, and doing another batch
193 2016-05-26 19:26:49	0|kanzure|merging segwit without activation might lessen the pressure on reviewers
194 2016-05-26 19:26:54	0|kanzure|which might be a negative side effect
195 2016-05-26 19:26:59	0|sdaftuar|kanzure: agree
196 2016-05-26 19:27:32	0|wumpus|anyhow if the segnet network helps testing I don't have problems with temporarily having it in master, as long as it is clearly communicated that people shouldn't rely on it
197 2016-05-26 19:27:55	0|sipa|i wasn't planning on including it in master
198 2016-05-26 19:28:10	0|wumpus|well playing psychological meta-tricks on reviewers doesn't play much of a role imo, we should do whatever is practical
199 2016-05-26 19:28:43	0|wumpus|if merging segwit helps make progress on other fronts so that 0.13 can be a better release
200 2016-05-26 19:28:45	0|wumpus|we should do that
201 2016-05-26 19:29:10	0|wumpus|also having it merged in master usually means it gets more testing and review, not less
202 2016-05-26 19:29:13	0|sipa|i'll do one more batch, and if there are some ACKs then, i'll squash
203 2016-05-26 19:29:31	0|kanzure|so it would be active in testnet segnet and regtest when merged, but not mainnet, and letting others maintain segwit for other 0.13 changes?
204 2016-05-26 19:29:50	0|sipa|kanzure: don't understand the last part
205 2016-05-26 19:30:04	0|sipa|if there are changes necessary to the code post-merge but pre-release, they can just go in master
206 2016-05-26 19:30:05	0|kanzure|the ideal of merging soon is to let others maintain segwit for possibly conflicting 0.13 changes?
207 2016-05-26 19:30:20	0|wumpus|there's not *that* much time left for 0.13, it's good to decide now what we still want to have in and focus on that
208 2016-05-26 19:30:31	0|sipa|kanzure: to let others rebase their own patches on top
209 2016-05-26 19:30:45	0|wumpus|well not 'maintain segwit' but work on top, yes
210 2016-05-26 19:30:57	0|btcdrak|kanzure: the only difference is not having activation params on mainnet. it would really help by not holding up other work.
211 2016-05-26 19:31:23	0|sdaftuar|sipa: would you still plan to backport to 0.12?
212 2016-05-26 19:31:31	0|sipa|sdaftuar: yes, but after merge in master
213 2016-05-26 19:31:40	0|sipa|(but before defining activation)
214 2016-05-26 19:31:43	0|sdaftuar|ok
215 2016-05-26 19:32:06	0|sipa|ok, other topics?
216 2016-05-26 19:32:11	0|gmaxwell|The non-merged status of segwit has kinda been holding up other work, unfortunately.
217 2016-05-26 19:32:46	0|kanzure|maybe bip151 things?
218 2016-05-26 19:33:12	0|sipa|status bip151: waiting for implementation
219 2016-05-26 19:33:14	0|sipa|i'd say :)
220 2016-05-26 19:33:20	0|instagibbs|sdaftuar, is that list of testing gaps public somewhere?
221 2016-05-26 19:33:22	0|kanzure|ok
222 2016-05-26 19:33:24	0|instagibbs|(sorry, backtracking)
223 2016-05-26 19:33:40	0|kanzure|https://gist.github.com/sdaftuar/0469a2583f33989cf8196d2f26d99114
224 2016-05-26 19:33:48	0|sdaftuar|instagibbs: yes, now :)
225 2016-05-26 19:34:07	0|luke-jr|lol
226 2016-05-26 19:34:16	0|instagibbs|not really my meaning, but ok ;P
227 2016-05-26 19:34:40	0|petertodd|re: bip151, I mentioned it today at the conf I was at to some cryptographers, and their response to it not being an off the shelf standard was horror :) might be a pr issue
228 2016-05-26 19:35:03	0|sipa|petertodd: it's openssh's chacha20-poly1305 exactly
229 2016-05-26 19:35:08	0|kanzure|were they horrified about the current implementation at all
230 2016-05-26 19:35:39	0|petertodd|sipa: good, we should make that 110% clear then
231 2016-05-26 19:35:39	0|sipa|petertodd: maybe that needs to be made more clear
232 2016-05-26 19:35:48	0|gmaxwell|it's pretty clear in the BIP now, I thought.
233 2016-05-26 19:35:57	0|gmaxwell|maybe it could be moved up to the top.
234 2016-05-26 19:36:17	0|petertodd|gmaxwell: yeah, move it to the top - I just looked at it and didn't see that
235 2016-05-26 19:36:45	0|sipa|#action jonasschnelli make it more clean that bip151 uses openssh's chacha20-poly1305 standard
236 2016-05-26 19:36:46	0|btcdrak|ok make that an action point for the logs
237 2016-05-26 19:36:56	0|sipa|jinx
238 2016-05-26 19:37:27	0|petertodd|make it clear that the standard *describes* a subset of openssh's standard, and that bitcoin's use of it is identical and can reuse the existing code
239 2016-05-26 19:37:40	0|kanzure|pus or minus licensing issues?
240 2016-05-26 19:37:44	0|kanzure|*plus
241 2016-05-26 19:38:16	0|jonasschnelli|Ack. Will do
242 2016-05-26 19:38:26	0|petertodd|kanzure: https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/LICENCE <- looks like BSD at least, no GPL code
243 2016-05-26 19:38:47	0|sipa|the actual cipher is public domain code
244 2016-05-26 19:38:52	0|sipa|the glue into openssh is BSD
245 2016-05-26 19:41:19	0|kanzure|petertodd: thanks for checking
246 2016-05-26 19:42:10	0|sipa|anything else?
247 2016-05-26 19:42:18	0|sipa|(mental note: type #topic next time)
248 2016-05-26 19:42:41	0|btcdrak|no just #topic
249 2016-05-26 19:42:47	0|kanzure|child-pays-for-parent?
250 2016-05-26 19:43:08	0|kanzure|and wasn't there something activating soon that we were looking at
251 2016-05-26 19:43:28	0|sdaftuar|happy to talk about CPFP, are there any questions?
252 2016-05-26 19:43:33	0|sipa|#topic child pay for parent
253 2016-05-26 19:44:06	0|sipa|i think the blocker is just the refactor for CNB
254 2016-05-26 19:44:15	0|sipa|which will conflict with segwit
255 2016-05-26 19:44:40	0|sdaftuar|right
256 2016-05-26 19:45:01	0|luke-jr|so maybe target 0.14
257 2016-05-26 19:45:04	0|luke-jr|?
258 2016-05-26 19:45:24	0|sipa|at the latest, i'd say
259 2016-05-26 19:45:30	0|kanzure|oh i forgot about the testing infrastructure stuff for sdaftuar
260 2016-05-26 19:45:36	0|kanzure|sdaftuar: something i mentioned in person a few days ago, https://www.terraform.io/
261 2016-05-26 19:45:37	0|sipa|but yes, it may miss 0.13
262 2016-05-26 19:45:38	0|sdaftuar|i will be sad if it is necessary to push it back that far
263 2016-05-26 19:45:46	0|sipa|me too
264 2016-05-26 19:46:26	0|sdaftuar|has anyone tried to test or review #7600?
265 2016-05-26 19:47:14	0|sipa|i started looking at it, but not in detail
266 2016-05-26 19:47:53	0|sdaftuar|alright, well no point in talking about blockers until it's been reviewed
267 2016-05-26 19:48:05	0|gmaxwell|I beleive I applied it to a node and started it. (but then switched out of it to test something else) It's on my list.
268 2016-05-26 19:50:12	0|sipa|other topics?
269 2016-05-26 19:50:34	0|CodeShark|sipa: your suggestion seems superior to 8101 :p
270 2016-05-26 19:50:38	0|CodeShark|at least for now
271 2016-05-26 19:50:51	0|CodeShark|I was going to bring that up...but perhaps we can defer that discussion
272 2016-05-26 19:50:51	0|luke-jr|sdaftuar: I'll be sad too: it's been waiting since like 0.4 :p
273 2016-05-26 19:51:38	0|sipa|luke-jr: well, feel free to help review/test 7600 already
274 2016-05-26 19:51:47	0|gmaxwell|I will be sad to not get CPFP in soon if that happens, especially considering all the work that it's taken to get it this far.
275 2016-05-26 19:52:10	0|sipa|so i would encourage people to review
276 2016-05-26 19:52:53	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-26-19.06.log.html
277 2016-05-26 19:52:53	0|lightningbot|Meeting ended Thu May 26 19:52:53 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
278 2016-05-26 19:52:53	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-26-19.06.html
279 2016-05-26 19:52:53	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-26-19.06.txt
280 2016-05-26 19:52:53	0|sipa|#endmeeting
281 2016-05-26 19:52:59	0|gmaxwell|[OT] There appears to be an emergent effort to flood reddit with recursive posts about BIP 151: http://imgur.com/xId5scH
282 2016-05-26 19:53:13	0|luke-jr|bbiab
283 2016-05-26 19:53:47	0|petertodd|gmaxwell: you guys suck at mixnets
284 2016-05-26 19:54:06	0|gmaxwell|adam's post is the best so far https://www.reddit.com/r/Bitcoin/comments/4l74p5/jameson_lopp_lukejr_gregory_maxwell_eragmus/
285 2016-05-26 19:54:36	0|btcdrak|LMAO
286 2016-05-26 19:57:01	0|sipa|i for one welcome the new recursively compressing overlords
287 2016-05-26 19:57:19	0|sipa|s/compressing/encrypting/
288 2016-05-26 19:58:27	0|petertodd|I for one welcome sipa's welcoming nature
289 2016-05-26 19:58:43	0|btcdrak|+1
290 2016-05-26 19:59:39	0|petertodd|C-C-C-C-C-C-C-Combo Breaker!
291 2016-05-26 20:12:13	0|gmaxwell|sipa: why didn't warnings save us from the global aliasing bug you fixed today?
292 2016-05-26 20:14:06	0|sipa|gmaxwell: #8105
293 2016-05-26 20:14:26	0|sipa|and travis didn't warn because of #8103
294 2016-05-26 20:15:28	0|gmaxwell|LOL
295 2016-05-26 20:16:16	0|sipa|"oh, machine shutdown
296 2016-05-26 20:16:26	0|sipa|"oh, machine shutdown... ALL TESTS PASS"
297 2016-05-26 20:16:31	0|gmaxwell|Perhaps we need to make sure all commiters have access to super fast machines, and make running the full tests part of the merge script?
298 2016-05-26 20:16:39	0|gmaxwell|sipa: "No failures detected."
299 2016-05-26 20:16:53	0|cfields_|hmm, we've seen that before. thought it was fixed on their end.
300 2016-05-26 20:16:54	0|cfields_|checking
301 2016-05-26 20:17:04	0|sipa|fair enough, that's a subtle but relevant distinction
302 2016-05-26 20:17:51	0|cfields_|one thing we could do is add the rpc-tests to 'make check'
303 2016-05-26 20:18:35	0|cfields_|especially once the java blocktester is replaced in python, that'll make it so that travis would basically just be running 'make check', same as what everyone could do manually
304 2016-05-26 20:19:07	0|sipa|cfields_: ack
305 2016-05-26 20:19:25	0|cfields_|sdaftuar: how's that replacement coming, btw?
306 2016-05-26 20:19:31	0|sipa|together with parallel checking, it's even not that painful anymore