12016-12-01T00:11:40 <bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/56bee4986d11...a143b88dbd49
22016-12-01T00:11:41 <bitcoin-git> bitcoin/master 0cc8b6b Wladimir J. van der Laan: init: Split up AppInit2 into multiple phases...
32016-12-01T00:11:41 <bitcoin-git> bitcoin/master 16ca0bf Wladimir J. van der Laan: init: Try to aquire datadir lock before and after daemonization...
42016-12-01T00:11:42 <bitcoin-git> bitcoin/master deec83f Wladimir J. van der Laan: init: Get rid of fServer flag...
52016-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
62016-12-01T00:15:39 <gmaxwell> hurrah
72016-12-01T00:15:48 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a143b88dbd49...72ae6f8cf022
82016-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.
92016-12-01T00:15:49 <bitcoin-git> bitcoin/master 72ae6f8 Pieter Wuille: Merge #9244: Trivial refactor: Remove extern keyword from function declarations...
102016-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
112016-12-01T00:31:20 *** harrymm has quit IRC
122016-12-01T00:32:48 *** moli has quit IRC
132016-12-01T00:33:27 *** moli has joined #bitcoin-core-dev
142016-12-01T00:34:45 *** windsok has quit IRC
152016-12-01T00:38:21 *** harrymm has joined #bitcoin-core-dev
162016-12-01T00:40:49 *** alpalp has joined #bitcoin-core-dev
172016-12-01T00:50:33 *** windsok has joined #bitcoin-core-dev
182016-12-01T00:54:49 *** windsok has quit IRC
192016-12-01T00:56:56 *** droark has joined #bitcoin-core-dev
202016-12-01T01:16:21 <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/72ae6f8cf022...3bf06e9bac57
212016-12-01T01:16:22 <bitcoin-git> bitcoin/master 083f203 Gregory Maxwell: Remove fNetworkNode....
222016-12-01T01:16:22 <bitcoin-git> bitcoin/master bdb922b Gregory Maxwell: Remove pnodeLocalHost....
232016-12-01T01:16:23 <bitcoin-git> bitcoin/master 3bf06e9 Pieter Wuille: Merge #9226: Remove fNetworkNode and pnodeLocalHost....
242016-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
252016-12-01T01:18:59 *** windsok has joined #bitcoin-core-dev
262016-12-01T01:56:22 *** abpa has quit IRC
272016-12-01T02:02:35 <phantomcircuit> ok can someone explain why nWalletDBUpdateCounter doesn't work as a static member of CWalletDB ?
282016-12-01T02:02:38 <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/9227/files
292016-12-01T02:02:46 <phantomcircuit> works fine as a static in the file
302016-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
312016-12-01T02:06:01 <phantomcircuit> oh
322016-12-01T02:06:05 <phantomcircuit> yeah that's not right
332016-12-01T02:06:12 <phantomcircuit> git exploded and i put it there but yeah
342016-12-01T02:06:40 <phantomcircuit> fixed
352016-12-01T02:07:19 <phantomcircuit> what's there now is right and works
362016-12-01T02:07:35 *** rafalcpp_ has joined #bitcoin-core-dev
372016-12-01T02:07:57 *** rafalcpp has quit IRC
382016-12-01T02:19:37 <BlueMatt> argggg, sipa
392016-12-01T02:19:48 <BlueMatt> please dont rebase when you squash unless you need to :(
402016-12-01T02:20:32 <BlueMatt> that said, #8580 needs rebased again :p
412016-12-01T02:20:36 <gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
422016-12-01T02:29:03 <sipa> BlueMatt: i needed to
432016-12-01T02:29:08 <BlueMatt> ahh, ok
442016-12-01T02:29:21 <sipa> i actually first updated without rebasing
452016-12-01T02:29:26 <sipa> and then it was grey in github
462016-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"
472016-12-01T02:29:41 <BlueMatt> I need to build a script for that
482016-12-01T02:29:44 <sipa> yup
492016-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
502016-12-01T02:31:52 <BlueMatt> yea, probably
512016-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
522016-12-01T02:33:02 <BlueMatt> (ofc this assumes we continue to use git as if it were not git, but...whatever)
532016-12-01T02:52:40 *** Ylbam has quit IRC
542016-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
552016-12-01T03:13:58 *** abpa has joined #bitcoin-core-dev
562016-12-01T03:25:12 <Victorsueca> kaspersky is marking bitcoin-qt as coin stealing malware
572016-12-01T03:25:53 <Victorsueca> and in my case is compiled from source so... doubt it's a fake executable
582016-12-01T03:26:22 <sipa> sogh
592016-12-01T03:26:23 <sipa> sigh
602016-12-01T03:26:55 <achow101> Victorsueca: it's marked as coin stealing because it looks for a wallet.dat file :/
612016-12-01T03:27:16 <Victorsueca> achow101: lol
622016-12-01T03:27:21 <Victorsueca> 404 logic not found
632016-12-01T03:27:28 *** rafalcpp_ has quit IRC
642016-12-01T03:27:42 <achow101> and sometimes they mark it as a bitcoin miner
652016-12-01T03:28:13 *** rafalcpp_ has joined #bitcoin-core-dev
662016-12-01T03:28:31 <Victorsueca> guess somebody will have to contact kaspersky so they whitelist it
672016-12-01T03:34:17 *** CubicEarth has joined #bitcoin-core-dev
682016-12-01T03:48:11 *** QinGW has joined #bitcoin-core-dev
692016-12-01T03:55:25 *** QinGW has quit IRC
702016-12-01T03:55:29 *** QinGW` has joined #bitcoin-core-dev
712016-12-01T03:59:32 *** QinGW`` has joined #bitcoin-core-dev
722016-12-01T03:59:56 *** QinGW` has quit IRC
732016-12-01T04:02:25 *** QinGW`` has quit IRC
742016-12-01T04:06:49 *** Atomicat_ has joined #bitcoin-core-dev
752016-12-01T04:09:44 *** Atomicat has quit IRC
762016-12-01T04:09:50 *** Atomicat_ is now known as Atomicat
772016-12-01T04:12:53 *** Chris_Stewart_5 has quit IRC
782016-12-01T04:21:05 <phantomcircuit> Victorsueca, that sounds like it's doing the right thing actually
792016-12-01T04:21:09 <phantomcircuit> you compiled a binary yourself
802016-12-01T04:21:11 <phantomcircuit> so it's unique
812016-12-01T04:21:16 <phantomcircuit> which is trying to open wallet.dat
822016-12-01T04:25:25 *** alpalp has quit IRC
832016-12-01T04:28:47 *** justanotheruser is now known as hairyengineer
842016-12-01T04:36:05 *** hairyengineer is now known as justanotheruser
852016-12-01T04:45:34 <luke-jr> phantomcircuit: that's not the right thing to do :/
862016-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
872016-12-01T04:55:33 *** abpa has quit IRC
882016-12-01T05:31:48 *** molz has joined #bitcoin-core-dev
892016-12-01T05:34:45 *** moli has quit IRC
902016-12-01T05:36:30 *** jtimon has quit IRC
912016-12-01T06:04:49 *** rebroad has joined #bitcoin-core-dev
922016-12-01T06:05:08 <rebroad> hi all. I've just identified a DoS vuln, which can crash the latest master
932016-12-01T06:05:13 <rebroad> want to report it responsibly
942016-12-01T06:05:55 <rebroad> I don't have PGP set up though..
952016-12-01T06:06:06 <rebroad> (have signal, telegram)
962016-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
972016-12-01T06:17:42 *** btcdrak_ has quit IRC
982016-12-01T06:20:49 *** btcdrak has joined #bitcoin-core-dev
992016-12-01T06:21:02 *** btcdrak has quit IRC
1002016-12-01T06:21:27 *** btcdrak has joined #bitcoin-core-dev
1012016-12-01T06:32:37 <sipa> rebroad: if it's not in a release, it's likely fine to disclose
1022016-12-01T06:32:49 *** rebroad has quit IRC
1032016-12-01T06:38:28 *** bobbytux_ has joined #bitcoin-core-dev
1042016-12-01T06:39:08 <gmaxwell> I'm around now.
1052016-12-01T06:39:28 <gmaxwell> q
1062016-12-01T06:39:40 *** bobbytux has quit IRC
1072016-12-01T06:45:42 *** rebroad has joined #bitcoin-core-dev
1082016-12-01T06:50:11 *** Alopex has quit IRC
1092016-12-01T06:51:00 *** Ylbam has joined #bitcoin-core-dev
1102016-12-01T06:51:17 *** Alopex has joined #bitcoin-core-dev
1112016-12-01T07:00:22 <paveljanik> rebroad, you do not need to have PGP to send mail to security@...
1122016-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
1132016-12-01T07:06:12 <sipa> it's not like https://bitcoincore.org/en/contact/ lists an encryption key..
1142016-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.
1152016-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. :)
1162016-12-01T07:07:58 <wumpus> I just mean that security@* is private enough
1172016-12-01T07:08:55 <wumpus> and indeed we don't even list an encryption key there
1182016-12-01T07:09:06 <gmaxwell> yea. indeed. well we should.
1192016-12-01T07:09:23 <gmaxwell> I seem to recall some parties previously being opposed to that.
1202016-12-01T07:09:28 <wumpus> how do you want to do that? a shared key?
1212016-12-01T07:10:25 <sipa> gpg needs 1-of-n multisig encryption.
1222016-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
1232016-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)
1242016-12-01T07:11:06 <gmaxwell> shared key would work fine. doesn't even need to be everyone, but should be more than one.
1252016-12-01T07:11:24 <phantomcircuit> rebroad, i promise to act as 1-n for people i deem to be in the set
1262016-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
1272016-12-01T07:11:34 <phantomcircuit> "multisig as trust in patrick"
1282016-12-01T07:11:46 <gmaxwell> sipa: unfortunately multiple recipents is too much to ask of the sender.
1292016-12-01T07:12:02 <gmaxwell> probably we should have some webform on bitcoin-core.org that does gpg in the browser.
1302016-12-01T07:12:04 <wumpus> it's too much to ask of the sender and it is an information leak in itself
1312016-12-01T07:12:05 <sipa> this is what openssl does: https://www.openssl.org/news/vulnerabilities.html
1322016-12-01T07:12:26 <gmaxwell> there is browser gpg..
1332016-12-01T07:12:29 <sipa> (shared key, and suggests mailing individual members with their keys)
1342016-12-01T07:12:38 <wumpus> gmaxwell: how is that more secure than just having a SSL-encrypted page?
1352016-12-01T07:13:14 <gmaxwell> wumpus: because when its saved on the webserver the data doesn't lay around in a vulnerable form.
1362016-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 :)
1372016-12-01T07:13:21 <gmaxwell> compromise is only point in time forward.
1382016-12-01T07:13:29 <wumpus> well the websever could also encrypt it when it receives it
1392016-12-01T07:13:39 <wumpus> I think we are overdesigining this
1402016-12-01T07:13:45 <wumpus> let's generate a shared key?
1412016-12-01T07:13:52 *** wasi has quit IRC
1422016-12-01T07:14:12 <sipa> sure
1432016-12-01T07:14:29 *** wasi has joined #bitcoin-core-dev
1442016-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
1452016-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
1462016-12-01T07:15:05 <wumpus> s/chance/time/
1472016-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
1482016-12-01T07:15:51 <gmaxwell> sure. in any case, someone can do it if they have the time/interest.
1492016-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
1502016-12-01T07:17:37 *** crudel has quit IRC
1512016-12-01T07:17:38 <gmaxwell> at least blabbing in here doesn't make it attractive to hack our email. :)
1522016-12-01T07:18:23 <rebroad> perhaps rather than using PGP keys we could use bitcoin address keys
1532016-12-01T07:18:40 <gmaxwell> that would only make things worse.
1542016-12-01T07:18:41 <wumpus> so instead of this meta talk, can you just let us know the issue please?
1552016-12-01T07:18:49 <gmaxwell> oh rebroad is here.
1562016-12-01T07:18:55 <rebroad> wumpus, ah, it was a false alarm (said above)
1572016-12-01T07:19:15 <wumpus> gah
1582016-12-01T07:19:20 <wumpus> *goes back to bed*
1592016-12-01T07:19:21 <gmaxwell> rebroad: we missed where you said that.
1602016-12-01T07:19:29 <rebroad> although i did lose internet shortly after so perhaps it didn't send
1612016-12-01T07:19:34 <gmaxwell> (doesn't show up in the logs)
1622016-12-01T07:19:49 <rebroad> this is the problem with IRC.. I never know which messages have sent :-s
1632016-12-01T07:20:00 <rebroad> why don't we use slack or something more "modern"?
1642016-12-01T07:20:03 <Lightsword> rebroad, use a bouncer
1652016-12-01T07:20:09 <Lightsword> then you can check logs on it
1662016-12-01T07:20:09 <wumpus> I never have that problem on IRC, my client reports when a message couldn't send.
1672016-12-01T07:20:33 <rebroad> wumpus, what client are you using please? I need to switch
1682016-12-01T07:20:34 <wumpus> no, we will not switch to a proprietary solution
1692016-12-01T07:20:46 <rebroad> wumpus, fair point. opensource is the way
1702016-12-01T07:21:02 <Lightsword> rebroad http://wiki.znc.in/ZNC
1712016-12-01T07:21:03 <sipa> i'm using irssi, running inside screen, on a vps
1722016-12-01T07:21:03 <rebroad> (and decentralized of course)
1732016-12-01T07:21:14 <wumpus> rebroad: I've used "quassel" and "irssi" and they both have that functionality
1742016-12-01T07:21:16 <Lightsword> znc lets you use a normal client with it
1752016-12-01T07:21:55 <rebroad> i hope no one actually got woken up to deal with this non-issue :-s
1762016-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
1772016-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
1782016-12-01T07:22:49 <wumpus> well it didn't wake me up literally, i was awake, but it caused a stressful morning agian
1792016-12-01T07:22:53 <Lightsword> netsplits still happen
1802016-12-01T07:22:58 <sipa> rebroad: distributed doesn't mean decentralized
1812016-12-01T07:23:11 <sipa> you can't just run your own server and join the network
1822016-12-01T07:23:17 <sipa> you can start your own network however
1832016-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
1842016-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.
1852016-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...
1862016-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!
1872016-12-01T07:25:02 <wumpus> gmaxwell: well you can use IRC to connect with slack - but anyhow let's not go there
1882016-12-01T07:25:09 <rebroad> wumpus, I do like how slack lets one quote previous messages.. sort of threading in a sense
1892016-12-01T07:25:34 <sipa> rebroad> wumpus, I do like how slack lets one quote previous messages.. sort of threading in a sense
1902016-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.
1912016-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 :)
1922016-12-01T07:25:51 *** moli has joined #bitcoin-core-dev
1932016-12-01T07:25:57 *** aalex_ has joined #bitcoin-core-dev
1942016-12-01T07:26:06 <wumpus> yea here you can do the age-old thing for quoting: just copy/paste
1952016-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!
1962016-12-01T07:27:23 <wumpus> rebroad: and you didn't even disconnect in between
1972016-12-01T07:27:29 <rebroad> weird...
1982016-12-01T07:27:34 <wumpus> rebroad: looks more like a client issue than a network one
1992016-12-01T07:27:41 <Lightsword> maybe you should set up a cheap VPS and run a client from there
2002016-12-01T07:27:42 <wumpus> unless someone is MiTMing you
2012016-12-01T07:27:59 * Lightsword wants a good self hosted version of irccloud
2022016-12-01T07:28:20 <rebroad> using hexchat - prett standard on linux
2032016-12-01T07:28:49 *** molz has quit IRC
2042016-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
2052016-12-01T07:29:03 <Lightsword> and if ssh is unreliable you can even use mosh
2062016-12-01T07:29:10 <sipa> i use mosh
2072016-12-01T07:29:14 <wumpus> mosh <3
2082016-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
2092016-12-01T07:30:12 <rebroad> sandwiches between two quotes
2102016-12-01T07:30:16 <gmaxwell> with how unreliable rebroad's connection has been in the past, I bet he'd like mosh.
2112016-12-01T07:30:21 <rebroad> s/sandwiches/sandwiched
2122016-12-01T07:30:25 <wumpus> another false positive :p need to be more careful in checking things
2132016-12-01T07:30:37 <rebroad> anothing thing I like about slack - i can edit spelling mistakes
2142016-12-01T07:30:40 <rebroad> (or telegram, etc)
2152016-12-01T07:30:54 <rebroad> somethng opensource like telegram would be nice - they have group chats on there
2162016-12-01T07:31:00 <gmaxwell> msitakes?
2172016-12-01T07:31:04 <gmaxwell> s/msitakes/mistakes/
2182016-12-01T07:31:21 <wumpus> well it won't just let you edit spelling mistakes, also other mistakes, or retroactively change statements/opinions
2192016-12-01T07:31:24 <rebroad> heh.. just need a front-end to parse those "s/" messages!
2202016-12-01T07:31:26 <paveljanik> gmaxwell, :-) You s/yes/no/.
2212016-12-01T07:31:33 <wumpus> "we've always been at war with eurasia"
2222016-12-01T07:31:55 <rebroad> anyway, enough of this silliness^H^H^H^H^H^H^H^H^H^Husefulness
2232016-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. :)
2242016-12-01T07:32:22 <sipa> stackexchange lets you modify comments for up to a few minutes
2252016-12-01T07:32:27 <wumpus> just need a front-end to parse those "s/" messages <- haha that'd be fun
2262016-12-01T07:32:28 <sipa> which is very useful
2272016-12-01T07:32:48 <wumpus> too much bother to implement though, seems my brain works well enough as a parser/frontend for that
2282016-12-01T07:32:48 <sipa> i have a few plugins in my irc client
2292016-12-01T07:32:56 <rebroad> RBF for chat :)
2302016-12-01T07:33:02 <sipa> mff fppppfpppmpmmpppff fppmfpppf mfpmpppffmpp fmfpppmpmmpppfffmmfmpmmmpppmpmfmm pmpmppppppppffm
2312016-12-01T07:33:11 * Lightsword think it wouldnât be that hard to build a decent irc web client like irccloud using twisted
2322016-12-01T07:33:21 <rebroad> sipa wtf?
2332016-12-01T07:33:22 <wumpus> gmaxwell: yeah you can do a full fledged chat by just editing two messages
2342016-12-01T07:33:35 <rebroad> sipa is that dinosaur dna?
2352016-12-01T07:33:46 <sipa> rebroad: it's a code called "kenny" which turns text into only [fmp ]
2362016-12-01T07:33:53 <rebroad> ahhh!
2372016-12-01T07:33:59 <sipa> and with a plugin it gets decoded automatically
2382016-12-01T07:34:09 <rebroad> lol
2392016-12-01T07:34:15 <sipa> Çuo sÄ±É¥Ê ÇÊÄ±Ê 'sɹÇÉ¥Êo ÊÇÉ É ÇÊÉÉ¥ ı
2402016-12-01T07:35:16 * rebroad has plugin envy
2412016-12-01T07:35:41 <rebroad> the upsidedown l looks suspect
2422016-12-01T07:35:45 *** protomar has joined #bitcoin-core-dev
2432016-12-01T07:35:49 * wumpus tries to recover his context before this kerfuffle, but apparently that part of memory has been overwritten
2442016-12-01T07:35:51 * Lightsword wonders if sipa has any that can send RCE exploits to take over other users IRC clients
2452016-12-01T07:35:57 <rebroad> lol
2462016-12-01T07:36:15 <rebroad> wumpus, you needed to wait for 6 conformations for it to count
2472016-12-01T07:36:22 <sipa> PC LOAD LETTER
2482016-12-01T07:36:26 <rebroad> s/conformations/confirmations
2492016-12-01T07:36:47 <gmaxwell> /exec -o <command> runs an arbritary command in most clients and puts it into IRC... envy plugins no more...
2502016-12-01T07:36:55 <gmaxwell> 123456789011: 123456789011
2512016-12-01T07:37:03 <gmaxwell> ^ see, factor
2522016-12-01T07:37:08 <rebroad> I'll confirm the use of the word kerfuffle though
2532016-12-01T07:37:28 <Lightsword> hmm, I think znc actually has a plugin that lets you execute shell commands over IRC
2542016-12-01T07:37:49 <gmaxwell> disquiet's
2552016-12-01T07:37:52 <gmaxwell> /exec -o shuf -n1 /usr/share/dict/words
2562016-12-01T07:38:31 <sipa> <sipa> exasperated
2572016-12-01T07:38:37 <sipa> (first try)
2582016-12-01T07:38:59 <sipa> wumpus: the context was that you were going back to sleep
2592016-12-01T07:39:51 <rebroad> hmmm.. blockchain based chat... now that would be decentralized properly..
2602016-12-01T07:40:01 <sipa> try bitmessage
2612016-12-01T07:40:27 <rebroad> sipa, any advantage over IRC?
2622016-12-01T07:40:32 <sipa> no
2632016-12-01T07:40:42 <wumpus> and puts the burden of storing your logs on everyone on the network - yea, that'd work
2642016-12-01T07:40:51 <sipa> and not sure if you're serious, but public blockchains don't actually work without the incentive of subsidy
2652016-12-01T07:41:10 <sipa> which makes non-currency use pretty unsustainable
2662016-12-01T07:41:11 <rebroad> sipa, speaking of that. dash has more nodes than bitcoin due to that I think
2672016-12-01T07:41:45 <gmaxwell> bitmessage isn't a blockchain, its a hashcash ratelimited flooding network.
2682016-12-01T07:41:47 <rebroad> and they are funding quite a few things from the blockchain also
2692016-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.
2702016-12-01T07:42:19 <gmaxwell> rebroad: please don't talk about dash here.
2712016-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
2722016-12-01T07:42:50 <wumpus> but if used through tor I guess it's pretty hard to do metadata analysis
2732016-12-01T07:43:07 <rebroad> gmaxwell, just referring to it as an example in the context of what sipa just said
2742016-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
2752016-12-01T07:44:07 <rebroad> gmaxwell, it's ok to talk about bitmessage but not dash?
2762016-12-01T07:44:31 <rebroad> luke-jr, good point indeed
2772016-12-01T07:44:38 <sipa> this whole discussion is off topic now
2782016-12-01T07:44:45 <rebroad> luke-jr, although are you meaning to imply dash is a scamcoin?
2792016-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.
2802016-12-01T07:45:15 <wumpus> but yes it's done
2812016-12-01T07:45:18 <wumpus> back to coding
2822016-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
2832016-12-01T07:45:32 <rebroad> sipa, it is drifting occaionally OT but comes back to bitcoin often enough :)
2842016-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
2852016-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.
2862016-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.
2872016-12-01T07:47:46 <wumpus> tldr: it's a waste of everyone's attention here
2882016-12-01T07:48:44 <wumpus> too easy to get into fights, people feel too strongly about those things, this is a no-politics channel
2892016-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?
2902016-12-01T07:49:28 <wumpus> please take it elsewhere
2912016-12-01T07:49:40 <rebroad> "it"?
2922016-12-01T07:49:46 <wumpus> yes. This whole thread.
2932016-12-01T07:49:53 <luke-jr> rebroad: ##altcoin-dev is a real channel you can discuss said things in
2942016-12-01T07:50:07 <rebroad> I have lost the thread by now
2952016-12-01T07:50:39 <rebroad> I am not clear on what thread is being referred to nor what are the taboo subjects
2962016-12-01T07:50:50 <sipa> altcoins are definitely off topic
2972016-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)
2982016-12-01T07:51:29 <wumpus> "Bitcoin Core development discussion and commit log"
2992016-12-01T07:51:30 <rebroad> sipa, so you mean mentioning them by name?
3002016-12-01T07:51:57 <luke-jr> rebroad: there is no context on topic to this channel where mentioning them by name would make sense.
3012016-12-01T07:52:14 <rebroad> I am also unsure what the definition of "altcoin" is
3022016-12-01T07:52:14 <sipa> we used to have a link to channel rules
3032016-12-01T07:52:21 <sipa> rebroad: other cryptocurrencies
3042016-12-01T07:52:23 <wumpus> rebroad: go discuss that elsewhere
3052016-12-01T07:52:32 <sipa> now, let's get back to development
3062016-12-01T07:52:35 <wumpus> this is also not the meta-channel "what to discuss in #bitcoin-core-dev"
3072016-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?
3082016-12-01T07:54:06 <luke-jr> #bitcoin is as meta as I know of
3092016-12-01T07:55:47 <rebroad> or #bitcoin-dev I'd have thought, since development is the key desire to talk about
3102016-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.
3112016-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
3122016-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
3132016-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
3142016-12-01T07:59:32 <luke-jr> rebroad: seek clarification in #bitcoin, not here
3152016-12-01T07:59:47 <rebroad> so it is really frustrating to come up against this again given all the proactivity so far
3162016-12-01T08:00:05 *** aalex_ has quit IRC
3172016-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.
3182016-12-01T08:01:22 <rebroad> sipa, thank you for that clarification. EOT
3192016-12-01T08:04:29 *** Giszmo has quit IRC
3202016-12-01T08:13:59 *** jl2012 has quit IRC
3212016-12-01T08:14:40 *** jl2012 has joined #bitcoin-core-dev
3222016-12-01T08:22:52 *** rebroad has quit IRC
3232016-12-01T08:24:13 *** LeMiner2 has joined #bitcoin-core-dev
3242016-12-01T08:25:52 *** LeMiner has quit IRC
3252016-12-01T08:25:52 *** LeMiner2 is now known as LeMiner
3262016-12-01T08:27:41 *** moli has quit IRC
3272016-12-01T08:28:07 *** moli has joined #bitcoin-core-dev
3282016-12-01T08:28:11 *** LeMiner2 has joined #bitcoin-core-dev
3292016-12-01T08:28:40 *** Cory has quit IRC
3302016-12-01T08:30:32 *** LeMiner has quit IRC
3312016-12-01T08:30:33 *** LeMiner2 is now known as LeMiner
3322016-12-01T08:31:37 *** Cory has joined #bitcoin-core-dev
3332016-12-01T08:36:12 <jonasschnelli> sipa: why would it break backwards compatibility?
3342016-12-01T08:36:18 <jonasschnelli> (remove of the default key)
3352016-12-01T08:36:36 <jonasschnelli> Because of fFirstRunRet?
3362016-12-01T08:36:40 <sipa> jonasschnelli: yup
3372016-12-01T08:36:50 <jonasschnelli> hmm..
3382016-12-01T08:37:19 <sipa> specifically, not having a default key in a wallet file would cause it to write the current chainstate
3392016-12-01T08:37:28 <sipa> and thus potentially miss a rescan
3402016-12-01T08:37:51 <sipa> writing a dummy default key... could result in the old wallet giving it out as address
3412016-12-01T08:38:15 <luke-jr> what's the harm in having a dummy default key that's actually in the wallet? O.o
3422016-12-01T08:38:30 <jonasschnelli> I don't like the default key for two reasons...
3432016-12-01T08:38:31 <sipa> luke-jr: that's basically what we have now :D
3442016-12-01T08:38:38 <jonasschnelli> 1) seems to be unused/miused
3452016-12-01T08:38:41 <luke-jr> exactly; I miss context as to why it should change
3462016-12-01T08:38:48 <jonasschnelli> 2) I want to have a private-key free wallet mode
3472016-12-01T08:38:57 <luke-jr> jonasschnelli: just pretend it isn't there?
3482016-12-01T08:38:59 <sipa> luke-jr: technical debt
3492016-12-01T08:39:29 <jonasschnelli> We probably should have removed it with 0.13 hd wallets (not backward comp.)
3502016-12-01T08:47:19 *** LeMiner has quit IRC
3512016-12-01T08:48:56 *** LeMiner has joined #bitcoin-core-dev
3522016-12-01T08:50:34 *** wasi has quit IRC
3532016-12-01T08:51:51 *** wasi has joined #bitcoin-core-dev
3542016-12-01T09:02:22 *** shesek has quit IRC
3552016-12-01T09:25:21 *** Atomicat_ has joined #bitcoin-core-dev
3562016-12-01T09:25:40 *** cysm has quit IRC
3572016-12-01T09:26:36 *** Atomicat has quit IRC
3582016-12-01T09:26:44 *** Atomicat_ is now known as Atomicat
3592016-12-01T09:30:07 *** laurentmt has joined #bitcoin-core-dev
3602016-12-01T09:40:28 *** laurentmt has quit IRC
3612016-12-01T09:51:04 *** Atomicat has quit IRC
3622016-12-01T09:52:05 *** ratoder has quit IRC
3632016-12-01T09:57:55 *** LeMiner has quit IRC
3642016-12-01T09:57:56 *** LeMiner has joined #bitcoin-core-dev
3652016-12-01T09:57:56 *** LeMiner has joined #bitcoin-core-dev
3662016-12-01T10:18:55 *** Atomicat has joined #bitcoin-core-dev
3672016-12-01T10:26:46 *** jannes has joined #bitcoin-core-dev
3682016-12-01T10:31:10 *** sdaftuar_ has joined #bitcoin-core-dev
3692016-12-01T10:32:27 *** phantomcircuit has quit IRC
3702016-12-01T10:32:34 *** ghtdak has quit IRC
3712016-12-01T10:36:14 *** phantomcircuit has joined #bitcoin-core-dev
3722016-12-01T10:39:04 *** LeMiner has quit IRC
3732016-12-01T10:39:04 *** Evel-Knievel has quit IRC
3742016-12-01T10:39:04 *** TD-Linux has quit IRC
3752016-12-01T10:39:05 *** juscamarena has quit IRC
3762016-12-01T10:39:05 *** xiangfu has quit IRC
3772016-12-01T10:39:05 *** sdaftuar has quit IRC
3782016-12-01T10:39:05 *** warren has quit IRC
3792016-12-01T10:42:17 *** Evel-Knievel has joined #bitcoin-core-dev
3802016-12-01T10:42:22 *** dcousens has quit IRC
3812016-12-01T10:42:40 *** dcousens has joined #bitcoin-core-dev
3822016-12-01T10:43:34 *** LeMiner has joined #bitcoin-core-dev
3832016-12-01T10:43:34 *** 7GHAAUHIH has joined #bitcoin-core-dev
3842016-12-01T10:43:34 *** TD-Linux has joined #bitcoin-core-dev
3852016-12-01T10:43:34 *** juscamarena has joined #bitcoin-core-dev
3862016-12-01T10:43:34 *** xiangfu has joined #bitcoin-core-dev
3872016-12-01T10:43:34 *** warren has joined #bitcoin-core-dev
3882016-12-01T10:44:00 *** 7GHAAUHIH has quit IRC
3892016-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
3902016-12-01T10:47:04 *** ghtdak has joined #bitcoin-core-dev
3912016-12-01T10:48:10 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bf06e9bac57...c79e52ad304a
3922016-12-01T10:48:11 <bitcoin-git> bitcoin/master 507145d Matt Corallo: Fix race when accessing std::locale::classic()...
3932016-12-01T10:48:12 <bitcoin-git> bitcoin/master 8b22efb Matt Corallo: Make fStartedNewLine an std::atomic_bool...
3942016-12-01T10:48:12 <bitcoin-git> bitcoin/master c79e52a Wladimir J. van der Laan: Merge #9230: Fix some benign races in timestamp logging...
3952016-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
3962016-12-01T10:56:16 *** Guyver2 has joined #bitcoin-core-dev
3972016-12-01T11:02:18 *** ghtdak has quit IRC
3982016-12-01T11:04:38 *** ghtdak has joined #bitcoin-core-dev
3992016-12-01T11:20:07 *** protomar has quit IRC
4002016-12-01T11:20:26 *** ThomasV has joined #bitcoin-core-dev
4012016-12-01T11:38:21 *** aalex_ has joined #bitcoin-core-dev
4022016-12-01T11:45:16 *** aalex_ has quit IRC
4032016-12-01T11:45:40 *** ThomasV has quit IRC
4042016-12-01T11:50:59 *** waxwing has quit IRC
4052016-12-01T11:58:58 *** waxwing has joined #bitcoin-core-dev
4062016-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
4072016-12-01T12:18:41 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9143
4082016-12-01T12:32:02 *** dcousens has quit IRC
4092016-12-01T12:33:43 *** dcousens has joined #bitcoin-core-dev
4102016-12-01T12:56:11 *** CubicEarth has quit IRC
4112016-12-01T13:22:43 *** dermoth_ has joined #bitcoin-core-dev
4122016-12-01T13:23:09 *** dermoth has quit IRC
4132016-12-01T13:23:11 *** dermoth_ is now known as dermoth
4142016-12-01T13:28:37 *** laurentmt has joined #bitcoin-core-dev
4152016-12-01T13:30:52 *** rafalcpp_ has quit IRC
4162016-12-01T13:31:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4172016-12-01T13:31:12 *** rafalcpp has joined #bitcoin-core-dev
4182016-12-01T13:44:31 *** Chris_Stewart_5 has quit IRC
4192016-12-01T13:49:34 *** crudel has joined #bitcoin-core-dev
4202016-12-01T13:49:41 *** laurentmt has quit IRC
4212016-12-01T13:55:15 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4222016-12-01T13:56:40 *** CubicEarth has joined #bitcoin-core-dev
4232016-12-01T14:01:28 *** CubicEarth has quit IRC
4242016-12-01T14:18:05 *** Guyver2__ has joined #bitcoin-core-dev
4252016-12-01T14:21:02 *** Guyver2 has quit IRC
4262016-12-01T14:21:08 *** Guyver2__ is now known as Guyver2
4272016-12-01T14:26:16 *** aalex_ has joined #bitcoin-core-dev
4282016-12-01T14:29:07 *** ThomasV has joined #bitcoin-core-dev
4292016-12-01T14:32:33 *** Ylbam has quit IRC
4302016-12-01T14:34:37 *** Ylbam has joined #bitcoin-core-dev
4312016-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
4322016-12-01T15:12:36 *** molz has joined #bitcoin-core-dev
4332016-12-01T15:14:13 *** moli has quit IRC
4342016-12-01T15:19:54 *** To7 has quit IRC
4352016-12-01T15:32:57 *** Giszmo has joined #bitcoin-core-dev
4362016-12-01T16:12:47 *** laurentmt has joined #bitcoin-core-dev
4372016-12-01T16:13:35 *** arubi has quit IRC
4382016-12-01T16:32:57 *** molz has quit IRC
4392016-12-01T16:33:34 *** sdaftuar_ is now known as sdaftuar
4402016-12-01T16:41:14 *** aalex__ has joined #bitcoin-core-dev
4412016-12-01T16:44:07 *** To7 has joined #bitcoin-core-dev
4422016-12-01T16:44:27 *** aalex_ has quit IRC
4432016-12-01T17:08:47 *** moli has joined #bitcoin-core-dev
4442016-12-01T17:35:56 *** abpa has joined #bitcoin-core-dev
4452016-12-01T17:45:50 *** jtimon has joined #bitcoin-core-dev
4462016-12-01T17:48:00 *** ThomasV has quit IRC
4472016-12-01T18:10:59 *** aalex_ has joined #bitcoin-core-dev
4482016-12-01T18:13:15 *** arubi has joined #bitcoin-core-dev
4492016-12-01T18:14:48 *** aalex__ has quit IRC
4502016-12-01T18:34:42 *** laurentmt has quit IRC
4512016-12-01T18:37:04 *** Anduck has quit IRC
4522016-12-01T18:39:05 *** bitcoin070 has joined #bitcoin-core-dev
4532016-12-01T18:39:28 <bitcoin070> anyone else having nuclear problems with bitcoin core 0.13.1?
4542016-12-01T18:39:59 <sipa> elaborate?
4552016-12-01T18:40:14 <wumpus> nuclear problems, wow
4562016-12-01T18:40:30 <bitcoin070> unfortunately wumpus
4572016-12-01T18:40:30 <bitcoin070> yes
4582016-12-01T18:40:37 <bitcoin070> I will elaborate in a minute here
4592016-12-01T18:40:43 <sipa> what version were you using that worked, what system specifications, what used to work, what does not?
4602016-12-01T18:40:49 <bitcoin070> sipa/wumpus
4612016-12-01T18:40:57 <bitcoin070> some very unfortunate behavior on m3.mediums on Amazon EC2
4622016-12-01T18:41:01 <wumpus> it's not recommended to use it on nuclear reactors
4632016-12-01T18:41:18 <bitcoin070> I have three separate instances and four different occasions now ....
4642016-12-01T18:41:22 <bitcoin070> extremely bad
4652016-12-01T18:41:31 <bitcoin070> on phone call but will elaborate fully in a moment
4662016-12-01T18:41:31 <sipa> can you please explain what is going on?
4672016-12-01T18:41:52 <wumpus> what is so nuclear about that?
4682016-12-01T18:42:11 <bitcoin070> essentially some form of mempool corruption where the bitcoin-cli getbalance / getinfo reads 0
4692016-12-01T18:42:19 <bitcoin070> but bitcoin-cli getbalance "" reads the true balance
4702016-12-01T18:42:25 <bitcoin070> RPC calls to sendtoaddress return insufficient balance
4712016-12-01T18:42:31 <bitcoin070> also .. the mega bad fuck up is
4722016-12-01T18:42:52 <sipa> what version were you using before?
4732016-12-01T18:42:55 <bitcoin070> as the behavior starts to unravel
4742016-12-01T18:45:21 *** lightningbot has joined #bitcoin-core-dev
4752016-12-01T18:45:37 <sipa> my guess is that your funds are tied up in unconfirmed change
4762016-12-01T18:45:47 <sipa> which is being kicked out of the mempool
4772016-12-01T18:45:55 <bitcoin070> but these transactions are all recent
4782016-12-01T18:46:05 <bitcoin070> why would they be getting kicked out of the mempool, should mempool not prioritize my own TX?
4792016-12-01T18:46:14 <wumpus> do you have spendzeroconfchange set to 0 perhaps?
4802016-12-01T18:46:27 <bitcoin070> nope
4812016-12-01T18:46:34 <bitcoin070> sorry to sound brash guys but i am a power user
4822016-12-01T18:46:38 <bitcoin070> been running nodes for 3+ years
4832016-12-01T18:46:42 <bitcoin070> well-versed in bitcoin.conf
4842016-12-01T18:46:45 <sipa> maybe too long chains of unconfirmed transactions?
4852016-12-01T18:46:59 <sipa> how many unconfirmed outgoing transactions do you have?
4862016-12-01T18:47:17 <bitcoin070> I think that's it
4872016-12-01T18:47:33 <bitcoin070> sipa there's no good way to tell as the node becomes completely nonsensical
4882016-12-01T18:47:41 <bitcoin070> listunspent 0 doesn't even show the outputs
4892016-12-01T18:47:48 <bitcoin070> the only thing I can do is track it back in a block explorer
4902016-12-01T18:48:00 <sipa> listtransactions should list them
4912016-12-01T18:48:02 <wumpus> if it's an unconfirmed change problem then it should resolve itself after the transactions are confirmed
4922016-12-01T18:48:24 *** droark has joined #bitcoin-core-dev
4932016-12-01T18:48:40 <morcos> what does getunconfirmedbalance say
4942016-12-01T18:49:33 <bitcoin070> so
4952016-12-01T18:49:41 <bitcoin070> there is a large large amount of unconfirmed spending unconfirmed
4962016-12-01T18:49:43 <bitcoin070> however
4972016-12-01T18:49:45 <bitcoin070> annoyingly, for instance
4982016-12-01T18:49:51 <bitcoin070> bitcoin-cli getmempooldescendants 10d6ab99beb58c22197c3ba0f2072ea2275660fbc03c8f1cff444247faa86d0e
4992016-12-01T18:49:55 <bitcoin070> returns an empty array
5002016-12-01T18:50:37 <bitcoin070> sorry
5012016-12-01T18:50:40 <bitcoin070> maybe not a good example let me find one
5022016-12-01T18:51:21 <bitcoin070> bitcoin-cli getmempoolancestors e2f2ff83b69a1b11e735cc4fac0a2b00d9eb3641913a3dbdd52043ca8f7b0ad7
5032016-12-01T18:53:23 <bitcoin070> so, I found a TX with 19 ancestors that are unconfirmed
5042016-12-01T18:54:07 <bitcoin070> bitcoin-cli getmempoolancestors 4c4dd9034d215a95dd951901271f38aaa02f14cf4be0150e2a1d4c7996aa710b
5052016-12-01T18:54:09 <bitcoin070> they are in the mempool though
5062016-12-01T18:54:17 <bitcoin070> it returns all 19 true txid
5072016-12-01T18:54:33 *** jcorgan has joined #bitcoin-core-dev
5082016-12-01T18:54:54 <bitcoin070> so, whatever is causing this, it's dangerous behavior and never happened before because
5092016-12-01T18:55:03 <bitcoin070> a lot of scripts and daemons are monitoring bitcoin node balance
5102016-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.
5112016-12-01T18:55:29 <bitcoin070> and when it goes from XXX to 0 without any transactions it starts a lot of commotion unfortunately
5122016-12-01T18:56:11 <bitcoin070> we want to support segwit, want HD wallet, etc
5132016-12-01T18:56:27 <wumpus> sounds like the whole chain of transactions was evicted
5142016-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.
5152016-12-01T18:56:55 <sipa> a larger max mempool size may help to avoid that
5162016-12-01T18:57:06 <wumpus> are you overriding fee or using the smart fee estimate?
5172016-12-01T18:57:18 <bitcoin070> not doing anything with fees
5182016-12-01T18:57:28 <bitcoin070> just letting the node handle it
5192016-12-01T18:57:44 <bitcoin070> I have all the time in the world, obviously I don't want to interrupt your meeting but
5202016-12-01T18:57:51 <bitcoin070> FWIW, BitGo is having issues right now too
5212016-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
5222016-12-01T18:58:05 <sipa> or you abandon them
5232016-12-01T18:58:07 <bitcoin070> their node is returning a TXID which is also not propagating the network
5242016-12-01T18:58:08 <wumpus> if you can queue up sends then use a sendmany you'd prevent nesting transactions so deeply
5252016-12-01T18:58:35 <bitcoin070> wumpus/sipa: interestingly though this only started becoming problematic in bitcoin core
5262016-12-01T18:58:46 <bitcoin070> sorry I mean 0.13
5272016-12-01T18:58:50 <sipa> bitcoin070: network conditions change all the time
5282016-12-01T18:59:00 <gmaxwell> bitcoin070: nothing about this was changed in 0.13, AFAIR.
5292016-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
5302016-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?
5312016-12-01T18:59:16 <sdaftuar> wasn't there a PR relating to that?
5322016-12-01T18:59:19 <sipa> sdaftuar: agree
5332016-12-01T18:59:36 <gmaxwell> We do, I believe I created that in response to this person.
5342016-12-01T18:59:37 <bitcoin070> damn, it's just strange because
5352016-12-01T18:59:48 <bitcoin070> I didn't see this ever happen in .12
5362016-12-01T18:59:55 <sipa> i believe that
5372016-12-01T18:59:56 <bitcoin070> I know network conditions aren't static, etc
5382016-12-01T19:00:14 <bitcoin070> so you're saying the root cause is too long of unconfirmed chain
5392016-12-01T19:00:25 <instagibbs> meeting taimu
5402016-12-01T19:00:26 <wumpus> if there is a PR for that, it'd make sense for bitcoin070 to test that
5412016-12-01T19:00:27 <sipa> or an evicted chain
5422016-12-01T19:00:33 <BlueMatt> meeting?
5432016-12-01T19:00:33 <wumpus> #startmeeting
5442016-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.
5452016-12-01T19:00:33 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5462016-12-01T19:00:39 <sipa> present
5472016-12-01T19:00:41 <bitcoin070> sipa -- evicted meaning what exactly?
5482016-12-01T19:00:46 <bitcoin070> sorry guys I don't want to interrupt
5492016-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
5502016-12-01T19:00:53 <jonasschnelli> here
5512016-12-01T19:00:59 <kanzure> hi.
5522016-12-01T19:01:00 <btcdrak> here
5532016-12-01T19:01:01 <cfields> here
5542016-12-01T19:01:02 <paveljanik> Hi
5552016-12-01T19:01:04 <achow101> hi
5562016-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
5572016-12-01T19:01:30 <michagogo> Oh, right, now that I'm in the U.S. these are in the early afternoon
5582016-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
5592016-12-01T19:01:40 <bitcoin070> okay
5602016-12-01T19:01:46 <bitcoin070> fwiw, bitcoin-cli estimatefee 1 returns -1
5612016-12-01T19:01:53 <morcos> both "" and "*" when used as the account, give different answers than putting nothing in for the account
5622016-12-01T19:01:53 <wumpus> anyhow, meeting started. Any proposed topics?
5632016-12-01T19:01:56 <morcos> bitcoin070: expected
5642016-12-01T19:02:09 <wumpus> bitcoin070: yes, that is known behavior
5652016-12-01T19:02:11 <bitcoin070> okay
5662016-12-01T19:02:14 <bitcoin070> 2 and 3 are okay
5672016-12-01T19:02:30 <bitcoin070> should these unconfirmed chains eventually confirm and the balance will correct?
5682016-12-01T19:02:35 <gmaxwell> wumpus: What issues do people feel aren't getting attention right now?
5692016-12-01T19:03:23 <wumpus> gmaxwell: in what regard?
5702016-12-01T19:03:33 <paveljanik> review etc.
5712016-12-01T19:03:37 <gmaxwell> like PRs and what not, proposed topic: does anyone need some love.
5722016-12-01T19:03:41 *** AaronvanW has quit IRC
5732016-12-01T19:04:14 <wumpus> bitcoin070: re: estimatefee returning -1 there's an issue about that: https://github.com/bitcoin/bitcoin/issues/9106
5742016-12-01T19:04:22 <bitcoin070> thanks guys
5752016-12-01T19:04:25 <bitcoin070> I'll wait and see what happens here
5762016-12-01T19:04:29 <bitcoin070> thanks again
5772016-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
5782016-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
5792016-12-01T19:04:37 <sipa> i have a short topic for later, about vchDefaultKey (walking to office right now)
5802016-12-01T19:04:39 <wumpus> wallet PRs need review at least
5812016-12-01T19:04:52 <wumpus> espeically the multiwallet ones
5822016-12-01T19:04:58 <jonasschnelli> Yes. An HD.
5832016-12-01T19:04:59 <gmaxwell> The test before evict PR seems to be being forgotten a bit.
5842016-12-01T19:05:04 <jonasschnelli> We need a restore feature.
5852016-12-01T19:05:23 <jonasschnelli> We shouldn't keep users to long in the dark about how they can restore a HD wallet
5862016-12-01T19:05:35 <jonasschnelli> Would be nice to have something in 0.14
5872016-12-01T19:05:47 <wumpus> vchDefaultKey should die
5882016-12-01T19:05:58 <jonasschnelli> heh. Lets discuss that when sipa is back
5892016-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?
5902016-12-01T19:06:39 <wumpus> sipa: re: vchDefaultkey I once created this issue: https://github.com/bitcoin/bitcoin/issues/8416
5912016-12-01T19:06:42 * jonasschnelli marks pr
5922016-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
5932016-12-01T19:07:54 <wumpus> usually if you just ask in teh channel someone will do it
5942016-12-01T19:08:03 <jonasschnelli> Tag #9239 for 0.14? IMO we should
5952016-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
5962016-12-01T19:08:11 <gmaxwell> BlueMatt: do you have any more big wads of data race fixes.
5972016-12-01T19:08:18 <bitcoin070> guys I agree 100% we need an HD wallet restore feature
5982016-12-01T19:08:21 <gmaxwell> jonasschnelli: we should.
5992016-12-01T19:08:24 <morcos> jonasschnelli: definitely
6002016-12-01T19:08:29 <bitcoin070> I would make that top priority
6012016-12-01T19:08:42 <morcos> bitcoin070: ha ha, it'll just make it always give -1
6022016-12-01T19:08:52 <bitcoin070> :)
6032016-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
6042016-12-01T19:09:25 <gmaxwell> BlueMatt: have you advised cfields about the racy things you found there?
6052016-12-01T19:09:27 <BlueMatt> to we have topics?
6062016-12-01T19:09:34 <BlueMatt> yes, we've been discussing them
6072016-12-01T19:09:44 <morcos> answering your own question?
6082016-12-01T19:09:51 <BlueMatt> topics? or are we meeting-chat-time-ing?
6092016-12-01T19:09:59 <gmaxwell> I'd like to discuss #9194
6102016-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
6112016-12-01T19:10:06 <cfields> gmaxwell: yes, i'm nuking things in parallel. Simple atomic changes aren't interrupting anything of mine
6122016-12-01T19:10:11 <kanzure> morcos: he means he is answering the 'racy' question
6132016-12-01T19:10:11 <BlueMatt> I'd like to discuss when to do The Main Split
6142016-12-01T19:10:39 <wumpus> #topic Non-segwit serialization vai rpc (#9194)
6152016-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
6162016-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.
6172016-12-01T19:11:28 *** protomar has joined #bitcoin-core-dev
6182016-12-01T19:11:58 <cfields> wumpus: as part of your named-arg PR, did you consider allowing any global named args?
6192016-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
6202016-12-01T19:12:19 <gmaxwell> sdaftuar: okay, it was mostly you I was concerned about.
6212016-12-01T19:12:21 <cfields> where for ^^, any command could accept a "serialversion" named arg
6222016-12-01T19:12:36 <wumpus> cfields: we're in a meeting
6232016-12-01T19:12:37 <sdaftuar> "sdaftuar was here" i did mean to review the test changes though
6242016-12-01T19:12:58 <instagibbs> sdaftuar, yes i basically failed to remember how the commitment worked :) thanks for the review
6252016-12-01T19:12:59 <cfields> wumpus: eh? I was referencing 9194 :)
6262016-12-01T19:13:03 <gmaxwell> wumpus: that is directly relevant here. :)
6272016-12-01T19:13:37 <gmaxwell> okay, if sdaftuar is not concerned about it, -- instagibbs are you waiting for anything there or just more review?
6282016-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
6292016-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
6302016-12-01T19:14:08 <wumpus> cfields: I don't have any problem with the idea at least.
6312016-12-01T19:14:13 <instagibbs> (ie zmq/rest suggestion)
6322016-12-01T19:14:36 <instagibbs> I think the tests actually work now, so confident on rpc side
6332016-12-01T19:14:39 *** CubicEarth has joined #bitcoin-core-dev
6342016-12-01T19:14:40 <gmaxwell> instagibbs: okay, sounds good to me then. I'll be happy to test and review.
6352016-12-01T19:14:56 <instagibbs> great
6362016-12-01T19:16:18 *** jannes has quit IRC
6372016-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
6382016-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.
6392016-12-01T19:16:37 <gribble> https://github.com/bitcoin/bitcoin/issues/8895 | Better SigCache Implementation by JeremyRubin · Pull Request #8895 · bitcoin/bitcoin · GitHub
6402016-12-01T19:16:57 <morcos> i think 8895 is ready to go in (maybe a little bit more review)
6412016-12-01T19:17:10 <morcos> in my opinion checkqueue is still a work in progress
6422016-12-01T19:17:10 <wumpus> is that a next topic?
6432016-12-01T19:17:18 <morcos> i would really like to get 8895 in for 0.14
6442016-12-01T19:17:22 <wumpus> if so, BlueMatt proposed one first
6452016-12-01T19:17:24 <BlueMatt> what morcos said, jeremyrubin is just waiting on review for #8895, I think
6462016-12-01T19:17:26 <gribble> https://github.com/bitcoin/bitcoin/issues/8895 | Better SigCache Implementation by JeremyRubin · Pull Request #8895 · bitcoin/bitcoin · GitHub
6472016-12-01T19:17:37 <sipa> i'll review 8895 again after the last round of changed to it
6482016-12-01T19:17:41 <gmaxwell> sorry, tangent.
6492016-12-01T19:17:51 <gmaxwell> sounds like the question is answered then.
6502016-12-01T19:17:57 <BlueMatt> wumpus: either way we finished that topic :p
6512016-12-01T19:18:07 <wumpus> #topic Main split
6522016-12-01T19:18:27 <sipa> let's do it
6532016-12-01T19:18:28 <morcos> to summarize last 2 topics... concept ack 9194 and 8895 for 0.14.0
6542016-12-01T19:18:47 <instagibbs> #9194
6552016-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
6562016-12-01T19:18:52 <instagibbs> oh right
6572016-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
6582016-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
6592016-12-01T19:19:31 <wumpus> if it has lots of acks it should be merged
6602016-12-01T19:19:34 <cfields> no objections to splitting asap here. It'll only collide trivially with my current work.
6612016-12-01T19:19:40 <jonasschnelli> BlueMatt: why when? Because of upcoming rebases?
6622016-12-01T19:19:42 <jtimon> I would say open the PR as soon as 9183 gets merged
6632016-12-01T19:19:52 <wumpus> no need to delay it if it is ready
6642016-12-01T19:19:56 <BlueMatt> jonasschnelli: question is if we do it now or wait until like right before 0.14
6652016-12-01T19:20:01 <jonasschnelli> I think all of us are happy to rebase for a such split
6662016-12-01T19:20:08 <BlueMatt> ok!
6672016-12-01T19:20:09 <jonasschnelli> IMO asap
6682016-12-01T19:20:11 <wumpus> let's just go on with it
6692016-12-01T19:20:13 <jtimon> BlueMatt: why? what's the advantage of waiting?
6702016-12-01T19:20:25 <BlueMatt> ok! sounds good, will open as soon as 9183 is merged
6712016-12-01T19:20:31 <morcos> Perhaps BlueMatt is asking if there are any more 0.13 backports to worry about first?
6722016-12-01T19:20:36 <cfields> jtimon: to ease backports in the meantime i guess?
6732016-12-01T19:20:46 <BlueMatt> morcos: oh, yea, that too
6742016-12-01T19:20:53 <jtimon> morcos: cfields oh, right
6752016-12-01T19:21:07 <jtimon> are there any backports on the horizon?
6762016-12-01T19:21:19 <jtimon> do they conflict with this?
6772016-12-01T19:21:22 <wumpus> speaking of 0.13.2, what still needs to go in? (that isn't merged into master yet)
6782016-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.
6792016-12-01T19:21:39 <gmaxwell> wumpus: the estimatefee 1 thing. and uhhh
6802016-12-01T19:21:39 <sdaftuar> i have one that could go in, the cs_main locking thing with compact blocks
6812016-12-01T19:21:42 <sdaftuar> plus 9194
6822016-12-01T19:21:45 <cfields> BlueMatt: is it 100% move-only?
6832016-12-01T19:21:50 <BlueMatt> cfields: yes
6842016-12-01T19:22:02 <morcos> huh is what move only
6852016-12-01T19:22:08 <BlueMatt> splitting main.cpp
6862016-12-01T19:22:09 <gmaxwell> yea, the locking around compact blocks
6872016-12-01T19:22:26 <gmaxwell> #9253 perhaps (though its minor)
6882016-12-01T19:22:26 <wumpus> gmaxwell: that one isn't tagged https://github.com/bitcoin/bitcoin/milestone/24
6892016-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
6902016-12-01T19:22:30 <sdaftuar> that doens't cleanly apply anyway though, so i'll open a separate PR for it for the backport
6912016-12-01T19:22:55 <gmaxwell> #9229
6922016-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
6932016-12-01T19:23:00 * jonasschnelli tagged 9239 (estimtefee -1) req. backport
6942016-12-01T19:23:27 <gmaxwell> #9194 I think (which is why I was asking about it)
6952016-12-01T19:23:28 <wumpus> so does the main split pose a difficulty for any of those?
6962016-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
6972016-12-01T19:23:30 <morcos> jonasschnelli: i was wondering about that, i think that would be my preference
6982016-12-01T19:23:39 <bitcoin070> hey guys, how often does a wallet rebroadcast transactions that aren't on the network?
6992016-12-01T19:23:49 <gmaxwell> I just noticed #9188 isn't merged. that too
7002016-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
7012016-12-01T19:23:58 * gmaxwell looks to see if he's the delay on that one
7022016-12-01T19:24:03 <wumpus> bitcoin070: after the meeting please
7032016-12-01T19:24:08 * gmaxwell is not the delay
7042016-12-01T19:24:15 <bitcoin070> sorry..
7052016-12-01T19:24:32 <jonasschnelli> I think after the main split, backports can get a bit more complicated.
7062016-12-01T19:24:34 <wumpus> jonasschnelli: thanks
7072016-12-01T19:24:59 <gmaxwell> oh good point.
7082016-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
7092016-12-01T19:25:17 <jonasschnelli> #9229 does not touch main, #9239 also not.
7102016-12-01T19:25:18 <gmaxwell> well all our backports should be small at least.
7112016-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
7122016-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
7132016-12-01T19:25:20 <wumpus> the only thing that really messes up backports is if the logic changes
7142016-12-01T19:25:30 <morcos> can someone tag all the backports we just mentioned...
7152016-12-01T19:25:34 <jonasschnelli> Indeed.
7162016-12-01T19:25:36 <sdaftuar> #9252 does, but it's easy for me to backport, so i am not worried
7172016-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
7182016-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
7192016-12-01T19:25:40 <BlueMatt> I can rebase main split on top of all the "Backport needed" PRs
7202016-12-01T19:25:49 <BlueMatt> but then we need to move fast on the backport-needed PRs
7212016-12-01T19:25:57 <BlueMatt> sipa: kk
7222016-12-01T19:26:17 <jonasschnelli> backport taged: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+backport%22
7232016-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
7242016-12-01T19:26:41 <wumpus> great
7252016-12-01T19:27:17 <wumpus> BlueMatt: makes sense to move fast on 0.13.2 in any case
7262016-12-01T19:27:24 <BlueMatt> true
7272016-12-01T19:27:28 <jtimon> wumpus: +1
7282016-12-01T19:27:33 <wumpus> there's plenty of stuff for a release already
7292016-12-01T19:27:36 <morcos> jonasschnelli: 9194, 9252 for backport i think is what we said
7302016-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?
7312016-12-01T19:28:01 <sipa> BlueMatt: sgtm
7322016-12-01T19:28:08 <sdaftuar> agreed
7332016-12-01T19:28:09 <jonasschnelli> tagged 9194 9252
7342016-12-01T19:28:09 <wumpus> sgtm too
7352016-12-01T19:28:19 *** laurentmt has joined #bitcoin-core-dev
7362016-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.
7372016-12-01T19:28:36 <gribble> https://github.com/bitcoin/bitcoin/issues/9019 | Avoid making chains of txn >25 deep. · Issue #9019 · bitcoin/bitcoin · GitHub
7382016-12-01T19:28:37 <jtimon> fine with me but will actually review 9183 first
7392016-12-01T19:28:49 <instagibbs> yeah sure, ive run into that a number of times :)
7402016-12-01T19:29:49 <wumpus> okay, that concludes the 0.13.2 and main split topic I guess
7412016-12-01T19:30:02 <wumpus> any other topics proposed?
7422016-12-01T19:30:04 <jonasschnelli> proposed topic from sipa: wallets default key, another topic could be: HD restore
7432016-12-01T19:30:06 *** laurentmt has quit IRC
7442016-12-01T19:30:09 <wumpus> ah yes
7452016-12-01T19:30:15 <sipa> ok
7462016-12-01T19:30:16 <wumpus> #topic vchdefault in wallet
7472016-12-01T19:30:23 *** laurentmt has joined #bitcoin-core-dev
7482016-12-01T19:30:28 <sipa> so we currently have a leftover remnant of ancient times, vchDefaultKey in the wallet
7492016-12-01T19:30:34 <jonasschnelli> The default key is misused for detecting the first run IMO
7502016-12-01T19:30:38 <wumpus> #link https://github.com/bitcoin/bitcoin/issues/8416
7512016-12-01T19:30:43 <sipa> which is absolutely unused, except for determining whether a new wallet was just created
7522016-12-01T19:30:52 <sipa> i'd like to get rid of it
7532016-12-01T19:30:54 <sipa> however
7542016-12-01T19:31:01 <wumpus> yes, we should get rid of it, but maybe not for 0.14, it's not really urgent
7552016-12-01T19:31:11 <sipa> if we do that, a downgrade to an older wallet version would result in failing to rescan
7562016-12-01T19:31:23 <jonasschnelli> Yes. We should combine it with other features.
7572016-12-01T19:31:25 <sipa> as it would trigger the new wallet logic, which writes the current chainstate to the wallet file
7582016-12-01T19:31:31 <jonasschnelli> We should have combined it with HD in 0.13. :/
7592016-12-01T19:31:45 <wumpus> sipa: we could add fallback logic into 0.14
7602016-12-01T19:31:49 <wumpus> then remove it for 0.15
7612016-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)
7622016-12-01T19:32:11 <wumpus> then it'd be possible to go back to 0.14 when 0.15 is released
7632016-12-01T19:32:14 <wumpus> but o further back
7642016-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
7652016-12-01T19:32:25 <wumpus> (unless we backport the fallback logic ofc)
7662016-12-01T19:32:46 <wumpus> yes, that'd be my preference
7672016-12-01T19:32:56 <wumpus> no dummies and other hacks, just versioining
7682016-12-01T19:33:09 <jonasschnelli> Yes. This only affect new wallets, right?
7692016-12-01T19:33:13 <wumpus> it'd only apply to new wallets created with the new version anyway
7702016-12-01T19:33:15 <wumpus> right.
7712016-12-01T19:33:19 <gmaxwell> I'm okay with versioning, but we should keep it simple.
7722016-12-01T19:33:23 <wumpus> it's not like you can't go back with an old wallet
7732016-12-01T19:33:26 <jonasschnelli> If you have a wallet from 0.12, it won't upgrade unless you do an explicit upgrtadew
7742016-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)
7752016-12-01T19:33:41 <wumpus> in any case this isn't urgent
7762016-12-01T19:33:53 <sipa> and then in 0.15 delete the vchDefaultKey and increase the min version to 0.14?
7772016-12-01T19:33:54 <jonasschnelli> sipa: ack
7782016-12-01T19:33:54 <wumpus> we could do it over 2-3 major versions
7792016-12-01T19:34:11 <gmaxwell> ACK sipa.
7802016-12-01T19:34:12 <wumpus> sipa: yes that's what I meant too
7812016-12-01T19:34:21 <jonasschnelli> Downgrading new wallets is probably not required over more then 2 major versions.
7822016-12-01T19:34:42 <wumpus> we could even backport that to 0.13
7832016-12-01T19:35:00 <jonasschnelli> wumpus: Yes. We should.
7842016-12-01T19:35:01 <wumpus> (e.g. work if there is no vchdefault, but do make it)
7852016-12-01T19:35:41 <wumpus> that particular code hasn't been touched for years so backporting is trivial
7862016-12-01T19:36:08 <sipa> ok, end topic
7872016-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
7882016-12-01T19:36:15 <jonasschnelli> HD restore? anyone interested?
7892016-12-01T19:36:47 <morcos> just to not hold up 0.13.2
7902016-12-01T19:36:52 <jonasschnelli> morcos: whats the downside of the (simple) backport?
7912016-12-01T19:36:56 <jonasschnelli> ok.
7922016-12-01T19:37:02 <jtimon> ack min wallet version
7932016-12-01T19:37:07 <sipa> jonasschnelli: certainly, but it requires some pretty big changes (like removing keypool entries with seen keys in received transactions)
7942016-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
7952016-12-01T19:37:20 <wumpus> morcos: I certainly wouldn't propose holding up 0.13.2 for it
7962016-12-01T19:37:23 <morcos> wumpus: +1 if it doesn't hold 13.2
7972016-12-01T19:37:27 <jonasschnelli> Okay. Yes. If the BP is non trivial, we can skip it.
7982016-12-01T19:37:32 <wumpus> morcos: no one is saying that!
7992016-12-01T19:37:45 <gmaxwell> yea, no holdup. but BP would be nice.
8002016-12-01T19:38:30 <jtimon> jonasschnelli: who requires to downgrade wallets?
8012016-12-01T19:38:39 <wumpus> "removing keypool entries with seen keys in received transactions"?
8022016-12-01T19:38:47 <wumpus> is that required for removing the default key?
8032016-12-01T19:39:51 <morcos> wumpus: is that HD restore he's talking about?
8042016-12-01T19:39:56 <jonasschnelli> jtimon: Is more about the option to run your wallet.dat on an older version
8052016-12-01T19:40:02 <jonasschnelli> morcos: not yet
8062016-12-01T19:40:11 <jonasschnelli> default key != HD
8072016-12-01T19:40:23 <morcos> jonasschnelli: yes understood, just trying to decipher sipas comment
8082016-12-01T19:40:25 <wumpus> morcos: I don't know? I'm confused
8092016-12-01T19:40:34 <jtimon> jonasschnelli: right, why do you want that? anyway, I was reading slow, we can discuss after the meeting
8102016-12-01T19:40:38 <gmaxwell> I thought sip was responding to "hd restore"
8112016-12-01T19:40:39 <wumpus> it'd make more sense, we're combinding topics is an awkward way now
8122016-12-01T19:40:43 <gmaxwell> s/sip/sipa/
8132016-12-01T19:40:54 <jonasschnelli> Ah. Sorry
8142016-12-01T19:41:00 *** Anduck has joined #bitcoin-core-dev
8152016-12-01T19:41:11 <wumpus> #topic HD restore
8162016-12-01T19:41:12 <jonasschnelli> Can we have the HD restore topic then?
8172016-12-01T19:41:15 <jonasschnelli> thx
8182016-12-01T19:41:20 <gmaxwell> TM: Prefix all messages related to topic 1 with T1: and for topic 2 with T2:
8192016-12-01T19:41:30 <jonasschnelli> Since 0.13 we have HD by default, we should have a feature to restore hd wallets
8202016-12-01T19:41:38 <jonasschnelli> Maybe to late for 0.14, but in 0.15.
8212016-12-01T19:41:44 <jonasschnelli> I think we need a concept first
8222016-12-01T19:41:59 <jonasschnelli> IMO it should go over a seperate tool (bitcoin-wallet)
8232016-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?
8242016-12-01T19:42:22 <jonasschnelli> Because you ideally don't want to handle master xpriv in RPC or -cmd
8252016-12-01T19:42:29 <gmaxwell> seperate tool sounds like something that would need a non-pruned blockchain .. which I don't think is desirable.
8262016-12-01T19:42:50 <jonasschnelli> Yes. You have an (olx) xpriv or a wallet.dump and you wish to restore the complete wallet
8272016-12-01T19:43:00 <jonasschnelli> gmaxwell: Yes. This is a good point.
8282016-12-01T19:43:17 <gmaxwell> how is this different from having a wallet.dat that you backed up right at the start?
8292016-12-01T19:43:20 <jonasschnelli> The tool should create wallet(s).dat and then you can run a rescan
8302016-12-01T19:43:33 <gmaxwell> okay thats how.
8312016-12-01T19:43:44 <jonasschnelli> Maybe the tool can interact with RPC and the UTXO set to detect the gap limits
8322016-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.
8332016-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)
8342016-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.
8352016-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
8362016-12-01T19:45:28 <jtimon> I assume is horribly inefficient, reading slow again
8372016-12-01T19:45:34 <gmaxwell> jtimon: sometime 100 years later your wallet is restored.
8382016-12-01T19:45:34 <jonasschnelli> gmaxwell: there was a PR with that. But nobody reviewd it (external and internal chain)
8392016-12-01T19:45:49 <gmaxwell> (rescans take hours, we should stop thinking of rescans as an option generally.)
8402016-12-01T19:45:52 <wumpus> jonasschnelli: yea :/ review is always a problem with wallet pulls
8412016-12-01T19:45:55 <jtimon> gmaxwell: thanks for confirming that is the flaw of my naive design
8422016-12-01T19:46:19 <wumpus> I'd recommend that we first review and get the current wallet pulls merged, before working on even more
8432016-12-01T19:46:40 <sipa> wumpus: +1
8442016-12-01T19:46:48 <jonasschnelli> I think it would help to review #9143 and #9256
8452016-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
8462016-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
8472016-12-01T19:46:54 <wumpus> I don't think HD recovery will make 0.4 as it still has to be written
8482016-12-01T19:46:57 <gmaxwell> jonasschnelli: I thought it was merged in fact, at the time. oh well.
8492016-12-01T19:47:00 <jonasschnelli> This would slowly allow creating a such tool
8502016-12-01T19:47:03 <wumpus> but we can make e.g. multiwallet land
8512016-12-01T19:47:13 <wumpus> s/0.4/0.14
8522016-12-01T19:47:28 <jonasschnelli> #8723 would also nice for HD
8532016-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
8542016-12-01T19:47:32 <wumpus> and yes the refactors
8552016-12-01T19:47:50 <jtimon> what about not restoring the whole wallet but only what's currently in the utxo? would that be acceptable?
8562016-12-01T19:48:03 <jonasschnelli> jtimon: Yes. That should be the default IMO
8572016-12-01T19:48:12 <jonasschnelli> Then you can optionally do a rescan if you like.
8582016-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.
8592016-12-01T19:48:30 <gmaxwell> We're already going to have to support one legacy setup, lets try to not proliferate little changes.
8602016-12-01T19:49:12 <jonasschnelli> Okay. I can focus on the path split
8612016-12-01T19:49:19 *** laurentmt has quit IRC
8622016-12-01T19:49:31 <jcorgan> gmaxwell: background on the "path split issue" i can go read?
8632016-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.
8642016-12-01T19:49:54 <jonasschnelli> jcorgan: bip32 internal and external chains
8652016-12-01T19:50:03 <instagibbs> jcorgan, change output is on same chain as spending
8662016-12-01T19:50:08 <jcorgan> ah, yes, i should ack 8723
8672016-12-01T19:50:35 <instagibbs> err receiving*
8682016-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.
8692016-12-01T19:51:20 <jcorgan> yeah, i get it
8702016-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.
8712016-12-01T19:51:29 <gmaxwell> yadda yadda.
8722016-12-01T19:51:37 <Chris_Stewart_5> gmaxwell: Thanks for the explanation
8732016-12-01T19:52:15 <gmaxwell> jonasschnelli: load your old wallet.dat. rescan. Where does that currently fall down?
8742016-12-01T19:52:24 <jonasschnelli> gmaxwell: missing keys
8752016-12-01T19:52:28 <sipa> ?
8762016-12-01T19:52:40 <jonasschnelli> you mean restore a old wallet.dat?
8772016-12-01T19:52:50 <jonasschnelli> you need to loop(1000, getnewaddress) first. :)
8782016-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.
8792016-12-01T19:53:01 <jonasschnelli> Well, if you have 1001 keys, you miss one.
8802016-12-01T19:53:17 <jonasschnelli> gmaxwell: this would result in multiple rescans.
8812016-12-01T19:53:21 <wumpus> right, it doesn't automatically wind forward when it sees known keys
8822016-12-01T19:53:22 <sipa> gmaxwell: what do you mean remove?
8832016-12-01T19:53:35 <gmaxwell> sipa: mark used in keypool.
8842016-12-01T19:53:42 <sipa> gmaxwell: that's not implemented at all
8852016-12-01T19:53:45 <luke-jr> :x
8862016-12-01T19:53:46 <gmaxwell> jonasschnelli: which is a workaround that you can answer.
8872016-12-01T19:53:58 <sipa> gmaxwell: you need the keypool
8882016-12-01T19:54:02 <jonasschnelli> Yes. The loop getnewaddress is the current workaround.
8892016-12-01T19:54:09 <jcorgan> it seems the bigger issue is there is no standard way of archiving derivation path usage + metadata
8902016-12-01T19:54:15 <gmaxwell> sipa: that needs to be implemented, at least that much would be small.
8912016-12-01T19:54:16 <jonasschnelli> But we don't even offer a rescan down to the HD feature birthdate.
8922016-12-01T19:54:23 <jonasschnelli> The UX is bad
8932016-12-01T19:54:26 <sipa> gmaxwell: it's not easy
8942016-12-01T19:54:35 <jonasschnelli> yes. It's pretty complex.
8952016-12-01T19:54:42 <sipa> gmaxwell: as we don't have a way to store keys without private key
8962016-12-01T19:54:53 <sipa> or rescan would require the passphrase
8972016-12-01T19:54:54 <gmaxwell> sipa: we can still mark the right things as used!
8982016-12-01T19:54:56 <jonasschnelli> We first need a Wallet record type hdkey
8992016-12-01T19:55:01 <sipa> gmaxwell: ah, yes!
9002016-12-01T19:55:12 <sipa> jonasschnelli: no we don't
9012016-12-01T19:55:31 <gmaxwell> sipa: e.g. rescan, unlock, rescan. not great, but failing to mark things as used is really goofy.
9022016-12-01T19:55:45 <gmaxwell> but should also be trivial to fix.
9032016-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)
9042016-12-01T19:55:57 <sipa> or not at all, i guess
9052016-12-01T19:56:08 <sipa> and always derive it on the fly
9062016-12-01T19:56:15 <gmaxwell> sipa: No, we can't.
9072016-12-01T19:56:27 <gmaxwell> (keys are hardened because we support export)
9082016-12-01T19:56:28 <jonasschnelli> IMO we should just store pubkeys and the according keypath
9092016-12-01T19:56:37 <sipa> gmaxwell: oh, right
9102016-12-01T19:56:45 <jonasschnelli> maybe the relevant master key (if we support multiple=
9112016-12-01T19:56:53 <gmaxwell> and yes, storing the private keys is a bit silly. :P but an optimization.
9122016-12-01T19:56:56 <jcorgan> jonasschnelli: agree, if there were a standard way of documenting that
9132016-12-01T19:57:19 <sipa> 3 minutes
9142016-12-01T19:57:30 <gmaxwell> ( I meant that not storing the private keys is mearly an optimization and not important.)
9152016-12-01T19:58:03 <sipa> gmaxwell: we could also stop rescanning whenever the keypool goes below some value, and require unlocking first
9162016-12-01T19:58:06 <sipa> or something
9172016-12-01T19:58:34 <jtimon> gmaxwell: I still don't know how you solve the problem you described
9182016-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.
9192016-12-01T19:59:04 <gmaxwell> the last is a path incompatible change unfortunately, :(
9202016-12-01T19:59:19 <gmaxwell> but the rest does not need coordination with anything.
9212016-12-01T19:59:20 <sipa> we should first split up the keypools into change and non-change, iguess
9222016-12-01T19:59:31 <jonasschnelli> Okay. I can work on a patch.
9232016-12-01T19:59:39 <jtimon> sipa: oh, I see
9242016-12-01T19:59:41 <sipa> then do the use marking (as it will need to mark within each path)
9252016-12-01T19:59:43 <jcorgan> jonasschnelli: let's pm after the mtg on that
9262016-12-01T19:59:56 <gmaxwell> sipa: the split will make wallets that do that incompatible with older software.
9272016-12-01T20:00:09 <sipa> gmaxwell: yes
9282016-12-01T20:00:16 <jonasschnelli> gmaxwell: Yes. We just need to support both types
9292016-12-01T20:00:34 <jtimon> does the change keypool have its own seed or is it derived?
9302016-12-01T20:00:40 <wumpus> #endmeeting
9312016-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)
9322016-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
9332016-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
9342016-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
9352016-12-01T20:00:41 <jonasschnelli> the one-chain-hd-wallet and the flexible-keypath-wallet with ext/int chain
9362016-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?)
9372016-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
9382016-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
9392016-12-01T20:00:50 <sipa> jtimon: the keypool is just a set of keys
9402016-12-01T20:00:52 <jonasschnelli> jcorgan: same seed
9412016-12-01T20:00:54 <gmaxwell> jtimon: see bip32.. internal vs external.
9422016-12-01T20:00:55 <instagibbs> jtimon, it's just a different path
9432016-12-01T20:01:03 <jonasschnelli> jcorgan: meant jtimon
9442016-12-01T20:01:07 <sipa> jtimon: the seed information is in how to replenish it, hwich happens elsewhere
9452016-12-01T20:01:42 <gmaxwell> jonasschnelli: whenever the answer is 'support both types' that strongly encourages batching changes.
9462016-12-01T20:01:44 <jtimon> sipa: thanks, I'm not so familiar with the bip32 wallet
9472016-12-01T20:01:49 <jonasschnelli> Combining the splitting with https://github.com/bitcoin/bitcoin/pull/8723/files would make sense IMO
9482016-12-01T20:01:54 <gmaxwell> I really do not want to support 30 different kinds of wallets 5 years from now. :)
9492016-12-01T20:02:08 <cfields> BlueMatt: looking
9502016-12-01T20:02:23 <jonasschnelli> Yes. We don't have the splitting because we wanted a minimal sane change.
9512016-12-01T20:02:31 <sipa> gmaxwell: we'll just do a softfork to require SNARKs in signatures that prove that keys were derived deterministically?
9522016-12-01T20:02:33 <jonasschnelli> I think this was resonable. But we shouln't wait to long now
9532016-12-01T20:02:34 <sipa> *ducks*
9542016-12-01T20:02:41 <jonasschnelli> heh
9552016-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
9562016-12-01T20:03:08 <wumpus> cfields: I guess we will use libevent for resolving anyway, when that lands?
9572016-12-01T20:03:18 <BlueMatt> wumpus: yes, but need something to backport
9582016-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.
9592016-12-01T20:03:41 <gmaxwell> so in any case, thats just why I was suggesting fixing the use-flagging first, no compatiblity concerns.
9602016-12-01T20:03:51 <wumpus> BlueMatt: sure in the meantime we can revert #4421 if it's buggy
9612016-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
9622016-12-01T20:03:53 <cfields> wumpus: yes. I'm not really concerned about dropping this back to sync for now for that reason
9632016-12-01T20:04:25 <BlueMatt> ok, so I'll just do a full-revert of 4421
9642016-12-01T20:04:27 <BlueMatt> sgtm
9652016-12-01T20:04:31 <cfields> BlueMatt: i'm tracing through the ifdefs locally now to make sure it works like i assume
9662016-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)
9672016-12-01T20:04:52 <wumpus> BlueMatt: please do comment in the issue that you'regoing to revert it and why
9682016-12-01T20:05:05 <BlueMatt> kk
9692016-12-01T20:05:23 <jtimon> not sure what the conclusions about the wallet are
9702016-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
9712016-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
9722016-12-01T20:06:14 <wumpus> espeically if you have no debug symbols for libc I guess?
9732016-12-01T20:06:24 <BlueMatt> wumpus: yes
9742016-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
9752016-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
9762016-12-01T20:07:02 *** d9b4bef9 has quit IRC
9772016-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
9782016-12-01T20:07:22 <wumpus> in any case reverting it for now makes sense
9792016-12-01T20:08:06 <BlueMatt> wumpus: https://sourceware.org/bugzilla/show_bug.cgi?id=20874#c4
9802016-12-01T20:08:07 *** d9b4bef9 has joined #bitcoin-core-dev
9812016-12-01T20:08:10 <BlueMatt> "This does look like a bug."
9822016-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
9832016-12-01T20:09:39 <BlueMatt> and I may be thinking of those, but gai_a is definitely unsafe
9842016-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 :)
9852016-12-01T20:10:06 <BlueMatt> good riddance
9862016-12-01T20:10:07 <luke-jr> sdaftuar: BIP 90; what's with the "foo" and "tmp.mediawiki" files?
9872016-12-01T20:10:17 <sdaftuar> luke-jr: gah, let check
9882016-12-01T20:10:23 <sdaftuar> let me check*
9892016-12-01T20:10:38 <wumpus> cfields: thanks for the update, looking forward to that :)
9902016-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
9912016-12-01T20:12:41 <cfields> (sorry, was trying to figure out what that had to do with gai_a)
9922016-12-01T20:13:20 <cfields> and actually, still not sure why they're entangled
9932016-12-01T20:13:25 <cfields> but either way, full revert sounds good to me
9942016-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).
9952016-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
9962016-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.
9972016-12-01T20:26:30 <BlueMatt> sdaftuar: yea, so I'd think dont backport 9252
9982016-12-01T20:28:00 *** gabridome has joined #bitcoin-core-dev
9992016-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
10002016-12-01T20:28:18 <sdaftuar> BlueMatt: done. er, undone. whateer.
10012016-12-01T20:31:30 <BlueMatt> cool, thanks
10022016-12-01T20:37:28 *** LeMiner has quit IRC
10032016-12-01T20:37:30 *** LeMiner has joined #bitcoin-core-dev
10042016-12-01T20:39:44 <morcos> jonasschnelli: Can I bother you to milestone for 0.14.0 #9107 and #9138
10052016-12-01T20:39:46 <gribble> https://github.com/bitcoin/bitcoin/issues/9107 | Safer modify new coins by morcos · Pull Request #9107 · bitcoin/bitcoin · GitHub
10062016-12-01T20:39:48 <gribble> https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
10072016-12-01T20:42:17 <BlueMatt> ACK on those for 14
10082016-12-01T20:52:37 *** randy-waterhouse has joined #bitcoin-core-dev
10092016-12-01T20:53:03 *** randy-waterhouse has joined #bitcoin-core-dev
10102016-12-01T20:53:33 *** bsm117532 has quit IRC
10112016-12-01T20:53:49 *** bsm117532 has joined #bitcoin-core-dev
10122016-12-01T20:58:37 <cfields> wumpus: are you aiming for 0.14 for #8811 ?
10132016-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
10142016-12-01T20:58:59 <luke-jr> sigh, MemorySanitizer is broken in Travis (not affecting Core)
10152016-12-01T21:00:04 *** bsm117532 has quit IRC
10162016-12-01T21:00:28 <cfields> luke-jr: doesn't it require an instrumented libc++ ?
10172016-12-01T21:01:18 <luke-jr> cfields: it worked before; seems some Linux kernel bugfix broke it
10182016-12-01T21:07:27 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c79e52ad304a...c1a52276848d
10192016-12-01T21:07:28 <bitcoin-git> bitcoin/master 9e1f468 Matt Corallo: Fix calculation of number of bound sockets to use
10202016-12-01T21:07:28 <bitcoin-git> bitcoin/master c1a5227 Pieter Wuille: Merge #9253: Fix calculation of number of bound sockets to use...
10212016-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
10222016-12-01T21:11:42 *** mrkent has joined #bitcoin-core-dev
10232016-12-01T21:35:07 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c1a52276848d...ad826b3df9f7
10242016-12-01T21:35:08 <bitcoin-git> bitcoin/master 5b0150a Gregory Maxwell: Make orphan parent fetching ask for witnesses....
10252016-12-01T21:35:09 <bitcoin-git> bitcoin/master ad826b3 Pieter Wuille: Merge #9188: Make orphan parent fetching ask for witnesses....
10262016-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
10272016-12-01T21:46:42 *** mrkent has quit IRC
10282016-12-01T21:49:04 *** mrkent has joined #bitcoin-core-dev
10292016-12-01T21:51:05 *** wvr has quit IRC
10302016-12-01T21:52:28 *** aalex__ has joined #bitcoin-core-dev
10312016-12-01T21:54:08 *** aalex has joined #bitcoin-core-dev
10322016-12-01T21:56:00 *** aalex_ has quit IRC
10332016-12-01T21:57:08 *** aalex__ has quit IRC
10342016-12-01T22:06:40 *** AaronvanW has joined #bitcoin-core-dev
10352016-12-01T22:06:40 *** AaronvanW has quit IRC
10362016-12-01T22:06:40 *** AaronvanW has joined #bitcoin-core-dev
10372016-12-01T22:07:40 *** bitcoin070 has quit IRC
10382016-12-01T22:08:10 *** droark has quit IRC
10392016-12-01T22:10:59 <BlueMatt> jtimon: ok with #9183 as-is now (with print cleanups maybe happening later?)
10402016-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
10412016-12-01T22:11:56 <jtimon> sure
10422016-12-01T22:13:22 <jtimon> BlueMatt: reacted with emojis to your answers, thanks
10432016-12-01T22:13:40 *** gabridome has quit IRC
10442016-12-01T22:14:52 <BlueMatt> cool, so i should bug sipa to press merge then...
10452016-12-01T22:15:15 <jtimon> right duh, it could work without the {}
10462016-12-01T22:15:24 <jtimon> fine with me
10472016-12-01T22:15:27 <BlueMatt> it could?
10482016-12-01T22:15:35 <BlueMatt> i dont think it does that level of magic, does it?
10492016-12-01T22:15:40 <jtimon> s/couldn't
10502016-12-01T22:16:06 <BlueMatt> ahh
10512016-12-01T22:16:17 <jtimon> I mean I should have realized that myself on review, but thanks for the clarification
10522016-12-01T22:26:41 *** randy-waterhouse has quit IRC
10532016-12-01T22:30:46 *** randy-waterhouse has joined #bitcoin-core-dev
10542016-12-01T22:30:53 *** gabridome has joined #bitcoin-core-dev
10552016-12-01T22:31:06 *** randy-waterhouse has quit IRC
10562016-12-01T22:31:06 *** randy-waterhouse has joined #bitcoin-core-dev
10572016-12-01T22:44:02 *** gabridome has quit IRC
10582016-12-01T22:47:07 <BlueMatt> oh, hey, the backport-needed PRs no longer touch main at all
10592016-12-01T22:47:13 <BlueMatt> hmm...sipa you wanna split main today?
10602016-12-01T22:47:33 <BlueMatt> or wumpus, if you havent gone to bed yet
10612016-12-01T22:48:12 <BlueMatt> also, anyone need some review-love?
10622016-12-01T22:56:50 *** protomar has quit IRC
10632016-12-01T22:58:31 *** dcousens has quit IRC
10642016-12-01T23:00:19 *** dcousens has joined #bitcoin-core-dev
10652016-12-01T23:06:20 <sipa> BlueMatt: does 9183 conflict with #9229, #9239, or #9194 ?
10662016-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
10672016-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
10682016-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
10692016-12-01T23:06:57 <BlueMatt> sipa: none of those touch main.{h,cpp}, which is the only thing 9183 touches
10702016-12-01T23:07:06 <BlueMatt> so...I doubt it?
10712016-12-01T23:07:08 <sipa> ok!
10722016-12-01T23:16:40 *** bitcoin272 has joined #bitcoin-core-dev
10732016-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?
10742016-12-01T23:17:23 <bitcoin272> running into a ton of issues here and i don't want to disable spending 0 conf change tb
10752016-12-01T23:17:25 <bitcoin272> tbh8
10762016-12-01T23:17:26 <bitcoin272> tbh*
10772016-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
10782016-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
10792016-12-01T23:19:47 <sipa> BlueMatt: it actually tries to avoid using very recently created change
10802016-12-01T23:19:50 <sipa> eh
10812016-12-01T23:19:51 <bitcoin272> instagibbs -- it's a huge huge issue unfortunately
10822016-12-01T23:19:52 <sipa> bitcoin272: ^
10832016-12-01T23:20:09 <bitcoin272> I don't know if this was ever a problem pre 0.13
10842016-12-01T23:20:19 <sipa> it should in 0.12 as well
10852016-12-01T23:20:19 *** nickler has quit IRC
10862016-12-01T23:20:21 <instagibbs> coin selection didn't change since then
10872016-12-01T23:20:28 <instagibbs> afaik
10882016-12-01T23:20:31 <sipa> indeed
10892016-12-01T23:20:32 <bitcoin272> what about mempool limits?
10902016-12-01T23:20:38 <instagibbs> nope
10912016-12-01T23:20:47 <sipa> mempool limits were added in 0.12
10922016-12-01T23:20:56 <instagibbs> right, since 0.12 i mean
10932016-12-01T23:20:58 <bitcoin272> i see
10942016-12-01T23:21:02 <bitcoin272> this behavior guys
10952016-12-01T23:21:10 <bitcoin272> is resulting in some very unfortunate things :/
10962016-12-01T23:21:27 <bitcoin272> where is the mempool constraint defined
10972016-12-01T23:21:34 <bitcoin272> is that something we could modify / recompile
10982016-12-01T23:21:40 <sipa> it's a setting
10992016-12-01T23:21:58 *** nickler has joined #bitcoin-core-dev
11002016-12-01T23:22:04 <sipa> limitancestorcount and limitdescendantcount
11012016-12-01T23:22:18 <bitcoin272> it defaults to 25?
11022016-12-01T23:22:21 <sipa> yes
11032016-12-01T23:22:26 <instagibbs> you can crank those up, but the wallet simply shouldn't violate those limits(I'm working on that)
11042016-12-01T23:22:30 <bitcoin272> and that's specifically meaning, dump things after 25 from the mempool, even if they are our own TX?
11052016-12-01T23:22:32 <sipa> yes, indeed
11062016-12-01T23:22:47 <sipa> bitcoin272: they're not dumped; they're just not accepted
11072016-12-01T23:22:55 <bitcoin272> i see... but
11082016-12-01T23:22:58 <bitcoin272> they are still broadcast to the network?
11092016-12-01T23:23:02 <sipa> no
11102016-12-01T23:23:08 <sipa> not until the rest is confirmed
11112016-12-01T23:23:17 <bitcoin272> ok right but
11122016-12-01T23:23:22 <bitcoin272> so to be clear
11132016-12-01T23:23:24 <bitcoin272> sendtoaddress will fail
11142016-12-01T23:23:29 <bitcoin272> the TX will sit in the wallet though
11152016-12-01T23:23:29 <sipa> yes, the wallet behaviour is bad currently
11162016-12-01T23:23:40 <bitcoin272> and when the parents confirm, it will auto rebroad cast
11172016-12-01T23:23:42 <bitcoin272> right?
11182016-12-01T23:23:51 <sipa> it should at least give an error instead of silently not doing anything
11192016-12-01T23:23:55 <sipa> yes, i believe it will
11202016-12-01T23:23:59 <bitcoin272> oh man so
11212016-12-01T23:24:06 <bitcoin272> this is the problem then
11222016-12-01T23:24:09 <bitcoin272> okay.. at least I know
11232016-12-01T23:24:23 <bitcoin272> it shouldn't queue that transaction because what happens is
11242016-12-01T23:24:28 <sipa> well it would be useful to verify this, by increasing your descendant and ancestor counts
11252016-12-01T23:24:37 <bitcoin272> it's easy for business logic to believe a transaction send has failed
11262016-12-01T23:24:41 <bitcoin272> and resend it
11272016-12-01T23:24:49 <bitcoin272> only for the wallet to send the same coins again when the parents confirm
11282016-12-01T23:24:57 <bitcoin272> resulting in multiple payments being facilitated
11292016-12-01T23:25:02 <sipa> yup
11302016-12-01T23:25:03 <bitcoin272> most unfortunate indeed
11312016-12-01T23:25:26 <bitcoin272> okay well this is a start
11322016-12-01T23:25:34 <bitcoin272> and this would've never been apparent pre 0.12 right
11332016-12-01T23:25:40 <BlueMatt> aaccctuuallllyyyyy....anyone have any objections if main.cpp gets renamed to "blocktxprocessing.cpp"?
11342016-12-01T23:25:46 <sipa> indeed
11352016-12-01T23:25:52 <bitcoin272> okay
11362016-12-01T23:25:55 <bitcoin272> sipa, I really appreciate this
11372016-12-01T23:25:57 <bitcoin272> this clarifies things
11382016-12-01T23:26:22 <bitcoin272> what is a reasonable limitancestorcount if resource consumption is low
11392016-12-01T23:26:45 <sipa> bitcoin272: thanks; if you have further results, can you comment here? https://github.com/bitcoin/bitcoin/issues/9019
11402016-12-01T23:27:05 <sipa> bitcoin272: you're not mining, right?
11412016-12-01T23:27:15 <bitcoin272> nope
11422016-12-01T23:27:25 <bitcoin272> I am going to bump ancestor/descendant count to 200
11432016-12-01T23:27:31 <sipa> that sounds reasonable to me
11442016-12-01T23:27:41 <sipa> just to be clear: don't expect these chains to confirm quickly
11452016-12-01T23:28:02 <sipa> because other nodes in the network won't accept these long chains, at least not immediately
11462016-12-01T23:28:14 <sipa> on rebroadcasts they should go out piecewise, though
11472016-12-01T23:28:33 <bitcoin272> well
11482016-12-01T23:28:39 <bitcoin272> it's more important that the sendtoaddress command doesn't fail
11492016-12-01T23:28:44 <bitcoin272> but still enqueue an automatic payment
11502016-12-01T23:28:47 <bitcoin272> that is 100% the most important
11512016-12-01T23:28:52 <bitcoin272> we just need sendtoaddress to return a txid
11522016-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
11532016-12-01T23:33:39 <bitcoin272> is there a way to purge a transaction
11542016-12-01T23:33:44 <bitcoin272> so it doesn't send?
11552016-12-01T23:33:48 <bitcoin272> (on this automatic queue)
11562016-12-01T23:34:33 *** Guyver2 has quit IRC
11572016-12-01T23:34:43 <bitcoin272> will abandontransaction do it?
11582016-12-01T23:38:33 <sipa> yes
11592016-12-01T23:38:57 <sipa> that's the intended behaviour... if your transaction doesn't confirm and gets evicted, you can manually abandon it
11602016-12-01T23:39:09 <sipa> though it's not very well integrated or good guidelines for it
11612016-12-01T23:39:14 <bitcoin272> i hear you
11622016-12-01T23:39:27 <bitcoin272> well
11632016-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
11642016-12-01T23:39:31 <bitcoin272> this has been a fun day, lol
11652016-12-01T23:39:33 <bitcoin272> right
11662016-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
11672016-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
11682016-12-01T23:40:45 <sipa> indeed
11692016-12-01T23:40:47 <bitcoin272> and sendtoaddress fails but it enqueues the transaction for broadcast automatically
11702016-12-01T23:42:49 <bitcoin272> is there any way to verify what the ancestor limit is
11712016-12-01T23:42:55 <bitcoin272> I bumped both limits to 250
11722016-12-01T23:43:06 <bitcoin272> just want to know if it's reflected in current config (I restarted daemon)
11732016-12-01T23:44:41 <sipa> if you used the correct option name, it should
11742016-12-01T23:44:51 <sipa> limitancestorcount=250
11752016-12-01T23:44:55 <sipa> in bitcoin.conf
11762016-12-01T23:48:58 <sipa> BlueMatt: so there will be the blockprocessing file and the rest? where does ProcessMessage go?
11772016-12-01T23:49:07 <BlueMatt> sipa: net_processing
11782016-12-01T23:49:20 <BlueMatt> net_processing.cpp and blocktx_processing.cpp
11792016-12-01T23:49:29 <BlueMatt> or blockandtxprocessing.cpp
11802016-12-01T23:49:34 <sipa> and will there still be main.cpp?
11812016-12-01T23:49:37 <BlueMatt> no
11822016-12-01T23:49:40 <BlueMatt> (!)
11832016-12-01T23:49:56 <sipa> really, is there nothing that doesn't fit either of those
11842016-12-01T23:50:21 <BlueMatt> theres some variables declared that dont
11852016-12-01T23:50:24 <BlueMatt> but aside from that, not really
11862016-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
11872016-12-01T23:52:49 <BlueMatt> and all of those arguably do
11882016-12-01T23:53:49 <sipa> GetTransaction, LastCommonAncestor, FormatStateMessage, AlertNotify, GetWarnings,
11892016-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.
11902016-12-01T23:54:19 <BlueMatt> AlertNotify is used exclusively for fork notification
11912016-12-01T23:54:24 <BlueMatt> and GetWarnings mostly is as well
11922016-12-01T23:54:26 <sipa> BlueMatt: how about calling it validation.cpp?
11932016-12-01T23:54:27 <bitcoin272> gmaxwell: understood, thank you
11942016-12-01T23:54:32 <BlueMatt> ok!
11952016-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
11962016-12-01T23:55:03 <gmaxwell> bitcoin272: you can also split up coins you deposit into the wallet to reduce the need for chaining
11972016-12-01T23:55:08 <bitcoin272> gmaxwell: yup
11982016-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.