1 2016-12-01 00:11:40	0|bitcoin-git|[13bitcoin] 15sipa pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/56bee4986d11...a143b88dbd49
  2 2016-12-01 00:11:41	0|bitcoin-git|13bitcoin/06master 140cc8b6b 15Wladimir J. van der Laan: init: Split up AppInit2 into multiple phases...
  3 2016-12-01 00:11:42	0|bitcoin-git|13bitcoin/06master 1416ca0bf 15Wladimir J. van der Laan: init: Try to aquire datadir lock before and after daemonization...
  4 2016-12-01 00:11:42	0|bitcoin-git|13bitcoin/06master 14deec83f 15Wladimir J. van der Laan: init: Get rid of fServer flag...
  5 2016-12-01 00:11:50	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9010: Split up AppInit2 into multiple phases, daemonize after datadir lock errors (06master...062016_10_init_split_daemon) 02https://github.com/bitcoin/bitcoin/pull/9010
  6 2016-12-01 00:15:40	0|gmaxwell|hurrah
  7 2016-12-01 00:15:49	0|bitcoin-git|13bitcoin/06master 14446a8f9 15Karl-Johan Alm: Trivial refactor: Remove extern keyword from function declarations, as they are extern by default.
  8 2016-12-01 00:15:49	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a143b88dbd49...72ae6f8cf022
  9 2016-12-01 00:15:50	0|bitcoin-git|13bitcoin/06master 1472ae6f8 15Pieter Wuille: Merge #9244: Trivial refactor: Remove extern keyword from function declarations...
 10 2016-12-01 00:15:58	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9244: Trivial refactor: Remove extern keyword from function declarations (06master...06no-extern-funcdecl) 02https://github.com/bitcoin/bitcoin/pull/9244
 11 2016-12-01 01:16:22	0|bitcoin-git|13bitcoin/06master 14083f203 15Gregory Maxwell: Remove fNetworkNode....
 12 2016-12-01 01:16:22	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/72ae6f8cf022...3bf06e9bac57
 13 2016-12-01 01:16:23	0|bitcoin-git|13bitcoin/06master 143bf06e9 15Pieter Wuille: Merge #9226: Remove fNetworkNode and pnodeLocalHost....
 14 2016-12-01 01:16:23	0|bitcoin-git|13bitcoin/06master 14bdb922b 15Gregory Maxwell: Remove pnodeLocalHost....
 15 2016-12-01 01:16:31	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9226: Remove fNetworkNode and pnodeLocalHost. (06master...06node_is_this_i_dont_even) 02https://github.com/bitcoin/bitcoin/pull/9226
 16 2016-12-01 02:02:35	0|phantomcircuit|ok can someone explain why nWalletDBUpdateCounter doesn't work as a static member of CWalletDB ?
 17 2016-12-01 02:02:38	0|phantomcircuit|https://github.com/bitcoin/bitcoin/pull/9227/files
 18 2016-12-01 02:02:46	0|phantomcircuit|works fine as a static in the file
 19 2016-12-01 02:05:45	0|sipa|phantomcircuit: you're defining a static variable in a header file. this means that every cpp that includes this header gets its own instance of that variable
 20 2016-12-01 02:06:01	0|phantomcircuit|oh
 21 2016-12-01 02:06:05	0|phantomcircuit|yeah that's not right
 22 2016-12-01 02:06:12	0|phantomcircuit|git exploded and i put it there but yeah
 23 2016-12-01 02:06:41	0|phantomcircuit|fixed
 24 2016-12-01 02:07:19	0|phantomcircuit|what's there now is right and works
 25 2016-12-01 02:19:38	0|BlueMatt|argggg, sipa
 26 2016-12-01 02:19:48	0|BlueMatt|please dont rebase when you squash unless you need to :(
 27 2016-12-01 02:20:33	0|BlueMatt|that said, #8580 needs rebased again :p
 28 2016-12-01 02:20:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
 29 2016-12-01 02:29:04	0|sipa|BlueMatt: i needed to
 30 2016-12-01 02:29:09	0|BlueMatt|ahh, ok
 31 2016-12-01 02:29:22	0|sipa|i actually first updated without rebasing
 32 2016-12-01 02:29:27	0|sipa|and then it was grey in github
 33 2016-12-01 02:29:32	0|BlueMatt|there really needs to be a better way to say "give me the diff from a to b, ignoring signed-merge-commit changes"
 34 2016-12-01 02:29:41	0|BlueMatt|I need to build a script for that
 35 2016-12-01 02:29:45	0|sipa|yup
 36 2016-12-01 02:30:09	0|sipa|i'd say you do it by comparing a merge of the original with the new base with the rebase
 37 2016-12-01 02:31:52	0|BlueMatt|yea, probably
 38 2016-12-01 02:32:52	0|BlueMatt|you have to find a common fork point, though, by tracing back merge commits until you find the root of the two
 39 2016-12-01 02:33:02	0|BlueMatt|(ofc this assumes we continue to use git as if it were not git, but...whatever)
 40 2016-12-01 02:56:52	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9253: Fix calculation of number of bound sockets to use (06master...062016-11-nbind) 02https://github.com/bitcoin/bitcoin/pull/9253
 41 2016-12-01 03:25:12	0|Victorsueca|kaspersky is marking bitcoin-qt as coin stealing malware
 42 2016-12-01 03:25:54	0|Victorsueca|and in my case is compiled from source so... doubt it's a fake executable
 43 2016-12-01 03:26:22	0|sipa|sogh
 44 2016-12-01 03:26:24	0|sipa|sigh
 45 2016-12-01 03:26:55	0|achow101|Victorsueca: it's marked as coin stealing because it looks for a wallet.dat file :/
 46 2016-12-01 03:27:16	0|Victorsueca|achow101: lol
 47 2016-12-01 03:27:22	0|Victorsueca|404 logic not found
 48 2016-12-01 03:27:42	0|achow101|and sometimes they mark it as a bitcoin miner
 49 2016-12-01 03:28:32	0|Victorsueca|guess somebody will have to contact kaspersky so they whitelist it
 50 2016-12-01 04:21:05	0|phantomcircuit|Victorsueca, that sounds like it's doing the right thing actually
 51 2016-12-01 04:21:10	0|phantomcircuit|you compiled a binary yourself
 52 2016-12-01 04:21:12	0|phantomcircuit|so it's unique
 53 2016-12-01 04:21:16	0|phantomcircuit|which is trying to open wallet.dat
 54 2016-12-01 04:45:35	0|luke-jr|phantomcircuit: that's not the right thing to do :/
 55 2016-12-01 04:53:12	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #9254: [depends] ZeroMQ 4.2.0 (06master...06zeromq-4-2-0) 02https://github.com/bitcoin/bitcoin/pull/9254
 56 2016-12-01 06:05:08	0|rebroad|hi all. I've just identified a DoS vuln, which can crash the latest master
 57 2016-12-01 06:05:14	0|rebroad|want to report it responsibly
 58 2016-12-01 06:05:56	0|rebroad|I don't have PGP set up though..
 59 2016-12-01 06:06:07	0|rebroad|(have signal, telegram)
 60 2016-12-01 06:07:26	0|rebroad|given it was only recently introduced, I don't suppose it matters so much and could raise an issue for it
 61 2016-12-01 06:32:37	0|sipa|rebroad: if it's not in a release, it's likely fine to disclose
 62 2016-12-01 06:39:08	0|gmaxwell|I'm around now.
 63 2016-12-01 06:39:28	0|gmaxwell|q
 64 2016-12-01 07:00:22	0|paveljanik|rebroad, you do not need to have PGP to send mail to security@...
 65 2016-12-01 07:03:40	0|wumpus|why not set up a gpg key - everyone in this space does. But yes, if it is only in master you don't necessarily need to encrypt it
 66 2016-12-01 07:06:13	0|sipa|it's not like https://bitcoincore.org/en/contact/ lists an encryption key..
 67 2016-12-01 07:07:25	0|gmaxwell|we should probably encourage people to make initial vuln disclosures in private, even if not encrypted-- they might be wrong about where it applies.
 68 2016-12-01 07:07:49	0|gmaxwell|It would kinda suck for someone to report something 'in master' that also ended up in a recent backport release and was all over the network. :)
 69 2016-12-01 07:07:58	0|wumpus|I just mean that security@* is private enough
 70 2016-12-01 07:08:55	0|wumpus|and indeed we don't even list an encryption key there
 71 2016-12-01 07:09:06	0|gmaxwell|yea. indeed. well we should.
 72 2016-12-01 07:09:24	0|gmaxwell|I seem to recall some parties previously being opposed to that.
 73 2016-12-01 07:09:28	0|wumpus|how do you want to do that? a shared key?
 74 2016-12-01 07:10:26	0|sipa|gpg needs 1-of-n multisig encryption.
 75 2016-12-01 07:11:00	0|wumpus|I remember there's an open issue about adding an encryption key to the security reporting page, but no one could decide on a sensible approach
 76 2016-12-01 07:11:01	0|sipa|(it does of course, you can have multiple recipients, but you can't associate multiple keys with an email/identity)
 77 2016-12-01 07:11:06	0|gmaxwell|shared key would work fine. doesn't even need to be everyone, but should be more than one.
 78 2016-12-01 07:11:24	0|phantomcircuit|rebroad, i promise to act as 1-n for people i deem to be in the set
 79 2016-12-01 07:11:33	0|wumpus|we also don't necessarily want to reveal the list of people behind the alias, and having people encrypt to multiple recipients is meh anyway
 80 2016-12-01 07:11:35	0|phantomcircuit|"multisig as trust in patrick"
 81 2016-12-01 07:11:47	0|gmaxwell|sipa: unfortunately multiple recipents is too much to ask of the sender.
 82 2016-12-01 07:12:02	0|gmaxwell|probably we should have some webform on bitcoin-core.org that does gpg in the browser.
 83 2016-12-01 07:12:04	0|wumpus|it's too much to ask of the sender and it is an information leak in itself
 84 2016-12-01 07:12:05	0|sipa|this is what openssl does: https://www.openssl.org/news/vulnerabilities.html
 85 2016-12-01 07:12:27	0|gmaxwell|there is browser gpg..
 86 2016-12-01 07:12:29	0|sipa|(shared key, and suggests mailing individual members with their keys)
 87 2016-12-01 07:12:39	0|wumpus|gmaxwell: how is that more secure than just having a SSL-encrypted page?
 88 2016-12-01 07:13:14	0|gmaxwell|wumpus: because when its saved on the webserver the data doesn't lay around in a vulnerable form.
 89 2016-12-01 07:13:16	0|wumpus|I still don't buy this 'client side in the browser' stuff, not for wallets, but also not for this :)
 90 2016-12-01 07:13:22	0|gmaxwell|compromise is only point in time forward.
 91 2016-12-01 07:13:29	0|wumpus|well the websever could also encrypt it when it receives it
 92 2016-12-01 07:13:40	0|wumpus|I think we are overdesigining this
 93 2016-12-01 07:13:46	0|wumpus|let's generate a shared key?
 94 2016-12-01 07:14:13	0|sipa|sure
 95 2016-12-01 07:14:49	0|gmaxwell|Yes, though compromise is a little less detectable that way. (in any case I wouldn't even have mentioned it except I know there is prefab gpg-webform stuff) https://www.hanewin.net/encrypt/PGencode.htm
 96 2016-12-01 07:14:52	0|wumpus|I mean, this is like the alert system, there are tons of ideas but no one is going to implement one for the 1 in a year or so chance it's necessary
 97 2016-12-01 07:15:05	0|wumpus|s/chance/time/
 98 2016-12-01 07:15:44	0|wumpus|the only thing we receive on this security alias is support request crap even though it lists IN RED on the page that it shouln't be used for that
 99 2016-12-01 07:15:51	0|gmaxwell|sure. in any case, someone can do it if they have the time/interest.
100 2016-12-01 07:16:33	0|wumpus|and apparantly people that want to report issues rather blather in here in public telling everyone they found something instead of discretely sending a mail, which even unencrypted would be better than that
101 2016-12-01 07:17:39	0|gmaxwell|at least blabbing in here doesn't make it attractive to hack our email. :)
102 2016-12-01 07:18:24	0|rebroad|perhaps rather than using PGP keys we could use bitcoin address keys
103 2016-12-01 07:18:40	0|gmaxwell|that would only make things worse.
104 2016-12-01 07:18:42	0|wumpus|so instead of this meta talk, can you just let us know the issue please?
105 2016-12-01 07:18:50	0|gmaxwell|oh rebroad is here.
106 2016-12-01 07:18:56	0|rebroad|wumpus, ah, it was a false alarm (said above)
107 2016-12-01 07:19:15	0|wumpus|gah
108 2016-12-01 07:19:21	0|gmaxwell|rebroad: we missed where you said that.
109 2016-12-01 07:19:21	0|wumpus|*goes back to bed*
110 2016-12-01 07:19:29	0|rebroad|although i did lose internet shortly after so perhaps it didn't send
111 2016-12-01 07:19:35	0|gmaxwell|(doesn't show up in the logs)
112 2016-12-01 07:19:49	0|rebroad|this is the problem with IRC.. I never know which messages have sent :-s
113 2016-12-01 07:20:00	0|rebroad|why don't we use slack or something more "modern"?
114 2016-12-01 07:20:04	0|Lightsword|rebroad, use a bouncer
115 2016-12-01 07:20:09	0|Lightsword|then you can check logs on it
116 2016-12-01 07:20:10	0|wumpus|I never have that problem on IRC, my client reports when a message couldn't send.
117 2016-12-01 07:20:33	0|rebroad|wumpus, what client are you using please? I need to switch
118 2016-12-01 07:20:35	0|wumpus|no, we will not switch to a proprietary solution
119 2016-12-01 07:20:46	0|rebroad|wumpus, fair point. opensource is the way
120 2016-12-01 07:21:02	0|Lightsword|rebroad http://wiki.znc.in/ZNC
121 2016-12-01 07:21:04	0|rebroad|(and decentralized of course)
122 2016-12-01 07:21:04	0|sipa|i'm using irssi, running inside screen, on a vps
123 2016-12-01 07:21:15	0|wumpus|rebroad: I've used "quassel" and "irssi" and they both have that functionality
124 2016-12-01 07:21:17	0|Lightsword|znc lets you use a normal client with it
125 2016-12-01 07:21:55	0|rebroad|i hope no one actually got woken up to deal with this non-issue :-s
126 2016-12-01 07:22:17	0|wumpus|rebroad: exactly, IRC is much more in the spirit of bitcoin, though not decentralized it is a generic internet protocol that everyone can write clients for, some of better quality than others, but interoperability is key
127 2016-12-01 07:22:44	0|rebroad|didn't IRC used to be decentralized? i remember the days of the net splitting a lot and that doesn't seem to happen these days
128 2016-12-01 07:22:49	0|wumpus|well it didn't wake me up literally, i was awake, but it caused a stressful morning agian
129 2016-12-01 07:22:53	0|Lightsword|netsplits still happen
130 2016-12-01 07:22:58	0|sipa|rebroad: distributed doesn't mean decentralized
131 2016-12-01 07:23:11	0|sipa|you can't just run your own server and join the network
132 2016-12-01 07:23:18	0|sipa|you can start your own network however
133 2016-12-01 07:23:30	0|rebroad|I just spent a week meditating in a monastery - works well for stress - as does driving the road from Mae Hong Son to Pai - very beautiful part of Thailand
134 2016-12-01 07:23:39	0|gmaxwell|It also works really well with the toolset most of us use. Far better than slack (which I find has an infuratingly slow interface-- compared to anything non-browser I use), ignoring perhaps the occasional netsplit.
135 2016-12-01 07:24:02	0|wumpus|right, IRC *networks* are not decentralized, more like federated. IRC itself could be considered decentralized if you consider that everyone can create a network that's true...
136 2016-12-01 07:24:19	0|rebroad|although despite that I do have a twitching eye - too much coffee and not enough sleep I suspect. anyway.. OT!
137 2016-12-01 07:25:02	0|wumpus|gmaxwell: well you can use IRC to connect with slack - but anyhow let's not go there
138 2016-12-01 07:25:09	0|rebroad|wumpus, I do like how slack lets one quote previous messages..  sort of threading in a sense
139 2016-12-01 07:25:34	0|sipa|rebroad> wumpus, I do like how slack lets one quote previous messages..  sort of threading in a sense
140 2016-12-01 07:25:40	0|sipa|rebroad> wumpus, I do like how slack lets one quote previous messages..  sort of threading in a sense <- i can quote too :)
141 2016-12-01 07:25:40	0|wumpus|rebroad: nothing seems to work here, though I haven't tried going to a monastary I must admit :) I don't think I could.
142 2016-12-01 07:26:07	0|wumpus|yea here you can do the age-old thing for quoting: just copy/paste
143 2016-12-01 07:26:29	0|rebroad|I actually had not seen that message from wumpus about the monastery - so clearly I am losng messages recved too!
144 2016-12-01 07:27:24	0|wumpus|rebroad: and you didn't even disconnect in between
145 2016-12-01 07:27:30	0|rebroad|weird...
146 2016-12-01 07:27:34	0|wumpus|rebroad: looks more like a client issue than a network one
147 2016-12-01 07:27:42	0|Lightsword|maybe you should set up a cheap VPS and run a client from there
148 2016-12-01 07:27:42	0|wumpus|unless someone is MiTMing you
149 2016-12-01 07:28:20	0|rebroad|using hexchat - prett standard on linux
150 2016-12-01 07:28:54	0|Lightsword|well if you run it over ssh on a cheap VPS with a reliable connection  you shouldn’t get dropouts
151 2016-12-01 07:29:04	0|Lightsword|and if ssh is unreliable you can even use mosh
152 2016-12-01 07:29:11	0|sipa|i use mosh
153 2016-12-01 07:29:14	0|wumpus|mosh <3
154 2016-12-01 07:29:46	0|rebroad|oh ignore me.. I am losing my mind obviously. sipa didn't quote wumpus's comment about the monastery - it was wumpus's actual comment :-s
155 2016-12-01 07:30:12	0|rebroad|sandwiches between two quotes
156 2016-12-01 07:30:16	0|gmaxwell|with how unreliable rebroad's connection has been in the past, I bet he'd like mosh.
157 2016-12-01 07:30:21	0|rebroad|s/sandwiches/sandwiched
158 2016-12-01 07:30:26	0|wumpus|another false positive :p need to be more careful in checking things
159 2016-12-01 07:30:37	0|rebroad|anothing thing I like about slack - i can edit spelling mistakes
160 2016-12-01 07:30:41	0|rebroad|(or telegram, etc)
161 2016-12-01 07:30:54	0|rebroad|somethng opensource like telegram would be nice - they have group chats on there
162 2016-12-01 07:31:00	0|gmaxwell|msitakes?
163 2016-12-01 07:31:04	0|gmaxwell|s/msitakes/mistakes/
164 2016-12-01 07:31:22	0|wumpus|well it won't just let you edit spelling mistakes, also other mistakes, or retroactively change statements/opinions
165 2016-12-01 07:31:24	0|rebroad|heh.. just need a front-end to parse those "s/" messages!
166 2016-12-01 07:31:27	0|paveljanik|gmaxwell, :-) You s/yes/no/.
167 2016-12-01 07:31:34	0|wumpus|"we've always been at war with eurasia"
168 2016-12-01 07:31:55	0|rebroad|anyway, enough of this silliness^H^H^H^H^H^H^H^H^H^Husefulness
169 2016-12-01 07:32:08	0|gmaxwell|the editing features are nice until they're not. very confusing when you read something and then its edited and then later you cant figure out where you read the original thing. :)
170 2016-12-01 07:32:23	0|sipa|stackexchange lets you modify comments for up to a few minutes
171 2016-12-01 07:32:28	0|wumpus|just need a front-end to parse those "s/" messages <- haha that'd be fun
172 2016-12-01 07:32:29	0|sipa|which is very useful
173 2016-12-01 07:32:48	0|wumpus|too much bother to implement though, seems my brain works well enough as a parser/frontend for that
174 2016-12-01 07:32:49	0|sipa|i have a few plugins in my irc client
175 2016-12-01 07:32:56	0|rebroad|RBF for chat :)
176 2016-12-01 07:33:03	0|sipa|mff fppppfpppmpmmpppff fppmfpppf mfpmpppffmpp fmfpppmpmmpppfffmmfmpmmmpppmpmfmm pmpmppppppppffm
177 2016-12-01 07:33:22	0|rebroad|sipa wtf?
178 2016-12-01 07:33:23	0|wumpus|gmaxwell: yeah you can do a full fledged chat by just editing two messages
179 2016-12-01 07:33:35	0|rebroad|sipa is that dinosaur dna?
180 2016-12-01 07:33:46	0|sipa|rebroad: it's a code called "kenny" which turns text into only [fmp ]
181 2016-12-01 07:33:53	0|rebroad|ahhh!
182 2016-12-01 07:33:59	0|sipa|and with a plugin it gets decoded automatically
183 2016-12-01 07:34:09	0|rebroad|lol
184 2016-12-01 07:34:16	0|sipa|ǝuo sıɥʇ ǝʞıʃ 'sɹǝɥʇo ʍǝɟ ɐ ǝʌɐɥ ı
185 2016-12-01 07:35:41	0|rebroad|the upsidedown l looks suspect
186 2016-12-01 07:35:57	0|rebroad|lol
187 2016-12-01 07:36:16	0|rebroad|wumpus, you needed to wait for 6 conformations for it to count
188 2016-12-01 07:36:23	0|sipa|PC LOAD LETTER
189 2016-12-01 07:36:27	0|rebroad|s/conformations/confirmations
190 2016-12-01 07:36:48	0|gmaxwell|/exec -o <command> runs an arbritary command in most clients and puts it into IRC... envy plugins no more...
191 2016-12-01 07:36:55	0|gmaxwell|123456789011: 123456789011
192 2016-12-01 07:37:04	0|gmaxwell|^ see, factor
193 2016-12-01 07:37:08	0|rebroad|I'll confirm the use of the word kerfuffle though
194 2016-12-01 07:37:29	0|Lightsword|hmm, I think znc actually has a plugin that lets you execute shell commands over IRC
195 2016-12-01 07:37:49	0|gmaxwell|disquiet's
196 2016-12-01 07:37:53	0|gmaxwell|/exec -o shuf -n1 /usr/share/dict/words
197 2016-12-01 07:38:31	0|sipa|<sipa> exasperated
198 2016-12-01 07:38:38	0|sipa|(first try)
199 2016-12-01 07:38:59	0|sipa|wumpus: the context was that you were going back to sleep
200 2016-12-01 07:39:51	0|rebroad|hmmm.. blockchain based chat...  now that would be decentralized properly..
201 2016-12-01 07:40:02	0|sipa|try bitmessage
202 2016-12-01 07:40:28	0|rebroad|sipa, any advantage over IRC?
203 2016-12-01 07:40:33	0|sipa|no
204 2016-12-01 07:40:42	0|wumpus|and puts the burden of storing your logs on everyone on the network - yea, that'd work
205 2016-12-01 07:40:51	0|sipa|and not sure if you're serious, but public blockchains don't actually work without the incentive of subsidy
206 2016-12-01 07:41:11	0|sipa|which makes non-currency use pretty unsustainable
207 2016-12-01 07:41:12	0|rebroad|sipa, speaking of that. dash has more nodes than bitcoin due to that I think
208 2016-12-01 07:41:45	0|gmaxwell|bitmessage isn't a blockchain, its a hashcash ratelimited flooding network.
209 2016-12-01 07:41:47	0|rebroad|and they are funding quite a few things from the blockchain also
210 2016-12-01 07:41:53	0|wumpus|meh, bitmessage is used for some private communication, it's basically a "dead drop". I don't know how effective it actually is at that though given the small number of users.
211 2016-12-01 07:42:20	0|gmaxwell|rebroad: please don't talk about dash here.
212 2016-12-01 07:42:39	0|rebroad|they *cough* hard-forked *cough* a few times to get that in place though - I am surprised the miners (who were getting 90%) went along with it
213 2016-12-01 07:42:50	0|wumpus|but if used through tor I guess it's pretty hard to do metadata analysis
214 2016-12-01 07:43:07	0|rebroad|gmaxwell, just referring to it as an example in the context of what sipa just said
215 2016-12-01 07:43:52	0|luke-jr|rebroad: don't confuse "works so far" with "can be relied on"; often scamcoins work only because nobody has bothered to attack them
216 2016-12-01 07:44:07	0|rebroad|gmaxwell, it's ok to talk about bitmessage but not dash?
217 2016-12-01 07:44:32	0|rebroad|luke-jr, good point indeed
218 2016-12-01 07:44:38	0|sipa|this whole discussion is off topic now
219 2016-12-01 07:44:46	0|rebroad|luke-jr, although are you meaning to imply dash is a scamcoin?
220 2016-12-01 07:45:01	0|wumpus|altcoins are decidedly off-topic here, alternative communication methods for developers, well meh it doesn't hurt to have that discussion once ina while when we feel like it.
221 2016-12-01 07:45:16	0|wumpus|but yes it's done
222 2016-12-01 07:45:18	0|wumpus|back to coding
223 2016-12-01 07:45:24	0|luke-jr|rebroad: we can discuss that further in ##altcoin-dev if you wish, but I'd suggest it's a distraction
224 2016-12-01 07:45:33	0|rebroad|sipa, it is drifting occaionally OT but comes back to bitcoin often enough :)
225 2016-12-01 07:46:30	0|rebroad|I do perceive an over-sensitivity to the conversation drifting to altcoins when they are relevant to the current context, as bitmessage was
226 2016-12-01 07:46:47	0|gmaxwell|In general I would prever to not talk about altcoins here. Beyond it being offtopic, saying negative things about some altcoins has been known to get people harassed.
227 2016-12-01 07:47:26	0|gmaxwell|And personally I find it somewhat stressful when someone is wrong about something on the internet and I can't even reply without knowing it's just going to create trouble for me.
228 2016-12-01 07:47:47	0|wumpus|tldr: it's a waste of everyone's attention here
229 2016-12-01 07:48:44	0|wumpus|too easy to get into fights, people feel too strongly about those things, this is a no-politics channel
230 2016-12-01 07:49:18	0|rebroad|how about barring strong feelings AND politics? and just being able to talk about possible features without fear of attack?
231 2016-12-01 07:49:29	0|wumpus|please take it elsewhere
232 2016-12-01 07:49:41	0|rebroad|"it"?
233 2016-12-01 07:49:46	0|wumpus|yes. This whole thread.
234 2016-12-01 07:49:53	0|luke-jr|rebroad: ##altcoin-dev is a real channel you can discuss said things in
235 2016-12-01 07:50:07	0|rebroad|I have lost the thread by now
236 2016-12-01 07:50:39	0|rebroad|I am not clear on what thread is being referred to nor what are the taboo subjects
237 2016-12-01 07:50:50	0|sipa|altcoins are definitely off topic
238 2016-12-01 07:51:24	0|sipa|(in this specific channel; there is #bitcoin-wizards for example for exotic ideas that may or may not make it into bitcoin some day)
239 2016-12-01 07:51:29	0|wumpus|"Bitcoin Core development discussion and commit log"
240 2016-12-01 07:51:30	0|rebroad|sipa, so you mean mentioning them by name?
241 2016-12-01 07:51:58	0|luke-jr|rebroad: there is no context on topic to this channel where mentioning them by name would make sense.
242 2016-12-01 07:52:14	0|rebroad|I am also unsure what the definition of "altcoin" is
243 2016-12-01 07:52:15	0|sipa|we used to have a link to channel rules
244 2016-12-01 07:52:22	0|sipa|rebroad: other cryptocurrencies
245 2016-12-01 07:52:24	0|wumpus|rebroad: go discuss that elsewhere
246 2016-12-01 07:52:33	0|sipa|now, let's get back to development
247 2016-12-01 07:52:36	0|wumpus|this is also not the meta-channel "what to discuss in #bitcoin-core-dev"
248 2016-12-01 07:53:40	0|rebroad|wumpus, the conversation flowed to this - it was a co-creation we all had a part in that. anyway, i agree. where is that meta channel?
249 2016-12-01 07:54:07	0|luke-jr|#bitcoin is as meta as I know of
250 2016-12-01 07:55:47	0|rebroad|or #bitcoin-dev I'd have thought, since development is the key desire to talk about
251 2016-12-01 07:57:35	0|rebroad|but I don't desire to have that meta conversation really. I'd rather talk about core development, which is why I am here - but I will refrain from mentioning the names of "altcoins" even though I don't understand why not, nor what "altcoins" are yet, so it's kind of impossible to make assurances at this stage given that.
252 2016-12-01 07:57:36	0|luke-jr|general & meta=#bitcoin ; bitcoin development=#bitcoin-dev ; Core dev=#bitcoin-core-dev ; wiki=#bitcoin-wiki ; trading=#bitcoin-otc ; far future dev & hardforks = #bitcoin-wizards ; mining=#bitcoin-mining ; altcoins=##altcoin-dev
253 2016-12-01 07:57:57	0|jonasschnelli|sipa: In case you once start with BIP150 (I know you'll wait until the net refactor has been completed), here is the extracted ChaCha20Poly1305AEAD code from openssh: https://github.com/jonasschnelli/chacha20poly1305
254 2016-12-01 07:59:20	0|rebroad|I have attempted to seek clarification previously on a clear and concise definition of "altcoin" and raised an issue both on the bitcoin project and for bitcoin.org to address this
255 2016-12-01 07:59:33	0|luke-jr|rebroad: seek clarification in #bitcoin, not here
256 2016-12-01 07:59:47	0|rebroad|so it is really frustrating to come up against this again given all the proactivity so far
257 2016-12-01 08:00:31	0|sipa|rebroad: again, please don't see a "go discuss this elsewhere" as "don't discuss this". people _are_ very willing to discuss these things and the reasons behind it. but not here.
258 2016-12-01 08:01:22	0|rebroad|sipa, thank you for that clarification. EOT
259 2016-12-01 08:36:13	0|jonasschnelli|sipa: why would it break backwards compatibility?
260 2016-12-01 08:36:19	0|jonasschnelli|(remove of the default key)
261 2016-12-01 08:36:36	0|jonasschnelli|Because of fFirstRunRet?
262 2016-12-01 08:36:40	0|sipa|jonasschnelli: yup
263 2016-12-01 08:36:50	0|jonasschnelli|hmm..
264 2016-12-01 08:37:20	0|sipa|specifically, not having a default key in a wallet file would cause it to write the current chainstate
265 2016-12-01 08:37:28	0|sipa|and thus potentially miss a rescan
266 2016-12-01 08:37:52	0|sipa|writing a dummy default key... could result in the old wallet giving it out as address
267 2016-12-01 08:38:15	0|luke-jr|what's the harm in having a dummy default key that's actually in the wallet? O.o
268 2016-12-01 08:38:30	0|jonasschnelli|I don't like the default key for two reasons...
269 2016-12-01 08:38:32	0|sipa|luke-jr: that's basically what we have now :D
270 2016-12-01 08:38:38	0|jonasschnelli|1) seems to be unused/miused
271 2016-12-01 08:38:42	0|luke-jr|exactly; I miss context as to why it should change
272 2016-12-01 08:38:48	0|jonasschnelli|2) I want to have a private-key free wallet mode
273 2016-12-01 08:38:57	0|luke-jr|jonasschnelli: just pretend it isn't there?
274 2016-12-01 08:39:00	0|sipa|luke-jr: technical debt
275 2016-12-01 08:39:29	0|jonasschnelli|We probably should have removed it with 0.13 hd wallets (not backward comp.)
276 2016-12-01 10:46:08	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9255: qt: layoutAboutToChange signal is called layoutAboutToBeChanged (06master...062016_12_qt_signals_warnings) 02https://github.com/bitcoin/bitcoin/pull/9255
277 2016-12-01 10:48:11	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3bf06e9bac57...c79e52ad304a
278 2016-12-01 10:48:12	0|bitcoin-git|13bitcoin/06master 14507145d 15Matt Corallo: Fix race when accessing std::locale::classic()...
279 2016-12-01 10:48:12	0|bitcoin-git|13bitcoin/06master 148b22efb 15Matt Corallo: Make fStartedNewLine an std::atomic_bool...
280 2016-12-01 10:48:13	0|bitcoin-git|13bitcoin/06master 14c79e52a 15Wladimir J. van der Laan: Merge #9230: Fix some benign races in timestamp logging...
281 2016-12-01 10:48:27	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9230: Fix some benign races in timestamp logging (06master...062016-11-loglocks) 02https://github.com/bitcoin/bitcoin/pull/9230
282 2016-12-01 12:16:36	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9256: Fix more CWallet/CWalletDB layer violations (06master...062016/12/ref_walletdb) 02https://github.com/bitcoin/bitcoin/pull/9256
283 2016-12-01 12:18:41	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/9143
284 2016-12-01 15:12:25	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9257: [qa] Dump debug logs on travis failures. (06master...06travis-debug-logs) 02https://github.com/bitcoin/bitcoin/pull/9257
285 2016-12-01 18:39:29	0|bitcoin070|anyone else having nuclear problems with bitcoin core 0.13.1?
286 2016-12-01 18:40:00	0|sipa|elaborate?
287 2016-12-01 18:40:14	0|wumpus|nuclear problems, wow
288 2016-12-01 18:40:30	0|bitcoin070|unfortunately wumpus
289 2016-12-01 18:40:31	0|bitcoin070|yes
290 2016-12-01 18:40:38	0|bitcoin070|I will elaborate in a minute here
291 2016-12-01 18:40:44	0|sipa|what version were you using that worked, what system specifications, what used to work, what does not?
292 2016-12-01 18:40:50	0|bitcoin070|sipa/wumpus
293 2016-12-01 18:40:57	0|bitcoin070|some very unfortunate behavior on m3.mediums on Amazon EC2
294 2016-12-01 18:41:02	0|wumpus|it's not recommended to use it on nuclear reactors
295 2016-12-01 18:41:19	0|bitcoin070|I have three separate instances and four different occasions now ....
296 2016-12-01 18:41:23	0|bitcoin070|extremely bad
297 2016-12-01 18:41:31	0|bitcoin070|on phone call but will elaborate fully in a moment
298 2016-12-01 18:41:31	0|sipa|can you please explain what is going on?
299 2016-12-01 18:41:53	0|wumpus|what is so nuclear about that?
300 2016-12-01 18:42:12	0|bitcoin070|essentially some form of mempool corruption where the bitcoin-cli getbalance / getinfo reads 0
301 2016-12-01 18:42:19	0|bitcoin070|but bitcoin-cli getbalance "" reads the true balance
302 2016-12-01 18:42:25	0|bitcoin070|RPC calls to sendtoaddress return insufficient balance
303 2016-12-01 18:42:32	0|bitcoin070|also .. the mega bad fuck up is
304 2016-12-01 18:42:53	0|sipa|what version were you using before?
305 2016-12-01 18:42:56	0|bitcoin070|as the behavior starts to unravel
306 2016-12-01 18:43:08	0|bitcoin070|bitcoind will return TXID that don't reflect on the network
307 2016-12-01 18:43:16	0|bitcoin070|and then when rebooting the node
308 2016-12-01 18:43:25	0|bitcoin070|it can result in some very unexpected behavior
309 2016-12-01 18:43:28	0|bitcoin070|0.12 before
310 2016-12-01 18:43:39	0|bitcoin070|the only thing that is off on these boxes was the time -- 7 minutes or so
311 2016-12-01 18:44:01	0|bitcoin070|as the VPS aren't running ntpdate
312 2016-12-01 18:44:01	0|sipa|that's unlikely to be a problem
313 2016-12-01 18:44:05	0|bitcoin070|agreed
314 2016-12-01 18:44:23	0|bitcoin070|bitcoin-cli getinfo {   "version": 130100,   "protocolversion": 70014,   "walletversion": 130000,   "balance": 0.00107642,   "blocks": 441461,   "timeoffset": -432,   "connections": 29,   "proxy": "",   "difficulty": 281800917193.1958,   "testnet": false,   "keypoololdest": 1480563469,   "keypoolsize": 100,   "paytxfee": 0.00000000,   "relayfee": 0.00001000,   "errors": "" }
315 2016-12-01 18:44:33	0|bitcoin070|bitcoin-cli getbalance "" 34.71912966
316 2016-12-01 18:44:43	0|bitcoin070|this is the 4th time this has happened
317 2016-12-01 18:44:53	0|bitcoin070|when it happened previously, I modified bitcoin.conf on these two boxes to limit mempool, outbound connections, etc
318 2016-12-01 18:45:08	0|bitcoin070|mempool=150, dbcache=70
319 2016-12-01 18:45:14	0|bitcoin070|fwiw I never once had a problem with bitcoind before
320 2016-12-01 18:45:38	0|sipa|my guess is that your funds are tied up in unconfirmed change
321 2016-12-01 18:45:47	0|sipa|which is being kicked out of the mempool
322 2016-12-01 18:45:55	0|bitcoin070|but these transactions are all recent
323 2016-12-01 18:46:05	0|bitcoin070|why would they be getting kicked out of the mempool, should mempool not prioritize my own TX?
324 2016-12-01 18:46:15	0|wumpus|do you have spendzeroconfchange set to 0 perhaps?
325 2016-12-01 18:46:27	0|bitcoin070|nope
326 2016-12-01 18:46:34	0|bitcoin070|sorry to sound brash guys but i am a power user
327 2016-12-01 18:46:38	0|bitcoin070|been running nodes for 3+ years
328 2016-12-01 18:46:42	0|bitcoin070|well-versed in bitcoin.conf
329 2016-12-01 18:46:46	0|sipa|maybe too long chains of unconfirmed transactions?
330 2016-12-01 18:47:00	0|sipa|how many unconfirmed outgoing transactions do you have?
331 2016-12-01 18:47:18	0|bitcoin070|I think that's it
332 2016-12-01 18:47:33	0|bitcoin070|sipa there's no good way to tell as the node becomes completely nonsensical
333 2016-12-01 18:47:42	0|bitcoin070|listunspent 0 doesn't even show the outputs
334 2016-12-01 18:47:49	0|bitcoin070|the only thing I can do is track it back in a block explorer
335 2016-12-01 18:48:01	0|sipa|listtransactions should list them
336 2016-12-01 18:48:03	0|wumpus|if it's an unconfirmed change problem then it should resolve itself after the transactions are confirmed
337 2016-12-01 18:48:40	0|morcos|what does getunconfirmedbalance say
338 2016-12-01 18:49:33	0|bitcoin070|so
339 2016-12-01 18:49:41	0|bitcoin070|there is a large large amount of unconfirmed spending unconfirmed
340 2016-12-01 18:49:43	0|bitcoin070|however
341 2016-12-01 18:49:45	0|bitcoin070|annoyingly, for instance
342 2016-12-01 18:49:51	0|bitcoin070|bitcoin-cli getmempooldescendants 10d6ab99beb58c22197c3ba0f2072ea2275660fbc03c8f1cff444247faa86d0e
343 2016-12-01 18:49:55	0|bitcoin070|returns an empty array
344 2016-12-01 18:50:38	0|bitcoin070|sorry
345 2016-12-01 18:50:41	0|bitcoin070|maybe not a good example let me find one
346 2016-12-01 18:51:21	0|bitcoin070|bitcoin-cli getmempoolancestors e2f2ff83b69a1b11e735cc4fac0a2b00d9eb3641913a3dbdd52043ca8f7b0ad7
347 2016-12-01 18:53:24	0|bitcoin070|so, I found a TX with 19 ancestors that are unconfirmed
348 2016-12-01 18:54:07	0|bitcoin070|bitcoin-cli getmempoolancestors 4c4dd9034d215a95dd951901271f38aaa02f14cf4be0150e2a1d4c7996aa710b
349 2016-12-01 18:54:10	0|bitcoin070|they are in the mempool though
350 2016-12-01 18:54:18	0|bitcoin070|it returns all 19 true txid
351 2016-12-01 18:54:54	0|bitcoin070|so, whatever is causing this, it's dangerous behavior and never happened before because
352 2016-12-01 18:55:03	0|bitcoin070|a lot of scripts and daemons are monitoring bitcoin node balance
353 2016-12-01 18:55:12	0|gmaxwell|bitcoin070: I suggest downgrading to 0.12.1, which will behave the same but will confirm that there is nothing new going on.
354 2016-12-01 18:55:29	0|bitcoin070|and when it goes from XXX to 0 without any transactions it starts a lot of commotion unfortunately
355 2016-12-01 18:56:11	0|bitcoin070|we want to support segwit, want HD wallet, etc
356 2016-12-01 18:56:27	0|wumpus|sounds like the whole chain of transactions was evicted
357 2016-12-01 18:56:54	0|gmaxwell|In prior attempts to assist you, going back a month ago, I was unable to extract the information I needed to make sense of your reports. If you have the patience now to work through things thats great, though we're about to begin a meeting in here.
358 2016-12-01 18:56:55	0|sipa|a larger max mempool size may help to avoid that
359 2016-12-01 18:57:07	0|wumpus|are you overriding fee or using the smart fee estimate?
360 2016-12-01 18:57:18	0|bitcoin070|not doing anything with fees
361 2016-12-01 18:57:28	0|bitcoin070|just letting the node handle it
362 2016-12-01 18:57:45	0|bitcoin070|I have all the time in the world, obviously I don't want to interrupt your meeting but
363 2016-12-01 18:57:52	0|bitcoin070|FWIW, BitGo is having issues right now too
364 2016-12-01 18:57:57	0|sipa|though i'm not sure what the correct behaviour in this case is... you effectively don't have spendable balance until those transactions confirm
365 2016-12-01 18:58:05	0|sipa|or you abandon them
366 2016-12-01 18:58:08	0|bitcoin070|their node is returning a TXID which is also not propagating the network
367 2016-12-01 18:58:08	0|wumpus|if you can queue up sends then use a sendmany you'd prevent nesting transactions so deeply
368 2016-12-01 18:58:36	0|bitcoin070|wumpus/sipa: interestingly though this only started becoming problematic in bitcoin core
369 2016-12-01 18:58:46	0|bitcoin070|sorry I mean 0.13
370 2016-12-01 18:58:51	0|sipa|bitcoin070: network conditions change all the time
371 2016-12-01 18:59:00	0|gmaxwell|bitcoin070: nothing about this was changed in 0.13, AFAIR.
372 2016-12-01 18:59:11	0|sipa|my guess is that this is just due to interaction with the limited mempool, not the new bitcoin core version
373 2016-12-01 18:59:12	0|sdaftuar|i think we do have an issue to fix, in that we should make it harder for the wallet to generate a transaction that violates the ancestor/descendant chain limits, right?
374 2016-12-01 18:59:16	0|sdaftuar|wasn't there a PR relating to that?
375 2016-12-01 18:59:19	0|sipa|sdaftuar: agree
376 2016-12-01 18:59:37	0|bitcoin070|damn, it's just strange because
377 2016-12-01 18:59:37	0|gmaxwell|We do, I believe I created that in response to this person.
378 2016-12-01 18:59:49	0|bitcoin070|I didn't see this ever happen in .12
379 2016-12-01 18:59:56	0|sipa|i believe that
380 2016-12-01 18:59:57	0|bitcoin070|I know network conditions aren't static, etc
381 2016-12-01 19:00:14	0|bitcoin070|so you're saying the root cause is too long of unconfirmed chain
382 2016-12-01 19:00:26	0|instagibbs|meeting taimu
383 2016-12-01 19:00:26	0|wumpus|if there is a PR for that, it'd make sense for bitcoin070 to test that
384 2016-12-01 19:00:28	0|sipa|or an evicted chain
385 2016-12-01 19:00:34	0|BlueMatt|meeting?
386 2016-12-01 19:00:34	0|lightningbot|Meeting started Thu Dec  1 19:00:33 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
387 2016-12-01 19:00:34	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
388 2016-12-01 19:00:34	0|wumpus|#startmeeting
389 2016-12-01 19:00:39	0|sipa|present
390 2016-12-01 19:00:41	0|bitcoin070|sipa -- evicted meaning what exactly?
391 2016-12-01 19:00:46	0|bitcoin070|sorry guys I don't want to interrupt
392 2016-12-01 19:00:50	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
393 2016-12-01 19:00:54	0|jonasschnelli|here
394 2016-12-01 19:01:00	0|btcdrak|here
395 2016-12-01 19:01:00	0|kanzure|hi.
396 2016-12-01 19:01:02	0|cfields|here
397 2016-12-01 19:01:03	0|paveljanik|Hi
398 2016-12-01 19:01:04	0|achow101|hi
399 2016-12-01 19:01:14	0|wumpus|bitcoin070: evicted because they pay the least fee/kb of the transactions in the mempool and the maximum size is reached, you can increase the maximum mempool size though
400 2016-12-01 19:01:31	0|michagogo|Oh, right, now that I'm in the U.S. these are in the early afternoon
401 2016-12-01 19:01:31	0|morcos|bitcoin070: please if you file an issue about this include the output of getbalance() and getunconfirmedbalance() without giving any accounts
402 2016-12-01 19:01:41	0|bitcoin070|okay
403 2016-12-01 19:01:46	0|bitcoin070|fwiw, bitcoin-cli estimatefee 1 returns -1
404 2016-12-01 19:01:53	0|morcos|both "" and "*" when used as the account, give different answers than putting nothing in for the account
405 2016-12-01 19:01:54	0|wumpus|anyhow, meeting started. Any proposed topics?
406 2016-12-01 19:01:57	0|morcos|bitcoin070: expected
407 2016-12-01 19:02:09	0|wumpus|bitcoin070: yes, that is known behavior
408 2016-12-01 19:02:12	0|bitcoin070|okay
409 2016-12-01 19:02:15	0|bitcoin070|2 and 3 are okay
410 2016-12-01 19:02:30	0|bitcoin070|should these unconfirmed chains eventually confirm and the balance will correct?
411 2016-12-01 19:02:36	0|gmaxwell|wumpus: What issues do people feel aren't getting attention right now?
412 2016-12-01 19:03:23	0|wumpus|gmaxwell: in what regard?
413 2016-12-01 19:03:34	0|paveljanik|review etc.
414 2016-12-01 19:03:38	0|gmaxwell|like PRs and what not, proposed topic: does anyone need some love.
415 2016-12-01 19:04:15	0|wumpus|bitcoin070: re: estimatefee returning -1 there's an issue about that: https://github.com/bitcoin/bitcoin/issues/9106
416 2016-12-01 19:04:23	0|bitcoin070|thanks guys
417 2016-12-01 19:04:25	0|bitcoin070|I'll wait and see what happens here
418 2016-12-01 19:04:29	0|bitcoin070|thanks again
419 2016-12-01 19:04:35	0|BlueMatt|so #9183 is proabbly ready for merge after travis passes, means we need to discuss when to do The(tm) split
420 2016-12-01 19:04:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/9183 | Final Preparation for main.cpp Split by TheBlueMatt · Pull Request #9183 · bitcoin/bitcoin · GitHub
421 2016-12-01 19:04:38	0|sipa|i have a short topic for later, about vchDefaultKey (walking to office right now)
422 2016-12-01 19:04:40	0|wumpus|wallet PRs need review at least
423 2016-12-01 19:04:52	0|wumpus|espeically the multiwallet ones
424 2016-12-01 19:04:58	0|jonasschnelli|Yes. An HD.
425 2016-12-01 19:05:00	0|gmaxwell|The test before evict PR seems to be being forgotten a bit.
426 2016-12-01 19:05:05	0|jonasschnelli|We need a restore feature.
427 2016-12-01 19:05:24	0|jonasschnelli|We shouldn't keep users to long in the dark about how they can restore a HD wallet
428 2016-12-01 19:05:35	0|jonasschnelli|Would be nice to have something in 0.14
429 2016-12-01 19:05:48	0|wumpus|vchDefaultKey should die
430 2016-12-01 19:05:58	0|jonasschnelli|heh. Lets discuss that when sipa is back
431 2016-12-01 19:06:10	0|morcos|Now is probably a good time to do a thorough evaluation of which PR's need 0.14.0 milestone...  who should we ping if we want someone to mark a PR?
432 2016-12-01 19:06:40	0|wumpus|sipa: re: vchDefaultkey I once created this issue: https://github.com/bitcoin/bitcoin/issues/8416
433 2016-12-01 19:06:45	0|BlueMatt|morcos: usually fanquake is pretty on top of it if you mention it in the pr or leave a note on here
434 2016-12-01 19:07:55	0|wumpus|usually if you just ask in teh channel someone will do it
435 2016-12-01 19:08:04	0|jonasschnelli|Tag #9239 for 0.14? IMO we should
436 2016-12-01 19:08:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/9239 | Disable fee estimates for 1 block target by morcos · Pull Request #9239 · bitcoin/bitcoin · GitHub
437 2016-12-01 19:08:11	0|gmaxwell|BlueMatt: do you have any more big wads of data race fixes.
438 2016-12-01 19:08:18	0|bitcoin070|guys I agree 100% we need an HD wallet restore feature
439 2016-12-01 19:08:22	0|gmaxwell|jonasschnelli: we should.
440 2016-12-01 19:08:25	0|morcos|jonasschnelli: definitely
441 2016-12-01 19:08:29	0|bitcoin070|I would make that top priority
442 2016-12-01 19:08:42	0|morcos|bitcoin070: ha ha, it'll just make it always give -1
443 2016-12-01 19:08:52	0|bitcoin070|:)
444 2016-12-01 19:08:58	0|BlueMatt|gmaxwell: I think not...maybe one or two more that I should PR and then net things, but since net is in the middle of so mouch touching I dont want to step all over cfields' toes trying to fix things he already has fixes for
445 2016-12-01 19:09:26	0|gmaxwell|BlueMatt: have you advised cfields about the racy things you found there?
446 2016-12-01 19:09:28	0|BlueMatt|to we have topics?
447 2016-12-01 19:09:35	0|BlueMatt|yes, we've been discussing them
448 2016-12-01 19:09:45	0|morcos|answering your own question?
449 2016-12-01 19:09:52	0|BlueMatt|topics? or are we meeting-chat-time-ing?
450 2016-12-01 19:10:00	0|gmaxwell|I'd like to discuss #9194
451 2016-12-01 19:10:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/9194 | Add option to return non-segwit serialization via rpc by instagibbs · Pull Request #9194 · bitcoin/bitcoin · GitHub
452 2016-12-01 19:10:07	0|cfields|gmaxwell: yes, i'm nuking things in parallel. Simple atomic changes aren't interrupting anything of mine
453 2016-12-01 19:10:11	0|BlueMatt|I'd like to discuss when to do The Main Split
454 2016-12-01 19:10:11	0|kanzure|morcos: he means he is answering the 'racy' question
455 2016-12-01 19:10:40	0|wumpus|#topic Non-segwit serialization vai rpc (#9194)
456 2016-12-01 19:10:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/9194 | Add option to return non-segwit serialization via rpc by instagibbs · Pull Request #9194 · bitcoin/bitcoin · GitHub
457 2016-12-01 19:11:24	0|gmaxwell|Thanks, where are we on this? (the change to let the rawtxn returning rpcs return witness stripped results) I think it's moderately important but there seemed to be some disagreement on the general direction.
458 2016-12-01 19:11:59	0|cfields|wumpus: as part of your named-arg PR, did you consider allowing any global named args?
459 2016-12-01 19:12:05	0|sdaftuar|gmaxwell: initially i wasn't a huge fan of it, but it ended up being less work than i thought, so i don't really care if we do it
460 2016-12-01 19:12:20	0|gmaxwell|sdaftuar: okay, it was mostly you I was concerned about.
461 2016-12-01 19:12:22	0|cfields|where for ^^, any command could accept a "serialversion" named arg
462 2016-12-01 19:12:37	0|wumpus|cfields: we're in a meeting
463 2016-12-01 19:12:38	0|sdaftuar|"sdaftuar was here"  i did mean to review the test changes though
464 2016-12-01 19:12:59	0|cfields|wumpus: eh? I was referencing 9194 :)
465 2016-12-01 19:12:59	0|instagibbs|sdaftuar, yes i basically failed to remember how the commitment worked :) thanks for the review
466 2016-12-01 19:13:03	0|gmaxwell|wumpus: that is directly relevant here. :)
467 2016-12-01 19:13:37	0|gmaxwell|okay, if sdaftuar is not concerned about it,  -- instagibbs are you waiting for anything there or just more review?
468 2016-12-01 19:13:42	0|wumpus|cfields: well that's not implemented in my pull, could be added later on I guess if you need "context" arguments
469 2016-12-01 19:14:01	0|instagibbs|gmaxwell, more review I think. Want to make sure it doesn't screw up anything I don't touch often
470 2016-12-01 19:14:09	0|wumpus|cfields: I don't have any problem with the idea at least.
471 2016-12-01 19:14:13	0|instagibbs|(ie zmq/rest suggestion)
472 2016-12-01 19:14:37	0|instagibbs|I think the tests actually work now, so confident on rpc side
473 2016-12-01 19:14:41	0|gmaxwell|instagibbs: okay, sounds good to me then. I'll be happy to test and review.
474 2016-12-01 19:14:57	0|instagibbs|great
475 2016-12-01 19:16:22	0|petertodd|re: luke-jr's point on "stripped sigs", lots of code gets written that calculates its own txids and isn't using the RPC for that, e.g. python-bitcoinlib RPC code would likely do that, so stripped sigs mode isn't useful there; 100% backwards compatibility is
476 2016-12-01 19:16:35	0|gmaxwell|I'd also like to ask about some other PRs? ##8895 and the checkqueue work for example-- but I don't think JeremyRubin is around.
477 2016-12-01 19:16:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/8895 | Better SigCache Implementation by JeremyRubin · Pull Request #8895 · bitcoin/bitcoin · GitHub
478 2016-12-01 19:16:58	0|morcos|i think 8895 is ready to go in (maybe a little bit more review)
479 2016-12-01 19:17:10	0|morcos|in my opinion checkqueue is still a work in progress
480 2016-12-01 19:17:10	0|wumpus|is that a next topic?
481 2016-12-01 19:17:19	0|morcos|i would really like to get 8895 in for 0.14
482 2016-12-01 19:17:23	0|wumpus|if so, BlueMatt proposed one first
483 2016-12-01 19:17:25	0|BlueMatt|what morcos said, jeremyrubin is just waiting on review for #8895, I think
484 2016-12-01 19:17:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/8895 | Better SigCache Implementation by JeremyRubin · Pull Request #8895 · bitcoin/bitcoin · GitHub
485 2016-12-01 19:17:37	0|sipa|i'll review 8895 again after the last round of changed to it
486 2016-12-01 19:17:42	0|gmaxwell|sorry, tangent.
487 2016-12-01 19:17:52	0|gmaxwell|sounds like the question is answered then.
488 2016-12-01 19:17:58	0|BlueMatt|wumpus: either way we finished that topic :p
489 2016-12-01 19:18:08	0|wumpus|#topic Main split
490 2016-12-01 19:18:27	0|sipa|let's do it
491 2016-12-01 19:18:28	0|morcos|to summarize last 2 topics... concept ack 9194 and 8895 for 0.14.0
492 2016-12-01 19:18:47	0|instagibbs|#9194
493 2016-12-01 19:18:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9194 | Add option to return non-segwit serialization via rpc by instagibbs · Pull Request #9194 · bitcoin/bitcoin · GitHub
494 2016-12-01 19:18:53	0|instagibbs|oh right
495 2016-12-01 19:19:03	0|BlueMatt|well I think #9183 is +/- ready for merge, jtimon just posted another comment I should look at, but probably ready in an hour or two, it has lots of acks, so question is when to do The Split
496 2016-12-01 19:19:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/9183 | Final Preparation for main.cpp Split by TheBlueMatt · Pull Request #9183 · bitcoin/bitcoin · GitHub
497 2016-12-01 19:19:31	0|wumpus|if it has lots of acks it should be merged
498 2016-12-01 19:19:34	0|cfields|no objections to splitting asap here. It'll only collide trivially with my current work.
499 2016-12-01 19:19:41	0|jonasschnelli|BlueMatt: why when? Because of upcoming rebases?
500 2016-12-01 19:19:42	0|jtimon|I would say open the PR as soon as 9183 gets merged
501 2016-12-01 19:19:53	0|wumpus|no need to delay it if it is ready
502 2016-12-01 19:19:57	0|BlueMatt|jonasschnelli: question is if we do it now or wait until like right before 0.14
503 2016-12-01 19:20:02	0|jonasschnelli|I think all of us are happy to rebase for a such split
504 2016-12-01 19:20:08	0|BlueMatt|ok!
505 2016-12-01 19:20:10	0|jonasschnelli|IMO asap
506 2016-12-01 19:20:11	0|wumpus|let's just go on with it
507 2016-12-01 19:20:13	0|jtimon|BlueMatt: why? what's the advantage of waiting?
508 2016-12-01 19:20:25	0|BlueMatt|ok! sounds good, will open as soon as 9183 is merged
509 2016-12-01 19:20:31	0|morcos|Perhaps BlueMatt is asking if there are any more 0.13 backports to worry about first?
510 2016-12-01 19:20:37	0|cfields|jtimon: to ease backports in the meantime i guess?
511 2016-12-01 19:20:47	0|BlueMatt|morcos: oh, yea, that too
512 2016-12-01 19:20:53	0|jtimon|morcos: cfields oh, right
513 2016-12-01 19:21:08	0|jtimon|are there any backports on the horizon?
514 2016-12-01 19:21:20	0|jtimon|do they conflict with this?
515 2016-12-01 19:21:22	0|wumpus|speaking of 0.13.2, what still needs to go in? (that isn't merged into master yet)
516 2016-12-01 19:21:23	0|gmaxwell|I'm more comfortable with 9183 since matt has been doing a lot of data race and locking testing. usually the worry I have with these sorts of rearrangements is that they'll invalidate hidden locking assumptions.
517 2016-12-01 19:21:39	0|gmaxwell|wumpus: the estimatefee 1 thing. and uhhh
518 2016-12-01 19:21:39	0|sdaftuar|i have one that could go in, the cs_main locking thing with compact blocks
519 2016-12-01 19:21:42	0|sdaftuar|plus 9194
520 2016-12-01 19:21:46	0|cfields|BlueMatt: is it 100% move-only?
521 2016-12-01 19:21:50	0|BlueMatt|cfields: yes
522 2016-12-01 19:22:03	0|morcos|huh is what move only
523 2016-12-01 19:22:09	0|BlueMatt|splitting main.cpp
524 2016-12-01 19:22:10	0|gmaxwell|yea, the locking around compact blocks
525 2016-12-01 19:22:26	0|gmaxwell|#9253 perhaps (though its minor)
526 2016-12-01 19:22:27	0|wumpus|gmaxwell: that one isn't tagged https://github.com/bitcoin/bitcoin/milestone/24
527 2016-12-01 19:22:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/9253 | Fix calculation of number of bound sockets to use by TheBlueMatt · Pull Request #9253 · bitcoin/bitcoin · GitHub
528 2016-12-01 19:22:31	0|sdaftuar|that doens't cleanly apply anyway though, so i'll open a separate PR for it for the backport
529 2016-12-01 19:22:55	0|gmaxwell|#9229
530 2016-12-01 19:22:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9229 | Remove calls to getaddrinfo_a by TheBlueMatt · Pull Request #9229 · bitcoin/bitcoin · GitHub
531 2016-12-01 19:23:27	0|gmaxwell|#9194 I think (which is why I was asking about it)
532 2016-12-01 19:23:28	0|wumpus|so does the main split pose a difficulty for any of those?
533 2016-12-01 19:23:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/9194 | Add option to return non-segwit serialization via rpc by instagibbs · Pull Request #9194 · bitcoin/bitcoin · GitHub
534 2016-12-01 19:23:30	0|morcos|jonasschnelli: i was wondering about that, i think that would be my preference
535 2016-12-01 19:23:39	0|bitcoin070|hey guys, how often does a wallet rebroadcast transactions that aren't on the network?
536 2016-12-01 19:23:50	0|gmaxwell|I just noticed #9188 isn't merged. that too
537 2016-12-01 19:23:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/9188 | Make orphan parent fetching ask for witnesses. by gmaxwell · Pull Request #9188 · bitcoin/bitcoin · GitHub
538 2016-12-01 19:24:03	0|wumpus|bitcoin070: after the meeting please
539 2016-12-01 19:24:16	0|bitcoin070|sorry..
540 2016-12-01 19:24:32	0|jonasschnelli|I think after the main split, backports can get a bit more complicated.
541 2016-12-01 19:24:34	0|wumpus|jonasschnelli: thanks
542 2016-12-01 19:25:00	0|gmaxwell|oh good point.
543 2016-12-01 19:25:01	0|wumpus|jonasschnelli: move-only isn't that much of a difficulty if the functions remain the same name and keep the same calling relationship
544 2016-12-01 19:25:18	0|gmaxwell|well all our backports should be small at least.
545 2016-12-01 19:25:18	0|jonasschnelli|#9229 does not touch main, #9239 also not.
546 2016-12-01 19:25:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/9229 | Remove calls to getaddrinfo_a by TheBlueMatt · Pull Request #9229 · bitcoin/bitcoin · GitHub
547 2016-12-01 19:25:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/9239 | Disable fee estimates for 1 block target by morcos · Pull Request #9239 · bitcoin/bitcoin · GitHub
548 2016-12-01 19:25:21	0|wumpus|the only thing that really messes up backports is if the logic changes
549 2016-12-01 19:25:30	0|morcos|can someone tag all the backports we just mentioned...
550 2016-12-01 19:25:34	0|jonasschnelli|Indeed.
551 2016-12-01 19:25:37	0|sdaftuar|#9252 does, but it's easy for me to backport, so i am not worried
552 2016-12-01 19:25:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/9252 | Release cs_main before calling ProcessNewBlock (cmpctblock handling) by sdaftuar · Pull Request #9252 · bitcoin/bitcoin · GitHub
553 2016-12-01 19:25:40	0|sipa|general request for move-only commits: leave functions/methods in the same order in the new file as in the old file; makes diffing much easier to verify move-onlyness
554 2016-12-01 19:25:41	0|BlueMatt|I can rebase main split on top of all the "Backport needed" PRs
555 2016-12-01 19:25:50	0|BlueMatt|but then we need to move fast on the backport-needed PRs
556 2016-12-01 19:25:58	0|BlueMatt|sipa: kk
557 2016-12-01 19:26:17	0|jonasschnelli|backport taged: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+backport%22
558 2016-12-01 19:26:29	0|gmaxwell|okay, I don't see anything else thats open which I strongly believe needs to be in 0.13.2
559 2016-12-01 19:26:41	0|wumpus|great
560 2016-12-01 19:27:18	0|wumpus|BlueMatt: makes sense to move fast on 0.13.2 in any case
561 2016-12-01 19:27:25	0|BlueMatt|true
562 2016-12-01 19:27:28	0|jtimon|wumpus: +1
563 2016-12-01 19:27:34	0|wumpus|there's plenty of stuff for a release already
564 2016-12-01 19:27:36	0|morcos|jonasschnelli: 9194, 9252 for backport i think is what we said
565 2016-12-01 19:27:49	0|BlueMatt|ok, so then everyone's review focus is "Needs backport" tag, and then we main-split after those are done?
566 2016-12-01 19:28:01	0|sipa|BlueMatt: sgtm
567 2016-12-01 19:28:08	0|sdaftuar|agreed
568 2016-12-01 19:28:10	0|jonasschnelli|tagged 9194 9252
569 2016-12-01 19:28:10	0|wumpus|sgtm too
570 2016-12-01 19:28:36	0|gmaxwell|instagibbs: could you give #9019 a look? we might want a simple fix for that in 0.13.2. It might be a two liner.
571 2016-12-01 19:28:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/9019 | Avoid making chains of txn >25 deep. · Issue #9019 · bitcoin/bitcoin · GitHub
572 2016-12-01 19:28:37	0|jtimon|fine with me but will actually review 9183 first
573 2016-12-01 19:28:50	0|instagibbs|yeah sure, ive run into that a number of times :)
574 2016-12-01 19:29:49	0|wumpus|okay, that concludes the 0.13.2 and main split topic I guess
575 2016-12-01 19:30:03	0|wumpus|any other topics proposed?
576 2016-12-01 19:30:05	0|jonasschnelli|proposed topic from sipa: wallets default key, another topic could be: HD restore
577 2016-12-01 19:30:09	0|wumpus|ah yes
578 2016-12-01 19:30:16	0|sipa|ok
579 2016-12-01 19:30:16	0|wumpus|#topic vchdefault in wallet
580 2016-12-01 19:30:29	0|sipa|so we currently have a leftover remnant of ancient times, vchDefaultKey in the wallet
581 2016-12-01 19:30:35	0|jonasschnelli|The default key is misused for detecting the first run IMO
582 2016-12-01 19:30:39	0|wumpus|#link https://github.com/bitcoin/bitcoin/issues/8416
583 2016-12-01 19:30:44	0|sipa|which is absolutely unused, except for determining whether a new wallet was just created
584 2016-12-01 19:30:53	0|sipa|i'd like to get rid of it
585 2016-12-01 19:30:54	0|sipa|however
586 2016-12-01 19:31:02	0|wumpus|yes, we should get rid of it, but maybe not for 0.14, it's not really urgent
587 2016-12-01 19:31:11	0|sipa|if we do that, a downgrade to an older wallet version would result in failing to rescan
588 2016-12-01 19:31:24	0|jonasschnelli|Yes. We should combine it with other features.
589 2016-12-01 19:31:25	0|sipa|as it would trigger the new wallet logic, which writes the current chainstate to the wallet file
590 2016-12-01 19:31:32	0|jonasschnelli|We should have combined it with HD in 0.13. :/
591 2016-12-01 19:31:46	0|wumpus|sipa: we could add fallback logic into 0.14
592 2016-12-01 19:31:49	0|wumpus|then remove it for 0.15
593 2016-12-01 19:31:56	0|sipa|writing a dummy has the disadvantage of actually risking giving out a dummy key as address (in very old versions)
594 2016-12-01 19:32:11	0|wumpus|then it'd be possible to go back to 0.14 when 0.15 is released
595 2016-12-01 19:32:15	0|wumpus|but o further back
596 2016-12-01 19:32:25	0|sipa|a third option is introducing a new min wallet version, so for example 0.15 wallets will never be openable with 0.13
597 2016-12-01 19:32:26	0|wumpus|(unless we backport the fallback logic ofc)
598 2016-12-01 19:32:46	0|wumpus|yes, that'd be my preference
599 2016-12-01 19:32:57	0|wumpus|no dummies and other hacks, just versioining
600 2016-12-01 19:33:09	0|jonasschnelli|Yes. This only affect new wallets, right?
601 2016-12-01 19:33:14	0|wumpus|it'd only apply to new wallets created with the new version anyway
602 2016-12-01 19:33:15	0|wumpus|right.
603 2016-12-01 19:33:19	0|gmaxwell|I'm okay with versioning, but we should keep it simple.
604 2016-12-01 19:33:24	0|wumpus|it's not like you can't go back with an old wallet
605 2016-12-01 19:33:26	0|jonasschnelli|If you have a wallet from 0.12, it won't upgrade unless you do an explicit upgrtadew
606 2016-12-01 19:33:41	0|sipa|so let's switch in 0.14 to stop relying on vchDefault key, but still write it (as an actually valid key)
607 2016-12-01 19:33:42	0|wumpus|in any case this isn't urgent
608 2016-12-01 19:33:54	0|jonasschnelli|sipa: ack
609 2016-12-01 19:33:54	0|sipa|and then in 0.15 delete the vchDefaultKey and increase the min version to 0.14?
610 2016-12-01 19:33:55	0|wumpus|we could do it over 2-3 major versions
611 2016-12-01 19:34:12	0|gmaxwell|ACK sipa.
612 2016-12-01 19:34:13	0|wumpus|sipa: yes that's what I meant too
613 2016-12-01 19:34:22	0|jonasschnelli|Downgrading new wallets is probably not required over more then 2 major versions.
614 2016-12-01 19:34:42	0|wumpus|we could even backport that to 0.13
615 2016-12-01 19:35:00	0|jonasschnelli|wumpus: Yes. We should.
616 2016-12-01 19:35:02	0|wumpus|(e.g. work if there is no vchdefault, but do make it)
617 2016-12-01 19:35:42	0|wumpus|that particular code hasn't been touched for years so backporting is trivial
618 2016-12-01 19:36:09	0|sipa|ok, end topic
619 2016-12-01 19:36:14	0|morcos|my 2 cents would be against backporting to 0.13.2 at least.. since i think 1 major version backport for downgrading the wallet seems sufficient
620 2016-12-01 19:36:16	0|jonasschnelli|HD restore? anyone interested?
621 2016-12-01 19:36:47	0|morcos|just to not hold up 0.13.2
622 2016-12-01 19:36:52	0|jonasschnelli|morcos: whats the downside of the (simple) backport?
623 2016-12-01 19:36:57	0|jonasschnelli|ok.
624 2016-12-01 19:37:02	0|jtimon|ack min wallet version
625 2016-12-01 19:37:08	0|sipa|jonasschnelli: certainly, but it requires some pretty big changes (like removing keypool entries with seen keys in received transactions)
626 2016-12-01 19:37:12	0|wumpus|morcos: I mean to 0.13 *branch*, so 0.13.2 or 0.13.3 or whatever happens to be then
627 2016-12-01 19:37:21	0|wumpus|morcos: I certainly wouldn't propose holding up 0.13.2 for it
628 2016-12-01 19:37:24	0|morcos|wumpus: +1 if it doesn't hold 13.2
629 2016-12-01 19:37:28	0|jonasschnelli|Okay. Yes. If the BP is non trivial, we can skip it.
630 2016-12-01 19:37:32	0|wumpus|morcos: no one is saying that!
631 2016-12-01 19:37:46	0|gmaxwell|yea, no holdup. but BP would be nice.
632 2016-12-01 19:38:31	0|jtimon|jonasschnelli: who requires to downgrade wallets?
633 2016-12-01 19:38:39	0|wumpus|"removing keypool entries with seen keys in received transactions"?
634 2016-12-01 19:38:48	0|wumpus|is that required for removing the default key?
635 2016-12-01 19:39:52	0|morcos|wumpus: is that HD restore he's talking about?
636 2016-12-01 19:39:57	0|jonasschnelli|jtimon: Is more about the option to run your wallet.dat on an older version
637 2016-12-01 19:40:03	0|jonasschnelli|morcos: not yet
638 2016-12-01 19:40:11	0|jonasschnelli|default key != HD
639 2016-12-01 19:40:24	0|morcos|jonasschnelli: yes understood, just trying to decipher sipas comment
640 2016-12-01 19:40:26	0|wumpus|morcos: I don't know? I'm confused
641 2016-12-01 19:40:34	0|jtimon|jonasschnelli: right, why do you want that? anyway, I was reading slow, we can discuss after the meeting
642 2016-12-01 19:40:38	0|gmaxwell|I thought sip was responding to "hd restore"
643 2016-12-01 19:40:39	0|wumpus|it'd make more sense, we're combinding topics is an awkward way now
644 2016-12-01 19:40:43	0|gmaxwell|s/sip/sipa/
645 2016-12-01 19:40:55	0|jonasschnelli|Ah. Sorry
646 2016-12-01 19:41:12	0|jonasschnelli|Can we have the HD restore topic then?
647 2016-12-01 19:41:12	0|wumpus|#topic HD restore
648 2016-12-01 19:41:15	0|jonasschnelli|thx
649 2016-12-01 19:41:20	0|gmaxwell|TM: Prefix all messages related to topic 1 with T1: and for topic 2 with T2:
650 2016-12-01 19:41:31	0|jonasschnelli|Since 0.13 we have HD by default, we should have a feature to restore hd wallets
651 2016-12-01 19:41:38	0|jonasschnelli|Maybe to late for 0.14, but in 0.15.
652 2016-12-01 19:41:45	0|jonasschnelli|I think we need a concept first
653 2016-12-01 19:42:00	0|jonasschnelli|IMO it should go over a seperate tool (bitcoin-wallet)
654 2016-12-01 19:42:20	0|morcos|jonasschnelli: can you explain what that means... you lost the full wallet backup but have the master seed/key whatever it's called?
655 2016-12-01 19:42:23	0|jonasschnelli|Because you ideally don't want to handle master xpriv in RPC or -cmd
656 2016-12-01 19:42:30	0|gmaxwell|seperate tool sounds like something that would need a non-pruned blockchain .. which I don't think is desirable.
657 2016-12-01 19:42:51	0|jonasschnelli|Yes. You have an (olx) xpriv or a wallet.dump and you wish to restore the complete wallet
658 2016-12-01 19:43:01	0|jonasschnelli|gmaxwell: Yes. This is a good point.
659 2016-12-01 19:43:17	0|gmaxwell|how is this different from having a wallet.dat that you backed up right at the start?
660 2016-12-01 19:43:21	0|jonasschnelli|The tool should create wallet(s).dat and then you can run a rescan
661 2016-12-01 19:43:33	0|gmaxwell|okay thats how.
662 2016-12-01 19:43:45	0|jonasschnelli|Maybe the tool can interact with RPC and the UTXO set to detect the gap limits
663 2016-12-01 19:44:35	0|gmaxwell|I think a tool to create a wallet.dat from dump data would be good, but perhaps not essential for restore functionality. which could work from just a wallet.dat that the user already backed up.
664 2016-12-01 19:44:39	0|jonasschnelli|IMO it should result with a wallet with the corresponding keys up to the last detected UTXO (respecting a large gap)
665 2016-12-01 19:44:59	0|gmaxwell|I'm really concnered that we didn't manage to split the change keypool for the HD wallet support. This makes recovery a mess.
666 2016-12-01 19:45:00	0|jtimon|jonasschnelli: what about something like this, create first 100 addresses, rescan, while some of them got any funds, create the next 100 and loop
667 2016-12-01 19:45:28	0|jtimon|I assume is horribly inefficient, reading slow again
668 2016-12-01 19:45:34	0|gmaxwell|jtimon: sometime 100 years later your wallet is restored.
669 2016-12-01 19:45:34	0|jonasschnelli|gmaxwell: there was a PR with that. But nobody reviewd it (external and internal chain)
670 2016-12-01 19:45:50	0|gmaxwell|(rescans take hours, we should stop thinking of rescans as an option generally.)
671 2016-12-01 19:45:53	0|wumpus|jonasschnelli: yea :/ review is always a problem with wallet pulls
672 2016-12-01 19:45:56	0|jtimon|gmaxwell: thanks for confirming that is the flaw of my naive design
673 2016-12-01 19:46:20	0|wumpus|I'd recommend that we first review and get the current wallet pulls merged, before working on even more
674 2016-12-01 19:46:41	0|sipa|wumpus: +1
675 2016-12-01 19:46:49	0|jonasschnelli|I think it would help to review #9143 and #9256
676 2016-12-01 19:46:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/9143 | Refactor ZapWalletTxes to avoid layer violations by jonasschnelli · Pull Request #9143 · bitcoin/bitcoin · GitHub
677 2016-12-01 19:46:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/9256 | Fix more CWallet/CWalletDB layer violations by jonasschnelli · Pull Request #9256 · bitcoin/bitcoin · GitHub
678 2016-12-01 19:46:54	0|wumpus|I don't think HD recovery will make 0.4 as it still has to be written
679 2016-12-01 19:46:58	0|gmaxwell|jonasschnelli: I thought it was merged in fact, at the time. oh well.
680 2016-12-01 19:47:01	0|jonasschnelli|This would slowly allow creating a such tool
681 2016-12-01 19:47:04	0|wumpus|but we can make e.g. multiwallet land
682 2016-12-01 19:47:14	0|wumpus|s/0.4/0.14
683 2016-12-01 19:47:29	0|jonasschnelli|#8723 would also nice for HD
684 2016-12-01 19:47:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub
685 2016-12-01 19:47:33	0|wumpus|and yes the refactors
686 2016-12-01 19:47:50	0|jtimon|what about not restoring the whole wallet but only what's currently in the utxo? would that be acceptable?
687 2016-12-01 19:48:04	0|jonasschnelli|jtimon: Yes. That should be the default IMO
688 2016-12-01 19:48:12	0|jonasschnelli|Then you can optionally do a rescan if you like.
689 2016-12-01 19:48:13	0|gmaxwell|I think we should not add any more complexity to the HD support until we fix the path split issue.
690 2016-12-01 19:48:31	0|gmaxwell|We're already going to have to support one legacy setup, lets try to not proliferate little changes.
691 2016-12-01 19:49:12	0|jonasschnelli|Okay. I can focus on the path split
692 2016-12-01 19:49:31	0|jcorgan|gmaxwell: background on the "path split issue" i can go read?
693 2016-12-01 19:49:42	0|jonasschnelli|But users start to ask,... how can I recover a HD wallet. We need to give them a reasonable answer.
694 2016-12-01 19:49:55	0|jonasschnelli|jcorgan: bip32 internal and external chains
695 2016-12-01 19:50:04	0|instagibbs|jcorgan, change output is on same chain as spending
696 2016-12-01 19:50:08	0|jcorgan|ah, yes, i should ack 8723
697 2016-12-01 19:50:36	0|instagibbs|err receiving*
698 2016-12-01 19:51:00	0|gmaxwell|jcorgan: the consequence is that you can end up giving out change keys as addresses for people to pay (hiding their payments from you) or have change show up as payments if you have wallets recovered from hd data.
699 2016-12-01 19:51:21	0|jcorgan|yeah, i get it
700 2016-12-01 19:51:25	0|gmaxwell|jcorgan: e.g. I give you an address. then recover my wallet. Then create a transaction and use the same addr for change.  Then you pay that address, and I don't see the payment.
701 2016-12-01 19:51:29	0|gmaxwell|yadda yadda.
702 2016-12-01 19:51:37	0|Chris_Stewart_5|gmaxwell: Thanks for the explanation
703 2016-12-01 19:52:16	0|gmaxwell|jonasschnelli: load your old wallet.dat. rescan.   Where does that currently fall down?
704 2016-12-01 19:52:25	0|jonasschnelli|gmaxwell: missing keys
705 2016-12-01 19:52:29	0|sipa|?
706 2016-12-01 19:52:41	0|jonasschnelli|you mean restore a old wallet.dat?
707 2016-12-01 19:52:51	0|jonasschnelli|you need to loop(1000, getnewaddress) first. :)
708 2016-12-01 19:52:57	0|gmaxwell|right we don't remove all keys up to the highest observed, only observed?  that sounds like a simple fix.
709 2016-12-01 19:53:01	0|jonasschnelli|Well, if you have 1001 keys, you miss one.
710 2016-12-01 19:53:18	0|jonasschnelli|gmaxwell: this would result in multiple rescans.
711 2016-12-01 19:53:21	0|wumpus|right, it doesn't automatically wind forward when it sees known keys
712 2016-12-01 19:53:23	0|sipa|gmaxwell: what do you mean remove?
713 2016-12-01 19:53:35	0|gmaxwell|sipa: mark used in keypool.
714 2016-12-01 19:53:42	0|sipa|gmaxwell: that's not implemented at all
715 2016-12-01 19:53:45	0|luke-jr|:x
716 2016-12-01 19:53:47	0|gmaxwell|jonasschnelli: which is a workaround that you can answer.
717 2016-12-01 19:53:58	0|sipa|gmaxwell: you need the keypool
718 2016-12-01 19:54:02	0|jonasschnelli|Yes. The loop getnewaddress is the current workaround.
719 2016-12-01 19:54:09	0|jcorgan|it seems the bigger issue is there is no standard way of archiving derivation path usage + metadata
720 2016-12-01 19:54:15	0|gmaxwell|sipa: that needs to be implemented, at least that much would be small.
721 2016-12-01 19:54:16	0|jonasschnelli|But we don't even offer a rescan down to the HD feature birthdate.
722 2016-12-01 19:54:24	0|jonasschnelli|The UX is bad
723 2016-12-01 19:54:27	0|sipa|gmaxwell: it's not easy
724 2016-12-01 19:54:36	0|jonasschnelli|yes. It's pretty complex.
725 2016-12-01 19:54:42	0|sipa|gmaxwell: as we don't have a way to store keys without private key
726 2016-12-01 19:54:54	0|sipa|or rescan would require the passphrase
727 2016-12-01 19:54:55	0|gmaxwell|sipa: we can still mark the right things as used!
728 2016-12-01 19:54:56	0|jonasschnelli|We first need a Wallet record type hdkey
729 2016-12-01 19:55:02	0|sipa|gmaxwell: ah, yes!
730 2016-12-01 19:55:13	0|sipa|jonasschnelli: no we don't
731 2016-12-01 19:55:32	0|gmaxwell|sipa: e.g. rescan, unlock, rescan. not great, but failing to mark things as used is really goofy.
732 2016-12-01 19:55:46	0|gmaxwell|but should also be trivial to fix.
733 2016-12-01 19:55:51	0|sipa|jonasschnelli: just a way to store a key without known private key (with semantics that it will get computed at first unlock)
734 2016-12-01 19:55:58	0|sipa|or not at all, i guess
735 2016-12-01 19:56:09	0|sipa|and always derive it on the fly
736 2016-12-01 19:56:16	0|gmaxwell|sipa: No, we can't.
737 2016-12-01 19:56:27	0|gmaxwell|(keys are hardened because we support export)
738 2016-12-01 19:56:29	0|jonasschnelli|IMO we should just store pubkeys and the according keypath
739 2016-12-01 19:56:37	0|sipa|gmaxwell: oh, right
740 2016-12-01 19:56:46	0|jonasschnelli|maybe the relevant master key (if we support multiple=
741 2016-12-01 19:56:53	0|gmaxwell|and yes, storing the private keys is a bit silly. :P but an optimization.
742 2016-12-01 19:56:57	0|jcorgan|jonasschnelli: agree, if there were a standard way of documenting that
743 2016-12-01 19:57:20	0|sipa|3 minutes
744 2016-12-01 19:57:31	0|gmaxwell|( I meant that not storing the private keys is mearly an optimization and not important.)
745 2016-12-01 19:58:04	0|sipa|gmaxwell: we could also stop rescanning whenever the keypool goes below some value, and require unlocking first
746 2016-12-01 19:58:07	0|sipa|or something
747 2016-12-01 19:58:34	0|jtimon|gmaxwell: I still don't know how you solve the problem you described
748 2016-12-01 19:58:37	0|gmaxwell|in any case, IMO low hanging is to correctly do the use-marking, and also increase the default keypool for hdwallets.. 100 is somewhat absurdly small, 1000 would be better.   And getting splitting in.
749 2016-12-01 19:59:05	0|gmaxwell|the last is a path incompatible change unfortunately, :(
750 2016-12-01 19:59:19	0|gmaxwell|but the rest does not need coordination with anything.
751 2016-12-01 19:59:21	0|sipa|we should first split up the keypools into change and non-change, iguess
752 2016-12-01 19:59:31	0|jonasschnelli|Okay. I can work on a patch.
753 2016-12-01 19:59:40	0|jtimon|sipa: oh, I see
754 2016-12-01 19:59:41	0|sipa|then do the use marking (as it will need to mark within each path)
755 2016-12-01 19:59:44	0|jcorgan|jonasschnelli: let's pm after the mtg on that
756 2016-12-01 19:59:57	0|gmaxwell|sipa: the split will make wallets that do that incompatible with older software.
757 2016-12-01 20:00:10	0|sipa|gmaxwell: yes
758 2016-12-01 20:00:17	0|jonasschnelli|gmaxwell: Yes. We just need to support both types
759 2016-12-01 20:00:34	0|jtimon|does the change keypool have its own seed or is it derived?
760 2016-12-01 20:00:40	0|wumpus|#endmeeting
761 2016-12-01 20:00:41	0|jonasschnelli|the one-chain-hd-wallet and the flexible-keypath-wallet with ext/int chain
762 2016-12-01 20:00:41	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-01-19.00.log.html
763 2016-12-01 20:00:41	0|lightningbot|Meeting ended Thu Dec  1 20:00:40 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
764 2016-12-01 20:00:41	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-01-19.00.html
765 2016-12-01 20:00:41	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-01-19.00.txt
766 2016-12-01 20:00:46	0|BlueMatt|wumpus, cfields re #9229 should I just switch it to be a full-revert of #4421 instead of fighting with autotools to keep the inet_pton working? (is anyone aware of any bugs from dropping those calls and just always using getaddrinfo?)
767 2016-12-01 20:00:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/9229 | Remove calls to getaddrinfo_a by TheBlueMatt · Pull Request #9229 · bitcoin/bitcoin · GitHub
768 2016-12-01 20:00:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/4421 | Use async name resolving to improve net thread responsiveness by 4tar · Pull Request #4421 · bitcoin/bitcoin · GitHub
769 2016-12-01 20:00:50	0|sipa|jtimon: the keypool is just a set of keys
770 2016-12-01 20:00:53	0|jonasschnelli|jcorgan: same seed
771 2016-12-01 20:00:55	0|gmaxwell|jtimon: see bip32.. internal vs external.
772 2016-12-01 20:00:56	0|instagibbs|jtimon, it's just a different path
773 2016-12-01 20:01:04	0|jonasschnelli|jcorgan: meant jtimon
774 2016-12-01 20:01:08	0|sipa|jtimon: the seed information is in how to replenish it, hwich happens elsewhere
775 2016-12-01 20:01:42	0|gmaxwell|jonasschnelli: whenever the answer is 'support both types' that strongly encourages batching changes.
776 2016-12-01 20:01:45	0|jtimon|sipa: thanks, I'm not so familiar with the bip32 wallet
777 2016-12-01 20:01:50	0|jonasschnelli|Combining the splitting with https://github.com/bitcoin/bitcoin/pull/8723/files would make sense IMO
778 2016-12-01 20:01:54	0|gmaxwell|I really do not want to support 30 different kinds of wallets 5 years from now. :)
779 2016-12-01 20:02:09	0|cfields|BlueMatt: looking
780 2016-12-01 20:02:24	0|jonasschnelli|Yes. We don't have the splitting because we wanted a minimal sane change.
781 2016-12-01 20:02:31	0|sipa|gmaxwell: we'll just do a softfork to require SNARKs in signatures that prove that keys were derived deterministically?
782 2016-12-01 20:02:34	0|jonasschnelli|I think this was resonable. But we shouln't wait to long now
783 2016-12-01 20:02:35	0|sipa|*ducks*
784 2016-12-01 20:02:41	0|jonasschnelli|heh
785 2016-12-01 20:03:09	0|jtimon|jonasschnelli: regarding donwgrading the wallet, no need for further discussion, I thought of an example case where I could want that myself already
786 2016-12-01 20:03:09	0|wumpus|cfields: I guess we will use libevent for resolving anyway, when that lands?
787 2016-12-01 20:03:19	0|BlueMatt|wumpus: yes, but need something to backport
788 2016-12-01 20:03:23	0|gmaxwell|If we're going to be incompatible, not storing private keys for hd keys would also be a good move... as it will make it less costly to make the lookahead larger.
789 2016-12-01 20:03:42	0|gmaxwell|so in any case, thats just why I was suggesting fixing the use-flagging first, no compatiblity concerns.
790 2016-12-01 20:03:51	0|wumpus|BlueMatt: sure in the meantime we can revert #4421 if it's buggy
791 2016-12-01 20:03:53	0|cfields|wumpus: yes. I'm not really concerned about dropping this back to sync for now for that reason
792 2016-12-01 20:03:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/4421 | Use async name resolving to improve net thread responsiveness by 4tar · Pull Request #4421 · bitcoin/bitcoin · GitHub
793 2016-12-01 20:04:26	0|BlueMatt|ok, so I'll just do a full-revert of 4421
794 2016-12-01 20:04:27	0|BlueMatt|sgtm
795 2016-12-01 20:04:32	0|cfields|BlueMatt: i'm tracing through the ifdefs locally now to make sure it works like i assume
796 2016-12-01 20:04:45	0|gmaxwell|BlueMatt mentioned to me that he thinks he's actually seen a getaddrinfo_a crash in production.  (backtrace was really short and without symbols because it was off in libc someplace)
797 2016-12-01 20:04:52	0|wumpus|BlueMatt: please do comment in the issue that you'regoing to revert it and why
798 2016-12-01 20:05:06	0|BlueMatt|kk
799 2016-12-01 20:05:23	0|jtimon|not sure what the conclusions about the wallet are
800 2016-12-01 20:05:34	0|BlueMatt|yes, if you've ever seen a crash in prod with a backtrace of length three with ???s for all of them...it might be gai_a
801 2016-12-01 20:06:08	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9259: [0.13 backport] Release cs_main before calling ProcessNewBlock or processing header (cmpctblock handling) (060.13...06cb-lock-13) 02https://github.com/bitcoin/bitcoin/pull/9259
802 2016-12-01 20:06:15	0|wumpus|espeically if you have no debug symbols for libc I guess?
803 2016-12-01 20:06:24	0|BlueMatt|wumpus: yes
804 2016-12-01 20:06:56	0|BlueMatt|wait, gmaxwell why do we want backport of #9252? I dont think releasing cs_main gives us anything in backport, but does carry risk
805 2016-12-01 20:06:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/9252 | Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) by sdaftuar · Pull Request #9252 · bitcoin/bitcoin · GitHub
806 2016-12-01 20:07:14	0|wumpus|I still wonder if we're misusing it or whether libc is really buggy. It's not impossible that libc is buggy just sounds so unlikely
807 2016-12-01 20:07:23	0|wumpus|in any case reverting it for now makes sense
808 2016-12-01 20:08:06	0|BlueMatt|wumpus: https://sourceware.org/bugzilla/show_bug.cgi?id=20874#c4
809 2016-12-01 20:08:11	0|BlueMatt|"This does look like a bug."
810 2016-12-01 20:09:30	0|BlueMatt|its possible I'm thinking of another issue wrt having seen this in prod - I've seen other issues in -qt that I think are just X instability
811 2016-12-01 20:09:39	0|BlueMatt|and I may be thinking of those, but gai_a is definitely unsafe
812 2016-12-01 20:09:53	0|cfields|in any case, I'm working furiously now on event-ifying the net code, pr should be up within the next few days, and is looking pretty simple. After that, the libevent changes come in. So the end is near for that code anyway :)
813 2016-12-01 20:10:07	0|BlueMatt|good riddance
814 2016-12-01 20:10:08	0|luke-jr|sdaftuar: BIP 90; what's with the "foo" and "tmp.mediawiki" files?
815 2016-12-01 20:10:17	0|sdaftuar|luke-jr: gah, let check
816 2016-12-01 20:10:24	0|sdaftuar|let me check*
817 2016-12-01 20:10:39	0|wumpus|cfields: thanks for the update, looking forward to that :)
818 2016-12-01 20:12:14	0|cfields|BlueMatt: ah i see, the inet_pton is just used to skip the getaddrinfo in the event that an ip was passed as a string
819 2016-12-01 20:12:41	0|cfields|(sorry, was trying to figure out what that had to do with gai_a)
820 2016-12-01 20:13:20	0|cfields|and actually, still not sure why they're entangled
821 2016-12-01 20:13:26	0|cfields|but either way, full revert sounds good to me
822 2016-12-01 20:23:29	0|sdaftuar|BlueMatt: gmaxwell: regarding #9252, i appear to have misremembered and thought we backported #8968 -- looking back on it, though, it appears we didn't (though it was tagged for backport at one point).
823 2016-12-01 20:23:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/9252 | Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) by sdaftuar · Pull Request #9252 · bitcoin/bitcoin · GitHub
824 2016-12-01 20:23:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/8968 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
825 2016-12-01 20:26:30	0|BlueMatt|sdaftuar: yea, so I'd think dont backport 9252
826 2016-12-01 20:28:00	0|bitcoin-git|[13bitcoin] 15sdaftuar closed pull request #9259: [0.13 backport] Release cs_main before calling ProcessNewBlock or processing header (cmpctblock handling) (060.13...06cb-lock-13) 02https://github.com/bitcoin/bitcoin/pull/9259
827 2016-12-01 20:28:19	0|sdaftuar|BlueMatt: done.  er, undone.  whateer.
828 2016-12-01 20:31:31	0|BlueMatt|cool, thanks
829 2016-12-01 20:39:45	0|morcos|jonasschnelli: Can I bother you to milestone for 0.14.0 #9107 and #9138
830 2016-12-01 20:39:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/9107 | Safer modify new coins by morcos · Pull Request #9107 · bitcoin/bitcoin · GitHub
831 2016-12-01 20:39:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
832 2016-12-01 20:42:18	0|BlueMatt|ACK on those for 14
833 2016-12-01 20:58:38	0|cfields|wumpus: are you aiming for 0.14 for #8811 ?
834 2016-12-01 20:58:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/8811 | rpc: Add support for JSON-RPC named arguments by laanwj · Pull Request #8811 · bitcoin/bitcoin · GitHub
835 2016-12-01 20:59:00	0|luke-jr|sigh, MemorySanitizer is broken in Travis (not affecting Core)
836 2016-12-01 21:00:29	0|cfields|luke-jr: doesn't it require an instrumented libc++ ?
837 2016-12-01 21:01:18	0|luke-jr|cfields: it worked before; seems some Linux kernel bugfix broke it
838 2016-12-01 21:07:28	0|bitcoin-git|13bitcoin/06master 149e1f468 15Matt Corallo: Fix calculation of number of bound sockets to use
839 2016-12-01 21:07:28	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c79e52ad304a...c1a52276848d
840 2016-12-01 21:07:29	0|bitcoin-git|13bitcoin/06master 14c1a5227 15Pieter Wuille: Merge #9253: Fix calculation of number of bound sockets to use...
841 2016-12-01 21:07:41	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9253: Fix calculation of number of bound sockets to use (06master...062016-11-nbind) 02https://github.com/bitcoin/bitcoin/pull/9253
842 2016-12-01 21:35:08	0|bitcoin-git|13bitcoin/06master 145b0150a 15Gregory Maxwell: Make orphan parent fetching ask for witnesses....
843 2016-12-01 21:35:08	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c1a52276848d...ad826b3df9f7
844 2016-12-01 21:35:09	0|bitcoin-git|13bitcoin/06master 14ad826b3 15Pieter Wuille: Merge #9188: Make orphan parent fetching ask for witnesses....
845 2016-12-01 21:35:24	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9188: Make orphan parent fetching ask for witnesses. (06master...06witness_the_orphans) 02https://github.com/bitcoin/bitcoin/pull/9188
846 2016-12-01 22:11:00	0|BlueMatt|jtimon: ok with #9183 as-is now (with print cleanups maybe happening later?)
847 2016-12-01 22:11:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/9183 | Final Preparation for main.cpp Split by TheBlueMatt · Pull Request #9183 · bitcoin/bitcoin · GitHub
848 2016-12-01 22:11:57	0|jtimon|sure
849 2016-12-01 22:13:23	0|jtimon|BlueMatt: reacted with emojis to your answers, thanks
850 2016-12-01 22:14:53	0|BlueMatt|cool, so i should bug sipa to press merge then...
851 2016-12-01 22:15:16	0|jtimon|right duh, it could work without the {}
852 2016-12-01 22:15:24	0|jtimon|fine with me
853 2016-12-01 22:15:28	0|BlueMatt|it could?
854 2016-12-01 22:15:35	0|BlueMatt|i dont think it does that level of magic, does it?
855 2016-12-01 22:15:40	0|jtimon|s/couldn't
856 2016-12-01 22:16:07	0|BlueMatt|ahh
857 2016-12-01 22:16:17	0|jtimon|I mean I should have realized that myself on review, but thanks for the clarification
858 2016-12-01 22:47:08	0|BlueMatt|oh, hey, the backport-needed PRs no longer touch main at all
859 2016-12-01 22:47:13	0|BlueMatt|hmm...sipa you wanna split main today?
860 2016-12-01 22:47:34	0|BlueMatt|or wumpus, if you havent gone to bed yet
861 2016-12-01 22:48:12	0|BlueMatt|also, anyone need some review-love?
862 2016-12-01 23:06:21	0|sipa|BlueMatt: does 9183 conflict with #9229, #9239, or #9194 ?
863 2016-12-01 23:06:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/9229 | Remove calls to getaddrinfo_a by TheBlueMatt · Pull Request #9229 · bitcoin/bitcoin · GitHub
864 2016-12-01 23:06:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/9239 | Disable fee estimates for 1 block target by morcos · Pull Request #9239 · bitcoin/bitcoin · GitHub
865 2016-12-01 23:06:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/9194 | Add option to return non-segwit serialization via rpc by instagibbs · Pull Request #9194 · bitcoin/bitcoin · GitHub
866 2016-12-01 23:06:58	0|BlueMatt|sipa: none of those touch main.{h,cpp}, which is the only thing 9183 touches
867 2016-12-01 23:07:06	0|BlueMatt|so...I doubt it?
868 2016-12-01 23:07:09	0|sipa|ok!
869 2016-12-01 23:17:14	0|bitcoin272|does sendtoaddress have any way to prioritize not making transactions that will have issues because of too many unconfirmed ancestors?
870 2016-12-01 23:17:23	0|bitcoin272|running into a ton of issues here and i don't want to disable spending 0 conf change tb
871 2016-12-01 23:17:25	0|bitcoin272|tbh8
872 2016-12-01 23:17:26	0|bitcoin272|tbh*
873 2016-12-01 23:18:04	0|bitcoin272|but sendtoaddress is making huge chains when it would be more sensible to build multiple chains based on the output set as opposed to only building 1 so that it goes over 25 unconfirmed ancestors and makes a huge mess
874 2016-12-01 23:19:37	0|instagibbs|bitcoin272, I started take a look at that today. I can probably at least have the send fail if it's going to run into mempool limits
875 2016-12-01 23:19:48	0|sipa|BlueMatt: it actually tries to avoid using very recently created change
876 2016-12-01 23:19:51	0|sipa|eh
877 2016-12-01 23:19:52	0|bitcoin272|instagibbs -- it's a huge huge issue unfortunately
878 2016-12-01 23:19:52	0|sipa|bitcoin272: ^
879 2016-12-01 23:20:10	0|bitcoin272|I don't know if this was ever a problem pre 0.13
880 2016-12-01 23:20:20	0|sipa|it should in 0.12 as well
881 2016-12-01 23:20:21	0|instagibbs|coin selection didn't change since then
882 2016-12-01 23:20:28	0|instagibbs|afaik
883 2016-12-01 23:20:32	0|sipa|indeed
884 2016-12-01 23:20:33	0|bitcoin272|what about mempool limits?
885 2016-12-01 23:20:38	0|instagibbs|nope
886 2016-12-01 23:20:48	0|sipa|mempool limits were added in 0.12
887 2016-12-01 23:20:56	0|instagibbs|right, since 0.12 i mean
888 2016-12-01 23:20:59	0|bitcoin272|i see
889 2016-12-01 23:21:02	0|bitcoin272|this behavior guys
890 2016-12-01 23:21:11	0|bitcoin272|is resulting in some very unfortunate things :/
891 2016-12-01 23:21:27	0|bitcoin272|where is the mempool constraint defined
892 2016-12-01 23:21:35	0|bitcoin272|is that something we could modify / recompile
893 2016-12-01 23:21:40	0|sipa|it's a setting
894 2016-12-01 23:22:05	0|sipa|limitancestorcount and limitdescendantcount
895 2016-12-01 23:22:19	0|bitcoin272|it defaults to 25?
896 2016-12-01 23:22:21	0|sipa|yes
897 2016-12-01 23:22:26	0|instagibbs|you can crank those up, but the wallet simply shouldn't violate those limits(I'm working on that)
898 2016-12-01 23:22:31	0|bitcoin272|and that's specifically meaning, dump things after 25 from the mempool, even if they are our own TX?
899 2016-12-01 23:22:33	0|sipa|yes, indeed
900 2016-12-01 23:22:48	0|sipa|bitcoin272: they're not dumped; they're just not accepted
901 2016-12-01 23:22:56	0|bitcoin272|i see... but
902 2016-12-01 23:22:59	0|bitcoin272|they are still broadcast to the network?
903 2016-12-01 23:23:02	0|sipa|no
904 2016-12-01 23:23:09	0|sipa|not until the rest is confirmed
905 2016-12-01 23:23:18	0|bitcoin272|ok right but
906 2016-12-01 23:23:23	0|bitcoin272|so to be clear
907 2016-12-01 23:23:25	0|bitcoin272|sendtoaddress will fail
908 2016-12-01 23:23:29	0|bitcoin272|the TX will sit in the wallet though
909 2016-12-01 23:23:30	0|sipa|yes, the wallet behaviour is bad currently
910 2016-12-01 23:23:41	0|bitcoin272|and when the parents confirm, it will auto rebroad cast
911 2016-12-01 23:23:43	0|bitcoin272|right?
912 2016-12-01 23:23:51	0|sipa|it should at least give an error instead of silently not doing anything
913 2016-12-01 23:23:56	0|sipa|yes, i believe it will
914 2016-12-01 23:24:00	0|bitcoin272|oh man so
915 2016-12-01 23:24:07	0|bitcoin272|this is the problem then
916 2016-12-01 23:24:09	0|bitcoin272|okay.. at least I know
917 2016-12-01 23:24:24	0|bitcoin272|it shouldn't queue that transaction because what happens is
918 2016-12-01 23:24:29	0|sipa|well it would be useful to verify this, by increasing your descendant and ancestor counts
919 2016-12-01 23:24:38	0|bitcoin272|it's easy for business logic to believe a transaction send has failed
920 2016-12-01 23:24:41	0|bitcoin272|and resend it
921 2016-12-01 23:24:50	0|bitcoin272|only for the wallet to send the same coins again when the parents confirm
922 2016-12-01 23:24:58	0|bitcoin272|resulting in multiple payments being facilitated
923 2016-12-01 23:25:02	0|sipa|yup
924 2016-12-01 23:25:03	0|bitcoin272|most unfortunate indeed
925 2016-12-01 23:25:27	0|bitcoin272|okay well this is a start
926 2016-12-01 23:25:35	0|bitcoin272|and this would've never been apparent pre 0.12 right
927 2016-12-01 23:25:41	0|BlueMatt|aaccctuuallllyyyyy....anyone have any objections if main.cpp gets renamed to "blocktxprocessing.cpp"?
928 2016-12-01 23:25:46	0|sipa|indeed
929 2016-12-01 23:25:53	0|bitcoin272|okay
930 2016-12-01 23:25:56	0|bitcoin272|sipa, I really appreciate this
931 2016-12-01 23:25:58	0|bitcoin272|this clarifies things
932 2016-12-01 23:26:22	0|bitcoin272|what is a reasonable limitancestorcount if resource consumption is low
933 2016-12-01 23:26:46	0|sipa|bitcoin272: thanks; if you have further results, can you comment here? https://github.com/bitcoin/bitcoin/issues/9019
934 2016-12-01 23:27:06	0|sipa|bitcoin272: you're not mining, right?
935 2016-12-01 23:27:16	0|bitcoin272|nope
936 2016-12-01 23:27:26	0|bitcoin272|I am going to bump ancestor/descendant count to 200
937 2016-12-01 23:27:32	0|sipa|that sounds reasonable to me
938 2016-12-01 23:27:42	0|sipa|just to be clear: don't expect these chains to confirm quickly
939 2016-12-01 23:28:03	0|sipa|because other nodes in the network won't accept these long chains, at least not immediately
940 2016-12-01 23:28:15	0|sipa|on rebroadcasts they should go out piecewise, though
941 2016-12-01 23:28:33	0|bitcoin272|well
942 2016-12-01 23:28:40	0|bitcoin272|it's more important that the sendtoaddress command doesn't fail
943 2016-12-01 23:28:45	0|bitcoin272|but still enqueue an automatic payment
944 2016-12-01 23:28:48	0|bitcoin272|that is 100% the most important
945 2016-12-01 23:28:53	0|bitcoin272|we just need sendtoaddress to return a txid
946 2016-12-01 23:29:14	0|bitcoin272|whether or not it hits the network immediately isn't so bad, we just can't have sendtoaddress failing but also having the wallet sending the coins again of its own accord
947 2016-12-01 23:33:40	0|bitcoin272|is there a way to purge a transaction
948 2016-12-01 23:33:45	0|bitcoin272|so it doesn't send?
949 2016-12-01 23:33:49	0|bitcoin272|(on this automatic queue)
950 2016-12-01 23:34:43	0|bitcoin272|will abandontransaction do it?
951 2016-12-01 23:38:34	0|sipa|yes
952 2016-12-01 23:38:58	0|sipa|that's the intended behaviour... if your transaction doesn't confirm and gets evicted, you can manually abandon it
953 2016-12-01 23:39:09	0|sipa|though it's not very well integrated or good guidelines for it
954 2016-12-01 23:39:15	0|bitcoin272|i hear you
955 2016-12-01 23:39:28	0|bitcoin272|well
956 2016-12-01 23:39:29	0|sipa|as that obviously doesn't guarantee that the old one won't confirm still if it went out to the network
957 2016-12-01 23:39:32	0|bitcoin272|this has been a fun day, lol
958 2016-12-01 23:39:34	0|bitcoin272|right
959 2016-12-01 23:39:55	0|sipa|there is work on a bumpfee command which will use bip125 to increase a txn's fee, and replace it with another one
960 2016-12-01 23:40:39	0|bitcoin272|so, the biggest issue with this ancestor/descendant stuff is that the wallet doesn't keep count of how many are chained when doing input selection
961 2016-12-01 23:40:45	0|sipa|indeed
962 2016-12-01 23:40:48	0|bitcoin272|and sendtoaddress fails but it enqueues the transaction for broadcast automatically
963 2016-12-01 23:42:50	0|bitcoin272|is there any way to verify what the ancestor limit is
964 2016-12-01 23:42:56	0|bitcoin272|I bumped both limits to 250
965 2016-12-01 23:43:07	0|bitcoin272|just want to know if it's reflected in current config (I restarted daemon)
966 2016-12-01 23:44:42	0|sipa|if you used the correct option name, it should
967 2016-12-01 23:44:52	0|sipa|limitancestorcount=250
968 2016-12-01 23:44:55	0|sipa|in bitcoin.conf
969 2016-12-01 23:48:58	0|sipa|BlueMatt: so there will be the blockprocessing file and the rest? where does ProcessMessage go?
970 2016-12-01 23:49:08	0|BlueMatt|sipa: net_processing
971 2016-12-01 23:49:20	0|BlueMatt|net_processing.cpp and blocktx_processing.cpp
972 2016-12-01 23:49:29	0|BlueMatt|or blockandtxprocessing.cpp
973 2016-12-01 23:49:34	0|sipa|and will there still be main.cpp?
974 2016-12-01 23:49:38	0|BlueMatt|no
975 2016-12-01 23:49:40	0|BlueMatt|(!)
976 2016-12-01 23:49:56	0|sipa|really, is there nothing that doesn't fit either of those
977 2016-12-01 23:50:22	0|BlueMatt|theres some variables declared that dont
978 2016-12-01 23:50:24	0|BlueMatt|but aside from that, not really
979 2016-12-01 23:52:38	0|BlueMatt|FormatStateMessage, GetTransaction, AbortNode are the only things you can argue in that file (outside of declarations) dont fall into mempool/block processing/block disk state management
980 2016-12-01 23:52:50	0|BlueMatt|and all of those arguably do
981 2016-12-01 23:53:50	0|sipa|GetTransaction, LastCommonAncestor, FormatStateMessage, AlertNotify, GetWarnings,
982 2016-12-01 23:53:57	0|gmaxwell|bitcoin272: aside and unrelated to your issues, you should _really_ adjust your workflow to use sendmany. And if you cannot for some reason and must continue to depend on unconfirmed chains you should start paying higher fees than default to assure that they get confirmed relatively quickly.
983 2016-12-01 23:54:20	0|BlueMatt|AlertNotify is used exclusively for fork notification
984 2016-12-01 23:54:24	0|BlueMatt|and GetWarnings mostly is as well
985 2016-12-01 23:54:26	0|sipa|BlueMatt: how about calling it validation.cpp?
986 2016-12-01 23:54:28	0|bitcoin272|gmaxwell: understood, thank you
987 2016-12-01 23:54:33	0|BlueMatt|ok!
988 2016-12-01 23:54:56	0|sipa|BlueMatt: in that it's a bit more generic than just processing... something like TestBlockValidity would go there as well, i guess
989 2016-12-01 23:55:04	0|gmaxwell|bitcoin272: you can also split up coins you deposit into the wallet to reduce the need for chaining
990 2016-12-01 23:55:09	0|bitcoin272|gmaxwell: yup
991 2016-12-01 23:55:43	0|gmaxwell|e.g. if you were going to put 10 BTC in that will likely be paid out in .9 BTC chunks,  making your payment of ten is as a sendmany with ten 1 BTC outputs would be prudent.