1 2018-06-21 01:36:46	0|bitcoin-git|[13bitcoin] 15fanquake reopened pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (06master...06document-freebsd-quirk) 02https://github.com/bitcoin/bitcoin/pull/13503
  2 2018-06-21 01:43:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13512: [qa] mininode: Expose connection state through is_connected (06master...06Mf1806-qaMininodeState) 02https://github.com/bitcoin/bitcoin/pull/13512
  3 2018-06-21 02:33:32	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13513: [wip] depends: native_protobuf 3.6.0 (06master...06depends-protobuf-36) 02https://github.com/bitcoin/bitcoin/pull/13513
  4 2018-06-21 02:49:41	0|fanquake|sipa: Feeling a bit nostalgic today? 100'000 was quite a while ago
  5 2018-06-21 03:23:06	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13514: depends: set LANG=C in Makefile (06master...06depends-ios-support) 02https://github.com/bitcoin/bitcoin/pull/13514
  6 2018-06-21 04:02:14	0|skeees|pierre_rochard: looks like bitcoinacks might not update when labels get removed from a pr
  7 2018-06-21 04:09:43	0|bitcoin-git|[13bitcoin] 15ken2812221 opened pull request #13515: travis: Enable Qt build for Windows and 32-bit Linux (06master...06travis_qt) 02https://github.com/bitcoin/bitcoin/pull/13515
  8 2018-06-21 08:02:47	0|wumpus|I won't be able to attend tonight's meeting, can someone else chair this time please?
  9 2018-06-21 09:06:42	0|jonasschnelli|wumpus: I'm also not sure if I make it on time... so happy if sipa, MarcoFalke or someone else takes the chair
 10 2018-06-21 10:52:51	0|Guest37145|bitcoin to rise $8230 2.35am EST tomorrow
 11 2018-06-21 11:00:45	0|Guest37145|dgdsgd
 12 2018-06-21 11:00:46	0|Guest37145|sg
 13 2018-06-21 11:00:46	0|Guest37145|sgd
 14 2018-06-21 11:00:47	0|Guest37145|d
 15 2018-06-21 11:00:47	0|Guest37145|dsg
 16 2018-06-21 11:00:48	0|Guest37145|dsg
 17 2018-06-21 11:00:48	0|Guest37145|g
 18 2018-06-21 11:00:49	0|Guest37145|dg
 19 2018-06-21 11:00:49	0|Guest37145|dsg
 20 2018-06-21 11:00:50	0|Guest37145|d
 21 2018-06-21 11:00:50	0|Guest37145|g
 22 2018-06-21 11:00:51	0|Guest37145|d
 23 2018-06-21 11:00:51	0|Guest37145|dg
 24 2018-06-21 11:00:52	0|Guest37145|g
 25 2018-06-21 11:00:52	0|Guest37145|gd
 26 2018-06-21 11:00:53	0|Guest37145|dsg
 27 2018-06-21 11:00:53	0|Guest37145|gds
 28 2018-06-21 12:44:36	0|pierre_rochard|skeees: ouch, I'll fix asap
 29 2018-06-21 13:25:53	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13517: qa: Remove need to handle the network thread in tests (06master...06Mf1806-qaAsyncIo) 02https://github.com/bitcoin/bitcoin/pull/13517
 30 2018-06-21 14:23:46	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 9 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6579d80572d2...000abbb6b074
 31 2018-06-21 14:23:47	0|bitcoin-git|13bitcoin/06master 14537efe1 15João Barbosa: rpc: Extract GetWalletNameFromJSONRPCRequest from GetWalletForJSONRPCRequest
 32 2018-06-21 14:23:47	0|bitcoin-git|13bitcoin/06master 146608c36 15João Barbosa: rpc: Add unloadwallet RPC
 33 2018-06-21 14:23:48	0|bitcoin-git|13bitcoin/06master 144940a20 15João Barbosa: test: Add functional tests for unloadwallet RPC
 34 2018-06-21 14:24:30	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #13111: Add unloadwallet RPC (06master...062018-04-unload-wallet) 02https://github.com/bitcoin/bitcoin/pull/13111
 35 2018-06-21 18:58:41	0|sipa|#startmeeting
 36 2018-06-21 18:58:42	0|lightningbot|Meeting started Thu Jun 21 19:00:01 2018 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
 37 2018-06-21 18:58:42	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 38 2018-06-21 18:58:48	0|achow101|hi
 39 2018-06-21 18:58:53	0|promag|hi
 40 2018-06-21 18:59:20	0|meshcollider|Hi
 41 2018-06-21 18:59:26	0|sipa|#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
 42 2018-06-21 18:59:33	0|kanzure|hi.
 43 2018-06-21 18:59:37	0|sipa|topics?
 44 2018-06-21 18:59:40	0|kanzure|alert key
 45 2018-06-21 18:59:45	0|kanzure|not priority tho
 46 2018-06-21 19:00:22	0|instagibbs|hi
 47 2018-06-21 19:01:04	0|sipa|okay, let's start with high-priority reviews
 48 2018-06-21 19:01:13	0|sipa|#topic review blocks
 49 2018-06-21 19:01:14	0|kanzure|also, bitcoin-dev mailing list hosting provider is migrating away from the email protocol, so the underlying host is going to probably switch soon (more details forthcoming)
 50 2018-06-21 19:01:56	0|jnewbery|hi
 51 2018-06-21 19:02:06	0|sipa|we have 3 open review blockers: #13062 #12196 #13425
 52 2018-06-21 19:02:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
 53 2018-06-21 19:02:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
 54 2018-06-21 19:02:17	0|gribble|https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
 55 2018-06-21 19:02:24	0|achow101|the merged ones should be removed from the list
 56 2018-06-21 19:02:40	0|sipa|good point, will od
 57 2018-06-21 19:03:28	0|sipa|done
 58 2018-06-21 19:03:36	0|sipa|any proposals for others to add?
 59 2018-06-21 19:03:54	0|promag|I'll update #13100 in the next couple of days, but would be nice to have it on high priority
 60 2018-06-21 19:03:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
 61 2018-06-21 19:04:17	0|promag|it's the missing piece in the dyn multi wallet story
 62 2018-06-21 19:04:29	0|sipa|promag: ping me when ready, i'll add it then
 63 2018-06-21 19:04:41	0|promag|will do ty
 64 2018-06-21 19:04:53	0|sipa|#topic alert key
 65 2018-06-21 19:04:55	0|sipa|kanzure: ^
 66 2018-06-21 19:05:19	0|kanzure|alert key system deprecated, topic has absolutely no impact on bitcoind itself AFAIK
 67 2018-06-21 19:05:30	0|achow101|besides vulnerable versions
 68 2018-06-21 19:05:31	0|kanzure|i recognize the request to perhaps wait for v0.13 end-of-life, would like to hear more comments about that
 69 2018-06-21 19:05:35	0|sipa|absent any other topic proposals, i'm sure we can talk about it
 70 2018-06-21 19:05:44	0|kanzure|i believe those vulnerabilities might not be public but whatever, yes those
 71 2018-06-21 19:06:16	0|achow101|0.13 is the first version to have the alert system gone. the final alert stuff was added in 0.14.
 72 2018-06-21 19:06:35	0|kanzure|for context: i'm thinking of releasing the private key, would be nice to get that out there and remove that liability
 73 2018-06-21 19:06:36	0|achow101|so waiting for 0.14 to be the oldest version in any form of support is good
 74 2018-06-21 19:06:42	0|gmaxwell|Though it was default off since what.. 0.10.something ?
 75 2018-06-21 19:06:47	0|achow101|0.12
 76 2018-06-21 19:06:47	0|luke-jr|if 0.13 doesn't have alert system at all, why wait for it to be EOL?
 77 2018-06-21 19:07:06	0|meshcollider|Yeah doesn't seem much point waiting for 13 EOL
 78 2018-06-21 19:07:18	0|meshcollider|0.12 is already gone
 79 2018-06-21 19:07:39	0|gmaxwell|There are two levels, off by default, and gone completely. 0.12 has it off by default and 0.13 gone completely?
 80 2018-06-21 19:07:44	0|achow101|yes
 81 2018-06-21 19:07:58	0|kanzure|i'm particularly interested in hearing from others who have good reason not to reveal the key.. in the year+ since this was announced i don't think much has been raised.
 82 2018-06-21 19:08:01	0|gmaxwell|and 0.12 is not supported at all, so all supported versions have it gone completely.
 83 2018-06-21 19:08:17	0|kanzure|i sent out an email to the mailing list a few days ago and i have heard back from exactly one person regarding a request for a final alert message to some other altcoin
 84 2018-06-21 19:08:30	0|kanzure|so i think this stuff is good and dead at this point
 85 2018-06-21 19:08:35	0|achow101|yes
 86 2018-06-21 19:08:47	0|achow101|also, if someone needs a final alert, they can pull it from the current source code
 87 2018-06-21 19:08:47	0|gmaxwell|So that sounds pretty good for a release now, unless pre-0.12 nodes are still popular, and I don't believe they are.
 88 2018-06-21 19:09:04	0|achow101|I would assume that someone who has changed the alert format would also change the alert key
 89 2018-06-21 19:09:10	0|kanzure|anyway, if anyone would like to send me name suggestions for someone to go talk to in private, i'm open to that, although i don't expect to hear from anyone
 90 2018-06-21 19:09:36	0|gmaxwell|unfortunately, final alerts don't have the protective properties we believed they had.
 91 2018-06-21 19:09:44	0|luke-jr|there's ~3% of the network on 0.12
 92 2018-06-21 19:09:52	0|achow101|luke-jr: what about earlier?
 93 2018-06-21 19:09:53	0|kanzure|was non-protection disclosed somewhere?
 94 2018-06-21 19:10:07	0|sipa|bitnodes says around 300 ish 0.12 and below nodes, out of 9945
 95 2018-06-21 19:10:20	0|luke-jr|achow101: 0.61% "other" versions, which includes everything before 0.12
 96 2018-06-21 19:10:32	0|luke-jr|http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
 97 2018-06-21 19:10:36	0|achow101|ok.. and they all probably have the final alert anyways
 98 2018-06-21 19:10:40	0|luke-jr|sipa: bitnodes only shows listening
 99 2018-06-21 19:10:50	0|luke-jr|although that's the same 3%
100 2018-06-21 19:10:50	0|sipa|luke-jr: i'm aware; just offering an extra data point
101 2018-06-21 19:11:15	0|luke-jr|gmaxwell: what was missing re protective properties?
102 2018-06-21 19:11:43	0|kanzure|also how do folks feel about the unmentioned (spamming) vulnerabilities related to this?
103 2018-06-21 19:12:42	0|gmaxwell|luke-jr: back when we first started talking about publishing it I was under the mistaken belief that a final alert basically disabled the alert code ... e.g. no more alert message processing, only relaying of the final alert.
104 2018-06-21 19:13:04	0|gmaxwell|so that a final alert would effectively also limit the usefulness of any alert dos attacks
105 2018-06-21 19:13:10	0|gmaxwell|But that isn't the case.
106 2018-06-21 19:13:14	0|achow101|kanzure: I think all of the vulns should be disclosed at the same time as the key
107 2018-06-21 19:13:28	0|kanzure|this sounds like the same one
108 2018-06-21 19:13:29	0|luke-jr|gmaxwell: that was also my impression
109 2018-06-21 19:13:42	0|gmaxwell|I doubt we know all the vulnerabilities. I know of at least two but I stopped looking.
110 2018-06-21 19:13:53	0|achow101|gmaxwell: I believe I know of three
111 2018-06-21 19:14:06	0|gmaxwell|Also depends on how you count. :)
112 2018-06-21 19:14:09	0|achow101|that too
113 2018-06-21 19:14:26	0|sipa|i tend to count using the ring of integers
114 2018-06-21 19:15:03	0|gmaxwell|in any case, the alert code didn't stand up to careful review and is somewhat exposed to malicious alerts.
115 2018-06-21 19:15:15	0|gmaxwell|But then again any code still with it is also exposed in other ways.
116 2018-06-21 19:15:30	0|BlueMatt|there's also limited utility to releasing the alert key
117 2018-06-21 19:15:36	0|kanzure|sounds like some forkcoin projects might have to deal with this if they haven't already, not just rely on the fantasy of a final alert that shuts down the alert system
118 2018-06-21 19:15:38	0|BlueMatt|aside from "one less thing to worry about"
119 2018-06-21 19:16:14	0|gmaxwell|kanzure: well if anything still had it, it would have been easy enough to fix.
120 2018-06-21 19:16:29	0|gmaxwell|(by basically adding an "if I have had a final alert, drop all new alert messages" line.
121 2018-06-21 19:16:30	0|jnewbery|I think 'one less thing to worry about' is good enough reason (also 'one less thing to discuss for the rest of our lives')
122 2018-06-21 19:16:31	0|gmaxwell|)
123 2018-06-21 19:16:41	0|kanzure|i was surprised by the one person that did message- didn't think he would have had something with the alert system :-)
124 2018-06-21 19:16:48	0|kanzure|and if he could make that kind of mistake, i'd imagine many others are making worse mistakes
125 2018-06-21 19:17:02	0|gmaxwell|I was more concerned about it a year ago when in a short periord we had multiple people crop up and propose using that stupid key as some centeralized controlled whatever.
126 2018-06-21 19:17:16	0|meshcollider|And it has been a couple of years since the deprecation was announced, it's not like fair warning wasn't given in any case
127 2018-06-21 19:17:19	0|achow101|kanzure: if the altcoins have better control of their alert key, publishing the bitcoin one and the related vulns shouldn't be a problem
128 2018-06-21 19:17:25	0|kanzure|#action collect vulnerability knowledge from achow101
129 2018-06-21 19:17:43	0|kanzure|achow101: ah interesting point. i was only thinking about the projects that copied the public key actually.
130 2018-06-21 19:18:04	0|gmaxwell|I had thought there were ~none, but it turns out prior searches were somewhat ineffective.
131 2018-06-21 19:18:06	0|achow101|kanzure: AFAICT, there aren't any projects using the bitcoin one
132 2018-06-21 19:18:12	0|gmaxwell|The litecoin alertkey is copied all over heck and back.
133 2018-06-21 19:18:19	0|achow101|Google and github search for the key itself has turned up nothing
134 2018-06-21 19:18:20	0|gmaxwell|achow101: there was at least one we missed.
135 2018-06-21 19:18:32	0|kanzure|achow101: there is at least one actually, and someone contacted me about it i think :-)
136 2018-06-21 19:18:52	0|achow101|it could be that they removed the alert system but still have legacy nodes?
137 2018-06-21 19:19:20	0|kanzure|unfortunately this person was also misinformed about the effects of the final alert message... in fact, i should go fix that misunderstanding.
138 2018-06-21 19:19:26	0|gmaxwell|In any case, I think there has been plenty of warning from the prior discussion.
139 2018-06-21 19:19:47	0|gmaxwell|kanzure: also I think our prior discussion made it pretty clear that the final alert turned out to not be so final.
140 2018-06-21 19:20:02	0|BlueMatt|at some point if you're so incompetent that you leave the alert key around for a while you've probably broken things in 10 other ways, honestly
141 2018-06-21 19:20:06	0|gmaxwell|(or rather there were DOS vulnerabilties that persisted in spite of it)
142 2018-06-21 19:20:22	0|kanzure|BlueMatt: yeah but i also somewhat have a duty to not inadvertedly break other people's broken systems just because they are stupid broken systems
143 2018-06-21 19:20:26	0|BlueMatt|I dont think we need to worry about other random crap
144 2018-06-21 19:20:33	0|meshcollider|Agreed, I think just a full post with all info, vulns and key would be best now to resolve this
145 2018-06-21 19:20:37	0|gmaxwell|the alert system was kinda cool, except for the bugs... and unclear security model, lack of multisig, etc. :P
146 2018-06-21 19:20:44	0|BlueMatt|more like worry about our own crap and make sure to sufficiently disclose, which clearly happened
147 2018-06-21 19:21:01	0|luke-jr|DoS is not a big deal IMO
148 2018-06-21 19:21:05	0|kanzure|sure. okay. let's move on.
149 2018-06-21 19:21:11	0|luke-jr|maybe the denial of service will prompt the user to upgrade ;)
150 2018-06-21 19:21:16	0|kanzure|i do have one other topic about bitcoin-dev mailing list
151 2018-06-21 19:21:18	0|gmaxwell|luke-jr: yes, assuming thats the worst of it.
152 2018-06-21 19:21:40	0|sipa|ok, let's switch topics
153 2018-06-21 19:21:50	0|gmaxwell|(I don't have any reason to assume it's worse than dos other than the fact that there were a bunch of DOS vulns that were unknown until I checked before publishing the key)
154 2018-06-21 19:21:54	0|sipa|#topic bitcoin-dev mailinglist
155 2018-06-21 19:22:04	0|kanzure|linuxfoundation is migrating away from the email protocol and will no longer be hosting the bitcoin-dev mailing list
156 2018-06-21 19:22:21	0|kanzure|there is a migration plan but it's under investigating still
157 2018-06-21 19:22:23	0|BlueMatt|what are the other 200 mailing lists on lists.linuxfoundation.org doing?
158 2018-06-21 19:22:23	0|kanzure|details are still forthcoming sorry i don't have anything specific at this time
159 2018-06-21 19:22:32	0|kanzure|will post to mailing list when i have more details about actual plan
160 2018-06-21 19:22:42	0|BlueMatt|errr, oh, actually there arent many
161 2018-06-21 19:22:44	0|kanzure|i believe the current plan is "give lists.linuxfoundation.org to osuosl"
162 2018-06-21 19:23:02	0|achow101|what does "migrating away from the email protocol" mean? are they just not doing mailing lists anymore?
163 2018-06-21 19:23:07	0|luke-jr|achow101: right
164 2018-06-21 19:23:12	0|kanzure|achow101: linuxfoundation no longer believes in email apparently
165 2018-06-21 19:23:22	0|kanzure|i don't know, man.
166 2018-06-21 19:23:25	0|meshcollider|lol
167 2018-06-21 19:23:28	0|gmaxwell|Is that like not believing in santa clause?
168 2018-06-21 19:23:39	0|kanzure|it's similar but not in the abstract
169 2018-06-21 19:23:43	0|gmaxwell|claus*
170 2018-06-21 19:24:02	0|sipa|How can you believe in the universe, if you don't even know if email is real?
171 2018-06-21 19:24:17	0|kanzure|i'll post more details once i have some, i'd prefer to get an email out to the mailing list before the migration happens since this is weird and unusual
172 2018-06-21 19:24:21	0|luke-jr|I guess if you disbelieve in email, it ceases to be real for you?
173 2018-06-21 19:24:34	0|gmaxwell|in any case, I can't say that I was completely happy with LF regardless.
174 2018-06-21 19:24:45	0|kanzure|my primary concern is about linkrot
175 2018-06-21 19:24:56	0|kanzure|they seem open to including some rewrite rules on their http server to fix some of the linkrot problem
176 2018-06-21 19:25:03	0|sipa|... for now
177 2018-06-21 19:25:20	0|luke-jr|kanzure: if they're letting OSUOSL use the domain, wouldn't OSUOSL just be able to maintain the links?
178 2018-06-21 19:25:34	0|kanzure|and also, if the mailing list was to move away from lists.linuxfoundation.org as the domain, and MX records, then potential email delivery problems for the current subscribers
179 2018-06-21 19:25:59	0|kanzure|luke-jr: sipa notes that the relationship there might change over time
180 2018-06-21 19:25:59	0|sipa|are there any other topics?
181 2018-06-21 19:26:07	0|achow101|I'm already experiencing mail delivery problems, so....
182 2018-06-21 19:26:20	0|luke-jr|kanzure: nothing we can do can prevent that AFAIK
183 2018-06-21 19:26:20	0|sipa|(we can let this discussion continue if nothing else, but perhaps there are more development related topics)
184 2018-06-21 19:26:25	0|kanzure|oh yeah, achow101 has reported mail delivery and receipt problems for lists.linuxfoundation.org that i haven't been able to investigate
185 2018-06-21 19:28:44	0|aj|was there configuration / bitcon-rw.conf / ...? stuff to discuss? i think some got deferred from previous meetings
186 2018-06-21 19:28:52	0|achow101|topic suggestion: coin selection
187 2018-06-21 19:29:01	0|achow101|(again)
188 2018-06-21 19:29:34	0|sipa|aj: i'm not up to date with that discussion
189 2018-06-21 19:29:40	0|sipa|#topic coin selection
190 2018-06-21 19:30:02	0|achow101|https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c
191 2018-06-21 19:30:02	0|achow101|I did a bunch of simulations of the srd fallback stuff
192 2018-06-21 19:30:17	0|luke-jr|aj: yes, last time it was deferred cuz someone wasn't here
193 2018-06-21 19:30:39	0|achow101|there are two problems that I see with this strategy: change can be incredibly small and the mean number of utxos in the wallet is quite highg
194 2018-06-21 19:31:45	0|achow101|the question is whether we can accept these tradeoffs or whether we need to find a better algorithm
195 2018-06-21 19:32:30	0|sipa|it sounds concerning to me
196 2018-06-21 19:32:43	0|achow101|I agree, especially the small change
197 2018-06-21 19:33:01	0|achow101|we may have to keep MIN_CHANGE, but I don't really like having a fixed minimum change
198 2018-06-21 19:33:19	0|gmaxwell|is this code discarding sub fee change?
199 2018-06-21 19:33:29	0|sipa|yes
200 2018-06-21 19:33:45	0|sipa|you mean turning dust change into fee? yes
201 2018-06-21 19:34:42	0|gmaxwell|OKAY
202 2018-06-21 19:35:08	0|gmaxwell|So let me check my understanding of our understanding.
203 2018-06-21 19:35:36	0|gmaxwell|SRD is producing poor solutions in cases where the wallet has lots of small inputs?  And also tends to produce small change itself?
204 2018-06-21 19:35:50	0|sipa|tends to produce
205 2018-06-21 19:36:34	0|achow101|however it does help BnB find more exact matches
206 2018-06-21 19:36:46	0|gmaxwell|Yes, but probably other strategies could do that.
207 2018-06-21 19:36:52	0|sipa|but clearly not enough to compensate (as the total number of UTXOs grows)
208 2018-06-21 19:37:01	0|gmaxwell|e.g. current algo but with a min_change that is randomized more.
209 2018-06-21 19:37:01	0|luke-jr|aj: (do you have time to discuss rwconf stuff after the meeting if we run out of time during?)
210 2018-06-21 19:37:05	0|jtimon|sorry I'm late, https://github.com/bitcoin/bitcoin/pull/13311 is kind of blocking to me for the block signed testnets thing (assuming there's still interest in that) </offtopic>
211 2018-06-21 19:37:43	0|gmaxwell|IIRC there is nothing fundimental about SRD that makes it good for making BNB work better, but rather it was the first alternative murch tried there.
212 2018-06-21 19:38:07	0|aj|luke-jr: (yes, it's the start of my day here)
213 2018-06-21 19:38:14	0|sipa|well and in murch's simulations, SRD performed reasoably well, and was extremely simple
214 2018-06-21 19:38:25	0|sipa|though i guess we may be seeing different results now
215 2018-06-21 19:38:33	0|gmaxwell|So for example, current solver plus add a couple extra inputs at random probably also makes BNB work better than current alone.
216 2018-06-21 19:39:26	0|sipa|i'm wondering if instead of SRD, we shouldn't use a BNB algorithm with a very large target range, larger than minimal change
217 2018-06-21 19:39:51	0|Murch|And then allow it to create change outputs?
218 2018-06-21 19:39:56	0|sipa|Murch: indeed
219 2018-06-21 19:40:14	0|sipa|Murch: basically run BNB in a mode where it assumes change will be created anyway
220 2018-06-21 19:40:21	0|sipa|and then minimize waste for that
221 2018-06-21 19:40:37	0|sipa|have you considered such a strategy?
222 2018-06-21 19:41:04	0|gmaxwell|stratigies that minimize change values are bad for building a collection of coins that help BNB.
223 2018-06-21 19:41:06	0|Murch|I have thought a bit about it, but figured that it is computationally intensive for no good reason
224 2018-06-21 19:41:18	0|sipa|gmaxwell: minimizing change != minimizing waste
225 2018-06-21 19:41:28	0|gmaxwell|sipa: what is 'waste'?
226 2018-06-21 19:41:53	0|jonasschnelli|hi
227 2018-06-21 19:41:54	0|Murch|Also, then you're just minimizing the input set since everything produces change and thus all with the same count of inputs have the same waste value
228 2018-06-21 19:42:03	0|Murch|at least at higher fees
229 2018-06-21 19:42:09	0|achow101|gmaxwell: line 36 of src/wallet/coinselection.cpp
230 2018-06-21 19:42:17	0|sipa|gmaxwell: in this case, it means minimziing fees
231 2018-06-21 19:42:30	0|Murch|Maybe one could just do smallest first selection at the lowest fee range to auto-consolidate?
232 2018-06-21 19:42:38	0|sipa|https://github.com/bitcoin/bitcoin/blob/master/src/wallet/coinselection.cpp#L36L40
233 2018-06-21 19:42:59	0|gmaxwell|Murch: smallest first is pathalogical for wallets with tons of tiny inputs, unfortunately.
234 2018-06-21 19:43:00	0|sipa|we probably shouldn't do algorithm design in this meeting, but ideas for things to try may be useful
235 2018-06-21 19:43:33	0|Murch|Alright, maybe oldest first on the ones that are smaller than the target. ;)
236 2018-06-21 19:43:36	0|gmaxwell|we can't have undefended pathological behavior, since we can't assume the usage will be supervised.
237 2018-06-21 19:43:48	0|Murch|but it would have some sort of limit on transaction size
238 2018-06-21 19:44:21	0|luke-jr|might be interesting to have coin selection pay attention to feerate estimates. use more inputs when feerates are low, for example. just a thought
239 2018-06-21 19:44:22	0|gmaxwell|We could still have that mode, it would just have to be guarded by something that cuts off the pathalogical behavior.
240 2018-06-21 19:44:35	0|Murch|gmaxwell: If smallest first is only used at < 4 sats/byte, why not auto-consolidate up to e.g. 250 unspents?
241 2018-06-21 19:44:40	0|achow101|luke-jr: preferably the algorithm would be self adjusting to the feerates
242 2018-06-21 19:44:41	0|sipa|luke-jr: it does
243 2018-06-21 19:44:49	0|sipa|BNB at least does
244 2018-06-21 19:45:00	0|Murch|ofc it would mean that a cpfp would be extremely expensive should it become necessary
245 2018-06-21 19:45:22	0|Murch|luke-jr: the new fee estimation is already fee sensitive
246 2018-06-21 19:45:29	0|luke-jr|i c
247 2018-06-21 19:45:32	0|sipa|Murch: you mean coin selections
248 2018-06-21 19:45:39	0|sipa|i would hope that fee estimation is fee sensitive :p
249 2018-06-21 19:45:40	0|Murch|äh, I do
250 2018-06-21 19:46:23	0|jonasschnelli|I have two topic proposal... but I guess I'm too late: a) Multiwallet session persistence b) Bech32X
251 2018-06-21 19:47:11	0|achow101|perhaps this coin selection discussion would be better done in person with whiteboards
252 2018-06-21 19:47:14	0|sipa|yeah
253 2018-06-21 19:47:20	0|sipa|#topic multiwallet session persistence
254 2018-06-21 19:47:23	0|Murch|I'm game
255 2018-06-21 19:47:25	0|jonasschnelli|Okay...
256 2018-06-21 19:47:36	0|luke-jr|ok, so I guess rwconf waits until after meeting :x
257 2018-06-21 19:47:41	0|gmaxwell|achow101: that leaves out people who can't attend.
258 2018-06-21 19:47:47	0|jonasschnelli|I guess it's not ideal that loaded wallets need to be re-loaded after a Bitcoin-Core restart...
259 2018-06-21 19:47:59	0|jonasschnelli|especially in pruning mode
260 2018-06-21 19:48:00	0|sipa|luke-jr, aj: i can make it a topic; it wasn't clear if you wanted it here
261 2018-06-21 19:48:06	0|gmaxwell|jonasschnelli: so put them in the conf file?
262 2018-06-21 19:48:13	0|luke-jr|sipa: almost out of time anyway
263 2018-06-21 19:48:15	0|sipa|jonasschnelli: that sounds like something to address with rwconf
264 2018-06-21 19:48:17	0|jonasschnelli|gmaxwell: that works for static enviromnents...
265 2018-06-21 19:48:30	0|gmaxwell|jonasschnelli: not with rwconf.
266 2018-06-21 19:48:34	0|luke-jr|gmaxwell: maybe not easy for GUI users (yet; rwconf to the rescue? :P)
267 2018-06-21 19:48:49	0|jonasschnelli|rwconf would be indeed a solution, yes.
268 2018-06-21 19:49:04	0|sipa|it seems like the exact same problem as the one rwconf is intended to solve
269 2018-06-21 19:49:17	0|luke-jr|unless you wanted multiple different sessions, maybe?
270 2018-06-21 19:49:36	0|luke-jr|but I'm not sure there's a use case for that
271 2018-06-21 19:50:23	0|gmaxwell|seems out of scope to me.
272 2018-06-21 19:50:26	0|jonasschnelli|Okay guess rw/config solves this... so /topic
273 2018-06-21 19:50:39	0|sipa|#topic bech32x
274 2018-06-21 19:50:57	0|jonasschnelli|Bech32X has currently the distance 27 BCH with correction to 7 chars (thanks to sipa)
275 2018-06-21 19:51:00	0|jonasschnelli|The idea is now..
276 2018-06-21 19:51:12	0|jonasschnelli|to have three "levels" or correction..
277 2018-06-21 19:51:39	0|sipa|i'll gladly create code for that
278 2018-06-21 19:51:48	0|jonasschnelli|I'd like to hear if this a) is "easy" possible (three generators) and b) if the use case makse sense (selective correction robusntess)?
279 2018-06-21 19:51:49	0|sipa|i don't have strong opinions about usage
280 2018-06-21 19:52:02	0|gmaxwell|12:52:32 < jonasschnelli> to have three "levels" or correction..
281 2018-06-21 19:52:02	0|gmaxwell|I don't understand
282 2018-06-21 19:52:09	0|jonasschnelli|7 chars is still not much more then 5% correction for 512bit key material
283 2018-06-21 19:52:27	0|luke-jr|maybe correction level should be somehow defined as a % of the whole?
284 2018-06-21 19:52:33	0|gmaxwell|Oh you want multiple codes so for long key data it uses a stronger code?
285 2018-06-21 19:52:37	0|jonasschnelli|gmaxwell: a flexible checksum, either 7 chars or 14chars or 28 chars of correction
286 2018-06-21 19:52:48	0|sipa|gmaxwell: or that the user can choose how much correction information they want
287 2018-06-21 19:52:53	0|jonasschnelli|gmaxwell: either the length or the HRP does hint what code to use
288 2018-06-21 19:52:54	0|sipa|(QR codes have this, for example)
289 2018-06-21 19:52:59	0|jonasschnelli|Yes.
290 2018-06-21 19:53:01	0|gmaxwell|It can't be 'flexible' without hurting performance, but we could just have more or less.
291 2018-06-21 19:53:07	0|gmaxwell|through multiple codes.
292 2018-06-21 19:53:23	0|sipa|yeah, i'm sure he just means have 3 codes to choose from
293 2018-06-21 19:53:29	0|jonasschnelli|yes
294 2018-06-21 19:53:34	0|gmaxwell|But I think it is not good to make it generally user selectable. The user _generally_ has no way to make a useful decision.
295 2018-06-21 19:53:53	0|jonasschnelli|gmaxwell: Yes. I also thought this...
296 2018-06-21 19:53:56	0|luke-jr|user in this case being the software I think
297 2018-06-21 19:54:00	0|gmaxwell|But making the format support multiple codes seems okay to me though it might lower the odds that powerful fancy decoders get written, because it'll be more work.
298 2018-06-21 19:54:04	0|jonasschnelli|On the other hand, maxing on 5% correction may also be not ideal
299 2018-06-21 19:54:28	0|sipa|gmaxwell: we can make sure they use the same field and extension, so that the majority of the recovery code can be shared
300 2018-06-21 19:54:38	0|gmaxwell|There are certian improved properties we can get if we know a code will only be used for shorter vs longer data.
301 2018-06-21 19:54:53	0|sipa|gmaxwell: not much as these levels of corrections (too large search space)
302 2018-06-21 19:55:18	0|gmaxwell|so if the goal really was just to have multiple codes to have a certian percentage of correction that could perhaps be used.
303 2018-06-21 19:55:46	0|gmaxwell|sipa: well we can still search for codes with improved performance over modest (e.g. 50 char) windows, giving better burst error handling.
304 2018-06-21 19:56:37	0|sipa|we can even make the generators multiples of each other, so that a valid code according to one is also valid according to the "weaker" versions
305 2018-06-21 19:56:48	0|gmaxwell|in any case, I assume sipa would come up with the codes.. fewer levels is better than more...
306 2018-06-21 19:56:49	0|sipa|(or with a different offset, guarantee that this exactly never happens)
307 2018-06-21 19:57:40	0|gmaxwell|sipa: if you're going to abandon beyond bch performance the difference codes could just be punctures of a single bigger one.
308 2018-06-21 19:58:01	0|sipa|gmaxwell: right, i believe that's actually saying the same thing
309 2018-06-21 19:58:37	0|sipa|gmaxwell: also, for distance 15 there is nothing we can grind, not even for short lengths
310 2018-06-21 19:58:49	0|lightningbot|Meeting ended Thu Jun 21 20:00:09 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
311 2018-06-21 19:58:49	0|sipa|#endmeeting
312 2018-06-21 19:58:50	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html
313 2018-06-21 19:58:50	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.html
314 2018-06-21 19:58:50	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.txt
315 2018-06-21 19:58:51	0|gmaxwell|It seems odd and a bit sad to have so much design freedom and not use it however.
316 2018-06-21 19:58:51	0|sipa|#lunch
317 2018-06-21 19:59:01	0|luke-jr|sipa responds and runs :P
318 2018-06-21 19:59:14	0|gmaxwell|will continue later.
319 2018-06-21 19:59:42	0|luke-jr|=⃦topic rwconf (ping aj)
320 2018-06-21 20:00:07	0|gmaxwell|sipa: I wonder if we can at least choose the lower degree part of the code to have better performance.
321 2018-06-21 20:00:23	0|sipa|gmaxwell: that's a good point
322 2018-06-21 20:00:24	0|aj|luke-jr: yo
323 2018-06-21 20:00:33	0|sipa|gmaxwell: we could just extend the bech32 generator for example
324 2018-06-21 20:00:39	0|luke-jr|aj: did you read the log? http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-07-19.00.log.html#l-102
325 2018-06-21 20:02:00	0|aj|luke-jr: yeah. the separate maps for cmdline and config were to preserve the flipped ordering behaviour
326 2018-06-21 20:02:38	0|luke-jr|aj: do you have any objections to reverting it back to a single-value map + multi-value map?
327 2018-06-21 20:03:04	0|luke-jr|(thereby resolving the ordering stuff at startup, rathre than runtime)
328 2018-06-21 20:03:54	0|sipa|i think AddArg should get a flag indicating whether the option is single-value or multi-value, so that repeated arguments can be dealt with at parsing time
329 2018-06-21 20:04:57	0|luke-jr|sipa: IMO that makes sense, but best as a separate PR
330 2018-06-21 20:05:16	0|aj|luke-jr: i don't think that quite works with prioritising the network stuff; ie atm it's "cmdline, [regtest], plainconfig"; but if you populate a single map with override first, then see a plain config option, then see regtest.foo=bah, you can't decide whether to drop the old entry or preserve it
331 2018-06-21 20:06:32	0|luke-jr|hmm
332 2018-06-21 20:06:52	0|aj|luke-jr: long term i like (an approach like) meshcollider's arg rework stuff
333 2018-06-21 20:07:59	0|aj|luke-jr: //github.com/MeshCollider/bitcoin/commits/201712_argument_registration maybe
334 2018-06-21 20:09:15	0|aj|luke-jr: anyway, i don't object to changing around the map stuff, this was just the simplest way i could see of getting relatively sane behavior
335 2018-06-21 20:09:18	0|luke-jr|aj: maybe the single map will need a flag indicating where it came from for now
336 2018-06-21 20:09:37	0|aj|luke-jr: yeah, that's just equivalent to two maps :)
337 2018-06-21 20:10:21	0|luke-jr|well, now we're getting into 4 sources - "cmdline, rwconf, [regtest], plainconfig"
338 2018-06-21 20:11:34	0|aj|luke-jr: 3 sources if you count them as cmdline, rwconf, config[foo=/regtest.foo=/test.foo=/main.foo=]
339 2018-06-21 20:11:43	0|aj|luke-jr: but yeah