1 2016-09-15 00:58:04	0|achow101|I'm experimenting with the review thing. Can someone go to https://github.com/achow101/ProtectedBranchTest/pull/3 and submit an "Approve" review?
  2 2016-09-15 00:59:35	0|sdaftuar|achow101: done
  3 2016-09-15 01:00:08	0|achow101|thanks. something's not working...
  4 2016-09-15 01:00:13	0|sdaftuar|yeah i saw :)
  5 2016-09-15 01:01:03	0|sdaftuar|does it need to be approved by someone with write privs maybe?
  6 2016-09-15 01:01:44	0|achow101|I don't know. I can't approve it since I wrote it. I'll try with the other account.
  7 2016-09-15 01:03:22	0|achow101|oh yeah. That was totally it.
  8 2016-09-15 01:08:26	0|achow101|Interesting that the status checks are still pending.
  9 2016-09-15 01:40:04	0|rebroad|is the -dropmessagestest code still needed in main.cpp? It's not even mentioned as a command line option in init.cpp
 10 2016-09-15 01:41:50	0|rebroad|oh... sorry, it is
 11 2016-09-15 01:58:21	0|rebroad|ok, so I am wondering... develoeprs seem to complain when I either raise too many pull requests or raise a pull request with too many changes.. so it seems the complain is about the amount of development I am doing, so my thnking is that this is implying I should be working on other thnigs, code review perhaps? In what areas is it that the complaint might be indication that I am not contributing enough?
 12 2016-09-15 02:00:32	0|achow101|I've mostly figured out how the review thing works, and it could benefit us.
 13 2016-09-15 02:00:55	0|achow101|So comments through the review thing are just general comments on the whole thing, kind of useless. You can still do line notes though and that is good
 14 2016-09-15 02:01:42	0|achow101|approving cannot be done commit by commit but rather by the full diff at the time of review.
 15 2016-09-15 02:04:11	0|achow101|requesting changes seems like it will revoke a previous approval
 16 2016-09-15 02:04:58	0|dcousens|achow101: you can't edit comments interestingly when posting an 'approval'
 17 2016-09-15 02:05:19	0|achow101|And lastly branches can be setup with protections to require an approve from a committer, pass status checks (travis), and prevent administrators from merging regardless
 18 2016-09-15 02:05:57	0|achow101|also the submitter can't approve or request changes in his own PR (duh)
 19 2016-09-15 02:06:22	0|GitHub54|[13bitcoin] 15rebroad opened pull request #8734: Send NOTFOUND when we don't have the block data. (06master...06NotfoundIfPruned) 02https://github.com/bitcoin/bitcoin/pull/8734
 20 2016-09-15 02:07:33	0|achow101|dcousens: right. so any comments done with the review thing can't be edited
 21 2016-09-15 02:07:41	0|rebroad|achow101, all sounds good!
 22 2016-09-15 02:09:06	0|achow101|I think the best thing about this is that it can be set so that a PR submitted by a committer must have another committer review it before it can be merged
 23 2016-09-15 02:09:20	0|achow101|just in case someone gets hacked
 24 2016-09-15 02:11:27	0|dcousens|achow101: eh,  they already have multiple processes in place... trusting github further isn't really necessary
 25 2016-09-15 02:12:35	0|dcousens|achow101: RE privileges to approve, you don't need any see https://github.com/bitcoin/bitcoin/pull/8723#pullrequestreview-82853
 26 2016-09-15 02:13:32	0|dcousens|I honestly don't see this being any better than the current ACK' system
 27 2016-09-15 02:15:18	0|achow101|anyone can approve, but only certain people's approvals (the committers) will allow a PR to be merged when the branch is protected
 28 2016-09-15 02:16:25	0|achow101|If you look at the one I linked earlier, you can see the message there about an "approved review" which apparantly must come from someone with write access
 29 2016-09-15 06:22:57	0|jonasschnelli|I guess thats also a new Githup thing: you can later change the base branch of a pull request
 30 2016-09-15 06:48:17	0|cfields_|wumpus: wip mingw toolchain: https://github.com/theuni/bitcoin/commit/6cc40455c96f8820a35f745fb03466bcdc8d9919
 31 2016-09-15 06:49:55	0|cfields_|wumpus: lots of work remains. But, mingw depends build fully, and bitcoin build breaks with the same threading problems that have been reported, so it's enough to help with testing/debugging.
 32 2016-09-15 06:50:55	0|cfields_|will continue with it tomorrow.
 33 2016-09-15 06:51:03	0|jonasschnelli|nice cfields_ !
 34 2016-09-15 06:51:49	0|cfields_|jonasschnelli: heh, not really. It's at the "it's a bloodbath, but it builds" stage of development :)
 35 2016-09-15 09:11:25	0|GitHub156|[13bitcoin] 15jonasschnelli opened pull request #8735: [Wallet] add option for a custom extended master privat key (xpriv) (06master...062016/09/hd_set_seed) 02https://github.com/bitcoin/bitcoin/pull/8735
 36 2016-09-15 09:49:51	0|dcousens|wumpus: oh, I wanted to mention.  And all other things aside.  A small RPC cache works wonders for reducing some of the performance issues with high loads (10-20 mb)
 37 2016-09-15 10:10:19	0|GitHub24|[13bitcoin] 15wjx opened pull request #8736: base58: Improve DecodeBase58 performance. (06master...06speedup-decodebase58) 02https://github.com/bitcoin/bitcoin/pull/8736
 38 2016-09-15 10:42:50	0|GitHub86|[13bitcoin] 15paveljanik opened pull request #8737: Trivial: UndoReadFromDisk works on undo files (rev), not on block files. (06master...0620160915_Undo_error_message_fix) 02https://github.com/bitcoin/bitcoin/pull/8737
 39 2016-09-15 14:44:37	0|GitHub111|[13bitcoin] 15rebroad closed pull request #8729: More granular debug (06master...06MoreGranularDebug6) 02https://github.com/bitcoin/bitcoin/pull/8729
 40 2016-09-15 16:02:48	0|phantomcircuit|jonasschnelli: poke 8696 updated to address nits
 41 2016-09-15 16:40:15	0|GitHub112|[13bitcoin] 15sdaftuar opened pull request #8739: [qa] Fix broken sendcmpct test in p2p-compactblocks.py (06master...06fix-cb-test) 02https://github.com/bitcoin/bitcoin/pull/8739
 42 2016-09-15 18:52:30	0|paveljanik|wumpus, jonasschnelli: here is a rough QT -Wshadow commit (https://github.com/paveljanik/bitcoin/commit/f9d00d7e624a6760a099ca61caca25d7982844d1). I'd like to hear what you like or dislike about such changes or what to do in some other way.
 43 2016-09-15 18:54:00	0|paveljanik|E.g. using member initializers instead in some places etc.
 44 2016-09-15 18:54:07	0|jonasschnelli|phantomcircuit: newline nits: https://github.com/bitcoin/bitcoin/pull/8696/files#diff-b2bb174788c7409b671c46ccc86034bdR2518
 45 2016-09-15 18:54:37	0|jonasschnelli|phantomcircuit: I prefere modeIn instead of _mode
 46 2016-09-15 18:54:43	0|jonasschnelli|But consider it as nit
 47 2016-09-15 18:54:58	0|paveljanik|for ~qt we already agreed on _...
 48 2016-09-15 18:55:12	0|jonasschnelli|Okay. Fair enought.
 49 2016-09-15 18:55:15	0|jonasschnelli|_ look always after instance vars IMO
 50 2016-09-15 18:55:29	0|jonasschnelli|But maybe because of my Obj-C past
 51 2016-09-15 18:56:05	0|jonasschnelli|phantomcircuit: But the change-set looks good!
 52 2016-09-15 18:56:12	0|jonasschnelli|ah. meant paveljanik
 53 2016-09-15 18:56:31	0|paveljanik|it is a bit huge :-(
 54 2016-09-15 18:57:01	0|paveljanik|and there are still two other issues, but they are more serialization related than qt/
 55 2016-09-15 18:57:48	0|paveljanik|and I do not like how I solved this-> stuff because it can be a lot nicer.
 56 2016-09-15 18:58:05	0|jonasschnelli|Maybe split it into parts? But I don't care. I'm happy to merge it at once. Its fairly reviewable.
 57 2016-09-15 18:59:17	0|paveljanik|this itself is a part ;-)
 58 2016-09-15 18:59:52	0|cfields_|jonasschnelli: completely agree, but i didn't want to create noise :)
 59 2016-09-15 18:59:54	0|jonasschnelli|Ah. Okay then. :)
 60 2016-09-15 19:00:01	0|sipa|DING
 61 2016-09-15 19:00:08	0|jonasschnelli|meeting?
 62 2016-09-15 19:00:09	0|cfields_|(about _foo being member)
 63 2016-09-15 19:00:09	0|petertodd|pong
 64 2016-09-15 19:00:12	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
 65 2016-09-15 19:00:13	0|kanzure|greetz.
 66 2016-09-15 19:00:13	0|paveljanik|peng
 67 2016-09-15 19:00:25	0|sdaftuar|hi
 68 2016-09-15 19:00:39	0|jonasschnelli|cfields_, paveljanik: do we already make use of _var instead of varIn?
 69 2016-09-15 19:00:57	0|cfields_|jonasschnelli: yea, in the PRs that are already in
 70 2016-09-15 19:01:20	0|jonasschnelli|#startmeeting
 71 2016-09-15 19:01:20	0|lightningbot|Meeting started Thu Sep 15 19:01:19 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
 72 2016-09-15 19:01:20	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 73 2016-09-15 19:01:28	0|jonasschnelli|topic proposals?
 74 2016-09-15 19:01:47	0|MarcoFalke|proposed short topic: EOL 0.11
 75 2016-09-15 19:02:12	0|jonasschnelli|#topic EOL 0.11
 76 2016-09-15 19:02:18	0|cfields_|I'll only be around for ~30 min before I have to head out.
 77 2016-09-15 19:02:30	0|MarcoFalke|#link https://github.com/bitcoin-core/bitcoincore.org/pull/211
 78 2016-09-15 19:02:37	0|wumpus|if we're following the same schedule as usual, 0.11 was EOL at the moment 0.13 was released
 79 2016-09-15 19:02:48	0|sipa|except critical fixes?
 80 2016-09-15 19:02:51	0|jonasschnelli|agree with wumpus
 81 2016-09-15 19:03:02	0|MarcoFalke|it is about critical fixes
 82 2016-09-15 19:03:03	0|wumpus|security problems may be an exception
 83 2016-09-15 19:03:22	0|MarcoFalke|We should set a date when we no longer fix critial issues
 84 2016-09-15 19:03:30	0|gmaxwell|I thought 0.11 was EOL when 0.13 was released, except for whatever exceptions we decide...
 85 2016-09-15 19:03:33	0|jeremyrubin|nheren
 86 2016-09-15 19:03:34	0|wumpus|but usually no new executables will be built, just simple backports
 87 2016-09-15 19:03:36	0|sipa|gmaxwell: agree
 88 2016-09-15 19:03:53	0|petertodd|ack EOL; you can always run 0.11 behind a 0.13 node if you need too
 89 2016-09-15 19:04:00	0|sipa|so we need to get https://bitcoincore.org/en/lifecycle/ updated?
 90 2016-09-15 19:04:08	0|kanzure|i think the concern was that 0.11 was not marked as EOL, not that it wasn't considered EOL.
 91 2016-09-15 19:04:10	0|MarcoFalke|Jup, note that I already changed maintenance end to 2016-08-23
 92 2016-09-15 19:04:19	0|wumpus|yes the bitcoin.org page needs to be updated
 93 2016-09-15 19:04:31	0|wumpus|+Core
 94 2016-09-15 19:04:38	0|achow101|If 0.11 is EOL, then what about 0.10?
 95 2016-09-15 19:04:48	0|sipa|ah, so 0.11 is not EOL but maintenance end
 96 2016-09-15 19:05:00	0|sipa|EOL means not even security critical backports
 97 2016-09-15 19:05:05	0|sipa|according to that website
 98 2016-09-15 19:05:07	0|gmaxwell|achow101: it was unmaintained as of january or so.
 99 2016-09-15 19:05:28	0|achow101|gmaxwell: but it is still marked as receiving critical updates on bitcoincore.org
100 2016-09-15 19:05:33	0|jonasschnelli|According to bitcoincore.org 0.10 has EOL in 2017
101 2016-09-15 19:05:36	0|sipa|but 0.10 should be EOL at 2016-08-23
102 2016-09-15 19:05:40	0|morcos|it seems to me that ending security critical backports depends not just on how old the release is but on how many people are still using it
103 2016-09-15 19:05:50	0|gmaxwell|what morcos says.
104 2016-09-15 19:05:54	0|wumpus|and how difficult it is to backport/test
105 2016-09-15 19:06:00	0|morcos|ha ha, of course!
106 2016-09-15 19:06:08	0|wumpus|I mean if it's just updating a dependency library like upnp...
107 2016-09-15 19:06:18	0|gmaxwell|the reality is that it has nothing to do with dates. We're not actively seeking to maintain these versions but will do what it takes to protect the ecosystem.
108 2016-09-15 19:06:20	0|sipa|sure, but the reason for having a clearly stated policy is so that people can make informed decisions about what to run
109 2016-09-15 19:06:26	0|MarcoFalke|^
110 2016-09-15 19:06:47	0|wumpus|I think this will always be a discussion people can't really agree on
111 2016-09-15 19:06:48	0|MarcoFalke|We should communicate the EOL in advance
112 2016-09-15 19:06:52	0|luke-jr|frankly 0.12 seems like EOL before 0.14 at this rate
113 2016-09-15 19:06:56	0|petertodd|gmaxwell: setting expectations also can help protect the ecosystem
114 2016-09-15 19:07:07	0|gmaxwell|We also continue to see no feedback from parties that would prefer to use a 0.old.next over a 0.new.hottness. :)
115 2016-09-15 19:07:19	0|morcos|agreed with all, but i'm saying we should be supplementing our discussion with #'s of nodes running 0.10, 0.11
116 2016-09-15 19:07:23	0|sipa|i wish we had more insight in users' needs... that there would be requests of the form "wait! no! i can't upgrade to 0.12 yet for reason X, but we really need updated for now"
117 2016-09-15 19:07:25	0|wumpus|in practice it's indeed not about dates, but if someone cares about using/maintainging it
118 2016-09-15 19:07:27	0|BlueMatt|am I the only one who wasnt aware of that page? I mean I dont think a strict N-monghts schedule really works, so we'd need to all be thinking about it/aware of it, at least, to make it reasonable
119 2016-09-15 19:07:29	0|wumpus|it seems to be 0 people
120 2016-09-15 19:07:30	0|gmaxwell|Which supports the view that effort spent supporting older versions is of negative value.
121 2016-09-15 19:07:45	0|luke-jr|wumpus: maintaining it is not practical without testing/usage
122 2016-09-15 19:07:52	0|petertodd|morcos: so many nodes are run because users "want to contribute" - I wouldn't read too much into that number. Equally, a lot of nodes are likely spy-nodes...
123 2016-09-15 19:07:58	0|wumpus|luke-jr: right it's a chicken egg problem
124 2016-09-15 19:08:00	0|sipa|wumpus: that's a fair characterization of reality, but perhaps that page should reflect that
125 2016-09-15 19:08:02	0|kanzure|BlueMatt: i think it's something like "people should be following the mailing lists and announcement mailing lists and the webpage, although apparently the webpage is out of sync with reality for the moment"
126 2016-09-15 19:08:45	0|wumpus|yes, updating the webpage to reflect reality would make sense
127 2016-09-15 19:08:47	0|BlueMatt|kanzure: hmm? people shouldnt have to follow the ml to find out if their node is EOL...we should have some kind of information for users, but devs have to be aware that it exists for it to be accurate :p
128 2016-09-15 19:08:50	0|gmaxwell|If we were being completely pragmatic we would probably say that we only support the very latest thing put out at all.-- this is all that I can tell people are upgrading to. But I think that is a bad principle and the fact that the only thing people upgrade to is the latest thing is an aspect of industry immaturity which will hopefully go away.
129 2016-09-15 19:08:56	0|luke-jr|wumpus: I maintained old versions back to 0.4 for years with no indication of real usage or feedback - the first few got some testing, but after a while it never made it past RC
130 2016-09-15 19:09:43	0|luke-jr|IMO we *should* have longer support, but it just doesn't seem feasible with softforks
131 2016-09-15 19:09:43	0|petertodd|fwiw I've never gotten any feedback from python-bitcoinlib users complaining about non-backwards-compatible changes
132 2016-09-15 19:09:47	0|wumpus|the point of creating that webpage was to have an easier available place where release maintenance status was available, but yes if it runs out of date with reality then at some point it's only confusing
133 2016-09-15 19:10:06	0|petertodd|BlueMatt: too bad we got rid of the alert system... /ducks
134 2016-09-15 19:10:20	0|kanzure|wumpus: probably a good fix would be to have a checklist for releases, and add EOL webpage updates to that checklist.
135 2016-09-15 19:10:22	0|wumpus|and it should reflect how things are, not how we think ideally they should be
136 2016-09-15 19:10:28	0|sipa|we could make node software automatically show a warning X months after being released...
137 2016-09-15 19:10:37	0|luke-jr|kanzure: we do have release-process.md
138 2016-09-15 19:10:43	0|kanzure|well is it in there?
139 2016-09-15 19:10:50	0|luke-jr|sipa: +1
140 2016-09-15 19:10:54	0|wumpus|kanzure: there's one in the release process, but there is already so much stuff there. I don't thin kthe assumption should be that the same person does all that
141 2016-09-15 19:11:06	0|kanzure|"EOL" not found in that doc, nor variations of it.
142 2016-09-15 19:11:07	0|petertodd|sipa: signal does that actually - they forgot the timer expired once and scared a bunch of people
143 2016-09-15 19:11:27	0|kanzure|wumpus: sure, sure, perhaps it's multiple people. but a checklist can still be helpful regardless of number of people that use it.
144 2016-09-15 19:11:30	0|BlueMatt|petertodd: is that automated? heh, yea, maybe
145 2016-09-15 19:11:48	0|achow101|has anyone actually tried asking the community? like posting on reddit, bitcointalk, etc.
146 2016-09-15 19:12:08	0|luke-jr|petertodd: if we stagnate for 12 months, something else is wrong
147 2016-09-15 19:12:20	0|wumpus|I think we should first document how things are clearly on the site, and only then worry about maybe changing it
148 2016-09-15 19:12:26	0|btcdrak|oh sorry I am late
149 2016-09-15 19:12:31	0|jonasschnelli|The problem is probably not what the community want, its more what the team is capable of delivering
150 2016-09-15 19:12:36	0|gmaxwell|achow101: we've posted asking for feedback on older versions many times in the past, and also called for testing on old support backups.
151 2016-09-15 19:12:37	0|wumpus|exactly jonasschnelli
152 2016-09-15 19:12:58	0|jonasschnelli|Its an OSS, if people want longer EOL, they should contribute
153 2016-09-15 19:13:19	0|gmaxwell|I've also gone 1:1 to several companies. Mostly we've recieved complete silence. scanning the network (and watching inbounds) also shows that adoption of point releases after a new major is out is basically non-existant.
154 2016-09-15 19:13:20	0|wumpus|as I've said before I have nothing against maintaining old releases if someone really commits to that
155 2016-09-15 19:13:24	0|sipa|that's fair... we're only so many people, and review for backports is a significant burden
156 2016-09-15 19:13:25	0|luke-jr|I'm happy to go back to maintaining stable versions longer if people will actually use it (and can't upgrade)
157 2016-09-15 19:13:31	0|gmaxwell|jonasschnelli: or at least speak up.
158 2016-09-15 19:13:32	0|wumpus|but I've never seen much interest, so reality is, it doesn't
159 2016-09-15 19:13:38	0|kanzure|i don't know what to think about re: automatic warnings after timelapse.   as long a there's some good reason to think it' dissimilar from automatic updates, i suppose..
160 2016-09-15 19:13:55	0|jonasschnelli|gmaxwell: right.
161 2016-09-15 19:13:55	0|wumpus|kanzure: I don't know what to think about it either
162 2016-09-15 19:13:58	0|kanzure|didn't mean to impose on wumpus with the checklist suggestion
163 2016-09-15 19:14:09	0|luke-jr|maybe update EOL page, and mention the lack of usage as the reason, suggesting if people want it, they should get in touch
164 2016-09-15 19:14:17	0|jonasschnelli|Luke-Jr: +1
165 2016-09-15 19:14:21	0|BlueMatt|ok, so lets post something on the ml or so that says "We're gonna stop doing this, but would very much love to hear if anyone actually wants it" and then link to that from reddit/emails/twitter/whatever
166 2016-09-15 19:14:28	0|BlueMatt|yea, that
167 2016-09-15 19:14:30	0|gmaxwell|stop doing what?
168 2016-09-15 19:14:32	0|gmaxwell|I am really confused.
169 2016-09-15 19:14:37	0|BlueMatt|stop supporting backports
170 2016-09-15 19:14:43	0|BlueMatt|beyond like one or two versions, maybe
171 2016-09-15 19:14:46	0|gmaxwell|We have a stated policy, we maintain one major version behind.
172 2016-09-15 19:14:46	0|wumpus|kanzure: I really don't like time-locks in programs. Though this would just be a warning I guess... but it could be intimidating
173 2016-09-15 19:14:47	0|luke-jr|gmaxwell: stop promising backports we aren't really doing anyway
174 2016-09-15 19:14:56	0|gmaxwell|BlueMatt: we already did that, like, a yea ago.
175 2016-09-15 19:14:58	0|jonasschnelli|stop doing sound negative... something more like "...we are concentrating ressources on X"
176 2016-09-15 19:15:01	0|gmaxwell|year*
177 2016-09-15 19:15:07	0|sipa|BlueMatt: "beyond one version" is exactly what the page says
178 2016-09-15 19:15:08	0|BlueMatt|s/one or two versions/one or so point releases/
179 2016-09-15 19:15:15	0|luke-jr|wumpus: might be good to make the time limit fuzzy, so not everyone gets hit at the same time
180 2016-09-15 19:15:17	0|btcdrak|Seems there's a lot of discussion here which was _already)_ covered in previous meetings and is detailed in the Lifecycle document https://bitcoincore.org/en/lifecycle/ tldr maintenance and EOL are two different things.
181 2016-09-15 19:15:23	0|luke-jr|perhaps 1 year from when it was installed?
182 2016-09-15 19:15:25	0|gmaxwell|what btcdrak says
183 2016-09-15 19:15:29	0|BlueMatt|sipa: gmaxwell to be fair, the website doesnt say that
184 2016-09-15 19:15:36	0|wumpus|well then add it to the website!
185 2016-09-15 19:15:42	0|wumpus|everyone can submit pulls there you know
186 2016-09-15 19:15:46	0|btcdrak|I suggest people re-read the Lifecycle page after the meeting :)
187 2016-09-15 19:15:57	0|wumpus|we can spend an hour discussing what should be added to the website, or just add it
188 2016-09-15 19:16:03	0|jonasschnelli|#action update Lifecycle page on bitcoincore.org
189 2016-09-15 19:16:04	0|Chris_Stewart_5|^
190 2016-09-15 19:16:08	0|kanzure|luke-jr: cool idea. fuzzy random noise time-delay notifications.  (hopefully nobody proposes "intentionally low performance over time until someone thinks to get a new version")
191 2016-09-15 19:16:11	0|BlueMatt|ok, next topic
192 2016-09-15 19:16:30	0|gmaxwell|BlueMatt: read the "Maintance period" section on the site, I think it's completely clear.
193 2016-09-15 19:16:32	0|wumpus|any other topics?
194 2016-09-15 19:16:49	0|jonasschnelli|#into hackdays in milan: http://coredev.tech/nextmeeting_tmp.html
195 2016-09-15 19:16:56	0|wumpus|0.14 release schedule maybe
196 2016-09-15 19:17:00	0|jonasschnelli|Its a temporary page.. not public yet. But feel free to register
197 2016-09-15 19:17:19	0|wumpus|I've posted a proposal for the 0.14 release schedule here: https://github.com/bitcoin/bitcoin/issues/8719
198 2016-09-15 19:17:30	0|jonasschnelli|#topic 0.14 release schedule
199 2016-09-15 19:17:34	0|MarcoFalke|sounds fine
200 2016-09-15 19:17:45	0|sipa|yes, sounds good
201 2016-09-15 19:17:49	0|jonasschnelli|yes. fine for me
202 2016-09-15 19:18:01	0|btcdrak|looks good to me
203 2016-09-15 19:18:06	0|BlueMatt|yea, looks good now
204 2016-09-15 19:18:06	0|wumpus|I'll mail it around on the mailing lists if there are no issues with it
205 2016-09-15 19:18:09	0|CodeShark|+1
206 2016-09-15 19:18:12	0|wumpus|ok great!
207 2016-09-15 19:18:16	0|kanzure|jonasschnelli: you have a typo in your form ("your are")
208 2016-09-15 19:18:34	0|jonasschnelli|kanzure: ill give you edit right. :)
209 2016-09-15 19:18:34	0|morcos|wumpus: my only thought is 0.13.1 release is a bit of a heavy lift, and depending on when that happens, it may seem like 0.14.0 is coming up quite quickly...  but i don't feel strongly about it
210 2016-09-15 19:18:56	0|wumpus|morcos: it's already a month later compared to 0.12 was this year
211 2016-09-15 19:19:13	0|MarcoFalke|No worries. I am sure the will be last-minute blockers for 0.14.0
212 2016-09-15 19:19:14	0|wumpus|morcos: postponsing major releases for minor releases makes very little sense I think
213 2016-09-15 19:19:52	0|morcos|wumpus: yeah i was only pointing out that 0.13.1 is not minor in a lot of ways..  but if others are fine with it, i don't object
214 2016-09-15 19:19:52	0|wumpus|0.14 will have lots of new features, 0.13.1 will not
215 2016-09-15 19:20:09	0|wumpus|morcos: I agree with that
216 2016-09-15 19:20:27	0|luke-jr|? 0.13.1 should only be fixes + softfork
217 2016-09-15 19:20:33	0|btcdrak|yes.
218 2016-09-15 19:20:33	0|wumpus|luke-jr: it is
219 2016-09-15 19:20:39	0|morcos|anyway, seems not its a widely shared concern, so lets stick with the schedule
220 2016-09-15 19:20:45	0|gmaxwell|having a short gap between releases would be a good problem to have. :)
221 2016-09-15 19:20:54	0|BlueMatt|yup
222 2016-09-15 19:20:55	0|jonasschnelli|#topic 0.13.1 release
223 2016-09-15 19:21:00	0|wumpus|it's a minor release strictly, just a lot of code changes, so you can jokingly call it 'major'
224 2016-09-15 19:21:15	0|btcdrak|Here are the remaining PRs and issues for 0.13.1 https://github.com/bitcoin/bitcoin/milestone/22
225 2016-09-15 19:21:22	0|btcdrak|#link https://github.com/bitcoin/bitcoin/milestone/22
226 2016-09-15 19:21:43	0|sdaftuar|i wanted to suggest that we consider dropping some of those PRs from the 0.13.1 milestone
227 2016-09-15 19:21:55	0|btcdrak|sdaftuar which in particular?
228 2016-09-15 19:21:55	0|wumpus|sdaftuar: specific suggestions?
229 2016-09-15 19:22:16	0|BlueMatt|nulldummy as softfork?
230 2016-09-15 19:22:17	0|sdaftuar|8654 is one
231 2016-09-15 19:22:20	0|kanzure|was there a mempool issue still open for 0.13.1.. don't see it listed there.
232 2016-09-15 19:22:25	0|BlueMatt|I figure I'd get yelled at, but I'm not convinced
233 2016-09-15 19:22:25	0|CodeShark|Is the mempool dos thing still urgent?
234 2016-09-15 19:22:27	0|kanzure|ah there it is.
235 2016-09-15 19:22:28	0|sdaftuar|that's a performance optimization that i think is not urgent
236 2016-09-15 19:22:35	0|kanzure|(8279)
237 2016-09-15 19:22:39	0|btcdrak|I recall sipa saying #8635 may not be essential for 0.13.1
238 2016-09-15 19:22:46	0|luke-jr|I reviewed a few merged fixes and commented on a few that they should be backported. Did someone with tagging access get to tag those?
239 2016-09-15 19:23:13	0|jonasschnelli|Luke-Jr: I'll have a look
240 2016-09-15 19:23:16	0|MarcoFalke|luke-jr: I think I did
241 2016-09-15 19:23:22	0|jl2012|i think #8635 may be dropped for 0.13.1
242 2016-09-15 19:23:37	0|sipa|agree
243 2016-09-15 19:23:45	0|jonasschnelli|jl2012: what do you think about https://github.com/bitcoin/bitcoin/pull/8654?
244 2016-09-15 19:23:46	0|btcdrak|ok let's untag it
245 2016-09-15 19:23:57	0|btcdrak|*untag 8635
246 2016-09-15 19:23:57	0|sipa|i'd like to see 8654 in
247 2016-09-15 19:24:09	0|luke-jr|ACK dropping 8635 for 0.13.1
248 2016-09-15 19:24:21	0|btcdrak|I guess the big blocker is #8393 compact blocks.
249 2016-09-15 19:24:21	0|jonasschnelli|untagged
250 2016-09-15 19:24:45	0|wumpus|#decision dropped #8635 for 0.13.1
251 2016-09-15 19:24:51	0|luke-jr|jonasschnelli: if that's strictly an optimisation, it should wait for 0.14
252 2016-09-15 19:25:12	0|jonasschnelli|sipa: why did you want to see 8654 in 0.13.1?
253 2016-09-15 19:25:15	0|wumpus|luke-jr: depends on whether it's an optimisation or an 'optimisation' (e.g. - DoS fix)
254 2016-09-15 19:25:22	0|gmaxwell|btcdrak: thats ... working fine for me, but we probably need to do a bit more organized testing. sdaftuar was updating some tests for it.
255 2016-09-15 19:25:27	0|luke-jr|wumpus: right, hence "if" ☺
256 2016-09-15 19:25:49	0|btcdrak|gmaxwell: well it's fine to merge afaik, but there was some discussion about the BIP text which is blocking it afaik
257 2016-09-15 19:26:06	0|btcdrak|I think #8636 is ok to merge.
258 2016-09-15 19:26:37	0|wumpus|that has a lot of ACKs
259 2016-09-15 19:26:41	0|michagogo|Hi
260 2016-09-15 19:26:48	0|wumpus|#action merge #8636
261 2016-09-15 19:26:53	0|wumpus|michagogo: hey!
262 2016-09-15 19:27:00	0|gmaxwell|Can someone make a list of all PR's merged for master that are not in 0.13 so we can check to make sure we haven't missed any that need backport?
263 2016-09-15 19:27:11	0|morcos|oh i was going to vote against 8636 as well
264 2016-09-15 19:27:26	0|morcos|i haven't reviewed it and don't necessarily have any concrete concerns
265 2016-09-15 19:27:29	0|wumpus|gmaxwell: all that still need backport should have the 'needs backport' tag
266 2016-09-15 19:27:35	0|wumpus|https://github.com/bitcoin/bitcoin/labels/Needs%20backport
267 2016-09-15 19:27:43	0|BlueMatt|its just more stuff for segwit that could easily fit in another softfork
268 2016-09-15 19:27:47	0|michagogo|Sorry, not too around -- was with my grandmother (my grandfather passed away on Sunday), and now shopping with the family.
269 2016-09-15 19:27:49	0|gmaxwell|assuming they got tagged.
270 2016-09-15 19:27:53	0|BlueMatt|better to push any more complication further
271 2016-09-15 19:27:55	0|luke-jr|gmaxwell: I did, but I may have missed some. (minor ones I didn't comment on, and have a local list I can backport myself)
272 2016-09-15 19:27:56	0|morcos|but just seems it possibly hasn't been thought about enough to know there isn't a hidden risk like jl2012 found low-s
273 2016-09-15 19:27:56	0|wumpus|(including what is already merged)
274 2016-09-15 19:28:08	0|gmaxwell|it's an istandardness rule
275 2016-09-15 19:28:21	0|btcdrak|morcos: it's already a standard rule
276 2016-09-15 19:28:22	0|gmaxwell|oh you're talkign about nulldummy sorry.
277 2016-09-15 19:28:47	0|BlueMatt|gmaxwell: yea, sorry, nulldummy...I'm more ok with adding standard rules for things we want to softfork out soon
278 2016-09-15 19:28:53	0|wumpus|michagogo:  hah, luckily the C parser doesn't accept it as number
279 2016-09-15 19:29:21	0|wumpus|otherwise some magic constants should be defined as zuzuzuzu, especially on windows
280 2016-09-15 19:29:56	0|jl2012|#8499 actually somehow depends on nulldummy softfork
281 2016-09-15 19:29:59	0|luke-jr|#define zu 11
282 2016-09-15 19:30:09	0|luke-jr|fixed C parser
283 2016-09-15 19:30:21	0|jl2012|it still works, just can't protect CHECKMULTISIG
284 2016-09-15 19:30:21	0|morcos|re: nulldummy, ok so if we think its got sufficient technical review, and we also think its technical enough it doesn't need more community discussion (for instance never appears in chain?) then ok wiht me
285 2016-09-15 19:30:41	0|sipa|i think the risk for nulldummy is very low
286 2016-09-15 19:30:46	0|petertodd|nulldummy is very, very simple
287 2016-09-15 19:30:51	0|jl2012|since without a softfork, we can't DoS ban a peer sending us a violating transaction
288 2016-09-15 19:31:16	0|sipa|jl2012: well we can't generally do that anyway
289 2016-09-15 19:31:32	0|sipa|an attacker node can always pretend to be an old version
290 2016-09-15 19:31:38	0|jl2012|for segwit tx we could
291 2016-09-15 19:31:39	0|cfields_|crap, gtg. wumpus: not a meeting topic, but I noticed that the libevent unit tests fail for the zu case. We should consider running unit tests for deps somewhere.
292 2016-09-15 19:31:39	0|gmaxwell|we could for Sw things however, as it doesn't have transisiton issue.
293 2016-09-15 19:31:44	0|cfields_|bbl
294 2016-09-15 19:31:45	0|jl2012|8499 is for segwit only
295 2016-09-15 19:31:48	0|luke-jr|sipa: if it's bundled with segwit I think we can?
296 2016-09-15 19:31:56	0|gmaxwell|But we could ban without the softfork in such a case too.
297 2016-09-15 19:32:02	0|sipa|luke-jr: an old node can always pretend to be pre-segwit
298 2016-09-15 19:32:12	0|gmaxwell|There is no need to link those behaviors though we have previously.
299 2016-09-15 19:32:13	0|wumpus|cfields_: yes did you see https://github.com/bitcoin/bitcoin/pull/8730?
300 2016-09-15 19:32:22	0|luke-jr|but then it won't have witness data at all
301 2016-09-15 19:32:40	0|wumpus|cfields_: running libevent tests would make some sense, yes, although we'd first need a travis run on ubuntu 16.04
302 2016-09-15 19:32:46	0|sipa|luke-jr: so? it's an attacker node. it just won't send segwit txn
303 2016-09-15 19:32:55	0|cfields_|wumpus: yes, I'm still making my way through that problem.
304 2016-09-15 19:32:56	0|sipa|it can make up all its transactions
305 2016-09-15 19:33:00	0|gmaxwell|in any case, I only think that its urgent to at least have these behaviors non-standard.
306 2016-09-15 19:33:02	0|cfields_|wumpus: indeed, it was just a general thought
307 2016-09-15 19:33:21	0|luke-jr|sipa: afaik the proposal is to ban Nulldummy-violating sw txns
308 2016-09-15 19:33:38	0|sipa|luke-jr: to ban nulldummy-violation sw *peers*
309 2016-09-15 19:33:50	0|sipa|so an attacker will just not be an sw peer
310 2016-09-15 19:33:54	0|wumpus|cfields_: at least that one's easy to fix, the -stack-protector-all problem is more worrying
311 2016-09-15 19:34:21	0|wumpus|cfields_: anyhw better to speak of this outside the meeting some time
312 2016-09-15 19:34:25	0|jl2012|sipa: I think it's to ban segwit-nulldummy-violation peers
313 2016-09-15 19:34:38	0|sipa|jl2012: ok
314 2016-09-15 19:34:40	0|morcos|too many conversations
315 2016-09-15 19:34:41	0|sipa|same thing
316 2016-09-15 19:34:43	0|sipa|morcos: agree
317 2016-09-15 19:34:47	0|luke-jr|well, whether it's useful or not is another matter - maybe it isn't
318 2016-09-15 19:34:49	0|sipa|what is the topic?
319 2016-09-15 19:34:56	0|jonasschnelli|0.13.1
320 2016-09-15 19:34:58	0|morcos|in summary i'm happy to let you guys decide what should go into 0.13.1 and what shouldn't, as i have been a bit out of the loop
321 2016-09-15 19:35:00	0|jonasschnelli|(nulldummy)
322 2016-09-15 19:35:03	0|wumpus|0.13.1 still
323 2016-09-15 19:35:13	0|morcos|however i just want to raise the concern that maybe we're putting a lot of things in very quickly at the end
324 2016-09-15 19:35:18	0|gmaxwell|welcome back
325 2016-09-15 19:35:19	0|morcos|and that should cause us to be nervous
326 2016-09-15 19:35:22	0|sipa|i think nulldummy is very low risk, but also not very useful
327 2016-09-15 19:35:23	0|gmaxwell|:)
328 2016-09-15 19:35:40	0|morcos|when already the segwit activation is going to be a lot to pay attention to
329 2016-09-15 19:35:42	0|BlueMatt|0.13.1 - various things...I think morcos, sdaftuar and I generally arent a fan of all these policy and various things coming in last minute before 0.13.1, but, I think we've all been out of the loop so maybe they have more review than we think
330 2016-09-15 19:35:45	0|sipa|it should happen at some point, and perhaps doing it together with segwit is easier
331 2016-09-15 19:35:52	0|btcdrak|morcos: in all fairness, these PRs have been worked on over quite a long time.. they arent out of the blue.
332 2016-09-15 19:36:02	0|BlueMatt|maybe nulldummy is ok, but still, so many things happening at the same time is a review burden and complicates things further
333 2016-09-15 19:36:03	0|btcdrak|you need to sync up on the conversations / background of them
334 2016-09-15 19:36:03	0|sipa|BlueMatt: yes, i don't like that either, but i think we just discovered many things to improve
335 2016-09-15 19:36:06	0|BlueMatt|when segwit is already complicated
336 2016-09-15 19:36:13	0|BlueMatt|sipa: ok, lets do it in a later sf
337 2016-09-15 19:36:14	0|BlueMatt|?
338 2016-09-15 19:36:26	0|BlueMatt|i mean sf-able things, that is
339 2016-09-15 19:36:38	0|gmaxwell|it's unclear whats being discussed now.
340 2016-09-15 19:36:40	0|BlueMatt|and maybe if policy isnt as restrictive as we'd like in 0.13.1, thats ok
341 2016-09-15 19:36:42	0|sipa|nulldummy sf
342 2016-09-15 19:37:29	0|btcdrak|the only sf is nulldummy, the rest is just policy standardness.
343 2016-09-15 19:37:37	0|jonasschnelli|Didn't we had this discussion already and where mostly for including nulldummy sf together with SW in 0.13.1?
344 2016-09-15 19:37:41	0|gmaxwell|bluematt is talking about many, if the discussion is limited to nulldummy whatever.
345 2016-09-15 19:38:02	0|gmaxwell|But the policy changes are more important.
346 2016-09-15 19:38:03	0|wumpus|yes I think trying to stash a lot of changes into 0.13.1 has caused some delays already, at the least we shouldn't be adding anything else now and focus on what is there getting in
347 2016-09-15 19:38:10	0|gmaxwell|jonasschnelli: yes, we did.
348 2016-09-15 19:38:31	0|luke-jr|IMO nulldummy isn't worth all the time we're spending disucssing it now.
349 2016-09-15 19:38:41	0|jonasschnelli|https://bitcoincore.org/en/meetings/2016/09/01/#nulldummy-and-lows-softfork-proposals
350 2016-09-15 19:38:47	0|Chris_Stewart_5|Do we have a tentative release date for 0.13.1 or feature freeze?
351 2016-09-15 19:38:53	0|gmaxwell|wumpus: that isn't what happened. We had specific necessary to fix issues related to SW specific moderate risk denial of service attacks, and the path to fixing them spun off a number of sub isues along the way.
352 2016-09-15 19:38:55	0|wumpus|if you discover any other nice improvements they can wait until next version, unless it's critical to deployment of segwit
353 2016-09-15 19:38:58	0|jonasschnelli|cfields_: no
354 2016-09-15 19:39:01	0|jonasschnelli|Chris_Stewart_5: no
355 2016-09-15 19:39:15	0|gmaxwell|It's a little frustrating to loop rediscussing the same things over again. Makes the meetings feel like a waste of time, FWIW.
356 2016-09-15 19:39:21	0|wumpus|gmaxwell: agreed
357 2016-09-15 19:39:31	0|jonasschnelli|agree with gmaxwell
358 2016-09-15 19:39:31	0|wumpus|there are a lot of repeated topics lately
359 2016-09-15 19:39:51	0|jonasschnelli|(which is mostly a sign of not made decistions)
360 2016-09-15 19:39:51	0|wumpus|e.g. people that have been out of the loop then bring up something that was discussed a meeting or a few meetings ago
361 2016-09-15 19:39:56	0|wumpus|meetings are not there to bring you up to speed
362 2016-09-15 19:40:18	0|btcdrak|we publish meeting summaries, people should be reading them :-p
363 2016-09-15 19:40:26	0|wumpus|the logs and minutes are available, and summaries are made and published on the site
364 2016-09-15 19:40:41	0|gmaxwell|okay, thats enough probably. :) people get the point.
365 2016-09-15 19:40:44	0|wumpus|and you can always ask about things outside the meeting
366 2016-09-15 19:40:57	0|gmaxwell|(I am glad to not be alone!)
367 2016-09-15 19:40:59	0|BlueMatt|wumpus: IIRC there are folks complaining now who were in favor of it, as there are now 5 related issues that are coming up.....8634, eg, was not previously discussed and is in the same veign
368 2016-09-15 19:41:04	0|BlueMatt|maybe that should be the next topic
369 2016-09-15 19:41:41	0|BlueMatt|otherwise, someone can propose a different topic :)
370 2016-09-15 19:41:47	0|wumpus|BlueMatt: yes, I'm not saying it should be impossible to reconsider things discussed in previous meetings if convinng new reasons come up! just that repeating the same discussions with the same outcomes is not constructive
371 2016-09-15 19:41:50	0|gmaxwell|BlueMatt: thats fine, things can be rediscussed again, but instead of repeating the discussion we should focus on whats changed or whats disagreed with.. a diff rather than a redo.
372 2016-09-15 19:41:58	0|btcdrak|We need some more ACKs on #8634 and #8499 and #8526
373 2016-09-15 19:42:04	0|wumpus|yes
374 2016-09-15 19:42:13	0|wumpus|#action review #8634 and #8499 and #8526
375 2016-09-15 19:42:42	0|sipa|it's not clear what is being discussed. if we're talking about nulldummy sf, i think there is little risk, but little benefit. it was discussed before however, and unless people strongly feel that everything being done is too much, then this is something that can be reconsidered. please don't start reconsidering everything. there are good reasons and they were discussed before
376 2016-09-15 19:42:43	0|btcdrak|then the compact block/BIP thing needs to be finalised so we can merge the compact block pull #8393
377 2016-09-15 19:43:05	0|BlueMatt|sipa: eg, btcdrak just pointed out three prs...two of which i think are optional in 0.13.1
378 2016-09-15 19:43:07	0|BlueMatt|as is nulldummy
379 2016-09-15 19:43:24	0|BlueMatt|now we're in a position where we have a at least 3 prs that are "optional", at least one or two has been previously agreed upon
380 2016-09-15 19:43:34	0|btcdrak|sipa: it's been well reviewed, and run on testnet for 4 weeks already.
381 2016-09-15 19:43:34	0|wumpus|nulldummy softwork has been discussed zillions of times in the meeting, everytime the sentiment was slightly in favor of doing it because it has very little risk
382 2016-09-15 19:43:42	0|BlueMatt|but we want to get this thing out the door without spreading ourselves thin over too much review
383 2016-09-15 19:43:50	0|wumpus|and by now it has lots of testing and review too
384 2016-09-15 19:43:51	0|btcdrak|can we move on?
385 2016-09-15 19:43:51	0|sipa|so let's just stick to it
386 2016-09-15 19:43:58	0|wumpus|so if you want to reconsider it have a very good reason
387 2016-09-15 19:44:04	0|wumpus|not just 'I personally don't like it very much'
388 2016-09-15 19:44:08	0|BlueMatt|btcdrak: "run on testnet for 4 weeks" is the opposite of "good testing"
389 2016-09-15 19:44:08	0|gmaxwell|fwiw, all of my testing lately has been with most of this stack applied.
390 2016-09-15 19:44:27	0|btcdrak|BlueMatt: it's completely trivial, come on.
391 2016-09-15 19:44:47	0|wumpus|topc nulldummy is over now
392 2016-09-15 19:44:51	0|btcdrak|Is there any thing I can do regarding CB, I'm sort of confused about what is holding it up?
393 2016-09-15 19:44:55	0|wumpus|other topic proposals?
394 2016-09-15 19:45:00	0|sipa|segwit cb?
395 2016-09-15 19:45:05	0|btcdrak|yes please
396 2016-09-15 19:45:14	0|wumpus|#topic segwit cb
397 2016-09-15 19:45:18	0|gmaxwell|yes, I'm also unsure what else is required. I have been testing.
398 2016-09-15 19:45:25	0|sipa|gmaxwell: the latest version?
399 2016-09-15 19:45:30	0|sdaftuar|i'm working on testing.  i foudn a bunch of problems with the test unfortunately :(
400 2016-09-15 19:45:31	0|sipa|(as of a few days ago)
401 2016-09-15 19:45:47	0|BlueMatt|it was updated a few days ago, afaik only sdaftuar has looked at it since
402 2016-09-15 19:45:54	0|sipa|i did
403 2016-09-15 19:45:58	0|morcos|i like the concept of the latest version, and looked at the code.  but unfortunately i have to review CB in the first place before i can review the pull, so thats what i'm doing
404 2016-09-15 19:46:04	0|BlueMatt|and sdaftuar is now rewriting the testers for it, so not much to talk about aside from people should look at it?
405 2016-09-15 19:46:09	0|gmaxwell|sipa: as of a week ago? I could check.
406 2016-09-15 19:46:35	0|morcos|not to say you need to wait for my review of course
407 2016-09-15 19:46:35	0|sipa|gmaxwell: 2 days ago
408 2016-09-15 19:47:56	0|BlueMatt|next topic?
409 2016-09-15 19:48:13	0|gmaxwell|(Fwiw, more segwit traffic on testnet would make live testing of that PR more useful)
410 2016-09-15 19:48:27	0|luke-jr|gmaxwell: where did you guys go btw?
411 2016-09-15 19:48:35	0|gmaxwell|luke-jr: to the photo room.
412 2016-09-15 19:48:37	0|btcdrak|gmaxwell: roasbeef is preparing to produce some load in the next day
413 2016-09-15 19:48:57	0|gmaxwell|btcdrak: okay, I'll try to get things updated to the latest first.
414 2016-09-15 19:49:59	0|jonasschnelli|any other topics?
415 2016-09-15 19:50:10	0|sipa|specifically it would be useful to test connections between 0.13-with-segwit-activation-removed testnet nodes with #8393
416 2016-09-15 19:50:24	0|sdaftuar|sipa: i'm also working on doing that in regtest, fyi
417 2016-09-15 19:50:32	0|sipa|awesome
418 2016-09-15 19:50:34	0|btcdrak|great
419 2016-09-15 19:50:40	0|gmaxwell|sipa: okay, I'll make sure that I run with that too.
420 2016-09-15 19:50:52	0|sipa|thanks
421 2016-09-15 19:51:37	0|luke-jr|would be handy to have some regular segwit spam on testnet in general IMO
422 2016-09-15 19:51:56	0|btcdrak|luke-jr: it's coming, roasbeef is setting something up
423 2016-09-15 19:53:02	0|btcdrak|*silence*
424 2016-09-15 19:53:42	0|jonasschnelli|#endmeeting
425 2016-09-15 19:53:42	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.log.html
426 2016-09-15 19:53:42	0|lightningbot|Meeting ended Thu Sep 15 19:53:41 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
427 2016-09-15 19:53:42	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.html
428 2016-09-15 19:53:42	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.txt
429 2016-09-15 19:56:03	0|btcdrak|I think I entered the twilight zone
430 2016-09-15 19:56:12	0|btcdrak|XD
431 2016-09-15 19:56:49	0|jonasschnelli|Well,... everyone went reviewing the 0.13.1 PRs
432 2016-09-15 19:57:20	0|petertodd|jonasschnelli: and I released OpenTimestamps earlier today, and have been up all night :) https://petertodd.org/2016/opentimestamps-announcement
433 2016-09-15 19:57:31	0|jonasschnelli|Saw that! Nice job btw!
434 2016-09-15 19:57:39	0|petertodd|thanks!
435 2016-09-15 19:58:02	0|petertodd|jonasschnelli: gonna (hopefully!) have a blog post tomorrow morning about the git commit timestamping it does as well
436 2016-09-15 19:58:40	0|petertodd|sipa: "hands.... hands everywhere...."
437 2016-09-15 19:58:51	0|jonasschnelli|petertodd: Yes. I think a "non-technical" description of the possibilities would be nice
438 2016-09-15 19:59:30	0|petertodd|jonasschnelli: I've actually written up (most) of that post already: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md
439 2016-09-15 20:00:00	0|petertodd|jonasschnelli: a step-by-step example of a case where you could use it (e.g. sipa's key compromise) would be good though
440 2016-09-15 20:01:12	0|jonasschnelli|petertodd: your git sig time-stamping is very clever...
441 2016-09-15 20:02:34	0|petertodd|jonasschnelli: yeah, that's a fun hack! I noticed it was possible awhile back, and made a demo of a PGP-signed git commit with signatures from Isis Lovecruft and myself on one commit :)
442 2016-09-15 20:02:48	0|petertodd|jonasschnelli: unfortunately, github shows those sigs as "unverified", but that's a minor problem
443 2016-09-15 20:03:12	0|jonasschnelli|Yes. The github-verified icon is nice. But does not prove anything. :)
444 2016-09-15 20:03:28	0|roasbeef|re testnet segwit spam: would help if we could get more segwit enabled hashpower on testnet and to get those currently mining to limit by max weight (4mil) instead of stripped size
445 2016-09-15 20:03:45	0|petertodd|jonasschnelli: well, if you trust github...
446 2016-09-15 20:03:48	0|roasbeef|err I mean regular size
447 2016-09-15 20:04:44	0|sipa|jonasschnelli: sure it does. as long as you trust github and the companies hosting their hardware.
448 2016-09-15 20:04:47	0|sipa|if.
449 2016-09-15 20:04:52	0|jonasschnelli|kanzure: I gave you edit right on https://docs.google.com/forms/d/1HbJecbEN62r8sL2H0nBjlznmJEa1VDCR_FWC76-qEvo/edit
450 2016-09-15 20:04:57	0|jonasschnelli|Thanks for fixing the typos. :)
451 2016-09-15 20:05:03	0|kanzure|oh.
452 2016-09-15 20:05:43	0|jonasschnelli|sipa: Yes. And probably trust all your browser plugins. :)
453 2016-09-15 20:06:13	0|jonasschnelli|I guess github.com does not include any third-party CDN-ish CSS/JS files..
454 2016-09-15 20:06:15	0|sipa|yes, and you c library, X server, kernel, cpu, motherboard manufacturer, delivery company, ...
455 2016-09-15 20:06:23	0|jonasschnelli|okay. stop. :)
456 2016-09-15 20:07:32	0|btcdrak|roasbeef: will pass it on
457 2016-09-15 20:07:38	0|sipa|(but admittedly, the browser is the easiest target of all of those)
458 2016-09-15 20:07:48	0|luke-jr|sipa: ping
459 2016-09-15 20:08:06	0|sipa|luke-jr: pung
460 2016-09-15 20:50:40	0|phantomcircuit|jonasschnelli: just the newline?
461 2016-09-15 21:44:13	0|GitHub48|[13bitcoin] 15laanwj opened pull request #8740: net: No longer send local address in addrMe (06master...062016_09_addrfrom_version) 02https://github.com/bitcoin/bitcoin/pull/8740
462 2016-09-15 22:00:55	0|gmaxwell|would it be unreasonable for us to keep a bitcoin-core keyring file that has the pgp keys of all the regulars around here in it?
463 2016-09-15 22:20:05	0|BlueMatt|argh ffs...can we all agree to not use github's fancy new review mode thing? it seems to be breaking github's emails as they are no longer threaded together for a single issue...hopefully they can fix in a day or two but they really broke my bitcoin-email workflow :(
464 2016-09-15 22:20:25	0|BlueMatt|damn github and their not always working perfectly :(
465 2016-09-15 22:20:42	0|BlueMatt|gmaxwell: https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys
466 2016-09-15 22:20:45	0|BlueMatt|we already have that :)
467 2016-09-15 22:21:14	0|gmaxwell|thats gitian, and doesn't include things like morcos' key.
468 2016-09-15 22:21:38	0|midnightmagic|mine's not in there either.
469 2016-09-15 22:21:39	0|BlueMatt|it doesnt include morcos' key because he had +/- never used it until a few days ago...
470 2016-09-15 22:21:47	0|BlueMatt|I had to push his to the keyserver for him :(
471 2016-09-15 22:22:07	0|BlueMatt|gmaxwell: but, I dont see why we shouldnt just include everyone there, whether the folder is renamed from gitian or not :)
472 2016-09-15 22:22:15	0|gmaxwell|right.
473 2016-09-15 22:22:56	0|btcdrak|seems about right.
474 2016-09-15 22:23:47	0|BlueMatt|oh, it doesnt have you there, gmaxwell :'(
475 2016-09-15 22:28:47	0|luke-jr|BlueMatt: is there an issue for this on GitHub?
476 2016-09-15 22:29:17	0|BlueMatt|luke-jr: dunno, I emailed their support@ alias that has been responsive to me in the past