1 2015-07-16 01:52:23 <sipa> TIL that you can use 'and' in C++ instead of &&
  2 2015-07-16 01:52:26 <sipa> http://en.cppreference.com/w/cpp/keyword/and
  3 2015-07-16 01:52:31 <ssa3512> sipa: what!
  4 2015-07-16 01:52:33 <ssa3512> no way
  5 2015-07-16 01:53:18 <sipa> my compiler just complained when i tried to call a variable 'and'
  6 2015-07-16 01:53:50 <ssa3512> hm, I didn't know about Digraphs and Trigraphs either
  7 2015-07-16 01:54:20 <ssa3512> ??< and ??> compile as open and close curly brackets
  8 2015-07-16 01:54:31 <sipa> i had heard about those
  9 2015-07-16 01:54:37 <sipa> but never looked into the details
 10 2015-07-16 01:55:09 <ssa3512> http://en.cppreference.com/w/cpp/language/operator_alternative
 11 2015-07-16 01:55:21 <ssa3512> not or and xor work too
 12 2015-07-16 01:59:05 <franl> And bitand is &, not_eq is !=, comp is ~
 13 2015-07-16 02:18:08 <ssa3512> does anyone know if Trezor support for Armory is coming any time soon?
 14 2015-07-16 04:15:23 <cfields> sipa: iirc that's a gcc-ism
 15 2015-07-16 04:15:59 <cfields> heh, i guess i should've clicked the link first
 16 2015-07-16 04:16:16 <cfields> maybe it's a gcc-ism for c? i could swear i just saw that in the man pages this week
 17 2015-07-16 08:08:58 <jtimon> sipa gavinandresen wumpus re "primitives/transaction.cpp added #include "memusage.h"" another option is to just not use #include "memusage.h" and turn methods into functions elsewhere (maybe slightly hurting encapsulation)
 18 2015-07-16 08:47:44 <jonasschnelli> aschildbach: i got the same mails from hetzner. :)
 19 2015-07-16 08:47:54 <jonasschnelli> aschildbach: if you like i have a patch ready.
 20 2015-07-16 08:48:09 <aschildbach> Ah cool to know
 21 2015-07-16 08:48:23 <jonasschnelli> hetzner is complaining about connections to non routable nets
 22 2015-07-16 08:48:42 <jonasschnelli> After i added the patch no more mails got sent over the net abuse checker.
 23 2015-07-16 08:49:10 <aschildbach> When did you get those mails?
 24 2015-07-16 08:53:39 <jonasschnelli> aschildbach: maybe 1-2 month ago.
 25 2015-07-16 08:53:42 <jonasschnelli> aschildbach: check https://github.com/jonasschnelli/bitcoin-seeder/commit/4abf94b12baa62b1da60c0129c754f3f20171268
 26 2015-07-16 08:53:51 <jonasschnelli> it's a quick and dirty solution
 27 2015-07-16 09:09:05 <aschildbach> jonasschnelli: Thanks! Maybe we should pull that commit upstream? It doesn't look too quick & dirty to me.
 28 2015-07-16 10:36:02 <aschildbach> hearn: Hi Mike!
 29 2015-07-16 10:36:16 <aschildbach> How's the TOA?
 30 2015-07-16 10:40:04 <wumpus> jtimon: yes, that's an option too
 31 2015-07-16 10:43:07 <jtimon> nobody has any thoughts on #6445 ? (Don't calculate nValueOut 5 times, Don't calculate nValueIn 3 times, Don't call CCoinsViewCache::HaveInputs 3 times )
 32 2015-07-16 10:43:23 <jtimon> that's only in AcceptToMemoryPool
 33 2015-07-16 13:04:51 <instagibbs> when installing from source, what directories do files end up in linux? I'm having an odd issue trying to upgrade my node, and am wondering if some residual files are screwing with me.
 34 2015-07-16 13:06:19 <instagibbs> compiling/running node
 35 2015-07-16 13:09:36 <harding> instagibbs: you can re-run ./configure with --prefix=/path to create a clean install for inspection.
 36 2015-07-16 13:14:58 <instagibbs> any good digest of the configure flags?
 37 2015-07-16 13:16:08 <harding> instagibbs: ./configure --help
 38 2015-07-16 13:16:20 <instagibbs> thx
 39 2015-07-16 13:24:38 <instagibbs> I see, I think I was installing in two different places accidentally. Thanks again. All updated now.
 40 2015-07-16 15:51:23 <jtimon> wumpus: cfields sipa would it make sense to put https://github.com/sipa/bitcoin/commit/27fc6c70f4e55ea4d7aa72472fb204865b264dce in the theuni/trivial-next ? It makes #6421 less readable
 41 2015-07-16 15:52:39 <jtimon> also when will be the trivial branch merged again ? (right after including that commit would be an option)
 42 2015-07-16 15:54:24 <jtimon> even if it's not using the trivial branch, I think we should merge that asap
 43 2015-07-16 16:09:34 <sipa> jtimon: sorry, i've been focussing on other things for the past few days
 44 2015-07-16 16:09:46 <jtimon> it's fine
 45 2015-07-16 16:12:02 <jtimon> sipa I'm about to propose reduced version of #6421 that caps the mempool, but simply rejects all replacements for now (at the same time I'm rebasing #6421 on top of that, of course)
 46 2015-07-16 16:12:49 <jtimon> do you think that makes sense? it's the dumbest replacement policy possible (the same we have for spending conflicts replacements, simply reject them all)
 47 2015-07-16 16:13:11 <jtimon> but hopefully #6421 would replace that soon
 48 2015-07-16 16:13:52 <jtimon> and we would get the mempool cap faster
 49 2015-07-16 16:46:22 <morcos> jtimon: the QT_NO_KEYWORDS almost entirely goes away if you rebase #6421
 50 2015-07-16 16:46:46 <morcos> i think the problem is a dumb cap (no replacement) is not necessarily better than an unbounded mempool
 51 2015-07-16 16:47:00 <jtimon> morcos oh, yeah, it's only 4 lines now
 52 2015-07-16 16:47:24 <jtimon> morcos well, at least you have the option to bound it
 53 2015-07-16 16:47:25 <morcos> for instance if that cap had been set at 100MB we'd have seen much worse problems on the network than we with unbounded mempools
 54 2015-07-16 16:47:58 <morcos> i suppose, as an option with a default of no_limit, but it doesn't seem like we'll release something like that until we get a better version in place
 55 2015-07-16 16:49:01 <jtimon> we can set it to 5 GB as default, there must be a default where having it is better than not having it for 90% of the users
 56 2015-07-16 16:49:03 <morcos> and the problem i see with #6421, is that although its probably clearly better as is than unbounded mempool.  it's replaced a big problem of one type, with a smaller but still big problem of another type
 57 2015-07-16 16:49:13 <jtimon> and the other 10% can change the default
 58 2015-07-16 16:49:38 <morcos> and it would be better to just try and make sure our fix doesn't have as much downside first...
 59 2015-07-16 16:50:00 <morcos> is there some emergency release with a mempool cap that's being planned that i don't know about?
 60 2015-07-16 16:50:20 <jtimon> do you think that a dumb limit that defaults at 5 GB has much of a downside ?
 61 2015-07-16 16:50:23 <morcos> i'm working on some improvements (discussed previously on IRC) to 6421
 62 2015-07-16 16:50:57 <jtimon> I don't know of any emergency release
 63 2015-07-16 16:51:38 <morcos> and then sdaftuar is working on a more radical sort by package fee rate design which would avoid the problems altogether.  it remains to be seen how feasible the package plan will be, but I think given a little more time, we can at least get some improvements to 6421 in place
 64 2015-07-16 16:51:56 <morcos> and then its going to need some heavy testing
 65 2015-07-16 16:52:47 <jtimon> well, let me finish my proposal and let me know what you think when you see the code, I hope nobody has any complain so that it can be merged fast and everybody can work on the same base
 66 2015-07-16 16:53:34 <morcos> how is that better than using 6421 as a base?
 67 2015-07-16 16:54:27 <jtimon> if it is merged, is more likely that everyody is working on top of it
 68 2015-07-16 16:55:11 <jtimon> if 6421 gets merged, then I just rebase #6416 and I close mine
 69 2015-07-16 16:56:20 <jtimon> #6416 also allows us to reuse someparts of the code to implement things like zero-conf-safe-RBF (which could replace first-seen)
 70 2015-07-16 16:56:46 <morcos> i guess there can be differing opinions, but I'd prefer to get the major functional change in first, and then concentrate on cleanups
 71 2015-07-16 16:56:58 <morcos> 6416 for instance conflicts with my improvements to 6421
 72 2015-07-16 16:57:45 <jtimon> not if you rebase on top of my rebased version of 6421, give me a sec
 73 2015-07-16 16:58:36 <jtimon> if you're building on top of 6421, your rebase on top of my rebased version of 6421 should be clean
 74 2015-07-16 17:01:32 <jtimon> I mean, I can even do a same thing without #6416, the main point is introducing the cap first, and the replacement policy (which will have more discussion and testing) later
 75 2015-07-16 17:02:41 <windter> Is there a default txfee in 0.11, for when bitcoind hasn't observed enough transactions to yet estimate fees?
 76 2015-07-16 17:03:20 <jtimon> uh, no, wait, what am I saying, the rebase wouldn't be clean, just probably simple
 77 2015-07-16 17:04:55 <jtimon> windter for the wallet or for relay policy?
 78 2015-07-16 17:05:10 <windter> @jtimon: For the wallet, when sending via rpc
 79 2015-07-16 17:05:30 <windter> I'm just wondering what happens when I freshly boot my bitcoind and it doesn't yet know what floating fees to use
 80 2015-07-16 17:06:58 <sipa> windter: it stores the fee estimate data on disk
 81 2015-07-16 17:07:27 <windter> Maybe it's because I just did an upgrade, but I ran  bitcoin-cli estimatefee 3  and it returns -1
 82 2015-07-16 17:07:44 <windter> So during that state, does that mean I'm unable to send transactions (if the default estimate is set to 3)
 83 2015-07-16 17:36:15 <cfields> jtimon: mind giving me a list of your PRs that are ready for review?
 84 2015-07-16 17:38:23 <jtimon> cfields I'll just close the ones that are not ready for review, that will be faster
 85 2015-07-16 17:38:31 <jtimon> then you can just go to https://github.com/bitcoin/bitcoin/pulls/jtimon
 86 2015-07-16 17:39:07 <cfields> ok, thanks
 87 2015-07-16 17:43:27 <morcos> windter: probably a question better for #bitcoin, but the answer is you can send a transaction with the default mininimum.  However that's probably not a great value to use right now
 88 2015-07-16 17:45:56 <windter> @morcos: (sorry, tried asking there but didn't get a straight answer).  Is the minimum fee what bitcoin will use in the case of `sendtoaddress` when it doesn't yet have a fee estimate?
 89 2015-07-16 17:46:10 <windter> Guess i can fire up a new bitcoin and find out
 90 2015-07-16 17:54:26 <jtimon> morcos: #6448
 91 2015-07-16 17:54:50 <jtimon> cfields: done, I had to close one, now my 13 open PRs are ready for review
 92 2015-07-16 17:56:17 <jtimon> cfields: I think #6068  #6381 and #6235 will all be fast for you to review
 93 2015-07-16 17:57:04 <jtimon> and the rebased I just did on #5114 seems to have failed...so better wait on that one
 94 2015-07-16 18:05:17 <jtimon> cfields: also, I closed #6051 and #6009, not because they weren't ready, but because nobody provides any feedback on txverify.cpp + blockverify.cpp vs consensus.cpp
 95 2015-07-16 18:07:02 <jtimon> if we go with .cpp, we would need to chose between exposing first verifyTx or verifyHeader, or just move all the code first and not expose anything else until libconsensus is fully ready
 96 2015-07-16 18:08:10 <jtimon> I know some people like gmaxwell dislike code movements, but it would be nice to know which of these approaches he would dislike more
 97 2015-07-16 18:10:46 <cfields> jtimon: thanks, looking
 98 2015-07-16 18:11:25 <jtimon> cfields: no problem, thanks to you for reviewing
 99 2015-07-16 19:33:09 <ajweiss> cfields: i've been playing around with gitian builds and it looks like the build system is trying to run wget inside of the conatiner, but it's not installed.  do you know why this would happen?
100 2015-07-16 19:33:16 <morcos> jtimon and sipa: see #6449 for my suggested improvements to #6421
101 2015-07-16 19:33:37 <cfields> ajweiss: 'make download' before running gitian, and copy the files to the cache
102 2015-07-16 19:35:03 <ajweiss> cfields: ok, and if i want to force a rebuild of dependencies, just clear the cache dir and replace the common subdir?
103 2015-07-16 19:35:26 <cfields> correct
104 2015-07-16 19:36:53 <ajweiss> ok, so it's trying to regrab native_ccache, and it appears to be intact in cache/common... any ideas why?
105 2015-07-16 19:38:15 <cfields> ajweiss: it'll re-fetch if the checksum doesn't match. that's about the only reason i can think of
106 2015-07-16 19:38:56 <cfields> unless maybe your timestamps are completely busted. but iirc they're never even checked, only file existence
107 2015-07-16 21:07:20 <ajweiss> hrm.  looks like sourceforge is b0rked
108 2015-07-16 21:33:26 <jgarzik> ajweiss, which bit?  should be mostly unused now
109 2015-07-16 21:33:59 <ajweiss> jgarzik: 'make download' pulls boost down from them
110 2015-07-16 21:34:31 <ajweiss> they're returning an error page, so the transfer succeeds, but the result fails the checksum
111 2015-07-16 22:05:15 <cfields> ajweiss: grr, i've reported that to them a few times
112 2015-07-16 23:13:25 <justinnewton> sort of a meta question, but could a list moderator release the post that I made early this morning?  Thank you!
113 2015-07-16 23:14:01 <sipa> are you on the new list?
114 2015-07-16 23:58:30 <warren> Anyone have a domain with strict DMARC enforcement who can retest the bitcoin-dev list?
115 2015-07-16 23:59:27 <warren> jgarzik: ^