12015-10-06T00:44:11 *** belcher has quit IRC
22015-10-06T00:44:21 *** CodeShark has joined #bitcoin-core-dev
32015-10-06T00:45:50 <gmaxwell> univale interface change sadness of the day: listunspent 0 9999999999 [stuff] fails because 9999999999 is too big.
42015-10-06T00:46:07 <gmaxwell> I expect this to bite some number of users.
52015-10-06T00:46:22 <gmaxwell> should probably be release noted that your 'infinite' values may be too large
62015-10-06T00:55:56 *** BashCo has joined #bitcoin-core-dev
72015-10-06T01:00:15 *** BashCo has quit IRC
82015-10-06T01:00:50 <jgarzik> gmaxwell, or just s/get_int/get_int64/
92015-10-06T01:03:56 <sipa> yeah, sounds like a bug in the conversion of the bitcoin to univalue, not a problem with univalue itself
102015-10-06T01:04:38 <gmaxwell> thats not a bitcoin value, it's an integer (confirmation depth). It could be 64bit.
112015-10-06T01:04:53 <jgarzik> we know
122015-10-06T01:05:35 <jgarzik> bug in conversion of bitcoin code to univalue
132015-10-06T01:05:56 <jgarzik> Let's see if 'git blame' works through all our refactors...
142015-10-06T01:06:15 <sipa> that code has hardly been touched by refactors :)
152015-10-06T01:07:20 <jgarzik> 2 major code movements to unwind so far
162015-10-06T01:08:10 <jgarzik> Though I'm guessing the problem is more subtle -- json_spirit code probably used get_int()
172015-10-06T01:09:40 <sipa> that would explain
182015-10-06T01:10:00 <sipa> did get_int behave differently in json spirit?
192015-10-06T01:10:17 <jgarzik> that's what I'm investigating now
202015-10-06T01:11:34 <sipa> cool
212015-10-06T01:11:57 <sipa> i've requested botbot logging for this channel, btw
222015-10-06T01:12:13 <sipa> (as suggested by btcdrak)
232015-10-06T01:12:44 <jgarzik> json_spirit implements get_int() as: return static_cast< int >( get_int64() );
242015-10-06T01:13:15 * jgarzik is a static_cast<> newbie - I wonder if that means an out-of-range behavior is different
252015-10-06T01:16:09 <jgarzik> i.e. static_cast<> triggers "new_type foo(int64)" which results in a INT_MAX value for out of range, versus an exception thrown for univalue
262015-10-06T01:29:27 <jgarzik> gmaxwell, Does this fix? http://gtf.org/garzik/bitcoin/patch.univalue_get_int
272015-10-06T01:30:16 <gmaxwell> jgarzik: I dunno that changing it is the right thing to do? new behavior might be better?
282015-10-06T01:30:40 <jgarzik> gmaxwell, I think new behavior is better, more type specific
292015-10-06T01:31:07 <jgarzik> gmaxwell, However checking that patch would provide a quick field fix + ascertain that it is indeed the problem
302015-10-06T01:31:31 <gmaxwell> k would be glad to test.
312015-10-06T01:31:40 <jgarzik> gmaxwell, every .get_int() would need to be re-examined
322015-10-06T01:33:30 <gmaxwell> er, I am currently diverged from master; so uh. hm.
332015-10-06T01:36:31 <jgarzik> gmaxwell, the file paths may have shuffled, but the files & code are likely to be applicable
342015-10-06T01:37:04 <rusty> sipa: botbot.me people finally got back to me about logging #lightning-dev; will ping them about this too when we close the loop.
352015-10-06T01:44:25 *** ParadoxSpiral_ has quit IRC
362015-10-06T01:46:04 <GitHub13> [bitcoin] sandakersmann opened pull request #6766: [Trivial] Consistent use of lower case letters (master...lower_case) https://github.com/bitcoin/bitcoin/pull/6766
372015-10-06T01:51:15 <GitHub62> [bitcoin] sandakersmann opened pull request #6767: [Trivial] Missing "Core" in header (master...missing_core) https://github.com/bitcoin/bitcoin/pull/6767
382015-10-06T01:58:38 <morcos> maaku: i didn't understand your response on email about decreasing granualarity being a soft fork?
392015-10-06T02:01:46 *** rusty has left #bitcoin-core-dev
402015-10-06T02:03:17 <morcos> maybe i'm confused as to what decreasing granularity means, but it seems to me if you go from 8 second granularity to 1 second granularity, you need 3 more bits and its a soft fork? if you decide you don't need 1 second granularity, and want to use those 3 bits for something else, that would be hard fork
412015-10-06T02:04:40 <morcos> so why not set aside more of the low order bits to start with and use only like 64 second granularity. then we'd have 1 high order bit for a different scheme and 11 or 14 low order bits for soft forking within the scheme
422015-10-06T02:12:32 <GitHub146> [bitcoin] sandakersmann closed pull request #6767: [Trivial] Missing "Core" in header (master...missing_core) https://github.com/bitcoin/bitcoin/pull/6767
432015-10-06T02:26:12 *** d_t has joined #bitcoin-core-dev
442015-10-06T02:50:23 <maaku> morcos: my terminology was reversed, sorry
452015-10-06T02:50:51 <maaku> but going from 1s -> 2^n seconds is a soft fork
462015-10-06T02:50:59 <morcos> maaku: why?
472015-10-06T02:51:18 <morcos> doesn't that depend on what the interpretation of those bits is in the new rules
482015-10-06T02:51:34 <maaku> morcos: you round up the relative lock-time to 2^n
492015-10-06T02:51:55 <morcos> the new rules will say that
502015-10-06T02:52:19 <morcos> but if the old rules use 1s, then something that was valid under the old rules, may or may not be valid under the new rules
512015-10-06T02:52:20 <maaku> right
522015-10-06T02:52:34 <maaku> that's a soft-fork
532015-10-06T02:53:02 <morcos> oh, did i just confuse myself
542015-10-06T02:53:37 <maaku> i think you're getting tripped up over a different concern -- if you change the meaning of those bits, old clients might be setting them without knowing that they are assigning meaning
552015-10-06T02:54:36 <maaku> but that too can be managed, either by making sure it is relatively harmless under the new rules, or by soft-forking in the "round up" rule, making those bits non-standard, letting infrastructure upgrade, and then soft-forking new meaning
562015-10-06T02:55:03 <morcos> so what exactly is the round up rule?
572015-10-06T02:55:42 <morcos> if we decide to use a few less bits, then you'll shift by less bits and then add 1 and then multiply by 2^n?
582015-10-06T02:56:00 <morcos> less = n
592015-10-06T02:56:03 <maaku> let's say we recover 3 from the time version, then 0 is a lock-time of 0, 1-8 are a lock-time of 8
602015-10-06T02:56:19 <maaku> *recover 3 bits
612015-10-06T02:56:22 <morcos> but how does that work
622015-10-06T02:56:28 <morcos> because don't 1 and 0 look the same
632015-10-06T02:56:45 <morcos> 0-7 look the same
642015-10-06T02:57:37 <maaku> the usual bitfiddling (n + 7) & ~0x7
652015-10-06T02:57:43 <maaku> or somesuch
662015-10-06T02:59:01 <morcos> i'll freely admit i'm too tired to convince even myself i know what i'm talking about, but perhaps it would help if you could write up a quick demonstration
672015-10-06T03:00:07 <morcos> also i didn't really think about how it ties into CSV?
682015-10-06T03:01:02 *** d_t has quit IRC
692015-10-06T03:01:23 <maaku> python -c 'for i in xrange(16): print "%d\t%d" % (i, (i+7) & ~0x7)'
702015-10-06T03:01:54 <maaku> http://0bin.net/paste/UHDsIjXHKean074O#OSrQQUnwoDJQeJ586RyQaAcxxmrE41tuLzBrjk0kj11
712015-10-06T03:02:43 <morcos> ha ha, yeah i got what you were saying, but the point is if you're no longer using those low 3 order bits how can you do that, they now mean something different
722015-10-06T03:03:17 <maaku> OH ok. I thought there must be a miscommunication. It's not THAT late there ;)
732015-10-06T03:03:36 <maaku> I mean you would just do that for the purpose of the relative lock-time check
742015-10-06T03:05:01 <maaku> so under the new rules, within LockTime() only, it does this round-up rule when calculating relative lock-time
752015-10-06T03:05:21 <morcos> but you can't, if someone wants to encode 000 in the 3 bits for the new rule and 0 for a lock time. they will have 0000 = 0 for CSV . on the other hand, someone who wanted to encode 111 for the new rule woudl have 0111 = 8 for CSV . but they both wanted 0 for CSV
762015-10-06T03:05:35 <morcos> how could someone encode 111 for the new rule, but still have a 0 for CSV
772015-10-06T03:06:27 <morcos> so perhaps thats a soft fork in that its more restrictive, but they can no longer choose the values they wanted?
782015-10-06T03:06:48 <maaku> you can't. but is that an issue?
792015-10-06T03:06:56 *** d_t has joined #bitcoin-core-dev
802015-10-06T03:07:13 <maaku> i mean you could round up the entire range so 0-7 means 8, 8-15 means 16
812015-10-06T03:07:22 <maaku> but then you lose the ability to specify zero lock time at all
822015-10-06T03:07:40 <maaku> for CSV, it does straight integer comparisons. it doesn't even mask off the unused low order bits
832015-10-06T03:07:40 <morcos> well thats what i'm claiming is that depending on what you wanted to use the other 3 bits for you might lose that
842015-10-06T03:07:48 <morcos> so i agree rounding up is a soft fork
852015-10-06T03:07:54 <morcos> if you lose some bits
862015-10-06T03:08:07 <morcos> why is adding bits for finer time granularity a hard fork
872015-10-06T03:10:47 <maaku> well now that we've had this conversation, I suppose you could add bits, just not to the first range
882015-10-06T03:10:52 <GitHub89> [bitcoin] jmcorgan opened pull request #6768: zmq: update docs to reflect feature is compiled in automatically (master...update-zmq-docs) https://github.com/bitcoin/bitcoin/pull/6768
892015-10-06T03:11:18 <morcos> first range? you mean high order bits?
902015-10-06T03:12:08 <maaku> let's say you went from 8s -> 1s
912015-10-06T03:13:20 <maaku> you could do that by saying 0 is now a relative lock-time of 8, 1 (previously still 0: 0.001) is now a relative lock-time of 9, 2 (0.010) is 10, etc.
922015-10-06T03:13:39 <morcos> i'm not sure i understand why you don't mask off the lower order bits for CSV. wouldn't that make it harder potentially to make some other soft fork out of them later.
932015-10-06T03:13:46 *** d_t has quit IRC
942015-10-06T03:14:23 <maaku> the bits were originally added by a suggestion from gmaxwell who was considering them to represent a share chain
952015-10-06T03:14:24 <morcos> i don't understand why you have to round up if you're adding bits... 0 is 0. 0.001 was 0 now its 1 and so on.. why do you have to start at 8?
962015-10-06T03:14:35 <maaku> in that case you could even have sub-block granularity
972015-10-06T03:15:15 <maaku> but you're right, masking them should be strictly safe to do
982015-10-06T03:15:23 <maaku> *safely soft-fork upgradable
992015-10-06T03:16:53 <morcos> i guess i'm viewing the low order bits (if they're masked off for all operations now) as something that is available for any kind of soft fork we want in the future while still have BIP 68 in effect
1002015-10-06T03:17:16 <morcos> and the high order bit represents a way to selectively have BIP 68 or some other use of nSequence
1012015-10-06T03:18:04 <maaku> correct
1022015-10-06T03:18:28 <morcos> so to me, if we're pretty sure we like BIP 68, then having only 1 high order bit is good enough, but we should leave as many low order bits as we can. i hadn't thought about the rounding up to get rid of some bits, but that doesn't work well if CSV is checking them anyway.
1032015-10-06T03:19:22 <maaku> morcos: it works the same I think
1042015-10-06T03:19:34 *** d_t has joined #bitcoin-core-dev
1052015-10-06T03:19:42 <morcos> i'm sorry for chiming in with an opinion late in this process, i wasn't really paying much attention earlier. but to the extent we preserve as much flexibility for the future as we can, it helps address petertodd's concerns
1062015-10-06T03:20:07 <maaku> I'm all for increased flexibility
1072015-10-06T03:20:18 <maaku> just trying to map out the ramifications here myself
1082015-10-06T03:21:13 <morcos> yeah i mean maybe even with CSV checking all the bits, as long as you round up enough you're ok, but i think it makes sense to make sure we're not losing any edge cases. I suppose a relative time lock of 0 seconds has no benefit because you can always use a 0 block lock?
1092015-10-06T03:21:38 <morcos> but it just seems cleaner to me to start with less bits and add more if we need the granularity than the other way around
1102015-10-06T03:24:48 <maaku> thank you for calling me on this; my thinking on the soft-fork vs hard-fork was backwords
1112015-10-06T03:25:31 <maaku> I just worked out some examples and it is a soft-fork to add bits
1122015-10-06T03:27:01 <morcos> just glad i wasn't totally off my rocker
1132015-10-06T03:27:54 <maaku> morcos: my proposal would then be 16-bits of precision: block-height granularity of 1 block, block-time granularity of 512s
1142015-10-06T03:28:05 <maaku> in both cases up to a year of relative lock-time
1152015-10-06T03:29:19 <morcos> yeah i mean i think that sounds nicer to me, but i'm not very familiar with the use cases
1162015-10-06T03:30:06 <maaku> well sub-600s lock-times are suspect anyway, because block interval and variance
1172015-10-06T03:31:51 <morcos> so with CSV it's valid if they are the same right? so yeah then it doesn't matter if you're including all the low order bits when comparing
1182015-10-06T03:33:18 <morcos> oh wait
1192015-10-06T03:33:45 <maaku> i think you would get the most flexibility by masking there as well
1202015-10-06T03:33:51 <morcos> yeah
1212015-10-06T03:36:20 <morcos> i wonder if it would be simpler just to reserve all the bits on the high order side
1222015-10-06T03:36:44 <morcos> you can always do the same thing with those bits, just a bit more complicated
1232015-10-06T03:38:33 <morcos> anyway, got to call it a night
1242015-10-06T03:39:18 <maaku> g'night
1252015-10-06T03:52:16 <GitHub183> [bitcoin] gmaxwell opened pull request #6769: Test LowS in standardness, removes nuisance malleability vector. (master...no_nuisance_malleability) https://github.com/bitcoin/bitcoin/pull/6769
1262015-10-06T04:59:52 *** Squidicuz has quit IRC
1272015-10-06T04:59:53 *** goregrind has quit IRC
1282015-10-06T05:02:42 *** Squidicuz has joined #bitcoin-core-dev
1292015-10-06T05:03:19 *** helo has quit IRC
1302015-10-06T05:03:36 *** fkhan has quit IRC
1312015-10-06T05:03:52 *** Apocalyptic has quit IRC
1322015-10-06T05:04:00 *** Luke-Jr has quit IRC
1332015-10-06T05:05:08 *** helo has joined #bitcoin-core-dev
1342015-10-06T05:06:41 *** Luke-Jr has joined #bitcoin-core-dev
1352015-10-06T05:09:49 *** Apocalyptic has joined #bitcoin-core-dev
1362015-10-06T05:16:59 *** fkhan has joined #bitcoin-core-dev
1372015-10-06T06:05:55 *** paveljanik has joined #bitcoin-core-dev
1382015-10-06T06:53:31 *** alpalp has quit IRC
1392015-10-06T07:05:15 <btcdrak> morcos: did you see my ML post? if you set the nSequence MSB then the remaining 31 bits are free entirely.
1402015-10-06T07:29:52 *** n0n0__ has joined #bitcoin-core-dev
1412015-10-06T07:57:49 <GitHub155> [bitcoin] laanwj closed pull request #6766: [Trivial] Consistent use of lower case letters (master...lower_case) https://github.com/bitcoin/bitcoin/pull/6766
1422015-10-06T08:00:03 <GitHub28> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a75c67364d34...3b2d37c61963
1432015-10-06T08:00:03 <GitHub28> bitcoin/master 58981d4 Arne Brutschy: Changed logging to make -logtimestamps to work also for -printtoconsole
1442015-10-06T08:00:04 <GitHub28> bitcoin/master 3b2d37c Wladimir J. van der Laan: Merge pull request #6742...
1452015-10-06T08:00:11 <GitHub180> [bitcoin] laanwj closed pull request #6742: Changed logging to make -logtimestamps to work also for -printtoconsole (master...feature-logtimestamps-toconsole) https://github.com/bitcoin/bitcoin/pull/6742
1462015-10-06T08:01:08 <GitHub17> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3b2d37c61963...5d98e0fa1496
1472015-10-06T08:01:08 <GitHub17> bitcoin/master 9f5c641 Johnathan Corgan: zmq: update docs to reflect feature is compiled in automatically if possible...
1482015-10-06T08:01:09 <GitHub17> bitcoin/master 5d98e0f Wladimir J. van der Laan: Merge pull request #6768...
1492015-10-06T08:01:13 <GitHub193> [bitcoin] laanwj closed pull request #6768: zmq: update docs to reflect feature is compiled in automatically (master...update-zmq-docs) https://github.com/bitcoin/bitcoin/pull/6768
1502015-10-06T08:01:57 <GitHub65> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5d98e0fa1496...b6f3a4eb19ae
1512015-10-06T08:01:57 <GitHub65> bitcoin/master 9204930 Peter Todd: Document pull-req #6424 in release-notes...
1522015-10-06T08:01:58 <GitHub65> bitcoin/master b6f3a4e Wladimir J. van der Laan: Merge pull request #6751...
1532015-10-06T08:02:07 <GitHub173> [bitcoin] laanwj closed pull request #6751: Document pull-req #6424 in release-notes (master...pull-req-6424-release-notes) https://github.com/bitcoin/bitcoin/pull/6751
1542015-10-06T08:02:37 <GitHub147> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b6f3a4eb19ae...79529e50dbe4
1552015-10-06T08:02:37 <GitHub147> bitcoin/master 202f612 Pavel JanÃk: The Bitcoin Core project is releasing Bitcoin Core, not Bitcoin.
1562015-10-06T08:02:38 <GitHub147> bitcoin/master 79529e5 Wladimir J. van der Laan: Merge pull request #6763...
1572015-10-06T08:02:43 <GitHub187> [bitcoin] laanwj closed pull request #6763: [Trivial] The Bitcoin Core project is releasing Bitcoin Core, not Bitcoin. (master...trivial_Bitcoin_vs_BitcoinCore_fix) https://github.com/bitcoin/bitcoin/pull/6763
1582015-10-06T08:03:45 <GitHub103> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79529e50dbe4...0a5385b23f33
1592015-10-06T08:03:46 <GitHub103> bitcoin/master efb37d4 randy-waterhouse: Changed run-bitcoind-for-test.sh.in to non-executable mode....
1602015-10-06T08:03:46 <GitHub103> bitcoin/master 0a5385b Wladimir J. van der Laan: Merge pull request #6760...
1612015-10-06T08:03:50 <GitHub82> [bitcoin] laanwj closed pull request #6760: Changed qa/pull-tester/run-bitcoind-for-test.sh.in to non-executable mode. (master...master) https://github.com/bitcoin/bitcoin/pull/6760
1622015-10-06T08:05:10 <GitHub73> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a5385b23f33...bdece5068bc7
1632015-10-06T08:05:11 <GitHub73> bitcoin/master dd28089 Johnathan Corgan: autotools: move checking for zmq library to common area in configure.ac...
1642015-10-06T08:05:11 <GitHub73> bitcoin/master bdece50 Wladimir J. van der Laan: Merge pull request #6743...
1652015-10-06T08:05:19 <GitHub28> [bitcoin] laanwj closed pull request #6743: autotools: move checking for zmq library to common area in configure.ac (master...fixes/6679) https://github.com/bitcoin/bitcoin/pull/6743
1662015-10-06T08:07:19 <GitHub158> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bdece5068bc7...66a86a3edb94
1672015-10-06T08:07:20 <GitHub158> bitcoin/master a19504b Pavel JanÃk: tests-config.sh is superseded by tests_config.py
1682015-10-06T08:07:20 <GitHub158> bitcoin/master 66a86a3 Wladimir J. van der Laan: Merge pull request #6762...
1692015-10-06T08:07:29 <GitHub76> [bitcoin] laanwj closed pull request #6762: [Trivial] tests-config.sh is superseded by tests_config.py [skip ci] (master...qatest_gitignore) https://github.com/bitcoin/bitcoin/pull/6762
1702015-10-06T08:08:25 *** randy-waterhouse has joined #bitcoin-core-dev
1712015-10-06T08:14:03 <GitHub116> [bitcoin] laanwj closed pull request #6642: Reduce systematic error of time offset measurements (master...MarcoFalke-2015-timeOffsetFix) https://github.com/bitcoin/bitcoin/pull/6642
1722015-10-06T08:14:48 *** instagibbs has quit IRC
1732015-10-06T08:17:14 *** paveljanik has quit IRC
1742015-10-06T08:18:07 *** instagibbs has joined #bitcoin-core-dev
1752015-10-06T08:22:08 <GitHub62> [bitcoin] laanwj closed pull request #6563: update miner_tests (master...miner_test) https://github.com/bitcoin/bitcoin/pull/6563
1762015-10-06T08:30:48 *** lightningbot` has joined #bitcoin-core-dev
1772015-10-06T08:31:59 *** btcdrak has quit IRC
1782015-10-06T08:33:43 *** btcdrak has joined #bitcoin-core-dev
1792015-10-06T08:34:40 *** d_t has quit IRC
1802015-10-06T09:19:31 *** goregrind has joined #bitcoin-core-dev
1812015-10-06T09:29:19 *** ParadoxSpiral has joined #bitcoin-core-dev
1822015-10-06T09:31:30 *** BashCo has joined #bitcoin-core-dev
1832015-10-06T10:18:18 *** Justitia has joined #bitcoin-core-dev
1842015-10-06T11:12:21 *** BashCo has quit IRC
1852015-10-06T11:17:05 *** jgarzik has quit IRC
1862015-10-06T11:39:42 *** da2ce7 has joined #bitcoin-core-dev
1872015-10-06T12:31:12 <GitHub74> [bitcoin] laanwj closed pull request #6248: Fix Qt build on arch by setting -fPIC (master...archbuild) https://github.com/bitcoin/bitcoin/pull/6248
1882015-10-06T13:10:14 *** BashCo has joined #bitcoin-core-dev
1892015-10-06T13:33:56 *** BashCo has quit IRC
1902015-10-06T13:40:42 *** BashCo has joined #bitcoin-core-dev
1912015-10-06T13:57:34 *** d_t has joined #bitcoin-core-dev
1922015-10-06T14:19:19 <GitHub10> [bitcoin] laanwj pushed 7 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/8a915e56f4be...5ed8d0b37e27
1932015-10-06T14:19:19 <GitHub110> [bitcoin] laanwj closed pull request #6750: Recent rejects backport to v0.11 (0.11...recent-rejects-v0.11-backport) https://github.com/bitcoin/bitcoin/pull/6750
1942015-10-06T14:19:20 <GitHub10> bitcoin/0.11 2983fe0 Peter Todd: Add uint256 support to CRollingBloomFilter...
1952015-10-06T14:19:20 <GitHub10> bitcoin/0.11 25cf122 Pieter Wuille: Reuse vector hashing code for uint256...
1962015-10-06T14:19:21 <GitHub10> bitcoin/0.11 83671ef Peter Todd: Make CRollingBloomFilter set nTweak for you...
1972015-10-06T14:34:42 <GitHub49> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/66a86a3edb94...b7d78fd0bd24
1982015-10-06T14:34:43 <GitHub49> bitcoin/master 535ed92 Gavin Andresen: Simple benchmarking framework...
1992015-10-06T14:34:44 <GitHub49> bitcoin/master 7072c54 Gavin Andresen: Support very-fast-running benchmarks...
2002015-10-06T14:34:44 <GitHub49> bitcoin/master b7d78fd Wladimir J. van der Laan: Merge pull request #6733...
2012015-10-06T14:34:52 <GitHub76> [bitcoin] laanwj closed pull request #6733: Simple benchmarking framework (master...bench) https://github.com/bitcoin/bitcoin/pull/6733
2022015-10-06T15:05:18 *** treehug88 has joined #bitcoin-core-dev
2032015-10-06T15:07:17 *** d_t has quit IRC
2042015-10-06T15:09:52 *** BashCo has quit IRC
2052015-10-06T15:11:45 *** d_t has joined #bitcoin-core-dev
2062015-10-06T15:22:44 *** CodeShark has quit IRC
2072015-10-06T15:25:28 <GitHub76> [bitcoin] laanwj closed pull request #6674: take steps towards standardizing and improving log output (master...logs) https://github.com/bitcoin/bitcoin/pull/6674
2082015-10-06T15:32:21 *** mtrythall has joined #bitcoin-core-dev
2092015-10-06T15:32:51 <mtrythall> hey sipa - want logging here too?
2102015-10-06T15:33:36 *** d_t has quit IRC
2112015-10-06T15:33:47 <sipa> mtrythall: check
2122015-10-06T15:34:24 *** [b__b] has joined #bitcoin-core-dev
2132015-10-06T15:34:27 <mtrythall> [b__b] ping
2142015-10-06T15:34:27 <[b__b]> Are you in need of my services, mtrythall?
2152015-10-06T15:34:32 <mtrythall> [b__b] help
2162015-10-06T15:34:33 <[b__b]> Available plugins: bangmotivate, help, last_seen, ping, logger (https://botbot.me/freenode/bitcoin-core-dev/help/)
2172015-10-06T15:35:34 *** BashCo has joined #bitcoin-core-dev
2182015-10-06T15:35:39 <sipa> mtrythall: is there any way to import older logs into botbot?
2192015-10-06T15:35:55 *** sipa changes topic to "Bitcoin Core development discussion and commit log | This is the channel for developing Bitcoin Core. Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: https://botbot.me/freenode/bitcoin-core-dev, http://www.erisian.com.au/bitcoin-core-dev/"
2202015-10-06T15:36:07 <mtrythall> not automatically, no
2212015-10-06T15:36:46 <mtrythall> it's a feature i'd love to have, but outside my skillset
2222015-10-06T15:37:16 <sipa> not even if we take care of converting it to whatever format the logs need to be in?
2232015-10-06T15:38:54 *** paveljanik has joined #bitcoin-core-dev
2242015-10-06T15:40:45 *** d_t has joined #bitcoin-core-dev
2252015-10-06T15:48:37 <GitHub42> [bitcoin] paveljanik opened pull request #6770: [Trivial] Ignore bench_bitcoin binary [skip ci] (master...bench_gitignore) https://github.com/bitcoin/bitcoin/pull/6770
2262015-10-06T15:51:12 <GitHub34> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b7d78fd0bd24...4fac576c619f
2272015-10-06T15:51:12 <GitHub34> bitcoin/master 42cb388 James O'Beirne: Add chainstate obfuscation to avoid spurious antivirus detection...
2282015-10-06T15:51:13 <GitHub34> bitcoin/master 4fac576 Wladimir J. van der Laan: Merge pull request #6650...
2292015-10-06T15:51:17 <GitHub112> [bitcoin] laanwj closed pull request #6650: Obfuscate chainstate (master...obfuscate_chainstate) https://github.com/bitcoin/bitcoin/pull/6650
2302015-10-06T15:54:11 <btcdrak> mtrythall, do you have any plugins like meetbot for botbot?
2312015-10-06T15:54:32 <mtrythall> not familiar with meetbot, so no
2322015-10-06T15:54:33 <mtrythall> what's meetbot?
2332015-10-06T15:55:13 <btcdrak> It allows IRC meeting minutes to be generated from IRC logs https://wiki.debian.org/MeetBot
2342015-10-06T15:55:48 <btcdrak> like this for example: http://meetbot.debian.net/apparmor/2015/apparmor.2015-01-05-15.16.html
2352015-10-06T15:56:14 <btcdrak> I was just curious if there were plugins
2362015-10-06T15:57:31 <mtrythall> there are plugins, but not for meetbot
2372015-10-06T15:57:37 <mtrythall> it's pretty easy to write a plugin
2382015-10-06T15:57:48 <mtrythall> all the code is up on Github for it
2392015-10-06T15:58:01 <mtrythall> take care :)
2402015-10-06T15:58:05 *** mtrythall has left #bitcoin-core-dev
2412015-10-06T16:02:05 *** BashCo has quit IRC
2422015-10-06T16:15:29 *** BashCo has joined #bitcoin-core-dev
2432015-10-06T16:18:48 <GitHub18> [bitcoin] morcos opened pull request #6771: Policy: Lower default limits for tx chains (master...lowerLimits) https://github.com/bitcoin/bitcoin/pull/6771
2442015-10-06T16:19:57 *** BashCo has quit IRC
2452015-10-06T16:20:20 *** d_t has quit IRC
2462015-10-06T16:43:42 *** d_t has joined #bitcoin-core-dev
2472015-10-06T17:02:02 *** d_t has quit IRC
2482015-10-06T17:02:21 *** d_t has joined #bitcoin-core-dev
2492015-10-06T17:16:13 *** jgarzik has joined #bitcoin-core-dev
2502015-10-06T18:01:25 *** challisto has quit IRC
2512015-10-06T18:32:50 *** ParadoxSpiral_ has joined #bitcoin-core-dev
2522015-10-06T18:36:11 *** ParadoxSpiral has quit IRC
2532015-10-06T18:36:17 *** BashCo has joined #bitcoin-core-dev
2542015-10-06T18:44:06 *** challisto has joined #bitcoin-core-dev
2552015-10-06T18:55:33 *** jgarzik has quit IRC
2562015-10-06T18:57:53 *** jgarzik has joined #bitcoin-core-dev
2572015-10-06T19:03:30 *** berndj has joined #bitcoin-core-dev
2582015-10-06T19:32:19 *** AtashiCon has quit IRC
2592015-10-06T19:33:11 *** Arnavion has quit IRC
2602015-10-06T19:39:26 *** BashCo has quit IRC
2612015-10-06T19:41:07 *** belcher has joined #bitcoin-core-dev
2622015-10-06T20:00:02 *** jgarzik has quit IRC
2632015-10-06T20:01:50 *** paveljanik has quit IRC
2642015-10-06T20:03:24 <sdaftuar> BlueMatt: around
2652015-10-06T20:03:25 <sdaftuar> ?
2662015-10-06T20:22:59 *** teward has quit IRC
2672015-10-06T20:30:09 <BlueMatt> sdaftuar: yea
2682015-10-06T20:30:22 <BlueMatt> (mostly)
2692015-10-06T20:35:14 *** teward has joined #bitcoin-core-dev
2702015-10-06T20:38:48 <BlueMatt> I'm not ignoring your comments on the pr, just backed up with other things atm
2712015-10-06T20:43:42 *** Jaamg has quit IRC
2722015-10-06T20:43:45 *** helo has quit IRC
2732015-10-06T20:43:46 *** aj has quit IRC
2742015-10-06T20:43:46 *** PRab has quit IRC
2752015-10-06T20:43:46 *** berndj has quit IRC
2762015-10-06T20:43:46 *** ProfMac has quit IRC
2772015-10-06T20:43:51 *** gmaxwell has quit IRC
2782015-10-06T20:43:51 *** cfields has quit IRC
2792015-10-06T20:43:53 *** jonasschnelli has quit IRC
2802015-10-06T20:43:53 *** gavinandresen has quit IRC
2812015-10-06T20:45:49 *** Jaamg has joined #bitcoin-core-dev
2822015-10-06T20:46:07 *** berndj has joined #bitcoin-core-dev
2832015-10-06T20:46:07 *** helo has joined #bitcoin-core-dev
2842015-10-06T20:46:07 *** PRab has joined #bitcoin-core-dev
2852015-10-06T20:46:07 *** aj has joined #bitcoin-core-dev
2862015-10-06T20:46:07 *** ProfMac has joined #bitcoin-core-dev
2872015-10-06T20:46:07 *** cfields has joined #bitcoin-core-dev
2882015-10-06T20:46:07 *** gavinandresen has joined #bitcoin-core-dev
2892015-10-06T20:46:07 *** gmaxwell has joined #bitcoin-core-dev
2902015-10-06T20:46:07 *** jonasschnelli has joined #bitcoin-core-dev
2912015-10-06T20:51:29 *** n0n0__ has quit IRC
2922015-10-06T21:03:00 *** randy-waterhouse has quit IRC
2932015-10-06T21:07:54 *** treehug88 has quit IRC
2942015-10-06T21:09:30 *** BashCo has joined #bitcoin-core-dev
2952015-10-06T21:22:03 *** ParadoxSpiral_ has quit IRC
2962015-10-06T22:09:18 *** michagogo has quit IRC
2972015-10-06T22:34:49 *** michagogo has joined #bitcoin-core-dev
2982015-10-06T23:11:38 *** BashCo has quit IRC
2992015-10-06T23:33:26 *** maaku__ has joined #bitcoin-core-dev