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