12015-10-01T00:19:36 <BlueMatt> wumpus: how did you measure the maxresident-during-compile thing?
22015-10-01T00:19:42 <BlueMatt> I'll run it on this jessie server
32015-10-01T00:28:25 *** zxzzt_ has joined #bitcoin-core-dev
42015-10-01T00:33:54 *** warren has joined #bitcoin-core-dev
52015-10-01T01:05:59 *** goregrind has quit IRC
62015-10-01T01:09:38 *** goregrind has joined #bitcoin-core-dev
72015-10-01T01:15:14 *** d_t has quit IRC
82015-10-01T01:38:46 *** nanotube has joined #bitcoin-core-dev
92015-10-01T01:55:51 *** Guest1234 has joined #bitcoin-core-dev
102015-10-01T03:03:21 *** jgarzik has quit IRC
112015-10-01T03:03:43 *** jgarzik has joined #bitcoin-core-dev
122015-10-01T03:03:45 *** jgarzik has joined #bitcoin-core-dev
132015-10-01T03:05:12 *** baldur has joined #bitcoin-core-dev
142015-10-01T03:58:00 *** d_t has joined #bitcoin-core-dev
152015-10-01T04:38:38 *** tripleslash has joined #bitcoin-core-dev
162015-10-01T05:09:21 *** d_t has quit IRC
172015-10-01T05:10:48 <rusty> BlueMatt: /usr/bin/time -v ?
182015-10-01T05:13:28 *** d_t has joined #bitcoin-core-dev
192015-10-01T05:25:46 *** ParadoxSpiral has joined #bitcoin-core-dev
202015-10-01T05:54:13 *** ParadoxSpiral has quit IRC
212015-10-01T06:00:30 <BlueMatt> rusty: except per-compile-target
222015-10-01T06:00:36 <BlueMatt> but, yea, thats probably how he did it
232015-10-01T06:00:44 <BlueMatt> I'm just lazy and was hoping for a one-liner instead of doing it myself
242015-10-01T06:00:50 <BlueMatt> I guess CXX=......
252015-10-01T06:02:52 *** zveda has joined #bitcoin-core-dev
262015-10-01T06:03:16 *** paveljanik has joined #bitcoin-core-dev
272015-10-01T06:06:33 *** go1111111 has joined #bitcoin-core-dev
282015-10-01T06:06:47 *** d_t has quit IRC
292015-10-01T06:07:21 *** zveda has left #bitcoin-core-dev
302015-10-01T06:22:36 *** CodeShark_ has joined #bitcoin-core-dev
312015-10-01T06:28:05 *** devrandom has joined #bitcoin-core-dev
322015-10-01T06:35:04 <wumpus> BlueMatt: yes, it's a time (logging the output to a file), CC=/CXX=, and a python script to process the results: https://gist.github.com/laanwj/108877a28ec03836568a
332015-10-01T06:36:04 <BlueMatt> ha! ask and ye shall succeed in being lazy :)
342015-10-01T06:47:04 <petertodd> interesting, got a report of Slush accepting low-S/high-S malleability: original: https://www.blocktrail.com/BTC/tx/586536ec5212cd53e243025f2dbf3330b47ac9aada1f2634ac63f590ea11f86f, mined: https://www.blocktrail.com/BTC/tx/1f94af0fbf2adc5f2ffaad45ad67d0ef844d76e879c05af4cd2c7c5ddf8ee43d
352015-10-01T06:47:21 <petertodd> 01000000022fba7d9ec118ddbe16efab46781e6899d65655ae936f57d078a4779e42a19b9a020000006a473044022036b64863715dff966f48604e1cf326af7619bb6b80a9777cac8c2a8810c6e3670220167a13b85207431a1556ebc7fe2c9ac90184dbf60305072d7eb20ea7aa97c41c012102b6243b0e1571f366383a98e432aea1781de7f527b7687e27c0a01e8fc8c60d1dffffffff4ed840270c06c648899a2b2b07796591ba735ab3acec3a8439a5dfa6d9d869972d0000006a4730440220258d60de0f6135991c25d2b406950bf ...
362015-10-01T06:47:24 <BlueMatt> jwtf
372015-10-01T06:47:25 <BlueMatt> wtf
382015-10-01T06:47:27 <petertodd> ... 6449a83821cd5630be0c7e3d8d6c6641602206e8efbef129dad1993fd3171dd908be899e76f9b336611bda4e7859f8381949501210238577ad5be7a48dc4bea10b473242cc6cb63a80887e7022a0a21005fe5b1f61fffffffff03b6c73e01000000001976a9142248f32ecfcddc8ede9ed1a45353eafffa4b15fa88acb6c73e01000000001976a9141b726719c8913fb9ff845a35a6054f2b665c951188acac704801000000001976a9142239da3ac4c7e210381178ca66d056ae212c6fe188ac00000000
392015-10-01T06:47:33 <petertodd> 01000000022fba7d9ec118ddbe16efab46781e6899d65655ae936f57d078a4779e42a19b9a020000006b483045022036b64863715dff966f48604e1cf326af7619bb6b80a9777cac8c2a8810c6e367022100e985ec47adf8bce5eaa9143801d36535b92a00f0ac43990e41204fe5259e7d25012102b6243b0e1571f366383a98e432aea1781de7f527b7687e27c0a01e8fc8c60d1dffffffff4ed840270c06c648899a2b2b07796591ba735ab3acec3a8439a5dfa6d9d869972d0000006a4730440220258d60de0f6135991c25d2b406950 ...
402015-10-01T06:47:34 <BlueMatt> wait, why wasnt that softforked out yet????
412015-10-01T06:47:39 <petertodd> ... bf6449a83821cd5630be0c7e3d8d6c6641602206e8efbef129dad1993fd3171dd908be899e76f9b336611bda4e7859f8381949501210238577ad5be7a48dc4bea10b473242cc6cb63a80887e7022a0a21005fe5b1f61fffffffff03b6c73e01000000001976a9142248f32ecfcddc8ede9ed1a45353eafffa4b15fa88acb6c73e01000000001976a9141b726719c8913fb9ff845a35a6054f2b665c951188acac704801000000001976a9142239da3ac4c7e210381178ca66d056ae212c6fe188ac00000000
422015-10-01T06:47:54 <petertodd> no, bip66 doesn't deal with low-s/hig-s
432015-10-01T06:48:00 <BlueMatt> i know it doesnt
442015-10-01T06:48:07 <BlueMatt> but it easily could have
452015-10-01T06:48:13 <BlueMatt> i guess thats the malleability bip.....
462015-10-01T06:48:23 <petertodd> well, could ave posed problems with old wallets
472015-10-01T06:48:39 <CodeShark_> BIP62 does that - BIP66 was pushed out as a fix to a more urgent issue
482015-10-01T06:48:53 <petertodd> (low-s/ig-s isn't related to the urgent problem of OpenSSL consensus)
492015-10-01T06:49:50 <petertodd> it'd be interesting to know what exactly is slush running and/or and what parts of IsStandard() have been commented out
502015-10-01T06:50:20 <BlueMatt> I'm aware of the reasons
512015-10-01T06:50:28 <BlueMatt> but....its already in the fucking code......
522015-10-01T06:50:30 <gmaxwell> There is no filtering of low/high S malleability.
532015-10-01T06:50:35 <BlueMatt> dude, who the fuck knows what slush is running
542015-10-01T06:50:38 <BlueMatt> gmaxwell: isnt it nonstandard?
552015-10-01T06:50:41 <gmaxwell> NO
562015-10-01T06:50:45 <gmaxwell> :)
572015-10-01T06:50:49 <BlueMatt> ohhhhh
582015-10-01T06:50:52 <BlueMatt> somehow i thought it was
592015-10-01T06:50:57 <gmaxwell> We cannot filter it right now because filtering is incompatible with a great many signers.
602015-10-01T06:51:11 <BlueMatt> i thought we had whittled that down to like one or two wallets
612015-10-01T06:51:17 <gmaxwell> Even in BIP66 it was going to be version gated.
622015-10-01T06:51:32 <petertodd> gmaxwell: oh, I thought we had that in IsStandard()... that takes all the fun out of it
632015-10-01T06:51:38 <gmaxwell> BlueMatt: oh no, I really really doubt that. I think you're remembering chasing canonical encodings.
642015-10-01T06:51:46 <gmaxwell> I wish.
652015-10-01T06:52:02 <BlueMatt> i thought it was, at one point, just blockchain.info and like one or two other really strange wallets
662015-10-01T06:52:05 <BlueMatt> this was a long time ago
672015-10-01T06:52:08 <BlueMatt> I'm sure more exist now
682015-10-01T06:52:11 <gmaxwell> I wanted to talk to petertodd about this actually. an interesting thing to do would be to use the RBF code to prefer lows.
692015-10-01T06:52:25 <petertodd> gmaxwell: haha
702015-10-01T06:52:29 <gmaxwell> BlueMatt: like _anyone_ who doesn't use ECDSA code that came from us will make the wrong kind.
712015-10-01T06:52:41 <petertodd> gmaxwell: speaking of, python-bitcoinlib now does low-S right
722015-10-01T06:53:03 <BlueMatt> gmaxwell: yes, that much I knew
732015-10-01T06:53:12 <BlueMatt> but long ago there were't /that/ many other wallets :p
742015-10-01T06:53:44 <BlueMatt> easiest solution: get one pool to just change everything mined to low-S
752015-10-01T06:53:55 <BlueMatt> then people's wallets would break in largely harmless ways
762015-10-01T06:54:04 *** d_t has joined #bitcoin-core-dev
772015-10-01T06:54:25 <BlueMatt> probably not entirely harmless, so maybe its dangerous
782015-10-01T06:54:27 <CodeShark_> one would hope ;)
792015-10-01T06:54:43 <BlueMatt> but I dont see anything that would obviously break without being trivially human-fixable
802015-10-01T06:54:49 <CodeShark_> I bet many wallets still track transactions by signed transaction hash
812015-10-01T06:54:58 <BlueMatt> most do, I'm sure
822015-10-01T06:55:02 <BlueMatt> but thats my point
832015-10-01T06:55:05 <BlueMatt> you'd show two txn
842015-10-01T06:55:08 <BlueMatt> and one failed
852015-10-01T06:55:18 <BlueMatt> (hopefully) not a huge deal anywhere
862015-10-01T06:56:41 <CodeShark_> in any case, this scenario is trivial to pull off so wallets that do think this is a big deal have a serious security issue
872015-10-01T06:57:44 <CodeShark_> karpeles excuses notwithstanding ;)
882015-10-01T07:02:08 <gmaxwell> I've brought up the mutate everythin approach, I think it's superior to just blocking completely.
892015-10-01T07:02:39 <gmaxwell> In any case, it's not hard to go measure this on the network, last time I did, it was ... all the non-canonical form.
902015-10-01T07:03:18 <gmaxwell> BlueMatt: it absolutely would break some wallets, but the same wallets are already super vulnerable.
912015-10-01T07:03:25 <CodeShark_> this raises an interesting point...BIP62 could be deployed along with a new relay policy that mutates transactions...
922015-10-01T07:03:49 <gmaxwell> Yes, its true. I'd only raised that before for lowS but its true generally.
932015-10-01T07:04:12 <gmaxwell> if your transactions are BIP62 friendly you get no mutation, otherwise you're always mutated.
942015-10-01T07:04:33 <BlueMatt> interesting deployment strategy :p
952015-10-01T07:05:21 <gmaxwell> for BIP66 we couldn't afford any debate, as we really needed to get the openssl consensus fix in, otherwise it would have been interesting to do it there.
962015-10-01T07:05:58 <gmaxwell> Even without the forced mutation, there is that RBF idea: if a lowS mutant comes in, replace.
972015-10-01T07:06:35 <phantomcircuit> gmaxwell, which pretty much instantly devolves into mutate everything :)
982015-10-01T07:06:38 <gmaxwell> means someone performing a mutation attack would have ~100% success on highS users and ~0% success on others.
992015-10-01T07:07:01 <gmaxwell> but absent an attack you're fine.
1002015-10-01T07:07:25 <gmaxwell> in any case, still leaves the general BIP62 problem that we're really not sure we got all the mutation vectors. :(
1012015-10-01T07:09:27 <gmaxwell> petertodd: fwiw this channel has existed since at least nov 2014.
1022015-10-01T07:12:12 <wumpus> it was created because people didn't want the github commit notifications on #bitcoin-dev
1032015-10-01T07:12:18 <wumpus> I think
1042015-10-01T07:16:06 <gmaxwell> I've missed it but didn't want to join another channel and was too lazy to remember to do the thing to merge the windows in irssi.
1052015-10-01T07:16:17 <gmaxwell> our commit volume is just not that high.
1062015-10-01T07:24:52 *** d_t has quit IRC
1072015-10-01T07:35:07 *** jl2012 has joined #bitcoin-core-dev
1082015-10-01T07:40:27 *** trippysalmon has joined #bitcoin-core-dev
1092015-10-01T07:57:51 *** rusty has quit IRC
1102015-10-01T08:07:53 <btcdrak> merge and pull request notification are very useful and will increase collaboration.
1112015-10-01T08:09:08 <paveljanik> +1
1122015-10-01T08:10:16 <jgarzik> +1
1132015-10-01T08:11:27 *** jl2012 has quit IRC
1142015-10-01T08:11:53 *** jl2012 has joined #bitcoin-core-dev
1152015-10-01T08:12:37 <wumpus> exactly, and we don't have that many commits that it gets in the way of discussion
1162015-10-01T08:21:48 *** Arnavion has quit IRC
1172015-10-01T08:22:18 *** rubensayshi has joined #bitcoin-core-dev
1182015-10-01T08:22:19 *** Arnavion has joined #bitcoin-core-dev
1192015-10-01T08:25:28 *** NLNico has joined #bitcoin-core-dev
1202015-10-01T08:34:19 *** TZander has joined #bitcoin-core-dev
1212015-10-01T08:36:27 <CodeShark_> are we still going to do the weekly core dev meetings on thursdays?
1222015-10-01T08:36:38 <CodeShark_> at the same time?
1232015-10-01T08:36:46 <wumpus> yes
1242015-10-01T08:36:50 <jgarzik> yes
1252015-10-01T08:36:54 <gmaxwell> I was assuming. I hope it goes more orderly than last time.
1262015-10-01T08:37:36 <gmaxwell> perhaps we should +m the channel between subjects or something, so we don't get three overlapping subjects and it starts moving so fast some people can't keep up?
1272015-10-01T08:37:37 <jgarzik> Fedora has an IRC meeting robot for logging, tracking agenda items, and notably, moving along from one item to the next
1282015-10-01T08:38:14 <jgarzik> Many subgroups in the Fedora community have weekly IRC meetings and associated software gadgetry to help
1292015-10-01T08:38:19 <CodeShark_> we just need to get the robot to come up with good ideas and code...and then none of us have to even be there :)
1302015-10-01T08:38:21 <wumpus> I have the following topics: CLTV(/CSV/...) deployment, mempool management. Feel free to suggest others
1312015-10-01T08:38:32 <gmaxwell> A lot of people (even IRC regulars) aren't really able to follow more than two concurrent discusisons.
1322015-10-01T08:38:59 <gmaxwell> We had homework from the last meeting that we should have reminded people about 24 hours out... we were supposted to review mempool management PRs.
1332015-10-01T08:39:28 <jgarzik> https://wiki.debian.org/MeetBot
1342015-10-01T08:39:29 <gmaxwell> I did, at least but maybe too promptly and have started swapping them out again. :(
1352015-10-01T08:39:42 <btcdrak> jgarzik: aj is adding that to the logging bot
1362015-10-01T08:40:14 <jgarzik> channel denizens tell MeetBot when topic A is finished, and it moves on to topic B
1372015-10-01T08:40:25 <jgarzik> produces nicely separated-out summaries by topic if necessary
1382015-10-01T08:40:33 <btcdrak> jgarzik: like this http://meetbot.debian.net/debconf-team/2015/debconf-team.2015-01-19-19.59.html
1392015-10-01T08:40:50 <jgarzik> yep
1402015-10-01T08:41:28 <btcdrak> well with any luck aj will have it setup for today's meeting, but otherwise, it will be there for sure next week
1412015-10-01T08:41:28 *** Naphex has joined #bitcoin-core-dev
1422015-10-01T08:45:01 *** GAit has joined #bitcoin-core-dev
1432015-10-01T08:48:19 *** jl2012 has quit IRC
1442015-10-01T08:49:01 *** jl2012 has joined #bitcoin-core-dev
1452015-10-01T08:52:58 <wumpus> minutes of last meeting were posted to the mailing list by Daniel Stadulis ( http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011190.html )
1462015-10-01T08:53:12 <Naphex> wumpus: that hearnban was best thing all month / grats
1472015-10-01T08:55:06 <jgarzik> wumpus, nod. It's not just taking minutes, but addressing e.g. gmaxwell concerns about multiple conversations going on at once. The btcdrak link shows much more than just meeting minutes: attendance log, actions resolved, to-do items and their owners, and more.
1482015-10-01T08:56:08 <wumpus> Naphex: yeah, it was about time
1492015-10-01T08:56:50 <gmaxwell> The multiple conversations don't bother me personally, but I _know_ some participants were left behind during the meeting because they couldn't keep up with the flood.
1502015-10-01T08:57:08 *** BashCo has joined #bitcoin-core-dev
1512015-10-01T08:57:10 <gmaxwell> For many years I used BitchX in a single window mode, while being in a dozen high traffic channels. :P
1522015-10-01T08:57:16 <wumpus> jgarzik: I was not posting it to argue with btcdrak :) just for information, re: the 'homework'
1532015-10-01T08:57:56 <wumpus> gmaxwell: I'm kind of slow so I have trouble following such things in real time :)
1542015-10-01T08:58:05 <gmaxwell> Other people are less crazy and have not subjected themselves to that kind of torture and prefer mettings deal with less than 10 things at a time.
1552015-10-01T08:59:07 <wumpus> I can read the English fast enough, these days, but following the chaos of different concerns at the same time can be problematic
1562015-10-01T09:20:37 <GitHub193> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1119cc3f5918...12a7712abd49
1572015-10-01T09:20:38 <GitHub193> bitcoin/master 835c122 Daniel Kraft: Clean up change computation in CreateTransaction....
1582015-10-01T09:20:39 <GitHub193> bitcoin/master 12a7712 Wladimir J. van der Laan: Merge pull request #5924...
1592015-10-01T09:20:39 <GitHub126> [bitcoin] laanwj closed pull request #5924: Clean up change computation in CreateTransaction. (master...change-cleanup) https://github.com/bitcoin/bitcoin/pull/5924
1602015-10-01T10:00:50 <GitHub55> [bitcoin] jgarzik pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/12a7712abd49...cf9bb11f97db
1612015-10-01T10:00:50 <GitHub55> bitcoin/master 9524c4d Tom Harding: In (strCommand == "tx"), return if AlreadyHave()...
1622015-10-01T10:00:51 <GitHub55> bitcoin/master cf9bb11 Jeff Garzik: Merge pull request #6588
1632015-10-01T10:01:00 <GitHub1> [bitcoin] jgarzik closed pull request #6588: In (strCommand == "tx"), return if AlreadyHave() (master...already_have) https://github.com/bitcoin/bitcoin/pull/6588
1642015-10-01T10:03:28 <GitHub178> [bitcoin] jgarzik pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf9bb11f97db...8a86d53bd570
1652015-10-01T10:03:28 <GitHub178> bitcoin/master 9639ead Wladimir J. van der Laan: doc: Add build guide for OpenBSD 5.7...
1662015-10-01T10:03:29 <GitHub178> bitcoin/master 8a86d53 Jeff Garzik: Merge pull request #6731
1672015-10-01T10:03:34 <GitHub54> [bitcoin] jgarzik closed pull request #6731: doc: Add build guide for OpenBSD 5.7 (master...2015_09_openbsd_build_guide) https://github.com/bitcoin/bitcoin/pull/6731
1682015-10-01T10:18:42 <aj> jgarzik, btcdrak, wumpus: hey, i think lightningbot works as a MeetBot now; http://www.erisian.com.au/meetbot/aj-test/2015/aj-test.2015-10-01-10.13.html
1692015-10-01T10:19:03 <btcdrak> nice work aj
1702015-10-01T10:20:12 <aj> btcdrak: you suck at pretending i didn't say anything btw :-P
1712015-10-01T10:20:36 <btcdrak> haha :)
1722015-10-01T10:21:09 <jgarzik> Trolling for reviews, add bip32 pub key serialization #6215 https://github.com/bitcoin/bitcoin/pull/6215
1732015-10-01T10:23:25 <jgarzik> Trolling for reviews, Bugfix: Fix testnet-in-a-box use case #5987 https://github.com/bitcoin/bitcoin/pull/5987
1742015-10-01T10:23:33 <btcdrak> Trolling for reviews, Mempool-only sequence number constraint verification https://github.com/bitcoin/bitcoin/pull/6312
1752015-10-01T10:23:49 <btcdrak> Trolling for reviews, Mempool-only CHECKSEQUENCEVERIFY https://github.com/bitcoin/bitcoin/pull/6564
1762015-10-01T10:25:14 <sipa> aj: who can give the bot commands?
1772015-10-01T10:26:00 <sipa> ah, the one who starts the meeting?
1782015-10-01T10:26:06 <jgarzik> btcdrak, (cc maaku): is there anywhere where use cases are discussed? BIP 112 just has one example
1792015-10-01T10:26:10 <aj> sipa: i think someone says #startmeeting and becomes the chair as a result
1802015-10-01T10:26:34 <jgarzik> some meeting bots allow channel participants to vote on "moving along"
1812015-10-01T10:26:48 <jgarzik> which can be helpful with contentious discussion that do not have a single chair
1822015-10-01T10:27:00 <btcdrak> jgarzik: BIP112 cites references where there are a ton of other uses
1832015-10-01T10:27:55 <btcdrak> jgarzik: for example: http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
1842015-10-01T10:27:58 <jgarzik> btcdrak, I must be blind :) I see one other reference related to use case, HTLC
1852015-10-01T10:28:05 <jgarzik> "ton of" == 2 :)
1862015-10-01T10:28:22 <btcdrak> :) I'm guilty of hyperbole
1872015-10-01T10:28:46 <CodeShark_> if the units are 1000 lbs, then yes, "ton of" == 2
1882015-10-01T10:30:20 <jgarzik> btcdrak, In any case, yes, maaku cajoled me as well. :) It's on the shortlist for review & test. It's in the "mostly ok" column but I want to understand how it impacts current payment channel stuff in the field.
1892015-10-01T10:32:38 <CodeShark_> its main purpose there is in providing a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction
1902015-10-01T10:33:36 <CodeShark_> absolute time lock means we need to close the channel and reopen it when we're getting close to the timeout
1912015-10-01T10:33:57 <CodeShark_> relative time lock means the clock starts ticking the moment the transaction gets in the block
1922015-10-01T10:35:46 <CodeShark_> it also means you know exactly how long you'll have to wait (in number of blocks) before you can pull your funds out of the channel in the event of a noncooperative counterparty
1932015-10-01T10:38:18 <CodeShark_> even if this were the only use case, I'd still say it's worth doing :)
1942015-10-01T10:40:12 *** Aquentin has joined #bitcoin-core-dev
1952015-10-01T10:40:34 <CodeShark_> the only nit I can possibly find is around naming
1962015-10-01T10:40:45 <CodeShark_> but as I've said before...meh
1972015-10-01T10:42:33 <jgarzik> Sorry, got my BIPs mixed up. It's BIP 68 that I need to understand deeply & thoroughly.
1982015-10-01T10:42:47 <jgarzik> redefinitions always make me nervous :)
1992015-10-01T10:45:02 <btcdrak> jgarzik: Should be clear in the BIP68 text.
2002015-10-01T10:46:05 <jgarzik> I wish BIPs were assigned 8-letter alphabetic codes; easier to disambiguate ;p
2012015-10-01T10:49:55 <wumpus> I like the short numbers
2022015-10-01T10:51:18 <wumpus> although I agre they're easy to confuse sometimes, but at least they stick in memory at some point
2032015-10-01T10:51:58 <jgarzik> not for me - I have to keep jumping to the BIP repo for older ones not actively discussed, or brand new ones that just appeared
2042015-10-01T10:52:42 <TZander> for rfcs there are simple lookups urls. So many a bot can be asked an rfc number and it will respond with the title
2052015-10-01T10:53:12 <wumpus> we had that at some point, but it probably broke when moving to a git repo instead of the wiki
2062015-10-01T10:53:31 <jgarzik> yeah, someone snag bitrfc.co and connect it to a bot
2072015-10-01T10:53:52 <TZander> I saw a wiki that is backed by a git repo; best of both worlds.
2082015-10-01T10:54:42 <Aquentin> I'm a bit scared, looks like a purge is going on...???
2092015-10-01T10:55:21 <sipa> ?
2102015-10-01T10:55:36 <Aquentin> why was this channel created?
2112015-10-01T10:56:09 <CodeShark_> to track merges and pull requests ;)
2122015-10-01T10:56:10 <TZander> Aquentin: Channel #bitcoin-core-dev created on Mon Nov 17 2014
2132015-10-01T10:56:29 <Aquentin> it didnt get a log bot until yesterday
2142015-10-01T10:56:39 <CodeShark_> yes, now it also contains dialog
2152015-10-01T10:57:00 <Aquentin> does jgarzick and gavinandresen have mod here?
2162015-10-01T10:57:11 <wumpus> to avoid political meta discussion, and focus on develpoment of the Bitcoin Core project in github.com/bitcoin/bitcoin
2172015-10-01T10:57:19 <wumpus> so strictly you're off topic
2182015-10-01T10:57:48 <Aquentin> I know... but sometime some things are too important for strict rules... such as when there seems to be a purge, coup, ostricising, whatever
2192015-10-01T10:57:58 <wumpus> last warning
2202015-10-01T10:58:43 <TZander> wumpus: thats a bit harsh...
2212015-10-01T10:59:04 <wumpus> I have to be, to avoid this becoming #bitcoin-dev again
2222015-10-01T10:59:52 <TZander> I think thats what they are talking about when people say that resolving issues is best. Otherwise they tend to follow you around.
2232015-10-01T11:00:07 <TZander> anyway #bitcoin-dev is kinda empty right now
2242015-10-01T11:00:27 <wumpus> the list of issues to be resolved here is at: https://github.com/bitcoin/bitcoin/issues , there are 367 open, good luck
2252015-10-01T11:01:10 <wumpus> after they're all closed, we could talk about something else :)
2262015-10-01T11:02:34 <jonasschnelli> jgarzik: cfields: does this makes sense: https://github.com/jonasschnelli/bitcoin/commit/37b779d031059982111f352ffe0c18b336113bba
2272015-10-01T11:03:01 <jonasschnelli> that change did work on my local machines (osx/debian)
2282015-10-01T11:03:55 <jonasschnelli> maybe L34 change is wrong... will double-check.
2292015-10-01T11:05:11 <TZander> wumpus: I'm not the one that has to resolve your issues ;)
2302015-10-01T11:06:22 <wumpus> TZander: you don't have to, working on open source is voluntary, but working on that repository is the point of this channel so please respect that
2312015-10-01T11:09:29 *** rusty has joined #bitcoin-core-dev
2322015-10-01T11:10:50 <Aquentin> The way people work on open source is part of working on open source and it seems to me that you sipa and gmaxwell are on the verge of declaring yourselves emperors unless you give mod to jgarzick gavin and all other core committers
2332015-10-01T11:11:45 <Aquentin> this isn't your project to dictate by ostracising
2342015-10-01T11:11:58 <CodeShark_> go away
2352015-10-01T11:12:00 <stonecoldpat> ugh, mod doesn't matter. People are here just to do work, please respect the channel.
2362015-10-01T11:12:22 <Aquentin> course it matters... banning developers from contributing does matter
2372015-10-01T11:12:35 *** ChanServ sets mode: +o wumpus
2382015-10-01T11:13:02 *** wumpus sets mode: +b *!*@unaffiliated/aquentin
2392015-10-01T11:13:09 *** Aquentin was kicked by wumpus (nothere)
2402015-10-01T11:13:09 * jonasschnelli hopes this channel keeps troll free and is used only for tech. topics
2412015-10-01T11:13:43 *** ChanServ sets mode: -o wumpus
2422015-10-01T11:28:36 <btcdrak> TZander: No it's not harsh, this channel is for core development discussions only and everything else is OT. If you want to have those discussions, take them to another channel.
2432015-10-01T11:34:45 <TZander> btcdrak: hey, I'm not the one that got kick/banned. I just wondered about how fast a warning should come when someone (not me) askes who is a moderator here.
2442015-10-01T11:35:08 <CodeShark_> we don't want that attitude in here, regardless of the specific question
2452015-10-01T11:36:04 <CodeShark_> anyone can create their own channel and discuss whatever topics they like
2462015-10-01T11:36:21 <wumpus> yes, it's not really about that question, just the way he came into here with the typical troll attitude. Anyhow, let's let it go.
2472015-10-01T11:37:09 * wumpus does need to actually add more moderators at some point here, but it has nothing to do with who is developer or not
2482015-10-01T11:47:40 *** ChanServ sets mode: +o wumpus
2492015-10-01T11:48:08 *** wumpus 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: http://www.erisian.com.au/bitcoin-core-dev/"
2502015-10-01T11:48:18 * wumpus stole #tor-dev's topic line
2512015-10-01T11:48:46 *** ChanServ sets mode: -o wumpus
2522015-10-01T11:59:26 *** rusty has quit IRC
2532015-10-01T12:11:32 *** CodeShark_ has quit IRC
2542015-10-01T12:12:49 <GitHub144> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8a86d53bd570...4899a04c24b9
2552015-10-01T12:12:50 <GitHub144> bitcoin/master e761d7a Luke Dashjr: Bugfix: Allow mining on top of old tip blocks for testnet (fixes testnet-in-a-box use case)
2562015-10-01T12:12:50 <GitHub144> bitcoin/master 4899a04 Wladimir J. van der Laan: Merge pull request #5987...
2572015-10-01T12:12:53 <GitHub44> [bitcoin] laanwj closed pull request #5987: Bugfix: Fix testnet-in-a-box use case (master...bugfix_tniab) https://github.com/bitcoin/bitcoin/pull/5987
2582015-10-01T13:27:51 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/6637 <--- seeks for a final review
2592015-10-01T13:50:22 *** Cocodude has joined #bitcoin-core-dev
2602015-10-01T13:52:16 <michagogo> 11:57:10 <gmaxwell> For many years I used BitchX in a single window mode, while being in a dozen high traffic channels. :P <-- Uh. At that point, why not just use netcat? :-P
2612015-10-01T13:57:48 <Cocodude> Is anyone seeing a lot of transaction malleability on the network again?
2622015-10-01T13:58:23 <wumpus> michagogo: because bitchx was l33t and had lots of colors :)
2632015-10-01T13:58:46 <wumpus> Cocodude: haven't noticed yet
2642015-10-01T13:59:24 <Cocodude> Already had one user on Bittylicious threatening to take us to Trading Standards because BitPay's Insight says there was a double spend and "not to trust this transaction"!
2652015-10-01T14:00:32 <btcdrak> jonasschnelli: can you add "You need to re-do ./autogen.sh and ./configure after this is merged" in the PR body, so it's clear for everyone.
2662015-10-01T14:02:34 <jonasschnelli> btcdrak: better: https://github.com/bitcoin/bitcoin/pull/6637?
2672015-10-01T14:03:24 <Cocodude> (we're only using Insight as a URL to give to users to show their transaction details)
2682015-10-01T14:03:41 <btcdrak> jonasschnelli: yes!
2692015-10-01T14:03:42 *** assadasafrt has joined #bitcoin-core-dev
2702015-10-01T14:04:17 <wumpus> well it's possible that someone is sneakily mutilating transactions on the network before relaying
2712015-10-01T14:04:29 <btcdrak> Cocodude: Use another block explorer like blocktrail.com
2722015-10-01T14:04:40 <jonasschnelli> btcdrak: Okay. Thanks for pointing this out.
2732015-10-01T14:04:56 <Cocodude> btcdrak: Yes, I think I will
2742015-10-01T14:05:16 <wumpus> Cocodude: do you have a copy of the tx hex of the original and conflicting transaction?
2752015-10-01T14:05:41 <Cocodude> btcdrak: blocktrail.com is already great - it gives the transaction that is "Double spent by", which will help the user identify the real txnid.
2762015-10-01T14:05:53 <Cocodude> wumpus: One example is https://www.blocktrail.com/BTC/tx/8c6995a207c79de1c356bc07fa23f3e2e76c73d9cb18a8bf84baad125104bad5
2772015-10-01T14:06:07 <Cocodude> But it's happened with a few txns over the last hour or so
2782015-10-01T14:06:50 *** assadasafrt has left #bitcoin-core-dev
2792015-10-01T14:15:03 <wumpus> blocktrail doesn't make it easy to get at the raw tx data (can't find it)
2802015-10-01T14:15:40 <wumpus> someone on #bitcoin also reporting malleated transactions
2812015-10-01T14:22:47 <GitHub147> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4899a04c24b9...17d0e638b66b
2822015-10-01T14:22:48 <GitHub147> bitcoin/master 110a1fd Jonas Schnelli: enable zmq-test in rpc-tests.sh
2832015-10-01T14:22:48 <GitHub147> bitcoin/master a9c27cd Jonas Schnelli: [travis] add zmq python module
2842015-10-01T14:22:49 <GitHub147> bitcoin/master 745f909 Cory Fields: travis: install a recent libzmq and pyzmq for tests
2852015-10-01T14:22:57 <GitHub83> [bitcoin] laanwj closed pull request #6686: [travis] add zmq python module, re-enable zmq rpc tests (master...2015/09/travis_zmq) https://github.com/bitcoin/bitcoin/pull/6686
2862015-10-01T14:28:03 <helo> nice bot...
2872015-10-01T14:30:38 <Cocodude> A follower on twitter interestingly stated that BIP66 should have sorted out the fake double spends. Is BIP66 live?
2882015-10-01T14:34:04 *** rubensayshi has quit IRC
2892015-10-01T14:34:43 <TZander> Cocodude: not related, and yes. For some time now.
2902015-10-01T14:34:54 <Cocodude> Ah, OK, ta
2912015-10-01T14:35:01 *** rubensayshi has joined #bitcoin-core-dev
2922015-10-01T14:35:35 <wumpus> Cocodude: that's BIP62, not BIP66. BIP66 forces strict DER encoding for signatures, it does not address other malleability issues
2932015-10-01T14:36:33 <Cocodude> Got it. I'll keep an eye on BIP62's progress
2942015-10-01T14:36:39 <GitHub50> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/17d0e638b66b...f297042cae57
2952015-10-01T14:36:39 <GitHub50> bitcoin/master 0917306 Jonas Schnelli: remove univalue, prepare for subtree
2962015-10-01T14:36:40 <GitHub50> bitcoin/master 2f9f082 Jonas Schnelli: Squashed 'src/univalue/' content from commit 87d9045...
2972015-10-01T14:36:40 <GitHub50> bitcoin/master 6e16a41 Jonas Schnelli: Merge commit '2f9f082b5ef3c495c70598ef23383effef675f9a' as 'src/univalue'
2982015-10-01T14:36:43 <GitHub25> [bitcoin] laanwj closed pull request #6637: Add UniValue as subtree (master...2015/09/univalue_subtree) https://github.com/bitcoin/bitcoin/pull/6637
2992015-10-01T14:38:33 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/6215 <-- trivial review, code is only used in unit tests right now
3002015-10-01T14:40:39 * jonasschnelli has sunken so low that he's cheerleading his pull requests, ..
3012015-10-01T14:42:37 <wumpus> well it's good to get the number of open pulls down a bit
3022015-10-01T14:43:28 <paveljanik> UniValue compiles cleanly here - OS X, clean build
3032015-10-01T14:43:31 <paveljanik> congrats!
3042015-10-01T14:45:22 <jonasschnelli> paveljanik: thanks for letting us know!
3052015-10-01T14:46:35 <GitHub171> [bitcoin] jonasschnelli closed pull request #6580: [UniValue] replace global function find_value() with UniValue::findValue() (master...2015/08/univalue_find_value) https://github.com/bitcoin/bitcoin/pull/6580
3062015-10-01T14:47:53 <wumpus> that pull moved to the univalue repository?
3072015-10-01T14:49:19 <jonasschnelli> wumpus: yeah. Need to do that upstream now... that was one of the goals, ... to improve UniValue without disturbing bitcoin-core.
3082015-10-01T14:50:10 <jonasschnelli> Only do a UniValue-Upgrade PR if there are reasonable changes that are worth merging.
3092015-10-01T14:50:49 <jonasschnelli> UniValue is also inconsistent with code style... get_str() and IsStr(), etc. Have plans to make it clean.
3102015-10-01T14:51:34 *** d_t has joined #bitcoin-core-dev
3112015-10-01T14:51:35 <wumpus> yes, it's mixing bitoin-core style UpperCamelCase methods with c_style_names, better to decide on one :)
3122015-10-01T14:52:20 <jonasschnelli> Right. I think it was mainly done this way because it reduced the diff when switch from json_spirit to univalue.
3132015-10-01T14:52:31 <wumpus> smaller diff, yes likely
3142015-10-01T14:53:20 <sipa> wumpus: is the meeting in this channel?
3152015-10-01T14:54:22 <wumpus> sipa: it's still on the schedule as #bitcoin-dev. Could announce a new channel, don't know what makes sense.
3162015-10-01T14:54:42 <sipa> either is fine to me, just want to know
3172015-10-01T14:55:13 <jonasschnelli> Maybe its better communication to do it on #bitcoin-dev unless there are clear infos about where the next irc meeting will be
3182015-10-01T14:55:21 <sipa> ok, #bitcoin-dev
3192015-10-01T14:55:24 <wumpus> ok, I'd say keep it to #bitcoin-dev for this week, we could move it next week, and announce somewhat longer in before
3202015-10-01T14:55:26 <wumpus> right
3212015-10-01T14:56:48 *** GAit has quit IRC
3222015-10-01T15:01:48 *** ParadoxSpiral has joined #bitcoin-core-dev
3232015-10-01T15:02:03 *** dgenr8 has joined #bitcoin-core-dev
3242015-10-01T15:10:10 *** lightningbot has joined #bitcoin-core-dev
3252015-10-01T15:10:45 <jgarzik> jonasschnelli, wumpus: json_spirit used find_value get_int etc. It would be better to move to consistency with CamelCaps.
3262015-10-01T15:11:16 <jonasschnelli> jgarzik: i'm currently doing this right tow :) .. will open a PR soon
3272015-10-01T15:11:32 <jonasschnelli> things like s/get_str()/getString() ... etc.
3282015-10-01T15:12:17 <jgarzik> +1
3292015-10-01T15:13:01 <jonasschnelli> the only function i'll keep is push_back (instead of pushBack) to keep it more std::vector compatible.
3302015-10-01T15:13:37 <wumpus> lowerCamelCast or UpperCamelCase? :p
3312015-10-01T15:14:08 <jgarzik> jonasschnelli, nod - that was the idea - match STL naming where possible, since it is a container.
3322015-10-01T15:15:11 <jonasschnelli> jgarzik: okay.. i'll keep that and use lowerCamelCast for non STL calls
3332015-10-01T15:15:46 <jgarzik> jonasschnelli, the typical C++ recommended naming is BlahBlah for classes and blahBlah for methods
3342015-10-01T15:15:50 <jgarzik> AFAIK
3352015-10-01T15:15:59 <wumpus> yes, that's also what I have mostly seen
3362015-10-01T15:16:05 <wumpus> at least Qt does that
3372015-10-01T15:16:06 <jgarzik> ditto for class members
3382015-10-01T15:16:27 <jonasschnelli> lowerCamelCast for functions is a quasi standard for oo languages.
3392015-10-01T15:16:44 <wumpus> I've seen C conventions used for methods/properties, but never UpperCamelCase before Satoshi =)
3402015-10-01T15:16:46 <jonasschnelli> s/functions/methods
3412015-10-01T15:17:06 <sipa> wumpus: Google has BlahBlah both for functions and methods
3422015-10-01T15:17:11 <jgarzik> I've seen C++ using BlahBlah for functions many times
3432015-10-01T15:17:18 <jgarzik> (as distinguished from methods)
3442015-10-01T15:17:50 <wumpus> sipa: ooh
3452015-10-01T15:26:14 *** Cocodude has left #bitcoin-core-dev
3462015-10-01T15:33:52 *** Eliel has joined #bitcoin-core-dev
3472015-10-01T19:18:05 *** lightningbot has joined #bitcoin-core-dev
3482015-10-01T19:18:07 <Cocodude> Sweet, thanks for that
3492015-10-01T19:25:42 <gmaxwell> !ops
3502015-10-01T19:29:20 <GitHub54> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/bb882d04e862...cd78c2a421ae
3512015-10-01T19:29:21 <GitHub54> bitcoin/master 6a07eb6 Peter Todd: Make TX_SCRIPTHASH clear vSolutionsRet first...
3522015-10-01T19:29:21 <GitHub54> bitcoin/master 5d8709c Peter Todd: Add IsPushOnly(const_iterator pc)...
3532015-10-01T19:29:22 <GitHub54> bitcoin/master da894ab Peter Todd: Accept any sequence of PUSHDATAs in OP_RETURN outputs...
3542015-10-01T19:29:25 <GitHub63> [bitcoin] laanwj closed pull request #6424: Policy: Decouple Solver() from nMaxDatacarrierBytes (for free) (master...policy-datacarriersize-0.11.99) https://github.com/bitcoin/bitcoin/pull/6424
3552015-10-01T19:31:36 <warren> Why are there a ton of ligtningbots?
3562015-10-01T19:32:14 <jonasschnelli> good question,.. :)
3572015-10-01T19:33:21 <Cocodude> sipa: Sorry again. It's all changed from when I looked at the code some time back. Do you know if there's a specific #define or similar any more for the magic numbers?
3582015-10-01T19:33:52 <sipa> there is an array with all prefixes, initialized for each chain separately in chainparams
3592015-10-01T19:33:52 <btcdrak> warren: I've PMd aj who owns the loggers.
3602015-10-01T19:35:16 <Cocodude> base58Prefixes I assume?
3612015-10-01T19:36:02 <sipa> yes
3622015-10-01T19:36:38 <Cocodude> Ha. Right, I know where I went wrong. I was looking at the dogecoind source and realising the magic numbers didn't match up.
3632015-10-01T19:36:44 <Cocodude> Sorry :p
3642015-10-01T19:39:53 <warren> not sure if asking about the status of RCLTV is on-topic
3652015-10-01T19:59:43 *** pavel__ has joined #bitcoin-core-dev
3662015-10-01T19:59:49 *** paveljanik has quit IRC
3672015-10-01T19:59:52 *** pavel__ has quit IRC
3682015-10-01T20:00:02 *** paveljanik has joined #bitcoin-core-dev
3692015-10-01T20:23:56 *** treehug88 has quit IRC
3702015-10-01T20:34:13 *** BashCo has joined #bitcoin-core-dev
3712015-10-01T20:35:52 *** BashCo_ has quit IRC
3722015-10-01T20:50:04 <btcdrak> I've asked a bunch of people privately to take a look, I'm not sure what else to do.
3732015-10-01T20:50:09 <wumpus> BIP112 is 'CSV' right? are the others depndent on that?
3742015-10-01T20:50:54 *** aj has quit IRC
3752015-10-01T20:50:54 <btcdrak> gmaxwell: they are all ready for merging from maaku's perspective. They have all been rebased.
3762015-10-01T20:50:54 *** lightningbot has joined #bitcoin-core-dev
3772015-10-01T20:50:54 *** ChanServ sets mode: +o wumpus
3782015-10-01T20:51:10 *** aj has joined #bitcoin-core-dev
3792015-10-01T20:51:53 <btcdrak> wumpus: BIP68 redefines nSequence, BIP112 creates an opcode for it.
3802015-10-01T20:51:53 <wumpus> aj: can you fix your bot please? it's entering and exiting all the time
3812015-10-01T20:52:20 *** lightningbot has quit IRC
3822015-10-01T20:52:22 *** ChanServ sets mode: +o wumpus
3832015-10-01T20:52:48 *** wumpus sets mode: +b *!~supybot@cerulean.erisian.com.au
3842015-10-01T20:52:52 <maaku> (it's kinda silly to have BIP112/CSV without BIP68/sequencenumbers, but technically they do not depend on each other in the same way that CLTV does not actually depend on nLockTime doing anything)
3852015-10-01T20:53:03 <wumpus> btcdrak: okay, thanks
3862015-10-01T20:53:03 <maaku> BIP68 / #6312 and BIP112 / #6564 are dependency-free
3872015-10-01T20:53:03 <maaku> BIP113 / #6566 builds off #6312
3882015-10-01T20:53:14 *** wumpus sets mode: +b *!lightningb@cerulean.erisian.com.au
3892015-10-01T20:53:30 <btcdrak> wumpus: BIP68 redefines nSequence, BIP112 creates an opcode for it.
3902015-10-01T20:53:58 *** wumpus sets mode: +b *!supybot@2400:8900::f03c:91ff:fedf:3a06
3912015-10-01T20:54:12 <wumpus> aj: let me know when you fixed the issues, then I'll unban them again
3922015-10-01T20:54:14 <btcdrak> maaku: so we could actually merge BIP112 now
3932015-10-01T20:55:14 <gmaxwell> maaku: has there been any objections (at all) to BIP113?
3942015-10-01T20:58:00 <wumpus> they're all leaving
3952015-10-01T21:00:00 <gmaxwell> maaku: I think I can make a pretty strong case that CLTV shouldn't go out without that one, simply because it changes the locktime semantics slightly... and we probably should not amplify nlocktime use right before changing the semantics.
3962015-10-01T21:01:01 <btcdrak> gmaxwell: and in that case, it means BIP68 is required too.
3972015-10-01T21:01:02 <sipa> bip68 doesn't change locktime semantics
3982015-10-01T21:01:03 <btcdrak> since BIP113 builds on 68
3992015-10-01T21:02:00 <gmaxwell> btcdrak: artifact of software.
4002015-10-01T21:05:00 <gmaxwell> Okay, so it sounds like main limitations are just on software review.
4012015-10-01T21:06:01 <gmaxwell> I know that PT had some specific documentation asks related to 68/112, basically he wanted more usecase examples.
4022015-10-01T21:06:02 <GitHub196> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/19c71864258f...5ab5dca6f1bb
4032015-10-01T21:06:03 <GitHub196> bitcoin/master 5467820 ptschip: Migrated rpc-tests.sh to all python rpc-tests.py...
4042015-10-01T21:06:04 <GitHub196> bitcoin/master 5ab5dca Wladimir J. van der Laan: Merge pull request #6616...
4052015-10-01T21:06:05 <GitHub91> [bitcoin] laanwj closed pull request #6616: Regression Tests: Migrated rpc-tests.sh to all Python rpc-tests.py (master...all_python) https://github.com/bitcoin/bitcoin/pull/6616
4062015-10-01T21:07:00 <gmaxwell> Which I think is reasonable. I suggested another candidate example space to maaku earlier today.
4072015-10-01T21:08:00 <gmaxwell> though generally I think most CLTV cases can be restated 'But with relative locktime!' and end up with a more robust protocol.
4082015-10-01T21:08:00 <btcdrak> gmaxwell: indeed
4092015-10-01T21:13:00 * btcdrak is impressed. The number of open PRs has reduced by 11+ in the last 24 hours...
4102015-10-01T21:15:00 <Anduck> closed or merged?
4112015-10-01T21:16:00 <wumpus> either
4122015-10-01T21:22:00 <btcdrak> do we want a bot to expand pull request numbers to URLs in this channel?
4132015-10-01T21:23:00 <kanzure> i am fine if the bot is only doing that
4142015-10-01T21:23:01 <kanzure> (e.g. no (automatic) titlebot spam)
4152015-10-01T21:24:00 <wumpus> I don't think it should expand all pull request numbers, we use them too much here
4162015-10-01T21:25:00 <wumpus> but if it has an explicit command to request a pull request number expansion that's ok with me, eg if you usea specific syntax
4172015-10-01T21:33:00 <gmaxwell> yea, thats good.
4182015-10-01T21:43:00 <wumpus> speaking of that, does anyone know of a good command line / ncurses utility to manipulate github pull requests? (through the API) Would like it but don't really feel like writing it.
4192015-10-01T21:43:00 <gmaxwell> man that would be nice.
4202015-10-01T21:44:00 <devrandom> wumpus: perhaps https://github.com/defunkt/github-gem can help, not sure how much PR support it has
4212015-10-01T21:47:00 <wumpus> devrandom: thanks, seems it has issues support, but don't see anything about PRs either (but maybe it includes that)
4222015-10-01T21:49:00 <kanzure> wumpus: there's a github cli client that the github people maintain
4232015-10-01T21:50:00 <kanzure> wumpus: https://github.com/github/hub
4242015-10-01T22:05:00 <maaku> gmaxwell: if anyone has any objections re: 113, they have yet to voice them
4252015-10-01T22:08:00 <GitHub142> [bitcoin] laanwj closed pull request #5422: Update block-tester (master...mempoolfix4) https://github.com/bitcoin/bitcoin/pull/5422
4262015-10-01T22:09:00 <kanzure> maaku: re: https://github.com/bitcoin/bitcoin/pull/6564 my concern was something about CSV-failing transaction rejection and then parent replacement if it was also in mempool, but nevermind i see why that's not important here
4272015-10-01T22:09:00 <kanzure> maaku: re: https://github.com/bitcoin/bitcoin/pull/6564 my concern was something about CSV-failing transaction rejection and then parent replacement if it was also in mempool, but nevermind i see why that's not important here
4282015-10-01T23:12:00 <nanotube> !bpr 5422
4292015-10-01T23:12:00 <gribble> Update block-tester by TheBlueMatt · Pull Request #5422 · bitcoin/bitcoin · GitHub | https://github.com/bitcoin/bitcoin/pull/5422
4302015-10-01T23:13:00 <nanotube> ^ have fun. as requested.
4312015-10-01T23:14:00 <sipa> !bpr 4096
4322015-10-01T23:14:00 <gribble> variable was used before it was initialized by tuttleorbuttle · Pull Request #4096 · bitcoin/bitcoin · GitHub | https://github.com/bitcoin/bitcoin/pull/4096
4332015-10-01T23:15:00 <sipa> does it work inside (,,bpr 4096)
4342015-10-01T23:15:00 <sipa> or something like that
4352015-10-01T23:17:00 <nanotube> commas first
4362015-10-01T23:17:00 <nanotube> like ,,(bpr 4096)
4372015-10-01T23:17:00 <gribble> variable was used before it was initialized by tuttleorbuttle · Pull Request #4096 · bitcoin/bitcoin · GitHub | https://github.com/bitcoin/bitcoin/pull/4096