1 2016-10-13 04:17:52	0|warren|cfields: how's the deterministic toolchain coming?
  2 2016-10-13 06:52:31	0|wumpus|cfields: I have backtraces for https://github.com/bitcoin/bitcoin/issues/8910 . That didn't help much I'm afraid though.
  3 2016-10-13 08:22:42	0|GitHub157|13bitcoin/06master 143f92bc9 15Wladimir J. van der Laan: doc: Add build instructions for FreeBSD
  4 2016-10-13 08:22:42	0|GitHub157|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d0754799698d...d270c30d5530
  5 2016-10-13 08:22:43	0|GitHub157|13bitcoin/06master 14d270c30 15Wladimir J. van der Laan: Merge #8892: doc: Add build instructions for FreeBSD...
  6 2016-10-13 08:22:59	0|GitHub150|[13bitcoin] 15laanwj closed pull request #8892: doc: Add build instructions for FreeBSD (06master...062016_10_freebsd_build) 02https://github.com/bitcoin/bitcoin/pull/8892
  7 2016-10-13 08:31:03	0|GitHub5|13bitcoin/06master 148aed5f6 15Wladimir J. van der Laan: qt: Translate all files, even if wallet disabled...
  8 2016-10-13 08:31:03	0|GitHub5|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d270c30d5530...8d46429c83ec
  9 2016-10-13 08:31:04	0|GitHub5|13bitcoin/06master 148d46429 15Wladimir J. van der Laan: Merge #8911: qt: Translate all files, even if wallet disabled...
 10 2016-10-13 08:31:15	0|GitHub129|[13bitcoin] 15laanwj closed pull request #8911: qt: Translate all files, even if wallet disabled (06master...062016_10_qt_translations_wallet2) 02https://github.com/bitcoin/bitcoin/pull/8911
 11 2016-10-13 10:35:27	0|GitHub12|13bitcoin/060.13 14633c4a1 15Wladimir J. van der Laan: qt: Periodic translations update...
 12 2016-10-13 10:35:27	0|GitHub12|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/633c4a1f3690152bdda4b0ac7bcfde22c237183e
 13 2016-10-13 14:39:44	0|BlueMatt|#8904 doesnt need backporting - the test is overspecified but thats ok, just needs fixing on master
 14 2016-10-13 14:39:54	0|BlueMatt|nvm, no one is here, I'll post on github
 15 2016-10-13 14:46:50	0|sipa|if nobody is here, who are you?
 16 2016-10-13 14:48:50	0|BlueMatt|I am your Conscience
 17 2016-10-13 14:49:04	0|sipa|if nobody is here, who am i?
 18 2016-10-13 14:49:15	0|BlueMatt|you are my Conscience
 19 2016-10-13 14:51:24	0|bsm117532|RuntimeError: maximum recursion depth exceeded
 20 2016-10-13 14:51:55	0|sipa|so i'm my own conscience's conscience?
 21 2016-10-13 14:54:01	0|kanzure|dmv5 says no
 22 2016-10-13 14:55:09	0|bsm117532|I wouldn't rely on a DSM5 you got from the DMV :-P
 23 2016-10-13 14:57:58	0|kanzure|oh oops.
 24 2016-10-13 15:16:34	0|btcdrak|wumpus: is there a meeting today?
 25 2016-10-13 15:16:40	0|BlueMatt|yes
 26 2016-10-13 15:17:03	0|btcdrak|wumpus: you've changed your hair colour?
 27 2016-10-13 15:48:22	0|wumpus|btcdrak: yes re: meeting, no re: hair colour
 28 2016-10-13 15:51:35	0|wumpus|thanks for reminding me it's thursday though, I'd probably have forgot the meeting otherwise :)
 29 2016-10-13 15:52:17	0|sipa|i can confirm that at least until yesterday around noon, wumpus' hair color had not changed measurably
 30 2016-10-13 16:19:26	0|jtimon|updated https://github.com/jtimon/consensus-doc/blob/generated/libconsensus.pdf with more images. any comments or suggestions welcomed
 31 2016-10-13 16:22:06	0|jtimon|or questions
 32 2016-10-13 16:36:02	0|GitHub104|[13bitcoin] 15laanwj opened pull request #8914: Kill insecure_random and associated global state (06master...062016_10_kill_insecurerandom) 02https://github.com/bitcoin/bitcoin/pull/8914
 33 2016-10-13 16:48:58	0|GitHub196|13bitcoin/06master 144cdece4 15Dagur Valberg Johannsson: [qa] Fix compact block shortids for a test case
 34 2016-10-13 16:48:58	0|GitHub196|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8d46429c83ec...e2a17e43e36f
 35 2016-10-13 16:48:59	0|GitHub196|13bitcoin/06master 14e2a17e4 15Wladimir J. van der Laan: Merge #8904: [qa] Fix compact block shortids for a test case...
 36 2016-10-13 16:49:13	0|GitHub114|[13bitcoin] 15laanwj closed pull request #8904: [qa] Fix compact block shortids for a test case (06master...06shortid-coinbase) 02https://github.com/bitcoin/bitcoin/pull/8904
 37 2016-10-13 16:57:08	0|GitHub192|13bitcoin/06master 144408558 15jonnynewbs: Update bitcoin-tx to output witness data.
 38 2016-10-13 16:57:08	0|GitHub192|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e2a17e43e36f...e2b8c394d61d
 39 2016-10-13 16:57:09	0|GitHub192|13bitcoin/06master 14e2b8c39 15Wladimir J. van der Laan: Merge #8817: update bitcoin-tx to output witness data...
 40 2016-10-13 16:57:18	0|GitHub18|[13bitcoin] 15laanwj closed pull request #8817: update bitcoin-tx to output witness data (06master...06bitcoin-tx-witness) 02https://github.com/bitcoin/bitcoin/pull/8817
 41 2016-10-13 17:40:19	0|GitHub60|[13bitcoin] 15petertodd opened pull request #8915: Add copyright/patent issues to possible NACK reasons (06master...062016-10-13-sound-legal-justification) 02https://github.com/bitcoin/bitcoin/pull/8915
 42 2016-10-13 18:14:17	0|MarcoFalke|wumpus: I think it is better to just cherry-pick https://github.com/bitcoin/bitcoin/pull/8643
 43 2016-10-13 18:22:57	0|wumpus|yes, I'm working on backports now, will include that one
 44 2016-10-13 18:23:46	0|wumpus|#8393 is turning out a bit tricky (due to CConnMan) the rest seems easy
 45 2016-10-13 18:24:42	0|achow101|I think #8899 can be merged
 46 2016-10-13 18:25:21	0|instagibbs|achow101, no it can not. There is an outstanding bug.
 47 2016-10-13 18:25:55	0|instagibbs|https://github.com/bitcoin/bitcoin/pull/8499#issuecomment-253184633
 48 2016-10-13 18:26:07	0|achow101|instagibbs: 8899, not 8499 (notice the 8)
 49 2016-10-13 18:26:19	0|instagibbs|ah :)
 50 2016-10-13 18:28:06	0|wumpus|yes, #8899 seems ready (not #8499)
 51 2016-10-13 18:30:21	0|wumpus|I think sipa has a good point there, but I'm not sure of the matter, it's probably better to just take over boost's patch
 52 2016-10-13 18:30:29	0|wumpus|maybe the issue should be raised upstream though
 53 2016-10-13 18:31:46	0|thomasthetank|hey, when i verify my txoutproof it returns incorrect txids
 54 2016-10-13 18:33:24	0|thomasthetank|i noticed the txoutproof size goes from 248 to 235 bytes after being parsed
 55 2016-10-13 18:33:27	0|jl2012|i hope 8499 will be ready in a few days. I have a branch here but sipa is working on a different solution: https://github.com/jl2012/bitcoin/commits/badwitnesscheck-1012
 56 2016-10-13 18:33:32	0|thomasthetank|is that standard
 57 2016-10-13 18:34:35	0|wumpus|thomasthetank: not sure, may be better to file an issue on github w/ exact input and output
 58 2016-10-13 18:40:33	0|GitHub164|[13bitcoin] 15laanwj closed pull request #8643: [0.13 backport] Added feeler connections increasing good addrs in the tried table. (060.13...062016/08/feeler_013) 02https://github.com/bitcoin/bitcoin/pull/8643
 59 2016-10-13 18:44:57	0|GitHub192|[13bitcoin] 15laanwj opened pull request #8916: 0.13.1 backports (060.13...062016_10_backports) 02https://github.com/bitcoin/bitcoin/pull/8916
 60 2016-10-13 18:53:03	0|wumpus|woohoo, just #8499 left https://github.com/bitcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr%20%20label%3A%22Needs%20backport%22%20milestone%3A0.13.1%20
 61 2016-10-13 18:55:18	0|GitHub144|13bitcoin/060.13 1449be9f0 15Michael Ford: Fix wake from sleep issue with Boost 1.59.0
 62 2016-10-13 18:55:18	0|GitHub144|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/633c4a1f3690...4ed26277347c
 63 2016-10-13 18:55:18	0|GitHub189|[13bitcoin] 15laanwj closed pull request #8899: [0.13] Fix wake from sleep issue with Boost 1.59.0 (060.13...06backport-boost-windows-patch) 02https://github.com/bitcoin/bitcoin/pull/8899
 64 2016-10-13 18:55:19	0|GitHub144|13bitcoin/060.13 144ed2627 15Wladimir J. van der Laan: Merge #8899: [0.13] Fix wake from sleep issue with Boost 1.59.0...
 65 2016-10-13 18:57:21	0|BlueMatt|woohoo
 66 2016-10-13 18:57:27	0|BlueMatt|!
 67 2016-10-13 19:00:12	0|sipa|doing
 68 2016-10-13 19:00:21	0|achow101|meeting?
 69 2016-10-13 19:00:28	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
 70 2016-10-13 19:00:34	0|kanzure|hi.
 71 2016-10-13 19:00:35	0|btcdrak|ping
 72 2016-10-13 19:00:39	0|instagibbs|pre-sent
 73 2016-10-13 19:00:48	0|sdaftuar|hi
 74 2016-10-13 19:00:54	0|jtimon|hi
 75 2016-10-13 19:01:01	0|BlueMatt|o where art though fearless leader wumpus
 76 2016-10-13 19:01:02	0|michagogo|hi
 77 2016-10-13 19:01:11	0|gmaxwell|Who called this meeting?
 78 2016-10-13 19:01:22	0|BlueMatt|wumpus: said we were meeting earlier
 79 2016-10-13 19:01:33	0|gmaxwell|Obviously a trap.
 80 2016-10-13 19:01:36	0|BlueMatt|anyway, topic recommendations while we're waiting for a #?
 81 2016-10-13 19:01:49	0|jtimon|I assume 0.13.1
 82 2016-10-13 19:01:58	0|kanzure|0.13.0 wallet bug about importaddress and scriptpubkeys
 83 2016-10-13 19:02:09	0|kanzure|(and witnesses)
 84 2016-10-13 19:02:48	0|gmaxwell|Backport statuses
 85 2016-10-13 19:02:57	0|jtimon|libconsensus verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
 86 2016-10-13 19:03:03	0|kanzure|jtimon: thanks for https://github.com/jtimon/consensus-doc/blob/generated/libconsensus.pdf
 87 2016-10-13 19:03:18	0|kanzure|jtimon: i suggest emailing that to mailing list at some point
 88 2016-10-13 19:03:21	0|achow101|prefinal alert
 89 2016-10-13 19:03:27	0|jtimon|kanzure: I already did
 90 2016-10-13 19:04:03	0|lightningbot|Meeting started Thu Oct 13 19:04:02 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 91 2016-10-13 19:04:03	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 92 2016-10-13 19:04:03	0|wumpus|#startmeeting
 93 2016-10-13 19:04:49	0|BlueMatt|ok, start with 13.1 status update?
 94 2016-10-13 19:04:52	0|wumpus|#topic 0.13.1
 95 2016-10-13 19:04:56	0|jtimon|kanzure: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013204.html
 96 2016-10-13 19:05:10	0|wumpus|I've just done all the remaining backports in https://github.com/bitcoin/bitcoin/pull/8916
 97 2016-10-13 19:05:13	0|BlueMatt|looks like we're one pr away from 13.1, sipa jl2012 or sdaftuar, where are we?
 98 2016-10-13 19:05:20	0|BlueMatt|on 8916
 99 2016-10-13 19:05:20	0|sipa|close.
100 2016-10-13 19:05:28	0|MarcoFalke|#link https://github.com/bitcoin/bitcoin/pull/8916
101 2016-10-13 19:05:29	0|wumpus|this leaves #8499
102 2016-10-13 19:05:42	0|BlueMatt|oh, sorry, 8916 is backports, meant 8499
103 2016-10-13 19:05:47	0|sipa|close.
104 2016-10-13 19:05:49	0|btcdrak|was 8393 backported yet?
105 2016-10-13 19:06:12	0|wumpus|0.13.0 wallet bug about importaddress and scriptpubkeys <- issue id?
106 2016-10-13 19:06:40	0|wumpus|btcdrak: yes, that one is part of #8916
107 2016-10-13 19:06:43	0|sipa|jl2012 has been writing a lot of tests for 8499, as there are a lot of edge cases. i believe they're all identified and fixable noe
108 2016-10-13 19:06:49	0|BlueMatt|ok, so i guess hopefully by next meeting (or late this week) the final few commits on #8499 should be ready for review and we can finalize then?
109 2016-10-13 19:06:49	0|sipa|wumpus: will file one soon
110 2016-10-13 19:07:45	0|wumpus|so there's another blocker for 0.13.1? ok
111 2016-10-13 19:07:58	0|sipa|it's part of 8499
112 2016-10-13 19:08:10	0|sipa|will be fixed simulteneously
113 2016-10-13 19:08:24	0|jtimon|wumpus: bip9 parameters?
114 2016-10-13 19:08:59	0|gmaxwell|BIP9 recommends it be set roughly a month after software release. I don't currently see a reason to deviate from that.
115 2016-10-13 19:09:01	0|wumpus|jtimon: that's a topic suggestion I suppose?
116 2016-10-13 19:09:29	0|gmaxwell|There should be some list discussion. I have been one on oneing with large users of Bitcoin for the last couple weeks.
117 2016-10-13 19:09:29	0|jtimon|gmaxwell: ack
118 2016-10-13 19:09:37	0|instagibbs|So would the idea be to set it only at final release and not RC?
119 2016-10-13 19:09:56	0|gmaxwell|instagibbs: I think we would set it at RC and take a guess.
120 2016-10-13 19:09:57	0|sipa|it should be set for RC
121 2016-10-13 19:10:07	0|sipa|but if a new RC is needed, we can jncrement
122 2016-10-13 19:10:10	0|instagibbs|Ok.
123 2016-10-13 19:10:36	0|gmaxwell|it doesn't have to be precise. The strong invariaent is that the start date should be _after_ the release. :)
124 2016-10-13 19:10:43	0|michagogo|Worst case, if there are a lot of RCs that can be adjusted before the last one
125 2016-10-13 19:10:48	0|wumpus|there can't be changes between the last RC and final
126 2016-10-13 19:10:54	0|MarcoFalke|Huh? If we just increment it may cause a consensus bug?
127 2016-10-13 19:10:55	0|wumpus|so it must be set for every RC too, I'm afraid
128 2016-10-13 19:10:56	0|gmaxwell|keeping in mind that it'll take minimum of 4 weeks to activate post start.
129 2016-10-13 19:11:04	0|MarcoFalke|I mean nodes don't agree
130 2016-10-13 19:11:04	0|sipa|MarcoFalke: assuming miners run RCs
131 2016-10-13 19:11:07	0|michagogo|But the last RC is generally within a week or so of final release
132 2016-10-13 19:11:13	0|jtimon|MarcoFalke: people should not use rc apart from testing
133 2016-10-13 19:11:13	0|michagogo|(Or, the other way around...)
134 2016-10-13 19:11:16	0|wumpus|michagogo: yes
135 2016-10-13 19:11:21	0|MarcoFalke|fine
136 2016-10-13 19:11:21	0|sipa|indeed
137 2016-10-13 19:11:35	0|sipa|when do we exoect 0.13.1rc1?
138 2016-10-13 19:11:37	0|gmaxwell|so I would recommend taking a best guess and changing it if release ends up past that date.
139 2016-10-13 19:11:39	0|wumpus|#topic BIP9 parameters
140 2016-10-13 19:11:52	0|cfields|whoops. Late, but made it.
141 2016-10-13 19:11:54	0|BlueMatt|lets avoid setting it differently in different rcs
142 2016-10-13 19:11:58	0|sdaftuar|i don't think we can just change bip9 params during the rc process
143 2016-10-13 19:12:03	0|sdaftuar|that's a consensus change
144 2016-10-13 19:12:12	0|sdaftuar|we almost screwed this up in 0.13.0
145 2016-10-13 19:12:12	0|wumpus|sipa: all depends on #8499 + the bug fix for 0.13.1
146 2016-10-13 19:12:34	0|wumpus|I'd do 0.13.1 today if it was not for those
147 2016-10-13 19:12:36	0|sipa|i'm sure we'll be ready next seek
148 2016-10-13 19:12:50	0|sipa|(i'd like to say tomorrow, but who knows)
149 2016-10-13 19:12:59	0|morcos|it seems not a bad idea to take a conservative estimate of the length of time the RC process will take, add a month to that and use the date.
150 2016-10-13 19:13:01	0|BlueMatt|proposal: do not set activation parameters in rc1, set them in an rc when we believe we are ready (ie last rc + 1 week or so) and then let that sit for a week before final tag
151 2016-10-13 19:13:11	0|morcos|so use 2 months after the time you issue the first RC for instance?
152 2016-10-13 19:13:14	0|jtimon|morcos: that makes sense to me
153 2016-10-13 19:13:15	0|wumpus|I usually estimate a month for the RC phase, for major releases
154 2016-10-13 19:13:16	0|btcdrak|BlueMatt: +1
155 2016-10-13 19:13:17	0|instagibbs|I think picking and staying with it is best.
156 2016-10-13 19:13:22	0|morcos|or right, like matt said
157 2016-10-13 19:13:23	0|gmaxwell|BlueMatt: the RC's are supposted to be the same as the release.
158 2016-10-13 19:13:25	0|btcdrak|There is no way rc1 will pass anyway.
159 2016-10-13 19:13:32	0|sipa|btcdrak: unsure.
160 2016-10-13 19:13:33	0|BlueMatt|gmaxwell: then lets call the first rc beta :)
161 2016-10-13 19:13:34	0|morcos|btcdrak: ha ha
162 2016-10-13 19:13:54	0|gmaxwell|btcdrak: I think it's likely to do so, I've spent a lot more time on 0.13 branch than master lately.
163 2016-10-13 19:14:03	0|jtimon|BlueMatt's solution is fine as well
164 2016-10-13 19:14:05	0|wumpus|the last RC is supposed to be the same as the release, you could do a RC that is not *really* a release candidate I guess ...
165 2016-10-13 19:14:18	0|BlueMatt|ok, so new proposal: lets do a "beta" phase first, and then graduate to rc?
166 2016-10-13 19:14:19	0|michagogo|Prerc1?
167 2016-10-13 19:14:23	0|michagogo|rc0?
168 2016-10-13 19:14:24	0|btcdrak|0.13.1pre
169 2016-10-13 19:14:42	0|jtimon|btcdrak: if we know rc1 won't pass how come we make it an rc?
170 2016-10-13 19:14:53	0|gmaxwell|I think we're over thinking it. The purpose of the starting time was simply to avoid the case where there was a risk that a feature got activated before any released version of the implementation for it existed at all-- because we found that miners were running master/candidates.
171 2016-10-13 19:14:56	0|wumpus|I guess we can use beta now that bitcoin core itself is no longer beta
172 2016-10-13 19:15:00	0|michagogo|jtimon: its more like, if it passes, something's "wrong"
173 2016-10-13 19:15:11	0|jtimon|michagogo: not following
174 2016-10-13 19:15:12	0|wumpus|thoug hI"d prefer just calling it rc, all tooling is setup for that
175 2016-10-13 19:15:15	0|michagogo|Like when your code compiles without errors the first time
176 2016-10-13 19:15:16	0|sipa|i don't like this. just pick a date reasonably far in the future and do rc1
177 2016-10-13 19:15:27	0|BlueMatt|so set parameters to 1.5 months for rc1? or 2?
178 2016-10-13 19:15:28	0|gmaxwell|Considering that there is a _minimum_ 4032 block interval from startdate to activation, there is a LOT of safty margin here.
179 2016-10-13 19:15:37	0|wumpus|sipa: +1
180 2016-10-13 19:15:45	0|wumpus|just estimate 2 months for the RC process
181 2016-10-13 19:15:47	0|cfields|sipa: agreed. Otherwise there's no way we'll be able to explain the semantics.
182 2016-10-13 19:15:48	0|wumpus|that should be ample enough
183 2016-10-13 19:15:49	0|BlueMatt|ok, I'm ok with something like 2 months from rc1
184 2016-10-13 19:15:55	0|btcdrak|most releases take 3 or 4 rcs, so if we set the date for 5 weeks on rc1 that would cover it I am sure.
185 2016-10-13 19:15:58	0|morcos|or is wumpus saying 3 months
186 2016-10-13 19:16:07	0|jtimon|michagogo: you mean we expect to have more than one? sure, but we shouldn't make it rc if there's known bugs or required changes is my point
187 2016-10-13 19:16:09	0|BlueMatt|ehh, I'd rather be conservative btcdrak
188 2016-10-13 19:16:12	0|wumpus|no, two months is fine
189 2016-10-13 19:16:15	0|morcos|2 months for process, one for it to be released
190 2016-10-13 19:16:17	0|achow101|I think two months after rc1 is fine
191 2016-10-13 19:16:17	0|BlueMatt|i mean I'm ok with 1.5 months, too
192 2016-10-13 19:16:27	0|michagogo|jtimon: well, obviously the goal is for rc1 to = final
193 2016-10-13 19:16:28	0|morcos|ok, i'm fine with either, less than 2 is a bit rushing it
194 2016-10-13 19:16:33	0|btcdrak|this is like an auction.
195 2016-10-13 19:16:41	0|gmaxwell|There are many people who _urgently_ want segwit activated yesturday.
196 2016-10-13 19:16:41	0|jtimon|michagogo: undesrtood
197 2016-10-13 19:16:42	0|wumpus|usually I estimate 1 month for rc1->final, but this maybe be more involved than usual, dunno
198 2016-10-13 19:16:46	0|michagogo|Just like when you write code the goal is for it to compile perfectly the first time :P
199 2016-10-13 19:16:57	0|BlueMatt|wumpus: or less, hopefully
200 2016-10-13 19:17:05	0|BlueMatt|:p
201 2016-10-13 19:17:07	0|sipa|i think this rc will be much shorter
202 2016-10-13 19:17:14	0|wumpus|BlueMatt: well this is a minor release, so it *should* be shorter
203 2016-10-13 19:17:18	0|btcdrak|well we could just commit to sleepless nights to make release happen on time :-p
204 2016-10-13 19:17:18	0|gmaxwell|I think it would be fine to set start date 1 month after final. Even then if RCs take two months we still will not be at risk of activation before a software release.
205 2016-10-13 19:17:30	0|sdaftuar|gmaxwell: the downside to rushing this out is that there's less time for everyone to test with the updated policy changes on testnet
206 2016-10-13 19:17:32	0|gmaxwell|er 1 month after RC1 not final.
207 2016-10-13 19:17:44	0|gmaxwell|sdaftuar: most of them are no-ops on testnet.
208 2016-10-13 19:17:56	0|sdaftuar|gmaxwell: how so?
209 2016-10-13 19:17:59	0|gmaxwell|though I have been running with the patches applied and testnet set to enforce policy.
210 2016-10-13 19:18:07	0|gmaxwell|sdaftuar: testnet doesn't enforce standardness rules.
211 2016-10-13 19:18:13	0|BlueMatt|i mean can we get testnet miners to do compact-enforcement today?
212 2016-10-13 19:18:14	0|sdaftuar|yes it does, for the script checks
213 2016-10-13 19:18:17	0|BlueMatt|that should be most of it?
214 2016-10-13 19:18:36	0|BlueMatt|phantomcircuit: Lightsword please do that ^
215 2016-10-13 19:18:38	0|btcdrak|well remember there are non Core nodes mining on testnet
216 2016-10-13 19:18:44	0|sdaftuar|gmaxwell: am i missing something?
217 2016-10-13 19:19:01	0|btcdrak|I think lightsword's miner must be off, none of roasbeef's txs are getting mined.
218 2016-10-13 19:19:06	0|gmaxwell|sdaftuar: no, though not all the new policy is scriptchecks.
219 2016-10-13 19:19:23	0|cfields|btcdrak: I'll be firing mine up in the next day or two
220 2016-10-13 19:19:23	0|gmaxwell|In any case, I don't think we should decide for sure here, we should make a list post.
221 2016-10-13 19:19:38	0|sdaftuar|gmaxwell: sure not all, but the most significant ones IMO
222 2016-10-13 19:19:42	0|jtimon|prosed topic, maybe not for today: testnet4
223 2016-10-13 19:19:50	0|btcdrak|There are 4k unconfirmed "spam" txs https://testnet.smartbit.com.au/
224 2016-10-13 19:20:09	0|gmaxwell|But I think we should be suggesting 1month post rc1 as the starting time, when we do. Unless something specific comes up that suggests otherwise.
225 2016-10-13 19:20:14	0|BlueMatt|gmaxwell: agreed, for now lets recommend 1.25 months from rc1 release on the list, and get some testnet miners spun up mining #8499 today so that we're less worried about sdaftuar's objection?
226 2016-10-13 19:20:35	0|gmaxwell|Keep in mind, in prior softforks the starting time was infinitely far in the past. And BIP9 made its way through 95% of its development with no starting time.
227 2016-10-13 19:20:43	0|michagogo|BlueMatt: perhaps 50 days for roundness
228 2016-10-13 19:20:44	0|michagogo|Or 55
229 2016-10-13 19:20:57	0|sipa|nov 15.
230 2016-10-13 19:21:10	0|michagogo|That's good too
231 2016-10-13 19:21:16	0|btcdrak|great.
232 2016-10-13 19:21:23	0|michagogo|(A birthday gift for my brother, perhaps?)
233 2016-10-13 19:21:24	0|gmaxwell|it was added because for one prior sf we ended up with >30% hashpower weeks before release... and that was for a SF with no quieting period... so it had a real risk of activating basically before a release.
234 2016-10-13 19:22:07	0|wumpus|I doubt that's a risk for segwit
235 2016-10-13 19:22:16	0|gmaxwell|Agreed.
236 2016-10-13 19:22:20	0|jtimon|gmaxwell: I think it's useful beyond that
237 2016-10-13 19:22:41	0|btcdrak|yes, the fact BIP9 requires 4-6 weeks to kick in realistically, makes it less of an issue
238 2016-10-13 19:23:03	0|sipa|nov 15 is close to a retarget
239 2016-10-13 19:23:07	0|gmaxwell|4-8 weeks with 6 weeks being the average if all miners immediately upgrade.
240 2016-10-13 19:23:08	0|btcdrak|ok so Nov 15th it is?
241 2016-10-13 19:23:11	0|sipa|maybe we want to pick a date just before a retarget
242 2016-10-13 19:23:35	0|achow101|nov 15th sounds good (at 00:00 AM?)
243 2016-10-13 19:23:36	0|btcdrak|sipa: yes and remember Bitfury are turning on a _lot_ of hash rate going forward
244 2016-10-13 19:23:39	0|gmaxwell|btcdrak: probably shouldn't be just setting it here, but just have a feel for what we think is reasonable.
245 2016-10-13 19:24:12	0|sipa|yes, let's propose on the ML
246 2016-10-13 19:24:16	0|BlueMatt|ok, seems like we have rough consensus on a month after rc1 is probably a reasonable recommendation, so lets propose to the ml
247 2016-10-13 19:24:24	0|instagibbs|Ack
248 2016-10-13 19:24:50	0|wumpus|yes
249 2016-10-13 19:24:59	0|gmaxwell|sipa: do you want to do the list thing, or should I or?
250 2016-10-13 19:25:05	0|sipa|i will
251 2016-10-13 19:25:08	0|jtimon|ack on following up on the mailing list, it seems nobody is unhappy about either rc1 + 1 month nor rc2 + 2 month
252 2016-10-13 19:25:19	0|wumpus|#action propose segwit activation parameters on the ML
253 2016-10-13 19:25:20	0|jtimon|nor 15 nov
254 2016-10-13 19:25:29	0|BlueMatt|ok, next topic?
255 2016-10-13 19:25:49	0|wumpus|#topic testnet4 (jtimon)
256 2016-10-13 19:26:03	0|BlueMatt|why?
257 2016-10-13 19:26:08	0|achow101|^
258 2016-10-13 19:26:12	0|wumpus|@jtimon
259 2016-10-13 19:26:16	0|jtimon|well, I would prefer to discuss verifyBlock vs processBlock actually
260 2016-10-13 19:26:34	0|wumpus|lol you proposed the topic
261 2016-10-13 19:26:42	0|jtimon|but some people complained about testnet being unreliable
262 2016-10-13 19:27:01	0|BlueMatt|isnt that a number of miners thing?
263 2016-10-13 19:27:04	0|wumpus|do you have a concrete proposal to fix that?
264 2016-10-13 19:27:08	0|gmaxwell|That has little to do with 'testnet4'  I think. It just is that testnet is not consistently mined.
265 2016-10-13 19:27:09	0|sipa|i don't know that resetting would help
266 2016-10-13 19:27:12	0|jtimon|my main interest would be to remove the special case for testnet on pow
267 2016-10-13 19:27:27	0|BlueMatt|that would make it more unreliable?
268 2016-10-13 19:27:31	0|jtimon|don't drop diff to 1, maybe just add a max difficulty or something simpler
269 2016-10-13 19:27:56	0|jtimon|BlueMatt: I doubts so
270 2016-10-13 19:28:09	0|BlueMatt|i mean we added that rule because testnet was unreliable
271 2016-10-13 19:28:23	0|jtimon|BlueMatt: and did it solved it?
272 2016-10-13 19:28:25	0|BlueMatt|though i have no intuition for properly setting a max testnet diff that is reasonable
273 2016-10-13 19:28:33	0|BlueMatt|jtimon: it made it an order of magnitude (or two) better
274 2016-10-13 19:28:38	0|wumpus|yes, without it it is even worse
275 2016-10-13 19:28:44	0|jtimon|BlueMatt: fair enough
276 2016-10-13 19:28:45	0|btcdrak|max diff would be a disaster
277 2016-10-13 19:28:51	0|jtimon|maybe next topic?
278 2016-10-13 19:28:55	0|sipa|we could live without the permanent reset bug, though
279 2016-10-13 19:29:02	0|wumpus|any other topics?
280 2016-10-13 19:29:59	0|wumpus|*crickets*
281 2016-10-13 19:30:38	0|achow101|the prefinal alert that was supposed to happen but didn't?
282 2016-10-13 19:30:42	0|jtimon|libconsensus: verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
283 2016-10-13 19:30:42	0|wumpus|well, that concludes the meeting early I guess. Let's make sure we can have a 0.13.1rc1 by next week
284 2016-10-13 19:30:50	0|BlueMatt|achow101: suggested prefinal alert
285 2016-10-13 19:31:09	0|gmaxwell|jtimon: a lot of people would like us to have a signed testnet using the pluggable pow stuff that is in elements, so that it would have perfectly predictable blocks and perfectly predictable reorgs.
286 2016-10-13 19:31:37	0|gmaxwell|achow101: we need to write explination text for bitcoin.org and I haven't had time to do it and no one else has stepped up.
287 2016-10-13 19:31:44	0|gmaxwell|I have an alert ready to go.
288 2016-10-13 19:31:50	0|jtimon|gmaxwell: I would be more than happy to put that in core if it's desirable, thanks for letting me know
289 2016-10-13 19:31:51	0|wumpus|#topic prefinal alert
290 2016-10-13 19:31:52	0|achow101|copy-paste from email
291 2016-10-13 19:32:26	0|gmaxwell|Needs to have an explination of the alert system, why it's gone now. And a description of the future steps that we discussed here.
292 2016-10-13 19:33:04	0|gmaxwell|achow101: do you want to try drafting something? I would be happy to review/edit.
293 2016-10-13 19:33:16	0|achow101|sure, I can try writing it
294 2016-10-13 19:33:58	0|gmaxwell|sounds good.
295 2016-10-13 19:34:22	0|wumpus|#action achow101 post about alert system for bitcoin.org
296 2016-10-13 19:34:44	0|wumpus|thanks
297 2016-10-13 19:34:56	0|btcdrak|Just a random information topic, there is a segwit dev guide for downstream published here https://bitcoincore.org/en/segwit_wallet_dev/
298 2016-10-13 19:34:57	0|gmaxwell|jtimon: if we're going to do any 'new testnet thing' we should figure out how to extract the good test cases from the existing testnet. E.g. instrumenting for code coverage and syncing testnet while noting which transactions increased coverage.
299 2016-10-13 19:35:10	0|wumpus|btcdrak: awesome!
300 2016-10-13 19:35:31	0|wumpus|#link segwit dev guide for downstream https://bitcoincore.org/en/segwit_wallet_dev/
301 2016-10-13 19:35:57	0|gmaxwell|we have other upcoming doc works. We should have a segwit deployment guide-- covering things like explaining how to setup perimiter nodes to shield unupgraded custom stuff-- ready at the start of the segwit queting period.
302 2016-10-13 19:36:11	0|achow101|apparently no one but me knew that dev guide even existed...
303 2016-10-13 19:36:27	0|gmaxwell|But we can get contributors outside of the regulars for this meeting, for the audience here advice on content would be good.
304 2016-10-13 19:36:31	0|morcos|it seems to me a better way to make testnet usable is to just pool some funding to have some small but non-trivial hashpower running it rather than implement more differences in behavior from mainnet
305 2016-10-13 19:36:42	0|wumpus|achow101: a lot of good information exists but the knowledge of that information is pretty sparse
306 2016-10-13 19:36:54	0|wumpus|achow101: has always been a problem in bitcoin :(
307 2016-10-13 19:37:05	0|gmaxwell|morcos: the problem is that some clown pool will occasionally drop a petahash onto it an drive the difficulty up.
308 2016-10-13 19:37:05	0|jtimon|gmaxwell: is there any recommended tool for coverage in bitcoin core?
309 2016-10-13 19:37:35	0|wumpus|jtimon: valgrind?
310 2016-10-13 19:37:45	0|jcorgan|gmaxwell: i could likely help with some of the documentation work, if there is someone on the team to work with
311 2016-10-13 19:37:56	0|gmaxwell|jtimon: lcov works. But to get data inline like that some stunts involving gprof can be done.
312 2016-10-13 19:38:27	0|gmaxwell|You can ask the gprof stuff to dump the current data with a function call, IIRC.. so presumably one could instrument doing that after processing each transaction.
313 2016-10-13 19:38:27	0|jtimon|oh, I just recently starting using lcov, nice
314 2016-10-13 19:39:25	0|gmaxwell|in any case, there are tests in testnet that do not exist in any unit test. It would be good to find most of them and be able to start out a new testnet where the first few hundred blocks excercise all of them.
315 2016-10-13 19:39:26	0|Chris_Stewart_5|gmaxwell: Content on what docs? Segwit docs?
316 2016-10-13 19:39:34	0|wumpus|after each block may be enough granularity
317 2016-10-13 19:40:12	0|gmaxwell|Chris_Stewart_5: on what materials should be covered in a deployment guide. For non-miners the only really important thing that comes to mind to me is instructions on setting up peremiter nodes.
318 2016-10-13 19:40:31	0|Chris_Stewart_5|Gotcha.
319 2016-10-13 19:40:40	0|gmaxwell|but no doubt there are other things.
320 2016-10-13 19:40:51	0|sdaftuar|all the policy changes!
321 2016-10-13 19:41:06	0|Chris_Stewart_5|jtimon: I think cfields has some sort of website that shows lcov coverage
322 2016-10-13 19:41:12	0|gmaxwell|sdaftuar: fair enough, though I expect those to be 99% invisible, but good to cover them more.
323 2016-10-13 19:41:42	0|cfields|Chris_Stewart_5: that was a one-time thing for segwit. Just need to fix up the makefile stuff so it can be auto-generated again
324 2016-10-13 19:43:00	0|wumpus|gah, looks like my backport of #8393 in #8916 is failing the RPC tests
325 2016-10-13 19:43:13	0|sdaftuar|wumpus: i'm running locally... compact blocks again
326 2016-10-13 19:43:36	0|sdaftuar|wumpus: i can reproduce at least
327 2016-10-13 19:43:39	0|jtimon|Chris_Stewart_5: gmaxwell: awesome, maybe we should consider putting some lcov stuff as tooling? something like in https://github.com/jgriffiths/libwally-core#generating-a-coverage-report ? stupid people like me appreciate these things...
328 2016-10-13 19:43:39	0|wumpus|okay thanks!
329 2016-10-13 19:44:38	0|jtimon|maybe I should start with that before a nexttestnet, anyway, I'll come back to you and cfields, we're mixing topics
330 2016-10-13 19:44:52	0|wumpus|jtimon: recently created a bitcoin-maintainer-tools repo https://github.com/laanwj/bitcoin-maintainer-tools, would make sense to add to that
331 2016-10-13 19:45:24	0|Chris_Stewart_5|jtimon: I think it is an easy way to direct new developers where it might be easiest to contribute to, as they can easily see where we are lacking tests
332 2016-10-13 19:45:31	0|cfields|jtimon: we have an --enable-lcov (or something like that). But it's broken atm.
333 2016-10-13 19:46:22	0|jtimon|awesome, so there's work to be done here but there's a base, thank you guys
334 2016-10-13 19:46:26	0|cfields|just need to get it fixed up again, shouldn't be too tough.
335 2016-10-13 19:46:37	0|wumpus|we should probably create an issue for that
336 2016-10-13 19:46:50	0|jtimon|wumpus: will check that out, does it contain lcov too? maybe we should consid
337 2016-10-13 19:46:58	0|gmaxwell|I haven't been too generally impressed with the utility of lcov on the bitcoin core codebase-- better than nothing I guess, but the branch coverage is full of BS unreachable branches due allocations in templaized container objects.
338 2016-10-13 19:47:07	0|jtimon|s//wumpus: will check that out
339 2016-10-13 19:47:11	0|wumpus|jtimon: no, it currently contains only a tool for doing per-function binary comparison of builds
340 2016-10-13 19:47:52	0|wumpus|jtimon: but I'm generally for sharing our tools more
341 2016-10-13 19:48:16	0|jtimon|gmaxwell: yeah, for a new testchain, take into account that we're still using globals and some hardcoding
342 2016-10-13 19:48:49	0|wumpus|jtimon: I have a lot of other ones, but need to clean up and disentangle them from other local stuff first before I can publish them
343 2016-10-13 19:49:19	0|wumpus|(for example for creating release notes)
344 2016-10-13 19:49:30	0|jtimon|things like https://github.com/bitcoin/bitcoin/pull/8855 should help with new testchains
345 2016-10-13 19:50:19	0|gmaxwell|so... another topic, probably mostly for a future meeting.. sybil attacks.
346 2016-10-13 19:50:20	0|jtimon|wumpus: nice, we can incorporate those upstream little by little
347 2016-10-13 19:50:21	0|wumpus|anyhow let's end the meeting, seems we're not really on a topic anymore
348 2016-10-13 19:50:34	0|gmaxwell|I am now seeing 60+ connections within seconds of starting a node..
349 2016-10-13 19:50:36	0|wumpus|jtimon: I really prefer having meta-tools in a separate repo
350 2016-10-13 19:51:18	0|wumpus|jtimon: as they're not really on the same release cycle, and go through lots of changes that don't really need to go through the bitcoin core review process
351 2016-10-13 19:51:22	0|jtimon|wumpus: well I don't have a strong opinion, you can always document where those tools are somewhere
352 2016-10-13 19:51:30	0|wumpus|yes
353 2016-10-13 19:51:37	0|wumpus|#topic sybil attacks
354 2016-10-13 19:51:43	0|gmaxwell|Does anyone here have any back channels into amazon operations? I'd like to know why they are unresponsive to abuse conmplaints regarding this user.
355 2016-10-13 19:52:44	0|gmaxwell|So background: someone is mass connecting many times in parallel to all reachable ondes, pretending, poorly, to be a mix of different spv clients.
356 2016-10-13 19:52:46	0|wumpus|reminds me I should still file a complaint for that
357 2016-10-13 19:53:02	0|jtimon|suggested topic: libconsensus: verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
358 2016-10-13 19:53:19	0|wumpus|sybil01: oh no :)
359 2016-10-13 19:53:33	0|gmaxwell|Because of the connection management stuff implemented a few versions ago, it doesn't disrupt the network much (these peers can get evicted). But I presume their motivation is to undermine user's privacy through observation.
360 2016-10-13 19:54:04	0|BlueMatt|gmaxwell: i mean if we fix the privacy leak that makes it useful to do this, maybe they'll go away :)
361 2016-10-13 19:54:23	0|CodeShark|hi guys...traveling and can't catch entire meeting but will read thr scrollback :)
362 2016-10-13 19:54:26	0|wumpus|that must be the reason to do this, it would be an extremely ineffective DoS
363 2016-10-13 19:54:29	0|gmaxwell|Right now, connecting more times in parallel will leak more information and we can reduce that leackage further with already planned future relay improvements. ... which I've only not finished due to focusing on testing segwit and whatnot.
364 2016-10-13 19:54:48	0|gmaxwell|wumpus: it would be a potent DOS prior to 0.12-ish.
365 2016-10-13 19:55:14	0|gmaxwell|but yes, I presume they'll stop if we further reduce the privacy leaks. So thats the obvious thing to do.
366 2016-10-13 19:55:19	0|wumpus|gmaxwell: but it seems they open a fixed number of connections per node. A DoS would exhaust slots
367 2016-10-13 19:55:28	0|btcdrak|can we ban multiple connection from the same IP? that would be a start against this particular AWS spy.
368 2016-10-13 19:55:35	0|gmaxwell|presumably they were doing this before, and prior improvements killed the leaks unless they connected multiple times which made them visible.
369 2016-10-13 19:55:49	0|sipa|btcdrak: meh, they'll move to routing through different ips
370 2016-10-13 19:56:02	0|gmaxwell|btcdrak: it would be pretty harmful to do that network wide as there are many instutions and even a country where all connections come from one ip.
371 2016-10-13 19:56:03	0|wumpus|theyalready use multiple IPs, though they also do multiple connections per IP form some reason
372 2016-10-13 19:56:17	0|gmaxwell|and they do already use multiple IPs. and they changed them after people started circulating banlists.
373 2016-10-13 19:56:54	0|BlueMatt|several folks now ban aws nodes wholesale, which sucks because aws nodes are useful due to DDoS protection built-in
374 2016-10-13 19:56:58	0|wumpus|but yes IPs are cheap anyway, as long as there's profit to be made from this they'll not go away. THough I personally ban multiple connects from a single IP on my nodes.
375 2016-10-13 19:56:59	0|BlueMatt|(including some of my nodes)
376 2016-10-13 19:57:06	0|gmaxwell|I'd like to avoid hardcoding netblock specific rules "one connection per IP from amazon IP space" and whatnot. :)
377 2016-10-13 19:57:20	0|gmaxwell|so in any case, reducing the leakage is always a good move and we should do that.
378 2016-10-13 19:57:24	0|BlueMatt|yup
379 2016-10-13 19:57:36	0|sipa|i think we can make the relay delays use deterministic randomness based on netgroup, so nodes in the same range will see the same thing
380 2016-10-13 19:57:58	0|sipa|and many more ideas
381 2016-10-13 19:58:02	0|cfields|gmaxwell: for one in every X connections, we could proxy and route messages together for peer-pairs. Then they'd poison their own stats :p
382 2016-10-13 19:58:02	0|sipa|probably not for this meeting
383 2016-10-13 19:58:23	0|gmaxwell|cfields: That won't work for reasons I'd rather not say in public, unfortunately.
384 2016-10-13 19:58:29	0|btcdrak|1 min 30 seconds to go
385 2016-10-13 19:58:47	0|wumpus|cfields: they don't actually ever send anything
386 2016-10-13 19:58:51	0|gmaxwell|well it would help. but not do quite what you think.. still could be useful.. many fun things to discuss.
387 2016-10-13 19:59:24	0|wumpus|cfields: they just negotiate the connection, answer pings, and listen. Though poisining the info sounds like fun.
388 2016-10-13 20:00:01	0|instagibbs|ding ding
389 2016-10-13 20:00:01	0|sipa|DANG
390 2016-10-13 20:00:05	0|btcdrak|dong
391 2016-10-13 20:00:07	0|wumpus|and yes, netblock specific rules are not an option, that'd be Hearnian
392 2016-10-13 20:00:11	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html
393 2016-10-13 20:00:11	0|lightningbot|Meeting ended Thu Oct 13 20:00:10 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
394 2016-10-13 20:00:11	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.html
395 2016-10-13 20:00:11	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.txt
396 2016-10-13 20:00:11	0|wumpus|#endmeeting
397 2016-10-13 20:00:44	0|gmaxwell|wumpus: it would potentially make sense to ship with a IP -> ASN map to make the same-netgroup logic more intelligent... though it would be a couple megabytes of data to ship, unfortunately.
398 2016-10-13 20:01:18	0|gmaxwell|but I don't know that doing anything that depends on IPs as a limit resource is worth any time.
399 2016-10-13 20:01:24	0|musalbas|blocking multiple connections per IP would also have the added benefit of helping to prevent Eclipse attacks (per http://eprint.iacr.org/2015/263.pdf)
400 2016-10-13 20:01:37	0|gmaxwell|musalbas: no, it wouldn't.
401 2016-10-13 20:02:07	0|wumpus|musalbas: IPv4's are cheap, any attack that runs profit of any kind can use tons of them
402 2016-10-13 20:02:13	0|musalbas|true
403 2016-10-13 20:02:18	0|wumpus|... not to speak about IPv6's :)
404 2016-10-13 20:02:20	0|gmaxwell|musalbas: multiple inbound connections per IP cannot really be used to perform eclipse attacks in bitcoin due to how the connection management works.
405 2016-10-13 20:02:39	0|gmaxwell|musalbas: if we run out of connections, we will start kicking off peers, and those dupes are among the first to go.
406 2016-10-13 20:04:03	0|instagibbs|due to metrics in AttemptToEvictConnection?
407 2016-10-13 20:04:18	0|musalbas|yeah i recall some countermeasures being implemented
408 2016-10-13 20:04:22	0|gmaxwell|musalbas: the logic is that when we fill and a new one comes in, we make a decision to potentially evict a connection (including the new one). The decision first protects a subset of peers based on them being "good" according to varrious different criteria, then it kicks the shortest uptime peer from the netgroup with the most inbound connections.
409 2016-10-13 20:04:38	0|instagibbs|if they're not serving data, and in same netgroup, only a small number may be protected from eviction
410 2016-10-13 20:04:42	0|musalbas|interesting
411 2016-10-13 20:04:43	0|wumpus|gmaxwell: yes IP to ASN map would be an idea
412 2016-10-13 20:05:15	0|instagibbs|musalbas, https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L873
413 2016-10-13 20:06:54	0|gmaxwell|the way this particular attacker works tends to exploit the longest uptime protection, unfortunately. Though we could easily strenghten that some.
414 2016-10-13 20:07:16	0|gmaxwell|I've hesitated adding narrow improvements that they could easily avoid, however.
415 2016-10-13 20:07:40	0|musalbas|out of curiosity are there any countermeasures to defend against the case where an attacker controls the user's network, forces them to only connect to their nodes and kills connections from the outside world, and starts giving them "secret" blocks?
416 2016-10-13 20:07:57	0|gmaxwell|musalbas: yes, proof of work.
417 2016-10-13 20:08:11	0|wumpus|gmaxwell: wonder if it woudl be possible to compress that map in a smart way, maybe approximate it, in a way that would be better than the current same-netgroup logic but fairly compact
418 2016-10-13 20:08:26	0|musalbas|gmaxwell, yes but assuming the adversary is well resourced but has less than 51% of hashing power they can still give a user secret blocks.
419 2016-10-13 20:08:36	0|gmaxwell|and the software knows about the identity of the 'real' chain, to enough extent that making a whole fake world is computationally hard, even if the node is interceptect from start.
420 2016-10-13 20:09:12	0|gmaxwell|musalbas: yup. There is no protection against that.  One of the motiviations behind the proposed authenticated transport is so that nodes could add authenticated peers.
421 2016-10-13 20:09:13	0|musalbas|gmaxwell, but the difference would be that the blocks would be a lot less frequence *unless they are pre-computed before the attack* - which could be a way to detect
422 2016-10-13 20:09:26	0|musalbas|frequent*
423 2016-10-13 20:09:54	0|musalbas|gmaxwell, i see
424 2016-10-13 20:10:19	0|BlueMatt|musalbas: even if the attacker has 50% of hashrate its gonna generate blocks slower than the "real" network
425 2016-10-13 20:10:19	0|BlueMatt|(though, at that point, the attacker potentially is the "real" network)
426 2016-10-13 20:11:01	0|musalbas|BlueMatt, unless the attacker knows the block height that the client is on before connecting to the network, and pre-computes a bunch of blocks with certain timestamps a long time before the attack occurs
427 2016-10-13 20:11:13	0|gmaxwell|musalbas: the slower criteria doesn't generally work that well, if you work out the math for an acceptably fp rate, the attacker has to be awfully slow for it to reliably trigger there.
428 2016-10-13 20:11:44	0|musalbas|i see
429 2016-10-13 20:12:00	0|BlueMatt|musalbas: i mean as long as the chain's hashpower isnt going up too fast, the client can tell that its last block was X days ago, and too few blocks were generated for that time
430 2016-10-13 20:12:20	0|BlueMatt|gmaxwell: luckily the math works out better over longer time horizons, like the attack musalbas is referencing :)
431 2016-10-13 20:12:26	0|musalbas|anyways, if the eclipse attack problem is solved for offline-networks, it could have some good applications for transparency overlays in threat models where the attacker owns the network
432 2016-10-13 20:12:50	0|BlueMatt|indeed, though you we also already have good tor support for this reason
433 2016-10-13 20:13:22	0|gmaxwell|musalbas: if it were actually solvable in a strong sense bitcoin wouldn't need mining.
434 2016-10-13 20:14:22	0|musalbas|gmaxwell, there are papers that suggest that bitcoin doesn't need mining if you collapse Bitcoin into Certificate Transparency-like system, but that assumes a level of trust in a set of distributed actors
435 2016-10-13 20:15:00	0|musalbas|however, if you can have trustless CT without blockchain then ... :)
436 2016-10-13 20:15:33	0|midnightmagic|-- then altcoin scams.
437 2016-10-13 20:16:01	0|musalbas|BlueMatt, yeah Tor could be good to prevent that, but it's not foolproof at you're transferring your trust to a set of distributed Tor directory authorities
438 2016-10-13 20:16:53	0|gmaxwell|musalbas: ultimately if you are not trusting a specified set, then what is to say that your isolating attacker _isn't_ the valid network.
439 2016-10-13 20:17:03	0|gmaxwell|So I think the problem you hope to solve is not well defined.
440 2016-10-13 20:17:38	0|gmaxwell|But having unforgable adjcencies with parties you know would protect from isolation attacks in practice, and requires no centeralized ttp.
441 2016-10-13 20:20:19	0|musalbas|gmaxwell, I would be curious to hear your opinion in the creator of Certificate Transparency's criticisms of Bitcoin, who argues that Bitcoin is not decentralized unless 51% of the world's processing power is doing Bitcoin hashing, and therefore you have to trust the people who set the checkpoints in the Bitcoin source code otherwise you can just rewrite the chain.
442 2016-10-13 20:20:47	0|instagibbs|hmm, test before evict didn't go anywhere. Wonder if that can get worked on.
443 2016-10-13 20:20:55	0|instagibbs|now that feeler is in
444 2016-10-13 20:20:58	0|musalbas|(http://www.links.org/files/decentralised-currencies.pdf)
445 2016-10-13 20:21:01	0|gmaxwell|musalbas: he's full of shit.
446 2016-10-13 20:21:03	0|gmaxwell|:)
447 2016-10-13 20:21:09	0|wumpus|the checkpoints are going to go
448 2016-10-13 20:21:20	0|gmaxwell|which I helpfully told him as soon as he wrote that, but alas, he didn't respond.
449 2016-10-13 20:21:25	0|gmaxwell|lemme give you my response.
450 2016-10-13 20:22:40	0|musalbas|yeah I agree - but I'm trying to making him come around by currently writing a paper for a way to make CT trustless but while keeping it scalable by enhancing it using the blockchain as a medium for partial transparency
451 2016-10-13 20:23:06	0|wumpus|only in the early blocks (when difficulty is very low) it'd be realistically possible to feed a client the wrong chain, and it may waste some time with that, and checkpoints are reasonably useful for avoiding that... but once it catches up it will notice anyhow that that's not the most-work chain
452 2016-10-13 20:23:39	0|gmaxwell|musalbas: http://0bin.net/paste/nyvikpO+-Q+R5ZsW#MmdECr9dkrXeLO0HKMp5LVvtgH377V-28cN9r1LSBGS  keep in mind, I wrote that in 2011... I would probably say some different things now.
453 2016-10-13 20:24:08	0|musalbas|i'll read
454 2016-10-13 20:25:46	0|musalbas|(but bbl for now as i have to travel home)
455 2016-10-13 20:26:30	0|gmaxwell|as wumpus mentions, we're now going to remove checkpoints soon, they don't do anything much anymore. There are a couple DOS attacks that they help with, getting rid of them is important to avoid misunderstandings like Ben's.
456 2016-10-13 20:27:45	0|gmaxwell|and FWIW, the last checkpoint was set at block 295000 ... over two years ago.
457 2016-10-13 21:40:37	0|achow101|gmaxwell: (and whoever can publish alerts, wumpus?) what do you think: https://github.com/achow101/bitcoin.org/blob/prefinal-alert/_alerts/2016-10-14-alert-retirement.md
458 2016-10-13 21:52:33	0|wumpus|looking :)
459 2016-10-13 21:54:22	0|btcdrak|achow101: also one key means we have no idea how many people the key was shared with and who is in possession of the key.
460 2016-10-13 21:55:24	0|btcdrak|and it seems like magicaltux also has the key and he was detained by police it seems reasonable that the key might be in many many people's possession by now
461 2016-10-13 21:59:06	0|wumpus|yes, we don't know who has the key at this point. It's a typical issue with only having one, shared, key. You don't know who was it that sent an alert, and you can't revert one person's key
462 2016-10-13 22:00:44	0|wumpus|"No Bitcoins are at risk and this warning may be safely ignored" yes, indeed. It's a no-op for most.
463 2016-10-13 22:01:59	0|gmaxwell|I like the text overall!
464 2016-10-13 22:02:04	0|wumpus|in the case of bitcoin core we have the bitcoin core announcement list now: https://bitcoincore.org/en/list/announcements/join/
465 2016-10-13 22:02:17	0|wumpus|me too
466 2016-10-13 22:03:12	0|wumpus|seems good to me
467 2016-10-13 22:03:25	0|kanzure|achow101: i suggest linking to at least https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html
468 2016-10-13 22:03:38	0|kanzure|and possibly earlier discussion too
469 2016-10-13 22:04:01	0|gmaxwell|I think the schedule should be: (1) that page goes up, (2) an email goes to varrious lists, warning about the prefinal alert. Then a day later, the prefinal alert goes out. (I don't see a reason to wait longer than a day, anyone who doesn't see it in a day won't see it anytime soon-- and the only reason to announce it in advance is just in case someone has automation that triggers a shutdown on
470 2016-10-13 22:04:07	0|gmaxwell|any alert)
471 2016-10-13 22:05:01	0|kanzure|not sure about an earlier link, any hints anyone?
472 2016-10-13 22:05:24	0|kanzure|i suppose there was https://github.com/bitcoin/bitcoin/pull/6260 (remove alert system)
473 2016-10-13 22:12:02	0|achow101|kanzure: yeah, I'll link the email, the discussion here from a while back, and that pr
474 2016-10-13 22:12:34	0|gmaxwell|the announcement should point out what versions its deactivated in.
475 2016-10-13 22:12:55	0|achow101|ok
476 2016-10-13 22:13:20	0|gmaxwell|because some people might want to update to a newer version but not all the way or something.
477 2016-10-13 22:14:11	0|gmaxwell|if we're close to a releaes it might make sense to delay sending the alert itself, as that might cause a few people to upgrade... would be kinda lame to have them upgrading to a version which is outdated a week later.
478 2016-10-13 22:14:58	0|wumpus|0.10.3 added the option to disable alerts (-alerts=0)
479 2016-10-13 22:15:15	0|sipa|wow, so long already
480 2016-10-13 22:15:40	0|achow101|which releases should I mention?
481 2016-10-13 22:17:27	0|wumpus|alerts are disabled by default on the 0.11 branch, however, there has been no release after doing that
482 2016-10-13 22:18:00	0|wumpus|0.12 removed alerts completely
483 2016-10-13 22:18:31	0|wumpus|(don't know which .x yet, looking)
484 2016-10-13 22:18:57	0|achow101|I thought only 0.13 had alerts actually removed
485 2016-10-13 22:21:11	0|gmaxwell|for the purpose of that message, disabled is probably the right milestone. Doesn't really matter to the user if the code is there but dead.
486 2016-10-13 22:21:39	0|wumpus|achow101: yes, you are right, had the 0.13 branch checkout out in my 0.12 repo for some reason, it is only disabled
487 2016-10-13 22:22:16	0|wumpus|but as gmaxwell says disabled is enough
488 2016-10-13 22:22:30	0|achow101|so 0.10.3, 0.11.x, and 0.12.x allows disabling with -alerts=0
489 2016-10-13 22:22:53	0|gmaxwell|question is where was it disabled by default first?
490 2016-10-13 22:23:02	0|wumpus|0.10.3 and 0.11.* has it enabled by default but allows disabling
491 2016-10-13 22:23:15	0|wumpus|yes
492 2016-10-13 22:24:02	0|wumpus|0.12.1 has it disabled by default
493 2016-10-13 22:24:04	0|wumpus|0.12.0 hasn't
494 2016-10-13 22:24:10	0|gmaxwell|seqeunce < spelling
495 2016-10-13 22:24:56	0|gmaxwell|As far as the final alert, I think we'd actually do it shortly prior to 0.14's RC phase?  so that we could hardcode it in to be given to older peers.
496 2016-10-13 22:25:04	0|achow101|Should I include other software that has removed alerts
497 2016-10-13 22:26:18	0|gmaxwell|What I would put is something stating that as far as we're aware all currently maintained implementations have removed alerts.
498 2016-10-13 22:26:37	0|wumpus|yes, 0.14.0 should hardcode the final alert
499 2016-10-13 22:27:40	0|achow101|made changes, gtg
500 2016-10-13 22:27:43	0|wumpus|indeed - there may be some altcoins that have literally copied the alert key, but that's not releavant to this message
501 2016-10-13 22:27:52	0|achow101|i'll be back in ~1 hr
502 2016-10-13 22:27:57	0|wumpus|later achow101
503 2016-10-13 22:28:47	0|gmaxwell|wumpus: there were a few but IIRC I didn't find any that were non-dead... and I attempted to contact all the ones I found.
504 2016-10-13 22:28:57	0|gmaxwell|there were a LOT more that copied litecoin's key.
505 2016-10-13 22:29:02	0|gmaxwell|like hundreds of them
506 2016-10-13 22:29:37	0|petertodd|achow101: ACK
507 2016-10-13 22:29:41	0|wumpus|yes the non-dead altcoins I've looked at also have a different key, didn't compare against the litecoin one :)
508 2016-10-13 22:31:34	0|wumpus|but it sounds sensible to me, most altcoins descent from litecoin, or the 'PoS' coins after that, not bitcoin directly
509 2016-10-13 22:33:50	0|sipa|anyone tried a gothib search for the alert key?
510 2016-10-13 22:33:54	0|sipa|eh, github
511 2016-10-13 22:33:56	0|gmaxwell|yes
512 2016-10-13 22:34:07	0|sipa|how did i manage to get two typos in one word?
513 2016-10-13 22:34:22	0|wumpus|github search is pretty crappy, I'm amazed that worked :) I did  a google search though.
514 2016-10-13 22:34:53	0|gmaxwell|sipa: jsmf ,ods;ohm,rmt.
515 2016-10-13 22:35:07	0|gmaxwell|I didn't say it was useful, I said I tried it.
516 2016-10-13 22:35:08	0|gmaxwell|:)
517 2016-10-13 22:35:18	0|gmaxwell|the openhub code search thing was more useful.
518 2016-10-13 22:36:53	0|wumpus|in any case they *too* are better off with the key being phased out,and the final alert being sent
519 2016-10-13 22:37:30	0|wumpus|it makes no sense for us to be able to send alerts on random altcoin networks
520 2016-10-13 22:37:47	0|gmaxwell|I think it makes lots of sense.
521 2016-10-13 22:37:49	0|gmaxwell|muhahah.
522 2016-10-13 22:38:16	0|wumpus|yes :-)
523 2016-10-13 22:38:51	0|wumpus|<trollface>
524 2016-10-13 22:46:09	0|musalbas|re: checkpointing - is there anything in Bitcoin consensus to prevent someone from going back 2048 blocks to a much lower difficulty, and then doing a 51% attack from there to get the longest chain? I think I must be missing a subtle consensus rule here
525 2016-10-13 22:46:39	0|gmaxwell|you are
526 2016-10-13 22:46:57	0|gmaxwell|Bitcoin's best chain selection is not 'most blocks', it's 'most work'.
527 2016-10-13 22:47:05	0|musalbas|ahh
528 2016-10-13 22:47:19	0|gmaxwell|though this was originally wrong, and it's wrong in the whitepaper, and there is no real way to update it-- so a lot of people aren't aware.
529 2016-10-13 22:47:31	0|gmaxwell|but it's been 'most work' since some time in 2010.
530 2016-10-13 22:47:59	0|musalbas|well that clears up many shower thoughts of mine.
531 2016-10-13 22:48:40	0|gmaxwell|(it was fixed around the same time that bitcoin first moved off the minimum difficulty)
532 2016-10-13 22:53:05	0|wumpus|maybe it would make sense to publish an 'errata' to the whitepaper
533 2016-10-13 22:53:58	0|sipa|wumpus: you'll get lynched...
534 2016-10-13 22:54:01	0|gmaxwell|lol
535 2016-10-13 22:54:24	0|musalbas|it will be like trying to modify the bible for many
536 2016-10-13 22:54:40	0|gmaxwell|so you might not be aware, but cobra proposed putting up an updated whitepaper on bitcoin.org with varrious errata and it started a week long lynchmob thing. OMG YOU CHALLENGED THE HOLY WORD.
537 2016-10-13 22:55:24	0|gmaxwell|nevermind that it's wrong in a few places, and we've learned _a lot_ about teaching people about Bitcoin since 2008.
538 2016-10-13 22:56:58	0|wumpus|oh I'd like to change the bible as well... </s>
539 2016-10-13 22:57:40	0|kanzure|all of them?
540 2016-10-13 22:58:51	0|wumpus|I think most oppositiion exists to changing the whitepaper, on the original URL, itself. Releaseing an updated version as long as it's clear that it's an updated version may run into less opposition. But I dunno, some people are pretty close to extremism
541 2016-10-13 22:58:54	0|musalbas|you can't update the bible. there are too many bible book nodes around the world, it's immutable
542 2016-10-13 22:59:37	0|wumpus|never mess with the satoshi cults...
543 2016-10-13 22:59:43	0|kanzure|was there anyone offering to do the legwork on a bitcoin core whitepaper?
544 2016-10-13 23:00:16	0|sipa|i don't think it's a good topic for a whitepaper
545 2016-10-13 23:00:24	0|sipa|maybe some subsystems could use one
546 2016-10-13 23:00:29	0|kanzure|well maybe i have the color wrong
547 2016-10-13 23:00:43	0|sipa|how about a black paper?
548 2016-10-13 23:01:01	0|wumpus|yes! much better
549 2016-10-13 23:01:16	0|musalbas|a black paper would waste lots of ink; you don't want critics to accuse bitcoin of using lots of energy as well as ink now
550 2016-10-13 23:01:18	0|wumpus|or a purplepaper
551 2016-10-13 23:01:25	0|sipa|we should check with dark coin
552 2016-10-13 23:01:35	0|sipa|maybe they have prior art
553 2016-10-13 23:02:03	0|wumpus|Amir's revenge?
554 2016-10-13 23:02:59	0|wumpus|darker than dark wallet
555 2016-10-13 23:04:16	0|musalbas|scientists have developed a new colour darker than black called 'super black', so it' spossible: http://newatlas.com/vantablack-super-black-material/33011/
556 2016-10-13 23:04:31	0|wumpus|infrablack
557 2016-10-13 23:04:34	0|gmaxwell|I have access to a high power pulsed laser so we can make superblack.
558 2016-10-13 23:05:15	0|gmaxwell|black on black won't be readable, but no one was going to read it anyways.
559 2016-10-13 23:05:25	0|wumpus|a hyperblock
560 2016-10-13 23:06:19	0|wumpus|yes, no matter how much energy would go into creating it, one would read it anyway
561 2016-10-13 23:08:05	0|sipa|so we are no longer restricted to a blockchain, but could use a blackchain?
562 2016-10-13 23:08:15	0|sipa|we need to combine that with rainbow tables
563 2016-10-13 23:09:37	0|wumpus|if we're no longer restricted to whitelisting, I'd prefer rainbowlisting
564 2016-10-13 23:10:42	0|gmaxwell|thats good because rainbows don't include black.
565 2016-10-13 23:11:45	0|petertodd|gmaxwell: additive color rainbows do
566 2016-10-13 23:12:03	0|gmaxwell|sipa: back to work; is there any real reason that we couldn't just make all inbound connections one 'group' for the purpose of relay... it would slow relay down some, but really throughly kill that information leak.
567 2016-10-13 23:14:03	0|sipa|do you mean let all of them use the same timing for relay?
568 2016-10-13 23:14:44	0|gmaxwell|yes.
569 2016-10-13 23:15:00	0|gmaxwell|oh hmp. my own concern with that is it makes the traffic more bursty.
570 2016-10-13 23:15:12	0|sipa|it would worsen spikyness of relay memory
571 2016-10-13 23:15:33	0|sipa|right, and memory usage too
572 2016-10-13 23:15:59	0|gmaxwell|the memory usage should be trivial, the transactions are shared, so the usage is just pointers.
573 2016-10-13 23:19:36	0|sipa|it's a set of txids
574 2016-10-13 23:19:46	0|sipa|not shared_ptrs
575 2016-10-13 23:20:01	0|gmaxwell|pointer, txid, same difference. you're not on a 256 computer yet?
576 2016-10-13 23:20:24	0|gmaxwell|I suppose inbound could be assigned to 4 groups or 8 groups based on a hash of their netgroup. ... and that would give a lot of burst mitigation while bounding the attack upside.
577 2016-10-13 23:21:26	0|gmaxwell|(salted hash)
578 2016-10-13 23:21:37	0|sipa|i think we could turn them into weak_ptr's to CTransactions, thougg
579 2016-10-13 23:22:23	0|gmaxwell|well we could replace this datastructure per peer to a single queue, with a bitmap that has a bit per peer.
580 2016-10-13 23:23:20	0|gmaxwell|(or better, an efficiently encoded bitmap... I guess there is no STL container that works like a judy1.
581 2016-10-13 23:23:23	0|gmaxwell|)
582 2016-10-13 23:27:49	0|achow101|i'm back
583 2016-10-13 23:30:27	0|achow101|should I submit a PR for the alert or will someone with commit access to bitcoin.org sign and push the commit?
584 2016-10-13 23:30:34	0|GitHub184|[13bitcoin] 15luke-jr opened pull request #8918: Qt: Add "Copy URI" to payment request context menu (06master...06gui_req_copy_uri) 02https://github.com/bitcoin/bitcoin/pull/8918
585 2016-10-13 23:32:08	0|gmaxwell|PR. none of us have commit access in any case, AFAIK-- and we wouldn't skip review. :)
586 2016-10-13 23:32:13	0|gmaxwell|a PR is fine.
587 2016-10-13 23:32:43	0|achow101|supposedly wumpus does: https://github.com/bitcoin-dot-org/bitcoin.org#who-to-contact
588 2016-10-13 23:33:06	0|achow101|and the readme says "Note: the commit must be signed by one of the people in the Who to Contact section for site auto-building to work." which is why I asked
589 2016-10-13 23:35:22	0|achow101|done: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1392
590 2016-10-13 23:39:58	0|wumpus|a PR is good, I have commit access to be able to do emergency bitcoin core releases