1 2018-05-17 00:25:20	0|fanquake|Now that 18.04 is available for WSL I think we might now have a somewhat sane build process for windows users.
  2 2018-05-17 01:13:22	0|fanquake|Scratch that. Half sure that a depends build just crashed VirtualBox..
  3 2018-05-17 02:02:33	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13251: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default (06master...06rephrase-bech-32) 02https://github.com/bitcoin/bitcoin/pull/13251
  4 2018-05-17 02:03:13	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #12208: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default (06master...06gui_legacy_bech32) 02https://github.com/bitcoin/bitcoin/pull/12208
  5 2018-05-17 02:08:05	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13252: Wallet: Refactor ReserveKeyFromKeyPool for safety (06master...06refactor_wallet_RKFKP) 02https://github.com/bitcoin/bitcoin/pull/13252
  6 2018-05-17 02:09:25	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9537: Wallet: Refactor ReserveKeyFromKeyPool for safety (06master...06refactor_wallet_RKFKP) 02https://github.com/bitcoin/bitcoin/pull/9537
  7 2018-05-17 02:27:50	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13253: [0.16] Further Backports (060.16...060-16-further-backports) 02https://github.com/bitcoin/bitcoin/pull/13253
  8 2018-05-17 02:30:11	0|fanquake|Going to drop the "Needs Backport" label off the PRs in 13253 so we can get a good idea of what's left.
  9 2018-05-17 03:12:46	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13254: Revert "Merge #12870: make clean removes src/qt/moc_ files" (06master...06make-clean-qt-moc) 02https://github.com/bitcoin/bitcoin/pull/13254
 10 2018-05-17 03:38:45	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13255: trivial: Fixed typos and cleaned up language (06master...06language-cleanup) 02https://github.com/bitcoin/bitcoin/pull/13255
 11 2018-05-17 03:39:21	0|fanquake|^ Can either be merged quickly or closed for now.
 12 2018-05-17 03:39:25	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #13010: Trivial: Language Cleanup (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/13010
 13 2018-05-17 03:43:56	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10708: Connecttrace fewer blocks (06master...06connecttrace-fewer-blocks) 02https://github.com/bitcoin/bitcoin/pull/10708
 14 2018-05-17 03:44:43	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10470: Fix for listsinceblock not filtering conflicted transactions (06master...06listsinceblock-filter-conflicts) 02https://github.com/bitcoin/bitcoin/pull/10470
 15 2018-05-17 03:45:35	0|fanquake|Added "Up for Grabs" labels to both of those, no updates to either for 6moths and nearly a year.
 16 2018-05-17 03:47:27	0|kallewoof|fanquake: Yeah, if no reaction even with feedback I think closing is ok. I don't think we should close PR's just because they lie around though. I mean, I have PRs that I am maintaining, with no feedback, that can lie around for months and months. Doesn't mean they should be closed. :)
 17 2018-05-17 03:48:36	0|kallewoof|I do think generally we should say 'Close this?' and let the author have a say before closing, since non-maintainers can't reopen their PRs even if they wanted to.
 18 2018-05-17 03:49:20	0|kallewoof|I.e. let the authors have an opportunity to close the PR themselves in case they wanna come back to it when they have more time/energy/inspiration.
 19 2018-05-17 04:06:23	0|fanquake|kallewoof sure. I have to run out but will comment when I'm back
 20 2018-05-17 04:08:30	0|kallewoof|fanquake: No worries, just idly musing.
 21 2018-05-17 05:03:09	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13257: wallet: Fix ReserveKeyFromKeyPool to always test key classification, even if last in the pool.  (06master...06fix-reserve-key-classification-check) 02https://github.com/bitcoin/bitcoin/pull/13257
 22 2018-05-17 05:05:39	0|bitcoin-git|[13bitcoin] 15Empact closed pull request #13257: wallet: Fix ReserveKeyFromKeyPool to always test key classification, even if last in the pool.  (06master...06fix-reserve-key-classification-check) 02https://github.com/bitcoin/bitcoin/pull/13257
 23 2018-05-17 05:10:31	0|Bonney|0xC0D332838f14EF42Fcde1cf2518c427dDB676729
 24 2018-05-17 05:32:07	0|wumpus|BlueMatt: yes, going to untag the fds one at least
 25 2018-05-17 05:32:37	0|wumpus|ones*
 26 2018-05-17 05:33:01	0|wumpus|oh, that's all that is left besides backports, right
 27 2018-05-17 05:53:23	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #13258: uint256: Remove unnecessary crypto/common.h use (alternative) (06master...06uint256-no-crypto-alt) 02https://github.com/bitcoin/bitcoin/pull/13258
 28 2018-05-17 06:40:51	0|fanquake|wumpus I've sorted out a few. There's a couple that should be backported in individual PRs though I think.
 29 2018-05-17 07:02:46	0|bitcoin-git|[13bitcoin] 15kallewoof closed pull request #13242: uint256: Remove unnecessary crypto/common.h use (06master...06uint256-no-crypto) 02https://github.com/bitcoin/bitcoin/pull/13242
 30 2018-05-17 07:31:06	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #13259: validation: add a macro for determining if a block is pruned or not (06master...06block-pruned-macro) 02https://github.com/bitcoin/bitcoin/pull/13259
 31 2018-05-17 08:13:36	0|wumpus|fanquake: thanks, I'll do some review on backports today
 32 2018-05-17 11:56:03	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #13262: Wallet/RPC: Add listsincetx with a stateless (server-side) long polling option (06master...062018/05/listsincetx) 02https://github.com/bitcoin/bitcoin/pull/13262
 33 2018-05-17 14:39:03	0|bitcoin-git|[13bitcoin] 15GreatSock opened pull request #13264: [qt] Satoshi unit (06master...06satoshis) 02https://github.com/bitcoin/bitcoin/pull/13264
 34 2018-05-17 16:05:51	0|promag|fyi can't attend meeting today
 35 2018-05-17 16:09:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4cfe17c3382b...ef0e5cd5174c
 36 2018-05-17 16:09:49	0|bitcoin-git|13bitcoin/06master 147ab1c6f 15Luke Dashjr: GUI: Rephrase Bech32 checkbox text/tooltip...
 37 2018-05-17 16:09:49	0|bitcoin-git|13bitcoin/06master 1482dda6b 15Luke Dashjr: GUI: Allow generating Bech32 addresses with a legacy-address default
 38 2018-05-17 16:09:50	0|bitcoin-git|13bitcoin/06master 14ef0e5cd 15MarcoFalke: Merge #13251: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default...
 39 2018-05-17 16:10:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13251: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default (06master...06rephrase-bech-32) 02https://github.com/bitcoin/bitcoin/pull/13251
 40 2018-05-17 16:30:08	0|bitcoin-git|13bitcoin/06master 1484f4194 15Chun Kuan Lee: break circular dependency: random/sync -> util -> random/sync
 41 2018-05-17 16:30:08	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ef0e5cd5174c...1b53e4f67c6d
 42 2018-05-17 16:30:09	0|bitcoin-git|13bitcoin/06master 141b53e4f 15MarcoFalke: Merge #13236: break circular dependency: random/sync -> util -> random/sync...
 43 2018-05-17 16:30:58	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13236: break circular dependency: random/sync -> util -> random/sync (06master...06random_util) 02https://github.com/bitcoin/bitcoin/pull/13236
 44 2018-05-17 17:33:09	0|promag|will trade reviews =) #13097
 45 2018-05-17 17:33:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/13097 | ui: Support wallets loaded dynamically by promag · Pull Request #13097 · bitcoin/bitcoin · GitHub
 46 2018-05-17 18:33:02	0|jonasschnelli|promag: you can remove the description part where it says "builds on top of" in 13097
 47 2018-05-17 18:33:15	0|promag|ok
 48 2018-05-17 18:33:22	0|promag|ty
 49 2018-05-17 18:33:32	0|jonasschnelli|will review
 50 2018-05-17 18:35:07	0|promag|thanks!
 51 2018-05-17 18:35:40	0|promag|https://github.com/bitcoin/bitcoin/projects/2 needs update
 52 2018-05-17 18:59:45	0|sipa|meeting?
 53 2018-05-17 18:59:48	0|lightningbot|Meeting started Thu May 17 19:00:35 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 54 2018-05-17 18:59:48	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 55 2018-05-17 18:59:48	0|wumpus|#startmeeting
 56 2018-05-17 18:59:50	0|jonasschnelli|hi
 57 2018-05-17 18:59:53	0|sipa|hi
 58 2018-05-17 18:59:54	0|promag|hi
 59 2018-05-17 18:59:55	0|jamesob|howdy
 60 2018-05-17 19:00:23	0|wumpus|#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 jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
 61 2018-05-17 19:00:32	0|kanzure|hi.
 62 2018-05-17 19:01:00	0|wumpus|proposed topics: 0.16.1 I guess
 63 2018-05-17 19:01:03	0|jimpo|hi
 64 2018-05-17 19:01:04	0|cfields|hi
 65 2018-05-17 19:01:32	0|wumpus|#topic High priority for review
 66 2018-05-17 19:01:43	0|sipa|i'd like to add #13142
 67 2018-05-17 19:01:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/13142 | Separate IsMine from solvability by sipa · Pull Request #13142 · bitcoin/bitcoin · GitHub
 68 2018-05-17 19:02:26	0|wumpus|we merged #10740 this week, #12254 #10757 #13011 #13097 #12979 #12634 are left
 69 2018-05-17 19:02:28	0|jnewbery|hello
 70 2018-05-17 19:02:28	0|jonasschnelli|I'd like to add #12196
 71 2018-05-17 19:02:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
 72 2018-05-17 19:02:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
 73 2018-05-17 19:02:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
 74 2018-05-17 19:02:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/13011 | Cache witness hash in CTransaction by MarcoFalke · Pull Request #13011 · bitcoin/bitcoin · GitHub
 75 2018-05-17 19:02:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/13097 | ui: Support wallets loaded dynamically by promag · Pull Request #13097 · bitcoin/bitcoin · GitHub
 76 2018-05-17 19:02:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into parallel validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
 77 2018-05-17 19:02:49	0|wumpus|there's quite a lot of things on the list yet, should we also remove something?
 78 2018-05-17 19:02:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/12634 | [refactor] Make TransactionWithinChainLimit more flexible by kallewoof · Pull Request #12634 · bitcoin/bitcoin · GitHub
 79 2018-05-17 19:02:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
 80 2018-05-17 19:03:13	0|BlueMatt|#13011 looks merge-ableish
 81 2018-05-17 19:03:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/13011 | Cache witness hash in CTransaction by MarcoFalke · Pull Request #13011 · bitcoin/bitcoin · GitHub
 82 2018-05-17 19:03:22	0|jtimon|hi
 83 2018-05-17 19:03:40	0|BlueMatt|I dunno if #12254 should stay on there, there's now discussion of the bip on the ml so its gonna be some time yet, I think
 84 2018-05-17 19:03:43	0|BlueMatt|jimpo: thoughts?
 85 2018-05-17 19:03:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
 86 2018-05-17 19:03:53	0|jonasschnelli|What is the maxlen for high-prio-list?
 87 2018-05-17 19:04:01	0|BlueMatt|1 per regular contributor :p
 88 2018-05-17 19:04:07	0|wumpus|ok added #12196 #13142
 89 2018-05-17 19:04:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
 90 2018-05-17 19:04:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/13142 | Separate IsMine from solvability by sipa · Pull Request #13142 · bitcoin/bitcoin · GitHub
 91 2018-05-17 19:04:15	0|jonasschnelli|Thanks wumpus
 92 2018-05-17 19:04:22	0|jonasschnelli|Agree with BlueMatt about 12254
 93 2018-05-17 19:04:29	0|wumpus|yes, what BlueMatt says, though PRs that are not actively updated should be removed
 94 2018-05-17 19:05:00	0|wumpus|agree, removed 12254
 95 2018-05-17 19:05:17	0|jtimon|I was expecting https://github.com/bitcoin/bitcoin/pull/10757 to be merged soonish and thus go out of the list
 96 2018-05-17 19:05:28	0|BlueMatt|topic: 0.16.1
 97 2018-05-17 19:05:29	0|promag|and I guess 13097 can be merged after jonasschnelli review
 98 2018-05-17 19:05:30	0|wumpus|something that is still being discussed on the mailing list certainly doesn't belong in the blocker slist
 99 2018-05-17 19:05:48	0|jonasschnelli|Yes. 13097 is in review here...
100 2018-05-17 19:05:55	0|jimpo|Can I get #13243 then so progress continues? :-)
101 2018-05-17 19:05:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/13243 | Make reusable base class for auxiliary indices by jimpo · Pull Request #13243 · bitcoin/bitcoin · GitHub
102 2018-05-17 19:06:01	0|MarcoFalke|#12979 needs a rebase
103 2018-05-17 19:06:02	0|sipa|sgtm
104 2018-05-17 19:06:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into parallel validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
105 2018-05-17 19:06:11	0|BlueMatt|MarcoFalke: yup, doing now
106 2018-05-17 19:06:24	0|BlueMatt|i was waiting on sdaftuar's review so I could take nits at the same time
107 2018-05-17 19:06:48	0|jonasschnelli|unicorn for 10757
108 2018-05-17 19:06:53	0|sipa|great.
109 2018-05-17 19:06:58	0|BlueMatt|topic: replacing github
110 2018-05-17 19:07:03	0|jonasschnelli|heh
111 2018-05-17 19:07:03	0|promag|wumpus: fyi 13063 on high priority after 13097 merge
112 2018-05-17 19:07:25	0|BlueMatt|topic: replacing github (not entirely unserious)
113 2018-05-17 19:07:30	0|jonasschnelli|don't make queues for highprio list. :)
114 2018-05-17 19:07:40	0|wumpus|promag: you already have one on the list!
115 2018-05-17 19:08:08	0|promag|wumpus: right, after 13097 merge
116 2018-05-17 19:08:18	0|wumpus|due to the length of the list I'm going to have to enforce one PR per person, sorry
117 2018-05-17 19:08:42	0|wumpus|#topic 0.16.1
118 2018-05-17 19:08:57	0|BlueMatt|huh? we always enforce one per person (well, one nomination per person, you can nominate someone elses')
119 2018-05-17 19:09:07	0|BlueMatt|I think we just need to finish backports and tag for 0.16.1rc1, no?
120 2018-05-17 19:09:12	0|wumpus|mostly #13253
121 2018-05-17 19:09:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/13253 | [0.16] Further Backports by fanquake · Pull Request #13253 · bitcoin/bitcoin · GitHub
122 2018-05-17 19:09:37	0|wumpus|BlueMatt: we had multiple theuni PRs on there at some point :)
123 2018-05-17 19:09:48	0|BlueMatt|well those got removed, and cfields confirmed that was ok
124 2018-05-17 19:10:40	0|wumpus|there's also three issues marked 0.16.1: #13110 #12646 #12337
125 2018-05-17 19:10:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/13110 | 0.16.0 bitcoin-qt: "Assertion `copyFrom failed" during launch · Issue #13110 · bitcoin/bitcoin · GitHub
126 2018-05-17 19:10:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/12646 | Assertion failure during rescan · Issue #12646 · bitcoin/bitcoin · GitHub
127 2018-05-17 19:10:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
128 2018-05-17 19:10:57	0|wumpus|not sure whether they are critical or can just be bumped to 0.16.2 or so
129 2018-05-17 19:11:09	0|sipa|we have one issue marked 0.15.2 which i don't understand
130 2018-05-17 19:11:51	0|wumpus|I don't know either, but at least that's not a blocker for 0.16.1
131 2018-05-17 19:11:52	0|BlueMatt|jonasschnelli: was the last to comment on 12337 " I'll try to find a solution for this..."
132 2018-05-17 19:11:55	0|MarcoFalke|wumpus: The assertion is a regression if I am not mistaken
133 2018-05-17 19:12:04	0|MarcoFalke|13110
134 2018-05-17 19:12:17	0|MarcoFalke|wasn't 12337 fixed?
135 2018-05-17 19:12:23	0|jonasschnelli|Will look into 12337...
136 2018-05-17 19:12:36	0|wumpus|I proposed a fix in 13110 and it apparently worked
137 2018-05-17 19:12:54	0|cfields|yes
138 2018-05-17 19:13:20	0|jonasschnelli|wumpus: can you PR https://github.com/bitcoin/bitcoin/issues/13110#issuecomment-385708583?
139 2018-05-17 19:13:34	0|wumpus|jonasschnelli: sure
140 2018-05-17 19:15:04	0|wumpus|so that leaves 12646
141 2018-05-17 19:16:11	0|jonasschnelli|maybe jnewbery can look into 12646?
142 2018-05-17 19:16:22	0|wumpus|anyone want to look int othat? or can we just bump it forward if it's not so importent
143 2018-05-17 19:16:55	0|jonasschnelli|I think its okay to bump this forward (as long as we track it)
144 2018-05-17 19:17:09	0|wumpus|yes I don't mean closing it
145 2018-05-17 19:17:21	0|jnewbery|Yes, I can look at 12646 (next week)
146 2018-05-17 19:18:15	0|wumpus|moved to 0.16.2
147 2018-05-17 19:18:34	0|wumpus|other proposed topics?
148 2018-05-17 19:18:40	0|BlueMatt|trashing github
149 2018-05-17 19:18:48	0|wumpus|#topic Trashing github
150 2018-05-17 19:18:58	0|BlueMatt|so it hasnt been working for like 3 weeks now
151 2018-05-17 19:19:14	0|BlueMatt|and I'd kinda like to have something self-hosted with better review tools anyway, which I know a lot of people wanted
152 2018-05-17 19:19:24	0|jonasschnelli|Should we give it more time?... I'm pretty sure they are aware of it
153 2018-05-17 19:19:26	0|sipa|there was some suggestiin (was it on twitter) to use gitlab
154 2018-05-17 19:19:41	0|BlueMatt|so I figured we should do a "do people think its actually a good idea to switch to something self-hosted" semi-poll
155 2018-05-17 19:19:46	0|BlueMatt|or we could switch to gitlab
156 2018-05-17 19:19:46	0|wumpus|gitlab seems ok
157 2018-05-17 19:19:52	0|jonasschnelli|BlueMatt: what alternatives would you propose?
158 2018-05-17 19:19:55	0|jtimon|I like gitlab
159 2018-05-17 19:19:57	0|sdaftuar|seems to me like it's way harder to get it right hosting ourselves
160 2018-05-17 19:19:59	0|BlueMatt|though gitlab seems to have no better review tools than github
161 2018-05-17 19:20:07	0|wumpus|self-hosted I don't know, who is going to babysit this, monitor it and apply security patches etc?
162 2018-05-17 19:20:09	0|BlueMatt|sdaftuar: oh? I mean I kinda disagree
163 2018-05-17 19:20:09	0|sipa|it would  e really cool if all pr comment history was in git too
164 2018-05-17 19:20:19	0|sdaftuar|dude we can't even keep the computers in our office running
165 2018-05-17 19:20:22	0|jamesob|self-hosted is very risky and potentially time-consumptive IMO
166 2018-05-17 19:20:23	0|BlueMatt|sipa: does gitlab do that?
167 2018-05-17 19:20:29	0|BlueMatt|sdaftuar: bitcoincore.org does just fine....
168 2018-05-17 19:20:30	0|sipa|BlueMatt: i have no clue
169 2018-05-17 19:20:38	0|wumpus|if no one is, it's going to become worse, not better, at least Github has a dedicated paid team
170 2018-05-17 19:20:48	0|sdaftuar|definitely agree with wumpus
171 2018-05-17 19:20:49	0|cfields|general nack, self-hosting issues aside, Github's network effect is too strong imo.
172 2018-05-17 19:20:51	0|sipa|blockstream uses gitlab internally, which seems to work fine (pribably due to people maintaining it)
173 2018-05-17 19:21:06	0|BlueMatt|i mean we could do self-hosted gitlab
174 2018-05-17 19:21:30	0|MarcoFalke|what advantage does that give, BlueMatt?
175 2018-05-17 19:21:50	0|jtimon|I assume the goal is less unicorns?
176 2018-05-17 19:21:53	0|jnewbery|cfields: +1
177 2018-05-17 19:22:04	0|wumpus|someone from github promised to look into the unicorn issue, maybe we should give them some more time
178 2018-05-17 19:22:05	0|MarcoFalke|gitlab also does hostign for free
179 2018-05-17 19:22:11	0|jimpo|Cursory internet search turned up reviewable.io, which is like a hosted layer on top of GitHub
180 2018-05-17 19:22:14	0|sipa|jnewbery, cfields: what do you suggest instead? waiting until github fixes it?
181 2018-05-17 19:22:18	0|jimpo|free for public repos
182 2018-05-17 19:22:20	0|BlueMatt|MarcoFalke: we can do our own security additions like putting the pr and comment history in git
183 2018-05-17 19:22:25	0|cfields|I can't be the only one who gets irrationally frustrated when the code I want to mess with is on BitBucket..
184 2018-05-17 19:22:27	0|BlueMatt|and have stuff that verifies it
185 2018-05-17 19:22:46	0|sipa|cfields: we'd mirror on github of course
186 2018-05-17 19:22:51	0|jnewbery|In the absence of something better, we should continue nagging them
187 2018-05-17 19:23:06	0|wumpus|cfields: yes, only players like freedesktop can really afford to host on separate infrastructure, for smaller projects the lack of network effect (and having to register separately) is bad
188 2018-05-17 19:23:16	0|cfields|sipa: all things considered, yes, I'd say waiting it out makes the most sense.
189 2018-05-17 19:23:30	0|BlueMatt|jnewbery: I think we *do* have ideas for better things
190 2018-05-17 19:23:34	0|cfields|I think I'm in the minority there, though :)
191 2018-05-17 19:23:34	0|jonasschnelli|Moving away from GitHub seems meh,... especially for a self-hostes solutions... looks after centralizing development
192 2018-05-17 19:23:37	0|jimpo|Who has reached out to GitHub and through what channel so far?
193 2018-05-17 19:23:38	0|BlueMatt|the self-hosting question is more a "will it be maintained" question
194 2018-05-17 19:23:42	0|BlueMatt|not "will it be better"
195 2018-05-17 19:23:46	0|jtimon|I'm ok with both people working on a gitlab instance and people nagging github devs
196 2018-05-17 19:23:50	0|sipa|cfields: i'moretty unconfortable with the fact that network effect is making us stick with a specific provider, even in the oresence of obvious issies
197 2018-05-17 19:24:15	0|sipa|of course, it's not like we could migrate quickly anyway
198 2018-05-17 19:24:18	0|wumpus|'will it be maintained' is really important though to not end up blaming each other
199 2018-05-17 19:24:19	0|jamesob|how much effort will, e.g., DoS protection be for something self-hosted?
200 2018-05-17 19:24:29	0|wumpus|at least now we can blame github people :)
201 2018-05-17 19:24:33	0|jtimon|we could perhaps save money on travis workers by using gitlab-CI too?
202 2018-05-17 19:24:33	0|sipa|haha
203 2018-05-17 19:24:57	0|wumpus|jamesob: exactly...
204 2018-05-17 19:25:00	0|BlueMatt|jamesob: dos protection is 6$/month
205 2018-05-17 19:25:03	0|BlueMatt|and works perfectly
206 2018-05-17 19:25:04	0|cfields|sipa: it's worth considering that the 0.16.1 issues might've never been reported if not for Github's issues
207 2018-05-17 19:25:24	0|jnewbery|BlueMatt: Yes, we have ideas, but that's different from something that's actually running. I don't have any interest in maintaining a self-hosted solution, and I don't think it's worth anyone else's time doing it either
208 2018-05-17 19:25:29	0|sipa|cfields: that's a good point
209 2018-05-17 19:25:45	0|wumpus|we could still use github for *issues*
210 2018-05-17 19:25:51	0|wumpus|gitlab would be for patches and review
211 2018-05-17 19:26:01	0|jtimon|jnewbery: yeah, I'm personally not interested in maintaining it either
212 2018-05-17 19:26:08	0|wumpus|doesn't necessarily need to be the same place
213 2018-05-17 19:26:36	0|sipa|let's move back to sourceforge
214 2018-05-17 19:26:38	0|BlueMatt|I'm not a fan of using issues and patches/review being in separate places
215 2018-05-17 19:26:38	0|wumpus|yes tbh I don't think we should change the issue reporting URL
216 2018-05-17 19:26:48	0|wumpus|I've been spamming that to so many people over the years
217 2018-05-17 19:26:49	0|jamesob|BlueMatt: I don't think CloudFlare works with git protocol, so you need to reveal underlying IPs: https://stackoverflow.com/questions/31817004/git-push-not-working-after-using-cloudflare-reverse-proxy
218 2018-05-17 19:26:51	0|jonasschnelli|if the unicorns is the showstopper, then better mirror github PR with comments > 20 via API with comment through API function
219 2018-05-17 19:26:58	0|jtimon|or just everything on gitlab, but since we have the github mirror, we will see issues created there by people who missed that the project moved
220 2018-05-17 19:27:01	0|wumpus|I don't really want to move it anywhere else. THe unicorns are only an issue for code review.
221 2018-05-17 19:27:07	0|BlueMatt|jamesob: bitcoincore.org does not use cloudflare (and costs 6$/month), cloudflare sucks ass
222 2018-05-17 19:27:08	0|jnewbery|I also think that the network effect thing is important. What percentage of new contributors/issue reports would we lose if we weren't on github?
223 2018-05-17 19:27:23	0|BlueMatt|jamesob: (and that's for redundant providers)
224 2018-05-17 19:27:54	0|BlueMatt|jonasschnelli: I'd actually be much happier with github if we had a client-side api-based cli-only github interface
225 2018-05-17 19:28:04	0|BlueMatt|(that verified eg pgp signatures on comments)
226 2018-05-17 19:28:05	0|wumpus|there is a github cli interface
227 2018-05-17 19:28:07	0|jtimon|wumpus: well the main point of using github is for code review, no?
228 2018-05-17 19:28:09	0|kanzure|email seems to work for long reviews (diffs)
229 2018-05-17 19:28:21	0|jonasschnelli|BlueMatt: that seems easyer then installing a gitlab solution on a custom server
230 2018-05-17 19:28:34	0|jonasschnelli|*easier
231 2018-05-17 19:28:40	0|BlueMatt|jonasschnelli: its the difference between building a whole app and installing one
232 2018-05-17 19:28:42	0|BlueMatt|so...no, not really
233 2018-05-17 19:28:43	0|jimpo|jnewberry: Who has reached out to GitHub and through what channel so far?
234 2018-05-17 19:28:45	0|moneyball|I am happy to follow-up with GitHub to try and accelerate a fix. Can someone provide me background info on the existing communication we have with GitHub?
235 2018-05-17 19:29:01	0|jnewbery|I've contacted Github support. I don't know who else has
236 2018-05-17 19:29:11	0|jtimon|I think someone reached to them on twitter too
237 2018-05-17 19:29:14	0|wumpus|I have contacted them through tthe contact site, and was told by support that many others have
238 2018-05-17 19:29:18	0|moneyball|Is there an open issue # that I can reference?
239 2018-05-17 19:29:21	0|jnewbery|jtimon: that was me
240 2018-05-17 19:29:26	0|jimpo|I can try asking someone I know that used to work there supporting open source projects
241 2018-05-17 19:29:31	0|jnewbery|moneyball: I'll forward you the email thread
242 2018-05-17 19:29:35	0|BlueMatt|moneyball: a few folks have emailed support@github, which historically has always gotten a response, some other projects were posting responses they got where they were saying "we dont actually know what change we made that triggered these issues, hold on"
243 2018-05-17 19:29:38	0|BlueMatt|buts its been like 3 weeks ago
244 2018-05-17 19:30:14	0|moneyball|jnewbery ok great i'll use that as context and follow-up
245 2018-05-17 19:30:29	0|moneyball|jimpo we can coordinate our efforts if you'd like
246 2018-05-17 19:30:50	0|jimpo|yeah, we can chat about it outside the meeting
247 2018-05-17 19:31:08	0|BlueMatt|ok, so it sounds like consensus is "stick with the broken shit we have now" :/
248 2018-05-17 19:31:14	0|BlueMatt|or at least no consensus on moving to something else
249 2018-05-17 19:31:26	0|wumpus|feel fre to set up something better and convince us to use it
250 2018-05-17 19:31:39	0|sipa|yeah i believe it will require someone to set up a demo
251 2018-05-17 19:31:52	0|wumpus|if not, this is just empty talk, we *have* nothing better
252 2018-05-17 19:32:06	0|wumpus|any other topics?
253 2018-05-17 19:32:12	0|MarcoFalke|And a plan to transition all open patches to the new review system?
254 2018-05-17 19:32:14	0|sipa|right; the question is whether we should look into alternatives
255 2018-05-17 19:32:23	0|sipa|not so much whether we should or shouldn't move
256 2018-05-17 19:32:46	0|wumpus|right
257 2018-05-17 19:32:50	0|cfields|iirc some alternatives support oath login via github
258 2018-05-17 19:32:59	0|BlueMatt|yea, it seems like lack of consensus to move even if we find something good
259 2018-05-17 19:33:06	0|cfields|that would go a long way towards shutting me up
260 2018-05-17 19:33:11	0|BlueMatt|which was mostly why I brought it up
261 2018-05-17 19:33:25	0|wumpus|I'm open to being convinced to use something else, if it's really better
262 2018-05-17 19:33:51	0|jimpo|cfields: I agree a code review tool with GitHub integration (where main repo is still hosted there) is ideal
263 2018-05-17 19:34:25	0|jnewbery|BlueMatt: If there was something else better running now AND there was a way to migrate all state AND we wouldn't lose contributors by switching AND we have someone committed to maintaining it, then I'd be open to it. Without that, I think it's a non-starter.
264 2018-05-17 19:34:41	0|jonasschnelli|Something like https://github.com/piotrmurach/github_cli seems a better start to deal with the unicorns
265 2018-05-17 19:35:06	0|wumpus|jonasschnelli: yes, I plan to look into github cli commands as well, there's a few (also "hub" IIRC)
266 2018-05-17 19:35:19	0|MarcoFalke|Agree with jnewbery. I am open to switching, but not without solving the transition issues first.
267 2018-05-17 19:35:44	0|wumpus|we'd end up with parallel infrastructure for a while anyway
268 2018-05-17 19:35:47	0|jtimon|well BlueMatt I think it would be easier to get consensus to move to something else if somebody had it working with CI and all
269 2018-05-17 19:35:56	0|jnewbery|topic request: separate wallet from node (#10973)
270 2018-05-17 19:36:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
271 2018-05-17 19:36:16	0|jonasschnelli|Moving away from Github just because of load issues for three weeks seems insane...
272 2018-05-17 19:36:20	0|BlueMatt|jtimon: it sounds like definite "no", so I'm not gonna spend time looking into it
273 2018-05-17 19:36:35	0|jtimon|in the meantime, prs with many comments get the unicorn and we have to try again until it loads
274 2018-05-17 19:36:39	0|wumpus|#topic separate wallet from node (jnewbery)
275 2018-05-17 19:36:40	0|BlueMatt|jonasschnelli: there are way more reasons people dont like github
276 2018-05-17 19:36:45	0|sipa|jonasschnelli: not being able to move away from github just because of network effect seems scary...
277 2018-05-17 19:36:55	0|jamesob|the upside is that this is an additional incentive to keep PRs small :)
278 2018-05-17 19:36:58	0|jtimon|BlueMatt: fair enough
279 2018-05-17 19:37:04	0|cfields|jonasschnelli: I agree. But I think the frustration comes from the helplessness that it's brought to light.
280 2018-05-17 19:37:05	0|wumpus|this discussion is starting to repeat itself
281 2018-05-17 19:37:16	0|jonasschnelli|sipa: that is a point we should take into consideration,.. but stop focusing on load issues
282 2018-05-17 19:37:26	0|sipa|ok, next topic it seems
283 2018-05-17 19:37:51	0|BlueMatt|oh, I have 2 more topics....
284 2018-05-17 19:38:05	0|wumpus|I don't think there's realistically any chance of anything replacing github until someone sets up a feasible alternative and shows us that it is better
285 2018-05-17 19:38:07	0|sipa|jnewbery: your topic
286 2018-05-17 19:38:09	0|jonasschnelli|(#topic separate wallet from node (jnewbery))
287 2018-05-17 19:38:18	0|BlueMatt|sipa: well I'm gonna look into having a cli app that checks signatures off github api comments/etc
288 2018-05-17 19:38:22	0|jnewbery|#10973 is a big PR, but I think it's very worthwhile
289 2018-05-17 19:38:24	0|BlueMatt|cause I think that would alleviate a lot of it
290 2018-05-17 19:38:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
291 2018-05-17 19:38:37	0|jnewbery|jamesob and I have both reviewed now, but it requires continual rebase
292 2018-05-17 19:39:05	0|jnewbery|There are a lot of PRs competing for high priority for review, but I think it'd be great to make some progress on this one
293 2018-05-17 19:39:15	0|promag|place in high priority this week?
294 2018-05-17 19:39:19	0|jamesob|I'll start a round of manual testing if we can get another reviewer or two
295 2018-05-17 19:39:23	0|jimpo|can it be broken up at all?
296 2018-05-17 19:39:26	0|jnewbery|so, next steps would be: concecpt ACK/NACKs
297 2018-05-17 19:39:37	0|BlueMatt|sounds like a high-priority-for-review nomination?
298 2018-05-17 19:39:43	0|jnewbery|and if people think it's too much to review in one go, ryanofsky is happy to split
299 2018-05-17 19:39:50	0|jimpo|1500+ lines is too big IMO
300 2018-05-17 19:39:53	0|wumpus|oh no, not more high priority for review
301 2018-05-17 19:40:01	0|jonasschnelli|jnewbery: this is orthogonal of using light client mode to decouple the wallet from the node? right,... it's more architectural?
302 2018-05-17 19:40:19	0|jnewbery|jimpo: it's mostly very mechanical changes, but yes it's a large +-loc
303 2018-05-17 19:40:29	0|wumpus|is it blocking anything? is it importnat for 0.17?
304 2018-05-17 19:40:37	0|jnewbery|there are only a couple of commits that require deep review
305 2018-05-17 19:41:05	0|sipa|jnewbery: thanks for bringing it up; big PRs are sometimes unnecessarily scary to dig into
306 2018-05-17 19:41:16	0|jnewbery|wumpus: it blocks (but doesn't necessarily have to lead to) process separation
307 2018-05-17 19:41:24	0|jonasschnelli|But I guess it's hard/impossible to break it into smaller PRs
308 2018-05-17 19:41:28	0|jamesob|jonasschnelli: it makes explicit the bitcoind interface that the wallet relies on, which is in itself useful but also if we want to do any kind of process separation
309 2018-05-17 19:41:32	0|jnewbery|jonasschnelli: you're correct
310 2018-05-17 19:41:33	0|wumpus|process separation is not something we'll have for 0.17 anyway
311 2018-05-17 19:42:07	0|jnewbery|so at this stage it's more of a concept review beg from me, and a poll on whether russ should spend time splitting it up
312 2018-05-17 19:42:27	0|jimpo|I'll give it a pass by tomorrow
313 2018-05-17 19:42:51	0|jnewbery|The reason I raised it is that because of the frequent rebases, reviews go stale very quickly, and it's now had two ACKs
314 2018-05-17 19:42:54	0|jnewbery|thanks jimpo
315 2018-05-17 19:43:03	0|ryanofsky|i actually don't think it's hard to split up, first 6 commits seem to group together nicely, with rest of changes more independent
316 2018-05-17 19:43:39	0|jnewbery|that's all from me. If 2 or 3 regular reviewers are happy to concept review, I think that's good progress
317 2018-05-17 19:44:05	0|jonasschnelli|If we assume the long term goal is process separation (where the wallet will turn into a pure transaction-filtering-thinkg), isn't it, that the coin-selection & signing elements in this interface will get throw away later?
318 2018-05-17 19:44:15	0|BlueMatt|topic: unverified-block-message
319 2018-05-17 19:44:27	0|BlueMatt|topic: queue drain lock assertions to avoid deadlocks
320 2018-05-17 19:44:55	0|wumpus|#topic unverified-block-message (BlueMatt)
321 2018-05-17 19:45:01	0|ryanofsky|jonasschnelli, there aren't any coin-selection or signing things in node/wallet interface in that pr
322 2018-05-17 19:45:37	0|jonasschnelli|maybe I should review the PR first...
323 2018-05-17 19:46:06	0|sipa|BlueMatt: your topic
324 2018-05-17 19:46:13	0|BlueMatt|so sdaftuar pointed out an old issue that we never really addressed where if you relay someone a script-invalid block they may announce it to their peers via compact blocks high-bandwidth-mode and then if you for some reason fall back to downloading it via getdata due to short id collision or so (we dont think there is a way to game it), then you'll end up disconnecting that peer for never responding to your request
325 2018-05-17 19:46:37	0|ryanofsky|jonasschnelli, yeah, you can just take a look at https://github.com/ryanofsky/bitcoin/blob/pr/wipc-sep/src/interfaces/chain.h to see the interface (first link in PR description)
326 2018-05-17 19:46:55	0|jtimon|re 10973 I agree I would preffer a few smaller ones, specially if there's commits that needs deeper review
327 2018-05-17 19:46:56	0|BlueMatt|we only came up with two real potential solutions: a "no, I'm not gonna send you that block" message (ie a not-batshit-insane reject message) or a "here is a block that may be invalid, but is valid pow+merkle root ala compact blocks requirement" message
328 2018-05-17 19:47:03	0|BlueMatt|or, I guess the second one is a getdata type
329 2018-05-17 19:47:13	0|sipa|BlueMatt: we have "notfound" also
330 2018-05-17 19:47:25	0|BlueMatt|sipa: isnt that a reject type?
331 2018-05-17 19:47:29	0|sipa|no
332 2018-05-17 19:47:54	0|wumpus|NetMsgType::NOTFOUND
333 2018-05-17 19:47:59	0|jnewbery|*5 chaincoders furiously grep for notfound*
334 2018-05-17 19:48:01	0|sipa|it's just a "i can't give you these INVs"
335 2018-05-17 19:48:03	0|sdaftuar|oh wow
336 2018-05-17 19:48:04	0|BlueMatt|sipa: ah, but we dont use it for blocks
337 2018-05-17 19:48:06	0|BlueMatt|only txn
338 2018-05-17 19:48:09	0|sipa|ah
339 2018-05-17 19:48:16	0|BlueMatt|still, easier would be a "here is a block that may be invalid" as that would remove the ABC in ProcessGetBlockData
340 2018-05-17 19:48:22	0|wumpus|the client ignores it just the same though
341 2018-05-17 19:48:32	0|cfields|BlueMatt: so, lots of NOTFOUNDs :)
342 2018-05-17 19:48:58	0|sipa|BlueMatt: we should have had that before compact blocks, i guess
343 2018-05-17 19:49:08	0|BlueMatt|sipa: should have had what?
344 2018-05-17 19:49:17	0|BlueMatt|sdaftuar: points out that it can be wholly independant, just a new getdata type
345 2018-05-17 19:49:17	0|sipa|a possibly invalid block relay
346 2018-05-17 19:49:29	0|sdaftuar|i think we could just add a new BLOKC response type
347 2018-05-17 19:49:33	0|sdaftuar|BLOCK_COULDBEBAD
348 2018-05-17 19:49:38	0|BlueMatt|well or both or whatever
349 2018-05-17 19:49:52	0|sipa|0xDEADB10C
350 2018-05-17 19:49:55	0|sdaftuar|where if someone requests a block but you don't know if its valid, or you know it's invalid, you return a different message containing the block to indicate that
351 2018-05-17 19:50:00	0|wumpus|hehe
352 2018-05-17 19:50:20	0|BlueMatt|yea, so old nodes would ignore it, and you'd just be sending a new message type
353 2018-05-17 19:50:21	0|sdaftuar|currently we would let the peer time us out instead
354 2018-05-17 19:50:22	0|sipa|sdaftuar: but only if you know they support such a message
355 2018-05-17 19:50:29	0|BlueMatt|or not
356 2018-05-17 19:50:30	0|sdaftuar|meh, sure, but not even needed imo
357 2018-05-17 19:50:31	0|BlueMatt|doesnt really matter
358 2018-05-17 19:50:41	0|BlueMatt|I mean they're about to disconnect you either way
359 2018-05-17 19:50:44	0|sipa|fair
360 2018-05-17 19:50:57	0|sipa|that makes compatibility really easy
361 2018-05-17 19:51:16	0|sipa|i guess... suggest something and write a bip?
362 2018-05-17 19:51:47	0|BlueMatt|oh, wait, no, you also want a new getdata type
363 2018-05-17 19:51:56	0|BlueMatt|cause otherwise you still need the ActivateBestChain in ProcessGetBlockData
364 2018-05-17 19:52:04	0|BlueMatt|which would require negotiation
365 2018-05-17 19:52:15	0|sdaftuar|yeah ok
366 2018-05-17 19:52:23	0|BlueMatt|so either that, or we start using NOTFOUNDs, I guess
367 2018-05-17 19:52:37	0|BlueMatt|I'm not sure what I prefer, so.....thoughts?
368 2018-05-17 19:52:43	0|sdaftuar|i think notfounds are worse because of the case where the block might not have been validated either way
369 2018-05-17 19:52:47	0|sdaftuar|it complicates download logic
370 2018-05-17 19:53:03	0|wumpus|if there is no specific reason to re-use NOTFOUND, a new message is much better imo
371 2018-05-17 19:53:05	0|BlueMatt|yea, its not really "notfound" its "I may find this soon"
372 2018-05-17 19:53:20	0|BlueMatt|or, really, "I dont currently find this"
373 2018-05-17 19:53:26	0|sipa|i don't think we should do protocol design in this meeting
374 2018-05-17 19:53:42	0|BlueMatt|well, there's a few options, so...good to ask
375 2018-05-17 19:53:58	0|wumpus|not the design but discussing it as a concern is valid
376 2018-05-17 19:54:03	0|wumpus|agree BlueMatt
377 2018-05-17 19:54:14	0|BlueMatt|obviously requires BIP and whatever else
378 2018-05-17 19:54:18	0|wumpus|yes
379 2018-05-17 19:55:08	0|wumpus|#topic queue drain lock assertions to avoid deadlocks (BlueMatt)
380 2018-05-17 19:55:22	0|BlueMatt|this one is less interesting, i realize now I should just open a pr and people will see it
381 2018-05-17 19:55:26	0|BlueMatt|its kinda knotty to describe
382 2018-05-17 19:55:38	0|BlueMatt|but, essentially, if you call ABC within a validationinterface callback you're hosed
383 2018-05-17 19:55:44	0|wumpus|ok, well only 4 minutes t ogo anyhow
384 2018-05-17 19:55:47	0|BlueMatt|which sucks, but I dont think we have a way to fix it
385 2018-05-17 19:55:56	0|BlueMatt|so current approach is to document it and DEBUG_LOCKORDER-assert
386 2018-05-17 19:56:07	0|BlueMatt|we can relax the requirement a bit with skeees' proposed validation-in-its-own-thread stuff
387 2018-05-17 19:56:14	0|BlueMatt|but there will still be some call restrictions
388 2018-05-17 19:57:30	0|BlueMatt|ok endtopic
389 2018-05-17 19:57:48	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.log.html
390 2018-05-17 19:57:48	0|lightningbot|Meeting ended Thu May 17 19:58:35 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
391 2018-05-17 19:57:48	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.html
392 2018-05-17 19:57:48	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-17-19.00.txt
393 2018-05-17 19:57:48	0|wumpus|#endmeeting
394 2018-05-17 19:58:26	0|cfields|my only request (same as always) is avoiding "if(on_thread1) foo() else bar()" type logic
395 2018-05-17 20:01:40	0|BlueMatt|cfields: nah, more a DUMMY_LOCK(on_thread1); AssertLockNotHeld(on_thread1) :p
396 2018-05-17 20:02:11	0|promag|jonasschnelli: will fix
397 2018-05-17 20:02:19	0|jonasschnelli|thx
398 2018-05-17 20:02:48	0|promag|np, see you later
399 2018-05-17 20:08:32	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #13265: wallet: Exit SyncMetaData if there are no transactions to sync (06master...062018_05_wallet_syncmetadata_empty_range) 02https://github.com/bitcoin/bitcoin/pull/13265
400 2018-05-17 20:16:15	0|gmaxwell|bytes, have a reasonable security argument, and require no network communications overhead.
401 2018-05-17 20:16:15	0|gmaxwell|cfields: I dunno if you discussed this with pieter before, but an alternative to your UHS that I suggested to him previously was that if you have a per-node secret salt S,  then for all "hash-like" scriptpubkey types, you could store as a key H(s || script-type || txid || vout || scriptpubkey-data)[0:16] and value is just the compact_amount.  This would allow storing almost all utxo in about 20
402 2018-05-17 20:16:26	0|achow101|damn, I forgot there was a meeting today
403 2018-05-17 20:17:04	0|achow101|wumpus: can I get #12136 for high prio?
404 2018-05-17 20:17:06	0|gmaxwell|The security argument is that with an attacker unknown salt S, the only property you need from the hash resistance to chance collisions. (also even if there were one, it would just break a single node).
405 2018-05-17 20:17:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
406 2018-05-17 20:18:07	0|jamesob|#13219 seems to have high review-effort:reward ratio in case anyone's bored
407 2018-05-17 20:18:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/13219 | bench: Add block assemble benchmark by MarcoFalke · Pull Request #13219 · bitcoin/bitcoin · GitHub
408 2018-05-17 20:18:12	0|gmaxwell|cfields: if it isn't obvious how you verify against it, when a transaction comes in, you take its input txin and vout indexes, and look at the scriptsig and construct the appropriate scriptpubkey from it.  Then check if thats in the database.
409 2018-05-17 20:18:38	0|jamesob|*low, ugh
410 2018-05-17 21:08:44	0|cfields|gmaxwell: yea, we discussed that as well. I'm not opposed, but I wanted to introduced the idea as a near drop-in for the status-quo, security wise. That salt ends up acting as a private key somewhat, which is not major but not trivial either
411 2018-05-17 21:10:21	0|cfields|gmaxwell: please mention that on the thread though. I just wanted to introduce the paradigm, I'm sure there are lots of better ways to execute it :)